Статычныя маршруты ці пратакол маршрутызацыі праз VPN паміж пляцоўкамі?

Абодва варыянты пераносяць пакеты паміж пляцоўкамі, таму рашэнне не ў тым, які пратакол навейшы, і памер тунеля таксама яго не вызначае. Вызначаюць тры ўмовы: колькі прэфіксаў змяняецца і як часта, ці патрэбна дызайну аўтаматычнае пераключэнне паміж шляхамі, і колькі механізмаў узроўню кіравання каманда здольная абслугоўваць у тры гадзіны ночы. Адкажыце на гэта сумленна, і выбар звычайна зробіць сябе сам. Астатняя частка гэтага тэксту — гэта цана кожнага адказу.

Тры ўмовы вызначаюць рашэнне

Першая ўмова — зменлівасць. Жменьку стабільных падсетак з ясным уладальнікам можна гадамі падтрымліваць уручную, і кожны маршрут застаецца радком, які хтосьці можа прачытаць і праверыць. Дзясяткі прэфіксаў, якія рухаюцца разам з прыходам і сыходам праектаў, — іншая праблема, бо кожны рух павінен дайсці да кожнай прылады, якая яшчэ памятае стары шлях.

Другая — паводзіны пры збоі. Калі рэзервовы шлях павінен стаць актыўным без удзелу чалавека, нешта павінна выявіць збой і адклікаць маршрут. Статычная маршрутызацыя можа гэта толькі праз адсочванне або ўмоўную ўстаноўку, і толькі для тых збояў, якія вы прадугледзелі загадзя.

Трэцяя — гатоўнасць да другога ўзроўню кіравання. Пратакол маршрутызацыі дадае сесіі, аўтэнтыфікацыю, фільтры і палітыку выбару, і кожнае з гэтага патрабуе маніторынгу і працэсу змен. Гэта пастаянныя эксплуатацыйныя выдаткі, а не разавая задача наладкі.

Табліца пад трэцім абзацам — гэта кароткая версія, а тры раздзелы пасля яе тлумачаць, чаму кожны радок стаіць там, дзе стаіць. Чытайце радкі супраць сваёй колькасці пляцовак перад выбарам, бо рашэнне, якое ігнаруе эксплуатацыйныя выдаткі, — гэта толькі палова рашэння.

Колькі насамрэч каштуе статычная маршрутызацыя

Статычны маршрут павінен быць правільным з абодвух бакоў тунеля. Даданне падсеткі азначае праўку аддаленага шлюза, лакальнага шлюза і звычайна зваротнага шляху, і забыццё любога з іх дае аднабаковы збой, які выглядае як памылка праграмы. Каманда праграмы бачыць тайм-аўты, а каманда сеткі бачыць маршрут, які прысутнічае і выглядае здаровым. Ні адна каманда не памыляецца, і таму гэты збой так доўга не ўдаецца лакалізаваць.

Статычны запіс таксама застаецца ўсталяваным пасля знікнення шляху пад ім. Калі платформа не дае адсочвання, маршрут працягвае паказваць на наступны хоп, які ўжо не перасылае, і трафік знікае замест пераключэння. Гэтая цішыня і ёсць цана, якую вы прымаеце, выбіраючы просты варыянт.

Запішыце метад адсочвання побач з кожным маршрутам, адзначце, якія збоі ён пакрывае, і трымайце спіс разам з канфігурацыяй тунеля. Інакш наступны перабой выявіць карыстальнік, а не сетка, і гэта заўсёды даражэйшае выяўленне.

Колькі насамрэч каштуе дынамічная маршрутызацыя

Пратакол абвяшчае новыя прэфіксы, адклікае недасягальныя і выказвае перавагу паміж шляхамі. Гэта сапраўды карысна, калі некалькі пляцовак або рэзервовыя тунелі інакш патрабавалі б узгодненых праўкаў пры кожнай змене. Гэта таксама прычына, чаму пратакол можа здзівіць вас у найгоршы момант. Кожнае з гэтых дзеянняў — змена стану, якую зрабілі не вы асабіста.

Ён стварае два станы, якія могуць разыходзіцца. Тунель можа быць падняты, пакуль сесія маршрутызацыі апушчана, а сесія можа быць паднята, пакуль яе аб'явы апускаюць падсетку, патрэбную праграме. Абодва выглядаюць як сетка, якая працуе напалову, і ні адзін не бачны са старонкі стану тунеля.

Таму фільтры і палітыка становяцца часткай дызайну, а не позняй думкай. Пратакол, які абвяшчае ўсё, рана ці позна абвесціць нешта няправільнае, і няправільны прэфікс падарожнічае хутчэй за чалавека, які можа яго выправіць. Напішыце фільтры да ўключэння першай сесіі, каб першая аб'ява ўжо была наўмыснай.

Кіруйце тым, што можа сказаць сесія маршрутызацыі

Вызначце дазволены спіс прэфіксаў для кожнага партнёра і прымяняйце яго на ўваходзе, бо зыходны фільтр не можа перашкодзіць партнёру даслаць вам маршрут па змаўчанні. Маршруты па змаўчанні і агрэгаты — гэта дарагія памылкі тут: яны могуць ціха замяніць незвязаныя шляхі адным вывучаным запісам, які выглядае законным. Адхіляйце іх відавочна, калі дызайн сапраўды іх не жадае.

Запішыце пляцоўку-ўладальніка побач з кожнай сеткай да запуску першай сесіі, бо гэта адлюстраванне — крыніца спісу фільтраў, а не ўпрыгожванне дакументацыі. Без яго той, хто правіць фільтр, мусіць здагадвацца, якая пляцоўка павінна абвяшчаць прэфікс.

Пераразмеркаванне паміж двума пратаколамі — гэта месца, дзе пачынаюцца петлі, і дзе той самы прэфікс прыходзіць двойчы з атрыбутамі, якія не параўноўваюцца чыста. Трымайце пераразмеркаванне па-за дызайнам, пакуль пэўная патрэба не прымусіць, і калі яно мусіць быць, пазначайце і фільтруйце маршруты на мяжы.

Тунельныя інтэрфейсы на аснове маршрутаў робяць дынамічную маршрутызацыю прасцейшай для адлюстравання, бо тунель становіцца інтэрфейсам з маршрутамі замест палітыкі, што супастаўляе селектары. Гэта не здымае пытанне пра абсяг партнёра: селектары IPsec усё яшчэ павінны дазваляць трафік, які вы збіраецеся маршрутызаваць.

Праверце шлях збою, а не шчаслівы шлях

Што б вы ні абралі, атульце адну знешнюю лінію і пацвердзіце, што трафік перамяшчаецца або што ён адмаўляе так, як вы задакументавалі. Дызайн, правераны толькі з двума здаровымі шляхамі, — гэта дызайн, які не правяраўся зусім. Змерце час выяўлення, пакуль вы там, бо лік, які вы змералі, — гэта лік, які адчуюць карыстальнікі.

Затым пацвердзіце зваротны шлях асобна, бо асіметрычная маршрутызацыя праз VPN — звычайная справа і незаўважная, пакуль прылада са станам не скіне адказы. Паток, які працуе ў адным кірунку, даказвае толькі палову шляху.

Парадак працы: палічыце прэфіксы, вырашыце, як выяўляць збоі, праверце, хто можа абслугоўваць пратакол, кіруйце тым, што абвяшчаецца, затым праверце адзін перабой ад пачатку да канца. Кожны крок дае факт, патрэбны наступнаму.