VPN සම්බන්ධ වී ඇති විට දේශීය ජාලයට ළඟා විය නොහැකි ද? පරීක්ෂා හතරක්

ටනලය ඉහළ යයි, ඉන්ට්‍රානෙට් දිස්වේ, මුද්‍රණ යන්ත්‍රය පිළිතුරු දීම නවත්වයි. LAN එකේ කිසිවක් කැඩී නැත; දැන් දේශීය ලෙස නොසැලකෙන ලිපින සඳහා සේවාලාභියා භාවිතා කරන මාර්ගය වෙනස් කර ඇත. පහත පරීක්ෂා හතර අනුපිළිවෙලින් කර එකක් පැහැදිලි නොගැළපීමක් පෙන්වූ විට නවතින්න, මන්ද එකම රෝග ලක්ෂණයට පොදු හේතු හතරක් ඇති අතර ඉන් එකක් පමණක් VPN සංස්කරණයෙන් නිරාකරණය වේ.

පළමුව, සේවාලාභියා ස්ථාපනය කළ මාර්ග වගුව බලන්න

VPN සම්බන්ධ වී ඇති විට සේවාලාභියාගේ මාර්ග වගුව විවෘත කරන්න. Linux හි ip route, Windows හි route print හෝ Get-NetRoute, macOS හි netstat -rn භාවිතා කරන්න. ඔබ සොයන්නේ ටනලය හරහා යන පෙරනිමි මාර්ගය සහ භෞතික පෙරනිමි මාර්ගයට සිදු වූ දේ ය.

සම්පූර්ණ ටනල සේවාලාභියා බොහෝ විට 0.0.0.0/0 ප්‍රතිස්ථාපනය කරනවාට වඩා අර්ධ පෙරනිමි මාර්ග දෙකක් එකතු කරයි: 0.0.0.0/1 සහ 128.0.0.0/1. මුල් පෙරනිමි මාර්ගය පෙනෙන්නට තිබුණත් සෑම සෙවුමකදීම පරාජය වේ, එබැවින් වගුව සම්පූර්ණ ලෙස පෙනුණත් උපජාලයෙන් පිටත සියලු රථවාහන ගමන් කරයි. VPN සේවාලාභියා බෙදූ ටනල විකල්පයක් දෙන්නේ නම් සහ ප්‍රතිපත්තිය අවසර දෙන්නේ නම්, එය වඩාත් පිරිසිදු අලුත්වැඩියාවයි.

ටනලය පෙරනිමි ලෙසම තිබිය යුතු නම්, ඒ වෙනුවට දේශීය උපජාලය ඇමිණන්න. Linux හි මාර්ගය භෞතික අතුරුමුහුණත සහ ද්වාරය නම් කරයි; Windows හි -p එකතු කර ස්ථිර කරන්න, සහ අතුරුමුහුණත අංකය අනුමාන නොකර route print වෙතින් කියවන්න:

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

ඇමිණූ මාර්ගය එය නම් කරන ලිපිනය එලෙසම පවතින තාක් පමණක් රැඳේ. සෑම සම්බන්ධතාවකදීම Wi-Fi අනුකරණයට නව අංකයක් ලැබෙන ලැප්ටොප් එකක නියමය නැවත කැඩේ, එබැවින් අලුත්වැඩියාව අසාර්ථක යැයි තීරණය කිරීමට පෙර අතුරුමුහුණතේ ලිපිනය පරීක්ෂා කරන්න.

දෙවනුව, එම ලිපිනය මුල සිටම දේශීය වූ බව තහවුරු කරන්න

ගමනාන්තය සම්බන්ධිත උපජාලය තුළ නම්, ටනලයේ පෙරනිමි මාර්ගය කිසි විටෙක යෙදෙන්නේ නැත සහ VPN හේතුව නොවේ. 192.168.1.0/24 සහිත සේවාලාභියා තුළ 192.168.1.40 හි මුද්‍රණ යන්ත්‍රය සම්බන්ධිත මාර්ගය භාවිතා කරයි; එම ලිපිනය අසාර්ථක නම් VPN නොව උපාංගය, ස්විචය හෝ සේවාලාභියාගේ ෆයර්වෝලය බලන්න.

