खुद को बाहर लॉक किए बिना फ़ायरवॉल बदलावों की जाँच करना

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

क्यों बचा हुआ सत्र सबसे कमज़ोर सबूत है

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

कार्यशील सत्र को माप नहीं, बल्कि आपातकालीन निकास मानें। हर सार्थक जाँच को ऐसे स्रोत से नया फ़्लो खोलना चाहिए जिसका मूल्यांकन नया नियम करेगा, और पहली जाँच वही होनी चाहिए जिसका विफल होना सबसे ज़्यादा चुभे। जब वही सत्र अंदर जाने का एकमात्र रास्ता हो, तो बदलाव अभी करने के लिए तैयार नहीं है।

वापसी के तीन रास्ते, हर एक किस पर निर्भर है उसके अनुसार क्रमबद्ध

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

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

एक बदलाव, फिर एक कनेक्शन जिसका मूल्यांकन होना ही है

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

nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf

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

काउंटर, स्थिति और फ़ाइल अलग-अलग सवालों के जवाब देते हैं

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

ss -tn state established

काउंटरों को योग नहीं, अंतर की तरह पढ़ें, क्योंकि मायने रखने वाली एकमात्र संख्या वही है जिसे आपके परीक्षण फ़्लो ने हिलाया। जिस नियम का काउंटर कभी नहीं बढ़ता वह मेल नहीं खाता, काग़ज़ पर कितना भी सही दिखे। अस्वीकृति का मामला भी पुष्टि करें: जिस नीति ने कभी कुछ अस्वीकार नहीं किया उसने कभी साबित नहीं किया कि वह वह अस्वीकार करती है जिसे आप रोकना चाहते थे। जिन परिवारों को तैनाती वास्तव में ढोती है, उनमें से हर एक में एक इंटरफ़ेस पर काम करें, क्योंकि v4 नियम v6 फ़्लो के बारे में कुछ नहीं कहता।

सहेजे गए नियम-समुच्चय से बहाल करें, फिर फ़ाइल को मेल में लाएँ

जब बदलाव विफल हो, तो लॉगिन फिर से काम करने तक अनुमति देने वाले नियम जोड़ने के बजाय सहेजा गया नियम-समुच्चय लोड करें। हर अतिरिक्त अनुमति लक्षण को शांत करती है और ऐसा छेद छोड़ती है जो घटना और उसकी स्मृति से ज़्यादा जीवित रहता है। बहाल करें, फिर से जुड़ें, और फिर विफल तुलना को अपने प्रयास के रिकॉर्ड के साथ रखें।

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