WireGuard ہینڈ شیک کام کرتا ہے مگر انٹرنیٹ نہیں: پیکٹ کا پیچھا کریں
ہینڈ شیک صرف چابیاں اور رسائی ثابت کرتا ہے۔ AllowedIPs سے فارورڈنگ، NAT اور واپسی راستے سے گزرتے ہوئے ایک پیکٹ کا پیچھا کریں اور دیکھیں کہ وہ کہاں رکتا ہے۔
سرنگ فعال ہے، wg show حالیہ ہینڈ شیک کی اطلاع دیتا ہے، آپ سرور کے سرنگ پتے کو پنگ کر سکتے ہیں، اور اس سے آگے کچھ جواب نہیں دیتا۔ پہلا خیال چابیاں دوبارہ بنانا یا کنفیگ دوبارہ شیئر کرنا ہوتا ہے۔ یہ راستے کے اسی حصے کو بدلتا ہے جو پہلے ہی کام کرنے کا ثبوت ہے۔
مکمل ہینڈ شیک کہتا ہے کہ دونوں فریق چابیوں پر متفق ہیں، UDP آخری نقطے تک پہنچتا ہے، اور کرپٹو روٹنگ پیکٹ قبول کرتی ہے۔ یہ نہیں بتاتا کہ پیکٹ بعد میں سرور سے نکل سکتا ہے یا نہیں۔
اس لیے اندازہ لگانے کے بجائے ایک پیکٹ کا پیچھا کریں۔ چار جگہیں ہیں جہاں وہ مر سکتا ہے، اور ہر ایک مختلف نشان چھوڑتی ہے۔
ہینڈ شیک دراصل کیا ثابت کرتا ہے
WireGuard ایک UDP پروٹوکول ہے جو Noise ہینڈ شیک سے سیشن قائم کرتا ہے اور پھر ساتھی کے لیے پیکٹ انکرپٹ کرتا ہے۔ جب wg show چند سیکنڈ پرانا ہینڈ شیک اور بڑھتا ہوا منتقلی کاؤنٹر دکھائے، تو آخری نقطہ، چابیاں اور ساتھی کی عوامی چابی سب درست ہیں۔
جو یہ ثابت نہیں کرتا وہ یہ ہے کہ آپ کا کلائنٹ انٹرنیٹ کی طرف جانے والا ٹریفک انٹرفیس میں بھیجتا ہے، سرور اسے آگے بھیجنے کو تیار ہے، یا جواب واپسی کا راستہ پا سکتا ہے۔ یہ کرنل روٹنگ اور فائر وال کے فیصلے ہیں، اور وہ سرنگ سے باہر لیے جاتے ہیں۔
اسی لیے سرور کے سرنگ پتے کو پنگ کرنا اتنا گمراہ کن امتحان ہے۔ وہ پیکٹ خود سرور کو مخاطب، اس لیے وہ مقامی طور پر ختم ہوتا ہے۔ اسے کبھی فارورڈنگ، کبھی ترجمہ اور کبھی انٹرنیٹ سے واپسی راستے کی ضرورت نہیں ہوتی۔
AllowedIPs ایک روٹنگ فیصلہ ہے
کلائنٹ پر AllowedIPs دو کام کرتا ہے۔ یہ کرپٹو چابی روٹنگ جدول ہے جو طے کرتا ہے کہ کون سے منزل کے پتے اس ساتھی کی سرنگ میں بھیجے جاتے ہیں، اور یہ ان ماخذ پتوں کی فہرست ہے جو ساتھی آپ سے قبول کرے گا۔ اگر کلائنٹ کنفیگ میں صرف 10.8.0.0/24 ہے، تو عوامی منزلیں کبھی انٹرفیس میں داخل نہیں ہوتیں اور آپ کا معمول کا ڈیفالٹ راستہ انہیں سرنگ سے باہر لے جاتا ہے۔ تب سرنگ مکمل طور پر کام کرتی ہے اور آپ کی مطلوبہ کوئی چیز نہیں کرتی۔
کنفیگ فائل کیا کہتی ہے یہ نہیں، دیکھیں کلائنٹ نے واقعی کیا انسٹال کیا:
wg show wg0 allowed-ipsip route get 1.1.1.1
دوسرا کمانڈ فیصلہ کن ہے۔ اگر جواب آپ کا طبعی انٹرفیس اور معمول کا گیٹ وے بتائے، تو پیکٹ سرنگ سے نہیں جا رہا اور سرور کی طرف کوئی تبدیلی اسے درست نہیں کرے گی۔ IPv4 کے لیے 0.0.0.0/0 اور IPv6 کے لیے ::/0 الگ الگ شامل کریں؛ ایک خاندان کے لیے سب کچھ پکڑنے والا قاعدہ دوسرے کو اس کے اصل راستے پر چھوڑ دیتا ہے، اور یہ کام کرتی IPv4 سرنگ اور رکی ہوئی IPv6 تلاش کی عام وجہ ہے۔
گیٹ وے پر پیکٹ کہاں مرتا ہے
اگر راستہ درست ہے اور پیکٹ پھر بھی کہیں نہیں جاتا، تو وہ سرور تک پہنچ کر وہیں رک جاتا ہے۔ چار جانچیں زیادہ تر گیٹ وے ڈھانپ لیتی ہیں۔
فارورڈنگ۔ sysctl net.ipv4.ip_forward کا 0 واپس کرنا کلاسک جواب ہے، اور بہت سی تقسیمیں اب بھی ڈیفالٹ میں 0 پر ہیں۔ اسے 1 ہونا چاہیے، اور ری بوٹ پر غائب ہونے والے کمانڈ کے بجائے sysctl فائل میں مستقل طور پر مقرر کرنا چاہیے۔ IPv6 فارورڈنگ الگ سوئچ ہے۔
فلٹر پالیسی۔ ڈیفالٹ drop پالیسی والی FORWARD زنجیر سرنگ کا ٹریفک پھینک دے گی جبکہ خود میزبان کی طرف جانے والے ٹریفک کی اجازت دے گی، جو علامات سے بالکل میل کھاتا ہے۔ محفوظ شدہ فائل نہیں، زندہ قواعد کا مجموعہ پڑھیں: nft list ruleset یا iptables -S۔
ترجمہ یا روٹنگ۔ نجی سرنگ پتے استعمال کرنے والے کلائنٹ کو یا تو سرور کے اخراجی انٹرفیس پر ماخذ NAT درکار ہے، یا ایسا روٹ شدہ سابقہ جسے اوپری نیٹ ورک واپس بھیجنا جانتا ہو۔ دونوں کے درمیان انتخاب پتوں کے منصوبے کی پیروی کرتا ہے۔ ایسے نیٹ ورک میں MASQUERADE شامل کرنا جو پہلے ہی آپ کا سابقہ واپس روٹ کرتا ہے بے ضرر مگر بے معنی ہے، اور جہاں کوئی راستہ نہیں وہاں اسے چھوڑ دینا جوابات کو ناقابلِ روٹ نجی حد کی طرف مخاطب چھوڑ دیتا ہے۔
واپسی راستہ۔ روٹ شدہ ڈیزائنوں میں اوپری راؤٹر کو آپ کے سرور کی طرف اشارہ کرنے والا راستہ درکار ہوتا ہے۔ فراہم کنندہ کا نیٹ ورک بھی اسے روک سکتا ہے: کئی کلاؤڈ انسٹنس پر ماخذ اور منزل کی جانچ فعال کرتے ہیں، جو ان پیکٹوں کو خاموشی سے گرا دیتی ہے جن کا ماخذ انسٹنس کا اپنا پتہ نہ ہو، جب تک وہ جانچ بند نہ کی جائے۔
DNS روٹنگ سے مختلف طریقے سے ناکام ہوتا ہے
کسی معلوم پتے پر پیکٹ اور نام کی تلاش دو الگ ناکامیاں ہیں، اور غلطی کے پیغام مخالف سمتوں میں گمراہ کرتے ہیں۔ اگر ping 1.1.1.1 کام کرے اور براؤزر کچھ بھی لوڈ نہ کر سکے، تو راستہ درست ہے اور نام کا حل نہیں۔ اگر پنگ خود ناکام ہو، تو DNS بے تعلق ہے اور آپ پچھلے حصے پر واپس آ گئے ہیں۔
wg-quick کنفیگ کی DNS = سطر سے resolver مقرر کر سکتا ہے، اور systemd-resolved کا ہر لنک کے لیے اپنا رویہ ہے۔ جو VPN resolver کو ایسے پتے سے بدل دیتا ہے جو صرف سرنگ کے اندر قابلِ رسائی ہو، وہ سرنگ گرتے ہی ہر تلاش ناکام کر دے گا، جو ایسا لگتا ہے کہ سرنگ ہی انٹرنیٹ توڑ رہی ہے۔
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
ثبوت دینے والا ترتیب
پہلے کلائنٹ کی طرف کی جانچ چلائیں، کیونکہ یہ ایک ہی کمانڈ ہے اور آدھی امکانات ہٹا دیتی ہے۔ پھر تصدیق کریں کہ سرور انٹرنیٹ کے اخراج کے لیے ہی بنا ہے؛ نجی رسائی کے لیے بنایا گیا گیٹ وے عوامی منزلوں کے ناکام ہونے پر ٹوٹا ہوا نہیں ہوتا۔
سرور پر، کلائنٹ سے پنگ بھیجتے وقت انٹرفیس دیکھیں: tcpdump -ni wg0 icmp کو درخواست دکھانی چاہیے، اور tcpdump -ni eth0 icmp کو اس کے باہر نکلنا دکھانا چاہیے، ترجمہ شدہ ہو یا نہ ہو۔ اگر وہ پہلے پر نظر آئے اور دوسرے پر کبھی نہ آئے، تو رکاوٹ سرور پر ہی مقامی ہے۔ اگر وہ نکلے اور کوئی جواب واپس نہ آئے، تو مسئلہ اوپر ہے، اور وہ الگ بات ہے۔
آخر میں اصلاح کو ری بوٹ کے بعد بھی قائم رکھیں۔ فارورڈنگ sysctl فائل میں، فائر وال کے قواعد اس سروس میں جو انہیں لوڈ کرتی ہے، اور کلائنٹ کے راستے اس کنفیگ میں ہونے چاہئیں جو انٹرفیس اٹھاتا ہے، نہ کہ ایسے شیل میں جسے آپ بھول جائیں گے۔ دوبارہ جڑیں، وہی دو امتحان دہرائیں اور تصدیق کریں کہ کاؤنٹر حرکت کر رہے ہیں۔