Несколько вопросов (ipsec, мак адреса, neignbors)

Обсуждение ПО и его настройки
ArtVAnt
Сообщения: 162
Зарегистрирован: 30 окт 2020, 15:00

Микрот 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

нужны ли они?
Полный фаервол прилагаю:
 полный код

Код: Выделить всё

/ip firewall raw
add action=drop chain=prerouting comment=\
    "Protected - WinBox, ssh, telnet. Drop in RAW" in-interface-list=Internet \
    src-address-list=BlackListProtected

/ip firewall filter
add action=fasttrack-connection chain=forward connection-mark=!ipsec \
    connection-state=established,related
add action=drop chain=forward comment="Drop invalid Forward" \
    connection-state=invalid
add action=drop chain=forward comment="drop all packets for lan, no nat" \
    connection-nat-state=!dstnat connection-state=new in-interface-list=\
    Internet
add action=accept chain=forward comment=Ipsec ipsec-policy=in,ipsec
add action=accept chain=forward ipsec-policy=out,ipsec
add action=accept chain=forward connection-state=established,related
add action=drop chain=input dst-port=53 in-interface-list=Internet log=yes \
    log-prefix=dnsdrop protocol=udp
add action=drop chain=input comment="Drop invalid input" \
    connection-nat-state="" connection-state=invalid connection-type=""
add action=accept chain=input dst-port=5678 protocol=udp
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
add action=accept chain=input comment="allow sstp" dst-port=443 protocol=tcp
add action=accept chain=input comment="Winbox MAC" dst-port=20561 \
    in-interface-list=!Internet protocol=udp
add action=accept chain=input comment=IPSec protocol=ipsec-esp
add action=jump chain=input comment="Protected - WinBox, ssh, telnet chain" \
    connection-state=new dst-port=8291,22,23 in-interface-list=Internet \
    jump-target=Protected log-prefix=proverka protocol=tcp
add action=accept chain=input comment="Accept Input established related" \
    connection-state=established,related protocol=!ipsec-esp
add action=add-src-to-address-list address-list="port scanners" \
    address-list-timeout=2d chain=input comment=\
    "Port scanners to list  ALL/ALL scan" in-interface-list=Internet \
    protocol=tcp tcp-flags=fin,syn,rst,psh,ack,urg
add action=add-src-to-address-list address-list=BlackListProtected \
    address-list-timeout=2d chain=input in-interface-list=Internet protocol=\
    tcp psd=21,3s,3,1
add action=add-src-to-address-list address-list=BlackListProtected \
    address-list-timeout=2d chain=Protected comment=\
    "Protected - WinBox, ssh, telnet. Drop in RAW" connection-state=new \
    src-address-list="ListProtected Stage 2"
add action=add-src-to-address-list address-list="ListProtected Stage 2" \
    address-list-timeout=2m chain=Protected connection-state=new \
    src-address-list="ListProtected Stage 1"
add action=add-src-to-address-list address-list="ListProtected Stage 1" \
    address-list-timeout=1m chain=Protected connection-state=new
add action=accept chain=Protected dst-port=8291,22,23 in-interface-list=\
    Internet protocol=tcp
add action=accept chain=input comment="allow l2tp, IKE, IPsecNAT" dst-port=\
    1701,500,4500 in-interface-list=Internet protocol=udp
add action=accept chain=input comment="Allow IGMP" in-interface=bridge-1 \
    protocol=igmp
add action=accept chain=input comment="accept ICMP" protocol=icmp
add action=drop chain=input comment="Drop All Other" in-interface-list=\
    Internet log-prefix="drop other"


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

1) у вас туннель 3 уровня, откуда там мак-адреса?

2) по первому правилу трафик будет ходить только между белыми адресами.
если на одном из устройств адрес серый, то будет udp 4500 использоваться.
остальные два правила в цепочке forward - а туннель вы устанавливаете между самими роутерами, так что там вы ничего и не увидите.


Telegram: @thexvo
ArtVAnt
Сообщения: 162
Зарегистрирован: 30 окт 2020, 15:00

Спасибо за ответ, доходчиво и по делу:
xvo писал(а): 30 окт 2020, 15:39 1) у вас туннель 3 уровня, откуда там мак-адреса?
Но маки же появляются еще на втором уровне... и на третьем они есть. Почему их там не должно быть?

