peered VPC मा पुग्न AWS Client VPN वा bastion

एउटा 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 दायरा अद्वितीय हुनुपर्छ र रिटर्न दायरा तपाईंको योजनासँग मिल्नुपर्छ।

मार्ग र अनुमति छुट्टाछुट्टै नियन्त्रण हुन्। मिल्ने अधिकार नियम नभएको सही endpoint मार्गले ग्राहकलाई केही दिँदैन; endpoint ले routed गर्न नसक्ने गन्तव्यको लागि अधिकार नियमले उसलाई कालो प्वाल दिन्छ। दुवैले एउटै दायरा उल्लेख गर्नुपर्छ।

endpoint मार्गले endpoint को आफ्नै VPC को सबनेटमा सङ्केत गर्छ, कहिल्यै peering जडानमा होइन। VPC मार्ग तालिकाहरूले peering जडानमा सङ्केत गर्छन्, कहिल्यै instance वा इन्टरफेसमा होइन। दुईबीच मान प्रतिलिपि गर्दा उजुरी बिना सुरक्षित हुन्छ र केही routed हुँदैन।

association सबनेटले ग्राहकको स्रोत अनुवाद गर्छ, त्यसैले B ले ग्राहक पूलमा होइन, VPC A मा फर्केर routed गर्नुपर्छ। peering जडानमा ग्राहक दायरा पठाउनु सममित देखिन्छ, समीक्षा पास हुन्छ र चुपचाप असफल हुन्छ किनकि B ले कहिल्यै ग्राहक स्रोत भएको प्याकेट देख्दैन।

सुरक्षा समूह र अनुमतिको अन्तिम मिटर

routing ले प्याकेट B मा ल्याउँछ; निर्णय B ले अझै गर्छ। एउटै क्षेत्रमा सक्रिय peering जडानका लागि, B मा रहेको सुरक्षा समूहले Client VPN association मा लागू गरिएको समूहलाई सन्दर्भ गर्न सक्छ, जसले नियम साँघुरो राख्छ र ठेगाना परिवर्तनमा टिक्छ। जहाँ समूह सन्दर्भ सम्भव छैन, त्यहाँ 0.0.0.0/0 सम्म फराकिलो बनाउनुको सट्टा association सबनेट दायरालाई स्पष्ट रूपमा अनुमति दिनुहोस्, किनकि यसले routing त्रुटिलाई अस्पष्ट टाइमआउटमा बदल्छ।

त्यसपछि routing ले कहिल्यै नछुने कुरा जाँच्नुहोस्: दुवै सबनेटमा नेटवर्क ACL, अनुप्रयोगको allow-list वा टोकन दर्शक, र DNS। peering ले निजी होस्टेड जोन प्रतिलिपि गर्दैन, त्यसैले ल्यापटपले समाधान गर्न नसक्ने ठेगानामा काम गर्ने मार्ग राख्न सक्छ, र peering जडानले प्रमाणपत्रमा विश्वास थप्दैन। endpoint लाई B को लागि जवाफ दिने resolver मा सङ्केत गर्नुहोस्, त्यसपछि निजी नाम र प्रमाणपत्र मिल्छन् भनी पुष्टि गर्नुहोस्।

bastion इमानदार उत्तर कहिले हुन्छ

मैले जानाजान bastion छान्न तीन ट्रिगर राखेको छु। peered VPC तपाईंको दायराको लागि रिटर्न मार्ग नथप्ने वा समूह सन्दर्भ स्वीकार नगर्ने टोलीको हो। पहुँच प्रत्येक सत्रको लागि स्वीकृत वा अभिलेखित हुनुपर्छ र अनुप्रयोगले त्यो आफैं बोक्न सक्दैन। वा अन्तिम हप B भित्रै रहनुपर्छ किनकि सेवा त्यहीँ मात्र समाधान हुन्छ र यसको TLS पहिचान आन्तरिक नाममा पिन गरिएको छ।

यीमध्ये केही पनि peering transitiv नहुनुको वरिपरिको बाटो होइन। अ-transitivता ले B का स्रोतहरूले के गर्न सक्छन् भन्ने सीमित गर्छ: तिनीहरूले A लाई A सँग peered भएको तेस्रो VPC मा transit को रूपमा प्रयोग गर्न सक्दैनन्। यसको अर्थ VPN प्रयोगकर्ता सीधै peered VPC मा पुग्न सक्दैन भन्ने कहिल्यै थिएन, र त्यो गलत पढाइ छल्न बनाइएको bastion बिना कारण patch गर्नुपर्ने host हो।

उल्टो गल्ती समयसँगै महँगो पर्छ: हरेक टोलीलाई पहिले नै रहेको एउटै bastion बाट पठाउनुहोस्, त्यसपछि थाहा पाउनुहोस् कि यसको सुरक्षा समूह, मार्ग तालिका र patch विन्डो नै उत्पादन निर्भरता हुन्। 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 मार्ग छोड्नुहोस्।