[Frage] Wireguard VPN mit IPV4 oder IPV6

[frank_m24]

Wireguard läuft auf einen Pi hinter der Fritzbox 192.168.178.1 mit der ip 192.168.178.2?

Schön, dass du wieder einen Fall konstruierst, der gar nichts mit der Ausgangsfrage zu tun hat. Das war ja auch dein Problem im anderen Thread, wo der Fragesteller eine hervorragende Lösung von dir bekommen hat - wenn er sich davon hätte überzeugen lassen, sein Haus zuweilen mit ins Ausland zu nehmen. Da sich herausgestellt hat, dass er sein Haus überwiegend stationär betreibt, führte der Lösungsansatz leider ins Leere.

Beziehen wir die Antwort auf die Frage dieses Threads: Du baust eine VPN Verbindung zur öffentlichen IPv4 Adresse der Fritzbox auf, wofür kein NAT erforderlich ist, da es ja eine öffentliche Adresse ist. Dein VPN Client bei der Fritzbox bekommt eine IP aus dem lokalen Netz der Box, da AVM ja Proxyarp macht, üblicherweise 192.168.178.201. Von dieser Adresse greifst du dann - ganz ohne NAT - auf die 192.168.178.25 des Enigma Receivers zu. Exakt so sähe es aus, wenn Box und Client eine IPv6 Adresse hätten - nur der Protokolloverhead wäre ein wenig höher, da IPv6 längere Header benutzt. Und exakt so wäre es auch, wenn du in deinem Heimnetz und für den VPN Tunnel IPv6 nutzen würdest, in dem Fall nutzt die Fritzbox ULA Adressen, die in der Praxis ähnliche Eigenschaften haben, wie private IPv4 Adressen. Jedenfalls erfolgt der Zugriff auf die Heimnetz-Ressourcen dann auch innerhalb eines Subnetzes, ohne NAT und ohne Routing.

Gehen wir von deinem Fall aus: der VPN Server ist nicht die Fritzbox, sondern im Netz dahinter. Genau deshalb hatte ich oben danach gefragt, um das auszuschließen. Aber wenn es so wäre, dann könnte man per IPv6 tatsächlich direkt auf den VPN Server zugreifen, während man für IPv4 eine Portweiterleitung braucht - also NAT. Ist aber nicht Gegenstand dieses Threads, und damit erübrigen sich alle Hinweise auf Vorteile, die man ggf. dadurch hätte.

Bleibt der Fall mit den IPv6-only Zugangsnetzen. Das kann sicherlich früher oder später passieren, besonders, wenn man im asiatischen Raum unterwegs ist. Im Moment ist das noch kein relevantes Problem, ich hab auch in asiatischen Ländern wie Japan oder China bislang immer noch IPv4 Adressen bekommen, wenn auch private. Aber das könnte zukünftig ein Grund dafür sein, Dual-Stack einzurichten.

 

[Insti]

Dein VPN Client bei der Fritzbox bekommt eine IP aus dem lokalen Netz der Box

Gibt es Adressänderungen bei Proxy ARP?

Oder besser gefragt, wie wird das genannt was die Fritzbox da macht auch wenn es kein RaspberryPi als Wireguard Server im Heimnetz gibt?

 

[Novize]

Wireguard läuft auf einen Pi hinter der Fritzbox 192.168.178.1 mit der ip 192.168.178.2

Da kommt kein NAT zum Einsatz sondern eine Routingtabelle: NetworkAdressTranslation / ein Übersetzung der IPv4-Adresse ist nicht da nicht im Spiel.
Damit bitte endlich SACHLICH beim Thema bleiben oder lieber als stiller Mitleser im Hintergrund agieren

 

[Insti]

Bemerkst Du da vielleicht einen (durchaus entscheidenden) Unterschied? Verstehst Du, warum da einmal kein NAT und einmal NAT (wenn Dein Pi per IPv4-Freigabe erreichbar ist) im Spiel ist?

Ok, lassen wir den Pi weg und es gibt nur die Fritzbox. Ziel ist immernoch einen Timer auf dem Enigma2 Receiver einzustellen aus dem Internet mit Wireguard.

Damit bitte endlich SACHLICH beim Thema bleiben

Bitte mal aufzeigen an welcher Stelle in diesem Thema ich etwas unsachliches geschrieben habe?

 

[Novize]

Lies Dir einfach mal selbst Deine Beiträge durch - das solltest bei 24 Beiträgen machbar sein...
Abseits vom Thema des TE ist es weiterhin, auch daraufhin lies Deine Beiträge noch einmal.

