Statické trasy, nebo směrovací protokol přes VPN mezi lokalitami?

Obě možnosti přenášejí pakety mezi lokalitami, takže rozhodnutí není o tom, který protokol je novější, a velikost tunelu ho také nerozhodne. Rozhodují tři podmínky: kolik prefixů se mění a jak často, zda návrh potřebuje automatické přepnutí mezi cestami, a kolik mechanismů řídicí roviny tým zvládne provozovat ve tři ráno. Odpovězte na to poctivě a volba se obvykle udělá sama. Zbytek tohoto textu je cena každé odpovědi.

Rozhodují tři podmínky

První podmínkou je proměnlivost. Několik stabilních podsítí s jasným vlastníkem lze roky udržovat ručně a každá trasa zůstává řádkem, který někdo může přečíst a zkontrolovat. Desítky prefixů, které se stěhují s tím, jak projekty přicházejí a odcházejí, jsou jiný problém, protože každý přesun se musí dostat do každého zařízení, které si ještě pamatuje starou cestu.

Druhou je chování při poruše. Když se záložní cesta musí stát aktivní, aniž by si toho člověk všiml, něco musí poruchu odhalit a trasu stáhnout. Statické směrování to umí jen pomocí sledování nebo podmíněné instalace, a to pouze u poruch, které jste předem promysleli.

Třetí je chuť na druhou řídicí rovinu. Směrovací protokol přidává relace, autentizaci, filtry a politiku výběru, a každé z toho potřebuje monitorování a proces změn. To je trvalý provozní náklad, ne jednorázový úkol s konfigurací.

Tabulka pod třetím odstavcem je krátká verze a tři části za ní vysvětlují, proč každý řádek stojí tam, kde stojí. Čtěte řádky proti svému počtu lokalit, než zvolíte, protože rozhodnutí, které ignoruje provozní náklad, je jen polovina rozhodnutí.

Co statické směrování skutečně stojí

Statická trasa musí být správná na obou stranách tunelu. Přidání podsítě znamená upravit vzdálenou bránu, místní bránu a obvykle i zpětnou cestu, a zapomenutí kterékoli z nich vytvoří jednosměrnou poruchu, která vypadá jako chyba aplikace. Tým aplikace vidí časové limity, zatímco síťový tým vidí trasu, která existuje a zdánlivě je zdravá. Ani jeden tým se nemýlí, a proto je tato porucha tak obtížné lokalizovat.

Statický záznam také zůstává nainstalovaný poté, co cesta pod ním zmizí. Pokud platforma neposkytuje sledování, trasa dál ukazuje na další skok, který už nepředává, a provoz mizí místo přepnutí. To ticho je náklad, který přijímáte, když volíte jednoduchou možnost.

Zapište metodu sledování vedle každé trasy, poznamenejte, které poruchy pokrývá, a držte seznam u konfigurace tunelu. Jinak příští výpadek objeví uživatel a ne síť, což je vždy dražší objev.

Co dynamické směrování skutečně stojí

Protokol inzeruje nové prefixy, stahuje nedostupné a vyjadřuje preferenci mezi cestami. To je skutečně užitečné, když by několik lokalit nebo redundantních tunelů jinak vyžadovalo sladěné úpravy při každé změně. Je to také důvod, proč vás protokol může překvapit v nejhorší chvíli. Každá z těch akcí je změna stavu, kterou jste osobně neudělali.

Vytváří dva stavy, které si mohou odporovat. Tunel může být nahoře, zatímco směrovací relace je dole, a relace může být nahoře, zatímco její inzeráty vynechávají podsíť, kterou aplikace potřebuje. Oba vypadají jako síť, která funguje napůl, a ani jeden není vidět ze stránky stavu tunelu.

Filtry a politika se proto stávají součástí návrhu, ne dodatečnou myšlenkou. Protokol, který inzeruje všechno, nakonec inzeruje něco špatně a špatný prefix cestuje rychleji než člověk, který ho dokáže opravit. Napište filtry dřív, než zapnete první relaci, aby první inzerát už byl záměrný.

Kontrolujte, co směrovací relace smí říkat

Určete povolený seznam prefixů pro každého peera a vynucujte ho na vstupu, protože odchozí filtr nezabrání peerovi poslat vám výchozí trasu. Výchozí trasy a agregáty jsou zde drahé chyby: mohou tiše nahradit nesouvisející cesty jediným naučeným záznamem, který vypadá legitimně. Odmítejte je výslovně, pokud je návrh opravdu nechce.

Napište vlastnící lokalitu vedle každé sítě dřív, než první relace naběhne, protože toto mapování je zdrojem seznamu filtrů, ne ozdoba dokumentace. Bez něj musí ten, kdo filtr upravuje, hádat, která lokalita má prefix inzerovat.

Redistribuce mezi dvěma protokoly je místo, kde začínají smyčky a kde stejný prefix dorazí dvakrát s atributy, které se neporovnávají čistě. Držte redistribuci mimo návrh, dokud ji nevynutí konkrétní požadavek, a pokud existovat musí, označte a filtrujte trasy na hranici.

Tunelová rozhraní založená na trasách usnadňují znázornění dynamického směrování, protože tunel se stane rozhraním s trasami místo politiky porovnávající selektory. To neodstraňuje otázku rozsahu peera: selektory IPsec stále musí povolit provoz, který hodláte směrovat.

Testujte cestu poruchy, ne šťastnou cestu

Ať zvolíte cokoli, shodte jedno vzestupné spojení a potvrďte, že provoz se přesune, nebo že selže tak, jak jste zdokumentovali. Návrh testovaný jen s oběma zdravými cestami je návrh, který se netestoval vůbec. Změřte dobu detekce, dokud jste tam, protože číslo, které jste naměřili, je číslo, které zažijí uživatelé.

Potom nezávisle potvrďte zpětnou cestu, protože asymetrické směrování přes VPN je běžné a neviditelné, dokud stavové zařízení nezahodí odpovědi. Tok, který funguje v jednom směru, dokazuje jen polovinu cesty.

Pořadí práce: spočítejte prefixy, rozhodněte, jak se mají poruchy odhalovat, zkontrolujte, kdo umí protokol provozovat, kontrolujte, co se inzeruje, a pak otestujte jeden výpadek od začátku do konce. Každý krok dává fakt, který potřebuje ten další.