Клиентская сеть OpenVPN для доступа к локальной сети сервера
У меня есть сервер OpenVPN, работающий в VPC, и клиент, работающий в офисной сети.
Есть следующая таблица на 10.24.11.37
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.24.11.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 10.24.11.1 0.0.0.0 UG 100 0 0 eth0
Хотеть 10.24.11.37 подключиться к 10.2.1.145, Поэтому я добавил следующие маршруты в 10.24.11.37.
route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.24.11.235
route add -net 10.2.0.0 netmask 255.255.0.0 gw 10.24.11.235
Теперь у меня есть следующая таблица 10.24.11.37
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.0 10.24.11.235 255.255.255.0 UG 0 0 0 eth0
10.24.11.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.2.0.0 10.24.11.235 255.255.0.0 UG 0 0 0 eth0
0.0.0.0 10.24.11.1 0.0.0.0 UG 100 0 0 eth0
Теперь я могу пинговать 10.8.0.2 из 10.24.11.37 Но не могу пинговать 10.2.1.145, 10.8.0.1, 10.2.2.101 из 10.24.11.37
У меня следующие маршруты на 10.24.11.235
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.8.0.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 10.24.11.1 0.0.0.0 UG 202 0 0 eth0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.24.11.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
38.xxx.xxx.291 10.24.11.1 255.255.255.255 UGH 0 0 0 eth0
128.0.0.0 10.8.0.1 128.0.0.0 UG 0 0 0 tun0
С сервера OpenVPN 10.2.2.101 Я могу пинговать 10.8.0.2, но нет 10.24.11.235. Я пытался добавить sudo ip route add 10.24.11.0/24 via 10.8.0.2 dev tun0 на сервер OpenVPN 10.2.2.101. Но это не устранило проблему.
Я отключил проверку источника / назначения для сервера OpenVPN (экземпляр EC2), включил переадресацию IP (net.ipv4.ip_forward = 1) на сервере OpenVPN 10.2.2.101 & Клиент OpenVPN 10.24.11.235
И на сервере OpenVPN 10.2.2.101
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.2.2.1 0.0.0.0 UG 100 0 0 ens5
10.2.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ens5
10.2.2.1 0.0.0.0 255.255.255.255 UH 100 0 0 ens5
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.24.11.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
OpenVPN сервер 10.2.2.101 & Клиент OpenVPN 10.24.11.235 имеет следующие правила брандмауэра
$ sudo iptables -nvL FORWARD
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
ping 10.8.0.2 из 10.24.11.37 не появляется в sudo tcpdump -i tun0 icmp на 10.24.11.235 но появляется в sudo tcpdump -i eth0 icmp на 10.24.11.235
sudo iptables -S на 10.24.11.235
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -s 10.24.11.0/24 -d 10.2.0.0/16 -j ACCEPT
-A FORWARD -s 10.2.0.0/16 -d 10.24.11.0/24 -j ACCEPT
-A FORWARD -s 10.24.11.0/24 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 10.24.11.0/24 -j ACCEPT
-A FORWARD -s 10.24.11.0/24 -d 10.2.0.0/16 -j ACCEPT
-A FORWARD -s 10.2.0.0/16 -d 10.24.11.0/24 -j ACCEPT
sudo iptables -S на 10.2.2.101
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -s 10.24.11.0/24 -d 10.2.0.0/16 -j ACCEPT
-A FORWARD -s 10.2.0.0/16 -d 10.24.11.0/24 -j ACCEPT
-A FORWARD -s 10.2.0.0/16 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 10.2.0.0/16 -j ACCEPT
-A FORWARD -s 10.24.11.0/24 -d 10.2.0.0/16 -j ACCEPT
-A FORWARD -s 10.2.0.0/16 -d 10.24.11.0/24 -j ACCEPT
Какой маршрут мне здесь не хватает?
Обновить :
Когда я пингую 10.8.0.2 из 10.2.1.145 я вижу ICMP echo request/reply на 10.2.2.101 с участием sudo tcpdump -i tun0 -nn icmp.
Но когда я пингую 10.24.11.235 из 10.2.1.145 Я вижу следующее
$ ping -c 1 10.24.11.235
PING 10.24.11.235 (10.24.11.235) 56(84) bytes of data.
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
--- 10.24.11.235 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
На 10.2.2.101 с участием sudo tcpdump -i ens5 -nn icmp :
$ sudo tcpdump -i ens5 -nn icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens5, link-type EN10MB (Ethernet), capture size 262144 bytes
13:36:45.072517 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072544 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072568 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072575 IP 10.2.2.101 > 10.2.2.46: ICMP redirect 10.24.11.235 to host 10.2.2.1, length 92
13:36:45.072576 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072602 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072606 IP 10.2.2.101 > 10.2.2.46: ICMP redirect 10.24.11.235 to host 10.2.2.1, length 92
13:36:45.072700 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072726 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072782 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072803 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072822 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072848 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072894 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072915 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072980 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072983 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073020 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073046 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073087 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073090 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073128 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073145 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073168 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073170 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073194 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073233 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073292 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073341 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073391 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073411 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073432 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073435 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073452 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073475 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073498 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073520 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073540 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073543 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073559 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073584 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073588 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073605 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073609 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073625 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073645 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073665 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073669 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073686 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073704 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073729 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073732 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073749 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073753 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073772 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073792 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073810 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073834 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073837 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073854 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073857 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073892 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073895 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073911 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073934 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073938 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073956 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
Обновление: 18 декабря 2019 г.
я добавил route 10.24.11.0 255.255.255.0 в /etc/openvpn/server.conf и перезапустили openvpn@server. Никаких других изменений конфигурации. Все еще не могу пинговать
Когда я пингую 10.8.0.2 из 10.2.1.145 Я вижу следующее на 10.2.2.101 с участием sudo tcpdump -i tun0 -nn icmp/ sudo tcpdump -i ens5 -nn icmp
17:09:53.076642 IP 10.2.7.61 > 10.8.0.2: ICMP echo request, id 27504, seq 1, length 64
17:09:53.158914 IP 10.8.0.2 > 10.2.7.61: ICMP echo reply, id 27504, seq 1, length 64
17:09:54.077827 IP 10.2.7.61 > 10.8.0.2: ICMP echo request, id 27504, seq 2, length 64
17:09:54.160234 IP 10.8.0.2 > 10.2.7.61: ICMP echo reply, id 27504, seq 2, length 64
Когда я пингую 10.2.1.145 из 10.24.11.37 Я слежу за 10.2.2.101 с участием sudo tcpdump -i tun0 -nn icmp
17:17:01.361549 IP 10.24.11.37 > 10.2.1.145: ICMP echo request, id 24639, seq 0, length 64
17:18:14.451241 IP 10.24.11.37 > 10.2.1.145: ICMP echo request, id 8768, seq 0, length 64
позвольте мне угадать, что вызывает вашу проблему, и указать вам, как (надеюсь) решить ее ...
Думаю, ваша проблема "внутренняя маршрутизация" на сервере openvpn. Как только вы открываете сеанс openvpn на сервере, создается «внутренняя запись маршрутизации», в которой говорится, что 10.8.0.2 доступен через текущий установленный сеанс. Рядом с ним находится "общая" запись маршрутизации системы ОС, в которой говорится, что 10.8.0.0/24 можно повторно использовать через tun0 - openvpn. Эти две информации вместе предоставляют всю необходимую информацию о том, как достичь 10.8.0.2.
Даже если вы разрешили пересылку трафика для 10.24.11.0/24 в системе и направили трафик на tun0 (сеанс сервера openvpn), как только он достигнет «внутренней маршрутизации» openvpn, нет информации, как поступить дальше ...
Чтобы решить эту проблему, вам необходимо использовать опцию CCD (Client Config Dir) на сервере openvpn и создать настраиваемую конфигурацию для клиента, соответствующего 10.8.0.2. Там вы можете добавить "iroute 10.24.11.0 255.255.255.0"запись, которая вызовет установку правила внутренней маршрутизации с установлением сеанса ... Другими словами, как только клиент будет подключен, будет" нормально "созданная запись внутренней маршрутизации для 10.8.0.2 (она работает даже сейчас) и рядом с ней также установит внутреннее правило маршрутизации для 10.24.11.0/24, которое будет направлено через этот сеанс на 10.8.0.2. Это должно быть настроено с использованием ccd, поскольку теоретически 10.8.0.2 не обязательно должен быть статическим, поэтому сервер openvpn должен знать, какой сеанс правильно использовать для маршрутизации трафика ... Более подробную информацию по этой теме вы можете найти, например, в страница с инструкциями по openvpn.
Если вы хотите, чтобы «запись маршрутизации системы ОС» была постоянной, вам следует добавить »route 10.24.11.0 255.255.255.0"в конфигурацию openvpn на стороне сервера - при запуске сервера openvpn он установит это системное правило.
Надеюсь, это вам поможет. Удачи !
Я не тестировал это, но это общая идея решения:
24.10.37:
# Add routes
route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.24.11.235 # this is not mandatory, only if you want 10.24.11.37 to be able to connect to 10.8.0.0/24
route add -net 10.2.0.0 netmask 255.255.0.0 gw 10.24.11.235
24.10.235:
# Add route
route add -net 10.2.0.0 netmask 255.255.0.0 gw 10.8.0.1
# Allow forwarding rules
## this is not mandatory, only if you want 10.24.11.37 to be able to connect to 10.8.0.0/24
iptables -A FORWARD -s 10.24.11.0/24 -d 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -d 10.24.11.0/24 -j ACCEPT
## For access to and from 10.2.1.145 / 10.24.11.37
iptables -A FORWARD -s 10.24.11.0/24 -d 10.2.0.0/16 -j ACCEPT
iptables -A FORWARD -s 10.2.0.0/16 -d 10.24.11.0/24 -j ACCEPT
На 10.2.2.101:
# Add route
route add -net 10.24.11.0 netmask 255.255.255.0 gw 10.8.0.2
# Allow forwarding rules
## this is not mandatory, only if you want 10.2.1.145 to be able to connect to 10.8.0.0/24
iptables -A FORWARD -s 10.2.0.0/16 -d 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -d 10.2.0.0/16 -j ACCEPT
## For access to and from 10.2.1.145 / 10.24.11.37
iptables -A FORWARD -s 10.24.11.0/24 -d 10.2.0.0/16 -j ACCEPT
iptables -A FORWARD -s 10.2.0.0/16 -d 10.24.11.0/24 -j ACCEPT
На 10.2.1.145:
# Add routes
route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.2.2.101 # this is not mandatory, only if you want 10.2.1.145 to be able to connect to 10.8.0.0/24
route add -net 10.24.11.0 netmask 255.255.255.0 gw 10.2.2.101
В основном вам нужно добавить маршруты и разрешить соответствующую переадресацию на всех хостах.