Возможно ли реализовать сервер для выбора VPN туннеля?
Доброго времени суток, использую несколько арендованных VPS на которых развернуты VPN (в основном на wireguard).
Интересует такой вопрос, возможно ли организовать доступ ко всем VPN разом с одной VPS по принципу:
Клиент ---(туннель WG)---> VPS с туннелями до всех VPN ---(туннель с самым низким пингом)---> VPS ---> точка назначения
Не знаю в какую сторону копать и что читать, бывают ситуации когда с одной VPS доступа к ресурсу нет, а с другой есть (ну либо отвратная скорость на одном из туннелей), поэтому хотелось настроить что то вроде "хаба" который выбирает оптимальный туннель для конкретного обращения клиента к ресурсу.
Клиент ---(туннель WG)---> VPS с туннелями до всех VPN
У Вас получается что клиент, всегда фиксировано подключается к одному ВПН серверу.
В такой ситуации, Вам нет смысла городить подтуннели в туннелях, т.к. вы и так заворачиваете весь траффик в туннелями WG, получается что Вам нужно смотреть в сторону маршрутов а не туннелями .
Схема выглядит примерно так - Ваш VPS с туннелями всегда постоянно подключен к другим машинам по VPN. Далее, в prerouting вам нужно понять, через какой туннель у вас наименьшая latency, и пустить траффик по маршруту с меньшей задержкой. Поэтому смотрите в сторону route по ping. Одно НО, некоторые хосты не отдают ответы на пинги, трасировка - тоже не всегда показателем будет - т.к. маршрут может идти между узлами с большей задержкой. Как прорабатывать такие исключения - вопрос. По линуксам, как сетевому устройству не подскажу как такое сделать, Но в любом случае, такая работа потребует больших накладных расходов, что может нивелировать преимущества такого решения.
Alkazam, к сожалению не ответ, поэтому оставил как коммент, но хоть крупными мазками направление подсказал. Вопрос интересный в целом, и как его решить представление есть, однако в том виде как я вижу, это будет нести больше вреда чем пользы. Т.к. расходы (ресурсов) на этот анализ - будут большие. А это в свою очереди скажется на скорости работы, что вы наоборот хотите повысить. Получается некая петля, выход из которой пока не вижу. Среди ответов, пока тоже не встретил конкретных предложений.
Если маршрутов не много, то я бы попробовал такой вариант.
Использовать zerotier, он позволяет получить mesh vpn. Потом в конфигурации zt определяеш один из VPS как default, а для остальных прописываеш статические маршруты для определенный ресурсов через определенный VPS. В результате клиент будет автоматически с ZT получать талицу маршрутизации и он будет знать к какому ресурсу через какой VPS ходить.
Не совсем понял зачем гордить огород и направлять пакет с одной VPS на другую да ещё и через VPN что естественно чревато потерей производительности и пинга.
Может не совсем корректно описал, фактически цель состоит в том, что имея много точек выхода в разных странах иметь возможность обратится к ресурсу по оптимальному маршруту из списка, не прибегая к ручному переключению.
Сейчас фактически к каждой VPS прокинут туннель и приходится на клиентах тыкать тот туннель который в данном случае нужен, хотелось просто автоматизировать этот процесс
Alkazam, все равно не понял потребность в нескольких VPS с разными VPN. Достаточно иметь один какой то в нормальной стране, и в крайнем случае один в РФ если надо снаружи заходить на российские гос сервера.
В случае с chr как определять наименьшую дистанцию до конечного узла через множество выходных интерфейсов и отмаркировать соединение для выдачи оптимального маршрута?
Maksim Herasim, маркировка здесь не нужна нужен скрипт определения наименьшего количества прыжков и переопределения distanse на его основе либо ручное определение приоритета на основе дистанции маршрутов, или петли через scope
Zerg89, Я не с целью критики, а интереса ради. Имею ввиду практическое применение, а не сравнительный анализ. Хотя бы абстрактную логическую цепочку. Нужно же каждый dst проверять, через какой interface его пускать. Пускай будет 10 выходных интерфейсов, нужно по каждому из них проверить наименьшую задержку, какими средствами это реализуется? Условно - в prerouting мы вычленяем каждый уникальный dst - далее нам нужно выполнить проверку через какой из выходов латенси будет меньше - далее маркируем соединение и отправляем его через предопределенный route. Как выполнить проверку наименьшего латенси, чтобы отмаркировать соединение ?
Zerg89, Ваш второй ответ увидел позже того, как написал свой.
Ручное определение - это титанический труд в данном случае (если предположить что конечные адреса ресурсов заранее неизвестны). Поэтому можно оставить за скобками. Плюс маршруты вышестоящих провайдеров могут меняться, от этого может меняться и latency до определенного узла. Постоянно вручную это отслеживать, такое себе удовольствие
Вашу затею со скриптом понял (заполнение таблицы маршутизации), но тоже не до конца понятно что лучше, т.к. эти маршруты нужно время от времени перепроверять - затея с маркировкой соединений выглядит интересно, но вероятно несёт бОльшие накладные расходы по ресурсам, поэтому тут нужно просчитывать, что по ресурсам выгоднее. Однако не понял как заставить CHR обрабатывать соединения в script
Maksim Herasim, соединения не стоит дропать принудительно (только в случаях отсутствия связи иначе больше задержек на переотправку данных на равнозначных каналах можно получить) и здесь возможно уже маркировка(маршрута) потребуется, если нужна скорость реакции на перестройку вышестоящих сетей провайдеров (bgp,ospf) но по сути если у вас отслеживаются все маршруты через петли то определить наименьшее количество прыжков через тот или иной шлюз не составит проблемы конечный итог просто изменение приоритета маршрутов, а по поводу, "адреса ресурсов заранее неизвестны" на это есть как минимум динамические access листы с днс именем ресурса вместо ip адреса, ну или если совсем в логику уходить l7 и regexp(на хорошей железке или VM будет работать это уже не роутер с mibs)
PS под ручным имелось ввиду по ACCESS list в определённый маршрут и только туда или через петлю в несколько разных маршрутов с другим scope(например через srcnat завернуть внутрь на другой маршрут)
Средний
