AWS Site-to-Site VPN. արտաքին, ներքին և LAN նախածանց

AWS Site-to-Site VPN-ի սխալների մեծ մասը հասցեների սխալներ են, և դրանք կատարվում են նախքան որևէ փաթեթի շարժվելը։ Թունելի արտաքին հասցեները հասնում են IPsec զուգընկերներին, ներքին հասցեները կազմում են նրանց միջև եղած երթուղային կապը, իսկ պաշտպանված նախածանցերը այն են, ինչի համար այդ կապը գոյություն ունի։ Պատճենեք մի դերը մյուսի մեջ, և թունելը բարձրանում է, մինչդեռ ոչինչ չի երթուղվում։ Ահա ընթերցել-ստուգել-կարգավորել հաջորդականությունը, որ օգտագործում եմ BGP հաճախորդային դարպասի վրա, արժեքները վերցված են ներբեռնված սարքի կոնֆիգուրացիայից, ոչ թե հիշողությունից։

Երեք հասցեի դեր, մեկ թունել

Արտաքին հասցեները հանրային են և պատկանում են IPsec զուգընկերներին՝ մեկը յուրաքանչյուր թունելի համար AWS-ի կողմում, և հաճախորդային դարպասի հասանելի ինքնությունը ձեր կողմում՝ հարմարեցված ձեր փաստացի NAT դասավորությանը։ Ներքին հասցեները մասնավոր են և պատկանում են տրամաբանական կապին, որը AWS-ը փաստաթղթավորում է որպես /30՝ վերցված 169.254.0.0/16-ից։ Պաշտպանված նախածանցերը այն VPC, տեղական կամ տրանզիտ ցանցերն են, որոնք երթուղավորում և հայտարարում եք այդ կապով։

LAN նախածանցը որպես թունելի ինտերֆեյսի հասցե նշանակելը այս սխալի դասական ձևն է։ Ինտերֆեյսը կարգավորված է թվում, LAN-ը չի հայտարարվում, և հակառակ կողմը դրա համար երթուղի չունի։ Թունելը կարող է նույնիսկ անցնել սեփական ներքին ping-ը, մինչդեռ յուրաքանչյուր հավելվածի անուն ժամանակավոր է դուրս գալիս։ Թունելի ընտրանքների տեղեկատուը թվարկում է ներքին CIDR-ի սահմանափակումները, ներառյալ այն հասցեների տիրույթը, որից այն պետք է լինի։

Կարդացեք արժեքները ներբեռնված կոնֆիգուրացիայից

Ներբեռնեք կոնֆիգուրացիան ձեր կոնկրետ սարքի մոդելի համար միացումից, ապա դրա հասցեների աղյուսակը ընդունեք որպես ճշմարտության աղբյուր։ Կոնսոլը ցույց է տալիս նույն արժեքները յուրաքանչյուր թունելի համար՝ արտաքին IP, ներքին CIDR և BGP զուգընկերոջ հասցեն AWS-ի կողմում։ Երկու թունելները առանձին օբյեկտներ են՝ առանձին արտաքին վերջնակետերով և առանձին ներքին /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-ը և հայտարարված նախածանցները յուրաքանչյուր թունելի համար մեկ աղյուսակում։ Հենց այդ աղյուսակն է հաջորդ փոփոխությունը դարձնում վերանայելի։