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