Always-on VPN કે kill switch: તમે ખરેખર કયું સક્રિય કર્યું?
Always-on VPN ટનલ ફરી જોડે છે; kill switch નક્કી કરે છે કે તેના વિના શું બહાર જઈ શકે. લેબલ પર ભરોસો કરતાં પહેલાં પાંચ ચકાસણી.
Always-on અને kill switch એક જ સેટિંગ્સ સ્ક્રીન પર બે લાઇનના અંતરે છે, તેથી લોકો તેમને એક ફીચરના બે નામ ગણે છે. તે નથી. Always-on ફરી કનેક્ટ થવાની નીતિ છે: બૂટ પર ટનલ શરૂ કરે, ક્રેશ કે નેટવર્ક બદલાવ પછી પાછી લાવે અને નિષ્ફળ જતાં ફરી પ્રયાસ કરે. Kill switch ટ્રાફિક નીતિ છે: ટનલ બંધ હોય ત્યારે કયા પેકેટ મશીન છોડી શકે તેનાં નામ આપે. પ્રથમને બીજા વિના સક્રિય કરી શકાય, અને મોટા ભાગના પ્લેટફોર્મ પર ડિફોલ્ટ પરિણામ ગેપ દરમિયાન ટ્રાફિક બહાર જવા દે છે.
ચકાસણી 1: બ્લોક પોતાનું સ્વિચ છે?
Android 10 અને પછીના વર્ઝનમાં સાચવેલી VPN પ્રોફાઇલ ગિયર આઇકોન પાછળ બે સ્વતંત્ર ટોગલ ખોલે છે: Always-on VPN અને VPN વિના કનેક્શન બ્લોક કરો. ફક્ત બીજું જ kill switch છે. ફક્ત always-on થી ટનલ ડ્રોપ પછી પાછી આવે છે, પણ વિનંતી વચ્ચે રહેલી કોઈ પણ એપ ત્યાં સુધી Wi-Fi કે મોબાઇલ ડેટાથી નેટવર્ક સુધી પહોંચે છે.
સંચાલિત ઉપકરણો નીતિ API માં એ જ વિભાજન રાખે છે. setAlwaysOnVpnPackage() પેકેજનું નામ અને lockdownEnabled ફ્લેગ લે છે; પેકેજ સેટ કરી ફ્લેગ ખોટો રાખનાર એડમિનિસ્ટ્રેટર કાયમી ટનલ બનાવે છે, બંધ ઉપકરણ નહીં. કન્સોલની ભાષા આ ફરક ભાગ્યે જ દેખાડે છે.
સ્થિતિ કન્સોલમાંથી નહીં, ઉપકરણમાંથી વાંચો: adb shell settings get global always_on_vpn_app અને adb shell settings get global always_on_vpn_lockdown. પ્રથમ null પરત કરે તો પ્લેટફોર્મ સ્તરે કોઈ પેકેજ લાદેલું નથી; બીજું 0 પરત કરે તો પ્લેટફોર્મ કંઈ બ્લોક કરતું નથી. Android VPN માર્ગદર્શિકા આને એક મોડ નહીં, અલગ ક્ષમતાઓ તરીકે વર્ણવે છે.
ચકાસણી 2: બ્લોક કયા સ્તરનું છે?
લેબલ ક્લાયન્ટમાં રહે છે અને બ્લોક સામાન્ય રીતે ફાયરવોલમાં, તેથી એક જ શબ્દ દરેક પ્લેટફોર્મ પર અલગ અર્થ ધરે છે. નીચેની પંક્તિઓ કોઈ પણ પર ભરોસો કરતાં પહેલાં ચકાસવા જેવી છે.
| Where you see the label | What the label promises | What actually blocks |
|---|---|---|
| Android VPN profile | Always-on VPN | Block connections without VPN |
| Android device policy | Always-on package | lockdownEnabled flag |
| Windows built-in VPN | Always On tunnel | Outbound firewall rules |
| WireGuard for Windows | Tunnel service | Block untunneled traffic option |
| wg-quick on Linux | Route via AllowedIPs | Your own nftables or iptables rules |
Windows એ બ્લોક ન કરતા લેબલનું સૌથી સ્પષ્ટ ઉદાહરણ છે. Always On ત્યાં ટનલની ટકાઉપણું બતાવે છે: મશીન પ્રમાણીકરણ માટે ડિવાઇસ ટનલ, સાઇન ઇન કરેલા ખાતા માટે યુઝર ટનલ, પ્રોફાઇલ XML કે Add-VpnConnection થી રૂપરેખાંકિત. ટનલ ન હોય ત્યારે તે પ્રોફાઇલમાં કંઈ પણ બહાર જતું પેકેટ રોકતું નથી, અને આઉટબાઉન્ડ ફિલ્ટરિંગ ડિફોલ્ટમાં ચાલુ નથી, તેથી Wi-Fi પરનું લેપટોપ VPN બંધ હોવા છતાં કામ ચાલુ રાખે છે.
WireGuard પણ એ જ રીતે વિભાજિત થાય છે, પણ ક્લાયન્ટ પ્રમાણે. Windows માટે WireGuard માં દરેક ટનલ માટે ટનલ વિનાનું ટ્રાફિક બ્લોક કરો વિકલ્પ છે જે ફિલ્ટર નિયમો સ્થાપે છે; Linux સાધનોમાં એવું સ્વિચ નથી. wg-quick દરેક AllowedIPs એન્ટ્રી માટે રૂટ અને fwmark નિયમ ઉમેરે છે, wg-quick down બંને દૂર કરે છે, તેથી ભૌતિક ડિફોલ્ટ રૂટ વચ્ચે પેકેટ ખોયા વિના ફરી સંભાળે છે.
Apple પ્લેટફોર્મ પર always-on દેખરેખ હેઠળના ઉપકરણો માટે મેનેજમેન્ટ પ્રોફાઇલ સુવિધા તરીકે આવે છે અને ચેકબોક્સ નહીં, ઓન-ડિમાંડ નિયમો તરીકે વ્યક્ત થાય છે. પેલોડમાંથી જવાબ માંગતો પ્રશ્ન: નિષ્ફળ ટનલ ટ્રાફિક નકારે છે કે ફક્ત બીજું કનેક્શન માંગે છે. મેનુનું શીર્ષક કહેશે નહીં.
ચકાસણી 3: ગેપ માપો, આઇકોન નહીં
ચાર સંક્રમણ મહત્વના છે, અને તે અલગ રીતે નિષ્ફળ જાય છે: કોઈ લોગિન કરે તે પહેલાં બૂટ, સ્લીપ અને જાગવું, Wi-Fi થી મોબાઇલ ડેટામાં બદલાવ, અને ટનલ ઇન્ટરફેસ અડધું રૂપરેખાંકિત રહે તેવું ક્લાયન્ટ ક્રેશ. એકમાં સ્વચ્છ પુનઃજોડાણ બાકીના ત્રણ વિશે કંઈ સાબિત કરતું નથી.
સૌથી સસ્તી કસોટી ટનલ જાણી જોઈને બંધ કરે છે અને પછી બહાર જવાનો પ્રયાસ કરે છે. ટનલ બંધ હોય ત્યારે curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com 200 પરત કરે તો નીતિ fail-open છે; ટાઇમઆઉટ કે નકારેલું કનેક્શન એટલે કંઈક હજી બ્લોક કરે છે. ip route get 1.1.1.1 પેકેટ લઈ જનારું ઇન્ટરફેસ નામ આપે છે, જે સામાન્ય રીતે ટ્રે આઇકોન કરતાં વધુ કહે છે, અને systemctl status wg-quick@wg0 ઇન્ટરફેસ સ્વચ્છ રીતે દૂર થયું કે નહીં તે બતાવે છે.
નેટવર્ક બદલાતું હોય ત્યારે જ બીજી વિન્ડોમાં એ જ પ્રોબ ચલાવો, ફક્ત પછી નહીં. ડ્રોપ અને ફરી પ્રયાસ વચ્ચેનો અંતરાલ મુખ્ય ભાગ છે, અને નામની શોધ એ ટ્રાફિક નાસી ગયો તે ધ્યાનમાં લેવાનો સૌથી ઝડપી રસ્તો છે: ટનલ બંધ હોય ત્યારે સ્થાનિક રિઝોલ્વર જવાબ આપે તો બ્લોક પૂર્ણ નથી.
ચકાસણી 4: લોક કરતાં પહેલાં અપવાદ નક્કી કરો
બે અપવાદ માળખાકીય છે. ક્લાયન્ટે VPN સર્વર સુધી પોતે પહોંચવું પડે, તેથી બધું ફેંકી દેતો નિયમ સેટ સુરક્ષા પાછી લાવતું પુનઃજોડાણ પણ રોકે છે. કેપ્ટિવ પોર્ટલ પણ ન ઊભેલી ટનલ દ્વારા પહોંચી શકાતું નથી, તેથી હોટેલ Wi-Fi પર લોક કરેલા ઉપકરણને પોર્ટલ ખોલવાનો દસ્તાવેજી રસ્તો જોઈએ, તાત્કાલિક નહીં.
ન્યૂનતમ આકાર, એન્ડપોઇન્ટ મંજૂર અને બાકી બધું ફેંકેલું:
table inet vpnlock {
chain output {
type filter hook output priority 0; policy drop;
oifname "lo" accept
ip daddr 203.0.113.10 udp dport 51820 accept
oifname "wg0" accept
}
}તે એન્ડપોઇન્ટ લાઇનને સ્થિર નહીં, ચલ તરીકે લો. પ્રદાતાઓ સરનામાં ફેરવે છે, અને જૂનો અપવાદ એ જ સામાન્ય કારણ છે કે કામ કરતું kill switch ફરી જોડાઈ ન શકતું ઉપકરણ બને છે. સ્થાનિક પ્રિન્ટર, NAS શેર અને ડેવલપમેન્ટ સેવાઓ એ જ લેખિત યાદીમાં આવે, નહીં તો એક એક સપોર્ટ ટિકિટે ખબર પડે.
ચકાસણી 5: ખરેખર શું સાબિત કર્યું તે નોંધો
ચાર કોલમનું કોષ્ટક રાખો અને પરીક્ષણ કરીને ભરો: સ્થિતિ, અપેક્ષિત વર્તન, જોયેલું વર્તન, પુરાવો. પંક્તિઓ ચકાસણી 3 ના સંક્રમણો અને એક જાણી જોઈને કરેલી નિષ્ફળતા છે. કમાન્ડના આઉટપુટથી ન ભરી શકાય તેવી પંક્તિ એ ન પરીક્ષણ કરેલી પંક્તિ છે, અને પુનઃજોડાણની પંક્તિ પાસ કરી બૂટની પંક્તિમાં નિષ્ફળ જતું ઉપકરણ એટલું સામાન્ય છે કે વધારાની દસ મિનિટ વસૂલ છે.
તેને પૂર્ણ કહેતાં પહેલાં:
- ખાતરી કરો કે બ્લોકિંગ સેટિંગ પુનઃજોડાણ સેટિંગથી અલગ છે, અને તેની કિંમત ઉપકરણ પર વાંચો.
- જાણો કે કયું સ્તર બ્લોક લાદે છે - ક્લાયન્ટ વિકલ્પ, ઉપકરણ નીતિ કે ફાયરવોલ - અને તે સ્તર ક્યાં રૂપરેખાંકિત થાય છે.
- બ્લોક સાબિત કરતો એક પ્રોબ કમાન્ડ રાખો, અને તેને સંક્રમણ દરમિયાન ચલાવો, પછી નહીં.
- અપવાદની યાદી લખો, એન્ડપોઇન્ટ સહિત, અને કોણ તેને તાજી કરે છે તે નોંધો.
- સંચાલિત હાર્ડવેર પર લાદેલી નીતિને એમ જ રહેવા દો; બ્લોક દૂર કરવો ટનલ સુધારવાને બદલે જરૂરિયાત બદલે છે.