Perché EC2 non riesce a raggiungere il tuo laptop con AWS Client VPN
Client VPN traduce le origini IPv4 del client verso l'interfaccia dell'endpoint. Per questo la risposta funziona e una nuova connessione da EC2 no.
Un laptop connesso tramite AWS Client VPN raggiunge un'applicazione su EC2 senza problemi. Poi provi il contrario, da EC2 all'indirizzo assegnato al client, e la connessione si blocca o viene rifiutata. Quell'asimmetria raramente è una regola di gruppo di sicurezza mancante. Su un endpoint Client VPN associato a subnet VPC, AWS traduce le origini IPv4 del client verso l'interfaccia di rete dell'endpoint, quindi non esiste un indirizzo VPC in ingresso che rappresenti il tuo laptop.
Inizia da ciò che mostra la cattura
Esegui una cattura sull'host EC2 mentre il client si connette e leggi l'indirizzo di origine che l'applicazione vede davvero. Se è l'interfaccia dell'endpoint lato VPC e non un indirizzo dal pool di client, la traduzione è confermata prima di cambiare una singola regola.
Il pool di client è un intervallo di assegnazione, non una subnet con una rotta di ritorno. È su questa distinzione che la maggior parte di queste indagini sbaglia.
La traduzione che spiega l'asimmetria
Tre flussi vengono confusi tra loro, e solo uno di essi è quello che le persone testano.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
La descrizione dei componenti di Client VPN specifica che le origini IPv4 del client vengono tradotte verso l'interfaccia dell'endpoint, il che basta a capire perché la riga centrale non ha nulla con cui corrispondere.
Una nuova connessione richiede una rotta, un passaggio di risoluzione dell'indirizzo e una decisione di autorizzazione. Lo stato di traduzione della sessione di qualcun altro non ne fornisce nessuno dei tre.
Perché una risposta non è una nuova connessione
Una risposta TCP viene confrontata con una voce esistente, ed è per questo che il percorso di ritorno funziona senza alcuna regola in ingresso. Un SYN nuovo dall'host EC2 non ha nessuna voce con cui corrispondere, quindi diventa un normale tentativo in uscita verso una destinazione che la VPC non sa come raggiungere.
Ecco anche perché è fuorviante descriverlo come traffico che va solo in una direzione. Il traffico di ritorno scorre di continuo in queste sessioni. La parte senza percorso è l'avvio.
Che cosa rompe ancora una sessione che dovrebbe funzionare
I gruppi di sicurezza, le ACL di rete e il firewall del laptop stesso contano tutti per le connessioni che dovrebbero riuscire. Un ping fallito dice meno di tutto, perché la politica ICMP è spesso separata dalla politica TCP che ti interessa.
Scrivi quelle regole rispetto all'origine tradotta, non all'indirizzo del client. Le regole legate all'indirizzo che non compare mai sulla rete sono il guasto autoinflitto più comune in questo progetto.
Quando la VPC deve davvero iniziare la conversazione
Se un servizio deve notificare una postazione di lavoro, inverti la direzione e lascia che il client mantenga un canale in uscita persistente a cui il servizio risponde. Se un'intera rete remota deve essere raggiungibile dalla VPC, scegli un'architettura che pubblica i suoi prefissi e la sua politica di accesso invece di dare per scontato che Client VPN lo faccia già. L'accesso da client a client è un terzo caso, più ristretto, con i propri oggetti di rotta e autorizzazione. Nessuno di questi è una casella di controllo sull'endpoint esistente.
Mantieni onesto anche l'ambito della spiegazione IPv4. La documentazione AWS attuale separa IPv6, dove quella traduzione non si applica, e altri modelli di collegamento che instradano in modo diverso.
Prova in tre passaggi etichettati: il client apre una sessione consentita, il servizio nella VPC risponde a quella sessione e un host della VPC apre una nuova sessione verso il client. Che i primi due riescano mentre il terzo fallisce è la forma attesa di questo progetto, non un difetto da inseguire con regole del firewall.