Zakaj BGP prek VPN ne nadzoruje poti spodnjega sloja

Dve lokaciji vzpostavita BGP prek tunela IPsec, se naučita predpon druga druge in diagram se preimenuje v nadzor poti. Prav ta oznaka je začetek zmede. Seja res izmenjuje dosegljivost in res uporablja politiko, vendar nima besede pri tem, kateri ponudnik, kabel ali usmerjevalnik prenaša šifrirane pakete. Videl sem ekipo, ki je obnavljala delujoč tunel, ker je pričakovala, da bo sprememba poti BGP premaknila promet na drugo optično pot, na katero seja nikoli ne bi mogla vplivati.

Kaj ljudje mislijo, da seja kupi

Večina pričakovanj izhaja iz tega, kako je videti sprememba poti v laboratoriju. Razglasite predpono prek tunela, oddaljena stran jo namesti in promet se premakne. Isto zaporedje se zgodi na usmerjevalniku, ki ima res vzvode za inženiring prometa, zato se oboje zameša. V laboratoriju si obe lokaciji običajno delita eno dostopovno povezavo, in prav zato se razlika tam nikoli ne pokaže.

BGP je protokol dosegljivosti. Pove partnerju, da lahko dostavite pakete za predpono, in vsaki strani omogoči, da razvrsti prejete ponudbe. Prek tunela je to res koristno: predpone se pojavljajo in izginjajo, ko lokacije prihajajo in odhajajo, in obseg lahko zavrnete, ne da bi na vsaki robni napravi zapisali statično pot. Česar pa ne stori, je to, da bi usmerjevalnike ponudnika spravil pod vaš nadzor.

Spodnji sloj nosi zunanjo glavo. Vaša končna točka tunela pošilja šifrirane pakete na naslov partnerja, omrežje med tema dvema naslovoma pa jih posreduje po poteh, ki so jih namestili njegovi operaterji. Nič v seji BGP te odločitve ne spremeni, razen če isti ponudnik ponuja podprto storitev, ki to počne.

Kaj seja v resnici nosi

Govornik BGP odpre povezavo TCP na vrata 179 svojega partnerja z uporabo oblik sporočil in atributov poti, opredeljenih v RFC 4271. Ko naslov partnerja leži znotraj tunela, mora biti tunel dvignjen in naslov dosegljiv, preden se seja sploh začne. Zaključena izmenjava IKE ni sosed BGP. Izvedbe IPsec, ki temeljijo na poteh, spustijo promet skozi šele, ko obstaja ustrezna pot tunela, tista, ki temelji na politiki, pa potrebuje naslov partnerja znotraj zaščitenega izbirnika. Obrat tega ustvari klasično stanje, ko je tunel zelen, seja pa sedi brez dela.

Ko je seja dvignjena, politika odloči, kaj jo prečka. Seznami predpon, filtri AS-path, zgornja meja največjega števila predpon in izrecna odločitev o privzetih poteh so minimum in veljajo v obeh smereh. Partner, ki sprejme vse, kar prejme, vam lahko da privzeto pot, ki tiho nadomesti lokalni dostop do interneta. Obe smeri potrebujeta ločena seznama, ker sta to, kar sprejmete od partnerja, in to, kar mu razglasite, dve različni odločitvi.

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

Nato ugrizne MTU. Zapiranje zmanjša uporabno koristno obremenitev, zato lahko velika posodobitev ustavi sejo, ki je videti popolnoma vzpostavljena: partner ostane dvignjen, predpone nikoli ne prispejo in nič očitnega ne pade v dnevnik. Omejite TCP MSS na vmesniku tunela ali nastavite MTU tunela s prostorom za dodatne stroške, preden obtožite filtre.

Kam zunanji paketi še vedno gredo

Šifrirani paketi z ene lokacije na drugo gredo ven skozi tisto, kar lokalni usmerjevalnik izbere za javni naslov partnerja. Če obe lokaciji kupujeta tranzit pri istem ponudniku, prečkata isto metropolitansko zgradbo ali ena stran sedi za NAT na ravni operaterja, tunel preživi izpad ponudnika le po naključju. Štetje ikon tunelov v nadzornem orodju vam o tem ne pove ničesar.

Izbira poti in namestitev posredovanja sta tudi ločena dogodka. Predpona lahko sedi v tabeli BGP kot najboljša in vseeno manjka v tabeli posredovanja, ker naslednji skok ni rešljiv ali zmaga bolj specifična pot. Ko nekdo poroča, da se je BGP predpone naučil, a promet ne teče, je koristno vprašanje, ali je nameščena in na kateri naslednji skok kaže.

