VGW aŭ TGW? Kie finiĝas la IPsec-tunelo de AWS Site-to-Site

Homoj demandas, kie AWS Site-to-Site VPN ĉesas protekti la paketon, kaj atendas unu respondon: ĉe la enirejo. La utila versio de tiu respondo nomas, kiu enirejo, ĉar virtuala privata enirejo kaj traireja enirejo estas malsamaj aranĝoj kun malsamaj aldonaĵobjektoj, kaj la revizianto, kiu supozas la malĝustan, konstruas la reston de la takso sur diagramo, kiu ne ekzistas. Trairu la tri kontrolojn sube laŭorde. Ĉiu aŭ konfirmas la limon aŭ diras al vi, ke la antaŭa respondo temis pri alia rimedo.

Nomu la tri finpunktojn antaŭ ol taksi ion ajn

Kriptada revizio de ĉi tiu vojo bezonas tri nomitajn aferojn: la klientan enirejon, la AWS VPN-celon, kiu finas IPsec, kaj la aplikaĵan finpunkton, kiu ricevas la internan paketon. Skribu ilin kun iliaj rimedaj identigiloj antaŭ ol malfermi eĉ unu konsolan paĝon, ĉar ĉio post ĉi tiu punkto estas aserto pri unu el tiuj tri.

La klienta enirejo estas via kaj ĝia agordo estas videbla al vi. La AWS-celo estas administrata rimedo, kaj la eraro estas supozi ĝin: VPN-konekto povas aldoniĝi al virtuala privata enirejo aŭ rekte al traireja enirejo, kaj neniu implicas la alian. La tria finpunkto estas tiu, kiun homoj preterlasas, kaj ĝi estas la sola, kiu respondas la veran demandon pri aplikaĵaj datumoj.

Kontrolo 1: kiu enirejo vere finas la tunelon

Ambaŭ aranĝoj estas subtenataj kaj la arkitektura gvidilo de Site-to-Site VPN priskribas ilin flanke al flanke, do demandu la API-on anstataŭ diagramon, kiu ofte estas unu jaron aĝa. Nurlega peto pri unu konekto redonas la celkampojn de 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}'

La distingilo estas TransitGatewayId, ne VpnGatewayId. Konekto kun malplena TransitGatewayId finiĝas ĉe memstara virtuala privata enirejo, dum konekto kun tiu kampo agordita finiĝas ĉe VPN-aldonaĵo de traireja enirejo, kaj VpnGatewayId povas ankoraŭ esti plenigita en tiu kazo, ĉar ĝi povas nomi la subtenan enirejon de la aldonaĵo. Legu unue la kampon TGW, poste konfirmu la aldonan tipon el la aldonaĵa listo anstataŭ el kamponomo, ĉar VPC-aldonaĵo ĉe tiu traireja enirejo ne estas la VPN-aldonaĵo. Trovi la celan instancon en ligita VPC diras al vi nenion pri tio, kiu VPN-aldonaĵo portis la paketon.

Dum vi estas tie, kontrolu la tunelojn. La konekto portas du IPsec-tunelojn por redundo, kaj konekto, kies dua tunelo neniam leviĝis, estas reala trovo por havebleco, eĉ se ĝi ŝanĝas nenion ĉe la kriptada limo:

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

Kontrolo 2: kion la interna paketo ankoraŭ portas

Post kiam IPsec finiĝas, AWS plusendas la malkapsuligitan paketon laŭ la itinero, kiu kongruis. De tiu punkto la trafiko estas ordinara VPC-trafiko, kaj la protekto de la VPN finiĝis. Tio ne estas manko en la servo; tio estas la signifo de la limo, kaj la ero en la kontrolo estas diri ĝin klare anstataŭ lasi "la VPN estas ĉifrita" anstataŭi "la datumoj estas ĉifritaj de fino al fino".

Nun ekzamenu, kio estis interne. Se la interna paketo estas aplikaĵa protokolo en klara teksto, nenio malsupre aldonas konfidencon ĝis io alia ĉifros ĝin. Se la interna paketo jam portas TLS-sesion, la forigo de la ekstera IPsec ŝanĝas nenion por tiu sesio: ĝi restas protektita ĝis sia propra finpunkto, kie ajn tiu finpunkto estas.

La ordinara trokorekto estas konkludi, ke ĉio malantaŭ la enirejo estas elmetita. Ne estas. Serva transporto, konserva ĉifrado kaj aplikaĵa TLS estas apartaj mekanismoj kun apartaj kondiĉoj, kaj ĉiu devas esti taksata laŭ siaj propraj kondiĉoj anstataŭ deduktata el la formo de la VPN. Fluprotokola ero montranta ACCEPT pruvas, ke la enrutigado funkciis, kaj diras nenion pri konfidenco, kio estas ĝuste la eraro, kiun ĉi tiu kontrolo ekzistas por malhelpi.

Kontrolo 3: kio finas TLS malantaŭ la enirejo

Sekvu la aŭskultanton, ne la adreson. Se ŝarĝbalancilo aŭ prokuro finas TLS, la konekto, kiun via kliento tenas, finiĝas tie, kaj la prokuro malfermas duan konekton al la malantaŭo, kiu povas esti klara teksto aŭ TLS kun alia fidoĉeno. Privata IP-adreso kaj kongrua itinero ne estas pruvo pri tiu dua konekto.

Testu la finpunkton, pri kiu vi vere zorgas, de interne de la VPC, kun la nomo, kiun la aplikaĵo uzas, anstataŭ IP, kiun vi solvis unufoje:

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

Ripetu tion por ĉiu salto, kiun la peto trapasas. Se la respondo malsamas inter la klienta nomo kaj la malantaŭa nomo, vi trovis ĝuste la segmenton, kiun la VPN neniam kovris, kaj tio estas la trovo, kiun endas skribi.

Registru la rezulton kiel segmentojn, ne kiel verdikton

La eligo de ĉi tiu kontrolo estas malgranda tabelo kun unu vico por segmento: klienta enirejo al AWS VPN-celo, enirejo al laborŝarĝo, laborŝarĝo al datenejo, kaj ajna prokura salto intere. Ĉiu vico diras, kio protektas ĝin kaj de kio tiu protekto dependas. "Ĉifrita" sen mekanismo kaj sen finpunkto ne estas vico.

Poste respondu la originan postulon per la samaj terminoj, per kiuj ĝi estis demandita. Se la postulo estas, ke datumoj restu konfidencaj ĝis la laborŝarĝo ricevos ilin, la VPN plenumas nur la unuan segmenton, kaj la ceteraj vicoj bezonas aplikaĵan transporton, servan TLS aŭ konservan ĉifradon agorditajn kaj kontrolitajn aparte.

Konservu la konektajn identigilojn, la tunelajn statojn kaj la atestilajn subjektojn en la registro. Kiam iu revenos al la dezajno post ses monatoj, tiuj tri artefaktoj respondos la liman demandon en kelkaj minutoj anstataŭ rekomenci la disputon el diagramo.