माथिल्लो VPN पछाडिका तल्लो क्लाइन्ट: रुट कि NAT?

एउटा गेटवेले तपाईंका आफ्नै उपकरणका लागि 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 फलब्याक पछ्याउनु हुँदैन, त्यसैले पार गर्न अनुमति दिने फायरवाल नीति पनि बन्द अवस्थामा असफल हुनुपर्छ। त्यसपछि वास्तविक तल्लो उपकरणबाट तीन अवस्था परीक्षण गर्नुहोस्: काम गर्ने अनुमत अनुरोध, असफल हुने निषेधित अनुरोध, र अनुमत अनुरोध रोक्ने माथिल्लो खराबी।

हरेक नियमका लागि एक पङ्क्तिमा रोलब्याक लेख्नुहोस्, ताकि मनसाय पुनर्निर्माण नगरी परिवर्तन रद्द गर्न सकियोस्।