خادم 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

وصّل عميلًا لم يكن متصلًا سابقًا وأكّد أن العنوان يقع داخل النطاق المعلن وخارج المجموعة المحجوزة. ثم أكّد مسار العودة: يجب أن يصل العميل إلى ما تسمح به السياسة ولا شيء أكثر. العنوان الذي يطابق الخطة لكن لا مسار عامل له ليس تغييرًا ناجحًا.

أعد توصيل عميل كان يحمل عنوانًا من النطاق القديم. يجب أن يتلقى عنوانًا من النطاق الجديد، ويجب أن تزول أي حالة مرتبطة بالجلسة ومرتبطة بالعنوان القديم. إذا احتفظ بالعنوان القديم، فشيء آخر يخصصه والتجمّع ليس المالك الذي تظنه.

التراجع عن تغيير في النطاق

احتفظ بالأسطر الثلاثة السابقة في سجل تغييراتك، لا بالملف السابق فقط. استعادتها وإعادة التشغيل تعيد التخصيص إلى السلوك القديم، والعملاء الذين يعيدون الاتصال بعد ذلك سيتلقون عناوين منه.

تحذيران ينتميان إلى السجل. العملاء المتصلون بالفعل عند التراجع يحتفظون بعناوينهم الحالية حتى يعيدوا الاتصال، فالتراجع ليس فوريًا عبر الأسطول كله. وإذا كان النطاق القديم يتقاطع مع تعيين ثابت، فإن استعادته تعيد التصادم أيضًا؛ ذلك التقاطع هو سبب التغيير، ويحتاج إلى إصلاح مختلف عن التراجع.

ينتهي تغيير التجمّع عندما يتلقى عميل جديد عنوانًا داخل النطاق، ولا يُمنح عنوان محجوز أبدًا، وتظل المسارات والقواعد التي تستهلك تلك العناوين تعمل كما هو مقصود. أي شيء أقل يترك للشخص التالي اكتشاف أي الثلاثة غير صحيح.