Skip to main content
تجلب خدمة linked-url-proxy داخل كل Pod من Pods ‏Ayakaleaf Pro ملفات “From External URL” (والملفات التي تنزّلها واجهة الاستيراد البرمجية والأداة web_fetch الخاصة بمساعد الذكاء الاصطناعي). وهي ترفض العناوين غير العامة، لذا لا يستطيع المستخدمون قراءة الخدمات الداخلية من خلالها. الميزة وإعداداتها موضّحة في عنوان URL خارجي.

الإعداد

30-config.yaml (additions)

ما الذي يُحظر على Kubernetes

يرفض الوكيل كل عنوان ليس عنوان unicast عامًا: عناوين loopback، وعناوين link-local (بما في ذلك عنوان البيانات الوصفية السحابية 169.254.169.254)، والنطاقات الخاصة 10.0.0.0/8 و172.16.0.0/12 و192.168.0.0/16، ونطاق carrier-grade NAT ‏100.64.0.0/10، ونظائرها في IPv6. لذلك تُحظر شبكات الـ Pods والـ Services الواقعة في هذه النطاقات، وهو الإعداد الافتراضي في kubeadm وflannel وCalico ومعظم الكتل المُدارة، دون أي إعداد، وكذلك الأسماء الداخلية للكتلة مثل redis أو git-bridge التي تُحَل إليها. العناوين العامة مسموح بها. إذا كانت للعقد أو لموازن الأحمال لديك عناوين عامة، فأضفها إلى OVERLEAF_LINKED_URL_BLOCKED_NETWORKS (مفصولة بمسافات أو فواصل)، حتى لا يتمكن المستخدمون من جلب الـ NodePorts أو صفحة حالة من خلالها. عند ضبط OVERLEAF_LINKED_URL_OUTBOUND_PROXY، يحلّ الوكيلُ الخارجي أسماءَ المضيفين، لذا لا يُتحقَّق إلا من عناوين URL التي تحتوي على عنوان IP: ويجب أن يحظر الوكيل الخارجي شبكاتك الداخلية بنفسه.

عدة نسخ متماثلة

لا حاجة إلى شيء إضافي: يجلب كل Pod الملفات عبر linked-url-proxy الخاص به وبالإعدادات نفسها.

الاختبار على Kubernetes

على Kubernetes 1.37 مع ثلاث نسخ متماثلة، وشبكة Pods الخاصة بـ flannel ‏10.244.0.0/16، وشبكة الخدمات الخاصة بـ kubeadm ‏10.96.0.0/12، رفض الوكيل التنزيلات من ClusterIP لإحدى الـ Services، ومن الأسماء الداخلية للكتلة redis وgarage وoverleaf-1.overleaf-hl.overleaf.svc.cluster.local، ومن عنوان إحدى العقد، دون أي OVERLEAF_LINKED_URL_BLOCKED_NETWORKS. كما نجحت اختباراتنا الشاملة لرفض عنوان loopback وعنوان البيانات الوصفية السحابية عبر واجهة الاستيراد البرمجية، ولقراءة مساعد الذكاء الاصطناعي الصفحات التي يسمح بها OVERLEAF_LINKED_URL_ALLOWED_RESOURCES فقط.
آخر تعديل في ٢ نوفمبر ٢٠٢٦