Pritunl चे खाजगी DNS अयशस्वी? एक अरुंद resolver मार्ग जोडा

खाजगी नावे कॉर्पोरेट नेटवर्कवर सर्वांसाठी सोडवली जातात आणि VPN वर सर्वांसाठी वेळ संपते। Resolver गेटवेला उत्तर देतो, तिथपर्यंत मार्ग अस्तित्वात आहे, आणि तरीही क्वेरीला कधीच उत्तर मिळत नाही। जे कमी आहे ते दुसरे सार्वजनिक resolver किंवा विस्तृत मार्ग नाही: खाजगी DNS सर्व्हर उत्तर देण्यास तयार असलेला स्रोत पत्ता आहे।

Resolver तुमचा क्लायंट पूल नाकारत असल्याची खात्री करा

अयशस्वीता पोहोचण्याशी नाही तर स्रोताशी संबंधित आहे हे सिद्ध करून सुरुवात करा। जोडलेल्या क्लायंटवरून खाजगी resolver ला थेट क्वेरी करा आणि विनंतीची वेळ संपते की नकार म्हणून परत येते ते पहा। dig @10.40.0.53 intranet.example.net +time=2 +tries=1 ची वेळ संपत असताना गेटवेवरून तीच क्वेरी यशस्वी होते, हे resolver वरील प्रवेश धोरणाकडे निर्देश करते। SERVFAIL उत्तर पूर्णपणे दुसरीकडे, सहसा झोन किंवा वरच्या फॉरवर्डरकडे निर्देश करते।

चाचणीपूर्वी क्लायंटचा पत्ता नोंदवा। क्लायंटवरील ip -4 addr show tun0, किंवा कन्सोलमध्ये दाखवलेली लीज, resolver कोणता पूल पाहतो हे सांगते।

नंतर मार्ग अस्तित्वात आहे याची खात्री करा। Resolver चा पत्ता टनेलमध्ये पाठवणारा मार्ग पूर्वअट आहे, उपाय नाही; जर पॅकेट कधीच पोहोचले नाहीत, तर स्रोत धोरणाचा विचारच केला जात नाही। क्लायंटवर ip route get 10.40.0.53 ने ते तपासा।

सर्व काही भाषांतरित करण्याऐवजी एक होस्ट मार्ग जोडा

Pritunl चे खाजगी DNS मार्गदर्शन अरुंद उपाय सांगते: resolver पत्त्यासाठी NAT सक्षम /32 मार्ग, तो पत्ता क्लायंटचा DNS सर्व्हर म्हणून निवडून। मार्ग फक्त DNS रहदारीसाठी resolver पाहत असलेला स्रोत बदलतो। अनुप्रयोग रहदारी तुम्ही त्यासाठी निवडलेली स्रोत-संरक्षण रचना टिकवते।

सध्याचे मार्ग आच्छादनासाठी तपासल्यानंतर, सर्व्हरच्या समर्थित मार्ग मालकामार्फत ते कॉन्फिगर करा। वरील उदाहरणात गंतव्य NAT सक्षम 10.40.0.53/32 आहे, आणि क्लायंट पूल 10.90.0.0/24 राहतो। एक सेवा दुरुस्त करण्यासाठी संपूर्ण खाजगी श्रेणीचे भाषांतर करू नका, कारण क्लायंटच्या खऱ्या पत्त्यावर अवलंबून असलेले प्रत्येक खालचे धोरण त्याऐवजी गेटवे पाहू लागेल। चाचणी लुकअपदरम्यान resolver चा क्वेरी लॉग पाहून तो प्रत्यक्षात कोणता पत्ता घेतो याची खात्री करा। फक्त होस्ट मार्ग भाषांतर किंवा परवानगीबद्दल काहीही सिद्ध करत नाही।

Resolver ला अजूनही भाषांतरित स्रोत UDP आणि TCP वर परवानगी द्यावी लागेल, आणि त्याची उत्तरे परत येऊ शकली पाहिजेत। स्रोत बदलल्याने गहाळ झोन किंवा रेकॉर्ड तयार होऊ शकत नाही।

क्वेरी सर्व्हर पाठवतो की क्लायंट हे ठरवा

Pritunl VPN Client DNS Mapping शी जोडलेली DNS-प्रॉक्सी व्यवस्था देखील दस्तऐवजात नोंदवते, जिथे सर्व्हर क्लायंटसाठी वरच्या क्वेरी फॉरवर्ड करतो। त्या मॉडेलमध्ये वरचा स्रोत सर्व्हरच्या स्वतःच्या नेटवर्क संदर्भाचा आहे, आणि क्लायंट-बाजूचा अपवाद चुकीचा उपाय आहे।

काहीही जोडण्यापूर्वी कोणते मॉडेल सक्रिय आहे ते ओळखा। तीन आच्छादक दुरुस्त्या, एक प्रॉक्सी, क्लायंटवर resolver बदलणे आणि हाताने NAT स्क्रिप्ट सहसा याचा अर्थ कोणीही हे स्थापित केले नाही: क्वेरी कोणत्या घटकाने पाठवायची। bootstrap देखील तपासा: टनेल अस्तित्वात येण्यापूर्वी एंडपॉइंट शोधण्याचा एकमेव मार्ग फक्त-खाजगी resolver असू शकत नाही, आणि कायमचे resolver बदल कनेक्शनपेक्षा जास्त टिकू नये।

सार्वजनिक वेब पृष्ठ नाही, खाजगी लुकअप तपासा

बदल लागू करून पुन्हा कनेक्ट केल्यानंतर, क्लायंटची प्रभावी resolver कॉन्फिगरेशन तपासा, नंतर फक्त खाजगी झोनमध्ये आहे हे तुम्हाला माहीत असलेले नाव सोडवा। स्पष्ट सर्व्हरशिवाय dig intranet.example.net क्लायंट प्रत्यक्षात काय वापरतो हे दाखवते। नंतर त्या लुकअपने परत दिलेल्या पत्त्यावर विनंती पाठवा, कारण सोडवणे आणि सेवा प्रवेश वेगवेगळे टप्पे आहेत। DNS-over-HTTPS द्वारे सार्वजनिक साइट लोड करणारा ब्राउझर ऑपरेटिंग सिस्टमच्या खाजगी resolver मार्गाबद्दल काहीही सिद्ध करत नाही। सार्वजनिक दुय्यम resolver देखील अंतर्गत झोनसाठी प्राधिकारी नाही।

Resolver पत्ता, /32 मार्ग आणि क्लायंट DNS सेटिंग एकत्र सर्व्हर नोट्समध्ये नोंदवा। त्या कॉन्फिगरेशनपैकी अर्धे एकटे पुनर्संचयित केल्यास मूळ अयशस्वीता पुन्हा घडते।

शेवटी, DNS यशस्वी झाल्यानंतर टनेल अजूनही अनुप्रयोगाच्या गंतव्याकडे मार्ग देत असल्याची खात्री करा। मार्ग, सेवा प्रवेश आणि प्रमाणीकरण नाव सोडवण्यापासून स्वतंत्र राहतात, आणि कार्यरत लुकअप थ्रूपुटबद्दल काहीही सांगत नाही। खाजगी पृष्ठ संथ असले तरी सोडवले जात असल्यास, resolver ने आपले काम केले आणि समस्या मार्गावर गेली।