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 तक नहीं पहुँचता, क्योंकि आपने जिस पड़ोसी को कॉन्फ़िगर किया है वही पता आपका अपना इंटरफ़ेस पहले से रखता है।

मार्क और 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 और घोषित प्रीफ़िक्स एक ही तालिका में दर्ज कीजिए। वही तालिका अगले बदलाव को समीक्षा-योग्य बनाती है।