Изъезженная тема, Но: реально не могу открыть порт

Все привет!
Только прошу не надо тыкать на гугл, день или больше убил в решении данной проблемы.
Сетка провайдера 192.168.0.0/24
У микрота внешний 192.168.100.200
Шлюз 192.168.100.1
Домашняя сетка 192.168.1.0/24
Никак не могу проделать элементарщину в качестве опыта. Пробросить порт с компа в сетке на внешний порт WAN
chain=dstnat action=dst-nat to-addresses=192.168.1.95 to-ports=443 protocol=tcp dst-address=192.168.100.200 in-interface=WAN dst-port=5029
C другого компа отправляю syn пакет на порт WAN 5029 в ответ получаю rst ack
Что еще может быть?

 

проброс извне делается в двух местах в разделе /ip firewall
/ip firewall filter - где принимается решение можно или нельзя и кому можно вообще проходить через барьер фильтра
а далее работает /ip firewall nat в котором то, что пропустил фильтр пробрасывается куда скажут
т.е в комплект к правилу Nat нужно и правило пропускающее пакеты с WAN Tcp dst-port=5029 в разделе Filter

например вот такое
/ip firewall filter add chain=input protocol=tcp dst-port=5029 in-interface=WAN action=accept
в порядке следования правил его разместить так, чтобы у него был шанс сработать (отследи сработку по счетчику пакетов для правила)
это самый простой вариант для теста(проверки работоспособности) но не самый правильный для жизни - для жизни нужно минимум формировать список адресов для которых этот проброс портов разрешен и только их пускать ... иначе отсканируют порт и начнут ломиться нехорошие люди и машины ...

 

Этим правилом просто открывается 5029 порт (адрес назначения) на роутере и для проброса портов он не имеет никакого значения

 

Посмотрите, чтобы в фильтре было правило и стояло выше запрещающих:
chain=forward action=accept connection-state=established,related in-interface-list=WAN log=no log-prefix=""

 

Да Вы правы и ваш вариант действительно правильнее глупо спорить

 

Ваш ответ сподвиг на проверку на практике и по результатам приходится менять собственные представления о движении пакетов в микротике
Пришлось обратиться к первоисточникам и рассмотреть диаграммы движения пакетов в RouterOS
в умолчательной конфигурации роутеров включены правила в разделе Filter на тему Forward

13 ;;; defconf: accept in ipsec policy
chain=forward action=accept log=no log-prefix="" ipsec-policy=in,ipsec

14 ;;; defconf: accept out ipsec policy
chain=forward action=accept log=no log-prefix="" ipsec-policy=out,ipsec

15 ;;; defconf: accept established,related, untracked
chain=forward action=accept connection-state=established,related,untracked log=no log-prefix=""

16 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid log=no log-prefix=""

17 ;;; defconf: drop all from WAN not DSTNATed
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN log=no log-prefix=""

18 chain=input action=drop in-interface-list=WAN log=no log-prefix=""

Правило пронумерованное как 17 указывает на то, что все пакеты пришедшие извне (wan) для которых есть правила NAT пропустившие их через цепочку DST-NAT будет пропускаться фильтром далее
из этого следует что отдельных фильтров в разделе Filter по портам и адресам вроде как и не нужно т.к. вся фильтрация возлагается на правила в цепочке NAT (Dst-Nat) и если они сработали то пакет пропускается фильтром а если нет то отбрасывается.
И все цепочки Filter работают уже ПОСЛЕ отработки цепочки NAT где принимается решение как модифицировать пакет и куда его отправить или в роутер или в сеть потребителю. (в моем предыдущем представлении Filter работал ДО NAT - оказалось что я ошибался - печально что ошибался но лучше корректировать свои представления в соответствии с действительностью чем бездумно утверждать что либо)

Если я не прав - поправьте меня

 

Ох сколько я про это правило тут уже написал

 

подскажи пожалуйста где именно чтоб не перечитывать все сообщения на форуме от начала времен

 

упс. Про другое писал. Но я бы и это отключил временно. И проверил бы.

add action=drop chain=input comment="defconf: drop all not coming from LAN" disabled=yes in-interface-list=!LAN

 

