Varför din Windows VPN-routingtabell visar 0.0.0.0/1 och 128.0.0.0/1
Inställningen för standardgateway lägger till två halvstandardrutter, inte en. Läs prefix, metrik och gränssnitt innan du lägger till eller tar bort en rutt på klienten.
Anslut till en Windows-VPN och öppna routingtabellen, och två poster sticker ut: 0.0.0.0/1 och 128.0.0.0/1. De är inte ett skrivfel och de ersätter inte standardrutten. Om de visas beror på en profilinställning, och paret är sättet en full tunnel byggs, inte en split-tunnelfunktion. Läs inställningen, prefixet och gränssnittet tillsammans innan du ändrar en enda rad.
Vad inställningen för standardgateway installerar
Profilinställningen som skickar allt genom tunneln fungerar genom att lägga till de två prefixen. Ta bort inställningen och de försvinner, och lämnar en rutt som bara täcker det subnät tunneladaptern har fått. Kryssrutan styr paret; den skriver inte om den enda standardrutten. Därför ser tabellen efter att krysset tagits bort ut som en partiell omskrivning i stället för en radering.
0.0.0.0/1 täcker den nedre halvan av IPv4-rymden och 128.0.0.0/1 den övre halvan, så tillsammans täcker de varje unicast-adress. Var och en är mer specifik än en standardrutt 0.0.0.0/0, vilket innebär att matchning på längsta prefix skickar vanlig trafik in i tunneln medan den fysiska standardrutten stannar där den var. Att behålla den standardrutten är inte kosmetika: paketen som packar in den krypterade nyttolasten är adresserade till serverns publika adress och måste gå ut genom den fysiska adaptern. Ersätt standardrutten i stället för att dela den, och tunnelns egen transport försöker gå in i tunneln, vilket är en slinga och inte en anslutning.
Därför är en bokstavlig 0.0.0.0/0 som pekar på VPN-adaptern värd att stanna vid. Den inbyggda klienten skriver normalt inte en sådan, så en manuell rutt eller en annan klients konfiguration har ändrat tabellen bakom ryggen på dig. Hitta den innan du felsöker något längre ned.
Nedmontering är billigare än att spara en gateway
Nedmontering är det praktiska argumentet för två poster i stället för en. Klienten äger exakt två rutter medan den är ansluten och raderar dem vid frånkoppling, och lämnar det den fysiska adaptern har i det ögonblicket. En klient som hade ersatt den enda standardrutten skulle behöva komma ihåg den föregående gatewayen, och efter en ändring av DHCP-lånet kunde den återställa en som inte längre finns. Två egna poster bär inget sådant tillstånd.
Andra klienter kommer fram till samma design. En OpenVPN-profil med redirect-gateway def1 installerar de två prefixen i stället för att radera standardrutten, och Windows-klienten följer mönstret av samma routing-skäl.
Det är också därför en tabell kan se ut som en full tunnel när du väntade dig en delning. Paret är sättet den fulla tunneln byggs, inte bevis på ett split-tunnelfel. Om profilen är inställd på att använda den fjärranslutna gatewayen routas allt, vad än en lokal applikation fortfarande når.
Längsta prefix vinner före någon metrik
Prefixlängden avgör uppslaget före något annat fält. Metriken bryter bara oavgjort mellan rutter med identiskt prefix, så en /1-post slår en /0-standard även när dess metrik är sämre. Gränssnittsbindningen avgör vad som återstår när två rutter delar ett prefix och Windows måste välja vilken adapter som skickar paketet.
route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20
En split-tunneltabell innehåller den fysiska standardrutten, de två halvstandardrutterna, rutten för tunnelns subnät och varje kontorsprefix du har lagt till. Den fysiska standardrutten kan ligga på en lägre eller högre metrik beroende på klienten och profilen, och så länge /1-paret finns ändrar den skillnaden ingenting. Den ändrar allt i samma ögonblick som paret tas bort, och det är då en inaktuell gateway eller ett fel gränssnitt dyker upp. Läs hela tabellen och inte den enda rad du förväntade dig att ändra.
Välj en ägare för kontorsprefixet
För en split-tunnel namnger du bara det prefix som måste använda VPN:en, och väljer ett sätt att äga det. Att peka rutten mot den tilldelade tunneladressen fungerar tills adressen ändras, medan bindning till gränssnittet överlever adressen men går sönder när indexet tilldelas på nytt efter att profilen byggts om. Cmdleten som är bunden till profilen undviker båda problemen, mot att profilen krävs.
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
Cmdleten binder prefixet till den namngivna profilen, så rutten dyker upp med anslutningen och försvinner med den, vilket en hanterad bärbar dator vill ha. En beständig rutt överlever omstarter och överlever profilen som motiverade den, och så lämnar en avvecklad VPN poster i åratal. Välj en metod per prefix och notera valet, eftersom en beständig rutt plus en profilrutt för samma prefix ger dubbletter som är svåra att reda ut vid nedmontering. Vad du än väljer bör ägarskapet synas i ärendet och inte bara på maskinen.
Ägarskap är frågan som det här avsnittet besvarar, inte syntaxen. Två ägare för ett prefix är det felfall som är värt att undvika.
Verifiera med en destination, inte en webbplats
Testa destinationen som måste korsa tunneln, inte en webbplats som rapporterar en utgångsadress. Find-NetRoute returnerar den valda rutten och källadressen, så du ser om kontorsprefixet eller den fysiska standardrutten vann, och sedan öppnar du själva delningen.
Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office
En utgångsadresswebbplats är en svag kontroll, eftersom DNS, IPv6 och en webbläsarproxy var och en kan skicka den begäran en annan väg. IPv4 och IPv6 har också separata inställningar i samma dialog, och att rensa en ruta lämnar den andra familjen orörd, så en maskin med dubbel stack kan föra IPv6 genom tunneln medan IPv4 följer split-rutten. Kontrollera båda familjerna innan du kallar profilen delad. Om rutten är rätt och tjänsten fortfarande misslyckas är det återstående lagret filtrering och inte routing.
En klienthanterad brandvägg kan blockera kontorets subnät med en perfekt routingtabell. Den policyn tillhör den som distribuerade profilen, inte personen som redigerar rutter.