Und jetzt Ende mit dem OT in diesem Thread und zurück zum Thema! Deine NAT-Beispiele sind keine NAT-Beispiele und damit hier OT...
Was NAT ist, was WG macht, wo NAT zum Einsatz kommt, kläre in einem eigenen Thread nicht aber hier.
=> Das ist eine moderatorische Anweisung, keine Diskussionsgrundlage.

 

[PeterPawn]

es gibt nur die Fritzbox

Dann wird der (entfernte) WireGuard®-Client (solange es keine LAN-LAN-Kopplung ist) zu einem Teil des lokalen IP(v4)-Netzes (eben per Proxy-ARP, womit sich die Box als lokales Ziel ausgibt für alle anderen Geräte in LAN) und erhält seinerseits eine Adresse aus diesem Netz für sein eigenes WireGuard®-Interface.

Auch dabei werden keine Netzwerkadressen "übersetzt" - die lokalen Pakete werden 1:1 eingepackt und zum entfernten Client gesendet, der seinerseits wieder direkt an sein WireGuard®-Interface sendet (auch das wird nur 1:1 zurück getunnelt).

 

[Grisu_]

Da bekommt dann der entfernte Client über den VPN-Tunnel eben (meist/bevorzugt) eine x.x.x.201 IPv4 aus dem Heimnetz und präsentiert sich als Client im Heimnetz - kann man das mit anderen (vielleicht einfacheren) Worten so sagen?

 

[Novize]

kann man das mit anderen (vielleicht einfacheren) Worten so sagen?

Ja, das kann man einfach ausgedrückt so beschreiben.
Jeder VPN-Client bekommt über das VPN im entfernten Ziel-Netz einen virtuellen Netzwerkadapter zugewiesen und agiert völlig ohne NAT im lokalen Netz.

Ich arbeite viel mit VPN in Kundennetzen:
Beispielsweise habe ich das lokale Subnetz 192.186.100.0/24, der Kunde hingegen hat 192.168.101.0/24
Verbinde ich mich mit einem Kundennetz sieht es so aus, dass der VPN-Dienst mir einen virtuellen Netzwerkadapter anlegt mit der IP 192.168.101.201 und ich mich damit frei im entfernten Netz des Kunden bewegen kann, als wäre ich mit laaaaangem Patchkabel dort eingestöpselt.
Der VPN-Dienst im Kundennetz hat dabei eine variable Anzahl an virtuellen Netzwerkadaptern (einen pro verbundenem VPN-Client), die er kontrolliert. Ich schicke was von meinem Netzwerkprogramm über meinen virtuellen Adapter los, das kommt 1:1 ohne "spezielle Behandlung", ohne Adressübersetzung auf der Gegenseite am virtuellen Adapter raus und bewegt sich in dem entfernten Netz. Antworten gehen dann an den virtuellen Adapter des entfernten VPN-Dienstes und diese Antwortpakete kommen 1:1 ohne Adress-Änderungen an meiner virtuellen Netzwerkkarte raus zurück zum Netzwerkprogarmm.
Ich wüsste nicht, wo das NAT mit hineinspielen könnte.
Hier kommt nur ein Routing-Mechanismus zum Einsatz, denn wenn mein Programm Netzwerkpakete für das Netz 192.168.101.0/24 aussendet, greift das Routing und legt fest, welcher Netzwerkadapter für dieses Datenpaket zuständig ist, in diesem Fall also der virtuelle Adapter von meinem VPN-Client. Das geschieht aber lokal auf meinem PC. Im entfernten Netz hingegen kommt das Datenpaket mit Absender 192.168.101.201 aus dem virtuellen Netzwerkadapter und alle Datenpakete (neue, wie auch Antwortpakete) gehen einfach an den virtuellen lokalen Netzwerkadapter mit der Adresse 192.168.101.201

 

[Grisu_]

Naja, davor halt schon, wenn CGNAT beim Betreiber geschaltet ist und die FB vom dem eben nur eine private 100.x.x.x bekommt.
Damit der Tunnel überhaupt aufgebaut werden kann, muß ja über die öffentliche IP auf die CGNAT zur FB übersetzt werden (schon beim Betreiber).
Ist aber natürlich alles außen vor und hat mit dem konkreten Fall nichts zu tun.
Wollte ja nur sagen, daß NAT im Spiel sein kann, aber wie gesagt völlig ohne Bedeutung für WG oder VPN-Tunnel.

