एक 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 नहीं।