फायरवॉल पॅकेज इन्स्टॉल झाले, रीबूटनंतर नियम गायब

पॅकेज स्वच्छ इन्स्टॉल झाले, नियमांची चाचणी झाली, आणि पुढील रीबूटनंतर गेटवे पूर्णपणे उघडे होते. व्यवहारात काहीही अयशस्वी झाले नाही; अपयश हे काय टिकेल या गृहीतकात होते. फायरवॉल साधने इन्स्टॉल करणे, कोणते नियम टिकले पाहिजेत हे ठरवणे आणि योग्य क्षणी ते पुनर्संचयित करणे या तीन वेगळ्या कामी आहेत.

लक्षण प्रत्यक्षात काय सांगते

रीबूटवर गायब होणाऱ्या नियमसंचाचा तीनपैकी एक मालक असतो: कोणीही तो साठवला नाही, दुसऱ्या एखाद्या गोष्टीने तो बदलला, किंवा ज्यावर तो अवलंबून आहे ते अस्तित्वात येण्यापूर्वी तो पुनर्संचयित झाला. पहिले दोन कॉन्फिगरेशनमध्ये दिसतात; तिसरा केवळ क्रमात दिसतो. म्हणूनच रीबूट डेटा हानीसारखा वाटू शकतो, जेव्हा प्रत्यक्षात तो क्रमाचा प्रश्न असतो.

रीबूटपूर्वी काय खरे होते ते लिहून सुरुवात करा: कोणती सेवा नियम ठेवत होती, सुरुवातीला तिने कोणती फाइल किंवा डेटाबेस वाचला, आणि त्या स्रोतात कधी लिहिले गेले होते का. कोणीही न साठवलेला सक्रिय नियमसंच हे वैध स्पष्टीकरण आहे आणि सर्वात सामान्यही.

पॅकेज पुन्हा इन्स्टॉल करून सुरुवात करू नका.

वापरण्यापूर्वी टिकाऊपणा साधन वाचा

डेबियनची साधने टिकाऊपणाकडे प्लगइन समस्या म्हणून पाहतात: प्रत्येक प्लगइनला स्वतःचे नियम कसे लिहायचे हे माहीत असते, आणि एक रॅपर त्यांना बोलावतो. त्याची साठवण्याची क्रिया त्या क्षणी लोड असलेले सर्व संग्रहित करते, आणि त्याची सुरुवातीची क्रिया तो स्नॅपशॉट परत लोड करते. दोन्ही क्रियांमध्ये काय संग्रहित होत आहे याचे पुनरावलोकन होत नाही.

ती स्नॅपशॉट आहे, पुनरावलोकन नाही. डीबगिंग सत्रातून उरलेली परवानगी, अपूर्ण प्रयोग किंवा दुसऱ्या सहाय्यकाने घातलेला सैल नियम हे सर्व तुम्हाला ठेवायचे होते त्या धोरणासोबत कायमचे होतात. स्थिती साठवणे आणि स्थिती मंजूर करणे या वेगळ्या क्रिया आहेत, आणि त्यातील एकालाच निर्णय लागतो. आधी लोड झालेला संच वाचा, मग कोणत्या ओळी टिकण्यास पात्र आहेत ते ठरवा.

काय लोड आहे ते वाचल्यानंतर जाणीवपूर्वक साठवा.

काय टिकले पाहिजे ते ठरवा

काही नियम इंटरफेसच्या जीवनचक्राचे असतात आणि त्यासोबतच गायब व्हायला हवेत. इतरांना टनेलपेक्षा जास्त काळ टिकावे लागते, आणि सर्वात स्पष्ट उदाहरण म्हणजे टनेल पडल्यावर क्लायंट रहदारीला भौतिक इंटरफेसवर परत जाण्यास प्रतिबंध करणारे बंधन. या दोन श्रेणींना वेगळे पुनर्संचयन ट्रिगर हवेत, एक सामायिक स्नॅपशॉट नाही.

तीन क्षणांसाठी इच्छित निकाल लिहा: बूट, VPN सक्रियकरण आणि टनेल हानी. नंतर तुम्ही निवडलेले साधन प्रत्येकाला व्यक्त करू शकते का ते तपासा. स्थिर स्नॅपशॉट पुन्हा लोड करणारे टिकाऊपणा पॅकेज पहिल्याला हाताळते आणि बाकीच्यांपैकी कदाचित एकालाही नाही, कारण स्नॅपशॉटला टनेलची स्थिती कधी बदलली हे माहीत नसते. जर ते त्यांना व्यक्त करू शकत नसेल, तर ती तूट दुसऱ्या घटकाची आहे.

उत्तर धोरण ठरवते, पॅकेज नाही.

पुनर्संचयितीचा क्रम तपासा

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

systemctl status netfilter-persistent
iptables -S

टिकाऊपणा सेवा थांबवणे हानिरहित आहे असे गृहीत धरू नका, कारण पॅकेज थांबल्यावर सशर्त फ्लशची नोंद करते. दूरून व्यवस्थापित गेटवेवर थांबवणे किंवा पुन्हा सुरू करणे प्रयोग म्हणून वापरण्यापूर्वी सेवेचे प्रत्यक्ष कॉन्फिगरेशन स्थापित करा. त्या चाचणीपूर्वी कन्सोल सत्र आणि नोंदवलेला रोलबॅक हे किमान आहेत.

क्रम हा चालू असलेल्या प्रणालीचा गुणधर्म आहे, डिस्कवरील फाइलचा नाही.

तीन वेगळे निकाल स्वीकारा

पॅकेज इन्स्टॉलेशन, लोड झालेला नियमसंच आणि लागू केलेले धोरण हे वेगळे तथ्य म्हणून नोंदवा. सहाय्यता थ्रेडमधील पॅकेजचे नाव केवळ पहिल्याला उत्तर देते, आणि तेच क्वचित महत्त्वाचे असते.

nft list ruleset

नंतर अनुमत क्रिया आणि आवश्यक नकाराची चाचणी करा.

जर नकार रीबूटनंतर आणि टनेल पडल्यानंतर टिकला, तर धोरण टिकते. जर तो त्यातील केवळ एका स्थितीत टिकला, तर तुम्ही दुरुस्त करण्याऐवजी क्रमाचा प्रश्न शोधला आहे.