एका AWS VPN टनेलवर अनेक LAN: SA मर्यादेचा अर्थ काय आहे
AWS प्रत्येक टनेलसाठी एक IPsec SA जोडीला परवानगी देते, आणि ती एक-सबनेट मर्यादा नाही। प्रथम संरक्षण व्याप्ती राउटिंग आणि प्रवेशापासून वेगळी करा।
AWS Site-to-Site VPN मध्ये दुसरे शाखा LAN जोडण्यासाठी त्या टनेलच्या आत दुसरे स्वतंत्र IPsec संलग्नीकरण आवश्यक नाही। लोक ज्या मर्यादेवर अडखळतात ती वास्तविक आहे, पण ऐकण्यापेक्षा अरुंद आहे: AWS दस्तऐवजीकरण करते प्रति टनेल एक अद्वितीय IPsec SA जोडी, एक येणारी आणि एक जाणारी, आणि एका कनेक्शनच्या दोन्ही टनेलना प्रत्येकी स्वतःची जोडी मिळते। हा सेवेचा गुणधर्म आहे, IPsec एका वेळी एक सबनेटचे संरक्षण करते असा नियम नाही। हा फरक सर्वात जास्त तेव्हा महत्त्वाचा असतो जेव्हा धोरण-आधारित ग्राहक गेटवे प्रत्येक धोरण नोंदीचे स्वतःचे संलग्नीकरण करते।
LAN यादीपासून नाही, कनेक्शनपासून सुरू करा
कन्सोलमध्ये कनेक्शन उघडा आणि ते कसे राउट होते ते पहा। स्थिर कनेक्शन तुम्ही जाहीर केलेले दूरस्थ प्रीफिक्स वाहते। BGP कनेक्शन ते ग्राहक गेटवेकडून शिकते।
कोणत्याही प्रकारे, टनेल राउट-आधारित आहे। त्यात काय जाते हे तुमचे उपकरण वाटाघाटी करणारे सिलेक्टर ठरवतात, फॉर्ममध्ये टाइप करता येणाऱ्या सबनेटची संख्या नाही।
ग्राहक गेटवे कशावर वाटाघाटी करते ते पहा
धोरण-आधारित उपकरण प्रत्येक धोरण नोंदीचे स्वतःचे SA करू शकते। दोन LAN म्हणजे दोन नोंदी, म्हणजे दोन SA, आणि इथूनच प्रति-टनेल मर्यादा महत्त्वाची होऊ लागते। ग्राहक गेटवेच्या आवश्यकता नेमके या वर्तनाबद्दल इशारा देतात आणि त्या उपकरणांवर एकत्रित नियम सुचवतात। उपकरणावरील ACL संख्येऐवजी वाटाघाटी केलेले सिलेक्टर तपासा।
उपकरणाला दोन्ही प्रीफिक्स एकाच धोरणाखाली सादर करण्यासाठी कॉन्फिगर करणे आवश्यक आहे, अन्यथा दूरचे टोक निकाल टिकवू शकणार नाही।
तीन याद्या, वेगळ्या ठेवलेल्या
या तीन याद्या मिसळा आणि प्रत्येक बदल अंदाज बनतो। त्या वेगळ्या स्तंभांमध्ये ठेवा आणि तुमच्या स्वतःच्या नेटवर्कसाठी प्रत्येक भरा।
| Inventory | What belongs there |
|---|---|
| Required networks | 10.20.10.0/24 and 10.20.30.0/24, as presented after any deliberate translation |
| Protection agreement | the selectors the tunnel actually negotiated for those prefixes |
| Delivery and permission | VPC routes, return routes, security groups and any filtering |
फक्त मधला स्तंभ SA मर्यादेने बांधलेला आहे। पहिला स्तंभ व्यावसायिक तथ्य आहे, आणि तिसरा स्तंभ हा आहे जो अनुप्रयोग चालवतो। तुम्ही लिहिलेल्या ACL ओळींच्या संख्येवरून व्याप्तीचा अंदाज लावण्याऐवजी उपकरणावर स्वीकारलेले सिलेक्टर वाचा।
परवानगी न वाढवता एकत्रित करा
सारांश मार्ग हा एक धोरण नोंद मिळवण्याचा स्पष्ट मार्ग आहे, आणि संरक्षित संच शांतपणे वाढण्याचा मार्गही तोच आहे। दोन्ही /24 व्यापणारा /20 असा पत्तेही व्यापतो जे कोणतीही शाखा वापरत नाही, आणि टनेल ते आनंदाने वाहून नेईल। जर सारांश करावाच लागत असेल, तर तो प्राप्ती बाजूच्या फिल्टरिंगशी जोडा जेणेकरून अतिरिक्त जागा केवळ जाहीर न होण्याऐवजी नाकारली जाईल। नाकारलेला पॅकेट पुरावा आहे। न जाहीर केलेला पत्ता केवळ पुराव्याचा अभाव आहे।
संरक्षण धोरण एकत्रित करणे हे काय एन्क्रिप्ट केले जाऊ शकते यातील बदल आहे। हे प्रवेशाचे अनुदान नाही आणि तसे मानले जाऊ नये।
दोन्ही LAN तपासा, नंतर दोन्ही टनेल ठेवा
समन्वित बदलानंतर सक्रिय संरक्षण व्याप्ती तपासा आणि नंतर प्रत्येक LAN मधून वास्तविक अनुप्रयोग चालवा। एक सबनेट चालणे दुसऱ्याच्या सिलेक्टर व्याप्तीबद्दल काहीही सिद्ध करत नाही, आणि त्याच्या प्रतिसाद मार्गाबद्दल त्याहून कमी।
डिझाइनमध्ये दोन्ही टनेल ठेवा। धोरण एकत्रित करणे म्हणजे अतिरेक टाकून देण्याची परवानगी नाही, आणि प्रत्येक शाखा LAN वाहणारे एकच टनेल पुढील देखभाल विंडोला व्यत्यय बनवते।
वाटाघाटी केलेले सिलेक्टर, दोन्ही प्रीफिक्स आणि मार्ग मालक एकाच बदल नोंदीत लिहा। तिसरा LAN आल्यावर ती नोंद तुम्हाला सांगेल की तुम्ही सिलेक्टर जोडत आहात की नव्याने सुरू करत आहात।