WireGuard مکمل ٹنل: AllowedIPs 0.0.0.0/0 کافی نہیں

ساتھی کے AllowedIPs میں 0.0.0.0/0, ::/0 ڈالنا وہ قدم ہے جو سب کو یاد رہتا ہے، اور یہ صرف یہ طے کرتا ہے کہ ساتھی کو کون سی ٹریفک اٹھانے کی اجازت ہے۔ یہ سابقے کوئی راستہ نہیں بناتے، دوسری طرف کچھ فارورڈ نہیں کرتے، اور ہر ایپلیکیشن کے حل کنندہ کو وہیں چھوڑ دیتے ہیں جہاں وہ تھا۔ مکمل ٹنل کے واقعی مکمل ہونے کے لیے چار الگ الگ چیزیں بیک وقت درست ہونی چاہئیں، اور انہیں نیچے دیے گئے ترتیب سے جانچنا بہتر ہے، کیونکہ بعد کی جانچ پہلی جانچ کو نہیں بچا سکتی۔ نیچے کی ہر جانچ ایک حقیقت ہے جو مشین سے پڑھی جا سکتی ہے، ایسی ترتیب نہیں جس کے لاگو ہونے کی آپ امید کریں۔

ساتھی کا سابقہ کیا منتخب کرتا ہے اور کیا نہیں

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

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

کلائنٹ کو راستہ دینا، صرف ساتھیوں کی فہرست نہیں

جیسے wg-quick کے منتظمین میزبان کی روٹنگ جدول آپ کی طرف سے پروگرام کرتے ہیں، اسی لیے دو یکساں ترتیبی فائلیں اس بات پر مختلف برتاؤ کرتی ہیں کہ انٹرفیس کیسے اوپر آیا۔ کم سے کم پروفائل ایک ہی سانس میں پڑھنے کے قابل ہے:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

کام دو تفصیلات اٹھاتی ہیں۔ Address فیلڈ کلائنٹ کا اپنا سمجھا ہوا سب نیٹ نہیں، بلکہ ایک ہی میزبان سابقہ ہے، اور منتظم ہی طے شدہ AllowedIPs کو حقیقی طے شدہ راستے میں بدلتا ہے۔ وہی فائل ip link اور wg setconf کے ذریعے اوپر لائیں اور کوئی راستہ نظر نہیں آئے گا، جو ٹوٹی ٹنل جیسا لگتا ہے مگر درحقیقت راستہ کاری کا مرحلہ چھوڑی ہوئی صحت مند ٹنل ہے۔ wg-quick کی دستی کتاب راستہ کاری اور Table رویے کی دستاویز کرتی ہے جو وہ منتظمین شامل کرتے ہیں۔

فائل نہیں، نتیجہ پڑھیں: ip route get 1.1.1.1 کو ٹنل انٹرفیس کا نام دینا چاہیے، اور wg show کو چلتے ہوئے منتقلی شمارندے کے ساتھ حالیہ مصافحہ رپورٹ کرنا چاہیے۔ راستے کے بغیر مصافحہ کا مطلب ہے کہ منتظم کبھی چلا ہی نہیں، اور پروفائل کو دوبارہ ترمیم کرنے سے یہ درست نہیں ہوگا۔ انٹرفیس کو اسی طرح شروع کریں جیسے صارف کرے گا، ورنہ امتحان تعیناتی کے بجائے آپ کا شیل ناپے گا۔

آخری نقطہ ٹنل سے باہر رکھنا

مکمل ٹنل ہر منزل کو پکڑتی ہے، اس سمیت جس سے وجود کے لیے بات کرنی ہوتی ہے۔ منتظمین اصل گیٹ وے کے ذریعے آخری نقطے کے لیے میزبان راستہ شامل کر کے اسے سنبھالتے ہیں، اسی لیے درست ترتیب میں تقریباً ہمیشہ ایک دانستہ استثنا ہوتا ہے۔ ترتیب کا آدھا حصہ منتظم سے اور باقی آدھا ہاتھ سے لاگو کرنا اس استثنا کے گم ہونے کا عام راستہ ہے۔

اگر آخری نقطہ ایسا میزبان نام ہے جو کئی پتوں پر، یا ایسے خاندان پر حل ہوتا ہے جو آپ نہیں اٹھاتے، تو استثنا بری طرح پرانا ہو جاتا ہے اور معمول کا لگنے والا دوبارہ رابطہ کے بعد ٹنل ناکام ہو سکتی ہے۔ آخری نقطے کو اپنے کنٹرول والے پتے پر پن کریں، یا یقینی بنائیں کہ منتظم اس کا دوبارہ جائزہ لیتا ہے، اور ہر نیٹ ورک تبدیلی کے بعد میزبان راستہ دوبارہ پڑھیں۔

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

گیٹ وے پر فارورڈنگ اور واپسی کا راستہ

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

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

تلاش گیٹ وے پر چلتی ہے، کلائنٹ پر نہیں، ورنہ آپ دوسری روٹنگ جدول پڑھیں گے۔ اگر یہ غلط انٹرفیس کا نام دے، یا بتائے کہ کوئی راستہ نہیں، تو کلائنٹ کی طرف کا کوئی بھی تبدیلی انٹرنیٹ سے باہر نکلنے کا راستہ نہیں بنائے گی۔ جب گیٹ وے باہر جاتے وقت کلائنٹ پتوں کا ترجمہ کرتا ہے، تو جواب اسی ترجمے کی حالت پر منحصر ہے، اس لیے قاعدہ صرف باہر جانے والی سمت کے لیے نہیں، بہاؤ کی دونوں سمتوں کے لیے ہونا چاہیے۔

DNS اور ناکامی کی حالت، الگ الگ جانچی گئی

پروٹوکول خود کسی بھی ایپلیکیشن کا حل کنندہ ترتیب نہیں دیتا۔ wg-quick تقسیم کے حل کنندہ کے انضمام کے ذریعے لائن DNS لاگو کرتا ہے، اپنے اسٹیک والے کنٹینر اور براؤزر اسے نظر انداز کر سکتے ہیں، اور اسی لیے ٹنل کے پیکٹ بالکل ٹھیک اٹھانے کے دوران بھی نام ناکام ہو سکتا ہے۔ پتے کے بجائے میزبان نام سے جانچیں، اور یہ سمجھنے کے بجائے کہ پروفائل والا سرور جواب دے گا، لکھیں کہ کس سرور نے جواب دیا۔

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

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