किन मात्र 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 विकल्प छाडेपछि कन्फिगर गरेको नाम सेवामा निर्भर छ, र चुपचाप असफल हुने त्यही हो।