ایک ہی وقت میں دو VPN ایپس: کون سا kill switch واقعی لاگو ہوتا ہے؟
دوسرا VPN کلائنٹ پہلے کا kill switch کبھی وراثت میں نہیں پاتا۔ کون سی پالیسی لاگو ہوتی ہے، تین شرائط طے کرتی ہیں، اور اپنی کیسے جانچیں۔
دو VPN کلائنٹس ساتھ ساتھ چل سکتے ہیں، مگر اُن کے kill switch ایک ہی پالیسی میں نہیں ملتے۔ ہر کلائنٹ اپنی ٹنل کے لیے قواعد نصب کرتا ہے، اور کوئی بھی نہیں جانتا کہ دوسرا موجود ہے۔ مجھے یہ ایک ورک کلائنٹ کے ساتھ پیش آیا جو پہلے منسلک تھا: دوسری ایپ اپنا مصافحہ مکمل نہ کر سکی، دس منٹ «Connecting» پر رہی، اور پہلی ٹنل نے سب کچھ خاموشی سے اٹھا لیا۔ دوسری ایپ محفوظ ہوتی ہے یا نہیں، یہ تین شرائط پر منحصر ہے، اِس پر نہیں کہ دونوں آئیکنز منسلک کہیں۔
kill switch اصل میں کن باتوں تک محدود ہے
آپریٹنگ سسٹم میں کوئی واحد kill switch جھنڈا نہیں ہوتا۔ ایسا جھنڈا بیان کرنے والا کلائنٹ قواعد کا ایک مجموعہ نصب کرتا ہے: جو میری ٹنل سے باہر نہ جائے اُسے گرا دو، اور ٹنل غائب ہونے پر اکثر fail closed برتاؤ۔ لینکس پر یہ عموماً nftables یا iptables زنجیر ہوتی ہے، ونڈوز پر Windows Filtering Platform فلٹرز کا مجموعہ، اینڈرائیڈ اور iOS پر خود ٹنل سروس کی روٹنگ کے ساتھ وہ سسٹم سیٹنگ جو VPN کے بغیر روابط بلاک کرتی ہے۔ اینڈرائیڈ VPN رہنما اِس سروس ماڈل کو بیان کرتا ہے اگر آپ پلیٹ فارم کا نقطۂ نظر چاہیں۔
دائرہ کار ہی اہم حصہ ہے۔ «صرف wg0 آؤٹ پٹ انٹرفیس پر پیکٹوں کی اجازت دو» جیسا قاعدہ اِس بات کی پروا نہیں کرتا کہ دوسری ٹنل موجود ہے یا نہیں۔ اگر کوئی دوسرا کلائنٹ wg1 اٹھا لے تو پہلے کلائنٹ کے قواعد اُن پیکٹوں کو عام ٹریفک سمجھتے ہیں: عموماً گرا دیے جاتے ہیں، کبھی اجازت مل جاتی ہے۔ بہرحال فیصلہ پہلا کلائنٹ کرتا ہے، اور اُسے کوئی اندازہ نہیں کہ دوسری ایپ انتظار کر رہی ہے۔
تین شرائط جو طے کرتی ہیں کہ کون ڈھکا جائے گا
ہر امتزاج گننے کی ضرورت نہیں۔ تین سوال چند منٹ میں یہ طے کر دیتے ہیں۔
- کیا پلیٹ فارم کوئی دوسری ٹنل بھی اجازت دیتا ہے؟ زیادہ تر اینڈرائیڈ فونز اور آئی فونز فی صارف پروفائل صرف ایک فعال VPN سروس قبول کرتے ہیں، لہٰذا دوسری ایپ کو کبھی ٹنل نہیں ملتی اور وہ کچھ نافذ نہیں کرتی۔ آپ کو ایک ہی پالیسی ملتی ہے، اُس ایپ سے جس نے جگہ جیتی۔
- ڈیفالٹ روٹ کس پروسیس کی ملکیت ہے؟ ونڈوز، میک او ایس اور لینکس دو ٹنلیں آرام سے اٹھا لیتے ہیں۔ ڈیفالٹ روٹ اُس کلائنٹ کا ہوتا ہے جس نے اُسے آخری بار یا بہتر میٹرک کے ساتھ ترتیب دیا، اور دوسرا کلائنٹ منسلک مگر بیکار ہوتا ہے۔ لینکس پر wg-quick کا ڈیفالٹ روٹ موڈ نجی جدول اور fwmark قاعدے کے ساتھ پالیسی پر مبنی روٹنگ استعمال کرتا ہے، لہٰذا دوسری wg-quick ٹنل پہلی کو بدلنے کے بجائے ایک حریف قاعدہ شامل کرتی ہے۔
- کیا دوسرا کلائنٹ اپنے سرور تک پہنچ سکتا ہے؟ اگر پہلا kill switch ڈیفالٹ انکار ہے تو دوسری ایپ کا بیرونی اختتامی نقطہ محض ایک اور گرا ہوا ہدف ہے۔ وہ خاموشی سے دوبارہ کوشش کرتی ہے اور کبھی غلطی کی اطلاع نہیں دیتی۔
مختصر ورژن، سپورٹ تھریڈز کے لیے:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
اِن سطروں میں سے دو سسٹم ٹرے کے آئیکن سے یکساں نظر آتی ہیں، اور اِسی لیے آئیکن یہاں دستیاب بدترین ثبوت ہے۔
سب سے پہلے کیا ناکام ہوتا ہے، اور کیسا دکھتا ہے
دوسرا صحت مند ہو اور ایک کلائنٹ «Connecting» پر پھنس جائے تو یہ تقریباً ہمیشہ اختتامی نقطے کی بھوک ہے: چل رہا kill switch دوسرے کلائنٹ کا اپنے سرور کی طرف مصافحہ گرا دیتا ہے۔ اِسے سستے طریقے سے یوں تصدیق کریں کہ پہلے کلائنٹ کے بلاک کرنے والے قواعد ایک کوشش کے لیے روک دیں۔ اگر دوسرا فوراً جڑ جائے تو سوال کا جواب مل گیا۔
DNS دوسری ناکامی ہے۔ کلائنٹس حل کنندہ کی ترتیب اپنے انٹرفیس کے لیے رکھتے ہیں، اور بعض عالمی فہرست کو یکسر اوپر لکھ دیتے ہیں۔ دونوں ٹنلیں اٹھی ہوں تو سوالات ایک طرف سے نکل سکتے ہیں جبکہ حل کنندہ دوسری طرف کا ہو۔ کوئی بھی ایپ منقطع کریں تو بچ جانے والا ناقابلِ رسائی نام سرور رکھتا ہے: صفحات ایک منٹ کے لیے رک جاتے ہیں پھر دوبارہ حل ہوتے ہیں، جبکہ VPN اب بھی منسلک دکھاتی ہے۔
تیسری بات روٹوں کی لہر ہے۔ دوبارہ رابطے ڈیفالٹ روٹ کو نئے سرے سے ترتیب دیتے ہیں، اور انٹرفیس سے بندھا kill switch اُس کی پیروی نہیں کرتا۔ وہ ٹریفک جو لمحے پہلے ٹنل میں تھی اب گرانے والے قاعدے سے مطابقت رکھتی ہے، جو صارف کی طرف سے ایسے VPN کے طور پر پڑھی جاتی ہے جو اتفاقاً کام کرنا چھوڑ دیتا ہے۔
جانچیں کہ کون سی پالیسی واقعی نافذ ہے
یہ بے ضرر ٹریفک کے ساتھ کریں، ایسی چیز کے ساتھ نہیں جس کی کمی محسوس ہو۔
لینکس پر کرنل سے پوچھیں کون جیتتا ہے اور فائر وال کس چیز سے بندھی ہے۔ ip -4 route show default اُس ٹنل کا نام لیتا ہے جو اخراج کی مالک ہے۔ ip rule show دکھاتا ہے کہ پالیسی پر مبنی روٹنگ کھیل میں ہے یا نہیں۔ sudo nft list ruleset | grep -n oifname دکھاتا ہے کہ گرانے والے عمل انٹرفیس نام، نشان یا پوری آؤٹ پٹ زنجیر سے بندھے ہیں۔
ونڈوز پر وہی کہانی روٹ میٹرک اور فلٹر فہرست میں رہتی ہے: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric اور Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN"۔ میک او ایس پر، netstat -rn -f inet | head -5 اور scutil --dns | head -20۔
پھر وہ قدم اٹھائیں جو لوگ چھوڑ دیتے ہیں: ٹنل جان بوجھ کر بند کریں اور تصدیق کریں کہ جس ٹریفک کے ناکام ہونے کی توقع ہے وہ واقعی ناکام ہوتی ہے۔ منسلک آئیکن انٹرفیس کی حالت ہے، نفاذ نہیں۔
کب دو کلائنٹس غلط ڈیزائن ہیں
اگر دوسری ایپ کے پیچھے واحد تقاضا زیادہ تحفظ ہے تو اُسے ہٹا دیں۔ دو متعامل بلاکنگ پالیسیاں ایک سے کم پیشگی قابلِ اندازہ ہوتی ہیں، اور ہر دوبارہ رابطہ ایسی حالت میں پھنسنے کا موقع ہے جسے کوئی وینڈر آزماتا نہیں۔
اگر واقعی زنجیر سازی درکار ہو، مثلاً تجارتی چھلانگ سے پہنچنے والا کارپوریٹ گیٹ وے، تو ایک نفاذ نقطے والا ڈیزائن چنیں۔ اس کا مطلب عموماً ایک راؤٹر یا ایک ایسا کلائنٹ ہے جو زنجیر کی تائید کرے، نہ کہ دو ڈیسک ٹاپ ایپس جو ایک ہی ڈیفالٹ روٹ پر مقابلہ کریں۔ منظم ڈیوائس پر منظور شدہ کلائنٹ رکھیں اور باقی سب کو دائرہ کار سے باہر سمجھیں، ٹرے میں جو بھی دکھائے۔
دونوں رکھنے سے پہلے چیک لسٹ
فہرست ترتیب سے طے کریں؛ پہلا ناکام ہونے والا بند وہی ہے جسے درست کرنا ہے۔
- تصدیق کریں کہ بالکل ایک کلائنٹ ڈیفالٹ روٹ اور حل کنندہ کا مالک ہے۔
- اگر دوسرا کلائنٹ اٹھا رکھنا چاہیں تو اُس کے سرور کا اختتامی نقطہ واضح طور پر اجازت دیں اور ہر کلائنٹ اپ ڈیٹ کے بعد دوبارہ جانچیں۔
- جب کوئی ٹنل گرے تو متوقع نتیجہ لکھیں اور بالکل وہی صورت آزمائیں۔
- دوبارہ آغاز کے بعد ناکامی کا راستہ جانچیں، جب آغاز کی ترتیب مختلف ہو۔
- منظم پروفائل پر رک جائیں اور کچھ شامل کرنے سے پہلے مالک سے پوچھیں۔
اگر تیسرا قدم ناکام ہو تو سچا جواب یہ ہے کہ صرف ایک کلائنٹ آپ کو پالیسی دے رہا ہے۔ طے کریں کہ کس پر بھروسا ہے اور دوسرے کو جانے دیں۔