नयाँ UFW नियम, पुरानो जडान: स्थापित अवस्था जित्छ

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

नियमको अस्तित्व होइन, क्रमले निर्णय गर्छ

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

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

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

फराकिलो अनुमतिमाथि घुसाउनुहोस्

लागू गर्नुअघि घुसाउने कुराको पूर्वावलोकन गर्नुहोस् र नियम सूचीमा अन्यत्र पहिले नै नभएको पुष्टि गर्नुहोस्। एउटै नीतिको नक्कल गर्दा पछिको हटाउने काम अस्पष्ट हुन्छ, र गलत प्रतिलिपि हटाउने व्यक्तिलाई हप्तौंसम्म थाहा हुँदैन।

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

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

त्यो नियममा कुनै गन्तव्य पोर्ट छैन, त्यसैले यसले त्यो ठेगानामा HTTPS मात्र होइन, हरेक TCP पोर्ट अस्वीकार गर्छ। यदि उद्देश्य एउटै सेवा हो भने पोर्टको नाम दिनुहोस्; नीतिभन्दा फराकिलो नियम पहिलो पाठक पर्खिरहेको भविष्यको घटना हो।

स्रोतलाई एउटै ठेगानामा सीमित गर्नुहोस्, त्यो ठेगाना इच्छित पहिचानसँग बाँधिएको छ भने मात्र। गतिशील बाँडफाँट भएको VPN पूलले भोलि त्यही ठेगाना अर्को ग्राहकलाई दिन सक्छ, र अस्वीकृतिले व्यक्तिको होइन, ठेगानाको पछि लाग्छ।

स्थापित प्रवाहहरू नयाँ नियमबाट जोगिन्छन्

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

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

सीमाहरू पनि सम्झनुहोस्। यो नियमले ICMP, UDP वा IPv6 बारे केही भन्दैन, त्यसैले सफल ping अस्वीकृति असफल भएको प्रमाण होइन। एउटा IPv4 ठेगाना पनि वेबसाइट होइन: नाम धेरै ठेगानामा समाधान हुन सक्छ, र तपाईंले नाम दिएको एउटा मात्र समेटिन्छ।

नयाँ प्रवाहसँग परीक्षण गर्नुहोस्

क्रमाङ्कित प्रयोगकर्ता नियमहरू र प्रभावकारी कच्चा दृश्य पढ्नुहोस्, त्यसपछि छानिएको ग्राहकबाट नयाँ जडान खोल्नुहोस्:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

कच्चा दृश्य महत्त्वपूर्ण छ किनकि status ले हातले लेखिएका फ्रेमवर्क नियमहरू छोड्छ, त्यसैले क्रम कर्नेलले लागू गर्नेभन्दा फरक देखिन सक्छ। नियम गलत ठाउँमा छ भन्ने निष्कर्षमा पुग्नुअघि दुवैको तुलना गर्नुहोस्।

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

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