Statiniai maršrutai ar maršrutizavimo protokolas per VPN tarp svetainių?

Abu variantai perduoda paketus tarp svetainių, todėl sprendimas ne apie tai, kuris protokolas naujesnis, ir tunelio dydis jo taip pat nenulemia. Jį nulemia trys sąlygos: kiek prefiksų keičiasi ir kaip dažnai, ar dizainui reikia automatinio perjungimo tarp kelių, ir kiek valdymo plokštumos mechanizmų komanda gali prižiūrėti trečią valandą nakties. Atsakykite į tai sąžiningai ir pasirinkimas paprastai padaro save pats. Likusi šio teksto dalis yra tai, kiek kainuoja kiekvienas atsakymas.

Trys sąlygos nulemia

Pirmoji sąlyga yra kaita. Keletą stabilių potinkių su aiškia nuosavybe galima metų metus prižiūrėti rankomis, ir kiekvienas maršrutas lieka eilute, kurią kas nors gali perskaityti ir patikrinti. Dešimtys prefiksų, kurie juda projektams ateinant ir išeinant, yra kita problema, nes kiekvienas judėjimas turi pasiekti kiekvieną įrenginį, kuris dar prisimena seną kelią.

Antroji yra elgsena gedimo metu. Kai atsarginis kelias turi tapti aktyvus žmogui nepastebint, kažkas turi aptikti gedimą ir atšaukti maršrutą. Statinis maršrutizavimas tai gali tik sekdamas arba sąlyginai įdiegdamas, ir tik tuos gedimus, kuriuos numatėte iš anksto.

Trečioji yra apetitas antrajai valdymo plokštumai. Maršrutizavimo protokolas prideda sesijas, autentifikavimą, filtrus ir pasirinkimo politiką, ir kiekvienas iš jų reikalauja stebėjimo bei keitimo proceso. Tai nuolatinės eksploatavimo išlaidos, o ne vienkartinė konfigūravimo užduotis.

Lentelė po trečia pastraipa yra trumpoji versija, o trys skyriai po jos paaiškina, kodėl kiekviena eilutė yra ten, kur yra. Prieš rinkdamiesi perskaitykite eilutes pagal savo svetainių skaičių, nes sprendimas, ignoruojantis eksploatavimo išlaidas, yra tik pusė sprendimo.

Kiek iš tikrųjų kainuoja statinis maršrutizavimas

Statinis maršrutas turi būti teisingas abiejose tunelio pusėse. Potinklio įtraukimas reiškia tolimojo šliuzo, vietinio šliuzo ir paprastai grįžimo kelio redagavimą, o pamiršus bet kurį iš jų atsiranda vienkryptis gedimas, kuris atrodo kaip programos klaida. Programos komanda mato laukimo viršijimus, o tinklo komanda mato maršrutą, kuris egzistuoja ir atrodo sveikas. Nė viena komanda neklysta, todėl šį gedimą taip sunku surasti.

Statinis įrašas taip pat lieka įdiegtas po to, kai kelias po juo išnyksta. Jei platforma neteikia sekimo, maršrutas toliau rodo į kitą šuolį, kuris jau neperduoda, ir srautas išnyksta, o ne persijungia. Ta tyla yra kaina, kurią priimate rinkdamiesi paprastą variantą.

Užrašykite sekimo metodą prie kiekvieno maršruto, pažymėkite, kuriuos gedimus jis apima, ir laikykite sąrašą kartu su tunelio konfigūracija. Priešingu atveju kitą sutrikimą atras naudotojas, o ne tinklas, ir tai visada brangesnis atradimas.

Kiek iš tikrųjų kainuoja dinaminis maršrutizavimas

Protokolas skelbia naujus prefiksus, atšaukia nepasiekiamus ir išreiškia pirmenybę tarp kelių. Tai tikrai naudinga, kai kelių svetainių ar perteklinių tunelių atveju kitaip prireiktų suderintų pakeitimų prie kiekvieno pokyčio. Tai taip pat priežastis, kodėl protokolas gali nustebinti jus blogiausiu metu. Kiekvienas iš tų veiksmų yra būsenos pokytis, kurio neatlikote patys.

Jis sukuria dvi būsenas, kurios gali nesutarti. Tunelis gali būti viršuje, o maršrutizavimo sesija apačioje, ir sesija gali būti viršuje, o jos skelbimai praleidžia potinklį, kurio reikia programai. Abi atrodo kaip pusiau veikiantis tinklas, ir nė viena nematoma tunelio būsenos puslapyje.

Todėl filtrai ir politika tampa dizaino dalimi, o ne vėlyva mintimi. Protokolas, skelbiantis viską, galiausiai paskelbs ką nors neteisingo, ir neteisingas prefiksas keliauja greičiau nei žmogus, kuris gali jį pataisyti. Parašykite filtrus prieš įjungdami pirmąją sesiją, kad pirmasis skelbimas jau būtų sąmoningas.

Kontroliuokite, ką maršrutizavimo sesija gali sakyti

Nustatykite leidžiamų prefiksų sąrašą kiekvienam partneriui ir vykdykite jį įėjime, nes išėjimo filtras negali sutrukdyti partneriui atsiųsti jums numatytojo maršruto. Numatytieji maršrutai ir agregatai čia yra brangios klaidos: jie gali tyliai pakeisti nesusijusius kelius vienu išmoktu įrašu, kuris atrodo teisėtas. Atmeskite juos aiškiai, nebent dizainas jų tikrai nori.

Užrašykite savininko svetainę prie kiekvieno tinklo prieš pakylant pirmajai sesijai, nes tas susiejimas yra filtrų sąrašo šaltinis, o ne dokumentacijos puošmena. Be jo filtro redaguotojas turi spėti, kuri svetainė turėtų skelbti prefiksą.

Perskirstymas tarp dviejų protokolų yra vieta, kur prasideda kilpos, ir kur tas pats prefiksas atvyksta du kartus su atributais, kurių negalima švariai palyginti. Laikykite perskirstymą už dizaino ribų, kol konkretus reikalavimas jo neprivers, o jei jis turi būti, pažymėkite ir filtruokite maršrutus pasienyje.

Maršrutu pagrįsti tunelio sąsajos leidžia lengviau pavaizduoti dinaminį maršrutizavimą, nes tunelis tampa sąsaja su maršrutais, o ne politika, atitinkančia selektorius. Tai nepanaikina partnerio apimties klausimo: IPsec selektoriai vis tiek turi leisti srautą, kurį ketinate maršrutizuoti.

Išbandykite gedimo kelią, o ne laimingą kelią

Kad ir ką pasirinktumėte, išjunkite vieną išorinę jungtį ir patvirtinkite, kad srautas juda arba kad jis nepavyksta taip, kaip dokumentavote. Dizainas, išbandytas tik su abiem sveikais keliais, yra visiškai neišbandytas dizainas. Išmatuokite aptikimo laiką, kol ten esate, nes skaičius, kurį išmatavote, yra skaičius, kurį patirs naudotojai.

Tada nepriklausomai patvirtinkite grįžimo kelią, nes asimetrinis maršrutizavimas per VPN yra įprastas ir nematomas tol, kol būseną saugantis įrenginys nenumes atsakymų. Srautas, veikiantis viena kryptimi, įrodo tik pusę kelio.

Darbo tvarka: suskaičiuokite prefiksus, nuspręskite, kaip turi būti aptinkami gedimai, patikrinkite, kas gali prižiūrėti protokolą, kontroliuokite, kas skelbiama, ir tada išbandykite vieną sutrikimą nuo pradžios iki galo. Kiekvienas žingsnis duoda faktą, kurio reikia kitam.