केवल पोर्ट 25 को सुरंग में भेजें, होस्ट को नहीं

Linux होस्ट अपना ही SMTP सुरंग से बाहर भेजे, इससे पहले चार चीज़ें मेल खानी चाहिए: समर्पित तालिका में एक रूट, ट्रैफ़िक चुनने वाला नीति-नियम, पीयर द्वारा स्वीकार किया जाने वाला स्रोत पता, और असममिति सहने वाला वापसी मार्ग। हर एक अलग कॉन्फ़िगरेशन है जिसकी अपनी विफलता-शैली है। नीचे का क्रम वही है जो विफलता को वास्तव में गलत हिस्से की ओर इंगित कराता है। यह पोर्ट-विशिष्ट राउटिंग कार्य है, VPN डिफ़ॉल्ट रूट का अनुरोध नहीं।

पोर्ट नियम डिफ़ॉल्ट रूट नहीं है

जो नियम स्थानीय रूप से उत्पन्न TCP को गंतव्य पोर्ट 25 से मिलाता है, वह उस ट्रैफ़िक को आपके बताए तालिका में भेजता है। नियम स्वयं कुछ नहीं बनाता: वह चुनता है, और तालिका में ऐसा रूट होना चाहिए जो पैकेट ले जा सके। दोनों का संयोजन केवल एक प्रोटोकॉल की बाहर जाने वाली दिशा को कवर करता है, इसलिए अन्य होस्टों के लिए फ़ॉरवर्डिंग, आने वाले मेल कनेक्शन और IPv6 इस व्यवस्था से बाहर रहते हैं। इसे VPN डिफ़ॉल्ट के बजाय पोर्ट-विशिष्ट नीति कहना उस सीमा को ईमानदार रखता है।

wg-quick की दो सेटिंगें पूर्व-शर्तें हैं, नीति का हिस्सा नहीं। AllowedIPs = 0.0.0.0/0 पीयर को मनमाने IPv4 गंतव्य ले जाने देता है, और Table = off wg-quick को उस प्रीफ़िक्स के लिए अपना डिफ़ॉल्ट रूट स्थापित करने से रोकता है। इन निर्देशों को ऐसे प्रबंधक के साथ न मिलाएँ जो अपनी रूट नीति लागू करता है, क्योंकि दोनों इस बात पर सहमत नहीं होंगे कि मुख्य तालिका किसकी है।

रूट, चयनक और रक्षक लिखें

ऐसी तालिका-संख्या और प्राथमिकता-युग्म चुनें जिन्हें और कुछ नहीं उपयोग करता, फिर उसी क्रम में रूट, चयनक और रक्षक लागू करें। नीचे की संख्याएँ उदाहरण हैं, आरक्षित मान नहीं:

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo नियम को स्थानीय उद्गम ट्रैफ़िक तक सीमित करता है, और ipproto tcp dport 25 कनेक्शन की दिशा पहचानता है; ip-rule संदर्भ दोनों चयनकों का दस्तावेज़ीकरण करता है। वे मौजूदा कर्नेल और iproute2 संस्करणों में हैं, और पुराने सिस्टम पर नियम सीधे अस्वीकार हो जाता है, जो ऐसे नियम से अधिक स्पष्ट विफलता है जो लोड होकर किसी चीज़ से मेल नहीं खाता।

अगली प्राथमिकता का unreachable नियम रक्षक है। उसके बिना, तालिका 51825 में अनुपलब्ध रूट सामान्य डिफ़ॉल्ट में गिर जाता है, और सुरंग बंद होने के दौरान मेल भौतिक लिंक से बाहर चला जाता है, जो ठीक वही स्थिति है जिसे रोकने के लिए नीति बनाई गई थी।

स्रोत पते का मेल होना चाहिए

रूट की src वरीयता केवल उन्हीं कनेक्शनों के लिए स्रोत भरती है जिन्होंने अपना स्रोत बाँधा नहीं है। यह अनुवाद नहीं है, और स्पष्ट बाइंडिंग को ओवरराइड नहीं करती, इसलिए भौतिक पते से बंधा डेमॉन उसी पते से भेजता रहता है। यदि आपको ठीक यही मिले, तो डेमॉन की अपनी सेटिंग बदलें या जानबूझकर अनुवाद नीति डिज़ाइन करें, क्योंकि देर से किया गया व्यापक masquerade अलग परिणामों वाला अलग समाधान है।

गेटवे पर, क्लाइंट के पीयर को वह स्रोत अधिकृत करना होता है जो उसे वास्तव में मिलता है, यानी चौड़े गंतव्य प्रीफ़िक्स के बजाय 10.77.0.2/32। क्लाइंट के 0.0.0.0/0 को हर गेटवे पीयर में कॉपी करने से यह उलझ जाता है कि कौन सा पीयर किस ट्रैफ़िक का मालिक है। गेटवे को फ़ॉरवर्डिंग, प्रवाह की अनुमति देने वाली फ़ायरवॉल नीति, और वापसी मार्ग भी चाहिए, जिसमें बाहर जाने वाला अनुवाद भी शामिल है जब अपस्ट्रीम निजी सुरंग पता रूट नहीं कर सकता।

वापसी मार्ग जाँचें, फिर स्थायित्व

किसी भी चीज़ पर भरोसा करने से पहले लुकअप पढ़ें, क्योंकि वे दिखाते हैं कि हर दिशा को कौन सी तालिका और कौन सा स्रोत मिलता है। पोर्ट 25 पर एक गंतव्य और पोर्ट 443 पर वही गंतव्य पर्याप्त हैं:

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

पहले लुकअप में wg0 और इच्छित स्रोत होना चाहिए, और दूसरे में सामान्य अपलिंक बना रहना चाहिए। जब एप्लिकेशन अपना पता बाँधता है, तो लुकअप में उस पते के साथ from जोड़ें। जो उत्तर-दिशा wg0 तक पहुँचकर स्थानीय रूप से गिरा दी जाती है, वह IPv4 रिवर्स-पाथ फ़िल्टरिंग की ओर संकेत करती है, क्योंकि केवल बाहर जाने वाले पोर्ट का नियम रिवर्स लुकअप को सुरंग चुनने पर विवश नहीं करता।

जहाँ असममित राउटिंग अधिकृत है, वहाँ net.ipv4.conf.wg0.rp_filter=2 के माध्यम से इंटरफ़ेस-सीमित ढीला मोड उपयुक्त हो सकता है, और पहले all तथा इंटरफ़ेस मानों का प्रभावी अधिकतम जाँचना उचित है। सत्यापन को शॉर्टकट के रूप में वैश्विक रूप से बंद न करें। फिर तालिका, प्राथमिकताएँ और रक्षक कॉन्फ़िगरेशन के मालिक को सौंपें, और पुनः कनेक्ट के बाद नए कनेक्शन खोलकर पुष्टि करें कि चयन अब भी टिका है। ध्यान रखें कि स्थानीय SMTP श्रोता के उत्तर स्रोत पोर्ट 25 ले जाते हैं, गंतव्य पोर्ट 25 नहीं, जो अलग नीति प्रश्न है।