AWS Client VPN connesso ma senza accesso a internet: controllo delle rotte

Siete connessi all’endpoint di AWS Client VPN, la sottorete privata risponde e ogni pagina pubblica va comunque in timeout. Questa combinazione restringe il problema a uno di tre oggetti sul lato gestito: la rotta che il client installa, la rotta dell’endpoint insieme alla sua regola di autorizzazione, oppure il salto successivo della sottorete associata. Le controllo in quest’ordine perché ogni guasto appare diverso dal lato client. Questa guida copre l’endpoint gestito associato alla VPC, non un server OpenVPN su un’istanza EC2 e non un collegamento Cloud WAN o Transit Gateway.

Iniziate da ciò che il client instrada davvero

Uno stato connesso dimostra la sessione TLS e l’assegnazione del CIDR al client, nulla di più. Chiedete al sistema operativo dove andrebbe un indirizzo pubblico mentre il tunnel è attivo. Su Linux, ip route get 1.1.1.1 dovrebbe indicare l’interfaccia del tunnel; su macOS, netstat -rn -f inet | head -5 mostra la voce predefinita; su Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 stampa l’interfaccia scelta e il salto successivo.

Poi leggete il flag dello split tunnel, perché decide se le rotte pubblicate dall’endpoint sono le uniche destinazioni che il client invia nel tunnel:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

Quando SplitTunnel vale true, una destinazione pubblica usa il tunnel solo se l’endpoint pubblica una rotta che la copre, quindi una 0.0.0.0/0 assente lascia quel traffico sull’interfaccia locale. Quando vale false, il client cattura il traffico, ma l’endpoint deve comunque instradarlo e autorizzarlo; altrimenti i pacchetti entrano nel tunnel e si fermano lì. Riconnettete il client dopo aver cambiato una delle due impostazioni, perché rotte e server DNS vengono consegnati al momento della connessione e un client in esecuzione può conservare il vecchio insieme.

Leggete la rotta dell’endpoint e la regola di autorizzazione separatamente

Sono due oggetti, e crearne uno non crea l’altro. Elencate le rotte dell’endpoint e cercate una rotta predefinita il cui target sia una sottorete associata:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Ogni rotta ha esattamente una sottorete di destinazione, quindi tre associazioni richiedono una rotta predefinita corrispondente ciascuna. AWS documenta questo requisito di copertura, e il sintomo pratico di una lacuna è un utente che lavora da una sottorete e si blocca da un’altra, cosa che si legge come un guasto intermittente invece che come una rotta mancante. La documentazione ufficiale dello scenario Client VPN descrive la disposizione con sottorete pubblica a cui appartengono queste rotte.

L’autorizzazione è il secondo oggetto. Quando nessuna regola copre la destinazione pubblica, il tunnel trasporta il pacchetto e il servizio lo scarta, quindi le risorse private continuano a funzionare mentre internet no:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Una regola per il CIDR della VPC non dice nulla su 0.0.0.0/0. Aggiungere i pezzi mancanti per un tunnel completo significa una rotta per sottorete associata più una regola di autorizzazione che potrete verificare in seguito:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all concede la destinazione a ogni client dell’endpoint, quindi tenetela solo finché il tunnel deve essere completo; una regola legata a un gruppo di directory è preferibile quando avete gruppi a cui legarla.

Seguite il pacchetto fuori dalla sottorete associata

La rotta dell’endpoint decide che AWS consegna il pacchetto a quella sottorete. Non decide il salto successivo oltre, che vive nella tabella delle rotte VPC della sottorete stessa:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

Una rotta predefinita utilizzabile punta a un internet gateway per una sottorete pubblica, o a un NAT gateway per una privata, e uno stato blackhole significa che il target è stato eliminato e il percorso ora muore in silenzio. Sono tabelle diverse dall’elenco delle rotte dell’endpoint, e riparare una non ripara l’altra.

Su questo salto ci sono due filtri. Il gruppo di sicurezza applicato all’associazione di rete di destinazione deve consentire il traffico in uscita verso la destinazione pubblica, e qualsiasi ACL di rete applicabile deve consentire la richiesta e il traffico di ritorno sulle porte effimere. Un gruppo di sicurezza di associazione restrittivo è una causa comune per cui l’accesso privato funziona e quello pubblico no.

Scegliete il primo livello dal sintomo invece di cambiare tutti e tre insieme:

Separate il guasto DNS da una rotta morta

La risoluzione dei nomi fallisce diversamente dall’inoltro, e il tunnel completo rende la differenza importante perché ora si raggiunge il resolver spinto attraverso il tunnel. Se l’endpoint specifica server DNS della VPC, i loro indirizzi hanno bisogno di copertura di rotta e autorizzazione come qualsiasi altra destinazione. Interrogate il resolver direttamente per vedere quale guasto avete: dig +short example.com @10.0.0.2, oppure nslookup example.com 10.0.0.2 su Windows.

Quando un URL numerico risponde e uno con nome no, smettete di modificare la rotta predefinita e lavorate sul DNS. Una richiesta a un indirizzo IP non dimostra nulla su un host virtuale con nome e sul suo certificato, quindi tenete una prova con nome nel controllo finale.

I tempi aiutano. Una connessione TCP che non riceve risposta entro pochi secondi indica l’instradamento o un filtro, mentre una richiesta che resta appesa nella ricerca del nome indica il resolver. Cambiare la rotta predefinita mentre il resolver è irraggiungibile tende a trasformare un guasto in due.

Tornate indietro con ordine, poi verificate il percorso di uscita

Entrambi gli oggetti erano additivi, quindi il rollback è una cancellazione e non una riparazione:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Riconnettetevi, poi confermate da quale percorso esce il traffico. Confrontate l’indirizzo pubblico osservato con l’indirizzo IP elastico del NAT gateway, o con l’internet gateway che intendevate usare, e verificate che una risorsa privata risponda ancora nella stessa sessione.

Chiudete con un elenco breve e trattate l’ultimo punto come parte della modifica e non come documentazione:

• Una 0.0.0.0/0 rotta di endpoint per ogni sottorete associata.
• Una regola di autorizzazione che copra 0.0.0.0/0 per i client che volete servire.
• Una rotta predefinita della VPC non in stato blackhole su ogni sottorete associata.
• L’uscita del gruppo di sicurezza dell’associazione, più il traffico di ritorno dell’ACL.
• Indirizzi del resolver instradati e autorizzati, verificati con una richiesta con nome.
• Un rollback documentato per la rotta e la regola.

Una nota di ambito: questo è un percorso IPv4. Un client dual stack conserva la connettività IPv6 che già ha, quindi una rotta predefinita IPv6 è una decisione separata con la propria autorizzazione e non un effetto collaterale di questa.