WireGuard رک جاتا ہے: MTU کی حد یا گم شدہ فارورڈنگ قاعدہ؟
سرور کے آگے کچھ بھی نہ چلنا فارورڈنگ یا واپسی راستے کا مسئلہ ہے۔ چھوٹی درخواستیں چلیں اور بڑی رک جائیں، یہ پیکٹ سائز کی علامت ہے۔
عادت یہ ہے کہ WireGuard کے بگڑتے ہی MTU کم کر دیا جائے، اور یہ عادت ایک اور خرابی چھپا دیتی ہے۔ جو گیٹ وے آگے نہیں بھیجتا اور جو راستہ بڑے پیکٹ نہیں اٹھاتا، وہ الگ پہچانے جانے والے نمونے بناتے ہیں: ایک دونوں سمتوں میں اور ہر سائز پر ناکام ہوتا ہے، دوسرا چھوٹی درخواستوں میں بچ جاتا ہے اور بڑیوں پر مر جاتا ہے۔ کوئی بھی عدد بدلنے سے پہلے طے کریں کہ آپ کے پاس کون سی شکل ہے۔ جانچ سستی ہے اور ممکنہ وجوہات میں سے نصف دور کر دیتی ہے۔
دو ناکامیاں، دو مختلف شکلیں
فارورڈنگ کا مسئلہ سرور کے فوراً بعد ظاہر ہوتا ہے۔ مصافحہ کامیاب ہوتا ہے، ٹنل کا پتہ جواب دیتا ہے، اور گیٹ وے کے پیچھے چھوٹی درخواست سے بھی کچھ نہیں پہنچتا۔ پیکٹ سرور تک پہنچا اور آگے نہیں بھیجا گیا، یا جواب کے پاس واپسی کا کوئی راستہ نہیں تھا۔
سائز کا مسئلہ صرف ایک حد سے اوپر ظاہر ہوتا ہے۔ DNS، TCP مصافحہ اور چھوٹی API کال چلتی ہیں، جبکہ فائل ڈاؤن لوڈ یا بڑا جواب رک جاتا ہے۔ جو پیکٹ سما گئے وہ ایک سرے سے دوسرے سرے تک گئے، اور جو نہ سما سکے وہ کہیں بغیر کسی کارآمد رپورٹ کے پھینک دیے گئے۔
یہ تفصیلات مختلف لوگوں اور مختلف کنفیگریشن فائلوں کی طرف اشارہ کرتی ہیں، اس لیے اندازے سے بہتر ہے کہ شکل کو ناپا جائے۔ گیٹ وے پر ایک تنہا پنگ انہیں الگ نہیں کر سکتا۔
کچھ بھی کم کرنے سے پہلے فارورڈنگ کو خارج کریں
گیٹ وے کو نہیں، گیٹ وے کے آگے کے منزل کو جانچیں۔ سرور کے ٹنل پتے پر پنگ صرف یہ ثابت کرتا ہے کہ انٹرفیس چل رہا ہے اور آپ اس مشین تک پہنچتے ہیں جو ٹنل ختم کرتی ہے۔ وسیع نیٹ ورک کی ٹریفک کا انحصار اس مشین پر IP فارورڈنگ کے فعال ہونے اور فارورڈ شدہ بہاؤ کی اجازت دینے والے فائر وال پر ہے۔ دونوں درست ہونے چاہئیں، اور اگر ایک بھی غلط ہو تو وہی خاموشی پیدا ہوتی ہے۔
واپسی روٹنگ بھی اتنی ہی اہم ہے۔ اگر منزل کا نیٹ ورک نہ جانے کہ کلائنٹ کے ٹنل پتے تک کیسے پہنچنا ہے، تو درخواست آتی ہے اور جواب غائب ہو جاتا ہے، اور کلائنٹ ایسا وقت ختم ہونے کی اطلاع دیتا ہے جو پھینکے گئے فارورڈ جیسا ہی دکھتا ہے۔
جہاں ڈیزائن پتہ ترجمہ استعمال کرتا ہے، وہاں ترجمے کا قاعدہ اسی واپسی راستے کا حصہ ہے۔ MTU مسئلے کا پیچھا کرتے ہوئے اسے ہٹانا چلتی ہوئی ڈیزائن کو ٹوٹی ہوئی میں بدل دیتا ہے، اس لیے ترمیم سے پہلے موجودہ قواعد پڑھیں۔
ناپ لیں کہ ٹوٹ کہاں سے شروع ہوتی ہے
پہلے فارورڈنگ کی حالت اور فلٹر قواعد پڑھیں۔ یہ صرف پڑھنے کی جانچیں ہیں اور سستے سوال کا جواب دیتی ہیں:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9پھر کلائنٹ سے گیٹ وے کے آگے کے ہوسٹ کی طرف، don’t-fragment بٹ کے ساتھ سائز جانچیں:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9اگر پہلی جانچ چلے اور دوسری ٹکڑوں میں تقسیم کی غلطی سے ناکام ہو، تو راستہ آپ کو اپنا قابل استعمال سائز بتا رہا ہے۔ اگر دونوں میں سے کوئی نہ چلے، تو آپ فارورڈنگ یا روٹنگ دیکھ رہے ہیں، اور MTU بدلنے والا متغیر نہیں ہے۔
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
جس تہہ کو آپ نے ثابت کیا اسے ٹھیک کریں
جب فارورڈنگ خرابی ہو، تو درستی ایک فارورڈنگ قاعدہ یا راستہ ہے، جسے ڈیزائن جتنا تنگ اجازت دے اتنا تنگ بیان کیا گیا ہو۔ جب سائز خرابی ہو، تو درستی ایسا MTU ہے جو اسی مخصوص راستے پر انکیپسولیشن کا حساب رکھتا ہے، اور ضرورت والے انٹرفیس پر لاگو ہوتا ہے، بیڑے کے ہر اڈاپٹر پر نہیں۔
بہرحال، بعد میں اسی منزل کی طرف وہی کام دہرائیں۔ اگر اصل بڑی منتقلی اب مکمل ہوتی ہے، تو تبدیلی نے اس تہہ کو حل کیا جو ناکام ہو رہی تھی۔ اگر صرف چھوٹی جانچ بہتر ہوئی، تو آپ نے علامت کا علاج کیا اور اصل حد اب بھی اپنی جگہ پر ہے۔
لکھیں کہ تبدیلی سے پہلے آپ نے کون سی شکل دیکھی۔ درستی کے ساتھ درج وہ ایک سطر ہی اگلے شخص کو ایسا MTU کم کرنے سے روکتی ہے جو کبھی مسئلہ نہیں تھا۔