Synology-NAS: IPv6 für eine mit nftables handgemachte DMZ

[ClausT]

Wo sind denn die öffentlichen IPv6-Adressen/-Netze (anonymisiert)?

In der Fritte natürlich.
Ich möchte zuerst mal ein rein lokales Netz hinbekommen, in welchem der Client die Fritz!Box durch den Router hindurch erfolgreich anpingen kann. Das muss ja möglch sein, bei IPv4 mit NAT-Forwarding und bei IPv6 halt mit reinem Routing. wenn das funktioniert, ist die Umstellung auf eine öffentliche IPv6 der nächste Schritt.

Wo zauberst Du denn grade ens5 her?

So heißen die Interfaces nun mal.
Der Client hat nur ens3.
Der Router hat ens3 = WAN zum Heimnetz der Fritz!Box, ens4 = WAN zum Gastnetz der Fritz!Box und ens5 = LAN
ens3 und ens4 machen DHCP, ens5 ist statisch.

Den Wiki-Artikel sehe ich mir natürlich an.

 

[Barungar]

ip -6 route show

fd76::15f dev ens3 proto kernel metric 256 expires 3011sec pref medium
fd76::/64 dev ens3 proto kernel metric 256 expires 3510sec pref medium
fd76:7ab:5f94::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
default via fe80::11:32ff:fe2a:7c8 dev ens3 proto ra metric 1024 expires 1710sec hoplimit 64 pref medium

Da sollte doch eigentlich ein Ping an die ULA der Fritte über ens3 an den Router gehen und dort von ens5 an ens3 geroutet und zur Fritte geschickt werden.
Aber es kommt ein " Address unreachable"
Und nftables loggt auch nix in der forward-chain

Hat die "Fritte" auch einen Rückweg? Klar, ens3 ist im IPv6-Subnetz der Fritte. Daher sollte ein Ping von ens3 an die Fritte funktionieren und eine Antwort erhalten. Ein Ping von ens5 über ens3 mag sogar bei der Fritte ankommen... hier hilft ggf. ein Paketmitschnitt an der Fritte. Aber wie soll sie antworten, wenn sie das Subnetz von ens5 nicht kennt?

 

[ClausT]

Wieder einen Schritt weiter:
Der Wiki-Artikel hats gebracht.
Der sorgt für die Routing-Funktionalität im Router, weil er das RA von ens3 auf ens5 überträgt und an den Client weiter reicht.
Damit hat der jetzt eine Adresse mit 2a02 am Anfang und kommt ins Internet.

Aber:
Das DHCP vom Router basiert noch auf dem isc-dhcp-client, der ja als veraltet gekennzeichnet ist
Und das RA auf radvd, was laut https://www.hveem.no/using-dnsmasq-for-dhcpv6 gar nicht mehr erforderlich sein soll.

Also mache ich jetzt erstmal einen Snapshot vom Router, stelle DHCP auf wide-dhcpv6-client um und und teste mal, ob das RA auch mit dnsmasq alleine funktionert.
Und danach ist dann die halb-feste IP vom Client dran.

Gruß
Claus

 

[ClausT]

Was für ein mühsames Vorhaben...

Vorbemerkung:
Es ist enorm hilfreich, beim Rumspielen mit der Netzwerkkonfiguration eine Konsole und ein Backup/Snapshot zu haben.
Zu schnell hat man sich nämlich auch mal ausgesperrt.

Bevor ich mich traue, am Router was zu ändern, teste ich das lieber erstmal mit einem Client.
Hier ist das mein Rustdesk-Server, der an ens5 = DMZ hängt.
Der erste Versuch mit wide-dhcpv6-client ist gescheitert.
Selbst mit einer Minimalkonfiguration hat er keine Adresse vom Router bekommen.
Das habe ich nur ansatzweise weiter verfolgt und das Programm wieder deinstalliert.
Der nächste Versuch mit dhcpcd war dann schon deutlich erfolgreicher.
Nach dem Installieren konnte ich ohne jede weitere Konfiguration ens3 von dhcpcd neu zuweisen lassen.
Also habe ich da - durch einen Snapshot abgesichert - dhclient deinstalliert und die VM neu gestartet.
Et voila - IPv4 und IPv6 sind da und ein ping -6 ins Internet ging auch.

