टनल ऊपर आता है, एप्लिकेशन लोड होता है, और फिर लैपटॉप पर बाकी सब कुछ अजीब व्यवहार करने लगता है। एक पंक्ति हटाकर लागू की गई केवल-निजी नीति की यही सामान्य शक्ल है। धकेला गया डिफ़ॉल्ट रूट हटाना वाकई बदलता है कि ट्रैफ़िक कहाँ जाता है, लेकिन यह नहीं बताता कि ट्रैफ़िक को इसके बजाय कहाँ जाना चाहिए, और यह नाम-समाधान को बिल्कुल नहीं छूता। परीक्षण से पहले नीति के दो सकारात्मक आधे हिस्से चाहिए।

रीडायरेक्ट हटाना बदलाव का केवल आधा है

पूर्ण-टनल रीडायरेक्ट और केवल-निजी नीति इस बात में भिन्न हैं कि वे दुनिया के बारे में क्या दावा करते हैं। रीडायरेक्ट हर गंतव्य का दावा करता है, जबकि निजी नीति एक सूची का दावा करती है और बाकी को अकेला छोड़ देती है। सूची लिखे बिना दावा हटाने से ऐसा क्लाइंट बनता है जो LAN के बाहर कहीं नहीं पहुँचता, जो नीति की कमी से ज़्यादा रूटिंग विफलता जैसा दिखता है। दावा हटाने से पहले सूची लिखें, और फिर उन दो चरणों का क्रम मायने रखना बंद कर देता है।

दोनों आधे डिफ़ॉल्ट नहीं बल्कि आवश्यकताएँ हैं। निजी प्रीफ़िक्स को टनल में प्रवेश करना होगा, और सामान्य गंतव्यों को वह पथ बनाए रखना होगा जो उनके पास कनेक्शन से पहले था।

यदि कोई संगठन पूर्ण टनल अनिवार्य करता है, तो इसमें से कुछ भी लागू नहीं होता। केवल-निजी डिज़ाइन उन परिनियोजनों का है जहाँ विभाजित रूटिंग स्वीकृत है।

pull-filter एक मिलान है, स्विच नहीं

pull-filter निर्देश उन धकेले गए विकल्पों को हटाता है जिनके नाम किसी प्रीफ़िक्स से मेल खाते हैं, और बस इतना ही करता है। रीडायरेक्ट को अनदेखा करने पर हर दूसरा धकेला गया विकल्प अपनी जगह रहता है, जो आमतौर पर वही है जो आप चाहते हैं: रूट, DNS सेटिंग्स और रूट-गेटवे मान अब भी आते हैं। यह स्थानीय प्रोफ़ाइल में लिखा निर्देश भी नहीं हटा सकता, क्योंकि फ़िल्टरिंग उस पर लागू होती है जो सर्वर धकेलता है।

route से शुरू होने वाले हर विकल्प को अनदेखा करने के प्रलोभन का विरोध करें। वह पैटर्न उन निजी रूटों को भी फेंक देता है जिनकी कनेक्शन को ज़रूरत है, और यह उस गेटवे जानकारी को गिरा सकता है जिस पर टनल निर्भर है।

route-nopull दिखने से ज़्यादा बड़ा निर्णय है। यह क्लाइंट को धकेले गए रूटों और DHCP-शैली के विकल्पों को समूह के रूप में स्वीकार करने से रोकता है, जो एक विकल्प फ़िल्टर करने से भिन्न नीति है।

एप्लिकेशन से बाहर की ओर रूट सूची लिखें

उससे शुरू करें जो उपयोगकर्ता वास्तव में खोलता है, फिर सहायक हिस्से जोड़ें। 10.60.20.15 पर एक एप्लिकेशन अपने सबनेट 10.60.0.0/16 को इंगित करता है, और निजी नाम उस समाधायक को इंगित करता है जो उसका उत्तर देता है। इसलिए जिस उपयोगकर्ता ने एक एप्लिकेशन माँगा है उसे दो गंतव्य और एक DNS निर्णय चाहिए। उस सूची से आगे का सब कुछ रचना से ही दायरे से बाहर है, और यही नीति को समीक्षायोग्य रखता है।

सहयोगी सर्वर पर वे दो धकेले गए रूट बन जाते हैं, और उनमें से कोई भी रीडायरेक्ट नहीं है। मौजूदा सेवा जो टनल टोपोलॉजी और रूट-गेटवे मान देती है उन्हें बनाए रखें।

जब केवल कुछ उपयोगकर्ताओं को यह नीति चाहिए, तो इसे प्रति क्लाइंट या प्रति समूह लागू करें। एक टीम की आवश्यकता ठीक करने के लिए सबका रूटिंग बदलना वही तरीका है जिससे विभाजित टनल व्यवधान बन जाता है।

DestinationIntended path
10.60.0.0/16Tunnel, for the approved application services
10.61.0.53/32Tunnel, to reach the internal resolver
corp.example queriesInternal resolver, selected per namespace
Everything elseLocal path and local resolver

DNS को वही पथ अपनाने दें

समाधायक तक का रूट समाधायक नीति नहीं है। systemd-resolved क्लाइंट पर अर्थपूर्ण परिणाम निजी नामस्थान के लिए एक रूटिंग डोमेन है जो आंतरिक समाधायक की ओर इशारा करता है, और यही उन नामों को ही उसका उपयोग करवाता है। Windows क्लाइंट को इसके बजाय अपना नामस्थान नीति तंत्र चाहिए। प्रोफ़ाइल में DNS सर्वर की एक पंक्ति अपने आप इनमें से कुछ भी स्थापित नहीं करती।

देखें ऑपरेटिंग सिस्टम ने क्या चुना, न कि प्रोफ़ाइल ने क्या माँगा। Linux पर resolvectl status प्रति-लिंक डोमेन और सर्वर दिखाता है; Windows पर नामस्थान नीति तालिका समतुल्य प्रमाण है।

समाधायक को टनल से पहुँच योग्य रखें, वरना नीति ऐसे पते की ओर इशारा करती है जिससे पूछा नहीं जा सकता। ऐसा समाधायक पता जहाँ तक टनल नहीं पहुँचती, काम करती नीति को समय-सीमा में बदल देता है।

पुनः कनेक्शन पर दोनों आधे जाँचें

बदलाव के बाद क्लाइंट को फिर से जोड़ें और निजी पते तथा सार्वजनिक पते तक प्रभावी रूट देखें। फिर एक निजी नाम और एक सार्वजनिक नाम हल करें और पुष्टि करें कि हर एक ने इच्छित समाधायक का उपयोग किया। किसी सार्वजनिक वेबसाइट का लोड होना केवल दूसरा आधा सिद्ध करता है, और आमतौर पर वही आधा संयोग से काम करता है।

तैयार नीति को एक वाक्य में दर्ज करें: ये प्रीफ़िक्स और नाम इस कनेक्शन का उपयोग करते हैं, बाकी सब स्थानीय पथ का अनुसरण करता है। फिर हर लॉगिन के बाद एडाप्टर सेटिंग्स ठीक करने के बजाय इसे प्रोफ़ाइल में रखें।

संबंधित लेख