07.05.2019

3536

Tunnel Routing durch VPS

Guten morgen,

ich habe mal eine kleine Frage.
Folgendes:

In Neu Seeland habe ich mir mal eine NAT VPS zugelegt. Für 8€ im Jahr wollte ich das mal ausprobieren

Nun das ganze scheint auch so zu laufen. Ich habe den VPS Server nun in einen VPN Tunnel zu meinem Colo Server nach Frankfurt genommen.
Ja natürlich, der Ping ist miserable. Aber gut bei der Entfernung.

Aber darum gehts nicht.
Im Tunnel verwende ich folgendes Subnetz : 10.128.132.0/16

Der VPS bekommt vom Colo Server folgende Route gepushet. 10.0.0.0/24

Das lokale Netz des VPS Servers ist 192.160.64.0/24

Wobei das schon sehr merkwürdig ist. Klasse C Netze ? Naja gut.

Das Ding ist, rufe ich vom VPS durch den Tunnel meine Pfsense auf (10.0.0.1/24) so bekomme ich ein ungültiges SSL Zertifikat angezeigt.
Das ist dann ausgestellt für den Core Router des Rechenzentrums.
Der Support sagte mir, das lokale Subnetz vom Core zum Upstrean ist 10.0.0.0/24

Jetzt Frage ich mich, sind routen durch den Tunnel nicht verschlüsselt und gar nicht ersichtlich für außenstehende.
Die Route dürfte doch dann nur meine Public IP des Servers beinhalten und die Absender IP des VPS .
Oder habe ich einen Denkfehler ?
Vielen lieben dank.

Christian

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 448180

Url: https://administrator.de/contentid/448180

Ausgedruckt am: 22.11.2024 um 04:11 Uhr

9 Kommentare

Neuester Kommentar

Klasse C Netze ?

Klassen gibts schon seit 1993 bei IP Netzen nicht mehr !! Hier lebst du also in der IT Steinzeit als Neandertaler:
https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing.
Warum du ein /16er Prefix in einem Punkt zu Punkt VPN Netz verwendest wollen wir hier besser auch lieber nicht wissen, aber egal...

so bekomme ich ein ungültiges SSL Zertifikat angezeigt.

Was ja normal ist und mit dem IP Routing nicht das Geringste zu tun hat. Die pfSense hat ein selbst signiertes default Zertifikat was in jedem modernen Browser diese Warning triggert !

Das ist dann ausgestellt für den Core Router des Rechenzentrums.

Aber nicht für deine pfSense ! Auf die greifst du ja auch zu und der Browser meckert dann zu Recht das selbst signierte Zertifikat der pfSense an !
Routing technisch ist das sauber. OK, der /16 Prefix ist natürlich Blödsinn, kollidiert ja aber nicht mit dem /24 Netz. Solange beide Netzsegmente einzigartig sind in deinem Konstrukt ist doch alles ok ?!

Jetzt Frage ich mich, sind routen durch den Tunnel nicht verschlüsselt

Oha, die Frage zeigt das du nicht wirklich verstanden hast was Layer 2, Layer 3 ist. Routing ist lediglich für die Wegefindung im IP Netz zuständig, es liest und versteht einzig nur IP Adressen. Was in höheren Layer im IP Paket transportiert wird gescheige denn ob es verschlüsselt ist oder nicht interessiert das Routing nicht die Bohne und weiss es deshalb auch nicht...muss es ja auch nicht, denn für die Wegefindung im IP Netz ist der Paket Inhalt völlig uninteressant !

Oder habe ich einen Denkfehler ?

Ja !
Mal Infos zu Layer 3 Routing lesen und verstehen !
Infos zu VPNs je nach Protokoll mit pfSense und Routing findest du wie immer hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router

Klassen gibts schon seit 1993 bei IP Netzen nicht mehr !!

JA das ist richtig. Ich könnte sagen , das wollte die IHK in der Abschlussprüfung aber heute wissen

Ich arbeite damit tatächlich gerne noch das stimmt.

Warum du ein /16er Prefix in einem Punkt zu Punkt VPN Netz verwendest wollen wir hier besser auch lieber nicht wissen, aber egal...

Ne nicht ganz. Das VPN Netz ist ein /24 aber das Lokale Server Netz ist ein /16
Ja, ist eigentlich überflüssig. Stimmt, ein /24 hätte auch gereicht.

Die pfSense hat ein selbst signiertes default Zertifikat was in jedem modernen Browser diese Warning triggert !

Ja, das weiß ich. Aber das Zertifikat bekomme ich nicht , das ist das Zertifikat vom Core Switch meines Hosters.
Das pfsense Zertifikat erkenne ich ja schon vom Namen. Das ist definitiv nicht meins.

Oha, die Frage zeigt das du nicht wirklich verstanden hast was Layer 2, Layer 3 ist

Nun, das wird nun schwer zu wiederlegen sein oder ?
Openvpn arbeitet doch auf Layer 3 oder ? Ist doch genauso wie IP.

Aber gepuschte Netze vom VPN Server laufen doch durch den Tunnel. Der VPS Server kennt doch das Netz hinter dem Gateway garnicht. Ist NAT.
Also dürfte das Gateway dahinter als Absender nur meinen Server und als Empfänger den Dedicated Server sehen. Aber doch nicht meine lokale Route.

Vielen Dank

Ich arbeite damit tatächlich gerne noch das stimmt.

