Salto successivo in una rotta VPN: perché il gateway deve essere raggiungibile localmente

Una rotta verso una rete VPN porta due indirizzi facili da confondere: il prefisso di destinazione che il pacchetto cerca di raggiungere e il salto successivo che lo avvicina di un passo. Su un host LAN, quel salto successivo deve essere un router che riuscite davvero a raggiungere sullo stesso collegamento. L’indirizzo VPN remoto non è un salto successivo, per quanto bene si adatti alla destinazione che avete in mente.

Questo manuale copre il caso ordinario: un portatile su 192.168.20.0/24, un gateway VPN con indirizzo LAN 192.168.20.5 e una rete remota 10.70.0.0/24 dietro quel gateway. Tutti i comandi seguenti presuppongono che siate sul portatile, salvo diversa indicazione.

Due indirizzi, una rotta

La voce prevista è 10.70.0.0/24 via 192.168.20.5. Il prefisso dice dove va il pacchetto; l’indirizzo via dice chi lo porta lì. Il kernel rifiuta di installare una rotta di cui non riesce a raggiungere il gateway attraverso l’interfaccia che indicate, e quel rifiuto è tutto il punto: un salto successivo che ha bisogno del tunnel per essere raggiungibile non può essere il salto successivo che costruisce il tunnel.

Quindi il primo controllo non è «il gateway funziona» ma «il gateway è su questo collegamento». La sottorete del portatile, la sua voce ARP o di vicino e l’interfaccia nella rotta devono concordare. Un indirizzo che esiste solo dentro 10.70.0.0/24 può essere la destinazione di una seconda rotta, mai l’indirizzo via della prima.

A che cosa il salto successivo vincola il gateway

Installare la rotta sul portatile decide solo la prima consegna. Poi il gateway ha bisogno del proprio percorso: inoltro attivo, una rotta di tunnel per 10.70.0.0/24 e qualsiasi politica di accesso che stabilisca chi può usarla. Su Linux è net.ipv4.ip_forward=1 più una rotta di tunnel; un firewall davanti ha bisogno di una regola che consenta il flusso inoltrato.

La direzione di ritorno è la parte che la gente dimentica. Il lato remoto deve avere una rotta di ritorno verso 192.168.20.0/24, oppure il progetto deve tradurre l’origine del portatile in qualcosa che il lato remoto conosce. Un ping che funziona dal gateway dimostra che il gateway raggiunge la rete remota; non dice nulla sulla sopravvivenza dei pacchetti del portatile nel viaggio di ritorno.

Verificate la ricerca dall’host che invia

Chiedete al kernel quale salto successivo sceglierebbe e leggete l’interfaccia nella risposta:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Se la ricerca riporta il gateway e l’interfaccia LAN, il primo tratto è configurato come previsto. Se riporta il dispositivo di tunnel, qualcosa più in alto nella tabella è più specifico e vince. Se la rotta non si installa affatto, il kernel vi sta dicendo che il gateway non è raggiungibile, e quel messaggio è più utile di qualsiasi cattura di pacchetti.

Poi ripetete il test dal posto giusto. Una richiesta creata sul gateway usa l’indirizzo di origine del gateway stesso, il che può nascondere una rotta di ritorno mancante o una politica che consente solo certe origini. Il manuale di ip-route separa la destinazione, il gateway e la deroga onlink, e la deroga vale la pena di essere capita prima di usarla.

Non usate onlink per fingere raggiungibilità

onlink dice al kernel di saltare il controllo di raggiungibilità di un gateway e di inviare comunque. Non crea un percorso, non risolve l’ARP per un indirizzo che non c’è e non fa rispondere un router remoto sul vostro segmento Ethernet. È legittimo per gateway che rispondono ma non stanno in una sottorete connessa, ed è una trappola quando serve a tacitare un errore che non avete spiegato.

Se la rotta si installa solo con onlink, la domanda successiva è perché il gateway non sia dove pensate. Una VLAN sbagliata, un secondo indirizzo sull’interfaccia sbagliata o un refuso nell’ultimo ottetto producono tutto questo, e ciascuno di essi rompe anche il percorso di ritorno appena il traffico inizia a fluire.

I tunnel punto a punto non sono Ethernet

Un dispositivo di tunnel non fa ARP e spesso non ha una sottorete di vicini sensata. Le sue rotte somigliano spesso a 10.70.0.0/24 dev tun0, senza alcun via, perché il peer è l’unico altro estremo. Copiare un via in stile LAN in quella tabella produce una rotta che il kernel può rifiutare o, peggio, una che punta a un indirizzo a cui il peer non risponde mai.

Tenete separati i due modelli nel manuale: una rotta LAN ha un gateway raggiungibile, una rotta di tunnel ha un’interfaccia e un peer. WireGuard, OpenVPN e IPsec espongono forme leggermente diverse, quindi annotate la forma che avete davvero usato invece di generalizzare da un solo host.

Aggiungete, confermate, tornate indietro

L’intera modifica sono tre comandi e un controllo, e andrebbe scritta in quest’ordine:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Confermate il percorso, confermate una destinazione, poi tenete pronta la riga di cancellazione nel caso la modifica renda l’host irraggiungibile in un modo che non avevate previsto. Se la rotta deve sopravvivere a un riavvio, mettetela nella configurazione di rete dell’host e non in un profilo della shell, e provate il riavvio prima di contarci. Una rotta che esiste solo nella shell che l’ha aggiunta è una rotta che farete il debug due volte.