नेस्टेड VPN: बाह्य जडान कुन सुरुङले बोक्छ?

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

नेस्टिङ तीन सर्तले निर्धारण गर्छ

पहिलो सर्त कुन अन्तिम बिन्दुलाई कुन बाटो चाहिन्छ भन्ने हो। भित्री सर्भरको ठेगाना भन्नुहोस्, बाह्य सर्भरको ठेगाना भन्नुहोस्, र भित्री सर्भर केवल बाह्य सुरुङबाट मात्र पहुँचयोग्य छ भनी स्पष्ट भन्नुहोस्। बाँकी सबै त्यही वाक्यबाट आउँछ, कुन मार्ग कुन तालिकामा छन् भन्ने पनि।

दोस्रो सर्त प्रत्येक तहमा तपाईं बाटो देख्न सक्नुहुन्छ कि भन्ने हो। यदि कुनै विशेष गन्तव्यले कुन मार्ग प्रयोग गर्छ भनी तपाईं कर्नेललाई सोध्न सक्नुहुन्न भने, तपाईं अन्तिम बाहिर जाने IP बाट श्रृंखलाको अनुमान लगाइरहनुभएको छ, र यही त्यो प्रमाण हो जसले नेस्टिङलाई संयोगबाट अलग गर्न सक्दैन।

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

पहिलो सर्त: कुन अन्तिम बिन्दुलाई कुन बाटो चाहिन्छ

ip route get 203.0.113.10 त्यो प्रश्नको सिधा उत्तर दिन्छ: यसले मार्ग, स्रोत ठेगाना र कर्नेलले अहिले त्यो गन्तव्यका लागि प्रयोग गर्ने इन्टरफेस छाप्छ।

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

दोस्रो सर्त: प्रत्येक तहमा मार्ग जाँच्नुहोस्

आधुनिक क्लाइन्टमा मार्ग छनोट मुख्य तालिकाभन्दा बढी हो। नीति नियमहरूले चिन्ह लगाइएका प्याकेट अर्को तालिकामा पठाउन सक्छन्, क्लाइन्टले आफ्नो सकेट कुनै इन्टरफेसमा बाँध्न सक्छ, र कन्टेनर वा नामस्थानका आफ्नै तालिका हुन्छन्। ip rule र ip route show table all यीमध्ये कुन संयन्त्र चलिरहेको छ भनी पत्ता लगाउने तरिका हुन्।

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

तेस्रो सर्त: बाह्य सुरुङ खस्दा के हुन्छ

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

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

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

श्रृंखलाले तपाईंलाई के दिँदैन

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

नतिजा एउटा छोटो कागजात हो, चल्ने जडान होइन: कुन अन्तिम बिन्दुले कुन मार्ग प्रयोग गर्छ, बाह्य असफलतामा के हुन्छ, र वर्तमान अवस्था देखाउने ती तीन कमाण्ड। strongSwan को फर्वार्डिङसम्बन्धी कागजात Linux होस्टमा सुरुङ ट्राफिक इन्टरफेसहरूबीच कसरी अगाडि पठाइन्छ भन्नेबारे उपयोगी सन्दर्भ हो। हरेक क्लाइन्ट अपडेटपछि जाँच फेरि चलाउनुहोस्, किनकि तपाईंको श्रृंखला बनाउने पूर्वनिर्धारित मानहरू सम्झौता होइनन्। जुन नेस्टेड सुरुङ तपाईं जाँच्न सक्नुहुन्न त्यो स्थिति बत्ती भएको हल्ला हो।