अंतर्गत नावे VPN वर सोडवली जात नाहीत, तर सार्वजनिक संकेतस्थळे उघडतात

एक वापरकर्ता नोंदवतो की इंट्रानेट होस्टनाव VPN वर सोडवले जात नाही. त्याच लॅपटॉपवरून आलेला दुसरा अहवाल सांगतो की गळती चाचणी अजूनही स्थानिक रिझॉल्व्हरने उत्तर दिलेल्या क्वेरी दाखवते. ती एकच समस्या वाटतात पण दोन आहेत, वेगवेगळ्या पुराव्यांसह, आणि पहिल्यासाठीची नेहमीची दुरुस्ती दुसरी बिघडवते. कोणतेही सेटिंग हाताळण्यापूर्वी त्या वेगळ्या करा.

एक बिघाड नसलेली दोन लक्षणे

अंतर्गत नाव सोडवता न येणे म्हणजे प्रश्न तिथे गेला जिथे त्याचे उत्तर नाही. बोगद्याबाहेर जाणाऱ्या क्वेरी म्हणजे उत्तर उपलब्ध असूनही प्रश्न चुकीच्या ठिकाणी गेला. ह्या विरुद्ध बिघाड आहेत: एक गहाळ उत्तर, दुसरा अतिरिक्त गंतव्य.

सापळा हा आहे की कार्यालयीन रिझॉल्व्हर सर्वत्र जोडल्यास पहिला सुटतो आणि दुसरा निश्चित होतो. सार्वजनिक रिझॉल्व्हर सर्वत्र जोडल्यास उलट घडते.

दोन्ही निरीक्षणे वेळेच्या नोंदीसह लिहा, नंतर खालील चार तपासण्या क्रमाने करा.

कोणत्या ॲडॉप्टरचा रिझॉल्व्हर प्रश्न घेतो

Windows वर DNS क्लायंट ॲडॉप्टर बाइंडिंग क्रमानुसार सर्व्हर निवडतो, आणि बोगदा ॲडॉप्टर स्वयंचलितपणे पहिला नसतो. ॲडॉप्टरची प्रगत सेटिंग्ज उघडा आणि दूरस्थ प्रवेश कनेक्शन भौतिक ॲडॉप्टरच्या वर हलवा, नंतर बदल नवीन सत्राला लागू होण्यासाठी पुन्हा कनेक्ट करा.

बाइंडिंग क्रम हा फक्त पहिला अर्धा भाग आहे. कोणती नावे त्या ॲडॉप्टरची आहेत हेही क्लायंटला माहीत असणे आवश्यक आहे, आणि तो क्रमाचा नव्हे प्रत्ययाचा प्रश्न आहे.

बोगदा सुरू असताना घेतलेला कार्यरत मशीनचा ipconfig /all लॅपटॉपच्या शेजारी ठेवा. कार्यरत मशीन तिच्या कार्यालयीन ॲडॉप्टरवर कनेक्शन-विशिष्ट DNS प्रत्यय दाखवेल, तर लॅपटॉप बोगद्यावर काहीही दाखवणार नाही. हा फरक सर्व्हर तिथेच आहे पण नाव अजूनही सोडवले जात नाही अशा अहवालांचा संपूर्ण वर्ग स्पष्ट करतो, कारण प्रत्ययाशिवाय लहान नाव कार्यालयीन रिझॉल्व्हर सेवा देत असलेल्या झोनपर्यंत कधीही पूर्ण होत नाही.

लहान नावाला आधी प्रत्यय लागतो, मग मार्ग

अपात्र होस्टनाव टाइप केल्यास रिझॉल्व्हरला डोमेन अंदाजण्यास सांगितले जाते. अंदाज कनेक्शनला जोडलेल्या प्रत्यय सूचीतून येतो, आणि ती सूची रिकामी असल्यास क्वेरी एकच लेबल म्हणून बाहेर जाते ज्याशी कोणताही खाजगी झोन जुळणार नाही.

कार्यरत मशीनचा प्रत्यय DNS टॅबवरील VPN ॲडॉप्टरच्या IPv4 गुणधर्मांत कॉपी करा, नंतर पुन्हा कनेक्ट करा. Linux वर समतुल्य गोष्ट बोगदा लिंकवरील शोध डोमेन आहे, जे systemd-resolved जागतिक नव्हे तर प्रत्येक लिंकसाठी दाखवते.

दोन्ही सेटिंग्ज तुमच्या टिपांमध्ये वेगळ्या ठेवा. प्रत्यय काय विचारले जाते ते बदलतो, रिझॉल्व्हरचा पत्ता कोणाला विचारले जाते ते बदलतो. दुसरे चुकीचे असताना एक दुरुस्त केल्यास यादृच्छिक वाटणारा निकाल मिळतो.

