UCS Einsatz und Unterstützung IPv6

german
ipv6

#1

Hallo,

die Thematik IPv6 ist für mich Neuland, weshalb ich vielleicht auch allgemeine Fragen stelle:

  1. In wie weit unterstützt UCS IPv6?
  2. In den Netzwerkeinstellungen kann eine IPv6 für das System manuell oder per SLAAC vergeben werden. Wenn noch ein Netzwerkgerät ein DHCPv6 bereitstellt sollte diese Funktion genutzt werden oder reicht SLAAC aus?
  3. Wie kann UCS als primärer DNS an alle Clients verteilt werden?
  4. Sollte sich die v6 Adresse z.B. alle 24 Stunden ändern, kann es hierdurch Probleme geben, da es kein NAT mehr gibt?

#2

Alles was ich brauche geht in meinem Dualstack-Setup.

Kommt drauf an was man will. Server und was ich erreichen können muss setze ich immer manuell und alles andere per SLAAC. Ich selbst habe im Moment keinen Bedarf an DHCPv6. Braucht man IMO nur wenn man etwas speizeilles braucht, z.B. Routen.

Das ist eine meiner Baustellen. Normalerweise dann man das über das Router-Advertisment regeln:
https://tools.ietf.org/html/rfc6106
Meine Firewall die das Routeradvertisment macht unterstützt das aber nicht, weshalb ich wieder über DHCPv6 nachdenke :frowning:

Für Clients: nein. Für Server: ja, deshalb setze ich da zusätzlich feste IPs, siehe oben


#3

Moin,

Größtenteils sehr gut. Allerdings gibt es Einschränkungen, z.B.:

  • Eine IPv6-native Umgebung ohne IPv4 ist nicht möglich. Dafür gibt es zu viele Orte im System, an denen angenommen wird, dass der Server eine IPv4-Adresse hat.
  • IPv6-Adressverteilung (SLAAC, DHCPv6) kann anders als IPv4-Adressverteilung nicht übers LDAP/die UMC gemanaget werden und muss daher manuell konfiguriert werden.

Hängt leider sehr davon ab :slight_smile: DHCPv6 und SLAAC bieten unterschiedliche Featuresets — und unterschiedliche Betriebssysteme unterstützen unterschiedliche Subsets. Z.B. kann Android kein DHCPv6, dafür kann man aber nicht alle Informationen über SLAAC übertragen, die per DHCPv6 übertragbar sind. Klingt mist? Ist es auch. Oft macht mann daher einen Mischbetrieb, bei dem man sowohl SLAAC als auch stateless DHCPv6 fährt (Adressverteilung erfolgt dabei über SLAAC; DHCPv6 wird nur für Zusatzinfos wie DNS-Server, NTP-Server etc. benutzt — aber auch diese Informationen werden, soweit möglich, per SLAAC übertragen).

Via stateless DHCPv6 und SLAAC, sinnvollerweise gleichzeitig (der radvd unterstützt Verteilung von DNS-Server und DNS-Suchliste via SLAAC aka RFC 6106).

Dynamische IPv6-Adressen sind für Serverdienste ein Problem, weil pro Adresswechsel die Konfiguration diverser Dienste (und DNS-Einträge) angepasst werden müsste. Leider ist das alles andere als trivial, da bei SLAAC der Linux-Kernel derjenige ist, der die Adresswechsel mitbekommt und vornimmt. Das ist anders als bei DHCP(v4/v6), wo es ein User-Space-Programm ist, das die Adresswechsel vornimmt und bei jedem Adresswechsel entsprechend externe Programme starten kann. Der Kernel kann das bei SLAAC hingegen nicht.

Eine etwas unschöne Möglichkeit, das zu umgehen, ist die Verwendung statischer Unique Local Addresses im lokalen Netz, und diese dann per 1:1 NAT am Router auf das jeweils gültige öffentliche IPv6-Netz umzumappen. Das muss der Router aber unterstützen, und es funktioniert potenziell nicht gut mit Protokollen, die lokale Serveradressen im Payload verwenden (z.B. FTP).

Kurz: wenn’s irgend geht vermeiden und statische, öffentliche IPv6-Adressen besorgen.

Wir nutzen seit langem IPv4+IPv6 in unserer Univention-Umgebung, inzwischen ohne echte Probleme.

Gruß
mosu


#4

Und das konfiguriert man im UCS DHCP wie? :slight_smile: Könnte ich nämlich gut brauchen …


#5

Moin,

unter UCS hab ich’s selber noch nicht gemacht, aber es läuft genau so, wie z.B. hier beschrieben. Da der DHCPd nicht gleichzeitig im v4 und v6-Modus laufen kann, legt man eine komplett neue Konfigurationsdatei (z.B. /etc/dhcp/dhcpdv6.conf) an. Wenn man stateless DHCPv6 nutzen will, dann verzichtet man in der Konfigurationsdatei schlicht auf alle range6-Anweisungen.

Die Optionen anzugeben, ist ziemlich trivial, z.B.:

default-lease-time 2592000;
preferred-lifetime 604800;
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
allow leasequery;

