स्प्लिट-टनेल कागजातलाई प्रत्येक मार्गको छेउमा DNS नियम चाहिन्छ
मार्गले ठेगानाले निर्णय गर्छ, रिजोल्भरले नामले निर्णय गर्छ। प्रत्येक प्रवाहका लागि दुवै चयनकर्ता लेख्नुहोस्, प्रत्येकसँग एक परीक्षण, नत्र DNS सर्दा टिप्पणी असफल हुन्छ।
"अफिसको ट्राफिक VPN मार्फत जान्छ" भन्ने स्प्लिट-टनेल टिप्पणीले एउटा निर्णय दस्तावेज गरेको छ र अरू तीनलाई संकेत गरेको छ। प्याकेट तहमा राउटिङ तालिकाले गन्तव्य ठेगानाद्वारा इन्टरफेस छान्छ; नाम तहमा रिजोल्भरले क्वेरीद्वारा सर्भर छान्छ, र यी दुई छनोट स्वतन्त्र रूपमा गरिन्छ। त्यसैले सही रूपमा दस्तावेज गरिएको प्रिफिक्सले अझै पनि आन्तरिक नामलाई सार्वजनिक ठेगानामा समाधान गर्ने, वा मार्ग पूर्ण देखिँदा केही पनि समाधान नगर्ने मेसिन उत्पादन गर्न सक्छ।
दुई चयनकर्ता, एक जडान प्रयास
जब अनुप्रयोगले files.corp.example सँग जोडिन्छ, प्याकेट अस्तित्वमा आउनु अघि दुई खोजी हुन्छन्। रिजोल्भरले कुन सर्भरले क्वेरी पाउने भनी खोजी डोमेन, प्रति-लिङ्क राउटिङ डोमेन वा स्पष्ट प्रोफाइल नियम प्रयोग गरी निर्णय गर्छ। त्यसपछि राउटिङ तालिकाले परिणामस्वरूप ठेगाना कहाँ जाने भनी गन्तव्यसँगको सबैभन्दा लामो प्रिफिक्स मिलान प्रयोग गरी निर्णय गर्छ।
ती दुई निर्णयलाई केहीले जोड्दैन। निजी क्षेत्रले 10.20.4.11 द्वारा जवाफ दिन सक्छ, जबकि राउटिङ तालिकाले 10.20.0.0/16 टनेलमा पठाउँछ, र जडान काम गर्छ। जुनसुकै उल्टाउनुहोस् र यो अर्कोजस्तै देखिने तरिकाले असफल हुन्छ: सही DNS नीति र हराएको मार्गले समाधान भएको नाम र समयसमाप्ति दिन्छ, जबकि सही मार्ग र सार्वजनिक रिजोल्भरले सफा रूपमा गलत ठाउँमा राउट हुने ठेगाना दिन्छ।
विभाजित क्षितिज DNS ले यसलाई थप तीव्र बनाउँछ। एउटै नामले आन्तरिक रिजोल्भरबाट निजी ठेगाना र इन्टरनेटतर्फ फर्केको रिजोल्भरबाट सार्वजनिक ठेगाना फर्काउन सक्छ, त्यसैले प्रिफिक्स मात्र लेख्ने टिप्पणीले क्लाइन्टले वास्तवमा कुन ठेगाना प्रयोग गर्ने भनी अनुमान गर्न सक्दैन। रिजोल्भरको मार्ग लेख्नुहोस्, नत्र ठेगाना अनुमान मात्र हो।
मार्ग-मात्र टिप्पणीले के छुटाउँछ
मार्ग-मात्र अभिलेख सबैभन्दा सामान्य स्प्लिट-टनेल असफलताका लागि बेकम्मा छ: नामहरू। प्रयोगकर्ताले आन्तरिक सञ्जाल लोड हुँदैन भनी रिपोर्ट गर्छ, टनेल सक्रिय छ, र प्रिफिक्स उपस्थित छ। टिकट लिने व्यक्तिसँग कुन रिजोल्भरले जवाफ दिनुपर्थ्यो भन्ने अभिलेख छैन, गलत खोजी प्रत्ययलाई अवरुद्ध सर्भरबाट छुट्याउने तरिका छैन, र तुलना गर्न आधाररेखा छैन।
दोस्रो छुटाइ अपवादको सूची हो। स्प्लिट-टनेल डिजाइन टनेलबाहिर के रहन्छ र भित्र के आउँछ दुवैले उत्तिकै परिभाषित गर्छ, र बहिष्कृत दायराहरू सामान्यतया पहिले भाँचिन्छन्, किनकि अझ विशिष्ट स्थानीय मार्ग वा क्लाइन्ट-पक्षीय फिल्टरले प्रोफाइल नछोइकन नियतलाई उल्लङ्घन गर्न सक्छ।
तेस्रो टनेलको टाढाको पक्ष हो। क्लाइन्ट मार्गले प्याकेटलाई तारमा राख्छ मात्र; गेटवेले अझै यसलाई अगाडि पठाउनुपर्छ र फर्कने बाटो हुनुपर्छ। strongSwan को अगाडि पठाउने मार्गदर्शिका गेटवेमा अगाडि पठाउने र फायरवाल नियमहरू सुविधाको भाग हुन्, अनुमान गर्न सकिने प्लम्बिङको भाग होइन भनी सम्झाउँछ।
टिप्पणीलाई कार्यान्वयनयोग्य बनाउने क्षेत्रहरू
प्रत्येक प्रवाहका लागि एक पङ्क्ति, र प्रवाह भनेको गन्तव्य जोड नाम जोड मालिक। वास्तविक घटनासँग सम्पर्कमा टिक्ने क्षेत्रहरू यी हुन्:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
"यो कहाँ बस्छ" पङ्क्ति मानिसहरूले छोड्ने पङ्क्ति हो। सर्भरले धकेलेको प्रिफिक्स, क्लाइन्ट प्रोफाइलले थपेको मार्ग र शेलमा टाइप गरिएको मार्ग कोले परिवर्तन गर्न सक्छ र पुनःजडानमा ती टिक्छन् कि भन्नेमा फरक पर्छ। त्यो क्षेत्र नभए अर्को इन्जिनियरले तीनमध्ये कुन हेरिरहेको छ भनी भन्न सक्दैन।
प्रत्येक नियमका लागि एक परीक्षण, प्रत्येक टनेलका लागि होइन
प्रत्येक पङ्क्तिलाई दुई हानिरहित जाँच चाहिन्छ: एउटा मार्ग अभ्यास गर्ने र एउटा नाम। मार्गका लागि, टनेल पार गर्नैपर्ने केही माग्नुहोस् र पुग्ने क्षमताको सट्टा मार्ग पुष्टि गर्नुहोस्, उदाहरणका लागि tracert -d 10.20.4.11 Windows मा वा ip route get 10.20.4.11 Linux मा। नामका लागि, निजी नामको क्वेरी गर्नुहोस् र कुन सर्भरले जवाफ दियो लेख्नुहोस्, टिप्पणीले उल्लेख गरेको रिजोल्भरविरुद्ध resolvectl query files.corp.example वा dig files.corp.example प्रयोग गरी।
नकारात्मक अपेक्षा पनि थप्नुहोस्: टनेल बन्द हुँदा के हुनुपर्छ। VPN बिना ब्लक सक्षम भएको Android वा iOS यन्त्रको बहिष्कृत अनुप्रयोगसँग कुनै जडान नहुन सक्छ, र डेस्कटप क्लाइन्टले टनेल पुनः जोडिँदै गर्दा त्यही अनुप्रयोग चलिराख्न दिन सक्छ। इच्छित जवाफ लेख्दा "VPN ले मेरो अनुप्रयोग बिगार्यो" जाँच्न सकिने भनाइ बन्छ।
अभिलेख कन्फिगरेसनसँगै राख्नुहोस्
टिप्पणी यसले वर्णन गर्ने प्रोफाइलको छेउमा भण्डारण गर्नुहोस् र त्यही प्रोफाइलसँग संस्करण दिनुहोस्। विकिमा रहेको कसैले अद्यावधिक नगर्ने कागजात अफवाह हो; धकेलेका मार्ग र रिजोल्भर नीति भएको उही भण्डारको तालिका उही परिवर्तनमा समीक्षा गर्न सकिन्छ।
केही बिग्रँदा, अर्को अपवाद थप्नु अघि लागू गरिएको मार्ग र प्रभावकारी रिजोल्भरलाई अभिलेखसँग तुलना गर्नुहोस्। तीन सामान्य कारणमध्ये दुई — पुरानो नामस्थान नियम र अनुप्रयोग नीतिबाहिरको सहायक प्रक्रिया — ठ्याक्कै VPN खराबीजस्तै देखिन्छन् र टिप्पणीले प्रिफिक्स मात्र सूचीबद्ध गरे अदृश्य हुन्छन्।
टिप्पणीलाई पूर्ण भन्नु अघि, यसले यी प्रश्नको लिखित जवाफ दिन्छ भनी पुष्टि गर्नुहोस्: कुन प्रिफिक्स, कुन ठेगाना परिवारका लागि; कुन निजी नामस्थान, कुन रिजोल्भरले जवाफ दिएको; कुन नाम जानीजानी सार्वजनिक रहन्छन्; प्रत्येक नियम कहाँ कन्फिगर छ र यसको मालिक को; र मार्ग प्रमाणित गर्ने एक आदेश र नाम प्रमाणित गर्ने एक आदेश। यीमध्ये केही छुट्यो भने अर्को घटनाको निदान शून्यबाट गरिनेछ।