Kāpēc jūsu Windows VPN maršrutu tabulā redzami 0.0.0.0/1 un 128.0.0.0/1

Izveidojiet savienojumu ar Windows VPN un atveriet maršrutu tabulu, un divi ieraksti izceļas: 0.0.0.0/1 un 128.0.0.0/1. Tie nav drukas kļūda un neaizstāj noklusējuma maršrutu. To parādīšanās ir atkarīga no vienas profila opcijas, un pāris ir veids, kā tiek būvēts pilns tunelis, nevis sadalītā tuneļa funkcija. Pirms maināt pat vienu rindu, izlasiet opciju, prefiksu un interfeisu kopā.

Ko instalē noklusējuma vārtejas opcija

Profila opcija, kas visu sūta pa tuneli, darbojas, pievienojot šos divus prefiksus. Noņemiet opciju, un tie pazūd, atstājot maršrutu, kas aptver tikai apakštīklu, kas piešķirts tuneļa adapterim. Izvēles rūtiņa kontrolē pāri; tā nepārraksta vienīgo noklusējuma maršrutu. Tāpēc tabula pēc atzīmes noņemšanas izskatās kā daļēja pārrakstīšana, nevis dzēšana.

0.0.0.0/1 aptver IPv4 telpas apakšējo pusi un 128.0.0.0/1 augšējo pusi, tāpēc kopā tās aptver katru unicast adresi. Katrs no tiem ir konkrētāks par noklusējuma 0.0.0.0/0, kas nozīmē, ka garākā prefiksa atbilstība sūta parasto datplūsmu tunelī, kamēr fiziskais noklusējuma maršruts paliek tur, kur tas bija. Šī noklusējuma saglabāšana nav kosmētiska: paketes, kas ietver šifrēto kravu, ir adresētas servera publiskajai adresei un tām jāiziet caur fizisko adapteri. Aizstājiet noklusējumu, tā vietā lai to sadalītu, un paša tuneļa transports mēģinās iekļūt tunelī, kas ir cilpa, nevis savienojums.

Tāpēc burtisks 0.0.0.0/0, kas norāda uz VPN adapteri, ir vērts apstāšanās. Vietējais klients parasti tādu neraksta, tāpēc manuāls maršruts vai cita klienta konfigurācija ir mainījusi tabulu aiz jums muguras. Atrodiet to, pirms atkļūdojat kaut ko tālāk.

Demontāža ir lētāka par vārtejas saglabāšanu

Demontāža ir praktiskais arguments par labu diviem ierakstiem, nevis vienam. Savienojuma laikā klientam ir tieši divi maršruti, un atvienošanās laikā tas tos dzēš, atstājot to, kas fiziskajam adapterim tajā brīdī ir. Klients, kas būtu aizstājis vienīgo noklusējumu, būtu spiests atcerēties iepriekšējo vārteju, un pēc DHCP nomas maiņas tas varētu atjaunot tādu, kas vairs neeksistē. Divi savi ieraksti šādu stāvokli neuztur.

Citi klienti nonāk pie tā paša dizaina. OpenVPN profils ar redirect-gateway def1 instalē šos divus prefiksus, nevis dzēš noklusējumu, un Windows klients seko tam pašam modelim tā paša maršrutēšanas iemesla dēļ.

Tāpēc arī tabula var izskatīties kā pilns tunelis, kad gaidījāt sadalījumu. Pāris ir veids, kā tiek būvēts pilnais tunelis, nevis sadalītā tuneļa kļūdas pierādījums. Ja profils ir iestatīts izmantot attālo vārteju, viss tiek maršrutēts, lai ko vēl sasniegtu kāda vietējā lietotne.

Garākais prefikss uzvar pirms jebkuras metrikas

