Routing ricorsivo: quando il tunnel cattura i propri pacchetti

Il tunnel sale, il registro mostra uno handshake completato e un secondo dopo la stessa sessione muore e si riconnette in loop. Quello schema ha una causa precisa: la rotta verso il server ora punta dentro il tunnel, quindi i pacchetti che trasportano il tunnel vengono inviati attraverso il tunnel. Nulla è cambiato nell’autenticazione, ed è per questo che reinserire le credenziali non cambia niente. Confrontate il percorso esterno prima e dopo il cambio di rotta e la ricorsione diventa visibile.

Controllate prima il percorso esterno

Ci sono due pacchetti in gioco, non uno. Il pacchetto interno appartiene all’applicazione e dovrebbe essere cifrato, mentre il pacchetto esterno è indirizzato al server e deve raggiungerlo lungo un percorso che non dipende dal tunnel.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Chiedete al kernel la rotta verso l’indirizzo del server dopo che il tunnel è attivo, e di nuovo dopo che è cambiata la rotta predefinita. Un salto successivo che finisce sul dispositivo del tunnel è la ricorsione, ed è visibile senza alcuna cattura di pacchetti. Un binding all’interfaccia, i marcatori o uno spazio dei nomi di rete possono rendere incompleta una semplice interrogazione, quindi usate il contesto che usa il client stesso. Quando la risposta sembra corretta ma la sessione continua a girare in loop, leggete le regole della politica di routing e non solo la tabella principale.

Perché la sessione sopravvive un istante

Lo handshake si completa prima che venga installata la nuova rotta, quindi i primi secondi sembrano sani. Appena il client aggiunge la rotta predefinita, il pacchetto esterno successivo la segue nell’interfaccia attraverso cui quel pacchetto deve viaggiare. Il server non vede nulla, il client ritrasmette e il tentativo o scade o uccide la sessione e ricomincia.

Quest’ordine spiega perché un tunnel può funzionare su un portatile e fallire su un router, e perché il guasto spesso inizia quando parte il traffico e non al momento della connessione. Spiega anche il loop: ogni riavvio ristabilisce la sessione prima che la rotta lo renda impossibile.

Trovate a chi appartiene l’eccezione dell’endpoint

I client supportati predispongono la propria eccezione: una rotta host verso il server attraverso il gateway originale, o un marcatore che tiene il socket esterno fuori dal tunnel. La domanda è se qualcos’altro l’abbia rimossa o scavalcata.

Per IPsec basato sulle rotte, esaminate i selettori di politica che decidono quali pacchetti entrano nel tunnel e confermate che l’indirizzo del peer ne sia escluso. Per WireGuard, il marcatore del firewall dell’interfaccia e le sue regole di politica tengono i pacchetti di trasporto fuori dal tunnel, quindi una rotta predefinita aggiunta a mano può rompere quell’assetto. Un secondo profilo VPN o uno script di gestione che riscrive la rotta predefinita è un colpevole frequente. Le regole di bypass ampie aggiunte una alla volta sono il risultato abituale, e trasformano un bug di routing in una tabella che nessuno riesce a mantenere.

Ricontrollate dopo un cambio di rete

Una rotta host attraverso un gateway Wi-Fi è corretta finché la macchina non passa a un’altra rete. Allora lo stesso sintomo ritorna senza alcun cambio di configurazione.

Annotate l’indirizzo dell’endpoint, la rotta prima e dopo la connessione e l’interfaccia usata da ciascuna. Questi tre fatti di solito separano un bug del client da uno scavalcamento, e sopravvivono alla persona che li ha raccolti.

Riconnettetevi sulla nuova rete e ripetete la lettura. Se l’eccezione manca di nuovo, la correzione appartiene al profilo che la possiede, non a un comando una tantum digitato durante un guasto.