OpenVPN ने DNS सर्व्हर पाठवला, पण Linux त्याकडे दुर्लक्ष करतो

पाठवलेला DNS सर्व्हर लॉगमध्ये आहे, टनल वर आहे, आणि अंतर्गत नावे अजूनही अयशस्वी होतात। पाठवण्यात स्वतः काहीही तुटलेले नाही; सेटिंग आले आणि तिथेच थांबले। पाठवलेला DNS पर्याय क्लायंटसाठी संदेश आहे, ऑपरेटिंग सिस्टमच्या रिझोल्व्हरसाठी सूचना नाही, आणि या दोघांमधील हस्तांतरण हेच अशा प्रकरणांचा बहुतेक शेवट होतो। पाच तपासण्या, क्रमाने, न झालेले हस्तांतरण शोधतात।

तपासणी एक: कनेक्शन कसे सुरू होते

कनेक्शनचा मालक ठरवतो की कोण रिझोल्व्हर सेटिंग्ज लागू करू शकतो। शेलमधून दिलेला थेट openvpn आदेश स्वतःच्या प्रक्रियेशिवाय काहीही धारण करत नाही, तर systemd युनिट, NetworkManager किंवा विक्रेत्याचा क्लायंट यापैकी प्रत्येकाकडे DNS प्रकाशित करण्याचा स्वतःचा मार्ग आहे। यापैकी कोणतेही गृहीत धरण्यापूर्वी प्रक्रिया यादी आणि युनिटचे नाव वाचा।

कमांड-लाइन प्रक्रिया आपोआप NetworkManager कनेक्शन नाही, आणि NetworkManager कनेक्शन आपोआप resolv.conf लिहिणारी गोष्ट नाही। ही दोन गृहीते या तपासणीत वाया गेलेल्या बहुतेक तासांचे स्पष्टीकरण देतात। तुम्ही प्रत्यक्षात पाहत असलेल्या इंटरफेससाठी कोणता घटक DNS प्रकाशित करेल असे विचारा।

पुढे जाण्यापूर्वी मालक लिहून ठेवा। पुढील प्रत्येक तपासणी त्यावर अवलंबून आहे।

तपासणी दोन: रिझोल्व्हर लिंक प्रत्यक्षात काय धरून आहे

systemd-resolved होस्टवर, resolvectl status प्रत्येक लिंक त्याच्या DNS सर्व्हर आणि डोमेनसह सूचीबद्ध करते। टनल लिंक शोधा आणि तिच्या नोंदी वाचा, आणि इंटरफेसचे नाव tun0 आहे असे गृहीत धरू नका, कारण क्रमांकन निर्मितीच्या क्रमाचे अनुसरण करते। पाठवलेला पत्ता लिंकवर नसल्यास हस्तांतरण अयशस्वी झाले, क्वेरी नाही।

पत्ता असल्यास, पुढील प्रश्न ती लिंक कोणत्या डोमेनवर दावा करते हा आहे। डोमेन यादी नसलेली लिंक फक्त ज्यांच्याबद्दल थेट विचारले जाते त्या नावांना उत्तर देते, आणि split-DNS उपयोजन हे क्वचितच इच्छिते। फक्त पत्ता आवश्यक आहे, पुरेसा नाही।

कोणताही निष्कर्ष काढण्यापूर्वी रिझोल्व्हर आउटपुटमधील लिंक नावाची VPN लॉगमधील इंटरफेस नावाशी तुलना करा। तिथली विसंगती सामान्यतः असे दर्शवते की लॉगची ओळ दुसऱ्या प्रक्रियेतून आली।

तपासणी तीन: नावांची जागा ती लिंक निवडते का

रिझोल्व्हरकडे योग्य सर्व्हर असूनही त्याचा सल्ला घेतला जाऊ शकत नाही। प्रति-लिंक डोमेन ठरवतो की कोणती क्वेरी कोणत्या लिंककडे जाते, आणि राउटिंग डोमेन नसल्यास खाजगी नावांची जागा डीफॉल्ट लिंक जे सांगते त्याकडे परत जाते। म्हणूनच अंतर्गत नावासाठी resolvectl query यशस्वी होऊ शकते तर अनुप्रयोग अजूनही अयशस्वी होतो। अनुप्रयोग पूर्णपणे वेगळा रिझोल्व्हर मार्ग वापरत असू शकतो।

डोमेन वाटप तपासा, फक्त सर्व्हर पत्ता नाही। ~corp.example असे लिहिलेले डोमेन राउटिंग डोमेन आहे, आणि टिल्ड चिन्ह नाव कसे जुळवले जाते ते बदलते।

अनुप्रयोगाकडे स्वतःचा रिझोल्व्हर असल्यास, सिस्टम साधनाने नाही, तो वापरत असलेल्या त्याच यंत्रणेने चाचणी करा। सिस्टम रिझोल्व्हर टाळणारे क्वेरी साधन लिंकची स्थिती काहीही असो यशस्वी होईल।

तपासणी चार: एक मालक, दोन नाही

NetworkManager आधीच VPN आणि रिझोल्व्हरची स्थिती सांभाळत असल्यास, असंबंधित हुक स्क्रिप्ट जोडल्याने स्पर्धक लेखक तयार होतात। पॅकेज systemd-resolved साठी पुरवणारा हुक समर्थित एकत्रीकरण आहे, आणि तो विशिष्ट जीवनचक्र अपेक्षित करतो: script-security 2, up मार्ग, up-restart, down मार्ग आणि down-pre। ते पर्याय नोंदणी आणि काढणे केवळ पहिल्या कनेक्शनवर नाही तर योग्य क्षणी होण्यास कारणीभूत होतात।

मार्गदर्शकातून नकल केलेल्या उदाहरणाऐवजी पॅकेजमधून स्थापित मार्ग वापरा। परवानग्याही महत्त्वाच्या आहेत, कारण हुक विशेषाधिकार कमी झाल्यानंतर चालतो।

त्याचे आउटपुट लक्ष्य बदलण्यासाठी वितरणाची रिझोल्व्हर स्क्रिप्ट संपादित करणे एका होस्टचा उपाय नोंदवते। ती सामान्य दुरुस्ती नाही।

तपासणी पाच: पुन्हा कनेक्ट केल्यानंतर तोच निकाल

पुन्हा कनेक्ट करा आणि लिंक पुन्हा वाचा। एकदा दिसून पुढील संक्रमणात नाहीशी होणारी नोंदणी हीच अयशस्वीता आहे ज्यासाठी ही संपूर्ण चेकलिस्ट आहे। सस्पेंडनंतर, सक्तीच्या पुनःकनेक्शननंतर आणि रिझोल्व्हर सेवा पुन्हा सुरू केल्यानंतर चाचणी करा। प्रत्येक संक्रमण वेगळे क्रम-गृहीत तपासते।

पुनःकनेक्शनवर पाचही तपासण्या उत्तीर्ण झाल्यावरच तुम्ही म्हणू शकता की पाठवलेली सेटिंग्ज वापरात आहेत। त्यापूर्वीचे सर्व काही भाग्यवान क्षणाचे स्नॅपशॉट आहे।