अलग इग्रेस: usb0 मा VPN पूल, eth0 मा गेटवे ट्राफिक

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

स्रोत ठेगाना राउटिङ निर्णयसम्म टिक्छ भनी पुष्टि गर्नुहोस्

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

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

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

पूर्ण हुने चयनित तालिका बनाउनुहोस्

तालिका साथीसहितको पूर्वनिर्धारित रुट होइन। प्रत्येक खोजी यसभित्रै टुंगिन अघि पर्याप्त रुट चाहिन्छ, WAN सबनेटको जोडिएको रुट पनि, ताकि अर्को हप पुग्न सकियोस्। tun1 मा 10.77.0.0/24 पूल, अर्को हप 203.0.113.1 भएको WAN ठेगाना 203.0.113.20/24, र तालिका 600 का लागि:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

नियम कुनै पनि विद्यमान सबै-समात्ने नियमभन्दा तल्लो प्राथमिकतामा बस्छ, त्यसैले मिल्ने क्लाइन्टहरू पहिले तालिका 600 मा पुग्छन् र बाँकी सबै मुख्य तालिकामा खस्छ। ip-rule सन्दर्भ ले क्रमबद्ध खोजी मोडेल र चयनकर्ताको वाक्यरचना पूर्ण रूपमा वर्णन गर्छ।

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

स्रोताको आफ्नै ट्राफिक नीतिबाहिर राख्नुहोस्

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

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

मेसिनमा भएका अरू सबैको तुलनामा क्रम पनि महत्त्वपूर्ण छ। Docker पुल, दोस्रो VPN र प्रदायकको इमेजबाट पहिल्यै भएका जुनसुकै नियम सबैले प्राथमिकता थप्छन्, त्यसैले प्राथमिकता 100 एक्लै छ भनी मान्नुको सट्टा पूरै नियम सूची पढ्नुहोस्।

फर्वार्डिङ र अनुवाद रुटसँग मिलाउनुहोस्

राउटिङले माथिल्लो लिङ्क छान्छ; यसले फर्वार्ड गर्न अनुमति दिँदैन। कर्नेलमा IPv4 फर्वार्डिङ सक्षम हुनुपर्छ, र फायरवालले क्लाइन्टबाट WAN तर्फको दिशा र फर्कने ट्राफिक स्वीकार गर्नुपर्छ। प्रवाह फाल्ने FORWARD चेनसहितको सही तालिकाले हराएको रुटजस्तै लक्षण दिन्छ, त्यसैले दुवै एउटै पटकमा जाँचिन्छन्।

यदि दोस्रो WAN ले निजी पूललाई तपाईंतर्फ फर्काएर रुट गर्दैन भने त्यो इग्रेसमा स्रोतको अनुवाद गर्नुहोस्। गतिशील ठेगाना भएको इन्टरफेसका लागि पूल र इन्टरफेसमा सीमित साँघुरो masquerade नियम सामान्य विकल्प हो:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

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

बाटोहरू फरक भएपछि टनेल ओभरहेडले पनि ध्यान माग्छ। क्लाइन्टहरू ठूलो TCP MSS मा सहमत भए र वैकल्पिक WAN को MTU कम छ वा भित्र टनेल छ भने ठूला खण्ड अड्किन्छन् र साना चल्छन्। फर्वार्डिङ बाटोमा MSS क्ल्याम्प गर्दा त्यो कहिलेकाहीँ अड्किने होइन, अनुमानयोग्य व्यवहार बन्छ।

usb0 हराउँदा के हुन्छ निर्णय गर्नुहोस्

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

जहाँ यो पछाडि फर्किने कुरा स्वीकार्य छैन, त्यहाँ तालिका 600 मा स्पष्ट टर्मिनल रुट थप्नुहोस्, जस्तै blackhole पूर्वनिर्धारित, वा इन्टरफेस बन्द हुँदा फायरवालमा पूल फाल्नुहोस्। दुवैमध्ये जुनसुकै पनि तपाईंले लेख्न सक्ने निर्णय हो; मौनता होइन।

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