ایک ہی راستہ ثابت کرنے والا دو پیر کا WireGuard ٹیسٹ کیسے بنائیں

ڈیفالٹ روٹ، LAN سابقہ، DNS اور فائر وال استثنا لے جانے والا WireGuard ٹیسٹ نہیں بتا سکتا کہ ان میں سے کون ٹوٹا۔ اسے دو پیر، ایک پتہ جوڑی اور ایک اجازت شدہ سروس تک کم کریں، پھر ناکامی کے چھپنے کی جگہ نہیں رہے گی۔ بورنگ بنیاد ہی تشخیص ہے۔ اسے پہلے بنائیں؛ اس میں پندرہ منٹ لگتے ہیں اور اندازہ لگانے میں گزرنے والی دوپہر بچ جاتی ہے۔

بنیاد جو ثابت کرتی ہے وہ اکثر لوگوں کی توقع سے تنگ ہے۔ یہ ثابت کرتی ہے کہ دو شناختیں متفق ہیں، UDP سننے والے پورٹ تک پہنچتا ہے اور ایک اجازت شدہ منزل درخواست لے کر جاتی ہے۔ فارورڈنگ، NAT، LAN راستے اور DNS بعد میں ایک ایک کر کے شامل کی جانے والی الگ خصوصیات ہیں۔

چابیاں، پتے اور واحد endpoint

ہر نظام پر چابی کی جوڑی بنائیں اور ان کے درمیان صرف عوامی حصے منتقل کریں۔ wg genkey | tee privatekey | wg pubkey > publickey دستاویزی ایک سطری حکم ہے، اور نجی چابی کو ایسی فائل میں چھوڑ دیتا ہے جسے آپ بعد میں محفوظ کر سکتے ہیں۔ سرنگ کے پتے ایسی رینج سے منتخب کریں جو آپ کی کسی دوسری ترتیب میں نظر نہ آئے، جیسے 10.99.0.1/24 اور 10.99.0.2/24۔ لکھیں کہ کون سا پتہ کس مشین کا ہے، کیونکہ ہر بعد کی جانچ اسی نقشے پر منحصر ہے۔

نجی چابیاں کبھی سفر نہیں کرتیں۔ اگر ٹیسٹ کو ایک چابی دوسری طرف نقل کرنی پڑے تو ٹیسٹ پہلے ہی غلط ہو چکا ہے۔ جب دونوں نظام NAT کے پیچھے ہوں، کم از کم ایک کو قابل رسائی UDP پورٹ درکار ہے جبکہ دوسرا اس کی طرف اشارہ کرنے والا Endpoint رکھتا ہے، اور عوامی پتہ اور پورٹ آپ کے نوٹس میں ہوں، 51820 کے بارے میں آپ کے مفروضوں میں نہیں۔

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

وہ فیلڈز جو wg سے تعلق رکھتے ہیں اور جو نہیں

بنیادی فیلڈز کا مجموعہ چھوٹا ہے: Interface کے تحت PrivateKey اور ListenPort، Peer کے تحت PublicKey، AllowedIPs اور Endpoint۔ Address اور DNS wg کے بجائے wg-quick سے تعلق رکھتے ہیں، اور یہ فرق اسی لمحے کاٹتا ہے جب وہی ترتیب کسی دوسرے آلے میں منتقل ہو۔

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs بیک وقت دو کام کرتا ہے۔ یہ چنتا ہے کہ کون سی منزلیں سرنگ میں جائیں گی، اور یہ پیر کو آمد پر وہ ماخذ پتے استعمال کرنے کی اجازت دیتا ہے۔ اسی لیے دوسری طرف کی آئینہ اندراج کو آپ کی سرنگ کا پتہ بالکل درست بتانا ہوگا؛ غلط پیر کے لیے /32 راستے کا مسئلہ سمجھا جاتا ہے اور اجازت کے مسئلے کی طرح برتاؤ کرتا ہے۔ WireGuard کی تیز شروعات فیلڈ ناموں کا موازنہ کرنا ہو تو معیاری الفاظ کے ساتھ وہی دو پیر کی شکل دکھاتا ہے۔

آئیکن کے بجائے ہینڈ شیک پڑھنا

انٹرفیس کو اسی کے مالک کے ذریعے اوپر لائیں، پھر اسٹیٹس لائٹ کے بجائے حالت پڑھیں۔ wg show ہر پیر کا تازہ ترین ہینڈ شیک بائٹ کاؤنٹرز کے ساتھ چھاپتا ہے، اور گزشتہ چند منٹوں میں ہینڈ شیک کا مطلب ہے کہ چابیاں، endpoint اور UDP راستہ سب کام کر رہے ہیں۔ صرف ایک سمت میں بڑھنے والا کاؤنٹر خود اپنا جواب ہے، اور یہ کبھی نہ ہونے والے ہینڈ شیک جیسی وہی ناکامی نہیں ہے۔

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

ایک اجازت شدہ سروس ثابت کرنا، پھر الٹی سمت

دوسرے پیر کے سرنگ پتے پر ایسی سروس میں درخواست بھیجیں جس کا جواب دینا مقصود ہو، اور ping سے بہتر کچھ چنیں۔ ICMP جواب کا نہ ہونا سرنگ کی خرابی نہیں بلکہ ہوسٹ فلٹرنگ ہو سکتا ہے، اس لیے خاموش ping کسی سمت کو ثابت نہیں کرتا۔ آپ کو معلوم کھلے پورٹ پر TCP رابطہ، یا ڈیٹا واپس کرنے والی درخواست، آپ کو قابل‌تشریح جواب دیتی ہے۔

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

بنیاد کو حوالے کے طور پر رکھنا

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

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