Ping von Linux-Server auf VPN-Client nicht möglich

[Datax]

Hallo,

benötige einmal Eure Hilfe bei einem Netzwerkproblem.

Ich habe auf einem Linux-Server einen OpenVPN-Server installiert.

Ein Linux-System mit "Linux Mint v19" kann sich problemlos über das Internet per OpenVPN-Client
bei dem OpenVPN-Server "einwählen" und bekommt dann auf der Schnittstelle "tun0" die IP-Adresse 10.242.2.2 zugewiesen.

Dieses Linux-System hat noch eine weitere Schnittstelle (eth0) mit der IP-Adresse 192.168.2.1.

Vom Linux-Server (tun0=10.242.2.1), auf dem der OpenVPN-Server läuft,
möchte ich gerne einen Ping auf die eth0-IP-Adresse des "Linux Mint"-Systems (192.168.2.1) machen.

Dies funktioniert jedoch nicht;
wenn ich also auf dem Linux-Server einen Ping auf die 192.168.2.1 (eth0-Adresse des "Linux Mint"-Systems)
bekomme ich keine Antwort zurück.

Auf dem Linux-Server habe ich bereits eine statische Route für das 192.168.2.0/24-Netz angelegt:
route add -net 192.168.2.0/24 gw 10.242.2.2 (VPN-IP-Adresse des VPN-Clients)

Die VPN-IP-Adresse des "Linux Mint"-Systems (10.242.2.2) ist übrigens statisch,
es bekommt also auf "tun0" bei jeder VPN-Einwahl die gleiche VPN-IP zugewiesen.

Auf dem "Linux Mint"-System habe ich außerdem natürlich das Routing im Kernel aktiviert:
echo 1 > /proc/sys/net/ipv4/ip_forward

Leider bekomme ich wie gesagt keine Antwort zurück,
wenn ich vom Linux-Server die 192.168.2.1 anpinge.

Wenn ich die VPN-IP des "Linux Mint"-Systems vom Linux-Server aus anpinge
(die 10.242.2.2), dann bekomme ich jedoch eine Antwort zurück.

Weiß im Moment nicht,
was genau die Ursache für dieses Problem ist.

Für mich ist es ein Routing-Problem,
jedoch bin ich in der Hinsicht kein Experte in Sachen Fehlersuche...

Kann mir da jemand weiterhelfen?

Gruß, Datax

 

[burglar2k18]

Bei Routing-Problemen würde ich erstmal Traceroutes machen :-)

 

[Datax]

Ja, das habe ich auch bereits gemacht.

Wenn ich ein "traceroute 192.168.2.1" auf dem Linux-Server mache,
dann bekomme ich etliche "Hops" angezeigt,
wo ausschließlich Sternchen (*) angezeigt werden.

Ist das eventuell eine Loop (eine Routing-Schleife)!?

Die Ping-Requests kommen auf jeden Fall nicht bei dem "Linux Mint"-System an,
das habe ich ebenfalls bereits mit "tcpdump" überprüft.

Der Befehl dazu auf dem "Linux Mint"-System:
tcpdump -i tun0 -n icmp

Gruß, Datax

 

[Juppi2016]

Das es per Default nicht geht sollte ja klar Sein. Der PC baut schließlich mit dem Netzwerk des Servers ein VPN auf und nicht umgekehrt. Wenn du die zweite Netzwerkkarte des Servers pingst, dann sollte das beispielsweise funktionieren.

Damit der Server eth0 vom PC pingen kann, kannst du mal versuchen eine Statische Route auf dem PC einzutragen.

 

[Datax]

Das es per Default nicht geht sollte ja klar Sein. Der PC baut schließlich mit dem Netzwerk des Servers ein VPN auf und nicht umgekehrt.

Keine Ahnung, was du mir damit sagen möchtest.

Wenn das "Linux Mint"-System eine VPN-Verbindung zum Linux-Server aufgebaut hat,
dann hat dieses selbst eine IP-Adresse auf "tun0" im Netzwerk des VPN-Pools (10.242.2.0/24).

Somit befindet sich das "Linux Mint"-System mit einem "Beinchen" im VPN-Netz (tun0)
und ist über die VPN-IP direkt vom Linux-Server aus erreichbar.

Was soll mir da eine statische Route auf dem PC bringen,
wenn dieser bereits eine Route in das VPN-Netz hat,
aus dem der Ping-Befehl ja schließlich abgesetzt wird!?

Der Ping-Befehl hat die Quell-IP-Adresse 10.242.2.1 und die Ziel-IP-Adresse
ist die 192.168.2.1 des "Linux Mint"-Systems.

