tun0 छैन? nftables मा डिक्रिप्ट गरिएको IPsec लाई meta ipsec सँग मिलाउनुहोस्

तपाईं टनेल इन्टरफेसको अपेक्षा गर्नुहुन्छ, खोज्नुहुन्छ, र फायरवालमा मिलाउन केही हुँदैन। यो नीतिमा आधारित गेटवे का लागि सामान्य हो: इन्क्रिप्ट गरिएको आदानप्रदान भौतिक इन्टरफेसमा आउँछ, र त्यसपछि अगाडि पठाइने डिक्रिप्ट गरिएको आन्तरिक प्याकेट पनि त्यही इन्टरफेसमा आएको देखिन्छ। tun0 छैन, किनकि कसैले पनि त्यो बनाएको छैन।

आन्तरिक अनुरोध अझै आफ्नै स्रोत, गन्तव्य र सेवा भएको छुट्टै प्याकेट हो, र कर्नेललाई त्यो कुन सुरक्षा संघबाट बाहिर निस्कियो भन्ने थाहा छ। यही ज्ञान एउटा फायरवाल नियमले मिलाउन सक्छ।

दुई प्याकेट, एउटा इन्टरफेस

आउने दिशा कल्पना गर्नुहोस्। ESP वा UDP मा लपेटिएको प्याकेट आउँछ, कर्नेलले मिल्ने नीति भेट्टाउँछ, डिक्रिप्ट गर्छ र स्पष्ट प्याकेट अगाडि पठाउने मार्गलाई दिन्छ। इन्टरफेसको नाम मात्र हेर्ने नियमले त्यो प्याकेटलाई त्यही तारमा आउने अन्य कुनै ट्राफिकबाट छुट्याउन सक्दैन।

त्यसलाई छुट्याउने कुरा प्याकेटसँग जोडिएको आउने सुरक्षा मार्गको सन्दर्भ हो। nftables ले त्यसलाई meta ipsec exists का रूपमा देखाउँछ, जुन प्याकेट IPsec सुरक्षा मार्गबाट आएको बेला सत्य हुन्छ। त्यसलाई ग्राहक पूल, गन्तव्य र सेवासँग जोड्नुहोस्, नियम सुरक्षित हुनलाई पुग्ने विशिष्ट हुन्छ।

सन्दर्भ छोड्नु सामान्य गल्ती हो, र त्यो सौन्दर्यको होइन, सुरक्षाको गल्ती हो। ग्राहक पूलबाट आउने सबै स्वीकार गर्ने नियमले स्थानीय सञ्जालबाट आएको नक्कली प्याकेट पनि उत्तिकै खुसीसाथ स्वीकार गर्छ, किनकि स्रोत ठेगाना आफैंमा कुनै कुराको प्रमाण होइन। स्रोतलाई अर्थपूर्ण बनाउने सबैभन्दा सस्तो मार्ग सुरक्षा मार्गको सन्दर्भ हो। लेखापरीक्षणपछि थप्नुको सट्टा सुरुदेखि नै त्यससँगै नियम लेख्नुहोस्।

अगाडि पठाउने नियम लेख्नुहोस्

10.90.0.0/24 मा ग्राहकहरू भएको प्रमाणित IPv4 टाढा-पहुँच सेवा र 203.0.113.40 मा एउटा स्वीकृत गन्तव्य छ भनी मान्नुहोस्। त्यो प्रवाहका लागि नियमको टुक्रा यस्तो देखिन्छ।

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

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

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

बाह्य आदानप्रदानका अनुमतिहरू छुट्टै छन्। गेटवेको इनपुट मार्गलाई यसले वास्तवमै प्रयोग गर्ने IKE र ESP वा UDP लपेटन पोर्ट चाहिन्छ, र ती अनुमतिहरूले भित्रको डिक्रिप्ट गरिएको प्याकेटबारे केही पनि अधिकृत गर्दैनन्। दुवै मिसाउनु भनेको चलिरहेको टनेल सबै अगाडि पठाउने फायरवालसँग अन्त्य हुने बाटो हो।

आउने सन्दर्भ जाने सन्दर्भ होइन

त्यही अभिव्यक्ति परिवारले अर्को दिशालाई rt ipsec ले समेट्छ, जसले प्याकेटले प्रयोग गर्ने जाने सुरक्षा संघको वर्णन गर्छ। यसले फरक प्रश्नको उत्तर दिन्छ: यो प्याकेट कहाँबाट आयो भन्ने होइन, तर अर्को चरणमा यो संरक्षित हुन्छ कि हुँदैन।

यो भिन्नता एउटा टनेल अन्त्य गरी अर्कोमा अगाडि पठाउने गेटवेमा महत्त्वपूर्ण हुन्छ। प्याकेट डिक्रिप्ट भएर आउन सक्छ र तैपनि इन्क्रिप्ट भएर जानुपर्ने हुन्छ, र आउने सन्दर्भका लागि मात्र लेखिएको स्वीकृतिले जाने आवश्यकताबारे केही भन्दैन। नीतिले त्यो सुरक्षा माग्छ भने, राउटिङले सम्हाल्छ भनी मान्नुको सट्टा नियमसमूहले त्यो व्यक्त गर्नुपर्छ।

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

NAT फायरवाल निर्णय होइन

निजी ग्राहक पूलबाट इन्टरनेटतर्फ जाने ट्राफिकलाई सामान्यतः स्रोत अनुवाद चाहिन्छ, ताकि उत्तरले फर्किने बाटो भेट्टाओस्। तर अर्को जाने IPsec नीतिका लागि छानिएको ट्राफिकले आफ्नो आवश्यक छुट कायम राख्नुपर्छ, र अर्को सुरक्षा निर्णयको बारेमा नसोची हरेक निजी स्रोत मास्क गर्नुले त्यो तोड्छ।

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

उल्टो पनि सत्य हो र मानिसलाई अचम्मित पार्छ: एउटा फिल्टर आधार शृंखलामा कतै भएको स्वीकृतिको अर्को लागू शृंखलाको पछिल्लो अस्वीकारसामु कुनै तौल हुँदैन। नतिजा क्रम र शृंखलाको दायराले निर्धारण गर्छ, फाइलमा स्वीकृति हुनुले होइन।

ठ्याक्कै आन्तरिक सेवा प्रमाणित गर्नुहोस्

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

nftables सन्दर्भ ले meta ipsec, rt ipsec र दिशा-विशिष्ट अभिव्यक्तिहरू अभिलेख गर्छ, र तपाईंको स्थापित संस्करणसँग वाक्यरचना जाँच्ने ठाउँ त्यही हो। र दायरा स्पष्ट राख्नुहोस्: यो IPv4 उदाहरण हो, यसले IPv6 बारे केही भन्दैन, र यसले स्वेच्छाचारी सार्वजनिक पोर्ट अगाडि पठाउने कामलाई VPN सेवाको भाग बनाउँदैन।