एउटै सर्भर IP, दुई बाटो: OpenVPN को बाहिरी प्रवाह चिन्ह लगाउने

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

अलग गर्न चाहेका दुई प्रवाहबाट सुरु गर्नुहोस्

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

यस विवरणमा 10.90.0.10 मा रहेको क्लाइन्ट tun1 मार्फत छ, सर्भरको सार्वजनिक ठेगाना 198.51.100.25 हो, र मुख्य तालिका अछुतो छ जसको पूर्वनिर्धारित मार्ग सामान्य अपलिंकतर्फ जान्छ भनी मान्नुहोस्। सर्भर पक्षले पनि भित्री मार्गमा वेब सेवा स्वीकार्नुपर्छ र ट्राफिक टनेल स्रोततिर फर्काउनुपर्छ; सार्वजनिक ठेगानामा प्याकेट पठाउँदा सर्भरको लिस्नर वा फायरवाल नीति रद्द हुँदैन।

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

खाम बोक्ने सकेटलाई चिन्ह लगाउनुहोस्

क्लाइन्ट कन्फिगरेसनले आफ्ना इन्क्रिप्टेड बाहिर जाने प्याकेटका लागि चिन्ह पाउँछ र आफैं मार्ग स्थापना गर्न छोड्छ, ताकि प्रतिस्थापन नीति नै मार्ग तय गर्ने एक मात्र कुरा होस्:

mark 42
route-noexec
disable-dco

दशमलव 42 हेक्साडेसिमल 0x2a हो, र हेक्स रूप नै त्यो हो जससँग राउटिङ नियम मिल्नेछन्। link-options को सन्दर्भ ले mark लाई Linux मा इन्क्रिप्टेड बाहिर जाने प्याकेटमा लागू हुने कुरा बताउँछ, अर्थात् ठ्याक्कै त्यही सकेट जसको मार्ग तपाईंले नियन्त्रण गर्नुपर्छ। डेटा च्यानलको अफलोड बन्द गर्दा यो उदाहरण प्रयोगकर्ता-स्पेस मार्गमा रहन्छ, जहाँ चिन्हको व्यवहार वर्णन गरिएकै हो।

route-noexec ले OpenVPN का स्वचालित मार्ग थप्ने र हटाउने काम दबाउँछ। यसले तिनीहरूको ठाउँमा केही स्थापना गर्दैन, त्यसैले यो क्षणदेखि मार्गको मालिकले टनेललाई चाहिने हरेक मार्ग कायम राख्नुपर्छ। परिवर्तनपछि कुनै निजी गन्तव्य हराएमा त्यो अनुपस्थित प्रतिस्थापन नीति हो, चिन्हको दोष होइन।

यो गर्दा 198.51.100.25 का लागि मुख्य तालिकामा होस्ट मार्ग नराख्नुहोस्। त्यस्तो मार्गले डिजाइनले साँघुरो पार्न खोजेको छुट नै फर्काउँछ, र तलका कुनै पनि नीति सोधिनुअघि त्यो HTTPS प्रवाहका लागि जित्नेछ।

बाँकी सबै टनेल तालिकामा पठाउनुहोस्

टनेल इन्टरफेस अस्तित्वमा आई आफ्नो ठेगाना राखेपछि नीति यस्तो देखिन्छ:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

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

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

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

फर्कने बाटोले पनि त्यही चिन्ह देखोस्

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

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

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

दुई मार्ग खोजले यो प्रमाणित गर्नुहोस्

कर्नेलले दुई सन्दर्भका लागि के निर्णय गर्छ तुलना गर्नुहोस्, र निकास स्थितिको सट्टा dev र src फिल्ड पढ्नुहोस्:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

पहिलो खोज टनेल स्रोतसहित tun1 मा टुंगिनुपर्छ, र दोस्रो अपलिंकमा। यी कृत्रिम खोज हुन्, त्यसैले तिनले नीति प्रमाणित गर्छन्, चलिरहेको प्रक्रिया होइन: चलिरहेको क्लाइन्टको वास्तविक यातायात मार्ग छुट्टै पुष्टि गर्नुहोस्, त्यसपछि प्रमाणपत्र प्रमाणीकरण खुला राखेर साँचो HTTPS अनुरोध गर्नुहोस्।

सम्पन्न घोषणा गर्नुअघि डिजाइनले के समेट्दैन लेख्नुहोस्। DNS, IPv6 र नियमको जीवनचक्रले हरेकले आफ्नै निर्णय चाहन्छ, र यो IPv4 राउटिङको उदाहरण हो, पूरा गोपनीयता कन्फिगरेसन होइन। यसको मूल्य चयनकर्ता हो: खामले अपलिंकको छुट पाउँछ, र त्यही ठेगानाको साधारण सेवाले त्यो उत्तराधिकारमा लिनु पर्दैन।