रिझॉल्व्हरला थेट विचारा, मग नावाला

कार्यालयीन रिझॉल्व्हरला थेट क्वेरी नावाची समस्या मार्गाच्या समस्येपासून वेगळी करते, कारण ती क्लायंटची रिझॉल्व्हर निवड पूर्णपणे टाळते.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

पहिला आदेश विशिष्ट सर्व्हरला पूर्णपणे पात्र नावासाठी विचारतो. त्याने उत्तर दिल्यास रिझॉल्व्हर आणि त्याकडे जाणारा मार्ग ठीक आहे आणि बिघाड निवडीत किंवा प्रत्ययात आहे. वेळ संपल्यास पत्ता चुकीचा किंवा पोहोचण्यायोग्य नाही आणि समस्या DNS नव्हे मार्गनिर्देशन आहे. दुसरा आदेश लहान नावाने काय होते ते दाखवतो, आणि तिसरा systemd होस्टवर प्रत्येक लिंकची रिझॉल्व्हर संरचना छापतो.

काही नेटवर्क अज्ञात नावांसाठी परत करतात त्या वाइल्डकार्ड उत्तरांकडे लक्ष द्या. विश्वासार्ह वाटणारे उत्तर म्हणजे हेतू असलेल्या सर्व्हरने उत्तर दिले याचा पुरावा नाही, म्हणून परत आलेल्या पत्त्याची अंतर्गत सेवा प्रत्यक्षात वापरत असलेल्या पत्त्याशी तुलना करा. पत्ता पार्किंग पृष्ठाचा किंवा प्रॉक्सीचा असल्यास रिझॉल्व्हरने उत्तर दिले पण उत्तर कधीही तुमचे नव्हते. हा फरक संपूर्ण वेळ चालू असलेल्या बोगद्यामागे लागण्याचा एक तास वाचवतो.

Linux वर /etc/resolv.conf पुन्हा लिहिणारा VPN क्लायंट स्थानिक रिझॉल्व्हर पूर्णपणे बदलतो. vpnc ते थांबवण्यासाठी DNSUpdate no देतो, आणि systemd-resolved फक्त सूचीबद्ध डोमेन बोगदा लिंककडे पाठवू शकतो. दोन्ही पद्धती सार्वजनिक नावे स्थानिक रिझॉल्व्हरवर ठेवतात आणि अंतर्गत नावे कार्यालयात पाठवतात.

गळती म्हणजे नियम, चेकबॉक्स नाही

नाव निराकरण हे पोर्ट 53 वरचे UDP देवाणघेवाण आहे, म्हणून वेब रहदारी वाहून नेणारा पण UDP न वाहणारा बोगदा क्वेरी भौतिक मार्गावर सोडतो. सार्वजनिक नाव सोडवले जात असताना भौतिक NIC वर कॅप्चर करून ते सिद्ध करा. त्या इंटरफेसवर वाचनीय स्वरूपात दिसणारी क्वेरी म्हणजे बोगदा ती वाहत नाही.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

त्या इंटरफेसवर क्वेरी वाचनीय स्वरूपात दिसल्यास बोगदा ती वाहत नाही. दुरुस्ती म्हणजे पोर्ट 53 फक्त VPN ने पाठवलेल्या रिझॉल्व्हरला परवानगी देणारा आणि इतर गंतव्ये वगळणारा नियम, तसेच पाठवलेला पर्याय गुपचूप टाकून न देणारी क्लायंट संरचना.

तो शेवटचा भाग दिसतो त्यापेक्षा अधिक महत्त्वाचा आहे. OpenVPN route-nopull सह सुरू केल्यास पाठवलेला DNS पर्याय मार्गांसोबत नाहीसा होतो, जोपर्यंत तो टिकवण्यासाठी पुल फिल्टर रुंदावला जात नाही. dhcp-option DNS दुर्लक्षणारा क्लायंट पूर्वीचे जे होते तेच वापरत राहील. सर्व्हरच्या बाजूने कोणताही बदल लागू होण्यासाठी नवीन सत्र आवश्यक आहे, कारण बोगदा उभा राहिल्यावर रिझॉल्व्हर सूची दिली जाते आणि जुने सत्र जुनी स्थिती दाखवत राहते.

तिकीट बंद करण्यापूर्वी कोणता बिघाड प्रत्यक्षात निरीक्षण केला ते नोंदवा. गहाळ अंतर्गत उत्तर आणि बोगद्यातून सुटलेली क्वेरी वेगवेगळ्या दुरुस्ती मागतात, आणि पहिला सुटणारा प्रत्यय बदल दुसरा गुपचूप बिघडवू शकतो. तिकीट पुढे घेणारा लेबलवर विश्वास ठेवेल, म्हणून लेबल अचूक करा.