Unitymedia IPv6 - steh völlig aufm Schlauch

[toppi]

Hi,

bitte nicht lachen. Ich mache gerade meine ersten Gehversuche mit IPv6. Ich möchte gern PI-Hole hinter meiner FB mit Dual-Stack betreiben.

Dazu muss ich ein Docker macvlan anlegen. Dazu benötige ich das IPv6 Subnetz. Und jetzt die Frage....wo steht das in der Firtzbox?

Gateway ist klar. Da würde ich mal die IPv6 Adresse der FB nehmen

Ich sehe den Wald vor lauter Bäumen irgenwie nicht....

Falls wer einen Tip hat würde ich mich wie verrückt freuen.

 

[Conan179]

http://www.ipv6-portal.de/tools/subnet-tabelle.html
einfach mal durch lesen.

 

[toppi]

Danke erstmal.

Aber habe ich denn nicht irgendwie auch intern ein Subnetz für IPv6?

Also UM weist mir ein IPv6 Netz zu. Aber das benutze ich doch gar nicht. Der interne DNS Server muss doch in einem eigenen IPv6 Subnetz Adressen vergeben, die erstmal nichts mit dem öffentlichen, mir zugewiesenen Netz zu tun haben, es sei denn, ich ändere das in den Einstellungen. Oder bin ich komplett auf dem Holzweg?

 

[Conan179]

klar, aus deinem /56(oder /59 in nrw) kannst du jederzeit ein kleines subnetz raus trennen. Wie genau weis ich nicht, man nimmt dan /80 oder so.

 

[Andreas1969]

oder /64 in nrw

59 in NRW :winken:

 

[Conan179]

Ha! hatte ich es doch falsch im kopf gehabt!

 

[why_]

klar, aus deinem /56(oder /59 in nrw) kannst du jederzeit ein kleines subnetz raus trennen. Wie genau weis ich nicht, man nimmt dan /80 oder so.

Aus einem /56 ein /80 zu machen wäre jetzt nicht die beste Wahl falls man da Endgeräte wie Android betreiben möchte. Das wird normalerweise ein /64 damit SLAAC funktioniert.

 

[Conan179]

ich schreib aber auch "Wie genau weis ich nicht," und "oder so".
mein hetzner server hat eine /64 bekommen und hab einen kleinen teil auf meinen openvpn verbindung abgezwackt (ok, da hab ich die /80 her...) die ich aber statisch vergeben, und da geht es, das ist aber eine andere geschichte.

 

[addicted]

"Netze" kleiner als /64 kannst Du dann nur für DHCP-Pools oder statische Zuweisungen nutzen.

 

[boba]

Was möchtest du am Ende haben? Also wenn es fertig eingerichtet ist. Wozu brauchst du das, was du einrichten möchtest?
Ich verstehe dein Szenario nicht, weil du nach deinen Angaben zuhause bereits ipv6 hast. Wozu dann ein subnet von deinem Hetzner Server nach Hause tunneln? Pi-Hole funktioniert bereits ohne sowas problemlos und ohne Einschränkungen.
Wenn man weiß, was du am Ende haben möchtest, kann man schauen, wie der Weg dahin zu bauen ist.

 

[Conan179]

@boba ich hab meinen openvpn verbindungen, die über handy netz nur ipv4 haben, eine ipv6 haben um ipv6 verbindungen herzustellen. DA brauch ich keine hilfe mehr, das läuft schon.
Toppi braucht hilfe, nicht ich.

 

[boba]

Ich komme immer durcheinander, wenn zwei Leute im selben Thread zwei ähnlich aussehende, dann aber doch völlig verschiedene Szenarien besprechen. Da wäre es sinnvoll, das zweite Thema in einem extra Thread zu besprechen.

Ich wollte die Frage eigentlich an @toppi richten - so wirklich verstehe ich nämlich nicht, wozu man überhaupt was aufwendiges wie ein docker-Image in Verbindung mit pi-hole und Fritzbox und einem ipv6-fähigen Unitymedia-Anschluss (sei es dslite, sei es dual stack) braucht. Man baut den pi auf, klemmt ihn ans LAN, richtet gegebenenfalls Filterlisten ein, biegt den in der Fritzbox vergebenen dns-Server auf den pi um, macht ipconfig /renew auf seinem PC oder rebootet ihn, damit die neue DNS Servereinstellung auf den eigenen PC rüberkommt, und fertig.

