إعداد التوجيه الديناميكي (خاصة BGP) عبر نفق OpenVPN على Linux (وربما * BSD)

لماذا وماذا عن هذا المقال؟

إذا كنت google حول الموضوع "openvpn bgp" ، فيمكنك العثور على العديد من المقالات المهمة والمفيدة من وجهة نظر عملية (على سبيل المثال ، مرة أو مرتين ). لكن البدء في حل المشكلة في العنوان ، لأسباب عديدة لم أكن حتى عناء أن أذهب إليها. جاءت الفكرة بطريقة أو بأخرى خلال عمل طويل مع OpenVPN بشكل عام (ضمن إطار مهام نموذجية تمامًا ، مع مجموعة ثابتة من الشبكات من كلا الجانبين) ، والعمل مع تطبيق OpenVPN على نظام RouterOS الخاص بـ MikroTik ، وربط أنظمة Linux و RouterOS مع بعضها البعض. في الواقع ، في عملية تحقيق أسباب كتابة تنفيذنا الخاص لـ OpenVPN في RouterOS ، جاءت "البصيرة" حول كيفية حل هذه المشكلة في إطار إصدار OpenVPN المجهز بالكامل. ثم كان هناك فحص تجريبي قصير ، والذي أظهر قدرة العمل الكاملة للفكرة وإطلاق هذا الحل في التشغيل "الصناعي".

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

جوهر المشكلة ("من يقع اللوم؟")

ما الفرق بين الإصدار العادي من OpenVPN والإصدار الذي يتم تنفيذه في RouterOS؟ من المحتمل وجود بعض الاختلافات ، لكن في هذه المقالة سننظر في شيء واحد فقط: نظام OpenVPN العادي في أنظمة أخرى غير RouterOS (وربما البعض الآخر) عبارة عن توليفة تحتوي على جزء النقل (أي ، نقل الحزمة نفسه ، إعادة التوجيه ، إنها أيضًا طائرة بيانات ) والتوجيه (أي ، تبادل المعلومات حول الطرق ، إنه التوجيه ، إنها أيضًا طائرة تحكم) ، وفي RouterOS تكون خدمة OpenVPN مسؤولة فقط عن جزء النقل ، ويتم التعامل مع التوجيه من خلال عملية نظام مختلفة ، من ناحية ، لا تسمح بتكرار وظيفة التوجيه تحت النظام (علاوة على ذلك ، لا تحتفظ بعدة جداول توجيه متطابقة في خدمات مختلفة وتزامنها باستمرار مع بعضها البعض) ، ومن ناحية أخرى ، تسمح بنقل جداول طاولات شفافة عبر هذه المركبات وتغيير جداول المسارات على كلا الجانبين أثناء الطيران.

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

حل المشكلة ("ماذا تفعل")

عند تحليل البرامج النصية الخاصة بي والتي تقوم بأتمتة تعيين المسارات لمختلف العملاء ، لاحظت أن OpenVPN لديه خياران مختلفان يحددان المسارات:

• i route - يضبط الطرق داخل جدول التوجيه لعملية OpenVPN.
• route - يعين المسارات التي تمر بها عملية OpenVPN إلى جدول مسار النظام (أي ، يضيف المسارات إلى الجدول من خلال واجهة النفق عند الاتصال بها ويحذفها عند قطع الاتصال).

السؤال الواضح الذي يطرح نفسه: ماذا سيحدث إذا أضفت المسار 0.0.0.0/0 على كلا الجانبين باستخدام i route ، ثم أضفت أو أزالت المسارات الضرورية (بما في ذلك تلك التي تظهر أو تختفي بشكل حيوي) على واجهة النفق نفسها ، على سبيل المثال ، مع خدمة توجيه ( هزت ، حمار وحشي / quagga ، الطيور ، وما إلى ذلك)؟

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

يعمل المخطط في وضع TLS-over-TCP ، أي للتكوين ، يجب عليك أولاً إنشاء مفاتيح وشهادات SSL.

أدناه ، أعطي مثالاً على تكوين OpenVPN للخادم وجانب العميل.

التكوين من جانب الخادم (واحد لكل عميل).

ملف server_dyn_rt.conf (جانب الخادم)

 daemon compress ping-timer-rem persist-tun persist-key tls-server proto tcp-server topology net30 mode server script-security 3 keepalive 15 45 tun-mtu 1500 remote-cert-tls client verify-x509-name <CLIENT_DISTINGUISHED_NAME> name auth <TLS_AUTH_ALGORITHM> cipher <CIPHER_ALGORITHM> local <SERVER_PUBLIC_IP> lport <SERVER_PUBLIC_PORT> dev-type tun dev <TUNNEL_INTERFACE_NAME> ifconfig <TUNNEL_SERVER_SIDE_IP> <TUNNEL_CLIENT_SIDE_IP> client-connect client_connect.sh push "route-gateway <TUNNEL_SERVER_SIDE_IP>" push "topology net30" push&nbsp"persist-tun" push&nbsp"persist-key" <dh> ... Diffie-Hellman data <</dh> <ca> ... Certificate Authority certificate data </ca> <cert> ... Server certificate data </cert> <key> ... Server Private Key data </key> 

