الانتقال إلى المحتوى الرئيسي
عندما يستدعي وكيل http_fetch أو web_search أو أي أداة تفتح اتصالاً صادراً، تكون الوجهة هي الجزء الذي تحتاج أكثر إلى حكمه. وكيل مرتبك أو مختطَف يمكنه الوصول إلى 169.254.169.254 يقرأ اعتمادات سحابتك؛ وآخر يمكنه إرسال POST إلى مضيف مهاجم يسرّب بياناتك. التحكم في egress الوكيل يحكم تلك الوجهة — تؤلّف قاعدة سماح/منع المضيف/CIDR على سطح egress في جدار الحماية، تربطها بمفتاح، وتفحص البوابة كل وجهة صادرة تبلّغ عنها أداة وكيل قبل أن يخرج الاستدعاء. هذه صفحة حالة استخدام مركّزة. لقواعد القاعدة الكاملة ودلالات الأحكام انظر مخطط القاعدة و الأحكام؛ ولكيفية جلوس egress بين نقاط الفرض الأخرى انظر المراحل.

​
1. التحكم في egress الوكيل على سطح egress

من أسطح جدار الحماية الأربعة، egress هو الذي يرى الوجهة الشبكية الصادرة التي تبلّغ عنها أداة — مضيف، أو حرف IP، أو CIDR. قاعدة مثبّتة على stage: egress تطابق على تلك الوجهة، وليس على اسم الأداة أو وسائطها، مما يجعلها تحكُّم SSRF وتسريب البيانات: تجيب عن أين يمكن لهذا الوكيل الوصول، مستقلةً عن أي أداة فعلت الوصول.
egress هو قصر الوجهة، وليس حجب الأداة. لإيقاف أداة عن الوجود أصلاً، ارفضها بالاسم على سطح inbound (حجب الأدوات). يفترض التحكم في egress أن الأداة قد تجلب بشكل مشروع — إنه يقيّد فقط إلى أين.

​
2. مثال واحد: ارفض وجهات SSRF

قاعدة egress النموذجية ترفض نقطة نهاية بيانات تعريف السحابة ونطاقات RFC-1918 الخاصة — الوجهات التي يجب ألّا تصل إليها أداة بهيئة الجلب أبداً. في وحدة تحكم مساحة عملك، افتح سياسة وأضف قاعدة بـ stage egress، وحكم deny، وقائمة egress: 
{
  "label": "deny SSRF destinations",
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"],\"allow\":[\"api.openai.com\"]}"
}
egress_json هي سلسلة مرمّزة بصيغة JSON تحمل قوائم المضيف/CIDR — مفكوكة، إنها {"deny": [...], "allow": [...]}. تطابق كل مدخلة كـ CIDR، أو حرف IP، أو اسم مضيف غير حسّاس لحالة الأحرف. لحكم deny تكون قائمة deny هي المجموعة في النطاق (الوجهات التي تحجبها القاعدة) وقائمة allow تنحت استثناءات منها — فالقاعدة أعلاه تحجب النطاقات الأربعة لكن تدع api.openai.com يمر حتى لو حُلّ يوماً إلى أحدها. عندما تكون وجهة اسم مضيف بدلاً من حرف IP وتحمل قائمتك مدخلات IP/CIDR، يُحَل الاسم بأفضل جهد وتُعاد فحص عناوينه، فـ metadata.internal لا يزال يطابق منع 169.254.0.0/16 رغم أنه ليس مدرجاً بالاسم.
لموقف قائمة سماح بدلاً من ذلك — اسمح فقط بمجموعة مسمّاة من الوجهات واحجب البقية — اكتب القاعدة بحكم allow وضع وجهاتك في قائمة allow. تنقلب القطبية: allow تصبح المجموعة في النطاق وdeny تنحت استثناءات. اقرنها بـ default_verdict للسياسة بـ deny فيُحجب أي شيء لا تغطّيه قاعدة السماح.

​
3. أنت تؤلّف قواعد CIDR — لا إعداد مسبق يشحنها

لا توجد قائمة CIDR مسبقة الإعداد. OrcaRouter لا يشحن قاعدة مدمجة ترفض 169.254.169.254 أو RFC-1918 أو أي نطاق آخر. قاعدة سماح/منع CIDR لك أنت لتؤلّفها — إنها المثال في §2، مكتوبة من قبلك مقابل شبكتك. انسخها، ثم اضبط النطاقات واستثناءات قائمة السماح لبيئتك.
ما يشحنه مستوى الاستقلالية tight وإعداده المسبق block_ssrf_egress هو مجموعة من المنوعات على أسماء الأدوات بهيئة الجلب — http_fetch وweb_search وfetch_url وrequest، بالإضافة إلى متغيراتها <server>.<tool> لـ MCP. هذا موقف فظّ: يرفض الأدوات بهيئة egress صراحةً بدلاً من قصر أين قد تصل. الجأ إليه عندما لا شأن لوكيل بإجراء استدعاءات شبكية أصلاً؛ والجأ إلى قاعدة وجهة (§2) عندما يجلب فعلاً لكن فقط من مجموعة مضيفين معتمدة.
النهجماذا يقيّدالمؤلِّف
إعداد SSRF المسبق لـ tightأسماء الأدوات بهيئة الجلب (يرفضها)مدمج
قاعدة CIDR/مضيف egressالوجهة التي قد تصل إليها أداة جلبأنت

