Плаваючы рэзервовы маршрут VPN не перахоплівае: кантрольны спіс пераключэння

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

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

Назвіце збой, які павінен пакрыць рэзерв

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

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

Перастаньце патрабаваць ад дыстанцыі чаго-небудзь выяўляць

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

Для статычных маршрутаў гэта патрабуе яўнага трэкера:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

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

Прасочыце, куды ідуць уласныя пакеты зонда

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

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

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

Вызначце, што азначае вынік зонда, перш чым дадаваць мэты

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

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

Праверце зваротны шлях і гісторыю сеансаў

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

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

Выканайце паслядоўнасць прыёмкі

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

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