फ़ायरवॉल पैकेज स्थापित, रीबूट के बाद नियम ग़ायब

पैकेज साफ़ स्थापित हुआ, नियमों का परीक्षण हुआ, और अगली रीबूट के बाद गेटवे पूरी तरह खुला था। लेन-देन में कुछ विफल नहीं हुआ; विफलता इस धारणा में थी कि क्या टिकेगा। फ़ायरवॉल उपकरण स्थापित करना, तय करना कि कौन से नियम बचें और उन्हें सही क्षण पर बहाल करना तीन अलग काम हैं।

लक्षण वास्तव में आपको क्या बताता है

रीबूट पर ग़ायब होने वाले नियम-समुच्चय का तीन में से एक स्वामी होता है: किसी ने उसे सहेजा नहीं, किसी और चीज़ ने उसे बदल दिया, या उसे उस चीज़ के होने से पहले बहाल कर दिया गया जिस पर वह निर्भर है। पहले दो कॉन्फ़िगरेशन में दिखते हैं; तीसरा केवल क्रम में दिखता है। इसीलिए रीबूट डेटा-हानि जैसा लग सकता है, जबकि वास्तव में यह क्रम की समस्या है।

शुरू में लिखें कि रीबूट से पहले क्या सच था: कौन सी सेवा नियम रखती थी, वह शुरुआत में कौन सी फ़ाइल या डेटाबेस पढ़ती थी, और क्या उस स्रोत में कभी लिखा गया था। कोई न सहेजा गया सक्रिय नियम-समुच्चय वैध व्याख्या है और सबसे सामान्य भी।

पैकेज को फिर से स्थापित करके शुरू न करें।

उपयोग से पहले दृढ़ता उपकरण पढ़ें

डेबियन के उपकरण दृढ़ता को प्लगइन समस्या मानते हैं: हर प्लगइन जानता है कि अपने नियम कैसे लिखें, और एक रैपर उन्हें बुलाता है। उसकी सहेजने की क्रिया उस क्षण जो लोड है उसे संग्रहीत करती है, और उसकी आरंभ क्रिया उस स्नैपशॉट को वापस लोड करती है। दोनों में से कोई भी क्रिया यह नहीं देखती कि क्या संग्रहीत कर रही है।

वह स्नैपशॉट है, समीक्षा नहीं। डिबगिंग सत्र से बची अनुमति, अधूरा प्रयोग या किसी अन्य सहायक द्वारा डाला गया ढीला नियम, सब उस नीति के साथ स्थायी हो जाते हैं जिसे आप रखना चाहते थे। स्थिति सहेजना और स्थिति को स्वीकृति देना अलग गतिविधियाँ हैं, और उनमें से केवल एक को निर्णय चाहिए। पहले लोड किया गया समुच्चय पढ़ें, फिर तय करें कौन सी पंक्तियाँ बचने योग्य हैं।

जो लोड है उसे पढ़ने के बाद सोच-समझकर सहेजें।

तय करें कि क्या बचना चाहिए

कुछ नियम किसी इंटरफ़ेस के जीवनचक्र के हैं और उसके साथ ग़ायब होने चाहिए। अन्य को टनल से अधिक जीना है, और सबसे स्पष्ट उदाहरण वह प्रतिबंध है जो क्लाइंट ट्रैफ़िक को भौतिक इंटरफ़ेस पर वापस गिरने से रोकता है, जब टनल गिरती है। इन दो श्रेणियों को अलग पुनर्स्थापन ट्रिगर चाहिए, एक साझा स्नैपशॉट नहीं।

तीन क्षणों के लिए इच्छित परिणाम लिखें: बूट, VPN सक्रियण और टनल हानि। फिर जाँचें कि आपके चुने उपकरण में हर एक को व्यक्त करने की क्षमता है या नहीं। स्थिर स्नैपशॉट को फिर से लोड करने वाला दृढ़ता पैकेज पहले को संभालता है और शायद बाकी में से किसी को नहीं, क्योंकि स्नैपशॉट को पता ही नहीं कि टनल की स्थिति कब बदली। यदि वह उन्हें व्यक्त नहीं कर सकता, तो यह अंतर किसी अन्य घटक का है।

उत्तर नीति तय करती है, पैकेज नहीं।

पुनर्स्थापन का क्रम जाँचें

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

systemctl status netfilter-persistent
iptables -S

यह न मानें कि दृढ़ता सेवा को रोकना हानिरहित है, क्योंकि पैकेज रुकने पर सशर्त फ़्लश का दस्तावेज़ देता है। दूर से प्रबंधित गेटवे पर रोकना या पुनः आरंभ करना प्रयोग के रूप में उपयोग करने से पहले सेवा का वास्तविक कॉन्फ़िगरेशन स्थापित करें। उस परीक्षण से पहले कंसोल सत्र और प्रलेखित रोलबैक न्यूनतम हैं।

क्रम चल रहे सिस्टम का गुण है, डिस्क पर पड़ी फ़ाइल का नहीं।

तीन अलग परिणाम स्वीकारें

पैकेज स्थापना, लोड किया गया नियम-समुच्चय और लागू की गई नीति को अलग तथ्यों के रूप में दर्ज करें। सहायता थ्रेड में पैकेज का नाम केवल पहले का उत्तर देता है, और वही है जो शायद ही कभी मायने रखता है।

nft list ruleset

फिर एक अनुमत क्रिया और एक आवश्यक अस्वीकृति का परीक्षण करें।

यदि अस्वीकृति रीबूट के बाद और टनल गिरने के बाद टिकी रहती है, तो नीति बची रहती है। यदि वह इन स्थितियों में से केवल एक में टिकती है, तो आपने इसे ठीक करने के बजाय क्रम की समस्या खोज ली है।