તમે ટનલમાંથી બહાર રાખેલી એપને તમારો કિલ સ્વિચ બ્લોક કરશે?
બહાર કાઢેલી એપ ઇરાદાપૂર્વક સીધી જઈ શકે છે, જ્યારે સુરક્ષિત એપ નિષ્ફળ થાય ત્યારે બંધ રહેવી જોઈએ. પહેલાં દરેક એપ માટે નીતિ લખો, પછી ક્લાયન્ટ શું લાગુ કરે છે તે તપાસો.
કિલ સ્વિચ ચાલુ, એક એપ ઇરાદાપૂર્વક ટનલમાંથી બહાર કાઢેલી, અને બંને જરૂરિયાતો હવે એકબીજાથી વિરોધાભાસી છે. એક કહે છે કે ટનલ સિવાય કંઈ બહાર જઈ શકે નહીં, બીજી કહે છે કે આ પ્રોગ્રામ સીધો જવો જોઈએ. દરેક ક્લાયન્ટ આ વિરોધાભાસ જુદી રીતે ઉકેલે છે, અને સેટિંગ્સ પૃષ્ઠ ભાગ્યે જ જણાવે છે કે કયો નિયમ જીતે છે. કોઈપણ લેબલ પર ભરોસો કરતા પહેલાં દરેક એપ માટે નીતિ લખો.
બે નીતિઓ, એક મશીન
કિલ સ્વિચ નિષ્ફળતા વિશેનું વચન છે: જ્યારે ટનલ ટ્રાફિકનું રક્ષણ કરતી નથી, ત્યારે ટ્રાફિક અટકે છે. વિભાજિત ટનલ પસંદગી વિશેનું વચન છે: આ પ્રોગ્રામો કે ગંતવ્યો ટનલ વાપરે છે, અને તે નહીં. બીજું વચન એવો ટ્રાફિક બનાવે છે જેના વિશે પહેલાને નિર્ણય લેવો પડે. બંનેમાંથી કોઈ વચન ખોટું નથી; તેઓ ફક્ત જુદા લોકોએ જુદા ખતરાઓ માટે લખ્યાં છે.
ત્રણ પરિણામો શક્ય છે અને તેમાંથી માત્ર એક જ તે છે જે તૈનાતીનો ઇરાદો હતો. બહાર કાઢેલી એપ વિક્ષેપ દરમિયાન સીધી રહી શકે છે, જે વિભાજનને માને છે અને કિલ સ્વિચ તોડે છે. તેને બાકીની બધી વસ્તુઓ સાથે બ્લોક કરી શકાય છે, જે કિલ સ્વિચને માને છે અને વિભાજન તોડે છે. અથવા તે ફક્ત ક્યારેક બ્લોક થઈ શકે છે, ઇન્ટરફેસ અદૃશ્ય થયા પછી પ્લેટફોર્મ નિયમનું મૂલ્યાંકન કેવી રીતે કરે છે તેના આધારે. તે છેલ્લો કિસ્સો જ ટિકિટ પેદા કરે છે.
નિયમ પહેલાં એપની યાદી લખો
જે પ્રોગ્રામોને ટનલ વાપરવી પડે, જેમને સીધા જવું પડે, અને જે નામો કે ગંતવ્યો ક્યારેય કોઈ પણ યાદીમાં ન દેખાવા જોઈએ તેમની યાદી બનાવો. રિઝોલ્વરનું વર્તન અને IPv6 બાજુ અલગ રીતે સામેલ કરો, કારણ કે બંને પૃષ્ઠ ટ્રાફિક કરતાં જુદી નીતિ અનુસરી શકે છે.
એપ દીઠ નિયમો સામાન્ય રીતે એક્ઝિક્યુટેબલ ફાઇલ કે પેકેજ સાથે મેળ ખાય છે, તેની અંદરની પ્રોફાઇલ સાથે નહીં. બ્રાઉઝર પ્રોફાઇલ, ખાનગી વિન્ડો અને એક્સ્ટેન્શન પોતાની નેટવર્ક ઓળખ ધરાવતા નથી, તેથી પ્રોસેસને જે મળ્યું તે તેઓ વારસામાં લે છે. તે બ્રાઉઝરે શરૂ કરેલી સહાયક પ્રોસેસ સમાન નિયમ વારસામાં ન પણ લે.
એક નહીં, બે યાદીઓ જરૂરી છે: ટનલે શું વહન કરવું જોઈએ, અને શું કોઈપણ કારણસર તેની બહાર મુસાફરી ન કરવી જોઈએ. બંનેમાં દેખાતી એપ લાગુ કરવાની વિગત નહીં પણ જરૂરિયાતનો વિરોધાભાસ છે, અને ક્લાયન્ટ ગોઠવતા પહેલાં તેને ઉકેલવો પડે.
વિક્ષેપ દરમિયાન ક્લાયન્ટ શું કરે છે
કેટલાક અમલીકરણો વિક્ષેપ દરમિયાન બહાર કાઢેલી એપને બ્લોક કરે છે અને ફરી જોડાતા તેમની ઍક્સેસ પુનઃસ્થાપિત કરે છે. અન્ય લોકો સીધો માર્ગ આખો સમય જાળવી રાખે છે, જે વિભાજન સાથે સુસંગત છે અને સુરક્ષા ગુણધર્મ તરીકે નબળો છે. પ્લેટફોર્મ સ્તરનું લોકડાઉન ક્લાયન્ટની એપ દીઠ પસંદગીને સંપૂર્ણપણે ઓવરરાઇડ કરી શકે છે. તે તફાવત દેખાવનો નથી, કારણ કે તે નક્કી કરે છે કે બહાર કાઢેલી એપ નીતિનો અપવાદ છે કે છિદ્ર.
Androidનું હંમેશા ચાલુ VPN, VPN વગરના કનેક્શન બ્લોક કરવાના વિકલ્પ સાથે, સૌથી સ્પષ્ટ કિસ્સો છે, કારણ કે લોકડાઉન ક્લાયન્ટ નહીં પણ પ્લેટફોર્મ લાગુ કરે છે, અને ટનલ બંધ હોય ત્યારે બહાર કાઢેલું પેકેજ બાકીની બધી વસ્તુઓ સાથે બ્લોક થાય છે. જે ડેસ્કટોપ ક્લાયન્ટ પોતાના ડ્રાઇવરમાં એપ દીઠ બાકાત લાગુ કરે છે તે સામાન્ય રીતે બહાર કાઢેલી પ્રોસેસને ભૌતિક ઇન્ટરફેસ પર છોડી દે છે, કારણ કે શરૂઆતથી તે પ્રોસેસના ટ્રાફિકનો માલિક ન હતો. બંને વર્તન સમર્થનીય છે અને તેમાંથી માત્ર એક જ એવી જરૂરિયાત સાથે મેળ ખાય છે જે કહે છે કે બહાર કાઢેલી એપ વપરાશયોગ્ય રહેવી જોઈએ. પરિણામનું અર્થઘટન કરતા પહેલાં પૂછો કે કયો ઘટક નિયમ લાગુ કરે છે.
તમારી સામેની ઓપરેટિંગ સિસ્ટમ માટેનું વર્તન વાંચો, બીજે જગ્યાએ સમાન નામનું સેટિંગ નહીં. અમલ કરાવવાના API અલગ છે, અને એક ચેકબોક્સ ડેસ્કટોપ પર અને ફોન પર સંપૂર્ણ જુદા અર્થ આપી શકે છે. આવૃત્તિ પણ મહત્વની છે, કારણ કે લોકડાઉન નિયંત્રણ Android આવૃત્તિઓ દરમિયાન સ્ક્રીનો વચ્ચે ખસ્યું છે, અને ક્લાયન્ટ બાજુની બાકાત યાદી પ્લેટફોર્મ લોકડાઉન જેટલું જ નિયંત્રણ નથી.
ત્રણ ક્ષણો: ટનલ ચાલુ, ટનલ બંધ, ફરી જોડાણ
ત્રણ ક્ષણોમાં નિરુપદ્રવી વિનંતીઓ વાપરો: ટનલ કામ કરતી હોય ત્યારે, તમને મહત્વની હોય તેવી નિષ્ફળતા દરમિયાન, અને ફરી જોડાયા પછી. એક બ્રાઉઝર પરિણામ બહાર કાઢેલી એપનું વર્તન સ્થાપિત કરી શકતું નથી.
curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com
બહિર્ગમન સરનામું બતાવે છે કે કયો માર્ગ લેવાયો, અને સ્પષ્ટ ઇન્ટરફેસ પરીક્ષણ બતાવે છે કે જ્યારે ટનલ જ એકમાત્ર ઉપલબ્ધ નિકાસ હોય ત્યારે શું થાય છે. કોઈપણ ચલાવતા પહેલાં દરેક લીટીની બાજુમાં અપેક્ષિત પરિણામ લખો, અન્યથા આઉટપુટનું અર્થઘટન પછીથી થશે.
બહાર કાઢેલી એપ ઑફલાઇન થાય તો, પહોળી ફાયરવોલ પરવાનગી ઉમેરતા પહેલાં નીતિની પ્રાથમિકતા તપાસો, કારણ કે તે સુધારો તમે પરીક્ષણ કરી રહ્યા હતા તે તફાવતનો નાશ કરે છે. જો તે સીધી રહે, તો ખાતરી કરો કે તે દસ્તાવેજીકૃત બાકાત હતી અને આકસ્મિક પતન નહીં. આખા ઉપકરણ માટે કડક જરૂરિયાત હોય તો બાકાત યાદી ટૂંકાવો જ્યાં સુધી હાથે પરીક્ષણ થઈ શકે.