विभाजित DNS आणि VPN: डोमेन नियम IP मार्ग नाहीत
विभाजित DNS नावानुसार रिझॉल्व्हर निवडतो, आणि उत्तराला तरीही मार्ग लागतो। डोमेन नियम आणि मार्ग वेगळे तपासा, तुम्ही प्रत्यक्षात चालवता त्या प्लॅटफॉर्मवर।
तुमचा लॅपटॉप intranet.corp टनेलमधून सोडवतो, तर gitlab.com सेवा पुरवठादाराच्या रिझॉल्व्हरकडे जात राहतो, आणि हीच रचना डिझाइननुसार काम करते। दोन वेगळ्या निर्णयांनी हे घडवले: नाव जुळणीच्या नियमाने रिझॉल्व्हर निवडला, आणि मार्गाने उत्तर परत आणले। यापैकी कोणताही तुटला तर ब्राउझर बाहेरून सारखीच दिसणारी अयशस्वीता दाखवतो। विभाजित DNS बद्दलचे बहुतेक अहवाल दुसऱ्या अयशस्वीतेचे वर्णन करतात आणि सोबत पहिल्याबद्दल पुरावा देतात।
दोन्ही अर्धे वेगवेगळ्या ठिकाणी असतात आणि सहसा वेगळे लोक त्यांचे संपादन करतात। एक VPN प्रोफाइलला जोडलेली DNS धोरण आहे, दुसरा टनेल बसवतो किंवा रोखतो तो मार्ग। कोणता अर्धा प्रत्यक्षात हलला हे कोणी ठरवत नाही तेव्हा डीबगिंग थांबते।
एका विनंतीत लपलेले दोन निर्णय
नावाचा अर्धा धोरण वस्तू आहे, मार्ग नाही। Windows वर ते VPN प्रोफाइलवरील नाव-निराकरण धोरण आहे; Apple प्लॅटफॉर्मवर DNS सेटिंग्ज वस्तूवरील जुळणारी डोमेनची संच; Linux वर मार्गक्रमण डोमेन, विभाजित रिझॉल्व्हर ओळ किंवा नाव सेवा स्विचचा क्रम। मार्गाचा अर्धा सामान्य मार्गक्रमण आहे, टनेलने किंवा हाताने बसवलेले, आणि होस्टनाव काय आहे हे त्याला माहीत नाही। प्रत्यय स्वीकारणारे प्रोफाइल फक्त कोण उत्तर देईल हे ठरवते; ते उत्तर कधीही पोहोचण्यायोग्य करत नाही।
झटपट लक्षण चाचणी त्यांना वेगळे करते: नावाच्या जागी पत्ता ठेवा। पत्ता चालत असेल तर मार्ग ठीक आहे आणि नियम चुकीचा। पत्ताही अयशस्वी झाला तर नियम बरोबर आणि मार्ग गायब असू शकतो।
प्रत्येक प्लॅटफॉर्म तोच नाव नियम कसा व्यक्त करतो
हेतू सारखाच आहे आणि क्षेत्रांची नावे नाहीत। एका क्लायंटवरून दुसऱ्यावर नकल केलेले उदाहरण स्वच्छ प्रकारे पार्स होते आणि कधीही जुळत नाही। तीन स्वरूप असे दिसतात:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
जुळणी किंवा मार्गक्रमण डोमेन ही प्रत्यय चाचणी आहे, म्हणून intranet.corp git.intranet.corp व्यापते आणि corp.intranet व्यापत नाही, आणि ते उलटे करणे ही संपूर्ण संरचनेतील सर्वात सामान्य चूक। Windows हे मॅपिंग प्रोफाइलला जोडलेले नाव-निराकरण धोरण म्हणून ठेवते, इंटरफेसकडे आधीच असलेल्या कोणत्याही प्रत्यय यादीसमोर स्वतःच्या प्राधान्यक्रमाने। Apple प्लॅटफॉर्म जुळणारी डोमेन नेटवर्क विस्ताराच्या DNS सेटिंग्ज वस्तूला जोडतात, आणि सिस्टम ती प्रत्येक मर्यादित रिझॉल्व्हरसाठी लागू करते। यांपैकी कोणतेही रूप मार्ग नाही, आणि कोणतेही अगम्य पत्त्याला गम्य करू शकत नाही। Windows नाव-निराकरण धोरण संदर्भ त्या प्लॅटफॉर्मची क्षेत्रनावे आणि प्राधान्य नियम सूचीबद्ध करतो, आणि ते Apple किंवा systemd दस्तऐवज वापरतात ते नियम नाहीत।
बरोबर उत्तराला तरीही मार्ग लागतो
रिझॉल्व्हरचे उत्तर फक्त एक पत्ता आहे, आणि अनुप्रयोगाला तरीही तिथपर्यंत पोहोचायचे आहे। विभाजित टनेल रचना बऱ्याचदा 10.20.0.0/16 ढकलते आणि मूळ मार्ग रोखून ठेवते, म्हणून अंतर्गत नाव सुटते आणि नंतर जोडणी लटकते। उलट प्रसंगही तितकाच सामान्य: मार्ग आहे, सार्वजनिक रिझॉल्व्हर खाजगी नावाला NXDOMAIN ने उत्तर देतो, आणि अयशस्वीता मार्गक्रमण समस्या म्हणून नोंदवली जाते। आधी मार्ग तपासल्यास कधीही सुटणार नाही अशा नावासाठी मार्गांकडे पाहत राहाल।
कोणताही अर्धा व्यापत नाही असे तिसरे द्वारही आहे। गेटवेवरील ACL, फायरवॉल नियम किंवा क्लायंट-बाजूचे धोरण दोन्ही निर्णय बरोबर झाल्यावरही जोडणी टाकू शकते। नाव सुटले, मार्ग आहे आणि तरीही जोडणीची वेळ संपते, तेव्हा DNS तपासणे थांबवा।
नावे आणि मार्ग ठराविक क्रमाने तपासणे
एक क्रम निवडा आणि तो पाळा, नाहीतर शेवटी अयशस्वी झालेल्या पायरीचा पाठलाग कराल। दस्तऐवजीकृत पूर्ण अंतर्गत नाव सोडवा, उत्तर हा मार्ग तक्ता वाहू शकेल असा पत्ता आहे याची खात्री करा, नंतर सार्वजनिक नावाने पुन्हा करा जेणेकरून टनेलने सर्व काही पकडले नाही हे सिद्ध होईल। systemd होस्टवर क्वेरी आणि रिझॉल्व्हरचे मार्गक्रमण डोमेन एका आदेशाच्या अंतरावर आहेत:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows क्लायंट तेच दोन प्रश्न वेगळ्या cmdlet ने विचारतो। दुसरा सिस्टम प्रत्यक्षात वापरेल तो इंटरफेस सांगतो:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10शोध पत्ता देत असेल आणि मार्ग तपासणी भौतिक इंटरफेस सांगत असेल, तर नाव नियम चालला आणि मार्ग नाही। लहान नाव अयशस्वी होत असेल आणि पूर्ण नाव सुटत असेल, तर प्रत्यय यादी चुकीची आहे, रिझॉल्व्हर नाही।
तुलना सहसा कुठे चुकते
पहिली चूक म्हणजे असंबंधित सार्वजनिक रिझॉल्व्हरला खाजगी नावाबद्दल विचारणे आणि नकार VPN बद्दलचा पुरावा म्हणून वाचणे। दुसरी म्हणजे चालणारा सार्वजनिक शोध टनेलचा रिझॉल्व्हर मार्ग सिद्ध करतो असे गृहीत धरणे। तिसरी म्हणजे विभाजित टनेलिंग आणि विभाजित DNS एकच रचना निर्णय मानणे, जेव्हा तैनाती एकात बरोबर आणि दुसऱ्यात तुटलेली असू शकते। प्रत्येक चूक आरोपी भागाची कधीही चाचणी न घेतलेल्या चाचणीतून आत्मविश्वासू निष्कर्ष देते।
स्वतःचे सुरक्षित DNS असलेला ब्राउझरही सिस्टम नियम बायपास करू शकतो, म्हणून एक ब्राउझर अयशस्वी होत असताना दुसरा यशस्वी होणे हा विरोधाभास नाही। उत्तर देणाऱ्या रिझॉल्व्हरची तुलना करा, तक्रार करणाऱ्या ब्राउझरची नाही।
दोन्ही अर्धे दिसू लागल्यावर उरलेला प्रश्न तांत्रिक नसून धोरणाचा असतो: कोणत्या नाव-अवकाशांचा संस्थेशी संबंध आहे, प्रत्येक उत्तराचा मालक कोण आहे, आणि त्यापैकी कोणी यंत्र सोडावे। ते प्रोफाइलजवळ लिहा, कारण नियमाला हात लावणाऱ्या पुढच्या व्यक्तीला त्याची गरज असेल।