මිනිසුන් රවටන අවස්ථාව වන්නේ දේශීය සේවාදායකයකට පොදු ලිපිනයක් දීමයි. LAN ඇතුළින් රවුටරයේ WAN ලිපිනයට ළඟා වී ආපසු ඒමට හෙයර්පින් NAT අවශ්‍ය වන අතර, බොහෝ රවුටර එය වරාය යොමු කිරීම සඳහා ක්‍රියාත්මක කරන්නේම නැත. පොදු ලිපිනයට යාබදව පෞද්ගලික ලිපිනය අත්හදා බලන්න. පෞද්ගලික ලිපිනය ක්‍රියා කර පොදු ලිපිනය නොකරන්නේ නම්, VPN කළේ කලින්ම තිබූ NAT සීමාවක් හෙළිදරව් කිරීමයි.

සත්කාරක නාමය මෙය තවත් නරක අතට හරවයි. දේශීය නාමය දැන් පොදු ලිපිනයට විසඳෙන්නේ නම්, ආපසු ඒමට නොහැකි මාර්ගයම සේවාලාභියා අත්හදා බලනු ඇත. පරීක්ෂාවට පෞද්ගලික ලිපිනය භාවිතා කර, පසුව තවත් වරාය යොමු කිරීමක් එකතු කරනවාට වඩා නාමය නිවැරදි කරන්න.

තෙවනුව, දැන් නාමවලට පිළිතුරු දෙන්නේ කවුරුන්ද යන්න බලන්න

ආයතනික විසඳුම්කරු ඉන්ට්‍රානෙට් දනී, නමුත් සාමාන්‍යයෙන් NAS සත්කාරක නාමය, මුද්‍රණ යන්ත්‍රයේ Bonjour නාමය හෝ රවුටරයේ දේශීය අන්වර්ථය ගැන කිසිවක් නොදනී. VPN තම DNS සේවාදායක තල්ලු කරන විට, එම ලිපින තවමත් ළඟා විය හැකි වුවත් එම නාම විසඳීම නවතී. නාමය සෘජුවම විමසා, උපාංගයට ඇති බව ඔබ දන්නා ලිපිනය සමඟ පිළිතුර සසඳන්න.

Linux හි resolvectl query nas.local කුමන විසඳුම්කරු පිළිතුරු දුන්නේද යන්න පෙන්වයි. Windows හි nslookup nas.local සේවාදායකය නම් කරයි, ipconfig /all විසඳුම්කරුවන්ගේ අනුපිළිවෙල පෙන්වයි. දේශීය උපසර්ගය දැන් ආයතනික විසඳුම්කරු විසින් හසුරුවන්නේ නම්, එම උපසර්ගය නැවත දේශීය විසඳුම්කරු වෙත යොමු කරන්න, නැතහොත් උපාංගය සඳහා IP ලිපිනය භාවිතා කරන්න.

සොයාගැනීම වෙනම ස්තරයකි. mDNS සහ විකාශන මාර්ගගත ටනලයක් හරහා නොයයි, එබැවින් උපාංගයක් ලිපිනයෙන් ළඟා විය හැකි වුවත් එහි නාමය නොපෙනී තිබිය හැක. පරාවර්තකයක් හෝ දේශීය DNS සටහනක් එය විසඳයි; මාර්ගයක් විසඳන්නේ නැත.

හතරවනුව, අනෙක් යන්ත්‍රය ද VPN එකක තිබේදැයි පරීක්ෂා කරන්න