ملف client_connect.sh (جانب الخادم)

 #!/bin/sh echo 'ifconfig-push TUNNEL_CLIENT_SIDE_IP TUNNEL_SERVER_SIDE_IP' >> ${1} echo 'push "iroute 0.0.0.0 0.0.0.0"' >> ${1} echo 'iroute 0.0.0.0 0.0.0.0' >> ${1} exit 0 

ملف client_dyn_rt.conf (جانب العميل)

 daemon compress tls-client auth <TLS_AUTH_ALGORITHM> cipher <CIPHER_ALGORITHM> client dev-type tun dev <TUNNEL_INTERFACE_NAME> script-security 3 remote-cert-tls server verify-x509-name <SERVER_DISTINGUISHED_NAME> name remote <SERVER_PUBLIC_IP> <SERVER_PUBLIC_PORT> tcp <ca> ... Certificate Authority certificate data </ca> <cert> ... Client certificate data </cert> <key> ... Client Private Key data </key> 

لا أذكر إعدادات الحزم وبروتوكولات التوجيه ، إما بسبب مجموعة متنوعة من الحزم ، أو بسبب مجموعة متنوعة من الإعدادات نفسها (في الواقع ، كمصدر لأمثلة التكوين ، يمكنك استخدام الثاني من المقالات ، الروابط التي ترد في بداية المقال). أريد فقط أن أشير إلى أن الإعداد أعلاه يسمح لك باستخدام BGP على وجه الخصوص (وهو ما يعجبني شخصيًا بسبب "قابليته للتحكم" والقدرة على نقل طرق البروتوكولات المختلفة في نفس الجلسة). في حالة BGP ، يجب استخدام العنوان <TUNNEL_CLIENT_SIDE_IP> كعنوان للجار على جانب "الخادم" ، ويجب استخدام العنوان <TUNNEL_SERVER_SIDE_IP> أو العناوين "الداخلية" للأطراف المعنية على جانب العميل ، ولكن بعد ذلك تحتاج إلى إضافة التوجيهات المقابلة للتكوين الخادم و / أو العميل.

إيجابيات وسلبيات الحل أعلاه

سلبيات:

1. يجب أن يكون هناك عميل واحد لكل خادم بالضبط ، لذلك سيكون عليك الاحتفاظ بالعديد من عمليات OpenVPN نشطة لعدة عملاء. نتيجة لذلك - بعض ذاكرة التجاوز وكل ذلك.
2. لا يمكنك استخدام وضع المفتاح الذي تمت مشاركته مسبقًا في OpenVPN ، لأن النقل الديناميكي للمعلمات من هذا الخادم إلى العميل (دفع / سحب) محظور في هذا الوضع. لهذا السبب ، هناك حاجة إلى تكوين أكثر تعقيدًا ، بما في ذلك إنشاء مجموعة من المفاتيح والشهادات ، بالإضافة إلى برنامج نصي لإنشاء جزء تكوين عميل على جانب الخادم (والذي ، مع ذلك ، يمكن استبداله بدليل للملفات الثابتة عن طريق استبدال خيار client-connect /path/to/script بخيار client-connect-dir /path/to/config/dir ، مما يزيد من مستوى أمان جانب الخادم.

الايجابيات:

1. على عكس البروتوكولات مثل GRE / IPIP ، يمكن أن تحتوي أنفاق OpenVPN على وحدة MTU تبلغ 1500 بايت (لأن عملية OpenVPN تخفي كل التجزئة / التجزئة "تحت الغطاء" عن طريق إرسال حزم كاملة الطول إلى واجهة النفق). هذا يجعل من السهل تكوين جميع أنواع الأنفاق الثانوية عبر نفق OpenVPN.
2. يدعم نفق OpenVPN في وقت واحد نقل كل من IPv4 و IPv6 ، مما يقلل من عدد الأنفاق بين أزواج العقد وتكلفة تكوينها وإدارتها ، وكذلك نقل مسارات IPv6 ضمن نفس جلسة BGP مثل مسارات IPv4.
3. جميع مزايا بروتوكول OpenVPN ، مثل سهولة إعداد معدات الشبكة الوسيطة (أو الافتقار الكامل للحاجة إليها) ، والقدرة على إخفاء حركة المرور بموجب HTTPS ، ووجود تطبيق لمعظم المنصات ، إلخ ، إلخ.

آمل أن يجد شخص ما الدليل أعلاه مفيدًا.