Рейтинг:0

OpenVPN: Can't route to private network once connected to VPN tunnel

флаг cm

I'm trying to setup an OpenVPN server to allow tunnelling to a private network (192.168.0.0/16) but when my VPN client is connected it cannot reach hosts on this network. No firewall is currently setup for the network/all ports are open. The server running OpenVPN is assigned the IP 192.168.0.2 on the private network

server.conf

local 1.2.3.4
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
server-ipv6 fddd:1194:1194:1194::/64
push "redirect-gateway def1 ipv6 bypass-dhcp"
push "route 192.168.0.0 255.255.0.0"
push "dhcp-option DNS 10.8.0.1"
ifconfig-pool-persist ipp.txt
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify

client.ovpn

client
dev tun
proto udp
remote 1.2.3.4 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
<ca>
REDACTED
</ca>
<cert>
REDACTED
</cert>
<key>
REDACTED
</key>
<tls-crypt>
REDACTED
</tls-crypt>

Client connected to the OpenVPN server can ping the OpenVPN gateway as well as using its IP on the other subnet. However it can't ping a different host on the same network...

[26/10/21 19:58:32] user@client:~$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=27.3 ms
^C
--- 10.8.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.276/27.276/27.276/0.000 ms
[26/10/21 19:58:49] user@client:~$ ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=27.3 ms
^C
--- 192.168.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.271/27.271/27.271/0.000 ms
[26/10/21 19:58:52] user@client:~$ ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data.
^C
--- 192.168.0.3 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

OpenVPN server can ping a different host on the same network...

root@server:~# ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data.
64 bytes from 192.168.0.3: icmp_seq=1 ttl=63 time=1.26 ms
^C
--- 192.168.0.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.262/1.262/1.262/0.000 ms

OpenVPN server route table...

root@server:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.31.1.1      0.0.0.0         UG    100    0        0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
172.31.1.1      0.0.0.0         255.255.255.255 UH    100    0        0 eth0
192.168.0.0     192.168.0.1     255.255.255.0   UG    0      0        0 ens10
192.168.0.1     0.0.0.0         255.255.255.255 UH    0      0        0 ens10

192.168.0.3 routing table...

root@server:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
_gateway        0.0.0.0         255.255.255.255 UH    100    0        0 eth0
192.168.0.0     192.168.0.1     255.255.0.0     UG    0      0        0 ens10
192.168.0.1     0.0.0.0         255.255.255.255 UH    0      0        0 ens10

Any help is appreciated.

Thanks.

Nikita Kipriyanov avatar
флаг za
Пожалуйста, покажите маршрутизацию на хостах, отличных от `192.168.0.2`. Также покажите таблицу маршрутизации в системе, которая установлена ​​в качестве шлюза по умолчанию для этих хостов (возможно, `192.168.0.1`). Кроме того, *никогда не используйте `route`*, это древнее слово, вводящее в заблуждение и на самом деле трудночитаемое. Сразу удалите `net-tools` (кстати, Debian 10 и 11 уже идут по умолчанию без этого пакета, так что это, конечно, не обязательно). Всегда используйте `ip route` и другие функции `iproute2`, которые являются правильным способом настройки и работы с "современным" (около 2000 года) сетевым стеком Linux.
Nikita Kipriyanov avatar
флаг za
Испорчу мысль: я подозреваю, что с путем от 10.8.х.х до 192.168.0.х все в порядке, а вот в обратном направлении какие-то проблемы. Это обратные пакеты, которые не могут быть доставлены, а не перенаправлены.
Mark Hingston avatar
флаг cm
Спасибо @NikitaKipriyanov. Я обновил свой вопрос таблицей маршрутизации для 192.168.0.3. Замечание по поводу использования `ip route`. Я не уверен, как обновить таблицу маршрутизации для хостов в локальной сети для этой конфигурации.
Nikita Kipriyanov avatar
флаг za
Как правило, вы запускаете службу VPN *на маршрутизаторе*, который, например, является шлюзом по умолчанию для какой-либо локальной сети. Или на другом маршрутизаторе, но тот, который является шлюзом, должен иметь через него выделенный маршрут к VPN. // И вы все еще использовали маршрут.Убейте эту привычку огнем, это хуже курения. Серьезно, Docker был бы невозможен без функциональности ip route, потому что утилита route ничего не знает о пространствах имен, на которых построен Docker. ifconfig, route, iptunnel, tunctl, brctl, vconfig — все они были заменены и больше не должны использоваться.
Рейтинг:1
флаг bq

Интернет-протокол смотрит только на IP-адрес назначения при маршрутизации пакетов. Им все равно, откуда пришел пакет. Им все равно, что пакет может быть частью более крупного сеанса, соединения или приложения. Единственное, что имеет значение, это IP-адрес назначения. Затем IP просматривает таблицу маршрутизации, чтобы определить, что делать с каждым пакетом, основываясь исключительно на адресе назначения. (Технически, такие вещи, как брандмауэры с отслеживанием состояния и контроль маршрутизации, могут сделать это ложью, но для текущих целей это подойдет.)