ඔබට ළඟා වීමට අවශ්‍ය යන්ත්‍රය ද VPN සේවාලාභියෙකු ධාවනය කරන්නේ නම්, ඔබේ සැසිය පැමිණිය හැකි නමුත් එහි පිළිතුර අනෙක් ටනලය හරහා පිටවිය හැක. එයින් සම්බන්ධතාවයක් ගොඩනැගී පසුව ඇනහිටියි, නැතහොත් RDP සහ SSH උත්සාහය ඔබේ පැත්තේ දෝෂයක් නොමැතිව කාලය ඉක්මවා යයි. ඔබේ සේවාලාභියාට දොස් පැවරීමට පෙර අනෙක් සත්කාරකයේ මාර්ග වගුව සහ එහි පෙරනිමි මාර්ගය පරීක්ෂා කරන්න.

සේවාව සවන් දෙන ලිපිනය ද පරීක්ෂා කරන්න. ටනල ලිපිනයට පමණක් බැඳුණු ශ්‍රාවකය VPN වෙතින් එන සම්බන්ධතා පිළිගෙන LAN වෙතින් එන ඒවා ප්‍රතික්ෂේප කරයි, මාර්ගකරණය පරිපූර්ණ වුවත්. එය සේවා වින්‍යාසයකි, ජාල මාර්ගයක් නොවේ, සහ VPN ලිපිනයට අගුළු දැමූ කළමනාකරණ අතුරුමුහුණත්වල මෙය සාමාන්‍යයි.

ටනලය මත රඳා නොපවතින කළමනාකරණ මාර්ගයක් තබා ගන්න: ඔබේ මූලාශ්‍ර ජාලය නම් කරන ස්ථිතික මාර්ගයක්, LAN එකට සම්බන්ධ තවත් අතුරුමුහුණතක්, නැතහොත් ටනලය සම්පූර්ණයෙන් මගහරින කොන්සෝලයක්. සැසිය බිඳ වැටීමෙන් පසු එම මාර්ගය නිර්මාණය කිරීම ඊළඟ සම්බන්ධතාවට පෙර එය එකතු කිරීමට වඩා බොහෝ අපහසු ය.

අසාර්ථක වූ පරීක්ෂාවට ගැළපෙන අලුත්වැඩියාව යොදන්න

මාර්ග වගුව අර්ධ පෙරනිමි අත්පත් කරගැනීමක් පෙන්වූයේ නම්, ප්‍රතිපත්තිය අවසර දෙන විට බෙදූ ටනලය සහ නොදෙන විට ඇමිණූ දේශීය මාර්ගය තෝරන්න. ලිපිනය පොදු බව පෙනුණේ නම්, පරීක්ෂාව සහ නාමය පෞද්ගලික ලිපිනයට මාරු කරන්න. විසඳුම්කරු අත් මාරු කළේ නම්, දේශීය උපසර්ගයට සීමා කරන්න නැතහොත් ලිපිනය භාවිතා කරන්න. අනෙක් සත්කාරකය ටනලයේ නම්, එහි ආපසු මාර්ගය හෝ ශ්‍රාවක බැඳීම නිවැරදි කරන්න.

එක් දෙයක් වෙනස් කර, පසුව එම පරීක්ෂාවම නැවත කරන්න. වැරදි උපජාලයක් සඳහා එකතු කළ මාර්ගය, අකුරු දෝෂයක් සහිත විසඳුම්කරු උපසර්ගය සහ නව අංක ලබන අතුරුමුහුණතක ඇමිණූ මාර්ගය, සියල්ල මුල් දෝෂය මෙන් පෙනේ. අලුත්වැඩියාව සහ අහම්බය වෙන් කරන්නේ නැවත කිරීමයි.

VPN සම්බන්ධ වී ඇති විට ක්‍රියා කළ මාර්ගය, ලිපිනය සහ විසඳුම්කරු ලියා තබන්න. ඊළඟ නැවත සම්බන්ධ වීම ඒවායින් අවම වශයෙන් එකක් හෝ වෙනස් කරනු ඇත, සහ එම සටහන ඊළඟ බාධාව නව පරීක්ෂණයක් වෙනුවට කෙටි සංසන්දනයක් බවට පත් කරයි.