Aprite la tabella di routing dopo la connessione e trovate un solo indirizzo instradato dal tunnel mentre la sottorete intorno continua ad andare al gateway locale. Quella voce è una rotta host: un indirizzo, abbinato da un prefisso di tutti uni. Conta perché le decisioni di routing usano il prefisso corrispondente più lungo, quindi un /32 può prevalere su un /24 o su una rotta predefinita senza cambiare né l’uno né l’altro. Se sia un’eccezione accurata o un’interruzione futura dipende da quale indirizzo nomina e da chi la mantiene.

Un indirizzo, una voce nella tabella

Una rotta host IPv4 porta un prefisso /32 e una rotta host IPv6 porta /128, il che significa che la voce può corrispondere esattamente a un indirizzo di destinazione. Nient’altro nella tabella si muove: la sottorete che la copre e la rotta predefinita restano dove erano. La voce stretta vince per quell’indirizzo perché il suo prefisso è più lungo, non perché è stata aggiunta dopo.

Questa proprietà rende una rotta host una buona eccezione e una cattiva abitudine. Due voci /32 che nominano la porta d’ingresso di un servizio non coprono il suo secondo indirizzo, il suo indirizzo IPv6 né l’indirizzo verso cui si trasferisce il mese prossimo. Una tabella piena di voci a indirizzo singolo non spiegate di solito significa che qualcuno ha continuato a rattoppare intorno a una decisione di sottorete invece di prenderla. Leggete prima la lunghezza del prefisso, poi chiedete cosa dovrebbe proteggere la voce.

Leggete la voce dal client verso l’esterno

Partite dalla macchina con il problema, perché lo stesso indirizzo può essere instradato diversamente su un portatile e sul gateway davanti a esso. Chiedete al kernel quale percorso sceglierebbe per l’indirizzo esatto che usa l’applicazione, invece di leggere la tabella dall’alto. La risposta include l’interfaccia e il salto successivo, che insieme sono la decisione.

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

Ripetete la query per la famiglia di indirizzi che l’applicazione sceglie davvero, perché un client può preferire IPv6 e aggirare in silenzio un’eccezione IPv4. Confrontate il risultato prima e dopo l’attivazione del tunnel, e conservate entrambi gli output. Quel confronto mostra se il client ha aggiunto la voce al momento della connessione o se era già lì.

Una voce persistente e una voce di runtime falliscono diversamente. Quella di runtime scompare con la sessione, mentre la persistente sopravvive a un riavvio e continua a inviare traffico a un gateway che non esiste più.

L’eccezione dell’estremità e la trappola della ricorsione

I client VPN di solito installano una rotta host verso l’indirizzo esterno del server attraverso il gateway originale prima di reindirizzare la rotta predefinita. Senza quella voce i pacchetti cifrati verrebbero inviati nel tunnel che stanno cercando di costruire, e la connessione andrebbe in loop finché non scade.

La trappola appare quando le sottoreti accettate del tunnel includono per caso quell’indirizzo dell’estremità, o quando un secondo profilo aggiunge poi una rotta più ampia. La voce dell’estremità perde allora contro un prefisso più lungo e la sessione crolla non appena inizia a far passare traffico. Scrivere l’indirizzo dell’estremità accanto alle sottoreti accettate è il modo meno costoso di notare la collisione prima degli utenti. Spiega anche perché lo stesso profilo funziona da una rete e fallisce da un’altra.

Verificate il percorso che l’applicazione usa davvero

Un ping riuscito al nome host è una prova debole quando l’applicazione si connette a un altro indirizzo o a un’altra famiglia. Verificate la combinazione esatta di indirizzo, famiglia, porta e interfaccia dalla macchina che esegue il client.

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

Se il percorso è sbagliato, decidete se il requisito è una rete o un indirizzo prima di modificare qualcosa. Un requisito di un solo indirizzo giustifica una rotta host con un commento e un responsabile; un servizio con indirizzi rotanti ha bisogno di routing basato sul dominio o di una decisione onesta di sottorete.

Rimuovete le voci che non corrispondono più a una destinazione reale e annotate quelle che conservate. Un /32 non spiegato è indistinguibile da un difetto tre mesi dopo, e la persona successiva lo cancellerà senza sapere da cosa dipendeva.

Articoli correlati