Странности в файрволе Микротика

[alibek]

Есть Микротик RB450G.

Странно себя ведет dst-nat.

/ip firewall nat
...
add action=dst-nat chain=dstnat comment="" dst-port=65500 \
    in-interface=pppoe-rt protocol=tcp src-address-list=net-staff \
    to-addresses=192.168.1.1 to-ports=80
add action=dst-nat chain=dstnat comment="" dst-port=65501 \
    in-interface=pppoe-rt protocol=tcp src-address-list=net-staff \
    to-addresses=192.168.1.20 to-ports=80
...

Устройство 192.168.1.20 подключено в порт eth1, на этом интерфейсе вручную задан IP-адрес 192.168.1.250/24.

Устройство 192.168.1.1 подключено в порт eth4, на этом интерфейсе включен dhcp-клиент и он получает IP-адрес 192.168.1.249/24.

Эти IP-адреса не используются одновременно — либо порт eth4 отключен (соответственно dhcp-клиент отключен и не получает IP-адрес), либо IP-адрес на интерфейсе eth1 отключается.

Соответственно конфликтов маршрутизации никогда не бывает, с самого Микротика 192.168.1.1 доступен без проблем, работает веб-интерфейс (если подключиться через telnet 192.168.1.1 80).

 

Но "снаружи" я не могу зайти на устройство 192.168.1.1 (пробую зайти на <external-ip>:65500). Счетчики на правилах ip firewall nat увеличиваются, однако подключение не происходит.

Но если попытаться зайти на <external-ip>:65501 (отключив порт eth4), то все работает.

Правила firewall filter не привожу, их довольно много, но они мешать не могут, в них не прописаны конкретные адреса, только подсети, отдельно интерфейсы eth1 или eth4 в правилах не присутствуют.

 

Что тут может быть причиной?

 

Пробовал в правилах NAT порт 65500 сменить на 65501 (на тот случай, если 65500 где-то используется или заблокирован).

Также пробовал в начало списка добавить правило, разрешающее все на input и forward.

Без изменений, снаружи подключиться по прежнему нельзя.

[VolanD666]

Посмотрите что в снифере

[taf_321]

Смотрите через какой порт есть маршрут до 192.168.1.0/24. Вполне вероятна ситуация, что после ваших манипуляций с портами остается висеть маршрут в статусе Unreachable
 

[alibek]

Нет, маршрут активен и непосредственно с микротика 192.168.1.0 доступен.

Я успешно подключаюсь к его веб-интерфейсу с микротика (через телнет) на порт 80.

Но снаружи порт 65500 не отвечает.

 

Сниффером сейчас посмотреть не могу, клиент отключил устройство от порта 4 (это роутер с 4G-модемом), железка находится далеко.

Но если счетчик на правиле nat увеличивался, значит до микротика внешние запросы на порт 65500 точно доходят.

[VolanD666]

В 12.11.2021 в 11:38, alibek сказал:

Но если счетчик на правиле nat увеличивался, значит до микротика внешние запросы на порт 65500 точно доходят.

Просто с сниффером вы можете в подробностях посмотреть что происход что и на какие адрес-порт приходит.

 

[naves]

А устройство имеет маршрут по умолчанию на ваш микротик? Может оно ответный пакет отправляет в другое место?

вообще логично, что девайс, который выдает адрес вашему микротику не имеет маршрута через ваш же микротик.

Там же 4г роутер, ну он и шлет вам ответ в свой интернет, можете у себя запустить дамп пакетов, скорее всего вы увидите ответ с нового адреса, который вами же отбрасывается, тк вы стучались по первому адресу.

добавьте в postrouting правило на src-nat action или вообще маскарад в сторону вашего проблемного устройства на пакеты dst ip 192.168.1.1. Идея в том, чтобы устройство думало, что это запрос из внутренней сети, который имеет внутренний адрес в src ip пакетов.

Собственно это и не странности, любой NAT так работает.

Edited November 13, 2021 by naves

[alibek]

Нужно будет проверить.

Пакеты на eth4 натятся (маскарадинг).

А вот как именно и какой в них подставляется src-ip я не смотрел. Может быть не адрес интерфейса (например 192.168.1.94), а что-нибудь постороннее.