खाजगी DNS नावे VPN क्लायंटवर का अयशस्वी होतात आणि कुठे तपासावे

तुम्ही हॉटेलच्या खोलीत लॅपटॉप उघडता, क्लायंट सुरू करता, अंतर्गत फाइल सर्व्हरचे नाव टाइप करता आणि काहीही परत मिळत नाही। बोगदा सांगतो की जोडलेले आहे, आणि त्याच सबनेटमधील पत्त्याला ping अजूनही उत्तर देतो, म्हणजे वाहतूक स्वतःच ठीक आहे। फक्त नाव अयशस्वी होते, आणि हे अंतर समस्या दोन ठिकाणी मर्यादित करते: क्लायंटने कोणत्या रिझॉल्व्हरला विचारले आणि मिळालेले उत्तर बोगद्यातून परत येऊ शकते का। एक दुरुस्त करा आणि दुसरे सोडून द्या, तर बिघाड फक्त जागा बदलतो।

कोणतेही प्रोफाइल संपादित करण्यापूर्वी क्लायंट नावासोबत काय करतो याची खात्री करा। Linux मध्ये resolvectl query files.corp.example दाखवते की कोणत्या लिंक आणि कोणत्या रिझॉल्व्हरने उत्तर तयार केले। Windows मध्ये Resolve-DnsName files.corp.example उत्तर दिलेला सर्व्हर आणि त्याने परत केलेला पत्ता दाखवते।

काहीही बदलण्यापूर्वी उत्तर वाचा

नाव काही मिलिसेकंदात NXDOMAIN म्हणून परत आले, तर प्रश्न तुमच्या झोनपर्यंत कधीच पोहोचला नाही आणि कोण्या सार्वजनिक किंवा हॉटेल रिझॉल्व्हरने उत्तर दिले। ते दीर्घ विरामानंतर परत आले, तर वाटेत काहीतरी UDP पोर्ट 53 टाकत आहे आणि क्लायंट शेवटी पर्यायावर उतरला। ते योग्य पत्त्यासह उत्तर देते पण कनेक्शन तरीही अडकते, तर शोध ठीक आहे आणि तुमची समस्या मार्गनिर्देशनात किंवा सेवेतच आहे।

हा तीन भागांतला विभाग एक तासाचा अंदाज वाचवतो। तो हेही सांगतो की VPN ला हात लावायचा का: योग्य खाजगी पत्त्यावर सोडवले जाणारे नाव रिझॉल्व्हरचा मार्ग आधीच सिद्ध करून झाले आहे, म्हणून उरलेले काम डेटाच्या मार्गावर आहे।

रिझॉल्व्हर बोगद्याच्या आतून वाटून द्या

क्लायंट दोन गटांत विभागले जातात। एका गटाला सर्व्हर कनेक्शन होत असताना रिझॉल्व्हर देऊ शकतो; दुसरा गट सेटिंग स्थानिक फाइलमध्ये ठेवतो जी कोणताही गेटवे दुरून बदलू शकत नाही।

OpenVPN पहिल्या गटात आहे। सर्व्हरवर push "dhcp-option DNS 10.8.0.53" आणि push "dhcp-option DOMAIN corp.example" नियंत्रण चॅनेलने खाली जातात, पण तेव्हाच जेव्हा क्लायंटच्या कॉन्फिगरेशनमध्ये pull अजूनही सक्रिय असेल। हाताने संपादित केलेला आणि pull-filter ignore "dhcp-option" घेऊन चालणारा क्लायंट त्यांना कधीच पाहणार नाही, आणि हीच एक ओळ आश्चर्यकारकपणे अनेक अशा प्रकरणांचे स्पष्टीकरण देते की «सर्व्हर ते ढकलतो पण माझा लॅपटॉप मानत नाही»।

