Quale indirizzo di origine registrerà NGINX per un client VPN?

In un'installazione di NGINX e OpenVPN sullo stesso host compaiono tre indirizzi client, uno per ogni percorso che una richiesta può seguire. Un browser che raggiunge l'indirizzo del tunnel, un browser che raggiunge l'indirizzo pubblico e un programma che esce dalla via internet del gateway appaiono tutti diversi sul socket in ascolto. Decidete quale percorso state osservando prima di interpretare la riga di log. La decisione dipende dalla destinazione usata dal client, dall'eccezione che mantiene per l'endpoint esterno della VPN e dal fatto che qualcosa traduca il pacchetto lungo il cammino.

Decidete per destinazione, non per chi è l'utente

Partite dall'indirizzo a cui è stata inviata la richiesta, perché è quell'indirizzo a scegliere il percorso. Una richiesta all'indirizzo del tunnel dell'host arriva sull'interfaccia del tunnel con l'indirizzo interno del client come origine. Una richiesta all'indirizzo pubblico dell'host di solito arriva sull'interfaccia rivolta a internet con l'indirizzo pubblico del client, anche quando lo stesso portatile ha un tunnel stabilito in quel momento. Appartenere al pool VPN è quindi una proprietà del percorso del pacchetto, non una proprietà che segue l'utente.

È proprio questa terza riga che conviene controllare per prima quando nel log compare un utente VPN con un indirizzo che non ha nulla a che fare con il tunnel. Spiega anche perché due utenti con lo stesso profilo possono produrre voci diverse: le loro reti di accesso sono diverse e nulla nel tunnel lo sovrascrive.

Perché l'endpoint esterno crea un secondo percorso pubblico

Il client deve raggiungere l'indirizzo pubblico del gateway per stabilire il tunnel, quindi deve esistere una rotta verso quell'indirizzo fuori dal tunnel. Quando un client reindirizza tutto il traffico verso l'interno, un'implementazione sensata mantiene una rotta host esplicita per l'indirizzo pubblico del server, per evitare un tunnel che dipenda da se stesso. Quell'eccezione non distingue tra servizi, per cui ogni richiesta allo stesso indirizzo pubblico la segue, compresa una richiesta del browser a un sito ospitato sul gateway.

È il meccanismo dietro la maggior parte delle segnalazioni confuse in questo ambito, e dipende dall'implementazione del client e non dal server. Due client con profili identici possono quindi comportarsi diversamente. Rimuovere l'eccezione per »aggiustare« il log porta giù anche il tunnel, per cui tenetela e progettate attorno a essa.

Leggete insieme il socket, la tabella e il formato del log

Tre osservazioni stabiliscono quale percorso state guardando: dove ascolta il socket, quale interfaccia risponde alla destinazione e che cosa registra davvero il formato del log. Se l'ascoltatore è legato solo all'indirizzo del tunnel, una richiesta pubblica non può raggiungerlo affatto, il che esclude subito due righe. Se la ricerca per il client restituisce il dispositivo del tunnel, la richiesta è arrivata con un'origine interna e il log dovrebbe mostrarlo.

ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44

Poi leggete il formato invece della riga. Un campo alimentato da un'intestazione inoltrata registra un'affermazione, non un peer del socket, e l'affermazione conta solo quando il peer immediato è un proxy fidato. Scrivere entrambi i valori nel log chiude le discussioni successive, perché il peer immediato e l'indirizzo sostituito sono fatti diversi e solo uno dei due è arrivato dalla rete.

log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.conf

Scegliete il punto d'ingresso che volete e fate concordare il DNS

Se il sito deve essere raggiungibile solo dal tunnel, dategli un nome che per i client VPN si risolva nell'indirizzo del tunnel e applicate la politica sul socket in ascolto. Una risposta DNS divisa che restituisce 10.24.0.1 per il nome interno è una decisione di instradamento travestita da dettaglio di risoluzione dei nomi. Se il sito deve essere anche pubblico, tenete due nomi o due porte e lasciate che il log vi dica quale ha servito la richiesta.

Le regole di autorizzazione seguono la stessa logica. Consentire il pool del tunnel non autorizza una richiesta pubblica e non riempirà un indirizzo interno su una connessione arrivata da internet. Mescolare i due punti d'ingresso sotto un solo nome rende l'origine registrata un effetto collaterale dell'instradamento del client invece di una scelta di progetto.

Verificate il percorso, poi la politica

Confermate il percorso con una cattura sul gateway e una richiesta che controllate. Una cattura sul dispositivo del tunnel e una sull'interfaccia pubblica mostrano quale ha trasportato i byte, e l'ordine dei pacchetti vi dice se è avvenuta una traduzione tra i due.

tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5

Poi verificate l'accesso in entrambe le direzioni: il punto d'ingresso con nome previsto funziona per il client previsto, e un percorso pubblico non approvato viene rifiutato anziché essere solo lento. Un sito generico di eco IP dimostra qualcosa sull'uscita internet del gateway e nulla su questo sito sullo stesso host. Quando una pagina e un WebSocket non concordano, confrontate i loro URL, le famiglie di indirizzi e le risposte DNS prima di toccare la configurazione del server.