एक Client VPN endpoint त्याच्या संबंधित VPC शी peered असलेल्या VPC पर्यंत पोहोचू शकतो, आणि ते कायदेशीर करण्यासाठी तुम्हाला bastion ची गरज नाही. करण्यासारखा निवड म्हणजे रहदारी कुठे हात बदलते: association सबनेटमध्ये उतरणारा आणि peering कनेक्शन ओलांडणारा endpoint मार्ग, किंवा peered VPC मधील host जो सत्र संपवतो. दोन्ही मार्ग काम करतात आणि ते वेगवेगळ्या ठिकाणी अपयशी होतात, म्हणून निर्णय मालकी आणि ऑडिटबद्दल आहे, AWS काय परवानगी देते याबद्दल नाही. त्यांच्यात मी कसा निवडतो आणि routed मार्ग कार्यान्वित करणाऱ्या चार नोंदी येथे आहेत.

दोन मार्ग, एक endpoint, वेगळे मालक

routed मार्गावर क्लायंट रहदारी endpoint पर्यंत पोहोचते, association सबनेटमधील Client VPN नेटवर्क इंटरफेसच्या पत्त्यात भाषांतरित होते, आणि A ते B peering कनेक्शनद्वारे ते सबनेट सोडते. VPC B कोणतेही VPN सत्र संपवत नाही; ते VPC A कडून सामान्य रहदारी पाहते, म्हणून त्याचा रिटर्न मार्ग क्लायंट पूलकडे नाही, VPC A कडे निर्देश करतो.

bastion मार्गावर क्लायंट प्रथम host पर्यंत पोहोचतो. A मधील bastion शेवटची हॉप अजूनही peering कनेक्शन ओलांडू देतो, त्यामुळे peering काम राहते आणि एक सत्र जोडले जाते. B मधील bastion लाही क्लायंटकडून मार्ग हवा, आणि जेव्हा तो मार्ग तोच endpoint मार्ग असेल, तेव्हा routed रचनेत एक हॉप वाढतो. bastion काम कमी करतो तेव्हाच जेव्हा तो आधीच अस्तित्वात आहे, आधीच मंजूर आहे, आणि त्याच्या मागील गोष्टीला नेटवर्क सीमेऐवजी सत्र सीमा हवी आहे.

चार नोंदी routed मार्ग कार्यान्वित करतात

AWS हे परिदृश्य Client VPN how-it-works पृष्ठावर दस्तऐवजीकरण करते, आणि प्रत्यक्षात दोन किंवा तीन संघांच्या मालकीच्या चार नोंदींवर येते. श्रेणी उदाहरणात्मक आहेत; peered श्रेणी अद्वितीय असावी आणि रिटर्न श्रेणी तुमच्या योजनेशी जुळावी.

ControlWhat it must say
Endpoint route10.70.0.0/16 targets the association subnet
Authorization ruleThe approved group may reach 10.70.0.0/16
VPC A association-subnet table10.70.0.0/16 targets the peering connection
VPC B resource-subnet tableVPC A's range targets the same peering connection

मार्ग आणि परवानगी स्वतंत्र नियंत्रणे आहेत. जुळणाऱ्या अधिकृतता नियमाशिवाय योग्य endpoint मार्ग क्लायंटला काहीही देत नाही; endpoint मार्गस्थ करू शकत नाही अशा गंतव्यासाठीचा अधिकृतता नियम त्याला काळी भोक देतो. दोन्हींनी एकच श्रेणी नमूद करावी.

endpoint मार्ग endpoint च्या स्वतःच्या VPC मधील सबनेटकडे निर्देश करतो, कधीही peering कनेक्शनकडे नाही. VPC मार्ग सारण्या peering कनेक्शनकडे निर्देश करतात, कधीही instance किंवा इंटरफेसकडे नाही. दोन्हींमध्ये मूल्य कॉपी करणे तक्रारीशिवाय साठवले जाते आणि काहीही मार्गस्थ करत नाही.

association सबनेट क्लायंटचा स्रोत भाषांतरित करतो, म्हणून B ने क्लायंट पूलकडे नाही, VPC A कडे परत मार्गस्थ करावे. peering कनेक्शनवर क्लायंट श्रेणी पाठवणे सममितीय दिसते, पुनरावलोकन पास होते आणि शांतपणे अपयशी होते कारण B कधीही क्लायंट स्रोत असलेले पॅकेट पाहत नाही.

सुरक्षा गट आणि परवानगीचा शेवटचा मीटर

मार्गस्थ करणे पॅकेट B मध्ये आणते; निर्णय B अजूनही घेतो. त्याच प्रदेशातील सक्रिय peering कनेक्शनसाठी, B मधील सुरक्षा गट Client VPN association वर लागू केलेल्या गटाचा संदर्भ देऊ शकतो, ज्यामुळे नियम अरुंद राहतो आणि पत्ता बदलांना तोंड देतो. जिथे गट संदर्भ शक्य नाही, तिथे 0.0.0.0/0 पर्यंत रुंदावण्याऐवजी association सबनेट श्रेणी स्पष्टपणे परवानगी द्या, कारण ते मार्गस्थ त्रुटीला स्पष्टीकरण नसलेल्या टाइमआउटमध्ये बदलते.

