Все привет! Только прошу не надо тыкать на гугл, день или больше убил в решении данной проблемы. Сетка провайдера 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 ? Или это невозможно? Объясните плиз!
Нарисуй схему подключения с адресами хоть на бумажке карандашом и снимок выложи ... чтоб не гадали как подключено и что где назначено и кроме того что выше попросили выложи 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 проходить должен Если результат такой - значит этот этап пройден
