VGW o TGW? Dove finisce il tunnel IPsec di AWS Site-to-Site
Il tunnel IPsec termina al VGW o all'allegato VPN del TGW, non alla tua istanza. Nomina i tre estremi, poi verifica cosa protegge ogni salto rimanente.
Le persone chiedono dove una VPN Site-to-Site di AWS smette di proteggere il pacchetto e si aspettano una risposta sola: al gateway. La versione utile di quella risposta dice quale gateway, perché un gateway privato virtuale e un gateway di transito sono disposizioni diverse con oggetti di allegato diversi, e il revisore che presuppone quella sbagliata costruisce il resto della valutazione su un diagramma che non esiste. Esegui i tre controlli qui sotto in ordine. Ognuno o conferma il confine o ti dice che la risposta precedente riguardava un'altra risorsa.
Nomina i tre estremi prima di valutare qualsiasi cosa
Una revisione della cifratura di questo percorso richiede tre cose nominate: il gateway del cliente, la destinazione VPN di AWS che termina IPsec e l'estremo applicativo che riceve il pacchetto interno. Annotali con i loro identificatori di risorsa prima di aprire una sola pagina della console, perché tutto ciò che segue è un'affermazione su uno di quei tre.
Il gateway del cliente è tuo e la sua configurazione è visibile a te. La destinazione AWS è una risorsa gestita, e l'errore è darla per scontata: una connessione VPN può collegarsi a un gateway privato virtuale o direttamente a un gateway di transito, e nessuna delle due implica l'altra. Il terzo estremo è quello che le persone saltano, ed è l'unico che risponde alla domanda reale sui dati dell'applicazione.
Controllo 1: quale gateway termina davvero il tunnel
Entrambe le disposizioni sono supportate e la guida all'architettura di Site-to-Site VPN le descrive affiancate, quindi interroga l'API invece di un diagramma che spesso ha un anno. Una query di sola lettura su una connessione restituisce i campi di destinazione 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}'
Il discriminante è TransitGatewayId, non VpnGatewayId. Una connessione con TransitGatewayId vuoto termina su un gateway privato virtuale autonomo, mentre una connessione con quel campo impostato termina su un allegato VPN del gateway di transito, e VpnGatewayId può essere ancora compilato in quel caso perché può nominare il gateway di supporto dell'allegato. Leggi prima il campo TGW, poi conferma il tipo di allegato dall'elenco degli allegati invece che dal nome di un campo, perché un allegato VPC su quel gateway di transito non è l'allegato VPN. Trovare l'istanza di destinazione in una VPC collegata non ti dice nulla su quale allegato VPN abbia trasportato il pacchetto.
Finché sei lì, controlla i tunnel. La connessione porta due tunnel IPsec per la ridondanza, e una connessione il cui secondo tunnel non è mai salito è un riscontro reale per la disponibilità anche se non cambia nulla al confine della cifratura:
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}'
Controllo 2: cosa porta ancora il pacchetto interno
Una volta che IPsec termina, AWS inoltra il pacchetto decapsulato lungo la rotta che vi corrispondeva. Da quel punto il traffico è traffico VPC ordinario, e la protezione della VPN è finita. Non è una lacuna del servizio; è ciò che significa il confine, e il punto della lista è dirlo chiaramente invece di lasciare che "la VPN è cifrata" sostituisca "i dati sono cifrati da un capo all'altro".
Ora esamina cosa c'era dentro. Se il pacchetto interno è un protocollo applicativo in chiaro, nulla a valle aggiunge riservatezza finché qualcos'altro non lo cifra. Se il pacchetto interno porta già una sessione TLS, la rimozione dell'IPsec esterno non cambia nulla per quella sessione: resta protetta fino al proprio estremo, dovunque quell'estremo sia.
La sovracorrezione comune è concludere che tutto ciò che sta dietro il gateway sia esposto. Non lo è. Il trasporto del servizio, la cifratura dell'archiviazione e il TLS applicativo sono meccanismi separati con condizioni separate, e ciascuno va valutato secondo i propri termini invece di essere dedotto dalla forma della VPN. Una voce del registro di flusso che mostra ACCEPT dimostra che l'instradamento ha funzionato e non dice nulla sulla riservatezza, che è esattamente l'errore che questa lista esiste per prevenire.
Controllo 3: cosa termina TLS dietro il gateway
Segui l'ascoltatore, non l'indirizzo. Se un bilanciatore di carico o un proxy termina TLS, la connessione che il tuo client tiene finisce lì, e il proxy apre una seconda connessione verso il backend che può essere in chiaro o TLS con una catena di fiducia diversa. Un indirizzo IP privato e una rotta corrispondente non sono prova su quella seconda connessione.
Prova l'estremo che ti interessa davvero dall'interno della VPC, con il nome che usa l'applicazione e non con un IP che hai risolto una volta:
openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error
Ripetilo per ogni salto attraversato dalla richiesta. Se la risposta differisce tra il nome rivolto al client e il nome del backend, hai trovato esattamente il segmento che la VPN non ha mai coperto, e questo è il riscontro da annotare.
Registra il risultato come segmenti, non come verdetto
L'output di questa lista è una piccola tabella con una riga per segmento: gateway del cliente verso destinazione VPN di AWS, gateway verso carico di lavoro, carico di lavoro verso archivio dati, e qualsiasi salto proxy nel mezzo. Ogni riga dice cosa la protegge e da cosa dipende quella protezione. "Cifrato" senza meccanismo e senza estremo non è una riga.
Poi rispondi al requisito originale con gli stessi termini con cui è stato posto. Se il requisito è che i dati restino riservati finché il carico di lavoro non li riceve, la VPN soddisfa solo il primo segmento, e le righe restanti richiedono trasporto applicativo, TLS di servizio o cifratura dell'archiviazione configurati e verificati separatamente.
Conserva gli identificatori di connessione, gli stati dei tunnel e i soggetti dei certificati nel registro. Quando qualcuno torna sul progetto tra sei mesi, questi tre artefatti rispondono alla domanda sul confine in pochi minuti invece di riaprire la discussione da un diagramma.