Was bei einem Site-to-Site-VPN zu dokumentieren ist: Selektoren und Umfang

Sechs Monate nach Inbetriebnahme eines Tunnels passt ein neues Subnetz nicht mehr zur Richtlinie, und das einzige Dokument auf der Freigabe sagt Büro-VPN. Das ist der Fehler, den ein Selektorprotokoll verhindert, und er ist konkret: Eine Adressmenge hat sich geändert, während die Unterlagen es nicht taten. Das Protokoll richtig zu schreiben heißt zu wissen, welche von mehreren Adressmengen man beschreibt, und diejenige festzuhalten, die die Gegenseite tatsächlich durchsetzt, statt der, die man konfiguriert hat.

Konfiguriert ist nicht ausgehandelt

In einem richtlinienbasierten IPsec-Tunnel schlägt jede Seite Verkehrsselektoren vor: Quell- und Zielbereiche für die Kind-Assoziation. Die antwortende Seite darf diesen Vorschlag verengen , sodass die installierte Assoziation weniger abdecken kann, als die Konfiguration aufführt. Ein Protokoll, das die Konfiguration kopiert, beschreibt daher eine Absicht und nicht den aktuellen Schutzumfang. Beide weichen still voneinander ab, und nichts auf der Tunnelstatusseite weist darauf hin.

Behalten Sie beide Spalten, mit dem Datum, an dem Sie sie beobachtet haben. Der konfigurierte Selektor ist das, was Sie meinten; der ausgehandelte ist das, was der Kernel gerade durchsetzt. Wenn sie sich unterscheiden, erklärt dieser Unterschied einen überraschenden Fehler weit häufiger als ein Routingfehler.

Eine Assoziation steht auch nicht für jedes konfigurierte Paar. Ein Tunnel mit mehreren Selektorkombinationen kann mit mehreren Kind-Assoziationen enden, und ein Protokoll, das eine davon aufführt, ist eine Teilinventur. Zählen Sie sie auf, statt sie zusammenzufassen.

Routenbasierte Tunnel wählen anders aus

Bei einer routenbasierten Schnittstelle entscheidet die Routentabelle, was in den Tunnel gelangt, und die Selektoren dürfen bewusst breit sein. Das ist ein legitimes Design und keine Schlamperei, und das Protokoll muss es als solches beschreiben. Notieren Sie die Route, die Schnittstelle, auf die sie zeigt, und die Firewallrichtlinie, die begrenzt, welche Dienste erreichbar sind. Der Schutzumfang ist absichtlich weit, und der Dienstumfang nimmt die Verengung vor.

Eine richtlinienbasierte Vorlage auf einen routenbasierten Tunnel zu kopieren erzeugt ein Dokument, das einen Mechanismus beschreibt, den die Bereitstellung nicht verwendet. Der nächste Ingenieur sucht dann nach Selektoren, die dort nie vorgesehen waren, und schließt, der Tunnel sei falsch konfiguriert, obwohl er nur schlecht dokumentiert ist.

Die Übersetzung gehört in dieselbe Tabelle

Wenn NAT der Gegenseite einen anderen Bereich präsentiert, halten Sie die ursprünglichen und die übersetzten Präfixe zusammen fest. Vermerken Sie die Stufe, auf der Selektoren und Zugriffsregeln sie abgleichen, denn die Reihenfolge entscheidet, ob die ferne Seite die von Ihnen notierte Adresse überhaupt sieht. Eine Tabelle mit nur einem der beiden Bereiche ist schlechter als keine Tabelle, weil sie vollständig aussieht.

Das ist das Detail, das einen funktionierenden Tunnel nach einer NAT-Änderung bricht: Der Selektor passt weiterhin zum ursprünglichen Präfix, die Gegenseite erhält nun ein übersetztes, und ihre Rückroute zeigt auf eine Adresse, die es nicht mehr gibt. Nichts protokolliert einen Fehler in dem Moment, in dem die beiden aufhören übereinzustimmen.

Privates DNS gehört an dieselbe Stelle. Ein Name, der zu einer Adresse auflöst, die vom betreffenden Standort aus unbrauchbar ist, ist ein Dokumentationsfehler mit angehängtem Supportticket, und man wird dem Tunnel die Schuld geben.

Hängen Sie die Dienstanforderung an

Ein geschützter Bereich ist keine Berechtigungsliste. Notieren Sie, welche Dienste von welcher Quelle aus erreichbar sein sollen und wem die Anwendung dahinter gehört. Diese beiden Felder beantworten verschiedene Fragen, und sie zu vermengen ist der Weg, auf dem eine Sicherheitsprüfung am Ende über Routing statt über Zugriff streitet.

Benennen Sie dann den Netzwerkadministrator, der die Regel pflegt. Eine Selektorinventur ohne Eigentümer veraltet still, und Veraltetes ist nicht von Falschem zu unterscheiden, wenn der Tunnel um zwei Uhr morgens bricht. Der Eigentümer ist auch die Person, die bestätigen kann, dass eine Änderung beabsichtigt war.

Machen Sie das Protokoll zum Testplan

Wählen Sie für jeden erforderlichen Pfad einen repräsentativen Quell- und Zielhost und notieren Sie die erwartete Route, den Dienst und das Antwort-Gateway. Das macht das Dokument zu einem Testplan statt zu einer Beschreibung. Lesen Sie die laufende Assoziation mit dem Befehl unten zurück und vergleichen Sie sie mit der ausgehandelten Zeile, die Sie notiert haben.

swanctl --list-sas

Ein Gerüst aus fünf Zeilen reicht meist, damit das Protokoll ehrlich bleibt. Die Version unten passt ohne Kürzung in ein Änderungsticket:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Ein Ping nur zum Gateway ist nicht der Abnahmetest. Er übt nie den Transitpfad aus, kann also bestehen, während jeder weitergeleitete Fluss scheitert. Testen Sie von einem Host auf der einen Seite zu einem Dienst auf der anderen und bestätigen Sie, dass die Antwort durch den Tunnel ankommt. Wenn nur der Ping besteht, hat das Protokoll gerade das Weiterleitungsproblem gefunden, das es verhindern sollte. strongSwan-Dokumentation zur Weiterleitung erklärt, wie Selektoren, Routen und Weiterleitung auf einer Linux-Gegenseite zusammenspielen.