option dhcp6.name-servers 2001:db8::feed:1;
option dhcp6.domain-search "mbu-test.intranet";

subnet6 2001:db8::/64 {
}

Dann muss man kurz die Lease-Datei anlegen: touch /var/lib/dhcp/dhcpd6.leases

Und zu guter Letzt noch eine systemd-Unit (z.B. /etc/systemd/system/dhcpdv6.service) dafür geschrieben:

[Unit]
Description=ISC DHCPv6 daemon
After=network-online.target
Wants=network-online.target
Conflicts=shutdown.target

[Service]
ExecStart=/usr/sbin/dhcpd -q -f -6 -cf /etc/dhcp/dhcpdv6.conf

[Install]
WantedBy=multi-user.target

Starten:

systemctl daemon-reload
systemctl start /etc/systemd/system/dhcpdv6.service
systemctl enable /etc/systemd/system/dhcpdv6.service

Für SLAAC installiert und konfiguriert man schlicht den radvd.

Gruß
mosu


#6

Hallo,

danke für die ausführlichen Beschreibungen.

Den ISC DHCPv6 Server und radvd kann ich z.B. mit auf dem UCS Master installieren oder bedarf es hierfür einen eignen Server?

Auf dem Router habe ich jetzt ULA aktiviert. Was trage ich jetzt bei Servern mit statischer IPv6 ein? Also, wenn ich es richtig verstehe wechselt bei aktiviertem ULA nur noch der Präfix und die Teilnetz- und Schnittstellen-ID bleiben gleich. Oder liege ich da falsch?


#7

Moin,

Der ISC DHCP-Server ist vermutlich eh schon installiert, denn er ist derjenige, der von Univention auch für DHCPv4 verwendet wird (selbes Paket, selbes Binary, nur mit anderen Optionen gestartet). Kann also definitiv auf einem DC Master installiert werden. Der radvd kann ebenfalls dort installiert werden; er wird halt nur von Univention nirgends selber benutzt.

Beides gilt natürlich nur dann, wenn der DC Master im selben Netz hängt, wie die Geräte, für die er Adressen bereitstellen soll.

Das Präfix bei ULAs ist genau wie die privaten Bereiche bei IPv4 frei wählbar — z.B. fd01:0db8:0815:0000:… oder kurz fd01:db8:815:/64. Was man dann mit dem Netzanteil macht, hängt halt davon ab — man kann hierfür SLAAC machen, aber zumindest für Server empfiehlt sich eine feste Zuteilung. Auch wenn man bei SLAAC durch die MAC-Adresse vorgegeben meist immer die gleiche Adresse bekommt, so sind kurze Adressen doch schlicht einfacher merkbar und, wichtiger, bei einem Wechsel der Netzwerkkarte ändert sich dann nicht gleich die IPv6-Adresse. Oft ist die …:1 der Router, und ab dann zählt man stupide hoch (oder nimmt eines von vielen, vielen weiteren möglichen Schemata).

Für Clients nimmt man dann der Einfachheit halber SLAAC.

Der Router sollte dann bei 1:1-NAT den ULA-Präfix durch den gerade gültigen global unicast prefix (das Äquivalent zu öffentlichen IPv4-Adressen) ersetzen, z.B. aus fd01:db8:815::42 dann 2001:db8:47:11::42 machen. Der Interface-Identifier sollte dabei erhalten bleiben.

Gruß
mosu


#8

Moin,

warum kann die IPv6 config bei UCS nicht schon direkt im Installer vorgenommen werden (z.B. Aktivierung SLAAC)?
Gibt ULA eigendlich mehr Sicherheit, ds Server und Clients nicht direkt aus dem Internet erreichbar sind?


#9

Moin,

vermutlich, weil das Gros der Nutzer bisher noch nicht mit IPv6 arbeiten (was in der Tat eine echte Schande ist).

Nicht wirklich. Sicherheit kommt nicht durch Nicht-Erreichbarkeit, sondern durch die Verwendung von Firewalls. NAT ist keine Sicherheitstechnik (auch bei IPv4 nicht).

Der Nachteil der Verwendung von ULAs ist generell der erhöhte Administrationsaufwand. Ich hab alle Situationen bei uns und Kunden durch:

  1. Nur öffentliche Adressen, sowohl intern als auch in der DMZ
  2. Intern nur ULAs, DMZ nur öffentliche
  3. Intern und DMZ sowohl ULAs als auch öffentliche

Die gleichzeitige Verwendung von beidem hat in der Praxis erhebliche Nachteile: man muss vor allem bei Firewallregeln höllisch aufpassen, weil man immer beide Netze berücksichtigen muss, und zum Anderen muss man sich damit auseinandersetzen, welche Quell-Adresse ein Client jeweils wählt und was das aus Firewall- und Daemon-Konfiguration-Sicht bedeutet (allein dafür gibt es ein eigenes RFC 6724 und Artikel für Linux). Weiterhin sind Protokolle problematisch, die die Adresse des Clients im Payload und nicht nur in den Headern verwenden, denn hier muss das NATende Gateway nicht nur die Paketheader, sondern auch den Payload verändern, was bei verschlüsseltem Payload dann z.B. gar nicht mehr geht; Beispiele dafür ist FTP (das gleiche Problem hat FTP aus dem gleichen Grund mit IPv4 bzw. generell mit NAT).

