Cambiar de provedor sen renumerar os enderezos VPN do sitio

Unha filial cambia de provedor de internet e o servidor de ficheiros conserva o seu enderezo. Ese resultado é normal nunha VPN de sitio encamiñada e sorprendente para quen supón que o enderezo do extremo do túnel é o enderezo da aplicación. Os dous viven en capas distintas do deseño e só un se moveu. Tratalos como un só é como unha migración de provedor se converte nun proxecto de renumeración.

Dous plans de enderezos que se moven de forma independente

O plan interior describe os enderezos privados que usan as aplicacións: o servidor da filial en 10.55.8.20, o prefixo da sede central que encamiña cara a el e a ruta de volta. O plan exterior describe como dúas pasarelas se alcanzan: enderezos de par, portos de escoita e o camiño por internet.

Un cambio de provedor toca o plan exterior. Por si só non esixe cambiar o plan interior.

Manter os dous inventarios separados é a razón práctica para executar unha superposición mesmo cando a aplicación xa cifra o seu propio tráfico. A superposición dálles unha topoloxía interior estable que sobrevive aos cambios exteriores. A aplicación conserva o seu enderezo, as súas regras de cortalumes e os seus rexistros DNS. Só cambian as entradas de transporte, e iso é unha revisión moito menor.

O túnel exterior leva a conversa interior

Nun túnel de pasarela a pasarela, a cabeceira IP exterior endereza as dúas pasarelas. A cabeceira interior segue nomeando os extremos reais da aplicación. A descrición de pasarela a pasarela do RFC 7296 trátao como encamiñamento ordinario que entrega tráfico a través dos extremos do túnel.

Por iso o servidor da filial pode conservar 10.55.8.20 mentres cambia o enderezo público da pasarela. O paquete interior non contén en absoluto o enderezo do provedor.

A separación é unha propiedade do deseño, non unha garantía automática. Se a ligazón de substitución non pode establecer o túnel admitido, ou as rutas interiores non se reinstalan, a aplicación perde o seu camiño aínda que o seu enderezo non cambie.

O traslado de provedor aínda ten unha lista de verificación

A lista exterior ten cinco entradas: o enderezo do par ou o nome mantido, o escoitador e calquera filtrado augas arriba, a tradución no camiño, a identidade esperada do par e os axustes permitidos da outra pasarela. Cada unha pode fallar por si soa. Manteña un camiño de recuperación aparte mentres cambia a ligazón que leva a administración. Cortar o acceso remoto durante un cambio de ligazón é unha caída que vostede mesmo provocou.

Despois, comprobe o prefixo da filial, a ruta en ambos os sentidos, a política de protección e un fluxo real de aplicación. Un túnel acabado de autenticar non arranxa unha ruta que apunta á subrede privada antiga.

O solapamento de enderezos con outro sitio conectado é un problema de planificación aparte. O cambio de provedor non o crea, pero unha migración adoita ser cando sae á luz.

O que non sobrevive: orixe pública e sesións

Un enderezo privado de servidor estable non é unha orixe pública estable. Se a navegación sae directamente polo novo provedor, os sitios ven o novo enderezo de cara ao provedor.

Manter ese enderezo estable require un deseño de saída deliberado, coa súa propia dispoñibilidade e política. Non vén gratis co túnel.

As sesións establecidas tampouco sobreviven a un cambio de camiño. O túnel pode restablecerse en segundos e aínda así romper conexións de longa duración ancoradas ao camiño antigo. Planifique o cambio para unha xanela na que as reconexións sexan aceptables. Non afirme que unha migración será invisible a non ser que se probasen os clientes concretos e os seus tempos de espera.

Verifique o traslado con catro comprobacións

Despois do cambio, verifique catro cousas por orde: o túnel está establecido co par previsto, a ruta interior cara ao prefixo da filial existe, a política permite o fluxo da aplicación e a aplicación responde. Cada unha ten o seu propio comando.

Nunha pasarela Linux, estas tres cobren a metade daquela lista:

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

Manteña os enderezos de transporte nun inventario e os de aplicación noutro. Actualice só as entradas que de verdade se moveron. Renumerar dependencias internas porque cambiou o enderezo exterior do túnel é traballo evitable.