مركز OpenVPN واحد وثلاث شبكات LAN: خطة العناوين وملفات iroute

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

اعمل على الخطوات بالترتيب. كل خطوة تعتمد على الخطة من الخطوة السابقة، ولا تحتاج أي منها إلى هيئة شهادات جديدة.

ابدأ بخطة لا يحتاج أحد إلى تخمينها

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

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

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

أخبر نواة المركز أين توجد الفروع

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

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

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

أعطِ كل فرع المسارات التي يحتاجها

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

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

الموقع الرابع يتبع النمط نفسه: اسم مصادق عليه مميز، وبادئة مملوكة، ومسار في نواة المركز، و iroute، وإعلانات فقط للمواقع المسموح لها بالوصول إليه.

اختبر في الاتجاهين قبل أن تعتبره منتهيًا

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

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

سجّل الخطة وملفات كل عميل وقواعد الجدار الناري في وثيقة واحدة، لأن إضافة الموقع التالي ستُقاس عليها.

يتماسك التصميم لأن لكل طبقة مهمة واحدة: الخطة تبقي البادئات فريدة، والمسار في النواة ينقل الحزم، و iroute يسمّي المالك، والجدار الناري يقرر ما هو مسموح. عندما ينكسر شيء، فإن تلك القائمة هي أيضًا ترتيب فحصه.