Bakit pinapatay ng iyong Windows VPN ang lokal na printer at paano ito pigilan

Ikonekta ang VPN at nawawala ang printer, tumitigil sa pagbukas ang NAS share, at nag-time out ang Remote Desktop session papunta sa makina sa tabi mo. Walang nasira. Nagdagdag ang client ng default route at pagmamay-ari na nito ang bawat destinasyon na kayang pangalanan ng laptop, kasama ang mga tatlong metro ang layo. Iyan ang buong mekanismo, at ang tawagin itong VPN fault ang siyang gumagawa ng isang linyang pag-aayos na maging support case.

Basahin muna ang route table

Bago magbago ng kahit ano, kunin ang IPv4 table gamit ang route print -4 at itago ang output. Kumonekta, kunin muli at ihambing ang mga linyang 0.0.0.0: pinangalanan ng aktibong default route ang isang interface, at kung ang interface na iyon ay ang tunnel, ang lokal na pagpi-print at pagba-browse ay ipinapadala muna sa opisina.

Ang interface number sa ikalawang column ang siyang kailangang tukuyin ng permanenteng ruta mamaya, kaya isulat ito habang nakaup ang tunnel. Ito rin ang value na nagbabago kapag muling ginawa ang adapter, kaya ang mga rutang naka-pin dito ay tahimik na maaaring lumampas sa silbi nila.

Alisin ang default route, sa tatlong paraan

Sa built-in na Windows profile, ang kontrol ay isang checkbox. Buksan ang properties ng koneksyon, IPv4, pagkatapos Advanced, at alisin ang Use default gateway on remote network; itinatago ng mas bagong Settings app ang parehong dialog nang isang patong palalim. Mula sa elevated na prompt, ang parehong pagbabago ay isang cmdlet:

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

Ang isang OpenVPN na profile ay gumagana nang iba, kaya nakakalito ang pag-uugali nito sa mga umaasang checkbox. Ang direktiba nitong redirect-gateway def1 ay hindi talaga pinapalitan ang default route; nag-i-install ito ng dalawang half-range na ruta, 0.0.0.0/1 at 128.0.0.0/1, na magkasamang nananalo sa default nang hindi ito binubura. Dahil nananatili ang orihinal na default, ang pagdaragdag ng prefix na nakaturo sa net_gateway ay ibinabalik lamang ang prefix na iyon sa lokal na router. Ipinaliwanag ng detalyeng iyon kung bakit ang pag-aayos para sa def1 profile ay isang prefix route at hindi isang checkbox na walang makahanap.

Ibalik lamang ang nabibilang sa trabaho

Kung wala ang default route, wala nang dinadala ang tunnel, kaya kailangang pangalanan nang tahasan ang mga work prefix. Ang cmdlet na nagbibigkis ng prefix sa koneksyon ay mas ligtas kaysa permanenteng ruta, dahil naka-install lamang ito habang nakaup ang koneksyong iyon at hindi umaasa sa interface number:

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

Gumagana pa rin ang lumang paraan at nasa bawat checklist pa rin: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, kasama ang sariling interface index at gateway address ng tunnel. Nananatili ito sa mga reboot, na siyang layunin at siya ring panganib, dahil ang index ay maaaring pag-aari ng iba sa susunod na boot.

Ang natitira ay pinagpapasyahan ng mga metric. Kung parehong nag-aangkin ng ruta ang pisikal at tunnel adapter para sa parehong prefix, nananalo ang mas mababang metric, at ang pagtaas ng metric ng tunnel ay isang lehitimong kontrol sa panig ng client at hindi isang hack.

Kapag ang server ang nagpapasya para sa iyo

Ang client na hindi pinapansin ang iyong checkbox ay karaniwang sumusunod sa isang patakaran. May setting na Allow Local LAN Access ang mga Cisco profile, at ang headend ay maaaring magtulak ng tunnel-all na patakaran na nangingibabaw sa anumang gusto ng client; sa sapilitang tunnel deployment ay walang lokal na switch na iikot. Basahin ang client log para sa mga itinulak na ruta at linya ng patakaran sa halip na muling suriin ang parehong dialog.

Pagkatapos tingnan ang name resolution, na isang hiwalay na switch mula sa routing. Ang split tunnel ay maaari pa ring makatanggap ng internal resolver at search suffix, kaya ang lokal na device ay maabot sa address at hindi mahanap sa pangalan hanggang maayos din ang panig ng DNS.

Ibang problema ang mga overlap

Kung ang LAN sa bahay at LAN sa opisina ay nagbabahagi ng prefix tulad ng 192.168.0.0/24, walang ruta ang makakapaghiwalay sa kanila. Bawat packet para sa saklaw na iyon ay may isang resulta ng paghahanap, at ang pag-aayos ay muling bilangin ang isang panig o marating ang opisina sa pamamagitan ng isinaling address mula sa pool. Ang pagdaragdag ng mas tiyak na ruta ay naglilipat lamang kung aling kalahati ng network ang nasisira.

Tapusin sa isang beripikasyon sa halip na lima: kumonekta, pagkatapos patakbuhin ang tracert laban sa isang panloob at isang pampublikong host. Dapat mag-iba ang unang hop, at kung hindi, wala sa puwesto ang paghahati kahit ano pa ang iulat ng client. Pagkatapos kumonekta muli nang isang beses at ulitin, dahil bumabalik ang mga itinulak na ruta sa bawat session.