तपाईंको स्प्लिट टनेल एपसम्म पुग्छ तर त्यसको 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 विचार गर्नुहोस्, जसले प्रयोगकर्ताले टाइप गरेका नामका लागि प्रणालीको रिजोल्भर पूर्ण रूपमा बाइपास गर्न सक्छ। खोजी उपसर्ग अर्को भ्रमकारी संकेत हो: यसले छोटो नामलाई पूर्ण योग्य नाममा विस्तार गर्छ र कुन सर्भरले जवाफ दिन्छसँग कुनै सम्बन्ध छैन।
अन्तमा फेरि जोडेर सामान्य खोजी दोहोर्याउनुहोस्, त्यसपछि सामान्य ब्राउजिङ अझै आफ्नो अनुमोदित नीति पालना गर्छ भनी पुष्टि गर्नुहोस्। असम्बन्धित नाम समाधान होस् भनेर निजी रिजोल्भरको सट्टा सार्वजनिक राख्नु सुधार होइन, र यसले निजी प्रश्नहरूलाई चुपचाप त्यहाँ सार्छ जहाँ तिनीहरू कहिल्यै जानु हुँदैनथ्यो।