VPN એપ ક્રેશ થઈ: શું તમારો કિલ સ્વિચ હજુ ચાલુ છે?
ક્રેશ બ્લોકને જગ્યાએ રાખી શકે છે અથવા પ્રોસેસ સાથે દૂર કરી શકે છે, તે કોણ લાગુ કરે છે તેના પર આધાર રાખે છે. નક્કી કરતા પહેલા ક્લાયન્ટ, ઓપરેટિંગ સિસ્ટમ અને ફાયરવોલ તપાસો.
જ્યાં વપરાશકર્તા શરૂ કરે છે ત્યાંથી શરૂ કરો: ક્લાયન્ટ વિન્ડો ગઈ, ટ્રે આઇકન ગાયબ થઈ, અને બ્રાઉઝર કાં તો લોડ કરે છે કાં તો નહીં. એકલું આ નિરીક્ષણ તમને કહી શકતું નથી કે બ્લોક ટકી ગયો કે નહીં. જવાબ એના પર આધાર રાખે છે કે કયો ઘટક નિયમો રાખે છે, એ ઘટક વિન્ડો સાથે મરી ગયો કે નહીં, અને પ્લેટફોર્મ અમલ એપની બહાર રાખે છે કે નહીં. વિન્ડોથી પ્રોસેસ સુધી, પછી ફાયરવોલ સુધી, પછી વાસ્તવિક માર્ગ સુધી જાઓ.
પહેલા રીબૂટ કરશો નહીં; રીબૂટ સામાન્ય રીતે પુરાવા નષ્ટ કરે છે.
જે હજુ ચાલે છે ત્યાંથી શરૂ કરો
કંઈપણ સ્પર્શ કરતા પહેલા પ્રોસેસ યાદી ખોલો. ડેસ્કટોપ ક્લાયન્ટ સામાન્ય રીતે વપરાશકર્તા ઇન્ટરફેસ પ્રોસેસ અને સેવા કે ડિમનમાં વિભાજિત થાય છે, અને પહેલાનો ક્રેશ બીજાને જરૂરી રીતે અટકાવતો નથી. Windows પર સેવા હજુ યાદીમાં હોઈ શકે, Linux પર યુનિટ હજુ સક્રિય હોઈ શકે, અને Android પર સંમતિ આપ્યા પછી ટનલ સિસ્ટમની માલિકીની હોય છે. એ ત્રણ હકીકતો એ જ ક્રમમાં વાંચો.
જો ડિમન જીવતું હોય, તો ટનલ પણ સંભવતઃ જીવતી છે, અને ખોવાયેલી વિન્ડો ફક્ત દેખાવની છે.
Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40
બ્લોકને એપમાંથી નહીં, લાગુ કરનાર પાસેથી વાંચો
જો ક્લાયન્ટ ફાયરવોલ નિયમો દાખલ કરીને તેનો કિલ સ્વિચ લાગુ કરે છે, તો એ નિયમો ઓપરેટિંગ સિસ્ટમના છે અને તેમને બનાવનાર પ્રોસેસ પછી પણ ટકી રહે છે. પછી ક્રેશ તમને બંધ કરવા માટે કોઈ ઇન્ટરફેસ વગર બ્લોક થયેલા મૂકી દે છે, જે સુરક્ષા કરતાં તૂટેલા નેટવર્ક જેવું લાગે છે. જો બ્લોક ક્લાયન્ટના પોતાના પેકેટ માર્ગની અંદર હોય, તો પ્રોસેસ મારવાથી બ્લોક એ જ ક્ષણે દૂર થાય છે.
Android આને ફરીથી અલગ રીતે સંભાળે છે: lockdown સાથે always-on VPN પ્લેટફોર્મ સેટિંગ છે, તેથી બ્લોક એપ પ્રોસેસથી સ્વતંત્ર રહે છે, અને સિસ્ટમ સેવા ફરી શરૂ કરી શકે છે. ડેસ્કટોપ ક્લાયન્ટ સાથે મેળ ખાય છે એમ ધારવાને બદલે ચોક્કસ વર્તન માટે પ્લેટફોર્મ દસ્તાવેજો જુઓ.
સ્વચ્છ એક્ઝિટને ક્રેશથી અલગ પાડો
સામાન્ય Quit સામાન્ય રીતે ક્લાયન્ટનો શટડાઉન માર્ગ ચલાવે છે, જે નિયમો દૂર કરે છે અને ટનલ જાણી જોઈને બંધ કરે છે. ક્રેશ એ માર્ગ છોડી દે છે અને લાગુ કરનાર પહેલેથી જ ઇન્સ્ટોલ કરેલું બધું છોડી દે છે. તફાવત પ્રોસેસના પ્રસ્થાનની તુલનામાં નિયમોના ટાઇમસ્ટેમ્પમાં અને માલિક વગરનું જૂનું ટનલ ઇન્ટરફેસ હજુ છે કે નહીં તેમાં દેખાય છે.
એ તફાવત તમારી પુનઃપ્રાપ્તિ નક્કી કરે છે: સ્વચ્છ એક્ઝિટને નવા કનેક્શનની જરૂર પડી શકે, જ્યારે ક્રેશને બાકીના નિયમો ક્લાયન્ટની સમર્થિત સમારકામ ક્રિયા દ્વારા દૂર કરવાની જરૂર પડી શકે.
અન્ય નિયંત્રણો તોડ્યા વિના પુનઃપ્રાપ્ત કરો
ક્લાયન્ટને તેના દસ્તાવેજીકૃત વર્કફ્લો દ્વારા ફરી શરૂ કરો, પછી જરૂરિયાતના બંને ભાગ ચકાસો: ટનલ ટ્રાફિક વહન કરે છે, અને બ્લોક જ્યારે જોઈએ ત્યારે હજુ લાગુ પડે છે. કનેક્ટિવિટી પાછી મેળવવા આખું ફાયરવોલ ફ્લશ કરવાથી અસંબંધિત નિયંત્રણો પણ જાય છે, અને એ બદલો ભાગ્યે જ યોગ્ય છે.
વારંવાર ક્રેશ માટે ક્લાયન્ટ સંસ્કરણ, પ્લેટફોર્મ બિલ્ડ અને વેન્ડર માંગે તે મર્યાદિત લોગ એકઠા કરો. બીજા ખાતા માટે ક્લાયન્ટ પ્રોફાઇલ, ખાનગી કી કે સંપૂર્ણ કનેક્શન લોગ ક્રેશ રિપોર્ટ માટે જરૂરી નથી, અને તેને સામેલ કરવાથી સપોર્ટ કેસ ડેટા હેન્ડલિંગ સમસ્યા બની જાય છે.
એક ક્રેશ લિકનો પુરાવો નથી. પુરાવો એ નીતિને રોકવાની હતી તેવા માર્ગેથી નીકળતું જોવા મળેલું પેકેટ છે, જે ક્લાયન્ટ બંધ હતો તે ક્ષણે કેદ થયું. તેને જાણી જોઈને, નિર્દોષ લક્ષ્ય સાથે પરીક્ષણ કરો, અને કયો અમલ સ્તર ટક્યો તે લખો.