Perché un server dietro un client VPN risponde tramite il tunnel

Le connessioni in ingresso verso un host che esegue anche un client VPN falliscono in modo molto specifico: l’handshake arriva, il demone risponde e il client non riceve nulla indietro. Nulla blocca la porta. La risposta è uscita dal tunnel, perché il tunnel possiede la rotta predefinita e il kernel instrada le risposte per destinazione, non per memoria di dove è arrivata la richiesta. Il demone è a posto e la porta è aperta.

La risposta viene instradata, non ricordata

Un client VPN che installa una rotta predefinita aggiunge una voce che supera il gateway LAN, per metrica o dividendo lo spazio in due metà più specifiche. I pacchetti in uscita scelgono ora l’interfaccia del tunnel. Il kernel non chiede mai da dove sia arrivato in origine il pacchetto a cui risponde. Questa unica omissione spiega ogni sintomo che segue.

La direzione di andata è instradata per destinazione, e così quella di ritorno. La risposta è indirizzata a un client pubblico, che il tunnel trasporterà volentieri. L’estremità remota riceve un pacchetto di cui non possiede l’origine, lo scarta, e il client originale attende fino allo scadere del tempo.

Il filtro rigoroso sul percorso inverso può scartare il pacchetto in ingresso prima ancora che il demone lo legga. Controlla prima quel contatore, perché uno scarto da filtro e un errore di routing sembrano identici dall’esterno.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

Il primo comando mostra quale rotta predefinita vince ora. Il secondo indica se il filtro rigoroso si applica globalmente o per interfaccia, e il terzo mostra qualsiasi regola della catena di inoltro che possa essere coinvolta.

Tre modi per conservare il percorso di ritorno

Escludere la destinazione del servizio dal tunnel è l’opzione più stretta. Una rotta host puntata al gateway LAN, più un demone legato all’indirizzo fisico invece che a ogni indirizzo, tiene quel singolo flusso fuori dal tunnel. La modifica è locale e facile da annullare.

Il routing basato su policy è la risposta generale. Una regola imperniata sull’indirizzo di origine o su un marchio del firewall seleziona una tabella la cui rotta predefinita punta al gateway WAN, mentre le connessioni proprie dell’host continuano a usare il tunnel. Mantieni la priorità esplicita perché la regola non venga oscurata più avanti.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

I primi due comandi costruiscono il percorso alternativo per le risposte con origine nell’indirizzo pubblico. Il terzo chiede al kernel quale percorso prenderebbero esattamente quella origine e quella destinazione, e così confermi che la regola abbia qualche effetto.

La traduzione di origine è la terza opzione e l’unica che sopravvive a un router che fa già NAT davanti al servizio. La risposta deve tornare a quel router, e il mascheramento verso l’interfaccia WAN lo ottiene nascondendo il client dai log del servizio. Sostituire a mano la rotta predefinita dopo la connessione è una diagnosi, perché il client riscrive la tabella alla riconnessione successiva.

Quando la macchina instrada anche per una LAN

Lo stesso guasto compare un salto più in là quando l’host instrada per i dispositivi dietro di sé. Una connessione in ingresso viene inoltrata a un dispositivo interno il cui unico percorso di ritorno è il tunnel, e la risposta raggiunge il client esterno dall’indirizzo del provider. Il dispositivo interno funziona correttamente per tutto il tempo.

Il tracciamento delle connessioni vede allora una risposta per un flusso che non ha mai registrato e la scarta. La traduzione di destinazione consegna la connessione in ingresso al dispositivo, e la traduzione di origine fa sembrare che la risposta provenga dal router stesso.

Una rotta policy che mantiene la porta inoltrata sulla WAN mentre il traffico proprio del router usa il tunnel è l’equivalente più pulito. Senza traduzione di origine la risposta è indirizzata al client esterno, e il dispositivo interno non ha alcuna rotta per quell’indirizzo.

Tre sonde che separano le cause

Esegui tre sonde: una connessione verso la macchina da internet, una connessione da essa verso un host pubblico e una risoluzione di nome. Quando le prime due discordano, il percorso di ritorno è colpevole. Quando i nomi falliscono in entrambe le direzioni, il resolver è un altro guasto che condivide solo il tunnel.

Correggi prima la questione del routing, poi guarda i nomi. Mescolare le due cose è il modo in cui un server funzionante viene incolpato per un resolver rotto.

Annota quale interfaccia nomina l’eccezione e tieni la configurazione sotto controllo di versione. Una regola scritta contro un’interfaccia rinominata dopo un aggiornamento passa oggi e fallisce dopo il prossimo riavvio.