MultiWAN MultiIP
-
Делал раньше тему про MultiWAN:
https://forum.netgate.com/topic/157261/multiwan-%D0%BD%D0%B5-%D1%81%D1%80%D0%B0%D0%B1%D0%B0%D1%82%D1%8B%D0%B2%D0%B0%D1%8E%D1%82-%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%B0-outbound-%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%BE/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, о чём вы? Где и зачем их надо трогать?
-
Может подскажет кто. не могу настроить 2 одновременных подключения. С 1м работает замечательно 2е не видит со стороны локальных пк не как. То есть есть ип со стороны 2го адаптера wan2 100.120.192.1 его не видит wan1(и не должен видеть но это значит что wan2 настроен верно) . Этот ип пингуется с консоли но не доступен не с ПК локальной сети. Если меняю шлюз на балансировочный то интернет с локалке исчезает вовсе. Даже если просто отключаю wan1 то интернет исчезает не переключает на wan2. Где то я что пропустил что то а где не пойму. Все шлюзы пишет онлайн. Если поменять их местами то работает 2 а 1 нет. И еще если сделать Пинг через веб иснтерфейс с выбором адаптера то работает через оба..
-
Все решил надо было нат в автомат поставить..
