توجيه حركة مجمِّع HTTPS في Monit عبر مرحّل SOCKS محلي

أبقِ اسم مضيف المجمِّع في عنوان URL الخاص بـ Monit بينما يمرّر مستمع loopback اتصال TCP عبر SOCKS4.

يمكن لمرحّل TCP محلي أن ينقل تقارير HTTPS الخاصة بـ Monit عبر SOCKS دون أن يصبح طرف TLS. يجب أن يحافظ التوجيه على اسم المجمِّع لأجل HTTPS مع منح المرحّل عنوان وجهته الحقيقي.

افترض أن المجمِّع هو collector.example على 203.0.113.40:443. في ترتيب قائم على socat، يكون للمرحّل هذا الشكل:

socat TCP4-LISTEN:9900,bind=127.0.0.1,reuseaddr,fork \
  SOCKS4:socks.example:203.0.113.40:443,socksport=1080

هنا يستقبل 127.0.0.1:9900 اتصال Monit المحلي. وsocks.example:1080 هو خادم SOCKS4، ويُطلب منه الاتصال بعنوان المجمِّع الحقيقي على المنفذ 443. استبدل جميع عناوين التوثيق بقيم النشر.

حلّ اسم المجمِّع إلى ذلك المستمع محليًا، وأبقِ الاسم في monitrc:

127.0.0.1 collector.example

set mmonit https://monit:[email protected]:9900/collector

السطر الأول مدخل في ملف hosts؛ والثاني هو إعداد Monit. استخدم بيانات اعتماد المجمِّع الحقيقية مع ترميز URL المطلوب. يؤثر تعيين ملف hosts أيضًا على التطبيقات الأخرى التي تستخدم ذلك الاسم على الجهاز.

لا تزال مصافحة HTTPS ملكًا للمجمِّع، لذا احتفظ باسم مضيفه وسياسة التحقق من الشهادة المقصودة. تغيير عنوان URL إلى localhost يغيّر الهوية التي يطلب Monit التحقق منها.

يستخدم المرحّل عمدًا عنوان IP الحقيقي للمجمِّع بدلًا من البحث عن الاسم المعاد تعيينه إلى loopback. حدّث ذلك العنوان عند تغيّر عنوان المجمِّع. أبقِ المستمع متاحًا كجزء من مسار الإبلاغ؛ وfork يمنح اتصالات المرحّل المقبولة معالجة منفصلة.

مقالات ذات صلة