Kial via Windows-VPN mortigas la lokan printilon kaj kiel tion haltigi

Konektu la VPN kaj la printilo malaperas, la NAS-kunhavaĵo ĉesas malfermiĝi, kaj fora labortabla sesio al la maŝino apud vi finiĝas pro tempolimo. Nenio rompiĝis. La kliento aldonis defaŭltan itineron kaj nun posedas ĉiun celon, kiun la tekokomputilo povas nomi, inkluzive de tiuj tri metrojn for. Tio estas la tuta mekanismo, kaj nomi ĝin paneo de la VPN estas ĝuste tio, kio transformas unulinian riparon en subtenan kazon.

Unue legu la itineran tabelon

Antaŭ ol ŝanĝi ion ajn, kaptu la tabelon IPv4 per route print -4 kaj konservu la eligon. Konektiĝu, kaptu denove kaj komparu la liniojn 0.0.0.0: la aktiva defaŭlta itinero nomas interfacon, kaj se tiu interfaco estas la tunelo, loka presado kaj retumado estas sendataj unue al la oficejo.

La interfaca numero en la dua kolumno estas tio, al kio daŭra itinero devos referenci poste, do notu ĝin dum la tunelo estas aktiva. Ĝi ankaŭ estas la valoro, kiu ŝanĝiĝas kiam la adaptilo estas rekreata, kaj tial itineroj fiksitaj al ĝi povas silente postvivi sian utilecon.

Forigu la defaŭltan itineron, tri manieroj

En enkonstruita Windows-profilo la regilo estas markobutono. Malfermu la ecojn de la konekto, IPv4, poste Plialtigita, kaj malmarku Use default gateway on remote network; la pli nova aplikaĵo Agordoj kaŝas la saman dialogon unu tavolon pli profunde. El plialtigita komanda invito la sama ŝanĝo estas unu cmdlet:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

La OpenVPN-profilo funkcias alimaniere, kaj tial ĝia konduto konfuzas homojn, kiuj atendas markobutonon. Ĝia redirect-gateway def1-direktivo tute ne anstataŭigas la defaŭltan itineron; ĝi instalas du duonintervalajn itinerojn, 0.0.0.0/1 kaj 128.0.0.0/1, kiuj kune venkas la defaŭltan sen forigi ĝin. Ĉar la originala defaŭlta postvivas, aldono de prefikso direktita al net_gateway resendas nur tiun prefikson al la loka enkursigilo. Tiu detalo klarigas, kial la solvo por def1-profilo estas prefiksa itinero kaj ne markobutono, kiun neniu povas trovi.

Reenmetu nur tion, kio apartenas al la laboro

Kun la defaŭlta itinero for, la tunelo portas nenion, do la laborprefiksoj devas esti nomitaj eksplicite. La cmdlet, kiu ligas prefikson al la konekto, estas pli sekura ol daŭra itinero, ĉar ĝi instaliĝas nur dum tiu konekto estas aktiva kaj ne dependas de interfaca numero:

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

La pli malnova aliro ankoraŭ funkcias kaj ankoraŭ estas en ĉiu kontrol-listo: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, kun la propra interfaca indekso kaj porda adreso de la tunelo. Ĝi postvivas restartojn, kio estas la celo kaj ankaŭ la danĝero, ĉar la indekso povas aparteni al io alia ĉe la sekva starto.

La metrikoj decidas la reston. Se kaj la fizika kaj la tunela adaptilo postulas itineron por la sama prefikso, venkas la pli malalta metriko, kaj plialtigi la metrikon de la tunelo estas laŭleĝa regado ĉe la klienta flanko, ne hako.

Kiam la servilo decidas por vi

Kliento, kiu ignoras vian markobutonon, kutime obeas politikon. Cisco-profiloj portas agordon Allow Local LAN Access, kaj headend povas puŝi politikon tunnel-all, kiu superregas tion, kion la kliento preferus; en deviga tunelo ne estas loka ŝaltilo por turni. Legu la klientan protokolon por puŝitaj itineroj kaj politikaj linioj anstataŭ rekontroli la saman dialogon.

Poste rigardu nomrezolvon, kiu estas aparta ŝaltilo de enkursigado. Disigita tunelo ankoraŭ povas ricevi internan solvilon kaj serĉan sufikson, do loka aparato estas atingebla per adreso kaj netrovebla per nomo ĝis ankaŭ la DNS-flanko estos riparita.

Interkovroj estas alia problemo

Se la hejma LAN kaj la oficeja LAN dividas prefikson kiel 192.168.0.0/24, neniu itinero povas distingi ilin. Ĉiu paketo por tiu gamo havas unu serĉrezulton, kaj la solvo estas renumeri unu flankon aŭ atingi la oficejon per tradukita adreso el la baseno. Aldoni pli specifajn itinerojn nur movas, kiun duonon de la reto rompiĝas.

Finu per unu kontrolo anstataŭ kvin: konektiĝu, poste rulu tracert kontraŭ interna kaj publika gastiganto. La unua salto devus diferenci, kaj se ĝi ne diferencas, la disigo ne estas en loko, kion ajn la kliento raportas. Poste rekonektiĝu unufoje kaj ripetu, ĉar puŝitaj itineroj revenas kun ĉiu sesio.