nftables cgroup बायपाससाठी स्रोत पत्त्याची दुरुस्तीही लागते

एका cgroup मधून येणारी रहदारी चिन्हांकित करणे हा सोपा भाग आहे. एकच अनुप्रयोग भौतिक इंटरफेसातून बाहेर पडेपर्यंत आणि बाकी सर्व बोगद्यात राहील तोपर्यंत तीन स्वतंत्र निर्णय जुळले पाहिजेत: कोणता सॉकेट अपवादात येतो, ते चिन्ह कोणता मार्ग शोध सुरू करते आणि पॅकेट बाहेर पडताना कोणता स्रोत पत्ता घेऊन जाते. बहुतेक अयशस्वी प्रयत्न पहिले बरोबर करतात, दुसरे अर्धवट आणि तिसरेकडे कधीच पाहत नाहीत.

तीन निर्णय, एक नाही

वर्गीकरण कोण सूट आहे याचे उत्तर देते. मार्गनिर्देशन चिन्हांकित पॅकेट त्याऐवजी कुठे जाते याचे उत्तर देते. स्रोत निवड दूरचा टोक काय पाहील आणि उत्तर कुठे परत जावे याचे उत्तर देते.

हे स्वतंत्रपणे अयशस्वी होतात. पॅकेटचे वर्गीकरण होऊन, भौतिक इंटरफेसवर पुन्हा मार्गनिर्देशित होऊनही ते असे खाजगी पत्ता वाहू शकते जो कोणताही वरचा राउटर परत पाठवू शकत नाही, आणि त्यातून फायरवॉल ब्लॉकसारखाच दिसणारा टाइमआउट तयार होतो. वर्गीकरणाच्या टप्प्यात याबद्दल काहीही इशारा देत नाही. मार्गनिर्देशनाच्या टप्प्यातही काही नाही.

क्रमही महत्त्वाचा आहे. पॅकेट तयार होताना वर्गीकरण होते, त्यानंतर मार्गनिर्देशन आणि बाहेर पडण्याच्या ठिकाणी भाषांतर होते.

तीनपैकी कोणता टप्पा बिघडला आहे हे सांगता येत नसेल, तर तुम्ही डीबग करत नाही आहात, नियम पुन्हा मांडून आशा धरत आहात.

उद्याही टिकणाऱ्या cgroup शी जुळवा

nftables सॉकेटचे cgroup v2 सदस्यत्व तपासू शकते, जे खरोखर उपयुक्त आहे कारण ते गंतव्यस्थानाऐवजी प्रक्रियेचा पाठलाग करते. अडचण ओळखकर्त्यात आहे. मेनूमधून सुरू केलेला डेस्कटॉप अनुप्रयोग पुढील सुरुवातीला नाव बदलणाऱ्या तात्पुरत्या scope मध्ये राहतो.

nft list ruleset
systemctl status session.slice 2>/dev/null
cat /proc/self/cgroup

एका सत्रातून scope चे नाव कॉपी करून ते कठोरपणे लिहिणे असे नियम तयार करते जे आज चालते आणि उद्या शांतपणे जुळायचे थांबते. त्याऐवजी अनुप्रयोग तुम्ही नियंत्रित करता अशा समर्पित scope किंवा unit सारख्या जाणीवपूर्वक, स्थिर कार्यान्वयन संदर्भात ठेवा आणि त्याशी जुळवा. मग नियम रीबूट आणि पॅकेज अद्यतनांनंतरही टिकतो. तसेच तुमच्या सत्र इतिहासाशिवाय सहकाऱ्याला समजू शकेल अशी गोष्ट होते.

कोणती यंत्रणा वापरत आहात हेही नक्की सांगा. cgroup v1 चे net_cls वर्गीकरण आणि cgroup v2 चे सॉकेट जुळणे वेगवेगळ्या गोष्टी आहेत, आणि दस्तऐवजातील सारख्याच नावाचे क्षेत्र त्यांना अदलाबदल करण्यायोग्य करत नाही.

दुसरा शोध route साखळी सुरू करते

स्थानिक पातळीवर तयार होणाऱ्या रहदारीसाठी चिन्ह लावल्यानंतर काही घडते का हे साखळीचा प्रकार ठरवतो. filter प्रकाराची output साखळी पॅकेट चिन्हांकित करू शकते आणि कर्नल आधीच निवडलेलाच मार्ग वापरत राहतो. route प्रकाराची साखळी ही नवीन शोध मागणारी यंत्रणा आहे.

