तपाईंको iptables नियमले ब्रिज गरिएको VPN ट्राफिक किन कहिल्यै देख्दैन
ब्रिज गरिएका फ्रेमहरूले तपाईंले निगरानी गरिरहनुभएको IP चेनलाई बाइपास गर्न सक्छन्। अर्को नियम थप्नु अघि मूल bridge परिवारको तुलना पुरानो br_netfilter सँग गर्नुहोस्।
एउटै होस्टका दुई वर्चुअल मेसिनहरू पुलमार्फत LAN मा पुग्छन्, र ip forward चेनमा राखिएको नियम कहिल्यै नसर्ने काउन्टर देखाउँछ। फ्रेमहरू वास्तविक छन्, ट्राफिक गइरहेको छ, र नियम बस त्यसको बाटोमा छैन। Linux ले पुल ट्राफिक देखाउने दुई तरिकाको तुलनाले यो मौनता व्याख्या गर्छ, र एउटा पुरानो मोड्युल लोड गर्नु देखिनेभन्दा किन नराम्रो उत्तर हो भन्ने पनि व्याख्या गर्छ।
एउटै होस्टबाट दुई बाटो
प्याकेटले यो होस्ट दुई धेरै फरक तरिकाले छोड्न सक्छ, र त्यो भिन्नताले कुन हुकहरूले यसलाई देख्ने भन्ने निर्धारण गर्छ। यदि गन्तव्य भौतिक पोर्टभन्दा पर छ र फ्रेम पुलका दुई पोर्टबीच स्विच हुन्छ भने, होस्टले Ethernet फ्रेम अगाडि पठाउँछ; राउटिङ कोडलाई सोधिँदैन, र कुनै राउटेड हप हुँदैन। यदि गन्तव्य होस्ट आफैं हो वा टनेल इन्टरफेसबाट पुगिने नेटवर्क हो भने, प्याकेट राउट हुन्छ र IP तहका हुकहरू साँच्चै लागू हुन्छन्। यो फाटो सम्झनुहोस्, किनकि चेन र परिवारबारे हरेक पछिको प्रश्न फ्रेमले दुई बाटोमध्ये कुन लिन्छ भन्नेबाट आउँछ।
त्यो भिन्नता केही पनि गणना नगर्ने नियमको पछाडिको पूरै कथा हो। veth9a1 बाट enp3s0 सम्मको ब्रिज गरिएको फ्रेमले IP स्ट्याक नभई पुल तर्छ, त्यसैले ip forward चेनले मिलाउन केही देख्दैन। पुरानो उदाहरणका इन्टरफेस नामहरूले तपाईंसँग कुन बाटो छ भन्ने निर्धारण गर्दैनन्, र त्यसैले पहिलो कदम नियमसङ्ग्रहतर्फ नभई टोपोलोजीतर्फ हेर्नु हो।
टनेलले नाम दिन लायक तेस्रो अवस्था थप्छ। TUN यन्त्रले IP प्याकेटहरू होस्टलाई दिन्छ, त्यसैले ती राउट हुन्छन् र साँच्चै IP चेनहरूबाट जान्छन्, जबकि पुलमा जोडिएको TAP यन्त्रले फ्रेम दिन्छ र पुलको अवस्थाजस्तै व्यवहार गर्छ। यन्त्रको प्रकारले निर्धारण गर्छ, उत्पादनको नामले होइन।
ब्रिज गरिएको फ्रेम देख्न सक्ने दुई परिवारको तुलना गर्नुहोस्
Linux ले nftables को bridge परिवारमार्फत मूल पुल फिल्टरिङ समर्थन गर्छ, र उडानमा फ्रेमहरू जाँचेर खसाल्न यसलाई कुनै पुरानो मोड्युल आवश्यक पर्दैन। कर्नेलकै पुलसम्बन्धी कागजात ले यो सिफारिस सिधै दिन्छ, जुन कुनै खोज परिणामले तपाईंलाई मोड्युल लोड गर्न भन्नुअघि जान्न लायक हुन्छ।
| Observation point | What it sees | What it costs |
|---|---|---|
nftables bridge family chains | Ethernet frames forwarded between bridge ports, in both directions | Rules must be written in bridge syntax with link-layer matches |
Legacy br_netfilter plus an ip chain | Bridged IPv4 and IPv6 packets, re-exposed through IP-layer hooks | Existing host rules may begin matching traffic they never saw before |
inet chain for routed traffic | Packets the host routes, including traffic arriving from a TUN device | No visibility into purely switched frames |
iptables को सट्टा nft आदेश प्रयोग गर्दा नियम आफैं सही परिवारमा राखिँदैन। bridge परिवारमा घोषणा गरिएको चेनले फ्रेम देख्छ; ip, ip6 वा inet मा घोषणा गरिएको चेनले ती देख्दैन, कुन बाइनरीले बनाएको भए पनि। परिवार चेनको गुण हो, टाइप गर्ने उपकरणको होइन।
पुरानो बाटो फरक तरिकाले काम गर्छ, र त्यसैले बानीले पक्ष छान्नुभन्दा तुलना गर्नु उचित हुन्छ। br_netfilter लोड गरेर bridge-nf-call सेटिङ सक्षम गर्दा ब्रिज गरिएको IPv4 र IPv6 ट्राफिक फेरि IP तहका हुकहरूमार्फत देखिन्छ, ताकि साधारण iptables नियमले अन्ततः यसलाई मिलाउन सकोस्। फ्रेमहरू बदलिँदैनन्; तिनीहरू जाने हुकहरूको समूह बदलिन्छ, जसको अर्थ प्रत्येक विद्यमान होस्ट नियमसँग अब नयाँ दर्शकवर्ग छ।
नियम थप्नु अघि प्रभावकारी बाटो पढ्नुहोस्
तीन आदेशले तपाईं कहाँ हुनुहुन्छ निर्धारण गर्छन्: पुल केसँग जोडिएको छ, पुरानो मोड्युल सक्रिय छ कि छैन, र bridge परिवारमा कुन चेनहरू पहिले नै छन्। केही लेख्नु अघि ती चलाउनुहोस्, किनकि उत्तरले दुई डिजाइनमध्ये कुन विस्तार गरिरहनुभएको छ भन्ने निर्धारण गर्छ। यो कदम छोड्नु भनेको सही नियम कुनै पनि नगइने चेनमा पर्ने तरिका हो।
bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"आउटपुटले अवस्थाहरूलाई सफा रूपमा अलग गर्छ। पुलमुनि सूचीबद्ध पोर्टहरूले कुन इन्टरफेसहरू स्विच हुँदैछन् बताउँछन्; खाली lsmod नतिजाको अर्थ ब्रिज गरिएका फ्रेमहरूको IP तहमा कुनै दृश्यता छैन; bridge परिवारको विद्यमान forward चेनको अर्थ नीतिको मालिक पहिले नै छ र तपाईंको नियम आफ्नै नयाँ चेनमा नभई त्यहीँ पर्छ।
त्यसपछि फेरि पढ्न सजिलो हुने एउटा नियम थप्नुहोस्, काउन्टरसहित र निर्णय नबदली, र एउटा प्रतिनिधि प्रवाह पुलबाट पठाउनुहोस्। सर्ने काउन्टरले फ्रेम नियमसम्म पुगेको प्रमाणित गर्छ। त्यत्ति मात्र यसले प्रमाणित गर्छ, त्यसैले अस्वीकृत बाटोसँग पनि अगाडि बढ्नुहोस्, किनकि सबै स्वीकार गर्ने नीतिले पनि सर्ने काउन्टर बनाउँछ।
nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter acceptपुरानो मोड्युलले व्यवहार कहाँ बदल्छ
चालु पुलमा पुरानो बाटो सक्षम गर्नु दृश्यता थप्ने तटस्थ क्रिया होइन। पहिले पुल ट्राफिकका लागि अगम्य रहेका नियमहरू गम्य हुन्छन्, जसमा अर्को इन्टरफेसका लागि लेखिएका होस्ट नियमहरू पनि पर्छन्, र ip forward चेनको पूर्वनिर्धारित drop नीति अचानक ती फ्रेमहरूमा लागू हुन सक्छ जो पहिले छोइन नगई जान्थे। जुन होस्ट त्यो पुलमार्फत व्यवस्थापन हुन्छ, त्यहाँ नतिजा कन्सोलविना लकआउट हुन्छ। यो काल्पनिक विफलता मोड होइन; यो तपाईंले भर्खरै फराकिलो बनाउनुभएको बाटोबाट पुग्ने मेसिनमा हुकको समूह फराकिलो बनाउँदाको सामान्य परिणाम हो।
अझ सुरक्षित क्रम भनेको कुन परिवारले नीति चलाउँछ निर्धारण गर्नु, नियम त्यहीँ लेख्नु, र कुनै पनि sysctl बदल्नु अघि स्वतन्त्र पुनःप्राप्ति बाटो राख्नु हो। यदि दुई परिवारले नियम राख्छन् भने कुन अधिकारिक हो लेखाजोखा गर्नुहोस्; दुई ओभरल्याप हुने नीतिहरू भनेको पढ्न एउटै फाइल नहुँदै प्याकेट एक ठाउँमा स्वीकार र अर्को ठाउँमा अस्वीकार हुने तरिका हो।
अलगावलाई आफैंले अझै पूर्ण डिजाइन चाहिन्छ। एउटा स्रोतलाई एउटा गन्तव्यसम्म अनुमति दिनुले एउटा प्रवाह चल्छ भन्ने मात्र प्रमाणित गर्छ, जबकि आवश्यकता सामान्यतया VM ले आफ्ना छिमेकी वा होस्टसम्म पुग्न नसक्नु हो। अस्वीकार नियमहरूका काउन्टर स्वीकार नियमको काउन्टरभन्दा बढी महत्त्वपूर्ण छन्, किनकि स्वीकार काउन्टर त्यही हो जो सर्ने तपाईंले पहिले नै अपेक्षा गर्नुभएको थियो।
अन्तमा, होस्ट-इनपुट अवस्था अलग राख्नुहोस्। पुलको आफ्नै IP मा सम्बोधित ट्राफिक forward मा नभई input मा आउँछ, र forward मा रहेको नियमले तपाईंले जुनसुकै परिवार छाने पनि त्यसलाई कहिल्यै देख्दैन। तीन अवस्था, दुई परिवार, एउटा पाठ: बाटोले हुक निर्धारण गर्छ, र हुकले तपाईंको नियम नै अस्तित्वमा छ कि छैन निर्धारण गर्छ।