स्टेटलेस VPN एज फ़ायरवॉल पर DNS उत्तर क्यों विफल होता है

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

दोनों आदान-प्रदान एक ही आदान-प्रदान नहीं हैं

ट्यूपल लिख लें और गलती स्पष्ट हो जाती है। अनुरोध का गंतव्य पोर्ट उत्तर का स्रोत पोर्ट बन जाता है, जो पोर्ट 53 के लिए इनबाउंड नियम जोड़ते समय अधिकांश लोगों की कल्पना के ठीक उलट है:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

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

स्टेटलेस एज बनाम स्टेटफुल होस्ट फ़ायरवॉल

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

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

अनुमति को प्रोटोकॉल के इर्द-गिर्द बनाएँ, पोर्ट संख्या के नहीं

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

फिर पुष्टि करें कि पथ पर कौन-सा उत्पाद वास्तव में ट्रैफ़िक छानता है। प्रलेखित IPv4 एज दायरा IPv6 नीति स्थापित नहीं करता, और प्रदाता का आंतरिक ट्रैफ़िक शायद उसी फ़िल्टर से कभी न गुज़रे।

किसी भी स्रोत पोर्ट 53 को अनुमति देना समाधान क्यों नहीं है

जो नियम स्रोत पोर्ट 53 होने का दावा करने वाली हर चीज़ स्वीकार करता है, वह ऐसा नियम है जो प्रेषक हेडर फ़ील्ड में जो लिखता है वही स्वीकार करता है। पोर्ट संख्या प्रेषक का प्रमाणीकरण नहीं करती और यह सिद्ध नहीं करती कि पेलोड वैध उत्तर है, इसलिए नियम रिज़ॉल्यूशन को अधिक भरोसेमंद बनाए बिना होस्ट का जोखिम बढ़ा देता है। स्रोत प्रतिबंध और क्लाइंट की अपनी उत्तर-जाँचें, स्रोत-पोर्ट रैंडमाइज़ेशन सहित, एक्सेस सूची सरल बनाने के लिए बंद करने के बजाय बनाए रखें।

अगर रिज़ॉल्वर आपके नियंत्रण वाली सेवा है, तो उसके पतों तक सीमित करना पर्याप्त है। अगर यह सार्वजनिक रिज़ॉल्वर है, तो उन पतों तक सीमित करें जिन्हें आपने स्वीकृत किया है और उन्हें नियम की टिप्पणी में लिखें।

सही सीमा पर, सही दिशा में जाँचें

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

इसे ठीक करना होस्ट को वास्तव में आवश्यक एक DNS आदान-प्रदान पूरा करता है। यह होस्ट को सार्वजनिक रिज़ॉल्वर नहीं बनाता, अग्रेषित VPN प्रवाहों को अनुमति नहीं देता, और यह सिद्ध नहीं करता कि DNS ही किसी असंबंधित टनल समस्या का कारण था।