AWS Client VPN o un bastion per raggiungere un VPC in peering

Un solo endpoint Client VPN può raggiungere un VPC che è in peering con il suo VPC associato, e non serve un bastion per rendere la cosa legittima. La scelta che vale la pena fare è dove il traffico cambia mani: una rotta dell'endpoint che atterra nella subnet di associazione e attraversa la connessione di peering, oppure un host nel VPC in peering che chiude la sessione. Entrambi i percorsi funzionano e falliscono in punti diversi, quindi la decisione riguarda proprietà e audit, non ciò che AWS consente. Ecco come scelgo tra i due, e le quattro voci che fanno funzionare il percorso instradato.

Due percorsi, un endpoint, proprietari diversi

Sul percorso instradato il traffico del client raggiunge l'endpoint, viene tradotto nell'indirizzo dell'interfaccia di rete Client VPN nella subnet di associazione ed esce da quella subnet attraverso la connessione di peering da A a B. Il VPC B non chiude alcuna sessione VPN; vede traffico ordinario dal VPC A, per questo la sua rotta di ritorno punta al VPC A e non al pool dei client.

Sul percorso del bastion il client raggiunge prima un host. Un bastion in A lascia comunque l'ultimo salto attraversare la connessione di peering, quindi mantenete il lavoro di peering e aggiungete una sessione. Un bastion in B ha comunque bisogno di un percorso dal client, e quando quel percorso è la stessa rotta dell'endpoint avete il progetto instradato più un salto. Il bastion toglie lavoro solo quando esiste già, è già approvato, e ciò che sta dietro ha bisogno di un confine di sessione e non di un confine di rete.

Quattro voci fanno funzionare il percorso instradato

AWS documenta questo scenario nella pagina Client VPN how-it-works, e in pratica si riduce a quattro voci possedute da due o tre team. Gli intervalli sono illustrativi; l'intervallo in peering deve essere univoco e l'intervallo di ritorno deve corrispondere al vostro piano.

Rotta e autorizzazione sono controlli separati. Una rotta dell'endpoint corretta senza una regola di autorizzazione corrispondente non dà nulla al client; una regola di autorizzazione per una destinazione che l'endpoint non può instradare gli dà un buco nero. Entrambe devono nominare lo stesso intervallo.

La rotta dell'endpoint punta a una subnet nel VPC dell'endpoint stesso, mai alla connessione di peering. Le tabelle delle rotte del VPC puntano alla connessione di peering, mai a un'istanza o a un'interfaccia. Copiare un valore tra le due viene salvato senza obiezioni e non instrada nulla.

Poiché la subnet di associazione traduce l'origine del client, B deve instradare di ritorno al VPC A, non al pool dei client. Inviare l'intervallo dei client attraverso la connessione di peering sembra simmetrico, supera la revisione e fallisce in silenzio perché B non vede mai un pacchetto con origine client.

Gruppi di sicurezza e l'ultimo metro di autorizzazione

L'instradamento porta i pacchetti in B; B decide ancora. Per una connessione di peering attiva nella stessa regione, un gruppo di sicurezza in B può referenziare il gruppo applicato all'associazione Client VPN, il che mantiene la regola stretta e sopravvive ai cambi di indirizzo. Dove un riferimento al gruppo non è praticabile, consentite esplicitamente l'intervallo della subnet di associazione invece di ampliarlo a 0.0.0.0/0, che trasforma un errore di instradamento in un timeout inspiegato.

Poi controllate ciò che l'instradamento non tocca mai: le ACL di rete su entrambe le subnet, l'elenco consentito o il pubblico del token dell'applicazione, e il DNS. Il peering non copia le zone ospitate private, quindi il portatile può mantenere una rotta funzionante verso un indirizzo che non riesce a risolvere, e una connessione di peering non aggiunge fiducia a un certificato. Puntate l'endpoint a un resolver che risponde per B, poi confermate che il nome privato e il certificato coincidono.

Quando il bastion è la risposta onesta

Tengo tre fattori scatenanti per scegliere un bastion di proposito. Il VPC in peering appartiene a un team che non aggiungerà una rotta di ritorno per il vostro intervallo o non accetterà un riferimento a un gruppo. L'accesso deve essere approvato o registrato per sessione e l'applicazione non può portarlo da sola. Oppure l'ultimo salto deve restare dentro B perché il servizio si risolve solo lì e la sua identità TLS è fissata a un nome interno.

Niente di tutto ciò aggira il fatto che il peering non è transitivo. La non transitività limita ciò che le risorse in B possono fare: non possono usare A come transito verso un terzo VPC con cui A è in peering. Non ha mai significato che un utente VPN non possa raggiungere un VPC in peering direttamente, e un bastion costruito per aggirare questa lettura sbagliata è un host da patchare senza motivo.

L'errore inverso costa di più nel tempo: fate passare ogni team dall'unico bastion che già esiste, poi scoprite che il suo gruppo di sicurezza, la sua tabella delle rotte e la sua finestra di patch sono la dipendenza di produzione. Annotate quale fattore scatenante serve l'host e ritiratelo quando il fattore scompare.

Transit Gateway e più associazioni cambiano l'aritmetica

Se l'endpoint è collegato direttamente a un Transit Gateway invece che a una subnet, il modello cambia: i client non vengono più tradotti in un indirizzo di interfaccia in una subnet di associazione, e le tabelle delle rotte del gateway devono portare l'intervallo dei client più il collegamento che porta al VPC in peering. È più pulito su larga scala, ma il lavoro si sposta da quattro voci alle tabelle delle rotte del gateway.

Più associazioni moltiplicano i controlli. La rotta dell'endpoint appartiene all'endpoint, ma ogni subnet di associazione ha bisogno di una tabella delle rotte con un vero prossimo salto di peering. Una sessione può riuscire attraverso un'associazione mentre un'altra non ha un percorso di ritorno, quindi provatele tutte.

Ordine di verifica che trova il guasto in fretta

Eseguitele in ordine; ogni passo può riuscire mentre il successivo fallisce, e un timeout del client quasi mai dice quale si è rotto.

1. Risolvete il nome dell'applicazione dal client e verificate che l'indirizzo sia nell'intervallo in peering.
2. Connettetevi, poi leggete il registro delle connessioni dell'endpoint per l'associazione che ha chiuso la sessione.
3. Su quella subnet di associazione, confermate che la tabella delle rotte punti l'intervallo in peering a una connessione di peering attiva.
4. Sulla subnet delle risorse in B, confermate una voce di ritorno per l'intervallo dell'interfaccia e regole di gruppo corrispondenti.
5. Provate un'operazione consentita e una risorsa che deve restare irraggiungibile; la seconda cattura i residui del debug.
6. Riconnettetevi dopo ogni modifica della rotta split-tunnel, perché un tunnel in esecuzione non prenderà un nuovo insieme di rotte.

Due sintomi meritano di essere memorizzati. Un SYN che raggiunge B senza risposta è quasi sempre la rotta di ritorno mancante. Una connessione che si completa e poi si reimposta è di solito il gruppo, l'ACL o l'applicazione. Nessuno dei due appare nel registro dell'endpoint come causa, quindi tenete le quattro voci con un proprietario accanto a ciascuna.

Se nessuno dei tre fattori scatenanti vale, completate il percorso instradato e registrate quelle quattro voci. Se uno vale, tenete il bastion solo per quella frontiera e lasciate la rotta dell'endpoint ai servizi che non hanno bisogno di una sessione davanti.