Ähm, na gut, es gibt dabei natürlich das bislang überall unbefriedigend oder gar nicht gelöste Problem des ipv6 Prefix Wechsels. Der ist ja nicht statisch, viele Programme wollen jedoch fixe ipv6 Adressen eingetragen haben. Bislang gibts dafür kaum praktische und automatisch laufende Lösungen. Serverdienste im LAN fallen fast immer beim prefix-Wechsel auf die Schnauze. Ein (unbefriedigender) Workaround ist, der Fritzbox die Vergabe von ipv6 ULA Adressen zu aktivieren und die ULA Adressen zu benutzen, wenn man via ipv6 Maschinen im LAN ansprechen will. Das ist allerdings sehr aufwendig in der Konfiguration, und die Namensauflösung lokaler Maschinen sowie die lokalen Firewall-Einstellungen auf den lokalen Maschinen gestaltet sich dadurch nicht einfacher.

Ich für meinen Teil habe mich dabei dazu entschieden, ipv6 lokal erstmal einfach so laufen zu lassen wie es via Router Announcement auto-konfiguriert wird, aber meine lokal laufenden Dienste nicht explizit auf ipv6 aufzubohren. So funktioniert es dann auch problemlos. Ich verteile auch keine ipv6 Adresse für meinen lokalen DNS Server. AAAA Records können ja auch via ipv4 abgefragt werden. In ein paar Jahren schau ich dann mal wieder drüber, wie sich das know-how und die Software in dem Bereich weiterentwickelt hat und der prefix-Wechsel besser unterstützt wird. Vor allem im Bereich lokaler DNS-Server in SOHO-Netzen in einer gemischten ip4/ip6 Umgebung.

 

[toppi]

Hi,

@boba: Darauf wird es jetzt bei mir wohl hinauslaufen. Ich installiere auf einem pi. Dann bekommt der alles zugewiesen und gut ist.

Werde mich dann mal in Ruhe mit ipv6 auseinandersetzen.

Danke euch allen!

 

[boba]

Dazu wäre noch zu sagen, dass man anfangen könnte, ipv6 im lokalen Netz genau so zu konfigurieren wie man das mit ipv4 getan hat: dhcp6 Server, eigene Adressvergabe, ULA-Adressen als Äquivalent zu 192.168.x.y, eigene dhcp und dns Konfiguration und so weiter. Damit wirft man jedoch die Auto-Konfiguration über Bord, die in ipv6 eingebaut ist. Man braucht aber z.B. keine ipv6 Adresse via dhcp6 und damit den ganzen Aufwand einer vollständigen dhcp6 Konfiguration, wenn man eine ipv6 die Adresse via SLAAC und Router Announcement bereits frei Haus geliefert bekommt, die auch im Moment des prefix-Wechsels die Clients im Netz perfekt mit diesem Prefix ausstattet.

Nur die Serverdienste sind dafür halt noch unvollständig ausgerüstet. Was mich und meinen pi bzw. meine Linux-Maschinen im LAN angeht: Eigentlich bräuchte ich nur einen hook, der ein Skript startet, sobald sich der Prefix ändert. Dieses Skript könnte dann Serverdienste mit dem neuen Prefix umkonfigurieren bzw. neu starten. Ich habs aber leider nicht hinbekommen. Die Skripte in /etc/NetworkManager/dispatcher.d beispielsweise werden zwar für alle möglichen und unmöglichen Netzwerk-Events aufgerufen, aber ausgerechnet der vom Router veranlasste prefix-Wechsel ist nicht dabei. Auch hooks von dhclient werden nicht ausgeführt. Das macht alles der Kernel, und für den gibts anscheinend keinen hook.

 

[why_]

ULA-Adressen als Äquivalent zu 192.168.x.y,

