Zašto BGP preko VPN-a ne kontroliše vašu putanju donjeg sloja

Dvije lokacije uspostavljaju BGP preko IPsec tunela, uče prefikse jedna druge, i dijagram se preimenuje u kontrolu putanje. Upravo taj naziv je početak zabune. Sesija zaista razmjenjuje dostupnost i primjenjuje politiku, ali nema riječi o tome koji provajder, kabl ili ruter nosi šifrovane pakete. Vidio sam tim koji obnavlja ispravan tunel jer je očekivao da će promjena BGP rute premjestiti saobraćaj na drugu fiber putanju na koju sesija nikada nije mogla uticati.

Šta ljudi pretpostavljaju da sesija kupuje

Većina očekivanja dolazi iz toga kako promjena rute izgleda u laboratoriji. Oglašavate prefiks preko tunela, suprotna strana ga instalira i saobraćaj se kreće. Isti slijed se dešava na ruteru koji zaista ima poluge za inženjering saobraćaja, pa se to dvoje brka. U laboratoriji obje lokacije obično dijele jednu pristupnu vezu, i upravo zato se razlika tamo nikada ne pokaže.

BGP je protokol dostupnosti. Govori peeru da možete dostaviti pakete za prefiks i dopušta svakoj strani da rangira ponude koje prima. To je istinski korisno preko tunela: prefiksi se pojavljuju i nestaju kako lokacije dolaze i odlaze, i možete odbiti raspon bez pisanja statičke rute na svakom rubnom uređaju. Ono što ne radi jeste da stavi provajderove rutere pod vašu kontrolu.

Donji sloj nosi vanjsko zaglavlje. Vaš tunelski endpoint šalje šifrovane pakete na adresu peera, a mreža između tih dviju adresa ih prosljeđuje koristeći rute koje su njeni operateri instalirali. Ništa u BGP sesiji ne mijenja tu odluku, osim ako isti provajder ne nudi podržanu uslugu koja to čini.

Šta sesija zaista nosi

BGP speaker otvara TCP vezu prema portu 179 na svom peeru, koristeći formate poruka i atribute putanje definisane u RFC 4271. Kada adresa peera živi unutar tunela, tunel mora biti podignut i ta adresa mora biti dostupna prije nego što sesija uopće može početi. Završena IKE razmjena nije BGP susjed. IPsec implementacije zasnovane na rutama propuštaju saobraćaj tek kada postoji odgovarajuća tunelska ruta, a ona zasnovana na politici treba adresu peera unutar zaštićenog selektora. Obrnuti redoslijed daje klasično stanje u kojem je tunel zelen, a sesija besposleno stoji.

Kada je sesija podignuta, politika odlučuje šta je prelazi. Liste prefiksa, AS-path filteri, gornja granica maksimalnog broja prefiksa i izričita odluka o default rutama su minimum i primjenjuju se u oba smjera. Peer koji prihvati sve što primi može vam dati default rutu koja tiho zamjenjuje lokalni pristup internetu. Dva smjera trebaju odvojene liste, jer ono što primate od peera i ono što mu oglašavate dvije su različite odluke.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

Zatim grize MTU. Enkapsulacija smanjuje korisni teret, pa veliko ažuriranje može zaglaviti sesiju koja izgleda savršeno uspostavljena: peer ostaje gore, prefiksi nikada ne stižu, a ništa očigledno ne pada u log. Ograničite TCP MSS na tunelskom interfejsu ili postavite tunelski MTU s prostorom za overhead, prije nego okrivite filtere.

Kuda vanjski paketi i dalje idu

Šifrovani paketi s jedne lokacije na drugu izlaze kroz ono što lokalni ruter odabere za javnu adresu peera. Ako obje lokacije kupuju tranzit od istog provajdera, prolaze kroz isti metro objekat ili jedna strana sjedi iza carrier-grade NAT-a, tunel preživljava ispad provajdera samo slučajno. Brojanje ikona tunela u alatu za nadzor ne govori vam ništa o tome.

Odabir rute i instalacija prosljeđivanja takođe su odvojeni događaji. Prefiks može stajati u BGP tabeli kao najbolji i ipak nedostajati u tabeli prosljeđivanja, jer je sljedeći hop nerješiv ili pobjeđuje specifičnija ruta. Kada neko prijavi da je BGP naučio prefiks ali saobraćaj ne teče, korisno pitanje je da li je instaliran i na koji sljedeći hop pokazuje.