Aber danke für die Bestätigung und tiefere Erklärung!

 

[Novize]

Ja klar, NAT ist im Spiel bei einer IPv4-Kommunikation von IPv4-LAN zu anderem IPv4-LAN über ein IPv4-WAN, wenn die Router zum WAN hin nur eine "öffentliche" IPv4-Adresse haben, also

• VPN-Dienst => lokales IPv4-Netz
• => Router zum WAN (NAT!)
• => WAN-IPv4-Netz
• => Router zum LAN (NAT!)
• => entferntes IPv4-Netz
• => entfernter VPN-Dienst.

Sitzt dein Router hinter einem Router des Providers, in dessen Netz Du eine private IPv4 zugewiesen bekommst, wird das ganze natürlich noch einmal eine Stufe mehr "genatted"...

• VPN-Dienst => lokales IPv4-Netz
• => Router zum Provider-LAN (NAT!)
• => Provider-LAN-IPv4-Netz
• => Provider-Router zum WAN (NAT!)
• => WAN-IPv4-Netz
• => Router zum LAN (NAT!)
• => entferntes IPv4-Netz
• => entfernter VPN-Dienst.

Hier wird an jedem Router das Datenpaket umadressiert mit der (eigenen) Absende-IP-Adresse
Der entfernte Router nimmt das Paket an, kontrolliert den Zielport, adressiert das Paket um auf die IP-Adresse des VPN-Dienstes
Rückpakete laufen entsprechend, da wird also fleißig mit NAT das nächste Zwischenziel adressiert, damit das Paket überhaupt dort ankommt.

Bildlich ist es ein Brief adressiert an Z), das Ziel ist aber nicht erreichbar, die nächste Poststation weiß aber über den Nachsendeantrag, der Brief muss an Adresse B)
Die nächste erreichbare (zuständige) Poststation B) nimmt den Brief, schaut in seine Nachsendeanträge und steckt den in einen neuen Umschlag adressiert an C), C) nimmt den Brief und übergibt ihn wegen des Ziel-Ports incl aller drinnen liegenden Umschläge an den VPN-Client Z), der den VPN-Inhalt innerhalb des lokalen Netzes bei ihm weiterleitet. Antworten werden dann in den innersten Briefumschlag gepackt und mit dem Stempel "Return an Sender" zurück gegeben. C) nimmt den Umschlag, entfernt den äußersten Umschlag und schickt den Brief mit "Return an Sender" zurück an B). B) entfernt den letzten Weiterleitungs-Umschlag, schickt den ursprünglichen Brief mit dem Vermerk "Return to Sender" zurück an den Dienst bei mir. Dieser VPN-Dienst entnimmt nun die Antwort und gibt diese zurück an das ursprünglich aussendende Programm

So wandern die VPN-Datenpakete zwischen den beiden VPN-Endpunkten mit den verschiedenen IPv4-Netzen dazwischen - das ist aber bei Instis Beispielen nicht der Fall. Insti fragt, "wie kontaktiere ich (ohne NAT) den Videoreceiver im entfernten Netz?" und das geschieht schlicht nur über einen virtuellen Netzwerkadapter im Zielnetz

 

[Insti]

@Novize
nur ein Hinweis bevor Du oder ein anderer mich wieder anpflaumt,
in #28 hast du es anders erklärt als in #30

 

[frank_m24]

in #28 hast du es anders erklärt als in #30

Nein, hat er nicht. Da steht genau das gleiche.

 

[Novize]

in #28 hast du es anders erklärt als in #30

Nö, ich habe zwar andere Worte gewählt und es in #30 ausführlicher erklärt, der Sachverhalt aber ist der Gleiche
Vermutlich kommst Du damit durcheinander, dass bei obigem IPv4-Beispiel NAT für den VPN-Tunnel wichtig ist, aber nicht für die VPN-Pakete an sich, denn die gehen nur durch den Tunnel zur Gegenseite und zurück. Wenn also eine Verbindung der VPN-Dienste untereinander besteht, egal wie aufgebaut, dann kommt nur noch die Routing-Tabelle zum Tragen, die entscheidet, über welchen (virtuellen) Netzwerkadapter die Datenpakete fließen.

 

[PeterPawn]

Wenn also eine Verbindung der VPN-Dienste untereinander besteht, egal wie aufgebaut, dann kommt nur noch die Routing-Tabelle zum Tragen, die entscheidet, über welchen (virtuellen) Netzwerkadapter die Datenpakete fließen.

