L’handshake di PiVPN funziona, le pagine si bloccano: controllate la MASQUERADE

Il telefono mostra il tunnel come connesso, il client riporta un indirizzo privato e la prima pagina resta bloccata a metà caricamento. Questa combinazione manda la maggior parte delle persone verso le impostazioni di cifratura e la temperatura della CPU, dove in realtà non c’è nulla di rotto. Il tunnel è salito, quindi la negoziazione è terminata; ciò che ha fallito è il passo successivo, quando il server prova a consegnare i pacchetti del client a internet. Seguite lo stesso percorso che fanno quei pacchetti e la discrepanza di solito è visibile in una riga della tabella NAT.

Partite da ciò che il client può e non può raggiungere

Dal client connesso, caricate una pagina che vive su internet pubblico e notate se fallisce subito o si blocca a metà. Poi aprite una risorsa sull’indirizzo privato del server VPN stesso e confrontate i due risultati.

Un indirizzo di tunnel che risponde al ping mentre i siti pubblici vanno in timeout è il segno di un problema di inoltro o di traduzione, non di un handshake rotto. Il pannello di stato del client non può distinguerli, perché sa solo che il canale di controllo è attivo. Controllate sul server l’interfaccia del tunnel con ip -br addr show tun0 e confermate che l’indirizzo assegnato al client cada nel pool che avete configurato. Se il pool e l’indirizzo del client non coincidono, correggete prima quello, perché ogni regola qui sotto corrisponde al pool.

Poi chiedete al server quale interfaccia userebbe per raggiungere un indirizzo pubblico. ip route get 203.0.113.9 stampa il dispositivo e la sorgente scelti sulla sua prima riga. Annotate il nome di quel dispositivo, perché è il valore che la regola NAT deve contenere.

Leggete la regola che decide se i pacchetti escono

MASQUERADE riscrive un pacchetto solo quando il pacchetto esce dall’interfaccia indicata nella regola. Una regola limitata a un dispositivo via cavo non fa nulla per il traffico che esce in Wi-Fi, e il pacchetto conserva il suo indirizzo sorgente privato fino al router a monte. Quel router non ha una rotta di ritorno verso il vostro pool del tunnel, quindi scarta la risposta, e il client vede una connessione che si apre e poi muore. Il sintomo cresce con la quantità di pagina che arriva prima che serva la prima risposta.

Elencate la tabella viva e leggete la colonna dell’interfaccia di uscita invece di cercare solo la parola MASQUERADE. L’output in forma di aggiunta è più facile da confrontare di un elenco formattato:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Su un Raspberry Pi che un tempo usava Ethernet e ora usa il Wi-Fi, il nome obsoleto è quasi sempre tutta la storia. L’installer ha registrato quale dispositivo era presente al momento della configurazione, e l’insieme di regole salvato lo ripete a ogni avvio. Confrontate il dispositivo della ricerca di rotta con quello nella regola prima di cambiare altro. Se coincidono, l’interfaccia non è il vostro problema e dovreste passare ai contatori dell’ultima sezione. Se differiscono, la correzione è una modifica di una parola nel file di persistenza.

Correggete l’insieme di regole salvato, non solo quello in esecuzione

Modificare solo la tabella viva dura fino al riavvio successivo, che è esattamente il tempo necessario per convincervi che il problema è risolto. Le regole che tornano all’avvio vivono in un file che un pacchetto di persistenza del firewall ricarica. Sulle immagini Pi basate su Debian quel file di solito è /etc/iptables/rules.v4.

Fate una copia prima di toccarlo, poi sostituite l’interfaccia di uscita sulla riga MASQUERADE con il dispositivo che avete annotato, per esempio -o wlan0 invece di -o eth0. Lasciate l’intervallo di origine com’è, a meno che il vostro pool di client sia cambiato. Ricaricate e confermate che la regola ora nomini il dispositivo giusto:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Due impostazioni adiacenti si dimenticano facilmente. sysctl net.ipv4.ip_forward deve riportare 1, e il router a monte non deve filtrare da solo gli indirizzi sorgente privati.

Dimostrate che la regola scatta, poi isolate ciò che è ancora lento

I contatori sono l’unica prova onesta che una regola ha corrisposto. Eseguite l’elenco dettagliato, avviate un download sul client e rieseguitelo. Le colonne dei pacchetti e dei byte accanto alla vostra regola dovrebbero salire, e una regola che resta a zero non corrisponde ancora. Se i contatori si muovono ma le pagine falliscono ancora, confrontate l’intervallo di origine con il pool reale con grep -n "^server " /etc/openvpn/server.conf. Se si muovono e le pagine si caricano ma il throughput è scarso, la traduzione è finita e il problema restante è altrove.

Confrontate due trasferimenti dallo stesso client, uno verso un host sulla rete locale e uno attraverso il tunnel verso lo stesso host. Lento in entrambi i casi indica il collegamento a monte del Pi o la connessione Wi-Fi, non la VPN. Lento solo attraverso il tunnel indica l’MTU e le ritrasmissioni, che potete ispezionare con ip -s link show tun0 prima di cambiare qualsiasi impostazione di crittografia.

Per annullare l’esperimento, ripristinate la copia e ricaricatela, poi confermate che la regola originale e i suoi contatori sono tornati. Scrivete il dispositivo di uscita e il comando di ricarica nelle note del server, perché il prossimo cambio di collegamento a monte riscoprirà la stessa discrepanza. Una regola che nomina il dispositivo sbagliato resta invisibile finché il traffico non ne ha bisogno.