Jetzt der Router.
Da ergibt sich eine Schwierigkeit:
Wenn man nach Informationen zu Linux DHCP Clients sucht, beschäftigen sich die allermeisten Treffer nur mit IPv4.
Und beim Rest taucht in der Regel irgendwo /etc/network/interfaces auf.
Die wird aber beim dhcpcd gar nicht mehr benutzt.
Dort ist alles in der /etc/dhcpcd.conf konfiguriert.
Das habe ich gemerkt, als ich ohne dhclient neu gebootet hatte und nicht mehr an die DMZ kam.
Ohne Eintrag für ens5 hat der dhcpcd dafür natürlich eine Autokonfiguration mit einer 169.254er-Adresse gemacht.
Deshalb hier meine aktuelle Konfiguration, die ich am Ende der /etc/dhcpcd.conf eingefügt habe:

# use the interface connected to WAN for Prefix Delegation
interface ens3
    ipv6rs
    iaid 1
    ia_pd 2 ens5/0/64  # request prefixes

#interface ens4
#    noipv6

interface ens5
    static ip_address=172.16.69.1/24

Mehr ist tatsächlich nicht erforderlich, nicht einmal ein Skript zur Übernahme der Prefix Delegation von ens3 nach ens5.
Das ist mir sehr sympatisch.
Genauso, dass das Programm als Dienst läuft und eine Service-Datei mitbringt und damit mit systemctl verwaltet wird.
Und dass man einzelne Interfaces gezielt mit dem CLI beeinflussen kann.

Nebeneffekte:
Beim Booten hat ifup@ens3.service ein Problem.
ifup scheitert aus irgendeinem mir noch nicht bekannten Grund.
Das bleibt jetzt aber erstmal liegen, weil auch mit dem Fehler alles funktioniert.
mosquitto.service wollte auch nicht mehr beim Boot starten.
Nach dem Boot ging ein händischer Start aber ohne Probleme.
Die Analyse brachte als Fehler, dass er sich nicht an eines der Interfaces binden konnte.
Da hatte ich gleich ens5 im Verdacht, weil das ja erst vom dhcpcd konfiguriert wird.
Der Service hat nur das Netzwerk als Abhängigkeit.
Also habe ich eine /etc/systemd/system/mosquitto.service.d/service.conf angelegt:

[Unit]
After=dhcpcd.service
Requires=dhcpcd.service

Jetzt spielt der auch wieder und versorgt die Shellys im Gastnetz mit Kommandos.

So weit schon mal.

Gruß
Claus

P.S.: radvd ist jetzt übrigens auch nicht mehr erforderlich

 

[ClausT]

Nachtrag:
Die Erweiterung für mosquitto hat nicht gereicht.
Der Service ist vermutlich zu schnell am Start - noch bevor die Interfaces vollständig konfiguriert sind.
Als Umgehung lasse ich den Service als ExecStartPre noch 5 Sekunden warten.
Das hat gereicht.

Jetzt die IP mit dem festen Interface Identifier.
Dazu steht in der dnsmasq.conf ein
dhcp-host=id:00:...:e7, , [::237]
Zuerst hat der Client immer nur eine dynamische IP bekommen und die feste nicht.
Irgendwann habe ich einfach mal beide Hosts neu gebootet und Überraschung - die IP ist da:
inet6 2a02:xxxx:xxxx:85d8::237/128 scope global dynamic noprefixroute valid_lft 40488sec preferred_lft 40488sec

Und die FritzBox scheint den Weg auch zu kennen:
Delegiert 2a02:xxxx:xxxx:85d8:: / 62

Der erste Test war natürlich ein Ping vom Router aus.
Der hat funktioniert.
Dann mit in nftables aktiviertem Logging ein Ping von einem Host im Heimnetz.
Der hat auch funktioniert.
Dann mit einem Service im Internet: Destination Host Unreachable
Und ein traceroute hört bei der FritzBox auf.
Das sieht nach einem Routing-Problem in der Fritte aus, was ich aber (noch) nicht verstehe.
Die sollte doch den Weg zu 85d8 kennen.

Ach so: Als IPv6 Interface-ID habe ich 0:0:0:237 eingetragen und auch die Haken bei
PING6 freigeben und
Firewall für delegierte IPv6-Präfixe dieses Gerätes öffnen
gesetzt.

Gruß
Claus

 

[ClausT]

