Miért nem irányítja a BGP a VPN felett a ti alaphálózati útvonalatokat

Két telephely BGP-t peerel egy IPsec-alagúton keresztül, megtanulják egymás prefixeit, és a diagram címkéje útvonal-vezérlésre változik. Ez a címke a zűrzavar kezdete. A munkamenet valóban cserél elérhetőséget és valóban alkalmaz politikát, de nincs beleszólása abba, melyik szolgáltató, kábel vagy router viszi a titkosított csomagokat. Láttam csapatot újraépíteni egy működő alagutat, mert azt várták, hogy egy BGP-útvonalváltozás másik száloptikai útvonalra viszi a forgalmat, amelyre a munkamenet soha nem hathatott.

Mit gondolnak az emberek, mit vásárol egy munkamenet

A várakozás nagy része abból jön, hogyan néz ki egy útvonalváltozás laboratóriumban. Meghirdetnek egy prefixet az alagúton, a távoli oldal telepíti, és a forgalom elindul. Ugyanez a sorrend játszódik le egy olyan routeren, amelynek valóban vannak forgalommérnöki fogantyúi, ezért a kettő összekeveredik. A laboratóriumban a két telephely általában egyetlen hozzáférési linket oszt meg, és éppen ezért nem mutatkozik meg ott soha a különbség.

A BGP elérhetőségi protokoll. Azt mondja egy peernek, hogy képes vagy prefixhez csomagokat kézbesíteni, és hagyja, hogy mindkét fél rangsorolja a kapott ajánlatokat. Ez alagúton át valóban hasznos: a prefixek megjelennek és eltűnnek, ahogy a telephelyek jönnek és mennek, és elutasíthatsz egy tartományt anélkül, hogy statikus útvonalat írnál minden peremeszközre. Amit nem tesz meg, az az, hogy egy szolgáltató routereit az irányításod alá helyezze.

Az alaphálózat viszi a külső fejlécet. Az alagút végpontja titkosított csomagokat küld egy peer-címre, és a két cím közötti hálózat azokkal az útvonalakkal továbbítja őket, amelyeket az üzemeltetői telepítettek. Semmi a BGP-munkamenetben nem változtat ezen a döntésen, hacsak ugyanaz a szolgáltató nem kínál olyan támogatott szolgáltatást, amely igen.

Mit visz valójában a munkamenet

A BGP-beszélő TCP-kapcsolatot nyit a peerje 179-es portjára, az RFC 4271-ben meghatározott üzenetformátumokkal és útvonal-attribútumokkal. Amikor a peer-cím az alagúton belül van, az alagútnak fel kell állnia, és a címnek elérhetőnek kell lennie, mielőtt a munkamenet egyáltalán elindulhat. Egy befejezett IKE-csere nem BGP-szomszéd. Az útvonal-alapú IPsec-implementációk csak akkor engedik át a forgalmat, ha létezik megfelelő alagútútvonal, a házirend-alapúnak pedig a védett szelektoron belül kell lennie a peer-címnek. Ennek megfordítása hozza létre a klasszikus állapotot, amelyben az alagút zöld, a munkamenet pedig tétlenül áll.

Amint a munkamenet feláll, a politika dönti el, mi halad át rajta. A prefixlisták, az AS-path szűrők, a maximális prefixek felső korlátja és az alapértelmezett útvonalakról szóló kifejezett döntés a minimum, és mindkét irányban érvényesek. Egy peer, amely mindent elfogad, amit kap, adhat olyan alapértelmezett útvonalat, amely csendben lecseréli a helyi internethozzáférést. A két iránynak külön listákra van szüksége, mert amit egy peertől elfogadsz, és amit felé hirdetsz, két különböző döntés.

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

Aztán harap az MTU. A beágyazás csökkenti a hasznos terhet, ezért egy nagy frissítés megakaszthat egy tökéletesen felálltnak látszó munkamenetet: a peer fent marad, a prefixek soha nem érkeznek meg, és semmi nyilvánvaló nem kerül a naplóba. Korlátozd a TCP MSS-t az alagút interfészén, vagy állíts be az overhead számára helyet hagyó alagút-MTU-t, mielőtt a szűrőket hibáztatnád.

Hová mennek mégis a külső csomagok

Az egyik telephelyről a másikra menő titkosított csomagok azon keresztül lépnek ki, amit a helyi router a peer nyilvános címéhez választ. Ha mindkét telephely ugyanattól a szolgáltatótól vásárol tranzitet, ugyanazon a metrólétesítményen halad át, vagy az egyik oldal carrier-grade NAT mögött van, az alagút csak véletlenül éli túl a szolgáltató kiesését. Az alagútikonok számlálása egy megfigyelő eszközben semmit sem mond erről.

Az útvonalválasztás és a továbbítás telepítése szintén külön események. Egy prefix ülhet a BGP-táblában legjobbként, és mégis hiányozhat a továbbítási táblából, mert a következő ugrás nem oldható fel, vagy egy konkrétabb útvonal nyer. Amikor valaki jelenti, hogy a BGP megtanulta a prefixet, de a forgalom nem folyik, a hasznos kérdés az, hogy telepítve van-e, és melyik következő ugrásra mutat.

