Perché una rotta VPN ampia rompe alcuni siti pubblici

La maggior parte delle pagine carica, due o tre vanno in timeout e il browser dà la colpa alla connessione. I siti che falliscono hanno qualcosa in comune che quelli funzionanti non hanno: i loro indirizzi risolti cadono dentro un prefisso installato dalla VPN. Una rotta abbastanza ampia da coprire un intervallo pubblico catturerà traffico che il tunnel non doveva mai trasportare, e il sintomo sembra un problema del sito invece di una decisione di routing.

Risolvi il nome che fallisce, poi guarda la tabella di routing invece del browser.

Confronta l'indirizzo, non il nome del sito

Cerca l'indirizzo che il client ha realmente provato, poi controlla quale rotta vi corrisponde. Una destinazione dentro 45.61.20.10 cade sotto 45.0.0.0/8 se quel prefisso è presente, anche se il sito stesso non ha nulla a che fare con il tunnel. Confrontare l'indirizzo che fallisce con i prefissi installati è un problema di sottrazione, non un indovinello.

Windows può rispondere a entrambe le metà direttamente, e una ricerca mostra quale interfaccia e quale salto successivo hanno vinto la selezione. Risolvi il nome due volte se il sito restituisce più indirizzi. Annota ciascuno con la rotta che corrispondeva. Indirizzi diversi possono produrre risposte diverse, e solo uno di essi può essere il caso che fallisce.

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

Leggi il prefisso corrispondente più specifico, non la prima riga che sembra familiare. Una rotta presente nella tabella non dimostra di aver vinto la ricerca; lo fa la corrispondenza più lunga. Due prefissi possono corrispondere a un indirizzo, e solo uno riceve il pacchetto. Il perdente resta nella tabella e sembra altrettanto reale in un elenco.

Annota il prefisso, la sua interfaccia e l'indirizzo risolto. Quei tre valori sono tutta la diagnosi.

Scopri chi ha installato la rotta

Le rotte arrivano da quattro luoghi: il profilo VPN nativo, un criterio di gestione, uno script di connessione o un client completamente diverso. Eliminare la voce attiva può confermarne la rilevanza, ma la connessione successiva la ricrea dalla configurazione salvata, quindi è l'origine che deve cambiare.

Controlla prima l'elenco delle rotte del profilo, poi il criterio di gestione, poi qualsiasi script eseguito alla connessione. Quest'ordine corrisponde alla frequenza con cui ciascuno risulta responsabile. Mantiene anche la modifica su uno strato invece di tre.

Leggi con attenzione il comportamento nativo basato sulle classi

I profili nativi di Windows hanno un'impostazione documentata, NativeProfile/DisableClassBasedDefaultRoute, che controlla una rotta automatica dedotta dall'indirizzo dell'interfaccia. Un indirizzo di profilo che inizia con 45 può produrre una voce 45.0.0.0/8 con questo comportamento, ed è così che un solo indirizzo pubblico cattura un intero intervallo di classe A.

Il nome della proprietà invita a una lettura errata: impostarla su true disattiva l'inferenza, e false la attiva. Non è nemmeno lo stesso oggetto di una rotta predefinita, e non governa i client di terze parti che installano i propri prefissi.

Se l'inferenza è la causa dimostrata, correggi il profilo tramite il suo proprietario di gestione e fornisci esplicitamente i prefissi privati previsti. Se uno script ha aggiunto la voce, ripara lo script. Sostituire una rotta ampia inspiegata con un'altra cambia il sintomo senza rispondere alla domanda.

Ripara l'origine, poi ricontrolla entrambi i percorsi

Dopo la modifica, riconnettiti e ripeti la ricerca per un sito pubblico che fallisce e per una risorsa che deve usare il tunnel. Il primo dovrebbe ora risolversi sull'interfaccia fisica, e il secondo dovrebbe ancora selezionare la VPN. Non fermarti al primo successo; una correzione che rompe anche l'accesso privato ha scambiato un guasto con un altro.

Esamina allo stesso tempo il piano degli indirizzi del server. Un pool che si sovrappone allo spazio pubblico causa questa classe di problema ancora e ancora. Un intervallo scelto di proposito dall'operatore merita un'altra conversazione, non una rinumerazione automatica.

Aumentare l'MTU o svuotare il DNS non correggerà un prefisso che dirige ancora quell'indirizzo nel tunnel. Verifica prima la selezione, poi il percorso.