Я борюсь с настройкой openVPN для подключения двух сайтов. Вот как выглядит сценарий
Офис 1 (сервер):
Офис 2 (клиент):
Внутренний IP-адрес клиента openvpn: 192.168.0.6 на tun0
внутренняя сеть openvpn: 192.168.0.0/24
И клиент, и сервер находятся за маршрутизаторами NAT с динамически назначаемыми IP-адресами.
По сути, предполагается, что задействованные машины в любом офисе «видят» друг друга. После настройки туннеля и правильной настройки таблиц маршрутизации на обоих сайтах обычные хосты в обеих сетях могут пинговать все в этих двух сетях. До сих пор хорошо.
Однако конечные точки могут видеть только друг друга, но ни один из хостов в их соответствующей удаленной сети. Например, если сделать
ping 192.168.178.2
с конечной точки VPN 192.168.177.2 он работает нормально, любой другой адрес работать не будет; хозяева не ответят.
Теперь посмотрим на вывод tcpdump, когда я пингую другой адрес, например 192.168.178.3.
11: 11: 28.104640 IP 192.168.0.6> 192.168.178.3: эхо-запрос ICMP, идентификатор 2130, последовательность 1, длина 64
Исходный IP-адрес кажется не совсем правильным. Он принадлежит внутренней сети OpenVPN, и я не получаю ответа ICMP.
Все начинает работать, когда я явно указываю ping использовать правильный IP-адрес источника:
ping 192.168.178.3 -I 192.168.177.2
Теперь вывод tcpdump тоже в порядке:
11: 20: 08.266271 IP 192.168.177.2> 192.168.178.3: эхо-запрос ICMP, id 7883, seq 17, длина 64 11: 20: 08.316037 IP 192.168.178.3> 192.168.177.2: эхо-ответ ICMP, id 7883, seq 17, длина 64
Глядя на критическую запись в таблице маршрутизации клиента, становится очевидным, что адрес источника находится во внутренней сети:
default via 192.168.177.1 dev p2p1 192.168.0.1 via 192.168.0.5 dev tun0 192.168.0.5 dev tun0 proto kernel scope link src 192.168.0.6 192.168.177.0/24 dev p2p1 proto kernel scope link src 192.168.177.2 192.168.178.0/24 via 192.168.0.5 dev tun0
Есть ли возможность заставить OpenVPN создать эту запись с соответствующим src ??
Вот мои файлы конфигурации openVPN. Я пропущу части TLS, так как сам туннель работает должным образом.
Сервер в офисе 1:
local 192.168.178.2 server 192.168.0.0 255.255.255.0 proto tcp-server port 1194 dev tun mssfix user nobody group nogroup keepalive 20 120 ping-timer-rem persist-tun persist-key float comp-lzo push "comp-lzo" push "route 192.168.178.0 255.255.255.0" route 192.168.177.0 255.255.255.0 client-config-dir client-configs
Есть одна конфигурация клиента, которая выглядит так:
iroute 192.168.177.0 255.255.255.0 push "route 192.168.178.0 255.255.255.0 vpn_gateway"
Клиент в офисе 2:
client dev tun0 remote <server address> proto tcp-client port 1194 connect-retry 15 comp-lzo user nobody group nogroup persist-tun persist-key
Я действительно в недоумении ... очень ценю вашу помощь.
Поведение, которое вы наблюдаете, было задумано. Хост в сети по умолчанию будет использовать IP-адрес интерфейса, с которого исходит трафик, в качестве IP-адреса источника.
Клиентский компьютер в одной из локальных сетей будет использовать, например, 192.168.178.10 в качестве исходного IP-адреса, поскольку он не является многосетевым. Затем шлюз направит пакет в ваш ящик OpenVPN, и он без проблем пройдет через туннель.
Однако, если вы выходите из самого окна OpenVPN, он будет использовать IP-адрес интерфейса OpenVPN, поскольку именно отсюда будет выходить пакет.
Что нормально. Он достигает удаленного сайта. Но затем удаленный сайт хочет отправить пакеты для ответа ping на 192.168.0.6. Ответ идет на шлюз, но поскольку у шлюза (я предполагаю, поскольку вы не разместили таблицы маршрутизации шлюза в сети) нет маршрута для этой сети, он не знает, как продолжить.
Самый простой способ решить эту проблему - просто добавить маршрут для 192.168.0.0/24 (ваша сеть OpenVPN) к шлюзу обеих сетей.
Другой вариант, если ваша операционная система поддерживает его (вы не указали, на какой ОС вы используете OpenVPN), - это посмотреть, можете ли вы использовать параметр «src» маршрута, чтобы переопределить это поведение по умолчанию при выборе IP-адреса. выходного интерфейса. См. Вопрос под названием Как установить собственный источник маршрута в openvpn Чтобы получить больше информации.