Statické trasy alebo smerovací protokol cez VPN medzi lokalitami?

Obe možnosti prenášajú pakety medzi lokalitami, takže rozhodnutie nie je o tom, ktorý protokol je novší, a veľkosť tunela ho tiež nerozhodne. Rozhodujú tri podmienky: koľko prefixov sa mení a ako často, či návrh potrebuje automatické prepnutie medzi cestami, a koľko mechanizmov riadiacej roviny tím zvládne obsluhovať o tretej ráno. Odpovedzte na to čestne a voľba sa zvyčajne urobí sama. Zvyšok tohto textu je cena každej odpovede.

Rozhodujú tri podmienky

Prvou podmienkou je premenlivosť. Niekoľko stabilných podsietí s jasným vlastníkom sa dá roky udržiavať ručne a každá trasa zostáva riadkom, ktorý niekto môže prečítať a skontrolovať. Desiatky prefixov, ktoré sa presúvajú s príchodom a odchodom projektov, sú iný problém, pretože každý presun sa musí dostať do každého zariadenia, ktoré si ešte pamätá starú cestu.

Druhou je správanie pri poruche. Keď sa záložná cesta musí stať aktívnou bez toho, aby si to človek všimol, niečo musí poruchu odhaliť a trasu stiahnuť. Statické smerovanie to dokáže len sledovaním alebo podmienenou inštaláciou, a to iba pre poruchy, ktoré ste vopred premysleli.

Treťou je chuť na druhú riadiacu rovinu. Smerovací protokol pridáva relácie, autentifikáciu, filtre a politiku výberu, a každé z toho potrebuje monitorovanie a proces zmien. To je trvalý prevádzkový náklad, nie jednorazová úloha s konfiguráciou.

Tabuľka pod tretím odsekom je krátka verzia a tri časti za ňou vysvetľujú, prečo každý riadok stojí tam, kde stojí. Čítajte riadky proti svojmu počtu lokalít pred výberom, pretože rozhodnutie, ktoré ignoruje prevádzkový náklad, je len polovica rozhodnutia.

Koľko statické smerovanie skutočne stojí

Statická trasa musí byť správna na oboch stranách tunela. Pridanie podsiete znamená upraviť vzdialenú bránu, miestnu bránu a zvyčajne aj spätnú cestu, a zabudnutie ktorejkoľvek z nich vytvorí jednosmernú poruchu, ktorá vyzerá ako chyba aplikácie. Tím aplikácie vidí časové limity, zatiaľ čo sieťový tím vidí trasu, ktorá existuje a zdanlivo je zdravá. Ani jeden tím sa nemýli, a preto je túto poruchu tak ťažké lokalizovať.

Statický záznam tiež zostáva nainštalovaný po tom, čo cesta pod ním zmizne. Ak platforma neposkytuje sledovanie, trasa naďalej ukazuje na ďalší skok, ktorý už nepreposiela, a prevádzka zmizne namiesto prepnutia. To ticho je náklad, ktorý prijímate, keď si vyberiete jednoduchú možnosť.

Napíšte metódu sledovania vedľa každej trasy, poznamenajte, ktoré poruchy pokrýva, a držte zoznam pri konfigurácii tunela. Inak ďalší výpadok objaví používateľ a nie sieť, čo je vždy drahší objav.

Koľko dynamické smerovanie skutočne stojí

Protokol inzeruje nové prefixy, sťahuje nedostupné a vyjadruje preferenciu medzi cestami. To je skutočne užitočné, keď by niekoľko lokalít alebo redundantných tunelov inak vyžadovalo zladené úpravy pri každej zmene. Je to aj dôvod, prečo vás protokol môže prekvapiť v najhoršej chvíli. Každá z tých akcií je zmena stavu, ktorú ste osobne neurobili.

Vytvára dva stavy, ktoré si môžu odporovať. Tunel môže byť hore, zatiaľ čo smerovacia relácia je dole, a relácia môže byť hore, zatiaľ čo jej inzeráty vynechávajú podsieť, ktorú aplikácia potrebuje. Obe vyzerajú ako sieť, ktorá funguje spolovice, a ani jedno nie je vidieť zo stránky stavu tunela.

Filtre a politika sa preto stávajú súčasťou návrhu, nie dodatočnou myšlienkou. Protokol, ktorý inzeruje všetko, nakoniec inzeruje niečo nesprávne a nesprávny prefix cestuje rýchlejšie ako človek, ktorý ho dokáže opraviť. Napíšte filtre pred zapnutím prvej relácie, aby bol prvý inzerát už zámerný.

Kontrolujte, čo smie smerovacia relácia hovoriť

Určte povolený zoznam prefixov pre každého partnera a vynucujte ho na vstupe, pretože odchádzajúci filter nezabráni partnerovi poslať vám predvolenú trasu. Predvolené trasy a agregáty sú tu drahé chyby: môžu ticho nahradiť nesúvisiace cesty jediným naučeným záznamom, ktorý vyzerá legitímne. Odmietajte ich výslovne, ak ich návrh naozaj nechce.

Napíšte vlastnícku lokalitu vedľa každej siete skôr, než prvá relácia naberie, pretože to mapovanie je zdrojom zoznamu filtrov, nie ozdobou dokumentácie. Bez neho musí ten, kto upravuje filter, hádať, ktorá lokalita má prefix inzerovať.

Redistribúcia medzi dvoma protokolmi je miesto, kde začínajú slučky a kde ten istý prefix dorazí dvakrát s atribútmi, ktoré sa nedajú čisto porovnať. Držte redistribúciu mimo návrhu, kým ju nevynúti konkrétna požiadavka, a ak existovať musí, označte a filtrujte trasy na hranici.

Tunelové rozhrania založené na trasách uľahčujú znázornenie dynamického smerovania, pretože tunel sa stane rozhraním s trasami namiesto politiky porovnávajúcej selektory. Neodstraňuje to otázku rozsahu partnera: selektory IPsec stále musia povoliť prevádzku, ktorú chcete smerovať.

Testujte cestu poruchy, nie šťastnú cestu

Čokoľvek si vyberiete, zhoďte jedno vzostupné spojenie a potvrďte, že prevádzka sa presunie alebo že zlyhá tak, ako ste zdokumentovali. Návrh testovaný len s oboma zdravými cestami je návrh, ktorý sa netestoval vôbec. Zmerajte čas detekcie, kým ste tam, pretože číslo, ktoré ste namerali, je číslo, ktoré zažijú používatelia.

Potom nezávisle potvrďte spätnú cestu, pretože asymetrické smerovanie cez VPN je bežné a neviditeľné, kým stavové zariadenie nezahodí odpovede. Tok, ktorý funguje v jednom smere, dokazuje len polovicu cesty.

Poradie práce: spočítajte prefixy, rozhodnite, ako sa majú poruchy odhaľovať, skontrolujte, kto dokáže protokol obsluhovať, kontrolujte, čo sa inzeruje, a potom otestujte jeden výpadok od začiatku do konca. Každý krok dáva fakt, ktorý potrebuje ten ďalší.