AWS Client VPN oder ein Bastion-Host für den Zugriff auf eine Peering-VPC

Ein Client-VPN-Endpoint kann eine VPC erreichen, die mit ihrer zugeordneten VPC peering-verbunden ist, und Sie brauchen keinen Bastion, um das legitim zu machen. Die Entscheidung, die sich lohnt, betrifft den Punkt, an dem der Verkehr den Besitzer wechselt: eine Endpoint-Route, die im Association-Subnetz landet und die Peering-Verbindung überquert, oder ein Host in der Peering-VPC, der die Sitzung beendet. Beide Wege funktionieren und sie scheitern an unterschiedlichen Stellen, also geht es um Eigentum und Audit, nicht darum, was AWS erlaubt. So wähle ich zwischen ihnen, und die vier Einträge, die den gerouteten Weg zum Laufen bringen.

Zwei Wege, ein Endpoint, verschiedene Eigentümer

Auf dem gerouteten Weg erreicht der Client-Verkehr den Endpoint, wird auf die Adresse der Client-VPN-Netzwerkschnittstelle im Association-Subnetz übersetzt und verlässt dieses Subnetz über die Peering-Verbindung von A nach B. VPC B beendet keine VPN-Sitzung; sie sieht gewöhnlichen Verkehr aus VPC A, weshalb ihre Rückroute auf VPC A zeigt und nicht auf den Client-Pool.

Auf dem Bastion-Weg erreicht der Client zuerst einen Host. Ein Bastion in A lässt den letzten Hop noch immer die Peering-Verbindung überqueren, also behalten Sie die Peering-Arbeit und fügen eine Sitzung hinzu. Ein Bastion in B braucht ebenfalls einen Weg vom Client, und wenn dieser Weg dieselbe Endpoint-Route ist, haben Sie das geroutete Design plus einen Hop. Der Bastion spart nur Arbeit, wenn er bereits existiert, bereits genehmigt ist und das dahinter eine Sitzungsgrenze statt einer Netzgrenze braucht.

Vier Einträge bringen den gerouteten Weg zum Laufen

AWS dokumentiert dieses Szenario auf der Client-VPN-how-it-works-Seite, und in der Praxis läuft es auf vier Einträge hinaus, die zwei oder drei Teams besitzen. Die Bereiche sind illustrativ; der Peering-Bereich muss eindeutig sein und der Rückbereich zu Ihrem Plan passen.

Route und Berechtigung sind getrennte Kontrollen. Eine korrekte Endpoint-Route ohne passende Autorisierungsregel gibt dem Client nichts; eine Autorisierungsregel für ein Ziel, das der Endpoint nicht routen kann, gibt ihm ein schwarzes Loch. Beide müssen denselben Bereich nennen.

Die Endpoint-Route zeigt auf ein Subnetz in der eigenen VPC des Endpoints, niemals auf die Peering-Verbindung. Die VPC-Routentabellen zeigen auf die Peering-Verbindung, niemals auf eine Instanz oder eine Schnittstelle. Einen Wert zwischen beiden zu kopieren, wird ohne Beschwerde gespeichert und routet nichts.

Weil das Association-Subnetz die Client-Quelle übersetzt, muss B zurück zu VPC A routen, nicht zum Client-Pool. Den Client-Bereich über die Peering-Verbindung zu senden wirkt symmetrisch, besteht die Prüfung und scheitert still, weil B nie ein Paket mit Client-Quelle sieht.

Sicherheitsgruppen und der letzte Meter der Berechtigung

Routing bringt Pakete in B; B entscheidet weiterhin. Für eine aktive Peering-Verbindung in derselben Region kann eine Sicherheitsgruppe in B die Gruppe referenzieren, die auf die Client-VPN-Assoziation angewendet wird, was die Regel eng hält und Adressänderungen übersteht. Wo eine Gruppenreferenz nicht machbar ist, erlauben Sie den Bereich des Association-Subnetzes ausdrücklich, statt auf 0.0.0.0/0 zu erweitern, was einen Routingfehler in einen unerklärten Timeout verwandelt.

Prüfen Sie dann, was Routing nie berührt: Netzwerk-ACLs auf beiden Subnetzen, die Allow-List der Anwendung oder die Token-Zielgruppe und DNS. Peering kopiert keine privaten gehosteten Zonen, also kann der Laptop eine funktionierende Route zu einer Adresse halten, die er nicht auflösen kann, und eine Peering-Verbindung fügt einem Zertifikat kein Vertrauen hinzu. Richten Sie den Endpoint auf einen Resolver, der für B antwortet, und bestätigen Sie dann, dass privater Name und Zertifikat übereinstimmen.

