Я пытаюсь создать «цепочку» OpenVPN, аналогичную описанной Вот. У меня есть две отдельные сети, A и B. Каждая сеть имеет сервер OpenVPN, использующий стандартный подход «дорожный воин» или «клиент / сервер». Клиент может подключиться к любому из них для доступа к хостам / службам в соответствующей сети.
Но серверы A и B также подключены к друг друга. Серверы в каждой сети имеют соединение типа "сеть-сеть" между ними.
То, что я пытаюсь достичь, - это возможность подключиться к сети A в качестве клиента, а затем установить соединения с хостами в сети B. Я использую tun / routing для всех VPN-подключений. «Цепочка» выглядит примерно так:
[Client] ---> [Server A] ---> [Server A] ---> [Server B] ---> [Server B] ---> [Host B]
(tun0) (tun0) (tun1) (tun0) (eth0) (eth0)
Вся идея состоит в том, что сервер A должен маршрутизировать трафик, предназначенный для сети B, через VPN «сайт-сеть», установленную на tun1, когда клиент из tun0 пытается подключиться.
Я сделал это просто, установив два профиля подключения на сервере A. Один профиль - это стандартная конфигурация сервера, работающая на tun0, определяющая виртуальную клиентскую сеть, пул IP-адресов, проталкивающие маршруты и т.д. клиент подключение к серверу B, работающему на tun1. После включения ip_forwarding я просто добавил «push route» для клиентов, объявляющих маршрут к сети B.
На сервере A это работает, когда я смотрю на вывод tcpdump. Если я подключаюсь как клиент, а затем проверяю связь с хостом в сети B, я вижу, как трафик проходит от tun0 к tun1 на сервере A:
tcpdump -nSi tun1 icmp
Странно то, что я не вижу, чтобы сервер B принимал этот трафик через туннель. Это как если бы сервер A отправлял его через соединение типа "сеть-сеть", как должен, но сервер B полностью игнорирует это. Когда я ищу трафик на сервере B, его просто нет.
Пинг с сервера A -> Host B работает нормально. Но эхо-запрос от клиента, подключенного к серверу A, к хосту B - нет.
Мне интересно, игнорирует ли сервер B трафик, потому что исходный IP-адрес не соответствует пулу клиентских IP-адресов, который он передает клиентам? Кто-нибудь знает, нужно ли мне что-то делать на сервере B, чтобы он видел трафик?
Это сложная проблема для объяснения, так что спасибо, если вы застряли со мной так далеко.
Я нашел решение этого. Нет необходимости иметь несколько / избыточных VPN-подключений, как описано в Ответе №1. Я также не думаю, что это помогло бы мне решить мою проблему, насколько я ценю отзывы.
Проблема связана с тем, что сервер OpenVPN будет принимать IP-трафик только через туннель подключенного клиента, если исходный IP-адрес совпадает с тем, что сервер назначил клиенту при создании туннеля. Трафик, исходящий с любого другого IP-адреса источника, проходящий через туннель, будет полностью игнорироваться сервером.
Взгляните на следующее:
10.2.1.15 10.2.0.1/123.123.123.1 124.124.124.1/10.1.0.1 10.1.1.20
(eth0) (eth0 / eth1) (eth0 / eth1) (eth0)
---------- ------------- ------------ ----------
| Хост A | ------------- | Шлюз 1 | ------------------------------------------ | Шлюз 2 | -------- | Хост B |
---------- -------------- {ИНТЕРНЕТ} ---------------- ------- ----
VPN КЛИЕНТ VPN СЕРВЕР
172.16.1.12 172.16.2.1
(tun0) (tun0)
Итак, в этом примере «шлюз 1» - это клиент VPN, устанавливающий туннель к «шлюзу 2» в качестве сервера VPN. То, что мы хотим достичь, - это возможность хоста A связываться с хостом B через VPN. Итак, мы установили стандартное соединение OpenVPN со шлюзом 1 в качестве клиента для сервера шлюза 2. Каждый шлюз имеет «публичный» и «частный» интерфейс. Один для частной сети, другой для общедоступного Интернета. Когда VPN-соединение установлено, каждый сервер использует дополнительный интерфейс tun0. Шлюз 2, действующий как сервер VPN, принимает соединение от шлюза 1 и назначает ему IP-адрес 172.16.1.12.
Проблема в том, что шлюз 2 будет принимать трафик через этот VPN-туннель, только если исходный IP-адрес 172.16.1.12.
Это прекрасно работает, когда Шлюз 1 хочет подключиться к хосту B, но это проблема, когда Хост А пытается подключиться к хосту B. Когда хост A пытается подключиться, шлюз 1 действует как маршрутизатор и правильно направляет трафик через VPN-туннель на шлюз 2 (при условии, что ваши маршруты настроены правильно). Если вы запустите tcpdump на tun0 устройства шлюза 1, вы даже увидите, что трафик от хоста A проходит через туннель, предназначенный для другой сети. Но шлюз 2 видит исходный IP-адрес как 10.2.1.15 который не совпадает IP-адрес, назначенный для подключения, и полностью игнорирует его.
Итак, решение - настроить Шлюз 2 принимать трафик из сети 10.2.0.0/16 через VPN-туннель. VPN-сервер должен быть настроен с iroute настройка. Процедура настройки и все параметры конфигурации описаны на официальном сайте OpenVPN. Вот поэтому я не буду повторно объяснять это в этом посте.
Я предлагаю при чтении этой документации обратить особое внимание на то, что вам необходимо использовать каталоги конфигурации клиента (CCD) в вашей конфигурации OpenVPN, чтобы использовать iroute. Убедитесь, что вы внимательно прочитали эту часть документации. Вам также, конечно же, потребуется настроить маршруты на всех ваших шлюзах, чтобы они знали, как направлять трафик через VPN-туннель. Ссылаясь на диаграмму выше, вам все равно нужно добавить маршрут на Шлюз 2 как это:
route add -net 10.2.0.0 маска сети 255.255.0.0 gw 172.16.1.12 tun0
и на шлюзе 1 вот так:
route add -net 10.1.0.0 маска сети 255.255.0.0 gw 172.16.2.1 tun0
Чтобы трафик от хоста B правильно маршрутизировался через VPN при попытке подключения к хосту A.
В моем конкретном случае шлюз 1 действует как клиент к шлюзу 2, но также как сервер другим клиентам, подключающимся из Интернета, которым необходим доступ к узлу A. Поэтому мне нужно было создать два интерфейса, tun0 и tun1, чтобы один можно было использовать для подключения клиента к другой сети, а другой - как сервер. для подключения дорожных воинов. Мне также нужно добавить дополнительные маршруты, чтобы я мог установить VPN-соединение со шлюзом 1 (сервер) из Интернета, и я мог направлять трафик на Хост B в другой сети.
Я надеюсь, что это поможет другим, кто не понимает этого.
Я недавно это настроил. Мне нужно было добавить правильные команды маршрута в openvpn.confs.
Моя конфигурация даже немного сложнее вашей. У меня есть три сайта, которые являются регионами EC2: us-east-1 (VA), us-west-1 (CA) и us-west-2 (OR). Каждый из них имеет свой собственный диапазон частных IP-адресов:
VA 10.1.0.0/16
CA 10.0.0.0/16
OR 10.10.0.0/16
Конфигурация - OR <=> CA <=> VA, при этом CA формирует центральный «концентратор».
конфигурация va-to-ca.conf
# Sample OpenVPN configuration file using a pre-shared static key
# Port to use: 1194 is the official IANA port number
port 1194
# Use a dynamic tun device.
dev tun
# Remote peer and network
remote 54.241.174.228
route 10.0.0.0 255.255.0.0
route 10.10.0.0 255.255.0.0
# Configure local and remote VPN endpoints
ifconfig 169.254.255.1 169.254.255.2
# The pre-shared static key
secret ovpn.key
# keepalive
keepalive 10 120
конфигурация ca-to-va.conf
# Sample OpenVPN configuration file using a pre-shared static key
# Port to use: 1194 is the official IANA port number
port 1195
# Use a dynamic tun device.
dev tun
# Remote peer and network
remote 54.244.21.223
route 10.10.0.0 255.255.0.0
# Configure local and remote VPN endpoints
ifconfig 169.254.255.3 169.254.255.4
# The pre-shared static key
secret ovpn.key
# keepalive
keepalive 10 120
конфигурация ca-to-or.conf
# Sample OpenVPN configuration file using a pre-shared static key
# Port to use: 1194 is the official IANA port number
port 1194
# Use a dynamic tun device.
dev tun
# Remote peer and network
remote 54.236.173.50
route 10.1.0.0 255.255.0.0
# Configure local and remote VPN endpoints
ifconfig 169.254.255.2 169.254.255.1
# The pre-shared static key
secret ovpn.key
# keepalive
keepalive 10 120
config или-to-ca.conf
# Sample OpenVPN configuration file using a pre-shared static key
# Port to use: 1194 is the official IANA port number
port 1195
# Use a dynamic tun device.
dev tun
# Remote peer and network
remote 54.241.174.228
route 10.0.0.0 255.255.0.0
route 10.1.0.0 255.255.0.0
# Configure local and remote VPN endpoints
ifconfig 169.254.255.4 169.254.255.3
# The pre-shared static key
secret ovpn.key
# keepalive
keepalive 10 120
Обратите внимание на команды маршрута, которые идут к другой конечной точке. Я думаю, если вы разместите свою сеть и все IP-адреса на любой конечной точке, вы быстро сможете изменить мой пример для своей топологии.