ઇન્ટરનેટ ફક્ત VPN એપ સાથે જ ચાલે છે? ચાર સ્તરો તપાસો

તમે એક અઠવાડિયું મફત VPN ક્લાયન્ટ કે બ્રાઉઝર એક્સટેન્શન વાપરો છો, તેને બંધ કરો છો, અને ઇન્ટરનેટ બંધ થઈ જાય છે. Wi-Fi આઇકન હજી પણ કનેક્શન બતાવે છે, એ જ રાઉટર પરના બીજા ઉપકરણો બરાબર ચાલે છે, અને બ્રાઉઝિંગ પાછું લાવે છે તેવું એકમાત્ર એ છે કે એપ ફરી ચાલુ કરો અથવા તેને અનઇન્સ્ટોલ કરો. એ પેટર્ન એન્ક્રિપ્શનથી બનેલી અવલંબન નથી. એ એવી સેટિંગ્સ છે જે એપે એવી જગ્યાએ લખી છે જેની માલિકી ટનલ પાસે નથી.

ક્લાયન્ટ એ સેટિંગ્સ બદલે છે જેની માલિકી ટનલ પાસે નથી

Windows કે macOS પરનો ગોપનીયતા ક્લાયન્ટ સામાન્ય રીતે એક સાથે ત્રણ જગ્યાએ સ્પર્શ કરે છે. તે સિસ્ટમનો HTTP પ્રોક્સી સેટ કરે છે, એ જ ફીલ્ડ જે Internet Options દર્શાવે છે. તે વર્ચ્યુઅલ એડેપ્ટર, ઘણી વાર TAP ડ્રાઇવર, ઇન્સ્ટોલ કરે છે જેથી પેકેટ પકડી શકે. અને તે રિઝોલ્વરની યાદી ફરીથી લખે છે, જ્યારે ડિસ્કનેક્ટ દબાવવાથી ફક્ત ટનલ જ અદૃશ્ય થાય છે.

બ્રાઉઝર એક્સટેન્શન વધુ સાંકડી વસ્તુ છે. તે સામાન્ય રીતે પોતાની પ્રોફાઇલ કે જે પ્રોક્સી એક બ્રાઉઝર અનુસરે છે તે બદલે છે. એટલે જ એક બ્રાઉઝર નિષ્ફળ થઈ શકે જ્યારે કમાન્ડ-લાઇન સાધનો કામ કરતાં રહે, અથવા ઊલટું: એક્સટેન્શન પાસે બીજા સ્તરોને સ્પર્શવાનો અધિકાર ક્યારેય નહોતો. તેણે કયું સ્તર સંપાદિત કર્યું તે નક્કી કરે છે કે કયાં સાધનો તૂટે છે.

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

ત્રણ અવશેષો, ત્રણ જુદી જુદી નિષ્ફળતાઓ

પહેલો અવશેષ એ પ્રોક્સી છે જે ક્યાંય નથી જતું: LAN પ્રોક્સીનું બોક્સ હજી ટિક થયેલું છે, અથવા કન્ફિગરેશન સ્ક્રિપ્ટનું URL એવા localhost પોર્ટ તરફ છે જ્યાં હવે કોઈ પ્રક્રિયા સાંભળતી નથી. બ્રાઉઝર દરેક વિનંતી એ મૃત પોર્ટ પર મોકલે છે અને ત્યાં સુધી અટકી જાય છે જ્યાં સુધી સમયસીમા મૃત નેટવર્ક જેવી ન લાગે. બીજો એ એડેપ્ટર છે જે હજી ડિફોલ્ટ રૂટ ધરાવે છે, કારણ કે TAP-Windows ઉપકરણ કે વેન્ડરનો રાઉટિંગ ડ્રાઇવર અનઇન્સ્ટોલ પછી પણ વાસ્તવિક ઇન્ટરફેસ રહે છે. તેને આપેલો રૂટ રાખે છે, અને ટ્રાફિક એવી ટનલમાં અદૃશ્ય થાય છે જે ત્યાં નથી. બંનેમાંથી કોઈ અવશેષ પોતાની જાહેરાત કરતું નથી; બંને બરાબર આઉટેજ જેવા દેખાય છે.