в той теме на которую была ссылка там IPSec а он очень специфически обрабатывается и 2 раза проходит через цепочку Input первый раз как пакет зашифрованный в направлении роутера с Lan интерфейса а второй раз после расшифровки и какой "in-interface" будет после расшифровки у пакета я сказать не берусь - возможно какой-то локальный а он не входит в список LAN и соответственно на втором круге этим правилом режется

Да не все умолчательные правила одинаково полезны и безальтернативны
я умолчательное правило привел т.к. у меня было неверное представление о порядке следования действий что раньше что позже (nat-filter или filter-nat)
и это изменение существенно меняет мою картину
не хватает базовых упорядоченных знаний- все приходится выяснять самостоятельно ... отсюда и прорехи ... нужно учится и экспериментировать чтоб реже ошибаться

 

Всем привет.
Развернутый ответ получается, это хорошо. У всех накопилось и наболело........ Сразу видать "крутые перцы" !
Опыт решил проделать чтоб получше понять как работает Firewall
У меня два ноута по wifi перед собой для экспериментов. Якобы открыл порт 5029, отправляю SYN пакет на микрот, ответ получаю, а счетчик молчит в правиле. Я не мог понять как уходит пакет, вернее уходит через Output а вот куда он приходит, был вопрос.
Конечно я "лепил" правила да повыше

и это еще повыше

И наконец-то родилось, создал правило в Mangle, и получил свой ответ.

Все от того что нехнуя не читаем как работает, что откуда и куда. Конечно неумелому и без опыта так сразу не понять, даже читая надо методом опыта "догонять" как и что работает.
А вот свой пакет я не смог отправить на WAN интерфейс, хотя отправил пакет на внешний (серый) ip. Пакет пришел и ушел через LAN. Помогите разобраться с этой ситуацией. У провайдера сетка 192.168.0.0/24, а меня таже самая подсеть 192.168.1.0/24. Из своей сети вижу все открытые хосты. И для меня пока совсем не понятно почему когда отправляю пакет на свой внешний ip, он приходит не на WAN а на LAN ? Или это невозможно? Объясните плиз!

 

Подсети как раз таки у Вас разные
Выложете ip address print и ip route print

 

Нарисуй схему подключения с адресами хоть на бумажке карандашом и снимок выложи ... чтоб не гадали как подключено и что где назначено
и кроме того что выше попросили выложи Bridge и Wireless разделы конфигурации

 

Всем привет.

Все верно, разные. Хотел сказать что моя и другие подсети, лежат в 192.168.0.0/24
По поводу конфигурациии.

 

TCP пакет между двумя ноутами в рамках одной сети (если они в одной сети /24) пройдет без маршрутизации через WiFi включенный в бридж LAN и вернется обратно через WiFi
При этом у пакета входящим интерфейсом в любом случае будет порт из списка интерфейсов LAN - все соединения обеспечит один интерфейс и уровень 2
Если Ты отправляешь пакет за пределы сети 192.168.1.0/24 то от пакет по маршрутизации скорее всего у тебя masquarade настроен (я предполагаю) должен отправится от имени интерфейса 192.168.25.100 в направлении маршрута 0.0.0.0/0 т.е адресу 192.168.25.1 т.е провайдеру и как он его обработает микротик не знает но если придет ответ то ConnectionTracker ответный пакет обработает как ответ на запрос установленный ранее изнутри сети и пропустит его как легальный ответ (правило с разрешением для established)

Если запрос со стороны провайдера придет на твой адрес 192.168.25.100:5029
Нужно правило для Wan интерфейса разрешающее маршрутизацию этого пакета внутрь сети на некий хост (для примера 192.168.1.100)
т.к. правило не для роутера а для другого хоста оно должно быть в цепочке Forward
/ip firewall filter add chain=forward protocol=tcp dst-port=5029 in-interface=WAN action=accept

