केवल route-nopull फ़ाइल सर्वर को पहुँच से बाहर क्यों छोड़ देता है
धकेले गए रूट को अनदेखा करना स्प्लिट टनल का आधा हिस्सा भर है। रूट का मालिक चुनें, ऑफ़िस प्रीफ़िक्स हाथ से जोड़ें और इसे ठीक कहने से पहले तीन प्रवाह जाँचें।
फ़ाइल सर्वर ठीक खुलता है, और बगल की खिड़की में वीडियो कॉल अटकने लगती है। कुछ भी धीमा नहीं है और कोई MTU ग़लत नहीं है: आपके क्लाइंट ने सर्वर की दी हुई रूट सूची स्वीकार कर ली, इसलिए अब हर पैकेट ऑफ़िस फ़ायरवॉल से बाहर जाता है। समाधान कोई और ट्यूनिंग फ़्लैग नहीं, बल्कि यह फ़ैसला है कि क्लाइंट की रूट तालिका का मालिक कौन है। वह फ़ैसला एक ही जगह का है, और नीचे दी गई विफलता के तरीके बताते हैं कि आपने असल में कौन-सी जगह चुनी।
तय करें कि रूट तालिका का मालिक कौन है
तीन मालिक संभव हैं। सर्वर रूट और डिफ़ॉल्ट गेटवे धकेल सकता है, जिस स्थिति में क्लाइंट वही स्थापित करता है जो उसे कहा जाए और पूरी टनल बन जाता है। क्लाइंट प्रोफ़ाइल धकेल को छोड़कर और अपनी रूट पंक्तियाँ लेकर मालिकाना ले सकती है। डेस्कटॉप कनेक्शन प्रबंधक भी अपने रूट और डिफ़ॉल्ट-रूट गुणों के ज़रिए फ़ैसले का मालिक हो सकता है।
हर विकल्प अलग तरह से विफल होता है, इसीलिए प्रोफ़ाइल संपादित करने से पहले तालिका पढ़ना उचित है। जो पंक्ति आपके लक्षण से मेल खाती है, वही वह मालिक है जो आपके पास असल में है।
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
एक चुनें और लिख लें। दो को मिलाना ऐसा होस्ट छोड़ता है जिसका डिफ़ॉल्ट मार्ग उसके अपने दस्तावेज़ का विरोध करता है, और अगला इंजीनियर यह नहीं बता सकता कि कौन-सी परत जीती। हारने वाले को स्पष्ट रूप से हटा दें।
route-nopull धकेल को छानता है, रूट जोड़ता नहीं
route-nopull क्लाइंट प्रोफ़ाइल में आता है, और उस फ़ाइल में उसका क्रम महत्वहीन है क्योंकि वह केवल सर्वर से आने वाले मानों को छोड़ता है। वह धकेले गए रूट छोड़ता है, धकेला गया डिफ़ॉल्ट रूट भी, जबकि टनल सामान्य रूप से ऊपर आती है।
जो परिणाम लोग चूक जाते हैं वह यह है कि धकेले गए DHCP विकल्प उनके साथ चले जाते हैं। सर्वर द्वारा भेजी गई DNS सेटिंग्स भी छोड़ दी जाती हैं, इसलिए आंतरिक नाम हल होना बंद कर देते हैं, भले ही टनल स्वस्थ हो और सर्वर पते से पहुँच में हो।
इससे ऑफ़िस प्रीफ़िक्स तक मार्ग न रखने वाली टनल बचती है, जब तक आप स्वयं एक न जोड़ें: उसी प्रोफ़ाइल में route-nopull के बाद route 10.30.0.0 255.255.0.0। वह पंक्ति पता और मास्क रखती है; वह अगले हॉप का नाम नहीं देती।
एक वैकल्पिक रूप गेटवे टोकन जोड़ता है, route 10.30.0.0 255.255.0.0 vpn_gateway, जो प्रविष्टि को नाम से टनल की ओर इंगित करता है। आयातक इस बात में भिन्न हैं कि वे उस रूपांतर का अनुवाद करते हैं या नहीं, इसलिए यदि प्रविष्टि कर्नेल तालिका से ग़ायब है तो संग्रहीत कनेक्शन जाँचें।
पिंग से नहीं, रूट लुकअप से सत्यापित करें
पिंग बताता है कि किसी ने उत्तर दिया। रूट लुकअप बताता है कि कर्नेल कौन-सा इंटरफ़ेस चुनेगा, और यही वह सवाल है जो आपने असल में पूछा था। चार छोटे आदेश ग़ायब रूट को ग़लत डिवाइस की ओर इशारा करने वाले रूट से अलग करते हैं।
ip route show dev tun0 के साथ पढ़ें कि टनल ने क्या स्थापित किया। बिलकुल आउटपुट न होना शून्य रूट का अर्थ है, जो काम करती स्प्लिट टनल नहीं है, और स्पष्ट पंक्ति के बिना फ़िल्टर जोड़ने का यही सामान्य परिणाम है।
फिर ip route get 10.30.5.7 से एक ऑफ़िस पता जाँचें, और ip route get 1.1.1.1 से एक सामान्य इंटरनेट पता। दूसरे को भौतिक इंटरफ़ेस का नाम बताना चाहिए; अगर वह टनल का नाम बताए, तो धकेल बिलकुल नहीं छना।
अंत में ip rule पढ़ें, क्योंकि किसी पुराने प्रयास द्वारा छोड़ा गया नीति नियम उस तालिका को पछाड़ सकता है जिसे आपने अभी ठीक किया है। ऊपर पुराने नियम वाली सही प्रोफ़ाइल बिलकुल टूटी प्रोफ़ाइल जैसी दिखती है। दूसरा जोड़ने से पहले पिछली बार जोड़ा गया नियम हटाएँ।
अतिव्यापी सबनेट टूटी टनल जैसे दिखते हैं
क्लाइंट की दृष्टि से दो निजी रेंज एक जैसी हो सकती हैं, और वहीं स्प्लिट टनल पर ऐसी बात का दोष मढ़ा जाता है जो उसने नहीं की। अगर ऑफ़िस वही प्रीफ़िक्स देता है जो आपका घरेलू राउटर इस्तेमाल करता है, तो टनल रूट राउटर को ढक लेता है और घरेलू नेटवर्क ग़ायब दिखने लगता है।
कुछ भी बदलने से पहले सादी पता सूची का उपयोग करके अपने इंटरफ़ेस के पते की तुलना प्रोफ़ाइल द्वारा स्थापित रूट से करें। अतिव्यापन वास्तविक है, और कोई प्रोफ़ाइल विकल्प उसे हल नहीं करता। आप नामकरण ठीक कर सकते हैं, ताकि अगला व्यक्ति एक के बजाय दो रेंज देखे।
ईमानदार सुधार हैं एक पक्ष को फिर से क्रमांकित करना या ऑफ़िस में पतों का अनुवाद करना। एक ही होस्ट रूट को राउटर पर पिन करना तब तक काम करता है जब तक राउटर का पता न बदले, और फिर वह पहले के ऊपर दूसरा रहस्य बन जाता है।
फ़ैसले को पुनः कनेक्शन तक टिकाएँ
हाथ से टाइप की गई प्रविष्टियाँ पुनः कनेक्शन तक नहीं टिकतीं, और कनेक्शन प्रबंधक हर बार प्रोफ़ाइल शुरू होने पर तालिका फिर से बनाता है। फ़ैसला वहाँ रखें जहाँ कनेक्शन बनता है, चाहे वह प्रोफ़ाइल हो या प्रबंधक की संग्रहीत सेटिंग्स। फिर कॉल के दौरान व्यवहार खोजने के बजाय एक बार जान-बूझकर कनेक्शन फिर से शुरू करें। जो प्रोफ़ाइल केवल अगले पुनः कनेक्शन तक काम करती है, वह पूरी नहीं है।
एक साथ तीन मार्ग आज़माएँ: शाब्दिक पते से एक ऑफ़िस होस्ट, नाम से वही होस्ट, और एक सामान्य सार्वजनिक साइट। बीच वाला उस नाम सेवा पर निर्भर है जिसे आपने धकेले गए DNS विकल्प छोड़ने के बाद सेट किया था, और चुपचाप विफल होने वाला वही है।