نیٹ ورک نیم اسپیس میں WireGuard: ساکٹ پیچھے کیوں رہ گیا

انٹرفیس اسی نیم اسپیس میں درج ہے جو آپ چاہتے تھے، ایپلیکیشن اس سے جڑی ہوئی ہے، پھر بھی ٹنل ٹریفک کبھی نظر نہیں آتی। یہ Linux کرنل کے اس WireGuard ڈیوائس کی شناخت ہے جو ایک نیم اسپیس میں بنا اور دوسرے میں منتقل ہوا: انٹرفیس منتقل ہو گیا اور اس کا خفیہ کردہ UDP ساکٹ منتقل نہیں ہوا। اندرونی ٹریفک کا مطلب پیدا ہونے سے پہلے دونوں کو صحیح جگہ پر ہونا چاہیے। ایک کے بجائے دو سیاق و سباق دیکھنے ہیں، یہ معلوم ہونے پر جانچ تیز ہو جاتی ہے।

علامت: صحیح نیم اسپیس، مگر پیکٹ نہیں

نیم اسپیس کے اندر ٹنل صحت مند دکھائی دیتا ہے। ڈیوائس موجود ہے، پتے تفویض ہیں اور پیر کی ترتیب موجود ہے। باہر، متوقع UDP تبادلہ اس انٹرفیس پر کبھی نظر نہیں آتا جسے آپ دیکھ رہے تھے، اور دوسرا فریق بتاتا ہے کہ کوئی ہینڈ شیک نہیں ہوا।

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

یہ منتقلی میں نقص نہیں اور نہ پیر کی غلط ترتیب ہے। کرنل کا نفاذ ایسا ہی کرتا ہے، اور WireGuard کے لیے نیم اسپیس دستاویزات بنانے کا قاعدہ براہ راست بیان کرتی ہیں।

ساکٹ کا پیدائشی مقام کیوں ہے

WireGuard ڈیوائس کے پاس اپنی خفیہ کردہ ترسیل کے لیے ایک UDP ساکٹ ہوتا ہے، اور وہ ساکٹ اسی نیم اسپیس میں کھلتا ہے جہاں ڈیوائس بنتی ہے। لنک کمانڈ سے انٹرفیس منتقل کرنے پر نظر آنە والی ڈیوائس منتقل ہوتی ہے مگر ترسیل وہیں رہتی ہے جہاں شروع ہوئی تھی। پھر دونوں چیزوں کے مالک مختلف ہوتے ہیں।

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

ساکٹ جہاں چاہتے ہوں وہیں اسے بنائیں

حل یہ ہے کہ ڈیوائس کو باہر بنا کر منتقل کرنے کے بجائے ہدف نیم اسپیس کے اندر بنائیں। یہ فرض کرتے ہوئے کہ منظور شدہ نیم اسپیس پہلے سے موجود ہے اور نام استعمال میں نہیں:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

اب انٹرفیس اور اس کا ساکٹ دونوں اسی سیاق کے ہیں، اس لیے بنیادی راستہ اور لاگو فلٹر قواعد وہی ہیں جو وہاں ترتیب دیے گئے। اگر ڈیزائن کو واضح پہلو کہیں اور چاہیے تو پہلے بنیادی انٹرفیس نیم اسپیس میں رکھیں اور پھر ٹنل بنائیں। ترتیب ڈیزائن کا حصہ ہے، نفاذ کی تفصیل نہیں।

انہیں نیٹ ورک انتظام کے احکام سمجھیں، ترکیب نہیں। یہ ڈیوائس بناتے ہیں اور حالت دکھاتے ہیں؛ چابیاں، پیر، پتے اور راستے اب بھی منظور شدہ ترتیب سے آنے چاہئیں، اور چلتی ہوئی پروڈکشن انٹرفیس کو کبھی مثال میں نہیں بدلنا چاہیے।

راستے کے دونوں رخ پڑھیں

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

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

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

ایک اور جانچ ریکارڈ میں ہونی چاہیے: دوبارہ شروع ہونے کے بعد ڈیوائس کیسے بنتی ہے। جو منتظم مختلف بنانے کے سیاق کے ساتھ انٹرفیس دوبارہ بناتا ہے وہ ساکٹ کا پیدائشی مقام بدل دیتا ہے। ایک بار چلنے والی دستی منتقلی منظم راستے کے بارے میں ثبوت نہیں ہے।