VPN इंटरफेस येत असताना nftables धोरण स्थिर ठेवा

टनेल क्षणिक असतात; धोरण तसे नसावे। Linux गेटवेवर टनेल इंटरफेसला नावाने जुळणारा nftables नियम एकदा लोड करता येतो आणि तो इंटरफेस येईल तेव्हा तो लागू राहतो। इंटरफेसचे तरीही जीवनचक्र असते: तो तयार होतो, जातो, आणि त्याच्या आसपासचे मार्ग व अनुवाद स्वतःचे वेळापत्रक पाळतात। हे मालक वेगळे करणेच पुन्हा जोडणीच्या वेळी प्रवेश स्थिर ठेवते।

नावाची जुळणी इंटरफेसपेक्षा जास्त टिकते

nftables संख्यात्मक इंटरफेस-निर्देशांक जुळणी आणि गतिशील नाव-जुळणी iifname व oifname देते। ही नावे वापरणारे नियम टनेल उपकरण अजून तयार नसतानाही स्वच्छ लोड होतात, जे बूटच्या वेळी नियमसंचाला नेमके हवे असते। इंटरफेसचे नाव बदलल्यास जुळणी थांबते आणि नवा इंटरफेस ते नाव घेतल्यास पुन्हा सुरू होते। संख्यात्मक निर्देशांकात तो गुण नाही, म्हणून टनेलसाठी नावाचा प्रकार नेहमीचा पर्याय आहे।

नाव ही जुळणीची किल्ली आहे, दुसऱ्या टोकाला कोण आहे याचा पुरावा नाही। साथीदाराची ओळखपडताळणी VPN चे कामच राहते।

नियम जोडण्यापूर्वी साखळी वाचा

नियमसंचात आता काय आहे आणि नवा नियम कुठे बसेल ते पाहा, कारण क्रमवारीच निकाल ठरवते।

nft list ruleset
nft -c -f /etc/nftables.conf

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

मार्ग, अनुवाद आणि प्रवाहांचे दुसरे मालक आहेत

इंटरफेसची उपस्थिती कोणतेही मार्ग तयार करत नाही आणि साथीदाराची पडताळणी करत नाही। ते VPN व्यवस्थापकाचे आहेत, तर अनुवादाचे तिसरे जीवनचक्र आहे।

conntrack -L -s 10.20.0.0/24 | head
ip route show dev vpn0

conntrack यादी विद्यमान प्रवाह त्यांच्या मूळ व अनुवादित मूल्यांसह दाखवते, आणि मार्ग यादी व्यवस्थापकाने इंटरफेससाठी काय स्थापित केले ते दाखवते। NAT नियम पहिल्या पॅकेटवरच जोडणी-मागोवा स्थिती तयार करतात, म्हणून प्रस्थापित प्रवाह नियम बदलल्यानंतरही आपला अनुवाद राखतो। म्हणून नियम अद्ययावत होणे आणि नवा मार्ग वापरणारा प्रवाह ही दोन वेगळी विधाने आहेत। कोणती सत्रे पुन्हा जोडायची ते ठरवा आणि असंबंधित प्रवाहांना सोडून द्या।

थंड सुरुवात, हानी आणि पुनर्प्राप्ती स्वीकारा

बूटच्या वेळी टनेल अनुपस्थित, नंतर उपस्थित, आणि नंतर खंड व परतीनंतर गेटवे तपासा। टनेल नसताना प्रतिबंधित फॉरवर्डिंग प्रतिबंधितच राहते, साथीदाराची पडताळणी झाल्यावर नवीन अनुमत प्रवाह चालतो, आणि पुनर्प्राप्तीसाठी असंबंधित स्थिती रिकामी करण्याची गरज नसते याची खात्री करा। एका प्रोफाइलची थांबवण्याची क्रिया म्हणून संपूर्ण POSTROUTING साखळी किंवा प्रत्येक conntrack नोंद पुसू नका, कारण इतर सेवा त्या सामायिक करतात। स्टार्ट हुक शून्यासह बाहेर पडला एवढेच नव्हे, तर कोणत्या घटकाने इंटरफेस, मार्ग व धोरण बदलले ते नोंदवा।

पुन्हा जोडणीत टिकणारे धोरण म्हणजे ज्याचे मालक नामनिर्देशित आहेत आणि ज्याचे नियम टनेल बंद व चालू दोन्ही स्थितीत तपासले गेले आहेत। यशाचा अहवाल देणारा हुक फक्त हुक चालला हेच सिद्ध करतो।