VGW ali TGW? Kje se konča tunel IPsec pri AWS Site-to-Site

Ljudje sprašujejo, kje AWS Site-to-Site VPN neha ščititi paket, in pričakujejo en odgovor: na prehodu. Uporabna različica tega odgovora poimenuje, kateri prehod, ker sta virtualni zasebni prehod in tranzitni prehod različni ureditvi z različnimi objekti priključka, in recenzent, ki predpostavi napačno, zgradi preostanek ocene na diagramu, ki ne obstaja. Izvedite tri spodnje kontrole po vrsti. Vsaka bodisi potrdi mejo bodisi pove, da je prejšnji odgovor veljal za drug vir.

Poimenujte tri končne točke, preden karkoli ocenite

Pregled šifriranja te poti potrebuje tri poimenovane stvari: prehod odjemalca, cilj AWS VPN, ki zaključi IPsec, in končno točko aplikacije, ki prejme notranji paket. Zapišite jih z identifikatorji virov, preden odprete eno samo stran konzole, ker je vse po tej točki trditev o enem od teh treh.

Prehod odjemalca je vaš in njegova konfiguracija vam je vidna. Cilj AWS je upravljani vir in napaka je, da ga predpostavite: povezava VPN se lahko priključi na virtualni zasebni prehod ali neposredno na tranzitni prehod in nobeno ne pomeni drugega. Tretja končna točka je tista, ki jo ljudje preskočijo, in je edina, ki odgovori na resnično vprašanje o podatkih aplikacije.

Kontrola 1: kateri prehod tunel dejansko zaključi

Obe ureditvi sta podprti in vodnik po arhitekturi Site-to-Site VPN ju opisuje drugo ob drugi, zato vprašajte API in ne diagrama, ki je pogosto star eno leto. Poizvedba samo za branje na eni povezavi vrne polja cilja VPN:

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

Razlikovalni element je TransitGatewayId, ne VpnGatewayId. Povezava s praznim TransitGatewayId se konča na samostojnem virtualnem zasebnem prehodu, medtem ko se povezava z nastavljenim tem poljem konča na priključku VPN tranzitnega prehoda, in VpnGatewayId je v tem primeru lahko še vedno izpolnjen, ker lahko poimenuje nosilni prehod priključka. Najprej preberite polje TGW, nato potrdite vrsto priključka s seznama priključkov, ne iz imena polja, ker priključek VPC na tem tranzitnem prehodu ni priključek VPN. Iskanje ciljnega primerka v povezanem VPC vam ne pove ničesar o tem, kateri priključek VPN je prenesel paket.

Medtem ko ste tam, preverite tudi tunele. Povezava nosi dva tunela IPsec za redundanco, in povezava, katere drugi tunel se ni nikoli dvignil, je resnična ugotovitev za razpoložljivost, čeprav na meji šifriranja ne spremeni ničesar:

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

Kontrola 2: kaj notranji paket še nosi

Ko se IPsec konča, AWS posreduje dekapsulirani paket po poti, ki se mu je ujemala. Od te točke je promet običajen promet VPC in zaščita VPN je končana. To ni vrzel v storitvi; to je pomen meje, in točka na kontrolnem seznamu je, da to poveste jasno, namesto da pustite "VPN je šifriran", da stoji namesto "podatki so šifrirani od konca do konca".

Zdaj preglejte, kaj je bilo notri. Če je notranji paket aplikacijski protokol v čistem besedilu, nič dolvodno ne doda zaupnosti, dokler ga nekaj drugega ne šifrira. Če notranji paket že nosi sejo TLS, odstranitev zunanjega IPsec za to sejo ne spremeni ničesar: ostane zaščitena do svoje lastne končne točke, kjer koli je ta končna točka.

Pogosta pretirana poprava je sklep, da je vse za prehodom izpostavljeno. Ni. Prenos storitve, šifriranje shrambe in aplikacijski TLS so ločeni mehanizmi z ločenimi pogoji, in vsakega je treba oceniti po njegovih lastnih pogojih, ne pa ga izpeljati iz oblike VPN. Vnos v dnevniku tokov z ACCEPT dokazuje, da je usmerjanje delovalo, in ne pove ničesar o zaupnosti, kar je natanko tista napaka, ki naj bi jo ta kontrolni seznam preprečil.

Kontrola 3: kaj zaključi TLS za prehodom

Sledite poslušalcu, ne naslovu. Če razporejevalnik obremenitve ali posrednik zaključi TLS, se povezava, ki jo drži vaš odjemalec, konča tam, in posrednik odpre drugo povezavo do zaledja, ki je lahko čisto besedilo ali TLS z drugo verigo zaupanja. Zasebni naslov IP in ujemajoča se pot nista dokaz o tej drugi povezavi.

Preizkusite končno točko, ki vam je resnično pomembna, od znotraj VPC, z imenom, ki ga uporablja aplikacija, in ne z naslovom IP, ki ste ga enkrat razrešili:

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

Ponovite to za vsak skok, skozi katerega gre zahteva. Če se odgovor razlikuje med imenom, obrnjenim k odjemalcu, in imenom zaledja, ste našli natanko tisti segment, ki ga VPN ni nikoli pokril, in to je ugotovitev, ki jo je treba zapisati.

Rezultat zapišite kot segmente, ne kot sodbo

Izhod tega kontrolnega seznama je majhna tabela z eno vrstico na segment: prehod odjemalca do cilja AWS VPN, prehod do delovne obremenitve, delovna obremenitev do shrambe podatkov in vsak skok posrednika vmes. Vsaka vrstica pove, kaj jo ščiti in od česa je ta zaščita odvisna. "Šifrirano" brez mehanizma in brez končne točke ni vrstica.

Nato odgovorite na prvotno zahtevo z istimi izrazi, s katerimi je bila postavljena. Če je zahteva, da podatki ostanejo zaupni, dokler jih delovna obremenitev ne prejme, VPN izpolni le prvi segment, preostale vrstice pa potrebujejo prenos aplikacije, storitveni TLS ali šifriranje shrambe, ločeno nastavljeno in preverjeno.

Shranite identifikatorje povezav, stanja tunelov in subjekte potrdil v zapis. Ko se nekdo po pol leta vrne k zasnovi, ti trije artefakti odgovorijo na vprašanje o meji v nekaj minutah, namesto da bi se spor začel znova od diagrama.