Назад | Перейти на главную страницу

OpenVPN | Как заставить сервер общаться с другим сервером в локальной сети через шлюз OpenVPN?

Я пробовал свой экземпляр EC2 (OMD) для связи с моим LAN-сервером (Raspberry Pi) через другой экземпляр EC2 (OpenVPN), но я не могу заставить его работать.

Сервер OMD может пинговать RPi, но он не может подключиться к нему через SSH, даже если настройки SSH установлены по умолчанию и нет брандмауэра. Но порт 6556 доступен.

Сканирование портов с сервера OMD

[root@omd ~]# nc -zvv 192.168.16.150 6556
Connection to 192.168.16.150 6556 port [tcp/*] succeeded!
[root@omd ~]# nc -zvv 192.168.16.150 22
nc: connect to 192.168.16.150 port 22 (tcp) failed: Connection timed out
[root@omd ~]#

RPi 22 и 6556 открыты для всех, но почему OMD не может подключиться к нему по SSH?

root@rpi:~# netstat -tunlp | egrep "6556|22"
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      535/sshd
tcp        0      0 0.0.0.0:6556            0.0.0.0:*               LISTEN      743/xinetd
tcp6       0      0 :::22                   :::*                    LISTEN      535/sshd
root@rpi:~#

Вот чего я пытался достичь. Пожалуйста, посмотрите это ссылка на сайт.

OpenVPN и RPi связаны друг с другом через VPN-соединение.
OMD не будет подключаться к VPN, он просто будет использовать сервер OpenVPN в качестве шлюза.
OMD будет связываться с RPi через сервер OpenVPN и наоборот.

Не могли бы вы помочь мне с этим?

Пожалуйста, дайте мне знать, если вам понадобится дополнительная информация.

Заранее спасибо, ребята!

AWS - OMD
eth0: 10.0.0.4

=======================
PING
=======================
[root@omd ~]# ping -c 3 192.168.16.150
PING 192.168.16.150 (192.168.16.150) 56(84) bytes of data.
64 bytes from 192.168.16.150: icmp_seq=1 ttl=63 time=100 ms
64 bytes from 192.168.16.150: icmp_seq=2 ttl=63 time=100 ms
64 bytes from 192.168.16.150: icmp_seq=3 ttl=63 time=159 ms    

--- 192.168.16.150 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2159ms
rtt min/avg/max/mdev = 100.072/119.877/159.357/27.917 ms
[root@omd ~]#    
=======================
TRACEROUTE
=======================
[root@omd ~]# traceroute 192.168.16.150
traceroute to 192.168.16.150 (192.168.16.150), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
[root@omd ~]#    
=======================
ROUTE TABLE
=======================
[root@omd ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.16.0    10.0.0.5        255.255.255.0   UG    0      0        0 eth0
172.17.0.0      10.0.0.5        255.255.255.0   UG    0      0        0 eth0
0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 eth0
[root@omd ~]#

AWS - OpenVPN
eth0: 10.0.0.5
tun0: 172.17.0.1

=======================
PING
=======================
[root@openpvn ~]# ping -c 3 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=0.502 ms
64 bytes from 10.0.0.4: icmp_seq=2 ttl=64 time=0.639 ms
64 bytes from 10.0.0.4: icmp_seq=3 ttl=64 time=0.570 ms

--- 10.0.0.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.502/0.570/0.639/0.059 ms
[root@openpvn ccd]# ping -c 3 192.168.16.150
PING 192.168.16.150 (192.168.16.150) 56(84) bytes of data.
64 bytes from 192.168.16.150: icmp_seq=1 ttl=64 time=173 ms
64 bytes from 192.168.16.150: icmp_seq=2 ttl=64 time=142 ms
64 bytes from 192.168.16.150: icmp_seq=3 ttl=64 time=120 ms

--- 192.168.16.150 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 120.684/145.486/173.209/21.546 ms
[root@openpvn ~]#
=======================
ROUTE
=======================
[root@openvpn ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.169.254 0.0.0.0         255.255.255.255 UH    0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.16.0    172.17.0.2      255.255.255.0   UG    0      0        0 tun0
[root@openvpn ~]#
=======================
IPTABLES
=======================
[root@openvpn ~]# cat /etc/sysconfig/iptables
*nat
:POSTROUTING ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -s 172.17.0.0/24 -d 0.0.0.0/0 -o eth0 -j MASQUERADE
COMMIT
[root@openvpn ~]#
=======================
SYSCTL
=======================
[root@openvpn ~]# grep forward /etc/sysctl.conf
# Controls IP packet forwarding
net.ipv4.ip_forward = 1
[root@openvpn ~]#

LAN - Raspberry Pi
eth0: 192.168.16.150
tun0: 172.17.0.253

=======================
PING
=======================
root@rpi:~# ping -c 3 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=63 time=128 ms
64 bytes from 10.0.0.4: icmp_seq=2 ttl=63 time=106 ms
64 bytes from 10.0.0.4: icmp_seq=3 ttl=63 time=126 ms   

--- 10.0.0.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 106.837/120.409/128.312/9.644 ms
root@rpi:~# 
=======================
TRACEROUTE
=======================
root@rpi:~# traceroute 10.0.0.4
traceroute to 10.0.0.4 (10.0.0.4), 30 hops max, 60 byte packets
 1  172.17.0.1 (172.17.0.1)  177.150 ms  200.416 ms  199.949 ms
 2  10.0.0.4 (10.0.0.4)  205.052 ms  216.804 ms  223.456 ms
root@rpi:~# 
=======================
ROUTE TABLE
=======================
root@rpi:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.17.0.1      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.8.1     0.0.0.0         UG    0      0        0 eth1
0.0.0.0         192.168.16.254  0.0.0.0         UG    202    0        0 eth0
0.0.0.0         192.168.8.1     0.0.0.0         UG    203    0        0 eth1
5X.XX.XX.XXX    192.168.8.1     255.255.255.255 UGH   0      0        0 eth1
128.0.0.0       172.17.0.1      128.0.0.0       UG    0      0        0 tun0
172.17.0.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.8.0     0.0.0.0         255.255.255.0   U     203    0        0 eth1
192.168.16.0    0.0.0.0         255.255.255.0   U     202    0        0 eth0
root@rpi:~#

На диаграмме, которую я вижу, указано, что вы используете адаптер tun, что означает маршрутизируемую сеть, а не сеть vpn уровня 2. Вам необходимо, чтобы переадресация IP работала правильно. Кроме того, для вашей ситуации вам также потребуется выполнить NAT на сервере VPN из-за безопасности, задействованной в протоколе ssh, чтобы гарантировать, что трафик идет туда и обратно через одни и те же серверные переходы.

Есть несколько моментов, чтобы это работало. Все нижеприведенное относится к немного старой системе CentOS.

Настройте переадресацию IP на любом компьютере OpenVPN (клиент или сервер), к которому подключена локальная сеть.

vi / etc / sysconfig / network и добавьте строку FORWARD_IPV4 = true
vi /etc/sysctl.conf и измените net.ipv4.ip_forward = 1

Для настройки необходимого NAT, если вы используете iptables для своего брандмауэра, эти команды необходимы на любом компьютере OpenVPN (клиент или сервер), к которому подключена локальная сеть.

iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --table nat --append POSTROUTING --out-interface tun0 -j MASQUERADE

Отключение брандмауэра сломает его. Возможно, вы также можете использовать firewalld, но у меня нет необходимых для этого команд. Также, когда вы удовлетворены правилами iptables, не забудьте сохранить их, чтобы они сохранялись после перезагрузки.

Плюс, чтобы каждый конец VPN знал, как маршрутизировать трафик для LAN на другом конце VPN, чтобы проходить через туннель, необходимый серверу.

строки конфигурации route remote_network подсеть для каждого из удаленных сайтов с подключенной локальной сетью, чтобы локальный сервер знал, как маршрутизировать трафик, предназначенный для этих подсетей, через этот туннель.
строки конфигурации нажать "маршрут сети подсети" поэтому каждый из подключающихся клиентов знает, как направлять трафик через туннель для этих подсетей. Это будет включать в себя серверную локальную сеть и все клиентские локальные сети.
строка конфигурации client-config-dir ccd чтобы сервер знал, что нужно проверять папку / etc / openvpn / ccd на наличие файлов с именами клиентов с локальными сетями в ней
файл ccd / client-name с содержимым подсеть сети iroute поэтому программное обеспечение VPN знает, что когда этот клиент подключается, трафик для этой подсети должен быть отправлен этому клиенту.

Наличие всех этих линий необходимо или, по крайней мере, особенно полезно, когда у вас есть более одной клиентской локальной сети. Когда к одному серверу подключается только один клиент, это намного проще. Единственная LAN-to-LAN - это не намного больше.