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 डिफल्ट रुट पुनर्स्थापित गर्नुहोस्, हरेक प्रिफिक्स थप्नुहोस्, रिजोल्युसन छुट्टै सुधार्नुहोस्, र पुनः जडानमा रुटहरू फर्किने अपेक्षा गर्नुहोस्।