دع عميل OpenVPN واحدًا يتصل بعميل آخر عبر SSH دون فتح المسبح

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

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

إلى أين ينقل client-to-client الحزمة

عند تفعيل client-to-client، يمرّر الخادم حزمة النظير داخليًا بدلًا من إعادة إرسالها خارج جهاز النفق، فلا تصل الحزمة أبدًا إلى مسار التمرير في النواة. هذا مريح ويعني أيضًا أن جدارك الناري لا يرى التدفق الذي يفترض أن يراقبه. أبقِ الخيار مغلقًا فيوجّه الخادم الحزمة مرة أخرى عبر الواجهة نفسها، ما يضعها أمام netfilter. الواجهة نفسها دخولًا وخروجًا، وسلسلة FORWARD هي صاحبة الصوت.

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

المسار الذي تسلكه حزمة النظير فعلًا

افترض خدمة Linux Community OpenVPN 2.6، ومعالجة TUN في مساحة المستخدم بدلًا من DCO، وطوبولوجيا الشبكة الفرعية، إضافة إلى tun0، ومسبحًا من 10.44.0.0/24 مع العميل A على 10.44.0.21 والعميل B على 10.44.0.37. مع طوبولوجيا الشبكة الفرعية، فإن العنوان والقناع الذي تلقاه A يغطيان المسبح أصلًا، لذا يرسل A الحزمة إلى جهاز النفق دون حاجة إلى مسار مدفوع إضافي. تحقق من المسار الفعلي على A بدلًا من افتراض واحد.

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

قاعدتان على الخادم، بهذا الترتيب

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

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

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

ما يجب أن يسمح به B بعد

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

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

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