VGW eller TGW? Hvor AWS Site-to-Site IPsec-tunnelen ender

Folk spørger, hvor en AWS Site-to-Site VPN holder op med at beskytte pakken, og forventer ét svar: ved gatewayen. Den brugbare version af det svar navngiver hvilken gateway, fordi en virtuel privat gateway og en transit-gateway er forskellige indretninger med forskellige attachment-objekter, og den anmelder, der antager den forkerte, bygger resten af vurderingen på et diagram, der ikke findes. Gennemfør de tre kontroller nedenfor i rækkefølge. Hver af dem bekræfter enten grænsen eller fortæller dig, at det foregående svar handlede om en anden ressource.

Navngiv de tre endepunkter, før du vurderer noget

En krypteringsrevision af denne vej kræver tre navngivne ting: kundegatewayen, det AWS VPN-mål, der afslutter IPsec, og applikationsendepunktet, der modtager den indre pakke. Skriv dem ned med deres ressource-id'er, før du åbner en enkelt konsolside, fordi alt efter dette punkt er en udtalelse om en af de tre.

Kundegatewayen er din, og dens konfiguration er synlig for dig. AWS-målet er en administreret ressource, og fejlen er at antage det: en VPN-forbindelse kan knytte sig til en virtuel privat gateway eller direkte til en transit-gateway, og ingen af dem forudsætter den anden. Det tredje endepunkt er det, folk springer over, og det er det eneste, der besvarer det egentlige spørgsmål om applikationsdata.

Kontrol 1: hvilken gateway afslutter faktisk tunnelen

Begge indretninger understøttes, og arkitekturvejledningen for Site-to-Site VPN beskriver dem side om side, så spørg API'et i stedet for et diagram, der ofte er et år gammelt. En skrivebeskyttet forespørgsel på én forbindelse returnerer VPN-målfelterne:

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

Det afgørende er TransitGatewayId, ikke VpnGatewayId. En forbindelse med tom TransitGatewayId afsluttes på en selvstændig virtuel privat gateway, mens en forbindelse med feltet udfyldt afsluttes på en VPN-attachment til transit-gatewayen, og VpnGatewayId kan stadig være udfyldt i det tilfælde, fordi det kan navngive attachmentets bærende gateway. Læs TGW-feltet først, og bekræft derefter attachment-typen ud fra attachment-listen i stedet for ud fra et feltnavn, fordi et VPC-attachment på den transit-gateway ikke er VPN-attachmentet. At finde destinationsinstansen i en tilknyttet VPC siger intet om, hvilket VPN-attachment der bar pakken.

Mens du er der, så kontroller tunnelerne. Forbindelsen bærer to IPsec-tunneler af hensyn til redundans, og en forbindelse, hvis anden tunnel aldrig er kommet op, er et reelt fund for tilgængelighed, selv om det intet ændrer ved krypteringsgrænsen:

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

Kontrol 2: hvad den indre pakke stadig bærer

Når IPsec afsluttes, videresender AWS den dekapsulerede pakke ad den rute, der matchede den. Fra det punkt er trafikken almindelig VPC-trafik, og VPN'ens beskyttelse er ophørt. Det er ikke et hul i tjenesten; det er, hvad grænsen betyder, og punktet på tjeklisten er at sige det rent ud i stedet for at lade "VPN'et er krypteret" stå i stedet for "dataene er krypteret ende til ende".

Undersøg nu, hvad der var indeni. Hvis den indre pakke er en applikationsprotokol i klartekst, tilføjer intet nedstrøms fortrolighed, før noget andet krypterer den. Hvis den indre pakke allerede bærer en TLS-session, ændrer fjernelsen af den ydre IPsec intet for den session: den forbliver beskyttet til sit eget endepunkt, hvor det endepunkt så end er.

Den almindelige overkorrektion er at konkludere, at alt bag gatewayen er eksponeret. Det er det ikke. Tjenestetransport, lagerkryptering og applikations-TLS er separate mekanismer med separate betingelser, og hver af dem skal vurderes på sine egne betingelser i stedet for at udledes af VPN'ens form. En flowlogpost, der viser ACCEPT, beviser, at routingen virkede, og siger intet om fortrolighed, hvilket netop er den fejl, denne tjekliste findes for at forhindre.

Kontrol 3: hvad afslutter TLS bag gatewayen

Følg lytteren, ikke adressen. Hvis en load balancer eller proxy afslutter TLS, slutter den forbindelse, din klient holder, der, og proxyen åbner en anden forbindelse til backenden, som kan være klartekst eller TLS med en anden tillidskæde. En privat IP-adresse og en matchende rute er ikke bevis for den anden forbindelse.

Test det endepunkt, du faktisk bekymrer dig om, indefra VPC'en, med det navn applikationen bruger i stedet for en IP, du har slået op én gang:

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

Gentag det for hvert hop, anmodningen passerer. Hvis svaret er forskelligt mellem det klientvendte navn og backend-navnet, har du fundet præcis det segment, VPN'en aldrig dækkede, og det er det fund, der skal skrives ned.

Notér resultatet som segmenter, ikke som en dom

Outputtet af denne tjekliste er en lille tabel med én række pr. segment: kundegateway til AWS VPN-mål, gateway til arbejdsbyrde, arbejdsbyrde til datalager og ethvert proxy-hop ind imellem. Hver række siger, hvad der beskytter den, og hvad den beskyttelse afhænger af. "Krypteret" uden mekanisme og uden endepunkt er ikke en række.

Besvar derefter det oprindelige krav i de samme vendinger, som det blev stillet i. Hvis kravet er, at data forbliver fortrolige, indtil arbejdsbyrden modtager dem, opfylder VPN'en kun det første segment, og de resterende rækker kræver applikationstransport, tjeneste-TLS eller lagerkryptering konfigureret og verificeret særskilt.

Behold forbindelses-id'erne, tunnelstatus og certifikatemnerne i notatet. Når nogen vender tilbage til designet om seks måneder, besvarer de tre artefakter grænsespørgsmålet på få minutter i stedet for at starte diskussionen forfra ud fra et diagram.