وہ سرور لائن جو CIDR لاحقے کو نقطوں والے ماسک کے ساتھ ملاتی ہے، ڈیمون کو پورٹ کھولنے سے پہلے ہی روک دیتی ہے۔ IPv4 کے لیے server معاون دو الگ دلائل چاہتا ہے: ایک سیدھا نیٹ ورک پتہ، پھر نقطوں والی شکل میں نیٹ ماسک۔ اُس لائن پر باقی سب قیاس ہے، اور قیاس ہی میں پول کے سائز اور کلائنٹ ماسک غلط ہوتے ہیں۔

وہ دو دلائل جو معاون قبول کرتا ہے

پہلے نیٹ ورک لکھیں اور پھر ماسک، پتے کے ساتھ کچھ بھی جوڑے بغیر:

server 10.72.16.0 255.255.240.0

یہ /20 کی شکل ہے۔ نیچے والی لائن غلطی ہے، اور یہ رن ٹائم میں نہیں، اختیارات کی تجزیہ کاری میں ناکام ہوتی ہے:

server 10.72.16.0/20 255.255.240.0

اسے ڈیبگ کرتے وقت دونوں خیال الگ رکھیں۔ سابقہ کی لمبائی اور نقطوں والا ماسک ایک ہی حد بیان کرتے ہیں، مگر معاون دونوں ایک ساتھ قبول نہیں کرتا، اور مسترد شدہ لائن ایسی اختیار خرابی دیتی ہے جو ہدایت کا نام لیتی ہے، حساب کا نہیں۔

ماسک لکھنے سے پہلے نیٹ ورک سیدھا کریں

پہلا پتہ حد کا نیٹ ورک پتہ ہے، اس کے اندر کا آسان کلائنٹ پتہ نہیں۔ /20 کے لیے حد 10.72.16.0 سے 10.72.31.255 تک چلتی ہے، اور ان میں سے صرف پہلا ہی درست نیٹ ورک دلیل ہے۔ /21 255.255.248.0 استعمال کرتا ہے اور 10.72.16.0 سے 10.72.23.255 تک محیط ہے، لہٰذا اس کی لائن server 10.72.16.0 255.255.248.0 ہے۔

سابقہ بدلنے سے حد بدلتی ہے اور کچھ نہیں۔ اس سے یہ نہیں بدلتا کہ ایک کلائنٹ کو کتنے پتے ملتے ہیں، کیونکہ یہ ٹوپولوجی کی خصوصیت ہے، اس لائن کے ماسک کی نہیں۔

سرور کی طرف سے پول کی تصدیق کریں

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

openvpn --config /etc/openvpn/server.conf --verb 4 --dev tun9 --port 1195

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

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

ٹوپولوجی کو مدنظر رکھتے ہوئے کلائنٹ کا ماسک پڑھیں

کلائنٹ اپنے ٹنل انٹرفیس پر /30 دکھائے، یہ خراب پول کا ثبوت نہیں۔ نقطہ سے نقطہ پتوں کے نظام میں ہر کلائنٹ چھوٹا بلاک پاتا ہے اور اس کے انٹرفیس کا ماسک وہی بلاک بیان کرتا ہے، جبکہ سرور کا پول مجموعی کو ڈھانپتا ہے۔ ذیلی نیٹ ٹوپولوجی میں اس کے بجائے کلائنٹ کا ماسک پول کے ماسک سے میل کھاتا ہے۔ اس لیے ماسک اکیلا بتاتا ہے کہ کون سی ٹوپولوجی کام کر رہی ہے، یہ نہیں کہ پول درست لکھا گیا ہے۔

نتیجے پر پہنچنے سے پہلے ترتیب شدہ ٹوپولوجی اور مختص کردہ پتہ ایک ساتھ جانچیں:

ip -4 addr show tun0

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

چلتے ہوئے پول کو بدلنا

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

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

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

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