VGW of TGW? Waar de IPsec-tunnel van AWS Site-to-Site eindigt

Mensen vragen waar een AWS Site-to-Site VPN stopt met het beschermen van het pakket en verwachten één antwoord: bij de gateway. De bruikbare versie van dat antwoord noemt welke gateway, want een virtuele privégateway en een transitgateway zijn verschillende opstellingen met verschillende bijlage-objecten, en de beoordelaar die de verkeerde aanneemt, bouwt de rest van de beoordeling op een diagram dat niet bestaat. Werk de drie controles hieronder in volgorde af. Elk bevestigt de grens of vertelt je dat het vorige antwoord over een andere resource ging.

Benoem de drie eindpunten voordat je iets beoordeelt

Een encryptiebeoordeling van dit pad heeft drie benoemde dingen nodig: de klantgateway, het AWS VPN-doel dat IPsec beëindigt, en het applicatie-eindpunt dat het binnenste pakket ontvangt. Schrijf ze met hun resource-ID's op voordat je één consolepagina opent, want alles na dit punt is een uitspraak over een van die drie.

De klantgateway is van jou en de configuratie ervan is voor jou zichtbaar. Het AWS-doel is een beheerde resource, en de fout is om die aan te nemen: een VPN-verbinding kan aan een virtuele privégateway of rechtstreeks aan een transitgateway worden gekoppeld, en geen van beide impliceert de andere. Het derde eindpunt is degene die mensen overslaan, en het is het enige dat de echte vraag over applicatiegegevens beantwoordt.

Controle 1: welke gateway de tunnel werkelijk beëindigt

Beide opstellingen worden ondersteund en de architectuurgids voor Site-to-Site VPN beschrijft ze naast elkaar, dus vraag de API in plaats van een diagram dat vaak een jaar oud is. Een alleen-lezen query op één verbinding geeft de VPN-doelvelden terug:

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}'

Het onderscheidende veld is TransitGatewayId, niet VpnGatewayId. Een verbinding met een leeg TransitGatewayId eindigt op een zelfstandige virtuele privégateway, terwijl een verbinding met dat veld ingesteld eindigt op een VPN-bijlage van de transitgateway, en VpnGatewayId kan in dat geval nog gevuld zijn omdat het de onderliggende gateway van de bijlage kan benoemen. Lees eerst het TGW-veld en bevestig daarna het bijlagetype uit de bijlagelijst in plaats van uit een veldnaam, want een VPC-bijlage op die transitgateway is niet de VPN-bijlage. De doelinstantie in een gekoppelde VPC vinden zegt niets over welke VPN-bijlage het pakket heeft gedragen.

Controleer terwijl je daar bent ook de tunnels. De verbinding draagt twee IPsec-tunnels voor redundantie, en een verbinding waarvan de tweede tunnel nooit is opgekomen is een echte bevinding voor beschikbaarheid, ook al verandert het niets aan de encryptiegrens:

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}'

Controle 2: wat het binnenste pakket nog draagt

Zodra IPsec eindigt, stuurt AWS het gedekapsuleerde pakket door via de route die erbij paste. Vanaf dat punt is het verkeer gewoon VPC-verkeer, en de bescherming van de VPN is voorbij. Dat is geen gat in de dienst; dat is wat de grens betekent, en het punt op de checklist is het gewoon zeggen in plaats van "de VPN is versleuteld" in de plaats te laten staan van "de gegevens zijn van begin tot eind versleuteld".

Onderzoek nu wat er binnenin zat. Als het binnenste pakket een applicatieprotocol in platte tekst is, voegt niets stroomafwaarts vertrouwelijkheid toe tot iets anders het versleutelt. Als het binnenste pakket al een TLS-sessie draagt, verandert het verwijderen van de buitenste IPsec niets voor die sessie: die blijft beschermd tot zijn eigen eindpunt, waar dat eindpunt ook is.

De gebruikelijke overcorrectie is concluderen dat alles achter de gateway is blootgesteld. Dat is niet zo. Diensttransport, opslagversleuteling en applicatie-TLS zijn afzonderlijke mechanismen met afzonderlijke voorwaarden, en elk moet op zijn eigen voorwaarden worden beoordeeld in plaats van uit de vorm van de VPN te worden afgeleid. Een flowlogboekregel met ACCEPT bewijst dat de routering werkte en zegt niets over vertrouwelijkheid, wat precies de fout is die deze checklist moet voorkomen.

Controle 3: wat TLS achter de gateway beëindigt

Volg de listener, niet het adres. Als een loadbalancer of proxy TLS beëindigt, eindigt de verbinding die je client houdt daar, en de proxy opent een tweede verbinding naar de backend die platte tekst kan zijn of TLS met een andere vertrouwensketen. Een privé-IP-adres en een passende route zijn geen bewijs over die tweede verbinding.

Test het eindpunt dat je echt aangaat van binnenuit de VPC, met de naam die de applicatie gebruikt in plaats van een IP dat je één keer hebt opgelost:

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

Herhaal dat voor elke hop die het verzoek passeert. Als het antwoord verschilt tussen de naam die naar de client is gericht en de backendnaam, heb je precies het segment gevonden dat de VPN nooit heeft gedekt, en dat is de bevinding die moet worden opgeschreven.

Leg het resultaat vast als segmenten, niet als oordeel

De uitvoer van deze checklist is een kleine tabel met één rij per segment: klantgateway naar AWS VPN-doel, gateway naar werklast, werklast naar gegevensopslag, en elke proxy-hop daartussen. Elke rij zegt wat het beschermt en waarvan die bescherming afhangt. "Versleuteld" zonder mechanisme en zonder eindpunt is geen rij.

Beantwoord daarna de oorspronkelijke eis in dezelfde bewoordingen waarin die is gesteld. Als de eis is dat gegevens vertrouwelijk blijven tot de werklast ze ontvangt, voldoet de VPN alleen aan het eerste segment, en de resterende rijen hebben applicatietransport, dienst-TLS of opslagversleuteling nodig, apart geconfigureerd en geverifieerd.

Bewaar de verbindings-ID's, de tunnelstatussen en de certificaatonderwerpen in het verslag. Wanneer iemand over zes maanden op het ontwerp terugkomt, beantwoorden die drie artefacten de grensvraag in minuten in plaats van de discussie opnieuw vanaf een diagram te beginnen.