Wieder nur "bildlich" oder doch wörtlich gemeint? Was ist denn bei der dritten Konfigurationsmöglichkeit für IPSec-Verbindungen im FRITZ!OS, jenseits einzelner (VPN-)Clients und LAN-LAN-Kopplungen?

Genauigkeit (meinetwegen auch Penibilität, wobei das eigentlich Synonyme sind) ist manchmal schon wichtig - auch wenn das ggf. ein paar mehr Worte der Erläuterung braucht, um korrekt zu differenzieren.

I couldn't resists … and/or I couldn't stand it.

 

[Insti]

Nö

habe ich das lokale Subnetz 192.186.100.0/24, der Kunde hingegen hat 192.168.101.0/24

Und das ist kein Widerspruch zu

• VPN-Dienst => lokales IPv4-Netz
• => Router zum WAN (NAT!)
• => WAN-IPv4-Netz
• => Router zum LAN (NAT!)

?

bei obigem IPv4-Beispiel NAT für den VPN-Tunnel wichtig ist, aber nicht für die VPN-Pakete an sich,

Wo bitteschön wurde das in Frage gestellt das es nicht so ist?

 

[Grisu_]

Den Widerspruch sehen ich auch nicht.
Die beiden Heimnetze müssen unterschiedlich sein, sonst weiß der Router ja nicht, daß es sich um eine IP im anderen (VPN-)Netz handelt und würde versuchen sie lokal zuzustellen, wo es u.U. sogar schon einen Client mit selber IP gibt.
Also geht VPN mit IPv4 gar nicht ohne NAT.
Aber da reden wir immer vom "normalen" NAT, das an jedem Router mit WAN zum Heimnetz stattfindet und kein zusätzliches NAT (Double-NAT, vorerst mal egal ob daheim am Modemrouter oder durch CGNAT des Carriers).

Dies alles passiert aber auch ganz ohne VPN, wenn du auf eine Heimat-IP zugreifen möchtest, auch ganz ohne VPN.

Dein Denkfehler ist glaube ich, daß der VPN-Tunnel nur bis zur Fritzbox aufgebaut wird, die deinem Client eine IP aus dem dortigen Heimnetz verpaßt.
Und somit wie alle anderen Geräte dort sich im selben Subnetz befindet, somit alles dort ansprechen kann als wäre er direkt dort eingebucht.

Da brauchst du keine PortForwards oder sonstwas, weil du nicht auf einen Client dort zugreifst, sondern deinen Client quasi ins dortige Netz "verschiebst" als wäre er dort daheim.
Und diese VPN-Verbindung passiert nur bis zur Fritzbox am entfernten Standort und nicht bis irgendwo dahinter (wo das eigentliche NAT von der öffentlichen IP zur Heimnetz-IP erfolgt).

@Novice: Bitte lyncht mich nicht, wenn es nicht ganz fachlich richtig ausgedrückt ist, aber ich denke meinen Worten kann er eher folgen als euren (sicher korrekteren aber doch eher abstrakten) Ausführungen.
Man kann halt nicht einzelne Worte oder Wortgruppen aus dem Zusammenhang reißen und dann miteinander ohne ganzes vergleichen, um einen Widerspruch darin zu vermuten.

 

[Insti]

Also geht VPN mit IPv4 gar nicht ohne NAT.

Danke @Grisu_ das ist auch was ich seit fast 2 Tagen versuche zu erklären.
Im #12 wurde gesagt das wäre falsch und es gibt kein NAT. Dann kamen noch 2 dazu (die es eigentlich besser wissen sollten) und sagen es braucht kein NAT und ich wäre nicht Sachlich.
Ehrlich gesagt war ich immer beim „Tunnelbau“ für das NAT bei ipv4 benötigt wird und nicht schon dabei durch Pakete von A nach B zu schicken.

 

[frank_m24]

Sorry, aber das ist Unsinn. Natürlich geht VPN ohne NAT, und der vorliegende Fall ist so einer.
Bei VPN unterscheiden wir 2 Dinge: Der Tunnel an sich und die Nutz-Daten im Tunnel. Wenn beide Kommunikationspartner eine öffentliche IP haben, wie in diesem Fall, können sie sich die Tunnel-Pakete ohne NAT zuschicken. Die Daten werden zwar geroutet, aber NAT gibt es nicht.

