VGW sau TGW? Unde se termină tunelul IPsec AWS Site-to-Site
Tunelul IPsec se termină la VGW sau la atașamentul VPN al TGW, nu la instanța ta. Numește cele trei puncte terminale și verifică apoi ce protejează fiecare salt rămas.
Oamenii întreabă unde o VPN Site-to-Site de la AWS nu mai protejează pachetul și așteaptă un singur răspuns: la gateway. Versiunea utilă a acelui răspuns numește care gateway, pentru că un gateway privat virtual și un gateway de tranzit sunt aranjamente diferite cu obiecte de atașare diferite, iar recenzentul care presupune varianta greșită construiește restul evaluării pe o diagramă care nu există. Parcurge cele trei verificări de mai jos în ordine. Fiecare fie confirmă limita, fie îți spune că răspunsul anterior privea altă resursă.
Numește cele trei puncte terminale înainte de a evalua ceva
O revizuire a criptării acestei căi are nevoie de trei lucruri numite: gateway-ul clientului, ținta VPN din AWS care termină IPsec și punctul terminal al aplicației care primește pachetul interior. Notează-le cu identificatorii de resursă înainte de a deschide o singură pagină de consolă, pentru că tot ce urmează este o afirmație despre unul dintre cele trei.
Gateway-ul clientului este al tău, iar configurația lui îți este vizibilă. Ținta din AWS este o resursă administrată, iar greșeala este să o presupui: o conexiune VPN se poate atașa la un gateway privat virtual sau direct la un gateway de tranzit, și niciuna nu o implică pe cealaltă. Al treilea punct terminal este cel pe care oamenii îl sar, și este singurul care răspunde la întrebarea reală despre datele aplicației.
Verificarea 1: care gateway termină de fapt tunelul
Ambele aranjamente sunt acceptate și ghidul de arhitectură Site-to-Site VPN le descrie alături, așa că întreabă API-ul în locul unei diagrame care are adesea un an. O interogare doar-citire pe o conexiune returnează câmpurile țintei 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}'
Distinctivul este TransitGatewayId, nu VpnGatewayId. O conexiune cu TransitGatewayId gol se termină la un gateway privat virtual de sine stătător, în timp ce o conexiune cu acel câmp setat se termină la un atașament VPN al gateway-ului de tranzit, iar VpnGatewayId poate rămâne completat în acel caz pentru că poate numi gateway-ul suport al atașamentului. Citește mai întâi câmpul TGW, apoi confirmă tipul atașamentului din lista de atașamente, nu din numele unui câmp, pentru că un atașament VPC pe acel gateway de tranzit nu este atașamentul VPN. Găsirea instanței destinație într-o VPC conectată nu îți spune nimic despre care atașament VPN a transportat pachetul.
Cât timp ești acolo, verifică tunelurile. Conexiunea poartă două tuneluri IPsec pentru redundanță, iar o conexiune al cărei al doilea tunel nu a urcat niciodată este o constatare reală pentru disponibilitate, chiar dacă nu schimbă nimic la limita criptării:
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}'
Verificarea 2: ce mai poartă pachetul interior
Odată ce IPsec se termină, AWS transmite pachetul decapsulat pe ruta care i se potrivea. Din acel punct traficul este trafic VPC obișnuit, iar protecția VPN s-a încheiat. Nu este o lipsă a serviciului; este sensul limitei, iar punctul de pe listă este să spui asta clar în loc să lași "VPN-ul este criptat" să stea în locul lui "datele sunt criptate cap la cap".
Acum examinează ce era înăuntru. Dacă pachetul interior este un protocol de aplicație în text simplu, nimic în aval nu adaugă confidențialitate până când altceva nu îl criptează. Dacă pachetul interior poartă deja o sesiune TLS, eliminarea IPsec-ului exterior nu schimbă nimic pentru acea sesiune: rămâne protejată până la propriul punct terminal, oriunde ar fi acel punct terminal.
Corecția excesivă obișnuită este să concluzionezi că tot ce este în spatele gateway-ului este expus. Nu este. Transportul serviciului, criptarea stocării și TLS-ul aplicației sunt mecanisme separate cu condiții separate, iar fiecare trebuie evaluat pe condițiile lui, nu dedus din forma VPN-ului. O intrare în jurnalul de flux care arată ACCEPT dovedește că rutarea a funcționat și nu spune nimic despre confidențialitate, ceea ce este exact greșeala pe care această listă există ca să o prevină.
Verificarea 3: ce termină TLS în spatele gateway-ului
Urmează ascultătorul, nu adresa. Dacă un balansator de sarcină sau un proxy termină TLS, conexiunea pe care o ține clientul tău se termină acolo, iar proxy-ul deschide o a doua conexiune către backend care poate fi text simplu sau TLS cu alt lanț de încredere. O adresă IP privată și o rută potrivită nu sunt dovadă despre acea a doua conexiune.
Testează punctul terminal care îți pasă cu adevărat din interiorul VPC-ului, cu numele pe care îl folosește aplicația, nu cu un IP pe care l-ai rezolvat o dată:
openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error
Repetă asta pentru fiecare salt prin care trece cererea. Dacă răspunsul diferă între numele orientat spre client și numele backend-ului, ai găsit exact segmentul pe care VPN-ul nu l-a acoperit niciodată, și aceea este constatarea de scris.
Înregistrează rezultatul ca segmente, nu ca verdict
Rezultatul acestei liste este un tabel mic cu un rând pe segment: gateway-ul clientului către ținta VPN din AWS, gateway-ul către sarcina de lucru, sarcina de lucru către depozitul de date și orice salt de proxy între ele. Fiecare rând spune ce îl protejează și de ce depinde acea protecție. "Criptat" fără mecanism și fără punct terminal nu este un rând.
Apoi răspunde cerinței originale în aceiași termeni în care a fost formulată. Dacă cerința este ca datele să rămână confidențiale până când sarcina de lucru le primește, VPN-ul satisface doar primul segment, iar rândurile rămase au nevoie de transportul aplicației, TLS de serviciu sau criptarea stocării configurate și verificate separat.
Păstrează identificatorii conexiunilor, stările tunelurilor și subiecții certificatelor în registru. Când cineva revine la design peste șase luni, acele trei artefacte răspund la întrebarea despre limită în câteva minute în loc să reia disputa de la o diagramă.