نیسٹڈ WireGuard: درمیانی ہاپ اپنی ہی پورٹ کا جواب نہیں دے سکتا
جب درمیانی ہاپ سب کچھ ایک ٹنل میں بھیجتا ہے تو اس کی آنے والی سروس کے جواب غلط راستے سے نکلتے ہیں۔ انٹرفیس پر ماخذ پورٹ کا قاعدہ اسے درست کرتا ہے۔
تین WireGuard ہاپس ایسے نیٹ ورک تک پہنچتے ہیں جس کا کوئی عوامی پتہ نہیں، پھر درمیانی مشین اس پورٹ پر جواب دینا بند کر دیتی ہے جس پر اسے سننا تھا۔ آگے کی ٹنل اب بھی کام کرتی ہے، دور کا ہوسٹ اب بھی جواب دیتا ہے، اور باہر سے خاموش صرف درمیانی سرور ہی ہوا ہے۔ یہ امتزاج الجھن میں ڈالتا ہے کیونکہ یہ خود کیا ہوا ہے: درمیانی ہاپ اپنی ہی روٹنگ ٹیبل کی پیروی کر رہا ہے، اور ٹیبل اس کے جوابات غلط سمت میں بھیجتی ہے۔
ایک زنجیر جو درمیانے باکس سے بات کرنے تک کام کرتی ہے
ایک مثالی زنجیر لیں: کلائنٹ A UDP 500 پر سرور B تک پہنچتا ہے، اور B UDP 500 پر سرور C کی طرف آگے بڑھتا ہے۔ C صرف اپنے واحد ساتھی کے پتے سے ٹریفک قبول کرتا ہے، جو اسے پتہ بناتا ہے اور اس کا رویہ سادہ رکھتا ہے۔ B پتہ نہیں ہے، اور اس خرابی کی تمام دلچسپ باتیں وہیں ہوتی ہیں۔
یہ فرق اہم ہے کیونکہ پتہ اور درمیانی کردار مخالف سمتوں میں کھینچتے ہیں۔ پتہ بغیر کسی نتیجے کے سب کچھ ایک ٹنل میں بھیج سکتا ہے، کیونکہ اس پر کوئی اور چیز منحصر نہیں۔ درمیانی ہاپ بیک وقت کلائنٹس کے لیے آخری نقطہ اور دور کی طرف کلائنٹ ہے، اور یہ دونوں کام مختلف روٹنگ چاہتے ہیں۔
جواب ٹنل سے کیوں نکلتا ہے
B پر، C کی طرف والا انٹرفیس متعلقہ ڈیفالٹ روٹ کے ساتھ AllowedIPs = 0.0.0.0/0 رکھتا ہے۔ اس لیے B کا بنایا ہوا ہر پیکٹ اسی ٹنل میں جاتا ہے، جب تک کوئی زیادہ مخصوص چیز ترجیح نہ پائے۔
A سے B کے لیے بھیجا گیا پیکٹ آتا ہے اور قبول کیا جاتا ہے، کیونکہ B منزل ہے اور مقامی ترسیل پہلے ہوتی ہے۔ جواب A کے عوامی پتے کی طرف نشانہ شدہ بالکل نیا مقامی طور پر بنایا گیا پیکٹ ہے، اور وہ منزل ٹنل کی ڈیفالٹ روٹ سے مطابقت رکھتی ہے۔ C اسے وصول کرتا ہے، اس پتے کا مالک نہیں، اور اسے پھینک دیتا ہے۔
علامت فائر وال مسئلے یا کلید کی عدم مطابقت جیسی پڑھی جاتی ہے، اور یہاں دونوں میں سے کوئی درست نہیں۔ C کی طرف ٹنل پر کیپچر دکھاتا ہے کہ جواب غلط سمت میں جا رہے ہیں۔ وہ ایک مشاہدہ کسی بھی مقدار میں کنفیگریشن پڑھنے سے زیادہ وقت بچاتا ہے، اس لیے کلیدیں بدلنا شروع کرنے سے پہلے اسے لکھ لیں۔ جس نے کیپچر نہیں دیکھا وہ سمجھے گا کہ ٹنل خود خراب ہے۔
تنگ مرمت: ماخذ پورٹ سے مطابقت رکھنے والے پالیسی قواعد
B کے سننے والے ساکٹ سے جواب ماخذ پورٹ 500 کے ساتھ نکلتے ہیں۔ ایک پالیسی قاعدہ اس سے مطابقت رکھ سکتا ہے اور ان پیکٹوں کو عام ٹیبل میں واپس بھیج سکتا ہے:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101پالیسی قواعد ترجیحی ترتیب میں دیکھے جاتے ہیں، اور مرکزی ٹیبل 32766 پر ہے، اس لیے 100 کا قاعدہ ٹنل کی ڈیفالٹ روٹ کے بولنے سے پہلے پوچھا جاتا ہے۔ ہر اس پورٹ کے لیے ایک اندراج شامل کریں جو باہر سے قابل رسائی رہنا چاہیے اور اس سے زیادہ کچھ نہیں، تاکہ آگے بھیجا گیا ٹریفک اسی ٹنل کو استعمال کرتا رہے جس کے لیے اسے بنایا گیا تھا۔
اس ترکیب کی حد جانیں۔ sport منتخب کنندہ مقامی طور پر بنائے گئے پیکٹوں سے مطابقت رکھتا ہے، جو بالکل جواب کی صورت کو محیط ہے اور جان بوجھ کر اس ٹریفک کو محیط نہیں جو B صرف کسی اور کے لیے آگے بھیجتا ہے۔ B کے پیچھے میزبانی شدہ سروس کو اب بھی اپنا جواب درکار ہے، اور اس کے برعکس ظاہر کرنا ایسی مرمت دیتا ہے جو پہلی سروس کے لیے کام کرتی ہے اور دوسری کے لیے ناکام ہوتی ہے۔
قاعدے کو مالک دیں
پرامپٹ پر ٹائپ کیا گیا قاعدہ اگلی بار انٹرفیس دوبارہ بننے پر غائب ہو جاتا ہے۔ WireGuard سیٹ اپ میں اسے وہاں رکھیں جہاں انٹرفیس بنایا اور ہٹایا جاتا ہے:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100اگر انٹرفیس کا مالک NetworkManager، تقسیم ہک یا کنٹینر کا داخلہ نقطہ ہے تو یہ جوڑا ہاتھ سے ترمیم شدہ فائل کے بجائے اسی مالک کا ہے۔ دوبارہ جڑنے کے بعد مؤثر قواعد چیک کریں، صرف پہلی شروعات کے بعد نہیں، کیونکہ پہلی شروعات وہ صورت ہے جو ہمیشہ کام کرتی ہے۔
متبادلات کا دیانت دارانہ موازنہ کریں
ماخذ پورٹ کا قاعدہ چار راستوں میں سے ایک ہے، اور ان میں سب سے تنگ۔ اس کا فائدہ یہ ہے کہ یہ ٹنل کی پالیسی کو بالکل نہیں چھوتا، اسی لیے یہ بعد کی تبدیلیوں میں اکثر بچ رہتا ہے۔ تنگ مرمتیں لاگو ہونا بند ہونے پر بلند آواز میں ناکام بھی ہوتی ہیں، جبکہ وسیع استثنا اپنی وجہ ختم ہونے کے بہت بعد تک خاموشی سے کام کرتا رہتا ہے۔ دو سال بعد جب باکس کا مالک کوئی اور ہو تو یہ فرق نفاست سے زیادہ اہمیت رکھتا ہے۔
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
انتخاب کے بعد دونوں سروں سے تصدیق کریں۔ A سے، B کی پورٹ پر کنکشن شروع کریں اور کچھ دیر اسے مصروف رکھیں۔ B پر، کرنل کو ip route get <address-of-A> sport 500 جیسی کسی چیز سے جوابی راستہ جائز قرار دینے دیں، اور تصدیق کریں کہ یہ ٹنل کے بجائے WAN انٹرفیس کا نام لیتا ہے۔ اس کے بعد، چیک کریں کہ C کے پیچھے کوئی چیز اب بھی زنجیر سے جواب دے رہی ہے، جو ثابت کرتا ہے کہ استثنا بائی پاس بننے کے بجائے تنگ ہی رہا۔ آخر میں، پورٹس کو ڈیزائن نوٹس میں درج کریں، ورنہ اگلا آپریٹر اسے کسی اور سروس پر دوبارہ دریافت کرے گا۔