Anunțurile BGP ale VGW față de tabela de rute a VPC: ce schimbă ce

Un prefix lipsă într-o tabelă de rute a unei subrețele VPC și un prefix lipsă pe routerul clientului sunt două defecțiuni diferite, iar doar una dintre ele este reparată în interiorul tabelelor de rute AWS. Gateway-ul privat virtual anunță blocurile CIDR asociate VPC-ului său; tabela de rute a subrețelei decide unde trimite o sarcină de lucru răspunsul. A trata al doilea ca pe o cale de a schimba primul este cea mai frecventă greșeală în acest diagnostic. Rulați verificările de mai jos în ordine și țineți cele două direcții separate.

Numiți atașamentul înainte de a citi orice tabelă

Un VPN site-to-site se termină fie pe un gateway privat virtual, fie pe un gateway de tranzit, iar ID-urile resurselor decid ce model de rutare se aplică. Citiți-le mai întâi: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Răspunsul vă spune dacă următoarea tabelă de inspectat este o tabelă de rute VPC sau o tabelă de rute a gateway-ului de tranzit.

Dacă VPN-ul este atașat unui gateway de tranzit, nu mai tratați tabela de rute VPC ca plan de control. Acolo tabela VPC indică atașamentul gateway-ului, iar asocierea și propagarea au loc în tabela de rute a gateway-ului de tranzit. Amestecarea celor două perspective produce concluzii încrezătoare despre obiectul greșit.

Direcția de la AWS spre birou este un anunț

Pentru un atașament VGW, gateway-ul anunță blocurile CIDR asociate VPC-ului său către gateway-ul clientului prin BGP. Adăugarea unei singure rute de subrețea sau direcționarea unei rute către un VPC partener sau către un dispozitiv nu adaugă un alt CIDR asociat și nu apare în acel anunț. Dacă în birou lipsește un prefix, comparați lista de rute primite cu asocierile VPC înainte de a edita orice tabelă de rute.

Regula simplă are excepții, așa că țineți-o în domeniul ei. O configurație VPN CloudHub poate reanunța prefixele siturilor între gateway-urile clienților, iar un gateway de tranzit urmează propriile reguli de propagare. Afirmația că un VGW anunță doar propriul VPC este o valoare implicită utilă, nu o lege care acoperă fiecare topologie pe care o veți întâlni.

Direcția de la birou spre AWS este propagare plus selecție

În direcția inversă, VGW învață prefixul biroului, dar asta singur nu mută o sarcină de lucru. Tabela de rute a subrețelei trebuie fie să aibă propagarea activată pentru atașament, fie să conțină o rută statică către aceeași destinație. Când ambele există pentru un prefix, câștigă ruta statică, iar potrivirea celui mai lung prefix rulează înaintea ambelor.

Citiți originea în loc să o presupuneți: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. O intrare cu originea EnableVgwRoutePropagation a venit din BGP; o intrare cu originea CreateRoute a fost tastată de un om și va continua să câștige până când cineva o șterge.

Un runbook care ține cele două direcții separate

Notați patru fapte pe partea AWS înainte de a schimba ceva: tipul atașamentului, CIDR-urile asociate ale VPC-ului, originea rutei de subrețea pentru prefixul în cauză și starea tunelului și a BGP. Același apel describe returnează VgwTelemetry cu numărul de rute acceptate pe tunel, ceea ce vă spune dacă AWS a acceptat vreo rută. Apoi comparați cu ceea ce a instalat efectiv dispozitivul clientului. Un prefix prezent în BGP, dar absent din tabela de redirecționare, este o problemă de import local sau de cea mai bună cale, nu o problemă a tabelei de rute AWS.

Dacă tabelei subrețelei îi lipsește complet prefixul, activați propagarea sau adăugați o rută statică, apoi recitiți aceeași interogare după intervalul de propagare, în loc să presupuneți că schimbarea a fost imediată. Dacă prefixul există și traficul tot eșuează, lăsați planul de control în pace și treceți la calea de date.

Ce să nu schimbați cât timp sunteți acolo

Nu activați sau dezactivați propagarea pe tabele de rute nelegate pentru a repara un singur prefix lipsă și nu adăugați o rută implicită pentru a acoperi un singur CIDR absent. Ambele schimbări lărgesc aria de impact și fac diagnosticul următor mai dificil. Limitați editarea la tabela care deservește subrețeaua sarcinii de lucru în cauză.

Calea de date este separată de toate acestea. Grupurile de securitate sunt stateful, ACL-urile de rețea nu sunt, iar un firewall de gazdă sau o cale de întoarcere asimetrică pot elimina traficul pe care rutarea l-a livrat corect. Un agregat anunțat nu autorizează nici fiecare serviciu din el, așa că restricționați accesul la limita politicii în loc să vă bazați pe apariția întâmplătoare a unei adrese într-un anunț BGP.

Salvați starea dinainte și de după fiecare interogare a tabelei de rute în registrul de modificări. Dacă modificarea înrăutățește lucrurile, restaurați rutele anterioare și confirmați cu aceeași interogare, deoarece o revenire pe care nu o puteți verifica este doar o presupunere.