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 सेवेचा भाग करत नाही।