अपस्ट्रीम VPN के पीछे डाउनस्ट्रीम क्लाइंट: रूट या NAT?
अपस्ट्रीम VPN केवल क्लाइंट का पता जानता है, इसलिए दूसरे सबनेट को आगे भेजने के लिए सहमत रूट या जानबूझकर स्रोत अनुवाद चाहिए।
एक गेटवे अपने उपकरणों के लिए WireGuard और किसी दूसरे के नेटवर्क की ओर OpenVPN क्लाइंट चलाता है। दो आंतरिक इंटरफ़ेस के बीच फ़ॉरवर्डिंग काम करती है, और यह निष्कर्ष निकालना आसान है कि डाउनस्ट्रीम सबनेट अब अपस्ट्रीम सेवा का हिस्सा है। ऐसा नहीं है। क्लाइंट जो रूट खींचता है वह आपके गेटवे को बताता है कि अनुरोध कहाँ भेजने हैं; यह नहीं बताता कि दूरस्थ नेटवर्क उन उपकरणों को ट्रैफ़िक कैसे लौटाता है जिनके बारे में उसने कभी सुना ही नहीं। एक भी नियम जोड़ने से पहले ऐसा रिटर्न मॉडल चुनें जिसे अपस्ट्रीम वास्तव में समर्थन देता हो।
रूटिंग को छूने से पहले रिटर्न मॉडल तय करें
इस वॉकथ्रू में डाउनस्ट्रीम क्लाइंट 10.90.0.0/24 का उपयोग करते हैं, गेटवे को दिया गया अपस्ट्रीम टनल पता 10.80.0.6 है, और स्वीकृत दूरस्थ संसाधन 172.20.0.30 है। इस आकार में दो मॉडल फ़िट होते हैं: डाउनस्ट्रीम स्रोत को बनाए रखें और दूर वाले पक्ष से उसे रूट कराएँ, या स्रोत का अनुवाद गेटवे के अपने टनल पते में करें। इस निर्णय के बाद सब कुछ यांत्रिक है, और निर्णय को स्वयं सेवा के मालिक की ज़रूरत है। ऊपर की एक पंक्ति दूर वाले पक्ष के साथ रूटिंग समझौता है; दूसरी स्थानीय नीति परिवर्तन है जो आप अकेले कर सकते हैं। इन दोनों को मिला देना ही दस मिनट के काम को बातचीत में बदल देता है।
preserved: 10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6 -> 172.20.0.30एक पंक्ति चुनें और उस पर टिके रहें। पंक्तियाँ विकल्प हैं, चरण नहीं, और इन्हें मिलाने से ऐसा डिज़ाइन बनता है जिसे समीक्षा में कोई समझा नहीं सकता।
रूटेड स्रोत संरक्षण
दूर वाला पक्ष डाउनस्ट्रीम पते से अनुरोध पाता है, इसलिए उसे उस सबनेट के लिए समर्थित रूट और पीयर स्वामित्व चाहिए, साथ ही उसे स्वीकार करने का प्राधिकरण भी। ये दूरस्थ सेटिंग्स हैं, और कोई स्थानीय Linux रूट इन्हें नहीं बनाता। इन्हें स्पष्ट रूप से और लिखित में माँगें, प्रीफ़िक्स और उसे ले जाने वाले टनल पीयर के साथ, और अपेक्षा रखें कि उत्तर इस पर निर्भर होगा कि सेवा साइट-टू-साइट व्यवस्थाओं का समर्थन करती है या नहीं।
यदि उत्तर हाँ है, तो स्थानीय कॉन्फ़िगरेशन छोटा है: फ़ॉरवर्डिंग सक्षम, डाउनस्ट्रीम रेंज को कवर करने वाले WireGuard पीयर के allowed-ips, और एक फ़ायरवॉल नीति जो दोनों दिशाओं में पारगमन की अनुमति देती है।
जानबूझकर स्रोत अनुवाद
यदि सेवा ट्रैफ़िक केवल जुड़े क्लाइंट के पते पर लौटाती है, तो जाते समय स्रोत का अनुवाद उस पते में करें और वह conntrack स्थिति रखें जो उत्तरों के लिए उसे उलट देती है। नियम को इच्छित डाउनस्ट्रीम स्रोतों, इच्छित दूरस्थ गंतव्यों और अपस्ट्रीम इंटरफ़ेस तक सीमित रखें। हर इंटरफ़ेस से निकलने वाली हर चीज़ का अनुवाद करने वाला नियम इस आवश्यकता से बहुत बड़ी नीति है, और बाद में यह आपको चौंका देगा।
IPv6 को अपना डिज़ाइन चाहिए; IPv4 masquerade लाइन की नकल करना आर्किटेक्चर नहीं है। अनुवादित पथ को कैश किए गए कनेक्शन के बजाय नए कनेक्शन से जाँचें।
स्थानीय डेटा पथ को अभी भी काम करना है
अनुवाद स्थानीय काम को नहीं हटाता: गेटवे को अभी भी डाउनस्ट्रीम गंतव्यों के लिए रूट, सही WireGuard पीयर स्रोत स्वामित्व, सक्षम फ़ॉरवर्डिंग और इंटरफ़ेस के बीच संकीर्ण फ़ायरवॉल नीति चाहिए। गेटवे पर ही बना अनुरोध इनमें से कोई भी अनुमति नहीं आज़माता, इसलिए गेटवे पर स्थानीय परीक्षण पास होते हैं और डाउनस्ट्रीम उपकरण अभी भी विफल रहते हैं।
गेटवे से नहीं, वास्तविक डाउनस्ट्रीम उपकरण से परीक्षण करें। स्रोत पता ही इस अभ्यास का पूरा उद्देश्य है।
एक स्रोत का अर्थ एक सत्र पहचान
दूरस्थ सेवा गेटवे का प्रमाणित सत्र और उसका अनुवादित पता देखती है, न कि हर डाउनस्ट्रीम उपकरण के लिए स्वतंत्र प्रमाणीकरण। प्रति-उपकरण अनुमतियाँ और एप्लिकेशन पहचान स्पष्ट रखें, और सेवा के मालिक से पुष्टि करें कि कई उपकरणों की ओर से काम करने वाला गेटवे वास्तव में अनुमत है। अनुवाद प्रति-उपकरण नामांकन आवश्यकता को दरकिनार करने का तरीका नहीं है; यदि सेवा हर उपकरण के नामांकन की मांग करती है, तो वही मॉडल अपनाएँ या साइट-टू-साइट व्यवस्था पर बातचीत करें।
उस पुष्टि को नियम के बगल में runbook में लिखें, क्योंकि अगला समीक्षक पूछेगा कि डिज़ाइन स्वीकृत था या केवल सुविधाजनक।
डिस्कनेक्टेड स्थिति परिभाषित करें, फिर तीन अनुरोध जाँचें
तय करें कि अपस्ट्रीम टनल गिरने पर क्या होता है। जहाँ निषिद्ध है वहाँ अधिकृत दूरस्थ ट्रैफ़िक को चुपचाप सामान्य WAN फ़ॉलबैक का अनुसरण नहीं करना चाहिए, इसलिए पारगमन की अनुमति देने वाली फ़ायरवॉल नीति को भी बंद अवस्था में विफल होना चाहिए। फिर वास्तविक डाउनस्ट्रीम उपकरण से तीन स्थितियाँ जाँचें: काम करने वाला अनुमत अनुरोध, विफल होने वाला अननुमत अनुरोध, और अनुमत अनुरोध को रोकने वाली अपस्ट्रीम विफलता।
प्रत्येक नियम के लिए एक पंक्ति में रोलबैक दर्ज करें, ताकि इरादे को फिर से बनाए बिना परिवर्तन रद्द किया जा सके।