WireGuard تازہ ترین ہینڈ شیک نہیں دکھا رہا: پہلے کیا جانچیں

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

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

غیر فعال انٹرفیس کے پاس بتانے کو کچھ نہیں

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

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

وہ ٹریفک متحرک کریں جو peer کو لے جانے کی اجازت ہے

مقامی مشین پر peer کے اجازت یافتہ سابقوں کے اندر ایک پتہ منتخب کریں اور تصدیق کریں کہ روٹنگ جدول اسے انٹرفیس کے ذریعے بھیجے گا۔ ان سابقوں سے باہر کی منزل WireGuard کی کسی شرکت کے بغیر عام روٹ شدہ درخواست پیدا کرتی ہے۔ تیز جواب دینے والی سروس استعمال کریں، جیسے ping یا مختصر TCP کنکشن، تاکہ کوشش کا نظر آنے والا آغاز اور اختتام ہو۔ پھر اسکرین دیکھ کر انتظار کرنے کے بجائے ہینڈ شیک لائن دوبارہ پڑھیں۔

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

راستے کی استفسار ping سے زیادہ اہم ہے۔ اگر یہ جسمانی انٹرفیس کا نام لے تو پیکٹ کبھی سرنگ میں داخل نہیں ہوا اور خالی ہینڈ شیک کرپٹوگرافک نہیں، روٹنگ کا جواب ہے۔ peer کو ڈیبگ کرنے سے پہلے راستہ ٹھیک کریں۔

کلید جوڑی اور اینڈ پوائنٹ کا موازنہ کریں

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

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

بیرونی UDP راستے پر نظر رکھیں

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

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

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

ہینڈ شیک نمودار ہوتے ہی، سرنگ کے ذریعے ایپلیکیشن کی جانچ کریں، کیونکہ مکمل شدہ تبادلہ شناخت اور رسائی ثابت کرتا ہے، قابل استعمال تھروپٹ یا درست DNS نہیں۔ تبدیلی سے پہلے اور بعد کا حالتی آؤٹ پٹ رکھیں، اور فرق آپ کا ثبوت بن جائے گا۔