VGW of TGW? Waar die AWS Site-to-Site-IPsec-tonnel eindig

Mense vra waar 'n AWS Site-to-Site VPN ophou om die pakkie te beskerm en verwag een antwoord: by die poort. Die nuttige weergawe van daardie antwoord noem watter poort, want 'n virtuele privaatpoort en 'n transito-poort is verskillende reëlings met verskillende aanhegselvoorwerpe, en die keurder wat die verkeerde een aanneem, bou die res van die assessering op 'n diagram wat nie bestaan nie. Werk die drie kontroles hieronder in volgorde deur. Elkeen bevestig óf die grens óf sê dat die vorige antwoord oor 'n ander hulpbron gegaan het.

Benoem die drie eindpunte voordat jy enigiets assesseer

’n Enkripsie-oudit van hierdie pad het drie benoemde dinge nodig: die kliëntpoort, die AWS VPN-teiken wat IPsec beëindig, en die toepassingseindpunt wat die binneste pakkie ontvang. Skryf hulle met hul hulpbron-identifiseerders neer voordat jy 'n enkele konsolesy oopmaak, want alles ná hierdie punt is 'n stelling oor een van daardie drie.

Die kliëntpoort is joune en sy konfigurasie is vir jou sigbaar. Die AWS-teiken is 'n bestuurde hulpbron, en die fout is om dit te aanvaar: 'n VPN-verbinding kan aan 'n virtuele privaatpoort of direk aan 'n transito-poort koppel, en nie een impliseer die ander nie. Die derde eindpunt is die een wat mense oorslaan, en dit is die enigste een wat die werklike vraag oor toepassingsdata beantwoord.

Kontrole 1: watter poort beëindig werklik die tonnel

Albei reëlings word ondersteun en die Site-to-Site VPN-argitektuurgids beskryf hulle langs mekaar, so vra die API eerder as 'n diagram wat dikwels 'n jaar oud is. 'n Lees-alleen-navraag op een verbinding gee die VPN-teikenvelde terug:

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

Die onderskeier is TransitGatewayId, nie VpnGatewayId nie. 'n Verbinding met TransitGatewayId leeg eindig op 'n selfstandige virtuele privaatpoort, terwyl 'n verbinding met daardie veld ingestel op 'n transito-poort VPN-aanhegsel, eindig, en VpnGatewayId kan in daardie geval steeds gevul wees omdat dit die aanhegsel se onderliggende poort kan noem. Lees eers die TGW-veld en bevestig dan die aanhegseltipe uit die aanhegsellys eerder as uit 'n veldnaam, want 'n VPC-aanhegsel op daardie transito-poort is nie die VPN-aanhegsel nie. Om die bestemmingsinstansie in 'n gekoppelde VPC te vind, sê niks oor watter VPN-aanhegsel die pakkie gedra het nie.

Kyk terselfdertyd na die tonnels. Die verbinding dra twee IPsec-tonnels vir oorbodigheid, en 'n verbinding waarvan die tweede tonnel nooit opgekom het nie, is 'n werklike bevinding vir beskikbaarheid, al verander dit niks aan die enkripsiegrens nie:

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

Kontrole 2: wat die binneste pakkie nog dra

Sodra IPsec beëindig, stuur AWS die gedekapsuleerde pakkie deur met die roete wat daarby pas. Van daardie punt af is die verkeer gewone VPC-verkeer, en die VPN se beskerming het geëindig. Dit is nie 'n gaping in die diens nie; dit is wat die grens beteken, en die kontrolelystitem is om dit eenvoudig te stel eerder as om "die VPN is geënkripteer" te laat instaan vir "die data is end-tot-end geënkripteer".

Ondersoek nou wat binne was. As die binneste pakkie 'n gewone teks-toepassingsprotokol is, voeg niks stroomaf vertroulikheid by totdat iets anders dit enkripteer nie. As die binneste pakkie reeds 'n TLS-sessie dra, verander die verwydering van die buitenste IPsec niks aan daardie sessie nie: dit bly beskerm tot sy eie eindpunt, waar daardie eindpunt ook al is.

Die algemene oorkorreksie is om af te lei dat alles agter die poort blootgestel is. Dit is nie so nie. Diensvervoer, stoorenkripsie en toepassing-TLS is aparte meganismes met aparte voorwaardes, en elkeen moet op sy eie terme beoordeel word eerder as om uit die VPN se vorm afgelei te word. 'n Vloeilog-inskrywing wat ACCEPT wys, bewys dat die roetering gewerk het en sê niks oor vertroulikheid nie, wat presies die fout is wat hierdie kontrolelys wil voorkom.

Kontrole 3: wat TLS agter die poort beëindig

Volg die luisteraar, nie die adres nie. As 'n lasbalanseerder of instaanbediener TLS beëindig, eindig die verbinding wat jou kliënt hou daar, en die instaanbediener open 'n tweede verbinding na die agterkant wat gewone teks of TLS met 'n ander vertrouensketting kan wees. 'n Privaat IP-adres en 'n bypassende roete is nie bewyse oor daardie tweede verbinding nie.

Toets die eindpunt waaraan jy werklik aandag gee van binne die VPC, met die naam wat die toepassing gebruik eerder as 'n IP wat jy een keer opgelos het:

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

Herhaal dit vir elke sprong waardeur die versoek gaan. As die antwoord verskil tussen die kliëntgerigte naam en die agterkantnaam, het jy presies die segment gevind wat die VPN nooit gedek het nie, en dit is die bevinding om neer te skryf.

Rekord die resultaat as segmente, nie as 'n uitspraak nie

Die uitset van hierdie kontrolelys is 'n klein tabel met een ry per segment: kliëntpoort tot AWS VPN-teiken, poort tot werklading, werklading tot datastoor, en enige instaanbediener-sprong tussenin. Elke ry sê wat dit beskerm en waarvan daardie beskerming afhang. "Geënkripteer" sonder meganisme en sonder eindpunt is nie 'n ry nie.

Beantwoord dan die oorspronklike vereiste in dieselfde terme waarin dit gevra is. As die vereiste is dat data vertroulik bly totdat die werklading dit ontvang, bevredig die VPN net die eerste segment, en die oorblywende rye benodig toepassingsvervoer, diens-TLS of stoorenkripsie wat apart opgestel en geverifieer moet word.

Hou die verbindings-identifiseerders, die tonneltoestande en die sertifikaat-subjekte in die rekord. Wanneer iemand die ontwerp oor ses maande weer besoek, beantwoord daardie drie artefakte die grensvraag binne minute eerder as om die argument van voor af uit 'n diagram te begin.