Iskren odgovor za pregled dizajna je lista zajedničkih zavisnosti: pristupni krug, upstream provajder, objekat i svaki uređaj sa stanjem na povratnoj putanji. Sesija preko tunela ne može ukloniti zavisnost nad kojom ne stoji.

Tri odluke koje vrijedi razdvojiti

Kada dizajn to pomiješa, svaki razgovor o ispadu ide u krug. Prvo ih razdvojite na papiru, zatim svaku povežite s uređajem koji je zaista provodi.

Svaki red ima drugog vlasnika. Prvi je pregovor, drugi je konfiguracija na vašim uređajima, treći je uglavnom tuđa mreža. Zahtjev za promjenu koji imenuje red koji dodiruje mnogo je lakše odobriti od onog koji kaže BGP problem.

Načini otkaza za koje vrijedi planirati

Prihvatanje peerove sumarne rute najčešća je samo-nanesena rana. Neko oglasi kratki agregat da pojednostavi razmjenu, suprotna strana ga prihvati, a saobraćaj za raspone koji nisu iza tunela slijedi tunel i umire. Filtrirajte na tačno očekivane prefikse ili koristite listu prefiksa s ispravnim granicama i nikada ne prihvatajte goli agregat jer čini da sesija izgleda uredno.

Vrijeme povlačenja je drugo. Detekcija zavisi od hold timera, BFD-a ako ste ga uključili, detekcije mrtvog peera tunela i od toga kako brzo suprotna strana prestaje oglašavati. Postojeće sesije su odvojen problem: nova ruta može obnoviti nove veze dok uspostavljene TCP sesije nastavljaju koristiti zastarjele adrese, a stateful firewall ili NAT na putanji mogu držati unose koji više ne odgovaraju. Stavite oporavak aplikacije u kriterije prihvatanja umjesto da pretpostavljate da promjena rute rješava sve.

Treći je asimetrija povratne putanje. Saobraćaj može stizati preko tunela i vraćati se provajderskom vezom koja nikada nije bila namijenjena da ga nosi, što se očituje kao jednosmjerni zvuk, neuspjela rukovanja ili firewall koji odbacuje odgovore. Provjerite oba smjera odvojeno.

Šta upisati u ugovor i kako to provjeriti

Zatražite dozvoljene prefikse pismeno: ko je ovlašten da originira svaki raspon, da li je default ruta dopuštena i koje porodice adresa tunelska usluga podržava. RFC 8212 učinio je izričitu politiku importa i exporta očekivanjem za eBGP u implementacijama koje ga slijede, pa peer koji se još oslanja na implicitno prihvati-sve ponašanje vrijedi dovesti u pitanje.

Zatim provjerite s uređaja, a ne s dijagrama. Korisne komande na ruterima nalik FRR-u:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Dodajte dva zapažanja koja vam tabela rutiranja ne može dati. Snimite na vanjskom interfejsu da potvrdite koju adresu enkapsulirani paketi zaista gađaju, na primjer tcpdump -ni eth0 udp port 51820 za WireGuard tunel, ili ESP filter za IPsec. Zatim trasirajte prema javnoj adresi peera i uporedite hopove s trasom unutar tunela; ako oba slijede isti provajderski lanac, vaša redundansa živi u politici rutiranja, a ne u mreži.

Na kraju, namjerno testirajte povlačenje. Spustite tunel tokom servisnog prozora, zabilježite koliko dugo prefiks ostaje instaliran, šta se dešava s postojećim sesijama i da li suprotna strana pada na rutu koju biste zaista prihvatili. Ta vježba govori više o dizajnu od bilo kojeg dijagrama.

Ruta nije ovlaštenje. Prefiksi oko kojih se dogovorite da ih razmjenjujete ne govore ništa o tome koji korisnici smiju dosegnuti koju uslugu iza tunela, zato zadržite autentikaciju, dozvoljene usluge i firewallove hosta tačno tamo gdje su bili. Dostupan peer također nije dopuštenje za neograničen tranzit ni za originiranje proizvoljnih adresa, a takva vrsta ovlaštenja pripada ugovoru kao komercijalno pitanje, a ne liniji BGP politike.

• Imenujte prefikse koje svaka strana smije originirati i one koje nikada ne smije prihvatiti.
• Ograničite MSS na tunelu i potvrdite da velika ažuriranja zaista stižu.
• Navedite zajedničke zavisnosti donjeg sloja, ne broj tunela.
• Izmjerite stvarno povlačenje i zabilježite šta aplikacija radi.