IPv6 - Unklare Formulierungen...???

  • Moin @ all

    Ich hoffe mal wieder auf Eure Hilfe bei einem kleinen Problem... denn im Moment hakts bei der Interpretation der folgenden Zeilen aus https://de.wikipedia.org/wiki/IPv6#Unique_Local_Unicast :

    Zitat

    Sofern in einem privaten Netz im Dualstack mit IPv4 nur ULA-Adressen verwendet werden, bevorzugt die Mehrheit der Clients bei einer DNS-Auflösung die IPv4-Adresse, auch wenn ein AAAA-Record existiert, da davon auszugehen ist, dass mit einer ULA-Adresse niemals der öffentliche IPv6-Adressraum erreicht werden kann. Dies führt in der Praxis dazu, dass in privaten Netzen (insbesondere beim Einsatz von NAT6) im Dualstack von ULA-Adressen abgeraten wird.

    Was habe ich vor:

    Ich versuche gerade meinen Server auch via IPv6 von außerhalb und via OpenVPN zu erreichen (IPv4 funktioniert ja schon seit langem). Seine lokale 2003:: IPv6 kann ich ja nicht verwenden, weil der DSL-Router das ja erwartungsgemäß schlichtweg blockt. Also gehts nur über den Umweg des Port öffnens und Weiterleitung der Pakete an (s)eine IPv6. Allerdings kann ich seine 2003:: auch hierbei nicht verwenden, weil die sich eben täglich durch die Zwangstrennung ändert. Das heisst, ich muss ihm auch eine quasi statische Adresse im LAN geben, an die ich die VPN-Pakete weiterleiten kann. Und genau dafür habe ich ihm jetzt eine GUA (fd00::) verpasst. LAN-Intern haut das jetzt alles hin. Der nächste Schritt wäre jetzt OpenVPN. Aber genau jetzt zweifel ich wegen der Bedeutung des obigen Zitates. Sind da Konflikte zu erwarten? Wie gesagt, mein Server-PI hat sowohl die GUA als auch die (normalerweise) nicht ins WEB geroutete ULA.

    Das sind die Rahmenbedingungen:

    - DSL mit Dual-Stack

    - RPi (Server) mit lokaler IPv4 und GUA IPv6 (2003::)

    - enthält zusätzlich eine IPv6 LLA (fe80::)

    - erhält via DHCP vom DSL-Router zusätzlich eine IPv6 GUA (fd00::)

    Die fd00:: auf dem Server habe ich jetzt neu eingerichtet, mit dem Gedanken ,diese als VPN-Ziel im Router einzurichten.

    Hat jemand ne Idee, ob der Ansatz richtig ist... ?.... (rpi444..?... bist Du wach? :saint:)

    Einmal editiert, zuletzt von WinterUnit16246 (31. August 2018 um 11:12)

  • Seine lokale 2003:: IPv6 kann ich ja nicht verwenden, weil der DSL-Router das ja erwartungsgemäß schlichtweg blockt. Also gehts nur über den Umweg des Port öffnens und Weiterleitung der Pakete an (s)eine IPv6.

    Was für einen DSL-Router/Modem hast Du? Kannst Du in diesem DSL-Router, die IPv6-Firewall für die v6-Clients an diesem Router, nicht öffnen?

    Kannst Du in diesem DSL-Router v6-Portweiterleitungen überhaupt konfigurieren?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Was für einen DSL-Router/Modem hast Du? Kannst Du in diesem DSL-Router, die IPv6-Firewall für die v6-Clients an diesem Router, nicht öffnen?

    Kannst Du in diesem DSL-Router v6-Portweiterleitungen überhaupt konfigurieren?

    Alles "ja"... ich habe die FB 7490... und die verhält sich merkwürdig bis fehlerhaft.... ich versuchs zu erklären

    Anfangs-Seite "Internet-Freigaben". Dort wähle ich aus "Gerät für Freigaben hinzufügen"... im Folgebildschirm wähle ich das Zielgerät aus, meinen Raspi-OpenVPN-Server... und da beginnt der erste Fehler: Nach der Auswahl des PIs zeigt er die korrekte IPv4, die korrekte MAC, aber die Interface-ID von einem anderen laufenden PI in der Form ::$(64Bit)... also ohne Prefix. Ich kann diese überschreiben und OK bestätigen, sie wird aber nicht geändert.

    Wen ich dann den Port 1194/UDP für IPv6 einrichte, zeigt er mir in dem neuen Fenster bei "IP-Adresse im Internet" die echte GUA des Raspi-OpenVPN-Servers, mit aktuellem Prefix und MAC-Based Internet-ID. Also alles so, wie es scheinbar sein müsste... aber ich sehe oben bei der Einstellung "Geräte-Auswahl" trotzdem die 2. Internet-IDs des anderen PI's

    Jetzt habe ich den 2. PI runtergefahren und die Fritte neu gebootet... aber bei neuem Einrichten der Freigabe passiert das gleiche... die falsche Internet-ID vom Zweit-PI wird zugehörig zum ersten PI angezeigt, editieren geht, speichern bleibt erfolglos.

    Also... ich sehe zwar die korrekte komplette IPv6 als Internet-Adresse bei der Freigabe, weiss aber nicht, ob der falsche Identifier in der Anzeige zum Gerät eine Auswirkung hat.

  • Nachtrag:

    Ich habs hingekriegt... mit "Gerät auswählen" gings nicht... da liegt scheinbar ein Fehler in der Fritte vor. Aber ich konnte statt Gerät auch "Interface-Identifier manuell eingeben" auswählen. Und damit gings dann. Im Grunde genommen hat sich (glaube ich erst mal) damit mein Problem erledigt. Wenn ich nur auf die Interface-ID weiterleiten kann und die Site-ID dynamisch/generisch dazugerechnet wird, ist also der Prefix zur Eingabe der vollständigen lokalen Zieladresse (Rpi-OpenVPN-Server) gar nicht notwendig. Wegen der mit der Zwangstrennung einhergehenden Probleme (wechselnder Prefix) hatte ich ja zur Lösung die statische ULA im Sinn... aber genau die blockt wieder andere Sachen... siehe oben das Zitat... und genau das konnte ich hier auch bestätigen: ich hatte zwar gültige GUAs, aber kein IPv6-Routing ins WWW.

    Aber mit der Weiterleitung auf NUR den GUA-Interface-Indentifier ist ja anscheinend auch gar keine statische ULA notwendig..... Mannoman... ist das verwirrend....

  • Aber ich konnte statt Gerät auch "Interface-Identifier manuell eingeben" auswählen.

    Hast Du eine statische Interface-ID für das v6-Interface deines PI?

    Ich mache das auch so (d. h. manuell) bei meinem PI, mit statischer Interface-ID beim v6-Interface meines PI.

    Es funktioniert (mit der FritzBox) bei mir auch ohne statischer Interface-ID und ohne manuelle Eingabe, aber dafür muss auf meinem PI, avahi installiert und aktiv sein. Aber avahi ist immer das Erste das ich (in Linux) deinstalliere.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • [OT]

    darf ich fragen, warum?

    [/OT]

    Naja, weil Probleme auftreten können. Siehe z. B. in: https://wiki.ubuntuusers.de/Avahi/ (nach "Probleme").

    ... und ich brauche avahi auch nicht.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hast Du eine statische Interface-ID für das v6-Interface deines PI?

    Ich mache das auch so (d. h. manuell) bei meinem PI, mit statischer Interface-ID beim v6-Interface meines PI.

    Ja, natürlich... die wird ja automatisch via Slaac basierend auf der MAC generiert. Die ins Internet wollenden Prozesse nutzen zwar die mit Privacy Extensions generierte IPv6, aber die Interface-ID der MAC-basierten ist natürlich statisch und aktiv... nur 2003::'er Site-ID ändert sich täglich durch die Zwangstrennung.

    Aber es gibt was anderes, was mich total irritiert... ich hab das jetzt noch mal kontrolliert : ich kann bei einer neuen IPv6-Freigabe in der Fritte keine vollständige IPv6 für den Zielhost eingeben, sondern nur eine Interface-ID. Wie unterscheidet die Fritte, wenn das NIC des Zielhosts mehrere IPv6 hat, also fe80::$(MacID), fd00::$(MacID) und 2003::$(MacID)? In IPv6-Sprech hat der OpenVPN-Host also eine LLA, eine ULA und eine GUA... und alle haben den gleichen Interface-ID.

    Ich weiss, dass avahi entbehrlich ist, und wenn mans entfernt, stört das technischerseits auch nicht weiter... aber ich hatte das immer als Komfort-Tool fürs Netzwerk-Handling verstanden und es einfach gelassen, wo es ist. Aber treffend erklären, worauf man nach dem Stop/Purge verzichtet, kann ich auch nicht. Kannste kurz was dazu sagen?

  • Aber es gibt was anderes, was mich total irritiert... ich hab das jetzt noch mal kontrolliert : ich kann bei einer neuen IPv6-Freigabe in der Fritte keine vollständige IPv6 für den Zielhost eingeben, sondern nur eine Interface-ID. Wie unterscheidet die Fritte, wenn das NIC des Zielhosts mehrere IPv6 hat, also fe80::$(MacID), fd00::$(MacID) und 2003::$(MacID)? In IPv6-Sprech hat der OpenVPN-Host also eine LLA, eine ULA und eine GUA... und alle haben den gleichen Interface-ID.

    Eine vollständige IPv6 ist nicht erforderlich, für die Freigabe. Denn die Freigabe in der v6-Firewall erfolgt immer für die externe/öffentliche IPv6-Adresse des "neuen" border device. Das ist nicht wie bei einer Portweiterleitung.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Eine vollständige IPv6 ist nicht erforderlich, für die Freigabe. Denn die Freigabe in der v6-Firewall erfolgt immer für die externe/öffentliche IPv6-Adresse des "neuen" border device. Das ist nicht wie bei einer Portweiterleitung.

    Ja, das ergibt Sinn... als Ziel im Internet scheint meine Site-ID allein ausreichend zu sein, und als Ziel im LAN reicht dann wiederum der Interface-Identifier der öffentlichen IPv6. Und soweit es die Freigabe im Router angeht, kann man das vermutlich eher als "Erlaubnis zum passieren" verstehen. Die Freigabe des Ports "auf" den Pi als Zielhost ist drin und mit "grün" als aktiv markiert, ebenso wie die schon ältere IPv4-Freigabe.

    Und dennoch scheitere ich hier auf ganzer Linie.. ich kanns einfach nicht testen... oder besser gesagt, ich weiss nicht, wie ich einen Test aufziehen soll, weil mir ein zweiter autonomer IPv6-Account fehlt. Irgendwann hatte ich mal gelesen und erinnere mich vage daran, dass IPv4-Clients im UMTS-Netz auch IPv6 -Adressen erreichen können... das würde über Transition im UMTS-Netz geregelt. Jetzt hatte ich gehofft, auf dem Laptop aktiviere ich den IPv6-Stack und wenn ich mich dann mit einem offenen Accesspoint (mein Handy (Thetering)) verbinde und im OpenVPN-Client des Laptops meine 2003::'er IPv6-Adresse für meinen PI zuhause eingebe, würde das vielleicht "durchgereicht" werden... aber ich krieg keinerlei Reaktion auf dem Server zu sehen. Tja, da ist das Problem: liegts am Client, am UMTS, an DSL-Router zuhause, am VPN-Server...?... das sind einfach zu viele Quellen, die ich nicht separat ausschließen kann... weil mir der 2. Account fehlt.

    Hast Du ne Idee, ob das überhaupt bei solchen Rahmenbedingungen testbar ist? Mir fällt da jetzt nix mehr ein.

  • Hast Du ne Idee, ob das überhaupt bei solchen Rahmenbedingungen testbar ist? Mir fällt da jetzt nix mehr ein.

    Ich mache das mit einem v6-online-scan-tool und mit tcpdump oder einem v6-tcp-Server auf meinem PI.

    EDIT:

    http://www.ipv6scanner.com/cgi-bin/main.py

    http://www.electronicsfaq.com/2012/12/simple…er-sockets.html

    EDIT 2:

    BTW: Benutzt Du einen v6-ddns-Client (... wegen dem dynamischen v6-Präfix)? Wenn ja, wie kommt der mit den aktivierten privacy extensions (für IPv6) klar?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    2 Mal editiert, zuletzt von rpi444 (1. September 2018 um 12:54)

  • Ich gestehe, ich bin jetzt hier mit dieser Baustelle überfordert. Da sind etliche Einflüsse, die ich nicht packen kann.

    - Der Port-Scan (verschiedene) sagen mir alle entweder Port gefiltert oder geschlossen, obwohl der Port geöffnet ist und die Verbindung hergestellt wird.

    - Ich finde keine UDP-Portscanner, dem man einen expliziten Port übergeben kann, sondern nur welche die standard-ports vorgegeben haben

    - ich habe jetzt erwartet, dass der IPv6-OpenVPN-Server auch auf IPv6 lauscht.... tu er aber nicht, nur IPv4

    - wie soll ein IPv6-Paket ankommen, wenn der Server nur IPv4 lauscht

    Es entzieht sich völlig meiner Kontrolle, was in diesem Mischmasch-Dualstack-Netz passiert. Ich krieg das nicht hin.. Nur IPv4 ist easy. Ich vermute, nur IPv6 wird man ohne Störeinflusse auch hinkriegen. Aber dieser lokale Mischmasch von beiden mit einem undurchsichtigen Dualstack.... :conf: ...

    Der Link nach electronicsfac ist klasse... habe ich sofort gebunkert, die Binaries für armhf und amd64 erstellt und getestet... funktioniert. Danke! Ich hatte so ein Tool schon für UDP und hab mir ansonsten mit netcat geholfen. Aber diese 4 sind auch gut... und lehrreich.

    Benutzt Du einen v6-ddns-Client

    Nee, ich hatte gedacht, ich könnte die 2003::'er Adresse auch direkt verwenden.... aber es scheint - wenn ich das richtig interpretiere- , also würde mir dabei die 4to6-transition fehlen. Deswegen könnte ich mir vorstellen: 4 zu 4 ist problemlos, 6 zu 6 ist problemlos ... aber 6 (über 4-UMTS) zu 6 funktioniert nicht, da brauchts wohl den DNS oder so. Und dann auch noch die Tatsache, dass mein OpenVPN-Server gar nicht auf 6 lauscht, aber trotzdem 6 an die entfernten Clients via Router-Advertisement verteilt.... ich kriegs nicht mehr auf die Reihe. :conf:

    wegen dem dynamischen v6-Präfix)? Wenn ja, wie kommt der mit den aktivierten privacy extensions (für IPv6) klar

    Das hat nach meinem Vertändnis keine Bedeutung. Die Temp-Addr wird nur bei Outbound präferiert. Bei Inbound ist es meiner Meinung nach egal, ob man die PE- oder die MAC-basierte nimmt. Und die MAC-basierte kriegt genau wie die andere bei jeder Zwangstrennung auch den neuen Prefix.... das handhabt SLAAC hier bei mir einwandfrei. Und theoretisch könnte man dem NIC mit dem aktuellen Prefix ja auch einfach einen ip addr add dev $(NIC) $(Prefix)::2 vergeben, also einfach einen Interface-Indentifier "2"... müsste imho doch genau so gehen. Und Outbound spielt die auch keine Rolle, da wird immer die PE-Adresse genommen.

    Einmal editiert, zuletzt von WinterUnit16246 (1. September 2018 um 16:35)

  • ich habe jetzt erwartet, dass der IPv6-OpenVPN-Server auch auf IPv6 lauscht.... tu er aber nicht, nur IPv4

    Du hast proto udp6 in der Server-config?

    nd theoretisch könnte man dem NIC mit dem aktuellen Prefix ja auch einfach einen ip addr add dev $(NIC) $(Prefix)::2 vergeben, also einfach einen Interface-Indentifier "2"..

    Dafür setzt man einfach einen token und hat immer schön les-/merkbare Adressen :)

    /sbin/ip token set ::beef dev eth0

    Wenn du nichts zu sagen hast, sag einfach nichts.

  • Das hat nach meinem Vertändnis keine Bedeutung. Die Temp-Addr wird nur bei Outbound präferiert. Bei Inbound ist es meiner Meinung nach egal, ob man die PE- oder die MAC-basierte nimmt.

    Das verstehe ich nicht, denn wenn bei Outbound Temp-Addr präferiert wird, was würde der v6-ddns-Client dann nehmen? Doch die mit der Temp-Addr? Und kann man mit der PE-basierten deinen PI per OPv6 aus dem Internet erreichen, wenn in der FritzBox die IPv6-Freigabe doch für die MAC-basierte konfiguriert worden ist?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Das verstehe ich nicht, denn wenn bei Outbound Temp-Addr präferiert wird, was würde der v6-ddns-Client dann nehmen? Doch die mit der Temp-Addr? Und kann man mit der PE-basierten deinen PI per OPv6 aus dem Internet erreichen, wenn in der FritzBox die IPv6-Freigabe doch für die MAC-basierte konfiguriert worden ist?

    Bei IPv6 ist es ja so, dass das Interface mehrere IP-Adressen haben kann, sogar mit der gleichen Site-ID.... das heisst, ich bin davon ausgegangen, dass man dem DDNS-Client sowieso mitteilen muss, welchen statischen Interface-Identifier er nimmt.. ob der nun MAC-basiert ist oder nicht, ist doch egal. Und der wird dann in der Freigabe auch eingetragen. Wenn das NIC eine lokale manuelle IPv6 (2003::GUA) mit der statischen InterfaceID ::2 enthält,, so kannst Du die auch als Freigabe im Router eintragen, wenn Du dem DDNS-Client mitteilst, dass er ::2 verwenden soll. Alles andere würde mich total überraschen. Das hat meiner Meinung auch gar nix mit den PE zu, es ist nur ein Static-Eintrag an drei Stellen: NIC, DDNS-Client und Freigabe. Und für lokalen vom PC initiierten Outbound wird dann trotzdem die PE-IPv6 genommen. Wenn das anders wäre, hab ich das falsch verstanden.

  • [OT]

    darf ich fragen, warum?

    [/OT]

    Ich kills seit rpi444's Erinnerungs-Hinweis auch wieder... jeztzt nachgeholt... durch die bank..... ich hatte das früher schon immer gekillt, aber irgendwie zwischenzeitlich aus den Augen veloren und schlichtweg vergessen.Man braucht es im Normalfall einfach nicht. Das ist im Normalfall mit am Router angeschlossenen Geräten ein völlig unnötiger Dienst.

  • meinst Du mit Probleme (im Link von Beitrag #7) die Avahi "Probleme mit ipv6", weil die Bonjour Namensauflösung defaultmäßig abgeschaltet*1 sein soll?

    *1 Kommentar von Alex

    Naja, ich hatte avahi schon vor dem Erscheinen/Einführen von IPv6 nicht benutzt, weil ich immer wieder "Unklarheiten" im (lokalen) DNS, DHCP und in diversen VPNs (tap) hatte. In meinem (W)LAN macht die FritzBox die lokale Namensauflösung und ich will auch selber genau konfigurieren (dhcp, dns, no-dhcp, etc.), wer mit wem wann kommunizieren kann/darf.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • ..., ich bin davon ausgegangen, dass man dem DDNS-Client sowieso mitteilen muss, welchen statischen Interface-Identifier er nimmt.. ob der nun MAC-basiert ist oder nicht, ist doch egal. ...

    OK, aber das "Wichtigste" für den DDNS-Client ist hier jetzt nicht die Interface-ID sondern der dynamische IPv6-Präfix, der sich ja alle 24 Stunden ändert. Und wenn das Interfaces mehrere externe IPv6-Adressen hat (und nach außem nur die via PE generierte kommuniziert wird), dann kann (für bzw. durch den DDNS-Client) die "richtige" externe IPv6-Adresse (Präfix + Interface-ID) nicht vom Interface entnommen werden und auch nicht per Web eruiert/ermittelt werden. Das müsste dann mit einem separaten/eigenständigen Script/Programm gemacht werden und so dem DDNS-Client bekannt gegeben werden. D. h., der DDNS-Client muss das auch können bzw. unterstützen.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • OK, aber das "Wichtigste" für den DDNS-Client ist hier jetzt nicht die Interface-ID sondern der dynamische IPv6-Präfix, der sich ja alle 24 Stunden ändert.

    Richtig , aber eine von SLAAC generisch auf der MAC basierend erzeugte Iterface-ID hat was mit einer manuell statisch vorgegebenen Interface-ID gemeinsam? Ganz einfach: beide sind statisch. Was haben sie noch gemeinsam? Beide haben täglich vor der Zwangstrennung die gleiche Site-ID und beide müssen auch nach der Zwangstrennung die neue Site-ID enthalten. Die alte manuell eingerichtete musst Du nach der Zwangstrennung auch manuell löschen und manuell neu einrichten. Danach ist es eine ganz normale GUA mit WWW-gültiger Site-ID.

    Und wenn das Interfaces mehrere externe IPv6-Adressen hat (und nach außem nur die via PE generierte kommuniziert wird),

    Nein, der Rückschluss ist meiner Meinung nach so nicht richtig. Alle GUA sind funktional zunächst mal auf dem Moment bezogen gleich "stark", systemisch wird outbound nur die via PE generierte präferiert, aber das bedeutet nicht, dass die anderen funktional weniger tauglich sind. Die PE-generierte funktioniert nur deshalb nicht als DDNS-Adresse, weil sich die Interface-ID ständig ändert. Aber ich habe gerade mal systemd-networkd gestoppt, alle 2003::'er Adressen von hand gelöscht und eine einzige neue angelegt $(ISP-Prefix)::2/64. Und was glaubst Du, welche IP mir http://ipv6-test.com/ jetzt anzeigt... ganz klar.... natürlich die mit ::2.

    Also, systemisch wird Outbound die PE-generierte präferiert. Inbound würde die PE-basierte nur deshalb nicht funktionieren, weil der Freigabe-Eintrag im Router ein
    statischer ist und weil sich ständig diese PE-Interface-ID ändert. Eine manuelle Interface-ID ist aber wieder statisch. Und wenn Du dich darum kümmerst, dass deren Prefix nach der Zwangstrennung aktualisiert wird, kannnst Du die problemlos nehmen und im Router z.B. diese ::2 eintragen. Ich würde als Schnittstelle nach draußen aus Gründen der Verschleierung sowieso nicht die MAC-basierte nehmen. Aber das ist eine rein subjektive Alut-Hut-Einschätzung. Technisch bezogen aufs VPN hat die eigene Static-Interface-ID imho keine negative Auswirkung.

    Natürlich darf man nicht verschweigen, dass das eine "kleine" weitere Logik beinhaltet... der ISP-Prefix der NIC-IPv6 mit der ::2 muss auch täglich manuell aktualisiert werden.

    Weiss Du was... ich glaube, wir meinen beide dasselbe und schauen auch auf dasselbe, schaffens aber nur noch nicht, die gleichen Worte und die gleiche Perspektive zu finden.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!