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 र घोषित प्रिफिक्सहरू एउटै तालिकामा लेख्नुहोस्। त्यही तालिकाले अर्को परिवर्तनलाई समीक्षायोग्य बनाउँछ।