Perché una sottorete continua a evitare la route predefinita della VPN

Passi la VPN a tunnel completo, la maggior parte del traffico obbedisce, e poi un indirizzo risponde direttamente — una stampante, un NAS, un jump host su 10.x. La lettura ovvia è che il tunnel perde, quindi abbassi la metrica sulla route predefinita e non cambia nulla. Quel tentativo fallito è l’indizio: una route predefinita è un ripiego, non un verdetto. La ricerca della route prende il prefisso corrispondente più lungo prima ancora di confrontare le metriche, quindi una /24 continua a vincere su una /0 qualunque numero tu attacchi a una delle due. Una volta chiaro quest’ordine, la fuga di solito è una route che qualcuno ha installato di proposito, o un prefisso che il client non ha mai inteso coprire.

Cosa promette davvero una route predefinita

0.0.0.0/0 corrisponde a ogni destinazione IPv4 con zero bit di specificità. Esiste perché un host possa raggiungere qualsiasi cosa la sua tabella non descriva meglio. Una route verso 192.168.1.0/24 porta 24 bit corrispondenti, quindi per 192.168.1.40 vince prima che qualcuno confronti metriche, distanza amministrativa o come il client chiami il suo campo di priorità. La stessa regola vale nella FIB di Linux, nella tabella di routing di Windows e nello stack BSD dietro macOS.

Su una LAN normale quel comportamento è una funzione. La sottorete locale è collegata direttamente, la stampante continua a funzionare mentre il tunnel porta la tua navigazione, e nulla è configurato male. La domanda che vale la pena porsi non è perché quell’indirizzo vada diretto, ma quale prefisso in quale tabella vi corrisponda, e chi ce l’ha messo.

Semi-route predefinite, o perché la voce predefinita può sembrare intatta

L’esempio più pulito è redirect-gateway def1 di OpenVPN. Invece di eliminare la route predefinita e sostituirla, aggiunge 0.0.0.0/1 e 128.0.0.0/1. Insieme la coppia copre tutto IPv4, ogni prefisso è più lungo di /0, ed entrambe battono la route predefinita del router lasciandola al suo posto. Esegui un elenco delle route dopo e la route predefinita originale è ancora lì, punta ancora al tuo gateway; semplicemente non viene mai scelta per le destinazioni internet.

Il wg-quick di WireGuard ottiene lo stesso risultato tramite routing basato su policy. Quando AllowedIPs copre 0.0.0.0/0 crea la propria tabella, vi invia i pacchetti marcati e aggiunge una regola che ignora il prefisso di lunghezza zero della tabella principale. La tabella principale conserva la sua voce predefinita, e le regole decidono che la tabella del tunnel viene consultata per prima per il traffico che l’interfaccia possiede.

Entrambi i progetti necessitano di esattamente una route fuori dal tunnel: una route host verso l’indirizzo del server VPN stesso attraverso il gateway originale. Senza di essa il client cercherebbe di portare dentro il tunnel i pacchetti che costruiscono il tunnel, e la connessione non si completerebbe mai. Una route non-tunnel nella tua tabella è quindi normale anche su un profilo rigoroso a tunnel completo. Le route che vale la pena mettere in dubbio sono quelle che coprono destinazioni che ti interessano davvero.

Le metriche decidono i pareggi, i prefissi decidono i vincitori

Le metriche si confrontano solo tra candidati che corrispondono altrettanto bene alla destinazione. Su Linux, ip route get 10.20.5.9 stampa il vincitore insieme alla sua tabella, e ip route show table all elenca i candidati, comprese eventuali semi-route predefinite e qualsiasi tabella a cui una regola punti. Su Windows, Find-NetRoute -RemoteIPAddress 10.20.5.9 restituisce la route selezionata e l’indirizzo di origine, mentre Get-NetRoute mostra la tabella grezza — ma il costo effettivo è la metrica della route più la metrica dell’interfaccia, quindi un adattatore lento può perdere un pareggio che sembra vincere.

Tre casi coprono la maggior parte di ciò che vedrai:

