Statiskie maršruti vai maršrutēšanas protokols pār VPN starp vietnēm?

Abi varianti pārvieto paketes starp vietnēm, tāpēc lēmums nav par to, kurš protokols ir jaunāks, un arī tuneļa izmērs to neizšķir. To izšķir trīs nosacījumi: cik prefiksu mainās un cik bieži, vai dizainam vajadzīga automātiska pārslēgšanās starp ceļiem, un cik daudz vadības plaknes mehānismu komanda spēj uzturēt trijos naktī. Atbildiet uz to godīgi, un izvēle parasti izdarās pati. Pārējais šajā tekstā ir tas, cik maksā katra atbilde.

Trīs nosacījumi to izšķir

Pirmais nosacījums ir mainība. Dažus stabilus apakštīklus ar skaidru piederību var gadiem uzturēt ar rokām, un katrs maršruts paliek rinda, ko kāds var izlasīt un pārbaudīt. Desmitiem prefiksu, kas pārvietojas līdz ar projektu atnākšanu un aiziešanu, ir cita problēma, jo katrai pārvietošanai jāsasniedz katra ierīce, kas vēl atceras veco ceļu.

Otrais ir uzvedība kļūmes gadījumā. Kad rezerves ceļam jākļūst aktīvam, cilvēkam to nepamanot, kaut kam jāatklāj kļūme un jāatsauc maršruts. Statiskā maršrutēšana to spēj tikai ar izsekošanu vai nosacītu instalāciju, un tikai tiem defektiem, kurus esat iepriekš pārdomājis.

Trešais ir apetīte pēc otras vadības plaknes. Maršrutēšanas protokols pievieno sesijas, autentifikāciju, filtrus un atlases politiku, un katram no tiem vajadzīga uzraudzība un izmaiņu process. Tās ir pastāvīgas ekspluatācijas izmaksas, nevis vienreizējs konfigurēšanas uzdevums.

Tabula zem trešās rindkopas ir īsā versija, un trīs sadaļas pēc tās skaidro, kāpēc katra rinda atrodas tur, kur tā atrodas. Pirms izvēles lasiet rindas pret savu vietņu skaitu, jo lēmums, kas ignorē ekspluatācijas izmaksas, ir tikai puse lēmuma.

Cik statiskā maršrutēšana patiešām maksā

Statiskajam maršrutam jābūt pareizam abās tuneļa pusēs. Apakštīkla pievienošana nozīmē rediģēt attālo vārteju, vietējo vārteju un parasti atgriešanās ceļu, un jebkura no tiem aizmirstība rada vienvirziena kļūmi, kas izskatās kā lietojumprogrammas kļūda. Lietojumprogrammas komanda redz noildzes, bet tīkla komanda redz maršrutu, kas pastāv un šķietami ir vesels. Neviena komanda nekļūdās, un tāpēc šo kļūmi ir tik grūti lokalizēt.

Statisks ieraksts arī paliek instalēts pēc tam, kad ceļš zem tā pazūd. Ja platforma nenodrošina izsekošanu, maršruts turpina norādīt uz nākamo lēcienu, kas vairs nepiegādā, un trafiks pazūd, nevis pārslēdzas. Šis klusums ir izmaksas, ko pieņemat, izvēloties vienkāršo variantu.

Pierakstiet izsekošanas metodi blakus katram maršrutam, atzīmējiet, kurus defektus tā aptver, un glabājiet sarakstu kopā ar tuneļa konfigurāciju. Citādi nākamo pārtraukumu atklās lietotājs, nevis tīkls, un tas vienmēr ir dārgākais atklājums.

Cik dinamiskā maršrutēšana patiešām maksā

Protokols paziņo jaunus prefiksus, atsauc nesasniedzamos un izsaka priekšroku starp ceļiem. Tas patiešām ir noderīgi, kad vairākām vietnēm vai liekiem tuneļiem citādi būtu vajadzīgas saskaņotas izmaiņas pie katras pārmaiņas. Tas ir arī iemesls, kāpēc protokols var pārsteigt jūs sliktākajā brīdī. Katra no šīm darbībām ir stāvokļa maiņa, ko neesat veicis pats.

