Микрот hap ac2, os версия 6.47.4. Поднят l2tp+ipsec сервер, и к нему по впн коннектится второй такой же микротик с такой же версией ОС.
1) Почему я не вижу в nignbors мак адреса микротиков? Что с одного не вижу, что с другого не вижу. Сам микротик виден, видно все кроме мака, соответственно и подключиться невозможно. Собстевнно из-за этого же не работает и Romon. В мак сервер все включено, в negnbors тоже. Куда копать?
даже вот это добавил
add action=accept chain=input comment="Winbox MAC" dst-port=20561 \
in-interface-list=!Internet protocol=udp
add action=accept chain=input dst-port=5678 protocol=udp
2)
в фаерволе для ipsec созданы несколько правил, но почему-то через них ничего не ходит..
add action=accept chain=input comment=IPSec protocol=ipsec-esp
add action=accept chain=forward comment=Ipsec ipsec-policy=in,ipsec
add action=accept chain=forward ipsec-policy=out,ipsec
нужны ли они?
Полный фаервол прилагаю:
Несколько вопросов (ipsec, мак адреса, neignbors)
-
- Сообщения: 4204
- Зарегистрирован: 25 фев 2018, 22:41
- Откуда: Москва
1) у вас туннель 3 уровня, откуда там мак-адреса?
2) по первому правилу трафик будет ходить только между белыми адресами.
если на одном из устройств адрес серый, то будет udp 4500 использоваться.
остальные два правила в цепочке forward - а туннель вы устанавливаете между самими роутерами, так что там вы ничего и не увидите.
2) по первому правилу трафик будет ходить только между белыми адресами.
если на одном из устройств адрес серый, то будет udp 4500 использоваться.
остальные два правила в цепочке forward - а туннель вы устанавливаете между самими роутерами, так что там вы ничего и не увидите.
Telegram: @thexvo
-
- Сообщения: 162
- Зарегистрирован: 30 окт 2020, 15:00
Спасибо за ответ, доходчиво и по делу:
Но маки же появляются еще на втором уровне... и на третьем они есть. Почему их там не должно быть?
про вторые два правила действительно, поменял на input и outpoot, по логам видны хождения через порт 1701. А .т.к. у меня есть правило с открытым этим портом, то эти два правила бесполезны. Правильно?xvo писал(а): ↑30 окт 2020, 15:39 2) по первому правилу трафик будет ходить только между белыми адресами.
если на одном из устройств адрес серый, то будет udp 4500 использоваться.
остальные два правила в цепочке forward - а туннель вы устанавливаете между самими роутерами, так что там вы ничего и не увидите.
-
- Сообщения: 4204
- Зарегистрирован: 25 фев 2018, 22:41
- Откуда: Москва
У вас в этих туннелях нет никакого второго уровня.
Поэтому и маков нет.
Не совсем так.
В таком виде, тем более в output, они не нужны.
Но например добавить условие in,ipsec прямо в правило на 1701й порт очень даже полезно - обезопасите себя от случайного подключения без ipsec, и от того, что к вам на 1701ы порт будут ломиться все, кому не лень.
Telegram: @thexvo
-
- Сообщения: 162
- Зарегистрирован: 30 окт 2020, 15:00
хм.. я еще больше запутался...
почему нет никакого второго уровня?
Можно подробнее?) Почему нет, почему нельзя, если можно, то как?
-
- Сообщения: 4204
- Зарегистрирован: 25 фев 2018, 22:41
- Откуда: Москва
В обычном варианте L2TP это IP туннель поверх IP, то есть вы IP полезную нагрузку пихаете в IP пакеты (конкретно UDP 1701).
Никакого L2 трафика в нем не ходит.
Но, в принципе, как следует из названия, это протокол именно второго уровня, то есть он на самом деле умеет пихать в IP пакеты L2-фреймы, просто это будет уже совсем другая конфигурация, которая не ваш текущий случай.
Если в PPP-профиле указать bridge куда этот туннель добавлять, то он начнет работать на L2 уровне, со всеми вытекающими.
То есть если вам ни для чего, кроме как для romon'а эти туннели не нужны - можете собрать их на стороне сервера в один бридж, на стороне клиентов сделать бриджи с одним единственным портом - самим l2tp-клиентом, и тогда оно будет работать (должно, по крайней мере).
Но если они для чего-то ещё используются, то это просто лишний оверхед (получится, что вы IP будете пихать в ethernet, и только потом опять в IP, и ещё и оборачивать потом IPSec'ом).
Никакого L2 трафика в нем не ходит.
Но, в принципе, как следует из названия, это протокол именно второго уровня, то есть он на самом деле умеет пихать в IP пакеты L2-фреймы, просто это будет уже совсем другая конфигурация, которая не ваш текущий случай.
Если в PPP-профиле указать bridge куда этот туннель добавлять, то он начнет работать на L2 уровне, со всеми вытекающими.
То есть если вам ни для чего, кроме как для romon'а эти туннели не нужны - можете собрать их на стороне сервера в один бридж, на стороне клиентов сделать бриджи с одним единственным портом - самим l2tp-клиентом, и тогда оно будет работать (должно, по крайней мере).
Но если они для чего-то ещё используются, то это просто лишний оверхед (получится, что вы IP будете пихать в ethernet, и только потом опять в IP, и ещё и оборачивать потом IPSec'ом).
Telegram: @thexvo
-
- Сообщения: 162
- Зарегистрирован: 30 окт 2020, 15:00
Спасибо за развернутый ответ. Понял куда копать.xvo писал(а): ↑30 окт 2020, 16:52 В обычном варианте L2TP это IP туннель поверх IP, то есть вы IP полезную нагрузку пихаете в IP пакеты (конкретно UDP 1701).
Никакого L2 трафика в нем не ходит.
Но, в принципе, как следует из названия, это протокол именно второго уровня, то есть он на самом деле умеет пихать в IP пакеты L2-фреймы, просто это будет уже совсем другая конфигурация, которая не ваш текущий случай.
Если в PPP-профиле указать bridge куда этот туннель добавлять, то он начнет работать на L2 уровне, со всеми вытекающими.
То есть если вам ни для чего, кроме как для romon'а эти туннели не нужны - можете собрать их на стороне сервера в один бридж, на стороне клиентов сделать бриджи с одним единственным портом - самим l2tp-клиентом, и тогда оно будет работать (должно, по крайней мере).
Но если они для чего-то ещё используются, то это просто лишний оверхед (получится, что вы IP будете пихать в ethernet, и только потом опять в IP, и ещё и оборачивать потом IPSec'ом).
Еще не разобрался вот с этими правилами:
add action=accept chain=input comment=dhcp dst-port=67 in-interface-list=\
!Internet protocol=udp
add action=accept chain=input dst-port=68 in-interface-list=!Internet \
protocol=udp
Для чего они нужны? От провайдера адрес получаю по dhcp.
-
- Сообщения: 4204
- Зарегистрирован: 25 фев 2018, 22:41
- Откуда: Москва
DHCP работает на уровне raw socket'ов.ArtVAnt писал(а): ↑30 окт 2020, 17:05 Еще не разобрался вот с этими правилами:
add action=accept chain=input comment=dhcp dst-port=67 in-interface-list=\
!Internet protocol=udp
add action=accept chain=input dst-port=68 in-interface-list=!Internet \
protocol=udp
Для чего они нужны? От провайдера адрес получаю по dhcp.
Так что если вы этот же ip firewall не спускаете на уровень ниже - на bridge, они просто не нужны.
На уровне ip вы его не заблочите, даже если захотите.
Telegram: @thexvo
-
- Сообщения: 162
- Зарегистрирован: 30 окт 2020, 15:00
Т.е. если правило drop закинуть в raw, то сработает? (Я понимаю, что совершенно не за чем это делать, просто для информации).xvo писал(а): ↑30 окт 2020, 17:26DHCP работает на уровне raw socket'ов.ArtVAnt писал(а): ↑30 окт 2020, 17:05 Еще не разобрался вот с этими правилами:
add action=accept chain=input comment=dhcp dst-port=67 in-interface-list=\
!Internet protocol=udp
add action=accept chain=input dst-port=68 in-interface-list=!Internet \
protocol=udp
Для чего они нужны? От провайдера адрес получаю по dhcp.
Так что если вы этот же ip firewall не спускаете на уровень ниже - на bridge, они просто не нужны.
На уровне ip вы его не заблочите, даже если захотите.
П.с. что скажете по остальным правилам в целом? Правила для базовой защиты домашнего микрота с белым внешним ип.
-
- Сообщения: 4204
- Зарегистрирован: 25 фев 2018, 22:41
- Откуда: Москва
Нет, этот raw не тот raw
Как я понимаю, все-таки вся секция IP -> Firewall работает уже именно с обычными IP пакетами.
А дефолтный firewall с этой функцией в общем-то вполне справляется.
Туда остается только добавлять то, что надо разрешить.
А в остальном он достаточно грамотно сделан.
Telegram: @thexvo