WireGuard کے ذریعے ایک ایپ: بائنڈنگ روٹنگ نہیں ہے

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

اس طریقہ کار کے دو حصے ہیں: ایک روٹنگ جدول جسے صرف ٹنل کی ٹریفک استعمال کرے، اور ایک قاعدہ جو مماثل ماخذ وہاں بھیجے۔

بائنڈنگ صرف ماخذ پتہ طے کرتی ہے

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

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

ٹنل کو اس کی اپنی جدول دیں

wg-quick راستے وہاں نصب کرتا ہے جہاں پروفائل کہے۔ [Interface] کے نیچے Table = 40 شامل کرنے سے وہ مرکزی جدول کے بجائے جدول 40 میں چلے جاتے ہیں۔ انٹرفیس اوپر کریں اور تصدیق کریں کہ وہ پہنچ گئے: ip -4 route ls table 40 کو ٹنل کے راستے دکھانے چاہئیں، اور ip -4 route get 10.66.127.142 دکھاتا ہے کہ کرنل اب ان میں سے ایک کو کیسے حل کرتا ہے۔ راستے اپنی جدول میں ہوں تو مرکزی جدول باقی سب کے لیے کام کرتی رہتی ہے۔

چوڑا سابقہ ملانے کے بجائے IPv6 کے لیے بھی یہی کریں۔ ip -6 rule add from fd00::2/128 lookup 40 ایک پتہ مقرر کرتا ہے؛ fc00::/8 میزبان کے دوسرے انٹرفیس سے ٹکرا سکتا ہے اور ایسا قاعدہ بنا سکتا ہے جو مقصد سے زیادہ مماثل ہو۔

ماخذ قاعدہ شامل کریں اور کاؤنٹر دیکھیں

پھر دونوں حصے جوڑیں: ip -4 rule add from 10.66.127.142/32 lookup 40، وہی پتہ WireGuard انٹرفیس سے منسلک رکھتے ہوئے۔ دونوں قواعد PostUp میں رکھیں تاکہ دوبارہ کنیکٹ ہونے پر وہ بحال ہوں۔ سیٹنگ سے نہیں، اصل درخواست سے جانچیں: ip route get 1.1.1.1 from 10.66.127.142 کو ٹنل ڈیوائس کا نام بتانا چاہیے، اور curl --interface wg0 ifconfig.me کو گھر کے پتے کے بجائے ٹنل کا پتہ بتانا چاہیے۔

اگر پھر بھی ناکام ہو تو ip -s rule پڑھیں۔ جو قاعدہ موجود ہے مگر کبھی مماثل نہیں ہوا وہ صفر کاؤنٹر دکھاتا ہے، اور یہی غلط قاعدے کو قاعدے کے بالکل نہ ہونے سے الگ کرتا ہے۔ وہ ایک کمانڈ ایپ نے اپنی انٹرفیس سیٹنگ نظر انداز کی یا نہیں، اس بارے میں بہت سے اندازے بچاتی ہے۔

الٹی صورت: SSH کو ٹنل سے باہر رکھیں

الٹا مسئلہ بھی اتنا ہی عام ہے: wg-quick ڈیفالٹ راستے کا مالک ہے اور سرور تک SSH سیشن بیچ میں ہی مر جاتا ہے۔ اس کے قواعد کم ترجیحی نمبر پر ہوتے ہیں، اس لیے استثنا کا جائزہ ان سے پہلے ہونا چاہیے۔ ip rule add dport 22 ipproto tcp table main priority 123 حالیہ iproute2 پر یہ کرتا ہے؛ جہاں سلیکٹر دستیاب نہ ہو وہاں nftables میں بہاؤ کو نشان زد کریں اور بجائے اس کے نشان سے مماثل کریں۔

واپسی کا راستہ بھی دیکھیں۔ جو SSH سیشن قائم ہو کر پھر خاموش ہو جاتا ہے اس میں عام طور پر غیر متناسب روٹنگ ہوتی ہے: ایک سمت ٹنل سے اور دوسری فزیکل انٹرفیس سے باہر جاتی ہے۔ سرور کے پتے کے لیے ip route get بتاتا ہے کہ جواب کس طرف جائے گا۔

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