سرور بدلتے وقت kill switch ٹریفک کیوں روکتا ہے

آپ کوئی قریب نظر آنے والا سرور منتخب کرتے ہیں، جڑیں دباتے ہیں، اور نیا ٹنل اٹھنے سے پہلے ہی براؤزر لوڈ ہونا بند کر دیتا ہے۔ آئیکن جڑنے کی حالت میں بدل جاتا ہے اور ہر ٹیب کا وقت ختم ہونے تک وہیں رہتا ہے۔ یہ وقفہ عام طور پر kill switch کا ڈیزائن کے مطابق کام ہوتا ہے: ٹریفک اُس وقت تک بلاک رہتا ہے جب تک کلائنٹ کے پاس بھیجنے کے لیے ٹنل نہ ہو۔ وقفہ قابلِ قبول ہے یا نہیں، یہ اُن لمحوں میں کلائنٹ کیا کرتا ہے اور بلاک ہٹا ہوا کہنے پر واقعی ہٹتا ہے یا نہیں، اِس پر منحصر ہے۔

دو سرورز کے درمیان کلائنٹ کیا کرتا ہے

اینڈ پوائنٹ بدلنا ایک سوئچ نہیں، کئی مرحلے ہیں۔ کلائنٹ موجودہ ٹنل توڑتا ہے، اپنے بلاک کرنے کے قواعد اپ ڈیٹ کرتا ہے، نیا اینڈ پوائنٹ حل کر کے ٹنل سے باہر اُس تک پہنچتا ہے، پھر نئی راہیں لگاتا ہے اور بلاک ہٹاتا ہے۔ آپ جو وقفہ محسوس کرتے ہیں وہ پہلے اور آخری مرحلے کے درمیان ہوتا ہے۔

یہاں ترتیب رفتار سے زیادہ اہم ہے۔ اگر بلاک کرنے کے قواعد نئے اینڈ پوائنٹ کی رعایت سے پہلے نافذ ہو جائیں، تو کلائنٹ ہاتھ ملانے کا عمل مکمل نہیں کر سکتا اور وقت ختم ہونے تک جڑنے کی حالت میں رہتا ہے۔ اگر رعایت پرانے سرور کے پتے کی نقل ہو، تو نیا ہاتھ ملانا کسی بھی دوسرے باہر جانے والے پیکٹ جیسا دکھتا ہے اور خارج کر دیا جاتا ہے۔ دونوں صورتیں براؤزر سے ایک جیسی دکھتی ہیں، اسی لیے چھ سیکنڈ بعد سنبھلنے والی تبدیلی اور کبھی نہ سنبھلنے والی تبدیلی کی وجہ ایک ہو سکتی ہے۔

نئے اینڈ پوائنٹ کو بلاک میں سوراخ چاہیے

ٹنل بنانے کے لیے کلائنٹ کو طبعی انٹرفیس سے نئے سرور کے پتے اور پورٹ پر پیکٹ بھیجنے ہوتے ہیں، مثلاً عام WireGuard پروفائل کے لیے UDP 51820 یا OpenVPN کے لیے 1194 اور 443، جو بھی آپ کا پروفائل مقرر کرے۔ وہ ٹریفک اُس ٹنل کے اندر نہیں ہے جو ابھی بننے والا ہے، اس لیے پورے آلے کا بلاک اُسے نگل جاتا ہے، الا یہ کہ کوئی مماثل اجازت کا قاعدہ موجود ہو۔

میزبان نام پر مبنی پروفائل دوسری شرط شامل کرتے ہیں: تلاش بذاتِ خود۔ اگر کلائنٹ بلاک اٹھنے سے پہلے اینڈ پوائنٹ حل کر لے، تو وہ محفوظ شدہ پتہ استعمال کر سکتا ہے، لیکن جب پروفائل پتے بدلے یا محفوظ اندراج پرانا ہو جائے، تو ہاتھ ملانا ایسے پتے کی طرف جاتا ہے جسے اجازت کا قاعدہ نہیں ڈھانپتا۔ IPv6 اِسے نظر آنے والا بناتا ہے، کیونکہ دوہرے اسٹیک والا اینڈ پوائنٹ A اور AAAA دونوں ریکارڈ شائع کر سکتا ہے، اور صرف v4 پتہ ڈھانپنے والا اجازت کا قاعدہ کلائنٹ کو بلاک شدہ v6 پتے کے خلاف بار بار کوشش کرتا چھوڑ دیتا ہے۔

اختیارات کے نام اور طے شدہ اقدار کلائنٹ اور ورژن کے لحاظ سے بدلتی ہیں، اس لیے اسکرین شاٹس سے اندازہ لگانے کے بجائے اپنے لیے دستاویزی فہرست پڑھیں۔ OpenVPN Connect کی سیٹنگز کا حوالہ openvpn.net/connect-docs/app-settings-windows پر ایک مثال ہے کہ کلائنٹ اپنے بلاک اور منقسم ٹنل اختیارات کیسے بیان کرتا ہے۔

Fail-closed ایک حالت مشین ہے، سوئچ نہیں

زیادہ تر کلائنٹ بلاک کو فائر وال پالیسی کے طور پر تین حالتوں میں بیان کرتے ہیں: ٹنل اوپر، ٹریفک ٹنل سے گزر رہا ہے اور کوئی بلاک نہیں؛ ٹنل نیچے، بلاک فعال؛ اور منتقلی، بلاک فعال کے ساتھ اینڈ پوائنٹ کے لیے عارضی رعایات۔ تیسری حالت ہی میں خرابیاں رہتی ہیں، کیونکہ اُسے چند سیکنڈ میں دو بار بدلنا ہوتا ہے، اور اُس سے باہر نہ نکلنا بالکل مستقل بلاک جیسا دکھتا ہے۔

