Quicktipp

Wer kennt das nicht – Sie befinden sich in Ihrem wohlverdienten Urlaub, aber Ihr Handy gönnt Ihnen keine freie Minute? Es erinnert Sie, trotz Abwesenheit, an Termine? Oder Ihr Kollege ruft Sie an, und fragt warum Sie nicht am Meeting teilnehmen, dabei liegen Sie krank zu Hause? 

Die Lösung für ein solches Problem: der Abwesenheitsassistent von Exchange Online!

Er kann Sie nicht vor Anrufen schützen, aber er kann im Zeitraum Ihrer Abwesenheit Ihren Kalender blocken oder auch Terminanfragen für Sie ablehnen oder auch absagen.

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

 

DirectAccess Manage Out funktioniert nicht von internen Windows 10 Clients…

…Hallo Allerseits,

in 4 verschiedenen DirectAccess-Umgebungen haben wir Probleme von internen Windows 10 Clients festgestellt welche externe DirectAccess Clients via Manage Out (Stichwort: ISATAP) verwalten wollen. Die Problematik lässt sich auf das Nicht-Funktionieren der Namensauflösung einschränken. Wenn z.B. von einer der betroffenen internen Maschinen ein Ping (oder RDP oder sonstiges Protokoll) auf den NetBios-Namen des externen DA-Clients abgesetzt wird kommt ein “Host unbekannt” zurück – und das obwohl der externe Client sich korrekt (mit seiner v6-IP) am internen DNS registriert hat.

Im folgenden Screenshot kann man erkennen, das ein NSLOOKUP auf einen NetBios-Namen korrekt aufgelöst wird, der direkt folgende Ping auf denselben Namen scheitert:

clip_image002

Richard Hicks hat über dieses Verhalten/Phänomen bereits im November 2015 berichtet und auch einen Workaround in Form von Registry-Hacks online gestellt:

https://directaccess.richardhicks.com/2015/11/10/directaccess-manage-out-from-windows-10-does-not-work/

Einer unserer Kunden hat nun ein Ticket bei Microsoft geöffnet um eine Aussage des Herstellers dazu zu erhalten. Dort wurde uns signalisiert das dieser Case nun als Bug klassifiziert wurde.

Im übrigen kann das Verhalten als Workaround auch mit einem einzelnen Registry-Key gelöst werden und zwar wie folgt, hier ein Ausschnitt aus der Ticket-Konversation:

***********************************************

Hallo Herr Hentrup,

ich habe weitere Informationen.

Für das von mir in der vorigen Email angesprochene Verhalten (der Client sendet keine AAAA Queries) ist die aktuelle Lösung diesen Registry Key zu setzten.

HKLM\System\CCS\Services\DNSCACHE\Parameters

REG_DWORD „AddrConfigControl „
Value: 0

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name AddrConfigControl -PropertyType dword -Value 0 -Force

Die anderen beiden Registry Keys können somit auf Ihren Standartwerten bleiben. Wenn Sie sie zurücksetzten wollen:

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableParallelAandAAAA -PropertyType dword -Value 0 -Force

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableServerUnreachability -PropertyType dword -Value 0 -Force

Testen Sie das doch bitte.

Wenn es auch so funktioniert haben wir sicherlich das Problem. Dieses Verhalten zeigt auch Win10 1511.

***********************************************

Haben wir getestet – funktioniert!

Gruß,

Karsten Hentrup…

|<-|

iteracon bloggt…

…Ich freue mich hier ankündigen zu dürfen, dass wir von der iteracon GmbH nun ein eigenes Blog hegen und pflegen. Wir werden hier über unsere Erfahrungen zu verschiedensten Microsoft-Produkten, deren Implementation und Betrieb berichten.

Unsere aktuellen thematischen Highlights sind die Managed Services rund um Microsoft Azure und Office 365, Consulting zum modernen effizienten Arbeiten rund um Windows 10, Office 2016, und Skype for Business. Darüber hinaus beschäftigen wir uns mit einigen Spezialthemen wie Multi-Factor Authentication, DirectAccess und Active Directory Security mit Advanced Threat Analytics.

Natürlich wird sich hier auch das eine oder andere “klassische” Microsoft Thema wiederfinden wie die System Center Suite, Exchange, Active Directory, Hyper-V, PKI, etc.

Wir lesen uns!

Gruß, Karsten Hentrup…

|<-|