चेनको नाम हुक होइन: 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 फ्रेमहरू स्वतः नियन्त्रण गर्दैन।

टाढाको गेटवे परिवर्तन गर्नु अघि स्वतन्त्र पुनःप्राप्ति पहुँच सुरक्षित राख्नुहोस्। त्यसपछि उही नियम-समूह अन्तर्गत अभिप्रेत प्रवाह र आवश्यक अस्वीकृतिहरू पुष्टि गर्नुहोस्। परिचित नाम भएको नयाँ खाली चेन मर्मत होइन।

तुलना एउटै प्रश्नमा टुंगिन्छ: यो प्याकेटका लागि कर्नेलले वास्तवमा कुन हुक बोलाउँछ? त्यसको उत्तर दिनुहोस्, र चेनको नाम महत्त्वपूर्ण रहँदैन।