VGW eller TGW? Var AWS Site-to-Site IPsec-tunneln slutar

Folk frågar var en AWS Site-to-Site VPN slutar skydda paketet och förväntar sig ett enda svar: vid gatewayen. Den användbara versionen av svaret namnger vilken gateway, eftersom en virtuell privat gateway och en transit-gateway är olika uppsättningar med olika anslutningsobjekt, och den granskare som antar den felaktiga bygger resten av bedömningen på ett diagram som inte finns. Gå igenom de tre kontrollerna nedan i ordning. Var och en bekräftar antingen gränsen eller säger att det förra svaret gällde en annan resurs.

Namnge de tre ändpunkterna innan du bedömer något

En krypteringsgranskning av den här vägen behöver tre namngivna saker: kundgatewayen, AWS VPN-målet som avslutar IPsec och applikationens ändpunkt som tar emot det inre paketet. Skriv ner dem med sina resurs-ID:n innan du öppnar en enda konsolsida, eftersom allt efter den punkten är ett påstående om en av de tre.

Kundgatewayen är din och konfigurationen är synlig för dig. AWS-målet är en hanterad resurs, och felet är att ta det för givet: en VPN-anslutning kan kopplas till en virtuell privat gateway eller direkt till en transit-gateway, och ingen av dem förutsätter den andra. Den tredje ändpunkten är den folk hoppar över, och den är den enda som svarar på den egentliga frågan om applikationsdata.

Kontroll 1: vilken gateway som faktiskt avslutar tunneln

Båda uppsättningarna stöds och arkitekturhandboken för Site-to-Site VPN beskriver dem sida vid sida, så fråga API:et i stället för ett diagram som ofta är ett år gammalt. En skrivskyddad fråga på en anslutning returnerar VPN-målfälten:

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 avgörande är TransitGatewayId, inte VpnGatewayId. En anslutning med tomt TransitGatewayId avslutas på en fristående virtuell privat gateway, medan en anslutning med fältet satt avslutas på en VPN-anslutning till transit-gatewayen, och VpnGatewayId kan fortfarande vara ifyllt i det fallet eftersom det kan namnge anslutningens bärande gateway. Läs TGW-fältet först och bekräfta sedan anslutningstypen från anslutningslistan i stället för från ett fältnamn, eftersom en VPC-anslutning på den transit-gatewayen inte är VPN-anslutningen. Att hitta målforekomsten i en ansluten VPC säger ingenting om vilken VPN-anslutning som bar paketet.

Medan du är där, kontrollera tunnlarna. Anslutningen bär två IPsec-tunnlar för redundans, och en anslutning vars andra tunnel aldrig har kommit upp är ett verkligt fynd för tillgänglighet även om det inte ändrar något vid 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}'

Kontroll 2: vad det inre paketet fortfarande bär

När IPsec avslutas vidarebefordrar AWS det avkapslade paketet längs den rutt som passade det. Från den punkten är trafiken vanlig VPC-trafik, och VPN:ens skydd har upphört. Det är inte en lucka i tjänsten; det är vad gränsen betyder, och punkten på checklistan är att säga det rakt ut i stället för att låta "VPN:en är krypterad" stå i stället för "data är krypterade från ände till ände".

Undersök nu vad som fanns inuti. Om det inre paketet är ett applikationsprotokoll i klartext lägger ingenting nedströms till konfidentialitet förrän något annat krypterar det. Om det inre paketet redan bär en TLS-session ändrar borttagandet av det yttre IPsec ingenting för den sessionen: den förblir skyddad till sin egen ändpunkt, var den ändpunkten än ligger.

Den vanliga överkorrigeringen är att dra slutsatsen att allt bakom gatewayen är exponerat. Det är det inte. Tjänstetransport, lagringskryptering och applikations-TLS är separata mekanismer med separata villkor, och var och en måste bedömas på sina egna villkor i stället för att härledas från VPN:ens form. En flödesloggpost som visar ACCEPT bevisar att routningen fungerade och säger ingenting om konfidentialitet, vilket är precis det fel som denna checklista finns för att förhindra.

Kontroll 3: vad som avslutar TLS bakom gatewayen

Följ lyssnaren, inte adressen. Om en lastbalanserare eller proxy avslutar TLS slutar anslutningen som din klient håller där, och proxyn öppnar en andra anslutning till backend som kan vara klartext eller TLS med en annan förtroendekedja. En privat IP-adress och en matchande rutt är inte bevis om den andra anslutningen.

Testa den ändpunkt du faktiskt bryr dig om inifrån VPC:n, med namnet applikationen använder i stället för en IP som du slog upp en gång:

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

Upprepa det för varje hopp som begäran passerar. Om svaret skiljer sig mellan det klientvända namnet och backendnamnet har du hittat exakt det segment som VPN:en aldrig täckte, och det är fyndet som ska skrivas ner.

Registrera resultatet som segment, inte som dom

Utdata från denna checklista är en liten tabell med en rad per segment: kundgateway till AWS VPN-mål, gateway till arbetsbelastning, arbetsbelastning till datalager och varje proxy-hopp däremellan. Varje rad säger vad som skyddar den och vad det skyddet beror på. "Krypterat" utan mekanism och utan ändpunkt är inte en rad.

Svara sedan på det ursprungliga kravet med samma ord som det ställdes i. Om kravet är att data förblir konfidentiella tills arbetsbelastningen tar emot dem, uppfyller VPN:en bara det första segmentet, och de återstående raderna behöver applikationstransport, tjänste-TLS eller lagringskryptering konfigurerad och verifierad separat.

Behåll anslutnings-ID:na, tunnelstatusarna och certifikatämnena i protokollet. När någon återvänder till designen om sex månader svarar dessa tre artefakter på gränsfrågan på några minuter i stället för att starta diskussionen på nytt från ett diagram.