Was aber per se falsch ist. Auch wenn die IHK bekanntlich noch in der IT Steinzeit lebt ! Aber egal...

Ne nicht ganz. Das VPN Netz ist ein /24 aber das Lokale Server Netz ist ein /16

Dann hast du aber gelogen in deiner Beschreibung ! Zitat: "Im Tunnel verwende ich folgendes Subnetz : 10.128.132.0/16"
Das besagt ja eindeutig das dein Tunnelnetz ein /16er ist. Wenn wir alle hier aneinander vorbeireden und/oder falsche Angaben machen wird eine zielführende Lösung unmöglich.

Stimmt, ein /24 hätte auch gereicht.

Ein /29 hätte gereicht !

Das pfsense Zertifikat erkenne ich ja schon vom Namen. Das ist definitiv nicht meins.

Aber du kannst und solltest dir auch ein eigenes erzeugen !! Siehe hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

Nun, das wird nun schwer zu wiederlegen sein oder ?

Kommt drauf an...

Openvpn arbeitet doch auf Layer 3 oder ? Ist doch genauso wie IP.

Wenn man es nach Standard konfiguriert ja. Es kann auch Bridging aber das sollte man wie immer besser lassen !
Also ja, OVPN routet.

Aber gepus(c)hte Netze vom VPN Server laufen doch durch den Tunnel.

Ja das ist richtig ! Diese Netze werden in der Client Seite in die Routing Tabelle geschrieben. Das kannst du bei einem Winblows Client z.B. mit route print sehen. Ist der Client eine pfSense sieht man es dort auch über die Routing Tabelle unter Diagnostics.

Der VPS Server kennt doch das Netz hinter dem Gateway garnicht. Ist NAT.

Wenn er nicht selber VPN Client ist, dann nicht. Aber dafür hat er ja eine Default Route auf das gateway was es dann kennt.
Ist der VPS Server selber VPN Client kennt er dieses Netz sehr wohl, denn es wird ihm ja dann per Push Kommando in die Routing Tabelle geschrieben.
OVPN Grundlagen auch hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router

Hi,

ja, wir reden dann wirklich aneinander vorbei.

Tut mir leid.

Ja Openvpn Routet bei mir. Bridging habe ich damals probiert aber das hat nie so richtig geklappt.

Ich versuche mich mal deutlicher auszudrücken.

VPS Server --- -------------Router (provider) --------------------- Internet -- Mein Sever
IP 192...------------------192.... NAT. 10.0.0.1 Router ---_---------------------------10.128.132.0/16 VPN Netz
VPN IP 10.128.132.X. ----- < - 10.0.0.1 Server Netz

Der VPN Server pushet die Route 10.0.0.0/24 auf den VPS Server, der als VPN Client arbeitet.
Der Core switch hat hinter dem 192. Netz die Route 10.0.0.0 , welche der VPS Server doch gar nicht sieht.
Ist ja nicht in seinem Netz.

Also Frage ich mich, wie der Server das Netz 10.0.0.0 hinter dem Core Switch entdeckt und mir ein falsches SSL Zertifikat ausgibt. Die Route verläuft doch gar nicht durch das default Gateway.

Vielen Dank.

aber das hat nie so richtig geklappt.

Kein Wunder. Bridging ist immer ein NoGo bei VPNs.

Der VPN Server pushet die Route 10.0.0.0/24 auf den VPS Server

Das hast du ganz sicher verifiziert mit route print (Winblows) oder netstat -r -n bzw. ip route show (unixoide OS, Linux etc.) ??

Der Core switch hat hinter dem 192. Netz die Route 10.0.0.0

Der taucht in deiner Skizze (die man nicht wirklich lesen kann

) oben ja gar nicht auf !!
Ist das ein Layer 3 Switch, also einer der routet ??

Also Frage ich mich, wie der Server das Netz 10.0.0.0 hinter dem Core Switch entdeckt

Das kann er natürlich nur wenn er eine entsprechende Route in dieses Netzwerk hat ! Sonst erreicht er es logischerweise nicht.
Deine Netzwerkskizze ist etwas unverständlich oben. Ggf. hilft da eine bessere Skizze ohne ASCII Text für einen besseren Durchblick ?!

Aha,

och glaube ich weiß was du meinst.

Die Route hinter dem Core Switch kenne ich natürlich nicht. Der Support sagte mir nur, das die Route existiert.

Wenn die natürlich in der Routing Tabelle vorher drin stand ist es klar.
Ist ja ein OpenVZ Container.

Danke für den Tipp.
Ich teste das heute abend mal.

VG
Christian

Der Support sagte mir nur, das die Route existiert.

Vertrauen ist gut, Kontrolle ist besser !!!
Traceroute ist hier wie immer dein bester Freund...

Ich teste das heute abend mal.

Wir sind gespannt...!

Nabend zusammen,

entschuldige die Verspätung. Der Urlaub war dazwischen.

Ich habe mal die Routing Tabelle gecheckt.
Ohne VPN Tunnnel habe ich nur die default Route eingetragen.
Allerdings kann ich die Adresse 10.0.0.1 tatächlich aus der VM heraus Pingen.
Da scheint eine Route hinter dem Gateway zu existieren.

Eine Traceroute bringt hier leider nichts, da der letzte Hop die IP des Hypervisors und damit Public ist.
Ich vermute da hängt ein Management Netz virtuell auf dem Server. Lustig nur, das ich als Kunde da rein darf.