Пребацивање на резерву код VPN-а: када повратни пут остане у старом тунелу

Резервни тунел се подиже, примарни пада, а апликација и даље прелази временско ограничење. На обе локације стање тунела изгледа здраво, и управо то збуњује. Пребацивање које премешта захтеве на резерву, али оставља одговоре на старом путу, није пребацивање. Упутство испод проверава повратни пут, не само руковање.

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

Забележите руте обе локације пре теста

За сваки заштићени префикс запишите примарну руту, резервну руту и предност која бира између њих. Укључите LAN пролаз иза сваке крајње тачке VPN-а, јер крајња тачка ретко је последњи скок.

Статичке метрике, праћене руте и динамичко усмеравање изражавају подобност на различите начине. Знајте које користи ваш дизајн и шта је потребно да алтернатива постане активна. Запишите услов поред руте, на пример нижу метрику док провера не пропадне.

Урадите то на обе локације. Резерва којој се даје предност на једној страни и која се игнорише на другој ствара управо ону асиметрију коју покушавате да избегнете.

Посматрајте захтеве и одговоре у свакој фази

Користите безопасну дозвољену апликацију и посматрајте три фазе: нормалну, отказ примарног пута и опоравак. У свакој фази запишите који тунел носи захтев, а који одговор. Доступна адреса партнера не доказује да заштићени пут апликације ради. Забележите на обе локације да једносмерни ток буде видљив.

Ако се захтеви помере, а одговори не, проверите руту удаљене локације ка префиксу клијента и њену предност за резерву. То је одлука о усмеравању, а не отказ тунела.

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

Управљајте стањем сесије када се пролаз промени

Заштитни зидови и NAT могу да чувају стање везе на једном пролазу, а промена пута ка другом пролазу га не преноси. Неке апликације се саме поново повезују; друге не успевају док се сесија не успостави поново. Ако резерва мења јавни извор или преведену приватну адресу, могу да реагују и правила удаљеног приступа. Документујте свако очекивано поновно покретање сесије уместо да обећавате пребацивање без прекида.

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

Тестирајте апликацију која држи дугу сесију, не само нови захтев.

Вратите примарни пут и проверите треперење

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

Одржите управљање пролазом доступним преко пута за опоравак, да вас сам тест не закључа напољу. Забележите фазе, посматране путеве и време опоравка; тај запис чини следеће пребацивање предвидивим. Белешке strongSwan о прослеђивању су корисне када су крајње тачке Linux домаћини.