Статични маршрути или протокол за маршрутизация през VPN сайт към сайт?

И двете опции пренасят пакети между сайтове, така че решението не е за това кой протокол е по-нов и размерът на тунела също не го решава. Решават го три условия: колко префикса се променят и колко често, дали дизайнът се нуждае от автоматично превключване между пътища, и колко механика на контролния слой екипът може да обслужва в три часа през нощта. Отговорете честно и изборът обикновено се прави сам. Останалото от този текст е цената на всеки отговор.

Три условия решават въпроса

Първото условие е изменчивостта. Шепа стабилни подмрежи с ясна собственост могат да се поддържат на ръка с години и всеки маршрут остава ред, който някой може да прочете и провери. Десетки префикси, които се местят с идването и отиването на проекти, са друг проблем, защото всяко местене трябва да стигне до всяко устройство, което още помни стария път.

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

Третото е апетит за втори контролен слой. Протоколът за маршрутизация добавя сесии, удостоверяване, филтри и политика за избор и всяко от тях се нуждае от мониторинг плюс процес за промени. Това е постоянен оперативен разход, а не еднократна задача по конфигуриране.

Таблицата под третия абзац е кратката версия, а трите раздела след нея обясняват защо всеки ред стои там, където стои. Четете редовете срещу собствения си брой сайтове, преди да изберете, защото решение, което пренебрегва оперативния разход, е само половина решение.

Колко всъщност струва статичната маршрутизация

Статичният маршрут трябва да е правилен от двете страни на тунела. Добавянето на подмрежа означава редакция на отдалечения шлюз, на локалния шлюз и обикновено на обратния път, а забравянето на който и да е от тях дава еднопосочен отказ, който изглежда като грешка в приложението. Екипът на приложението вижда изчаквания, докато екипът на мрежата вижда маршрут, който присъства и изглежда здрав. Никой от двата екипа не греши и затова този отказ се локализира толкова дълго.

Статичният запис също остава инсталиран, след като пътят под него изчезне. Освен ако платформата не предоставя проследяване, маршрутът продължава да сочи към следващ хоп, който вече не препраща, и трафикът изчезва вместо да превключи. Тази тишина е разходът, който приемате, избирайки простата опция.

Запишете метода за проследяване до всеки маршрут, отбележете кои откази покрива и дръжте списъка с конфигурацията на тунела. Иначе следващото прекъсване се открива от потребител, а не от мрежата, което винаги е по-скъпото откриване.

Колко всъщност струва динамичната маршрутизация

Протоколът обявява нови префикси, оттегля недостъпните и изразява предпочитание между пътищата. Това е наистина полезно, когато няколко сайта или резервни тунела иначе биха изисквали съгласувани редакции при всяка промяна. Това е и причината протоколът да ви изненада в най-лошия момент. Всяко от тези действия е промяна на състояние, която не сте направили лично.

Той създава две състояния, които могат да не съвпадат. Тунелът може да е вдигнат, докато сесията за маршрутизация е свалена, а сесията може да е вдигната, докато обявите й пропускат подмрежата, от която приложението се нуждае. И двете изглеждат като мрежа, която работи наполовина, и нито едно не се вижда от страница за състоянието на тунела.

Затова филтрите и политиката стават част от дизайна, а не късна добавка. Протокол, който обявява всичко, рано или късно ще обяви нещо грешно и грешният префикс пътува по-бързо от човека, който може да го поправи. Напишете филтрите, преди да включите първата сесия, така че първата обява вече да е умишлена.

Контролирайте какво може да казва сесията за маршрутизация

Определете разрешения списък с префикси за всеки партньор и го налагайте на входа, защото изходящ филтър не може да спре партньор да ви изпрати маршрут по подразбиране. Маршрутите по подразбиране и агрегатите са скъпите грешки тук: те могат тихо да заменят несвързани пътища с един научен запис, който изглежда законен. Отхвърляйте ги изрично, освен ако дизайнът наистина ги иска.

Запишете сайта собственик до всяка мрежа, преди първата сесия да вдигне, защото това съответствие е източникът на списъка с филтри, а не украшение на документацията. Без него човекът, който редактира филтър, трябва да гадае кой сайт трябва да обявява префикса.

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

Тунелните интерфейси, базирани на маршрути, правят динамичната маршрутизация по-лесна за представяне, защото тунелът става интерфейс с маршрути вместо политика, съпоставяща селектори. Това не премахва въпроса за обхвата на партньора: селекторите на IPsec все още трябва да разрешават трафика, който възнамерявате да рутирате.

Тествайте пътя на отказа, не щастливия път

Каквото и да изберете, свалете една връзка и потвърдете, че трафикът се мести или че се проваля по начина, който сте документирали. Дизайн, тестван само с двата здрави пътя, е дизайн, който изобщо не е тестван. Измерете времето за откриване, докато сте там, защото числото, което сте измерили, е числото, което потребителите ще изпитат.

След това потвърдете обратния път независимо, защото асиметричната маршрутизация през VPN е обичайна и невидима, докато устройство със състояние не изпусне отговорите. Поток, който работи в една посока, доказва само половината от пътя.

Ред на работа: пребройте префиксите, решете как да се откриват отказите, проверете кой може да обслужва протокола, контролирайте какво се обявява, после тествайте едно прекъсване от край до край. Всяка стъпка дава факт, който следващата стъпка иска.