LostSoul Опубликовано 15 октября, 2019 · Жалоба Добрый день. Отлаживал нечто другое, включил лог отвергнутых правилами антиспуфа пакетов со стороны клиентов. Цитата 23:08:24 firewall,info forward: in:vlan-clients out:vlan-uplink, src-mac e4:8d:8c:xx:xx:xx, proto TCP (ACK,FIN,PSH), 192.168.0.246:46165->193.0.170.25:443, len 791 23:08:28 firewall,info forward: in:vlan-clients out:vlan-uplink, src-mac e4:8d:8c:xx:xx:xx, proto TCP (ACK,FIN,PSH), 192.168.0.246:46164->193.0.170.25:443, len 989 23:08:28 firewall,info forward: in:vlan-clients out:vlan-uplink, src-mac e4:8d:8c:xx:xx:xx, proto TCP (ACK,FIN,PSH), 192.168.0.246:46166->193.0.170.25:443, len 984 23:08:28 firewall,info forward: in:vlan-clients out:vlan-uplink, src-mac e4:8d:8c:xx:xx:xx, proto TCP (ACK,FIN,PSH), 192.168.0.246:46163->193.0.170.25:443, len 989 C стороны множества абонентских mikrotik прорываются наружу IP-пакеты с src ip из их внутренней локалки. В основном это фрагменты tcp соединений. То есть то что, согласно правилу MASQUERADE должно было быть спрятано за белый IP на их роутере , но оно прорывается без переписывания заголовков. правила NAT на этих роутерах написаны так /ip firewall nat add action=masquerade chain=srcnat out-interface=sfp1-isp src-address=192.168.0.0/24 Меня даже не то расстраивает что они "прорвались" а то , что раз эти пакеты прорвались в таком виде, то значит работа соответствующих соединений видимо была нарушена и интернет у клиентов работает плохо. Есть идеи? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 15 октября, 2019 · Жалоба Дык, ублюдки забывают исключить серые адреса из правила трансляции и при маршрутизации между сетями внутри микротик это все радостно маскарадит и срёт в окружающий мир. Аналогично, при флапе линка маскарадинг может некоторое время высылать такие недоделки. Делать надо action=src-nat, address-list на все серые сети , и в правиле nat что-нибудь вроде dst-address-list=!созданный list Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LostSoul Опубликовано 15 октября, 2019 · Жалоба 15 минут назад, jffulcrum сказал: Дык, ублюдки забывают исключить серые адреса из правила трансляции и при маршрутизации между сетями внутри микротик это все радостно маскарадит и срёт в окружающий мир. Аналогично, при флапе линка маскарадинг может некоторое время высылать такие недоделки. Делать надо action=src-nat, address-list на все серые сети , и в правиле nat что-нибудь вроде dst-address-list=!созданный list никаких сетей внутри у этих клиентов нету. одна единственная клиентская подсеть и один белый IP на WAN интерфейсе. Никаких флапов нету тоже , линк с последнего обновления routers больше месяца наверное. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 16 октября, 2019 · Жалоба Может с tcp в маскарад попадают только полноценные сессии? Может для этих пакетов роутер не видел SYN, SYN+ACK ? Или это уже завершенные сессии, а клиент делает ретрансмит... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LostSoul Опубликовано 16 октября, 2019 · Жалоба 7 часов назад, ShyLion сказал: Или это уже завершенные сессии, а клиент делает ретрансмит... в линукс ядре это все предусмотрено . после закрытия сессии они еще живут определенный таймаут в conntrack. но даже если так - должна начаться новая сессия и тоже NAT-иться. а не вот такое.... это явная бага кмк Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...