Локальные ресурсы в локальной сети по WAN ip или доменному имени при использовании multi-wan

Konstanti

@sirota
Добрый день
А почему нельзя для каждого сервиса сделать свой поддомен
service1.site.xyz
sevice2.site.xyz
.....

и спокойно продолжать использовать split dns ?

sirota

@Konstanti said in Локальные ресурсы в локальной сети по WAN ip или доменному имени при использовании multi-wan:

и спокойно продолжать использовать split dns ?

Начнем с того как это решит проблему:

@sirota said in Локальные ресурсы в локальной сети по WAN ip или доменному имени при использовании multi-wan:

или первый будет не доступен, то я ни как не смогу получить доступ к ресурсам?

И закончим тем что есть пересекающиеся сервисы, а так же внешние которые уже настроены настроены на данную работу. Как минимум 150 клиентов уже работают и только им чтобы все это переделать - большой труд.

Konstanti

@sirota

Так смысл split dns в том , чтобы внутри сети клиенты получали внутренний ip адрес сервиса , а снаружи внешний
Те не будет никакого обращения к ресурсам PF. А будут обращаться к серверам напрямую.

sirota

@Konstanti 1. Я уже объяснил, поменять домен+порт на субдомен+домен не выход. Я знаю что есть 100% решение этого вопроса более элегантно. 2. Просто к примеру в условиях того же микрота это решается элегантно просто - пакеты с входящего wan маркируются и исходящий ответ по маркировке уйдет только по нужному шлюзу (образно). В pfsense же какая-то проблема с этим.

Konstanti

@sirota
Может быть мы друг друга не понимаем
Сейчас , насколько я вижу , у Вас все замкнуто через WAN1/WAN2 , и весь внутренний трафик "ходит" через PFSense
Но я ,все-таки на Вашем месте , рассмотрел бы вариант , чтобы внутренний DNS сервер возвращал клиентам внутренний ip адрес сервера для каждого сервиса , и клиенты тогда обращались бы к серверам/сервисам напрямую .
И не было бы таких сложных конструкций с NAT-ми и пробросами портов
Да , придется провести заново настройку клиентов , но это поможет Вам в будущем избежать проблем в случае усложнения топологии сети.
Все остальное , это "костыли" , по-моему

sirota

This post is deleted!

sirota

@Konstanti said in Локальные ресурсы в локальной сети по WAN ip или доменному имени при использовании multi-wan:

у Вас все замкнуто через WAN1/WAN2

Не понял что замкнуто? 2 провайдера. Оба не отличаются ни великой скоростью за разумную плату, ни стабильнотью. По этому Gateway Groups где оба провайдера выставлены tier1. Своеобразная балансировка + отказоустойчивость.
Если я убираю целиком и полностью второго провайдера, то моя схема работает безотказно до момента пока у первого провайдера не упадет инет )))
Проблема возникает только когда мне надо чтобы одновременно было 2 провайдера. Грубо говоря из интернета проблем нет, я спокойно получаю доступ ко всем ресурсам по любому из внешних IP в том числе и по доменному имени.

Ну dns-split - как по мне костыль еще больший. В случае смены локального IP у сервиса мне потребует переназначать его в DNS forwader. Попутно правя правила в файрволе. А как мне быть когда завтра я подниму безотказный кластер локального ресурса? Как тогда быть?
Давай больше не будем мусолить dns-split. Он мне не подходит и точка.

Konstanti

@sirota
Так вот именно в этом и есть проблема , что Вы клиенту отдаете в качестве внутреннего ip адреса сервера внешний ip адрес Вашего файрвола. Тем самым заставляете клиента весь внутренний трафик прогонять через файрвол , заставляя последнего выполнять ненужную работу. И если внешний интерфейс падает , то внутренний клиент об этом никак не узнает и продолжает гнать трафик на этот интерфейс, и все его работа встает. О падении внешнего интерфейса DNS сервер тоже ничего не знает , поэтому спокойно отдает его ip адрес в DNS ответе.

Решения , я лично вижу тут 2

