VGW, nebo TGW? Kde končí tunel IPsec u AWS Site-to-Site

Lidé se ptají, kde AWS Site-to-Site VPN přestává chránit paket, a čekají jednu odpověď: na bráně. Užitečná verze této odpovědi pojmenuje, která brána to je, protože virtuální privátní brána a tranzitní brána jsou různá uspořádání s různými objekty přílohy a recenzent, který předpokládá to nesprávné, staví zbytek posouzení na diagramu, který neexistuje. Proveďte tři níže uvedené kontroly v pořadí. Každá buď potvrdí hranici, nebo vám řekne, že předchozí odpověď byla o jiném prostředku.

Než cokoli posoudíte, pojmenujte tři koncové body

Revize šifrování této cesty potřebuje tři pojmenované věci: zákaznickou bránu, cíl AWS VPN, který ukončuje IPsec, a koncový bod aplikace, který přijímá vnitřní paket. Zapište je s jejich identifikátory prostředků, než otevřete jedinou stránku konzole, protože vše po tomto bodě je tvrzení o jednom z těch tří.

Zákaznická brána je vaše a její konfigurace je vám viditelná. Cíl AWS je spravovaný prostředek a chybou je považovat ho za daný: připojení VPN se může připojit k virtuální privátní bráně nebo přímo k tranzitní bráně a ani jedno neimplikuje druhé. Třetí koncový bod je ten, který lidé přeskakují, a je jediný, který odpovídá na skutečnou otázku o datech aplikace.

Kontrola 1: která brána tunel skutečně ukončuje

Obě uspořádání jsou podporována a průvodce architekturou Site-to-Site VPN je popisuje vedle sebe, takže se ptejte API, ne diagramu, kterému je často rok. Dotaz pouze pro čtení na jednom připojení vrátí pole cíle 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ícím prvkem je TransitGatewayId, nikoli VpnGatewayId. Připojení s prázdným TransitGatewayId končí na samostatné virtuální privátní bráně, zatímco připojení s tímto polem nastaveným končí na VPN příloze tranzitní brány, a VpnGatewayId v takovém případě může být stále vyplněno, protože může pojmenovat nosnou bránu přílohy. Nejprve přečtěte pole TGW, potom potvrďte typ přílohy ze seznamu příloh, ne z názvu pole, protože příloha VPC na této tranzitní bráně není VPN přílohou. Nalezení cílové instance v připojené VPC vám nic neříká o tom, která VPN příloha paket přenesla.

Když už tam jste, zkontrolujte tunely. Připojení nese dva tunely IPsec pro redundanci a připojení, jehož druhý tunel se nikdy nezvedl, je skutečným nálezem pro dostupnost, i když na hranici šifrování nic nemění:

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: co vnitřní paket ještě nese

Jakmile IPsec skončí, AWS přepošle dekapsulovaný paket po trase, která mu odpovídala. Od tohoto bodu je provoz běžný provoz VPC a ochrana VPN skončila. To není mezera ve službě; to je smysl hranice a položkou kontrolního seznamu je říci to přímo, místo aby "VPN je šifrovaná" zastupovalo "data jsou šifrována od konce ke konci".

Nyní prohlédněte, co bylo uvnitř. Pokud je vnitřní paket aplikační protokol v čistém textu, nic níže už nepřidá důvěrnost, dokud ho něco jiného nezašifruje. Pokud vnitřní paket už nese relaci TLS, odebrání vnějšího IPsec pro tuto relaci nic nemění: zůstává chráněna až ke svému vlastnímu koncovému bodu, ať je kdekoli.

Běžnou přehnanou korekcí je usoudit, že vše za bránou je vystaveno. Není. Přeprava služby, šifrování úložiště a aplikační TLS jsou oddělené mechanismy s oddělenými podmínkami a každý se musí posoudit podle vlastních podmínek, ne odvodit z tvaru VPN. Záznam v protokolu toků s ACCEPT dokazuje, že směrování fungovalo, a o důvěrnosti neříká nic, což je přesně ta chyba, které má tento kontrolní seznam zabránit.

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

Sledujte naslouchající prvek, ne adresu. Pokud nástroj pro vyrovnávání zátěže nebo proxy ukončuje TLS, připojení, které drží váš klient, končí tam a proxy otevře druhé připojení k backendu, které může být v čistém textu nebo TLS s jiným řetězcem důvěry. Privátní IP adresa a odpovídající trasa nejsou důkazem o tomto druhém připojení.

Otestujte koncový bod, na kterém vám skutečně záleží, zevnitř VPC, s názvem, který aplikace používá, ne s IP, kterou jste jednou přeložili:

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

Opakujte to pro každý skok, kterým požadavek prochází. Pokud se odpověď liší mezi názvem obráceným ke klientovi a názvem backendu, našli jste přesně ten segment, který VPN nikdy nepokryla, a to je nález, který je třeba zapsat.

Výsledek zaznamenejte jako segmenty, ne jako verdikt

Výstupem tohoto kontrolního seznamu je malá tabulka s jedním řádkem na segment: zákaznická brána k cíli AWS VPN, brána k pracovní zátěži, pracovní zátěž k úložišti dat a jakýkoli proxy skok mezi tím. Každý řádek říká, co ho chrání a na čem tato ochrana závisí. "Šifrováno" bez mechanismu a bez koncového bodu není řádek.

Potom odpovězte na původní požadavek stejnými termíny, v jakých byl položen. Pokud požadavek zní, že data zůstanou důvěrná, dokud je pracovní zátěž nepřijme, VPN splňuje jen první segment a zbývající řádky potřebují přepravu aplikace, TLS služby nebo šifrování úložiště nastavené a ověřené zvlášť.

Uchovejte identifikátory připojení, stavy tunelů a subjekty certifikátů v záznamu. Když se někdo za šest měsíců vrátí k návrhu, tyto tři artefakty odpoví na otázku hranice během minut, místo aby se spor začínal znovu od diagramu.