Wann der Bastion die ehrliche Antwort ist

Ich halte drei Auslöser für die bewusste Wahl eines Bastions. Die Peering-VPC gehört einem Team, das keine Rückroute für Ihren Bereich hinzufügt oder keine Gruppenreferenz akzeptiert. Zugriff muss pro Sitzung genehmigt oder aufgezeichnet werden, und die Anwendung kann das nicht selbst tragen. Oder der letzte Hop muss in B bleiben, weil der Dienst nur dort auflöst und seine TLS-Identität an einen internen Namen gebunden ist.

Nichts davon ist ein Umweg um die Tatsache, dass Peering nicht transitiv ist. Nichttranstivität begrenzt, was Ressourcen in B tun dürfen: Sie können A nicht als Transit zu einer dritten VPC nutzen, mit der A peering-verbunden ist. Es bedeutete nie, dass ein VPN-Benutzer eine direkt peering-verbundene VPC nicht erreichen kann, und ein Bastion, der gebaut wurde, um diese Fehllesung zu umgehen, ist ein Host, der ohne Grund gepatcht wird.

Der umgekehrte Fehler kostet mit der Zeit mehr: Schicken Sie jedes Team durch den einen Bastion, der bereits existiert, und stellen Sie dann fest, dass seine Sicherheitsgruppe, Routentabelle und sein Patch-Fenster die Produktionsabhängigkeit sind. Notieren Sie, welchem Auslöser der Host dient, und ziehen Sie ihn zurück, wenn der Auslöser wegfällt.

Transit Gateway und mehrere Assoziationen ändern die Rechnung

Wenn der Endpoint direkt an ein Transit Gateway statt an ein Subnetz angebunden ist, ändert sich das Modell: Clients werden nicht mehr auf eine Schnittstellenadresse in einem Association-Subnetz übersetzt, und die Gateway-Routentabellen müssen den Client-Bereich plus die Anbindung tragen, die zur Peering-VPC führt. Das ist im Maßstab sauberer, aber die Arbeit wandert von vier Einträgen in Gateway-Routentabellen.

Mehrere Assoziationen vervielfachen die Prüfungen. Die Endpoint-Route gehört dem Endpoint, doch jedes Association-Subnetz braucht eine Routentabelle mit einem echten Peering-Next-Hop. Eine Sitzung kann über eine Assoziation gelingen, während eine andere keinen Rückweg hat, also testen Sie jede.

Prüfreihenfolge, die den Bruch schnell findet

Führen Sie diese der Reihe nach aus; jeder Schritt kann bestehen, während der nächste scheitert, und ein Client-Timeout sagt fast nie, welcher gebrochen ist.

1. Lösen Sie den Anwendungsnamen vom Client auf und prüfen Sie, dass die Adresse im Peering-Bereich liegt.
2. Verbinden Sie sich, und lesen Sie dann das Endpoint-Verbindungsprotokoll für die Assoziation, die die Sitzung beendet hat.
3. Bestätigen Sie in diesem Association-Subnetz, dass die Routentabelle den Peering-Bereich auf eine aktive Peering-Verbindung zeigt.
4. Bestätigen Sie im Ressourcen-Subnetz in B einen Rückeintrag für den Schnittstellenbereich und passende Gruppenregeln.
5. Testen Sie eine erlaubte Operation und eine Ressource, die unerreichbar bleiben muss; die zweite fängt Debug-Reste.
6. Verbinden Sie sich nach jeder Änderung der Split-Tunnel-Route neu, weil ein laufender Tunnel kein neues Routenset aufnimmt.

Zwei Symptome lohnen sich zu merken. Ein SYN, der B ohne Antwort erreicht, ist fast immer die fehlende Rückroute. Eine Verbindung, die abgeschlossen und dann zurückgesetzt wird, ist meist die Gruppe, die ACL oder die Anwendung. Keines erscheint im Endpoint-Protokoll als Ursache, also halten Sie die vier Einträge mit einem Eigentümer neben jedem.

Wenn keiner der drei Auslöser zutrifft, schließen Sie den gerouteten Weg ab und zeichnen Sie diese vier Einträge auf. Wenn einer zutrifft, behalten Sie den Bastion nur für diese Grenze und überlassen Sie die Endpoint-Route Diensten, die keine Sitzung davor brauchen.