Netfence

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 पर ट्रैफ़िक को होस्ट छोड़ने से पहले गिरा देता है, जिसमें वार्म्ड-पथ ओवरहेड होता है जो वर्तमान बेंचमार्क में सामान्य सॉकेट कनेक्ट से प्रभावी रूप से अप्रभेद्य है।

विशेषताएँ

• eBPF फ़िल्टर को नेटवर्क इंटरफ़ेस (TC) या cgroups से अटैच करें
• नीति मोड: अक्षम, अनुमति सूची, अस्वीकृति सूची, सभी-अवरुद्ध
• वैकल्पिक TTL के साथ IPv4 और IPv6 CIDR समर्थन
• डोमेन अनुमति सूची/अस्वीकृति सूची और क्रमबद्ध अपस्ट्रीम ओवरराइड के साथ प्रति-अटैचमेंट UDP/TCP DNS सर्वर
• डोमेन नियम विशिष्टता-आधारित मिलान के साथ उपडोमेन का समर्थन करते हैं (अधिक विशिष्ट नियम जीतते हैं)
• हल किए गए डोमेन स्वचालित रूप से IP फ़िल्टर को पॉप्युलेट करते हैं
• डेमॉन और अटैचमेंट पर मेटाडेटा VM ID, टेनेंट आदि से जोड़ने के लिए
• प्रति-अटैचमेंट DNS निर्णय लेने के लिए DNS क्वेरी को नियंत्रण प्लेन पर प्रॉक्सी करने का समर्थन

सुरक्षा नोट: डिफ़ॉल्ट छूट (carve-outs)

अनुमति सूची मोड में, 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 लिंक-लोकल अब डिफ़ॉल्ट रूप से बंद है, अस्वीकृति सूची मोड मेटाडेटा सेवा को भी अवरुद्ध कर सकता है।

अन्य विकल्पों से अंतर