Tas rada divus stāvokļus, kas var nesaskanēt. Tunelis var būt augšā, kamēr maršrutēšanas sesija ir lejā, un sesija var būt augšā, kamēr tās paziņojumi izlaiž apakštīklu, kas vajadzīgs lietojumprogrammai. Abi izskatās kā pusēm strādājošs tīkls, un neviens nav redzams tuneļa stāvokļa lapā.

Tāpēc filtri un politika kļūst par dizaina daļu, nevis vēlīnu domu. Protokols, kas paziņo visu, agrāk vai vēlāk paziņos kaut ko nepareizu, un nepareizais prefikss ceļo ātrāk nekā cilvēks, kurš to var labot. Uzrakstiet filtrus pirms pirmās sesijas ieslēgšanas, lai pirmais paziņojums jau būtu apzināts.

Kontrolējiet, ko maršrutēšanas sesija drīkst teikt

Nosakiet atļauto prefiksu sarakstu katram partnerim un piemērojiet to ieejā, jo izejas filtrs nevar liegt partnerim nosūtīt jums noklusējuma maršrutu. Noklusējuma maršruti un apkopojumi šeit ir dārgas kļūdas: tie var klusi aizstāt nesaistītus ceļus ar vienu apgūtu ierakstu, kas izskatās likumīgs. Noraidiet tos skaidri, ja vien dizains tos tiešām nevēlas.

Pierakstiet īpašniekvietni blakus katram tīklam pirms pirmās sesijas pacelšanās, jo šī atbilstība ir filtru saraksta avots, nevis dokumentācijas rotājums. Bez tā filtra redaktors var tikai minēt, kurai vietnei būtu jāpaziņo prefikss.

Pārdale starp diviem protokoliem ir vieta, kur sākas cilpas, un kur viens un tas pats prefikss ierodas divreiz ar atribūtiem, kurus nevar tīri salīdzināt. Turiet pārdali ārpus dizaina, līdz konkrēta prasība to piespiež, un ja tai jābūt, atzīmējiet un filtrējiet maršrutus uz robežas.

Uz maršrutiem balstītas tuneļa saskarnes atvieglo dinamiskās maršrutēšanas attēlošanu, jo tunelis kļūst par saskarni ar maršrutiem, nevis politiku, kas saskaņo selektorus. Tas neizslēdz partnera tvēruma jautājumu: IPsec selektoriem joprojām jāatļauj trafiks, kuru plānojat maršrutēt.

Pārbaudiet kļūmes ceļu, nevis laimīgo ceļu

Lai ko izvēlētos, izslēdziet vienu augšupējo savienojumu un pārliecinieties, ka trafiks pārvietojas vai ka tas neizdodas tā, kā dokumentējāt. Dizains, kas pārbaudīts tikai ar abiem veseliem ceļiem, ir dizains, kas nav pārbaudīts vispār. Izmēriet noteikšanas laiku, kamēr esat tur, jo skaitlis, ko izmērījāt, ir skaitlis, ko piedzīvos lietotāji.

Pēc tam neatkarīgi pārliecinieties par atgriešanās ceļu, jo asimetriskā maršrutēšana pār VPN ir izplatīta un neredzama, līdz stāvokli glabājoša ierīce nomet atbildes. Plūsma, kas darbojas vienā virzienā, pierāda tikai pusi ceļa.

Darba kārtība: saskaitiet prefiksus, izlemiet, kā jāatklāj kļūmes, pārbaudiet, kas var uzturēt protokolu, kontrolējiet, kas tiek paziņots, un tad pārbaudiet vienu pārtraukumu no sākuma līdz beigām. Katrs solis dod faktu, kas vajadzīgs nākamajam.