Mac L2TP स्प्लिट रूट: होस्ट पता क्यों काम नहीं करता
setadditionalroutes को नेटवर्क और मास्क की जोड़ी चाहिए, पूरी सूची बदल देता है और शाब्दिक सेवा नाम चाहता है। गेटवे को दोष देने से पहले तालिका जाँचें।
VPN जुड़ता है, मेनू बार उसे दिखाता है, और कोई आंतरिक होस्ट फिर भी समय-सीमा पार कर जाता है। ऐसी स्थिति में तीन संभावित कारण होते हैं, और कौन-सा लागू है यह इस पर निर्भर करता है कि टनल कैसे कॉन्फ़िगर किया गया था। या तो रूट कमांड ने वहाँ होस्ट पता इस्तेमाल किया जहाँ नेटवर्क पता ज़रूरी था, या प्रोफ़ाइल स्वयं एक डिफ़ॉल्ट रूट स्थापित करती है जो निर्णय को निगल जाती है, या क्लाइंट PPP टनल है जिसे प्रोफ़ाइल कुंजी के बजाय हुक चाहिए। इन्हें इसी क्रम में जाँचें, क्योंकि पहले को बाहर करना सबसे सस्ता है।
गंतव्य नेटवर्क पता है, मास्क उपसर्ग का वर्णन करता है
networksetup -setadditionalroutes गंतव्य, सबनेट मास्क और गेटवे के त्रिक लेता है। जो कॉल एक आंतरिक सबनेट को टनल से भेजता है वह ऐसा दिखता है:
sudo networksetup -setadditionalroutes "VPN (L2TP)" 192.168.1.0 255.255.255.0 10.2.0.0
ध्यान दें कि गंतव्य क्या है: नेटवर्क पता, वह सर्वर पता नहीं जिस तक आप पहुँचना चाहते हैं। जिस मामले ने यह लेख पैदा किया, उसमें उस स्थान पर 192.168.1.20 के साथ वही कमांड कुछ उपयोगी नहीं कर पाई, और उसे 192.168.1.0 से बदलने पर तुरंत काम हो गया। वही मास्क, वही गेटवे, एक अलग संख्या। पूरी विफलता छोटे रूप में यही है।
कारण अंकगणित है, नीति नहीं। /24 मास्क के साथ जोड़ा गया होस्ट पता 192.168.1.0/24 का वर्णन नहीं करता; वह ऐसी चीज़ का वर्णन करता है जिसे रूटिंग तालिका उपयोगी रूप से नहीं रख सकती, इसलिए प्रविष्टि अस्वीकार या अनदेखी हो जाती है और टनल अंततः आपके इरादे से कम ढोता है।
जब आपको ठीक एक होस्ट चाहिए, तो होस्ट पता 255.255.255.255 मास्क के साथ उपयोग करें। मिश्रित जोड़ियाँ ही वह जगह हैं जहाँ यह गड़बड़ाता है, होस्ट पता का उपयोग स्वयं नहीं। एक पते से बना /32 वैध रूट है; एक पते से बना /24 गलती है।
कॉल सूची बदल देता है, और नाम शाब्दिक है
पहले प्रयास में दो व्यवहार लोगों को चौंकाते हैं। कमांड पूरी अतिरिक्त रूट सूची सेट करता है, जोड़ता नहीं, इसलिए एक उपसर्ग जोड़ने वाला कॉल पहले से मौजूद बाकी को चुपचाप हटा देता है। पूरा सेट एक ही कॉल में बनाएँ।
सेवा नाम भी वह लेबल नहीं है जो आपने गढ़ा था। इसे औज़ार से पढ़ें और प्रकार के प्रत्यय सहित ठीक वैसे ही कॉपी करें:
networksetup -listallnetworkservices
एक अक्षर से अलग नाम न पढ़ने लायक त्रुटि देता है न कोई रूट। यहाँ सही तकनीक कॉपी-पेस्ट है, स्मृति से फिर टाइप करना नहीं।
जब प्रोफ़ाइल डिफ़ॉल्ट रूट पर दावा करती है
स्प्लिट रूट किसी भी ऐसे गंतव्य के लिए डिफ़ॉल्ट रूट से हार जाते हैं जिसे वे स्पष्ट रूप से कवर नहीं करते, और पूर्ण टनल के लिए कॉन्फ़िगर एक L2TP प्रोफ़ाइल ठीक वही स्थापित करती है। यदि प्रोफ़ाइल कहती है कि सब कुछ टनल से जाता है, तो अतिरिक्त रूट सूची बहुत कम बदलती है। आपकी प्रविष्टि गलत नहीं है; वह उन गंतव्यों के लिए बस अप्रासंगिक है जिनका वह कभी नाम नहीं लेती। इसका नियंत्रण आमतौर पर किसी रूट कमांड में नहीं, बल्कि प्रोफ़ाइल की सारा ट्रैफ़िक भेजने की सेटिंग में होता है।
और प्रविष्टियाँ संपादित करने से पहले तय करें कि आप वास्तव में कौन-सा मॉडल चाहते हैं। अपवादों के साथ पूर्ण टनल विशिष्ट उपसर्गों वाले स्प्लिट टनल से अलग कॉन्फ़िगरेशन है, और दोनों को मिलाने से ऐसी तालिका बनती है जिसका कोई अनुमान नहीं लगा सकता।
यदि संगठन पूर्ण टनल मांगता है, तो उसे स्थानीय रूप से विभाजित करने की कोशिश बंद करें और आवश्यकता को नीति के मालिक तक ले जाएँ। स्थानीय रूप से जोड़ा गया रूट जो उसका विरोध करता है, अगले प्रोफ़ाइल अपडेट से वैसे भी हट जाएगा।
PPP टनल को कुंजी के बजाय हुक चाहिए
PPP-आधारित टनल के लिए, defaultroute वह प्रोफ़ाइल कुंजी है जो डिफ़ॉल्ट रूट बनाती है; इसे हटा दें और क्लाइंट हर गंतव्य पर दावा करना बंद कर देता है। फिर इंटरफ़ेस दिखने के बाद रूट जोड़े जाते हैं, आमतौर पर /etc/ppp/ip-up से:
#!/bin/sh
/sbin/route add -net 192.168.1.0 -interface ppp0
स्क्रिप्ट को root के स्वामित्व और निष्पादन योग्य रखें, और जब मशीन पर एक से अधिक टनल प्रोफ़ाइल हों तो इंटरफ़ेस नाम पर एक गार्ड जोड़ें। हर PPP लिंक के लिए चलने वाला और एक ही डिवाइस नाम मान लेने वाला हुक लंबी उम्र वाली छोटी बग है।
तीन अनुरोधों से विभाजन सत्यापित करें
जुड़े रहते हुए तालिका कैप्चर करें और नोट करें कि कौन-सा इंटरफ़ेस टनल की सेवा करता है। फिर विशिष्ट गंतव्य जाँचें, उसे बनाने वाले कमांड की निकास स्थिति पर भरोसा करने के बजाय। निकास कोड बताता है कि औज़ार ने तर्क स्वीकार किए या नहीं, यह नहीं कि ट्रैफ़िक आपके इरादे वाले रास्ते से जाता है।
तीन अनुरोधों के साथ समाप्त करें जो विभाजन साबित करें: पते से एक आंतरिक होस्ट, आंतरिक रिज़ॉल्वर के माध्यम से एक आंतरिक नाम, और एक सार्वजनिक साइट जिसे अभी भी स्थानीय कनेक्शन उपयोग करना चाहिए। यदि सार्वजनिक साइट अब टनल से भी जाती है, तो विभाजन कभी हुआ ही नहीं, रूट सूची चाहे जो कहे।
एक बार और फिर से कनेक्ट करें और आंतरिक अनुरोध दोहराएँ, क्योंकि हाथ से जोड़े गए रूट उस इंटरफ़ेस से अधिक जी सकते हैं जिसने उन्हें वैध बनाया और टनल गिरने के बाद ट्रैफ़िक को चुपचाप ब्लैकहोल में बदल सकते हैं।