Kial via Windows-VPN-vojiga tabelo montras 0.0.0.0/1 kaj 128.0.0.0/1

Konektiĝu al Windows-VPN kaj malfermu la vojigan tabelon, kaj du enskriboj elstaras: 0.0.0.0/1 kaj 128.0.0.0/1. Ili ne estas tajperaro kaj ne anstataŭigas la implicitan vojon. Ĉu ili aperas dependas de unu profila agordo, kaj la paro estas la maniero konstrui plenan tunelon, ne funkcio de dividita tunelo. Legu la agordon, la prefikson kaj la interfacon kune antaŭ ol ŝanĝi eĉ unu linion.

Kion la opcio pri implicita enirejo instalamas

La profila agordo, kiu sendas ĉion tra la tunelo, funkcias aldonante tiujn du prefiksojn. Forigu la agordon kaj ili malaperas, lasante vojon, kiu kovras nur la subreton donitan al la tunela adaptilo. La markobutono regas la paron; ĝi ne reskribas la ununuran implicitan vojon. Tial la tabelo post malmarkado aspektas kiel parta reskribo anstataŭ forigo.

0.0.0.0/1 kovras la suban duonon de la IPv4-spaco kaj 128.0.0.0/1 la supran duonon, do kune ili kovras ĉiun unukastan adreson. Ĉiu estas pli specifa ol implicita vojo 0.0.0.0/0, kio signifas, ke kongruo de la plej longa prefikso sendas ordinaran trafikon en la tunelon dum la fizika implicita vojo restas kie ĝi estis. Konservi tiun implicitan vojon ne estas kosmetika: la pakaĵoj, kiuj envolvas la ĉifritan ŝarĝon, estas adresitaj al la publika adreso de la servilo kaj devas eliri tra la fizika adaptilo. Anstataŭigu la implicitan vojon anstataŭ dividi ĝin, kaj la transporto de la tunelo mem provos eniri la tunelon, kio estas buklo, ne konekto.

Tial laŭvorta 0.0.0.0/0 direktita al la VPN-adaptilo indas halti ĉe ĝi. La indiĝena kliento kutime ne skribas tion, do permana vojo aŭ la agordo de alia kliento ŝanĝis la tabelon malantaŭ vi. Trovu ĝin antaŭ ol senerarigi ion pli malsupre.

Malkonstruo malpli kostas ol konservi enirejon

Malkonstruo estas la praktika argumento por du enskriboj anstataŭ unu. La kliento posedas precize du vojojn dum konekto kaj forigas ilin ĉe malkonekto, lasante tion, kion la fizika adaptilo tenas tiun momenton. Kliento, kiu estus anstataŭiginta la ununuran implicitan vojon, devus memori la antaŭan enirejon, kaj post ŝanĝo de DHCP-luo ĝi povus restaŭri unu, kiu jam ne ekzistas. Du posedataj enskriboj portas neniun tian staton.

Aliaj klientoj alvenas al la sama dezajno. OpenVPN-profilo kun redirect-gateway def1 instalas tiujn du prefiksojn anstataŭ forigi la implicitan, kaj la Windows-kliento sekvas la saman ŝablonon pro la sama vojiga kaŭzo.

Tial ankaŭ tabelo povas aspekti kiel plena tunelo, kiam vi atendis dividon. La paro estas kiel la plena tunelo estas konstruata, ne pruvo de eraro pri dividita tunelo. Se la profilo estas agordita uzi la malproksiman enirejon, ĉio estas vojigata, kion ajn unu loka aplikaĵo ankoraŭ sukcesas atingi.

La plej longa prefikso venkas antaŭ iu ajn metriko

La prefiksa longo decidas la serĉon antaŭ iu ajn alia kampo. La metriko nur solvas egalecojn inter vojoj kun identa prefikso, do enskribo /1 venkas implicitan /0 eĉ kiam ĝia metriko estas pli malbona. La interfaca bindado decidas, kio restas kiam du vojoj dividas prefikson kaj Windows devas elekti, kiu adaptilo sendos la pakaĵon.

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

Tabelo de dividita tunelo tenas la fizikan implicitan vojon, la du duon-implicitajn, la vojon por la tunela subreto kaj ĉiun oficejan prefikson, kiun vi aldonis. La fizika implicita vojo povas sidi ĉe pli malalta aŭ pli alta metriko laŭ la kliento kaj la profilo, kaj dum la paro /1 ekzistas tiu diferenco ŝanĝas nenion. Ĝi ŝanĝas ĉion en la momento, kiam la paro estas forigita, kaj tiam aperas kaduka enirejo aŭ malĝusta interfaco. Legu la tutan tabelon anstataŭ la unu linion, kiun vi atendis ŝanĝi.

Elektu unu posedanton por la oficeja prefikso

Por dividita tunelo nomu nur la prefikson, kiu devas uzi la VPN-on, kaj elektu unu manieron posedi ĝin. Direkti la vojon al la asignita tunela adreso funkcias ĝis tiu adreso ŝanĝiĝos, dum bindado al la interfaco postvivas la adreson sed rompiĝas, kiam la indekso estas reasignita post rekonstruo de la profilo. La profil-ligita cmdlet evitas ambaŭ problemojn, kontraŭ la kosto bezoni la profilon.

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

La cmdlet ligas la prefikson al la nomita profilo, do la vojo aperas kun la konekto kaj foriras kun ĝi, kion administrita tekkomputilo volas. Konstanta vojo postvivas restartojn kaj postvivas la profilon, kiu ĝin kaŭzis, kaj tiel emeritiĝinta VPN lasas enskribojn dum jaroj. Elektu unu metodon por prefikso kaj notu la elekton, ĉar konstanta vojo plus profila vojo por la sama prefikso produktas duplikatojn, kiujn estas dolore malimpliki dum malkonstruo. Kion ajn vi elektas, la posedo devus esti videbla en la bileto kaj ne nur en la maŝino.

Posedo estas la demando, al kiu ĉi tiu sekcio respondas, ne sintakso. Du posedantoj por unu prefikso estas la fiaska modo inda eviti.

Kontrolu per celo, ne per retejo

Testu la celon, kiun devas transiri la tunelo, ne retejon, kiu raportas eliran adreson. Find-NetRoute redonas la elektitan vojon kaj la fontan adreson, do vi vidas, ĉu venkis la oficeja prefikso aŭ la fizika implicita vojo, kaj poste malfermu la kunhavon mem.

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

Elir-adresa retejo estas malforta kontrolo, ĉar DNS, IPv6 kaj retumila prokurilo povas sendi tiun peton laŭ malsama vojo. IPv4 kaj IPv6 ankaŭ havas apartajn agordojn en la sama dialogo, kaj malplenigi unu keston lasas la alian familion netuŝita, do maŝino kun duobla stako povas porti IPv6 tra la tunelo dum IPv4 sekvas la dividitan vojon. Kontrolu ambaŭ familiojn antaŭ ol nomi la profilon dividita. Se la vojo estas ĝusta kaj la servo ankoraŭ fiaskas, la restanta tavolo estas filtrado, ne vojigado.

Klient-administrata fajroŝirmilo povas bloki la oficejan subreton kun perfekta vojiga tabelo. Tiu politiko apartenas al tiu, kiu disdonis la profilon, ne al la persono, kiu redaktas vojojn.