Bei den Nutz-Daten im Tunnel muss es ebenfalls kein NAT geben. Hier gibt es prinzipiell 3 Möglichkeiten: Die Fritzbox macht ProxyARP, da gibt es kein dediziertes Transportnetz und der VPN Client bekommt eine IP aus dem lokalen Subnetz der Fritzbox. Da gibt es KEIN NAT: Das VPN Gateway nimmt die Pakete mit der lokalen IP entgegen, verpackt sie direkt in Tunnelpakete mit der öffentlichen IP und schickt das ganze auf die Reise. KEIN NAT.
Die nächste Möglichkeit ist ein Transportnetz, wie es Wireguard und OpenVPN gerne machen. Hier werden die Daten im Tunnel mit anderen IPs übertragen, als das Subnetz des lokalen Routers. Hier gibt es prinzipiell wieder 2 Möglichkeiten: man kann vollwertig routen, dann kommt ebenfalls kein NAT zum Einsatz, dafür braucht man ggf. statische Routen, wenn das VPN Gateway nicht zugleich auch das Default Gateway ist. Oder das VPN Gateway macht NAT, das geht auch. Es hängt vom Anwendungsfall ab, ob NAT an der Stelle Sinn macht, oder nicht, z.B. wenn man über den VPN Tunnel das Internet erreichen will. Dafür schränkt NAT an der Stelle die bi-direktionale Erreichbarkeit ein, das sollte man auf dem Schirm haben. Das gilt dann aber genauso für IPv6, auch dort muss man dann NAT machen, da das Transportnetz üblicherweise mit ULA Adressen arbeitet.

 

[Novize]

Wieder nur "bildlich" oder doch wörtlich gemeint? Was ist denn bei der dritten Konfigurationsmöglichkeit

Das herauszufinden, auch ob das relevant ist im Bezug zu dem komplett fehlenden Wissen zu den Grundlagen in manchen Beiträgen hier, überlasse ich deiner Genauigkeit beim Lesen meiner und anderer Beiträge.

 

[Grisu_]

Da hast mich auch völlig falsch verstanden.
Waren wohl auch meine Worte unverständlich für dich.

Dann ein anderer Versuch:

Es wird eine normale Verbindung zu der entfernten Box aufgebaut, ob da NAT im Spiel ist oder nicht ist völlig irrelevant!
Falls die Fritzbox eine öffentliche IPv4 am WAN Port hat, geschieht da überhaupt kein NAT!!!
Deine verbindet sich mit der entfernten über die öffentliche IPv4, nix mit NAT.
Die beiden bauen dann einen VPN-Tunnel auf, wodurch dein Client eine IPv4 des entfernten Subnetzes bekommt.
Noch immer kein NAT.
NAT übersetzt die öffentliche IPv4 auf eine IPv4 im Heimnetz.
Das geschieht hier überhaupt nicht!

Nur wenn an der fernen Fritzbox keine öffentliche IPv4 anliegen hast kommt NAT ins Spiel (aber nicht bezogen aufs VPN).
Entweder beim Betreiber CGNAT, der die öffentliche IPv4 auf jene übersetzt, die du dann an der fernen FB am WAN-Port anliegen hast.
Oder wenn deine FB hinter einem Modemrouter beheimatet ist, dann übersetzt das Modem auf sein Heimnetz.
Da gibts aber kein VPN.
Es wird einfach nur eine Verbindung zwischen den beiden FB aufgebaut, falls da wo NAT passiert soll es so sein, andernfalls eben gar nicht.
Hat nichts mit VPN zu tun. Einzig entscheidend ist der Umstand, daß sich die beiden FB irgendwie sehen und miteinander kommunizieren können.
Sobald dies erfolgreich geschehen ist, bauen sie einen Tunnel auf.
Und jetzt gibts VPN.
Der VPN-Tunnel hört und sieht nichts vom NAT (sofern vorher eins zwecks Verbindung der beiden Boxen überhaupt nötig war).
Der nutzt einfach die zuvor aufgebaute Verbindung zwischen den Boxen und gibt deinem Client eine IP vom fernen Heimnetz, damit er mit den Geräten dort kommunizieren kann.
Nur die beiden Boxen kennen die VPN-Verbindung und das VPN selbst kennt kein NAT.
Die öffentiche IPv4 wird niemals auf die Heimnetz-IP deines Client im fernen Netz übersetzt, daher gibts da auch kein NAT!!!
Nur die beiden Boxen kommunizieren untereinander und schicken gewisse Daten über den VPN-Tunnel.
Gäbe es NAT, müßte in der Fernen Box ein Forward eines (oder mehrerer oder aller) Ports auf eine IP dort geschehen, dies ist aber nicht der Fall.