एका 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 का चालत नाही.