რატომ არ ჩანს თქვენი BGP სესია VPC-ის მარშრუტების ცხრილში

განმეორებადი ამბავია, რომ EC2 VPN მოწყობილობაზე მომუშავე მარშრუტიზაციის დემონი VPC-ს თავის დისტანციურ პრეფიქსებს ასწავლის, როგორც კი BGP ამოვა. ამის ნახევარი მართალია. სესია ამოდის და ამის გამო VPC-ის მარშრუტების ცხრილში არაფერი იცვლება, ამიტომ პირველი სიმპტომი ჩვეულებრივ არის ქვექსელი, რომელიც ჩუმად ყრის ტრაფიკს შავ ხვრელში.

აქ ორი სხვადასხვა რამ ერევა ერთმანეთს: მარშრუტიზაციის სერვერთან პირინგი და მარშრუტების ცხრილში ჩადგმა.

მითი: ასწიე BGP და VPC პრეფიქსებს ისწავლის

BGP ორ მოსაუბრეს შორის საუბარია და ამ დიზაინში მოსაუბრეები არიან თქვენი მოწყობილობის მარშრუტიზაციის დემონი და VPC Route Server-ის ბოლო წერტილი, რომელსაც AWS თქვენს საკუთარ ქვექსელში ათავსებს. ეს საუბარი პრეფიქსებს ატარებს. ის არ ეხება თქვენი დატვირთვის ქვექსელების მარშრუტების ცხრილს, რადგან ეს ცხრილები სწავლობს მხოლოდ გავრცელების გზით, რომელიც თითოეულ მათგანზე უნდა ჩაირთოს. სანამ ეს მოხდება, VPC-ის ქსოვილმა არაფერი იცის იმის შესახებ, რაც მოწყობილობამ იცის.

კონფიგურაციის ნაბიჯები განცალკევებულია მიზეზის გამო: დაკავშირება, ბოლო წერტილის შექმნა, პირინგი, შემდეგ გავრცელების ჩართვა.

Route Server საკონტროლო სიბრტყეა და არა გვირაბი

Route Server არც ერთ პაკეტს არ შიფრავს, არ გადასცემს და არ ამოწმებს. ის არსებობს იმისთვის, რომ მოწყობილობასთან BGP გაცვალოს და მიღებული პრეფიქსები გადასცეს იმ მარშრუტების ცხრილებს, რომლებიც მათ მისაღებად არიან კონფიგურირებული. მონაცემთა სიბრტყე უცვლელია: პაკეტები კვლავ გადის მოწყობილობის ქსელურ ინტერფეისზე, მოძრაობს მის VPN-ში და ბრუნდება იმავე გზით.

ეს ნიშნავს, რომ გადამცემ ინსტანსზე წყაროსა და დანიშნულების შემოწმება კვლავ მნიშვნელოვანია, რადგან ინსტანსი ახლა სხვისთვის მიმართულ ტრაფიკს გადასცემს.

უსაფრთხოების ჯგუფები და ქვექსელის კონტროლი ასევე ვრცელდება გადაცემულ ნაკადზე. Route Server არ აიძულებს ტრაფიკის მომშორებელ მოწყობილობას მის გადაცემას და არ შეაკეთებს დისტანციურ მხარეს დაკარგულ დაბრუნების მარშრუტს.

გავრცელება თითოეული მარშრუტის ცხრილისთვისაა და არა მთელი VPC-ისთვის

მარშრუტიზაციის სერვერის VPC-თან დაკავშირება და მარშრუტების ცხრილზე გავრცელების ჩართვა ორი გადაწყვეტილებაა და მხოლოდ მეორე ცვლის იმას, რასაც ქვექსელი აკეთებს. ექვსი მარშრუტის ცხრილის მქონე VPC-ს შეუძლია გავრცელებული პრეფიქსი ერთში მიიღოს და დანარჩენ ხუთში არა, რაც ზუსტად სწორია ჰაბ ქვექსელისთვის და ზუსტად ის არის, რაც ქმნის დამაბნეველ შედეგს «ნახევრად მუშაობს». მაშინაც კი, როცა გავრცელება ჩართულია, კონკურენტ მარშრუტს შეუძლია გაიმარჯვოს, რადგან VPC-ის მარშრუტის არჩევა უპირატესობას ანიჭებს ყველაზე გრძელ პრეფიქსს და თანაბარი სიგრძისას უპირატესობას ანიჭებს სტატიკურ მარშრუტს გავრცელებულზე. ეს უპირატესობა ჩუმად გამოიყენება.

შეამოწმეთ კონკრეტული ქვექსელის ეფექტური ცხრილი და არა იმ პრეფიქსების სია, რომლებსაც მოწყობილობა აცხადებს. API პირდაპირ პასუხობს ამ კითხვას: aws ec2 associate-route-server და aws ec2 enable-route-server-propagation --route-table-id <id> ის ორი ნაბიჯია, რომლებსაც ადამიანები ივიწყებენ, ხოლო aws ec2 describe-route-tables --route-table-ids <id> გვიჩვენებს, საერთოდ მოვიდა თუ არა პრეფიქსი route server-ის ჩანაწერად.

მოწყობილობა კვლავ ყველა პაკეტს ატარებს

ხელმისაწვდომობის გამოცხადება იგივე არ არის, რაც მისი ქონა. BGP სესია შეიძლება დარჩეს დამყარებული, სანამ მოწყობილობის VPN გამორთულია, და არასოდეს ცვალებადი სტატიკური განცხადება აგრძელებს ტრაფიკის მკვდარი გზისკენ წევას. Route Server მხარს უჭერს ხარვეზების აღმოჩენას, მაგალითად BFD-ს, მაგრამ ეს პარტნიორის სიცოცხლისუნარიანობას ამოწმებს და არა მის უკან ყველაფრის ჯანმრთელობას.

მიამაგრეთ განცხადება რეალურ დისტანციურ მარშრუტს: გამოაცხადეთ პრეფიქსი, როცა გვირაბი და დისტანციური ქსელი მუშაობს, და გაიწვიეთ, როცა არ მუშაობს.

გაიწვიეთ პრეფიქსი და ნახეთ რა მოხდება

შეამოწმეთ ეტაპობრივად და ბოლო ეტაპად მოხსნა გააკეთეთ. დაადასტურეთ, რომ განცხადება აღწევს, პრეფიქსი ჩნდება თითოეულ განზრახ ცხრილში, მოწყობილობა შემდეგი ნახტომია, გადაცემა გადის აქტიურ გვირაბში და დისტანციური მხარე პასუხობს. შემდეგ გაიწვიეთ სატესტო პრეფიქსი ან დახურეთ დამტკიცებული გვირაბი და დააკვირდით, გადადის თუ არა ტრაფიკი იქ, სადაც დიზაინი ამბობს. ჩაწერეთ ცხრილები ტესტის დაწყებამდე და შემდეგ, სანამ ტესტი ღიაა.

მარშრუტის მეორე მოწყობილობაზე გადატანა არ გადააქვს ის სესიები, რომლებსაც ის ატარებდა, რადგან NAT-ისა და firewall-ის მდგომარეობა პირველ მოწყობილობაზე რჩება.

ერთი ათეული პრეფიქსის ფიქსირებული ნაკრებისთვის VPC-ის ცხრილებში სტატიკური მარშრუტები უფრო იაფ პასუხად რჩება. Route Server იმსახურებს თავის ადგილს, როცა პრეფიქსების სია ნამდვილად იცვლება და გაწვევის პოლიტიკა ისეთი რამ არის, რაც მორიგეობის ადამიანს შეგიძლიათ აუხსნათ.