VGW alebo TGW? Kde sa končí tunel IPsec v AWS Site-to-Site

Ľudia sa pýtajú, kde AWS Site-to-Site VPN prestáva chrániť paket, a čakajú jednu odpoveď: na bráne. Užitočná verzia tej odpovede pomenúva, ktorá brána, pretože virtuálna privátna brána a tranzitná brána sú rôzne usporiadania s rôznymi objektmi prílohy, a recenzent, ktorý predpokladá to nesprávne, stavia zvyšok hodnotenia na diagrame, ktorý neexistuje. Vykonajte tri kontroly nižšie v poradí. Každá buď potvrdí hranicu, alebo vám povie, že predchádzajúca odpoveď bola o inom zdroji.

Skôr než čokoľvek ohodnotíte, pomenujte tri koncové body

Revízia šifrovania tejto cesty potrebuje tri pomenované veci: zákaznícku bránu, cieľ AWS VPN, ktorý ukončuje IPsec, a koncový bod aplikácie, ktorý prijíma vnútorný paket. Zapíšte ich s ich identifikátormi zdrojov, skôr než otvoríte jedinú stránku konzoly, pretože všetko po tomto bode je tvrdenie o jednom z tých troch.

Zákaznícka brána je vaša a jej konfigurácia je vám viditeľná. Cieľ AWS je spravovaný zdroj a chybou je považovať ho za daný: pripojenie VPN sa môže pripojiť k virtuálnej privátnej bráne alebo priamo k tranzitnej bráne a ani jedno neimplikuje druhé. Tretí koncový bod je ten, ktorý ľudia preskakujú, a je jediný, ktorý odpovedá na skutočnú otázku o údajoch aplikácie.

Kontrola 1: ktorá brána tunel skutočne ukončuje

Obe usporiadania sú podporované a príručka architektúry Site-to-Site VPN ich opisuje vedľa seba, takže sa pýtajte API, nie diagramu, ktorý má často rok. Dotaz iba na čítanie na jednom pripojení vráti polia cieľa 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}'

Rozlišujúcim prvkom je TransitGatewayId, nie VpnGatewayId. Pripojenie s prázdnym TransitGatewayId končí na samostatnej virtuálnej privátnej bráne, zatiaľ čo pripojenie s týmto poľom nastaveným končí na VPN prílohe tranzitnej brány, a VpnGatewayId v takom prípade môže byť stále vyplnené, pretože môže pomenovať nosnú bránu prílohy. Najprv prečítajte pole TGW, potom potvrďte typ prílohy zo zoznamu príloh, nie z názvu poľa, pretože príloha VPC na tej tranzitnej bráne nie je VPN príloha. Nájsť cieľovú inštanciu v pripojenej VPC vám nič nepovie o tom, ktorá VPN príloha paket preniesla.

Kým ste tam, skontrolujte tunely. Pripojenie nesie dva tunely IPsec pre redundanciu a pripojenie, ktorého druhý tunel sa nikdy nevzniesol, je skutočným nálezom pre dostupnosť, aj keď na hranici šifrovania nič nemení:

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: čo vnútorný paket ešte nesie

Keď IPsec skončí, AWS prepošle dekapsulovaný paket po trase, ktorá mu zodpovedala. Od tohto bodu je prevádzka bežnou prevádzkou VPC a ochrana VPN sa skončila. To nie je medzera v službe; to je zmysel hranice a bodom kontrolného zoznamu je povedať to priamo, namiesto toho, aby "VPN je šifrovaná" zastupovalo "údaje sú šifrované od konca do konca".

Teraz preskúmajte, čo bolo vnútri. Ak je vnútorný paket aplikačný protokol v čistom texte, nič nižšie nepridá dôvernosť, kým ho niečo iné nezašifruje. Ak vnútorný paket už nesie reláciu TLS, odstránenie vonkajšieho IPsec pre túto reláciu nič nemení: zostáva chránená až do svojho vlastného koncového bodu, nech je ten koncový bod kdekoľvek.

Bežnou prehnanou korekciou je usúdiť, že všetko za bránou je vystavené. Nie je. Preprava služby, šifrovanie úložiska a aplikačný TLS sú oddelené mechanizmy s oddelenými podmienkami a každý treba hodnotiť podľa jeho vlastných podmienok, nie odvodzovať z tvaru VPN. Záznam v protokole tokov s ACCEPT dokazuje, že smerovanie fungovalo, a o dôvernosti nehovorí nič, čo je presne tá chyba, ktorej má tento kontrolný zoznam zabrániť.

Kontrola 3: čo ukončuje TLS za bránou

Sledujte poslucháča, nie adresu. Ak nástroj na vyvažovanie záťaže alebo proxy ukončuje TLS, pripojenie, ktoré drží váš klient, sa tam končí a proxy otvorí druhé pripojenie k backendu, ktoré môže byť v čistom texte alebo TLS s iným reťazcom dôvery. Privátna IP adresa a zodpovedajúca trasa nie sú dôkazom o tomto druhom pripojení.

Otestujte koncový bod, na ktorom vám skutočne záleží, zvnútra VPC, s názvom, ktorý aplikácia používa, nie s IP, ktorú ste raz preložili:

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

Zopakujte to pre každý skok, ktorým požiadavka prechádza. Ak sa odpoveď líši medzi názvom obráteným ku klientovi a názvom backendu, našli ste presne ten segment, ktorý VPN nikdy nepokryla, a to je nález, ktorý treba zapísať.

Výsledok zaznamenajte ako segmenty, nie ako verdikt

Výstupom tohto kontrolného zoznamu je malá tabuľka s jedným riadkom na segment: zákaznícka brána k cieľu AWS VPN, brána k pracovnej záťaži, pracovná záťaž k úložisku údajov a akýkoľvek proxy skok medzi tým. Každý riadok hovorí, čo ho chráni a od čoho táto ochrana závisí. "Šifrované" bez mechanizmu a bez koncového bodu nie je riadok.

Potom odpovedzte na pôvodnú požiadavku rovnakými termínmi, v akých bola položená. Ak požiadavka znie, že údaje zostanú dôverné, kým ich pracovná záťaž neprijme, VPN spĺňa len prvý segment a zostávajúce riadky potrebujú prepravu aplikácie, TLS služby alebo šifrovanie úložiska nastavené a overené osobitne.

Uchovajte identifikátory pripojení, stavy tunelov a subjekty certifikátov v zázname. Keď sa niekto po pol roku vráti k návrhu, tieto tri artefakty odpovedia na otázku hranice v priebehu minút, namiesto toho, aby sa spor začínal znova od diagramu.