VGW või TGW? Kus lõpeb AWS Site-to-Site'i IPsec-tunnel

Inimesed küsivad, kus AWS Site-to-Site VPN lakkab paketti kaitsmast, ja ootavad ühte vastust: lüüsi juures. Selle vastuse kasulik versioon nimetab, millise lüüsi juures, sest virtuaalne privaatne lüüs ja transiitlüüs on erinevad lahendused erinevate kinnitusobjektidega ning arvustaja, kes eeldab vale, ehitab ülejäänud hinnangu diagrammile, mida ei ole olemas. Tee kolm allolevat kontrolli järjekorras. Igaüks neist kas kinnitab piiri või ütleb, et eelmine vastus käis teise ressursi kohta.

Nimeta kolm lõpp-punkti enne, kui midagi hindad

Selle tee krüpteerimise ülevaatus vajab kolme nimetatud asja: kliendi lüüs, AWS VPN-i sihtmärk, mis lõpetab IPsec-i, ja rakenduse lõpp-punkt, mis võtab vastu sisemise paketi. Kirjuta need koos ressursside identifikaatoritega üles enne, kui avad ükskõik millise konsooli lehe, sest kõik pärast seda punkti on väide ühe kohta neist kolmest.

Kliendi lüüs on sinu oma ja selle konfiguratsioon on sulle nähtav. AWS-i sihtmärk on hallatav ressurss ja viga on selle eeldamine: VPN-ühendus saab kinnituda virtuaalse privaatse lüüsi või otse transiitlüüsi külge ning kumbki ei tähenda teist. Kolmas lõpp-punkt on see, mille inimesed vahele jätavad, ja see on ainus, mis vastab tegelikule küsimusele rakenduse andmete kohta.

Kontroll 1: milline lüüs tunnelit tegelikult lõpetab

Mõlemad lahendused on toetatud ja Site-to-Site VPN-i arhitektuurijuhend kirjeldab neid kõrvuti, seega küsi API-lt, mitte diagrammilt, mis on sageli aasta vana. Ühe ühenduse kohta tehtud ainult lugemise päring tagastab VPN-i sihtmärgi väljad:

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

Eristaja on TransitGatewayId, mitte VpnGatewayId. Ühendus, mille TransitGatewayId on tühi, lõpeb eraldiseisva virtuaalse privaatse lüüsi juures, samas kui ühendus, mille see väli on seatud, lõpeb transiitlüüsi VPN-kinnitusega, ja VpnGatewayId võib sel juhul siiski täidetud olla, sest see võib nimetada kinnituse kandvat lüüsi. Loe esmalt TGW väli ja kinnita seejärel kinnituse tüüp kinnituste loendist, mitte välja nimest, sest VPC-kinnitus sellel transiitlüüsil ei ole VPN-kinnitus. Sihteksemplari leidmine ühendatud VPC-st ei ütle sulle midagi selle kohta, milline VPN-kinnitus paketti kandis.

Kui sa juba seal oled, kontrolli tunneleid. Ühendus kannab liiasuse huvides kahte IPsec-tunnelit ja ühendus, mille teine tunnel ei ole kunagi üles tulnud, on kättesaadavuse seisukohast tõeline leid, kuigi see ei muuda krüpteerimispiiril midagi:

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

Kontroll 2: mida sisemine pakett veel kannab

Kui IPsec lõpeb, edastab AWS lahtipakitud paketi marsruudil, mis sellega sobis. Sellest punktist on liiklus tavaline VPC-liiklus ja VPN-i kaitse on lõppenud. See ei ole teenuse tühik; see on piiri tähendus ja kontroll-loendi punkt on öelda seda selgelt, selle asemel et lasta "VPN on krüpteeritud" seista "andmed on otsast otsani krüpteeritud" eest.

Nüüd uuri, mis sees oli. Kui sisemine pakett on rakenduse protokoll puhtal kujul, ei lisa midagi allavoolu konfidentsiaalsust enne, kui miski muu selle krüpteerib. Kui sisemine pakett kannab juba TLS-sessiooni, ei muuda välimise IPsec-i eemaldamine selle sessiooni jaoks midagi: see jääb kaitstuks kuni oma lõpp-punktini, kus iganes see lõpp-punkt asub.

Tavaline ülekorrigeerimine on järeldada, et kõik lüüsi taga on paljastatud. Ei ole. Teenuse transport, salvestuse krüpteerimine ja rakenduse TLS on eraldi mehhanismid eraldi tingimustega ning igaüht tuleb hinnata selle enda tingimustel, mitte tuletada VPN-i kujust. Vooglogi kirje, mis näitab ACCEPT-i, tõestab, et marsruutimine töötas, ja ei ütle konfidentsiaalsuse kohta midagi, mis on täpselt see viga, mille vältimiseks see kontroll-loend olemas on.

Kontroll 3: mis lõpetab TLS-i lüüsi taga

Järgi kuulajat, mitte aadressi. Kui koormusjaotur või puhverserver lõpetab TLS-i, lõpeb sinu kliendi hoitav ühendus seal ja puhverserver avab teise ühenduse taustarakendusega, mis võib olla puhas tekst või TLS teise usaldusahelaga. Privaatne IP-aadress ja sobiv marsruut ei ole tõend selle teise ühenduse kohta.

Testi lõpp-punkti, millest sa tõesti hoolid, VPC seest, nimega, mida rakendus kasutab, mitte IP-ga, mille sa üks kord lahendasid:

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

Korda seda iga hüppe puhul, millest päring läbi läheb. Kui vastus erineb kliendi poole suunatud nime ja taustarakenduse nime vahel, oled leidnud täpselt selle segmendi, mida VPN kunagi ei katnud, ja see on leid, mis tuleb kirja panna.

Kirjenda tulemus segmentidena, mitte otsusena

Selle kontroll-loendi väljund on väike tabel ühe reaga iga segmendi kohta: kliendi lüüs AWS VPN-i sihtmärgini, lüüs töökoormuseni, töökoormus andmehoidlani ja mis tahes puhverserveri hüpe nende vahel. Iga rida ütleb, mis seda kaitseb ja millest see kaitse sõltub. "Krüpteeritud" ilma mehhanismi ja lõpp-punktita ei ole rida.

Seejärel vasta algsele nõudele samades terminites, milles see esitati. Kui nõue on, et andmed jäävad konfidentsiaalseks, kuni töökoormus need kätte saab, rahuldab VPN ainult esimest segmenti ja ülejäänud read vajavad rakenduse transporti, teenuse TLS-i või salvestuse krüpteerimist, mis on eraldi seadistatud ja kontrollitud.

Hoia ühenduse identifikaatorid, tunnelite olekud ja sertifikaatide subjektid kirjas. Kui keegi kuue kuu pärast disaini juurde naaseb, vastavad need kolm artefakti piiriküsimusele minutitega, selle asemel et vaidlust diagrammilt uuesti alustada.