Schon wieder IPv6…

Vermutlich denken Sie jetzt – mit eingeschränkter Begeisterung, dass hier schon wieder jemand einen Artikel über die theoretischen Vorteile von IPv6 schreibt und damit das lesende Volk verunsichern will. Naja, im Prinzip richtig. Tatsächlich möchte ich hier ein Ergebnis zusammenfassen, dass wir in unserer eigenen iteracon-Infrastruktur erlebt haben. Wir sahen uns tatsächlich gezwungen, IPv6 selektiv einzuführen. Vielleicht ist ja dieser Bericht für den einen oder anderen Leser eine Unterstützung bei eigenen Überlegungen.

Wie also kam es dazu, dass wir (unfreiwillig) gezwungen wurden, IPv6 einzusetzen?

Ausgangspunkt ist die Verwendung von Skype for Business (S4B). Wir setzen als Microsoft Gold Partner natürlich S4B ein und ermöglichen unseren Mitarbeitern damit auch eine komfortable Erreichbarkeit an Heimarbeitsplätzen. Microsoft empfiehlt, in diesen Szenarien den S4B Verkehr nicht zusätzlich per VPN zu verschlüsseln, da hierdurch zusätzliches Delay und Jitter entsteht und die Sprachqualität entsprechend abnehmen kann. Siehe z.B. folgenden etwas älteren Artikel hierzu: https://blogs.technet.microsoft.com/nexthop/2011/11/14/enabling-lync-media-to-bypass-a-vpn-tunnel/. S4B verschlüsselt die übertragenen Daten bereits von Hause aus und unterstützt sichere Verfahren für die Authentisierung. Es besteht also keine unmittelbare Notwendigkeit S4B via VPN zu implementieren.

Wenn man dieser Microsoft-Empfehlung folgt, werden beim entfernten Teilnehmer (z.B. Heimarbeitsplatz) einige TCP-/UDP-Ports für die Verbindung benötigt und zwar auch in Richtung des Teilnehmers. Diese Ports werden teilweise dynamisch ausgehandelt und sind nicht im Vorfeld bekannt. Das STUN-Protokoll unterstützt hierbei den Verbindungsaufbau durch Firewalls und über NAT Devices. Sofern man über einen Anschluss mit (z.B. einer festen) IPv4-Adresse verfügt, der bezüglich der nutzbaren Ports nicht eingeschränkt ist, ist alles gut. Allerdings ist dies kaum der Standard; viele Heimarbeitsplätze verwenden dynamisch vom Provider vergebene IPv4-Adressen und bei diesen setzen immer mehr Provider Carrier Grade NAT Verfahren ein (CGN), um die Menge der zur Verfügung stehenden öffentlichen IPv4-Adressen optimal nutzen zu können. Es geschieht gelegentlich eine recht hohe Überbuchung der öffentlichen IPv4-Adressen der Provider. Es ist absehbar, dass mit solchen CGN-Verfahren S4B in Probleme laufen kann, wenn die öffentlichen IPv4-Adressen stark in Nutzung sind und damit die freien TCP/UDP Ports knapp werden.

So geschehen: Wir hatten bei einigen Mitarbeitern das Problem, dass sie nicht immer von zu Hause telefonieren oder Konferenzen nutzen konnten. Die Fehlersuche gestaltete sich schwierig, da keine offensichtlichen Fehler in der Infrastruktur gefunden werden konnten. Die Probleme traten zudem nicht konstant auf, sondern eher sporadisch. Nach einigen Analyse haben wir dann das Carrier-Grade-NAT in Verdacht gehabt und unterstellt, dass notwendige Ports beim entfernten Teilnehmer nicht immer frei waren / genutzt werden konnten.

Unsere Infrastruktur verwendet einen S4B Edge-Server in einer DMZ für die Kommunikation mit Teilnehmern außerhalb des Firmennetzes. Dieser Edge-Server authentisiert die Teilnehmer und bündelt die Kommunikation in Richtung S4B Front-End-Server im LAN. Um Probleme mit NAT auszuloten, haben wir folgende Änderungen durchgeführt:

  • Der Edge-Server hat eine zusätzliche IPv6-Adresse bekommen (Dual-Stack).
  • Wir haben auf der Firewall IPv6 in Richtung des Internets für den Edge-Server freigeschaltet.
  • Wir haben auf der Firewall auch eingehende S4B-Kommunikation über IPv6 zugelassen.
  • Schließlich haben wir im öffentlichen DNS einen zusätzliche aaaa-Record mit gleichem Namen wie beim vorhandenen a-Record gesetzt und diesen auf die IPv6-Adressee des Edge-Servers auflösen lassen.

 

Das Ergebnis: mit diesen Änderungen funktioniert die Telefonie nun auch bei allen Teilnehmern wieder zuverlässig. Insbesondere profitieren die Teilnehmer, deren Internet-Zugänge bereits IPv6 sprechen (also die meisten). Eine Analyse mit Wireshark zeigt: Hat ein S4B-Client eine IPv4- und IPv6-Konfiguration, versucht er, den Verbindungsaufbau über aaaa/IPv6 zu initiieren. Gelingt dies, ist IPv6 hier sogar der präferierte Weg! Eine Überbuchung von IPv6-Adressen bzgl. NAT ist bisher nicht in Sicht. IPv6 ist also in diesem Szenario die Lösung des Problems!

Das Szenario scheint mir deshalb akzeptabel, weil es mit relativ geringen Änderungen in der Infrastruktur umsetzbar ist. Wir setzen IPv6 nur bis in die DMZ ein, danach geht es per IPv4 weiter. Gegen eine weiter reichende Einführung von IPv6 (IPv6 bis zum Front-End-Server in unser lokales Netzwerk) hätte ich deutliche Vorbehalte, weil dies alle vorhandenen Kommunikationsregeln (Firewall, DNS, Routing) in Frage gestellt hätte und sich der übliche Aufwand für Fehlersuchen im Netz damit relativ schnell verdoppeln würde.

Unser Fazit: Es ist absehbar, dass uns an einigen Stellen IPv6 unerwartet begegnen wird und dass wir uns dann zwangsweise damit anfreunden müssen. Es scheint aus heutiger Sicht ratsam, diese Szenarien vorzubereiten und IPv6 bis an die Grenze des Unternehmensnetzes (Firewall, DMZ) schon einmal zu durchdenken und nutzbar zu machen.

Es grüßt, Harald Krause

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*