Iskren odgovor za pregled zasnove je seznam deljenih odvisnosti: dostopovno vezje, nadrejeni ponudnik, zgradba in katera koli naprava s stanjem na povratni poti. Seja prek tunela ne more odstraniti odvisnosti, nad katero ne sedi.

Tri odločitve, ki jih je vredno ločiti

Ko zasnova te stvari meša, gre vsak pogovor o izpadu v krogu. Najprej jih ločite na papirju, nato vsako povežite z napravo, ki jo res uveljavlja.

Vsaka vrstica ima drugega lastnika. Prva so pogajanja, druga je konfiguracija na vaših napravah, tretja je večinoma omrežje nekoga drugega. Zahteva za spremembo, ki poimenuje vrstico, ki se je dotika, je veliko lažje odobriti kot tista, ki pravi težava BGP.

Načini odpovedi, za katere se je vredno pripraviti

Sprejetje povzetne poti partnerja je najpogostejša samozadana rana. Nekdo razglasi kratek agregat, da bi poenostavil izmenjavo, oddaljena stran ga sprejme in promet za obsege, ki niso za tunelom, sledi tunelu in umre. Filtrirajte po natančno pričakovanih predponah ali uporabite seznam predpon s pravilnimi mejami in nikoli ne sprejmite golega agregata, ker naredi sejo urejeno na videz.

Čas umika je drugi. Zaznavanje je odvisno od časovnikov zadržanja, od BFD, če ste ga omogočili, od zaznavanja mrtvega partnerja tunela in od tega, kako hitro oddaljena stran preneha razglašati. Obstoječe seje so ločen problem: nova pot lahko obnovi nove povezave, medtem ko vzpostavljene seje TCP še naprej uporabljajo zastarele naslove, požarni zidovi s stanjem ali NAT na poti pa lahko hranijo vnose, ki se ne ujemajo več. Vključite obnovitev aplikacije v merila sprejemljivosti, namesto da predpostavljate, da sprememba poti reši vse.

Tretja je asimetrija povratne poti. Promet lahko prispe po tunelu in se vrne po povezavi ponudnika, ki ni bila nikoli mišljena, da bi ga prenašala, kar se pokaže kot enosmerni zvok, neuspeli rokovanji ali požarni zid, ki odmetava odgovore. Preverite obe smeri ločeno.

Kaj zapisati v pogodbo in kako to preveriti

Zahtevajte dovoljene predpone pisno: kdo je pooblaščen za ustvarjanje vsakega obsega, ali je privzeta pot dovoljena in katere družine naslovov podpira storitev tunela. RFC 8212 je naredil izrecno politiko uvoza in izvoza pričakovanje za eBGP v izvedbah, ki ji sledijo, zato si partner, ki se še vedno zanaša na implicitno sprejemanje vsega, zasluži vprašanje.

Nato preverjajte z naprave in ne iz diagrama. Uporabni ukazi na usmerjevalnikih v slogu FRR:

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 dve opažanji, ki vam jih tabela poti ne more dati. Zajemite na zunanjem vmesniku, da potrdite, na kateri naslov zaprti paketi res ciljajo, na primer tcpdump -ni eth0 udp port 51820 za tunel WireGuard ali filter ESP za IPsec. Nato sledite proti javnemu naslovu partnerja in primerjajte skoke s sledjo znotraj tunela; če oba sledita isti verigi ponudnika, vaša redundanca živi v politiki poti in ne v omrežju.

Na koncu namerno preizkusite umik. Spustite tunel v servisnem oknu, zabeležite, kako dolgo predpona ostane nameščena, kaj se zgodi z obstoječimi sejami in ali se oddaljena stran vrne na pot, ki bi jo res sprejeli. Ta vaja pove o zasnovi več kot kateri koli diagram.

Pot ni dovoljenje. Predpone, o katerih se dogovorite za izmenjavo, ne povedo ničesar o tem, kateri uporabniki lahko dosežejo katero storitev za tunelom, zato pustite preverjanje pristnosti, dovoljene storitve in požarne zidove gostiteljev točno tam, kjer so bili. Dosegljiv partner tudi ni dovoljenje za neomejen tranzit ali za ustvarjanje poljubnih naslovov, in tovrstna pristojnost sodi v pogodbo kot poslovno vprašanje, ne v vrstico politike BGP.

• Poimenujte predpone, ki jih lahko ustvari vsaka stran, in tiste, ki jih nikoli ne sme sprejeti.
• Omejite MSS na tunelu in potrdite, da velike posodobitve res prispejo.
• Naštejte deljene odvisnosti spodnjega sloja, ne števila tunelov.
• Izmerite resničen umik in zabeležite, kaj počne aplikacija.