مستخدم بوابة Access Server: توجيه الشبكة المحلية لفرع العميل

يمكنك أن تصل إلى عنوان النفق لعميل OpenVPN ثم لا تصل إلى أي مضيف على الشبكة المحلية خلفه. يمنح Access Server ذلك العميل عنوانًا من مجمع VPN، وعنوان المجمع هو كل ما يعرف الخادم أنه يملكه. بادئة الفرع حقيقة منفصلة يجب إعلانها، وحتى بعد إعلانها يحتاج الفرع إلى مُمرِّر والمركز الرئيسي إلى مسار عودة. والمسار المكتوب في المكان الخطأ لا يغيّر شيئًا.

عنوانان، وادعاءان مختلفان للملكية

عند اتصال العميل يمنحه Access Server عنوانًا من مجمع VPN المهيّأ، مثل 10.90.0.0/24. هذا التخصيص إجارة لمضيف واحد. ولا يقول الاتصال إن العميل نفسه يقف أمام 10.60.0.0/24، ولن يخمّن الخادم: بادئة الشبكة المحلية لا يُوصل إليها عبر عميل معيّن إلا إذا أعلنها مسؤول.

لهذا لا يعمل مسار ثابت على جهاز آخر. يقول المسار أرسل 10.60.0.0/24 إلى هذا العنوان، لكن إن كان العنوان لعميل لم يُعلَّم كبوابة فلن يجد الخادم سببًا لتسليم تلك الحزم إليه، وقد تُسقطها حزمة العميل. الإعلان والمسار نصفان لآلية واحدة.

ما الذي يثبته إعداد البوابة فعليًا

في واجهة الإدارة يكون الإعلان خاصية مستخدم: فعّل Configure VPN gateway على مستخدم الموصل وأدخل بادئة الفرع الحقيقية في Network on the VPN client side. يُصادق هذا المستخدم كغيره، فيحتاج سياسة بيانات اعتماد تناسب جهازًا بلا مراقبة، وملف الدخول التلقائي سرّ لا ملف راحة.

خلف ذلك المربع يعامل الخادم البادئة كقابلة للوصول عبر عنوان المجمع لذلك العميل، ويحدد إعداد التوجيه تحت Access Controls ما يُبلَّغ للعملاء الآخرين: المسارات المدفوعة إلى العملاء العاديين وقواعد الوصول التي تسمح بمرور الحركة من شبكات المركز إلى عناوين العملاء وشبكاتهم الفرعية. فعّل التوجيه للشبكات التي يجب أن تصل إلى الفرع، وأبقِ قائمة الشبكات المسموحة قصيرة.

لا تشارك توجيهات بنمط Community الملصقة في ملف مُولَّد في هذا النموذج. فالمنتج يملك جدول التوجيه الذي يدفعه، وأي سطر مُحرَّر يدويًا يُستبدل عند التوليد التالي أو يُتجاهل.

أكمل مساري العودة في الشبكتين

خطة ملموسة: المركز 10.40.0.0/24، الفرع 10.60.0.0/24، مجمع VPN 10.90.0.0/24، و Access Server يُوصل إليه بعنوان خاص من جهة المركز. يحتاج موجّه المركز إلى مسارات لبادئة الفرع وللمجمع، كلاهما نحو Access Server. بدونها يحمل النفق الطلب ويخرج الرد عبر البوابة الافتراضية، وهو الاتصال النصف المفتوح المعروف.

في الفرع يجب أن يمرّر الموصل الحزم غير الموجّهة إليه: تمكين تمرير IP في نظامه بالإضافة إلى إذن تمرير محصور بواجهتي النفق والشبكة المحلية؛ على Linux هو net.ipv4.ip_forward=1 مع قواعد سلسلة forward، وعلى Windows هو التوجيه والوصول البعيد. ثم تحتاج مضيفات الفرع مسار عودة: إما أن يكون الموصل بوابتها الافتراضية، أو تحمل البوابة القائمة مسارات محددة لبادئتي المركز والمجمع.

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

اقرأ الفشل كمسار لا كإذن

اختبر بترتيب ثابت: أولًا خدمة مسموحة من Access Server إلى مضيف في الفرع، ثم الخدمة نفسها من مضيف عادي في المركز، ثم الاتجاه المعاكس إن سمحت السياسة. إن نجح الأول وفشل الثاني فالمسارات المدفوعة أو قواعد الوصول هي المشكلة. وإن نجح الاثنان ولم تصل الردود فافحص التمرير في الفرع ومسار العودة في المركز.

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

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

درس Access Server من موقع إلى موقع يسرد الإعدادات نفسها بترتيب المنتج، ويستحق أن يُتبع مرة قبل تكييف التصميم على بادئاتك.