ત્રીજું DNS છે, અને તે બીજા બે કરતાં વહેલું નિષ્ફળ જાય છે. જો રિઝોલ્વરની યાદીમાં ફક્ત ટનલ દ્વારા પહોંચી શકાય તેવા સર્વર હોય, તો એક પણ પૃષ્ઠ મંગાવાય તે પહેલાં દરેક શોધ સમયસીમા વીતી જાય છે, તેથી બ્રાઉઝર મૃત પ્રોક્સીને બદલે પહોંચી ન શકાય તેવી સાઇટ જણાવે છે. તમારી પાસે તેમાંથી કોઈ પણ હોય, તેમાંથી એક પણ નેટવર્ક અર્થમાં આઉટેજ નથી. દરેક એ અવશેષ છે જે કોઈએ રદ કર્યું નથી, અને દરેક જુદી જગ્યાએ સમારવામાં આવે છે.

ચાર સ્તરો નીચે કામ કરો

એપ્લિકેશનની સૌથી નજીકથી શરૂ કરો અને નીચે જાઓ, કારણ કે સ્તરો એ જ દૃશ્યતાના ક્રમમાં નિષ્ફળ જાય છે. દરેક પરીક્ષણમાં એક સ્તર બદલો, અને દરેક પછી ફરી પરીક્ષણ કરો. બધું એકસાથે રીસેટ કરવાથી સામાન્ય રીતે બ્રાઉઝિંગ પાછું આવે છે, અને તે તમને એ કહેવામાં અસમર્થ બનાવે છે કે કયા અવશેષે તે કર્યું, તેથી આગલી ઇન્સ્ટોલ એ જ કોયડો ફરી બનાવે છે. ક્રમ છે પ્રોક્સી, એડેપ્ટર, રૂટ, રિઝોલ્વર.

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

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux અને macOS ને પોતાના આદેશો જોઈએ છે, અને તે એકબીજાના બદલે વાપરી શકાતા નથી. Linux પર રૂટ ip route માંથી અને રિઝોલ્વર resolvectl status માંથી આવે છે જ્યાં systemd-resolved તેનો માલિક છે, અને cat /etc/resolv.conf પર પાછા ફરે છે. macOS પર રૂટ netstat -rn માંથી, રિઝોલ્વર scutil --dns માંથી અને સિસ્ટમ પ્રોક્સી scutil --proxy માંથી આવે છે. ip route ચલાવનાર macOS વાચકને command not found મળે છે, અને ત્યાં /etc/resolv.conf એ જનરેટ થયેલું સ્ટબ છે, સત્તાવાર રૂપરેખાંકન નહીં. સ્તર તપાસતાં પહેલાં પ્લેટફોર્મ તપાસો, નહીં તો પહેલો આદેશ જ શોધ બની જાય છે.

દરેક સ્તરને એક પ્રશ્ન પૂછો: જ્યારે એપ બંધ હોય ત્યારે પણ આ મૂલ્ય હજી એવી કોઈ વસ્તુ તરફ છે જે અસ્તિત્વમાં છે? મૃત પોર્ટ પરનું પ્રોક્સી, ટનલ વગરનું એડેપ્ટર, બંધ ઇન્ટરફેસ દ્વારા ડિફોલ્ટ રૂટ અને ટનલની અંદરનું રિઝોલ્વર, બધા ના જવાબ આપે છે. કોઈ પણ એક ના લક્ષણ સમજાવવા પૂરતું છે, અને એટલે જ દરેક પરીક્ષણમાં એક જ ફેરફાર મહત્ત્વનો છે.

પ્રોક્સી ટનલ નથી

પ્રોક્સી વિનંતી સ્વીકારે છે, તેને બીજે લાવે છે અને જવાબ પાછો આપે છે, એટલે તે ગંતવ્ય જાણે છે અને સાઇટે પોતે એન્ક્રિપ્ટ ન કરેલું બધું જુએ છે. તે બીજા પ્રોટોકોલ વહન કરતું નથી. જ્યાં સુધી ગંતવ્ય પહેલેથી TLS વાપરતું ન હોય ત્યાં સુધી તે માર્ગનું રક્ષણ કરતું નથી. અને તેને ઇન્સ્ટોલ કરનાર કંઈ પણ તમારી ભાગીદારી વગર તેને બદલી શકે છે.

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

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

ઘટક દૂર કરો, પુરાવા નહીં

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

જો આગલું ક્લાયન્ટ ઇન્સ્ટોલ કર્યા પછી લક્ષણ પાછું આવે, તો સેવાએ કંઈક તોડ્યું છે એમ નક્કી કરતાં પહેલાં ચાર સ્તરો ફરી ચાલો. પુરાવા સામાન્ય રીતે હજી એ ચાર જગ્યાઓમાંની એકમાં હોય છે. બીજી એપ પાંચમું સ્તર બનાવતી નથી; તે ચારમાંથી એકને સંપાદિત કરે છે.

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