साखळीचे नाव हुक नाही: iptables विरुद्ध nftables

दोन्ही फायरवॉल फॉरवर्ड होणारी VPN वाहतूक गाळू शकतात, आणि ते नियम पॅकेट मार्गाला वेगवेगळ्या प्रकारे जोडतात. iptables मध्ये तक्त्याच्या आत अंगभूत साखळ्या असतात, म्हणून FORWARD हा नाव असलेला हुक बिंदू म्हणून अस्तित्वात असतो. nftables साखळीचे नाव तिच्या प्रकार, हुक आणि प्राधान्यापासून वेगळे करते, याचा अर्थ FORWARD नावाची साधी साखळी काहीच गाळत नाही. दोन्ही प्रतिकृतींची तुलना एका साधनात बरोबर दिसणारी नोंद दुसऱ्यात का परिणाम करत नाही हे स्पष्ट करते.

साखळी हे पात्र आहे. कर्नेल ती पाहते का हे अंमलबजावणीवर आणि नियम-संच ती कशी जोडतो यावर अवलंबून असते.

दोन प्रतिकृती, दोन वेगळे जोडणी

iptables मध्ये filter तक्ता तीन अंगभूत साखळ्यांसह येतो, INPUT, FORWARD आणि OUTPUT, आणि -N वापरकर्ता-परिभाषित साखळी तयार करतो जी त्यांपैकी एकातून तिच्यावर उडी मारल्यावरच प्रभावी होते. nftables पुस्तिका त्याऐवजी आधारभूत साखळ्या परिभाषित करते, ज्या त्यांचा प्रकार, हुक आणि प्राधान्य जाहीर करतात, आणि साध्या साखळ्या, ज्या तसे करत नाहीत. आधारभूत साखळी कोणतेही नाव घेऊ शकते, आणि FORWARD नावाच्या साध्या साखळीला तिच्या लेबलातून कोणताही गुण मिळत नाही. हा सर्व फरक आहे, आणि केवळ नियमाचा मजकूर दाखवणाऱ्या पाठात तो दिसत नाही.

सुसंगतता बॅकएंड आदेशाच्या नावावरून वर्तनाचा अंदाज न लावण्याचे दुसरे कारण जोडतात. iptables चे दस्तऐवज iptables-nft अंतर्गत वेगळ्या असलेल्या क्रिया नमूद करते, म्हणून मूळ nftables, iptables-nft आणि जुना नियम-संच यांना एकाच तीन लेखनपद्धती नव्हे तर तीन प्रणाली माना.

त्रुटी तिच्या खऱ्या संदर्भात वाचा

गहाळ तक्ता, परवानगीचा अपयश, अनुपलब्ध कर्नेल सुविधा आणि गहाळ नावाची साखळी या चार वेगळ्या निष्कर्ष आहेत, आणि त्यांपैकी फक्त एक साखळीबद्दल आहे. साधनाची आवृत्ती, मागितलेला पत्ता कुटुंब आणि तक्ता, नेटवर्क नामविश्व आणि पहिली अचूक त्रुटी नोंदवा. नंतर नियम-संच कोणत्या घटकाचा आहे ते तपासा: फायरवॉल सेवा किंवा उत्पादन-व्यवस्थापित गेटवे स्वतःच्या साखळ्या आणि क्रम निर्माण करू शकतात. त्यांच्या शेजारी मूळ साखळी जोडल्यास व्यवस्थापित धोरण अस्पर्श राहते आणि यादी अधिक गोंधळक होते.

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

काउंटर पोहोच सिद्ध करतात, निर्णय नाही

नियम काउंटर सांगतात की नियमापर्यंत पोहोचले. पुढील नियमाने क्रियेला परवानगी दिली हे ते सांगत नाहीत, आणि प्रत्येक पर्यायी मार्ग नाकारला गेला हे सिद्ध करत नाहीत. एका निरुपद्रवी अधिकृत प्रवाहादरम्यान, नियम क्रम आणि साखळी जोडणीसह ते वाचा, आणि निर्णय नव्हे तर एक निरीक्षण म्हणून पाहा. drop नियमावरील शून्येतर काउंटरचा अर्थ वाहतूक त्याला लागली; जी लागली नाही त्या वाहतुकीबद्दल तो काहीही सांगत नाही.

कर्नेल IP फॉरवर्डिंग पूर्णपणे वेगळे सेटिंग आहे. साखळी असणे फॉरवर्डिंग सक्षम करत नाही, आणि परिचित लेबल नसणे म्हणजे फॉरवर्डिंग थांबले असे नाही.

तुम्हाला ज्या प्रवाहाचे संरक्षण करायचे आहे ते वर्णन करा

डीकॅप्स्युलेशननंतर एक क्लायंट विनंती लिहा: तिचा स्रोत, तिचे गंतव्य, पत्ता कुटुंब, आणि ती गेटवेवर संपते की त्यातून जाते. स्थानिक सेवेचे इनपुट आणि फॉरवर्ड होणारी वाहतूक वेगवेगळ्या बिंदूंवर पाहिली जाते, म्हणून त्यांना वेगळे नियम आणि वेगळ्या चाचण्या लागतात. ब्रिज्ड VPN साठी ब्रिज मार्गही तपासा, कारण IP स्तरावरील साखळी Ethernet फ्रेम्सवर स्वयंचलितपणे देखरेख करत नाही.

दूरस्थ गेटवे बदलण्यापूर्वी स्वतंत्र पुनर्प्राप्ती प्रवेश राखून ठेवा. नंतर त्याच नियम-संचाखाली इच्छित प्रवाह आणि आवश्यक नकारांची पुष्टी करा. परिचित नावाची नवीन रिकामी साखळी दुरुस्ती नाही.

तुलना एका प्रश्नावर संपते: या पॅकेटसाठी कर्नेल प्रत्यक्षात कोणता हुक कॉल करते? त्याचे उत्तर द्या, आणि साखळीचे नाव महत्त्वाचे राहत नाही.