Access Server in tunnel completo su EC2: perché una sola casella non basta

Azzerare il controllo source/destination su un’istanza EC2 è la risposta più ripetuta alle domande sull’uscita internet di Access Server, e da sola non fa nulla per i tuoi client. Il controllo è un vincolo di inoltro di AWS: fa sì che l’istanza accetti pacchetti la cui origine o destinazione non è il suo indirizzo. Non dice al client di Access Server di inviare il traffico internet attraverso il tunnel, non crea una route a monte e non aggiunge NAT. Il mito è che la casella di controllo sia la funzionalità.

Cosa controlla davvero quella casella

Ogni interfaccia di rete EC2 scarta il traffico che non è indirizzato a sé, a meno che l’istanza non agisca come router, dispositivo NAT o gateway VPN e tu non disattivi quel controllo. Disattivarlo concede il permesso di inoltrare. Il permesso non è configurazione: l’istanza ha comunque bisogno di una route verso un internet gateway o un dispositivo NAT, la tabella di route della VPC ha comunque bisogno della voce corrispondente, i security group devono comunque consentire il flusso e il server deve comunque tradurre o instradare il traffico di ritorno.

Verifica il valore attuale con aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck prima di cambiare qualsiasi cosa. Se lo cambi nella console, fallo perché l’istanza inoltra per altri, non perché un client non riesce a raggiungere internet.

Access Server gestisce la politica di routing del client

In Access Server 3, apri Access Controls e trova la sezione Internet Access and DNS. La selezione Internet Gateway offre il tunnel completo o lo split tunneling; il tunnel completo dice al client di instradare il traffico predefinito nella VPN, lo split tunneling lascia il traffico internet sul percorso locale del client. Salva e applica tramite il flusso di lavoro del prodotto, poi riconnetti un client di prova, perché la politica viene consegnata al momento della connessione.

Le versioni più vecchie usano menu diversi e alcune build Community di OpenVPN non hanno un controllo equivalente. Controlla la versione principale installata prima di cercare una schermata che non esiste. Poi verifica cosa ha ricevuto il client: un profilo con tunnel completo deve installare una route predefinita attraverso il tunnel, un profilo con split tunneling no.

Traccia il pacchetto dopo il tunnel

Una volta che il client invia il traffico internet nel tunnel, il server deve inoltrarlo e di solito tradurlo. Access Server gestisce le proprie regole NAT e di routing, quindi leggi la configurazione effettiva invece di aggiungere regole di OpenVPN Community ai file generati; le regole non gestite vengono sovrascritte o entrano in conflitto al successivo aggiornamento del prodotto. sudo iptables -t nat -L -n -v o l’equivalente nftables mostra cosa sta effettivamente traducendo.

Il lato AWS è un percorso separato. Un’istanza in una sottorete pubblica raggiunge direttamente un internet gateway e mantiene il suo indirizzo pubblico o il suo elastic IP. Un’istanza in una sottorete privata ha bisogno di una route verso un NAT gateway o un’istanza NAT, e il dispositivo NAT ha bisogno della propria route verso l’internet gateway. Collegare un internet gateway alla VPC non dà di per sé un indirizzo pubblico di ritorno a nessuna origine privata, ed è per questo che la stessa configurazione di Access Server funziona in una sottorete e fallisce silenziosamente in un’altra.

Controlla la tabella di route associata alla sottorete dell’istanza, non solo la tabella principale della VPC. Le associazioni di sottorete hanno la precedenza sulla tabella principale, e un’associazione obsoleta è una causa comune di una configurazione funzionante che smette di funzionare dopo una ricostruzione.

Tieni separati l’uscita IP e il DNS

Prova prima un indirizzo letterale, poi un nome, dalla stessa applicazione client. Se curl -4 https://checkip.amazonaws.com restituisce un indirizzo pubblico ma i nomi host falliscono, il tunnel e il percorso NAT funzionano e il problema è il DNS: il resolver inviato, lo stato del resolver del client o un security group che blocca il resolver. Le impostazioni DNS di Access Server si trovano nella stessa area Internet Access, ma viaggiano su un percorso di codice diverso.

Confronta l’indirizzo restituito con l’uscita che intendevi. Se è l’indirizzo pubblico dell’istanza, il traffico viene tradotto dall’istanza; se è un indirizzo di un NAT gateway, è in uso il percorso della sottorete privata. Entrambi possono essere corretti. Quello che non puoi concludere è che un browser sul server dimostri l’inoltro per i client.

Non lasciare che una casella chiuda l’indagine

IPv6 è una decisione separata. Una politica di tunnel completo per IPv4 non dice nulla su se IPv6 venga trasportato, bloccato o lasciato uscire, e un client dual-stack può continuare a usare il suo percorso IPv6 locale mentre IPv4 passa nel tunnel. Verifica la famiglia di indirizzi che ti interessa davvero e decidi esplicitamente se l’altra debba essere disattivata.

Infine, verifica lo stato disconnesso. Una selezione di tunnel completo descrive la politica di routing da connesso, non cosa succede quando il tunnel cade. Se il requisito è che nessun traffico esca fuori dalla VPN, quella è una questione di kill switch e firewall, e richiede un proprio test invece di un’inferenza dalla tabella di route.