फायरवाल प्याकेज स्थापना भयो, रिबूटपछि नियम हराए

प्याकेज सफा रूपमा स्थापना भयो, नियमहरू परीक्षण गरिए, र अर्को रिबूटपछि गेटवे पूरै खुला थियो। कारोबारमा केही पनि असफल भएन; असफलता के रहन्छ भन्ने अनुमानमा थियो। फायरवाल उपकरण स्थापना गर्नु, कुन नियम रहनुपर्छ भन्ने निर्णय गर्नु र ठीक समयमा तिनलाई पुनर्स्थापित गर्नु तीनवटा अलग काम हुन्।

लक्षणले वास्तवमा के बताउँछ

रिबूटमा हराउने नियमसमूहको तीनमध्ये एक मालिक हुन्छ: कसैले पनि सुरक्षित गरेन, अरू केहीले प्रतिस्थापन गर्‍यो, वा त्यो निर्भर रहेको कुरा अस्तित्वमा आउनुअघि नै पुनर्स्थापित भयो। पहिला दुई कन्फिगरेसनमा देखिन्छन्; तेस्रो क्रममा मात्र देखिन्छ। त्यसैले रिबूट डेटा हानि जस्तो देखिन सक्छ, जब वास्तवमा यो क्रमको समस्या हो।

रिबूटअघि के सत्य थियो भनेर लेख्नबाट सुरु गर्नुहोस्: कुन सेवाले नियम राखेको थियो, सुरुमा कुन फाइल वा डेटाबेस पढ्यो, र त्यो स्रोतमा कहिल्यै लेखिएको थियो कि। कसैले नसुरक्षित गरेको सक्रिय नियमसमूह मान्य व्याख्या हो र सबैभन्दा सामान्य पनि।

प्याकेज पुनः स्थापना गरेर सुरु नगर्नुहोस्।

प्रयोग गर्नुअघि दिगोपन उपकरण पढ्नुहोस्

डेबियनका उपकरणहरूले दिगोपनलाई प्लगइन समस्या मान्छन्: हरेक प्लगइनलाई आफ्ना नियम कसरी लेख्ने थाहा हुन्छ, र एउटा र्‍यापरले तिनलाई बोलाउँछ। यसको सुरक्षित गर्ने क्रियाले त्यस क्षणमा लोड भएको सबै भण्डारण गर्छ, र सुरु गर्ने क्रियाले त्यो स्न्यापसट फिर्ता लोड गर्छ। दुवै क्रियामा के भण्डारण हुँदैछ भनेर समीक्षा गर्दैन।

त्यो स्न्यापसट हो, समीक्षा होइन। डिबगिङ सत्रबाट बाँकी अनुमति, अधुरो प्रयोग वा अर्को सहायकले हालिदिएको खुकुलो नियम सबै तपाईं राख्न चाहनुभएको नीतिसँगै स्थायी हुन्छन्। अवस्था सुरक्षित गर्नु र अवस्था स्वीकृत गर्नु फरक गतिविधि हुन्, र तीमध्ये एउटालाई मात्र निर्णय चाहिन्छ। पहिले लोड भएको समूह पढ्नुहोस्, त्यसपछि कुन हरफ रहन योग्य छन् भन्ने निर्णय गर्नुहोस्।

के लोड भएको छ पढेपछि जानाजान सुरक्षित गर्नुहोस्।

के रहनुपर्छ भन्ने निर्णय गर्नुहोस्

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

तीन क्षणका लागि अभिप्रेत नतिजा लेख्नुहोस्: बुट, VPN सक्रियता र टनेल हानि। त्यसपछि तपाईंले छान्नुभएको उपकरणले प्रत्येकलाई व्यक्त गर्न सक्छ कि जाँच्नुहोस्। स्थिर स्न्यापसट पुनः लोड गर्ने दिगोपन प्याकेजले पहिलो सम्हाल्छ र बाँकीमध्ये सायद कुनै पनि सम्हाल्दैन, किनकि स्न्यापसटलाई टनेलको अवस्था कहिले बदलियो भन्ने थाहा हुँदैन। यदि तिनलाई व्यक्त गर्न सक्दैन भने त्यो अन्तर अर्को घटकको हो।

उत्तर नीतिले निर्धारण गर्छ, प्याकेजले होइन।

पुनर्स्थापनाको क्रम जाँच्नुहोस्

फाइल पुनर्स्थापित गर्नु नतिजाको स्वामित्व हुनुसँग बराबर होइन। अर्को प्रबन्धकले नियम बदल्न सक्छ, अघिल्लो अनुमतिले तिनलाई छाया गर्न सक्छ, वा प्रतिबन्ध लागू हुनुअघि ग्राहकहरूले पठाउन थाल्न सक्छन्। सुरक्षित फाइलको उपस्थिति मात्र होइन, सुरु र पुनःजडानको व्यवहार समीक्षा गर्नुहोस्।

systemctl status netfilter-persistent
iptables -S

दिगोपन सेवा रोक्नु हानिरहित छ भनी नमान्नुहोस्, किनकि प्याकेजले रोकिँदा सशर्त फ्लसको दस्तावेज गर्छ। टाढाबाट व्यवस्थापन गर्ने गेटवेमा रोक्नु वा पुनः सुरु गर्नु प्रयोगका रूपमा प्रयोग गर्नुअघि सेवाको वास्तविक कन्फिगरेसन स्थापित गर्नुहोस्। त्यो परीक्षणअघि कन्सोल सत्र र दस्तावेजीकृत रोलब्याक न्यूनतम हुन्।

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

तीन अलग नतिजा स्वीकार्नुहोस्

प्याकेज स्थापना, लोड भएको नियमसमूह र लागू गरिएको नीति अलग तथ्यका रूपमा अभिलेख गर्नुहोस्। सहायता थ्रेडमा प्याकेजको नामले पहिलोको मात्र जवाफ दिन्छ, र त्यही कुरा विरलै महत्त्वपूर्ण हुन्छ।

nft list ruleset

त्यसपछि अनुमत कार्य र आवश्यक अस्वीकृतिको परीक्षण गर्नुहोस्।

यदि अस्वीकृति रिबूटपछि र टनेल खसेपछि टिक्छ भने नीति टिक्छ। यदि त्यो ती अवस्थामध्ये एउटामा मात्र टिक्छ भने तपाईंले सुधार्नुको सट्टा क्रमको समस्या भेट्टाउनुभएको छ।