Prefiksa garums nosaka meklēšanu pirms jebkura cita lauka. Metrika tikai izšķir neizšķirtu starp maršrutiem ar identisku prefiksu, tāpēc /1 ieraksts pārspēj /0 noklusējumu pat tad, ja tā metrika ir sliktāka. Sasaiste ar interfeisu nosaka, kas paliek, kad divi maršruti dala prefiksu un Windows ir jāizvēlas, kurš adapters sūtīs paketi.

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

Sadalītā tuneļa tabula satur fizisko noklusējumu, divus pusnoklusējumus, tuneļa apakštīkla maršrutu un jebkuru pievienoto biroja prefiksu. Fiziskais noklusējums var atrasties zemākā vai augstākā metrikā atkarībā no klienta un profila, un, kamēr pastāv /1 pāris, šī atšķirība neko nemaina. Tā maina visu brīdī, kad pāris tiek noņemts, un tad parādās novecojusi vārteja vai nepareizs interfeiss. Lasiet visu tabulu, nevis to vienu rindu, kuru gaidījāt mainīt.

Izvēlieties vienu īpašnieku biroja prefiksam

Sadalītam tunelim nosauciet tikai to prefiksu, kuram jāizmanto VPN, un izvēlieties vienu veidu, kā tam piederēt. Maršruta novirzīšana uz piešķirto tuneļa adresi darbojas, līdz šī adrese mainās, savukārt sasaiste ar interfeisu pārdzīvo adreses maiņu, bet salūzt, kad indekss pēc profila pārbūves tiek piešķirts no jauna. Ar profilu saistītais cmdlet izvairās no abām problēmām, par cenu, ka nepieciešams profils.

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

Cmdlet saista prefiksu ar nosaukto profilu, tāpēc maršruts parādās kopā ar savienojumu un pazūd kopā ar to, ko vēlas pārvaldīts portatīvais dators. Pastāvīgs maršruts pārdzīvo pārstartēšanu un pārdzīvo profilu, kas to izraisīja, un tā izstāts VPN atstāj ierakstus gadiem ilgi. Izvēlieties vienu metodi katram prefiksam un pierakstiet izvēli, jo pastāvīgs maršruts kopā ar profila maršrutu vienam un tam pašam prefiksam rada dublikātus, kurus demontāžas laikā ir sāpīgi izšķetināt. Ko vien izvēlaties, īpašumtiesībām jābūt redzamām biļetē, nevis tikai mašīnā.

Īpašumtiesības ir jautājums, uz ko atbild šī sadaļa, nevis sintakse. Divi īpašnieki vienam prefiksam ir kļūmes modelis, no kura ir vērts izvairīties.

Pārbaudiet ar galamērķi, nevis ar vietni

Pārbaudiet galamērķi, kuram jāšķērso tunelis, nevis vietni, kas ziņo izejas adresi. Find-NetRoute atgriež izvēlēto maršrutu un avota adresi, tāpēc redzat, vai uzvarēja biroja prefikss vai fiziskais noklusējums, un pēc tam atverat pašu koplietojumu.

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

Izejas adreses vietne ir vāja pārbaude, jo DNS, IPv6 un pārlūka starpniekserveris katrs var nosūtīt šo pieprasījumu pa citu ceļu. IPv4 un IPv6 tajā pašā dialogā ir arī atsevišķi iestatījumi, un vienas rūtiņas notīrīšana atstāj otru saimi neskartu, tāpēc mašīna ar divkāršu steku var vest IPv6 pa tuneli, kamēr IPv4 seko sadalītajam maršrutam. Pārbaudiet abas saimes, pirms saucat profilu par sadalītu. Ja maršruts ir pareizs un pakalpojums joprojām neizdodas, atlikušais slānis ir filtrēšana, nevis maršrutēšana.

Klienta pārvaldīts ugunsmūris var bloķēt biroja apakštīklu arī ar perfektu maršrutu tabulu. Šī politika pieder tam, kurš izplatīja profilu, nevis tam, kurš rediģē maršrutus.