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 და გამოცხადებული პრეფიქსები თითოეული გვირაბისთვის ერთ ცხრილში. სწორედ ეს ცხრილი ხდის შემდეგ ცვლილებას განხილვადს.