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