WireGuard صرف اس وقت کام کرتا ہے جب سرور پہلے بھیجے: اختتامی نقطے کی معلومات

ایسا لگتا ہے کہ سرنگ صرف اس وقت کام کرتی ہے جب سرور پہلے کچھ بھیجتا ہے۔ کلائنٹ سے شروع کریں اور کچھ نہیں ہوتا، چند سیکنڈ انتظار کریں، دوبارہ کوشش کریں اور یہ کامیاب ہو جاتا ہے۔ معمول کی تشخیص خراب NAT ہے، اور معمول کی تشخیص غلط ہے۔ جو بدلا وہ یہ ہے کہ ایک پیر نے جان لیا کہ دوسرا کہاں رہتا ہے۔

اختتامی نقطے کی معلومات، رسائی نہیں

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

wg show اس تصویر کے دونوں رخ چھاپتا ہے، اور آؤٹ پٹ میں اختتامی نقطے کے بغیر پیر کچھ شروع نہیں کر سکتا، چاہے اس کی عوامی کلید اور اجازت یافتہ سابقے کتنے ہی درست ہوں۔ کوئی بھی قاعدہ بدلنے سے پہلے کلائنٹ کے نظریے کا سرور سے موازنہ کریں، کیونکہ دونوں اکثر اس پر متفق نہیں ہوتے کہ کسے کیا معلوم ہے۔

پیر اختتامی نقطہ کیسے سیکھتا ہے

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

wg کے لیے اوزار کی دستاویز اس اپ ڈیٹ کی وضاحت کرتی ہے، اور اگر آپ اس کے گرد ڈیزائن کرنے والے ہیں تو ایک بار پڑھنا مناسب ہے۔

حالت والا ترجمہ اپنی سمت شامل کرتا ہے

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

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

وہ سمت ترتیب دیں جو آپ واقعی چاہتے ہیں

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

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

محرک سے پہلے اور بعد کی حالت کا موازنہ کریں

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

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

اختتامی نقطے کا کالم اور ترجمہ اندراج ایک ساتھ لکھیں۔ بغیر اختتامی نقطے والا پیر اور بغیر نقشہ بندی والا گیٹ وے دو الگ خرابیاں ہیں۔ ان میں سے صرف ایک keepalive سے درست ہوتی ہے۔