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 डीफॉल्ट रूट पुनर्संचयित करा, प्रत्येक प्रीफिक्स जोडा, रिझोल्यूशन वेगळे दुरुस्त करा आणि पुन्हा जोडल्यावर राउट परत येतील अशी अपेक्षा ठेवा.