VGW-ის BGP რეკლამები VPC მარშრუტების ცხრილის წინააღმდეგ: რა რას ცვლის

VPC ქვექსელის მარშრუტების ცხრილში დაკარგული პრეფიქსი და კლიენტის როუტერზე დაკარგული პრეფიქსი ორი სხვადასხვა ხარვეზია და მათგან მხოლოდ ერთი სწორდება AWS მარშრუტების ცხრილების შიგნით. ვირტუალური კერძო კარიბჭე აცხადებს თავის VPC-ზე მიბმულ CIDR ბლოკებს; ქვექსელის მარშრუტების ცხრილი წყვეტს, სად აგზავნის დატვირთვა პასუხს. მეორის, როგორც პირველის შეცვლის საშუალების, განხილვა ამ დიაგნოზში ყველაზე გავრცელებული არასწორი მოსახვევია. შეასრულეთ ქვემოთ მოცემული შემოწმებები თანმიმდევრობით და ორი მიმართულება ცალ-ცალკე შეინახეთ.

ნებისმიერი ცხრილის წაკითხვამდე დაასახელეთ მიმაგრება

საიტ-საიტ VPN ან ვირტუალურ კერძო კარიბჭეზე მთავრდება, ან ტრანზიტულ კარიბჭეზე, და რესურსის ID-ები განსაზღვრავენ, რომელი მარშრუტიზაციის მოდელი მოქმედებს. ჯერ ისინი წაიკითხეთ: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. პასუხი გეტყვით, შემდეგი შესამოწმებელი ცხრილი VPC მარშრუტების ცხრილია თუ ტრანზიტული კარიბჭის მარშრუტების ცხრილი.

თუ VPN ტრანზიტულ კარიბჭეზეა მიმაგრებული, შეწყვიტეთ VPC მარშრუტების ცხრილის, როგორც მართვის სიბრტყის, განხილვა. იქ VPC ცხრილი კარიბჭის მიმაგრებაზე მიუთითებს, ხოლო ასოცირება და გავრცელება ტრანზიტული კარიბჭის მარშრუტების ცხრილში ხდება. ორი ხედვის შერევა არასწორ ობიექტზე თავდაჯერებულ დასკვნებს იძლევა.

AWS-იდან ოფისისკენ მიმართულება რეკლამაა

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

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

ოფისიდან AWS-ისკენ მიმართულება გავრცელება პლუს შერჩევაა

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

წაიკითხეთ წარმომავლობა, ნაცვლად მისი ვარაუდისა: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. ჩანაწერი EnableVgwRoutePropagation წარმომავლობით BGP-იდან მოვიდა; ჩანაწერი CreateRoute წარმომავლობით ადამიანმა აკრიფა და გაიმარჯვებს მანამ, სანამ ვინმე წაშლის.

რანბუკი, რომელიც ორ მიმართულებას ცალ-ცალკე ინახავს

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

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

რა არ შეიცვალოს, სანამ იქ ხართ

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

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

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