Reihner
Anmeldungsdatum: 14. Juni 2017
Beiträge: 157
Wohnort: Klendathu
|
Hallo ihr, und auch du da in de Ecke, die Frage ist eigentlich simpel, nur finde ich bisher keine Lösung. Wie leite ich die IPv6-Ende-zu-Ende-Verbindung durch einen VPN-Tunnel? Ich selbst nutze OpenVPN auf einem Pi und das funktioniert mit IPv4 auch problemlos, zudem weiß ich ich nicht ob ich es überhaupt benötige und die "never chance a running system"-Regel musste ich schon schmerzhaft lernen.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8558
Wohnort: Münster
|
Reihner schrieb: […] Wie leite ich die IPv6-Ende-zu-Ende-Verbindung durch einen VPN-Tunnel?
Das geht genauso wie bei IPv4: Man richtet für den Verkehr, der durch den Tunnel soll, einen Leitweg (Route) ein. Die bestehenden Leitwege für IPv4 sieht man mit diesem Befehl: ip -4 route show (show kann man weglassen.) Entsprechend die für IPv6: ip -6 route Eine neue Route richtet man ein mit: sudo ip route add …
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
IPv6 funktioniert hier diesbezüglich genauso wie IPv4: Wenn die Routen auf dem Host sagen, dass die Pakete über ein bestimmtes Gateway oder eine bestimmte Schnittstelle geschickt werden sollen, dan passiert das auch. Wenn du allerdings danach fragst, wie du IPv4 zu einem IPv6-Host geprügelt bekommst (oder umgekehrt), wird es schwieriger. Im Endeffekt würdest du einen (besseren oder schlechteren?) Proxy als Gateway in das jeweilige Netz stellen, der die passenden Protokollversionen spricht und den Clients vorgaukelt, ihre Welt sei noch in Ordnung. Mit Proxy meine ich hier auch so Sachen wie die Sixxs-Tunnel.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7651
|
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Reihner schrieb: die Frage ist eigentlich simpel, nur finde ich bisher keine Lösung.
Ja, weil das überhaupt nicht so trivial ist, wie man hier meint... ganz im Gegenteil, und mit einer einfachen Route ist da nämlich gar nix getan, weil man möglicherweise gar nicht das IPv6-Netz kennt, für welches eine Route einzurichten ist.... deswegen nicht, weils vielleicht noch täglich wegen Zwangstrennung wechselt... was nämlich z.B. bei Dualstack-Providern mit einem täglich neuen /56er-Prefix durchaus noch üblich ist. Weil Du leider jetzt wichtige Informationen vorenthalten hast, muss man allerdings nun raten und ne Glaskugel bemühen, um da etwas dazu zu sagen. Also, alles ohne Gewähr. Ich nehmen mal an, wei bei Dir IPv4 funktioniert, hast Du keinen reinen DS-Lite-Account, Du kannst Dich ja anscheinend via IPv4 von irgendwo nachhause via DynDNS verbinden. Wenn Du weiterhin auch von IPv6 sprichst, kann man annehmen, dass Du einen Dual-Stack-Account hast und noch täglich zusätzlich einen IPv6-Prefix bekommst. Und damit beginnen die Probleme, Deine lokalen Clients bilden sich selber bei jedem Boot aus dem Prefix, den sie durch das RA bekommen, via SLAAC beim Hochfahren des Rechners eine gültige öffentliche IPv6 (GUA). Da gibts kein DHCP und auch keine vom lokalen Admin willkürlich definierte Static-IPs.... das wäre schon möglich, die sind aber dann rein lokal (ULA). Das Problem ist, die Site-ID (/64) ändert sich somit täglich, und weil die das V6-Netz repräsentiert ist da nix mit statischen Routen. Du brauchst aber eine loakle statische IPv6, eben weil die ja üblicherweise von vornherein öffentliche IPv6s sind (und man kann sich ja damit vernünftigerweise DynDNSv6 sparen), damit Du überhaupt Deinen Server "anrufen" kannst. Stells Dir wie die heimische Telefon-Nr. vor und den Effekt, wenn die täglich wechseln würdest und Du von unterwegs anrufen möchtst. Darüber hinaus, wenn Du -was unbedingt ratsam ist- auch noch die PE aktiviert hast, ändert sich auch täglich noch Teil 2 der IPv6, und zwar die Interface-ID, also geht das auch nicht so leicht mit er Port-Weiterleitung. Das gleiche gilt für die Clients hinter den tun-Devices. Das nächste Problem ist, Du bekommst aus dem Mobil-Netz sowieso keine Verbindung auf Deine öffentliche IPv6, weil das Mobile-Netz kein 4to6-Nat durchführt. Und wenn Du einen echten statischen öffentlichen Prefix haben willst, wirst Du den Buchen und Bezahlen müssen. Ne Garantie ohne Kohle gibts nicht, auch nicht bei DS-Lite, weil die auf die Zwangstrennung verzichten. Die Fluktuation ist da nur geringer. Also, ums kurz zu sagen, das RA zu Tunneln ist bei Zwangstrennung äußerst anspruchsvoll, weil die LLA (die das RA transportiert), durch den Tunnnel muss, damit der Client sich via SLAAC auf dem Tun-Device überhaupt eine passende IPv6 bilden kann. Erst wenn das gelingt, kann man über Routen nachdenken. Und wenn der Client eine eigenen echte IPV6 aus dem Heimnetz haben soll, ist das der einzige Weg. Bei einem reinen IPv6-Stack mit statischer SiteID hat man allerdings gute Karten. Ich habe aber keine Ahnung, wer das schon mal erfolgreich gemacht hat. Ich habe das mit DualStack anders gelöst, ich verzichte auf SLAAC und vergebe dem Client eine ULA via VPN-DHCPv6 und mach für die aufs reguläre Interface des VPN-Servers ausgehenden Pakete ein masquerading. Damit hat der Client zwar keine öffentliche IPv6, kann aber dennoch -wenn ich auf meinem S8 Tethering öffne- sogar übers Handynetz IPv6-Adresssen erreichen. Das geht, weil die IPv6-Pakete im Tunnel in IPv4-Pakete encapsulated sind. Also das kann ich Dir sagen... die Frage mag simpel sein, die Lösung ist das auf keinen Fall. 😛
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
Nun ja, die Frage lautete, ob ich rein theoretisch auf Protokollebene irgendwas besonderes machen muss, um IPv6-Pakete durch ein VPN zu leiten und die Antwort lautet nunmal: Nein, ich brauche nur passende Routen auf den betroffenen Hosts/Gateways. Wie nun die Spezifikation der Route bestimmt wird, ist für die Beantwortung der konkreten Frage vollkommen unerheblich und ergänzende Antworten haben vielleicht sogar den Nachteil, dass sich plötzlich ein Bild aus Notwendigkeiten entwickelt, die gar nicht zu den Anforderungen passen. IPv6 hat im Verhältnis zu IPv4 wesentlich mehr als nur eine Erweiterung des Adressraums mit sich gebracht. Um die Horrorgeschichte zum Thema "Die Hölle auf Erden - oder ein kurzer Überblick über IPv6 in der Praxis" zu ergänzen, schlage ich die Lektüre bzgl. ortsunabhängiger IP-Adressen vor. Es ist zwar schon recht lange her, dass ich das letzte Mal darüber las und deshalb fehlen mir die richtigen Begriffe. Im Ergebnis habe ich jedoch z.B. auf meinem Mobilgerät eine ortsunabhängige IP-Adresse aus meinem "lokalen" Adressbereich mit mir herumgetragen und konnte diese trotzdem in beliebigen Netzwerken ohne große Probleme nutzen. Klang ziemlich cool, als ich das vor zehn Jahren gelesen habe - ist aber alles wieder vergessen. ☹ Übrigens lässt sich die ganze Antwort auch hübsch für IPv4 umschreiben. Es müssen nur eine Hand voll IPv6-bezogene Abkürzungen auf möglichst hässliche IPv4-Mechanismen umgesetzt werden und schon ist IPv6 nicht mehr die Hölle, sondern IPv4. Der Unterschied ist eigentlich nur, dass wir es so gewohnt sind, mit IPv4-Eigenarten rumzueiern, dass wir gar nicht mehr merken, wie aufwändig das teilweise ist - aus logischer Sicht betrachtet.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Cranvil schrieb: Nun ja, die Frage lautete, ob ich rein theoretisch auf Protokollebene irgendwas besonderes machen muss, um IPv6-Pakete durch ein VPN zu leiten und die Antwort lautet nunmal: Nein, ich brauche nur passende Routen auf den betroffenen Hosts/Gateways.
Nun ja, ich halte das für eine Interpretation... nicht mehr, nicht weniger. Ob das allerdings wirklich damit gemeint war, oder vielleicht auch einfach nur eine funktionierende "IPv6-Ende-zu-Ende-Verbindung durch einen VPN-Tunnel" (so der Wortlaut), wissen wir nicht. Ich glaube, weil es sich hier ums Ubuntu-Forum handelt, eben primär mit der Zielgruppe private Anwender, halte ich meine Interpretation für wahrscheinlicher.
IPv6 hat im Verhältnis zu IPv4 wesentlich mehr als nur eine Erweiterung des Adressraums mit sich gebracht.
Ja, gravierende Verbesserungen, mit der z.B. endlich dieses unnötige NAT weggefallen ist und der Paket-Overhead reduziert wurde, oder Global-Unicast-Adressen, wodurch der Client endlich selber und direkt im WWW kommunizieren kann. Ich empfinde IPv6 überhaupt nicht als Horror, sondern schlichtweg als geniale Lösung.
Im Ergebnis habe ich jedoch z.B. auf meinem Mobilgerät eine ortsunabhängige IP-Adresse aus meinem "lokalen" Adressbereich mit mir herumgetragen und konnte diese trotzdem in beliebigen Netzwerken ohne große Probleme nutzen. Klang ziemlich cool, als ich das vor zehn Jahren gelesen habe - ist aber alles wieder vergessen.
Ja, ist doch normal... eine IPv6 (LLA) aus dem Netz fe80::/64 mit einer Machine-ID aus der MAC gebildet wird direkt während des Boots vom Kernel erzeugt und sie ist quasi statisch. Damit und via NDP und RouterAdvertisement bekommt der Client seinen Prefix und generiert sich selber seine öffentliche IPv6 im lokalen Netz. Das funktioniert bestens auch bei Netzwerkwechseln... solange nicht eine Portsecurity an betriebsbekannte MACs gebunden ist. Man muss dabei nur den Scope der IPv6-Typen unterscheiden ... ortsunabhängige Global-Unicast-Adressen gibts meiner Meinung nach jedenfalls nicht, die Site-ID, um in einem Netz Mitglied zu werden, muss trotzdem übereinstimmen.
Der Unterschied ist eigentlich nur, dass wir es so gewohnt sind, mit IPv4-Eigenarten rumzueiern, dass wir gar nicht mehr merken, wie aufwändig das teilweise ist - aus logischer Sicht betrachtet.
Ja, wenn man in der Fessel "NAT" denkt, aus dem Denken nicht rauskommt und das für sicherer hält und nicht versteht, das mal ohne diese Fessel schneller rennen könnte.... *lol*. Gibt ja sogar immer noch Leute, die IPv6 zu deaktivieren empfehlen. Also ich bin zweifelsfrei ein IPv6-Fan.
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
Ist unsere Unterhaltung jetzt eigentlich noch On Topic, weil der Frager recht unspezifisch gefragt hat? Dann mache ich nämlich mit dem allgemeinen hier und da einfach mal weiter. ☺ TomLu schrieb: ..., halte ich meine Interpretation für wahrscheinlicher.
Grundsätzlich gehe ich auch davon aus, dass die Frage am Ende in diese Richtung geht. Ich finde nur den Diskurs interessanter, wenn man sich das gemeinsam Stück für Stück erarbeitet. Dann wird der Leser auch nicht gleich so erschlagen. ☺ Um es noch mit einem ausreichend hinkenden Bild zu ergänzen: Am Ende war die Frage wirklich so platt und dein umfangreicher Artikel fühlt sich dann wie eine fertig vorbereitete Willamette-Pipeline (20 Stufen) in dem Moment, in dem sich herausstellt, dass die einleitende Sprungvorhersage falsch war.
Ja, gravierende Verbesserungen, mit der z.B. endlich dieses unnötige NAT weggefallen ist und der Paket-Overhead reduziert wurde, oder Global-Unicast-Adressen, wodurch der Client endlich selber und direkt im WWW kommunizieren kann. Ich empfinde IPv6 überhaupt nicht als Horror, sondern schlichtweg als geniale Lösung.
Versteh mich nicht falsch. Ich mag IPv6 auch sehr, habe recht lange mit meinem Sixxs-Tunnel und lokalem IPv6 experimentiert. Für jemanden, der sich mit IPv6 noch nicht so sehr beschäftigt hat, liest sich die Zusammenstellung gefühlt wie eine Aufzählung der Stolpersteine, die hinter jeder Ecke lauern. Und auch wenn es richtig ist, dass man ob der vielen Möglichkeiten hier und dort aufpassen muss, erschreckt das den einen oder anderen vielleicht auch so sehr, dass wir plötzlich wieder in GroßNATtinghausen landen.
Ja, ist doch normal... eine IPv6 (LLA) aus dem Netz fe80::/64 mit einer Machine-ID aus der MAC gebildet wird direkt während des Boots vom Kernel erzeugt und sie ist quasi statisch. Damit und via NDP und RouterAdvertisement bekommt der Client seinen Prefix und generiert sich selber seine öffentliche IPv6 im lokalen Netz. Das funktioniert bestens auch bei Netzwerkwechseln... solange nicht eine Portsecurity an betriebsbekannte MACs gebunden ist. Man muss dabei nur den Scope der IPv6-Typen unterscheiden ... ortsunabhängige Global-Unicast-Adressen gibts meiner Meinung nach jedenfalls nicht, die Site-ID, um in einem Netz Mitglied zu werden, muss trotzdem übereinstimmen.
Wenn ich irgendwann in den nächsten zehn Jahren mal schaffe, mich wieder damit zu beschäftigen, finde ich die korrekte Darstellung vielleicht. Deine Beschreibung passt noch nicht ganz auf das, was ich damals gelesen habe - zumindest fühlt es sich so an.
Ja, wenn man in der Fessel "NAT" denkt, aus dem Denken nicht rauskommt und das für sicherer hält und nicht versteht, das mal ohne diese Fessel schneller rennen könnte.... *lol*. Gibt ja sogar immer noch Leute, die IPv6 zu deaktivieren empfehlen.
Ich arbeite derzeit bei einem Unternehmen, bei dem ich sehr geschickt taktieren muss, wenn IPv6 endlich implementiert wird... also ich meine IPv7. Sollte ich nicht aufpassen, kommen die nicht nur nicht auf die Idee, die dynamischen, zentral steuerbaren Methoden zu verwenden, sondern vergeben die Adressen auch wieder manuell. Und ich fürchte, außer unseren Betriebssystemen haben wir derzeit keine IPv6-fähige Software. 🙄 Na mal schauen, wie sich das noch entwickelt dort. Immerhin habe ich mittlerweile das Gefühl, dass ich nicht mehr des Hauses verwiesen werde, wenn ich die Nutzung von DHCP und DNS vorschlage. Hat auch nur ein Jahr gedauert.
Also ich bin zweifelsfrei ein IPv6-Fan.
+1 (auch wenn ich noch im IPv4-Land arbeiten muss ☹ ).
|
Reihner
(Themenstarter)
Anmeldungsdatum: 14. Juni 2017
Beiträge: 157
Wohnort: Klendathu
|
Emm ... OK ... Ich fürchte Ich habe mein Anliegen nicht akkurat vorgetragen oder ich verstehe die Antwort nicht. Aufbau: Router ist eine ganz normale FB 7490, auf einem RPi2 läuft der OpenVPN-Server. Öffentliche IPv4 und IPv6-Addressen sind vorhanden. Zielsetzung: Der OpenVPN-Server soll nicht länger eine IPv6NAT (ich weiß das dies nicht der korrekte Ausdruck ist aber der richtige ist mir gerade entfallen) nutzen sonder der FB sinngemäss sagen: "Hallo, ich nur ein Switch und an mir hängt noch ein ein Gerät, gib dem mal ne IPv4 und ne IPv6." Ergebnis soll sein: Der VPN-Tunnel leitet eine durchgehende IPv6-Verbindung vom Client bis zur Besuchten Seite weiter. atm wird die IPv6-Leitung durch den OpenVPN-Server unterbrochen.
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
Nach dem, was ich da jetzt verstehe, gehe ich davon aus, dass du deine OpenVPN-Konfiguration von tun auf tap umstellen musst. Die Wikipedia hat da einen Artikel, der die beiden kurz umreißt - die englische Version hat sogar eine hübsche Grafik zur besseren Darstellung. Ich habe mal ein paar Artikel zusammengesucht. Ubuntu OpenVPN Server tap/NAT Netzwerk Bridging einrichten🇩🇪 enthält nach kurzem Überfliegen nicht nur den Punkt zum Bridging sondern auch noch einige Aspekte mehr (z.B. eigene Zertifizierungsstelle für die VPN-Verbindungen). Sieht nach einer insgesamt nützlichen Anleitung aus, die mit Schritt 11 so langsam in den für dich interessanten Bereich gerät. Ich habe noch den🇩🇪 einen🇬🇧 oder anderen🇬🇧 Artikel gefunden. Allen gemein ist, dass sie ein klein wenig über dein Ziel hinaus schießen dürften, da bei dir vermutlich das Umstellen der OpenVPN-Konfiguration von tun auf tap ausreichen dürfte. In keinem dieser Fälle ist nach meinem Verständnis eine Verständigung zwischen FritzBox und OpenVPN-Server notwendig, das der/die Host(s) auf der anderen Seite gewissermaßen durch die Verbindung in dein lokales Netzwerk gezerrt werden, als wären sie wirklich nur an einem Switch angeschlossen.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Reihner schrieb: Emm ... OK ... Ich fürchte Ich habe mein Anliegen nicht akkurat vorgetragen oder ich verstehe die Antwort nicht.
Dann solltest Du meinen Rat am Ende befolgen.
Aufbau: Router ist eine ganz normale FB 7490, auf einem RPi2 läuft der OpenVPN-Server. Öffentliche IPv4 und IPv6-Addressen sind vorhanden.
Zielsetzung: Der OpenVPN-Server soll nicht länger eine IPv6NAT (ich weiß das dies nicht der korrekte Ausdruck ist aber der richtige ist mir gerade entfallen) nutzen sonder der FB sinngemäss sagen: "Hallo, ich nur ein Switch und an mir hängt noch ein ein Gerät, gib dem mal ne IPv4 und ne IPv6."
Die FB gibt Deinen Clients keine IPv6, alle Clients generieren die sich stateless selber via SLAAC.... das heisst, das macht der Kernel ganz automatisch. Deswegen ist dafür auch erst mal gar kein DHCP-Client aktiv... weil man den schlichtweg nicht braucht.
Ergebnis soll sein: Der VPN-Tunnel leitet eine durchgehende IPv6-Verbindung vom Client bis zur Besuchten Seite weiter.
Ich gebe Dir da mal einen gutgemeinten Rat, den Du in Deinem eigenem Interesse befolgen solltest...und zwar bei den folgenden Gegebenheiten: wenn Du Deine Mobilgeräte häufig an fremden offenen WLAN-Accesspoints verbindest und dann OpenVPN zur Verbindung nachhause nutzt, solltest Du in diesen besonderen Fällen und in Deinem eigenem Interesse IPv6 temporär sogar ganz deaktivieren. BTW, Cranvil und ich verstehen offensichtlich ein völlig unterschiedliches Problem und befassen uns somit mit völlig unterschiedlichen Lösungen. Du solltest also schon erklären, für was Du Dein OpenVPN überhaupt nutzt.... für eine Site-2-Site-Verbindung (2 Netzwerke) ist Bridging der richtige Ansatz, wie von Cranvil angeregt. Wenn Du einem Road-Warrior eine sichere Leitung nachhause geben willst, ist Routing die richtige Lösung, woran ich nach Deinen Äußerungen denke. Du solltest das wirklich klarstellen.
https://openvpn.net/faq/what-are-the-fundamental-differences-between-bridging-and-routing-in-terms-of-configuration/
|
Reihner
(Themenstarter)
Anmeldungsdatum: 14. Juni 2017
Beiträge: 157
Wohnort: Klendathu
|
TomLu schrieb: BTW, Cranvil und ich verstehen offensichtlich ein völlig unterschiedliches Problem und befassen
achso, ich versuche mich an der Road-Warrior-Variante TomLu schrieb: alle Clients generieren die sich stateless selber via SLAAC
Und es ich nicht möglich den VPN-Client anzuweisen sich via SLAAC eine eigene IPv6 mit dem (in meinem Fall /64)-prefix der VPN-Internet-Schnittstelle anzufertigen? TomLu schrieb: Ich gebe Dir da mal einen gutgemeinten Rat, den Du in Deinem eigenem Interesse befolgen solltest...und zwar bei den folgenden Gegebenheiten: wenn Du Deine Mobilgeräte häufig an fremden offenen WLAN-Accesspoints verbindest und dann OpenVPN zur Verbindung nachhause nutzt, solltest Du in diesen besonderen Fällen und in Deinem eigenem Interesse IPv6 temporär sogar ganz deaktivieren.
Könnest du dies bitte es ausführlicher erleutern? Also Grund und mögliche Gefahren. Und wie würde ich IPv6 komplett sperren?
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Reihner schrieb: Und es ich nicht möglich den VPN-Client anzuweisen sich via SLAAC eine eigene IPv6 mit dem (in meinem Fall /64)-prefix der VPN-Internet-Schnittstelle anzufertigen?
Doch, das geht, Du kannst auch das Router-Advertisement resp. NDP durch den Tunnel routen. Hier ein paar Ansätze dazu:
https://unix.stackexchange.com/questions/136211/routing-public-ipv6-traffic-through-openvpn-tunnel Es bleibt allerdings die Frage, wie sinnvoll das ist... gerade auch, wenn Du einen DualStack-DSL-Account hast und der noch einer täglichen Zwangstrennung unterworfen ist. Damit ändert sich nämlich auch der tägliche Prefix und Du müsstest täglich die Routen im Client, Server und ggf. Router neu setzen, was ja eigentlich kaum praktikabel ist, wenn man es manuell tun muss. Und Dir muss klar sein, dass es im Mobil-Netz sowieso kein IPv6 gibt, das bedeutet, Deine IPv6-Pakete werden vor dem Interface des Mobilgerätes sowieso in IPv4-Pakete gekapselt und erst dann übertragen. Auf dem VPN-Server müssen sie hingegen wieder ausgepackt werden und werden erst dann an den IPv6-Stack des Servers gegeben. Ich vermute fast, dass das ganze Konstrukt eher nachteilig ist. Aber vielleicht können die Netzwerks-Experten hier im Forum mehr dazu sagen. Ich würde Dir davon jedenfalls abraten, weil die Nachteile den Nutzen meiner Meinung nach überwiegen. Wenn überhaupt V6, dann würde ich auf jeden Fall ein V6-NAT einrichten und das ist auch auf jeden Fall so ausreichend, dass Du keinen Unterschied bemerken wirst. BTW, Du merkst ja auch nicht die NAT für IPv4.
Könntest du dies bitte etwas ausführlicher erläutern? Also Grund und mögliche Gefahren. Und wie würde ich IPv6 komplett sperren?
Ich habe mein Setup auf meiner HP beschrieben... da findest Du auch einige Erklärungen: http://www.thlu.de/openvpn.html
|