VGW oder TGW? Wo der IPsec-Tunnel von AWS Site-to-Site endet

Man fragt, wo eine AWS Site-to-Site VPN aufhört, das Paket zu schützen, und erwartet eine einzige Antwort: am Gateway. Die brauchbare Fassung dieser Antwort nennt, welches Gateway, denn ein virtuelles privates Gateway und ein Transit-Gateway sind verschiedene Anordnungen mit verschiedenen Attachment-Objekten, und wer die falsche annimmt, baut den Rest der Bewertung auf einem Diagramm auf, das es nicht gibt. Arbeiten Sie die drei Prüfungen unten der Reihe nach ab. Jede bestätigt entweder die Grenze oder sagt Ihnen, dass die vorherige Antwort eine andere Ressource betraf.

Benennen Sie die drei Endpunkte, bevor Sie irgendetwas bewerten

Eine Verschlüsselungsprüfung dieses Pfads braucht drei benannte Dinge: das Kundengateway, das AWS VPN-Ziel, das IPsec beendet, und den Anwendungsendpunkt, der das innere Paket empfängt. Schreiben Sie sie mit ihren Ressourcenkennungen auf, bevor Sie eine einzige Konsolenseite öffnen, denn alles nach diesem Punkt ist eine Aussage über eines dieser drei.

Das Kundengateway gehört Ihnen, und seine Konfiguration ist für Sie sichtbar. Das AWS-Ziel ist eine verwaltete Ressource, und der Fehler besteht darin, es anzunehmen: Eine VPN-Verbindung kann an ein virtuelles privates Gateway oder direkt an ein Transit-Gateway angebunden werden, und keines schließt das andere ein. Der dritte Endpunkt ist der, den Leute überspringen, und er ist der einzige, der die eigentliche Frage nach den Anwendungsdaten beantwortet.

Prüfung 1: welches Gateway den Tunnel tatsächlich beendet

Beide Anordnungen werden unterstützt, und der Architekturleitfaden für Site-to-Site VPN beschreibt sie nebeneinander, fragen Sie also die API statt ein Diagramm, das oft ein Jahr alt ist. Eine reine Leseabfrage zu einer Verbindung liefert die VPN-Zielfelder:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

Das Unterscheidungsmerkmal ist TransitGatewayId, nicht VpnGatewayId. Eine Verbindung mit leerem TransitGatewayId endet an einem eigenständigen virtuellen privaten Gateway, während eine Verbindung mit gesetztem Feld an einem VPN-Attachment des Transit-Gateways, also einer Anbindung am Transit-Gateway, endet, und VpnGatewayId kann in diesem Fall weiterhin gefüllt sein, weil es das tragende Gateway des Attachments benennen kann. Lesen Sie zuerst das TGW-Feld und bestätigen Sie dann den Attachment-Typ aus der Attachment-Liste statt aus einem Feldnamen, denn ein VPC-Attachment an diesem Transit-Gateway ist nicht das VPN-Attachment. Die Zielinstanz in einer angebundenen VPC zu finden sagt nichts darüber, welches VPN-Attachment das Paket befördert hat.

Prüfen Sie, während Sie dort sind, auch die Tunnel. Die Verbindung trägt zwei IPsec-Tunnel zur Redundanz, und eine Verbindung, deren zweiter Tunnel nie hochgekommen ist, ist ein echter Befund für die Verfügbarkeit, auch wenn er an der Verschlüsselungsgrenze nichts ändert:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

Prüfung 2: was das innere Paket noch trägt

Sobald IPsec endet, leitet AWS das entkapselte Paket über die Route weiter, die darauf passte. Ab diesem Punkt ist der Verkehr gewöhnlicher VPC-Verkehr, und der Schutz der VPN ist beendet. Das ist keine Lücke im Dienst; das ist die Bedeutung der Grenze, und der Punkt auf der Checkliste ist, es klar zu sagen, statt "die VPN ist verschlüsselt" für "die Daten sind Ende zu Ende verschlüsselt" stehen zu lassen.

Untersuchen Sie nun, was innen war. Ist das innere Paket ein Anwendungsprotokoll im Klartext, fügt nichts weiter hinten Vertraulichkeit hinzu, bis etwas anderes es verschlüsselt. Trägt das innere Paket bereits eine TLS-Sitzung, ändert das Entfernen des äußeren IPsec für diese Sitzung nichts: Sie bleibt bis zu ihrem eigenen Endpunkt geschützt, wo dieser Endpunkt auch liegt.

Die übliche Überkorrektur ist der Schluss, alles hinter dem Gateway sei offengelegt. Das ist es nicht. Diensttransport, Speicherverschlüsselung und Anwendungs-TLS sind getrennte Mechanismen mit getrennten Bedingungen, und jeder muss zu seinen eigenen Bedingungen bewertet werden statt aus der Form der VPN abgeleitet zu werden. Ein Flow-Log-Eintrag mit ACCEPT beweist, dass das Routing funktioniert hat, und sagt nichts über Vertraulichkeit, was genau der Fehler ist, den diese Checkliste verhindern soll.

Prüfung 3: was hinter dem Gateway TLS beendet

Folgen Sie dem Listener, nicht der Adresse. Beendet ein Load Balancer oder Proxy TLS, endet die Verbindung Ihres Clients dort, und der Proxy öffnet eine zweite Verbindung zum Backend, die Klartext sein kann oder TLS mit einer anderen Vertrauenskette. Eine private IP-Adresse und eine passende Route sind kein Beleg für diese zweite Verbindung.

Testen Sie den Endpunkt, der Ihnen wirklich wichtig ist, von innerhalb der VPC, mit dem Namen, den die Anwendung verwendet, statt mit einer IP, die Sie einmal aufgelöst haben:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

Wiederholen Sie das für jeden Hop, den die Anfrage durchläuft. Unterscheidet sich die Antwort zwischen dem clientseitigen Namen und dem Backend-Namen, haben Sie genau das Segment gefunden, das die VPN nie abgedeckt hat, und das ist der Befund, der festgehalten werden muss.

Halten Sie das Ergebnis als Segmente fest, nicht als Urteil

Das Ergebnis dieser Checkliste ist eine kleine Tabelle mit einer Zeile pro Segment: Kundengateway zum AWS VPN-Ziel, Gateway zur Arbeitslast, Arbeitslast zum Datenspeicher und jeder Proxy-Hop dazwischen. Jede Zeile sagt, was sie schützt und wovon dieser Schutz abhängt. "Verschlüsselt" ohne Mechanismus und ohne Endpunkt ist keine Zeile.

Beantworten Sie dann die ursprüngliche Anforderung in denselben Begriffen, in denen sie gestellt wurde. Lautet die Anforderung, dass Daten vertraulich bleiben, bis die Arbeitslast sie erhält, erfüllt die VPN nur das erste Segment, und die übrigen Zeilen benötigen Anwendungstransport, Dienst-TLS oder Speicherverschlüsselung, die getrennt konfiguriert und geprüft werden.

Halten Sie die Verbindungskennungen, die Tunnelzustände und die Zertifikatsantragsteller im Protokoll fest. Wenn jemand in sechs Monaten auf das Design zurückkommt, beantworten diese drei Artefakte die Grenzfrage in Minuten, statt die Debatte von einem Diagramm aus neu zu beginnen.