Loka reto neatingebla dum la VPN estas konektita? Kvar kontroloj

La tunelo ekfunkcias, la enreta reto aperas, kaj la printilo ĉesas respondi. Nenio en la loka reto paneis; la kliento ŝanĝis la vojon, kiun ĝi uzas por adresoj, kiujn ĝi ne plu traktas kiel lokaj. Trairu la kvar kontrolojn sube en ordo kaj haltu, kiam unu montras konkretan malkongruon, ĉar la sama simptomo havas kvar oftajn kaŭzojn kaj nur unu el ili ripariĝas per redaktado de la VPN.

Unue, rigardu la enkursigan tabelon, kiun la kliento instalis

Malfermu la enkursigan tabelon de la kliento dum la VPN estas konektita. En Linux uzu ip route, en Windows uzu route print aŭ Get-NetRoute, kaj en macOS uzu netstat -rn. Vi serĉas defaŭltan vojon tra la tunelo kaj tion, kio okazis al la fizika defaŭlta vojo.

Kliento de plena tunelo ofte aldonas du duondefaŭltajn vojojn, 0.0.0.0/1 kaj 128.0.0.0/1, anstataŭ anstataŭigi 0.0.0.0/0. La origina defaŭlta vojo restas videbla sed perdas ĉiun serĉon, kaj tial la tabelo povas aspekti sendifekta dum la tuta trafiko ekster la subreto moviĝas. Se la VPN-kliento proponas opcion de dividita tunelo kaj la politiko permesas ĝin, tio estas la plej pura riparo.

Se la tunelo devas resti la defaŭlta vojo, anstataŭe fiksu la lokan subreton. En Linux la vojo nomas la fizikan interfacon kaj la pordegon; en Windows aldonu -p por igi ĝin daŭra kaj legu la interfacan numeron el route print anstataŭ diveni ĝin:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Fiksita vojo teniĝas nur dum la adreso, kiun ĝi nomas, restas la sama. Portebla komputilo, kiu renumerigas sian Wi-Fi-adaptilon ĉe ĉiu konekto, denove rompos la regulon, do kontrolu la interfacan adreson antaŭ ol decidi, ke la riparo malsukcesis.

Due, konfirmu, ke la adreso estis loka jam komence

Se la celo estas ene de la konektita subreto, la defaŭlta vojo de la tunelo neniam aplikiĝas kaj la VPN ne estas la kaŭzo. Printilo ĉe 192.168.1.40 ĉe kliento kun 192.168.1.0/24 uzas la konektitan vojon; se tiu adreso malsukcesas, rigardu la aparaton, la ŝaltilon aŭ la fajroŝirmilon sur la kliento anstataŭ la VPN.

La kazo, kiu trompas homojn, estas publika adreso por loka servilo. De ene de la loka reto, atingi la WAN-adreson de la enkursigilo kaj reveni postulas harpinglan NAT, kaj multaj enkursigiloj simple ne realigas ĝin por pordaj plusendoj. Testu la privatan adreson apud la publika. Se la privata adreso funkcias kaj la publika ne, la VPN nur malkaŝis NAT-limigon, kiu jam ekzistis.

Gastigna nomo plimalbonigas tion. Se la loka nomo nun solviĝas al la publika adreso, la kliento daŭre provos la vojon, kiu ne povas reiri. Uzu la privatan adreson por la testo, poste riparu la nomon anstataŭ aldoni plian pordan plusendon.

Trie, vidu, kiu nun respondas al nomoj

Entreprena solvilo konas la enretan reton kaj kutime nenion pri NAS-gastigna nomo, la Bonjour-nomo de printilo aŭ la loka kaŝnomo de enkursigilo. Kiam la VPN puŝas siajn DNS-servilojn, tiuj nomoj ĉesas solviĝi eĉ se iliaj adresoj ankoraŭ atingeblas. Demandu la nomon rekte kaj komparu la respondon kun la adreso, kiun vi scias, ke la aparato havas.

En Linux, resolvectl query nas.local montras, kiu solvilo respondis. En Windows, nslookup nas.local nomas la servilon, kaj ipconfig /all montras la ordon de la solviloj. Se la loka sufikso nun estas traktata de la entreprena solvilo, aŭ reenigu tiun sufikson al la loka solvilo aŭ uzu la IP-adreson de la aparato.

Malkovro estas aparta tavolo. mDNS kaj dissendo ne trapasas enkursigitan tunelon, do aparato povas esti atingebla per adreso dum ĝia nomo restas nevidebla. Reflektilo aŭ loka DNS-enskribo solvas tion; vojo ne.

Kvare, kontrolu, ĉu ankaŭ la alia maŝino estas en VPN

Kiam la maŝino, kiun vi volas atingi, ankaŭ rulas VPN-klienton, via sesio povas alveni dum ĝia respondo eliras tra la alia tunelo. Tio produktas konekton, kiu establiĝas kaj poste haltas, aŭ provon de RDP kaj SSH, kiu finiĝas pro tempolimo sen ia ajn eraro ĉe via flanko. Kontrolu la enkursigan tabelon de la alia gastiganto kaj ĝian defaŭltan vojon antaŭ ol kulpigi vian klienton.

Kontrolu ankaŭ la adreson, sur kiu la servo aŭskultas. Aŭskultanto ligita nur al la tunela adreso akceptas konektojn el la VPN kaj rifuzas ilin el la loka reto, eĉ kiam enkursigo estas perfekta. Tio estas serva agordo, ne reta vojo, kaj ĝi oftas ĉe administradaj interfacoj, kiuj estis ŝlositaj al la VPN-adreso.

Tenu administran vojon, kiu ne dependas de la tunelo: statika vojo nomanta vian fontan reton, alia interfaco konektita al la loka reto, aŭ konzolo, kiu tute preterlasas la tunelon. Projekti tiun vojon post kiam la sesio falis estas multe pli malfacile ol aldoni ĝin antaŭ la sekva konekto.

Apliku la riparaĵon kongruan kun la kontrolo, kiu malsukcesis

Se la enkursiga tabelo montris duondefaŭltan kaptadon, elektu dividitan tunelon kiam politiko permesas kaj fiksitan lokan vojon kiam ĝi ne permesas. Se la adreso montriĝis publika, ŝanĝu la teston kaj la nomon al la privata adreso. Se la solvilo ŝanĝis manojn, limigu la lokan sufikson aŭ uzu la adreson. Se la alia gastiganto estas tunela, riparu ĝian revenvojon aŭ ĝian aŭskultantan ligon.

Ŝanĝu unu aferon, poste ripetu la saman kontrolon. Vojo aldonita por malĝusta subreto, solvila sufikso kun tajperaro kaj fiksita vojo sur interfaco, kiu renumerigas, ĉiuj aspektas kiel la origina paneo. La ripetado estas tio, kio apartigas riparon de hazardaĵo.

Notu la vojon, la adreson kaj la solvilon, kiuj funkciis dum la VPN estis konektita. La sekva rekonekto ŝanĝos almenaŭ unu el ili, kaj la noto transformas la sekvan interrompon en mallongan komparon anstataŭ novan esploron.