स्टेटलेस 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 हेच कोणत्याही असंबंधित टनेल समस्येचे कारण होते असे सिद्ध होत नाही.