VPN एंडपॉइंट के लिए अनुमति सूची: वह DNS रीफ़्रेश जिसे आप भूल गए

फ़ायरवॉल अपवाद में vpn.example.com टाइप करना DNS की सदस्यता लेने जैसा लगता है। आम तौर पर जो होता है वह लोड समय पर अनुवाद है, जिसके बाद नियम पते रखता है और कोई उन्हें रीफ़्रेश नहीं करता। अब दो घटक काम साझा करते हैं: उत्तर देने वाला रिज़ॉल्वर और संग्रह करने वाला फ़ायरवॉल। अधिकांश एंडपॉइंट व्यवधान वहीं शुरू होते हैं जहाँ वह हस्तांतरण कभी डिज़ाइन नहीं किया गया था।

नियम में होस्टनाम कोई जीवंत सदस्यता नहीं है

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

सही होस्ट का नाम देने वाला नियम भी गलत पते की अनुमति दे सकता है। वह अंतर मिथक है, वर्तनी की गलती नहीं।

कैश TTL आपके फ़ायरवॉल का टाइमर नहीं है

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

वास्तविक उत्पाद से तीन प्रश्न पूछें: यह कब हल करता है, परिणाम कहाँ संग्रह करता है, और क्या अपडेट ट्रिगर करता है। यदि उत्तर केवल बूट पर है, तो लंबे समय तक चलने वाला सत्र उस पते से अधिक जी सकता है जिस पर उसे प्रवेश दिया गया था।

dig +short vpn.example.com
resolvectl query vpn.example.com

रीफ़्रेश और विफलता को एक नीति के रूप में डिज़ाइन करें

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

विफलता व्यवहार सोच-समझकर चुनें। पुराना पता रखना सत्र बचा सकता है और पुरानी अनुमति छोड़ सकता है; सेट साफ़ करना रिकवरी को अटका सकता है। इनमें से कोई भी विफल लुकअप का आकस्मिक परिणाम नहीं होना चाहिए। चुना गया व्यवहार रनबुक में लिखें ताकि अगला ऑपरेटर दबाव में अनुमान न लगाए।

बूटस्ट्रैप DNS को भी संकीर्ण रखें। सार्वजनिक रिज़ॉल्वर के लिए बिना शर्त अपवाद जो भी मेल खाता है उसके लिए सीधा DNS मार्ग है, केवल एंडपॉइंट के नाम के लिए नहीं।

एंडपॉइंट परिवर्तन सिद्ध करें, पहला कनेक्शन नहीं

क्लाइंट के समर्थित प्रबंधक का उपयोग करें यदि वह पहले से ही रिज़ॉल्यूशन और ब्लॉकिंग का समन्वय करता है। साइट-प्रबंधित PF होस्ट पर, भिन्न जीवनचक्र व्यवहार वाले अन्य प्लेटफ़ॉर्म से होस्टनाम-तालिका सिंटैक्स कॉपी करने के बजाय साइट का स्वामित्व और रिकवरी योजना रखें।

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