طریقہ کار پلیٹ فارم کے لحاظ سے مختلف ہے، اور ناکامی بھی۔ Windows Filtering Platform کے فلٹرز میں وزن ہوتا ہے، اس لیے آپ کی اجازت کو پیچھے چھوڑنے والا بلاک فلٹر اجازت ہونے کے باوجود پیکٹ گراتا رہتا ہے، اور مارے گئے کلائنٹ عمل نے چھوڑے فلٹرز ایپ جانے کے بعد بھی مشین کو آف لائن رکھ سکتے ہیں۔ macOS کلائنٹ عام طور پر pf قواعد کسی اینکر میں لکھتے ہیں، جہاں قواعد کی ترتیب اور تیز فیصلے طے کرتے ہیں کہ کون سا قاعدہ لاگو ہوگا۔ Linux کلائنٹ عام طور پر drop پالیسی والی nftables یا iptables زنجیر چلاتے ہیں اور اینڈ پوائنٹ، ٹنل انٹرفیس اور loopback کے لیے واضح اجازتیں دیتے ہیں۔ Android کا always-on VPN، VPN کے بغیر رابطے بلاک کرنے والے اختیار کے ساتھ، گروپ میں سب سے سخت ہے، کیونکہ آپریٹنگ سسٹم بلاک کو فی ایپ نہیں بلکہ پورے آلے پر لاگو کرتا ہے۔

WireGuard کو اپنا نوٹ چاہیے، کیونکہ AllowedIPs راستہ چننے والا ہے، بلاک کرنے والا نہیں۔ یہ طے کرتا ہے کہ کون سی منزلیں ٹنل میں جاتی ہیں؛ جو پیکٹ ابھی ٹنل نہیں رکھتا اُسے Wi-Fi سے باہر جانے سے روکنے کے لیے یہ کچھ نہیں کرتا۔ صرف WireGuard اور بغیر فائر وال قاعدے والی ترتیب میں kill switch دراصل راستے کا نہ ہونا ہے، اور خارج شدہ ہاتھ ملانے کے بعد طبعی انٹرفیس سے حقیقی پیکٹ باہر جا سکتا ہے۔

آئیکن دیکھنے کے بجائے وقفہ ناپیں

حالت کی بتی نہیں، پیکٹ دیکھیں۔ Linux میں ایک ٹرمینل میں کسی عوامی پتے پر سست ping شروع کریں اور دوسرے میں طبعی انٹرفیس پر ٹنل کا ٹرانسپورٹ پورٹ پکڑیں:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

دونوں چلتے ہوئے کلائنٹ میں سرور بدلیں۔ تین باتیں اہم ہیں: ping کتنی دیر رکتے ہیں، پکڑ یہ دکھاتی ہے کہ ہاتھ ملانا نئے اینڈ پوائنٹ تک پہنچتا ہے یا نہیں، اور ٹریفک کلائنٹ کی حالت جڑی ہونے سے پہلے واپس آتا ہے یا بعد میں۔ اگر ping کا وقفہ پہلے ختم ہو، تو یا بلاک جلدی ہٹ گیا ہے یا اشارے کے ماننے سے پہلے ہی ٹنل اوپر ہے۔ وقفہ دیر سے ختم ہو، تو اشارہ حد سے زیادہ امید پرست ہے۔

Windows میں netsh wfp show state ایک اسنیپ شاٹ لکھتا ہے، جس میں آپ ایسے بلاک فلٹر ڈھونڈ سکتے ہیں جو اب بھی موجود ہیں جبکہ کلائنٹ خود کو منقطع بتا رہا ہے۔ macOS میں sudo pfctl -sr لوڈ شدہ قواعد اور اُن کی ترتیب کی فہرست دیتا ہے۔ کوئی بھی اسنیپ شاٹ کلائنٹ کے اپنے لاگ سے ملا دیں؛ آپ کے ping کی ٹائم لائن بتاتی ہے کہ بلاک دیر سے ختم ہوا یا کبھی نہیں۔

عام اندھیرا بمقابلہ پھنسا ہوا بلاک

تھوڑی رکاوٹ اِس خصوصیت کا مقصد ہے، اس لیے کوئی بھی سیٹنگ بدلنے سے پہلے درجہ بندی کریں:

اگر آپ دوسری یا پانچویں سطر میں پڑیں، تو جانچ کے لیے kill switch بند نہ کریں، کیونکہ اِس سے راستے کی خرابی لیک بن جاتی ہے۔ کلائنٹ کی سروس دوبارہ شروع کریں، یا جہاں عمل مارنے کے بعد بھی فلٹر رہتے ہیں وہاں مشین دوبارہ بوٹ کریں، پھر دیکھیں کہ بلاک ہٹتا ہے یا نہیں۔ اگر ہٹ جائے، تو خرابی بلاک میں نہیں بلکہ تبدیلی کے دوران صفائی میں ہے۔

اگلی تبدیلی سے پہلے چار باتیں یقینی بنائیں: اینڈ پوائنٹ کی اجازت آپ کے پروفائل کے حل کردہ ہر پتہ خاندان کو ڈھانپتی ہے، کلائنٹ لاگ منتقلی مکمل ہونے کو دکھاتا ہے، آپ کی ping جانچ آئیکن نہیں بلکہ وقفہ ناپتی ہے، اور کلائنٹ بند کرنے سے عام رابطہ بحال ہوتا ہے۔ جو kill switch تبدیلی کے دوران قائم رہے اور بعد میں چھوڑے، وہ اپنا کام کرتا ہے۔ جو جلدی یا کبھی نہ چھوڑے، وہ ڈیبگ کرنے کے قابل ہے۔