У меня настроен site-to-site VPN с использованием OpenVPN. Туннель, кажется, работает нормально (и я могу пинговать с одного конца на другой), но я не могу заставить сети на двух концах видеть друг друга.
Моя топология следующая:
Net1 (192.168.13.0/24)
|
|
|
192.168.13.35
ens160
-----------
OVPN Client
-----------
tun0
10.13.10.2
|
|
10.13.10.1
tun0
-----------
OVPN Server
-----------
ens160
10.1.121.6
|
|
Net2 (10.1.121.0/26)
Я могу выполнить ping от клиента к серверу:
srv# ping 10.13.10.2
PING 10.13.10.2 (10.13.10.2) 56(84) bytes of data.
64 bytes from 10.13.10.2: icmp_seq=1 ttl=64 time=5.46 ms
64 bytes from 10.13.10.2: icmp_seq=2 ttl=64 time=5.01 ms
Я могу получить доступ от клиента к Net1 (конечно, добавив соответствующие маршруты):
client#ping 10.1.121.8
PING 10.1.121.8 (10.1.121.8) 56(84) bytes of data.
64 bytes from 10.1.121.8: icmp_seq=1 ttl=63 time=48.0 ms
Однако я совершенно не могу сделать наоборот (пропинговать что-то в клиентской сети -Net2- с сервера). Я даже не могу получить доступ к IP клиента в Net2 с сервера:
server#ping 192.168.13.35
PING 192.168.13.35 (192.168.13.35) 56(84) bytes of data.
^C
--- 192.168.13.35 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2014ms
У меня есть соответствующие маршруты:
server# ip route
default via 10.1.121.1 dev ens160 onlink
10.1.121.0/26 dev ens160 proto kernel scope link src 10.1.121.6
10.13.10.0/24 dev tun0 proto kernel scope link src 10.13.10.1
192.168.13.0/24 via 10.13.10.2 dev tun0
client# ip route
default via 192.168.13.1 dev ens160 onlink
10.1.121.0/24 via 10.13.10.1 dev tun0
10.13.10.0/24 dev tun0 proto kernel scope link src 10.13.10.2
192.168.13.0/24 dev ens160 proto kernel scope link src 192.168.13.35
IPTables ничего не блокирует (все установлено на ACCEPT):
client# iptables -L -vn
Chain INPUT (policy ACCEPT 56 packets, 3839 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 40 packets, 4343 bytes)
pkts bytes target prot opt in out source destination
server# iptables -L -vn
Chain INPUT (policy ACCEPT 736 packets, 75398 bytes)
pkts bytes target prot opt in out source destination
2 168 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 4 packets, 236 bytes)
pkts bytes target prot opt in out source destination
1 84 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 449 packets, 43393 bytes)
pkts bytes target prot opt in out source destination
Если я запускаю tcpdump на туннельном интерфейсе, я вижу, что пакеты ICMP исходят от клиента, но не вижу, что они поступают на сервер:
server# ping 192.168.13.35
PING 192.168.13.35 (192.168.13.35) 56(84) bytes of data.
16:57:40.262004 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 1, length 64
16:57:41.269165 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 2, length 64
16:57:42.277154 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 3, length 64
16:57:43.285163 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 4, length 64
client# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
Обе конечные точки — это Ubuntu 16.04 Server LTS (x64, установлены в основном с настройками по умолчанию).
Я думал, что немного разбираюсь в сетях Linux, но... похоже, я ошибался :) . Я понятия не имею, почему это не работает, и у меня закончились идеи, что я мог бы попробовать. Может ли кто-нибудь указать мне правильное направление?
Спасибо!
решение1
Вам может не хватать iroute. Помимо push-маршрутов, вам понадобятся irouteфайлы конфигурации. Вот отрывок из страницы руководства OpenVPN.
--iroute сеть [сетевая маска]
Сгенерировать внутренний маршрут к определенному клиенту. Параметр netmask, если он опущен, по умолчанию равен 255.255.255.255. Эта директива может использоваться для маршрутизации фиксированной подсети от сервера к определенному клиенту, независимо от того, откуда подключается клиент. Помните, что вы также должны добавить маршрут в системную таблицу маршрутизации (например, с помощью директивы --route). Причина, по которой необходимы два маршрута, заключается в том, что директива --route направляет пакет из ядра в OpenVPN. В OpenVPN директива --iroute направляет пакет к определенному клиенту. Этот параметр должен быть указан либо в файле конфигурации экземпляра клиента с помощью --client-config-dir, либо динамически сгенерирован с помощью скрипта --client-connect. Директива --iroute также имеет важное взаимодействие с --push "route ...". --iroute по сути определяет подсеть, которой владеет определенный клиент (мы будем называть этого клиента A). Если вы хотите, чтобы другие клиенты могли достичь подсети A, вы можете использовать --push "route ..." вместе с --client-to-client для этого. Чтобы все клиенты могли видеть подсеть A, OpenVPN должен передать этот маршрут всем клиентам, КРОМЕ A, поскольку подсеть уже принадлежит A. OpenVPN достигает этого, не отправляя маршрут клиенту, если он соответствует одному из маршрутов клиента.
Вам понадобятся записи конфигурации, подобные приведенным ниже, в соответствующих клиенте и серверах.
маршрут 192.168.3.0 255.255.255.0
Кроме того, вам может потребоваться проверка CCD, если у вас несколько сетей за несколькими клиентами.
client-config-dir
Эта директива задает каталог конфигурации клиента, который сервер OpenVPN будет сканировать при каждом входящем подключении, ища файл конфигурации, специфичный для клиента (см. страницу руководства для получения дополнительной информации). Файлы в этом каталоге можно обновлять на лету, без перезапуска сервера. Обратите внимание, что изменения в этом каталоге вступят в силу только для новых подключений, а не для существующих. Если вы хотите, чтобы изменение файла конфигурации, специфичное для клиента, вступило в силу немедленно для подключенного в данный момент клиента (или того, который отключился, но сервер не истечет время ожидания своего объекта экземпляра), уничтожьте объект экземпляра клиента с помощью интерфейса управления (описанного ниже). Это заставит клиента переподключиться и использовать новый файл client-config-dir
решение2
Ответ Fossil был именно тем, что мне было нужно, и я уже принял его. Я просто хотел бы добавить немного информации для других людей, у которых может быть та же проблема. Поскольку вопрос уже задавался на serverfault, но в ответах либо не упоминается iroute (один пример), или иметь только неработающие ссылки (например,Вот этот)
Итак... во-первых, я нашел хорошее объяснение iroute (и зачем он нужен)здесь. Но поскольку я только что упомянул о риске неработающих ссылок, я также постараюсь упомянуть наиболее важные идеи ниже.
Похоже, что маршрутов ядра недостаточно для прохождения трафика через туннель OpenVPN. Если вы хотите достичь локальной сети, которая находится за клиентом OpenVPN, вам также нужен внутренний маршрут OpenVPN (iroute). Он добавляется с помощью оператора client-configuration-dir в server.conf и добавления операторов iroute в файлы конфигурации, размещенные внутри этого подкаталога.
В моем случае мне также понадобилось:
#Inside server.conf
client-configuration-dir my-config-dir
#Inside my-config-dir/client1 (same name as the client!)
#Tell OpenVPN that 192.168.13.0/24 is reachable via client1
iroute 192.168.13.0 255.255.255.0
Это также поднимает интересную проблему - если OpenVPN не может работать, используя только маршруты ядра, на первый взгляд кажется, что невозможно запустить протокол маршрутизации поверх туннелей ovpn. Удалось ли кому-нибудь заставить такое решение (ovpn+rip/ospf) работать?