هل يمكن لعملاء خادمي OpenVPN اثنين أن يصل بعضهم إلى بعض؟

إنشاء خادم OpenVPN ثانٍ يمنحك مكانًا ثانيًا لاتصال العملاء، ولا شيء أكثر. إنه لا يضع هؤلاء العملاء على شبكة الخادم الأول، والخيار المسمى client-to-client يغيّر فقط إعادة التوجيه داخل عملية خادم واحدة. تصبح المجموعتان شبكة واحدة عندما تمرّر التوجيه بينهما عن قصد، مع مسؤول لكل اتجاه. كل ما يلي يفترض وضع TUN في فضاء المستخدم مع تعطيل ذلك التوجيه الداخلي، بحيث تتخذ النواة القرار.

الأسطورة: قائمة حسابات واحدة، شبكة واحدة

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

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

أعطِ كل بوابة مجموعتها وعنوان العبور الخاص بها

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

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

ثبّت المسار على الجانبين

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

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

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

ادفع مسار العميل دون تزييف الملكية

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

push "route 10.64.20.0 255.255.255.0"

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

أثبت طلبًا واحدًا وارفض آخر

اختر عملية حقيقية، مثل HTTPS من عميل على 10.64.10.21 إلى خدمة على 10.64.20.37، واسمح بها تحديدًا على كلا المضيفين. يقبل كل جدار حماية الطلب على جانبه الوارد والرد المتتبع على جانب العودة؛ ولا يزال على سياسة الخدمة في الوجهة أن تقبله.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

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