AWS Client VPN con tunnel diviso: quali rotte pubblicare

La console offre un interruttore per il tunnel diviso, quindi la decisione sembra una casella di controllo. Non lo è. Ciò che arriva davvero al client è l'insieme delle rotte pubblicate dell'endpoint, e quell'elenco decide quali prefissi privati usano il tunnel, se il traffico internet generale resta locale o esce tramite AWS, e con quale resolver il client può ancora parlare. Tre domande risolvono il progetto, e a ciascuna si può rispondere male mentre la connessione riesce comunque.

Un flag del tunnel diviso non è un elenco di destinazioni

AWS descrive il tunnel diviso come l'aggiunta delle rotte dell'endpoint alla tabella delle rotte del client al momento della connessione. Una rotta per il VPC privato limita il tunnel a quella destinazione; tutto il resto segue il percorso ordinario del client. Una rotta predefinita è un'istruzione diversa con un effetto diverso, ed è per questo che la documentazione sul tunnel diviso sconsiglia di pubblicare 0.0.0.0/0 su un endpoint configurato per questa modalità: di solito rompe la connettività invece di estenderla. La tabella delle rotte dell'endpoint è la politica, e la tabella delle rotte del client è il risultato che puoi ispezionare.

Leggi insieme la tabella delle rotte dell'endpoint e le rotte installate del client. L'etichetta descrive un'intenzione; le rotte descrivono ciò che accade.

Prima decisione: il traffico internet generale deve restare locale?

Se la navigazione deve usare la connessione dell'utente, pubblica solo le destinazioni private che servono al lavoro e fermati lì. Non aggiungere una rotta internet perché un tutorial sul tunnel completo ne includeva una, e non presumere che la rotta extra migliori la sicurezza. Cambia il percorso, non aggiunge una politica e di solito costa una latenza che non avevi previsto.

Se il traffico internet deve uscire tramite AWS, costruisci l'architettura di accesso a internet documentata: rotta dell'endpoint, regole di autorizzazione, il percorso della sottorete associata, politica di sicurezza e un'uscita a monte funzionante. Una rotta predefinita da sola non fornisce nulla di tutto ciò.

Seconda decisione: quali prefissi privati, autorizzati da chi?

Pubblica l'insieme più piccolo di destinazioni che serve al carico reale, e verifica che ogni sottorete associata possa instradare verso di esse. La destinazione della rotta dell'endpoint e l'instradamento VPC della sottorete sono livelli diversi, e una rotta che esiste in uno non è prova dell'altro. L'autorizzazione è ancora separata: una destinazione può essere raggiungibile e comunque negata perché il gruppo del client non ha una regola che la permetta.

Testare una sola sessione riuscita dimostra un solo percorso. Controlla ogni sottorete associata, perché un'associazione di sottorete aggiunta dopo è esattamente dove di solito si trova la rotta mancante.

Quando una destinazione deve essere raggiungibile per nome, nota che la domanda successiva è la risoluzione dei nomi, non quella della rotta.

Terza decisione: quale resolver segue il tunnel?

Un client può ricevere un server DNS raggiungibile solo tramite la VPN, e quel resolver funziona solo se il suo indirizzo è a sua volta dentro una rotta autorizzata. Verifica entrambe le metà: l'indirizzo del resolver segue una rotta pubblicata, e il server risponde ai nomi che l'applicazione chiede. Una richiesta che riesce per indirizzo ma fallisce per nome host indica la denominazione, non l'instradamento, e in quel caso fare debug del tunnel spreca il pomeriggio.

I nomi pubblici dovrebbero risolversi come prima della connessione, un'altra ragione per essere precisi su ciò che pubblichi.

Cambia l'insieme delle rotte, poi verifica entrambi i mondi

AWS documenta che modificare le rotte su un endpoint con tunnel diviso reimposta le connessioni dei client. Pianifica la modifica tenendolo presente: applicala, riconnettiti tramite il client supportato e rileggi le rotte installate invece di fidarti dello stato applicato prima della modifica. Uno stato applicato obsoleto è il motivo più comune per cui una modifica corretta sembra rotta.

Accetta il progetto solo quando una risorsa privata e una destinazione pubblica si comportano come previsto, per nome e per indirizzo, nelle famiglie di indirizzi che supporti davvero. Un tunnel che autentica non è la stessa cosa di un tunnel che divide correttamente.

Scrivi l'elenco delle rotte nel runbook accanto al ragionamento, così la persona successiva distingue un'esclusione intenzionale da una dimenticata.