VPN के लिए UFW अपवाद जब एंडपॉइंट का पता बदलता है

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

टनल फिर जुड़ती है, फिर कुछ बाहर नहीं जाता

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

सार्वजनिक खोज जो पता लौटाती है उसे पिन कर देना आज काम कराता है और कल को टूटा छोड़ देता है। वह एकबारगी संपादन है, रखरखाव की नीति नहीं।

उस अपवाद का वर्णन करें जो आप वास्तव में चाहते हैं

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

नीचे दिया गया कमांड वायर्ड अपलिंक पर एक IPv4 UDP एंडपॉइंट का रूप दिखाता है। दोनों मानों को उनसे बदलें जिन्हें आपने परिनियोजन के विरुद्ध सत्यापित किया है।

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

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

इसे एक वर्कफ़्लो के रूप में ताज़ा करें

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

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

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

अंत में पुरानी अनुमति को जानबूझकर हटाएँ, स्वीकृत ओवरलैप विंडो की अनुमति देते हुए जब तक पुराना सत्र सक्रिय है। पुरानी प्रविष्टि को बहुत जल्दी हटाना संक्षिप्त बंदी देता है; उसे हमेशा के लिए छोड़ देना ऐसी अनुमति छोड़ देता है जिसे कोई समझा नहीं सकता।

पुरानी अनुमति को जानबूझकर हटाएँ

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

पूरी समीक्षा दोहराएँ जब अपलिंक Ethernet से Wi-Fi पर बदले, जब ट्रांसपोर्ट बदले, या जब कोई सेवा कई पतों पर घूमे। इंटरफ़ेस-विशिष्ट नियम को नेटवर्क बदलने के बाद मेल खाना बंद करना चाहिए, और वह व्यवहार सही है भले ही वह गिरावट जैसा लगे।

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