Perché un client VPN sulla LAN dell’ufficio perde ogni risposta

Un portatile sta sulla /24 dell’ufficio via Ethernet e si unisce anche a un server OpenVPN che vive in quella stessa /24. Un collega fa ping all’indirizzo del tunnel; la richiesta arriva chiaramente e non torna nulla. Il log del tunnel è pulito e la navigazione funziona ancora, quindi il tunnel è il sospetto sbagliato. La validazione della sorgente IPv4 sulla macchina che riceve getta il pacchetto prima che qualcosa lo legga.

Lo scarto avviene prima che qualcosa legga il pacchetto

La validazione della sorgente pone una domanda su ogni pacchetto in entrata: se questo host rispondesse a quella sorgente, la risposta uscirebbe dall’interfaccia da cui il pacchetto è appena arrivato? Quando la risposta è no, il kernel getta il pacchetto all’arrivo. Né un socket né un percorso di inoltro lo vedono mai, ed è per questo che una cattura sul tunnel registra ancora una richiesta che l’applicazione non riceve mai.

Il client qui tiene 10.66.0.9 sul suo tunnel, e il server OpenVPN risponde a 192.168.80.10 dentro il prefisso dell’ufficio. Un collega a 192.168.80.25 fa ping all’indirizzo del tunnel, così la richiesta attraversa la LAN, il server la instrada nel tunnel, e arriva sull’interfaccia tunnel del client portando un indirizzo sorgente dell’ufficio. Nella tabella di routing di quella macchina il prefisso dell’ufficio appartiene al dispositivo Ethernet, non al tunnel. La validazione confronta l’interfaccia di arrivo con la rotta, trova una discrepanza e scarta il pacchetto, così il collega vede una perdita totale mentre entrambe le estremità riportano un tunnel sano.

La direzione a specchio ha la stessa forma: quando il client inizia verso l’ufficio, le risposte possono essere scartate sul lato ufficio per lo stesso motivo. Una correzione verificata solo in una direzione tende a tornare come un secondo ticket.

Dimostrate il modo in vigore prima di toccare un sysctl

Leggete i valori effettivi invece di fidarvi di un valore predefinito della distribuzione, perché l’impostazione per interfaccia è solo metà della decisione. Il modo in vigore è il maggiore tra il valore dell’interfaccia e il valore di all, quindi uno zero sull’interfaccia del tunnel non significa nulla finché all vale uno. La decisione del modo rigoroso è una decisione di routing, quindi eseguite la ricerca che esegue il kernel e confrontate la sua risposta con l’interfaccia da cui il pacchetto è realmente arrivato.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Poi ripetete il ping osservando il contatore degli errori. Un conteggio che sale accanto a una richiesta che la cattura già mostra è la firma di questo scarto, non di una rotta assente. Attivate la registrazione dei pacchetti marziani mentre siete lì, così il kernel nomina la sorgente e l’interfaccia che ha rifiutato. Insieme escludono la cifratura, il firewall e un iroute mancante come spiegazioni.

Annotate la linea di base prima di cambiare qualsiasi cosa: entrambi i valori, il dispositivo scelto dalla ricerca e il contatore che avete osservato. È quella registrazione a dirvi poi se la modifica ha fatto ciò che pensate.

Che cosa accetta davvero ogni modo di rp_filter

Il kernel espone tre valori per interfaccia, e non sono tre sfumature di una stessa regola. Zero disattiva il controllo. Uno è rigoroso e richiede che la sorgente sia instradata di nuovo fuori dall’interfaccia di arrivo. Due è lasso e richiede solo che esista una qualche rotta verso la sorgente nella tabella, dovunque punti.

La riga che conta qui è quella lassa, e ciò che continua a rifiutare. Una sorgente falsificata instradabile ovunque nella vostra tabella passa, mentre una sorgente senza alcuna rotta viene ancora rifiutata. Su un portatile è una concessione stretta; su un router che inoltra traffico per altri è ampia. Il modo appartiene all’host, quindi lo stesso numero porta un peso diverso nei due luoghi.

Quale riga serva a questa topologia deriva dalla tabella e non dall’abitudine. Il pacchetto è legittimo e la sua sorgente è instradabile, quindi il lasso lo accetta e il rigoroso no. Nulla nel caso richiede zero, e scegliere zero toglierebbe un controllo che qui non costa nulla.

Scegliete la modifica più piccola che elimina l’ambiguità

Il modo lasso è la modifica più piccola che si adatta, ed è una vera riduzione del rigore, non un interruttore innocuo. Esiste un’opzione migliore ogni volta che la topologia lo permette: eliminate la sovrapposizione e l’ambiguità sparisce.

Dove il prefisso dell’ufficio serve solo via Ethernet, toglietelo dalle rotte che il profilo tira e l’indirizzo diventa raggiungibile per un solo percorso. Quando i due percorsi devono davvero coesistere, fissate la sorgente e il dispositivo con una regola di policy invece di allentare la validazione su ogni interfaccia. Così si mantiene un filtraggio rigoroso per tutto il resto della macchina e si documenta l’eccezione dove il prossimo tecnico la cercherà.

Qualunque percorso scegliate, registratelo in un drop-in di sysctl e non in un comando vivo. Impostate le chiavi all e default insieme, così una riconnessione non può ripristinare in silenzio il modo rigoroso.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Che cosa cede il modo lasso, e dove

Il modo lasso rifiuta ancora una sorgente che nessuna rotta potrebbe raggiungere, e smette di rifiutare una sorgente falsificata che risulta instradabile. Su un portatile è una concessione stretta. Su un dispositivo che inoltra traffico che non possiede, la stessa scelta è molto più ampia. Lo stesso parametro porta quindi due significati molto diversi a seconda di dove gira.

Spegnere del tutto il controllo su un host che inoltra traffico per altre persone è l’unica riparazione da evitare. Zero getta via la validazione che il modo lasso custodisce con cura. Se l’host inoltra per altri, sostenete invece l’opzione della regola di policy della sezione precedente.

Lasciate una nota che nomini le due interfacce, il prefisso sovrapposto e la sonda esatta che ora riesce. È più utile al prossimo tecnico di una riga che dice che il filtraggio è stato regolato.