Hvorfor Windows VPN-rutetabellen din viser 0.0.0.0/1 og 128.0.0.0/1

Koble til en Windows-VPN og åpne rutetabellen, og to oppføringer skiller seg ut: 0.0.0.0/1 og 128.0.0.0/1. De er ikke en skrivefeil, og de erstatter ikke standardruten. Om de vises, avhenger av én profilinnstilling, og paret er måten en full tunnel bygges på, ikke en split-tunnel-funksjon. Les innstillingen, prefikset og grensesnittet sammen før du endrer én eneste linje.

Hva innstillingen for standard gateway installerer

Profilinnstillingen som sender alt gjennom tunnelen, virker ved å legge til de to prefiksene. Fjern innstillingen, og de forsvinner og etterlater en rute som bare dekker subnettet tunneladapteren har fått. Avkrysningsboksen styrer paret; den skriver ikke om den ene standardruten. Derfor ser tabellen etter at hakket fjernes ut som en delvis omskriving i stedet for en sletting.

0.0.0.0/1 dekker den nedre halvdelen av IPv4-rommet og 128.0.0.0/1 den øvre halvdelen, så sammen dekker de hver unicast-adresse. Hver av dem er mer spesifikk enn en standardrute 0.0.0.0/0, noe som betyr at samsvar med lengste prefiks sender vanlig trafikk inn i tunnelen mens den fysiske standardruten blir der den var. Å beholde den standardruten er ikke kosmetikk: pakkene som pakker inn den krypterte nyttelasten er adressert til serverens offentlige adresse og må gå ut gjennom den fysiske adapteren. Erstatt standardruten i stedet for å dele den, og tunnelens egen transport vil prøve å gå inn i tunnelen, noe som er en løkke og ikke en forbindelse.

Derfor er en bokstavelig 0.0.0.0/0 som peker på VPN-adapteren verdt å stoppe ved. Den innebygde klienten skriver normalt ikke noe slikt, så en manuell rute eller en annen klients konfigurasjon har endret tabellen bak ryggen din. Finn den før du feilsøker noe lenger ned.

Nedriving er billigere enn å spare en gateway

Nedriving er det praktiske argumentet for to oppføringer i stedet for én. Klienten eier nøyaktig to ruter mens den er tilkoblet og sletter dem ved frakobling, og etterlater det den fysiske adapteren har i det øyeblikket. En klient som hadde erstattet den ene standardruten, måtte huske den forrige gatewayen, og etter en endring i DHCP-leasen kunne den gjenopprette en som ikke finnes lenger. To egne oppføringer bærer ingen slik tilstand.

Andre klienter kommer til samme design. En OpenVPN-profil med redirect-gateway def1 installerer de to prefiksene i stedet for å slette standardruten, og Windows-klienten følger mønsteret av samme rutingsgrunn.

Det er også derfor en tabell kan se ut som en full tunnel når du forventet en splitting. Paret er måten den fulle tunnelen bygges på, ikke bevis på en split-tunnel-feil. Hvis profilen er satt til å bruke den eksterne gatewayen, rutes alt, uansett hva én lokal applikasjon fortsatt når.

Lengste prefiks vinner før noen metrikk

Prefikslengden avgjør oppslaget før noe annet felt. Metrikken bryter bare uavgjort mellom ruter med identisk prefiks, så en /1-oppføring slår en /0-standard selv når metrikken er dårligere. Grensesnittbinding avgjør hva som er igjen når to ruter deler et prefiks og Windows må velge hvilken adapter som sender pakken.

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

En split-tunnel-tabell inneholder den fysiske standardruten, de to halvstandardene, ruten for tunnelens subnett og ethvert kontorprefiks du har lagt til. Den fysiske standardruten kan ligge på en lavere eller høyere metrikk avhengig av klienten og profilen, og så lenge /1-paret finnes, endrer den forskjellen ingenting. Den endrer alt i det øyeblikket paret fjernes, og det er da en utdatert gateway eller et feil grensesnitt dukker opp. Les hele tabellen i stedet for den ene linjen du forventet å endre.

Velg én eier for kontorprefikset

For en split-tunnel navngir du bare prefikset som må bruke VPN-en, og velger én måte å eie det på. Å peke ruten mot den tildelte tunneladressen virker til adressen endres, mens binding til grensesnittet overlever adressen, men brekker når indeksen tildeles på nytt etter at profilen er gjenoppbygd. Cmdleten som er bundet til profilen, unngår begge problemene, mot at profilen er nødvendig.

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 prefikset til den navngitte profilen, så ruten dukker opp med tilkoblingen og forsvinner med den, noe en administrert bærbar PC vil ha. En vedvarende rute overlever omstart og overlever profilen som motiverte den, og slik etterlater en nedlagt VPN oppføringer i årevis. Velg én metode per prefiks og noter valget, for en vedvarende rute pluss en profilrute for samme prefiks gir duplikater som er vonde å nøste opp under nedriving. Uansett hva du velger, bør eierskapet være synlig i saken og ikke bare på maskinen.

Eierskap er spørsmålet denne delen svarer på, ikke syntaks. To eiere for ett prefiks er feilmodusen som er verdt å unngå.

Verifiser med en destinasjon, ikke et nettsted

Test destinasjonen som må krysse tunnelen, ikke et nettsted som rapporterer en utgangsadresse. Find-NetRoute returnerer den valgte ruten og kildeadressen, så du ser om kontorprefikset eller den fysiske standardruten vant, og deretter åpner du selve delingen.

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

Et utgangsadresse-nettsted er en svak kontroll, fordi DNS, IPv6 og en nettleserproxy hver kan sende den forespørselen via en annen vei. IPv4 og IPv6 har også separate innstillinger i samme dialog, og å fjerne ett hakk lar den andre familien være urørt, så en maskin med dobbel stabel kan føre IPv6 gjennom tunnelen mens IPv4 følger split-ruten. Kontroller begge familiene før du kaller profilen splittet. Hvis ruten er riktig og tjenesten fortsatt feiler, er det gjenværende laget filtrering og ikke ruting.

En klientstyrt brannmur kan blokkere kontorets subnett med en perfekt rutetabell. Den policyen tilhører den som distribuerte profilen, ikke personen som redigerer ruter.