Превключване при отказ на VPN: когато обратният път остава в стария тунел

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

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

Запишете маршрутите на двата сайта преди теста

За всеки защитен префикс запишете основния маршрут, резервния маршрут и предпочитанието, което избира между тях. Включете LAN шлюза зад всяка крайна точка на VPN, защото крайната точка рядко е последният хоп.

Статичните метрики, проследяваните маршрути и динамичното маршрутизиране изразяват допустимостта по различен начин. Знайте кое използва вашият дизайн и какво е нужно, за да стане алтернативата активна. Запишете условието до маршрута, например по-ниска метрика, докато проверката не се провали.

Направете това в двата сайта. Резерв, който е предпочитан от едната страна и пренебрегван от другата, създава точно асиметрията, която се опитвате да избегнете.

Наблюдавайте заявките и отговорите във всяка фаза

Използвайте безвредно разрешено приложение и наблюдавайте три фази: нормална, отказ на основния път и възстановяване. Във всяка фаза записвайте кой тунел носи заявката и кой носи отговора. Достъпен адрес на партньор не доказва, че защитеният път на приложението работи. Записвайте в двата сайта, за да се види еднопосочният поток.

Ако заявките се преместят, а отговорите не, проверете маршрута на отдалечения сайт до префикса на клиента и предпочитанието му към резерва. Това е решение за маршрутизиране, а не отказ на тунела.

Възстановете първоначалното условие след теста и потвърдете, че основният път отново е предпочитан. Възстановен основен път, който не е предпочитан, е дизайн на превключване, който не е завършен.

Управлявайте състоянието на сесията при смяна на шлюза

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

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

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

Възстановете основния път и проверете за трептене

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

Поддържайте администрирането на шлюза достъпно през път за възстановяване, за да не се заключите сами с теста. Запишете фазите, наблюдаваните пътища и времето за възстановяване; именно този запис прави следващото превключване предвидимо. Бележките на strongSwan за препращане са полезни, когато крайните точки са Linux хостове.