आफूलाई बाहिर नताल्चालेर फायरवाल परिवर्तनको परीक्षण गर्ने
नियम लागू गर्नु अघि तपाईंका पुनर्प्राप्ति मार्गहरू क्रममा राख्नुहोस्, त्यसपछि बाँचेको सत्र होइन, नयाँ नीतिले मूल्याङ्कन गर्नुपर्ने प्रवाहबाट प्रमाणित गर्नुहोस्।
नियम लागू हुन्छ, तपाईंसँग पहिलेदेखि भएको टर्मिनल जवाफ दिइरहन्छ, र अर्को लगइन अस्वीकार गरिन्छ। तपाईंले परिवर्तन गरिरहेको जडानमा फायरवाल परिवर्तनको परीक्षण गर्ने सारा कठिनाई यही खाडल हो। जडान ट्र्याकिङले एकचोटि निर्णय गर्छ र त्यसपछि हेर्न छोड्छ, त्यसैले स्थापित प्रवाह नयाँ नीति देख्न नसक्ने एक मात्र जाँच हो। अब परतिने तीन मार्गको तुलना गरिन्छ, त्यसपछि नियम कुन क्रममा बदल्ने र जाँच्ने भनी निर्धारण गरिन्छ।
बाँचेको सत्र किन सबैभन्दा कमजोर प्रमाण हो
अवस्था भएको फायरवालले प्रवाहको पहिलो प्याकेट मूल्याङ्कन गर्छ र प्रविष्टि जीवित रहेसम्म त्यही फैसला राख्छ। पछि थपिएका नियमहरू पछि सुरु हुने प्रवाहहरूमा लागू हुन्छन्, त्यसैले तपाईं टाइप गरिरहेको विन्डो प्रयोगयोग्य रहन्छ, जबकि अरू सबै अस्वीकार गरिन्छन्। त्यसबाट तपाईंले सिक्ने कुराले केही मिनेट अघि लागू रहेको नीतिको वर्णन गर्छ। त्यही प्रवाहमा लिइएको क्याप्चरले पनि मेसिनले पहिले नै लिएको निर्णय देखाउँछ।
कार्यरत सत्रलाई मापन नभई आपत्कालीन निकास मान्नुहोस्। प्रत्येक अर्थपूर्ण जाँचले नयाँ नियमले मूल्याङ्कन गर्ने स्रोतबाट नयाँ प्रवाह खोल्नुपर्छ, र पहिलो जाँच त्यही हुनुपर्छ जसको असफलता सबैभन्दा बढी दुखाइ दिन्छ। जब त्यही सत्र भित्र पस्ने एक मात्र बाटो हो, परिवर्तन गर्न तयार छैन।
परतिने तीन मार्ग, प्रत्येक केमा निर्भर छ त्यसैअनुसार क्रमबद्ध
परीक्षणमा रहेको यन्त्रमा कति निर्भर छन् भन्ने आधारमा विकल्पहरू क्रमबद्ध गर्नुहोस्, किनकि नियम गलत सावित भएपछि तपाईं त्यही क्रम समात्नुहुन्छ। फायरवालबाट कहिल्यै नगइने कन्सोल स्वतन्त्र छ, अभ्यास गरिएको रोलब्याक लगभग त्यस्तै छ, र पहिलेदेखि खुला सत्र त्यस्तो छैन।
| Way back in | What it survives | Where it fails |
|---|---|---|
| out-of-band or hypervisor console | a policy that blocks new logins | needs separate access you have already tried |
| rollback rehearsed on that platform | a rule that breaks remote access | fails when nobody ever ran it |
| the session that is already open | the change itself | cannot show whether new flows work |
परिवर्तन अघि कन्सोलबाट लगइन गर्नुहोस् र त्यो काम गर्छ भनी प्रमाणित गर्नुहोस्, किनकि कहिल्यै नप्रयोग गरेको आउट-अफ-ब्यान्ड मार्ग रेखाचित्र हो, विकल्प होइन। रोलब्याकले आफ्नो स्थान त्यही प्लेटफर्ममा, त्यही नियमसेटसँग, स्वीकृत प्रक्रिया पालना गरी गरिएको अभ्यासपछि मात्र पाउँछ, जीवित मेसिनमा तत्काल उपाय गर्नुको सट्टा। चरणहरू लेख्नुहोस् र अरू कसैलाई पढेर सुनाउन लगाउनुहोस्। यदि क्रम पूरा गर्न तपाईंको सम्झना चाहिन्छ भने त्यो योजना होइन।
एउटा परिवर्तन, त्यसपछि मूल्याङ्कन गर्नुपर्ने जडान
चालु नियमसेट र त्यसको मालिक फाइल सुरक्षित गर्नुहोस्, त्यसपछि एउटै साँघुरो सम्पादन गर्नुहोस्। प्रति परीक्षण एक परिवर्तनले नतिजा आरोपणयोग्य राख्छ; एकैचोटि दुई गरे कुन सम्पादनले काम गर्यो भन्ने कल्पना पनि रहँदैन। जहाँ प्लेटफर्मले कन्फिगरेसन नलोड गरी विश्लेषण गर्न सक्छ, त्यहाँ पहिले त्यही गर्नुहोस्, ताकि टाइपिङ त्रुटि केही पनि जोखिममा नहुँदा पक्रियोस्।
nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf
त्यसपछि कन्सोल अझै जोडिएको अवस्थामा, परिवर्तित नियमसँग मिल्ने स्रोतबाट नयाँ सत्र सुरु गर्नुहोस्। सफल भए एकचोटि दोहोर्याउनुहोस्, किनकि पहिलो प्रयास तालिकामा पहिलेदेखि भएको प्रविष्टिमा पर्न सक्छ। असफल भए भित्र पस्ने बाटो र फिर्ता लिने निर्णय दुवै बाँकी रहन्छ, र त्यही उपलब्ध सबैभन्दा सस्तो नराम्रो नतिजा हो।
काउन्टर, अवस्था र फाइल फरक प्रश्नको उत्तर दिन्छन्
तीन अवलोकनमध्ये प्रत्येक एक्लै विश्वसनीय देखिन सक्छ र बाँकी दुईबारे तपाईंलाई भ्रममा पार्न सक्छ। काउन्टरले भर्खरै बनाएको प्रवाहले सम्पादित नियमसम्म पुग्यो कि पुगेन देखाउँछ। अवस्था तालिकाले मेसिनले कुन प्रवाहलाई पहिलेदेखि स्थापित मान्छ देखाउँछ, र यसरी बिग्रिएको नियम पनि स्वस्थ देखिन सक्छ। सुरक्षित फाइलले अर्को रिलोडपछि यन्त्रले के गर्नेछ देखाउँछ, र त्यो अहिले चलिरहेको नियमसेटले गरिरहेको कुराभन्दा फरक हुन सक्छ।
ss -tn state established
काउन्टरलाई जोड नभई डेल्टाका रूपमा पढ्नुहोस्, किनकि महत्त्वपूर्ण एक मात्र संख्या तपाईंको परीक्षण प्रवाहले सारेको हो। जसको काउन्टर कहिल्यै नबढ्ने नियम मिल्दैन, कागजमा जति सही देखिए पनि। अस्वीकृतिको अवस्था पनि पुष्टि गर्नुहोस्: कहिल्यै केही अस्वीकार नगरेको नीतिले तपाईंले रोक्न खोजेको कुरा अस्वीकार गर्छ भनी कहिल्यै प्रमाणित गरेको छैन। तैनातीले वास्तवमै बोक्ने प्रत्येक परिवारमा एउटा इन्टरफेसबाट जानुहोस्, किनकि v4 नियमले v6 प्रवाहबारे केही भन्दैन।
सुरक्षित नियमसेटबाट पुनर्स्थापित गर्नुहोस्, त्यसपछि फाइल मिलाउनुहोस्
परिवर्तन असफल भए, लगइन फेरि काम नगरेसम्म अनुमति दिने नियम थप्नुको सट्टा सुरक्षित नियमसेट लोड गर्नुहोस्। प्रत्येक थप अनुमतिले लक्षण शान्त पार्छ र घटना र त्यसको सम्झनाभन्दा लामो बाँच्ने प्वाल छोड्छ। पुनर्स्थापित गर्नुहोस्, फेरि जोडिनुहोस्, त्यसपछि असफल तुलनालाई तपाईंले के प्रयास गर्नुभयो भन्ने अभिलेखको छेउमा राख्नुहोस्।
सफल परिवर्तनपछि, डिस्कमा रहेको फाइलले चलिरहेको नियमसेटको वर्णन गरोस्, र रिलोडले त्यसलाई पुनरुत्पादन गर्छ भनी पुष्टि गर्नुहोस्। आफ्नै कन्फिगरेसन फाइलबाट टाढा गएको जीवित नियमसेट अर्को रिबुटका लागि राखिएको जाल हो।