• जब नियम किसी IP को अस्वीकार करने के लिए बदलते हैं तो मौजूदा कनेक्शनों का तत्काल काटना (केवल इंटरफ़ेस अटैचमेंट)
• सभी नेटवर्क प्रोटोकॉल का समर्थन, और सीधे IP नेटवर्किंग। उदाहरण के लिए, शानदार httpjail आपको सीधे IP से कनेक्ट करने, या डेटाबेस से कनेक्ट करने जैसे सीधे TCP/UDP कनेक्शन की अनुमति नहीं देता।
• DNS का गतिशील हल और पूर्व-समाधान फ़िल्टरिंग (ताकि 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 मैप में मौजूद है।

सामान्य, संरक्षित-LPM और DNS सटीक-होस्ट कनेक्ट पथों के बीच मापा गया फैलाव नमूना शोर के भीतर है।

आज कोई 'कर्नेल मिस पैरेंट प्रक्रिया से पूछता है' पथ नहीं है। cgroup अनुमति सूची मिस को eBPF द्वारा स्थानीय रूप से तय किया जाता है और तुरंत अवरुद्ध कर दिया जाता है।

DNS क्वेरी पथ

ये संख्याएँ DNS सर्वर पथ को मापती हैं, वार्म किए गए सॉकेट कनेक्ट पथ को नहीं।

कोल्ड पंक्तियाँ वास्तविक अटैचमेंट म्यूटेशन बैरियर के माध्यम से सिंक्रोनाइज़ होती हैं और क्वेरी के बीच बेंचमार्क स्वामित्व ग्राफ और नकली सटीक-मैप स्नैपशॉट को साफ़ करती हैं। टाइमर UDP शेड्यूलर स्थानीयता को संरक्षित करने के लिए लगातार चलता है, जबकि ns/op अलग से रिपोर्ट किए गए fixture-reset-ns/op वॉल समय (क्लाइंट को अपना पैकेट प्राप्त करने के बाद पिछले हैंडलर की किसी भी पूंछ सहित) को घटाता है और इस प्रकार वर्तमान क्लाइंट एक्सचेंज को मापता है। raw-total-ns/op दोनों को एक साथ रिपोर्ट करता है। रीसेट कॉन्फ़िगर की गई नीति डोमेन और बैकिंग स्टोरेज को संरक्षित करता है, और बेंचमार्क प्रति क्वेरी एक भौतिक सटीक-मैप जोड़ का दावा करता है। वार्म पंक्तियाँ एक बार स्वामित्व को प्राइम करती हैं और रन के दौरान एक भौतिक जोड़ का दावा करती हैं।

नीचे दिए गए आंतरिक स्वामित्व माइक्रोबेंचमार्क स्केलेबिलिटी डायग्नोस्टिक्स हैं, एंड-टू-एंड DNS क्वेरी-पथ स्वीकृति पंक्तियाँ नहीं। कैश्ड हेल्पर केवल परीक्षणों और बेंचमार्क के लिए रखा गया है; यह एक समय में एक रिकॉर्ड लपेटता है और डोमेन सत्यापन दोहराता है। यह और सामान्य रिज़ॉल्वर ट्रैफ़िक दोनों अटैचमेंट म्यूटेशन बैरियर को पार करते हैं, जबकि सामान्य रिज़ॉल्वर ट्रैफ़िक प्रत्येक पूर्ण प्रतिक्रिया को एक लेन-देन के रूप में स्वीकार करता है।

डिज़ाइन

आर्किटेक्चर```

+------------------+ +-------------------------+ | Your Control |<------->| Daemon (per host) | | Plane (gRPC) | stream | | +------------------+ | +-------------------+ | | | DNS Server | | | | (per-attachment) | | | +-------------------+ | +-------------------------+ | +------+------+ | | TC Filter Cgroup Filter (veth, eth) (containers)

प्रत्येक अटैचमेंट को डेमन द्वारा प्रदान एक अद्वितीय DNS पता (पोर्ट) मिलता है। कंटेनर/VM को अपने निर्धारित DNS पते का उपयोग करने के लिए कॉन्फ़िगर किया जाना चाहिए; सामान्य वर्कलोड DNS ट्रैफ़िक को फ़िल्टर करना इसे पारदर्शी रूप से रीडायरेक्ट नहीं करता है।

### DNS रिज़ॉल्वर टोपोलॉजी और व्यवहार

`dns.listen_addr` को एक ठोस IPv4 या IPv6 पता पहचानना चाहिए जो हर जुड़े वर्कलोड तक पहुँच सके। वाइल्डकार्ड पतों को अस्वीकार कर दिया जाता है क्योंकि उन्हें रिज़ॉल्वर एंडपॉइंट के रूप में विज्ञापित नहीं किया जा सकता। एक कॉन्फ़िगर किया गया होस्टनाम डेमन शुरू होने पर एक बार हल किया जाता है और परिणामी ठोस IP बाइंडिंग, विज्ञापन, स्थायित्व और फ़िल्टर बूटस्ट्रैप के लिए उपयोग किया जाता है। डिफ़ॉल्ट `127.0.0.1` केवल तभी उपयुक्त है जब वर्कलोड डेमन के नेटवर्क नेमस्पेस को साझा करता है; किसी अन्य नेमस्पेस में एक कंटेनर या VM को सामान्यतः इसके बजाय एक पहुँच योग्य होस्ट/ब्रिज पते की आवश्यकता होती है।```yaml
dns:
  listen_addr: 10.0.0.1
  port_min: 11000
  port_max: 11500
  # Daemon-global fallback when DnsConfig.upstream_servers is empty.
  upstream: 1.1.1.1:53
  # Hard daemon ceilings for each attachment's bounded DNS exact ownership.
  # Zero/unset uses these defaults (max_ips_per_family instead derives from
  # filter.max_dns_rule_entries).
  max_ips_per_family: 4096
  max_ips_per_response: 64
  max_ips_per_policy_domain: 1024
  max_tracked_domains: 1024
  max_ownership_edges: 8192
  # Rolling physical-admission/LRU mutation budget and slow-planning work
  # allowance. The window is daemon-global and immutable until restart;
  # DnsConfig.max_churn_units may only lower the daemon ceiling.
  max_churn_units: 8192
  churn_window: 1m

Attach ठोस dns_address लौटाता है; उस सटीक पते को कार्यभार के रिज़ॉल्वर के रूप में कॉन्फ़िगर करें। Netfence लिसनर IP के लिए एक सुरक्षित, गैर-समाप्त होने वाली /32 या /128 अनुमति प्रविष्टि स्थापित करता है ताकि अनुमतिसूची मोड बिना नियंत्रण-तल DNS-IP नियम के बूटस्ट्रैप हो सके। वर्तमान फ़िल्टर IP उपसर्गों को लागू करते हैं, गंतव्य पोर्ट को नहीं, इसलिए वह सुरक्षित प्रविष्टि लिसनर IP पर प्रत्येक पोर्ट की अनुमति देती है (न केवल उसके DNS पोर्ट की); यह cgroup अटैचमेंट खतरे के मॉडल के लिए विशेष रूप से महत्वपूर्ण है। जब वह व्यापक पहुँच स्वीकार्य नहीं है तो एक समर्पित लिसनर IP का उपयोग करें।

निर्धारित एंडपॉइंट UDP और TCP दोनों की सेवा करता है। UDP उत्तर पुराने क्लाइंट की 512-बाइट सीमा या उसके विज्ञापित EDNS आकार तक छोटे कर दिए जाते हैं और जब आवश्यक हो तो TC ध्वज रखते हैं, जिससे कार्यभार उसी एंडपॉइंट पर TCP पर पुनः प्रयास कर सकता है। अपस्ट्रीम रिज़ॉल्यूशन के लिए, एक छोटा UDP उत्तर पहले उसी अपस्ट्रीम के विरुद्ध TCP पर पुनः प्रयास किया जाता है। एक परिवहन विफलता, SERVFAIL, या REFUSED फिर क्रम में अगले कॉन्फ़िगर किए गए अपस्ट्रीम पर आगे बढ़ता है।

DnsConfig.upstream_servers एक अटैचमेंट के लिए डेमॉन-वैश्विक dns.upstream को ओवरराइड करता है। प्रविष्टियाँ host:port सिंटैक्स (ब्रैकेट IPv6 शाब्दिक) का उपयोग करती हैं, पहले-देखे गए क्रम में विहित और डी-डुप्लिकेट की जाती हैं, और अधिकतम आठ अद्वितीय सर्वरों तक सीमित होती हैं। एक खाली सूची वैश्विक फ़ॉलबैक का चयन करती है।

फ़िल्टरिंग मोड में, Netfence HTTPS/SVCB उत्तरों से ipv4hint और ipv6hint पैरामीटर हटा देता है, जिसमें उनके संगत mandatory संदर्भ भी शामिल हैं, क्योंकि संकेतित पतों ने स्वतंत्र रूप से फ़िल्टर प्रवेश पास नहीं किया है। अक्षम मोड अपस्ट्रीम उत्तरों को अपरिवर्तित रखता है।

DNS क्वेरी काउंटर परस्पर अनन्य हैं: dns_queries_allowed सफलतापूर्वक उत्तरित नीति-अनुमत क्वेरी (NXDOMAIN सहित) गिनता है, dns_queries_blocked नीति REFUSED प्रतिक्रियाएँ गिनता है, और dns_queries_errors रिज़ॉल्वर, प्रॉक्सी, फ़िल्टर-प्रवेश, प्रतिक्रिया-लेखन और अन्य त्रुटि पथ गिनता है। एक क्वेरी बिल्कुल एक बाल्टी बढ़ाती है।

फ़िल्टरिंग DNS मोड में प्रत्येक पता-युक्त प्रतिक्रिया को उसके उत्तर, अधिकार, या अतिरिक्त अनुभागों से किसी A/AAAA पते को वापस करने से पहले एक लेन-देन के रूप में अटैचमेंट के सटीक IPv4/IPv6 HASH स्तर में प्रवेश दिया जाता है। यदि पूर्ण प्रतिक्रिया का प्रतिनिधित्व नहीं किया जा सकता है, तो रिज़ॉल्वर बिना किसी पते के SERVFAIL लौटाता है और पहले स्वीकृत कार्यशील सेट को संरक्षित करता है। PROXY निर्णय जो पते लौटाते हैं, उन्हें add_to_filter सेट करना चाहिए; अन्यथा वे भी SERVFAIL के रूप में बंद विफल होते हैं। अक्षम DNS मोड स्पष्ट पास-थ्रू अपवाद है।

सटीक प्रविष्टियाँ सामान्यीकृत क्वेरी से मिलान की गई नीति स्वामी तक TTL किनारे रखती हैं। किसी डोमेन को हटाने या अस्वीकार करने से तुरंत उसके अंतिम DNS-केवल सटीक पते हट जाते हैं, जबकि एक साझा पता किसी अन्य जीवित क्वेरी स्वामी से बच जाता है और एक अतिव्यापी नियंत्रण-तल CIDR संरक्षित LPM स्तर में स्वतंत्र रूप से जारी रहता है। DNS DENYLIST डिफ़ॉल्ट-अनुमति और स्पष्ट-अनुमति उत्तर भी ट्रैक किए जाते हैं, भले ही पैकेट DENYLIST सटीक अनुमतियों को अनदेखा करता है, ताकि बाद में पैकेट-मोड स्विच से ALLOWLIST में पहले से लौटाए गए कैश किए गए पतों का उपयोग बिना पुनर्क्वेरी के हो सके।

सभी सामान्य/जीवित उपयोगकर्तास्तर स्वामित्व स्थिति उपरोक्त पाँच स्वामित्व सेटिंग्स द्वारा सीमित है। पुनर्स्थापित सिंथेटिक अस्थायी किनारे उन तार्किक सीमाओं से मुक्त हैं ताकि वे सामंजस्य से पहले भूल न जाएँ, लेकिन भौतिक IPv4/IPv6 सटीक मानचित्रों द्वारा सीमित रहते हैं। कॉन्फ़िगर की गई नीति डोमेन और जीवित क्वेरी डोमेन max_tracked_domains साझा करते हैं, और प्रत्येक (query, matched owner, IP) TTL रिकॉर्ड एक max_ownership_edges स्लॉट का उपभोग करता है।

दबाव पर, प्रवेश पहले समाप्त TTL किनारों को हटा देता है। फिर यह कम से कम भौतिक संपार्श्विक के साथ पूर्ण तार्किक क्वेरी/स्वामी किनारों को पुनः प्राप्त करता है, उसके बाद रिकेंसी के अनुसार, फिर नियतात्मक रिज़ॉल्वर-अवलोकित LRU (विहित IP टाई तोड़ता है)। एक भौतिक निकासी पूरे DNS सटीक कुंजी और उसके सभी DNS स्वामियों को हटा देती है। आने वाली भौतिक IP और सटीक आने वाली (IP, query, owner) किनारे प्रतिक्रिया लेन-देन के लिए संरक्षित हैं। पुनर्स्थापित अस्थायी स्वामित्व अपनी भौतिक कुंजी को आधिकारिक सामंजस्य तक सुरक्षित रखता है, लेकिन उस कुंजी को साझा करने वाले असंबंधित सामान्य DNS मेटाडेटा को अभी भी पुनः प्राप्त किया जा सकता है। आधिकारिक नियंत्रण-तल/सिस्टम अनुमतियाँ और प्रत्येक अस्वीकृति अलग LPM स्तरों में रहती हैं और DNS पुनःप्राप्ति के लिए कभी उम्मीदवार नहीं होती हैं।

रोलिंग प्रति-अटैचमेंट खपत बजट एक नई भौतिक सटीक कुंजी के लिए एक इकाई और प्रत्येक जीवित भौतिक DNS कुंजी निकाले जाने के लिए एक इकाई शुल्क लेता है; एक पूर्ण पुराने-से-नए प्रतिस्थापन इसलिए दो की लागत देता है। रिफ्रेश, केवल-तार्किक पुनःप्राप्ति, समाप्ति और नीति हटाने की लागत शून्य है। घटनाएँ तब तक सक्रिय रहती हैं जब तक उनकी आयु dns.churn_window से कम होती है और सटीक सीमा पर समाप्त होती हैं। DnsConfig.max_churn_units केवल डेमॉन सीलिंग को कम कर सकता है; शून्य इसे विरासत में लेता है। विंडो को नियंत्रण तल द्वारा नहीं बदला जा सकता है, और डेमॉन सीलिंग/विंडो बदलने के लिए पुनरारंभ की आवश्यकता होती है। एक अटैचमेंट सीमा को कम करना और बाद में बढ़ाना अभी भी सक्रिय इतिहास को नहीं भूलता है।

एक अलग रोलिंग कार्य बहीखाता महँगे स्वामित्व-ग्राफ योजना को सीमित करता है। त्वरित रिफ्रेश और सामान्य प्रवेश इसे कभी स्पर्श नहीं करते हैं। दबाव पथ ग्राफ को क्लोन या विश्लेषित करने से पहले, Netfence वर्तमान भौतिक कुंजी, स्वामित्व किनारे, ट्रैक किए गए डोमेन और अपरिवर्तनीय डेमॉन/मानचित्र सीमाओं के सापेक्ष प्रतिक्रिया आकार से प्राप्त स्थिर कार्य इकाइयाँ शुल्क लेता है। वह प्रयास शुल्क तब भी बना रहता है जब योजना असंभव साबित होती है या बाद में सटीक-मानचित्र लेन-देन विफल होता है, उपरोक्त लेन-देन संबंधी भौतिक-खपत लेखांकन को बदले बिना शून्य-उत्परिवर्तन पुनर्प्रयास पथ को CPU/आवंटन दबाव के लिए बंद कर देता है। डिफ़ॉल्ट सीलिंग पर, भत्ता प्रति विंडो आठ अधिकतम-समतुल्य ग्राफ पास स्वीकार करता है; DnsConfig.max_churn_units कम करने पर कम से कम एक बरकरार रहता है। सीमा को कम करना और बाद में बढ़ाना सक्रिय कार्य इतिहास को कभी पुनर्स्तर या भूलता नहीं है।

जब कोई पात्र DNS स्थिति किसी सीमा को संतुष्ट नहीं कर सकती, या कोई भी रोलिंग भत्ता समाप्त हो जाता है, Netfence स्वीकृत कार्यशील सेट को संरक्षित करता है और बिना अप्रवेशित पते के SERVFAIL लौटाता है। क्षमता विफलताएँ map_full_drops बढ़ाती हैं; भौतिक-खपत और योजना-कार्य थ्रॉटल नहीं बढ़ाते। हार्टबीट सटीक-मानचित्र वर्तमान, क्षमता और प्रक्रिया-पीढ़ी उच्च-जल मानों के साथ-साथ संचयी DNS LRU निकासी, सभी प्रवेश विफलताएँ, और एक समग्र बजट-थ्रॉटल गणना जो दोनों रोलिंग गार्ड को कवर करती है, उजागर करता है। क्षमता, भौतिक-बजट और कार्य-बजट दबाव/पुनर्प्राप्ति लॉग स्वतंत्र रूप से दर-सीमित हैं। संचालक TTL/विंडो पुनर्प्राप्ति की प्रतीक्षा कर सकते हैं, प्रतिक्रिया/डोमेन खपत या बार-बार सीमा-दबाव प्रयासों को कम कर सकते हैं, या DnsConfig.max_churn_units को डेमॉन dns.max_churn_units सीलिंग तक बढ़ा सकते हैं। डेमॉन सीलिंग बढ़ाने के लिए पुनरारंभ की आवश्यकता होती है; filter.max_dns_rule_entries बढ़ाने के लिए भी अटैचमेंट को पुनः बनाने की आवश्यकता होती है क्योंकि पिन किए गए मानचित्रों को स्थान पर आकार नहीं दिया जा सकता है।

संरक्षित CIDR क्षमता और बंद-विफल पुनर्प्राप्ति

आधिकारिक नियंत्रण-तल CIDR और डेमॉन-सिस्टम नियम चार स्वतंत्र, गैर-निकासी योग्य LPM मानचित्रों का उपयोग करते हैं: अनुमति/अस्वीकार × IPv4/IPv6। प्रत्येक मानचित्र में filter.max_rule_entries स्लॉट हैं। DNS लिसनर /32 या /128 बूटस्ट्रैप एक सिस्टम अनुमति है और संबंधित संरक्षित अनुमति मानचित्र के विरुद्ध गिना जाता है। DNS सटीक-होस्ट प्रविष्टियाँ अपने अलग मानचित्रों में रहती हैं और इन स्लॉट्स का उपभोग नहीं कर सकती हैं। कोई भी संरक्षित नियम कभी LRU-निकासित नहीं किया जाता है: स्पष्ट अनुमतियाँ, सिस्टम नियम, और प्रत्येक अस्वीकार अधिकृत निष्कासन या पूर्ण प्रतिस्थापन तक बने रहते हैं।

एक पूर्ण SubscribedAck या BulkUpdate को विहित किया जाता है और उत्परिवर्तन से पहले सभी चार मानचित्रों के लिए इसकी अंतिम अधिभोग की जाँच की जाती है। क्षमता अंतिम स्थिति पर आधारित है, इसलिए पूर्ण मानचित्र में कुंजी बदलना मान्य है; अतिरिक्त आकार के राज्य को नियमों को निकाले या आंशिक रूप से स्वीकार किए बिना अस्वीकार कर दिया जाता है। बचे हुए लोगों को हटाया और पुनः नहीं जोड़ा जाता है। यदि बाद में कोई मानचित्र syscall विफल होता है, तो Netfence कॉल से पहले के सटीक चार-मानचित्र सूची को पुनर्स्थापित और सत्यापित करता है। रोलबैक के बाद सिद्ध मोड पुराना मोड या BLOCK_ALL (सामान्यतः BLOCK_ALL) होता है, इसलिए डेमॉन अटैचमेंट को तब तक बंद विफल रखता है जब तक एक पूर्ण आधिकारिक पुनर्प्रयास सफल नहीं हो जाता।

संरक्षित-नीति सुरक्षा स्थिति अटैचमेंट के साथ बनी रहती है और हार्टबीट में निर्यात की जाती है। BLOCK_ALL अपने आप में एक सामान्य, स्वस्थ कॉन्फ़िगर किया गया मोड है: policy_degraded गलत है जब policy_degraded_reason खाली है। एक जोखिमपूर्ण संरक्षित उत्परिवर्तन जो स्वस्थ BLOCK_ALL के दौरान शुरू होता है, पहले protected_policy_mutation_in_progress जर्नल करता है। यह एक क्षणिक क्रैश जर्नल है, स्थिर विफलता निदान नहीं: जीवित संचालन अपने इच्छित मोड को अंतिम जर्नल-साफ़ सहेजने से पहले प्रकाशित कर सकता है, और सफल समाप्ति जर्नल को स्वयं साफ़ कर देती है। यदि स्टार्टअप क्रैश के बाद इसे पाता है, तो स्टार्टअप पहले BLOCK_ALL को बाध्य और सिद्ध करता है, फिर protected_policy_mutation_interrupted बनाए रखता है। स्थिर अपमानित कारण कोड हैं:

• protected_policy_mutation_interrupted
• authoritative_protected_policy_failed
• incremental_deny_install_failed
• incremental_allow_removal_failed
• incremental_mode_change_failed

ये स्थिर वर्गीकरण हैं, कभी कच्चे syscall/स्टोर टेक्स्ट नहीं। प्रगति पर जर्नल एक आंतरिक बनाए रखा गया क्रैश सीमा है; हार्टबीट आँकड़े स्वामी उत्परिवर्तन के साथ क्रमबद्ध होते हैं और इसलिए या तो इसकी सफल सफाई या एक स्थिर विफलता रूपांतरण देखते हैं, लाइव मध्यवर्ती जर्नल नहीं। स्थिर अपमानित/बाधित कारण पैकेट प्रवर्तन को सिद्ध BLOCK_ALL में रखते हैं और वृद्धिशील CIDR और पैकेट-मोड कमांड को अस्वीकार करते हैं। स्वतंत्र DNS कॉन्फ़िगरेशन परिवर्तन और DNS TTL समाप्ति उस सिद्ध होल्ड के तहत जारी रह सकते हैं, लेकिन स्थिर कारण को साफ़ नहीं कर सकते या पैकेट नीति को पुनः सक्रिय नहीं कर सकते। स्थिर कारण से पुनर्प्राप्ति के लिए एक पूर्ण LPM और DNS वांछित स्थिति की आवश्यकता होती है: नियंत्रण तल या स्थानीय API के माध्यम से BulkUpdate लागू करें (या पुनर्स्थापित अटैचमेंट के ताज़ा Subscribed का SubscribedAck के साथ उत्तर दें)। Netfence पूर्ण संरक्षित स्थिति को चरणबद्ध करता है, आधिकारिक DNS स्थिति लागू करता है, अनुरोधित मोड सक्रिय करता है, और प्रत्येक चरण सफल होने के बाद ही टिकाऊ कारण को साफ़ करता है। नियंत्रण-तल पुनर्प्राप्ति BulkUpdate पर एक अद्वितीय command_id पसंद करें और एक सफल CommandResult की आवश्यकता है; स्थानीय API command_id को अस्वीकार करता है क्योंकि इसका यूनरी RPC परिणाम पहले से ही सफलता या विफलता रिपोर्ट करता है।

हार्टबीट सभी चार संरक्षित मानचित्रों के लिए वर्तमान भौतिक प्रविष्टियाँ, कठिन क्षमता और डेमॉन-पीढ़ी उच्च-जल स्वतंत्र रूप से उजागर करता है। बूटस्ट्रैप शामिल है; अपनाई गई पिन की गई प्रविष्टियाँ नई पीढ़ी के उच्च-जल को आरंभ करती हैं। map_full_drops संचयी है और इसमें संरक्षित क्षमता अस्वीकृतियाँ शामिल हैं। यदि कोई अधिभोग पढ़ना विफल होता है, तो डेमॉन अंतिम सिद्ध स्नैपशॉट बनाए रखता है और नई गणनाएँ आविष्कार करने के बजाय प्रति 30 सेकंड में अधिकतम एक बार चेतावनी उत्सर्जित करता है। दबाव से उबरने के लिए, प्रति-मानचित्र क्षमता से नीचे पूर्ण वांछित नियमों को कम करें और पूर्ण अद्यतन का पुनः प्रयास करें। filter.max_rule_entries बढ़ाना केवल लोड-समय है और मौजूदा पिन किए गए अटैचमेंट को पुनः बनाने की आवश्यकता होती है। यदि डेमॉन BLOCK_ALL सिद्ध नहीं कर सकता या अपने सुरक्षा मार्कर को स्थायी रूप से रिकॉर्ड नहीं कर सकता, तो वह उत्परिवर्तन प्रवेश को रोक देता है; मानचित्र/स्टोर दोष की मरम्मत करें और प्रवर्तन फिर से खुला मानने के बजाय पुनरारंभ करें।

प्रति होस्ट

डेमॉन चलाएँ, जो:

• अटैचमेंट, नीति और निरीक्षण के लिए एक स्थानीय gRPC API (DaemonService) उजागर करता है
• वैकल्पिक रूप से द्विदिश स्ट्रीम (ControlPlane.Connect) के माध्यम से आपके नियंत्रण तल से जुड़ता है
• eBPF प्रोग्राम लोड और प्रबंधित करता है

डेमॉन प्रारंभ करें:```bash

Start with default config

netfenced start

Start with custom config file

netfenced start --config /etc/netfence/config.yaml

**डेमन स्थिति जांचें:**```bash
netfenced status

control_plane.url के बिना, एक नया अटैचमेंट अक्षम packet/DNS मोड में कमिट होता है और स्थानीय API या CLI के माध्यम से तुरंत कॉन्फ़िगर किया जा सकता है। “Per attachment” के अंतर्गत दर्ज स्टैंडअलोन वर्कफ़्लो के लिए कोई control-plane प्रक्रिया आवश्यक नहीं है।

स्थानीय Unix-सॉकेट विश्वास सीमा

स्थानीय gRPC API में कोई per-RPC प्रमाणीकरण नहीं है। इसके Unix सॉकेट तक फ़ाइलसिस्टम पहुंच प्राधिकरण सीमा है, और जो भी प्रक्रिया कनेक्ट हो सकती है वह पूरी तरह से विश्वसनीय होस्ट-नेटवर्क प्रशासक है: यह होस्ट eBPF प्रोग्राम को अटैच या डिटैच कर सकती है, पैकेट और DNS नीति को बदल सकती है, और वर्कलोड ट्रैफ़िक को खोल या बंद कर सकती है। सॉकेट-ग्रुप सदस्यता को संकीर्ण रखें और सॉकेट के पैरेंट डायरेक्टरी की रक्षा करें।```yaml

Defaults to /var/run/netfence.sock.

socket: /run/netfence/netfence.sock

Unix group name or numeric GID. Empty/unset uses the daemon's effective GID.

socket_group: netfence-admin

`NETFENCE_SOCKET` और `NETFENCE_SOCKET_GROUP` समतुल्य पर्यावरण चर हैं। स्टार्टअप पर डेमॉन एक निजी स्टेजिंग निर्देशिका में सॉकेट को बाइंड करता है, उसके समूह और मोड `0660` को सेट करता है जब तक वह अगम्य होता है, और फिर इसे परमाणु रूप से प्रकाशित करता है। डेमॉन कॉन्फ़िगर किए गए लक्ष्य पर किसी भी पूर्व-मौजूदा यूनिक्स सॉकेट को हटा देता है—यह किसी पुराने सॉकेट और किसी अन्य चालू डेमॉन के स्वामित्व वाले सॉकेट के बीच अंतर नहीं करता है—इसलिए वास्तव में एक डेमॉन को सॉकेट पथ का स्वामी होना चाहिए। यह एक गैर-सॉकेट लक्ष्य को हटाने से इनकार करता है। Linux पर, no-replace rename उस हटाने के बाद बनाए गए नए पथ को अधिलेखित होने से रोकता है; शटडाउन केवल तब प्रकाशित पथ को हटाता है जब वह अभी भी डेमॉन के अपने सॉकेट inode की पहचान करता है। एक अमान्य समूह, स्वामित्व/मोड विफलता, या गैर-सॉकेट लक्ष्य बिना अनुमोदक एंडपॉइंट प्रकाशित किए स्टार्टअप को विफल कर देता है।

### नियंत्रण-प्लेन परिवहन सुरक्षा (TLS / mTLS / bearer token)

नियंत्रण-प्लेन चैनल सिस्टम में सबसे उच्च-मूल्य का आक्रमण सतह है (जो कोई भी इसे नियंत्रित करता है वह प्रत्येक वर्कलोड पर `ALLOW` नियमों को धकेल सकता है), इसलिए डेमॉन **बंद होकर विफल होता है**: यदि `control_plane.url` सेट किया गया है, तो कॉन्फ़िग को स्पष्ट रूप से एक परिवहन चुनना होगा — या तो `control_plane.tls` ब्लॉक या `control_plane.insecure: true`। दोनों में से कोई भी न होने पर URL स्टार्टअप पर अस्वीकार कर दिया जाता है; कोई अंतर्निहित-प्लेनटेक्स्ट डिफ़ॉल्ट नहीं है। (यह एक जानबूझकर किया गया व्यवहार परिवर्तन है: पुराने संस्करण चुपचाप नियंत्रण प्लेन को बिना एन्क्रिप्ट किए डायल करते थे।)```yaml
control_plane:
  url: cp.internal:443
  tls:
    # CA bundle used to verify the control-plane server certificate.
    # Path to a PEM file or inline PEM; omit to use the system root pool.
    ca: /etc/netfence/cp-ca.pem
    # Client certificate + key (path or inline PEM). Setting BOTH enables
    # mTLS: the daemon presents this cert to the control plane. Setting only
    # one is a config error.
    cert: /etc/netfence/daemon.pem
    key: /etc/netfence/daemon.key
    # Optional hostname override for server certificate verification (SNI),
    # e.g. when dialing by IP.
    server_name: cp.internal
  # Optional bearer token, sent as `authorization: Bearer <token>` metadata
  # on every control-plane RPC. Refused on a plaintext channel unless
  # `insecure: true` was explicitly set (so a misconfiguration can't leak it).
  auth_token: "..."

केवल सिस्टम रूट्स के साथ TLS (सार्वजनिक CA-जारी सर्वर प्रमाणपत्र, कोई mTLS नहीं) बस एक खाली ब्लॉक है:```yaml control_plane: url: cp.example.com:443 tls: {}

स्थानीय विकास के लिए सादा पाठ एक स्पष्ट ऑप्ट-इन है (`tls` के साथ परस्पर अनन्य):```yaml
control_plane:
  url: localhost:9000
  insecure: true

प्रमाणपत्र और कुंजियाँ स्टार्टअप पर एक बार लोड होती हैं, इसलिए गलत पथ/PEM स्टार्ट को स्पष्ट त्रुटि के साथ विफल कर देता है, न कि हर पुन: कनेक्ट पर दिखाई देने के बजाय।

कंट्रोल-प्लेन जीवंतता (कीपअलाइव) और पुन: कनेक्ट बैकऑफ़

डेमॉन कंट्रोल-प्लेन कनेक्शन पर HTTP/2 कीपअलाइव पिंग भेजता है ताकि चुपचाप मृत पथ (केबल खिंचाव, हटाया गया NAT मैपिंग, ब्लैकहोल रूट) का पता लगाया जा सके और लगभग keepalive_time + keepalive_timeout में समाप्त किया जा सके — मिनटों तक CONNECTED बैठे रहने के बजाय जब तक कर्नेल का TCP पुनर्प्रेषण टाइमआउट न हो जाए, जबकि हर प्रॉक्सीड DNS क्वेरी अपना पूरा टाइमआउट खा लेती है। पुन: कनेक्ट को जिटर्ड एक्सपोनेंशियल बैकऑफ़ (1s से शुरू, दोगुना, ±20% जिटर, reconnect_backoff_max पर सीमित) द्वारा गति दी जाती है; बैकऑफ़ केवल 30 सेकंड तक कनेक्शन स्वस्थ रहने के बाद फ्लोर पर रीसेट होता है, इसलिए एक कंट्रोल प्लेन जो कनेक्शन स्वीकार करता है और तुरंत ड्रॉप करता है, बैकऑफ़ करता रहता है, फ्लोर पर बार-बार हमला नहीं होता।```yaml control_plane:

Send a keepalive ping after this much inactivity… (default 30s; gRPC

clamps the effective interval to a 10s minimum client-side)

keepalive_time: 30s

…and declare the peer dead if no ack arrives within this (default 10s).

keepalive_timeout: 10s

Cap on the jittered exponential reconnect backoff (default 30s).

reconnect_backoff_max: 30s

शून्य/अनसेट मान डिफ़ॉल्ट को दर्शाते हैं — वे **keepalive या backoff को अक्षम नहीं करते** हैं। आपके नियंत्रण तल (control plane) को अपनी gRPC keepalive प्रवर्तन नीति में इस पिंग कैडेंस की अनुमति देनी होगी (नीचे देखें), अन्यथा यह डेमॉन को `ENHANCE_YOUR_CALM (too_many_pings)` के साथ अस्वीकार कर देगा।

### डेमॉन पुनर्प्रारंभ, क्रैश और अपग्रेड (पिन की गई BPF स्थिति)

डेमॉन प्रत्येक अटैचमेंट के BPF लिंक और नियम मैप्स को bpffs पर पिन करता है (`filter.bpf_pin_dir`, डिफ़ॉल्ट `/sys/fs/bpf/netfence`, प्रति अटैचमेंट ID एक निर्देशिका)। क्योंकि पिन की गई स्थिति कर्नेल द्वारा रखी जाती है — डेमॉन प्रक्रिया द्वारा नहीं — **प्रवर्तन तब भी जारी रहता है जब डेमॉन डाउन होता है**: एक क्रैश (`kill -9`), एक सुचारू रुकना, या अपग्रेड अंतिम ज्ञात नीति (मोड + सभी नियम) को प्रवर्तित छोड़ देता है, और अगला डेमॉन प्रारंभ पिन की गई स्थिति को यथा-स्थिति ग्रहण करता है। रिस्टोर कभी भी लाइव मैप्स को पुनः अटैच या पुनर्लेखन नहीं करता है, इसलिए ऐसा कोई विंडो नहीं है जहां एक अनुमति सूचीबद्ध कार्यभार अवरुद्ध हो या अवरुद्ध गंतव्य की अनुमति हो, और कोई डुप्लिकेट अटैचमेंट नहीं होता है।

स्टॉप व्यवहार स्पष्ट कॉन्फ़िग है (`filter.detach_on_stop`):```yaml
filter:
  # false (default): stopping the daemon KEEPS ENFORCING — filters stay
  # attached via their bpffs pins and are re-adopted on the next start
  # (fail-closed across restarts/upgrades).
  # true: stopping the daemon detaches filters and removes their pins —
  # traffic is unfiltered while the daemon is down (explicit fail-open).
  detach_on_stop: false
  # bpffs directory for pinned state. Must be on a bpffs mount; the daemon
  # mounts bpffs at /sys/fs/bpf if needed (privileged). An explicit "" turns
  # pinning off entirely (BPF state then dies with the process).
  bpf_pin_dir: /sys/fs/bpf/netfence
  # Capacity of each authoritative/system LPM map (allowed/denied per family).
  # Protected entries are non-evictable; the DNS listener bootstrap consumes
  # one slot in its address family. Changing pinned-map capacity requires
  # recreating the attachment.
  max_rule_entries: 4096
  # Independent capacity of each DNS-derived exact-host HASH map (IPv4/IPv6).
  # These entries can never consume or evict authoritative/deny capacity.
  max_dns_rule_entries: 4096

एक स्पष्ट Detach (RPC/CLI), या किसी जीवित सह-स्वामित्व वाले लक्ष्य को हटाना, पिन की गई स्थिति को अटैचमेंट के साथ नष्ट कर देता है। रीस्टार्ट पर, लक्ष्य की अनुपस्थिति अनुमान लगाने का अधिकार नहीं देती: भविष्य की, अप्रतिबद्ध, मिश्रित, या अन्यथा अप्रमाणित बने रहने वाले पिन को संरक्षित किया जाता है और स्टार्टअप निरीक्षण के लिए रोक दिया जाता है।

पिन निर्देशिकाएँ एक संस्करणित स्थायित्व प्रारूप हैं। स्कीमा मार्कर को सबसे अंत में पिन किया जाता है, केवल तभी जब प्रत्येक आवश्यक मैप और लिंक मौजूद हो। एक पूर्व-सटीक-टियर अटैचमेंट को अपग्रेड करने से दो नए खाली सटीक मैप को एक प्रगति-में-है मार्कर के साथ पिन किया जाता है, जीवित आधिकारिक मैप का पुन: उपयोग करते हुए प्रत्येक लिंक के प्रोग्राम को परमाणु रूप से बदलता है, प्रोग्राम/मैप पहचान को सत्यापित करता है, और मार्कर को सबसे अंत में प्रतिबद्ध करता है। एक क्रैश या अस्पष्ट अपडेट मार्कर को अप्रतिबद्ध छोड़ देता है; अगला स्टार्ट उसी मैप का उपयोग करके हर लिंक को फिर से अपडेट करता है। पुरानी और नई प्रोग्राम पीढ़ियाँ उस सीमित मिश्रित अवस्था के दौरान समान आधिकारिक LPM नीति लागू करती हैं, इसलिए माइग्रेशन कभी भी किसी व्यवहार्य फ़िल्टर को अनपिन या पुन: निर्मित नहीं करता। अज्ञात, अपूर्ण, या अप्रमाणित पिन सेट को संरक्षित किया जाता है और अनुमान लगाने के बजाय निरीक्षण के लिए स्टार्टअप को रोकता है।

पुनः ग्रहण की गई स्थिति पर नोट्स:

• प्रत्येक सफलतापूर्वक बहाल किया गया अटैचमेंट आधिकारिक समाधान के लिए चिह्नित होता है। प्रत्येक कंट्रोल-प्लेन कनेक्शन पर डेमॉन पहले SyncRequest भेजता है, फिर प्रत्येक बहाल अटैचमेंट के लिए एक पूर्ण Subscribed घोषणा जिसे अभी भी समाधान की आवश्यकता है। एक ताज़ा SubscribedAck के साथ जवाब दें: इसका मोड, CIDRs, TTLs, और DNS कॉन्फ़िगरेशन संपूर्ण वांछित स्थिति है। डेमॉन एक डेल्टा लागू करता है (अपरिवर्तित CIDRs को कभी नहीं हटाया जाता), और पूरे ack के लागू होने के बाद ही बहाल मार्कर को साफ़ करता है। टाइमआउट, डिस्कनेक्ट, या सत्यापन विफलता प्रवर्तन को अपरिवर्तित छोड़ देती है। एक फ़िल्टर/मैप/DNS/स्टोर आवेदन विफलता आंशिक डेल्टा छोड़ सकती है, लेकिन समाधान पूरे मैप क्लियर या हटाना/पुन: जोड़ना अपरिवर्तित उत्तरजीवियों का उपयोग नहीं करता; बहाल मार्कर सेट रहता है और डेमॉन बाद के कनेक्शन के बाद पुन: प्रयास करता है।
• नियम TTL समय-सीमाएँ स्वयं स्थायी नहीं होती हैं। पुनः ग्रहण किए गए नियमों को अस्थायी रूप से स्थायी माना जाता है जब तक ताज़ा SubscribedAck नहीं आता; वह आधिकारिक ack उनकी अवधियों को ठीक से बदल देता है, जिसमें समय-सीमा को छोटा करना या अस्थायी स्थायी नियम को वापस सीमित-TTL नियम में बदलना शामिल है। बहाल किए गए सटीक DNS कुंजियों की सूची बनाई जाती है और बाधित अस्थायी स्वामियों द्वारा प्रस्तुत की जाती है (वास्तविक पिन किए गए मैप क्षमताएँ सीमा हैं); पहला आधिकारिक DNS कॉन्फ़िगरेशन हर कृत्रिम दावे को त्याग देता है, बिना स्वामी के छोड़ी गई कुंजियों को हटाता है, और किसी कुंजी को केवल तभी संरक्षित करता है जब उसके पास अलग से कोई सामान्य जीवित स्वामी हो। एक अ-प्रामाणिक/टकराने वाली सूची बिना अनुमान लगाए या आंशिक रूप से स्वामित्व मेटाडेटा प्रकाशित किए बहाली को रोकती है।
• कोई स्थायी स्थानीय वांछित-स्थिति दस्तावेज़ मौजूद नहीं है। यदि कोई कंट्रोल प्लेन कॉन्फ़िगर या पहुंच योग्य नहीं है, तो कोई स्वचालित नियम परिवर्तन नहीं होता: एक ग्रहण किया गया पिन किया गया मैप अपने अंतिम ज्ञात संरक्षित CIDRs को लागू करता रहता है, उपयोगकर्तास्पेस रजिस्ट्री में अस्थायी के रूप में प्रस्तुत, जब तक पूर्ण अपडेट न हो। एक बहाली जो मान्य पिन ग्रहण नहीं कर सकती, अटैचमेंट को उसके स्थायी मोड में खाली मैप के साथ पुन: बनाती है (अनुमत सूची/ब्लॉक-ऑल के लिए विफल-बंद)। एक स्टैंडअलोन ऑर्केस्ट्रेटर को प्रत्येक डेमॉन रीस्टार्ट के बाद netfenced apply-rules को फिर से चलाना चाहिए ताकि अस्थायी पैकेट स्थिति को बदला जा सके और अपनी पूर्ण वांछित स्थिति और TTLs को बहाल किया जा सके।

प्रति अटैचमेंट

आपका ऑर्केस्ट्रेशन सिस्टम डेमॉन के स्थानीय API को कॉल करता है।

RPC:``` DaemonService.Attach(interface_name: "veth123", tc_direction: TC_DIRECTION_INGRESS, metadata: {vm_id: "abc"}) // or DaemonService.Attach(cgroup_path: "/sys/fs/cgroup/...", metadata: {container_id: "xyz"})

**CLI:**```bash
# Attach to a host-side veth peer or VM tap (TC) - use ingress direction
netfenced attach --interface veth123 --direction ingress --metadata vm_id=abc

# Attach to a cgroup
netfenced attach --cgroup /sys/fs/cgroup/... --metadata container_id=xyz

# Attach to an uplink inside the workload's own netns (TC) - egress is the default
netfenced attach --interface eth0 --metadata tenant=acme,env=prod

TC निर्देश: tc_direction फ़ील्ड (CLI --direction) चुनता है कि फ़िल्टर किस TCX हुक से जुड़ता है, और सही हुक चुनना इस बात पर निर्भर करता है कि इंटरफ़ेस लिंक के किस तरफ है:

निर्देश केवल इंटरफ़ेस (TC) अटैचमेंट पर लागू होता है; cgroup अटैचमेंट के लिए इसे अनदेखा किया जाता है।

• डेमन लक्ष्य पर एक eBPF फ़िल्टर अटैच करता है।
• जब control_plane.url कॉन्फ़िगर किया गया हो, तो डेमन Subscribed{id, target, type, metadata} भेजता है और प्रारंभिक कॉन्फ़िग (मोड, CIDR, DNS नियम) के साथ SubscribedAck की प्रतीक्षा करता है। यदि कंट्रोल प्लेन टाइमआउट (डिफ़ॉल्ट 5 सेकंड, control_plane.subscribe_ack_timeout के माध्यम से कॉन्फ़िगरेबल) के भीतर जवाब नहीं देता है, तो अटैचमेंट रोल बैक कर दिया जाता है और अटैच कॉल विफल हो जाती है। सत्यापन और अन्य प्री-कमिट विफलताएँ उसी सामान्य रोलबैक नियम का पालन करती हैं।
• कोई कंट्रोल प्लेन कॉन्फ़िगर न होने पर, अटैच तुरंत डिसेबल मोड में कमिट हो जाता है; इसे कॉन्फ़िगर करने के लिए नीचे दिए गए स्थानीय पॉलिसी कमांड का उपयोग करें।
• एक वैध प्रारंभिक पॉलिसी जो संरक्षित-मानचित्र/स्टोर विफलता तक पहुँचती है, वह जानबूझकर कमिट की गई त्रुटि अपवाद है: डेमन अटैचमेंट को विनाशकारी रूप से रोलबैक करने के बजाय स्थायी BLOCK_ALL में बनाए रखता है। एक सीमित टाइमआउट के साथ, Attach एक त्रुटि लौटाता है जिसमें बनाए रखा गया अटैचमेंट ID होता है; कॉलर List में लक्ष्य से मिलान करके उस ID को खोज सकता है, और कंट्रोल प्लेन को इसे एक पूर्ण BulkUpdate के साथ पुनर्प्राप्त करना होगा।
• subscribe_ack_timeout: 0 के साथ, एक नया Attach को कतारबद्ध करने के बाद लौटता है; बाद में आने वाला एक को अभी भी मान्य और लागू किया जाता है। यह शून्य मान पुनर्स्थापित-अटैचमेंट समाधान को अक्षम नहीं करता है: पुनर्स्थापना प्रयास बैकग्राउंड में 5 सेकंड तक प्रतीक्षा करते हैं और यदि आवश्यक हो तो बाद के कनेक्शन पर पुनः प्रयास करते हैं। यदि वह बाद में आने वाला एक संरक्षित दबाव से टकराता है, तो पहले से लौटाया गया अटैचमेंट में बना रहता है; न तो उत्सर्जित करता है और न ही त्रुटि , और डेमन पुनरारंभ से पहले अपने आप घोषणा को पुनः संचालित नहीं करता है। में और उसके कारण, अधिभोग/क्षमता, और का पता लगाएं, फिर एक स्पष्ट पुनर्प्राप्ति परिणाम प्राप्त करने के लिए के साथ एक पूर्ण भेजें।

RPC:``` DaemonService.Detach(id)

**CLI:**```bash
netfenced detach --id <attachment-id>

अनुलग्नक सूचीबद्ध करें:```bash netfenced list netfenced list --all # fetch all pages

### स्थानीय नीति और निरीक्षण

हर स्थानीय उत्परिवर्तन एकल `DaemonService.ApplyCommand(ControlCommand)` RPC का एक पतला CLI एन्कोडिंग है। `attach` द्वारा लौटाए गए अटैचमेंट आईडी प्रदान करें:```bash
# Packet policy and protected CIDRs.
netfenced set-mode <id> allowlist
netfenced allow-cidr <id> 10.0.0.0/8
netfenced allow-cidr <id> 192.0.2.10/32 --ttl 5m
netfenced deny-cidr <id> 10.20.0.0/16
netfenced remove-cidr <id> 10.20.0.0/16 --list deny
# --list accepts allow, deny, or both (the default).

# DNS policy.
netfenced set-dns-mode <id> denylist
netfenced allow-domain <id> example.com --subdomains
netfenced deny-domain <id> blocked.example.com
netfenced remove-domain <id> blocked.example.com

# Deterministic current-policy inspection as protobuf JSON.
netfenced rules <id>

पैकेट मोड disabled, allowlist, denylist, और block-all हैं; DNS मोड disabled, allowlist, denylist, और proxy हैं। DNS proxy के लिए एक सुलभ कॉन्फ़िगर किया गया कंट्रोल प्लेन आवश्यक है। डोमेन मिलान सबसे विशिष्ट मिलान प्रत्यय का उपयोग करता है; जब समान रूप से विशिष्ट अनुमति और अस्वीकार नियम दोनों मेल खाते हैं, तो अस्वीकार जीतता है। CIDR और डोमेन कैननिकलीकृत किए जाते हैं। नकारात्मक, विकृत, या अन्यथा अमान्य TTLs, enums, CIDRs, डोमेन, चयनकर्ता और नेस्टेड संदेश म्यूटेशन से पहले अस्वीकार कर दिए जाते हैं, इसलिए एक अमान्य कमांड एक नीति नो-ऑप है।

पूर्ण प्रतिस्थापन के लिए, apply-rules मौजूदा BulkUpdate प्रोटोबफ JSON आकार को किसी फ़ाइल या stdin से पढ़ता है:```bash cat >rules.json <<'JSON' { "mode": "POLICY_MODE_ALLOWLIST", "allowCidrs": [{"cidr": "10.0.0.0/8"}], "dns": { "mode": "DNS_MODE_DENYLIST", "denyDomains": [{"domain": "blocked.example.com", "includeSubdomains": true}] } } JSON netfenced apply-rules --file rules.json

Equivalent stdin form:

netfenced apply-rules --file - < rules.json

`ApplyCommand` केवल `SetMode`, `AllowCIDR`, `DenyCIDR`, `RemoveCIDR`, `BulkUpdate`, `SetDnsMode`, `AllowDomain`, `DenyDomain`, और `RemoveDomain` को स्वीकार करता है।
स्ट्रीम-ओनली sync/ack वेरिएंट, अज्ञात या खाली कमांड, और स्थानीय `command_id` मान अस्वीकार कर दिए जाते हैं। `BulkUpdate` एकमात्र स्थानीय संक्रिया है जो स्थिर डिग्रेडेड पैकेट नीति को पुनर्प्राप्त कर सकती है; इसमें पूर्ण LPM और DNS वांछित स्थिति शामिल होनी चाहिए।

वैकल्पिक `ControlCommand.remove_cidr_list` चयनकर्ता जब कमांड वेरिएंट `RemoveCIDR` होता है, तो अनुमति सूची, अस्वीकार सूची, या दोनों को लक्षित कर सकता है। इसका लीगेसी अनिर्दिष्ट मान और स्पष्ट `BOTH` दोनों सूचियों से हटाते हैं, मूल प्रोटोकॉल व्यवहार को संरक्षित करते हुए।

स्थानीय और नियंत्रण-तल के उत्परिवर्तन एक पार्सर, उत्परिवर्तन अवरोध, TTL रजिस्ट्री, फेल-क्लोज़ पुनर्प्राप्ति पथ, और नीति स्वामी साझा करते हैं। जानबूझकर स्थानीय-बनाम-नियंत्रण-तल स्वामित्व मध्यस्थता नहीं है: एक व्यक्तिगत नीति सूची पर परस्पर विरोधी संक्रियाएँ स्रोत की परवाह किए बिना अपने प्रतिबद्ध क्रम में प्रभावी होती हैं। विशेष रूप से, बाद में आने वाला पूर्ण नियंत्रण-तल `BulkUpdate` या `SubscribedAck` स्थानीय स्थिति को बदल सकता है।

`GetRules`/`netfenced rules` एक सुसंगत, नियतात्मक यूज़रस्पेस रजिस्ट्री स्नैपशॉट लौटाता है। प्रत्येक CIDR अनुमति/अस्वीकार सूची, स्थानीय-या-नियंत्रण-तल `policyOwned`, डेमॉन `systemOwned`, निरपेक्ष `expiresAt`, पुनर्स्थापित `provisional`, और अंतिम प्रतिबद्ध कर्नेल `installed` स्थिति की रिपोर्ट करता है। बिना किसी स्वामी वाली स्थापित प्रविष्टि एक असफल-निष्कासन पुनर्प्रयास है, वांछित नीति नहीं। DNS आउटपुट लाइव, सामान्यीकृत प्रभावी `DnsConfig` है। निरीक्षण जानबूझकर संरक्षित कर्नेल मैप्स की गणना नहीं करता या गतिशील रूप से हल किए गए DNS सटीक-होस्ट कैश प्रविष्टियों को उजागर नहीं करता; संरक्षित-मैप अधिभोग के लिए हार्टबीट टेलीमेट्री का उपयोग करें।

## नियंत्रण तल पर (आप इसे लागू करते हैं)

`ControlPlane.Connect` RPC लागू करें - एक द्विदिश स्ट्रीम:

अपने gRPC सर्वर की keepalive प्रवर्तन नीति कॉन्फ़िगर करें ताकि डेमॉन की पिंग आवृत्ति (`control_plane.keepalive_time`, डिफ़ॉल्ट 30s) की अनुमति हो: `MinTime` को उस अंतराल पर या उससे नीचे सेट करें और `PermitWithoutStream: true`। gRPC डिफ़ॉल्ट नीति (5 मिनट) डेमॉन के पिंग को दुरुपयोग मानती है और `ENHANCE_YOUR_CALM (too_many_pings)` के साथ कनेक्शन बंद कर देती है। Go में:```go
grpc.NewServer(grpc.KeepaliveEnforcementPolicy(keepalive.EnforcementPolicy{
    MinTime:             10 * time.Second,
    PermitWithoutStream: true,
}))

डेमॉन से प्राप्त करें:

• कनेक्ट/रीकनेक्ट पर SyncRequest (वर्तमान अनुलग्नकों की सूची)
• Subscribed जब नए अनुलग्नक जोड़े जाते हैं, और SyncRequest के बाद पुनर्स्थापित अनुलग्नकों के लिए जिन्हें अभी भी नवीन आधिकारिक स्थिति की आवश्यकता है
• Unsubscribed जब अनुलग्नक हटाए जाते हैं
• Heartbeat आँकड़ों के साथ
• CommandResult{command_id, id, success, error} — आपके द्वारा भेजे गए किसी भी कमांड का परिणाम जिसमें एक गैर-रिक्त command_id है (ControlCommand पर वैकल्पिक सहसंबंध nonce; बिना इसके कमांड कोई परिणाम उत्पन्न नहीं करते)। success केवल तभी सत्य है जब कमांड पूरी तरह से लागू हुआ — एक आंशिक रूप से लागू BulkUpdate संचित त्रुटि के साथ विफलता की रिपोर्ट करता है। परिणाम best-effort हैं: लापता परिणाम को अज्ञात मानें, विफल नहीं।

डेमॉन को भेजें:

• SyncAck SyncRequest प्राप्त करने के बाद
• SubscribedAck{mode, cidrs, dns_config} Subscribed प्राप्त करने के बाद (आवश्यक - डेमॉन इसकी प्रतीक्षा करता है)
• SetMode{mode} - IP फ़िल्टर नीति मोड बदलें
• AllowCIDR{cidr, ttl} / DenyCIDR / RemoveCIDR (वैकल्पिक रूप से allow, deny, या दोनों चुनें; अनिर्दिष्ट रहने पर पुराने "both" व्यवहार को बनाए रखता है)
• SetDnsMode{mode} - DNS फ़िल्टरिंग मोड बदलें
• AllowDomain{domain} / DenyDomain / RemoveDomain (सबसे विशिष्ट मिलान जीतता है; समान विशिष्टता वाले टाई में deny जीतता है)
• BulkUpdate{mode, cidrs, dns_config} - पूर्ण स्थिति सिंक

जब नियंत्रण तल (control plane) Subscribed प्राप्त करता है, तो उसे पूर्ण SubscribedAck के साथ उत्तर देना होता है। एक नए अनुलग्नक के लिए डेमॉन सामान्यतः स्थानीय कॉलर को सफलता लौटाने से पहले उस ack की प्रतीक्षा करता है। एक पुनर्स्थापित अनुलग्नक के लिए हैंडशेक पृष्ठभूमि में चलता है जबकि पिन की गई अंतिम-ज्ञात नीति प्रवर्तन जारी रखती है। VM/टेनेंट/कंटेनर की पहचान करने के लिए मेटाडेटा का उपयोग करें और पूर्ण वांछित मोड, CIDRs (TTLs सहित), और DNS स्थिति लौटाएं; एक छोड़ा गया DNS कॉन्फ़िग अक्षम का अर्थ है खाली डोमेन सूचियों के साथ।

पुनर्कनेक्ट और इडेमपोटेंसी (आवश्यक)

SyncRequest आधिकारिक समाधान बिंदु है: प्रत्येक (पुनः)कनेक्ट पर यह स्ट्रीम पर पहली घटना है और डेमॉन के वर्तमान अनुलग्नक सेट को सूचीबद्ध करता है। अपने दृष्टिकोण को इसके अनुसार समाधान करें — उन अनुलग्नकों को जोड़ें जिनके बारे में आप नहीं जानते थे, जो सूची में अनुपस्थित हैं उन्हें हटा दें। पुनर्कनेक्ट पर डेमॉन पिछले कनेक्शन के विरुद्ध कतारबद्ध घटनाओं को हटा देता है (सिंक उन्हें ओवरराइड करता है), इसलिए आप पुराने Heartbeats, सिंक से पहले से अनुपस्थित अनुलग्नकों के लिए Unsubscribeds, या मृत कनेक्शन से बाद में दोबारा चलाए गए CommandResults नहीं देखेंगे। डिज़ाइन के अनुसार दो किनारी मामले बने रहते हैं, और आपके नियंत्रण तल (control plane) को उन्हें इडेमपोटेंट रूप से संभालना चाहिए:

• एक Subscribed एक SyncRequest का अनुसरण कर सकता है जो पहले से ही समान id सूचीबद्ध करता है। ऐसा तब होता है जब एक नए अनुलग्नक का ack पुनर्कनेक्ट के दौरान लंबित था, और जानबूझकर प्रत्येक पुनर्स्थापित अनुलग्नक के लिए जब तक एक आधिकारिक ack पूरी तरह से लागू नहीं हो जाता। इसे एक अद्यतन के रूप में मानें, एक ताजा पूर्ण SubscribedAck के साथ उत्तर दें, और इसे कभी भी डुप्लिकेट के रूप में न छोड़ें। SyncRequest अनुलग्नक सूची का समाधान करता है; SubscribedAck वांछित नीति का समाधान करता है।
• एक घटना जो (पुनः)कनेक्ट के साथ समवर्ती रूप से उत्पन्न होती है, वह सिंक स्नैपशॉट के साथ किसी भी दिशा में प्रतिस्पर्धा कर सकती है। किसी अज्ञात या पहले से हटाए गए अनुलग्नक id के लिए Unsubscribed को नो-ऑप के रूप में मानें।

नियम जीवनकाल (TTLs)

• CIDR प्रविष्टियाँ (AllowCIDR/DenyCIDR कमांड, और SubscribedAck/BulkUpdate में CIDR सूचियाँ) एक वैकल्पिक TTL रखती हैं। TTL वाले नियम डेमॉन जैनिटर द्वारा समाप्त होने पर हटा दिए जाते हैं (स्कैन अंतराल ttl_janitor_interval, डिफ़ॉल्ट 1s); बिना TTL वाले नियम स्थायी होते हैं।
• वृद्धिशील AllowCIDR/DenyCIDR पुन:जोड़ एक CIDR को बाद की समय सीमा तक बढ़ाते हैं — वे कभी छोटा नहीं करते — और बिना TTL के एक वृद्धिशील पुन:जोड़ इसे स्थायी बनाता है। इसके विपरीत, SubscribedAck/BulkUpdate में पूर्ण स्थिति प्रत्येक नियंत्रण-तल जीवनकाल को बिल्कुल बदल देती है, इसलिए आधिकारिक समाधान TTL को छोटा कर सकता है या लाइव मैप प्रविष्टि को हटाए/पुन:जोड़े बिना स्थायी को सीमित में बदल सकता है। किसी वृद्धिशील नियम को जल्दी छोड़ने के लिए RemoveCIDR का उपयोग करें।
• DNS-समाधानित IPs केवल सटीक स्तर में प्रवेश करते हैं जिसमें रिकॉर्ड TTL dns.min_filter_ttl द्वारा फ़्लोर किया जाता है (डिफ़ॉल्ट 60s; शून्य/अनसेट का अर्थ डिफ़ॉल्ट है, "कोई फ़्लोर नहीं" नहीं)। शून्य का अपस्ट्रीम TTL इसलिए फ़्लोर के लिए रहता है; एक छोड़ा गया PROXY TTL को फ़्लोर लागू करने से पहले स्पष्ट रूप से 300s पर डिफ़ॉल्ट किया जाता है। एक स्थायी या लंबे जीवनकाल वाला CIDR नियम जो समान पते को कवर करता है, सटीक DNS स्वामित्व समाप्त होने पर संरक्षित LPM स्तर में स्वतंत्र रूप से स्थापित रहता है।