टनल का /32 कॉपी करने से ऑफ़िस सबनेट रूट नहीं होगा
VPN आपके एडाप्टर को जो पता देता है वह लिंक का वर्णन करता है, गंतव्य का नहीं। प्रोफ़ाइल में संसाधन प्रीफ़िक्स जोड़ें और डिफ़ॉल्ट को अछूता छोड़ दें।
VPN जुड़ता है, इंटरफ़ेस बत्तीस-बिट मास्क वाला पता दिखाता है, और ऑफ़िस सर्वर पहुँच से बाहर रहता है। अगला कदम अक्सर वही मास्क किसी रूट में दोबारा इस्तेमाल करना होता है, इस धारणा पर कि इंटरफ़ेस बताता है कि टनल कहाँ तक पहुँच सकता है। ऐसा नहीं है। वह पता पॉइंट-टू-पॉइंट लिंक के स्थानीय सिरे का वर्णन करता है, और जिस गंतव्य की आपको चिंता है वह उसके दूसरी ओर किसी दूसरे प्रीफ़िक्स में रहता है।
दो अलग चीज़ें मिलाई जा रही हैं: टनल ने आपको जो पता दिया, और जिस नेटवर्क तक आप उसके ज़रिए पहुँचना चाहते हैं।
दो पते, दो काम
पॉइंट-टू-पॉइंट टनल में क्लाइंट का पता अक्सर एक ही होस्ट पता होता है क्योंकि लिंक के दूसरे सिरे पर ठीक एक साथी होता है। कोई साझा सेगमेंट नहीं है और ARP नहीं है, इसलिए जो मास्क Ethernet पर बेतुका लगेगा वह यहाँ पूरी तरह सामान्य है।
गंतव्य प्रीफ़िक्स ऑफ़िस नेटवर्क के बारे में तथ्य है, टनल के बारे में नहीं। अगर आपको एक सर्वर चाहिए, तो रूट उस सर्वर के लिए होस्ट रूट है। अगर आपको पूरा ऑफ़िस सबनेट चाहिए, तो रूट वह सबनेट है। इनमें से कोई भी उत्तर इंटरफ़ेस से नहीं पढ़ा जा सकता, और किसी एक को इसलिए चुनना कि वह टनल पते के पास दिखा था, यही काम करती सेटिंग को तोड़ने का तरीका है।
| What you need to reach | What to install |
|---|---|
| One server, nothing else | A host route for that address |
| The office subnet | A route for the subnet prefix |
| Everything in the private space | Only if the requirement says so, and only with the owner's approval |
वही तीसरी पंक्ति वह जगह है जहाँ आशावाद ठप्पे में बदल जाता है। पूरे निजी दायरे को ऐसी टनल में रूट करना जो सिर्फ़ एक साइट की सेवा करती है, असंबंधित ट्रैफ़िक को ऐसे रास्ते पर धकेलता है जो उसे पहुँचा नहीं सकता, और परिणामी विफलताएँ टूटे VPN जैसी दिखती हैं, ज़्यादा चौड़े रूट जैसी नहीं।
ज़रूरत से प्रीफ़िक्स चुनें
प्रोफ़ाइल छूने से पहले ज़रूरत को एक वाक्य में लिखें: किन होस्ट तक पहुँच होनी चाहिए, और उन्हें ढकने वाला सबसे संकरा प्रीफ़िक्स कौन-सा है? एक सर्वर होस्ट रूट है। एक सबनेट सबनेट रूट है। सबनेट का दायरा एक सारांश है, और सारांश यह वादा है कि उसके भीतर हर पता पहुँच-योग्य है, जो कम ही सच होता है।
फिर संख्या को ऑफ़िस के वास्तविक उपयोग से मिलाएँ। साइट की एड्रेसिंग योजना से पुष्टि किए बिना चैट संदेश से प्रीफ़िक्स कॉपी करना ही वह तरीका है जिससे रूट ऐसे सबनेट की ओर इशारा करने लगता है जिसका कोई मालिक नहीं।
यह भी याद रखें कि रूट एक रास्ता है, अनुमति नहीं। गेटवे अब भी तय करता है कि आपका क्लाइंट गंतव्य का उपयोग कर सकता है या नहीं, और कोई सेवा अब भी आपको मना कर सकती है। रूट सही ढंग से इंस्टॉल करने से पैकेट वहाँ पहुँच जाता है और अधिकृति के बारे में कुछ नहीं कहता।
प्रोफ़ाइल में जोड़ें, उसे कभी बदलें नहीं
NetworkManager प्रोफ़ाइल में रूट बहुमान गुण हैं, और सेट करने तथा जोड़ने के बीच का अंतर एक अक्षर है। एंट्री जोड़ने और पहले से सहेजा सब कुछ बनाए रखने के लिए प्लस रूप का उपयोग करें।
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"प्लस के बिना, असाइनमेंट पूरी सूची बदल देता है। जिस प्रोफ़ाइल में पहले से कई प्रीफ़िक्स हैं, वहाँ यह चुपचाप काम करने वाले प्रीफ़िक्स मिटा देता है, और लक्षण बाद में ऐसी सेवा के रूप में आता है जो पहले इस लैपटॉप से पहुँच-योग्य थी।
नाम के बजाय UUID का उपयोग करें। बहाली के बाद नाम दोहराए जाते हैं, और जिस कनेक्शन को आप संपादित कर रहे हैं वह शायद आपका ट्रैफ़िक ले जाने वाला न हो। पहले जाँचें कि कोई मौजूदा समान एंट्री है या नहीं, क्योंकि नकल जोड़ना हानिरहित होने पर भी बेतरतीब है।
यह रूट गुण संदर्भ इंस्टॉल किए गए संस्करण के लिए गंतव्य, वैकल्पिक अगला हॉप, मीट्रिक और विशेषता सिंटैक्स का दस्तावेज़ीकरण करता है। अगला हॉप जोड़ने से पहले इसे पढ़ें, क्योंकि इसकी आवश्यकता इंटीग्रेशन और टोपोलॉजी पर निर्भर करती है, और इंटरफ़ेस सूची के पहले पते से इसका अनुमान लगाना कोई तरीका नहीं है।
डिफ़ॉल्ट रूट और DNS अलग निर्णय हैं
Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.
स्वचालित रूट दूसरी चीज़ है जिसे लापरवाही से नहीं छेड़ना चाहिए। एक गायब एंट्री हल करने के लिए उन्हें दबाने से कई काम करने वाली एंट्री हट सकती हैं, और जिसने इसे सुझाया वह आमतौर पर अलग पुश वाली दूसरी प्रोफ़ाइल देख रहा था।
DNS का अपना रास्ता और अपनी विफलताएँ हैं। गलत रिज़ॉल्वर से सही पते पर हल होने वाला नाम, या ऐसा रिज़ॉल्वर जो निजी ज़ोन के लिए उत्तर नहीं दे सकता, रूट के सही होने पर भी रूटिंग समस्या जैसा दिखेगा। पते और नाम को अलग-अलग जाँचें, फिर तय करें कि कौन-सी परत वास्तव में विफल हुई।
जाँचें कि क्या लागू हुआ
सहेजा गया बदलाव लागू किया गया बदलाव नहीं है। मैनेजर के समर्थित जीवनचक्र से फिर से कनेक्ट करें, फिर इच्छित गंतव्य के वास्तविक रूट और यह तय करने वाले नीति नियमों को देखें कि कौन-सी तालिका देखी जाती है।
अगर प्रीफ़िक्स वहाँ है और कनेक्शन फिर भी विफल होता है, तो आप दूसरी समस्या पर आ गए हैं: स्रोत पता चयन, दूर के सिरे पर वापसी रूट, या ऐसी सेवा जो आपके क्लाइंट को मना करती है। इनमें से हर एक उस प्रोफ़ाइल से देखने की बेहतर जगह है जिसे आप पहले ही ठीक कर चुके हैं।