OpenVPN سرور nopool کے ساتھ: واضح پول رینج کا اعلان کریں

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

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

اسی سب نیٹ سے شروع کریں جو آپ کے پاس پہلے سے ہے

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

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

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

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

nopool شامل کریں اور رینج کا اعلان کریں

معاون کلیدی لفظ nopool قبول کرتا ہے، جو سب نیٹ کنفیگریشن رکھتا ہے اور خودکار متحرک پول کو دبا دیتا ہے، جیسا کہ OpenVPN 2.6 دستی بیان کرتا ہے۔ پھر واضح ifconfig-pool سطر وہ شامل رینج دیتی ہے جس کا آپ ارادہ رکھتے ہیں، اور اس کا نیٹ ماسک سب نیٹ سے مطابقت رکھتا ہے۔ دونوں سطریں ایک ہی سرور بلاک میں آتی ہیں، کیونکہ اپنے سب نیٹ کے بغیر پول کا کوئی مطلب نہیں۔ ان کے درمیان ترتیب صرف پڑھنے کی سہولت کے لیے اہم ہے، کیونکہ سروس شروع ہونے پر معاون اس جوڑے کو کھولتا ہے۔

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

دونوں حدود شامل ہیں، اس لیے مثال اکہتر پتے پیش کرتی ہے۔ سرور کا پتہ اور ہر مستقل تفویض اس دائرے سے باہر رکھیں؛ متحرک رینج کے اندر پڑنے والی مستقل تفویض ایسی ٹکر پیدا کرتی ہے جو کنکشن کی ترتیب پر منحصر ہوتی ہے، اور یہ ڈیبگ کرنے کے لیے بدترین قسم ہے۔ اگر مستقل تفویضات بڑھنے کا امکان ہو تو مخصوص مجموعے اور رینج کے درمیان فرق رکھیں۔

رینج کا حجم اور ہم وقتی الگ حدود ہیں۔ max-clients اگر کچھ اور کہے تو سو پتے سو ہم وقت کلائنٹ نہیں ہیں، اور ہم وقتی حد سے بڑا پول بربادی نہیں بلکہ معمول ہے۔ اہم یہ ہے کہ دونوں حدود طے شدہ رویے سے ورثے میں لینے کے بجائے باشعور طریقے سے چنی جائیں۔

مستقل تفویضات کو متحرک رینج سے باہر رکھیں

کلائنٹ کے لیے مخصوص ifconfig-push پول تقسیم سے مختلف طریقہ کار ہے اور اسے فعال ٹوپولوجی کے مطابق پیرامیٹر استعمال کرنے چاہئیں۔ سب نیٹ موڈ میں یہ ایک پتہ اور نیٹ ماسک ہے؛ پرانی مثال میں دکھائی دینے کی وجہ سے net30 جوڑا لانا عام غلطی ہے۔

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

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

زندگی چکر سے نافذ کریں، پھر تصدیق کریں

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

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

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

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

رینج کی تبدیلی واپس لینا

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

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

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