Как указывает @Nikita, и вывод маршрут(8) шоу, ведущие лайкают 192.168.0.3 (и, предположительно, другие хосты в вашей сети) могут отправлять пакеты только на ваш маршрутизатор 192.168.0.1. Им нечего сказать им, чтобы отправлять пакеты в вашу систему OpenVPN по адресу 192.168.0.2.. Так .3 и друзья будут отправлять весь свой трафик на ваш роутер. Ваш маршрутизатор не знает о вашем VPN. Ваш маршрутизатор либо отбрасывает пакеты, либо отправляет их в общедоступный Интернет (где маршрутизатор следующего перехода, скорее всего, отбросит их).

Есть несколько возможных решений.

Решение №1 — простое, но неэффективное

Скажите своему маршрутизатору, что 10.8.0.0/24 доступен через шлюз в 192.168.0.2. Это приведет к шпилечному маршруту — пакеты будут отправляться с таких хостов, как .3, к интерфейсу LAN вашего маршрутизатора по адресу .1, а затем вернитесь к тому же интерфейсу маршрутизатора и к шлюзу OpenVPN по адресу .2. Это неэффективно, но должно работать.

Вы не говорите, какой у вас роутер, но если бы это был Linux, команда была бы примерно такой:

ip маршрут добавить 10.8.0.0/24 через 192.168.0.2

Решение № 2 — Ненавязчиво, но утомительно

Вы можете настроить статический маршрут на каждом хосте локальной сети, сообщая им тот же самый лакомый кусочек маршрутизации, что и № 1, но везде. Это было бы незначительной проблемой для настройки и обслуживания, но это было бы наиболее эффективным решением, сохраняющим существующую топологию сети. Та же команда, что и выше (для Linux), но вы должны запустить ее на каждом хосте локальной сети. Вам также необходимо сделать это на всех других устройствах, которые должны работать через VPN, включая коробки Windows, принтеры, планшеты, телефоны, лампочки Wi-Fi и т. д. В конце концов вы забудете одно и удивитесь, почему оно не работает, потратив время на волосы, а потом чувствуешь себя наркоманом, когда вспоминаешь, почему.

Решение № 3 — сложное, но разрушительное

Вы можете поместить свой VPN-шлюз на путь маршрутизации в Интернет. Здесь есть две подальтернативы.

Решение № 3A — VPN на маршрутизаторе

В наши дни даже потребительские маршрутизаторы иногда могут запускать реализацию OpenVPN, особенно если вы используете стороннюю прошивку (OpenWRT, DD-WRT и т. д.). Однако им часто не хватает мощности процессора для адекватной производительности. Вы также можете заменить потребителя чем-то лучшим — коммерческим маршрутизатором или другим Linux. Возможно, вы даже сможете переназначить свой VPN-шлюз как VPN+маршрутизатор+брандмауэр.

В этом сценарии VPN и маршрутизатор — это одно и то же, поэтому вам не нужно беспокоиться о том, что маршрутизатор взаимодействует с VPN-шлюзом. Это, вероятно, наиболее эффективный с точки зрения дизайна сети.

Решение № 3B — шлюз стека и маршрутизатор

Вы можете разместить VPN-шлюз между маршрутизатором и остальной частью локальной сети с разными IP-подсетями по обе стороны от VPN-шлюза. Все остальные узлы локальной сети отправляют данные на шлюз VPN, чтобы получить доступ в Интернет. Шлюз VPN отправляет и перенаправляет на маршрутизатор, чтобы получить доступ к Интернету.

Это потребует размещения двух сетевых интерфейсов в VPN-шлюзе — один для локальной сети и один для передачи обслуживания маршрутизатору. (Или сделать шпильку на VPN-шлюзе, что хуже, чем № 1, потому что теперь все Интернет-трафик зашкаливает).

Основные преимущества такого подхода: Вы можете оставить свой существующий маршрутизатор (возможно, ваш интернет-провайдер заставляет вас использовать свое оборудование, может быть, у него есть какие-то другие полезные для вас свойства). Если блок VPN сломается, вы можете вытащить его из картины и (возможно) быстро перенастроить маршрутизатор, чтобы он занял его место.

Mark Hingston avatar
флаг cm
Очень полезно спасибо
Ben Scott avatar
флаг bq
@MarkHingston: я рад, что вы нашли это полезным. Если вам нужна дополнительная помощь, добавьте подробности в комментарии и/или измените свой вопрос. Если вы считаете, что ваш вопрос решен, [примите ответ] (https://stackoverflow.com/help/someone-answers).

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.