Natürlich haben ULAs auch Vorteile, z.B.: Ändern sich die öffentlichen Netzbereiche, so muss man deutlich weniger Geräte (Firewalls, Router) und Software (allem voran DNS-Server) umkonfigurieren.

In Summe bin ich von meiner Erfahrung her ULAs gegenüber eher abgeneigt. Die Komplexität ist erheblich (und im Vorfeld nicht wirklich offensichtlich), und der Gewinn eher gering.

Gruß
mosu


#10

Da ich zu meiner Schande auch noch nicht umgestellt habe: Gilt das deiner Meinung nach auch, wenn man nur dynamisches IPv6 bekommen kann?


#11

Moin,

wie ich oben geschrieben habe, halte ich dynamische Adressen zusammen mit Serverdiensten für mindestens ungüstig und im Fall von IPv6 für gar nicht sinnvoll handlebar (weil DNS-Updates nach Adressänderung durch SLAAC ein riesiges, ungelöstes Problem darstellen).

Wenn Sie in der Tat nur dynamische IPv6-Adressen bekommen, so können ULAs ein Weg sein, der aber halt erfordert, dass Ihr Router 1:1-NAT ganzer Netzwerke unterstützt.

Gruß
mosu


#12

Das tut pfSense (und auch der Fork OPNSense) derzeit AFAIK nicht. Dann heißt es erstmal weiter warten.


#13

Hallo,

nach der Einrichtung von IPv6 auf dem Master wurde von UCS automatisch der folgende rDNS Eintrag angelegt: fd00:0000:0000:0000, dieser zeigt wiederrum auf den Hostname vom Master. Warum fängt dieser Eintrag mit fd an und nicht mit fe80, wie es intern bei einem ULA-Netz sein soll? Auch die IP vom Master fängt mit fe80 an.

Über IPv4 sind die Hosts (UCS Member) direkt über den Hostname oder FQDN erreichbar. Es existiert aber kein entsprechender Eintrag im DNS, wie können diese nun trotzdem aufgerufen werden?
Über IPv6 ist dies nicht möglich, wahrscheinlich weil kein DNS Eintrag existiert. Hierfür müsste dann einer angelegt werden, welche auf die IPv6 der UCS-Memberserver zeigt?

Ich hatte gelesen, dass der radvd auf einem Linux Gateway Router installiert werden soll. Ist dies zwingend erforderlich? Und wenn ja, wie konfiguriere ich UCS zum Gateway für v6? Wie nennt sich das Paket radvd unter UCS als Installationskandidat?

Der DHCPv6 kann aber auch, wie der DHCPv4, unabhängig vom Gateway installiert werden?


#14

Moin,

Adressen aus dem Bereich fe80::/10 sind link-local unicast addresses. Diese dienen ausschließlich der direkten Kommunikation zweier Knoten im selben Netzwerk. Die Adressen sind lokal für die jeweilige Netzwerkschnittstelle gültig, für mehr nicht. Man sollte diese Adressen definitiv nicht im DNS pflegen.

Die ULAs sind der Bereich fc00::/7. Der Bereich fc00::/7 ist noch mal in zwei Unterbereiche aufgeteilt, von denen einer der fd00::/8 ist. Bevor ich hier alles wiederhole, empfehle ich einfach die Lektüre dieses Artikels (und generell von Einführungsartikel in IPv6…).

Da man fe80::/10 nicht im DNS einträgt, vermutet das UCS vermutlich, dass fd00::/8 gemeint war.

Über link-local ULAs gar nicht. Nur über ULAs oder andere Unicast addreses with global scope (= öffentliche Adressen). Im Browser wäre das dann z.B. https://[2001:db8:4711::815]/. Sinnigerweise legt man dafür DNS-Einträge an.

In der UMC das Rechnerobjekt öffnen, IPv6-Adresse hinzufügen, Mapping zu Namen im DNS-Bereich
für die IPv6-Adresse hinzufügen, speichern.

Ja. Man konfiguriert radvd auf allen Geräten, die als Router für bestimmte IPv6-Subnetze fungieren (oder halt als IPv6-Default-Gateway). Wenn z.B. das UCS ein VPN zu einem anderen Netz aufbaut und das entfernte IPv6-Subnetz für das lokale Subnetz als routebares Netz bekannt geben will, dann würde man auf dem UCS-System den radvd das entferne Subnetz ausstrahlen lassen. Damit wüssten alle Clients im lokalen Subnetz: aha, das entferne Subnetz erreiche ich über den UCS-Server, auch wenn z.B. das IPv6-Default-Gateway gar nicht das UCS-System sondern ein anderes ist.

Routing im Kernel einschalten, Firewall konfigurieren, damit Pakete erlaubt werden.

radvd. Das unmaintained-Repository muss aktiv sein.

Ja.

Gruß
mosu