Zašto se vaša BGP sesija ne pojavljuje u VPC tablici usmjeravanja

Priča koja se ponavlja jest da će routing daemon na EC2 VPN uređaju naučiti VPC njegove udaljene prefikse čim BGP proradi. Pola toga je točno. Sesija proradi i ništa se u VPC tablici usmjeravanja zbog toga ne mijenja, zato je prvi simptom obično podmreža koja tiho baca promet u crnu rupu.

Ovdje se miješaju dvije različite stvari: peering s route serverom i instaliranje ruta u tablicu.

Mit: podignite BGP i VPC će naučiti prefikse

BGP je razgovor između dva sugovornika, a u ovom su dizajnu sugovornici routing daemon na vašem uređaju i endpoint VPC Route Servera koji AWS postavlja u podmrežu koju posjedujete. Taj razgovor nosi prefikse. On ne dira tablicu usmjeravanja vaših radnih podmreža, jer te tablice uče samo kroz propagaciju koja mora biti omogućena na svakoj od njih. Dok se to ne dogodi, VPC tkivo ne zna ništa o tome što uređaj zna.

Koraci postavljanja odvojeni su s razlogom: povežite, stvorite endpoint, uspostavite peering, zatim omogućite propagaciju.

Route Server je kontrolna ravnina, a ne tunel

Route Server ne šifrira, ne prosljeđuje i ne pregledava ni jedan paket. Postoji da razmijeni BGP s uređajem i preda dobivene prefikse tablicama usmjeravanja koje su konfigurirane da ih primaju. Ravnina podataka je nepromijenjena: paketi i dalje izlaze kroz mrežno sučelje uređaja, putuju njegovim VPN-om i vraćaju se istim putem.

To znači da je provjera izvora i odredišta na instanci koja prosljeđuje i dalje bitna, jer instanca sada prosljeđuje promet adresiran na nekog drugog.

Sigurnosne grupe i kontrole podmreže i dalje vrijede za proslijeđeni tok. Route Server neće natjerati uređaj koji odbacuje promet da ga proslijedi, niti će popraviti nedostajuću povratnu rutu na udaljenoj strani.

Propagacija je po tablici usmjeravanja, ne po VPC-u

Povezivanje route servera s VPC-om i omogućavanje propagacije u tablici usmjeravanja dvije su odluke, a samo druga mijenja ono što podmreža radi. VPC sa šest tablica usmjeravanja može primiti propagirani prefiks u jednoj, a ne u ostalih pet, što je točno ispravno za hub podmrežu i točno ono što stvara zbunjujući rezultat «radi napola». Čak i tamo gdje je propagacija uključena, konkurentska ruta može pobijediti, jer VPC odabir ruta preferira najdulji prefiks, a pri istoj duljini preferira statičku rutu nad propagiranom. Ta se preferencija primjenjuje tiho.

Provjerite efektivnu tablicu za konkretnu podmrežu, a ne popis prefiksa koje uređaj objavljuje. API na to pitanje odgovara izravno: aws ec2 associate-route-server i aws ec2 enable-route-server-propagation --route-table-id <id> dva su koraka koja ljudi zaborave, a aws ec2 describe-route-tables --route-table-ids <id> pokazuje je li prefiks uopće stigao kao route server unos.

Uređaj i dalje nosi svaki paket

Objavljivati dostupnost nije isto što i imati je. BGP sesija može ostati uspostavljena dok je VPN uređaja pao, a statička objava koja se nikad ne mijenja stalno vuče promet prema mrtvom putu. Route Server podržava otkrivanje kvarova poput BFD-a, ali to testira živost peera, a ne zdravlje svega iza peera.

Vežite objavu za stvarnu udaljenu rutu: objavite prefiks kada su tunel i udaljena mreža gore, i povucite ga kada nisu.

Povucite prefiks i gledajte što se događa

Testirajte u fazama, i neka zadnja faza bude uklanjanje. Potvrdite da objava stiže, da se prefiks pojavljuje u svakoj predviđenoj tablici, da je uređaj sljedeći hop, da prosljeđivanje prelazi aktivni tunel i da udaljena strana odgovara. Zatim povucite testni prefiks ili zatvorite odobreni tunel i promatrajte pomiče li se promet tamo gdje dizajn kaže da treba. Zabilježite tablice prije i poslije dok je test još otvoren.

Premještanje rute na drugi uređaj ne premješta sesije koje je nosila, jer stanje NAT-a i vatrozida ostaje na prvom uređaju.

Za fiksni skup od desetak prefiksa statičke rute u VPC tablicama ostaju jeftiniji odgovor. Route Server zaslužuje svoje mjesto kada se popis prefiksa doista mijenja i kada politika povlačenja može objasniti osobi koja je na dežurstvu.