Клиенты ломятся в интернет через правило проброса портов dstnat

[Rednaxel]

Здравствуйте!
Подскажите пожалуйста, что может быть не так у меня с пробросом портов?

• Model: RB760iGS Firmware 7.9
• Провайдер: ByFly, PPPoE интерфейс в Mikrotik
• Осн.правило NAT стоит на первом месте: Chain srcnat; Out interface ByFly; Action masquerade
• Проброс порта HTTPs: Chain dstnat; Protocol 6 (tcp); Вые port 443; Action netmap; Log Yes; Log prefix HTTPs; To Address 192.168.0.20; To Prots 443

Как только включаю правило проброса, в логе начинается форменная истерика, например:

HTTPs dstnat: in:bridge out:(unknown 0), connection-state:new src-mac d8:5e:**:**:**:**, proto TCP (SYN), 192.168.0.127:53551->13.94.251.244:443, len 52
HTTPs dstnat: in:pppoe-out1 out:(unknown 0), proto TCP (SYN), 82.146.37.75:38208->213.184.244.154:443, len 60

Т.е., если я правильно расшифровал первую строку примера, клиент LAN через это правило с порта отчего-то 53551 пытается подключиться к какому-то нужному ему адресу в интернете.
По второй строке вообще не догоняю при чем здесь эти внешние адреса
Соответственно интернет у всех начинает дико тупить и практически не работает. Помогите пожалуйста разобраться!

[Chupaka]

Приветствую. У вас правило "проброс порта" ловит все пакеты на 443-й порт, даже идущие на адреса внешних сервисов. Добавьте в правило параметр dst-address-type=local (в графическом интерфейсе на вкладке Extra), чтобы правило действовало только на пакеты, летящие только на адреса самого роутера.

[Rednaxel]

удалить сообщение

[Rednaxel]

... Добавьте в правило параметр dst-address-type=local (в графическом интерфейсе на вкладке Extra) ..

Да, это работает. Сердечно благодарю!
Но хотелось бы понять и причины таких траблов. Специально сравнил настройки с другими Mikrotik - там никаких Extra, все аналогично настроено и проблем нет. Это в версии 7.Х такие нововведения что-ли? Отчего клиент не использует masquerad, который первый по списку и ломится через правило netmap?

[Chupaka]

Нет, так всегда работало и будет работать Как иначе вы сможете, например, перенаправить все соединения на squid proxy для кэширования/блокирования?

Цепочки srcnat и dstnat независимые, поэтому не надо мешать в кучу правила из них. Любое соединение может попасть под действие как src-nat, так и dst, поэтому masquerade никак не отменяет проброс портов. Более того, dst-nat срабатывает в самом начале приключений пакета в роутере, а src-nat - ближе к концу (см. https://help.mikrotik.com/docs/display/ ... n+RouterOS)

[Rednaxel]

Другими словами, параметр dst-address-type=local нужно всегда добавлять во все правила проброса портов, правильно?
Просто меня это реально удивило, т.к. настроил уже не один десяток Mikrotik и ни разу с таким не сталкивался и ни в каких инструкциях не встречал подобных рекомендаций.

[Chupaka]

Альтернативный вариант - in-interface=WAN. Так оно будет ловить новые входящие подключения из Интернета (не обращая внимание на исходящие из локалки), а они крайне редко предназначаются не самому роутеру, а, например, какой-нибудь подсети за ним

[Rednaxel]

Здравствуйте!
Не могли бы вы прояснить еще один, связанный с сабжем момент:
Отчего правило проброса порта срабатывает на подключение с любого порта? Вот например такая строка в логе (префикс RDP):

dstnat: in:#1_ByFly out:(unknown 0), connection-state:new proto TCP (SYN), 136.243.50.24:50137->8Х.ХХ.ХХ.ХХХ:3389, len 52

Я так понимаю, что это уже не проблема с NAT, которую мы тут решили, а банальная атака на RDP, но непонятно что означает вот это TCP (SYN) и главное, отчего вообще правило срабатывает с этого немецкого IP приходит с совершенно левого порта 50137 на порт 3389 ? Проброс настроен симметрично 3389-->3389 .
По итогам разборок настроил 3х-уровневый Fail2ban, но походу правила "add src to address list" в списки срабатывает не всегда, вероятно только когда идёт симметричное подключение...
Очевидно я не до конца понимаю как это все работает ^-(

[Rednaxel]

но походу правила "add src to address list" в списки срабатывает не всегда, вероятно только когда идёт симметричное подключение...

Сейчас проверил -- предположение ложное. Вот пример срабатывания первой стадии Fail2ban
Fail2Ban_S1 input: in:#1_ByFly out:(unknown 0), connection-state:new proto TCP (SYN), 38.132.109.171:41376-><Мой IP>:1723, len 44
Ну тогда вообще не пойму отчего срабатывает едва ли на одном из пяти, а то и одном из десяти новых подключений? Не успевает что-ли?

[Rednaxel]

И да, Action "add src to address lisc" выглядит так:

add src to address lisc.png

Может вообще то правильнее будет новую ветку завести для такого вопроса? А то явно не туда уже несет

[Chupaka]

Да, лучше отдельную ветку.

136.243.50.24:50137->8Х.ХХ.ХХ.ХХХ:3389, len 52

Вы почитайте, как TCP работает. Он для исходящих подключений выбирает какой-нибудь порт из заданного в настройках диапазона (50137, но, строго говоря, если клиент за NAT'ом, то и его NAT может при некоторых настройках/ситуациях порт поменять) - и от него уже подключается к целевому порту на целевом адресе (8Х.ХХ.ХХ.ХХХ:3389). Оно всегда так работало и будет работать. "Проброс настроен симметрично 3389-->3389" - это, я так понимаю, значит, что подключаясь на внешний адрес роутера на порт 3389, вы попадаете на внутренний адрес сервера на порт 3389. К порту источника (в примере 50137) это никакого отношения не имеет.