• Stessa destinazione, /24 contro /0: la /24 vince sulla lunghezza del prefisso, qualunque cosa dicano le metriche.
• Stessa destinazione, due /24 con metriche diverse: vince la metrica effettiva più bassa.
• Stessa destinazione, due tabelle, una scelta da una regola di policy: la regola sceglie prima la tabella, e il confronto dei prefissi avviene al suo interno.

Il terzo caso è dove finisce la maggior parte di questi resoconti. Una ip rule di Linux o un filtro del traffico VPN di Windows può inviare traffico a una tabella che non ha mai contenuto la route predefinita del tunnel, e la tabella principale sembra perfetta tutto il tempo.

Chi possiede di solito l’aggiramento

Inizia dal profilo, non dalla tabella. Le configurazioni split-tunnel e le impostazioni VPN per app lasciano deliberatamente prefissi denominati fuori dal tunnel; un profilo di lavoro che protegge una sottorete privata e lascia che la navigazione generale vada diretta si comporta come progettato, e sovrascriverlo rompe la policy che doveva applicare. La guida al routing VPN di Microsoft traccia la stessa linea tra traffico forzato nel tunnel ed eccezioni esplicite, il che la rende un utile controllo incrociato prima di modificare qualsiasi cosa.

Poi cerca i residui. Una route che punta a un’interfaccia che non esiste più, o a un indirizzo della rete precedente, compare dopo che docking station, adattatori USB e bridge per container vanno e vengono. Eliminarla una volta non è la fine: i profili di connessione di NetworkManager, i file netplan e le route persistenti di Windows la reinstallano alla connessione o all’avvio successivo, quindi trova il file o il profilo che la possiede prima di modificare qualsiasi cosa.

Poi controlla IPv6 separatamente. ip -6 route e Get-NetRoute -AddressFamily IPv6 mantengono stato separato, route predefinite separate e comportamento client separato. Un controllo solo IPv4 non dice nulla su un host dual-stack che preferisce in silenzio un percorso IPv6 nativo, e questo da solo può far sembrare un client in split-tunnel.

Conferma con il flusso dell’applicazione stessa

Registra la destinazione che l’applicazione usa davvero, poi chiedi al sistema il percorso che prenderebbe dall’indirizzo di origine a cui quell’applicazione si lega. ip route get 10.20.5.9 from 192.168.1.40 risponde su Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 più l’indirizzo locale lo fa su Windows. Confronta il risultato con ciò che il profilo afferma. La pagina dell’IP pubblico di un browser testa una destinazione su un protocollo e non dice nulla sull’indirizzo privato che ha iniziato la lamentela.

Correggi l’oggetto più stretto che spiega la differenza. Se l’eccezione è approvata, annota il prefisso e lascialo stare; se non lo è, rimuovi la route o aggiungi una route esplicita più stretta attraverso il tunnel invece di abbassare la metrica della predefinita. Abbassare una metrica non può superare un prefisso più lungo, e modificare la predefinita mentre due route /1 possiedono il percorso internet non cambia nulla comunque.

Poi ricollega il tunnel e ripeti la stessa interrogazione. I client reinstallano le route a ogni connessione, quindi una modifica che sopravvive solo fino al prossimo handshake non è stata testata. Se il percorso diverge ancora, i sospetti rimanenti sono una regola di policy, una seconda tabella o un filtro lato client — non la route predefinita.

• Nomina la destinazione e l’indirizzo di origine che l’app usa davvero.
• Stampa la route vincente con ip route get o Find-NetRoute.
• Controlla se una coppia /1 o una tabella di policy possiede il percorso internet.
• Elenca ogni prefisso più lungo di /0 che corrisponde alla destinazione.
• Ripeti il controllo IPv6 separatamente.
• Ripercorri la route sopravvissuta fino al file, al profilo o al filtro che la installa.
• Ricollega e riesegui l’interrogazione prima di dichiararla risolta.

Se tutti e sette concordano con il profilo, il tunnel fa esattamente ciò per cui è stato configurato, e la correzione appartiene al profilo, non a una metrica.