FortiClient पूर्ण टनल: केवल ऑफ़िस सबनेट रूट करें

टनल ऊपर आता है, आइकन हरा हो जाता है और स्थानीय नेटवर्क गायब हो जाता है: प्रिंटर, NAS और ऑफ़िस राउटर सभी जवाब देना बंद कर देते हैं। FortiClient वही कर रहा है जो प्रोफ़ाइल ने माँगा था। गेटवे ने डिफ़ॉल्ट रूट भेजा, क्लाइंट ने उसे इंस्टॉल किया, और अब हर पैकेट का टनल में जाने का रास्ता है। मरम्मत रूट-तालिका का एक संपादन है जिसके पीछे DNS का संपादन है, और इन संपादनों का क्रम तय करता है कि मशीन अंत में बेहतर रहेगी या बदतर।

क्लाइंट ने क्या इंस्टॉल किया, और LAN क्यों गायब हुआ

क्लाइंट इंटरफ़ेस के बजाय तालिका पढ़कर शुरू करें। macOS पर netstat -rn पूरी तालिका छापता है और route -n get default उस इंटरफ़ेस और मीट्रिक का नाम बताता है जो अभी जीत रहे हैं; Linux पर जोड़ी ip route show और ip route get 8.8.8.8 है। दोनों एक ही सवाल का जवाब देते हैं: कौन-सी प्रविष्टि ऐसे पैकेट को ले जाएगी जो किसी अधिक विशिष्ट चीज़ से मेल नहीं खाता।

टनल डिवाइस का नाम स्थिर नहीं है। macOS पर IKEv2 प्रोफ़ाइल आमतौर पर संख्या के साथ utun दिखाती है, SSL VPN क्लाइंट ppp0 दिखाता है, और OpenVPN tun0 दिखाता है। अलग-अलग मीट्रिक के साथ दो डिफ़ॉल्ट रूट एक ही समय पर भी मौजूद हो सकते हैं, और क्लाइंट प्रविष्टि शायद फिर से कनेक्ट होने के बाद ही नियंत्रण ले, दिखने के पल में नहीं। इसलिए पाँच मिनट के अंतर पर लिए गए दो तालिका डंप अलग-अलग कहानियाँ बता सकते हैं।

टनल डिफ़ॉल्ट रूट को पहले क्यों जाना चाहिए

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

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

macOS और Linux पर क्रम

macOS पर यह क्रम टनल डिफ़ॉल्ट हटाता है, भौतिक डिफ़ॉल्ट बहाल करता है और एक ऑफ़िस प्रीफ़िक्स वापस टनल में भेजता है। यहाँ दिए उदाहरण इंटरफ़ेस नामों को अपनी तालिका वाले नामों से बदलें।

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

Linux पर वही क्रम दूसरा उपकरण इस्तेमाल करता है: डिफ़ॉल्ट के लिए LAN गेटवे और ऑफ़िस प्रीफ़िक्स के लिए टनल डिवाइस। पुराना route कमांड अब भी पुराना सिंटैक्स स्वीकार करता है, लेकिन ip route वह रूप है जो वर्तमान दस्तावेज़ों से मेल खाता है।

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

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

प्रीफ़िक्स, रिज़ॉल्वर और अंधेरे में रहने वाला DMZ

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

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

Linux SSL क्लाइंट में एक फ़ील्ड-विशिष्ट विफलता है जिसे जानना चाहिए: टनल जुड़ता है, ऑफ़िस LAN जवाब देता है, और एक DMZ रेंज अंधेरे में रह जाती है। छूटा हुआ टुकड़ा टनल गेटवे से उस रेंज के लिए एक रूट है, और गेटवे मशीन के अनुसार बदलता है, इसलिए हार्ड-कोड किया गया पता ही वह तरीका है जिससे अगला लैपटॉप टूटता है। इसे क्लाइंट की स्थिति से निकालें और कमांड को स्व-दस्तावेजी रखें:

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

चलाने से पहले दोनों मान पढ़ें। peer पॉइंट-टू-पॉइंट टनल का दूर का सिरा है, और वही वह पता है जिसकी DMZ रूट को ज़रूरत है; रूटेड टनल में समकक्ष वह इंटरफ़ेस या गेटवे है जिसकी रिपोर्ट क्लाइंट करता है। अगर दोनों में से कोई न दिखे, तो क्लाइंट उस मोड में नहीं है जो आपने माना था।

अगले कनेक्शन के बाद, और इसे स्थानीय रूप से कब बंद करें

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

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

जाँच-सूची छोटी है: तालिका पढ़ें, टनल डिफ़ॉल्ट हटाएँ, LAN डिफ़ॉल्ट बहाल करें, हर प्रीफ़िक्स जोड़ें, रिज़ॉल्यूशन अलग से ठीक करें, और उम्मीद करें कि फिर से कनेक्ट होने पर रूट लौट आएँगे।