Mtandao wa ndani haufikiki wakati VPN imeunganishwa? Ukaguzi nne

Handaki linapanda, intranet inaonekana, na printa inaacha kujibu. Hakuna kilichoharibika kwenye LAN; mteja amebadilisha njia anayotumia kwa anwani ambazo hazionei tena kama za ndani. Fanya ukaguzi nne hapa chini kwa mpangilio na uache wakati mmoja unaonyesha kutolingana dhahiri, kwa sababu dalili hiyo hiyo ina sababu nne za kawaida na ni moja tu kati yao hutatuliwa kwa kubadilisha VPN.

Kwanza, angalia jedwali la njia ambalo mteja alisakinisha

Fungua jedwali la njia la mteja wakati VPN imeunganishwa. Kwenye Linux tumia ip route, kwenye Windows tumia route print au Get-NetRoute, na kwenye macOS tumia netstat -rn. Unatafuta njia chaguo-msingi kupitia handaki na kile kilichotokea kwa njia chaguo-msingi ya kimwili.

Mteja wa handaki kamili mara nyingi huongeza njia mbili za nusu chaguo-msingi, 0.0.0.0/1 na 128.0.0.0/1, badala ya kubadilisha 0.0.0.0/0. Njia chaguo-msingi ya awali inabaki kuonekana lakini inashindwa kila utafutaji, ndiyo sababu jedwali linaweza kuonekana salama wakati trafiki yote nje ya subnet inasogea. Ikiwa mteja wa VPN anatoa chaguo la handaki lililogawanywa na sera inaruhusu, hicho ni kirekebishaji safi zaidi.

Ikiwa handaki lazima libaki chaguo-msingi, bandika subnet ya ndani badala yake. Kwenye Linux njia inataja kiolesura cha kimwili na lango; kwenye Windows ongeza -p ili iwe ya kudumu na soma namba ya kiolesura kutoka route print badala ya kuikisia:

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

Njia iliyobandikwa hudumu tu wakati anwani inayoitaja inabaki ile ile. Kompyuta ya mkononi inayopata namba mpya ya adapta ya Wi-Fi kila inapounganishwa itavunja sheria tena, kwa hiyo angalia anwani ya kiolesura kabla ya kuamua kwamba kirekebishaji kimeshindwa.

Pili, hakikisha kwamba anwani ilikuwa ya ndani tangu mwanzo

Ikiwa lengwa liko ndani ya subnet iliyounganishwa, njia chaguo-msingi ya handaki haitumiki kamwe na VPN si sababu. Printa iliyo kwenye 192.168.1.40 kwa mteja mwenye 192.168.1.0/24 hutumia njia iliyounganishwa; ikiwa anwani hiyo inashindwa, angalia kifaa, swichi au firewall ya mteja badala ya VPN.

Kisa kinachowadanganya watu ni anwani ya umma kwa seva ya ndani. Kutoka ndani ya LAN, kufikia anwani ya WAN ya router na kurudi kunahitaji hairpin NAT, na router nyingi hazitekelezi hilo kwa uelekezaji wa bandari. Jaribu anwani ya kibinafsi kando ya ile ya umma. Ikiwa ya kibinafsi inafanya kazi na ya umma haifanyi, VPN ilifunua tu kikwazo cha NAT kilichokuwa tayari.

Jina la mwenyeji hufanya hali kuwa mbaya zaidi. Ikiwa jina la ndani sasa linatatuliwa hadi anwani ya umma, mteja ataendelea kujaribu njia isiyoweza kurudi. Tumia anwani ya kibinafsi kwa jaribio, kisha rekebisha jina badala ya kuongeza uelekezaji mwingine wa bandari.

Tatu, angalia nani anajibu majina sasa

Kitatuzi cha shirika kinajua intranet na kwa kawaida hakijui chochote kuhusu jina la mwenyeji la NAS, jina la Bonjour la printa au lakabu ya ndani ya router. VPN inaposukuma seva zake za DNS, majina hayo huacha kutatuliwa ingawa anwani zake bado zinafikika. Uliza jina moja kwa moja na linganisha jibu na anwani unayojua kifaa kinayo.

Kwenye Linux resolvectl query nas.local inaonyesha kitatuzi kilichojibu. Kwenye Windows nslookup nas.local inataja seva, na ipconfig /all inaonyesha mpangilio wa vitatuzi. Ikiwa kiambishi cha ndani sasa kinashughulikiwa na kitatuzi cha shirika, ama elekeza kiambishi hicho kurudi kwa kitatuzi cha ndani au tumia anwani ya IP kwa kifaa.

Ugunduzi ni tabaka tofauti. mDNS na utangazaji havuki handaki lililoelekezwa, kwa hiyo kifaa kinaweza kufikika kwa anwani wakati jina lake linabaki halionekani. Kiakisi au ingizo la DNS la ndani hutatua hilo; njia haitatui.

Nne, angalia ikiwa mashine nyingine pia iko kwenye VPN

Wakati mashine unayotaka kufikia pia inaendesha mteja wa VPN, kikao chako kinaweza kufika wakati jibu lake likitoka kupitia handaki lingine. Hilo huzalisha muunganisho unaojianzisha kisha kukwama, au jaribio la RDP na SSH linaloisha muda bila kosa upande wako. Angalia jedwali la njia la mwenyeji mwingine na njia yake chaguo-msingi kabla ya kulaumu mteja wako.

Angalia pia anwani ambayo huduma inasikiliza. Msikilizaji aliyefungwa tu kwa anwani ya handaki hukubali miunganisho kutoka VPN na kuikataa ile kutoka LAN, hata wakati uelekezaji ni kamili. Hiyo ni usanidi wa huduma, si njia ya mtandao, na ni kawaida kwenye violesura vya usimamizi vilivyofungwa kwa anwani ya VPN.

Weka njia ya usimamizi ambayo haitegemei handaki: njia tuli inayotaja mtandao wako wa chanzo, kiolesura kingine kilichounganishwa na LAN, au konsoli inayokwepa handaki kabisa. Kubuni njia hiyo baada ya kikao kuanguka ni vigumu zaidi kuliko kuiongeza kabla ya muunganisho unaofuata.

Tumia kirekebishaji kinacholingana na ukaguzi ulioshindwa

Ikiwa jedwali la njia lilionyesha unyakuzi wa nusu chaguo-msingi, chagua handaki lililogawanywa wakati sera inaruhusu na njia ya ndani iliyobandikwa wakati hairuhusu. Ikiwa anwani ilionekana kuwa ya umma, badilisha jaribio na jina hadi anwani ya kibinafsi. Ikiwa kitatuzi kimebadilisha mikono, weka kikomo kwa kiambishi cha ndani au tumia anwani. Ikiwa mwenyeji mwingine yuko kwenye handaki, rekebisha njia yake ya kurudi au ufungaji wa msikilizaji.

Badilisha kitu kimoja, kisha rudia ukaguzi huo huo. Njia iliyoongezwa kwa subnet isiyo sahihi, kiambishi cha kitatuzi chenye makosa ya herufi na njia iliyobandikwa kwenye kiolesura kinachopata namba mpya zote zinaonekana kama hitilafu ya awali. Kurudia ndiko kunakotenganisha kirekebishaji na bahati mbaya.

Andika njia, anwani na kitatuzi vilivyofanya kazi wakati VPN imeunganishwa. Muunganisho unaofuata utabadilisha angalau kimoja kati yao, na noti hiyo itageuza usumbufu unaofuata kuwa ulinganisho mfupi badala ya uchunguzi mpya.