दोस्रो VPN सुरुङले पहिलोलाई किन भाँच्छ?

एउटा ग्राहक सञ्जालसम्म पुग्न दोस्रो VPN क्लाइन्ट स्थापना गर्नु यो सुरु हुने सामान्य तरिका हो, र दुवै क्लाइन्ट सफलता रिपोर्ट गर्दै गर्दा पहिलो सुरुङ अँध्यारो हुन्छ। हरेक क्लाइन्टले पूर्वनिर्धारित मार्ग स्थापना गर्यो, दोस्रो बढी विशिष्ट थियो, र कर्नेल अब पहिलो सुरुङको आफ्नै बाह्य जडानबाहेक सबैका लागि त्यही पछ्याउँछ। केही पनि भत्किएन र कुनै प्रोफाइल गलत छैन। एउटा मार्गले अर्कोलाई प्रतिस्थापन गर्यो, र समाधान भनेको कुन सुरुङले पूर्वनिर्धारितको मालिक हुनुपर्ने हो भन्ने निर्णय गर्नु हो।

लक्षण: दोस्रो क्लाइन्ट चुपचाप जित्छ

OpenVPN: redirect-gateway def1 विकल्पले 0.0.0.0/0 लाई पुनर्लेखन गर्दैन। यसले 0.0.0.0/1 र 128.0.0.0/1 थप्छ: दुवै मिलेर हरेक IPv4 ठेगाना ढाक्छन्, र हरेक प्रिफिक्स लम्बाइमा साधारण पूर्वनिर्धारितलाई हराउँछ। मूल पूर्वनिर्धारित तालिकामा रहन्छ र सामान्य ट्राफिकका लागि प्रयोग हुन छोड्छ, र VPN सर्भरतर्फको होस्ट मार्गले सुरुङलाई आफ्नै बाह्य प्याकेट समात्नबाट रोक्छ। दुवै क्लाइन्टले यसो गर्छन्, र दोस्रोले आफ्नो जोडी पछि स्थापना गर्छ।

त्यसैले पहिलो सुरुङ विच्छेद नभई मृत देखिन्छ। यसको इन्टरफेस माथि छ, यसको नियन्त्रण च्यानल जीवित छ, र अब कुनै अनुप्रयोग ट्राफिक यससम्म पुग्दैन। उल्टो गुनासो पनि त्यही हराएको push बाट आउँछ: जोडिने तर केही नपठाउने फोन सामान्यतया कहिल्यै redirect-gateway घोषणा नगरेको सर्भरसँग कुरा गर्छ, त्यसैले उपकरणले आफ्नै पूर्वनिर्धारित राख्छ र पूलसम्म मात्र पुग्छ।

दोस्रो क्लाइन्ट जोडिनुअघि र पछि राउटिङ स्न्यापसट लिनुहोस्। तालिकामा देखिने दुई आधा मार्ग नै सम्पूर्ण परिवर्तन हुन्, र तिनले दुवै गुनासो व्याख्या गर्छन्। लक्षण देखिन तालिकामा अरू केही सर्नु आवश्यक छैन। त्यसैले दोस्रो क्लाइन्ट हटाउँदा पहिलो तुरुन्तै पुनर्स्थापित हुन्छ।

कुन सुरुङले साँच्चै जित्छ पढ्नुहोस्

क्लाइन्ट कुन क्रममा सुरु भए वा ट्रेको आइकनबाट विजेता अनुमान नगर्नुहोस्। दुवै निजी सञ्जालबाहिरको गन्तव्यका लागि कर्नेलले कुन मार्ग प्रयोग गर्छ सोध्नुहोस्, र फर्किएको इन्टरफेस पढ्नुहोस्।

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

पहिलो दुई लिनक्सको उत्तर र अन्तिम दुई विन्डोजको समतुल्य हुन्। दुवै सुरुङ माथि हुँदा तिनीहरू चलाउनुहोस्, त्यसपछि एउटा विच्छेद गरी फेरि चलाउनुहोस्। दुई आउटपुटबीचको फरक नै समाधान छान्नुअघि आवश्यक तथ्य हो, र यो कुनै पनि क्लाइन्टको लग पढ्नभन्दा कम समय लिन्छ।

नतिजा लेख्नुहोस्, इन्टरफेसको नाम र मिलेको प्रिफिक्स सहित। दोस्रो VPN ले पहिलोलाई भाँच्यो भन्ने टिकट लक्षणको वर्णन हो, कोहीले कार्य गर्न सक्ने राउटिङ भनाइ होइन। खोजले यसलाई अर्को इन्जिनियरले एउटै आदेशमा दोहोर्याउन सक्ने तथ्यमा बदल्छ।

विन्डोज: एउटा प्रोफाइललाई पूर्वनिर्धारितको मालिक हुनबाट रोक्नुहोस्

विन्डोजले भण्डारण गरिएका प्रोफाइल राख्छ, र अन्तर्निहित क्लाइन्टले एउटालाई अर्कोमा निर्भर रहन दिन्छ ताकि दोस्रो जोडिँदा पहिलो स्वतः माथि आउँछ। सबैभन्दा पछि जोडिएको प्रोफाइलले पूर्वनिर्धारित राख्ने झुकाव राख्छ, त्यसैले व्यावहारिक मालिक पहिलो होइन, अन्तिम डायल हो। हरेक प्रोफाइललाई आफ्नै push मार्ग दिनुहोस् र पूर्वनिर्धारित नहुनुपर्ने प्रोफाइलमा स्प्लिट सुरुङ सक्रिय गर्नुहोस्।

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

