Setzen Sie das VPN-Gateway neben Windows XP, nicht hinein

Irgendwo im Gebäude steht eine Maschine, die eine Anwendung ausführt, die niemand ersetzen kann, auf einem Betriebssystem, das mit nichts verbunden werden sollte. Vom Netzwerkadapter dieses Hosts nach außen zu gehen, zeigt am schnellsten, wohin der Tunnel gehört. In den meisten Entwürfen gehört er überhaupt nicht auf den Host. Verschieben Sie ihn einen Schritt weiter auf ein gepflegtes Gateway, und das alte Problem schrumpft auf die Anwendung zurück, mit der es begann.

Beginnen Sie beim Hostadapter, nicht bei einem VPN-Client

Öffnen Sie die Adaptereigenschaften und geben Sie dem Host eine feste Adresse in einem kleinen dedizierten Segment, mit dem Gateway als Standardroute. Dann braucht der Host keinen Tunnelclient, keine Tunnel-Anmeldedaten und keine Routingtabelleneinträge in das breitere Unternehmensnetz. Wenn die Anwendung ein einziges entferntes Subnetz braucht, fügen Sie genau diese eine Route hinzu.

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

Dieser Befehl bindet ein einziges Ziel an das Gateway und lässt alles andere unroutbar, und das ist die gewünschte Form. Bestätigen Sie das Ergebnis mit route print, statt sich auf den Exit-Code zu verlassen. Prüfen Sie dann, ob die Anwendung ihren Servernamen noch auflöst, denn ein alter Host mit kaputtem Resolver sieht genau wie ein Netzwerkfehler aus, und den Resolver zu reparieren ist eine Sache von fünf Minuten, eine Anwendung nach einer falschen Netzwerkänderung neu aufzubauen nicht. Jedes Ziel, das der Host nicht erreicht, ist eine Sache weniger, zu der ein alter Netzwerkstack überredet werden kann, sie anzugreifen.

Setzen Sie den Tunnel auf Hardware, die Sie aktualisieren können

Das Gateway will zwei Schnittstellen: eine zum Hostsegment und eine dorthin, wo die Anwendung lebt, wobei der Tunnel auf der zweiten endet. Dieses Gerät kann Firmware-Updates erhalten, seine kryptografische Konfiguration austauschen und Flows protokollieren, ohne dass jemand die alte Maschine anfasst. Sein Hersteller liefert außerdem Korrekturen für die Tunnelimplementierung, die der Host nie erhalten wird. Zwei Maschinen und eine Frist sind kein Grund, ein Rezept mit statischem Geheimnis aus einem Forumsbeitrag zu kopieren.

Geben Sie jedem Gateway eine eigene Peer-Identität, statt eine Clientkonfiguration über eine Flotte zu klonen. Wenn ein Gerät ersetzt wird, widerrufen Sie die alte Identität in dem Moment, in dem Sie die neue online nehmen, sonst bleiben zwei unkontrollierte Kopien, die sich am selben Endpunkt authentifizieren. Bewahren Sie die Schlüssel dort auf, wo die Managementebene des Gateways sie erwartet, behandeln Sie eine Konfigurationssicherung als Geheimnis und prüfen Sie, wer diese Konfiguration ausrollen darf, denn das entscheidet jetzt, was der alte Host erreichen kann.

Erlauben Sie Dienste, keine Netzwerke

Schreiben Sie die Richtlinie in Begriffen von Protokoll, Port und Richtung zwischen den beiden Anbindungen. Ein einzelner erlaubter Port zu einer einzelnen Anwendungsadresse ist die übliche Antwort, und ein administrativer Pfad über einen Sprunghost deckt den Rest ab.

Die Fernwartung des alten Hosts sollte nicht über dieselbe Regel laufen wie die Anwendung, und das Ablehnen zu testen ist ebenso wichtig wie das Schreiben der Regel. Senden Sie eine Anfrage vom Host an ein Ziel, das abgelehnt werden soll, und bestätigen Sie, dass die Ablehnung aus der Richtlinie und nicht aus einer fehlenden Route kommt. Protokollieren Sie die erlaubten Flows, solange der Entwurf neu ist, damit Sie sehen, was die Anwendung tatsächlich nutzt, und nicht, was ihre Dokumentation behauptet. Zwei Subnetze zusammenzulegen, weil ein gebrücktes Tutorial kürzer aussah, ist der Weg, auf dem ein altes Segment still zum Sprungbrett wird.

Setzen Sie den alten Listener nicht als Abkürzung am Gateway vorbei direkt ins Internet. Halten Sie den administrativen Pfad vom Anwendungspfad getrennt, damit die Kompromittierung des einen den anderen nicht mitliefert. Eine Regel, die nie ausgeübt wird, ist eine Regel, die niemand geprüft hat, und deshalb gehört das abgelehnte Ziel in den Abnahmelauf.

Wiederherstellung muss ohne den Tunnel funktionieren

Entscheiden Sie vor dem ersten Ausfall, wer das Gateway aktualisiert und wiederherstellt, und stellen Sie sicher, dass diese Person es ohne den Tunnel erreicht, den es beendet. Konsolenzugang, ein lokaler Managementport oder ein Out-of-Band-Pfad zählen alle als Antwort. Ein Gateway, das nur über den Tunnel konfiguriert werden kann, den es bereitstellt, ist eine Falle, die geduldig auf einen schlechten Firmware-Push wartet.

Schreiben Sie das Runbook für den Ausfall, den Sie tatsächlich erleben werden: Tunnel unten, Gateway tot, Host-Festplatte weg. Halten Sie das Wiederherstellungsabbild des Hosts unter der Supportvereinbarung, die noch existiert, und denken Sie daran, dass eine Wiederherstellung auch den Softwarezustand und die Anmeldedaten in diesem Abbild zurückbringt. Stellen Sie zuerst auf dem isolierten Segment wieder her, bestätigen Sie, dass die Anwendung startet, und verbinden Sie erst dann etwas wieder; wenn sich das Gateway ändert, aktualisieren Sie Runbook und Inventar im selben Zug.

Zertifikate, Uhren und Signaturwarnungen

Der Zertifikatsablauf eines Installers sagt für sich genommen nicht voraus, was eine Signaturprüfung heute sagen wird. Microsofts Hinweise zu Authenticode-Zeitstempeln erklären, dass ein Zeitstempel eine Signatur nach Ablauf des Signaturzertifikats weiter verifizierbar halten kann und die Validierung weiterhin von der Signatur, der Vertrauenskette und dem prüfenden Verifier abhängt. Zwei Maschinen mit unterschiedlichen Vertrauensspeichern können sich daher über dieselbe Datei uneinig sein. Ein abgelaufener Unterzeichner ist kein Beweis, dass eine Binärdatei bösartig ist, und eine gültige Signatur ist kein Beweis, dass die Software gepflegt wird.

Stellen Sie die Systemuhr nicht zurück und schalten Sie Signaturprüfungen nicht ab, um einen alten Installer laufen zu lassen. Besorgen Sie ein autorisiertes Artefakt bei dem, der die Anwendung noch unterstützt, und lassen Sie sich sagen, was die Plattform akzeptiert. Behandeln Sie Beiträge, die behaupten, ein bestimmter Build sei der letzte für XP gewesen, als Geschichte und nicht als Installationsziel, denn die tatsächliche Anforderung hängt von der Anwendung ab; wenn Erhaltungsarbeit wirklich nötig ist, halten Sie sie auf einem isolierten Segment fern vom Produktionszugang und dokumentieren Sie, warum es sie gibt.