Waarom uw Windows VPN-routetabel 0.0.0.0/1 en 128.0.0.0/1 toont

De optie voor de standaardgateway voegt twee halfstandaardroutes toe, niet één. Lees prefix, metriek en interface voordat u een route op de client toevoegt of verwijdert.

Maak verbinding met een Windows-VPN en open de routetabel, en twee vermeldingen vallen op: 0.0.0.0/1 en 128.0.0.0/1. Ze zijn geen typfout en vervangen de standaardroute niet. Of ze verschijnen, hangt af van één profieloptie, en het paar is de manier waarop een volledige tunnel wordt gebouwd, geen split-tunnelfunctie. Lees de optie, het prefix en de interface samen voordat u één regel wijzigt.

Wat de optie voor de standaardgateway installeert

De profieloptie die alles door de tunnel stuurt, werkt door die twee prefixen toe te voegen. Schakel de optie uit en ze verdwijnen, met een route die alleen het subnet dekt dat de tunneladapter heeft gekregen. Het selectievakje beheert het paar; het herschrijft niet de enige standaardroute. Daarom lijkt de tabel na het uitvinken op een gedeeltelijke herschrijving in plaats van een verwijdering.

0.0.0.0/1 dekt de onderste helft van de IPv4-ruimte en 128.0.0.0/1 de bovenste helft, dus samen dekken ze elk unicastadres. Elk is specifieker dan een standaardroute 0.0.0.0/0, wat betekent dat de langste-prefixmatch gewoon verkeer de tunnel in stuurt terwijl de fysieke standaardroute blijft waar hij was. Die standaardroute behouden is geen cosmetica: de pakketten die de versleutelde payload inpakken, zijn geadresseerd aan het openbare adres van de server en moeten via de fysieke adapter naar buiten. Vervang de standaardroute in plaats van hem te splitsen, en het transport van de tunnel zelf probeert de tunnel in te gaan, wat een lus is en geen verbinding.

Een letterlijke 0.0.0.0/0 die naar de VPN-adapter wijst, is dus het stoppen waard. De native client schrijft dat normaal niet, dus een handmatige route of de configuratie van een andere client heeft de tabel achter uw rug gewijzigd. Vind hem voordat u iets verderop debugt.

Afsluiten is goedkoper dan een gateway bewaren

Afsluiten is het praktische argument voor twee vermeldingen in plaats van één. De client bezit precies twee routes terwijl hij verbonden is en verwijdert ze bij het verbreken, en laat achter wat de fysieke adapter op dat moment heeft. Een client die de enige standaardroute had vervangen, zou de vorige gateway moeten onthouden, en na een wijziging van de DHCP-lease zou hij een gateway kunnen herstellen die niet meer bestaat. Twee eigen vermeldingen dragen zo'n toestand niet.

Andere clients komen tot hetzelfde ontwerp. Een OpenVPN-profiel met redirect-gateway def1 installeert die twee prefixen in plaats van de standaardroute te verwijderen, en de Windows-client volgt het patroon om dezelfde routeringsreden.

Daarom kan een tabel op een volledige tunnel lijken wanneer u een splitsing verwachtte. Het paar is de manier waarop de volledige tunnel wordt gebouwd, geen bewijs van een split-tunnelfout. Als het profiel is ingesteld op de externe gateway, wordt alles gerouteerd, wat een lokale toepassing ook nog bereikt.

Het langste prefix wint vóór elke metriek

De prefixlengte bepaalt de opzoeking vóór elk ander veld. De metriek breekt alleen gelijkspel tussen routes met een identiek prefix, dus een /1-vermelding verslaat een /0-standaard zelfs wanneer de metriek slechter is. Interfacebinding bepaalt wat er overblijft wanneer twee routes een prefix delen en Windows moet kiezen welke adapter het pakket verstuurt.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

Een split-tunneltabel bevat de fysieke standaardroute, de twee halfstandaarden, de route voor het subnet van de tunnel en elk kantoorprefix dat u hebt toegevoegd. De fysieke standaardroute kan op een lagere of hogere metriek staan, afhankelijk van de client en het profiel, en zolang het /1-paar bestaat, verandert dat verschil niets. Het verandert alles op het moment dat het paar wordt verwijderd, en dan duikt een verouderde gateway of een verkeerde interface op. Lees de hele tabel en niet de ene regel die u verwachtte te wijzigen.

Kies één eigenaar voor het kantoorprefix

Voor een split-tunnel noemt u alleen het prefix dat de VPN moet gebruiken, en kiest u één manier om het te bezitten. De route naar het toegewezen tunneladres richten werkt tot dat adres verandert, terwijl binding aan de interface het adres overleeft maar breekt wanneer de index opnieuw wordt toegewezen nadat het profiel opnieuw is opgebouwd. De cmdlet die aan het profiel is gebonden, vermijdt beide problemen, tegen de prijs dat het profiel nodig is.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

De cmdlet bindt het prefix aan het genoemde profiel, zodat de route met de verbinding verschijnt en ermee verdwijnt, wat een beheerde laptop wil. Een permanente route overleeft herstarts en overleeft het profiel dat hem heeft veroorzaakt, en zo laat een buiten gebruik gestelde VPN jarenlang vermeldingen achter. Kies één methode per prefix en noteer de keuze, want een permanente route plus een profielroute voor hetzelfde prefix levert duplicaten op die bij het afsluiten pijnlijk zijn om te ontwarren. Wat u ook kiest, het eigenaarschap moet zichtbaar zijn in het ticket en niet alleen op de machine.

Eigenaarschap is de vraag die deze sectie beantwoordt, niet de syntaxis. Twee eigenaren voor één prefix is de faalmodus die het waard is te vermijden.

Controleer met een bestemming, niet met een website

Test de bestemming die de tunnel moet passeren, niet een website die een uitgaand adres meldt. Find-NetRoute geeft de gekozen route en het bronadres terug, zodat u ziet of het kantoorprefix of de fysieke standaardroute heeft gewonnen, en dan opent u de share zelf.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

Een website met uitgaand adres is een zwakke controle, omdat DNS, IPv6 en een browserproxy dat verzoek elk via een andere weg kunnen sturen. IPv4 en IPv6 hebben in dezelfde dialoog ook aparte instellingen, en één vakje leegmaken laat de andere familie onaangeroerd, zodat een machine met dubbele stack IPv6 door de tunnel kan leiden terwijl IPv4 de splitroute volgt. Controleer beide families voordat u het profiel gesplitst noemt. Als de route klopt en de dienst toch faalt, is de resterende laag filtering en niet routering.

Een door de client beheerde firewall kan het kantoorsubnet blokkeren met een perfecte routetabel. Dat beleid hoort bij degene die het profiel heeft uitgerold, niet bij degene die routes bewerkt.

Gerelateerde artikelen