Always-on VPN بمقابلہ kill switch: آپ نے اصل میں کون سا فعال کیا؟

Always-on اور kill switch ایک ہی ترتیبات کی اسکرین پر دو لائنوں کے فاصلے پر ہوتے ہیں، اس لیے لوگ انہیں ایک ہی خصوصیت کے دو نام سمجھتے ہیں۔ ایسا نہیں ہے۔ Always-on دوبارہ جڑنے کی پالیسی ہے: بوٹ پر ٹنل شروع کریں، کریش یا نیٹ ورک کی تبدیلی کے بعد اسے واپس لائیں، اور ناکام ہونے تک دوبارہ کوشش کرتے رہیں۔ Kill switch ٹریفک کی پالیسی ہے: یہ بتاتا ہے کہ ٹنل بند ہونے پر کون سے پیکٹ اب بھی مشین سے باہر جا سکتے ہیں۔ آپ پہلا دوسرے کے بغیر فعال کر سکتے ہیں، اور زیادہ تر پلیٹ فارمز پر طے شدہ نتیجہ اس وقفے میں بھی ٹریفک باہر جانے دیتا ہے۔

جانچ 1: کیا بلاک اپنا الگ سوئچ ہے؟

Android 10 اور اس کے بعد، محفوظ شدہ VPN پروفائل گیئر آئیکن کے پیچھے دو آزاد ٹوگل کھولتا ہے: Always-on VPN اور Block connections without VPN۔ kill switch صرف دوسرا ہے۔ صرف always-on کے ساتھ ٹنل گرنے کے بعد واقعی واپس آتا ہے، اور درخواست کے درمیان موجود کوئی بھی ایپ اس وقت تک Wi-Fi یا موبائل ڈیٹا کے ذریعے نیٹ ورک تک پہنچ سکتی ہے۔

منظم ڈیوائسز پالیسی API میں وہی تقسیم رکھتی ہیں۔ setAlwaysOnVpnPackage() پیکج کا نام اور lockdownEnabled جھنڈا لیتا ہے؛ جو منتظم پیکج مقرر کر کے جھنڈے کو false چھوڑ دیتا ہے اس نے مستقل ٹنل بنایا ہے، بند ڈیوائس نہیں۔ کنسول کی عبارت یہ فرق شاذ و نادر ہی دکھاتی ہے۔

حالت کنسول کی بجائے ڈیوائس سے پڑھیں: adb shell settings get global always_on_vpn_app اور adb shell settings get global always_on_vpn_lockdown۔ اگر پہلا null لوٹاتا ہے تو پلیٹ فارم کی سطح پر کوئی پیکج نافذ نہیں؛ اگر دوسرا 0 لوٹاتا ہے تو پلیٹ فارم کچھ بھی بلاک نہیں کر رہا۔ Android VPN گائیڈ انہیں ایک موڈ کے بجائے الگ الگ صلاحیتوں کے طور پر بیان کرتی ہے۔

جانچ 2: بلاک کس پرت کی ملکیت ہے؟

لیبل کلائنٹ میں اور بلاک عام طور پر فائر وال میں رہتے ہیں، اسی لیے ایک ہی لفظ ہر پلیٹ فارم پر مختلف معنی دیتا ہے۔ نیچے دی گئی سطریں وہ ہیں جنہیں کسی ایک پر بھروسہ کرنے سے پہلے تصدیق کرنا مناسب ہے۔

Windows اس لیبل کی سب سے واضح مثال ہے جو بلاک نہیں کرتا۔ وہاں Always On ٹنل کے تسلسل کو بیان کرتا ہے: مشین کی توثیق کے لیے ڈیوائس ٹنل اور سائن ان شدہ اکاؤنٹ کے لیے صارف ٹنل، جو پروفائل XML یا Add-VpnConnection کے ذریعے ترتیب دی جاتی ہے۔ اس پروفائل میں کچھ بھی ٹنل نہ ہونے پر باہر جانے والا پیکٹ نہیں روکتا، اور آؤٹ باؤنڈ فلٹرنگ طے شدہ طور پر فعال نہیں، اس لیے Wi-Fi پر لیپ ٹاپ VPN بند ہونے پر بھی کام کرتا رہتا ہے۔

WireGuard بھی اسی طرح بٹتا ہے، لیکن کلائنٹ کے لحاظ سے۔ WireGuard for Windows میں ہر ٹنل کے لیے فلٹر قواعد نصب کرنے والا Block untunneled traffic اختیار ہے؛ Linux کے اوزار میں ایسا سوئچ نہیں۔ wg-quick ہر AllowedIPs اندراج کے لیے راستہ اور ایک fwmark قاعدہ شامل کرتا ہے، اور wg-quick down دونوں ہٹا دیتا ہے، اس لیے طبعی طے شدہ راستہ ایک بھی پیکٹ گرائے بغیر دوبارہ ذمہ داری لے لیتا ہے۔

Apple پلیٹ فارمز پر always-on نگرانی والے آلات کے لیے مینجمنٹ پروفائل کی خصوصیت کے طور پر آتا ہے اور چیک باکس کے بجائے on-demand قواعد کی صورت میں ظاہر ہوتا ہے۔ پے لوڈ سے جس سوال کا جواب دینا ہے وہ یہ ہے کہ ناکام ٹنل ٹریفک سے انکار کرتا ہے یا صرف دوسرا کنکشن مانگتا ہے۔ مینو کا عنوان یہ نہیں بتائے گا۔

جانچ 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 سرور تک پہنچنا ہوتا ہے، اس لیے سب کچھ گرا دینے والا قاعدہ مجموعہ اس دوبارہ جڑنے کو بھی روکتا ہے جو تحفظ واپس لائے گا۔ Captive portal بھی ایسے ٹنل سے نہیں پہنچا جا سکتا جو اٹھا نہ ہو، اس لیے ہوٹل کے 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 کی منتقلیاں اور ایک جان بوجھ کر ناکامی ہیں۔ جس سطر کو کمانڈ آؤٹ پٹ سے نہ بھر سکیں وہ آپ کی نہ جانچی گئی سطر ہے، اور جو ڈیوائس دوبارہ جڑنے والی سطر پاس کر کے بوٹ والی سطر میں ناکام ہوتی ہے وہ اتنی عام ہے کہ اضافی دس منٹ بنتے ہیں۔

اسے مکمل کہنے سے پہلے:

• یقینی بنائیں کہ بلاکنگ سیٹنگ دوبارہ جڑنے کی سیٹنگ سے الگ ہے، اور اس کی قدر ڈیوائس پر پڑھیں۔
• جانیں کہ بلاک کون سی پرت نافذ کرتی ہے - کلائنٹ آپشن، ڈیوائس پالیسی یا فائر وال - اور وہ پرت کہاں ترتیب دی جاتی ہے۔
• بلاک ثابت کرنے والی ایک جانچ کمانڈ رکھیں، اور اسے منتقلی کے دوران چلائیں، بعد میں نہیں۔
• استثناؤں کی فہرست اینڈ پوائنٹ سمیت لکھیں، اور نوٹ کریں کہ اسے کون تازہ کرتا ہے۔
• منظم ہارڈویئر پر نافذ پالیسی کو چھوڑ دیں؛ بلاک ہٹانا ٹنل ٹھیک کرنے کے بجائے ضرورت بدل دیتا ہے۔