OpenVPN کلائنٹ کے پیچھے ذیلی نیٹ تک رسائی کیوں نہیں ہے؟

سرور کے ٹنل پتے پر ping کامیاب ہوتے ہیں، کلائنٹ کی اپنی روٹ ٹیبل درست دکھائی دیتی ہے، اور اس کلائنٹ کے پیچھے موجود LAN اب بھی ناقابلِ رسائی ہے۔ کلائنٹ کی روٹنگ ٹیبل درست دکھائی دیتی ہے، سرور کے پاس ٹنل کی طرف اشارہ کرنے والا راستہ ہے، اور پیکٹ پھر بھی غائب ہو جاتے ہیں۔ یہ layer-3 ٹنل کی کلاسیک علامت ہے، جسے معلوم نہیں کہ اس کا ایک کلائنٹ خود بھی گیٹ وے ہے۔

tun انٹرفیس میں ہر کلائنٹ کے لیے اگلا ہاپ نہیں ہوتا۔ کرنل کئی پیریوں والا ایک ہی انٹرفیس دیکھتا ہے، اس لیے دور دراز LAN کے لیے کون سا کلائنٹ پیکٹ لے گا یہ فیصلہ OpenVPN عمل کے اندر کرنا پڑتا ہے۔ وہ فیصلہ iroute سے ترتیب دیا جاتا ہے، اور اس کے بغیر پیکٹ کے پاس جانے کی جگہ نہیں۔

سرور انٹرفیس کے مطابق نہیں، کلائنٹ کے مطابق روٹ کرتا ہے

جب سرور کو کسی کلائنٹ کے ٹنل پتے پر پیکٹ بھیجنا ہوتا ہے تو جواب واضح ہے: پتہ اس کلائنٹ کے سیشن کا ہے۔ لیکن جب منزل اس کلائنٹ کے پیچھے پورا ذیلی نیٹ ہو، تو پتہ سرور کے جاننے والے کسی کا نہیں ہوتا، اور ٹنل کی طرف کرنل راستہ صرف "اس انٹرفیس سے" کہتا ہے، کون سا پیر ہے یہ نہیں بتاتا۔

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

اگر نقشہ سازی نہ ہو تو پیکٹ سرور تک پہنچتا ہے، ٹنل راستے سے میل کھاتا ہے اور رد کر دیا جاتا ہے کیونکہ کوئی کلائنٹ منزل کا دعویٰ نہیں کرتا۔ کچھ بھی واضح خرابی درج نہیں کرتا، اس لیے ناکامی روٹنگ لوپ کے بجائے خاموش سیاہ شگاف جیسی دکھائی دیتی ہے۔

کلائنٹ کا نام لینے والا iroute اندراج لکھنا

iroute سرور کی مرکزی ترتیب میں نہیں، کلائنٹ کے مخصوص ترتیبی فائل میں رہتا ہے۔ client-config-dir اختیار کے ساتھ سرور کو کسی ڈائریکٹری کی طرف اشارہ کریں، پھر ایسی فائل بنائیں جس کا نام کلائنٹ کے سرٹیفکیٹ کا عام نام ہو اور اس میں سابقہ رکھیں۔

جس شاخ کا LAN 10.20.0.0/24 ہے اور سرٹیفکیٹ کا عام نام branch-router ہے، اس راستے کی فائل میں iroute 10.20.0.0 255.255.255.0 جیسی سطر ہوتی ہے۔ مرکزی ترتیب کو صرف ڈائریکٹری اختیار درکار ہے؛ سابقہ کلائنٹ کے پاس رہتا ہے۔

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

ایک کلائنٹ کئی سابقے رکھ سکتا ہے۔ ہر نیٹ ورک کے لیے ایک iroute سطر شامل کریں اور نقشہ سازی کو قابلِ تدقیق رکھنے کے لیے فہرست اس کلائنٹ کی باقی ترتیبات کے ساتھ رکھیں۔

دونوں سمتوں میں واپسی راستہ بنانا

دور دراز LAN تک پیکٹ پہنچانا آدھا کام ہے۔ کلائنٹ کو اس LAN کی ٹریفک بھی ٹنل میں بھیجنی ہوتی ہے، جو عام طور پر کلائنٹ کو راستہ دھکیل کر کیا جاتا ہے: push "route 10.8.0.0 255.255.255.0" جیسی سطر ہر کلائنٹ کو بتاتی ہے کہ سرور کی طرف کے نیٹ ورک تک کیسے پہنچنا ہے۔ شاخ کے لیے، مساوی راستہ سرور کی طرف جس بھی چیز تک پہنچنا ہو اس کے لیے ٹنل کی طرف اشارہ کرتا ہے۔

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

سرور ہوسٹ پر فارورڈنگ فعال ہونی چاہیے۔ اس کے بغیر کرنل ٹنل سے پیکٹ وصول کرتا ہے اور اسے LAN انٹرفیس تک بھیجنے سے انکار کرتا ہے، جو کلائنٹ کے نقطہ نظر سے غائب iroute جیسا ہی دکھائی دیتا ہے۔

درست جانچ کے ساتھ رسائی کی تصدیق

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

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

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