VGW BGP sludinājumi pret VPC maršrutu tabulu: kas ko maina
VPC maršrutu tabula kontrolē pārsūtīšanu apakštīklos; tā nemaina to, ko virtuālā privātā vārteja sludina ar BGP. Izsekojiet katram virzienam atsevišķi.
Trūkstošs prefikss VPC apakštīkla maršrutu tabulā un trūkstošs prefikss klienta maršrutētājā ir divi dažādi bojājumi, un tikai viens no tiem tiek novērsts AWS maršrutu tabulu iekšienē. Virtuālā privātā vārteja sludina ar savu VPC saistītos CIDR blokus; apakštīkla maršrutu tabula nosaka, kur darba slodze sūta atbildi. Uz otro attiekties kā uz veidu, kā mainīt pirmo ir visizplatītākais nepareizais pagrieziens šajā diagnostikā. Izpildiet tālāk minētās pārbaudes secīgi un turiet abus virzienus atsevišķi.
Pirms jebkuras tabulas lasīšanas nosauciet piesaisti
Site-to-Site VPN beidzas vai nu virtuālajā privātajā vārtējā, vai tranzīta vārtējā, un resursu ID nosaka, kurš maršrutēšanas modelis attiecas. Vispirms izlasiet tos: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Atbilde pateiks, vai nākamā pārbaudāmā tabula ir VPC maršrutu tabula vai tranzīta vārtējas maršrutu tabula.
Ja VPN ir piesaistīts tranzīta vārtējai, pārtrauciet VPC maršrutu tabulu uzskatīt par vadības plakni. Tur VPC tabula norāda uz vārtējas piesaisti, un asociācija un izplatīšana notiek tranzīta vārtējas maršrutu tabulā. Abu skatījumu sajaukšana rada pārliecinātus secinājumus par nepareizo objektu.
Virziens no AWS uz biroju ir sludinājums
VGW piesaistes gadījumā vārtēja sludina ar savu VPC saistītos CIDR blokus klienta vārtējai ar BGP starpniecību. Atsevišķa apakštīkla maršruta pievienošana vai maršruta novirzīšana uz savienotu VPC vai ierīci nepievieno citu saistītu CIDR un neparādās šajā sludinājumā. Ja birojam trūkst prefiksa, pirms jebkuras maršrutu tabulas rediģēšanas salīdziniet saņemto maršrutu sarakstu ar VPC asociācijām.
Vienkāršajam noteikumam ir izņēmumi, tāpēc turiet to tā tvērumā. VPN CloudHub izkārtojums var atkārtoti sludināt vietnes prefiksus starp klienta vārtējām, un tranzīta vārtēja ievēro savus izplatīšanas noteikumus. Apgalvojums, ka VGW sludina tikai savu VPC, ir noderīga noklusējuma vērtība, nevis likums, kas aptver katru topoloģiju, ar ko saskarsities.
Virziens no biroja uz AWS ir izplatīšana plus atlase
Pretējā virzienā VGW apgūst biroja prefiksu, bet tas vien nepārvieto darba slodzi. Apakštīkla maršrutu tabulā vai nu jābūt iespējotai izplatīšanai piesaistei, vai jābūt statiskam maršrutam uz to pašu galamērķi. Ja vienam prefiksam pastāv abi, uzvar statiskais maršruts, un garākā prefiksa atbilstība tiek izpildīta pirms abiem.
Lasiet izcelsmi, nevis pieņemiet to: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Ieraksts ar izcelsmi EnableVgwRoutePropagation nāca no BGP; ierakstu ar izcelsmi CreateRoute ierakstīja cilvēks, un tas turpinās uzvarēt, līdz kāds to izdzēš.
Runbook, kas tur abus virzienus atsevišķi
Pirms kaut ko mainīt, AWS pusē pierakstiet četrus faktus: piesaistes tipu, saistītos VPC CIDR, attiecīgā prefiksa apakštīkla maršruta izcelsmi, kā arī tuneļa un BGP stāvokli. Tas pats describe izsaukums atgriež VgwTelemetry ar pieņemto maršrutu skaitu katram tunelim, kas parāda, vai AWS vispār pieņēma kādus maršrutus. Pēc tam salīdziniet to ar to, ko klienta ierīce faktiski instalēja. Prefikss, kas ir BGP, bet nav pārsūtīšanas tabulā, ir lokālas importēšanas vai labākā ceļa problēma, nevis AWS maršrutu tabulas problēma.
Ja apakštīkla tabulā prefiksa vispār nav, iespējojiet izplatīšanu vai pievienojiet statisku maršrutu, pēc tam nolasiet to pašu vaicājumu vēlreiz pēc izplatīšanas intervāla, nevis pieņemiet, ka izmaiņas bija tūlītējas. Ja prefikss pastāv un trafiks joprojām neizdodas, atstājiet vadības plakni mierā un pārejiet uz datu ceļu.
Ko nemainīt, kamēr esat tur
Neieslēdziet un neizslēdziet izplatīšanu nesaistītās maršrutu tabulās, lai salabotu vienu trūkstošu prefiksu, un nepievienojiet noklusējuma maršrutu, lai nomaskētu vienu trūkstošu CIDR. Abas izmaiņas paplašina ietekmes apjomu un apgrūtina nākamo diagnostiku. Ierobežojiet rediģēšanu tikai ar to tabulu, kas apkalpo attiecīgo darba slodzes apakštīklu.
Datu ceļš ir atdalīts no visa šī. Drošības grupas ir ar stāvokli, tīkla ACL nav, un resursdatora ugunsmūris vai asimetrisks atgriešanās ceļš var nomest trafiku, ko maršrutēšana piegādāja pareizi. Sludināts apkopojums arī neautorizē katru pakalpojumu tajā, tāpēc ierobežojiet piekļuvi politikas robežā, nevis paļaujieties uz to, vai adrese nejauši parādās BGP sludinājumā.
Saglabājiet katras maršrutu tabulas vaicājuma stāvokli pirms un pēc izmaiņu žurnālā. Ja izmaiņas pasliktina situāciju, atjaunojiet iepriekšējos maršrutus un apstipriniet ar to pašu vaicājumu, jo atritināšana, ko nevarat pārbaudīt, ir tikai minējums.