AWS Site-to-Site VPN: बाहेर, आत आणि LAN प्रीफिक्स

AWS Site-to-Site VPN मधील बहुतेक चुका पत्त्यांच्या चुका असतात आणि कोणतेही पॅकेट हलण्यापूर्वी त्या होतात. टनेलचे बाह्य पत्ते IPsec पीअरपर्यंत पोहोचतात, आतील पत्ते त्यांच्यातील राउटिंग दुवा बनवतात, आणि संरक्षित प्रीफिक्स हे तो दुवा ज्यासाठी आहे तेच. एक भूमिका दुसऱ्यात कॉपी करा आणि टनेल वर येते पण काहीच राउट होत नाही. BGP कस्टमर गेटवेवर मी वापरतो तो वाचा-तपासा-कॉन्फिगर करा क्रम हा आहे, आणि मूल्ये स्मरणातून नाही तर डाउनलोड केलेल्या उपकरण कॉन्फिगरेशनमधून घेतली आहेत.

तीन पत्ता भूमिका, एक टनेल

बाह्य पत्ते सार्वजनिक आहेत आणि IPsec पीअरचे आहेत: AWS बाजूला प्रत्येक टनेलसाठी एक, आणि तुमच्या बाजूला कस्टमर गेटवेची पोहोचण्यायोग्य ओळख, तुमच्या प्रत्यक्ष NAT रचनेनुसार जुळवून. आतील पत्ते खाजगी आहेत आणि तार्किक दुव्याचे आहेत, ज्याला AWS 169.254.0.0/16 मधून घेतलेला /30 म्हणून नोंदवते. संरक्षित प्रीफिक्स म्हणजे त्या दुव्यावर तुम्ही राउट करता आणि जाहीर करता ती VPC, स्थानिक किंवा ट्रान्झिट नेटवर्क.

टनेल इंटरफेसचा पत्ता म्हणून LAN प्रीफिक्स देणे हे या चुकीचे क्लासिक स्वरूप आहे. इंटरफेस कॉन्फिगर केलेला दिसतो, LAN जाहीर होत नाही, आणि समोरच्या बाजूला त्यासाठी मार्ग नाही. टनेल स्वतःचा आतील ping पार करू शकते, पण प्रत्येक अनुप्रयोग नाव वेळ संपते. टनेल पर्याय संदर्भ आतील CIDR च्या मर्यादा सांगतो, ते कोणत्या पत्ता श्रेणीतून असावे हेही.

मूल्ये डाउनलोड केलेल्या कॉन्फिगरेशनमधून वाचा

कनेक्शनमधून तुमच्या विशिष्ट उपकरण मॉडेलसाठीचे कॉन्फिगरेशन डाउनलोड करा, नंतर त्याच्या पत्ता तक्त्याला सत्याचा स्रोत माना. कन्सोल प्रत्येक टनेलसाठी तीच मूल्ये दाखवते: बाह्य IP, आतील CIDR आणि AWS बाजूचा BGP पीअर पत्ता. दोन्ही टनेल स्वतंत्र वस्तू आहेत, स्वतंत्र बाह्य अंतबिंदू आणि स्वतंत्र आतील /30 सह, दोन्ही एकाच संरक्षित नेटवर्क वाहत असले तरी.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,TunnelInsideCidr]'
aws ec2 describe-customer-gateways --customer-gateway-ids cgw-0123456789abcdef0 \
  --query 'CustomerGateways[0].[IpAddress,BgpAsn]'

डाउनलोड केलेली फाइल आणि थेट कन्सोल जुळत नसल्यास फाइल जुनी आहे. पत्ते हाताने संपादित करण्याऐवजी पुन्हा डाउनलोड करा, कारण आतील जोडी आणि पीअरच्या कॉन्फिगर केलेल्या शेजाऱ्यातील फरक हा शांत BGP अपयश आहे.

योग्य पत्ता टाकून दुवा तयार करा

Linux गेटवेवर टनेल VTI किंवा XFRM इंटरफेस आहे, आणि आतील /30 त्या इंटरफेसवर जातो. दोन टनेल म्हणजे दोन इंटरफेस आणि दोन BGP शेजारी, प्रत्येक AWS अंतबिंदूसाठी एक. AWS डाउनलोड केलेल्या उपकरण कॉन्फिगरेशनमध्ये जी प्रथा छापते ती व्हर्च्युअल खाजगी गेटवेला प्रत्येक आतील /30 च्या पहिल्या पत्त्यावर आणि तुमच्या कस्टमर गेटवेला दुसऱ्यावर ठेवते, म्हणून तुम्ही वरचा पत्ता घेता आणि खालच्याशी पीअर करता. इथे कोणालाही LAN पत्त्याची गरज नाही.

