Здравствуйте! Ребят, подскажите правило! надо грамотно перенаправить на внутренний сервак В фильтре разрешаем вход на роутер (имеющий статический внешний) с внешнего IP ааа.ввв.ссс.0/19 по порту и протоколу далее нужно натировать на адрес внутри сети 192.168.1.10 просто через нат работает, но как сказал Гуру Илья - это не есть наш метод надо вначале отфильтровать, а потом передать
Не... Вы не поняли. Сначала сработает dst-nat и потом фильтр в цепочке forward. В input этот трафик не попадет.
А как отправить в цепочку фильтр после нат? если мы разрешим chain=dstnat action=dst-nat to-addresses=192.168.1.10 protocol=udp in-interface=ether1 dst-port=5060-5070,10000-20000 то пойдет к нам все кому не лень если укажем chain=dstnat action=dst-nat to-addresses=192.168.1.10 protocol=udp src-address=" IP ВАСИ" in-interface=ether1 dst-port=5060-5070,10000-20000 то пакеты по придут только от IP ВАСИ, но это судя по вашим статьям не надежно если просто поставить chain=forward action=accept protocol=udp src-address=IP ВАСИ in-interface=ether1 ну правило и правило, нат то все всех равно пускает можно поставить внизу форвард правило chain=forward action=drop in-interface=ether1 не хочется грузить проц ошибочными правилами а да самое нижнее правило у меня chain=input action=drop in-interface=ether1, в принципе это дублирует блокировку форвард правил у меня пока не много, проц 1-2% загружен я работаю по принципу запретить всё, а потом разрешаю. читал, что это сейчас не очень практикуется. как лучше?
Нет конечно. Дальше пишем в файрволле правило в цепочке forward. Только с учетом того, что адрес назначения и порт назначения уже те, что задал NAT. Тут грубо /ip firewall filter add action=drop dst-address=192.168.1.10 dst-port=5060-5070,10000-20000 src-address-list=!allowed-sip не пропустит никого кроме тех, кто указан в списке allowed-sip Нет единого стандарта. Даже на одном роутере используются обе политики в зависимости от интерфейса.
а почему грубо? мне кажется не плохо добавили протокол, поднимаем правило наверх и вуаля, пусть сразу все гуляют должно работать.
Илья, если указываем порты, то он просит еще и протокол обязательно, что логично. у меня стоит так 0 chain=input action=drop src-address-list=BOGON in-interface=ether1 1 chain=input action=accept in-interface=!ether1 2 chain=forward action=accept connection-state=established 3 chain=forward action=accept connection-state=related 4 chain=forward action=drop protocol=udp dst-address=192.168.1.10 src-address-list=!allow-sip dst-port=4569,5060-5070,10000-20000 если поднимаю выше то нет или звука или вообще регистрации. ну пока вроде нормально fail2ban не ругается ps сегодня заметил телики LG лезут в гугл на 64.233.165.188:5228 108.177.14.188:5228 и хард помаргивает периодически, достала эта слежка, думаю рубануть.
У вас какой-то странный файрволл. Скажем так Код: /ip firewall filter Разрешили на вход все что сами создали в Output Код: add chain=input connection-state=established,related action=accept Разрешили ICMP Код: add chain=input protocol=icmp action=accept Грохаем все что пришло с WAN. Если что-то надо разрешить ставим перед этим правилом. Все это все. И богоны тоже. Код: add chain=input in-interface=WAN action=drop //Теперь пошел Forward. Если у нас клиенты за NAT, что чтобы трафик снаружи попал в форвард надо или чтобы клиент из-за ната создал подключение, или было правило в dst-nat Тогда грохаем непонятнтые соединения. Код: add chain=forward connection-state=invalid action drop И защищаемся от подмены адреса на входе. Если новый пакте идет с WAN и попал в Forward он ДОЛЖЕН был быть обработан dst-nat. Иначе drop Код: add chain=forward connection-nat-state=!dstnat connection-state=new in-interface=WAN action=drop Остальное дописать по желанию.
Еще раз благодарю Вас, Илья. у меня списочек побольше, что то перекочевало из правил линуха 0 chain=input action=drop src-address-list=BOGON in-interface=ether1 log=no log-prefix="" 1 chain=input action=accept in-interface=!ether1 log=no log-prefix="" 2 chain=forward action=accept connection-state=established log=no log-prefix="" думаю правило 2 и 3 можно объединить, по старинке раздельно делал 3 chain=forward action=accept connection-state=related log=no log-prefix="" 4 chain=forward action=drop protocol=udp dst-address=192.168.1.10 src-address-list=!allow-sip dst-port=4569,5060-5070,10000-20000 log=no log-prefix="" 5 chain=forward action=drop connection-state=invalid log=no log-prefix="" 6 chain=input action=accept tcp-flags=ack protocol=tcp log=no log-prefix="" 7 chain=input action=accept connection-state=established log=no log-prefix="" и 7, 8 можно вместе 8 chain=input action=accept connection-state=related log=no log-prefix="" 9 chain=input action=accept protocol=udp src-port=53 dst-port=1024-65535 log=no log-prefix="" 10 chain=input action=accept protocol=icmp icmp-options=0:0-255 log=no log-prefix="" 11 chain=input action=accept protocol=icmp icmp-options=3:0-255 log=no log-prefix="" 12 chain=input action=accept protocol=icmp icmp-options=4:0-255 log=no log-prefix="" 13 chain=input action=accept protocol=icmp icmp-options=11:0-255 log=no log-prefix="" 14 chain=input action=accept protocol=icmp icmp-options=12:0-255 log=no log-prefix="" 15 chain=input action=drop in-interface=ether1 log=no log-prefix="" Вообще классная вещь Mikrotik, много функций.
Сори за некропостинг, нагуглил эту тему... В последнее время замечаю ночами сильный поток данных, на различные ip оканчивающиеся на 188 (aaa.bbb.ccc.188) порт всегда 5228, источник - ПК Кто-нибудь может прокомментировать - что это?
порт похож на гугловский, но стоит все-таки проверить компьютер на вирусы, определить источник, если что-то подозрительное - убить )
5228 - порт через который работает google play (маркет). Что именно может так теребить с ПК - не понятно...
Про гугл плей не прокомментирую, хотя да, с мобильных устройств, через Wi-Fi, тоже есть поток данных на этот порт и эти IP Но и со стационарных ПК, оставленных на ночь, аналогичная ситуация, более сотни соединений с 3-5 компов. Разве что, если это гугл, может обновление Google Chrome... сложно сказать, это действительно надо мониторить сам ПК, но вирусов быть, по идее не должно, антивирусник есть (согласен, это не всегда показатель чистоты компа)
кстати, может кто подскажет, на сколько корректно правило, которое ловит только TCP syn запросы (не проверяя другие флаги - наличие отсутствие), у меня по данному правилу уже более 4000 адресов в бане
Во вложении скрин попыток подключиться к 5228 не вижу, но возможно они были ранее, либо их просто не было из-за того, что компы погасили, когда правило еще работало, что странно, ПК с данными IP в сети давно нет, а вот соединения висят, при том с теми же 188 адресами, только порт теперь 443 (https) и таймаут в несколько часов из-за чего видимо и висят Соответственно вопрос, а кто определяет таймаут соединения? и как их убивать, это хорошо их сейчас 20 штук, а так будут висеть пара сотен, к примеру к слову, на dhcp у меня таймаут для ip 5 минут
