आपका स्प्लिट टनल ऐप तक पहुँचता है पर उसके DNS सर्वर तक नहीं
एक स्प्लिट टनल ऐप के सबनेट को रूट कर सकता है और फिर भी उसके पास बैठा रिज़ॉल्वर छोड़ सकता है। होस्ट रूट जोड़ें, फिर जाँचें कि Windows वास्तव में कौन-सा सर्वर चुनता है।
ऐप के सबनेट को रूट करना स्प्लिट टनल का स्पष्ट हिस्सा है और यह पूरा काम नहीं है। रिज़ॉल्वर अक्सर उस ऐप से अलग पते पर बैठता है जिसकी वह सेवा करता है, इसलिए काम करता टनल भी लुकअप को उसके बाहर छोड़ सकता है। जो प्रोफ़ाइल 10.80.0.0/16 ले जाती है और और कुछ नहीं, वह 10.90.0.53 के लिए क्वेरी स्थानीय इंटरफ़ेस से भेजती है, जहाँ कोई निजी ज़ोन नहीं है। रिज़ॉल्वर का रास्ता जोड़ें, फिर समस्या का दूसरा आधा हिस्सा देखें: क्लाइंट वास्तव में कौन-सा सर्वर चुनता है।
मिथक: एक रूट पूरी सेवा को ढक लेता है
स्प्लिट टनल उन गंतव्यों की सूची है जो कनेक्शन से होकर जाते हैं, किसी सेवा का वर्णन नहीं। ऐप का सबनेट और रिज़ॉल्वर का पता दो गंतव्य हैं, और प्रोफ़ाइल एक को दूसरे के बिना ले जा सकती है। जब ऐसा होता है, ऐप पते से पहुँच में रहता है जबकि उसका नाम विफल होता है, जो रूटिंग अंतराल से अधिक DNS खराबी जैसा दिखता है।
रिज़ॉल्वर के आसपास का सबनेट भी अपने आप ढका नहीं जाता। एक पते के लिए होस्ट रूट उस रिज़ॉल्वर के लिए पर्याप्त है और उसके पड़ोसियों को नहीं खोलता। होस्ट रूट का यही अर्थ है: रचना से सँकरा, और अगली सेवा उसी सबनेट में आने पर भूल जाना आसान।
लुकअप के काम करने के लिए तीन बातें सच होनी चाहिए: क्लाइंट रिज़ॉल्वर का पता टनल से रूट करे, गेटवे उस अनुरोध को स्वीकार करे और आगे भेजे, और रिज़ॉल्वर जो स्रोत पाता है उसे स्वीकार करे। उत्तर भी तय रास्ते से वापस आना चाहिए। इनमें से कोई एक छूटे तो लक्षण वही रहता है, इसलिए कॉन्फ़िगरेशन छूने से पहले पतों की तालिका लिख लेना उचित है।
तय करें कि प्रोफ़ाइल को कौन-से पते ले जाने हैं
गंतव्य क्रम में सूचीबद्ध करें: ऐप का नेटवर्क, रिज़ॉल्वर का पता और वह सार्वजनिक अंतिम बिंदु जो टनल को ही समाप्त करता है। तीसरे को कभी टनल में रूट नहीं करना चाहिए, क्योंकि बाहरी कनेक्शन को ऐसा रास्ता चाहिए जो टनल से पहले मौजूद हो।
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
DNS के लिए UDP और TCP दोनों शामिल करें, क्योंकि कार्यान्वयनों से UDP के साथ TCP का समर्थन अपेक्षित है, और अवरुद्ध TCP रास्ता स्वच्छ विफलताओं के बजाय धीमी, आंशिक विफलताएँ पैदा करता है। यदि निजी ज़ोन IPv6 से भी परोसा जाता है, तो समतुल्य होस्ट अपवाद IPv6 पता और उपसर्ग इस्तेमाल करता है और अलग प्रविष्टि है।
कुछ भी जोड़ने से पहले दर्ज करें कि प्रोफ़ाइल पहले से क्या ढकती है। दोहरा रूट हानिरहित है, लेकिन अप्रत्याशित मौजूदा रूट आपको बताता है कि प्रोफ़ाइल आपको मिली योजना से भिन्न पता योजना के लिए बनाई गई थी।
कनेक्शन के मालिक के माध्यम से होस्ट रूट जोड़ें
स्थानीय रूप से प्रबंधित मूल Windows प्रोफ़ाइल के लिए, रूट मशीन की वैश्विक रूटिंग तालिका के बजाय कनेक्शन का होता है। पहले जोड़ का पूर्वावलोकन करें, फिर उसे उसी दायरे से लागू करें जो प्रोफ़ाइल इस्तेमाल करती है।
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
पहला कमांड बिना कुछ स्थापित किए बदलाव का पूर्वावलोकन करता है, और दूसरा उन रूटों की सूची देता है जो प्रोफ़ाइल इस समय ले जाती है। Microsoft का Add-VpnConnectionRoute संदर्भ प्रति-उपयोगकर्ता और सभी-उपयोगकर्ता दायरों का दस्तावेज़ीकरण करता है; सभी-उपयोगकर्ता प्रोफ़ाइल को अपना दायरा पैरामीटर चाहिए, और सभी-उपयोगकर्ता प्रोफ़ाइल के विरुद्ध प्रति-उपयोगकर्ता कमांड विफल होता है या गलत जगह पहुँचता है।
जब प्रोफ़ाइल प्रबंधित हो या विक्रेता क्लाइंट से आए, तो बदलाव उसी मालिक का होता है। कनेक्शन नीति पर स्थायी सिस्टम रूट चढ़ाना तब तक काम करता है जब तक नीति फिर से लागू न हो और रूट गायब न हो जाए, जो आमतौर पर परीक्षण के दौरान नहीं बल्कि सहायता कॉल के दौरान होता है। वह विफलता मौन है: रूट गायब हो जाता है, नाम हल होना बंद कर देता है, और कोई दो घटनाओं को नहीं जोड़ता। बदलाव को मालिक के अपने रिकॉर्ड में रखें ताकि अगला पुनःप्रयोग उसे मिटाने के बजाय ले जाए।
लागू करने के बाद रूट को लागू मान लेने के बजाय प्रोफ़ाइल को फिर से कनेक्ट करें। जीवंत कनेक्शन पर रूट बदलाव हमेशा नहीं उठाए जाते, और फिर से कनेक्ट करना वह स्थिति भी दोहराता है जो आपके उपयोगकर्ताओं के पास वास्तव में होगी।
जाँचें कि क्लाइंट ने वास्तव में कौन-सा रिज़ॉल्वर इस्तेमाल किया
रूट रिज़ॉल्वर को संबोधित पैकेटों को नियंत्रित करता है। यह तय नहीं करता कि कौन-से नाम वहाँ भेजे जाएँ, और वह चयन अलग तंत्र है। Windows में, प्रभावी नामस्थान नियम प्रति डोमेन रिज़ॉल्वर चुन सकते हैं, जबकि प्रोफ़ाइल की DNS सेटिंग्स डिफ़ॉल्ट देती हैं। ये दो परतें बिना कोई त्रुटि पैदा किए असहमत हो सकती हैं, इसलिए सीधी क्वेरी केवल आधा प्रमाण है।
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
पहला कमांड प्रभावी नामस्थान नीति छापता है, और दूसरा निजी रिज़ॉल्वर से सीधे ऐप का नाम पूछता है। सीधा उत्तर साबित करता है कि रास्ता और रिज़ॉल्वर काम करते हैं; यह साबित नहीं करता कि ऐप के अपने लुकअप ने वही सर्वर चुना। इसकी तुलना उसी नाम के सामान्य लुकअप से और ऐप को मिलने वाले उत्तर से करें।
कैश और ब्राउज़र-स्तर के सुरक्षित DNS को ध्यान में रखें, जो उपयोगकर्ता द्वारा टाइप किए नामों के लिए सिस्टम रिज़ॉल्वर को पूरी तरह बायपास कर सकता है। खोज उपसर्ग एक और भ्रामक संकेत है: यह छोटे नाम को पूर्ण योग्य नाम में फैलाता है और इससे कोई लेना-देना नहीं कि कौन-सा सर्वर उत्तर देता है।
अंत में फिर से कनेक्ट करें और सामान्य लुकअप दोहराएँ, फिर पुष्टि करें कि सामान्य ब्राउज़िंग अब भी अपनी स्वीकृत नीति का पालन करती है। किसी असंबंधित नाम को हल कराने के लिए निजी रिज़ॉल्वर को सार्वजनिक से बदलना सुधार नहीं है, और यह निजी क्वेरीज़ को चुपचाप वहाँ ले जाता है जहाँ उन्हें कभी नहीं जाना था।