Staðarnetið óaðgengilegt þegar VPN er tengt? Fjórar athuganir

Göngin koma upp, innra netið birtist og prentarinn hættir að svara. Ekkert á LAN-inu hefur bilað; biðlarinn breytti því hvaða leið hann notar fyrir netföng sem hann telur ekki lengur staðbundin. Farðu í gegnum fjórar athuganirnar hér að neðan í röð og stansaðu þegar ein þeirra sýnir áþreifanlegt misræmi, því sama einkennið hefur fjórar algengar orsakir og aðeins ein þeirra er lagað með því að breyta VPN-inu.

Fyrst skaltu skoða leiðatöfluna sem biðlarinn setti upp

Opnaðu leiðatöflu biðlarans meðan VPN er tengt. Á Linux skaltu nota ip route, á Windows route print eða Get-NetRoute, og á macOS netstat -rn. Þú ert að leita að sjálfgefinni leið í gegnum göngin og að því hvað varð um sjálfgefnu líkamlegu leiðina.

Biðlari með full göng bætir oft við tveimur hálfsjálfgefnum leiðum, 0.0.0.0/1 og 128.0.0.0/1, í stað þess að skipta út 0.0.0.0/0. Upprunalega sjálfgefna leiðin helst sýnileg en tapar hverri uppflettingu, sem er ástæðan fyrir því að taflan getur litið óskert út á meðan allur umferð utan undirnetsins færist til. Ef VPN-biðlarinn býður upp á valmöguleika fyrir klofin göng og stefnan leyfir það, er það hreinasta viðgerðin.

Ef göngin verða að vera sjálfgefna leiðin skaltu festa staðbundna undirnetið í staðinn. Á Linux nefnir leiðin líkamlega tengið og gáttina; á Windows skaltu bæta -p við svo hún varist og lesa tenginúmerið úr route print frekar en að giska á það:

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

Föst leið heldur aðeins á meðan netfangið sem hún nefnir er óbreytt. Fartölva sem fær nýtt númer á Wi-Fi-tenginguna við hverja tengingu mun brjóta regluna aftur, svo athugaðu netfang tengisins áður en þú ákveður að viðgerðin hafi mistekist.

Í öðru lagi, staðfestu að netfangið hafi verið staðbundið frá upphafi

Ef áfangastaðurinn liggur innan tengda undirnetsins, gildir sjálfgefna leið ganganna aldrei og VPN er ekki orsökin. Prentari á 192.168.1.40 á biðlara með 192.168.1.0/24 notar tengdu leiðina; ef það netfang bregst skaltu skoða tækið, rofann eða eldvegginn á biðlaranum í stað VPN.

Tilfellið sem blekkir fólk er opinbert netfang fyrir staðbundinn þjón. Innan LANsins krefst þess að ná WAN-netfangi beinagrindarinnar og koma aftur haftpinsa-NAT, og margir beinagrindar framkvæma það einfaldlega ekki fyrir port forwarding. Prófaðu einkanetið við hlið opinbera netfangsins. Ef einkanetið virkar og það opinbera ekki, þá leiddi VPN aðeins í ljós NAT-takmörkun sem var þegar til staðar.

Hýsilsnafn gerir þetta verra. Ef staðbundna nafnið leysist nú í opinbera netfangið mun biðlarinn halda áfram að prófa leiðina sem getur ekki komið aftur. Notaðu einkanetið fyrir prófið og lagfærðu síðan nafnið frekar en að bæta við annarri port forwarding.

Í þriðja lagi, sjáðu hver svarar nöfnum núna

Fyrirtækjauppflettir þekkir innra netið og yfirleitt ekkert um hýsilsnafn NAS, Bonjour-nafn prentara eða staðbundið samheiti beinagrindar. Þegar VPN ýtir DNS-þjónum sínum hætta þessi nöfn að leysast þótt netföngin séu enn aðgengileg. Flettaðu nafninu beint og berðu svarið saman við netfangið sem þú veist að tækið hefur.

Á Linux sýnir resolvectl query nas.local hvaða uppflettir svaraði. Á Windows nefnir nslookup nas.local þjóninn og ipconfig /all sýnir röð uppfletta. Ef staðbundna viðskeytið er nú í höndum fyrirtækjauppflettisins skaltu annaðhvort beina því viðskeyti aftur til staðbundna uppflettisins eða nota IP-töluna fyrir tækið.

Uppgötvun er sérstakt lag. mDNS og útvarp fara ekki yfir leiðsett göng, svo tæki getur verið aðgengilegt eftir netfangi á meðan nafnið er ósýnilegt. Endurkastari eða staðbundin DNS-færsla leysir það; leið gerir það ekki.

Í fjórða lagi, athugaðu hvort hin vélin er líka á VPN

Þegar vélin sem þú vilt ná í keyrir líka VPN-biðlara getur setan þín borist á meðan svarið fer út um hin göngin. Það framkallar tengingu sem kemst á fót og stöðvast svo, eða RDP- og SSH-tilraun sem rennur út án villu á þinni hlið. Athugaðu leiðatöflu hins hýsilsins og sjálfgefnu leið hans áður en þú kennir biðlaranum þínum um.

Athugaðu líka netfangið sem þjónustan hlustar á. Hlustandi sem er bundinn eingöngu við netfang ganganna tekur við tengingum frá VPN og hafnar þeim frá LAN, jafnvel þótt leiðsögnin sé fullkomin. Það er stilling þjónustunnar, ekki netlagnaleið, og er algeng á stjórnviðmótum sem voru læst við VPN-netfangið.

Haltu stjórnleið sem er ekki háð göngunum: kyrrstæðri leið sem nefnir upprunanetið þitt, öðru tengi sem er tengt LANinu, eða stjórnborði sem fer alveg fram hjá göngunum. Að hanna þá leið eftir að setan dettur út er mun erfiðara en að bæta henni við fyrir næstu tengingu.

Beittu þeirri viðgerð sem passar við athugunina sem mistókst

Ef leiðataflan sýndi hálfsjálfgefna yfirtöku skaltu velja klofin göng þegar stefnan leyfir og fasta staðbundna leið þegar hún leyfir það ekki. Ef netfangið reyndist opinbert skaltu skipta prófinu og nafninu yfir í einkanetið. Ef uppflettirinn skipti um hendur skaltu afmarka staðbundna viðskeytið eða nota netfangið. Ef hinn hýsillinn er í göngum skaltu laga afturleið hans eða bindingu hlustandans.

Breyttu einu atriði og endurtaktu síðan sömu athugun. Leið sem bætt var við fyrir rangt undirnet, uppflettisviðskeyti með innsláttarvillu og föst leið á tengi sem fær nýtt númer líta allt eins út og upprunalega bilunin. Endurtekningin er það sem greinir viðgerð frá tilviljun.

Skrifaðu niður leiðina, netfangið og uppflettinn sem virkuðu meðan VPN var tengt. Næsta endurtenging mun breyta að minnsta kosti einu þeirra, og athugasemdin gerir næstu niðurtöku að stuttum samanburði í stað nýrrar rannsóknar.