Portátil en itinerancia: ¿nombre estable o dirección fija de oficina?

Abre la consola de administración desde casa, busca el portátil por su nombre y obtiene una dirección que dejó de ser válida cuando salió de la oficina. El instinto es trasladar la dirección de la oficina al adaptador VPN para que todo siga funcionando. Esa solución suele romper otra cosa, porque encontrar un dispositivo, permitir su tráfico y mantener viva una sesión son tres problemas distintos. Sepárelos antes de elegir un diseño de direcciones.

Separe los tres requisitos

Anote cuál de los tres falla realmente. Una persona o herramienta no encuentra el servicio; un servidor rechaza peticiones porque la dirección de origen no está en una lista; o una aplicación se cae cuando cambia la interfaz. En una hoja de cálculo parecen iguales y necesitan arreglos distintos.

La mayoría de las quejas de itinerancia caen en el primer cajón y se arreglan en DNS. Nombrar una identidad estable es barato y cubre el primer caso. Preservar la dirección es caro y solo ayuda al segundo si la política se reescribe de todos modos.

Haga que el nombre sea lo estable

Dele al portátil un nombre que resuelva a cualquier dirección alcanzable por quien llama. En este ejemplo la dirección de la oficina es 192.168.50.42, el grupo de acceso remoto entrega 10.90.0.42, y laptop17.corp.example sigue la conexión. Nada exige que coincida el último octeto, y diseñar alrededor de esa coincidencia crea trabajo sin beneficio. El registro debe apuntar a la dirección que quien llama puede usar de verdad, no a cada interfaz que el portátil haya tenido jamás.

dig +short laptop17.corp.example

Los resolutores cachean respuestas, así que el cambio no es instantáneo para todos. Los TTL cortos ayudan, y la lógica de reconexión de la aplicación ayuda más.

Cuando la lista de orígenes permitidos es la restricción real

Una lista de orígenes permitidos ve la dirección que recibe el servicio protegido, después de cualquier traducción. A menudo es una dirección de puerta de enlace o NAT y no la del propio portátil, por eso editar los registros DNS nunca repara una petición rechazada. Actualice la política para la dirección que realmente llega, o sustituya la lista por una identidad autenticada.

Capture una petición aceptada en el servidor y lea el campo de origen, y luego repita desde la ruta remota. Si las dos direcciones difieren, la política necesita dos entradas o un mecanismo distinto. Anote ambas direcciones junto con la entrada de política para que la siguiente persona vea por qué hay dos. Reutilizar una dirección que ya está activa en el mismo enlace es un problema de conflicto aparte, con sus propias reglas de detección.

Qué requiere de verdad la continuidad

La continuidad de la conexión es el requisito más difícil y el que más se malinterpreta. Una conexión TCP se identifica por ambas direcciones y ambos puertos, así que una dirección local nueva es otra conexión, diga lo que diga el DNS. Las aplicaciones que importan deben reconectarse, lo que significa una capa de sesión o un cliente que reintenta, no un truco de red. Observe una sesión durante el movimiento y la caída es inmediata, no gradual.

ss -tnp state established '( dport = :443 )'

Clonar una dirección MAC tampoco resuelve esto. La identidad del arrendamiento DHCP puede usar un identificador de cliente explícito, y dos interfaces que comparten una identidad siguen necesitando rutas coordinadas. Trate la movilidad como un diseño de aplicación y asignación, y mantenga estable la identidad del dispositivo mientras su dirección sigue a la red.