तुमचे स्प्लिट टनेल ॲपपर्यंत पोहोचते, पण तिच्या 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 विचारात घ्या, जे वापरकर्त्याने टाइप केलेल्या नावांसाठी प्रणालीचा रिझॉल्व्हर पूर्णपणे टाळू शकते। शोध उपसर्ग हा आणखी एक दिशाभूल करणारा सुगावा आहे: तो लहान नाव पूर्णपणे पात्र नावात विस्तारतो आणि कोणता सर्व्हर उत्तर देतो याच्याशी काहीही संबंध नाही।
शेवटी पुन्हा जोडून सामान्य शोधाची पुनरावृत्ती करा, नंतर सामान्य ब्राउझिंग अजूनही त्याच्या मंजूर धोरणाचे पालन करते याची खात्री करा। असंबंधित नाव सोडवण्यासाठी खाजगी रिझॉल्व्हरच्या जागी सार्वजनिक ठेवणे हा उपाय नाही, आणि ते खाजगी क्वेरी शांतपणे तिथे हलवते जिथे त्यांना कधीही जायचे नव्हते।