Warum gehst du mit ULA Adressen? Hat das einen bestimmten Grund, Gegenfalls sogar einen vorteil außer das die sich per VPN über mehrere Standorte Routen lassen?
Ich nehme bei mir immer die Link Local Adressen für den DNS. Die sind Statisch und funktionieren immer. DHCP kaputt oder sonst was verbockt mit dem Netzwerk, per Link Local Adressen kommst du noch an die Kisten ran. Das ist bei den ULA nicht so, Router fällt aus und die ULA Adressen sind weg.

 

[addicted]

ULAs kannst Du genauso statisch konfigurieren wie Link Local. Passiert halt nicht automatisch, aber seit wann hält das irgendwen auf?

 

[toppi]

Hi,

mit dem PI war das jetzt nicht mehr so das Problem. Läuft jetzt!

 

[Wechseler]

Dazu wäre noch zu sagen, dass man anfangen könnte, ipv6 im lokalen Netz genau so zu konfigurieren wie man das mit ipv4 getan hat: dhcp6 Server, eigene Adressvergabe, ULA-Adressen als Äquivalent zu 192.168.x.y, eigene dhcp und dns Konfiguration und so weiter.

RFC 4193 ist nicht äquivalent zu RFC 1918. Es ist eher das Gegenteil:

RFC 4193-Adressen (IPv6 ULA) sind global eindeutig (unique), mit lokalem Scope.
RFC 1918-Adressen (IPv4 private Internets) sind lokal eindeutig, mit globalem Scope.

RFC 1918 werden für den IPv4-Internetzugriff verwendet (globaler Scope), selbst auf der WAN-Seite (siehe Mobilfunk), natürlich müssen NAT-Gateways diese umschreiben, da diese Adressen nicht global eindeutig sind.
RFC 4193 werden nie für den Internetzugriff verwendet (lokaler Scope), sind jedoch (hoffentlich) global eindeutig, müssen also nie umgeschrieben werden. Für den Internetzugriff wird bei IPv6 immer eine andere Adresse mit einem globalen Präfix verwendet.

Damit wirft man jedoch die Auto-Konfiguration über Bord, die in ipv6 eingebaut ist. Man braucht aber z.B. keine ipv6 Adresse via dhcp6 und damit den ganzen Aufwand einer vollständigen dhcp6 Konfiguration, wenn man eine ipv6 die Adresse via SLAAC und Router Announcement bereits frei Haus geliefert bekommt, die auch im Moment des prefix-Wechsels die Clients im Netz perfekt mit diesem Prefix ausstattet.

Man kann DHCPv6 und SLAAC parallel betreiben und Hosts zwei oder mehr Adressen zuweisen. Man kann ihnen mehrere Präfixe geben, zum Beispiel ein lokales (ULA) und ein globales, aus welchem sie selbständig das Richtige auswählen. Sie können also ein Suffix von einem DHCPv6 bekommen und sich zusätzlich eine autokonfigurierte IPv6 zuweisen. Oben drein kommen dann noch die temporären IPv6-Adressen (Privacy Extensions). Das können dann pro Host schon mal vier bis zehn IPv6-Adressen werden.

Nur die Serverdienste sind dafür halt noch unvollständig ausgerüstet. Was mich und meinen pi bzw. meine Linux-Maschinen im LAN angeht: Eigentlich bräuchte ich nur einen hook, der ein Skript startet, sobald sich der Prefix ändert. Dieses Skript könnte dann Serverdienste mit dem neuen Prefix umkonfigurieren bzw. neu starten. Ich habs aber leider nicht hinbekommen. Die Skripte in /etc/NetworkManager/dispatcher.d beispielsweise werden zwar für alle möglichen und unmöglichen Netzwerk-Events aufgerufen, aber ausgerechnet der vom Router veranlasste prefix-Wechsel ist nicht dabei. Auch hooks von dhclient werden nicht ausgeführt. Das macht alles der Kernel, und für den gibts anscheinend keinen hook.

Man kann Serverdienste an statische lokale Adressen binden (dann sind sie nicht aus dem Internet erreichbar) oder an ::, dann reagieren sie auf alle Präfixe. Bei dynamischen Präfixen implementiert man sinnvollerweise ein dynamisches DNS-Update, um das sich entweder der DHCP-Server kümmert oder das die Hosts selbst vornehmen.