Статични рути или протокол за рутирање преку VPN од локација до локација?

Двете опции пренесуваат пакети меѓу локации, така што одлуката не е за тоа кој протокол е понов, а ниту големината на тунелот не ја решава. Ја решаваат три услови: колку префикси се менуваат и колку често, дали на дизајнот му треба автоматско префрлање меѓу патеки, и колку механизам на контролен слој тимот може да одржува во три часот наутро. Одговорете на овие искрено и изборот обично се прави сам. Остатокот од овој текст е што чини секој одговор.

Три услови одлучуваат

Првиот услов е променливоста. Неколку стабилни подмрежи со јасна сопственост може со години да се одржуваат рачно, и секоја рута останува ред што некој може да го прочита и провери. Десетици префикси што се преместуваат како што доаѓаат и заминуваат проектите се друг проблем, бидејќи секое преместување мора да стигне до секој уред што ја памети старата патека.

Вториот е однесувањето при дефект. Кога резервната патека треба да стане активна без човек да забележи, нешто мора да го открие дефектот и да ја повлече рутата. Статичкото рутирање тоа може само преку следење или условна инсталација, и само за дефектите што сте ги предвиделе.

Третиот е апетитот за втор контролен слој. Протоколот за рутирање додава сесии, автентикација, филтри и политика за избор, и секое од тоа бара надзор и процес на промени. Тоа е траен оперативен трошок, а не еднократна задача со конфигурација.

Табелата под третиот пасус е кратката верзија, а трите секции по неа објаснуваат зошто секој ред стои таму каде што стои. Прочитајте ги редовите наспроти вашиот број локации пред да изберете, бидејќи одлука што го игнорира оперативниот трошок е само половина одлука.

Колку всушност чини статичкото рутирање

Статичката рута мора да биде точна од двете страни на тунелот. Додавањето подмрежа значи уредување на оддалечениот портал, локалниот портал и обично повратната патека, а заборавањето на кое било од нив создава еднонасочен дефект што изгледа како грешка во апликацијата. Апликацискиот тим гледа истекувања на време, додека мрежниот тим гледа рута што постои и навидум е здрава. Ниту еден тим не греши, и затоа овој дефект толку тешко се лоцира.

Статичкиот запис исто така останува инсталиран откако патеката под него ќе исчезне. Ако платформата не нуди следење, рутата продолжува да покажува кон следниот скок што веќе не препраќа, и сообраќајот исчезнува наместо да се префрли. Таа тишина е трошокот што го прифаќате кога ја избирате едноставната опција.

Запишете го методот на следење покрај секоја рута, забележете кои дефекти ги покрива и чувајте ја листата со конфигурацијата на тунелот. Инаку следниот прекин ќе го открие корисник, а не мрежата, што е секогаш поскапо откривање.

Колку всушност чини динамичкото рутирање

Протоколот објавува нови префикси, повлекува недостапни и изразува претпочитање меѓу патеки. Тоа е навистина корисно кога неколку локации или вишок тунели инаку би барале координирани измени при секоја промена. Тоа е и причината зошто протоколот може да ве изненади во најлош момент. Секое од тие дејства е промена на состојба што не сте ја направиле сами.

Тој создава две состојби што можат да се разидуваат. Тунелот може да е подигнат додека сесијата за рутирање е спуштена, а сесијата може да е подигната додека нејзините објави ја испуштаат подмрежата што ѝ треба на апликацијата. Двете изгледаат како мрежа што работи половина, и ниту една не се гледа од страница за состојба на тунелот.

Затоа филтрите и политиката стануваат дел од дизајнот, а не подоцнежна мисла. Протокол што објавува сите префикси на крајот ќе објави нешто погрешно, а погрешниот префикс патува побрзо од човекот што може да го исправи. Напишете ги филтрите пред да се вклучи првата сесија, за првата објава веќе да биде намерна.

Контролирајте што смее да каже сесијата за рутирање

Одредете ја дозволената листа на префикси по партнер и спроведете ја на влезот, бидејќи излезен филтер не може да спречи партнер да ви испрати стандардна рута. Стандардните рути и агрегатите се скапите грешки овде: тие можат тивко да ги заменат неповрзаните патеки со еден научен запис што изгледа легитимно. Одбијте ги експлицитно, освен ако дизајнот навистина не ги сака.

Запишете ја локацијата сопственик покрај секоја мрежа пред да се подигне првата сесија, бидејќи тоа мапирање е изворот на листата со филтри, а не украс на документацијата. Без него, тој што уредува филтер мора да погодува која локација треба да го објавува префиксот.

Прераспределбата меѓу два протокола е местото каде почнуваат јамките и каде истиот префикс пристигнува двапати со атрибути што не се споредуваат чисто. Држете ја прераспределбата надвор од дизајнот додека конкретен услов не ја наметне, и ако мора да постои, означете ги и филтрирајте ги рутите на границата.

Тунелските интерфејси засновани на рути го олеснуваат претставувањето на динамичкото рутирање, бидејќи тунелот станува интерфејс со рути наместо политика што ги совпаѓа селекторите. Тоа не го отстранува прашањето за опсегот на партнерот: IPsec селекторите и понатаму мора да го дозволуваат сообраќајот што планирате да го рутирате.

Тестирајте ја патеката на дефектот, не среќната патека

Што и да изберете, спуштете еден нагорен линк и потврдете дека сообраќајот се преместува или дека не успева како што документиравте. Дизајн тестиран само со двете здрави патеки е дизајн што воопшто не е тестиран. Измерете го времето на откривање додека сте таму, бидејќи бројот што го измеривте е бројот што корисниците ќе го доживеат.

Потоа потврдете ја повратната патека независно, бидејќи асиметричното рутирање преку VPN е вообичаено и невидливо додека уред што чува состојба не ги отфрли одговорите. Тек што работи во една насока докажува само половина од патеката.

Редослед на работа: избројте ги префиксите, одлучете како треба да се откриваат дефектите, проверете кој може да го одржува протоколот, контролирајте што се објавува, потоа тестирајте еден прекин од почеток до крај. Секој чекор дава факт што му треба на следниот.