Statische IPv6 Adressen für Server
IPv6 bietet mit der dynamischen Adresszuteilung per SLAAC einen eleganten Weg, feste und temporäre IP Adressen an Hostsysteme zuzuweisen. Das hat Vor- und Nachteile. Gerade bei Umbauten im Netzwerk müssen spontan völlig unbeteiligte Systeme angefaßt werden. Aber wie minimiert man diese Aufwände?
Zunächst einmal verringert SLAAC, also StateLess Address AutoConfig, den Verwaltungsaufwand für den Netzwerker erheblich: Der Router verteilt ein Prefix, aus dem sich die Hosts im versorgten Netzwerk automatisch bedienen, solange das Prefix gültig ist. Soweit so einfach. Das ganze skaliert auch bestens, weil man mehrere Prefixe pro Router oder auch mehrere Router reinstellen kann und alles gleichzeitig funktioniert. Die Hosts lernen dann halt mehrere IP Adressen mit den dazugehörigen Routern. SLAAC ist damit der Mechanismus, mit dem man leicht und im laufenden Betrieb von einem Provider zum anderen wechseln kann, indem man in einer Übergangszeit beide gleichzeitig anschließt: Renumbering is easy.
Hosts leiten mit SLAAC mehrere IP Adressen aus dem Prefix ab: Zum einen eine statische IP, die i.d.R. aus der MAC Adresse oder einer anderen eindeutigen und dauerhaften Nummer gebildet wird, sowie einen Satz zufällig generierter IPs, die nur zeitweise genutzt werden (Privacy extensions).
Interessant für den Dauerbetrieb sind die festen IPs, die auf anderen Systemen hinterlegt werden: Im DNS und in Konfigurationdateien, Zugriffsbeschränkungen, Firewalls, Datenbanken etc. pp. Ändern sich diese Adressen ungeplant, ist der manuelle und zeitliche Aufwand bis zum reibungslosen Betrieb erheblich.
Linux und Window 2003 leiten die feste IPs von der MAC der jeweiligen Netzwerkkarte nach dem EUI-64 Schema ab. Ist zum Tausch von Technik gezwungen (z.B. durch Hardwareausfall), so bekommen diese Server neue IPs. Zur parallelen Inbetriebnahme eines neues Servers ist das ungemein nützlich: Die Technik wird einfach angesteckt und angeschaltet, schon ist das Gerät unter einer vorhersehbaren IP in einem beliebigen Netzsegment direkt erreichbar.
Erfolgt aber der Funktionsübergang von der alten zur neuen Hardware, ergibt sich ein Problem: Überall wo die alte Maschine mit ihrer IP bekannt war, muß die neue IP verbreitet werden. Eine Änderung im DNS scheint einfach, jedoch gibt es immer noch zuviel Software, die das Ergebnis einer DNS Auflösung nicht regelmäßig (TTL!) überprüfen. Firewalls wie iptables, Netzwerksoftware wie Sendmail und NTP, Datenbanken wie PostgreSQL müssen neu gestartet werden, um die Änderungen mitzubekommen – von den manuell eingetragenen IPs in verschiedenen Geräten und Scripten ganz zu schweigen. Wohl dem, der seine Konfigurationen zentral in Textform abgelegt hat: zgrep -Ri "alteip" /archiv/configs/ liefert zumindest Anhaltspunkte für die manuell anzufassenden Systeme. Aber auch zentrales Deployment und Konfigurationsmanagement generiert nach der Änderung der IP einen heftigen Schluckauf über die vielen betroffenen Systeme.
Um gegen Hardwaretausch besser gefeit zu sein, generiert Window 2008 die feste IP beim Einstellen in ein neues Netzwerk zufällig und speichert diese ab. Nun kann man am Server die Netzkarten auswechseln, ohne daß auf anderen Systemen etwas angefaßt werden muß: Der Hardwaretausch bleibt ein lokales Phänomen. Window 2008 macht die Netzwerkumgebung an der Adresse des versorgenden Routers fest: Ändert sich die default Route nicht, so behält Window auch für andere Prefixe den gleichen Suffix bei: Renumbering ist easy. Ändert sich aber die default Route, ändert Windows die festen IPs. Es genügt also, den Router zu tauschen, um spontanes Chaos für alle versorgten Windows Netze zu generieren. Zwar korrigieren sich die DNS Einträge von allein (wenn man das nicht verbietet), aber die anderen betroffenen Systeme sind ebenfalls überrascht.
Die Anforderungen an "feste IPv6 Adressen" sind also vielfältig und widersprüchlich:
- Hardwaretausch soll nur lokale Aktionen erfordern.
- Neue Hardware soll ohne großen Verwaltungsaufwand versorgt werden.
- Neue Netze sollen ohne großen Verwaltungsaufwand einrichtbar sein.
Bei uns hat sich folgendes Schema als praktisch herausgestellt:
- Router bekommen feste link-lokal Adressen: fe80::<gerät>:<interface>, wobei die Gerätenummer zentral in 0.8.e.f.ip6.arpa. als Wildcard verwaltet wird.
- Da die Routingtabellen praktisch nur Link-Local Adressen enthalten (z.B. bei SLAAC und OSPF), entfällt die Notwendigkeit von offizellen IPv6 Adressen auf Transfernetzen und die Existenz der Reverse-DNS-Zone erweist sich als äußerst nützlich.
- Bei den meisten Routern und Firewalls wird der Link-Local Teil auch für die offiziellen Adressen verwendet, womit ein konsistentes Erscheinungsbild beibehalten wird.
- Für Server ist die Verwaltung in einer zentralen Geräteliste umständlich und unnötig. Da praktisch alle Systeme dual-stack laufen, existiert bereits eine IPv4 Adresse (öffentlich oder privat). Diese übernehmen wir in den lokalen Teil der IPv6 Adresse. Aus 192.168.240.12 wird 2001:db8:x:y:192:168:240:12. Die EUI-64 Beschränkungen für die höchstwertigen Bits existieren nicht, wenn der kennzeichnende "ff:fe" Teil fehlt.
- Ein Windows System kann nur voll dynamisch oder voll statisch konfiguriert werden. Die IPv6 Adresse ergibt sich also aus der IPv4 und dem gültigen Netzprefix, während das default Gateway die schon bekannte Form fe80::<gerät>:<interface> hat.
- Linux Systeme gestatten eine Mischkonfiguration. In /proc/sys/net/ipv6/conf/ kann man mit "echo 0 > autoconfig" die Adressgenerierung abschalten, während die Routen gelernt werden. Mit "echo 0 > accept_ra_defrtr" kann man das Lernen der default Route untersagen, aber die Adressbildung zulassen.
Beispielkonfig eines Linux Systems:
( cd /proc/sys/net/ipv6/conf # all future interfaces and all current interfaces (incl. the predefined ones) for i in default all eth*; do echo 0 > $i/accept_ra echo 0 > $i/forwarding done ) ... loading modules, creating bonding, vlans, etc. ... ( cd /proc/sys/net/ipv6/conf # automatic address in the managment network, but no routing echo 0 > mgmt/accept_ra_defrtr echo 1 > mgmt/accept_ra # fixed address in the public network, learn routers echo 0 > public/autoconf echo 1 > public/accept_ra ) # ip -6 addr automatic dev mgmt ip -6 addr add 2001:db8:42:23:203:0:113:131/64 dev public # ip -6 route default via automatic dev public ip -4 addr add 203.0.113.131/24 dev public ip link set mgmt up ip link set public up ip -4 route add default via 203.0.113.1
Zuerst natürlich die Defaults umstellen und dann die Interfaces gleichartig konfigurieren, anderenfalls handelt man sich eine schwer zu debuggende Racecondition ein. Unglücklicherweise überschreibt "all" nicht zwingend die Einstellung existierender Interfaces, deswegen werden diese extra benannt. Die Einrichtung neuer Interface im laufenden Betrieb generiert dank dieser Defaults keine Routingstörungen mehr.
Nachdem dann alle Interfaces existieren, werden nur die Ausgewählten mit IPv6 versorgt werden. Externe vorgegebene Angaben sind dabei nur auskommentiert angegeben. In dieser Konfiguration kann der Host in ein beliebiges Managment-Netz gestellt werden und hat dort immer eine durch die Hardware vorhersagbare Adresse aus dem jeweiligen Management-Netz. Die MAC Adresse der Hardware kann man im Notfall am Switchport ablesen, um sich einen Management-Zugriff zu verschaffen.
Die Routingtabelle schaut dann so aus:
2001:db8:42:23::/64 dev public proto kernel metric 256 2001:db8:42:f000::/64 dev mgmt proto kernel metric 256 expires 2592292sec fe80::/64 dev public proto kernel metric 256 fe80::/64 dev mgmt proto kernel metric 256 ff00::/8 dev public metric 256 ff00::/8 dev mgmt metric 256 default via fe80::52:3167 dev public proto kernel metric 1024 expires 1647sec unreachable default dev lo proto kernel metric -1 error -101 metric 10 255
Beispielkonfig eines Cisco Routers:
interface Loopback0 ip address 192.0.2.56 255.255.255.255 ipv6 address 2001:db8:42::56:0/128 ! interface FastEthernet1/0 description Management IPv6 only ipv6 address FE80::56:1000 link-local ipv6 address 2001:db8:42:f000::56:1000/64 ! interface GigabitEthernet2/0.75 description Core encapsulation dot1Q 75 ip address 198.51.100.28 255.255.255.248 ipv6 address FE80::56:2075 link-local ipv6 unnumbered Loopback0 ipv6 ospf 1 area 0 ! router ospf 1 network 198.51.100.24 255.255.255.248 area 0 ! ipv6 router ospf 1 !
Interessant ist am Cisco Beispiel der Verzicht auf Transfernetze im Core und die deutliche Vereinfachung der OSPF Konfiguration gegenüber der legacy Version.
@Marc:
> (1) Kannst Du ein Beispiel für den Reverse-Wildcard-Eintrag ...
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
*.3.2.1.0 PTR router.do.main.
> (2) Sieht ein Traceroute "von außen" nicht ekelhaft aus
Im Traceroute erscheint - wenn das Interface nur link lokal hat - die erste benutzbar public IP der anderen Interfaces beginnend mit Loopback0.
> (3) Habt Ihr in Euren Netzen eine immer gleiche IPv6-Adresse für das
Defaultgateway (z.B. fe80::1)
Default-Gateway hat prefix::, d.h. der Hostteil ist 0000:0000:0000:0000:0000. Das ist der well-known Router-Anycast.
> (4) Wie stellt Ihr sicher, dass Eure Server alle euren Internen Netze über
da mgmt-Interface ansprechen?
VRF?
auch wenn der Beitrag schon ein paar Jahre her ist frage ich mal...
Hast du die gut lesbaren fe80::-Adressen auch auf routenden Nexus-Switches im Einsatz, die möglicherweise noch OSPFv3 mit anderen Routern sprechen?
Falls ja, wie sind die Erfahrungen?
Falls nein, warum (gab es Probleme)?
Grüsse
Ulrich
Wir hatten die Situation, dass der Provider doch spontan mal ein neues Präfix verteilt hat. Bei IPv6 landen diese Auswirkungen dann direkt bei den Endgeräten, d.h. der Provider bringt von außen die ganze Struktur durcheinander. Nun kann ich statische Adressen eintragen, ändert der Provider aber erneut das Präfix, habe ich doch Adressen eingetragen, deren Präfix mir garnicht mehr "gehören"? Sind also unter "folgende IPv6-Adresse verwenden" folglich nur linklocal-Adressen einzutragen? Und wie kann ich mich gegen das Chaos-Diktat von aussen absichern?
danke für diesen wie immer gut durchdachten Artikel. Ich hab ein paar
Fragen:
(1)
Kannst Du ein Beispiel für den Reverse-Wildcard-Eintrag eines Routers
(fe80::gerät:interface) geben?
(2)
Sieht ein Traceroute "von außen" nicht ekelhaft aus, wenn auf
Transfernetzen nur Link-Local Adressen sichtbar sind? Wenn man im
IPv4-Internet Router mit RFC1918-Adressen versorgt, wird man von der
Netzwerkercommunity am nächsten Serverrack aufgeknüpft.
(3)
Habt Ihr in Euren Netzen eine immer gleiche IPv6-Adresse für das
Defaultgateway (z.B. fe80::1), um Geräte mit kaputtem oder
abgeschalteten SLAAC schnell ans IPv6-Internet bringen zu können? Wenn
ja, wie löst Ihr das Problem, dass Linux-Router sich weigern,
fe80::1%eth0 als Defaultgateway zu lernen, wenn fe80::1 auf br0
bereits konfiguriert ist?
(4)
Wie stellt Ihr sicher, dass Eure Server alle euren Internen Netze über
da mgmt-Interface ansprechen?
Grüße
Marc
Die IPv4 default Route kann nur gesetzt werden, wenn das Interface zuvor "up" genommen wurde. Heute einen zusätzlichen Reboot hingelegt und nun tut's.
5 Kommentare