VGW ili TGW? Gdje završava AWS Site-to-Site IPsec tunel

Ljudi pitaju gdje AWS Site-to-Site VPN prestaje štititi paket i očekuju jedan odgovor: na gatewayu. Korisna verzija tog odgovora imenuje koji gateway, jer su virtualni privatni gateway i tranzitni gateway različita rješenja s različitim objektima privitka, a recenzent koji pretpostavi pogrešan gradi ostatak procjene na dijagramu koji ne postoji. Provedite tri provjere ispod redom. Svaka ili potvrđuje granicu ili vam kaže da se prethodni odgovor odnosio na drugi resurs.

Imenujte tri krajnje točke prije nego što bilo što procijenite

Revizija enkripcije ovog puta treba tri imenovane stvari: korisnički gateway, AWS VPN cilj koji završava IPsec i aplikacijsku krajnju točku koja prima unutrašnji paket. Zapišite ih s njihovim identifikatorima resursa prije nego što otvorite ijednu stranicu konzole, jer je sve nakon te točke tvrdnja o jednoj od te tri.

Korisnički gateway je vaš i njegova konfiguracija vam je vidljiva. AWS cilj je upravljani resurs, a greška je pretpostaviti ga: VPN veza se može priključiti na virtualni privatni gateway ili izravno na tranzitni gateway i nijedno ne podrazumijeva drugo. Treća krajnja točka je ona koju ljudi preskoče i jedina je koja odgovara na stvarno pitanje o aplikacijskim podacima.

Provjera 1: koji gateway zapravo završava tunel

Oba rješenja su podržana i Vodič kroz arhitekturu Site-to-Site VPN-a ih opisuje jedan uz drugi, pa pitajte API umjesto dijagrama koji je često godinu dana star. Upit samo za čitanje na jednoj vezi vraća polja VPN cilja:

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

Razlikovni element je TransitGatewayId, a ne VpnGatewayId. Veza s praznim TransitGatewayId završava na samostalnom virtualnom privatnom gatewayu, dok veza s postavljenim tim poljem završava na VPN privitku tranzitnog gatewaya, a VpnGatewayId i tada može biti popunjen jer može imenovati nosivi gateway privitka. Najprije pročitajte polje TGW, zatim potvrdite vrstu privitka iz popisa privitaka, a ne iz naziva polja, jer VPC privitak na tom tranzitnom gatewayu nije VPN privitak. Pronalaženje odredišne instance u priključenom VPC-u ne govori ništa o tome koji je VPN privitak prenio paket.

Dok ste tamo, provjerite tunele. Veza nosi dva IPsec tunela radi redundancije, a veza čiji se drugi tunel nikad nije podigao pravi je nalaz za dostupnost, iako ne mijenja ništa u granici enkripcije:

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

Provjera 2: što unutrašnji paket još nosi

Nakon što IPsec završi, AWS prosljeđuje dekapsulirani paket rutom koja mu je odgovarala. Od te točke promet je običan VPC promet i zaštita VPN-a je završila. To nije praznina u usluzi; to je značenje granice, a stavka na kontrolnom popisu je to reći jednostavno umjesto dopustiti da "VPN je enkriptiran" zamijeni "podaci su enkriptirani od kraja do kraja".

Sada pregledajte što je bilo unutra. Ako je unutrašnji paket aplikacijski protokol s čistim tekstom, ništa nizvodno ne dodaje povjerljivost dok to nešto drugo ne enkriptira. Ako unutrašnji paket već nosi TLS sesiju, uklanjanje vanjskog IPsec-a ne mijenja ništa za tu sesiju: ona ostaje zaštićena do svoje vlastite krajnje točke, gdje god se ona nalazila.

Uobičajena pretjerana korekcija je zaključiti da je sve iza gatewaya izloženo. Nije. Prijenos usluge, enkripcija pohrane i aplikacijski TLS odvojeni su mehanizmi s odvojenim uvjetima i svaki se mora procijeniti po vlastitim uvjetima, a ne izvesti iz oblika VPN-a. Zapis u dnevniku tokova koji pokazuje ACCEPT dokazuje da je usmjeravanje radilo i ne govori ništa o povjerljivosti, što je upravo greška koju ovaj kontrolni popis postoji da spriječi.

Provjera 3: što završava TLS iza gatewaya

Slijedite slušatelja, a ne adresu. Ako balansir opterećenja ili proxy završava TLS, veza koju vaš klijent drži završava ondje, a proxy otvara drugu vezu prema pozadini koja može biti čisti tekst ili TLS s drugim lancem povjerenja. Privatna IP adresa i odgovarajuća ruta nisu dokaz o toj drugoj vezi.

Testirajte krajnju točku do koje vam je stvarno stalo iz unutrašnjosti VPC-a, s imenom koje aplikacija koristi, a ne s IP-om koji ste jednom razriješili:

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

Ponovite to za svaki skok kroz koji zahtjev prolazi. Ako se odgovor razlikuje između imena okrenutog klijentu i imena pozadine, pronašli ste točno onaj segment koji VPN nikada nije pokrivao i to je nalaz koji treba zapisati.

Zabilježite rezultat kao segmente, a ne kao presudu

Izlaz ovog kontrolnog popisa mala je tablica s jednim retkom po segmentu: korisnički gateway do AWS VPN cilja, gateway do radnog opterećenja, radno opterećenje do spremišta podataka i svaki proxy skok između. Svaki redak kaže što ga štiti i o čemu ta zaštita ovisi. "Enkriptirano" bez mehanizma i bez krajnje točke nije redak.

Zatim odgovorite na izvorni zahtjev istim izrazima kojima je postavljen. Ako je zahtjev da podaci ostanu povjerljivi dok ih radno opterećenje ne primi, VPN zadovoljava samo prvi segment, a preostali retci trebaju aplikacijski prijenos, TLS usluge ili enkripciju pohrane konfigurirane i provjerene odvojeno.

Zadržite identifikatore veza, stanja tunela i subjekte certifikata u zapisu. Kad se netko vrati dizajnu za šest mjeseci, ta tri artefakta odgovaraju na pitanje granice u minutama umjesto da ponovno započnu raspravu s dijagrama.