У меня есть только базовый опыт работы с VPN (в основном OpenVPN) и в основном теоретический, но теперь я хочу настроить что-то более сложное и оцениваю возможные проблемы, с которыми я могу столкнуться. Я постараюсь изобразить гипотетическую ситуацию на примерах. Допустим, для этой настройки используется OpenVPN.
У меня есть один главный сервер, на котором будет работать клиент OpenVPN, и разные удаленные места, на которых будут разные серверы OpenVPN. Я буду одновременно открывать разные туннели от главного сервера до этих удаленных мест. Допустим, у меня будет одновременно открыто десять разных туннелей.
Каждому из туннелей будет назначен локальный IP-адрес для клиента, например:
10.0.0.2/24 (туннель А)
10.0.1.2/24 (туннель B)
10.0.2.2/24 (туннель C)
...
Так, например, сервер OpenVPN в туннеле A будет 10.0.0.1/24. Если я хочу получить доступ к некоторому ресурсу внутри LAN туннеля A - например, к Apache, работающему на 172.16.0.50, Я бы просто ввел IP-адрес в компьютер своего VPN-клиента и подключился к веб-серверу (при условии, что все маршруты в порядке).
Моя основная проблема заключается в том, чтобы иметь одновременно разные туннели и несколько служб, работающих под одним и тем же локальным IP. В приведенном выше примере:
Туннель A: сервер 10.0.0.1/24, клиент 10.0.0.2/24, Apache 172.16.0.50
Туннель B: сервер 10.0.1.1/24, клиент 10.0.1.2/24, Apache 172.16.0.50
В этом конкретном примере у нас есть два экземпляра Apache, работающих в разных сетях, но использующих один и тот же локальный IP-адрес, поэтому, когда клиент вводит 172.16.0.50 пока активны два туннеля, я думаю, он выйдет из строя.
Я не уверен, что моя догадка верна, но держу пари, что это не такая уж нетипичная ситуация. Может кто-нибудь объяснить, что нужно делать в этой ситуации?
РЕДАКТИРОВАТЬ: Приношу свои извинения, если я был недостаточно ясен - позвольте мне упростить проблему, разбив ее на простые шаги:
Нет, убедительного и беспроблемного способа сделать это нет.
На уровне 3, когда оба туннеля открыты, клиент не имеет абсолютно никакого способа различить 172.16.0.50-через-туннель-1 из 172.16.0.50-через-туннель-2; IP просто не поддерживает такого рода принятие решений (маршрутизация по модулю от источника, что будет очень болезненно и плохо поддерживается).
Есть несколько грязных приемов, которые вы можете использовать: вы можете настроить NAT на клиенте, наложить два разных диапазона RFC1918 поверх двух похожих сетей и использовать маршрутизацию на основе политик для передачи трафика.
Но тогда вам придется переписать все, что ссылается на адреса из перекрывающегося диапазона, в зависимости от того, через какой туннель они проходят.
Честно говоря, будет менее болезненно перенастроить одну из двух целевых сетей. Это будет иметь удобное дополнительное преимущество, заключающееся в том, что вы сможете напрямую связать две сети - и если для бизнеса желательно, чтобы один клиент связался с обеими сетями, это только вопрос времени, когда станет желательным для бизнеса их прямое соединение.
редактировать: при текущих настройках та же проблема влияет на эту ситуацию: для любой учитывая адрес в перекрывающемся диапазоне, клиент не имеет возможности узнать, по какому туннелю он должен быть направлен вниз. Вы можете решить эту проблему только давая маршруты к 172.16.0.50 через туннель 1, и 172.16.0.51 через туннель 2. Однако это не очень хорошо масштабируется, если все интересные хосты в одной локальной сети не находятся в 172.16.0.0/25, а все остальные находятся в 172.16.0.128/25. В этом случае перенаправление IP не должно быть более болезненным, чем изменение сетевой маски повсюду.
Если все в порядке, трафик маршрутизируется через VPN1 по умолчанию и через VPN2 в качестве резервного, разделение проталкиваемого маршрута на 2/25 диапазонов на VPN1 и проталкивание полного / 24 на VPN2 приведет к исправлению этого.
В случае, если VPN1 не работает и маршруты 2/25 удалены, у него все еще есть / 24 из VPN2, поэтому вы получите высокую доступность, хотя и без балансировки нагрузки.
Итак, на VPN1 вы могли:
push "route 172.16.0.0 255.255.255.128"
push "route 172.16.0.128 255.255.255.128"
в то время как на VPN2 вы бы сделали:
push "route 172.16.0.0 255.255.255.0"
Поскольку наиболее "узкий" маршрут имеет приоритет, клиент предпочел бы VPN1 вместо VPN2.
Также вы можете вместо этого указать другую клиентскую сторону route-metric в конфигурации клиента, например, в конфигурации клиента для VPN1:
route-metric 200
а в VPN2:
route-metric 201