Statičke rute ili protokol rutiranja preko VPN-a od lokacije do lokacije?

Obje opcije prenose pakete između lokacija, pa odluka nije o tome koji je protokol noviji, a veličina tunela je također ne rješava. Rješavaju je tri uslova: koliko prefiksa se mijenja i koliko često, da li dizajnu treba automatski prelaz između putanja, i koliko mehanizama kontrolnog sloja tim može održavati u tri sata ujutro. Odgovorite na to iskreno i izbor se obično sam nametne. Ostatak ovog teksta je šta svaki odgovor košta.

Tri uslova odlučuju

Prvi uslov je promjenljivost. Nekoliko stabilnih podmreža s jasnim vlasništvom može se godinama održavati ručno, a svaka ruta ostaje red koji neko može pročitati i provjeriti. Desetine prefiksa koji se sele kako projekti dolaze i odlaze drugi su problem, jer svaki prelaz mora stići do svakog uređaja koji još pamti stari put.

Drugi je ponašanje pri otkazu. Kada rezervna putanja mora postati aktivna bez toga da to čovjek primijeti, nešto mora otkriti otkaz i povući rutu. Statičko rutiranje to može samo praćenjem ili uslovnom instalacijom, i to samo za otkaze koje ste unaprijed predvidjeli.

Treći je apetit za drugi kontrolni sloj. Protokol rutiranja dodaje sesije, autentifikaciju, filtere i politiku odabira, a svako od toga traži nadzor i proces promjena. To je trajni operativni trošak, a ne jednokratni zadatak konfiguracije.

Tabela ispod trećeg pasusa je kratka verzija, a tri odjeljka nakon nje objašnjavaju zašto svaki red stoji tamo gdje stoji. Čitajte redove prema svom broju lokacija prije odabira, jer odluka koja zanemaruje operativni trošak je samo pola odluke.

Koliko statičko rutiranje zapravo košta

Statička ruta mora biti tačna s obje strane tunela. Dodavanje podmreže znači uređivanje udaljenog gejtveja, lokalnog gejtveja i obično povratne putanje, a zaboravljanje bilo kojeg od njih daje jednosmjerni otkaz koji izgleda kao greška u aplikaciji. Aplikacijski tim vidi isteke vremena, dok mrežni tim vidi rutu koja postoji i naizgled je zdrava. Nijedan tim nije u krivu, i zato je ovaj otkaz tako teško smjestiti.

Statički zapis također ostaje instaliran nakon što putanja ispod njega nestane. Ako platforma ne nudi praćenje, ruta nastavlja pokazivati na sljedeći hop koji više ne prosljeđuje, a saobraćaj nestaje umjesto da se prebaci. Ta tišina je trošak koji prihvatate kada birate jednostavnu opciju.

Upišite metodu praćenja uz svaku rutu, zabilježite koje otkaze pokriva i držite spisak uz konfiguraciju tunela. Inače sljedeći prekid otkrije korisnik, a ne mreža, što je uvijek skuplje otkriće.

Koliko dinamičko rutiranje zapravo košta

Protokol oglašava nove prefikse, povlači nedostupne i izražava preferenciju između putanja. To je istinski korisno kada bi nekoliko lokacija ili redundantni tuneli inače tražili usklađene izmjene pri svakoj promjeni. To je i razlog zašto vas protokol može iznenaditi u najgorem trenutku. Svaka od tih radnji je promjena stanja koju niste sami napravili.

On stvara dva stanja koja se mogu razilaziti. Tunel može biti podignut dok je sesija rutiranja spuštena, a sesija može biti podignuta dok njena oglašavanja izostavljaju podmrežu koja treba aplikaciji. Oba izgledaju kao mreža koja radi na pola, a nijedno se ne vidi sa stranice stanja tunela.

Filteri i politika zato postaju dio dizajna, a ne naknadna misao. Protokol koji oglašava sve na kraju će oglasiti nešto pogrešno, a pogrešan prefiks putuje brže od osobe koja ga može ispraviti. Napišite filtere prije nego što se prva sesija omogući, da prvo oglašavanje već bude namjerno.

Kontrolirajte šta sesija rutiranja smije reći

Odredite dozvoljeni spisak prefiksa po peeru i primijenite ga na ulazu, jer izlazni filter ne može spriječiti peera da vam pošalje zadanu rutu. Zadane rute i agregati su skupocjene greške ovdje: mogu tiho zamijeniti nepovezane putanje jednim naučenim zapisom koji izgleda legitimno. Odbijte ih izričito, osim ako dizajn to zaista želi.

Upišite lokaciju vlasnika uz svaku mrežu prije nego što prva sesija podigne, jer je to mapiranje izvor spiska filtera, a ne ukras dokumentacije. Bez toga osoba koja uređuje filter mora nagađati koja lokacija treba oglašavati prefiks.

Redistribucija između dva protokola je mjesto gdje petlje počinju i gdje isti prefiks stiže dvaput s atributima koji se ne porede čisto. Držite redistribuciju izvan dizajna dok je konkretan zahtjev ne nametne, a ako mora postojati, označite i filtrirajte rute na granici.

Tunelski interfejsi zasnovani na rutama čine dinamičko rutiranje lakšim za predstavljanje, jer tunel postaje interfejs s rutama umjesto politike koja uparuje selektore. To ne uklanja pitanje obuhvata peera: IPsec selektori i dalje moraju dozvoljavati saobraćaj koji namjeravate rutirati.

Testirajte putanju otkaza, a ne sretnu putanju

Šta god izabrali, spustite jedan uzlazni link i potvrdite da se saobraćaj pomjera ili da pada na način koji ste dokumentovali. Dizajn testiran samo sa obje zdrave putanje je dizajn koji uopšte nije testiran. Izmjerite vrijeme otkrivanja dok ste tamo, jer broj koji ste izmjerili je broj koji će korisnici osjetiti.

Zatim nezavisno potvrdite povratnu putanju, jer je asimetrično rutiranje preko VPN-a uobičajeno i nevidljivo dok uređaj koji čuva stanje ne odbaci odgovore. Tok koji radi u jednom smjeru dokazuje samo pola putanje.

Redoslijed rada: prebrojte prefikse, odlučite kako se otkazi trebaju otkrivati, provjerite ko može održavati protokol, kontrolirajte šta se oglašava, pa testirajte jedan prekid od početka do kraja. Svaki korak daje činjenicu koja treba sljedećem.