Canvieu de proveïdor sense renumerar les adreces VPN del lloc

Una branca canvia de proveïdor d'internet i el servidor de fitxers conserva la seva adreça. Aquest resultat és normal en una VPN de lloc encaminada i sorprenent per a qui assumeix que l'adreça del punt final del túnel és l'adreça de l'aplicació. Les dues viuen en capes diferents del disseny i només una s'ha mogut. Tractar-les com una sola és com una migració de proveïdor es converteix en un projecte de renumeració.

Dos plans d'adreces que es mouen independentment

El pla interior descriu les adreces privades que fan servir les aplicacions: el servidor de la branca a 10.55.8.20, el prefix de la seu central que hi encamina i la ruta de tornada. El pla exterior descriu com es troben dues passarel·les: adreces de parell, ports d'escolta i el camí per internet.

Un canvi de proveïdor toca el pla exterior. Per si sol, no obliga a canviar el pla interior.

Mantenir els dos inventaris separats és la raó pràctica per executar una superposició fins i tot quan l'aplicació ja xifra el seu propi trànsit. La superposició us dona una topologia interior estable que sobreviu a les fluctuacions exteriors. L'aplicació conserva la seva adreça, les seves regles de tallafoc i els seus registres DNS. Només canvien les entrades de transport, i això és una revisió molt més petita.

El túnel exterior porta la conversa interior

En un túnel de passarel·la a passarel·la, la capçalera IP exterior adreça les dues passarel·les. La capçalera interior encara nomena els punts finals reals de l'aplicació. La descripció de passarel·la a passarel·la de l'RFC 7296 ho tracta com a encaminament ordinari que lliura trànsit a través dels punts finals del túnel.

Per això el servidor de la branca pot conservar 10.55.8.20 mentre l'adreça pública de la passarel·la canvia. El paquet interior no conté gens l'adreça del proveïdor.

La separació és una propietat del disseny, no una garantia automàtica. Si l'enllaç de substitució no pot establir el túnel admès, o les rutes interiors no es reinstal·len, l'aplicació perd el camí encara que la seva adreça no canviï.

El trasllat de proveïdor encara té una llista de verificació

La llista exterior té cinc entrades: l'adreça del parell o el nom mantingut, l'escoltador i qualsevol filtratge aigües amunt, la traducció al camí, la identitat esperada del parell i els paràmetres permesos de l'altra passarel·la. Cada una pot fallar sola. Mantingueu un camí de recuperació separat mentre canvieu l'enllaç que porta l'administració. Tallar l'accés remot durant un canvi d'enllaç és una caiguda que us heu causat vosaltres mateixos.

Després, comproveu el prefix de la branca, la ruta en tots dos sentits, la política de protecció i un flux real d'aplicació. Un túnel acabat d'autenticar no arregla una ruta que apunta a la subxarxa privada antiga.

El solapament d'adreces amb un altre lloc connectat és un problema de planificació a part. El canvi de proveïdor no el crea, però una migració sol ser quan surt a la llum.

Què no sobreviu: origen públic i sessions

Una adreça privada estable de servidor no és un origen públic estable. Si la navegació surt directament pel nou proveïdor, els llocs web veuen la nova adreça d'enfront del proveïdor.

Mantenir aquella adreça estable requereix un disseny de sortida deliberat, amb la seva pròpia disponibilitat i política. No ve gratis amb el túnel.

Les sessions establertes tampoc no sobreviuen a un canvi de camí. El túnel es pot restablir en segons i tot i així trencar connexions de llarga durada lligades al camí antic. Planifiqueu el canvi per a una finestra on les reconnexions siguin acceptables. No afirmeu que una migració serà invisible si no heu provat els clients concrets i els seus temps d'espera.

Verifiqueu el trasllat amb quatre comprovacions

Després del canvi, verifiqueu quatre coses per ordre: el túnel està establert amb el parell previst, la ruta interior cap al prefix de la branca existeix, la política permet el flux de l'aplicació i l'aplicació respon. Cada una té la seva comanda.

En una passarel·la Linux, aquestes tres cobreixen el mig d'aquella llista:

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

Manteniu les adreces de transport en un inventari i les adreces d'aplicació en un altre. Actualitzeu només les entrades que s'han mogut de debò. Renumerar dependències internes perquè l'adreça exterior del túnel ha canviat és feina evitable.