Клиентская сеть OpenVPN для доступа к локальной сети сервера

У меня есть сервер OpenVPN, работающий в VPC, и клиент, работающий в офисной сети.

enter image description here Есть следующая таблица на 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
1
задан 3 December 2019 в 20:38
2 ответа

Я не протестировал его, но это - общее представление для решения:

На 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

В основном необходимо добавить маршруты и позволить соответствующую передачу на всех хостах

0
ответ дан 4 December 2019 в 02:33

позвольте мне высказать одно предположение, что вызывает Вашу проблему, и укажите на Вас, как (надо надеяться), решить его...

я думаю, что Вашей проблемой является "внутренняя маршрутизация" на 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 сервер, это установит это системное правило.

, Надо надеяться, это поможет Вам. Удачи!

0
ответ дан 4 December 2019 в 02:33

Теги

Похожие вопросы