xvo писал(а): 30 окт 2020, 15:39 2) по первому правилу трафик будет ходить только между белыми адресами.
если на одном из устройств адрес серый, то будет udp 4500 использоваться.
остальные два правила в цепочке forward - а туннель вы устанавливаете между самими роутерами, так что там вы ничего и не увидите.
про вторые два правила действительно, поменял на input и outpoot, по логам видны хождения через порт 1701. А .т.к. у меня есть правило с открытым этим портом, то эти два правила бесполезны. Правильно?


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

ArtVAnt писал(а): 30 окт 2020, 16:17 Но маки же появляются еще на втором уровне... и на третьем они есть. Почему их там не должно быть?
У вас в этих туннелях нет никакого второго уровня.
Поэтому и маков нет.
ArtVAnt писал(а): 30 окт 2020, 16:17 про вторые два правила действительно, поменял на input и outpoot, по логам видны хождения через порт 1701. А .т.к. у меня есть правило с открытым этим портом, то эти два правила бесполезны. Правильно?
Не совсем так.
В таком виде, тем более в output, они не нужны.
Но например добавить условие in,ipsec прямо в правило на 1701й порт очень даже полезно - обезопасите себя от случайного подключения без ipsec, и от того, что к вам на 1701ы порт будут ломиться все, кому не лень.


Telegram: @thexvo
ArtVAnt
Сообщения: 162
Зарегистрирован: 30 окт 2020, 15:00

xvo писал(а): 30 окт 2020, 16:28
ArtVAnt писал(а): 30 окт 2020, 16:17 Но маки же появляются еще на втором уровне... и на третьем они есть. Почему их там не должно быть?
У вас в этих туннелях нет никакого второго уровня.
Поэтому и маков нет.
хм.. я еще больше запутался...
почему нет никакого второго уровня?

Можно подробнее?) Почему нет, почему нельзя, если можно, то как?


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

В обычном варианте L2TP это IP туннель поверх IP, то есть вы IP полезную нагрузку пихаете в IP пакеты (конкретно UDP 1701).
Никакого L2 трафика в нем не ходит.

Но, в принципе, как следует из названия, это протокол именно второго уровня, то есть он на самом деле умеет пихать в IP пакеты L2-фреймы, просто это будет уже совсем другая конфигурация, которая не ваш текущий случай.

Если в PPP-профиле указать bridge куда этот туннель добавлять, то он начнет работать на L2 уровне, со всеми вытекающими.

То есть если вам ни для чего, кроме как для romon'а эти туннели не нужны - можете собрать их на стороне сервера в один бридж, на стороне клиентов сделать бриджи с одним единственным портом - самим l2tp-клиентом, и тогда оно будет работать (должно, по крайней мере).
Но если они для чего-то ещё используются, то это просто лишний оверхед (получится, что вы IP будете пихать в ethernet, и только потом опять в IP, и ещё и оборачивать потом IPSec'ом).


Telegram: @thexvo
ArtVAnt
Сообщения: 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.


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

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.
DHCP работает на уровне raw socket'ов.
Так что если вы этот же ip firewall не спускаете на уровень ниже - на bridge, они просто не нужны.
На уровне ip вы его не заблочите, даже если захотите.


Telegram: @thexvo
ArtVAnt
Сообщения: 162
Зарегистрирован: 30 окт 2020, 15:00

xvo писал(а): 30 окт 2020, 17:26
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.
DHCP работает на уровне raw socket'ов.
Так что если вы этот же ip firewall не спускаете на уровень ниже - на bridge, они просто не нужны.
На уровне ip вы его не заблочите, даже если захотите.
Т.е. если правило drop закинуть в raw, то сработает? (Я понимаю, что совершенно не за чем это делать, просто для информации).
П.с. что скажете по остальным правилам в целом? Правила для базовой защиты домашнего микрота с белым внешним ип.


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

ArtVAnt писал(а): 30 окт 2020, 21:42 Т.е. если правило drop закинуть в raw, то сработает? (Я понимаю, что совершенно не за чем это делать, просто для информации).
Нет, этот raw не тот raw :-)
Как я понимаю, все-таки вся секция IP -> Firewall работает уже именно с обычными IP пакетами.
ArtVAnt писал(а): 30 окт 2020, 21:42 П.с. что скажете по остальным правилам в целом? Правила для базовой защиты домашнего микрота с белым внешним ип.
А дефолтный firewall с этой функцией в общем-то вполне справляется.
Туда остается только добавлять то, что надо разрешить.
А в остальном он достаточно грамотно сделан.


Telegram: @thexvo
Ответить