ip tunnel add tun0 mode vti local 203.0.113.10 remote 18.230.1.1 key 42
ip addr add 169.254.10.2/30 dev tun0
ip link set tun0 up mtu 1400
ip tunnel add tun1 mode vti local 203.0.113.10 remote 18.230.2.1 key 43
ip addr add 169.254.10.6/30 dev tun1
ip link set tun1 up mtu 1400

तुमच्या उपकरण मॉडेलची फाइल उलटी जोडी छापत असल्यास तिचे आकडे वापरा आणि नियम पाळा: इंटरफेसवरील पत्ता तुमचा, पीअरचा पत्ता AWS चा. हे उलटे केल्यास कधीही Established गाठणार नाही असे टनेल तयार होते, कारण तुम्ही कॉन्फिगर केलेला शेजारी हा तुमच्या स्वतःच्या इंटरफेसकडे आधीच असलेला पत्ता आहे.

mark आणि VTI किल्ली IKE डीमन चाइल्ड SA इंटरफेसशी बांधण्यासाठी वापरतो त्याच्याशी जुळवून ठेवा, नाहीतर रहदारी टनेलवर येते पण उतरण्यासाठी इंटरफेस नसतो. दुसऱ्या साइटवरून आकडा कॉपी करण्याऐवजी MTU मार्ग आणि IKE डीमनच्या स्वतःच्या सेटिंग्जविरुद्ध तपासा.

मार्ग तपासण्यापूर्वी BGP तपासा

IPsec वर येणे म्हणजे पीअर सुरक्षा संघटनेवर सहमत आहेत एवढेच सिद्ध होते, इतर काही नाही. BGP सत्र हे आतील दुव्यावरचे स्वतंत्र बोलणे आहे, म्हणून शेजाऱ्याची स्थिती आणि प्रीफिक्स काउंटर वाचा, नंतर तुम्ही जाहीर करण्याचा विचार केलेल्या गोष्टीशी तुलना करा.

ip -s addr show dev tun0
vtysh -c 'show bgp summary'
vtysh -c 'show bgp neighbors 169.254.10.1'
vtysh -c 'show ip bgp neighbors 169.254.10.1 advertised-routes'

Established स्थिती आणि शून्य प्रीफिक्स मिळणे ही धोरण किंवा जाहिरातीची समस्या आहे, टनेलची नाही. संपूर्ण तपासणी दुसऱ्या टनेलवर पुन्हा करा; चालणारे पहिले टनेल पत्ते विश्वासार्ह आहेत असे सांगते, दुसरे टनेल कॉन्फिगर झाले आहे असे नाही.

राउट झालेल्या पॅकेटचा मागोवा घ्या, नंतर थांबा

सत्र प्रीफिक्स वाहू लागल्यावर गेटवेवरून दोन्ही दिशांनी मार्ग तपासा: स्रोत पत्ता, पुढील हॉप आणि रहदारीस परवानगी देणारे सुरक्षा धोरण. BGP सत्र वर असू शकते पण तुमच्या अनुप्रयोगाला हवा असलेला विशिष्ट प्रीफिक्स गाळलेला, सारांशित किंवा चुकीच्या इंटरफेसकडे निर्देशित असू शकतो.

Reachability Analyzer हे AWS बाजूचे साधन आहे, जे स्रोत, गंतव्य आणि मार्ग घेते आणि समर्थित कॉन्फिगरेशनमध्ये कोणत्या घटकाने तो अडवला ते सांगते. VPC पासून तुमच्या कस्टमर गेटवे पत्त्यापर्यंतचा मार्ग तपासण्यासाठी याचा वापर करा, अनुप्रयोग होस्टवरून नाही. ते कॉन्फिगरेशनचे विश्लेषण करते आणि स्थानिक फायरवॉलमधून पॅकेट पाठवत नाही, म्हणून त्याचा निर्णय तुमच्या स्वतःच्या इंटरफेस काउंटर आणि पॅकेट कॅप्चरपासून वेगळा ठेवा.

प्रत्येक टनेलची बाह्य जोडी, आतील /30 आणि जाहीर केलेले प्रीफिक्स एकाच तक्त्यात नोंदवा. तोच तक्ता पुढील बदल पुनरावलोकनयोग्य करतो.