Cambiar la dirección de peer de IPsec en un ASA sin romper el túnel
Mover una dirección de peer toca la lista de candidatos, la coincidencia de perfil, la red subyacente y las sesiones activas. Recorra la lista de comprobación en orden.
Un cambio de dirección de peer parece una línea y se comporta como una migración. Lo que realmente se mueve es un conjunto de objetos: la lista de peers candidatos del crypto map, el perfil o la asignación de autenticación que identifica el extremo remoto, la red subyacente que llega hasta él, y las asociaciones activas construidas a partir de los valores antiguos. Trate la edición de la configuración como el último paso de ese conjunto, no el primero.
1. Registre el estado actual antes de tocar nada
Empiece por la lista completa de candidatos de la entrada de crypto map correspondiente, en orden, no solo por la dirección que cree que está en uso. El orden importa porque es lo que el dispositivo prueba realmente.
Captúrela con show run crypto map y lea la entrada efectiva con show crypto map, y guarde ambas salidas junto al nuevo valor previsto. Anote también qué peer eligió cada asociación existente mientras está ahí.
Haga lo mismo con la capa de sesiones, usando show vpn-sessiondb l2l y show crypto ipsec sa peer <old-address>. Esas dos salidas son su imagen previa cuando alguien pregunte por qué cayó un túnel a las 02:10.
2. Demuestre que el nuevo peer es alcanzable con la misma política
Demuestre la alcanzabilidad antes de programar el corte. Una ejecución de packet-tracer desde la interfaz interna hacia la red protegida del nuevo peer muestra si el enrutamiento, la exención de NAT y la política de acceso coinciden. Después confirme la ruta de transporte, porque IKE e IPsec necesitan UDP 500 y 4500 para atravesar cualquier filtro entre las puertas de enlace. Un ping correcto no demuestra nada de eso por sí solo.
Si la red subyacente necesita una ruta o un cambio de traducción, ese es un segundo cambio con su propio riesgo. Agrúpelo en la misma ventana o prográmelo por separado, pero decida cuál en lugar de descubrirlo a mitad del corte.
3. Mueva la asignación del perfil, no solo la dirección
La selección de peer y la selección de perfil son búsquedas distintas. Un perfil de conexión LAN-to-LAN contiene atributos generales y puede coincidir por dirección, por identidad de certificado o por nombre de grupo. Cambiar la IP no cambia qué perfil coincide cuando el perfil se basa en el sujeto de un certificado.
| Objeto | Sobre qué está indexado | Qué toca una nueva dirección de peer |
|---|---|---|
| Lista de candidatos del crypto map | Entradas de peer configuradas y su orden | A dónde envía el ASA sus paquetes iniciales |
| Perfil de conexión | Dirección, identidad de certificado o grupo | Solo los perfiles indexados por dirección |
| Prefijos protegidos | Objetos de red locales y remotos | Nada, salvo que también los cambie |
Mantenga intacto el contrato de credenciales. Un cambio de dirección no es motivo para relajar las comprobaciones de identidad ni para pegar una clave precompartida de ejemplo en un ticket.
4. Observe las sesiones activas mientras existen ambos candidatos
Mientras ambas direcciones están en la lista de candidatos, decida por escrito si la antigua es un respaldo o un resto. Una configuración que contiene ambas es válida y no demuestra nada sobre qué peer llevó la última sesión.
Borre las asociaciones de seguridad obsoletas solo con la forma limitada al peer de su versión, clear crypto ipsec sa peer <address>, y espere que los túneles afectados renegocien. Un reinicio global tumba todas las sesiones del dispositivo y no se perdonará en horario laboral.
Después pase un flujo de aplicación real desde un host protegido y confirme que la respuesta vuelve por el punto final previsto. show vpn-sessiondb l2l debería nombrar el nuevo peer para esa sesión, y los contadores de bytes deberían moverse.
5. Ciérrelo o revierta
Escriba la reversión antes del cambio: la lista de candidatos antigua, la asignación de perfil antigua y la entrada antigua de la red subyacente. Mantenga una ruta de gestión independiente hacia el ASA, porque una edición de dirección de peer que además le cuesta el acceso es una noche larga. Quite el peer obsoleto y las credenciales solo después de la aceptación y de registrar la decisión de respaldo. Confirme también que la política de acceso en las redes protegidas no se ha desviado.
La migración termina cuando el peer previsto se autentica y transporta el servicio requerido bajo la política conservada. Una dirección nueva en la configuración en ejecución es prueba de haber tecleado, no de éxito.