Windows-VPN-Gateway: drei Aufgaben, drei Zuständigkeiten

Drei Funktionen werden zusammengeworfen, sobald jemand VPN-Server sagt: den verschlüsselten Tunnel beenden, Pakete zwischen Netzen bewegen und optional Adressen umschreiben. Unter Windows liegen sie in verschiedenen Teilen des Stapels, selbst wenn eine Maschine alle drei übernimmt. Jede hat ihre eigenen Eingaben und ihre eigene Fehlerart, und jede lässt sich einem anderen Produkt übergeben. Sie auf dem Papier zu trennen ist der billigste Weg, eine kleine Installation verständlich zu halten.

Ein lesbares Design benennt den Eigentümer jedes Flusses, statt die Maschine als Rolle zu beschreiben.

Beenden, weiterleiten, übersetzen

RRAS übernimmt den Tunnel für den Windows-eigenen Fall: Es authentifiziert den Benutzer, weist eine Adresse aus einem Pool zu und entscheidet, welche Ziele erlaubt sind. Ein anderes VPN-Produkt kann stattdessen den Listener und den virtuellen Adapter besitzen und Windows die entschlüsselten Pakete weiterleiten lassen. Die Remote Access-Dokumentation von Microsoft trennt VPN-, Site-to-Site- und Routingrollen, und die Installation der Routingrolle erzeugt keine zweite VPN-Identität. Eine weitere VPN-Anwendung gibt ihren Adapter auch nicht an jede vorhandene Gateway-Funktion weiter.

Die Übersetzung ist die dritte und am ehesten optionale Aufgabe. Sie kommt nach dem Weiterleiten und ändert die Quelladresse, die das ferne Netz sieht. Ob Sie sie brauchen, hängt davon ab, was das Zielnetz als Quelle akzeptiert, nicht davon, dass die Maschine VPN-Gateway genannt wird.

Wem gehören Adapter und Pool

Wenn mehrere Produkte den Host teilen, brauchen vier Dinge jeweils einen einzigen Eigentümer: Listener-Ports, Lebensdauer des Adapters, Client-Adresspool und Routen. Der Adapter ist der unangenehme Fall, weil ein VPN-Dienst ihn dynamisch anlegen und beim Trennen zerstören kann. Diese Schnittstelle als dauerhaft benannte Netzwerkkarte zu behandeln und Regeln gegen ihren Namen zu schreiben, funktioniert bis zum nächsten Wiederverbinden. Nutzen Sie den unterstützten Integrationspunkt des Produkts, statt einen Schnittstellennamen fest zu verdrahten.

Der Adresspool ist die zweite Kollision. Zwei Produkte, die überlappende Bereiche ausgeben, erzeugen Routing, das korrekt aussieht und nichts liefert. Halten Sie die Pools im selben Dokument wie die Routen, damit eine Änderung an einem gegen den anderen sichtbar ist.

Die Quelle bewahren oder umschreiben

Die Quelladresse des Clients zu bewahren erhält die Sichtbarkeit pro Benutzer: Protokolle, Kontingente und Firewall-Regeln können einen Benutzer von einem anderen unterscheiden. Der Preis ist, dass das Ziel-LAN eine Rückroute zum Gateway braucht und jemand sie pflegen muss. Die Quelle mit NAT umzuschreiben beseitigt diese Anforderung und beseitigt die Sichtbarkeit gleich mit. Entscheiden Sie bewusst und notieren Sie, welche Informationen das Umschreiben verbirgt.

Zugriff auf private Netze, Internet-Ausgang und Verbindungen, die am Gateway selbst enden, sind drei verschiedene Pfade. Sie brauchen nicht alle dieselbe Behandlung.

Den Fluss in einem Satz beschreiben

Ein Satz sollte das Design beschreiben: welche Clients dieser Dienst zulässt, welche Ressourcen diese Weiterleitungsrichtlinie gewährt und wie der Rückweg den Fluss vollendet. Wenn der Satz eine zweite NAT-Schicht braucht, um wahr zu sein, ist das meist ein Zeichen dafür, dass die früheren Teile nicht geklärt waren. Der Host ist auch eine gemeinsame Fehler- und Vertrauensgrenze, sodass eine Routing-Änderung sowohl den Benutzerzugriff als auch die Administration betreffen kann. Für Letztere gehört ein unabhängiger Wiederherstellungspfad dazu.

Führen Sie ein Rollenverzeichnis neben der Konfiguration: welches Produkt beendet, welches leitet weiter, welches übersetzt und wer jedes davon ändern kann. Diese Liste macht die nächste Änderung überprüfbar.

Wenn der Satz unklar wird, macht eine weitere Übersetzungsschicht ihn selten klarer. Eine zu entfernen meist schon.