​
4. كيف يبدو egress محجوب

عندما تطابق وجهة قاعدة egress فارضة، يُرفض الاستدعاء قبل أن يغادر البوابة ويُسجَّل التقييم كحدث جدار حماية بسطح egress وحكم deny. في وضع الظل يُخفَّض deny إلى audit بسبب مسبوق بـ [shadow] would …، فيمكنك قياس أي الوجهات بالضبط كانت قاعدة ستحجبها مقابل حركة المرور الحقيقية قبل أن تفرضها.
قائمة egress مشوّهة أو بلا مدخلات تُعامَل بتحفّظ: قاعدة deny فارضة لا تزال تحكم (خطأ مطبعي لا يمكنه إيقافها صامتاً عن الحجب)، لكن قاعدة allow بقائمة معطوبة لن تُطلق — وإلا فقائمة سماح بخطأ مطبعي ستصبح سماح-للكل وتظلّل منع افتراضي. تُتحقَّق القواعد الجديدة عند الحفظ (يجب أن تعلن القائمة عن مدخلة سماح أو منع واحدة على الأقل)، فهذا يحرس الصفوف القديمة فقط.

​
5. ألّف من حركة المرور الحقيقية، ثم اطرح

سجل الأحداث يسجّل مضيف الوجهة على كل حدث سطح egress (egress_host/egress_url)، ففلتره إلى سطح egress وألّف قائمة المنع من الوجهات التي ظهرت فعلاً بدلاً من التخمين. تبويب Discovered Tools تجميع لكل اسم أداة (أسماء الأدوات والأسطح التي أُطلقت عليها) — يخبرك أي الأدوات بهيئة الجلب عملت، وليس المضيفين الذين وصلت إليهم. انظر التحليلات.
تبويب Test في وحدة التحكم يجري سياسة تجريبياً مقابل tool_name + سطح (+ وسائط اختيارية) عينة ويعيد الحكم، والقاعدة المطابقة، والسبب — لا شيء يُرسَل. يؤكّد أي قاعدة يُحَل إليها استدعاء؛ لتأكيد حساب CIDR/المضيف مقابل وجهات حقيقية، استخدم وضع الظل أدناه (حمولة Test لا تحمل وجهة، فمطابقة قائمة egress تُمارَس على حركة egress الحية). انظر اختبار القواعد.
فعّل وضع الظل ويُسجَّل منع egress كما كان سيُطلق دون حجب. راقب سجل الأحداث مفلتراً إلى سطح egress، أكّد أنه يصطاد الوجهات التي تتوقعها، ثم أطفئ الظل.
قصر الوجهة في البوابة دفاع متعمّق، وليس الخط الأخير. الـ IP الذي يُحَل إليه اسم مضيف وقت التقييم قد يختلف عن الذي تتصل به أداة فعلاً (إعادة ربط DNS). احتفظ بتحكُّم منع IP في طبقة egress/الاتصال الخاصة بك أيضاً؛ قاعدة البوابة هي الالتقاط ما قبل الإقلاع الرخيص للحالات الواضحة.

​
6. اربط السياسة ومن يمكنه تحريرها

لا تفعل سياسة شيئاً حتى يُحَل إليها مفتاح. اربط في وحدة التحكم بضبط firewall_policy_id على المفتاح، أو اجعل السياسة افتراضي مساحة العمل. الحل هو: السياسة المرتبطة بالمفتاح (عندما تكون موجودة ومفعّلة)، وإلا افتراضي مساحة العمل. كل ضبط قاعدة egress يعمل في وحدة التحكم تحت جلستك (/api/workspace/firewall/*):
الإجراءالدور
قراءة السياسات، الإعدادات المسبقة، الأدوات المكتشفة، Simulate للاستقلاليةMember
إنشاء / تحرير / حذف قواعد egress والسياساتDeveloper+
نقطة نهاية Test التجريبية (POST /test)Developer+
قراءة سجل الأحداث وتجميعات التشغيلDeveloper+

​
ذات صلة

تسريب البيانات

التهديد الذي يعالجه التحكم في egress.

المراحل

الأسطح الأربعة، وأين يقع egress.

الأحكام

ماذا يفعل deny وaudit وallow على السلك.

حجب الأدوات

ارفض أداة جلب بالاسم بدلاً من بالوجهة.

استدعاءات الأدوات الخطرة

فئة المخاطر الأوسع.

مرجع جدار الحماية

مرجع القاعدة + المطابقة الكامل، بما في ذلك قوائم egress.