Waarom een brede VPN-route een paar openbare sites breekt

De meeste pagina's laden, twee of drie lopen in een time-out, en de browser geeft de verbinding de schuld. De sites die falen hebben iets gemeen dat de werkende niet hebben: hun opgeloste adressen vallen binnen een prefix dat de VPN heeft geïnstalleerd. Een route die breed genoeg is om een openbaar bereik te dekken, vangt verkeer dat de tunnel nooit hoorde te dragen, en het symptoom lijkt op een websiteprobleem in plaats van een routeringsbeslissing.

Los de naam op die faalt en kijk dan naar de routeringstabel in plaats van naar de browser.

Vergelijk het adres, niet de naam van de site

Zoek het adres op dat de client werkelijk probeerde en controleer dan welke route erbij past. Een bestemming binnen 45.61.20.10 valt onder 45.0.0.0/8 als dat prefix aanwezig is, ook al heeft de site zelf niets met de tunnel te maken. Het falende adres vergelijken met de geïnstalleerde prefixes is een aftreksom, geen gok.

Windows kan beide helften direct beantwoorden, en een opzoeking laat zien welke interface en welke volgende hop de selectie wonnen. Los de naam twee keer op als de site meerdere adressen teruggeeft. Noteer elk adres met de route die erbij paste. Verschillende adressen kunnen verschillende antwoorden geven, en slechts één ervan is misschien het falende geval.

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

Lees het meest specifieke passende prefix, niet de eerste regel die bekend voorkomt. Een route in de tabel bewijst niet dat hij de opzoeking won; dat doet de langste overeenkomst. Twee prefixes kunnen bij één adres passen, en slechts één ervan ontvangt het pakket. De verliezer blijft in de tabel staan en ziet er in een lijst net zo echt uit.

Noteer het prefix, de interface en het opgeloste adres. Die drie waarden zijn de hele diagnose.

Zoek uit wie de route heeft geïnstalleerd

Routes komen van vier plaatsen: het native VPN-profiel, een beheerbeleid, een verbindingsscript of een heel andere client. Het actieve item verwijderen kan de relevantie bevestigen, maar de volgende verbinding maakt het opnieuw aan uit de opgeslagen configuratie, dus de bron is wat moet veranderen.

Controleer eerst de routelijst van het profiel, dan het beheerbeleid, dan elk script dat bij het verbinden draait. Die volgorde komt overeen met hoe vaak elk verantwoordelijk blijkt. Het houdt de wijziging ook in één laag in plaats van drie.

Lees het native klassegebaseerde gedrag zorgvuldig

Native Windows-profielen hebben een gedocumenteerde instelling, NativeProfile/DisableClassBasedDefaultRoute, die een automatische route aanstuurt die uit het interfaceadres is afgeleid. Een profieladres dat met 45 begint, kan onder dat gedrag een vermelding 45.0.0.0/8 opleveren, en zo vangt één openbaar adres een heel klasse-A-bereik.

De naam van de eigenschap nodigt uit tot verkeerd lezen: op true gezet schakelt het de afleiding uit, en false schakelt die in. Het is ook niet hetzelfde object als een standaardroute, en het bestuurt geen clients van derden die hun eigen prefixes installeren.

Als de afleiding de aangetoonde oorzaak is, corrigeer het profiel via de beheereigenaar en geef de bedoelde privéprefixes expliciet op. Als een script de vermelding heeft toegevoegd, repareer dan het script. Eén onverklaarde brede route door een andere vervangen verandert het symptoom zonder de vraag te beantwoorden.

Repareer de bron en controleer daarna beide paden opnieuw

Maak na de wijziging opnieuw verbinding en herhaal de opzoeking voor een falende openbare site en voor een bron die de tunnel moet gebruiken. De eerste moet nu naar de fysieke interface oplossen, en de tweede moet nog steeds de VPN kiezen. Stop niet bij het eerste succes; een correctie die ook privétoegang breekt, heeft de ene fout voor de andere ingeruild.

Bekijk tegelijk het adresplan van de server. Een pool die overlapt met openbare ruimte veroorzaakt dit soort probleem steeds opnieuw. Een bereik dat de operator bewust koos verdient een ander gesprek, geen automatische hernummering.

De MTU verhogen of DNS leegmaken lost geen prefix op dat dat adres nog steeds de tunnel in stuurt. Test eerst de selectie en dan het pad.