Varför en bred VPN-rutt bryter några offentliga webbplatser
Några webbplatser misslyckas medan resten laddas, eftersom ett brett prefix fångar deras adresser. Matcha rutten mot den uppslagna adressen och ta sedan reda på vem som installerar den.
De flesta sidor laddas, två eller tre tar timeout, och webbläsaren skyller på anslutningen. Webbplatserna som misslyckas har något gemensamt som de fungerande inte har: deras uppslagna adresser hamnar inom ett prefix som VPN:en installerade. En rutt som är bred nog att täcka ett offentligt område fångar trafik som tunneln aldrig var avsedd att bära, och symptomet ser ut som ett webbplatsproblem i stället för ett routingbeslut.
Slå upp namnet som misslyckas och titta sedan på routingtabellen i stället för webbläsaren.
Jämför adressen, inte webbplatsens namn
Slå upp adressen klienten faktiskt försökte och kontrollera sedan vilken rutt som matchar den. Ett mål inom 45.61.20.10 hamnar under 45.0.0.0/8 om det prefixet finns, även om webbplatsen själv inte har något med tunneln att göra. Att jämföra den misslyckade adressen med de installerade prefixen är en subtraktionsuppgift, inte en gissning.
Windows kan svara på båda halvorna direkt, och en uppslagning visar vilket gränssnitt och vilket nästa hopp som vann urvalet. Slå upp namnet två gånger om webbplatsen returnerar flera adresser. Anteckna var och en med rutten som matchade. Olika adresser kan ge olika svar, och bara en av dem är kanske det misslyckade fallet.
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
Läs det mest specifika matchande prefixet, inte den första raden som ser bekant ut. En rutt i tabellen bevisar inte att den vann uppslagningen; det gör den längsta träffen. Två prefix kan matcha en adress, och bara en av dem tar emot paketet. Förloraren stannar i tabellen och ser lika verklig ut i en lista.
Anteckna prefixet, dess gränssnitt och den uppslagna adressen. De tre värdena är hela diagnosen.
Ta reda på vem som installerade rutten
Rutter kommer från fyra ställen: den inbyggda VPN-profilen, en hanteringspolicy, ett anslutningsskript eller en helt annan klient. Att ta bort den levande posten kan bekräfta dess relevans, men nästa anslutning återskapar den från den sparade konfigurationen, så källan är det som måste ändras.
Kontrollera profilens ruttlista först, sedan hanteringspolicyn, sedan alla skript som körs vid anslutning. Den ordningen stämmer med hur ofta var och en visar sig ansvarig. Den håller också ändringen i ett lager i stället för tre.
Läs det inbyggda klassbaserade beteendet noggrant
Inbyggda Windows-profiler har en dokumenterad inställning, NativeProfile/DisableClassBasedDefaultRoute, som styr en automatisk rutt som härleds från gränssnittsadressen. En profiladress som börjar med 45 kan under det beteendet skapa en post 45.0.0.0/8, och så fångar en enda offentlig adress ett helt klass-A-område.
Egenskapens namn inbjuder till fel läsning: satt till true stänger av härledningen, och false slår på den. Det är inte heller samma objekt som en standardrutt, och det styr inte tredjepartsklienter som installerar sina egna prefix.
Om härledningen är den bevisade orsaken, rätta profilen via dess hanteringsägare och ange de avsedda privata prefixen uttryckligen. Om ett skript lade till posten, reparera skriptet. Att ersätta en oförklarad bred rutt med en annan ändrar symptomet utan att svara på frågan.
Reparera källan och kontrollera sedan båda vägarna igen
Efter ändringen, återanslut och upprepa uppslagningen för en misslyckad offentlig webbplats och för en resurs som måste använda tunneln. Den första bör nu slås upp till det fysiska gränssnittet, och den andra bör fortfarande välja VPN:en. Stanna inte vid den första framgången; en rättelse som också bryter privat åtkomst har bytt ett fel mot ett annat.
Granska serverns adressplan samtidigt. En pool som överlappar offentligt utrymme orsakar den här typen av problem om och om igen. Ett område som operatören valde medvetet förtjänar ett annat samtal, inte automatisk omnumrering.
Att höja MTU:n eller rensa DNS rättar inte ett prefix som fortfarande leder den adressen in i tunneln. Testa urvalet först, sedan vägen.