So planen Sie einen Adresspool für VPN-Clients, der passt

Beginnen Sie im Poolfeld auf dem VPN-Server, nicht in einer Tabellenkalkulation. Was Sie dort eintragen, wird zum inneren Adressraum für jeden Client, der sich danach verbindet, und es muss mit dem LAN koexistieren, das diese Clients erreichen, den dahinter gerouteten Standorten und jeder Adresse, die der Client zu Hause bereits hält. Verbinden Sie einen Client, sobald der Pool gespeichert ist, denn diese erste Verbindung sagt Ihnen, ob der Wert in der Praxis funktioniert. Von dort bewegt sich der Rundgang nach außen: die Adresse, die der Client erhielt, den Weg, den eine Antwort nimmt, und den Eintrag, den Sie hinterlassen.

Beginnen Sie beim Poolfeld, bevor sich ein Client verbindet

Jedes Produkt legt das anders offen, finden Sie also das Objekt, das Adressen tatsächlich zuweist. OpenVPN hat eine serverseitige Pooldirektive, die die nächste freie Adresse vergibt, ein IKEv2-Gateway hat einen Poolabschnitt, der an die Peer-Konfiguration gebunden ist, und WireGuard hat beides nicht, weil jeder Peer seine eigene Adresse in seiner Konfigurationsdatei trägt. Eine Pooldirektive und eine Adresse pro Peer sind nicht austauschbar, und das falsche zu bearbeiten verschwendet den Rest des Rundgangs.

Sobald Sie das Feld haben, listen Sie die Bereiche auf, die bereits existieren: das Büro-LAN, jeden gerouteten Standort, die Cloud-VPC und jeden anderen Pool, der noch in Betrieb ist. Überlappung entscheidet sich durch Präfixarithmetik, nicht dadurch, ob die Hostnummern vertraut aussehen, also vergleichen Sie das Aggregat mit jedem dieser Bereiche. Zwei Bereiche, die beide wie 10.x aussehen, sind harmlos, wenn sich ihre Aggregate nicht schneiden, und ein Supportfall, wenn sie es tun.

Dann entscheiden Sie, ob die Adresse eine Funktion davon ist, wer sich verbindet, oder davon, wann sie sich verbinden. Dynamische Zuweisung vergibt, was frei ist, während Zuweisung pro Identität eine feste Adresse an ein Credential bindet. Schreiben Sie die Wahl auf, denn sie ändert, wie eine erneute Verbindung später aussehen soll.

Lesen Sie die Adresse, die der Client tatsächlich erhielt

Verbinden Sie einen Client und lesen Sie, was der Tunnel meldet, nicht was der Pool versprochen hat. Der Client zeigt seine innere Adresse im Verbindungsstatus, und unter Linux trägt die Schnittstelle sie direkt.

Vergleichen Sie diese Adresse mit dem gespeicherten Bereich. Liegt sie außerhalb, sehen Sie einen anderen Zuweisungsweg als den bearbeiteten. Prüfen Sie auch die Präfixlänge, denn ein Client mit einer /32 hat keinen On-Link-Peer und sendet jedes Ziel über seine Standardroute.

ip -4 addr show tun0
ip route get 192.168.50.20

Ein Client, der sich von einem Heimrouter mit demselben Bereich verbindet, wird sich verbinden und dann fast nichts erreichen. Der Client behält seine lokale Route für dieses Präfix, sodass die Tunneladresse mit dem Netz dahinter kollidiert und der Verkehr über die falsche Schnittstelle verlässt. Dieser Fall lässt sich auf dem Server nicht reparieren; die dokumentierte Abhilfe ist, das Heimnetz neu zu nummerieren oder einen Poolbereich zu wählen, der weit genug entfernt ist, damit Kollisionen selten bleiben. Notieren Sie sowohl den Fehler als auch die Abhilfe, denn der Helpdesk wird ihr wieder begegnen.

Verbinden Sie denselben Client erneut und beobachten Sie die Adresse. Ein dynamischer Pool kann denselben oder einen anderen Wert zurückgeben, und beides ist korrekt, während ein Pool pro Identität, der die Adresse ändert, die Bindung nicht einhält. Diese Prüfung dauert Sekunden und entscheidet, ob der im ersten Abschnitt notierte Modus der geltende ist.

Verfolgen Sie eine Antwort von der Dienstseite zurück

Der Pool funktioniert nur, wenn Antworten zu ihm zurückreisen können. Ein Dienst im LAN antwortet auf die innere Adresse, also braucht sein Gateway eine Route für den Pool oder eine Übersetzung vor dem Dienst. Wenn eine Anfrage durch den Tunnel ankommt und die Antwort über einen anderen Weg abgeht, verwirft eine zustandsbehaftete Firewall oder eine Reverse-Path-Prüfung sie, und der Client sieht einen Dienst, der sich verbindet und dann hängt. Setzen Sie den Pool als einen zusammenfassbaren Block in das Routingdesign, statt Routen pro Host hinzuzufügen.

Übersetzung ändert, was der Rest des Systems sieht. Wenn die Quelle umgeschrieben wird, ist die Adresse in der Host-Firewall und im Anwendungsprotokoll die übersetzte, sodass eine Regel gegen die Pooladresse nichts trifft und eine Protokollzeile sich nicht zu einem Client zurückverfolgen lässt. Die strongSwan-Dokumentation zur Weiterleitung deckt die serverseitige Hälfte dieses Wegs für ein IKEv2-Gateway ab. DNS trägt dieselbe Einschränkung, denn ein Name, der zu einer Adresse auflöst, die der Client nicht erreichen kann, scheitert später und anderswo.

Zwei Clients, dann ein Widerruf

Verbinden Sie zwei Clients gleichzeitig und lesen Sie beide Adressen. Sie müssen verschieden, nutzbar und innerhalb des Pools sein, und jeder muss den Dienst erreichen, für den er gedacht ist. Ein Pool, der doppelte Adressen vergibt, zeigt sich meist hier und nicht im ersten Test mit einem Client.

Widerrufen Sie ein Credential, während der andere Client verbunden bleibt, und versuchen Sie dann den Dienst vom überlebenden Client. Ein Widerruf, der die andere Sitzung stört, weist auf geteilten Zustand hin, meist ein Credential oder eine Adresse, die geräteübergreifend wiederverwendet wird. Verbinden Sie den widerrufenen Client erneut und bestätigen Sie, dass er abgelehnt wird, statt die freigegebene Adresse zu erhalten.

Schließen Sie mit einem Ziel ab, das verweigert werden sollte. Ein Client, der alles erreicht, wurde verbunden, nicht getestet.

Schreiben Sie die vier Werte dorthin, wo die nächste Änderung sie findet

Der Eintrag ist kurz: Poolbereich und Präfix, der Zuweisungsmodus, der Rückweg oder die Übersetzung in Gebrauch und der DNS-Umfang, der für diese Ziele antwortet. Legen Sie ihn neben die Serverkonfiguration statt in ein Ticket, und datieren Sie ihn. Wer später einen der vier ändert, braucht die anderen drei davor, denn eine Poolgrößenänderung bricht die Route und eine Routenänderung bricht die DNS-Antwort.

Halten Sie die Eigentumsnotiz dabei: Der Tunnelbereich gehört dem VPN-Server, und eine im DHCP-Bereich des LAN angelegte Reservierung reserviert nichts für einen Client innerhalb des Tunnels. Diese eine Zeile verhindert die häufigste Nacharbeit, bei der jemand eine Reservierung hinzufügt und erwartet, dass die Tunneladresse ihr folgt.