VPN કનેક્ટ હોવા છતાં લોકલ નેટવર્ક પહોંચમાં નથી? ચાર તપાસ

ટનલ ઊભી થાય છે, ઇન્ટ્રાનેટ દેખાય છે, અને પ્રિન્ટર જવાબ આપવાનું બંધ કરે છે. લોકલ નેટવર્કમાં કંઈ નિષ્ફળ ગયું નથી; ક્લાયન્ટે એ સરનામાંઓ માટે વપરાતો માર્ગ બદલ્યો છે જેને તે હવે લોકલ ગણતું નથી. નીચેની ચાર તપાસ ક્રમમાં કરો અને જ્યારે એક ચોક્કસ અસંગતિ આપે ત્યારે અટકો, કારણ કે એ જ લક્ષણને ચાર સામાન્ય કારણો છે અને તેમાંથી માત્ર એક જ 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 નહીં, પણ ઉપકરણ, સ્વિચ કે ક્લાયન્ટનો ફાયરવોલ જુઓ.

લોકોને છેતરતો કિસ્સો લોકલ સર્વર માટેનું જાહેર સરનામું છે. લોકલ નેટવર્કની અંદરથી રાઉટરના 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 તરફથી કનેક્શન સ્વીકારે છે અને લોકલ નેટવર્ક તરફથી નકારે છે, રૂટિંગ પરફેક્ટ હોય ત્યારે પણ. એ સેવા રૂપરેખાંકન છે, નેટવર્ક માર્ગ નહીં, અને VPN સરનામે તાળું મારેલા મેનેજમેન્ટ ઇન્ટરફેસ પર એ સામાન્ય છે.

ટનલ પર આધાર ન રાખતો મેનેજમેન્ટ માર્ગ રાખો: તમારું સ્રોત નેટવર્ક જણાવતો સ્થિર રૂટ, લોકલ નેટવર્ક સાથે જોડાયેલું બીજું ઇન્ટરફેસ, અથવા ટનલને સંપૂર્ણ બાયપાસ કરતો કન્સોલ. સત્ર તૂટ્યા પછી એ માર્ગ રચવો આગલા કનેક્શન પહેલાં ઉમેરવા કરતાં ઘણો અઘરો છે.

જે તપાસ નિષ્ફળ ગઈ તેને અનુરૂપ સુધારો લાગુ કરો

જો રૂટ કોષ્ટકે અર્ધ-ડિફોલ્ટ કબજો દેખાડ્યો હોય, તો નીતિ પરવાનગી આપે ત્યારે સ્પ્લિટ ટનલ અને ન આપે ત્યારે પિન કરેલો લોકલ રૂટ પસંદ કરો. જો સરનામું જાહેર નીકળે, તો પરીક્ષણ અને નામ ખાનગી સરનામે બદલો. જો રિઝોલ્વર બદલાયું હોય, તો લોકલ સફિક્સ મર્યાદિત કરો અથવા સરનામું વાપરો. જો બીજો હોસ્ટ ટનલમાં હોય, તો તેનો પરત માર્ગ કે લિસનરનું બંધન સુધારો.

એક વસ્તુ બદલો, પછી એ જ તપાસ ફરીથી કરો. ખોટા સબનેટ માટે ઉમેરેલો રૂટ, જોડણી ભૂલવાળું રિઝોલ્વર સફિક્સ અને ફરી નંબર મેળવતા ઇન્ટરફેસ પરનો પિન કરેલો રૂટ—બધા મૂળ ખામી જેવા દેખાય છે. પુનરાવર્તન જ સુધારાને સંયોગથી અલગ પાડે છે.

VPN કનેક્ટ હોય ત્યારે જે રૂટ, સરનામું અને રિઝોલ્વર કામ કરતા હતા તે લખી રાખો. આગલું પુનઃકનેક્શન તેમાંથી ઓછામાં ઓછું એક બદલશે, અને નોંધ આગલી ખામીને નવી તપાસને બદલે ટૂંકી સરખામણી બનાવે છે.