LAN dietro una sessione AWS Client VPN: cosa viene inoltrato

Il portatile si connette all’endpoint di AWS Client VPN, raggiunge la sottorete privata e tutto sembra sano. Il desktop sulla stessa LAN non raggiunge nulla, anche se l’host Linux ha anch’esso un’interfaccia bridge e le due macchine sono sullo stesso cavo. Nulla è configurato male nel tunnel; il pezzo mancante è l’instradamento, e il bridge è una falsa pista.

Estendere una sessione Client VPN a una LAN è un ruolo di gateway. Non è un segmento Ethernet allungato dentro un servizio gestito.

L’host funziona e la LAN no

L’interfaccia del tunnel sulla macchina Linux ha un indirizzo dentro il CIDR del client Client VPN, e l’endpoint ha inviato rotte per gli intervalli del VPC. Una richiesta fatta su quella macchina è traffico generato localmente: sceglie una rotta, esce dal tunnel e riceve una risposta. Quel percorso non tocca mai il codice di inoltro, l’interfaccia LAN né alcuna regola del firewall che governa il transito.

Il traffico da un altro dispositivo della LAN è un flusso diverso. Arriva sull’interfaccia LAN, ha bisogno di una rotta che punti nel tunnel, ha bisogno dell’inoltro abilitato, ha bisogno di un firewall che lo consenta e ha bisogno che la risposta torni attraverso lo stesso host. Quattro requisiti, e il test riuscito sul portatile non ne dimostra nessuno. Dal desktop il guasto sembra strano: il tunnel è attivo, le credenziali sono valide e la destinazione semplicemente non risponde mai. Il difetto è locale al percorso di inoltro del gateway, non al servizio.

Non tutti i client possono essere un gateway

AWS dichiara che la sua applicazione desktop Client VPN non supporta l’inoltro IP, e che altri client potrebbero farlo. Quel vincolo decide l’architettura prima che venga digitato qualsiasi comando. Se l’unico client disponibile è l’applicazione desktop ufficiale, un gateway Linux che inoltra per la LAN non è una configurazione che potete completare, e nessuna quantità di masquerading lo cambierà.

Anche il client sostitutivo deve corrispondere al metodo di autenticazione dell’endpoint e alla policy che intendete applicare. Gli endpoint basati su certificati, su directory e su SAML non accettano le stesse configurazioni client, e un client di terze parti che si autentica ma ignora le rotte inviate non è un miglioramento.

Trattate la scelta del client come parte della revisione del progetto. Determina se il modello di inoltro LAN è disponibile, e determina quale identità vede l’endpoint per ogni dispositivo dietro il gateway. Registrate il client e la configurazione dell’endpoint contro cui è stato testato. Un cambio di client sei mesi dopo può rimuovere silenziosamente la capacità che il progetto dava per scontata.

Instradate la LAN verso il tunnel e traducetela

Con un client supportato al suo posto, il resto è normale lavoro da gateway. I dispositivi della LAN hanno bisogno di una rotta per l’intervallo del VPC che punti all’host Linux, e l’host ha bisogno dell’inoltro abilitato. Se volete che il VPC veda il traffico come il client connesso e non come un indirizzo LAN arbitrario, traducete la sorgente in uscita.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Limitate la regola all’interfaccia del tunnel e all’intervallo del VPC, come sopra, invece di fare masquerading di tutto ciò che l’host inoltra. La regola più stretta è più facile da ragionare, e non cambia silenziosamente traffico che doveva conservare il suo indirizzo di origine originale.

Fate arrivare la rotta della LAN automaticamente se potete: un’opzione DHCP, un annuncio del router o una rotta statica inviata da ciò che gestisce la LAN. Una rotta che esiste solo su una macchina di test farà sembrare il progetto rotto nel momento in cui qualcun altro lo prova.

Anche la risposta ha bisogno di un percorso

Una volta che la richiesta raggiunge il VPC, la risposta deve tornare attraverso gli stessi stati di traduzione e trovare la rotta della LAN sul gateway. Quella parte di solito funziona quando la regola di masquerading è in posizione, perché la mappatura vive sull’host che l’ha eseguita. Si rompe quando il lato VPC ha una rotta che manda la risposta altrove, ed è per questo che contano sia la rotta del CIDR del client sia l’associazione di sottorete sull’endpoint.

Guardate i contatori, non solo il ping. Una regola di masquerading con zero pacchetti vi dice che la richiesta non ha mai raggiunto l’interfaccia del tunnel, il che riporta alla rotta della LAN o alla tabella di routing del client stesso. Una regola con pacchetti ma senza risposte punta al lato VPC, alle regole di autorizzazione o a un gruppo di sicurezza che non accetta la sorgente tradotta. Leggete entrambe le direzioni prima di cambiare qualcosa, perché un conteggio che cresce solo da un lato è un percorso a senso unico, non uno lento.

Ricordate che l’endpoint è un servizio gestito. Non c’è alcun file di configurazione del server da modificare né alcuna direttiva client-config da aggiungere, quindi le istruzioni scritte per un server OpenVPN autogestito con rotte personalizzate delle sottoreti client non si trasferiscono. Su AWS le leve sono l’associazione di sottorete, le regole di autorizzazione e le tabelle di routing del VPC.

L’identità condivisa è la parte a cui la policy deve rispondere

Ogni dispositivo dietro il gateway usa la sessione VPN del gateway. Le regole di autorizzazione dell’endpoint concedono l’accesso a un utente o a un gruppo, e dal punto di vista del servizio c’è esattamente un utente su quella sessione. L’inoltro locale non moltiplica quell’identità in autenticazione per dispositivo, e non estende i controlli di postura del dispositivo alla stampante nell’angolo.

Può essere accettabile, oppure può essere il motivo per cui il progetto viene respinto. Dipende da ciò che le risorse del VPC presuppongono su chi chiama. Un’identità condivisa che si adatta al modello di autorizzazione va bene; una che trasforma silenziosamente una singola sessione autenticata in accesso all’intera LAN è un rilievo che attende di essere scritto.

Se il requisito è davvero collegare un intero sito a un VPC, confrontate un progetto site-to-site supportato prima di estendere un client di accesso remoto. La semantica è diversa, e una sessione client con NAT è un cattivo sostituto di un collegamento di sito quando il VPC deve iniziare connessioni verso la LAN.

Decidete il client, la rotta, la traduzione e la storia dell’identità in quest’ordine. Ognuno vincola il successivo, e l’ordine spiega perché l’host funziona mentre la LAN no.