У меня есть сервер OpenVPN, работающий в VPC, и клиент, работающий в офисной сети.
Есть следующая таблица на 24.10.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 через 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 Client 10.24.11.235
И на OpenVPN Server 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 Server 10.2.2.101
и OpenVPN Client 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
на 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
Я не протестировал его, но это - общее представление для решения:
На 10.24.11.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
На 10.24.11.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
В основном необходимо добавить маршруты и позволить соответствующую передачу на всех хостах
позвольте мне высказать одно предположение, что вызывает Вашу проблему, и укажите на Вас, как (надо надеяться), решить его...
я думаю, что Вашей проблемой является "внутренняя маршрутизация" на 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 сервер, это установит это системное правило.
, Надо надеяться, это поможет Вам. Удачи!