Альтернативой может служить в этом случае правило из умолчательной конфигурации роутера (при обязательном условии наличия правила в разделе nat - DstNat которое этот пакет обработает ДО фильтра и в фильтр пакет попадет уже после Dst-Nat'a )
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN log=no log-prefix=""

и к нему в комплекте правило для DST-NAT которое пробросит на конкретный порт
/ip firewall nat add protocol=tcp dst-port=5029 in-interface=wan action=dst-nat to-addresses=192.168.1.100
обрати внимание на то, что dst-nat видит входящий интерфейс и исходный (source) адрес пакета а фильтр видит souce адрес пакета замененный на внутренний интерфейс микротика для целевой сети т.к исходящим адресом в фильтре у пакета будет уже 192.168.1.1

и вторая ремарка - убедись что твой интерфейс WAN точно включен в список интерфейсов с таким-же названием да и что Бридж LAN тоже в нужном списке интерфейсов явно числится
иначе можно долго правила разглядывать ... (мало ли чего)

Из конфигурации я сделал предположение что порт WiFi включен в бридж Lan - но утверждать этого я не могу - стоит проверить в bridge-Ports

 

Да верно, wifi включен в bridge LAN. Спасибо. Ща попробую. Очень уж интересно. Чтобы тупых вопросов меньше задавать о сложных вещах, лучше сначала разобраться на самых простейших вещах как ходят пакеты.

 

Я не знаю как построил Экспериментальную часть Вы я сделал бы в этой ситуации следующее
1. Отключил антивирусы на обоих компах сервере (.1.100) и клиенте
2. Отключил бы (на время тестов естественно) фаерволы на обоих компьютерах
3. Убрал из цепочки тестов WiFi и включил оба ноутбука проводами (чтоб исключить неопределенности)
Далее серия экспериментов последовательно приближаясь к целевой конфигурации
гасим все правила в цепочке Filter( все все ) гасим все правила в цепочке nat
1. оба ноутбука подключаем кабелями к порту 2 и 3 микротика (оба в один сегмент LAN)(клиент 192.168.1.101/24 сервер 192.168.1.100) - одна сеть, нет маршрутизации - шлем пакеты с клиента на сервер
Если ОК проходим далее
2. Включаем nat правила для masquarad'инга и dst-nat tcp 5029 (убеждаемся что в фильтре все вЫключено)
включаем клиента в роли инет провайдера в первый порт (Wan) настраиваем клиента как 192.168.25.1/24 - сервер остается 192.168.1.100 (задача - имитация пакета пришедшего извне или клиент извне )
Шлем Пакеты проверяем работу - если ОК задумываемся о защите и фильтрации
3. Включаем правила в разделе Filter - доводим до работоспособного состояния
если ОК то далее
4. Если важно - переключаем сервер на WiFi (если это действительно важно- что вряд-ли) и проводим тесты работоспособности

 

Ваш совет явно пошел на пользу, потому как некоторые вещи такие как фаерволы отключить, забываются.
Нет результата это тоже результат...........
1 пункт Проделал, все ОК
На втором уже затык, не хватает мозгов наверное.
На одном ноуте прописал ip 192.168.25.1/24 gw-none И "воткнул" в WAN порт
Далее добавил

И нексуя не хочет работать моя схема.

 

Попробуем разобраться
в разделе /ip routes меняем правило для пакетов идущих в "МИР" = За пределы сетей роутера

Первое правило 0.0.0.0/0 меняем шлюз с WAN1 на явно указанный IP адрес 192.168.25.1 (в роли которого будет выступать второй компьютер на время тестов и все куда можно будет отправлять пакеты в рамках теста это только ОН (компьютер) большего ждать не стоит

правило в /ip firewall Nat оставляем неизменным оно сильно похоже на правильное для этого теста

Не всякий интерфейс может автоматически отдать реальный IP для указания куда слать пакеты в таблице маршрутизации поэтому на время лучше указать конкретный адрес шлюза в явном виде и не применять названия интерфейсов в Routes в качестве шлюза

На этой стадии теста должен начать ходить пинг изнутри сети на 192.168.25.1 не более того

 

Добившись первого результата усугубляем

Далее добавляем в ip firewall nat dst

/ip firewall nat add protocol=tcp dst-port=5029 in-interface=wan action=dst-nat to-addresses=192.168.1.100

с этого момента сервер 192.168.1.100 сможет пинговать 192.168.25.1

и если все выполнено правильно
то TCP пакеты извне отправленные на 192.168.25.2:5029 должны доходить до сервера 192.168.1.100
но при этом PING 192.168.1.100 с клиента проходить НЕ должен - это нормально
ping 192.168.25.2 проходить должен

Если результат такой - значит этот этап пройден