तुमचा 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 मधील नियम तुम्ही कोणतेही कुटुंब निवडले तरी ते कधीही पाहणार नाही। तीन स्थिती, दोन कुटुंबे, एक धडा: मार्ग हुक ठरवतो, आणि हुक तुमचा नियम अस्तित्वात आहे की नाही हे ठरवतो।