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 మరియు ప్రకటించిన ప్రిఫిక్స్‌లను ఒకే పట్టికలో నమోదు చేయండి. ఆ పట్టికే తదుపరి మార్పును సమీక్షించదగినదిగా చేస్తుంది.