एउटा AWS Client VPN सत्रको पछाडिको LAN: के अगाडि पठाइन्छ

ल्यापटप AWS Client VPN इन्डपोइन्टमा जोडिन्छ, निजी सबनेटमा पुग्छ, र सबै कुरा स्वस्थ देखिन्छ। त्यही LAN मा रहेको डेस्कटप कतै पुग्दैन, यद्यपि Linux होस्टमा पनि ब्रिज इन्टरफेस छ र दुवै मेसिन एउटै तारमा छन्। टनेलमा केही पनि गलत कन्फिगर गरिएको छैन; छुटेको भाग राउटिङ हो, र ब्रिज एउटा भ्रमपूर्ण सङ्केत हो।

Client VPN सत्रलाई LAN मा विस्तार गर्नु गेटवेको भूमिका हो। यो व्यवस्थापित सेवामा तानिएको Ethernet खण्ड होइन।

होस्ट चल्छ तर LAN चल्दैन

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

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

हरेक क्लाइन्ट गेटवे बन्न सक्दैन

AWS भन्छ कि यसको Client VPN डेस्कटप अनुप्रयोगले IP फर्वार्डिङ समर्थन गर्दैन, र अन्य क्लाइन्टहरूले गर्न सक्छन्। त्यो प्रतिबन्धले कुनै पनि आदेश टाइप गर्नुअघि नै वास्तुकला निर्धारण गर्छ। यदि उपलब्ध एकमात्र क्लाइन्ट आधिकारिक डेस्कटप अनुप्रयोग हो भने, LAN का लागि फर्वार्ड गर्ने Linux गेटवे तपाईंले पूरा गर्न सक्ने कन्फिगरेसन होइन, र कुनै पनि masquerading ले त्यो बदल्दैन।

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

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

LAN लाई टनेलतर्फ डोर्‍याउनुहोस् र अनुवाद गर्नुहोस्

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

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

नियमलाई माथिको जस्तै टनेल इन्टरफेस र VPC दायरामा सीमित गर्नुहोस्, होस्टले फर्वार्ड गर्ने सबै masquerade गर्नुको सट्टा। साँघुरो नियमबारे सोच्न सजिलो हुन्छ, र यसले आफ्नो मूल स्रोत ठेगाना राख्नुपर्ने ट्राफिकलाई चुपचाप बदल्दैन।

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

जवाफलाई पनि बाटो चाहिन्छ

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

ping मात्र होइन, काउन्टर हेर्नुहोस्। शून्य प्याकेटको masquerade नियमले अनुरोध टनेल इन्टरफेसमा कहिल्यै पुगेन भन्ने बताउँछ, जसले LAN रुट वा क्लाइन्टको आफ्नै राउटिङ तालिकातर्फ सङ्केत गर्छ। प्याकेट भए पनि जवाफ नभएको नियमले VPC पक्ष, अनुमति नियम, वा अनुवादित स्रोत स्वीकार नगर्ने सुरक्षा समूहतर्फ सङ्केत गर्छ। केही बदल्नुअघि दुवै दिशा पढ्नुहोस्, किनभने एउटै पक्षमा बढ्ने गणना ढिलो बाटो होइन, एकतर्फी बाटो हो।

इन्डपोइन्ट व्यवस्थापित सेवा हो भन्ने सम्झनुहोस्। सम्पादन गर्न सर्भर कन्फिगरेसन फाइल छैन र थप्न client-config निर्देशन छैन, त्यसैले अनुकूलित क्लाइन्ट सबनेट रुट भएको स्व-व्यवस्थापित OpenVPN सर्भरका लागि लेखिएका निर्देशनहरू लागू हुँदैनन्। AWS मा लिभरहरू सबनेट सम्बन्ध, अनुमति नियम र VPC राउटिङ तालिकाहरू हुन्।

साझा पहिचान त्यो भाग हो जसको जवाफ नीतिले दिनुपर्छ

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

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

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

क्लाइन्ट, रुट, अनुवाद र पहिचानको कथा यही क्रममा निर्धारण गर्नुहोस्। प्रत्येकले अर्कोलाई सीमित गर्छ, र यो क्रमले होस्ट किन चल्छ तर LAN किन चल्दैन भन्ने व्याख्या गर्छ।