Ĉu la printilo estas senkonekta, kiam la VPN konektiĝas? Kontrolu la enkursigan tabelon

Via tekkomputilo aliĝas al la firmaa VPN, kaj la printilo du metrojn for ĉesas respondi. Nenio ŝanĝiĝis ĉe la printilo, kaj la loka reto ne falis. Kio ŝanĝiĝis estas la enkursiga tabelo: la tunela adaptilo nun posedas vojon, kiu kovras la adreson de la printilo, do tiuj pakaĵoj eliras tra la VPN kaj alvenas ĉe kluzo, kiu tute ne scias, kie troviĝas via ebena reto. Trapasu la kvar kontrolojn sube laŭ ordo, kaj haltu ĉe la unua, kiu malsukcesas.

Paŝo unu: pruvu, ke la printilo ankoraŭ atingeblas en la LAN

Antaŭ ol vi tuŝos la enkursigadon, konfirmu, ke la aparato vivas por io, kio ne uzas la VPN. Petu telefonon en la sama Wi-Fi malfermi la retpaĝon de la printilo, aŭ pingu la adreson de alia maŝino en la ebena reto. Se la printilo ankaŭ tie ne respondas, la VPN estas hazardo kaj la kulpo kuŝas ĉe la printilo, ĝia Wi-Fi-asocio aŭ klienta izolado ĉe la alirpunkto.

Se ĝi respondas ĉie krom ĉe ĉi tiu tekkomputilo, vi havas enkursigadan aŭ nomrezolvan problemon, kiu loĝas en la tekkomputilo, kaj la sekva paŝo diras al vi, kiu el la du ĝi estas.

Paŝo du: trovu la vojon, kiun Windows fakte elektas

Ne legu la tabelon de supre suben kaj ne divenu. Demandu Windows, kiun rikordon ĝi elektas por la preciza adreso, kiu gravas al vi, kaj samtempe prenu la interfacan indekson.

Find-NetRoute -RemoteIPAddress 192.168.1.50
route print -4
tracert -d 192.168.1.50

Find-NetRoute presas la venkan vojon kaj ĝian interfacon, kaj tiuj estas la du faktoj, de kiuj dependas la resto. route print -4 montras la ĉirkaŭajn rikordojn, inkluzive de la du duon-defaŭltoj, kiujn instalas plentunelaj klientoj: 0.0.0.0/1 kaj 128.0.0.0/1, kiuj kune kovras la tutan IPv4-spacon sen iam anstataŭigi 0.0.0.0/0. /1 estas pli longa ol /0, sed via 192.168.1.0/24 estas eĉ pli longa, kaj tial mankanta LAN-vojo pli gravas ol la aserto de la tunelo mem.

Du reguloj decidas la respondon. La plej longa kongrua prefikso venkas unue, kaj inter rikordoj kun la sama prefikso venkas la pli malalta totala metriko, kie la totalo kunigas la vojometrikon kaj la interfacan metrikon. Se la elektita interfaco estas la tunelo, daŭrigu. Se ĝi estas la fizika adaptilo kaj trafiko ankoraŭ malsukcesas, haltu ĉi tie: via problemo estas nomrezolvado aŭ la propra alirlisto de la printilo, ne la VPN-vojo.

Paŝo tri: aldonu la plej mallarĝan vojon, kiu nomas kluzon kaj interfacon

La riparo estas unu rikordo, kiu direktas la adreson de la printilo al la loka enkursigilo ĉe la loka adaptilo. Rulu ĝin en altigita komandlinio kaj anstataŭigu la valorojn, kiujn vi ĵus legis.

route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 if 12 -p

La valoro de if estas la interfaca indekso de la fizika adaptilo. Ellasi ĝin estas la plej ofta kialo, ke la komando ŝajnas sukcesi kaj ŝanĝas nenion, ĉar kun du adaptiloj kapablaj atingi la saman sekvan salton Windows libere elektas tiun, kiun vi ne volis. La flago -p igas la rikordon daŭra, do ĝi postvivas restartigon anstataŭ morti kun la sesio.

Preferu gastigan vojon por la unuopa aparato anstataŭ vojon por la tuta 192.168.1.0/24. Subreta vojo estas pli larĝa ol la tasko bezonas, kaj ĝi kolizias en la momento, kiam ankaŭ la firmaa flanko uzas tiun prefikson: unu prefikso tiam havas du posedantojn, kaj kiu rikordo venkas, tio decidas, kiun reton vi efektive povas atingi.

En la alia direkto, se vi forviŝis la opcion de defaŭlta kluzo en la VPN-konekto por protekti la LAN, ankaŭ la foraj privataj prefiksoj ĉesas rezolviĝi. Aldonu vojojn por ili tra la VPN-interfaco same, aŭ la tunelo fariĝas ligo, kiu portas nenion.

Paŝo kvar: igi la escepton postvivi la sekvan konekton

Multaj firmaj klientoj reinstalas sian tutan vojaron ĉe ĉiu konekto kaj rekomputas interfacajn metrikojn dum tio, do vojo, kiu funkciis hieraŭ, povas esti superregita hodiaŭ. Post rekonekto, ripetu Find-NetRoute por la printilo kaj kontrolu, ke la interfaco ankoraŭ kongruas kun la fizika adaptilo. Se la rikordo malaperis, io forigas ĝin; daŭra vojo ne protektas vin kontraŭ agento, kiu balaas la tabelon. Planitaj taskoj, kiuj re-aldonas la vojon post kiam la VPN konektiĝas, estas la kutima solvo, kaj ili ankaŭ estas la solvo, kiu rompiĝas, kiam la adaptila indekso ŝanĝiĝas post doko aŭ pelila ĝisdatigo.

Observu IPv6 aparte. Kliento, kiu postulas nur la IPv4-defaŭlton, povas lasi la IPv6-defaŭltan vojon ĉe la fizika adaptilo, do printilo atingebla per IPv6 daŭre funkcias dum IPv4 malsukcesas, aŭ inverse. Testu per ping -4 kaj ping -6 antaŭ ol decidi, ke la enkursiga tabelo estas senkulpa.

Kion kostas al vi la loka fuĝvojo

Ĉiu vojo, kiu preterpasas la tunelon, estas truo en la promeso de la tunelo. Trafiko al tiu adreso ne plu pasas tra la firmaa kluzo, kio signifas neniun inspektadon, neniun protokoladon kaj neniun politikan plenumadon pri ĝi. Sur administrata aparato tio povas esti konformiga problemo anstataŭ prefero, do demandu, ĉu ekzistas oficiala escepto por dividita tunelo, antaŭ ol aldoni unu permane. Tenu vian tiel mallarĝa kiel la tasko kaj tiel mallongdaŭra kiel la situacio permesas.

Se la printilo respondos post la ŝanĝo, ripetu la kvar kontrolojn post via sekva rekonekto anstataŭ supozi, ke la riparo teniĝis. Se ĝi ne respondos, kaptu la eligon de Find-NetRoute antaŭ kaj post la konekto; la diferenco diras al vi, ĉu la kliento forigis la rikordon aŭ nur reordigis ĝin.