एउटै Linux गेटवेमा दुई OpenVPN क्लाइन्ट: नीति बाँड्नुहोस्

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

कर्नेलले निर्धारण गर्छ, डेमनले होइन

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

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

हरेक प्रतिलाई आफ्नै स्रोत-समूह दिनुहोस्

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull सर्भरले धकेलेका रुटहरू स्थानीय तालिकाबाहिर राख्छ, र नीतिका तालिका स्पष्ट हुनुपर्ने बेला तपाईंलाई यही चाहिन्छ। दिइएको सर्भरले redirect-gateway विकल्प पनि धकेल्छ कि र तपाईंको क्लाइन्ट संस्करणले फिल्टर ढाँचा समर्थन गर्छ कि, अनुमान गर्नुको सट्टा निर्देशिकामा जाँच्न लायक छ।

म्याट्रिक्स लेख्नुहोस्: स्रोत, तालिका, यन्त्र

हरेक क्लाइन्ट समूहका लागि स्रोत ठेगानाद्वारा तालिका छान्ने नियम थप्नुहोस्, त्यसपछि इच्छित बाटो त्यो तालिकामा राख्नुहोस्:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

सुरुङको आफ्नै यातायात क्लाइन्ट समूहमा छैन

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

स्थानीय व्यवस्थापन सत्र र तल्लो तहको बाटो नीतिका तालिकाबाहिर स्पष्ट राख्नुहोस्। ती अपवादहरू म्याट्रिक्सको छेउमा लेख्नुहोस्; ती डिजाइनको भाग हुन्, घटनाको समयमा फेरि पत्ता लगाउनुपर्ने उपाय होइन।

बाटो छान्नु त्यसको अनुमति होइन

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

स्रोत अनुवाद तेस्रो निर्णय हो, र त्यो स्रोत समूह र त्यसलाई साँच्चै बोक्ने सुरुङ यन्त्रसम्म सीमित हुनुपर्छ। दुई प्रतिका लागि समर्पित शृंखला थप्नुहोस्, postrouting शृंखला खाली गर्नुको सट्टा, किनकि असम्बन्धित सेवाका त्यहाँ प्रविष्टि हुन सक्छन् र खाली गर्दा ती चुपचाप हट्छन्।

एउटा सुरुङ खस्दा के हुन्छ

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

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