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 वर गेल्यावर, ट्रान्सपोर्ट बदलल्यावर किंवा सेवा अनेक पत्त्यांवर फिरल्यावर संपूर्ण आढावा पुन्हा करा। इंटरफेस-विशिष्ट नियमाने नेटवर्क बदलल्यानंतर जुळणे थांबवावे, आणि ते वर्तन बरोबर आहे जरी ते घसरणीसारखे दिसत असले तरी।

मग करार हानीकारक नसलेल्या रहदारीने सिद्ध करा। मंजूर एंडपॉइंट सेटअपच्या वेळी पोहोचण्यायोग्य असावा, संरक्षित अ‍ॅप्लिकेशन कनेक्ट झाल्यावर चालले पाहिजे, आणि असंबंधित थेट रहदारी बंदीच्या काळात अडवलेली राहिली पाहिजे। दोन्ही पत्ता कुटुंबे आणि एक जाणूनबुजून अपयशी अद्ययावत प्रयत्न समाविष्ट करा, कारण पिन केलेल्या पत्त्याच्या एका बदलानंतर यशस्वी होणारे कनेक्शन यापैकी कोणतीही स्थिती सिद्ध करत नाही।