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 मा बदलिँदा, ट्रान्सपोर्ट बदलिँदा, वा सेवा धेरै ठेगानामा घुम्दा पूरै समीक्षा दोहोर्याउनुहोस्। इन्टरफेस-विशेष नियमले सञ्जाल बदलिएपछि मिल्न छोड्नुपर्छ, र त्यो व्यवहार सही छ यद्यपि यो गिरावटजस्तो देखिन्छ।

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