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

Folk spør hvor en AWS Site-to-Site VPN slutter å beskytte pakken, og forventer ett svar: ved gatewayen. Den nyttige versjonen av svaret navngir hvilken gateway, fordi en virtuell privat gateway og en transit-gateway er ulike ordninger med ulike vedleggsobjekter, og den som vurderer og antar den gale, bygger resten av vurderingen på et diagram som ikke finnes. Gå gjennom de tre kontrollene nedenfor i rekkefølge. Hver av dem bekrefter enten grensen eller forteller deg at det forrige svaret gjaldt en annen ressurs.

Navngi de tre endepunktene før du vurderer noe

En krypteringsgjennomgang av denne veien trenger tre navngitte ting: kundegatewayen, AWS VPN-målet som avslutter IPsec, og applikasjonsendepunktet som mottar den indre pakken. Skriv dem ned med ressurs-ID-ene sine før du åpner én eneste konsollside, fordi alt etter dette punktet er en påstand om én av de tre.

Kundegatewayen er din, og konfigurasjonen er synlig for deg. AWS-målet er en administrert ressurs, og feilen er å ta det for gitt: en VPN-tilkobling kan knyttes til en virtuell privat gateway eller direkte til en transit-gateway, og ingen av dem forutsetter den andre. Det tredje endepunktet er det folk hopper over, og det er det eneste som svarer på det egentlige spørsmålet om applikasjonsdata.

Kontroll 1: hvilken gateway som faktisk avslutter tunnelen

Begge ordningene støttes, og arkitekturveiledningen for Site-to-Site VPN beskriver dem side om side, så spør API-et i stedet for et diagram som ofte er et år gammelt. En skrivebeskyttet spørring på én tilkobling returnerer VPN-målfeltene:

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 avgjørende er TransitGatewayId, ikke VpnGatewayId. En tilkobling med tom TransitGatewayId avsluttes på en frittstående virtuell privat gateway, mens en tilkobling med feltet satt avsluttes på et VPN-vedlegg til transit-gatewayen, og VpnGatewayId kan fortsatt være utfylt i det tilfellet fordi det kan navngi vedleggets bærende gateway. Les TGW-feltet først, og bekreft deretter vedleggstypen fra vedleggslisten i stedet for fra et feltnavn, fordi et VPC-vedlegg på den transit-gatewayen ikke er VPN-vedlegget. Å finne målforekomsten i en tilknyttet VPC sier ingenting om hvilket VPN-vedlegg som bar pakken.

Mens du er der, kontroller tunnelene. Tilkoblingen bærer to IPsec-tunneler for redundans, og en tilkobling der den andre tunnelen aldri har kommet opp, er et reelt funn for tilgjengelighet selv om det ikke endrer noe ved krypteringsgrensen:

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

Kontroll 2: hva den indre pakken fortsatt bærer

Når IPsec avsluttes, videresender AWS den dekapsulerte pakken langs ruten som passet til den. Fra det punktet er trafikken vanlig VPC-trafikk, og VPN-ens beskyttelse er over. Det er ikke et hull i tjenesten; det er hva grensen betyr, og punktet på sjekklisten er å si det rett ut i stedet for å la "VPN-et er kryptert" stå i stedet for "dataene er kryptert ende til ende".

Undersøk nå hva som var inni. Hvis den indre pakken er en applikasjonsprotokoll i klartekst, legger ingenting nedstrøms til konfidensialitet før noe annet krypterer den. Hvis den indre pakken allerede bærer en TLS-økt, endrer fjerningen av den ytre IPsec ingenting for den økten: den forblir beskyttet til sitt eget endepunkt, uansett hvor det endepunktet er.

Den vanlige overkorreksjonen er å konkludere med at alt bak gatewayen er eksponert. Det er det ikke. Tjenestetransport, lagringskryptering og applikasjons-TLS er separate mekanismer med separate betingelser, og hver av dem må vurderes på egne premisser i stedet for å utledes fra VPN-ens form. En flytloggoppføring som viser ACCEPT beviser at rutingen virket og sier ingenting om konfidensialitet, som er nettopp feilen denne sjekklisten finnes for å forhindre.

Kontroll 3: hva som avslutter TLS bak gatewayen

Følg lytteren, ikke adressen. Hvis en lastbalanserer eller proxy avslutter TLS, slutter tilkoblingen klienten din holder der, og proxyen åpner en andre tilkobling til backend som kan være klartekst eller TLS med en annen tillitskjede. En privat IP-adresse og en samsvarende rute er ikke bevis om den andre tilkoblingen.

Test endepunktet du faktisk bryr deg om, innenfra VPC-en, med navnet applikasjonen bruker i stedet for en IP du slo opp én gang:

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

Gjenta det for hvert hopp forespørselen går gjennom. Hvis svaret er forskjellig mellom det klientvendte navnet og backend-navnet, har du funnet nøyaktig det segmentet VPN-en aldri dekket, og det er funnet som skal skrives ned.

Registrer resultatet som segmenter, ikke som dom

Utdataene fra denne sjekklisten er en liten tabell med én rad per segment: kundegateway til AWS VPN-mål, gateway til arbeidsbelastning, arbeidsbelastning til datalager, og ethvert proxy-hopp imellom. Hver rad sier hva som beskytter den, og hva den beskyttelsen avhenger av. "Kryptert" uten mekanisme og uten endepunkt er ikke en rad.

Svar deretter på det opprinnelige kravet med de samme begrepene det ble stilt i. Hvis kravet er at data blir konfidensielle til arbeidsbelastningen mottar dem, oppfyller VPN-en bare det første segmentet, og de resterende radene trenger applikasjonstransport, tjeneste-TLS eller lagringskryptering konfigurert og verifisert separat.

Ta vare på tilkoblings-ID-ene, tunnelstatusene og sertifikatsobjektene i protokollen. Når noen kommer tilbake til designet om seks måneder, svarer disse tre artefaktene på grensespørsmålet på minutter i stedet for å starte diskusjonen på nytt fra et diagram.