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 सेवा का हिस्सा नहीं बनाता।