10.77.20.0/24 کے لیے کوئی پیکٹ OpenVPN سرور پر دو الگ فیصلوں سے گزرتا ہے: آپریٹنگ سسٹم کو اسے VPN انٹرفیس کے حوالے کرنا ہوتا ہے، اور OpenVPN کو معلوم ہونا چاہیے کہ وہ پری فکس کس منسلک کلائنٹ کی ملکیت ہے۔ کرنل روٹ غائب ہو تو پیکٹ سرنگ تک پہنچنے سے پہلے گرا دیا جاتا ہے، اور پیئر روٹ غائب ہو تو بعد میں گرا دیا جاتا ہے۔ دور دراز کی LAN سے دونوں ناکامیاں ایک جیسی دکھتی ہیں، اور یہ جانچنے کے لیے کہ آپ کے پاس کون سی ہے، ہر طرف ایک کمانڈ درکار ہے۔

روایتی صارف اسپیس ڈیٹا پاتھ میں کرنل روٹ پیکٹ کو سرنگ کے عمل میں داخل کرتا ہے اور iroute اُس عمل کو بتاتا ہے کہ کون سا پیئر اسے وصول کرے۔ کوئی بھی دوسرے کا متبادل نہیں، اور صرف ایک پر مشتمل کنفیگریشن پہلے پنگ تک معقول دکھتی رہے گی۔

ایک نہیں، دو فیصلے

ایک سائٹ ٹو سائٹ لنک کا تصور کریں جہاں 10.77.20.0/24 ایک ہی کلائنٹ کے پیچھے ہے۔ سرور کا کرنل روٹ، مثلاً ip route add 10.77.20.0/24 dev tun0، مماثل پیکٹ سرنگ ڈیوائس کی طرف بھیجتا ہے۔ پھر OpenVPN اپنی اندرونی جدول دیکھتا ہے، جو کلائنٹ کنفیگ ڈائریکٹری میں iroute اندراجات سے بنی ہوتی ہے، تاکہ طے کرے کہ کون سا پیئر کنکشن انہیں وصول کرے گا۔ کرنل روٹ کے بغیر پیکٹ عمل تک پہنچتا ہی نہیں، اور پیئر روٹ کے بغیر وہ عمل تک پہنچ کر کہیں نہیں جاتا۔

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

iroute کہاں رکھا جاتا ہے اور کیا بتاتا ہے

اندراج کلائنٹ کے common_name کے نام سے بنائی گئی فی کلائنٹ فائل میں، client-config-dir کے تحت، iroute 10.77.20.0/24 کی صورت میں جاتا ہے۔ فائل نام کا میل محض ظاہری نہیں: OpenVPN تصدیق شدہ شناخت تلاش کرتا ہے اور بالکل اُسی نام کی فائل پڑھتا ہے، لہٰذا site-a نامی فائل صرف اُس کلائنٹ پر اثر انداز ہوتی ہے جس کا common name site-a ہو۔ اگر ایسی فائل کے بغیر کلائنٹس کو فوراً مسترد کرنا ہو تو ccd-exclusive شامل کریں، جو تب درست ترتیب ہے جب ہر کلائنٹ سائٹ گیٹ وے ہو۔ ہر گیٹ وے کے لیے ایک فائل رکھیں اور اس کا نام اُس سرٹیفکیٹ سبجیکٹ پر رکھیں جو آپ واقعی جاری کرتے ہیں۔

سرور سے اندراج جانچیں، دور دراز کی LAN کو مورد الزام ٹھہرانے سے پہلے۔ اسٹیٹس فائل منسلک کلائنٹس کو اُن کے common names کے ساتھ فہرست کرتی ہے، اور --verb 4 پر چلنے والا سرور پیئر کے جڑنے کے ساتھ iroute کی تنصیب لاگ کرتا ہے۔ اگر کنکشن کے وقت کچھ ظاہر نہ ہو تو فائل غلط ڈائریکٹری میں ہے یا غلط شناخت کا نام لیتی ہے۔

پھندا: فائل موجود، شناخت غلط

صحیح دکھنے والا iroute اگر غلط پیئر سے منسلک ہو تو غائب فائل سے زیادہ وقت ضائع کرتا ہے، کیونکہ ڈسک پر سب کچھ درست دکھتا ہے۔ سرٹیفکیٹ کا نام بدلنا، دہرائے گئے common names، اور مؤثر شناخت بدل دینے والا username-as-common-name، یہ سب ایسا پیدا کرتے ہیں۔ یہ دیکھیں کہ سرور نے کس شناخت کی تصدیق کی، نہ کہ آپ نے کس کی توقع کی تھی: اسٹیٹس آؤٹ پٹ مستند ہے، جبکہ فائل نام محض تلاش کی کلید ہے۔

روٹ اپنے مالک سے زیادہ عرصہ زندہ بھی رہ سکتا ہے۔ اسٹیٹک روٹس اور iroute اندراجات پری فکس بیان کرتے ہیں، دستیابی کی ضمانت نہیں، اس لیے ٹریفک ایسے پیئر کی طرف رواں رہ سکتی ہے جو اس وقت منقطع ہے۔

پیئر سے آگے کا راستہ مکمل کریں

پیئر کی ملکیت راستے کا وسط ہے، اختتام نہیں۔ کلائنٹ کو سرنگ سے پیکٹ اپنی LAN میں آگے بھیجنے ہوں گے، جس کا مطلب اُس ہوسٹ پر IP فارورڈنگ فعال ہونا اور ٹرانزٹ کی اجازت دینے والا فائر وال اصول ہے۔ دور دراز LAN کے ہوسٹس کو سرنگ ایڈریس کے لیے واپسی کا راستہ چاہیے، یا تو گیٹ وے کی طرف اشارہ کرنے والا روٹ یا کلائنٹ کی طرف سوچا سمجھا NAT ڈیزائن۔ کلائنٹ پر فارورڈنگ کی ترتیب sysctl net.ipv4.ip_forward سے تصدیق کریں، ڈسٹری بیوشن کے طے شدہ قدر کو فرض نہ کریں۔

اگر دیگر VPN کلائنٹس کو بھی اُس سب نیٹ تک پہنچنا ہو تو ترتیب پھر بڑھ جاتی ہے: سرور کو client-to-client درکار ہوتا ہے، اور اُن کلائنٹس کو پری فکس سرنگ کے ذریعے روٹ کرنا ہوتا ہے۔ ان میں سے کوئی چیز سرور کی اپنی روٹنگ جدول سے لازم نہیں آتی۔

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

متعلقہ مضامین