WireGuard موبائل ڈیٹا پر چلتا ہے، مگر اسی Wi-Fi پر نہیں
LAN کے اندر سے راؤٹر کے عوامی پتے تک جانے والی درخواست موبائل ڈیٹا سے آنے والی درخواست سے الگ راستہ لیتی ہے۔ پہلے باہر سے جانچیں، پھر مقامی راستہ چنیں۔
ٹنل موبائل ڈیٹا پر اوپر آتا ہے اور پھر گھر پر اسی پروفائل، اسی پیر کلید اور درمیان میں کسی ترتیب کی تبدیلی کے بغیر وہ جڑ رہا ہے کی حالت میں بیٹھا رہتا ہے۔ فرق سفر میں ہے: LAN کے اندر سے راؤٹر کے عوامی پتے تک جانے والی درخواست انٹرنیٹ سے آنے والی درخواست کا وہی سفر نہیں ہے۔ زیادہ تر گھریلو گیٹ ویز یا واپسی کا راستہ نافذ نہیں کرتے، یا صرف چند پروٹوکولز کے لیے نافذ کرتے ہیں۔ اس سے کلید کے بارے میں کچھ بھی نہ بدلنے کے باوجود علامت ٹوٹی کلید جیسی دکھتی ہے۔ کلید، پورٹ فارورڈ یا کلائنٹ پروفائل کو چھونے سے پہلے طے کریں کہ کون سا راستہ ناکام ہوا۔
ایک پتہ، دو مختلف راستے
باہر سے ایک پیکٹ راؤٹر کے عوامی پتے تک پہنچتا ہے اور پورٹ فارورڈ اصول اسے اندرونی ہوسٹ پر WireGuard کے سننے والے کے حوالے کرتا ہے۔ اندر سے کلائنٹ وہی عوامی پتہ ڈائل کرتا ہے، اس لیے پیکٹ کلائنٹ سے نکلتا ہے، راؤٹر تک پہنچتا ہے اور اسے واپس LAN کی طرف موڑنا پڑتا ہے۔ اسی واپسی موڑ پر دونوں راستے الگ ہوتے ہیں، کیونکہ راؤٹر کو ایسا بہاؤ ترجمہ کرنا پڑتا ہے جو ایک ہی انٹرفیس سے نکل کر پھر اسی میں داخل ہوتا ہے۔ بہت سی عمل درآمدیں ترجمہ کرنے کے بجائے اسے گرا دیتی ہیں، اور پھر کلائنٹ اس ہینڈ شیک کا انتظار کرتا ہے جو کبھی بھیجا ہی نہیں گیا۔
اس رویے کو عام طور پر NAT لوپ بیک یا ہیئر پننگ کہا جاتا ہے، اور یہ WireGuard کا نہیں بلکہ راؤٹر کا وصف ہے؛ RFC 4787 ان ترجمہ کی صورتوں کو بیان کرتا ہے جن میں گیٹ وے اس کی حمایت کر سکتا ہے یا نہیں۔ WireGuard خود راستے کے بارے میں کوئی رائے نہیں رکھتا، کیونکہ وہ صرف وہ پیکٹ دیکھتا ہے جو اس کے انٹرفیس تک پہنچتے ہیں۔ جب راؤٹر بہاؤ گرا دیتا ہے، ڈیمون کو کچھ نہیں ملتا، کلائنٹ ہینڈ شیک ٹائم آؤٹ بتاتا ہے اور سرور لاگ خالی رہتا ہے۔ اس لیے خالی لاگ اس بات کا سراغ ہے کہ پیکٹ کہاں رکا، اس بات کا ثبوت نہیں کہ سرور بند ہے۔ دوبارہ انسٹال کرنے سے کچھ نہ بدلنے کی وجہ بھی یہی ہے۔
الٹا بھی اہم ہے: LAN پتے سے ہینڈ شیک کی کوشش دکھانے والا سرور لاگ ثابت کرتا ہے کہ پیکٹ پہنچا اور راستہ درست ہے، جس سے جانچ کلیدوں اور مجاز پتوں کی طرف چلی جاتی ہے۔ لاگ اس لیے پڑھیں کہ وہ کیا ثابت کرتا ہے، اس لیے نہیں کہ آپ کیا دیکھنا چاہتے تھے۔
کچھ بدلنے سے پہلے اسے دوبارہ پیدا کریں
اسی ڈیوائس اور اسی پروفائل کے ساتھ کسی مجاز بیرونی نیٹ ورک سے جانچیں، پھر کچھ بھی بدلے بغیر LAN کے اندر وہی جانچ دہرائیں۔ باہر مکمل ہونے والا ہینڈ شیک اور اندر وہ کلائنٹ جو ڈیوائس سے نکلتا ہی نہیں، اندازے کے بجائے اس حالت کو دوبارہ پیدا کرتے ہیں۔ دونوں کوششوں میں ایک ہی پروفائل استعمال ہونا چاہیے، ورنہ موازنہ کچھ ثابت نہیں کرتا۔
پھر دیکھیں کہ اس ڈیوائس کے لیے اینڈ پوائنٹ نام کس پتے پر حل ہوتا ہے۔ یہ تین کمانڈیں یہ بھی دکھاتی ہیں کہ کلائنٹ نے واقعی کون سا پتہ ڈائل کیا:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netپہلی کمانڈ بتاتی ہے کہ انٹرفیس اس وقت کون سا اینڈ پوائنٹ استعمال کر رہا ہے، اور باقی دو دکھاتی ہیں کہ اس مشین پر نام کس پتے پر حل ہوتا ہے۔ سرور کے اسی نیٹ ورک پر بیٹھ کر عوامی پتہ ڈائل کرنے والا کلائنٹ ہیئر پن راستہ استعمال کر رہا ہے۔ LAN پتہ ڈائل کرنے والا کلائنٹ ایسا نہیں کر رہا، اور وہاں کی ناکامی کسی دوسری جانچ کی بات ہے۔ یہی فرق طے کرتا ہے کہ اگلا حصہ یہاں لاگو ہوتا ہے یا نہیں۔
قریبی سرور تک پہنچنے کے معاون طریقے
سب سے صاف بندوبست اسپلٹ ہورائزن جواب ہے: عوامی نام انٹرنیٹ کے لیے عوامی پتے پر اور اندرونی کلائنٹس کے لیے سرور کے LAN پتے پر حل ہوتا ہے۔ پروفائل ایک ہی اینڈ پوائنٹ نام رکھتی ہے اور حل کرنے والا راستہ چنتا ہے۔ اس کے لیے اندرونی DNS جواب پر کنٹرول درکار ہے، جو گھریلو راؤٹر عام طور پر دیتا ہے اور کوئی ادارہ سوچ سمجھ کر بندوبست کر سکتا ہے۔ اس کنٹرول کے بغیر بچے اختیارات راؤٹر کی کوئی خصوصیت یا دوسرا پروفائل ہیں۔
راؤٹر کی خصوصیت انعکاس ہے: گیٹ وے اندر سے باہر جانے والے بہاؤ کا ترجمہ کر کے اسے واپس اندر بھیجتا ہے۔ جہاں یہ چلتا ہے وہاں کلائنٹ میں تبدیلی درکار نہیں، اور جہاں نہیں چلتا وہاں کوئی کلائنٹ سیٹنگ اسے نہیں بچا سکتی۔ راؤٹر کی خصوصیات کی فہرست پڑھنے کے بجائے اندرونی کوشش کے دوران سرور لاگ دیکھ کر اسے جانچیں۔
پروفائل کو نجی پتے پر بدلنا تشخیص ہے، ڈیزائن نہیں۔ یہ ثابت کرتا ہے کہ سرور LAN پر جواب دیتا ہے، اور لیپ ٹاپ کے گھر سے باہر نکلتے ہی وہی پروفائل ٹوٹ جاتی ہے۔
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
گھر سے دور بھی پروفائل کو قابل استعمال رکھیں
کوئی بھی راستہ چنیں، شناخت کی جانچ کو ہاتھ نہ لگائیں۔ اینڈ پوائنٹ پتہ پیر کی شناخت نہیں ہے، اور پتہ بدل جانا کبھی ایسی غیر متعلق عوامی کلید قبول کرنے کا جواز نہیں بنتا جو اتفاقاً جواب دے رہی ہو۔ WireGuard کلید سے ہی تصدیق کرتا ہے، اس لیے غلط ہوسٹ ہینڈ شیک ناکام کرتا ہے، کسی غیر متوقع چیز تک رسائی نہیں دیتا۔
اگر عوامی پتہ ہل جائے تو نام کو مفید رکھنے والا ڈائنامک DNS ہے، اور تبدیلی کتنی جلد لاگو ہوتی ہے یہ کلائنٹ کا ریفریش رویہ طے کرتا ہے۔ پتہ بدلنے کے بعد اسے باہر سے جانچیں، کیونکہ LAN کی صورت اس کی تصدیق نہیں کر سکتی۔ ایسے حل کرنے والے سے ہوشیار رہیں جو ریکارڈ کی عمر گزرنے کے بعد بھی پرانا جواب کیش میں رکھتا ہے۔ پچھلے پتے کی طرف اشارہ کرتا نام بالکل بند پڑے سرور جیسا دکھتا ہے۔
لکھ لیں کہ پروفائل کون سا نام استعمال کرتی ہے اور حد کے دونوں طرف وہ کس پتے پر حل ہوتا ہے۔ کسی کی جانب سے درج نہ کی گئی راؤٹر خصوصیت پر منحصر پروفائل اگلی فرم ویئر اپ ڈیٹ کا انتظار کرتی مدد کی کال ہے۔ وہی نوٹ اگلے شخص کو بتاتا ہے کہ اندرونی ناکامی جانا پہچانا ہیئر پن معاملہ ہے یا کچھ نیا۔