کیا WireGuard کلائنٹ OpenVPN کلائنٹ تک نہیں پہنچ سکتا؟

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

علامت میں ایک وقت میں ایک ہی حصہ غائب ہوتا ہے

wg1 پر 10.71.0.0/24 کا WireGuard پول اور tun1 پر 10.72.0.0/24 کا OpenVPN پول استعمال کرتا ہے، دونوں ایک ہی گیٹ وے پر ختم ہوتے ہیں۔ زیر آزمائش درخواست 10.71.0.5 سے 10.72.0.30 پر HTTPS تک جاتی ہے۔ نیچے ہر قدم اسی ایک بہاؤ کے بارے میں ہے۔ ہر جانچ کا ناکامی کا نشان مختلف ہے حالانکہ صارف انہیں یکساں محسوس کرتا ہے، اور عام طور پر ایک وقت میں تین میں سے صرف ایک غائب ہوتا ہے۔

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

سپوک کی منزل کی کوریج بڑھائیں

WireGuard کلائنٹ پر، موجودہ peer اندراج کو OpenVPN منزل کے لیے گیٹ وے منتخب کرنا ہوگا، یعنی منزل کا سابقہ اس peer کی اجازت شدہ فہرست میں آنا چاہیے۔ اسے شامل کرنے سے دوسری ٹنل نہیں بنتی؛ یہ بدلتا ہے کہ کلائنٹ وہ پتہ ڈھونڈتے وقت کون سا peer منتخب کرتا ہے، اور wg-quick کے ساتھ راستہ عام طور پر فہرست کی خود بخود پیروی کرتا ہے۔

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

اصل چابی اور endpoint کی سطریں اچھوتی چھوڑ دیں، اور یاد رکھیں کہ Table = off استعمال کرنے والا منتظم اس فہرست سے کوئی راستہ نہیں لیتا۔ ایسی صورت میں وہی سابقہ نظام کے راستہ جدول میں اس کے مالک کو نصب کرنا ہوگا، اور وہاں غائب راستہ بالکل غائب اجازت شدہ سابقہ جیسا دکھائی دیتا ہے۔

گیٹ وے پر ماخذ کی ملکیت رکھیں

اس کلائنٹ کا گیٹ وے پر peer اندراج اسی کلائنٹ کے ماخذ پتے کی ملکیت رکھتا رہے۔ اجازت شدہ پتے دونوں طرف جانچے جاتے ہیں: وہ باہر جانے والی ٹریفک کے لیے peer منتخب کرتے ہیں اور تصدیق کرتے ہیں کہ آنے والے پیکٹ کا ماخذ اسی peer کا ہے جس نے اسے بھیجا۔ سپوک اس پول تک پہنچنا چاہتا ہے اس لیے OpenVPN پول کو سپوک کے اندراج میں ڈالنا وہی غلطی ہے جو ٹریفک کو غلط شریک کی طرف دھکیلتی ہے۔

AllowedIPs = 10.71.0.5/32

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

OpenVPN جانب کو واپسی کا راستہ دیں

منزل کو اب WireGuard ماخذ کی طرف واپسی کا راستہ چاہیے، اور پول کلائنٹس کے لیے یہ عام طور پر OpenVPN سرور سے دھکیلا گیا راستہ ہوتا ہے۔ صرف انہی کلائنٹس کو دھکیلیں جن کے پاس یہ ہونا چاہیے، اور یہ ماننے کے بجائے کہ ہدایت لاگو ہوئی، کلائنٹ پر تصدیق کریں کہ یہ قبول ہوا۔

push "route 10.71.0.0 255.255.255.0"

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

صرف اسی ایک سروس کی اجازت دیں جس کی آپ اجازت دینا چاہتے تھے

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

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

باہمی راستے عام طور پر یہ معنی رکھتے ہیں کہ ماخذ کی ترجمانی کی ضرورت نہیں، جو منزل پر WireGuard پتہ محفوظ رکھتا ہے اور لاگ پڑھنے کے قابل بناتا ہے۔ دو پروٹوکول شامل ہیں اس لیے جامع masquerading نہ شامل کریں، اور موجودہ ترجمانی قاعدہ یہ جانے بغیر نہ ہٹائیں کہ اس پر کیا منحصر ہے۔ پھر اسی ایک بہاؤ کو شروع سے آخر تک تصدیق کریں، اور ایک ممنوع ماخذ یا پورٹ بھی آزمائیں: دونوں طرف کام کرنے والا ہینڈ شیک نہ کراس راستہ ثابت کرتا ہے نہ علیحدگی۔