table inet bypass {
  chain mark {
    type route hook output priority mangle; policy accept;
    socket cgroupv2 level 2 "app.slice" meta mark set 0x1 comment "app bypass"
  }
}
ip rule add fwmark 0x1 lookup 200
ip route add default via 203.0.113.1 dev wlan0 table 200

मग चिन्हाला ते तक्त्याकडे पाठवणारा धोरण नियम लागतो, आणि तो तक्ता पूर्ण असला पाहिजे: डीफॉल्ट मार्ग, अनुप्रयोगाला अजून लागणारी स्थानिक गंतव्ये आणि खरोखर उत्तर देणारा वरचा गेटवे.

चिन्हाचे मूल्य जाणीवपूर्वक निवडा. WireGuard बाह्य वाहतूक रहदारीसाठी स्वतःचे fwmark वापरते, आणि अपघाताने त्याच क्रमांकावर उतरणे बोगद्याच्याच मार्ग अपवादात अडथळा आणू शकते अशा प्रकारे की निदान करणे कष्टप्रद होते.

स्रोत पत्ता मार्गाचा पाठलाग करत नाही

बोगद्याच्या मार्गासाठी आधीच स्रोत पत्ता निवडलेला सॉकेट पुनर्मार्गनिर्देशनानंतरही तो पत्ता कायम ठेवतो. मार्ग बदलात त्याला पुन्हा लिहिणारे काहीही नाही, म्हणूनच पॅकेट वरचे नेटवर्क परत पाठवू शकत नाही अशा खाजगी स्रोतासह भौतिक इंटरफेसातून बाहेर पडते.

दिसणारे लक्षण म्हणजे डेटा पाठवत असल्यासारखे वाटणारे पण कधीच उत्तर न मिळणारे अनुप्रयोग आणि पॅकेट कधीच परत न आल्याने काहीही न दाखवणारा फायरवॉल लॉग.

अरुंद दुरुस्ती म्हणजे त्या अनुप्रयोगाच्या चिन्हावर आणि त्याच्या खऱ्या आउटपुट इंटरफेसवर मर्यादित, आधीपासून असलेल्या NAT सोबत एकत्रित केलेला, त्याला बदलणारा नाही असा स्रोत भाषांतर नियम:

table inet bypass {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    meta mark 0x1 oifname "wlan0" masquerade
  }
}

फक्त अपवादाचे भाषांतर करा, इतर काहीही नाही. सर्वव्यापी masquerade नियम लक्षण दुरुस्त करतो आणि कोणता रहदारी कोणत्या मार्गाने गेला हे ओळखण्याची क्षमता नष्ट करतो. चिन्ह, खरा आउटपुट इंटरफेस आणि शक्य असल्यास अनुप्रयोगाच्या स्वतःच्या पत्त्याशी जुळवा. रुंद नियम लिहायला सोपे आणि नंतर लेखापरीक्षण करायला जवळजवळ अशक्य असतात.

अजूनही अपवादातून काय सुटते

नाव विश्लेषण दुसऱ्या cgroup मधील वेगळ्या resolver प्रक्रियेतून येऊ शकते, म्हणून ब्राउझरचे सॉकेट वर्गीकृत केल्याने त्याचे शोध वर्गीकृत होत नाहीत. resolver च्या प्रश्न बोगद्यात राहिले आणि कनेक्शन त्याबाहेर गेले तर split-horizon उत्तरे मार्गाशी जुळू शकत नाहीत. ती तफावत DNS बगसारखे दिसणारे पण नसलेले बिघाड निर्माण करते.

बहुतेक संरचनांमध्ये उपप्रक्रिया cgroup वारसा घेतात, पण स्वतःला स्वतःच्या scope मध्ये हलवणारा सहाय्यक घेत नाही. गृहीत धरण्याऐवजी तपासा, विशेषतः स्वतःला पुन्हा चालवणाऱ्या प्रत्येकासाठी.

शेवटी, बोगदा बंद असताना काय व्हावे हे ठरवा. शांतपणे पूर्ण बायपास होणारा अपवाद ही बंद होऊन पडणाऱ्या अपवादापेक्षा वेगळी सुरक्षा स्थिती आहे, आणि त्यातील फक्त एकच तुम्हाला अभिप्रेत होता.