બહાર નીકળવું કે ડિસ્કનેક્ટ: VPN ના બે અલગ પરિણામો

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

ક્લાયન્ટનું દસ્તાવેજીકરણ એ જ એકમાત્ર વિશ્વસનીય જગ્યા છે જ્યાંથી ખબર પડે કે કયું શું છે.

ચાર નિયંત્રણો, કદાચ ચાર વર્તણૂકો

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

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

સર્વર બાજુનો વિક્ષેપ સાવ પાંચમો માર્ગ છે, અને વપરાશકર્તાઓને વાસ્તવમાં સૌથી વધુ એ જ મળે છે.

દરેક ક્રિયા પહેલાં અને પછી સ્થિતિ વાંચો

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

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

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

હાથે ડિસ્કનેક્ટ કરવું ક્રેશ નથી

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

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

તમને ખરેખર જે અનુપલબ્ધ સ્થિતિની જરૂર છે તે પસંદ કરો

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

જો ધ્યેય સામાન્ય સીધી ઍક્સેસ હોય, તો પ્રોસેસ મારવાને બદલે અથવા આખું ફાયરવોલ બંધ કરવાને બદલે દસ્તાવેજીકૃત નિયંત્રણ વાપરો. અટકેલી નિકાસ પછી રહેલા જૂના નિયમો જાણી જોઈને કરેલા લૉકડાઉન કરતાં અલગ સમસ્યા છે, અને તેમને અલગ પુનઃપ્રાપ્તિની જરૂર છે.

કયું ઘટક અટક્યું તે લખો: ટનલ, દૃશ્યમાન એપ્લિકેશન, કે નીતિ લાગુ કરતું સ્તર. એ એક વાક્ય આ નિયંત્રણો સર્જતી મોટા ભાગની મૂંઝવણ અટકાવે છે.