• Делал раньше тему про MultiWAN:
    https://forum.netgate.com/topic/157261/multiwan-не-срабатывают-правила-outbound-решено/5
    ... и вот нарисовалось продолжение.

    В принципе подозрения сразу были что тема шляпная и попахивает конкретной недоработкой, но всё же может кто-то опытный объяснит философию.

    В локальной сети стоят сервера, за PF бушует интернет. Несколько сетевых у PF смотрят в сторону локалок, а несколько в сторону провайдеров. От каждого провайдера имеем отдельный диапазон внешних белых адресов IP, которые используются для настройки доступа к различным сервисам на локальных серверах. Короче - совершенно обычная нормальная ситуация без каких-либо там прибамбасов и извращений, всё стандартно и понятно.

    ЗАДАЧА (очень простая):
    Во внешней зоне DNS для адреса странички вида www.adres.com сделать несколько записей А с разными IP. Конкретно пусть будет два адреса IP из диапазона разных провайдеров, для повышения отказоустойчивости и распределения нагрузки.

    Тоесть клиенты будут заходить на www.adres.com по двум IP. Не одновременно, а на выбор через какой-то один из двух доступных. Нужный выбирается или случайно или какой браузеру больше понравится (по быстрому тесту), ну или если нет ответа то через какое-то время обычно браузеры начинают пробовать стучать на второй. Технология ранее неоднократно опробована и вопросов не возникало на предыдущем старом роутере. А вот на новом с PF на борту вопросы возникают - нифига не работает. Клиент может быть перенаправлен в соответствии с настройками NAT на нужный хост, но хост не может по какой-то причине обратно с этим клиентом по этому каналу обмениваться пакетами, только если это будет default gateway. Я не могу понять почему так происходит и по какой логике. Но ведь должен же возникнуть канал, связывающий клиента с сервером! Даже через NAT-ы с динамическими IP из дома можно пользоваться ресурсами - на ftp например попадать, или через облако смотреть домашнюю IP камеру. Как же так!

    ВОПРОС:
    Есть ли возможность у PF правильно обслуживать запросы через встроенный NAT из-вне на разных шлюзах с нескольких IP? Откуда пришло - туда слать. С каждым клиентом на отдельном канале. Пакеты там подписывать или что...

    Это совершенно точно какой-то баг или фича самого PF. С точки зрения сервера www он видит только один адрес шлюза в лице роутера PF, а от него через NAT приходят запросы клиентов с интерфейса PF, смотрящего в локалку. Какого хрена он обратно всё заворачивает на "избранный" внешний интерфейс, так, словно сервер сам пытается выйти в интернет а не по запросу отвечает? В чём тут проблема, может надо какой режим ему включить? Пропадает смысл в таком роутере, который не способен организовать комуникацию. В прошлый раз оказалось что надо прямо на интерфейсе жёстко указывать какому IP на какой шлюз, но я не могу таким образом один внутренний IP настроить сразу на два отдельных внешних шлюза. Зачем тогда вообще правила сделали входящие/исходящие если это не работает для нескольких карт?! Бред полнейший. Объясните.


  • @luha
    Здр
    Несколько раз перечитал написанное ,и если я все верно понял ,то в некоторых случаях ответный пакет от сервера идет на Lan интерфейс PF , а PF , в свою очередь , пакет "пихает" не в интерфейс , откуда пришел пакет , а в шлюз по умолчанию . Верно ?
    Такая ситуация возможна , если интерфейс PF - виртуальный , а не физический . Много раз писалось, что у PF "поломана" функция "reply-to" для виртуальных интерфейсов, и поэтому все ответные пакеты от неизвестных источников PF отправляет в шлюз по умолчанию .

    Те если не "перемудрили" с настройками правил и интерфейс внешний PF - физический , то такой ситуации быть не должно.
    По таблице состояний PF отправит пакет на тот интерфейс , откуда пришел первый пакет


  • @konstanti Спасибо. Думаю всё ты правильно понял по теме вопроса. Что касается решения то теперь мне надо бы как-то проверить данный факт. Интерфейсы это физические отдельные сетевые адаптеры intel - возможно что они в PF настроены как виртуальные?

    Кстати обратно пакет не "иногда идёт не туда", а всегда идёт только на шлюз по умолчанию. Если он с этого шлюза то клиент получает страничку. Если со второго провайдера, то клиент не получает страничку.


  • @luha
    Если интерфейсы физические , то Вы могли "перемудрить" , например , настраивая floating rules для входящего трафика.
    функция 'reply-to' для физических интерфейсов реализована корректно .

    Найдите файл /tmp/rules.debug . В этом файле найдите правило проброса, которое не работает . Оно должно выглядеть , к примеру , так

    pass  in  quick  on $WAN reply-to ( igb0 XX.XXX.XXX.X ) inet proto tcp  from any to 192.168.99.80 port 443 tracker 1546256424 flags S/SA keep state
    
    
    

    и сравните


  • @konstanti Хорошо, поищу.

    Ну, как, я старался не мудрить. Значит так. Что я вижу. В меню "Interfaces" перечислены отдельно имеющиеся в наличие физические адаптеры, в настройках указано включен или выключен, его название, тип настроек и всё такое... также адрес IP4, данный провайдером для настройки (этот адрес я могу использовать) и ещё один адрес IP4 в составе опции "IPv4 Upstream gateway", где я выбираю опять же настройки шлюза, что бы это не значило (If this interface is an Internet connection, select an existing Gateway from the list or add a new one using the "Add" button.
    On local area network interfaces the upstream gateway should be "none". Gateways can be managed by clicking here.) - этот адрес я использовать не могу, он на самом деле уже по стороне провайдера находится.

    В меню "Interfaces / Interface Assignments" приписано какой "Interface" смотрит на какой физический "Network port".

    В остальных подменю (Interface Groups, Wireless, VLANs, QinQs, PPPs, GREs, GIFs, Bridges, LAGGs) ничего не настраивалось - пусто.

    "Firewall / Aliases / IP (и прочие подменю)" - пусто

    А вот тот самый "диапазон адресов IP" настроен в другом месте. В меню "Firewall / Virtual IPs". Тип каждого адреса: Type - "IP Alias", "Single address"

    Это имелось в виду под "настроены виртуальные интерфейсы"? Тут поломано?


  • @luha
    Посмотрите личку
    Виртуальные интерфейсы - GRE, VTI, OpenVPN и тд и тп


  • @konstanti Короче всётаки получается что интерфейся не виртуальные. Виртуальные только адреса IP из диапазона.


  • В процессе разбора и изучения файлика /tmp/rules.debug всплыло что как раз именно для этого правила NAT на 80-м порту у меня всё норм настроено, а на 443-м неверно указан шлюз. Нужно после правки ещё раз перепроверить и отпишусь для будущих поколений.

    Спасибо коллеге @konstanti за поддержку и пинок в нужную сторону.


  • @luha Всё нормально работает. Человеческий фактор в условиях неудобного интерфейса - сам накосячил и не заметил. :)

    Если у вас возникают похожие проблемы то лучшим решением будет перепроверить актуальную конфигурацию маршрутизации в файле /tmp/rules.debug как мне посоветовали выше. Прелесть этого файлика в том что всё нужное собрано в одном месте в читаемом виде и в отличие от вебморды пригодно для анализа.

    Когда настраивал правила NAT для дополнительного адреса IP воспользовался для упрощения функцией дублирования настроек. А потом подправлял и в одном месте не переключил интерфейс. Вот такая история, но замечу что функция оказалась довольно коварной, надо внимательнее.

    Я не критикую, может есть на то причина, но думаю что очень странно там организованы настройки. А главное они не перепроверяются никак перед сохранением и позже в общей таблице не фигурируют! А чтобы перепроверить надо протыкать всё по очереди, что вообще нереально при большом их количестве. Некоторые параметры по нескольку раз дублируются в разных местах. Сами посудите - если я выбираю из выпадающего меню конкретный адрес IP, который уже приписан и относится к определённому интерфейсу, то какой смысл ещё раз отдельно указывать интерфейс? Видимо маршрутизация организована на основе анализа ядром пакетов в потоке... как бы и фиг с ним, но очевидны проблемы при использовании модифицированных фальшивых пакетов, проплывающих на разных уровнях в составе протоколов. В общем я не оценил такой подход. Недавно пересел на PF и он неустанно удивляет на фоне других решений, где нельзя так просто любую фигню пихать в настройки - перед внесением конфигурация проверяется на очевидные нестыковки и не даёт творить "добро". Но это так... личное.


  • @luha
    Совет. Не трогайте floating rules. Если трогали. Вообще.
    Вы не первый, кто начинает в них правила создавать, а потом #попаболь


  • @werter Какие floating rules, о чём вы? Где и зачем их надо трогать?