WireGuard दुसऱ्या गटात आहे, कारण प्रोटोकॉलमध्ये पर्यायांची कोणतीही बोलणी नाही। रिझॉल्व्हर आणि शोध डोमेन क्लायंटच्या स्वतःच्या [Interface] ब्लॉकमध्ये DNS = 10.8.0.53, corp.example म्हणून जातात। wg-quick ते resolvconf किंवा systemd-resolved द्वारे लागू करतो, आणि Windows वर अधिकृत क्लायंट NRPT चे ते नियम बसवतो जे फक्त बोगदा उभा असेपर्यंत असतात: Get-DnsClientNrptPolicy ते सूचीबद्ध करते, ज्यामुळे क्लायंटने तुमची फाइल कधी लागू केली का हे पाहण्याचा तो जलद मार्ग बनतो।

IPsec/IKEv2 मध्ये आहे। strongSwan चा attr प्लगइन तलावातून काढलेला DNS सर्व्हर परत देऊ शकतो, आणि Windows क्लायंट सहसा तो स्वीकारतो, पण स्वतःचा नाव सर्व्हर खिळवून ठेवणारे प्रोफाइल गेटवे जे काही देऊ करेल त्यावर मात करते। Linux क्लायंटवर समतुल्य हातचे पाऊल resolvectl dns wg0 10.8.0.53 आणि नंतर resolvectl domain wg0 '~corp.example' आहे; दोन्ही इंटरफेससोबत नाहीशी होतात, जे बोगद्यापुरते मर्यादित सेटिंगसाठी नेमके हवे तेच आहे।

प्रत्येक प्रश्न गिळण्याऐवजी प्रत्यय मर्यादित करा

क्लायंटची संपूर्ण रिझॉल्व्हर यादी तुमच्या अंतर्गत सर्व्हरकडे वळवणे सोपे आणि सहसा चुकीचे। मग प्रत्येक सार्वजनिक नाव तुमच्या डेटा सेंटरच्या बाहेर जाण्याच्या मार्गाने सोडवले जाते, CDN दूरचे पत्ते परत देतात, आणि रिझॉल्व्हरचा एक बिघाड वापरकर्त्याचे ब्राउझिंगही सोबत घेऊन जातो।

आत फक्त खाजगी प्रत्यय पाठवा। systemd-resolved मध्ये ~ ने सुरू होणारे डोमेन फक्त मार्गनिर्देशनासाठी आहे, म्हणून ~corp.example म्हणजे त्या प्रत्ययाखालील प्रश्न त्या लिंकच्या सर्व्हरकडे जातात तर बाकी सर्व भौतिक नेटवर्क वापरत राहते। Windows हेच काम नामस्थानापुरते मर्यादित NRPT नियमांनी करते, आणि macOS /etc/resolver/ खालील अतिरिक्त रिझॉल्व्हर फाइलने।

मल्टिकास्ट नावे स्वतःच्या उत्तराची पात्र आहेत। .local नावे रचनेने link-local आहेत (RFC 6762) आणि बिंदू-ते-बिंदू tun इंटरफेस तो मल्टिकास्ट गट वाहत नाही, म्हणून सार्वजनिक रिझॉल्व्हर जोडल्याने ती प्रकाशित होणार नाहीत आणि अंतर्गत unicast रिझॉल्व्हरला त्यांच्याबद्दल विचारल्यास NXDOMAIN परत येते। avahi सारखा परावर्तक परावर्तन मोडमध्ये दोन विभाग जोडू शकतो, पण हा सर्व्हरच्या बाजूचा निर्णय आहे जो कोणताही क्लायंट मागू शकत नाही। जर प्रिंटर किंवा NAS नावाने उपलब्ध असणे आवश्यक असेल, तर त्याऐवजी तुमच्या झोनमध्ये त्याला A रेकॉर्ड द्या।

उत्तर परत येऊ शकते हे सिद्ध करा

