هل هناك أي عيوب لـ proxy عبر port بدلاً من unix domain socket؟

تثبيت
1

أنا أختبر نشر Discourse فوق AlmaLinux 9 المشتق من CentOS مع تمكين SELinux و nginx خارجي مُعد.

نظرًا لأن الحاوية المستندة إلى Ubuntu لا تعرف عن SELinux، فإنها تستمر في استبدال مقبس النطاق الموحد بملف جديد غير مُصنف أمنيًا في كل مرة أبدأ فيها الحاوية، ولا يُسمح لـ nginx بالتحدث إليه حتى أقوم بتشغيل restorecon للملف لمنحه سياقًا أمنيًا مسموحًا لـ nginx بالوصول إليه. من الواضح أن هذا لا يعمل كحل إنتاجي.

لا أرغب حقًا في تشغيل semanage permissive -a httpd_t لأنني أرغب في الاستفادة فعليًا من SELinux على الخدمة الوحيدة المفتوحة للعالم الخارجي. :smiling_face:

إنه يعمل إذا قمت بالوكالة إلى منفذ شبكة بدلاً من مقبس نطاق موحد:

  • setsebool -P httpd_can_network_connect 1
  • لا تستخدم templates/web.socketed.template.yml
  • expose: - "8008:80"
  • في nginx الخارجي، proxy_pass http://127.0.0.1:8008

هل هناك أي عيوب معينة لهذا؟ هل يجب علي تغيير أي معلمات مثل تحديد الاتصال في هذا التكوين؟

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

إعجابَين (2)
2

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

3 إعجابات
3

شكرًا!

public (active)
  target: default
...
  services: dhcpv6-client http https ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:
4

هناك فرق في زمن الاستجابة، حيث يكون المقبس أسرع بحوالي 3 مرات من منفذ الاسترجاع المحلي.

ومع ذلك، نحن نتحدث عن فرق يتراوح بين 4-5 ميكروثانية هنا في أفضل الأحوال.

3 إعجابات
5

بعد المزيد من البحث، أرغب بالتأكيد في إضافة proxy_set_header "Connection" ""; لتعطيل ترويسة Connection: close الافتراضية.