A tervezési átvizsgálás őszinte válasza a megosztott függőségek listája: hozzáférési vonal, felső szolgáltató, létesítmény és minden állapottartó eszköz a visszaúton. Az alagúton átmenő munkamenet nem távolíthat el olyan függőséget, amely felett nem ül.

Három döntés, amelyet érdemes szétválasztani

Amikor egy tervezés ezeket összekeveri, minden kiesési beszélgetés körben forog. Először papíron válaszd szét őket, majd rendeld mindegyiket ahhoz az eszközhöz, amely valóban kikényszeríti.

Minden sor más tulajdonoshoz tartozik. Az első tárgyalás, a második a saját eszközeid konfigurációja, a harmadik többnyire valaki más hálózata. Egy változásigény, amely megnevezi az érintett sort, sokkal könnyebben jóváhagyható, mint az, amely azt mondja: BGP-probléma.

Meghibásodási módok, amelyekre érdemes tervezni

Egy peer összefoglaló útvonalának elfogadása a leggyakoribb ön okozta seb. Valaki egy rövid aggregátumot hirdet a csere egyszerűsítésére, a távoli oldal elfogadja, és az alagút mögött nem lévő tartományok forgalma követi az alagutat és meghal. A pontosan várt prefixekre szűrj, vagy használj megfelelő határokkal rendelkező prefixlistát, és soha ne fogadj el csupasz aggregátumot, mert rendben lévőnek mutatja a munkamenetet.

A visszavonás időzítése a második. Az észlelés a tartási időzítőktől, a BFD-től, ha engedélyezted, az alagút halott-peer észlelésétől és attól függ, milyen gyorsan hagyja abba a hirdetést a távoli oldal. A meglévő munkamenetek külön probléma: egy új útvonal helyreállíthat új kapcsolatokat, miközben a felállt TCP-munkamenetek továbbra is elavult címeket használnak, és az útvonalon lévő állapottartó tűzfalak vagy NAT olyan bejegyzéseket tarthatnak, amelyek már nem illeszkednek. Tedd az alkalmazás helyreállítását az elfogadási kritériumokba ahelyett, hogy feltételeznéd, egy útvonalváltozás mindent elrendez.

A harmadik a visszaúti aszimmetria. A forgalom érkezhet az alagúton át, és visszatérhet egy olyan szolgáltatói linken, amelyet soha nem arra szántak, hogy vigye, ami egyirányú hangként, sikertelen kézfogásként vagy a válaszokat eldobó tűzfalként jelenik meg. Ellenőrizd külön mindkét irányt.

Mit írjunk a szerződésbe, és hogyan ellenőrizzük

Kérd írásban az engedélyezett prefixeket: ki jogosult az egyes tartományok eredetére, engedélyezett-e az alapértelmezett útvonal, és mely címcsaládokat támogatja az alagútszolgáltatás. Az RFC 8212 tette a kifejezett import- és exportpolitikát az eBGP elvárásává azokban az implementációkban, amelyek követik, ezért egy peer, amely még mindig hallgatólagos mindent-elfogad viselkedésre támaszkodik, megkérdőjelezhető.

Aztán az eszközből ellenőrizd, ne a diagramból. Hasznos parancsok FRR-stílusú routereken:

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

Adj hozzá két megfigyelést, amelyet az útvonaltábla nem tud megadni. Rögzíts a külső interfészen, hogy megerősítsd, melyik címre céloznak valójában a beágyazott csomagok, például tcpdump -ni eth0 udp port 51820 egy WireGuard-alagút esetén, vagy ESP-szűrőt az IPsec-hez. Aztán kövesd a nyomvonalat a peer nyilvános címe felé, és hasonlítsd össze az ugrásokat az alagúton belüli nyomvonallal; ha mindkettő ugyanazt a szolgáltatói láncot követi, a redundanciád az útvonalpolitikában él, nem a hálózatban.

Végül tesztelj szándékosan egy visszavonást. Vedd le az alagutat egy karbantartási ablakban, jegyezd fel, meddig marad telepítve a prefix, mi történik a meglévő munkamenetekkel, és visszaesik-e a távoli oldal egy olyan útvonalra, amelyet valóban elfogadnál. Ez a gyakorlat többet mond a tervezésről, mint bármely diagram.

Az útvonal nem felhatalmazás. A kicserélni megállapodott prefixek semmit sem mondanak arról, mely felhasználók érhetik el az alagút mögötti melyik szolgáltatást, ezért tartsd a hitelesítést, az engedélyezett szolgáltatásokat és a gazdagépek tűzfalait pontosan ott, ahol voltak. Egy elérhető peer szintén nem engedély korlátlan tranzitre vagy tetszőleges címek eredetére, és az ilyen típusú felhatalmazás a szerződésbe tartozik kereskedelmi kérdésként, nem egy BGP-politikai sorba.

• Nevezd meg a prefixeket, amelyeket mindkét fél eredethet, és azokat, amelyeket soha nem fogadhat el.
• Korlátozd az MSS-t az alagúton, és erősítsd meg, hogy a nagy frissítések valóban megérkeznek.
• Sorold fel a megosztott alaphálózati függőségeket, ne az alagutak számát.
• Időzíts egy valódi visszavonást, és jegyezd fel, mit tesz az alkalmazás.