fundave3
Goto Top

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 face-smile

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. face-smile

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

Content-Key: 448180

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

Printed on: April 19, 2024 at 01:04 o'clock

Member: aqui
aqui May 07, 2019 updated at 18:35:01 (UTC)
Goto Top
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
Member: fundave3
fundave3 May 08, 2019 updated at 18:48:41 (UTC)
Goto Top
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 face-smile
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
Member: aqui
aqui May 09, 2019 at 06:37:01 (UTC)
Goto Top
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. face-sad
Stimmt, ein /24 hätte auch gereicht.
Ein /29 hätte gereicht ! face-wink
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... face-wink
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
Member: fundave3
fundave3 May 11, 2019 updated at 14:57:25 (UTC)
Goto Top
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.
Member: aqui
aqui May 11, 2019 updated at 15:28:42 (UTC)
Goto Top
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 face-sad ) 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 ?!
Member: fundave3
fundave3 May 13, 2019 at 10:39:56 (UTC)
Goto Top
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
Member: aqui
aqui May 13, 2019 at 10:52:52 (UTC)
Goto Top
Der Support sagte mir nur, das die Route existiert.
Vertrauen ist gut, Kontrolle ist besser !!!
Traceroute ist hier wie immer dein bester Freund... face-wink
Ich teste das heute abend mal.
Wir sind gespannt...! face-wink
Member: fundave3
fundave3 May 19, 2019 at 17:05:21 (UTC)
Goto Top
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. face-smile
Member: aqui
aqui May 20, 2019 at 15:06:35 (UTC)
Goto Top
Der Urlaub war dazwischen.
Du Glücklicher !! face-smile
Lustig nur, das ich als Kunde da rein darf
Gruselig...da hat einer geschlampt !