स्टेटलेस 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 नै कुनै असम्बन्धित टनेल समस्याको कारण थियो भनी प्रमाणित गर्दैन।