کل سوئچ کسی بھی ٹریفک کے بہنے سے پہلے VPN سرور کو روکتا ہے
کل سوئچ کس مرحلے کو روکتا ہے: اینڈ پوائنٹ کی تلاش، بیرونی راستہ، واپسی کا راستہ اور پرانے پیر استثنائیں — اندازوں کی بجائے کاؤنٹروں کے ساتھ۔
کل سوئچ ایسی سمت میں ناکام ہوتے ہیں جس کی لوگ توقع نہیں کرتے: وہ ٹنل کے نیچے ہونے پر ٹریفک روکنے کے لیے بنائے گئے ہیں، اور ٹنل بنانے والے پیکٹ خود ٹریفک ہیں۔ یہی پوری خرابی ہے۔ جو قواعد کا مجموعہ ہر اس چیز کو پھینک دیتا ہے جو ٹنل سے باہر نہیں جاتی، وہ اس ہینڈ شیک کو بھی پھینک دیتا ہے جو اسے اوپر اٹھانا تھا، اس لیے کلائنٹ لوپ میں دوبارہ کوشش کرتا ہے اور خرابی اسی مرحلے سے منسوب ہوتی ہے جو پہلے جانچا جاتا ہے۔ فائر وال کو وسیع کرنے سے پہلے معلوم کریں کہ تین مراحل میں سے کون سا مسترد ہو رہا ہے: نام کی تلاش، پیر کی طرف بیرونی پیکٹ، یا واپس آنے والا جواب۔
ٹنل اور اس کی اپنی ترسیل ایک دوسرے پر کیسے منحصر ہیں
VPN کلائنٹ کو نیٹ ورک کی دو حالتوں کے طور پر پڑھیں جو ایک ہی ساکٹ راستہ بانٹتی ہیں۔ ٹنل کے وجود سے پہلے کلائنٹ فزیکل اڈاپٹر پر ساکٹ کھولتا ہے اور خفیہ کردہ فریم پیر کے پتے اور پورٹ پر بھیجتا ہے۔ اسی تبادلے کی کامیابی کے بعد ہی وہ ٹنل ڈیوائس بناتا ہے اور راستے نصب کرتا ہے۔ کل سوئچ دوسری حالت کے بارے میں پالیسی ہے، اتنی وسیع لکھی گئی کہ دونوں پر لاگو ہو۔
انٹرفیس پر مبنی قواعد عام شکل ہیں: اس راستے سے باہر جانے والی چیز قبول کریں tun0 یا wg0، باقی آؤٹ پٹ راستہ پھینک دیں۔ یہ ساخت کلائنٹ کے اپنے سرور سے رابطے کو مستثنیٰ نہیں کر سکتی، اس لیے درست عمل درآمد وہ استثنا صریحاً شامل کرتا ہے، اور آپ بھی ہاتھ سے قواعد لکھتے وقت ایسا کرتے ہیں۔ Windows اور macOS پر فی ایپلیکیشن قواعد انٹرفیس کی بجائے پروسیس ملانے سے اس کا کچھ حصہ بچاتے ہیں، مگر پروسیس کو بھی ٹنل بننے سے پہلے باہر نکلنا ہوتا ہے۔
تین مراحل، اسی ترتیب میں جس میں ہوتے ہیں
پہلا مرحلہ حل ہے۔ جب پروفائل لفظی پتے کی بجائے ہوسٹ نام محفوظ کرتا ہے، تو کچھ بھیجنے سے پہلے کلائنٹ کو DNS جواب کی ضرورت ہوتی ہے۔ DNS کو ٹنل کے حل کنندہ کی طرف موڑنے والا پروفائل ایک تعطل بناتا ہے: حل کنندہ تک صرف اسی ٹنل سے پہنچا جا سکتا ہے جسے تلاش نے فعال کرنا تھا۔ ٹنل سے باہر حل کرنا، یا اینڈ پوائنٹ کو پتے پر پن کرنا، اس ابہام کو دور کرتا ہے۔
دوسرا مرحلہ بیرونی پیکٹ ہے، جسے اسی ترتیب میں پہلے روٹنگ اور پھر فائر وال عبور کرنی ہے۔ wireguard-tools WireGuard کے لیے اس کی روٹنگ کا نصف حصہ خود سنبھالتا ہے: اپنے پیکٹ نشان زد کرتا ہے اور ایک پالیسی قاعدہ شامل کرتا ہے تاکہ وہ ابھی نصب کردہ ڈیفالٹ راستہ چھوڑ دیں؛ wg-quick کا مینوئل صفحہ اس قاعدے اور اس جدول کی وضاحت کرتا ہے جو یہ استعمال کرتا ہے۔ اس روٹنگ کو ہاتھ سے دوبارہ بنائیں، یا دوسرے اوزار کو قواعد دوبارہ لکھنے دیں، تو نشان زد پیکٹ اسی ٹنل میں واپس بھیجے جا سکتے ہیں جو انہیں بنانا تھا۔
تیسرا مرحلہ واپسی کا راستہ ہے۔ بغیر جواب کے ہینڈ شیک باہر پھینکنے کا ثبوت نہیں؛ یہ سرور کے اندرونی قاعدے یا میپنگ بھول جانے والے NAT ڈیوائس کے ساتھ بھی اتنا ہی مطابقت رکھتا ہے۔ کلائنٹ کو چھونے سے پہلے انہیں الگ کریں۔
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
کلائنٹ وہ علامت درج کرتے ہیں جو انہیں ملتی ہے، ناکام مرحلہ نہیں، اس لیے جدول عام طور پر لاگ سے تیز ہوتا ہے۔
کاؤنٹر لاگ سے تیزی سے فیصلہ کرتے ہیں
Linux پر، nft list ruleset یا iptables -vnL OUTPUT ہر قاعدے کے لیے پیکٹ کاؤنٹر چھاپتا ہے۔ ایک بار جڑیں، ناکام ہونے دیں، پھر کاؤنٹر دوبارہ پڑھیں۔ جس قاعدے کا کاؤنٹر ہلا وہی وہ قاعدہ ہے جسے ہینڈ شیک نے چھوا؛ اگر کہیں کچھ نہ ہلا تو پیکٹ کبھی فائر وال تک نہیں پہنچا۔ میں نے ایک قواعد کے مجموعے کو اپنا ہی ہینڈ شیک پھینکتے دیکھا ہے، اور یہ صرف کاؤنٹروں نے بتایا۔
کبھی فائر وال تک نہ پہنچنے اور کبھی ہوسٹ سے باہر نہ نکلنے کو الگ کرنے کے لیے خود انٹرفیس کو دیکھیں۔ ip -s link show dev wlan0 بھیجے گئے پیکٹ بتاتا ہے، اور tcpdump -ni wlan0 udp port 51820 فریم دکھاتا ہے۔ اگر کلائنٹ کے دوبارہ کوشش کرنے کے دوران یہ ہموار رہے، تو خرابی netfilter کے اوپر ہے: پیر کا غائب راستہ، ایسے ڈیوائس کی طرف اشارہ کرنے والا پالیسی قاعدہ جو ابھی موجود نہیں، یا وہ ساکٹ نقص جسے کلائنٹ نگل جاتا ہے۔
استثناؤں کو دستاویزی پتوں پر جانچیں، مثلاً 203.0.113.10، تاکہ کوئی چوک کسی اور کے ہوسٹ کی جانچ نہ کر سکے۔
پرانے اینڈ پوائنٹ کا استثنا سرور بند ہونے کی طرح پڑھا جاتا ہے
سب سے گمراہ کن نسخہ پیر کا پتہ بدلنے کے بعد سامنے آتا ہے: متحرک پتہ سروس نے اسے منتقل کیا، ہوسٹ دوبارہ بنایا گیا، یا آپ کے نیٹ ورک کا خارجی پتہ مختلف ہے۔ استثنا اب بھی پرانے پتے کا نام لیتا ہے، اس لیے نئے کی طرف جانے والے پیکٹ پھینکنے والے قاعدے پر پڑتے ہیں۔ وہی ترتیب کل کام کر رہی تھی، اسی لیے لوگ سرور کی جانچ سے شروع کرتے ہیں۔
فائر وال قاعدے کے اندر ہوسٹ نام آپ کو نہیں بچاتا۔ nftables میں نام قواعد کے مجموعے کے لوڈ ہونے پر حل ہوتا ہے، اس لیے وہ اُس وقت موجود پتے کو پن کر دیتا ہے اور لفظی پتے کی طرح پرانا ہو جاتا ہے۔ پائیدار حل یہ ہے کہ اینڈ پوائنٹ بدلنے پر استثنا اپ ڈیٹ کریں اور اسے تنگ رکھیں: ایک پیر پتہ، ایک ترسیلی پورٹ۔ پتہ تبدیلی سہنے کے قابل اتنی چوڑی حد اتنی ہی چوڑی ہے کہ غیر متعلقہ ٹریفک بھی باہر جا سکے۔
جب کل سوئچ سرور ہوسٹ پر چلتا ہے
وہی انحصار دوسرے سرے پر بھی ہے، اور وہاں اسے چھوڑ دینا آسان ہے۔ اگر آپ کے VPN سرور کا کردار ادا کرنے والی مشین کل سوئچ والا ڈیسک ٹاپ کلائنٹ یا لیپ ٹاپ سے نقل شدہ فائر وال پروفائل بھی چلاتی ہے، تو اس کے پھینکنے والے قواعد ٹنل ختم کرنے والی سروس پر لاگو ہوتے ہیں۔ کلائنٹ کے ہینڈ شیک کے جواب پھینک دیے جاتے ہیں، اس لیے ہر کلائنٹ جڑ نہیں پاتا جبکہ سرور صحت مند دکھتا ہے اور اس کا ٹنل انٹرفیس بے استعمال پڑا رہتا ہے۔
اس ہوسٹ کو پھینکنے سے پہلے تین تنگ منظوریاں درکار ہیں: فزیکل انٹرفیس پر سننے والی پورٹ، ڈکرپٹ شدہ ٹریفک کے لیے ٹنل انٹرفیس، اور ٹنل سے اس طرف بھیجنا جہاں کلائنٹ کو پہنچنا ہے۔ نصب شدہ مجموعہ اس سے پڑھیں: nft list ruleset، iptables -S، یا pfctl -sr کچھ بھی بدلنے سے پہلے، اور یاد رکھیں کہ محفوظ شدہ قواعد کا مجموعہ ری بوٹ کے بعد بھی رہتا ہے، اس لیے وہاں کی غلطی اسے بنانے والے عمل سے زیادہ زندہ رہتی ہے۔
مشین کو بند رکھنے والی بحالی کی ترتیب
پروفائل سے باہر کی طرف کام کریں۔ کلائنٹ جو پیر پتہ اور پورٹ استعمال کرتا ہے وہ پڑھیں، تصدیق کریں کہ ہوسٹ نام ٹنل کے بغیر حل ہوتا ہے، پھر صرف فزیکل اڈاپٹر پر اس پتے اور پورٹ کے لیے ایک استثنا شامل کریں۔ دوبارہ جڑیں اور بھیجنے کا کاؤنٹر دیکھیں؛ مکمل ہوا ہینڈ شیک اس بات کا اشارہ ہے کہ دوسرا مرحلہ درست ہو گیا۔
جانچ کے دوران پھینکنے کی باقی پالیسی کو اس کی جگہ رہنے دیں۔ بے ضرر جانچ یہ ہے کہ کسی غیر متعلقہ دستاویزی پتے پر رابطے کی کوشش کریں اور تصدیق کریں کہ یہ اب بھی وقت ختم ہو کر رکتا ہے، جو دکھاتا ہے کہ کل سوئچ بند نہیں بلکہ کام کر رہا ہے۔ ٹنل مستحکم ہونے پر استثنا سخت کریں، اور سہولت کی خاطر کلائنٹ پروگرام کے لیے مستقل سب کچھ کی اجازت نہ چھوڑیں۔
اگر ٹنل اوپر آ جائے اور ایپلیکیشن پھر بھی ناکام ہو، تو باقی مراحل یہ نہیں: منقسم DNS، MTU اور فی ایپلیکیشن روٹنگ میں سے ہر ایک جڑا ہوا ٹنل اور ٹوٹی ٹریفک دیتا ہے، اور ہر ایک کی پہلی جانچ مختلف ہے۔