Aprire la porta VPN non fa arrivare i client alla LAN

Il tunnel sale, il client si autentica, ma la LAN dietro il gateway resta invisibile. La regola che doveva risolverlo consente la porta VPN e funziona esattamente come scritta, perché quella regola governa i pacchetti indirizzati al gateway stesso. Il traffico del client verso un host dietro il gateway ha un’altra destinazione e un’altra catena. Un accesso riuscito non cambia quale delle due catene consulta il kernel.

Due catene, due destinazioni diverse

Il destino di un pacchetto lo decide dove va, non come è arrivato. Il traffico indirizzato a un indirizzo del gateway viene consegnato localmente e valutato con le regole di input. Il traffico che il gateway inoltra viene valutato con le regole di inoltro. La stessa interfaccia del tunnel può produrre entrambi i tipi di pacchetto, perciò una sola regola non può coprire entrambi i compiti.

Tutto il mito in una frase: consentire l’ascoltatore non dice nulla sul consentire la rete che sta dietro. Sono due decisioni separate con prove separate, e un nome di interfaccia su entrambe non le unisce.

Che cosa ammette davvero la regola dell’ascoltatore

I pacchetti dell’ascoltatore terminano nel processo VPN, ed è questo che permette di stabilire il tunnel. Anche la pagina di amministrazione del gateway e una risposta diagnostica locale usano il percorso di input dell’host, perciò un test verso il gateway riesce mentre tutto ciò che sta dietro fallisce. Entrambi i risultati sono corretti e nessuno riguarda la LAN.

Quando il processo decapsula il traffico del client per un’altra destinazione, il pacchetto entra nel percorso di inoltro e lì ha bisogno di un permesso. L’autenticazione riuscita stabilisce chi è il client; non stabilisce dove può andare. Le due domande hanno proprietari, registri e messaggi di errore diversi.

Provate da un client, mai dal gateway

Un test generato sul gateway segue il percorso di uscita dell’host e può riuscire mentre il percorso inoltrato è chiuso. Iniziate il test dal client e osservate entrambe le estremità del flusso.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Se la richiesta compare su tun0 e nulla arriva alla destinazione, il pacchetto viene scartato dopo l’arrivo, il che indica le regole di inoltro o il filtraggio della destinazione stessa. Se su tun0 non compare nulla, il client non la invia nemmeno al tunnel, e il problema è il routing sul client e non la politica sul gateway. Confrontatelo con una richiesta che esce correttamente e non restituisce nulla, che è il caso del percorso di ritorno.

L’inoltro richiede tre cose, non una

L’inoltro del kernel deve essere attivo, una regola di filtro deve accettare il flusso e la destinazione deve essere raggiungibile con un percorso per il ritorno della risposta. Se manca una delle tre, il silenzio è identico dal punto di vista del client.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Leggete le tre uscite insieme. Uno zero nella prima rende irrilevanti le altre due, e una politica di scarto predefinita nella seconda scarta i pacchetti del client mentre il traffico del gateway continua a funzionare. La terza uscita mostra perché la regola dell’ascoltatore non è mai stata il problema.

Tenete separati i due insiemi di regole nella documentazione

Scrivete la regola dell’ascoltatore e quella del servizio inoltrato su righe separate, con proprietari e motivi separati. Quando la porta VPN cambia o viene pubblicato un nuovo servizio, quella separazione impedisce a una modifica di allargare silenziosamente l’altra.

Invece di trattare ogni peer autenticato come membro fidato della LAN, usate regole strette per gli intervalli di client e i servizi che ne hanno bisogno. Le note sull’inoltro di StrongSwan descrivono il lato della rotta di ritorno e della traduzione dello stesso confine, che è ancora una terza decisione.

Infine, tenete dritti i livelli quando un utente viene rifiutato. Se la richiesta raggiunge l’host e l’applicazione rifiuta l’account, riparate il permesso dell’applicazione su quel livello; allargare l’inoltro non può fornire una credenziale per la condivisione di file e allargherà l’accesso a tutti gli altri che si connettono con successo.