Le risposte della VPN Linux spariscono? Controllate rp_filter e la route

Le richieste lasciano la macchina, il peer VPN risponde e la risposta non arriva mai al socket. Il tunnel è attivo, i log del peer mostrano l'invio del pacchetto e nulla nell'applicazione spiega il silenzio. Su Linux uno dei sospetti abituali è il filtraggio del percorso inverso: un pacchetto IPv4 in ingresso può essere rifiutato quando la validazione della sorgente non concorda con la route che il kernel si aspetta per quella sorgente. Percorrerlo in ordine vi dice se è la causa o una coincidenza. Vi evita anche di disattivare un controllo di sicurezza per riparare una route mancante.

Cosa decide la validazione della sorgente

Il kernel verifica se l'indirizzo di origine di un pacchetto è plausibile per l'interfaccia da cui è arrivato, consultando la tabella di instradamento per una route di ritorno verso quella sorgente. Se la route inversa punta altrove, il pacchetto può essere scartato prima che qualsiasi regola del firewall o socket dell'applicazione lo veda. Quel controllo esiste per rendere più difficili certi schemi di spoofing, ed è anche il motivo per cui le progettazioni asimmetriche e instradate per policy lo incontrano, mentre ogni client ordinario sulla stessa rete funziona bene. I client ordinari hanno un instradamento simmetrico, che è esattamente ciò che il controllo presuppone.

La parola importante è plausibile. Il pacchetto può essere del tutto legittimo e fallire comunque il controllo, perché non è la legittimità a essere verificata.

Leggete la modalità effettiva, non un solo campo

Esistono tre modalità: disattivata, rigorosa e permissiva. La rigorosa impone un'aspettativa di route diversa dalla permissiva, e l'impostazione globale interagisce con quelle per interfaccia, quindi leggere un solo file può descrivere male ciò che è realmente in vigore. Leggete entrambi, e leggeteli sull'interfaccia che riceve la risposta, non su quella della route predefinita.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

La ricerca della route in quella terza riga è la parte che la gente salta. Vi dice cosa il kernel ritiene della sorgente, ed è esattamente l'input del controllo.

Trovate la discrepanza prima di cambiare il controllo

Stabilite perché la risposta arriva su quell'interfaccia e se la sua route inversa dovrebbe essere diversa. Una regola di policy che manda le richieste su un percorso mentre le risposte tornano su un altro è una progettazione legittima, ed è anche la progettazione che la validazione rigorosa rifiuta. I mark usati nell'instradamento per policy possono contare anche qui, perché cambiano ciò che la ricerca inversa restituisce.

Se la route inversa manca semplicemente, aggiungerla corregge la causa invece di disattivare un controllo. Una route mancante, un rifiuto del firewall e un selettore di traffico errato producono lo stesso sintomo visibile, e solo uno di essi riguarda la validazione della sorgente.

Non disattivate i controlli della sorgente a livello globale come prima reazione. Questo scambia una diagnosi precisa con un cambiamento di comportamento ampio che dovrete ricordare più avanti.

Una regolazione selettiva che potete difendere

Se una regolazione ristretta è davvero necessaria, limitatela all'interfaccia che ne ha bisogno, annotate il perché e mettetela nella configurazione che possiede quell'interfaccia, così sopravvive a un riavvio. Poi verificate di nuovo esattamente il flusso che ha fallito, dalla stessa sorgente alla stessa destinazione, invece di un ping a qualcosa di comodo.

Includete un caso che dovrebbe ancora essere rifiutato. Se quel caso ora riesce, la regolazione ha indebolito più dell'unico percorso che volevate riparare.

Tenete separati IPv4 e IPv6

Un sysctl dall'aspetto familiare non è una policy per ogni famiglia di indirizzi. IPv6 ha un proprio comportamento e proprie impostazioni, e una macchina può essere rigorosa su una famiglia e permissiva sull'altra senza che nessuno lo noti finché una destinazione specifica non fallisce. Controllate entrambe se il carico di lavoro usa entrambe.

Registrate la modalità, l'interfaccia, l'output della ricerca della route e il motivo della modifica in un unico posto. La persona successiva troverà l'impostazione e nessuna spiegazione, e o la rimuoverà o la copierà dove non appartiene.