Accesso intermittente con AWS Client VPN: verificate ogni subnet associata

Un utente si connette, apre l’app interna e ottiene una risposta; un collega sullo stesso endpoint riceve un timeout da un portatile identico sulla stessa Wi-Fi. Questo schema è la firma di un endpoint client VPN con più di una subnet associata, dove i percorsi non sono equivalenti. Affronto la cosa dalla console verso l’esterno, perché due schede decidono se il resto dell’indagine vale la pena. Nulla nella configurazione del client lo spiega.

Partite dall’endpoint e elencate le associazioni

Nella console VPC, aprite Client VPN endpoints, scegliete l’endpoint e leggete la scheda Associations. Ogni associazione è una subnet in una zona di disponibilità, e il client atterra su quella che il servizio sceglie quando viene costruita la connessione. Annotate gli ID delle subnet e la tabella di routing che ciascuna usa davvero, perché questi due elenchi sono il confronto che state per fare.

Se l’endpoint mostra una sola associazione, questa teoria è sbagliata e il client è il sospetto migliore.

Confrontate la tabella di routing dell’endpoint con ogni associazione

Aprite la scheda Route table sullo stesso endpoint. Ogni CIDR di destinazione lì ha un target, e in un client VPN il target è un’associazione e non un gateway. AWS richiede una voce di destinazione per ogni subnet associata, quindi una rotta che ne punta una sola rende l’accesso dipendente da dove è atterrata la sessione. Controllate la destinazione che vi interessa davvero, poi la sua regola di autorizzazione, perché la rotta fornisce il percorso e la regola decide chi può usarlo.

Una volta tabulate entrambe le voci, il guasto è difficile da mancare.

La seconda riga è tutto il bug nella maggior parte dei ticket. La rotta dell’endpoint c’è, quindi nessuno guarda oltre, e il pacchetto muore un salto dopo dentro la VPC.

Seguite ogni subnet fino alla sua tabella di routing effettiva

Una subnet senza associazione esplicita a una tabella di routing eredita la tabella principale della VPC. Leggete la tabella realmente in vigore, non quella il cui nome sembra giusto, e confrontate destinazione e target invece dell’etichetta sulla riga.

La guida AWS sull’accesso intermittente la descrive come copertura delle rotte tra le associazioni, che è il modello corretto. L’endpoint porta il pacchetto a una subnet, e la tabella di quella subnet deve ancora sapere dove vive la rete dell’applicazione.

Correggete la riga mancante nella tabella che la possiede. Copiare un’intera tabella di routing da una subnet funzionante copia anche scelte di internet, appliance e isolamento che non erano mai state pensate per questa, e quello scambio di solito è peggio del disservizio con cui avete iniziato.

Controllate le regole di autorizzazione, poi il percorso di ritorno

Le regole di autorizzazione sono per destinazione e per gruppo, e vengono valutate separatamente dalle rotte. Una destinazione con rotte ovunque ma senza regola per il gruppo dell’utente si comporta come un buco nero con una tabella di routing che sembra sana.

Il percorso di ritorno merita la stessa attenzione. Una connessione peering richiede una rotta nella VPC dell’applicazione che punti al CIDR del client, regole dei gruppi di sicurezza che consentano il traffico a entrambe le estremità e ACL di rete che non lo scartino. La raggiungibilità a senso unico, dove ping funziona e la stretta di mano TCP no, di solito indica un’ACL o un gruppo di sicurezza e non la VPN.

I gruppi di sicurezza dell’endpoint stesso stanno sulle interfacce di rete elastiche dell’associazione, quindi una regola che consente la porta dell’applicazione dal CIDR del client deve essere collegata all’associazione, non solo all’istanza.

Verificate con una riconnessione, non con una richiesta fortunata

Con il tunnel diviso, le rotte dell’endpoint vengono inviate quando la connessione viene stabilita, quindi un insieme di rotte modificato non arriva mai a un client che resta connesso. Disconnettetevi e riconnettetevi tramite il client supportato, poi confermate che le nuove rotte siano presenti sulla macchina.

Infine, correlate il registro delle connessioni con l’indirizzo ricevuto dal client, e ripetete il test abbastanza volte da colpire più di un’associazione. Una sola richiesta riuscita dopo una correzione dimostra che un percorso funziona, e il ticket riguardava l’altro.