☰

SSH-Verbindung zum OpenVPN-Cloud-Connector-Computer über VPN-IP nicht möglich

tag-icon • tag-icon linux openvpn linux-networking site-to-site-vpn
SSH-Verbindung zum OpenVPN-Cloud-Connector-Computer über VPN-IP nicht möglich

Ich habe gerade angefangen, OpenVPN-Cloud-Konnektoren zum Erstellen von Mesh-VPN-Netzwerken zu verwenden. Ich habe einen Konnektor bereitgestellt und relevante IP-Weiterleitungs- und NAT-Protokolle eingerichtet, die mir den Zugriff auf das LAN-Netzwerk hinter der Maschine ermöglichen, auf der der OpenVPN-Cloud-Konnektor läuft. Das ist mir erfolgreich gelungen. (Meine Informationen stammen größtenteils von diesem Linkhttps://openvpn.net/cloud-docs/connecting-networks-to-openvpn-cloud-using-connectors/)

Das Problem ist nun, warum ich mich nicht per SSH mit der Maschine verbinden kann, auf der der Cloud Connector über die VPN-IP von läuft 100.96.1.18? Komischerweise kann ich sie problemlos anpingen. Bildbeschreibung hier eingeben

~$ ssh [email protected]
ssh: connect to host 100.96.1.18 port 22: Network is unreachable

~$ ping 100.96.1.18 -c 4
PING 100.96.1.18 (100.96.1.18) 56(84) bytes of data.
64 bytes from 100.96.1.18: icmp_seq=1 ttl=62 time=209 ms
64 bytes from 100.96.1.18: icmp_seq=2 ttl=62 time=279 ms
64 bytes from 100.96.1.18: icmp_seq=3 ttl=62 time=208 ms
64 bytes from 100.96.1.18: icmp_seq=4 ttl=62 time=204 ms

--- 100.96.1.18 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 203.702/224.971/279.214/31.383 ms

Überraschenderweise kann ich mich per Remote-Zugriff (über einen VPN-Client-Computer) per SSH mit dem Connector-Computer verbinden, und zwar über die lokale IP-Adresse von192.168.18.1

Hier sind die IP-Routen auf der Connector-Maschine.

~$ ip route
default via 192.168.18.1 dev eno1 proto dhcp metric 100 
64.120.110.199 via 192.168.18.1 dev eno1 
100.80.0.0/12 via 100.96.1.17 dev tun0 
100.96.0.0/11 via 100.96.1.17 dev tun0 
100.96.1.16/30 dev tun0 proto kernel scope link src 100.96.1.18 
169.254.0.0/16 dev eno1 scope link metric 1000 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
192.168.0.0/24 via 100.96.1.17 dev tun0 
192.168.18.0/24 dev eno1 proto kernel scope link src 192.168.18.88 metric 100 

~$ ifconfig tun0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 100.96.1.18  netmask 255.255.255.252  destination 100.96.1.18
        inet6 fd:0:0:8101::2  prefixlen 126  scopeid 0x0<global>
        inet6 fe80::5a84:3a5:f59b:d64f  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 1682  bytes 451719 (451.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1755  bytes 637526 (637.5 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Auch zum Debuggen sind hier die IP-Routen von einem verbundenen Client-Rechner

~$ ip route
default via 192.168.31.1 dev wlp2s0 proto dhcp metric 600 
25.0.0.0/8 dev ham0 proto kernel scope link src 25.56.7.62 
100.80.0.0/12 via 100.96.1.1 dev tun0 
100.96.0.0/11 via 100.96.1.1 dev tun0 
100.96.1.0/28 dev tun0 proto kernel scope link src 100.96.1.2 
169.254.0.0/16 dev wlp2s0 scope link metric 1000 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.107.213.76 via 192.168.31.1 dev wlp2s0 
192.168.0.0/24 via 100.96.1.1 dev tun0 
192.168.18.0/24 via 100.96.1.1 dev tun0 
192.168.31.0/24 dev wlp2s0 proto kernel scope link src 192.168.31.189 metric 600 

~$ traceroute 100.96.1.18
traceroute to 100.96.1.18 (100.96.1.18), 64 hops max
  1   100.96.1.18  265.200ms !N  109.653ms !N  105.821ms !N

Mein Hauptstreitpunkt besteht darin, dass 100.96.0.0/11 via 100.96.1.1 dev tun0ich, da die Route an den Client gesendet wird, in der Lage sein sollte, die 100.96.1.18IP zu erreichen und per SSH oder Traceroute usw. eine Verbindung dorthin herzustellen.

PS: Ich frage das hier, da der OpenVPN-Support nicht antworten konnte.

Antwort1

Nur für den Fall, dass jemand in dieselben Schwierigkeiten gerät: Dieses Problem hat nichts mit der Firewall auf Ihrer Seite zu tun, da die Verbindung auf der Cloud-Seite unterbrochen wird. Gemäß der OpenVPN-Cloud-Idee verwenden Sie „Netzwerkkonnektoren“, um sich als Client mit einem Netzwerk zu verbinden, und „Hostkonnektoren“, um Clients die Verbindung mit Ihnen zu ermöglichen. Wenn Sie also über die OpenVPN-Cloud eine Verbindung zu Ihrem Server herstellen möchten, muss dieser Server über einen „Hostkonnektor“ und nicht über einen „Netzwerkkonnektor“ mit dem VPN verbunden sein, da nur beim „Hostkonnektor“ die Firewall für eingehende Verbindungen auf der Cloud-Seite geöffnet ist.

Um zu prüfen, ob dies auf Sie zutrifft, stellen Sie sicher, dass Ihr OpenSSH-Server auf allen Schnittstellen (0.0.0.0:22 oder :::22 für IPv6) lauscht, indem Sie „netstat -pan | grep ssh“ verwenden, oder zumindest auf Ihrer VPN-Schnittstelle. Verwenden Sie dann (vorausgesetzt, VPN befindet sich auf der Tun0-Schnittstelle) „tcpdump -pni tun0 tcp port 22“, um zu sehen, ob Sie SSH-Verbindungsanfragen von VPN erhalten. Sie können „Port 22“ löschen und versuchen, Ihren „Server“ anzupingen, um sicherzustellen, dass der Datenverkehr läuft. Normalerweise wird Ihr Ping mit „Network Connector“ durchkommen, aber für SSH-Anfragen wird nichts sichtbar sein, da die Cloud keinen SSH-Datenverkehr zulässt. Wenn Sie die Verbindung über die Cloud mit „Host Connector“ herstellen, funktioniert es.

https://openvpn.net/cloud-docs/owner/servers/hosts/adding-a-host.html

verwandte Informationen