अगम्य पत्त्याकडे बोट दाखवणारे बरोबर उत्तर अगदी रिझॉल्व्हरच्या समस्येसारखे दिसते जोपर्यंत तुम्ही मार्ग तपासत नाही। कर्नेलला विचारा की उत्तर कुठे जाईल: ip route get 10.20.5.20 इंटरफेस आणि अधिक उपयुक्त म्हणजे तो वापरणारा स्रोत पत्ता सांगते।

रिझॉल्व्हरच्या पत्त्याकडेच लक्ष ठेवा। ज्या क्लायंटकडे DNS = 10.8.0.53 सोबत AllowedIPs = 10.20.0.0/16 आहे तो आपले प्रश्न भौतिक NIC मधून बाहेर पाठवतो, जिथे ते गपचूप मरतात, कारण रिझॉल्व्हर बोगदा दावा करत असलेल्या कोणत्याही उपसर्गात नाही। हाच विसंगती या संपूर्ण क्षेत्रातील सर्वात सामान्य एक-कारण बिघाड आहे, आणि DNS सेटिंगची अनुमत उपसर्गांशी ओळीओळीने तुलना करेपर्यंत ती अदृश्य राहते।

आच्छादित श्रेणी उलटा बिघाड घडवतात। उत्तर बरोबर आहे, मार्ग अस्तित्वात आहे, आणि तो चुकीच्या यजमानाकडे बोट दाखवतो, कारण घरी 192.168.0.0/24 त्याच श्रेणीकडे जाणाऱ्या बोगद्याच्या मार्गापेक्षा अधिक विशिष्ट आहे। एक बाजू पुन्हा क्रमांकित करा किंवा अरुंद मार्ग ढकला, नंतर सेवा यजमानाचा फायरवॉल आणि परतीचा मार्ग पुष्टी करा; strongSwan च्या अग्रेषण विषयी टिपण्या त्या मार्गाची sysctl बाजू व्यापतात।

प्रमाणपत्रे ही वेगळी ओळख तपासणी आहे ज्याचा दोष लोक DNS वर टाकतात। ब्राउझरने सोडवण्याच्या त्रुटीऐवजी नावाची विसंगती कळवली, तर शोध आधीच चालला आहे आणि प्रमाणपत्रातील SAN हीच दुरुस्त करायची गोष्ट आहे। HTTPS नावावर तपासा, कधीही उघड्या IP वर नाही।

गेटवे वरून नाही, क्लायंटवरून पुन्हा तपासा

ज्या ॲपमधून वापरकर्ता तक्रार करतो त्याच्या आत तपासा, कारण कमांड लाइनवरील शोध ब्राउझर तोच मार्ग घेतो हे सिद्ध करत नाही। Chrome चे सुरक्षित DNS आणि Firefox चे network.trr.mode सिस्टम रिझॉल्व्हर पूर्णपणे बायपास करू शकतात, आणि जेव्हा तसे करतात तेव्हा खाजगी नाव एकतर अयशस्वी होते किंवा सार्वजनिक रिझॉल्व्हरकडे गळते। resolvectl query ची हाताने चालवलेल्या dig @10.8.0.53 files.corp.example शी तुलना कोणती घटना घडली ते सांगते।

नंतर ते दुरुस्त झाले असे म्हणण्यापूर्वी कनेक्शन तोडा आणि पुन्हा जोडा। इंटरफेसवर हाताने लावलेल्या सेटिंग इंटरफेससोबत नाहीशा होतात, आणि विसरलेल्या स्थानिक बदलामुळेच बरोबर वाटणारे प्रोफाइल पुढच्या वेळी चालू होताना अयशस्वी होईल।

पुढच्या मशीनसाठी छोटी यादी: नाव बोगद्याच्या रिझॉल्व्हरने सोडवले जाते, प्रत्यय मर्यादित आहे जागतिक नाही, रिझॉल्व्हरचा पत्ता अनुमत उपसर्गांच्या आत आहे, उत्तरातील यजमान सेवेच्या पोर्टवर उत्तर देतो, आणि प्रमाणपत्र वापरकर्त्याने लिहिलेले नाव व्यापते।