फायरवाल नियम परिवर्तन काम गर्दैन: नियमहरूको क्रम र जडानको स्थिति

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

नियमहरूको क्रम र जडानको स्थिति फरक खराबी हुन्

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

जडान ट्र्याकिङले दोस्रो लक्षण उत्पन्न गर्छ, र बाहिरबाट त्यो ठ्याक्कै उस्तै देखिन्छ। प्रवाह स्थिति तालिकामा आएपछि, चेनको माथिल्लो भागनजिकको established-or-related अनुमति तपाईंको नयाँ नियमलाई विचार गर्नुअघि नै फर्कन्छ। NAT म्यापिङमा पनि त्यही गुण छ: प्रवाह सुरु हुँदा अनुवाद निश्चित भइसकेको थियो, त्यसैले सम्पादित postrouting नियमले पहिले नै चलिरहेको सत्र पुनःलेख्दैन। यसैकारण परिवर्तन 09:00 बजे नयाँ जडानका लागि काम गरेजस्तो देखिन्छ र 08:55 बजे कसैले खोलेको सत्रका लागि केही नगरेजस्तो देखिन्छ।

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

सक्रिय नियमसेट पढ्नुहोस्, तपाईंले सम्पादन गरेको फाइल होइन

कर्नेलले अहिले के लागू गरिरहेको छ त्यसबाट सुरु गर्नुहोस्। कहिल्यै लागू नगरिएको सुरक्षित कन्फिगरेसनले अचम्मलाग्दो धेरै अपरिवर्तित व्यवहार व्याख्या गर्छ, र त्यसलाई बाहिर राख्न एक आदेश मात्र लाग्छ:

nft list ruleset
iptables-save

त्यसपछि तपाईंको नियमसम्म पुगिन्छ कि भनी सोध्नुहोस्। प्याकेट काउन्टरहरूले सोझै जवाफ दिन्छन्, र मनसायबारेको कुनै पनि तर्कभन्दा राम्रो जवाफ दिन्छन्:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

वास्तविक परीक्षण प्रयासपछि शून्य प्याकेट भएको लकडाउन नियम नीतिको समस्या होइन, त्यो स्थानको समस्या हो। त्यसलाई सार्नु एक लाइनको परिवर्तन हो, र मूल बग निम्त्याउने कुरा ठ्याक्कै त्यही वाक्यरचना थियो। iptables मा -I सुरुमा घुसाउँछ र -A अन्त्यमा थप्छ; nftables मा insert नियमलाई चेनको सुरुमा राख्छ र add अन्त्यमा थप्छ। नियमले जित्नै पर्ने भए, संयोगवश लोड भएको क्रममा भरोसा गर्नुको सट्टा त्यो स्पष्ट भन्नुहोस्।

प्रवाह ट्र्याक भइरहेको छ कि छैन प्रमाणित गर्नुहोस्

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

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

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

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

केही मार्ग ट्र्याक हुँदैनन्, र ती उल्टो व्यवहार गर्छन्। raw तालिकामा notrack भनी चिन्ह लगाइएको ट्राफिक, सामान्य हुक छल्ने केही सुरुङ, र प्रवाहलाई दुई गेटवेबीच बाँड्ने असममित रुटिङ — सबैले एकएक गरी मूल्यांकन हुने प्याकेट वा दुवै छेउमा कहिल्यै नबन्ने स्थिति उत्पन्न गर्छन्। हरेक प्याकेटमा काउन्टर सर्छ भने, क्रममाथि शंका गर्नुअघि त्यस्तो मार्गमाथि शंका गर्नुहोस्।

फर्कने बाटोसहित नयाँ प्रवाहबाट परीक्षण गर्नुहोस्

टाढाको पहुँच काट्न सक्ने नियम परीक्षण गर्नुअघि पुनःप्राप्तिको बाटो बनाउनुहोस्: प्रदायकको कन्सोल, सिरियल कन्सोल, ब्यान्डबाहिरको व्यवस्थापन ठेगाना, वा नियमले मिल्न नसक्ने दोस्रो इन्टरफेस। रोलब्याक टाइमर उपयुक्त साथी हो, किनभने परीक्षणको बीचमा तपाईंको सत्र मरे पनि यसले अघिल्लो नियमसेट पुनर्स्थापित गर्छ।

त्यसपछि स्थितिले पहिले नै ढाक्न नसक्ने आदानप्रदानले परीक्षण गर्नुहोस्। क्लाइन्ट विच्छेद गरी फेरि जोड्नुहोस् ताकि नयाँ पाँचौं बनोस्, र त्यो हुँदा दुवै छेउ हेर्नुहोस्:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

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

नियमसँगै उद्देश्य र स्थान अभिलेख गर्नुहोस्

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

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