स्प्लिट सुरुङले यो बदल्छ: तालिकामा सर्भरले push गरेका प्रिफिक्स मात्र आउँछन्, जसले पूर्वनिर्धारित पहिलो सुरुङमा राख्छ। दुवै सर्भरले पूर्वनिर्धारित मार्ग push गरेमा ढाँचा अझै असफल हुन्छ, किनकि त्यतिबेला अन्तिम जडान जित्छ र क्लाइन्ट-साइडको कुनै सेटिङले त्यो बदल्दैन। सर्भर-साइड push सुधार्नुहोस् वा एउटा मालिक स्वीकार गर्नुहोस्।

एप-ट्रिगर प्रोफाइल अर्को सुविधा हो र जान्न योग्य छ: विन्डोज प्रोफाइल नामित एक्जिक्युटेबल सुरु हुँदा सुरु हुन सक्छ, जसमा ट्राफिक फिल्टरले के बोक्ने निर्धारण गर्छ। यो फायरवाल नियम होइन, प्रोफाइल सेटिङ हो, र यसले पूर्वनिर्धारित-मार्ग द्वन्द्वभन्दा फरक समस्या समाधान गर्छ।

लिनक्स: दोस्रो सुरुङलाई मुख्य तालिकाबाहिर राख्नुहोस्

एउटै मेसिनमा openvpn --config का दुई प्रतिलिपि चलाउँदा दुवै क्लाइन्ट एउटै तालिकामा पर्छन्, र तीन विकल्पले बढ्दो अलगावसँग तिनलाई छुट्याउँछन्। सबैभन्दा हल्का भनेको दोस्रो क्लाइन्टलाई तालिका सम्पादन गर्नै नदिनु हो: स्पष्ट मार्गसहित route-nopull, वा तपाइँले चाहेको मात्र स्थापना गर्ने route-up स्क्रिप्ट। त्यसपछि दोस्रो सुरुङले तपाइँले नाम दिएका प्रिफिक्स मात्र बोक्छ र अरू केही होइन। त्यसपछि कुन प्रिफिक्स कहाँ जाने भनेर पछि पत्ता लगाउनुको सट्टा आफै निर्णय गर्नुहुन्छ।

नीति राउटिङ मध्य विकल्प हो। एउटा नियमले एउटा स्रोत ठेगाना वा फायरवाल चिन्हका लागि छुट्टै तालिका छान्छ, र त्यो तालिकाले दोस्रो सुरुङका मार्ग बोक्छ। यहाँ जाल उल्टो-मार्ग फिल्टरिङ हो, किनकि तालिकाले छान्ने इन्टरफेसभन्दा फरक इन्टरफेसमा आउने जवाफ खारेज हुन्छ, त्यसैले सुरुङ भाँचिएको निष्कर्षमा पुग्नुअघि rp_filter सेटिङ जाँच्नुहोस्।

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

सञ्जाल नेमस्पेस सबैभन्दा भारी र सबैभन्दा सफा विकल्प हो। दोस्रो क्लाइन्टलाई ip netns भित्र सुरु गर्नुहोस्, यसलाई veth जोडी दिनुहोस्, र प्रयोग गर्न त्यो नेमस्पेसमा प्रवेश गर्नुहोस्। हस्तक्षेप हराउँछ किनकि हरेक नेमस्पेसले एउटा तालिका साझा गर्नुको सट्टा आफ्नै तालिका राख्छ, जुन दुवै सुरुङ हप्तौं माथि राख्नुपर्दा थप सेटअपको लायक छ।

प्रति-अनुप्रयोग, र चेनिङ अलग समस्या रूपमा

कहिलेकाहीँ एउटा कार्यक्रमले मात्र दोस्रो सुरुङ प्रयोग गर्नुपर्छ। लिनक्समा प्रयोगकर्ता, cgroup वा पोर्ट अनुसार नीति राउटिङले त्यो नतिजा दिन्छ, र एउटा गन्तव्यलाई पूर्वनिर्धारित नछोई इन्टरफेसमा पिन गर्न सकिन्छ। आफ्नो सकेट एउटा इन्टरफेसमा पिन गर्ने अनुप्रयोगले राउटिङ तालिकासँग पटक्कै सोध्दैन, त्यसैले लन्चरले आफ्नै सेटिङमा ठेगाना छानिएसम्म भौतिक एडाप्टर प्रयोग गर्न जारी राख्न सक्छ।

चेनिङ दुई सुरुङ सँगै चलाउनुभन्दा फरक कार्य हो। A लाई B माथिबाट चेन गर्नु भनेको भित्री सर्भरको ठेगाना बाह्य सुरुङभित्रबाट पुग्न सकिने हुनुपर्छ। बाह्य क्लाइन्टले पनि भित्री क्लाइन्टका इन्क्रिप्टेड प्याकेटलाई चुहावट ठान्नु हुँदैन। भर्चुअल मेसिनभित्रको एउटा क्लाइन्ट ठुलो तर भरपर्दो संस्करण हो; दुवै एउटै होस्टमा हुँदा माथिको राउटिङ कामसँगै भित्री सर्भरतर्फ बाह्य यस्तो बाटो चाहिन्छ जो कहिल्यै भित्री सुरुङमा प्रवेश गर्दैन।

पूर्वनिर्धारितको मालिक, हरेक सुरुङले बोक्ने प्रिफिक्स सूची र DNS मार्ग लेख्नुहोस्। ती तीन तथ्यले अर्को घटनालाई जाँचको सट्टा खोजमा बदल्छन्।