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 मा सार्ने सहायकले पाउँदैन। अनुमान नगरी जाँच्नुहोस्, विशेष गरी आफैलाई पुनः चलाउने सबैका लागि।

अन्तमा, सुरुङ बन्द हुँदा के हुनुपर्छ भन्ने निर्णय गर्नुहोस्। चुपचाप पूर्ण बाइपास बन्ने अपवाद बन्द भएर खस्ने अपवादभन्दा फरक सुरक्षा अवस्था हो, र तीमध्ये एउटा मात्र तपाईंले चाहेको हो।