Једна филијала мења интернет провајдера, а датотечни сервер задржава своју адресу. Тај исход је нормалан код рутираног VPN-а локације и изненађујући за свакога ко претпостави да је адреса крајње тачке тунела адреса апликације. Њих двоје живе у различитим слојевима дизајна, а померио се само један. Третирати их као једно је начин на који миграција провајдера постаје пројекат пренумерисања.

Два плана адреса који се крећу независно

Унутрашњи план описује приватне адресе које апликације користе: сервер филијале на 10.55.8.20, префикс централе који рутира ка њему и повратну руту. Спољашњи план описује како два гејтвеја долазе један до другог: адресе партнера, портове за слушање и пут кроз интернет.

Промена провајдера дотиче спољашњи план. Она сама по себи не захтева промену унутрашњег плана.

Држати два инвентара одвојено практичан је разлог за покретање overlay-а чак и када апликација већ шифрује сопствени саобраћај. Overlay вам даје стабилну унутрашњу топологију која преживљава спољашње промене. Апликација задржава своју адресу, правила заштитног зида и 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

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

Повезани чланци