So langsam wird mir NAT immer sympatischer...

Also:
Die FritzBox hat im vierten Block ein 8fc0 und stellt eine /56-Adresse für Subnetze zur Verfügung.
Der Rest der IP ist eigentlich nicht von Interesse.
Das nimmt der Router per PD entgegen und verwendet es für sein Subnetz an ens5.
Deshalb bekommt ens5 die Adresse 85d8::1
Die ersten drei Blöcke stammen von ens3.

Jetzt zur Fritz!Box:
Das gibt es entweder Pakete, die für sie selbst bestimmt sind.
Dafür gibt es entweder einen Dienst der Box selbst, der lauscht.
Für Pakete für andere Hosts im Netzwerk gibt es drei Lösungen: Portweiterleitung, Portfreigabe und statische Routen.
Für IPv4 gibt es die Portweiterleitung, die mit NAT nach innen weiter gereicht wird.
IPv6 kennt kein NAT und nur Routing.
Also kann die Fritte nur Pakete weiter leiten, zu der sie Routing-Informationen hat.
Dafür git es zum Einen die Portfreigabe.
Da trägt man die letzten 4 Böcke ein und die Fritte packt ihren Prefix davor, also ::85c0
Damit ist zwar ens3 mit seine 85c0-Adresse ens5 vom Router auf diesem Weg erreichbar, ens5 mit 85d8::1 aber nicht.
Eigentlich kennt die Fritte die delegierten Subnetze und damit auch 85d8::/62 - das steht so bei den IPv6-Infos.
Sie scheint aber nicht auf die Idee zu kommen, dafür eine Route zu dem Host einzurichten, der diese PD angefordert hat.
Sonst wäre 85d8::1 ja ohne weiteres Zutun von außen anpingbar.
Dann gibt es noch statische Routen.
Bei IPv4 trägt man Netzwerk und Gateway mit der vollen Länge ein.
Bei IPv6 ist leider genauso.
Da sehe ich nix mit dynamischem Prefix.

Bleibt also eigentlich nur die Portfreigabe.
Damit werden alle Pings und die Pakete für freigegebene Ports an den Router durchgereicht.
Ping geht damit zwar nur bis zum Router - das war bei IPv4 aber auch schon so.
Die anderen Pakete müssten dann je nach Port zur passenden Zieladresse an ens5 weiter gereicht werden.

Frage deshalb: Kann nft auf ens3 eingehende Pakete für einen bestimmten Port an eine Adresse an ens5 umrouten nur unter Angabe der letzten 4 Blöcke der IPv6?

Gruß
Claus

 

[Barungar]

Sie scheint aber nicht auf die Idee zu kommen, dafür eine Route zu dem Host einzurichten, der diese PD angefordert hat.

Die musst Du halt einrichten... dafür gibt es auch passende Optionen, die die Route (dynamisch) generieren.

 

[ClausT]

Die MyFritz-Freigabe sorgt dafür, dass die korrekte IPv6 und die IPv4 im A/AAAA-Record landet

Ähm - nö.
Die MyFritz-Adresse ist ::85c0::237 - ja, die Notation ist so nicht erlaubt, zeigt aber das Problem.
Die Fritz!Box geht bei MyFritz-Freigaben immer davon aus, dass der Host im Heimnetz der Box ist.
Die korrekte Addresse ist aber ::85d8::237

Die musst Du halt einrichten... dafür gibt es auch passende Optionen, die die Route (dynamisch) generieren.

Ich habe zusätzlich mal eine MyFritz-Freigabe für den Router und einen nicht genutzten Port eingerichtet.
Damit müsste ein Ping auf ens5 des Routers mit der Adresse ::85d8::1 durchgehen.
Tut es aber nicht.

 

[Barungar]

Ich muss ehrlich sagen, ich blicke durch eine Konstellation nicht durch. Du brauchst aber keine "Freigabe" für einen Host im delegierten Netz anzulegen. Weil die FritzBox grundsätzlich "Firewall für delegierte IPv6-Präfixe" freigibt, wenn Du (siehe Post) den entsprechen Haken bei dem Host setzt, der die Delegation anfordert.

Und ja, die MyFritz-DynDNS Funktion scheiert in diesem Fall. Du musst also das DynDNS auf den Host verlagern, wenn er sich in einem delegierten Präfix befindet.