VGW vai TGW? Kur beidzas AWS Site-to-Site IPsec tunelis

Cilvēki jautā, kur AWS Site-to-Site VPN pārstāj aizsargāt pakešu un gaida vienu atbildi: pie vārtejas. Noderīgā atbildes versija nosauc, kura vārteja, jo virtuālā privātā vārteja un tranzīta vārteja ir dažādi izkārtojumi ar dažādiem piesaistes objektiem, un recenzents, kurš pieņem nepareizo, pārējo vērtējumu būvē uz diagrammas, kuras nav. Veic trīs pārbaudes zemāk pēc kārtas. Katra vai nu apstiprina robežu, vai pasaka, ka iepriekšējā atbilde bija par citu resursu.

Nosauc trīs galapunktus pirms kaut ko vērtē

Šī ceļa šifrēšanas pārskatam vajag trīs nosauktas lietas: klienta vārteju, AWS VPN mērķi, kas pabeidz IPsec, un lietotnes galapunktu, kas saņem iekšējo pakešu. Pieraksti tos ar resursu identifikatoriem pirms atveri kaut vienu konsoles lapu, jo viss pēc šī punkta ir apgalvojums par vienu no tiem trim.

Klienta vārteja ir tava, un tās konfigurācija tev ir redzama. AWS mērķis ir pārvaldīts resurss, un kļūda ir to pieņemt: VPN savienojums var piesaistīties virtuālai privātai vārtejai vai tieši tranzīta vārtejai, un neviens neizriet no otra. Trešais galapunkts ir tas, ko cilvēki izlaiž, un tas ir vienīgais, kas atbild uz īsto jautājumu par lietotnes datiem.

Pārbaude 1: kura vārteja patiešām pabeidz tuneli

Abi izkārtojumi tiek atbalstīti, un Site-to-Site VPN arhitektūras rokasgrāmata tos apraksta līdzās, tāpēc jautā API, nevis diagrammai, kas bieži ir gadu veca. Tikai lasīšanas vaicājums par vienu savienojumu atgriež VPN mērķa laukus:

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

Atšķirējs ir TransitGatewayId, nevis VpnGatewayId. Savienojums ar tukšu TransitGatewayId beidzas pie atsevišķas virtuālas privātas vārtejas, bet savienojums ar iestatītu šo lauku beidzas pie tranzīta vārtejas VPN piesaistes, un VpnGatewayId šajā gadījumā var joprojām būt aizpildīts, jo tas var nosaukt piesaistes balstošo vārteju. Vispirms izlasi TGW lauku, pēc tam apstiprini piesaistes tipu piesaistu sarakstā, nevis lauka nosaukumā, jo VPC piesaiste šai tranzīta vārtejai nav VPN piesaiste. Mērķa instances atrašana piesaistītā VPC neko nepasaka par to, kura VPN piesaiste nesa pakešu.

Kamēr esi tur, pārbaudi tuneļus. Savienojums nes divus IPsec tuneļus dublēšanai, un savienojums, kura otrais tunelis nekad nav pacēlies, ir īsts atradums pieejamībai, lai gan šifrēšanas robežu tas nemaina:

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

Pārbaude 2: ko iekšējā pakešu vēl nes

Kad IPsec beidzas, AWS pārsūta atkapsulēto pakešu pa maršrutu, kas tam atbilda. No šī punkta satiksme ir parasta VPC satiksme, un VPN aizsardzība ir beigusies. Tā nav plaisa pakalpojumā; tā ir robežas nozīme, un kontrolsaraksta punkts ir to skaidri pateikt, nevis ļaut "VPN ir šifrēts" stāvēt "dati ir šifrēti no gala līdz galam" vietā.

Tagad izpēti, kas bija iekšā. Ja iekšējā pakešu ir atklāta teksta lietotnes protokols, nekas lejup pa straumi nepievieno konfidencialitāti, kamēr kaut kas cits to nešifrē. Ja iekšējā pakešu jau nes TLS sesiju, ārējā IPsec noņemšana tai sesijai neko nemaina: tā paliek aizsargāta līdz savam galapunktam, lai kur tas galapunkts būtu.

Biežākā pārmērīgā korekcija ir secināt, ka viss aiz vārtejas ir atklāts. Tas tā nav. Pakalpojuma transports, krātuves šifrēšana un lietotnes TLS ir atsevišķi mehānismi ar atsevišķiem nosacījumiem, un katrs ir jāvērtē pēc saviem nosacījumiem, nevis jāsecina no VPN formas. Plūsmas žurnāla ieraksts ar ACCEPT pierāda, ka maršrutēšana darbojās, un neko nepasaka par konfidencialitāti, un tā ir tieši tā kļūda, ko šis kontrolsaraksts paredzēts novērst.

Pārbaude 3: kas pabeidz TLS aiz vārtejas

Seko klausītājam, nevis adresei. Ja slodzes balansētājs vai starpniekserveris pabeidz TLS, savienojums, ko tur tavs klients, beidzas tur, un starpniekserveris atver otru savienojumu ar aizmuguri, kas var būt atklāts teksts vai TLS ar citu uzticības ķēdi. Privāta IP adrese un atbilstošs maršruts nav pierādījums par to otru savienojumu.

Pārbaudi galapunktu, kas tev patiešām svarīgs, no VPC iekšpuses, ar nosaukumu, ko lieto lietotne, nevis ar IP, ko reiz atrisināji:

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

Atkārto to katram lēcienam, caur kuru iet pieprasījums. Ja atbilde atšķiras starp klientam vērsto nosaukumu un aizmugures nosaukumu, tu esi atradis tieši to segmentu, ko VPN nekad neaptvēra, un tas ir atradums, kas jāpieraksta.

Rezultātu pieraksti kā segmentus, nevis kā spriedumu

Šī kontrolsaraksta izvade ir maza tabula ar vienu rindu uz segmentu: klienta vārteja līdz AWS VPN mērķim, vārteja līdz darba slodzei, darba slodze līdz datu krātuvei, un jebkurš starpniekservera lēciens starp tiem. Katra rinda pasaka, kas to aizsargā un no kā šī aizsardzība ir atkarīga. "Šifrēts" bez mehānisma un bez galapunkta nav rinda.

Pēc tam atbildi uz sākotnējo prasību ar tiem pašiem terminiem, ar kādiem tā tika izteikta. Ja prasība ir, ka dati paliek konfidenciāli, līdz darba slodze tos saņem, VPN apmierina tikai pirmo segmentu, un atlikušajām rindām vajag lietotnes transportu, pakalpojuma TLS vai krātuves šifrēšanu, kas konfigurēta un pārbaudīta atsevišķi.

Glabā savienojumu identifikatorus, tuneļu stāvokļus un sertifikātu subjektus ierakstā. Kad kāds pēc pusgada atgriežas pie dizaina, šie trīs artefakti minūšu laikā atbild uz robežas jautājumu, nevis sāk strīdu no jauna no diagrammas.