danthegoodman1/netfenceمثل Envoy xDS، لكن لمرشحات eBPF
مثل Envoy xDS، ولكن لمرشحات eBPF.
يعمل Netfence كخفي على مضيفي الأجهزة الافتراضية/الحاويات الخاص بك ويقوم تلقائياً بحقن برامج مرشحات eBPF في مجموعات cgroups وواجهات الشبكة، مع خادم DNS مدمج يقوم بحل النطاقات المسموح بها ويملأ قائمة عناوين IP المسموح بها.
يمكن تشغيل خفي Netfence من خلال واجهة برمجة التطبيقات المحلية لمقبس Unix وحدها، أو الاتصال بمستوى تحكم مركزي تقوم بتنفيذه عبر gRPC لمزامنة قوائم السماح/المنع مع الواجهة الخلفية الخاصة بك.
يدفع مستوى التحكم الخاص بك قواعد الشبكة مثل ALLOW *.pypi.org أو ALLOW 10.0.0.0/16 إلى الواجهات/مجموعات cgroups المرفقة. عندما يستعلم جهاز افتراضي/حاوية عن DNS، يقوم Netfence بحله، ويضيف عناوين IP إلى مرشح eBPF، ويسقط حركة المرور إلى عناوين IP غير معروفة قبل أن تغادر المضيف مع حمل المسار الدافئ الذي لا يمكن تمييزه فعلياً عن اتصال مأخذ عادي في المقاييس الحالية.
في وضع قائمة السماح، لم يعد IPv4 المحلي للرابط (169.254.0.0/16) مسموحاً به تلقائياً بشكل افتراضي — لذا يتم حظر خدمة البيانات الوصفية السحابية (169.254.169.254) ما لم يتم السماح بها صراحة. هذا متعمد: خدمة البيانات الوصفية هي هدف لسرقة بيانات الاعتماد، ويجب ألا تتمكن أعباء العمل المحصورة من الوصول إليها ضمنياً. يظل المضيف المحلي (127.0.0.0/8, ::1) واكتشاف الجيران IPv6 (fe80::/10, ff02::/16) مسموحين بهم افتراضياً حتى تستمر الاتصالية الأساسية و NDP في العمل. للسماح بخدمة البيانات الوصفية لعبء عمل، قم بالسماح 169.254.169.254/32 (تجاوز استثناء لكل مرفق عبر مستوى التحكم هو متابعة مخطط لها).
البث IPv4 (255.255.255.255) والبث المتعدد (224.0.0.0/4) ليس لهما استثناء ويخضعان للسياسة، لذا في وضع قائمة السماح TC يتم حظر حركة المرور مثل بث تجديد DHCP ما لم يتم السماح بها صراحة. يتم إجراء فحوصات الاستثناء قبل قائمة المنع، لذا لا يمكن حظر نطاق مستثنى إلا بإيقاف تشغيل استثنائه — ولأن IPv4 المحلي للرابط الآن متوقف افتراضياً، يمكن لوضع قائمة المنع حظر خدمة البيانات الوصفية أيضاً.
بعض الفوائد الرئيسية لهذا الحل التي لا تدعمها الخيارات الأخرى عادةً:
secretdata.someattacker.com)على حد علمي، لا تقدم أي حلول أخرى كل هذه الميزات معاً.
قيد معروف: تقوم مرفقات cgroup بالتصفية على طبقة المقبس (خطافات connect/sendmsg)، لذا يمكن لعملية لديها CAP_NET_RAW إنشاء حزم خام تتجاوزها. استخدم مرفق TC (الواجهة)، الذي يقوم بالتصفية على طبقة الجهاز، لأعباء العمل التي قد تحمل CAP_NET_RAW.
ومع ذلك، فإن هذا له حمل زائد أكبر قليلاً من شيء مثل httpjail.
تم قياس هذه الأرقام في بوابة Docker Linux المميزة على linux/arm64 باستخدام make bench-docker. القيم هي متوسطات خمس عينات.
يستخدم معيار المقبس الدافئ مقابس UDP متصلة لعزل تكلفة خطاف eBPF cgroup/connect4 عن زمن مصافحة TCP. في هذا المسار، قام DNS بالفعل بحل النطاق، ولا يزال عنوان IP ضمن TTL، وعنوان IP/CIDR موجود بالفعل في خريطة eBPF.
| المسار | متوسط زمن الاستجابة |
|---|---|
| اتصال مقبس عادي، بدون eBPF | ~2.647 us |
| قائمة السماح الدافئة، إصابة LPM محمية | ~2.691 us |
| قائمة السماح الدافئة، إصابة مضيف DNS الدقيق | ~2.741 us |
| فقدان قائمة السماح، حظر محلي | ~1.652 us |
الفرق المقاس بين مسارات الاتصال العادي، LPM المحمي، ومضيف DNS الدقيق يقع ضمن ضوضاء العينة.
لا يوجد مسار "فقدان kernel يسأل العملية الأم" اليوم. يتم تحديد فقدان قائمة السماح cgroup محلياً بواسطة eBPF ويتم حظره فوراً.
تقيس هذه الأرقام مسار خادم DNS، وليس مسار اتصال المقبس الدافئ.
| المسار | متوسط زمن الاستجابة |
|---|---|
| استعلام وكيل بارد، دالة سياسة داخل العملية | ~31.336 us |
| استعلام وكيل دافئ | ~27.964 us |
| استعلام قائمة السماح بارد مع تصاعدي محلي | ~53.510 us |
| استعلام قائمة السماح دافئ مع تصاعدي محلي | ~53.432 us |
تتزامن الصفوف الباردة عبر حاجز تحوير المرفق الحقيقي وتمسح رسم بياني لملكية المعيار ولقطة خريطة دقيقة وهمية بين الاستعلامات. يعمل المؤقت بشكل مستمر للحفاظ على موقع جدولة UDP، بينما يطرح ns/op وقت الجدار fixture-reset-ns/op المُبلغ عنه بشكل منفصل (بما في ذلك أي ذيل من المعالج السابق بعد أن استلم العميل حزمة) وبالتالي يقيس تبادل العميل الحالي. يُبلغ raw-total-ns/op عن كليهما معاً. يحافظ إعادة التعيين على نطاقات السياسة المكونة والتخزين الداعم، ويؤكد المعيار إضافة خريطة دقيقة مادية واحدة لكل استعلام. تقوم الصفوف الدافئة بتهيئة الملكية مرة واحدة وتؤكد إضافة مادية واحدة عبر التشغيل.
المعايير الدقيقة للملكية الداخلية أدناه هي تشخيصات قابلية التوسع، وليست صفوف قبول مسار استعلام DNS من النهاية إلى النهاية. يتم الاحتفاظ بالمساعد المخبأ فقط للاختبارات والمعايير؛ فهو يلف سجلاً واحداً في كل مرة ويكرر التحقق من النطاق. كلاهما وحركة مرور المحلل العادي يعبران حاجز تحوير المرفق، بينما تعترف حركة مرور المحلل العادي بكل استجابة كاملة كصفقة واحدة.
| تشخيص قابلية التوسع الداخلي | متوسط الحالي | الذاكرة / التخصيصات |
|---|---|---|
| قبول مفتاح جديد بارد، رسم بياني للملكية فارغ | ~370.3 ns | 232 B، 5 تخصيصات/عملية |
| قبول مفتاح جديد بارد، 4,095 إدخال غير مرتبط | ~451.2 ns | 232 B، 5 تخصيصات/عملية |
| ضغط السعة المادية واستبدال LRU | ~3.820 ms | ~4.23 MB (4,226,243 B)، 4,336 تخصيص/عملية |
| فحص مسبق للميزانية المادية المستنفدة | ~611.9 ns | 344 B، 9 تخصيصات/عملية |
| ضغط الحافة القصوى، استجابة 64 عنوان | ~6.849 ms | ~7.66 MB (7,658,774 B)، 2,233 تخصيص/عملية |
| حارس العمل الأقصى للرسم البياني، الخطة الكاملة المسموح بها | ~2.763 ms | ~4.26 MB (4,264,386 B)، 3,074 تخصيص/عملية |
| حارس العمل الأقصى للرسم البياني، رفض ما قبل الإسقاط المستنفد | ~10.935 us | 8.76 KB (8,760 B)، 14 تخصيص/عملية |
| عملية ميزانية التغيير بالقرب من السقف العددي | ~18.98 ns | 0 B، 0 تخصيص/عملية |
| لقطة متماسكة لإحصائيات الملكية | ~2.094 ns | 0 B، 0 تخصيص/عملية |
| فحص انتهاء صلاحية بدون عملية عبر 4,095 إدخال | ~74.849 us/فحص | 0 B، 0 تخصيص/عملية |
+------------------+ +-------------------------+ | Your Control |<------->| Daemon (per host) | | Plane (gRPC) | stream | | +------------------+ | +-------------------+ | | | DNS Server | | | | (per-attachment) | | | +-------------------+ | +-------------------------+ | +------+------+ | | TC Filter Cgroup Filter (veth, eth) (containers)
يحصل كل مرفق على عنوان DNS فريد (منفذ) يوفره الخفي. يجب تكوين الحاويات/الآلات الافتراضية لاستخدام عنوان DNS المخصص لها؛ ولا يؤدي تصفية حركة مرور DNS العادية للعمل إلى إعادة توجيهها بشكل شفاف.
### طوبولوجيا وسلوك محلل DNS