То которое Вам не подходит ( кстати , не совсем понял ,при чем тут правила файрвола в схеме split-dns , если весь внутренний трафик пойдет мимо него )
Это написание некоего скрипта/модуля , который бы при падении одного из интерфейсов , ip адрес которого отдает DNS сервер
а. Убивал бы все соединения на этом интерфейсе
б. Подменял бы ответы DNS сервера на ответы с ip адресом "живого" интерфейса
в. При поднятии интерфейса все бы возвращалось на " круги своя"
(AF_ROUTE SOCKET + NETGRAPH)
Мб существует еще какое-то решение , но я пока не придумал как

sirota

@Konstanti

Это не есть проблема. Там производительности вагон и маленькая тележка. Пусть работает. Мне не жалко.
Если упадут оба внешних интерфейса, то смысла и так от этих сервисов будет не много, ибо их работа так же зависит от работоспособности сети интернет.
Конечно существует. На микроте это делается без великих проблем. И у меня даже есть 2 места где это работает.

Konstanti

@sirota
Если на микротике это реализуется маркировкой пакетов

Просто к примеру в условиях того же микрота это решается элегантно просто - пакеты с входящего wan маркируются и исходящий ответ по маркировке уйдет только по нужному шлюзу (образно).

То Вы тоже аналогично можете "поиграться " маркировкой - делается это в настройках правил файрвола . В настройках правил интерфейса метка наносится , во Floating правилах можно метку анализировать.

werter

Добрый.

@sirota

ВМЕСТО сплитднс можно создать портфорвард на ЛАН и принудительно заворачивать все необходимое на нужный 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

pigbrother

@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

sirota

@werter Привет. Я думал завтра тебе набрать )))
Я так и сделал

При чем я даже немного ужесточил - все что попадает на 443 порт на wan-ах все попадает на сервер в локальной сети.
Из инета все работает, ни каких проблем. Отключаю WAN1 и из инета люди пользуются сервисами через wan2. И обратно. Но так не прокатывает если нужны сервисы из сети в которой они расположены:

Видишь там на вторая звездочка - это default gateway. Без этого правила в сети до ресурсов вообще не добраться. И правила работают только если там стоит default gateway и клиентский ПК запросил доступ к ресурсу по ip WAN1. Если руками в правиле поменять default gateway на gateway wan1, то оно уже работать не будет и для запроса по ip wan1. Если на днях время будет свободное, можем попробовать потыкать. Я уже и tcpdump-ом гонял и со своего ПК и на пфсенсе, вообще не вдуплю.

sirota

@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. И данная связка уже не работала.

werter

Добрый.
@sirota

Но так не прокатывает если нужны сервисы из сети в которой они расположены:

Правило форвардинга нужно и на ВАН и на ЛАН.
После для проверки либо сбросить днс-кеш на клиенте (в Вин - ipconfig /flushdns из под Админ-ра), либо перезагрузить его машину.

sirota

@werter said in Локальные ресурсы в локальной сети по WAN ip или доменному имени при использовании multi-wan:

Добрый.
@sirota

Но так не прокатывает если нужны сервисы из сети в которой они расположены:

Правило форвардинга нужно и на ВАН и на ЛАН.
После для проверки либо сбросить днс-кеш на клиенте (в Вин - ipconfig /flushdns из под Админ-ра), либо перезагрузить его машину.

Так?
Просто временно убрал у dns регистратора второй ip. Ибо мне забыли его сделать статикой.

werter

@sirota

Пример завернет все идущее на 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. Логика же проста до примитивности.

sirota

@werter said in Локальные ресурсы в локальной сети по WAN ip или доменному имени при использовании multi-wan:

@sirota

Пример завернет все идущее на 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 ВНЕШНЕЕ имя нужного ресурса.

Да-да. Я уже догнал. Переделываю как раз сейчас.

werter

После для проверки либо сбросить днс-кеш на клиенте (в Вин - ipconfig /flushdns из под Админ-ра), либо перезагрузить его машину.

sirota

@werter
Взлетело! Отключил WAN1, и у меня по доменному имени открылся сайт через WAN2. При этом правила файрвола созданные автоматом для wan1 и для wan2 идентичны и работает соответственно только первое в списке.
Еще раз спасибо тебе большое!
Правда есть затуп для тех клиентов у которых инет отключен кроме белого списка. Надо будет потом еще посмотреть что за затуп. Но Скорее всего там сертфикат стоит такой что не добавлен в белый список домен где список отзывов лежит.