एउटै Pi मा दुई VPN हप: कुन रुटले कुन पियर बोक्छ
एउटै Pi मा दुई टनेल ठेगाना गल्ती होइनन्। प्रत्येक गन्तव्यलाई आफ्नै वाहक, आफ्नै प्रमाण र बाहिरी हप मर्दा घोषित ब्याकअप चाहिन्छ।
एउटा सानो बोर्डमा दुई टनेल ठेगाना गल्तीजस्तो देखिन्छन्, र प्रतिक्रिया एउटा मेटाउने हुन्छ। त्यो प्रतिक्रियाले व्यवस्थित गर्नुपर्ने चीज नै तोड्छ। दुई हप बोक्ने होस्टले प्रत्येक जडानका लागि एउटा ठेगाना राख्छ, र प्रत्येक ठेगाना फरक रुटले चयन गर्छ। सोध्नैपर्ने प्रश्न कुन रुटले कुन गन्तव्यका लागि कुन वाहक छान्छ भन्ने हो, कतिओटा ठेगाना छन् भन्ने होइन।
फरक वाहक चाहिने तीन गन्तव्य
दुई हपको शृंखला एकापसमा राखिएका तीन गन्तव्य वर्ग हुन्, र प्रत्येकलाई फरक जडानले बोक्छ। बाहिरी पियरसम्म भौतिक लिंकबाट पुग्नुपर्छ। भित्री पियरसम्म बाहिरी टनेलबाट पुग्नुपर्छ। ढाकिएको एप्लिकेसनको गन्तव्यसम्म भित्री टनेलबाट पुग्नुपर्छ, जसको आफ्नै ढुवानी बाहिरी टनेलले बोक्छ।
| Destination class | View that names the carrier | Command that proves it | Symptom when the wrong carrier wins |
|---|---|---|---|
| Outer peer, 198.51.100.10 | the main table, by destination | ip route get 198.51.100.10 | the outer handshake never completes |
| Inner peer, 203.0.113.7 | the main table once the outer tunnel is up | ip route get 203.0.113.7 | the inner handshake leaves over the physical link |
| Application destination, 172.30.9.1 | the table the inner client's traffic is selected into | ip route get 172.30.9.1 from 10.8.0.2 | the exit address looks right and the traffic never crossed the outer hop |
| Parallel tunnels, one per source group | one policy per group, not the main table | ip rule show beside a marked test connection | both tunnels are up and one steals the other's traffic |
रुट छुनुअघि पंक्तिहरू पाठकका वास्तविक ठेगानाले भर्नुहोस्, किनकि तालिका ठोस भएपछि मात्र उपयोगी हुन्छ। काम गर्ने शृंखलाले चारै पंक्ति एकैसाथ पूरा गर्छ, र आधा काम गर्ने शृंखलाले सामान्यतया तीमध्ये एउटालाई गलत वाहकसँग पूरा गर्छ। गलत पंक्तिलाई खराबीका रूपमा पढ्नुले नै रुटिङ समस्यालाई पूरै दिउँसोको सम्पादनमा बदल्छ।
ठेगानाका भूमिका हुन्छन्, संख्या होइन
लिनक्सले एउटा इन्टरफेसमा धेरै ठेगाना र एउटा होस्टमा धेरै टनेल अनुमति दिन्छ, त्यसैले संख्याले शुद्धताबारे केही भन्दैन। महत्त्वपूर्ण कुरा कुन ठेगाना कुन जडानको हो, र दिइएको पियरका लागि रुटले तपाईंले चाहेको जडान छान्छ कि छैन भन्ने हो। तीन दृश्यले तीन दिशाबाट त्यसको जवाफ दिन्छन्, र प्रत्येक पटक उनीहरूलाई एउटै क्रममा पढ्न लायक छ।
ठेगाना सूचीले के छ र कुन जडानले त्यसको स्वामित्व राख्छ देखाउँछ। रुट तालिकाले सामान्य गन्तव्य ट्राफिकका लागि वाहकको प्रश्नको जवाफ दिन्छ। नीति दृश्यले स्रोत वा चिन्हद्वारा छानिएको ट्राफिकका लागि फेरि जवाफ दिन्छ, दुई क्लाइन्टले एउटा होस्ट साझा गर्दा यो सामान्य व्यवस्था हो।
ip -4 addr show
ip -4 route show table all
ip rule showसूची लामो देखिन्छ भनेर ठेगाना मेटाउँदा बाटोको एक भाग हट्न सक्छ, र अतिरिक्त देखिन्छ भनेर रुट मेटाउँदा त्यही काम अझ शान्त रूपमा गर्छ। दुवैले त्रुटि दिँदैनन्; पियरले तपाईंले चाहेको बाटोमा जवाफ दिन छोड्छ, तर अर्को बाटोबाट पुग्न सकिने रहन्छ। भित्री पियरको बाहिर जाने ठेगाना रिपोर्ट गर्ने एप्लिकेसनले ट्राफिक बाहिरी टनेलबाट गयो भनी प्रमाणित गर्दैन, किनकि सीधा पहुँचले त्यही अवलोकन दिन्छ। अवलोकन र प्रमाणबीचको यही अन्तर नै रुटिङ तहमा वाहक जाँचिनुको कारण हो।
सक्रियताको क्रमले निश्चित प्रतीक्षालाई जित्छ
भित्री क्लाइन्ट बाहिरी क्लाइन्टले उपलब्ध गराउने ठेगाना वा रुटमा निर्भर छ भने, सक्रियताले ढिलाइको सट्टा त्यो स्रोत पर्खनुपर्छ। प्रतीक्षा बाहिरी टनेल ढिलो हुने दिनसम्म काम गर्छ, अनि कसैले पनि पुनः उत्पादन गर्न नसक्ने तरिकाले बेलाबेलामा असफल हुन्छ। निर्भरतामा आधारित क्रमले अनुमान हटाउँछ र निर्भरता एक पटक वर्णन गर्नबाहेक केही खर्च गर्दैन। इन्टरफेसका नाम पनि क्रमको संयन्त्र होइनन्।
कर्नेलले tun0 र tun1 जस्ता नाम सिर्जनाको क्रममा दिन्छ, र त्यो क्रम पुनः सुरु वा पुनः जडानबीच बदल्न सक्छ। कन्फिगरेसनलाई उपकरणले दिने पहिचान वा तपाईंले जानाजान दिने नामसँग बाँध्नुहोस्। तपाईंले छान्ने नाम सम्झौता हो; कर्नेलले छान्ने नाम संयोग हो।
प्रत्येक क्लाइन्टको ढुवानीलाई अर्कोको एप्लिकेसन रुटबाहिर राख्नुहोस्, र OpenVPN 2.6 रुटिङ विकल्पहरू ले वास्तवमा के वाचा गर्छन् भन्नेमा सटीक रहनुहोस्। कागजात गरिएको पूर्वनिर्धारित पुनःनिर्देशन संयन्त्रले क्लाइन्टलाई पहिले नै रहेको गेटवेबाट आफ्नै टाढाको पियरसम्म पुग्न सक्षम राख्छ, जसले एउटा विशेष पुनरावृत्ति लूप काट्छ। यसले एउटा क्लाइन्टलाई अर्कोको वाहक बनाउँदैन, त्यसैले शृंखलाको बाँकी भाग तपाईंको डिजाइन नै रहन्छ। शृंखलालाई रुटको सट्टा नीति चाहिने ठाउँमा स्पष्ट स्रोत वा चिन्ह नियम लेख्नुहोस् र जुन ट्राफिकसँग मिल्नुपर्ने हो त्यसैसँग परीक्षण गर्नुहोस्।
बाहिरी हप मर्दा के हुन्छ
शृंखला पूर्ण मानिनुअघि बाहिरी हप हराउँदा के हुन्छ निर्णय गर्नुहोस्। भित्री क्लाइन्टको ढुवानी त्यसैसँग मर्छ, र अर्को कदम प्राविधिक होइन, नीतिको प्रश्न हो: असफल हुने, फेरि प्रयास गर्ने, वा भौतिक लिंकबाट सीधै पुनः जोडिने। तेस्रो परिणाम नै सोच्न लायक छ। प्रयोगकर्ताले कभरेज अझै अभंग छ भन्ने विश्वास गर्ने क्षणमै यसले दुई हपको डिजाइनलाई एक हपको डिजाइनमा चुपचाप बदल्छ।
दुई हप अनिवार्य छन् भने बाहिरी गएपछि भित्री क्लाइन्टले सीधा बाटो स्थापित गर्न सक्नु हुँदैन, र त्यो थाहा पाउने तरिका बाहिरी हप तोडेर भित्रीले के गर्छ हेर्नु हो। स्वीकृत ब्याकअप वैध उत्तर हो, तर त्यो लिखित, परीक्षित र जानकारी गराइएको हुनुपर्छ। कसैले कागजात नगरेको ब्याकअप घटना समीक्षामा चुहावटबाट छुट्याउन सकिँदैन।
DNS र अर्को ठेगाना परिवार एउटै निर्णयमा पर्छन्। स्थानीय रूपमा बनाइएको खोजी फर्वार्ड गरिएको क्लाइन्टको नीति होइन, होस्टकै आफ्नै नीति पछ्याउँछ, त्यसैले फर्वार्ड गरिएको ट्राफिकका लागि काम गर्ने रिजोल्भर होस्ट आफैंले प्रयोग गर्ने नहुन सक्छ।
प्रत्येक तहलाई तपाईंले बनाएको क्रममा स्वीकार गर्नुहोस्
शृंखला जुन क्रममा बनाइयो त्यही क्रममा परीक्षण गर्नुहोस्: पहिले एक्लै बाहिरी टनेल, त्यसपछि बाहिरी टनेलबाट भित्री क्लाइन्टको ढुवानी, त्यसपछि भित्री टनेलबाट एप्लिकेसन। प्रत्येक स्वीकृति पहिले खुलेको पृष्ठ होइन, नयाँ जडान हुनुपर्छ। त्यसपछि प्रत्येक तह अलग-अलग तोडेर पुनःस्थापित गर्नुहोस् र अर्कोले के गर्छ हेर्नुहोस्।
ब्याकअपको नतिजा यहाँ सबैभन्दा मूल्यवान अवलोकन हो, र सार्वजनिक IP पृष्ठले कहिल्यै नदेखाउने कुरा। पियरका बाटा, उनीहरूले प्रयोग गर्ने ठेगाना र त्यो नतिजा कन्फिगरेसनको छेउमा सुरक्षित राख्नुहोस्, किनकि सुखी बाटो पछि प्रश्न उठ्ने भाग होइन।