नंतर मार्गस्थ करणे कधीही स्पर्श न करणारे तपासा: दोन्ही सबनेटवरील नेटवर्क ACL, अनुप्रयोगाची allow-list किंवा टोकन प्रेक्षक, आणि DNS. peering खाजगी होस्टेड झोन कॉपी करत नाही, त्यामुळे लॅपटॉप सोडवू शकत नाही अशा पत्त्याकडे कार्यरत मार्ग ठेवू शकतो, आणि peering कनेक्शन प्रमाणपत्रात विश्वास जोडत नाही. endpoint ला B साठी उत्तर देणाऱ्या resolver कडे निर्देश करा, नंतर खाजगी नाव आणि प्रमाणपत्र जुळतात याची खात्री करा.

bastion प्रामाणिक उत्तर कधी असतो

मी जाणूनबुजून bastion निवडण्यासाठी तीन ट्रिगर ठेवतो. peered VPC तुमच्या श्रेणीसाठी रिटर्न मार्ग जोडणार नाही अशा किंवा गट संदर्भ स्वीकारणार नाही अशा संघाचे आहे. प्रवेश प्रत्येक सत्रासाठी मंजूर किंवा नोंदवला पाहिजे आणि अनुप्रयोग ते स्वतः वाहू शकत नाही. किंवा शेवटची हॉप B च्या आत राहिली पाहिजे कारण सेवा फक्त तिथेच सोडवली जाते आणि तिची TLS ओळख अंतर्गत नावाशी पिन केलेली आहे.

यापैकी काहीही peering संक्रामक नाही या वस्तुस्थितीभोवतीचा मार्ग नाही. संक्रामकता नसणे B मधील संसाधने काय करू शकतात हे मर्यादित करते: ते A ला A सोबत peered असलेल्या तिसऱ्या VPC कडे ट्रान्झिट म्हणून वापरू शकत नाहीत. याचा अर्थ VPN वापरकर्ता थेट peered VPC पर्यंत पोहोचू शकत नाही असा कधीही नव्हता, आणि ती चुकीची वाचन टाळण्यासाठी बांधलेला bastion हा कारणाशिवाय पॅच करायचा host आहे.

उलट चूक काळानुसार जास्त महाग पडते: प्रत्येक संघाला आधीच अस्तित्वात असलेल्या एकमेव bastion मधून जाऊ द्या, नंतर त्याचा सुरक्षा गट, मार्ग सारणी आणि पॅच विंडो हे उत्पादन अवलंबन आहे हे शोधा. host कोणत्या ट्रिगरची सेवा करतो ते लिहा, आणि ट्रिगर गेल्यावर तो निवृत्त करा.

Transit Gateway आणि अनेक association गणना बदलतात

जर endpoint सबनेटऐवजी थेट Transit Gateway ला जोडलेला असेल, तर मॉडेल बदलते: क्लायंट यापुढे association सबनेटमधील इंटरफेस पत्त्यात भाषांतरित होत नाहीत, आणि gateway मार्ग सारण्यांनी क्लायंट श्रेणी आणि peered VPC कडे नेणारे जोडणी दोन्ही वाहून न्यावे. हे प्रमाणात स्वच्छ आहे, पण काम चार नोंदींमधून gateway मार्ग सारण्यांमध्ये सरकते.

अनेक association तपासण्या गुणाकारतात. endpoint मार्ग endpoint चा आहे, तरीही प्रत्येक association सबनेटला खऱ्या peering पुढील हॉपसह मार्ग सारणी हवी. एका association मधून सत्र यशस्वी होऊ शकते तर दुसऱ्याला रिटर्न मार्ग नसेल, म्हणून प्रत्येकाची चाचणी करा.

बिघाड लवकर शोधणारा पडताळणी क्रम

हे क्रमाने चालवा; प्रत्येक पायरी पुढील अपयशी होत असतानाही पास होऊ शकते, आणि क्लायंट टाइमआउट कोणते तुटले हे जवळपास कधीही सांगत नाही.

  1. क्लायंटकडून अनुप्रयोगाचे नाव सोडवा आणि पत्ता peered श्रेणीत आहे याची तपासणी करा.
  2. कनेक्ट करा, नंतर सत्र संपवलेल्या association साठी endpoint कनेक्शन लॉग वाचा.
  3. त्या association सबनेटवर, मार्ग सारणी peered श्रेणी सक्रिय peering कनेक्शनकडे निर्देश करते याची खात्री करा.
  4. B मधील संसाधन सबनेटवर, इंटरफेस श्रेणीसाठी रिटर्न नोंद आणि जुळणारे गट नियम तपासा.
  5. एक परवानगी असलेले ऑपरेशन आणि पोहोचू नये असे एक संसाधन चाचणी करा; दुसरे डीबगिंगचे अवशेष पकडते.
  6. कोणत्याही split-tunnel मार्ग बदलानंतर पुन्हा कनेक्ट करा, कारण चालू असलेली टनेल नवीन मार्ग संच घेणार नाही.

लक्षात ठेवण्यासारखी दोन लक्षणे आहेत. उत्तर न देता B पर्यंत पोहोचणारा SYN जवळपास नेहमीच गहाळ रिटर्न मार्ग असतो. पूर्ण होऊन नंतर रीसेट होणारे कनेक्शन सहसा गट, ACL किंवा अनुप्रयोग असते. दोन्ही endpoint लॉगमध्ये कारण म्हणून दिसत नाहीत, म्हणून चार नोंदी प्रत्येकाच्या शेजारी मालकासह ठेवा.

तीन ट्रिगरपैकी कोणताही लागू नसेल तर routed मार्ग पूर्ण करा आणि त्या चार नोंदी नोंदवा. एक लागू असेल तर bastion फक्त त्या सीमेसाठी ठेवा आणि समोर सत्र न लागणाऱ्या सेवांसाठी endpoint मार्ग सोडा.

संबंधित लेख