फक्त 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, जे नोंदीला नावाने टनेलकडे निर्देश करते। आयातक ते रूपांतर भाषांतर करतात की नाही यात भिन्न आहेत, म्हणून कर्नेल सारणीत नोंद नसल्यास साठवलेले कनेक्शन तपासा।
ping ने नाही, मार्ग शोधांनी तपासा
ping सांगतो की काहीतरी उत्तर दिले। मार्ग शोध सांगतो की कर्नेल कोणता इंटरफेस निवडेल, आणि तोच प्रश्न तुम्ही प्रत्यक्षात विचारला होता। चार छोट्या आदेशांनी गहाळ मार्ग आणि चुकीच्या उपकरणाकडे निर्देश करणारा मार्ग वेगळा होतो।
ip route show dev tun0 ने टनेलने काय इन्स्टॉल केले ते वाचा। अजिबात आउटपुट नसणे म्हणजे शून्य मार्ग, जो कार्यरत स्प्लिट टनेल नाही, आणि स्पष्ट ओळीशिवाय फिल्टर जोडण्याचा हा नेहमीचा परिणाम आहे।
नंतर ip route get 10.30.5.7 ने एक कार्यालयीन पत्ता आणि ip route get 1.1.1.1 ने एक सामान्य इंटरनेट पत्ता तपासा। दुसऱ्याने भौतिक इंटरफेसचे नाव दिले पाहिजे; जर तो टनेलचे नाव देत असेल, तर ढकलणे अजिबात गाळले गेले नाही।
शेवटी ip rule वाचा, कारण पूर्वीच्या प्रयत्नाने सोडलेला धोरण नियम तुम्ही नुकतीच दुरुस्त केलेल्या सारणीवर मात करू शकतो। वर जुना नियम असलेली बरोबर प्रोफाइल तंतोतंत तुटलेल्या प्रोफाइलसारखी दिसते। दुसरा जोडण्यापूर्वी गेल्या वेळी जोडलेला नियम हटवा।
एकमेकांवर चढणारे सबनेट तुटलेल्या टनेलसारखे दिसतात
क्लायंटच्या दृष्टिकोनातून दोन खाजगी श्रेणी सारख्याच असू शकतात, आणि तिथेच स्प्लिट टनेलवर त्याने केले नसलेल्या गोष्टीचा दोष मढला जातो। कार्यालय तुमच्या घरातील राउटर वापरत असलेला तोच उपसर्ग देत असेल, तर टनेल मार्ग राउटरवर पसरतो आणि घरातील नेटवर्क गायब झाल्यासारखे दिसते।
काहीही बदलण्यापूर्वी साधी पत्ता यादी वापरून तुमच्या इंटरफेसवरील पत्त्याची प्रोफाइल इन्स्टॉल करणाऱ्या मार्गाशी तुलना करा। ओव्हरलॅप खरा आहे, आणि कोणताही प्रोफाइल पर्याय तो सोडवत नाही। तुम्ही दुरुस्त करू शकता ते नामकरण, जेणेकरून पुढील व्यक्तीला एकाऐवजी दोन श्रेणी दिसतील।
प्रामाणिक उपाय म्हणजे एक बाजू पुन्हा क्रमांकित करणे किंवा कार्यालयात पत्ते भाषांतरित करणे। एकच यजमान मार्ग राउटरला पिन करणे राउटरचा पत्ता बदलल्याशिवाय चालते, आणि नंतर ते पहिल्यावर दुसरे कोडे बनते।
निर्णय पुन्हा कनेक्ट होण्यापर्यंत टिकून राहील असे करा
हाताने टाइप केलेल्या नोंदी पुन्हा कनेक्ट होण्यापर्यंत टिकत नाहीत, आणि कनेक्शन मॅनेजर प्रोफाइल सुरू होताना प्रत्येक वेळी सारणी पुन्हा बांधतो। निर्णय तिथे ठेवा जिथे कनेक्शन तयार होते, मग ते प्रोफाइल असो वा मॅनेजरची साठवलेली सेटिंग्ज। नंतर कॉल दरम्यान वर्तन शोधण्याऐवजी एकदा मुद्दाम कनेक्शन पुन्हा सुरू करा। जी प्रोफाइल पुढील पुन्हा कनेक्ट होण्यापर्यंतच चालते ती पूर्ण नाही।
एकाच वेळी तीन मार्ग तपासा: शब्दशः पत्त्याने कार्यालयीन यजमान, नावाने तोच यजमान, आणि एक सामान्य सार्वजनिक साइट। मधला तुम्ही ढकललेले DNS पर्याय सोडल्यानंतर संरचित केलेल्या नाव सेवेवर अवलंबून आहे, आणि शांतपणे अयशस्वी होणारा तोच आहे।