Смяна на доставчик без преномериране на адресите на сайтовия VPN

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

Два плана за адреси, които се движат независимо

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

Смяната на доставчик засяга външния план. Тя сама по себе си не изисква промяна на вътрешния план.

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

Външният тунел носи вътрешния разговор

При тунел шлюз към шлюз външната IP заглавка адресира двата шлюза. Вътрешната заглавка все още назовава действителните крайни точки на приложението. Описанието шлюз към шлюз в RFC 7296 третира това като обикновено маршрутизиране, което доставя трафик през крайните точки на тунела.

Затова сървърът на клона може да запази 10.55.8.20, докато публичният адрес на шлюза се променя. Вътрешният пакет изобщо не съдържа адреса на доставчика.

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

Преместването на доставчика все още има контролен списък

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

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

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

Какво не оцелява: публичен източник и сесии

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

Задържането на този адрес стабилен изисква обмислен дизайн на изходящия трафик със собствена наличност и политика. Той не идва безплатно с тунела.

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

Провери преместването с четири проверки

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

На Linux шлюз тези три покриват средата на този списък:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

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