Das "Linux Mint"-System hat auf "tun0" wie gesagt die 10.242.2.2 und hat somit
natürlich auch eine (Rück)route in das VPN-Netz (10.242.2.0/24).

Es gibt also bereits eine Route für den Rückweg.

Was soll da eine weitere statische Route bringen???

Wie sollte dieses statische Route deiner Meinung nach aussehen?

Auf dem Linux-Server gibt es wie bei #1 erwähnt eine statische Route in das 192.168.2.0/24-Netz
auf die VPN-IP des "Linux Mint"-Systems. Somit weiß der Linux-Server über welches Gateway
er die 192.168.2.1 erreichen kann.

Gruß, Datax

 

[Raijin]

Check mal die Firewall bzw iptables. Darüber hinaus würde ich mittels tcpdump schauen ob nu die Antwort nicht zurück kommt oder ob der ursprüngliche Ping gar nicht erst ankommt..

 

[Datax]

Auf der Firewall bzw. dem Linux-Server sehe ich den Ping-Request auf dem "tun0"-Interface.

Auf dem "Linux Mint"-System, das per VPN eingeloggt ist (IP=10.242.2.2), sehe ich diese Ping-Requests
per tcpdump auf "tun0" jedoch schon nicht mehr.

Das ist echt merkwürdig.

Werde ich mir heute Abend bei Zeit oder die Tage nochmal anschauen.

Gruß, Datax

 

[Juppi2016]

Kannst du uns mal mir die Routingtabellen der beiden Rechner schicken?

Denke mal es braucht eine Route, die alles von tun0 (VPN) zu eth0 schickt.

Gibt mal auf dem Server ein:
ip route add 192.168.2.0/24 via tun0

Und auf dem Mint PC:
ip route add 192.168.2.0./24 via eth0

 

[Datax]

Hi,

hier die Routing-Tabelle des Linux-Servers:

Destination Gateway Genmask Flags Metric Ref Use Iface
10.242.2.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
192.168.2.0 10.242.2.2 255.255.255.0 UG 5 0 0 tun0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

Das 192.168.2.0/24-Netz gibt es bereits eine (statische) Route,
die ich selbst hinzugefügt hatte, die per "tun0"-Schnittstelle behandelt wird.

Und hier die Routing-Tabelle des "Linux Mint"-Systems:

Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.43.1 0.0.0.0 UG 100 0 0 ens33
10.242.2.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 ens33
192.168.2.0 0.0.0.0 255.255.255.0 U 101 0 0 ens37
192.168.10.0 10.242.2.1 255.255.255.0 UG 0 0 0 tun0
192.168.43.0 0.0.0.0 255.255.255.0 U 100 0 0 ens33

Wie gesagt kann ich die Ping-Requests,
die ich vom Linux-Server losschicke, auf "tun0" des "Linux Mint"-Systems nicht sehen.

Auf dem Linux-Server pinge ich mit folgendem Befehl:
ping 10.242.2.2 (VPN-IP des "Linux Mint"-Systems)

Auf dem "Linux Mint"-System mache ich einen "tcpdump" mit folgendem Befehl:
tcpdump -i tun0 -n icmp

Der "tcpdump" zeigt keinen einzigen Ping-Request ... ich weiß nur nicht,
warum dort nichts hingeroutet wird...

Wäre cool, wenn ihr mir noch einen Tipp geben könntet.

Habe mich bis gerade noch daran versucht,
aber bin weiterhin bei dem Stand von gestern.

Das "Linux Mint"-System hat übrigens auch eine direkte Route in das 192.168.2.0/24-Netz,
weil es ja selbst eine IP-Adresse in diesem Netz hat (siehe auch Routing-Tabelle des "Linux Mint"-Systems oben):

192.168.2.0 0.0.0.0 255.255.255.0 U 101 0 0 ens37

Diese Route wird ja vom Linux-Kernel direkt angelegt,
nachdem man die betreffende Netzwerkschnittstelle (in diesem Fall heißt sie "ens37") konfiguriert hat
(Festlegen der IP-Adresse + Subnetzmaske).

Gruß, Datax

 

[Raijin]

Am besten machst du immer Screenshots von den Ergebnissen. Routing-Tabelle, tcpdump und iptables (s.u.). Bei copy&paste geht jedwede Formatierung verloren (sofern der output überhaupt formatiert ist) und bei frei beschriebenen Resultaten gehen unter Umständen Informationen verloren. Daher bitte immer vollständige Screenshots posten.

