Il client VPN instradato raggiunge il server ma non gli host della LAN

Il tunnel sale, il client esegue il ping del server VPN, e una condivisione su una macchina a un salto di distanza non risponde mai. Nulla nella configurazione del client lo spiega, perché la richiesta ha davvero lasciato il client ed è davvero arrivata. Ciò che è fallito è il viaggio di ritorno, e il dispositivo che ha fallito è di solito il gateway della LAN e non l’host VPN. Tracciare il pacchetto di risposta spiega tutta questa classe di sintomi.

Seguite la risposta, non la richiesta

Il server VPN decifra il pacchetto del client e lo inoltra alla LAN con l’indirizzo del client ancora nel campo di origine. L’host di destinazione risponde a quell’indirizzo, e ora la sua tabella di routing decide tutto. Il suo gateway predefinito non sa nulla del pool del tunnel, quindi la risposta esce verso il provider internet e viene scartata da qualche parte lungo quel percorso.

Sul client il sintomo è un timeout silenzioso: nessun rifiuto, nessun reset, solo nulla. La navigazione di una condivisione si blocca, il ping segnala che non c’è risposta, e i log del server sembrano sani perché il server ha fatto il suo lavoro.

Mettete la rotta di ritorno dove guardano gli host

Ogni host della LAN consulta il proprio gateway predefinito, quindi il gateway è l’unico dispositivo che deve sapere dove si trova il pool del tunnel. Aggiungete lì una rotta statica e ogni host eredita il percorso corretto senza essere toccato.

Se il gateway distribuisce il proprio indirizzo come opzione DHCP, distribuite la rotta in quel modo così le nuove macchine la prendono automaticamente. Altrimenti la rotta vive in un file di configurazione e scompare alla successiva ricostruzione.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Perché il NAT di origine sembra ripararlo

Mascherare il pool di client dietro l’indirizzo del server VPN elimina il problema eliminando l’indirizzo del client dal pacchetto. Le risposte tornano allora al server, che sa già come raggiungere il tunnel, e tutto funziona. Il costo è che gli host interni non possono più vedere chi è il client, e ogni connessione sembra provenire da un’unica macchina.

Quello scambio a volte è corretto, per esempio quando a un dispositivo di un fornitore non si può assegnare una rotta statica. Non rendete la regola più ampia del pool attuale, perché una regola scritta per un /24 smette di corrispondere il giorno in cui il pool viene rinumerato in un /16, e il primo segno è un gruppo di nuovi client che si collegano e non raggiungono nulla.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Il percorso cloud richiede tre impostazioni

In una VPC la stessa lacuna torna in un’altra forma, perché la sottorete non ha alcuna rotta per l’intervallo dei client. La tabella di routing ha bisogno di una voce per il pool del tunnel che punti all’interfaccia di rete dell’istanza, e l’interfaccia deve avere il controllo di origine e destinazione disattivato perché la piattaforma accetti pacchetti la cui origine non è il proprio indirizzo. Anche i gruppi di sicurezza e le ACL di rete devono ammettere il pool in entrambe le direzioni.

Ogni omissione produce un guasto parziale distinto. Saltate la voce della tabella di routing e le istanze private rispondono in una sottorete che non può portare la risposta al pool. Con il controllo ancora attivo, la piattaforma scarta la risposta dopo che l’istanza l’ha già inviata. Senza la regola del gruppo di sicurezza, la richiesta stessa non arriva mai, e il client vede il timeout uno strato prima.

Eseguite i controlli in questo ordine

Confermate l’inoltro e la politica di filtraggio prima di dare la colpa al routing, perché un host che non inoltrerà fallisce nello stesso modo silenzioso. Poi leggete l’impostazione effettiva del percorso inverso sull’interfaccia che porta il tunnel, dato che un filtro severo può scartare risposte che arrivano da una direzione inattesa.

Chiudete con una cattura presa sull’host della LAN mentre il client lo pinga. Una richiesta che arriva senza risposta corrispondente prova il percorso di ritorno, e una richiesta che non arriva mai sposta la colpa al server o al tunnel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Il controllo di origine e destinazione è documentato nella guida dell’interfaccia di rete elastica. Impostatelo sull’interfaccia che porta davvero il traffico del tunnel, non su un adattatore non correlato collegato alla stessa istanza.