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