BGP-ruteannonceringer fra VGW versus VPC-rutetabellen: hvad ændrer hvad

Et manglende præfiks i en VPC-undernets-rutetabel og et manglende præfiks på kundens router er to forskellige fejl, og kun én af dem repareres inde i AWS' rutetabeller. Den virtuelle private gateway annoncerer de CIDR-blokke, der er knyttet til dens VPC; undernettets rutetabel afgør, hvor en arbejdsbelastning sender et svar. At behandle det andet som en måde at ændre det første er den mest almindelige forkerte drejning i denne diagnosticering. Kør kontrollerne nedenfor i rækkefølge, og hold de to retninger adskilt.

Navngiv vedhæftningen, før du læser nogen tabel

En Site-to-Site VPN afsluttes enten på en virtuel privat gateway eller på en transit-gateway, og ressource-ID'erne afgør, hvilken rutningsmodel der gælder. Læs dem først: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Svaret fortæller dig, om den næste tabel, der skal undersøges, er en VPC-rutetabel eller en transit-gateway-rutetabel.

Hvis VPN'et er knyttet til en transit-gateway, så stop med at behandle VPC-rutetabellen som kontrolplanet. Der peger VPC-tabellen på gatewayvedhæftningen, og association og propagering sker i transit-gateway-rutetabellen. Blandes de to syn, får man selvsikre konklusioner om det forkerte objekt.

Retningen fra AWS til kontoret er en annoncering

For en VGW-vedhæftning annoncerer gatewayen de CIDR-blokke, der er knyttet til dens VPC, til kundegatewayen over BGP. At tilføje en enkelt undernetsrute eller pege en rute mod en peer-VPC eller en appliance tilføjer ikke endnu et tilknyttet CIDR og vises ikke i den annoncering. Hvis kontoret mangler et præfiks, så sammenlign listen over modtagne ruter med VPC-tilknytningerne, før du redigerer nogen rutetabel.

Den enkle regel har undtagelser, så hold den inden for rammerne. En VPN CloudHub-opsætning kan genannoncere stedpræfikser mellem kundegatewayer, og en transit-gateway følger sine egne propageringsregler. Udsagnet om, at en VGW kun annoncerer sin egen VPC, er en nyttig standard, ikke en lov der dækker enhver topologi, du møder.

Retningen fra kontoret til AWS er propagering plus udvælgelse

I den modsatte retning lærer VGW'en kontorets præfiks, men det alene flytter ikke en arbejdsbelastning. Undernettets rutetabel skal enten have propagering aktiveret for vedhæftningen eller indeholde en statisk rute til samme destination. Når begge findes for ét præfiks, vinder den statiske rute, og det længste præfiksmatch kører før nogen af dem.

Læs oprindelsen i stedet for at antage den: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. En post med oprindelsen EnableVgwRoutePropagation kom fra BGP; en post med oprindelsen CreateRoute blev skrevet af et menneske og vil blive ved med at vinde, indtil nogen sletter den.

En runbook, der holder de to retninger adskilt

Notér fire fakta på AWS-siden, før du ændrer noget: vedhæftningstypen, de tilknyttede VPC-CIDR'er, undernetsrutens oprindelse for det pågældende præfiks samt tunnel- og BGP-tilstanden. Det samme describe-kald returnerer VgwTelemetry med et antal accepterede ruter pr. tunnel, hvilket fortæller dig, om AWS overhovedet accepterede nogen ruter. Sammenlign derefter med det, kundeenheden faktisk installerede. Et præfiks, der findes i BGP men mangler i videresendelsestabellen, er et lokalt import- eller bedste-vej-problem, ikke et AWS-rutetabelproblem.

Hvis undernetstabellen helt mangler præfikset, så aktivér propagering eller tilføj en statisk rute, og læs derefter den samme forespørgsel igen efter propageringens interval i stedet for at antage, at ændringen var øjeblikkelig. Hvis præfikset findes, og trafikken stadig fejler, så lad kontrolplanet være og gå videre til datastien.

Hvad du ikke skal ændre, mens du er der

Slå ikke propagering til eller fra på urelaterede rutetabeller for at rette ét manglende præfiks, og tilføj ikke en standardrute for at dække over et enkelt manglende CIDR. Begge ændringer øger påvirkningens omfang og gør den næste diagnosticering sværere. Hold redigeringen begrænset til den tabel, der betjener det pågældende arbejdsbelastnings-undernet.

Datastien er adskilt fra alt dette. Sikkerhedsgrupper er stateful, netværks-ACL'er er det ikke, og en host-firewall eller en asymmetrisk returvej kan droppe trafik, som rutningen leverede korrekt. En annonceret aggregering autoriserer heller ikke enhver tjeneste indeni, så begræns adgangen ved politikgrænsen i stedet for at stole på, om en adresse tilfældigvis optræder i en BGP-annoncering.

Gem før og efter af hver rutetabel-forespørgsel i ændringsregistret. Hvis ændringen gør tingene værre, gendan de tidligere ruter og bekræft med den samme forespørgsel, fordi en tilbagerulning, du ikke kan verificere, kun er et gæt.