Zugschlusbeobachtungen

Es kommt in der Praxis vor, dass ein solches Projekt auf die Nase fällt oder auf einen vorhergehenden Stand zurückgerollt werden muss, weil nach dem Tausch einer Komponente der VPN-Link nicht mehr auf die Füße kommt, weil der paranoiden Gegenstelle ein vom neuen Gerät anders gesetztes Statusbit im IKE-Phase-1-Proposal nicht in den Kram passt und man morgens um zwei keinen technischen Ansprechpartner der Gegenseite zu fassen bekommt, der einem aus dem Log der Gegenstelle vorlesen könnte oder der gar eine von uns dringend benötigte Anpassung schnell durchführen kann.

Bei Client-VPNs für mobile User hat man oft keine Möglichkeit, selbst zu testen, weil der VPN-Zugang in vielen Unternehmen ein Statussymbol ist und das Fußvolk, mit dem man es im Projekt zu tun hat, nicht über so einen Zugang verfügt. Hier lohnt es sich in aller Regel, durch alle vom Kunden aufgestellten brennenden Reifen zu springen, um einen solchen Zugang während der Migration zur Verfügung gestellt zu bekommen, damit man testen kann. Sonst darf man zu irgendwelchen Unzeiten (morgens um acht nach einer bis vier Uhr morgens gehenden Migrationsnacht) mit unwilligen und unhöflichen Managern telefonieren und mit ihnen zusammen das VPN debuggen, nicht ohne sich ständig anhören zu müssen dass der Gesprächspartner eigentlich arbeiten müsste. Zum selbst testen ist ein unabhängiger Internetzugang von Vorteil, der notfalls per UMTS oder (besser!) mit einem UMTS-to-WLAN-Router oder (noch besser!) mit einem extra für solche Zwecke bereitgehaltenen DSL-Zugang in den Arbeitsräumen des Migrationsprojekts - zumindest die UMTS-Lösungen kann man für den Fall eines Falles selbst bereithalten.

Rechnet gerade im Falle von IPSEC nicht damit, dass das, was der Kunde als Dokumentation im Schrank stehen hat, stimmt. Die Parameter einer IPSEC-Verbindung sind vielfältig, und bei vielen Geräten hat man nicht die Möglichkeit, an wirklich jeder Stellschraube zu drehen. Deswegen ist es nicht selten, dass die Mail, die der Kunde archiviert hat, nur das theoretische "Wunschkonzert" einer der beiden Seiten darstellt, und eventuell stimmt beispielsweise die Time-To-Live des Phase2-Proposals nicht mehr mit der Dokumentation überein, weil das VPN-Gerät der Gegenseite gar nicht erlaubt, diesen Wert getrennt von seinem Phase1-Gegenstück einzustellen. Wenn man bei einem Gerät einen Parameter nicht einstellen kann, muss man wissen, welchen Wert das Gerät hier verwendet - das muss nicht notwendigerweise der Wert sein, der in der Dokumentation steht.

So gerne ich bei Debuggingaktionen einfach mal mit einem Sniffer aufs Kabel gucke, so wenig hilft das in aller Regel bei VPN-Tunneln - denn die Kommunikation ist aus naheliegenden Gründen verschlüsselt. Das reicht also höchstens dafür, um beurteilen zu können, ob die Geräte überhaupt versuchen, miteinander zu kommunizieren. Will man es genauer wissen, muss man in den sauren Apfel beißen und gucken, ob man dem Gateway selbst irgendwelche Informationen entlocken kann. Leider ist das oft auch der Punkt, wo die Herstellerdokumentation aufhört, weil es nun interessant wird. Mit Glück kriegt man noch gesagt, wie das Kommando zum Aktivieren des Debugging heißt.

Lustig sind hier auch die Shared Secrets, denn bei vielen Geräten bekommt man sie zwar rein, nicht aber wieder aus dem Gerät heraus. Und wenn sich dann auch noch herausstellt, dass das alte Gerät im Shared Secret standardwidrig keine Sonderzeichen erlaubt, das dokumentierte Passwort aber solche enthält, weiß man nicht, was denn nun als Shared Secret auf den neuen Tunnel konfiguriert gehört. Schade, Schade, Schade, und es ist Zeit für ein Telefonat mit der Gegenseite, die hoffentlich (a) gerade erreichbar und (b) kooperativ genug ist, um "on the fly" ein neues Shared Secret zu vereinbaren. Normalerweise ist so eine Situation ein akuter Showstopper, da man ja gerade migriert und es vermutlich gerade mitten in der Nacht ist.

In den allermeisten Fällen sind alle VPN-Tunnel auf einer einzigen IP-Adresse des eigenen Systems terminiert, was sofort bedeutet, dass alle auf dem Gerät terminierten VPN-Tunnel gleichzeitig umziehen müssen. Man hat es also im übelsten Fall mit zehn verschiedenen Gegenstellen zu tun, die alle verschiedene Arbeitszeiten haben, bei denen die Hälfte der Ansprechpartner mit Sachkenntnis im Projekt, Urlaub oder in Elternzeit sind und wo jede einzelne Gegenstelle für den Kunden überlebenswichtig ist.

Oft ist es empfehlenswert, das neue System parallel zum alten aufzubauen und jeden einzelnen Tunnel - mit Hilfe der Gegenstelle und unter Veränderung der eigenen Gateway-Adresse - einzeln auf das neue System umzuziehen. Das ist sicherlich die Lösung, die für jede Anwendung die kürzeste Einzeldowntime hat; dafür ist es oft aufwändig zu organisieren. Bei hinreichend hirnrissiger Architektur beim Kunden sind die Funktionen jedoch so miteinander verwoben, dass man nicht auf eine andere IP-Adresse ausweichen kann, oder politische Entscheidungen ("dem Tunnel hat die Gegenstelle erst nach dem zehnten Ouzo zugestimmt, den hat er bestimmt vergessen, wir wollen nicht dass er sich daran erinnert") zwingen zu einem anderen Vorgehen.

Dann sollte man alle Tunnel auf dem neuen Gerät möglichst so einrichten, dass sie mit dem alten Equipment ebenfalls funktionieren, damit man die Möglichkeit hat, auf die alte Umgebung zurückzuwechseln, wenn der Tunnel, um den man sich gerade kümmert, beispielsweise ohne Kommunikation mit der Gegenstelle mit dem neuen Gerät partout nicht funktionieren mag. Wenn tatsächlich eine Änderung an der Konfiguration der Gegenseite notwendig ist, sollte auch der geänderte Tunnel mit dem alten Gerät noch funktionieren - denn im Zweifel zwingt einen ein anderer Tunnel wieder auf die alte Umgebung zurück, und den Kunden vor die Wahl "entweder Berlin oder Leipzig, aber derzeit nicht beide gleichzeitig" stellen zu müssen, beschert totsicheren Ärger.

Im allgemeinen zwingen einen Kombigeräte hier zu abenteuerlichsten Vorgehensweisen, weil der Wechsel "zurück" bei einer mit einem VPN-Gateway kombinierten Firewall üblicherweise ein erheblich tieferer Eingriff in die Infrastruktur ist als das "interface foo; shut; interface bar; no shut" auf dem Switch, an dem die beiden reinen VPN-Geräte angeschlossen sind. Dies ist übrigens einer der Gründe, warum ich meinen Kunden immer empfehle, Firewall und VPN voneinander zu trennen: Das ist im Wirkbetrieb und in Migrationen einfach viel besser zu debuggen und besser zu handhaben.