A felhő VPN-nek BGP kell: miért vallanak kudarcot a többi útválasztási protokoll

Az IPsec biztonsági társulás él, az alagút számlálói mozognak, és a felhő prefixéhez irányuló forgalom eltűnik. Az üzemeltető ekkor megpróbálja engedélyezni az OSPF-et az ügyfél routerén, arra számítva, hogy létrejön a szomszéd, és semmi sem történik. Az alagút soha nem a hiányzó darab volt: egy felügyelt felhő VPN meghatározott útválasztási szerződést tesz elérhetővé, és a nagy platformokon ez a szerződés a BGP. Amíg nem létezik munkamenet, és nem fogadnak el egy prefixet, az alagút csak egy titkosított útvonal mögötte célpontok nélkül.

Az alagút él, és hiányzik az útvonal

Az 1. fázis és a 2. fázis befejezése azt bizonyítja, hogy a felek egyetértenek a védelemben, nem azt, hogy bármelyik fél tudja, hová küldje a forgalmat. Ezek különálló állapotgépek különálló hibaüzemmódokkal.

Tegyen fel három kérdést sorrendben: hirdették-e a prefixet, elfogadta-e a szomszéd, és telepítették-e továbbításra? A hirdetett, majd szűrt prefix házirend-probléma. A soha nem hirdetett prefix munkamenet- vagy konfigurációs probléma. Az elfogadott, de nem telepített prefix útvonalválasztási probléma, és minden válasz a konfiguráció más részére mutat.

Mit ad valójában a szolgáltató

A felügyelt VPN átjáró nem korlátlan router. A szolgáltató olyan átjárót ad, amely támogatott szomszédcímekkel, autonóm rendszer beállítással, prefixkorlátokkal és meghatározott hibaviselkedéssel rendelkezik. Ez a felület a termék.

A Google Cloud dokumentálja a dinamikus BGP-útválasztást a HA VPN-hez, ahol a Cloud Router megtanulja a szomszédok útvonalait, és jogosult egyéni dinamikus útvonalakat szolgáltat a VPC-nek. Az AWS Site-to-Site VPN dokumentálja a statikus és dinamikus útválasztás közötti választást, és a BGP életképességi ellenőrzéseket hasznosnak írja le az alagút átvételéhez, miközben a BGP nélküli eszközök állapotellenőrzését is támogatja. Egyik platform viselkedését sem szabad a másik terméknevéből levezetni.

A gyakorlati következmény az, hogy először a felügyelt módot választja, majd elolvassa a támogatott paramétereket. Az a terv, amely olyan szomszédságtípust feltételez, amelyet a szolgáltatás nem kínál, nem konfigurációs probléma, amelyet az ügyfél routerén kell megoldani.

Az alagút védelme és az elérhetőség külön feladat

Az IPsec az alagúthoz kiválasztott forgalmat védi. A BGP szolgáltatja azt az elérhetőségi információt, amely alkalmassá tesz egy prefixet. Egy működő alagút nem bizonyítja, hogy a várt prefixet hirdették, elfogadták vagy telepítették.

Képzeljen el egy fióktelepet, amely 10.42.0.0/16-ot hirdet két alkalmas alagútútvonalon. Távolítson el egy használható útvonalat, és az útvonalválasztás megváltozhat anélkül, hogy bárki szerkesztené az egyes munkaterhelések útvonalát. Az észlelés, az útvonalválasztás és az alkalmazás helyreállítása nem azonnali, és nem azonos a különböző telepítések között, ezért az átvételi tesztnek a teljes sorrendet kell megfigyelnie, nem az első átjutó csomagot.

Ha egy felhő prefixe elérhetetlen, ellenőrizze a munkamenet állapotát és a megtanult útvonalakat, mielőtt a titkosításhoz nyúl. Egy élő SA mögötte útvonal nélkül a tünet leggyakoribb formája.

Ahol az OSPF-feltevések megbuknak

Az OSPF, az IS-IS vagy más protokoll egy IPsec-alagúton belül teljesen lehetséges egy saját felügyeletű készüléken, ahol mindkét vég és a továbbítási terv az Öné. Ez a tény semmit sem mond arról a felügyelt szolgáltatásról, amely dinamikus útválasztási módként csak BGP-t kínál.

Ha egy javasolt terv olyan szomszédságot igényel, amelyet a szolgáltatás nem támogat, szándékosan változtassa meg az architektúrát. A lehetőségek közé tartozik egy saját felügyeletű készülék a VPC-ben, a statikus útválasztás ott, ahol a szolgáltatás támogatja, vagy egy másik kapcsolati termék. A protokoll csak az ügyfél routerén való konfigurálása nem tud hozzáadni egy nem létező felhőoldali szomszédot, és nem fogja megjeleníteni a prefixet.

Ne vigye át az egyik szállító válaszát egy másik szállító átjárójára. Ugyanazok a szavak, például a dinamikus útválasztás vagy az alagút átvétele, különböző mechanizmusokat és különböző korlátokat írhatnak le.

Olvassa el a szolgáltatás követelményét, aztán tervezzen

Az első konfigurációs sor előtt írja le a szomszédcímeket, az autonóm rendszerek számait, a hirdetni és elfogadni kívánt prefixeket, az útvonalkorlátokat és a várt viselkedést, amikor egy alagút meghibásodik. Ez az öt elem a szerződés, amelyre tervez.

Ezután ugyanabban a sorrendben ellenőrizze: munkamenet létrejött, prefix megérkezett, útvonal jelen van a VPC útvonaltáblázatában, és valódi adatfolyam egy szolgáltatáscím felé. Ismételje meg kényszerített átvétel után, mert egy újra létrejövő munkamenet más útvonalkészlettel térhet vissza. Ha a terv másodperc alatti konvergenciától függ, mérje meg, ne feltételezze.

Tartsa a szolgáltatási szerződést a változásrekorddal együtt. Amikor később valaki megkérdezi, miért nem futtathat az alagút OSPF-et, a válasz termékhatár, nem protokollkorlát, és a rekordnak ezt kell mondania.