danthegoodman1/netfenceएनवॉय xDS की तरह, लेकिन eBPF फ़िल्टर के लिए
Envoy xDS की तरह, लेकिन eBPF फ़िल्टर के लिए।
Netfence आपके VM/कंटेनर होस्ट पर एक डेमॉन के रूप में चलता है और स्वचालित रूप से cgroups और नेटवर्क इंटरफ़ेस में eBPF फ़िल्टर प्रोग्राम इंजेक्ट करता है, जिसमें एक अंतर्निहित DNS सर्वर होता है जो अनुमत डोमेन को हल करता है और IP अनुमति सूची को पॉप्युलेट करता है।
Netfence डेमॉन को उनके स्थानीय Unix-सॉकेट API के माध्यम से अकेले चलाया जा सकता है, या एक केंद्रीय नियंत्रण प्लेन से कनेक्ट किया जा सकता है जिसे आप gRPC के माध्यम से लागू करते हैं ताकि आपके बैकएंड के साथ अनुमति सूची/अस्वीकृति सूची को सिंक्रनाइज़ किया जा सके।
आपका नियंत्रण प्लेन ALLOW *.pypi.org या ALLOW 10.0.0.0/16 जैसे नेटवर्क नियमों को जुड़े इंटरफ़ेस/cgroups पर पुश करता है। जब कोई VM/कंटेनर 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 वाली प्रक्रिया कच्चे पैकेट बना सकती है जो उन्हें बायपास करते हैं। उन कार्यभारों के लिए जिनमें CAP_NET_RAW हो सकता है, TC (इंटरफ़ेस) अटैचमेंट का उपयोग करें, जो डिवाइस परत पर फ़िल्टर करता है।
हालाँकि, इसमें httpjail जैसी किसी चीज़ की तुलना में थोड़ा अधिक ओवरहेड है।
ये संख्याएँ linux/arm64 पर विशेषाधिकार प्राप्त Docker Linux गेट में make bench-docker का उपयोग करके मापी गईं। मान पाँच नमूनों के मध्यिका हैं।
वार्म सॉकेट बेंचमार्क कनेक्टेड UDP सॉकेट का उपयोग करता है ताकि cgroup/connect4 eBPF हुक की लागत को TCP हैंडशेक विलंबता से अलग किया जा सके। इस पथ में DNS पहले ही डोमेन को हल कर चुका है, IP अभी भी TTL के भीतर है, और IP/CIDR पहले से ही eBPF मैप में मौजूद है।
| पथ | मध्यिका विलंबता |
|---|---|
| सामान्य सॉकेट कनेक्ट, कोई eBPF नहीं | ~2.647 us |
| वार्म अनुमति सूची, संरक्षित LPM हिट | ~2.691 us |
| वार्म अनुमति सूची, DNS सटीक-होस्ट हिट | ~2.741 us |
| अनुमति सूची मिस, स्थानीय ब्लॉक | ~1.652 us |
सामान्य, संरक्षित-LPM और DNS सटीक-होस्ट कनेक्ट पथों के बीच मापा गया फैलाव नमूना शोर के भीतर है।
आज कोई 'कर्नेल मिस पैरेंट प्रक्रिया से पूछता है' पथ नहीं है। 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 allocs/op |
| कोल्ड नई-कुंजी प्रवेश, 4,095 असंबंधित प्रविष्टियाँ | ~451.2 ns | 232 B, 5 allocs/op |
| भौतिक-क्षमता दबाव और LRU प्रतिस्थापन | ~3.820 ms | ~4.23 MB (4,226,243 B), 4,336 allocs/op |
| समाप्त भौतिक-बजट पूर्वजांच | ~611.9 ns | 344 B, 9 allocs/op |
| अधिकतम-किनारा दबाव, 64-पता प्रतिक्रिया | ~6.849 ms | ~7.66 MB (7,658,774 B), 2,233 allocs/op |
| अधिकतम-ग्राफ कार्य गार्ड, अनुमत पूर्ण योजना | ~2.763 ms | ~4.26 MB (4,264,386 B), 3,074 allocs/op |
| अधिकतम-ग्राफ कार्य गार्ड, समाप्त पूर्व-प्रक्षेपण अस्वीकृति | ~10.935 us | 8.76 KB (8,760 B), 14 allocs/op |
| संख्यात्मक सीमा के निकट चर्न-बजट संचालन | ~18.98 ns | 0 B, 0 allocs/op |
| सुसंगत स्वामित्व-आँकड़ा स्नैपशॉट | ~2.094 ns | 0 B, 0 allocs/op |
| 4,095 प्रविष्टियों पर नो-ऑप समाप्ति स्कैन | ~74.849 us/स्कैन | 0 B, 0 allocs/op |