Beim tcpdump wäre zB interessant gewesen von welcher Quell-IP der Ping losgeschickt wurde.

Kannst du bitte noch den output von iptables -vnL posten? Evtl wird der Ping ja hier bereits geblockt.

 

[Datax]

Der Ping wurde von der Quell-IP-Adresse des OpenVPN-Servers auf dem Linux-Server verschickt.

Das ist die 10.242.2.1.

Aber ich schicke vermutlich heute Abend mal Screenshots (tcpdump, iptables-output, ping-Befehl).

Gruß, Datax

 

[Datax]

So, habe das Ganze gerade nochmal durchgetestet und Screenshots gemacht.

Hier der Ping von der Firewall (Linux-Server) aus:

Passend dazu der "tcpdump" auf der Schnittstelle "tun0" auf der Firewall:

Und hier noch der "tcpdump" zur gleichen Zeit auf dem "Linux Mint"-System:

Hier noch der "iptables"-Output vom "Linux Mint"-System:

Den "iptables"-Output habe ich als Datei-Anhang mitgeschickt,
die Ausgabe von "iptables" passte nicht in einen Screenshot...

Kann mir da weiterhin keinen Reim drauf machen.

Bei Rückfragen etc. gerne bei mir melden und natürlich bei weiterhelfenden Infos...

Gruß, Datax

Ergänzung (14. Dezember 2018)

So, und hier noch nachgereicht die Routing-Tabellen von der Firewall sowie des "Linux Mint"-Systems.

Routing-Tabelle der Firewall:

Routing-Tabelle des "Linux Mint"-Systems:

Gruß, Datax

 

[Raijin]

Scheiß die Wand an... Die iptables muss ich morgen mal in aller Ruhe am PC durchschauen, am Smartphone ist das nicht lesbar

 

[Datax]

Ja, das hatte ich mir schon gedacht.

An der Firewall habe ich nur sehr wenig konfiguriert.

Fast alle alle dieser iptables-Regeln werden von der Firewall (Sophos UTM) automatisch im Hintergrund erstellt.

Gruß, Datax

 

[Datax]

Hat noch jemand eine Idee zu meinem Problem?

Gruß, Datax

 

[Juppi2016]

Häng mal den 192.168.43.1 Anschluss irgendwo dran. Vllt. liegt es da dran, dass es nicht funkt.

 

[Datax]

Habe in der Zwischenzeit eine andere Lösung für mein Problem gefunden.

Habe mich mal mit der VPN-Lösung "WireGuard" beschäftigt,
die schnell und sicher sein soll.

Hier mal ein Link dazu:
https://www.stavros.io/posts/how-to-configure-wireguard/

Habe mein Test-Netzwerk dafür verwendet und einen WireGuard-Server sowie einen WireGuard-Client aufgesetzt.

Der WireGuard-Client hat nach dem Herstellen der VPN-Verbindung auch problemlos Zugriff auf das LAN hinter dem WireGuard-Server (das "Forwarding" muss natürlich dafür aktiviert sein).

Des Weiteren habe ich mit einer MASQUERADING-Regel gearbeitet,
weshalb keinerlei statische Routen nötig waren.

Der Umstand, dass die Geräte im LAN die echte Quell-IP-Adresse des VPN-Clients (die VPN-IP-Adresse) nicht sehen können, ist in diesem Fall unerheblich.

Wie gesagt, die Lösung funktioniert perfekt und mein Vorhaben konnte ich damit genau so umsetzen wie ich es vorhatte.

Bei der Konfiguration des OpenVPN-Servers und / oder des OpenVPN-Clients muss ich wohl Fehler gemacht haben. Konnte nur leider nicht herausfinden, was genau falsch konfiguriert war, aber das ist nicht so schlimm.

Vielen Dank für Eure Unterstützung.

Muss ich diesen Thread irgendwo auf "erledigt" bzw. "geschlossen" setzen?

Gruß, Datax

 

[Datax]

So, und jetzt habe ich das OpenVPN-Problem selbst auch gelöst.

Habe mit gleichem Aufbau des Test-Netzes wie bei dem WireGuard-Projekt auch die OpenVPN-Lösung ans Laufen bekommen so wie ich es zu Beginn des Threads ursprünglich vor hatte.

In der OpenVPN-Config des Servers und/oder des Clients muss was falsch gewesen sein.

Habe alles komplett neu eingerichtet und es lief auf Anbieb.

Gruß, Datax

 

[Juppi2016]

Gut zu hören!