Der Client-CIDR von AWS Client VPN darf den VPC-Bereich nicht überlappen

Ein AWS Client VPN-Endpunkt vergibt Client-Adressen aus einem Pool, den Sie wählen, und AWS prüft diesen Pool gegen das Zielnetz, bevor es den Endpunkt erstellt. Die Prüfung gilt nicht der Frage, ob ein Subnetz frei aussieht. Sie gilt der Frage, ob der Pool den VPC-Bereich überlappt, und die Antwort ist dieselbe, ob eine EC2-Instanz diese Adressen heute zufällig nutzt oder nicht. Überlappung ist eine Frage der Bereiche, nicht der Zuweisungen.

Arbeiten Sie fünf Prüfungen der Reihe nach ab. Halten Sie bei der ersten an, die fehlschlägt, denn kein späterer Schritt kann eine frühere Entscheidung reparieren.

Überlappung ist ein Bereichstest, kein Test auf freie Adressen

Beginnen Sie beim VPC-CIDR, nicht bei dem Subnetz, das Sie zuordnen wollen. Ein Pool von 172.20.0.0/22 liegt in einer VPC von 172.20.0.0/16 und wird abgelehnt, auch wenn kein Subnetz ihn belegt, weil Überlappung eine Eigenschaft der Bereiche ist und nicht der aktuellen Zuweisungen. Fügen Sie dann die Ziele hinzu, zu denen der Endpunkt routet: gepeerte VPCs, ein Transit-Gateway, lokale Bereiche über eine Site-to-Site-Verbindung. Jeder Bereich, den ein Client erreichen können muss, gehört in die Liste.

Sammeln Sie sie aus dem Konto statt aus dem Gedächtnis: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", dazu die Routentabelleneinträge für das Subnetz, das Sie zuordnen wollen.

Die Poolgröße wird vor dem Aufbau entschieden

AWS akzeptiert bei Client VPN einen IPv4-Client-Pool zwischen /22 und /12. Ein /24 ist zu klein, ein /8 liegt außerhalb des dokumentierten Bereichs, und beide Fehler entstehen daraus, den Pool wie ein Workload-Subnetz zu bemessen. Bemessen Sie ihn nach erwarteten gleichzeitigen Clients plus Reserve und runden Sie dann auf ein zulässiges Präfix.

Prüfen Sie die Arithmetik, bevor Sie sie in die Konsole tippen, denn ein vertipptes Präfix ändert die Poolgröße ohne jede Warnung:

python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"

Das gibt die Adressanzahl, die Präfixlänge und die Kollision des Kandidaten mit dem VPC-Bereich aus, was schneller ist, als am Ende eines Änderungsfensters über Netzmasken nachzudenken.

Der Resolver hat eine eigene Adressrolle

Der VPC-Resolver antwortet auf der Basisadresse des VPC-Bereichs plus zwei, die nicht zwingend im zugeordneten Subnetz liegt. Die Annahme, der Resolver müsse im Client-Pool leben, oder ein Subnetz um diese Adresse zu bauen, fügt Objekte hinzu, ohne etwas zu ändern. Entscheidend ist, dass der Endpunkt eine DNS-Einstellung trägt, die der Client anwenden kann, und dass der Resolver aus dem Tunnel erreichbar ist.

Halten Sie Resolver, Client-Pool und zugeordnetes Subnetz als drei getrennte Punkte im Adressplan fest. Sie fallen unabhängig aus, und dass einer richtig ist, sagt nichts über die anderen zwei.

Vier Felder, auf die Sie sich bei der Erstellung festlegen

Der IPv4-Client-CIDR ist bei der Erstellung fest. Den DNS-Server zu wechseln, eine Zuordnung hinzuzufügen, die Sicherheitsgruppe zu tauschen, Autorisierungsregeln zu bearbeiten oder Split-Tunnel-Routen zu ändern sind alles gewöhnliche Änderungen, und keine davon benennt den Pool um. Diese Asymmetrie ist der Grund, warum das eine Überprüfung verdient: Die billigen Einstellungen sind die, die Sie später ändern wollen, und die teure ist die, auf die Sie sich zuerst festlegen. Lesen Sie die Endpunktbeschreibung, bevor Sie ein Änderungsfenster planen.

Prüfen Sie den bereitgestellten Endpunkt, bevor Sie einen Neuaufbau annehmen. aws ec2 describe-client-vpn-endpoints liefert Pool, DNS, Split-Tunnel-Kennzeichen und Zuordnungen in einer Antwort, was meist genügt, um einen Neuaufbau auszuschließen.

Ersetzen Sie den Endpunkt, statt ihn zu flicken

Ein neuer Endpunkt ist ein neuer Endpunkt, keine Migration. Bestehende Sitzungen wechseln nicht dorthin, Client-Profile zeigen auf einen anderen Namen, und jede Einstellung, die Sie als selbstverständlich betrachtet haben, muss neu erstellt werden: Serverzertifikat, Authentifizierung, Zuordnungen, Routen, Autorisierungsgruppen, Logging. Validieren Sie mit einem Client gegen einen erforderlichen privaten Dienst und gegen ein Ziel, das abgelehnt werden muss, und erweitern Sie dann den Zugriff. Alles Ausgelassene wird später zu einem Support-Ticket.

Lassen Sie den alten Endpunkt laufen, bis diese Validierung besteht, und behalten Sie einen administrativen Weg, der nicht vom neuen abhängt.

Eine Grenze, die erwähnt werden sollte: Dies deckt den IPv4-Client-Pool ab. Einstellungen für Dual-Stack- und IPv6-Datenverkehr bei Client VPN folgen ihrem eigenen Adressierungsmodell, also übernehmen Sie diese Checkliste nicht, ohne die Dokumentation für diesen Modus zu lesen.