Локальные ресурсы в локальной сети по WAN ip или доменному имени при использовании multi-wan
-
Так смысл split dns в том , чтобы внутри сети клиенты получали внутренний ip адрес сервиса , а снаружи внешний
Те не будет никакого обращения к ресурсам PF. А будут обращаться к серверам напрямую. -
@Konstanti 1. Я уже объяснил, поменять домен+порт на субдомен+домен не выход. Я знаю что есть 100% решение этого вопроса более элегантно. 2. Просто к примеру в условиях того же микрота это решается элегантно просто - пакеты с входящего wan маркируются и исходящий ответ по маркировке уйдет только по нужному шлюзу (образно). В pfsense же какая-то проблема с этим.
-
@sirota
Может быть мы друг друга не понимаем
Сейчас , насколько я вижу , у Вас все замкнуто через WAN1/WAN2 , и весь внутренний трафик "ходит" через PFSense
Но я ,все-таки на Вашем месте , рассмотрел бы вариант , чтобы внутренний DNS сервер возвращал клиентам внутренний ip адрес сервера для каждого сервиса , и клиенты тогда обращались бы к серверам/сервисам напрямую .
И не было бы таких сложных конструкций с NAT-ми и пробросами портов
Да , придется провести заново настройку клиентов , но это поможет Вам в будущем избежать проблем в случае усложнения топологии сети.
Все остальное , это "костыли" , по-моему -
This post is deleted! -
@Konstanti said in Локальные ресурсы в локальной сети по WAN ip или доменному имени при использовании multi-wan:
у Вас все замкнуто через WAN1/WAN2
Не понял что замкнуто? 2 провайдера. Оба не отличаются ни великой скоростью за разумную плату, ни стабильнотью. По этому Gateway Groups где оба провайдера выставлены tier1. Своеобразная балансировка + отказоустойчивость.
Если я убираю целиком и полностью второго провайдера, то моя схема работает безотказно до момента пока у первого провайдера не упадет инет )))
Проблема возникает только когда мне надо чтобы одновременно было 2 провайдера. Грубо говоря из интернета проблем нет, я спокойно получаю доступ ко всем ресурсам по любому из внешних IP в том числе и по доменному имени.Ну dns-split - как по мне костыль еще больший. В случае смены локального IP у сервиса мне потребует переназначать его в DNS forwader. Попутно правя правила в файрволе. А как мне быть когда завтра я подниму безотказный кластер локального ресурса? Как тогда быть?
Давай больше не будем мусолить dns-split. Он мне не подходит и точка. -
@sirota
Так вот именно в этом и есть проблема , что Вы клиенту отдаете в качестве внутреннего ip адреса сервера внешний ip адрес Вашего файрвола. Тем самым заставляете клиента весь внутренний трафик прогонять через файрвол , заставляя последнего выполнять ненужную работу. И если внешний интерфейс падает , то внутренний клиент об этом никак не узнает и продолжает гнать трафик на этот интерфейс, и все его работа встает. О падении внешнего интерфейса DNS сервер тоже ничего не знает , поэтому спокойно отдает его ip адрес в DNS ответе.Решения , я лично вижу тут 2
-
То которое Вам не подходит ( кстати , не совсем понял ,при чем тут правила файрвола в схеме split-dns , если весь внутренний трафик пойдет мимо него )
-
Это написание некоего скрипта/модуля , который бы при падении одного из интерфейсов , ip адрес которого отдает DNS сервер
а. Убивал бы все соединения на этом интерфейсе
б. Подменял бы ответы DNS сервера на ответы с ip адресом "живого" интерфейса
в. При поднятии интерфейса все бы возвращалось на " круги своя"
(AF_ROUTE SOCKET + NETGRAPH) -
Мб существует еще какое-то решение , но я пока не придумал как
-
-
- Это не есть проблема. Там производительности вагон и маленькая тележка. Пусть работает. Мне не жалко.
- Если упадут оба внешних интерфейса, то смысла и так от этих сервисов будет не много, ибо их работа так же зависит от работоспособности сети интернет.
- Конечно существует. На микроте это делается без великих проблем. И у меня даже есть 2 места где это работает.
-
@sirota
Если на микротике это реализуется маркировкой пакетовПросто к примеру в условиях того же микрота это решается элегантно просто - пакеты с входящего wan маркируются и исходящий ответ по маркировке уйдет только по нужному шлюзу (образно).
То Вы тоже аналогично можете "поиграться " маркировкой - делается это в настройках правил файрвола . В настройках правил интерфейса метка наносится , во Floating правилах можно метку анализировать.
-
Добрый.
ВМЕСТО сплитднс можно создать портфорвард на ЛАН и принудительно заворачивать все необходимое на нужный IP в ЛАН.
Пример завернет все идущее на https://yandex.ru на https://локальный-ip-сервера :
int -LAN, proto - TCP, src-LAN, dst addr - yandex.ru, dst port - 443, NAT IP - локальный-ip-сервера, NAT port - 443 -
@Konstanti said in Локальные ресурсы в локальной сети по WAN ip или доменному имени при использовании multi-wan:
То Вы тоже аналогично можете "поиграться " маркировкой - делается это в настройках правил файрвола . В настройках правил интерфейса метка наносится , во Floating правилах можно метку анализировать.
В Микротике практически все, что связано с multiwan да и многое другое реализуется через mangle,
@Konstanti said in Локальные ресурсы в локальной сети по WAN ip или доменному имени при использовании multi-wan:
То Вы тоже аналогично можете "поиграться " маркировкой - делается это в настройках правил файрвола . В настройках правил интерфейса метка наносится , во Floating правилах можно метку анализировать.
Imho, по аналогии с Linux:
все цепочки таблицы mangle пакеты проходят раньше, чем одноименные цепочки таблиц nat и filter. Это позволяет классифицировать и маркировать пакеты и соединения в цепочках этой таблицы. Впоследствии эти маркировки могут быть использованы в цепочках двух других таблиц при принятии решений о фильтрации и трансляции адресов.Логичнее будет пакеты маркировать (tag) во Floating, а анализировать\использовать в основных правилах NAT\Firewall
-
@werter Привет. Я думал завтра тебе набрать )))
Я так и сделал
При чем я даже немного ужесточил - все что попадает на 443 порт на wan-ах все попадает на сервер в локальной сети.
Из инета все работает, ни каких проблем. Отключаю WAN1 и из инета люди пользуются сервисами через wan2. И обратно. Но так не прокатывает если нужны сервисы из сети в которой они расположены:
Видишь там на вторая звездочка - это default gateway. Без этого правила в сети до ресурсов вообще не добраться. И правила работают только если там стоит default gateway и клиентский ПК запросил доступ к ресурсу по ip WAN1. Если руками в правиле поменять default gateway на gateway wan1, то оно уже работать не будет и для запроса по ip wan1. Если на днях время будет свободное, можем попробовать потыкать. Я уже и tcpdump-ом гонял и со своего ПК и на пфсенсе, вообще не вдуплю. -
@pigbrother В пфсенсе можно маркировать пакет во флоате и что-то с ним сделать дальше? Во флоате я ловлю входящий пакет (к примеру в логах файрвола при default gateway и запросе с wan1 из локалки я вижу к примеру пакет вида 192.168.0.10 - 192.168.0.215 (IP.WAN1). на lan интерфейсе с назначением IP.WAN1 и интересующем мне порту и мечу его к примеру wan1service1. Как мне теперь обратный пакет зарезолвить? Просто я вот как делал - отключал wan1 интерфейс вообще и в правилах жестко писал не defaultt gateway (он у пфсенса как я понял всегда жестко забинден на wan по умолчанию (у меня он переименован в wan1)), а wan2 gateway. И данная связка уже не работала.
-
Добрый.
@sirotaНо так не прокатывает если нужны сервисы из сети в которой они расположены:
Правило форвардинга нужно и на ВАН и на ЛАН.
После для проверки либо сбросить днс-кеш на клиенте (в Вин - ipconfig /flushdns из под Админ-ра), либо перезагрузить его машину. -
@werter said in Локальные ресурсы в локальной сети по WAN ip или доменному имени при использовании multi-wan:
Добрый.
@sirotaНо так не прокатывает если нужны сервисы из сети в которой они расположены:
Правило форвардинга нужно и на ВАН и на ЛАН.
После для проверки либо сбросить днс-кеш на клиенте (в Вин - ipconfig /flushdns из под Админ-ра), либо перезагрузить его машину.Так?
Просто временно убрал у dns регистратора второй ip. Ибо мне забыли его сделать статикой. -
Пример завернет все идущее на https://yandex.ru на https://локальный-ip-сервера :
int -LAN, proto - TCP, src-LAN, dst addr - yandex.ru, dst port - 443, NAT IP - локальный-ip-сервера, NAT port - 443По аналогии.
Вместо yandex.ru - ВНЕШНЕЕ имя нужного ресурса, а не LAN addr\WAN addr. Логика же проста до примитивности. -
@werter said in Локальные ресурсы в локальной сети по WAN ip или доменному имени при использовании multi-wan:
Пример завернет все идущее на https://yandex.ru на https://локальный-ip-сервера :
int -LAN, proto - TCP, src-LAN, dst addr - yandex.ru, dst port - 443, NAT IP - локальный-ip-сервера, NAT port - 443По аналогии. Вместо yandex.ru ВНЕШНЕЕ имя нужного ресурса.
Да-да. Я уже догнал. Переделываю как раз сейчас.
-
После для проверки либо сбросить днс-кеш на клиенте (в Вин - ipconfig /flushdns из под Админ-ра), либо перезагрузить его машину.
-
@werter
Взлетело! Отключил WAN1, и у меня по доменному имени открылся сайт через WAN2. При этом правила файрвола созданные автоматом для wan1 и для wan2 идентичны и работает соответственно только первое в списке.
Еще раз спасибо тебе большое!
Правда есть затуп для тех клиентов у которых инет отключен кроме белого списка. Надо будет потом еще посмотреть что за затуп. Но Скорее всего там сертфикат стоит такой что не добавлен в белый список домен где список отзывов лежит. -
@werter
Это для 80 и 443 порта. Выходит по 4 правила на порт.А ну и как обычно вылезла проблема - ip6 на клиентских компах. Надо всем его выключить. почему-то у тех у кого он включен и отключен инет (ip6 у меня же вообще рубится), то nslookup отвечает по ip6 что не получен ответ. В то время если у человека включен инет без ограничений, включен ip6 в винде и так же рубится ip6 на pfsense, то у него ответ нормального человека по ip4.
-
Блин (
Не надо в dst - WAN addr для форвардинга на ЛАН.
В dst пишем реальный ВНЕШНИЙ адрес того сайта, к-ый мы редиректим. Если сайт наз-ся site.ru, то и пишем его в dst.