VGW eller TGW? Kvar AWS Site-to-Site IPsec-tunnelen endar

Folk spør kvar ein AWS Site-to-Site VPN sluttar å verne pakken, og ventar eitt svar: ved gatewayen. Den nyttige versjonen av svaret namngjev kva gateway, fordi ein virtuell privat gateway og ein transitt-gateway er ulike ordningar med ulike festeobjekt, og den som vurderer og legg den gale til grunn, byggjer resten av vurderinga på eit diagram som ikkje finst. Gå gjennom dei tre kontrollane nedanfor i rekkjefølgje. Kvar av dei stadfester anten grensa eller fortel deg at det førre svaret gjaldt ein annan ressurs.

Namngje dei tre endepunkta før du vurderer noko

Ein krypteringsgjennomgang av denne vegen treng tre namngjevne ting: kundegatewayen, AWS VPN-målet som avsluttar IPsec, og applikasjonsendepunktet som tek imot den indre pakken. Skriv dei ned med ressurs-ID-ane sine før du opnar éi einaste konsollside, fordi alt etter dette punktet er ei påstand om éin av dei tre.

Kundegatewayen er din, og konfigurasjonen er synleg for deg. AWS-målet er ein administrert ressurs, og feilen er å ta det for gjeve: ein VPN-tilkopling kan knytast til ein virtuell privat gateway eller direkte til ein transitt-gateway, og ingen av dei føreset den andre. Det tredje endepunktet er det folk hoppar over, og det er det einaste som svarar på det eigentlege spørsmålet om applikasjonsdata.

Kontroll 1: kva gateway som faktisk avsluttar tunnelen

Begge ordningane er støtta, og arkitekturrettleiinga for Site-to-Site VPN skildrar dei side om side, så spør API-et i staden for eit diagram som ofte er eitt år gammalt. Ei skriveverna spørjing på éi tilkopling returnerer VPN-målfelta:

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 avgjerande er TransitGatewayId, ikkje VpnGatewayId. Ei tilkopling med tom TransitGatewayId avsluttast på ein frittståande virtuell privat gateway, medan ei tilkopling med feltet sett avsluttast på eit VPN-feste til transitt-gatewayen, og VpnGatewayId kan framleis vere fylt ut i det tilfellet fordi det kan namngje den berande gatewayen til festet. Les TGW-feltet først, og stadfest deretter festetypen frå festelista i staden for frå eit feltnamn, fordi eit VPC-feste på den transitt-gatewayen ikkje er VPN-festet. Å finne målforekomsten i ein tilknytt VPC seier ingenting om kva VPN-feste som bar pakken.

Medan du er der, kontroller tunnlane. Tilkoplinga ber to IPsec-tunnelar for redundans, og ei tilkopling der den andre tunnelen aldri har kome opp, er eit reelt funn for tilgjenge sjølv om det ikkje endrar noko ved krypteringsgrensa:

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: kva den indre pakken framleis ber

Når IPsec avsluttast, sender AWS den dekapsulerte pakken vidare langs ruta som passa til han. Frå det punktet er trafikken vanleg VPC-trafikk, og vernet til VPN-en er over. Det er ikkje eit hol i tenesta; det er kva grensa tyder, og punktet på sjekklista er å seie det rett ut i staden for å la "VPN-en er kryptert" stå i staden for "dataa er krypterte frå ende til ende".

Undersøk no kva som var inni. Viss den indre pakken er ein applikasjonsprotokoll i klartekst, legg ingenting nedstraums til konfidensialitet før noko anna krypterer han. Viss den indre pakken alt ber ei TLS-økt, endrar fjerninga av den ytre IPsec ingenting for den økta: ho blir verande verna til sitt eige endepunkt, uansett kvar det endepunktet er.

Den vanlege overkorreksjonen er å konkludere med at alt bak gatewayen er eksponert. Det er det ikkje. Tenestetransport, lagringskryptering og applikasjons-TLS er separate mekanismar med separate vilkår, og kvar av dei må vurderast på eigne premissar i staden for å utleiast frå forma til VPN-en. Ei flytloggoppføring som viser ACCEPT, beviser at rutinga verka og seier ingenting om konfidensialitet, som er nettopp feilen denne sjekklista finst for å hindre.

Kontroll 3: kva som avsluttar TLS bak gatewayen

Fylg lyttaren, ikkje adressa. Viss ein lastbalansar eller proxy avsluttar TLS, sluttar tilkoplinga klienten din held der, og proxyen opnar ei andre tilkopling til bakenden som kan vere klartekst eller TLS med ei anna tillitskjede. Ei privat IP-adresse og ei samsvarande rute er ikkje prov om den andre tilkoplinga.

Test endepunktet du faktisk bryr deg om, innanfrå VPC-en, med namnet applikasjonen brukar i staden for ein IP du slo opp éin gong:

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

Gjenta det for kvar hopp førespurnaden går gjennom. Viss svaret er ulikt mellom det klientvendte namnet og backend-namnet, har du funne nøyaktig det segmentet VPN-en aldri dekte, og det er funnet som skal skrivast ned.

Registrer resultatet som segment, ikkje som dom

Utdataa frå denne sjekklista er ein liten tabell med éi rad per segment: kundegateway til AWS VPN-mål, gateway til arbeidslast, arbeidslast til datalager, og kvar proxy-hopp imellom. Kvar rad seier kva som vernar henne, og kva det vernet avheng av. "Kryptert" utan mekanisme og utan endepunkt er ikkje ei rad.

Svar deretter på det opphavlege kravet med dei same omgrepa det vart stilt i. Viss kravet er at data blir verande konfidensielle til arbeidslasta tek imot dei, oppfyller VPN-en berre det første segmentet, og dei attverande radene treng applikasjonstransport, teneste-TLS eller lagringskryptering sett opp og stadfesta kvar for seg.

Ta vare på tilkopling-ID-ane, tunnelstatusane og sertifikatobjekta i protokollen. Når nokon kjem tilbake til designet om seks månader, svarar desse tre artefaktane på grensespørsmålet på få minutt i staden for å starte diskusjonen på nytt frå eit diagram.