IP estática en Azure P2S VPN: por qué cambia la dirección del cliente

Cada cliente de Azure point-to-site recibe una dirección del grupo cuando se autentica, y la conserva solo mientras dura esa conexión. No hay tabla de reservas, ni asignación por usuario, ni ajuste de puerta de enlace que signifique «da siempre 172.16.0.10 a esta persona». Ese único mecanismo explica los dos síntomas con los que la gente se topa más adelante: una regla de NSG que deja de coincidir con un usuario con el que antes coincidía, y una lista de permitidos que admite en silencio una máquina que nadie añadió a propósito. Sustituir la regla por una regla IP más ingeniosa no arregla ninguna de las dos cosas, porque lo que la regla nombra se reasigna según un calendario que usted no controla.

El grupo es capacidad, no identidad. Existe para que los túneles simultáneos obtengan direcciones únicas, y las recicla en el momento en que termina un arrendamiento. Cuando eso queda claro, la pregunta útil deja de ser «cómo fijo este cliente» y pasa a ser «contra qué puedo escribir una regla que la puerta de enlace no recicle».

Qué hace realmente la puerta de enlace cuando un cliente se conecta

La puerta de enlace mantiene el grupo de direcciones de cliente configurado y lo trata como una tabla de arrendamientos. Al conectar toma la siguiente dirección libre, en la práctica la más baja disponible, y la asigna al adaptador del túnel hasta que el cliente se desconecta o el arrendamiento caduca. Decide el orden, no la identidad: quien se reconecta primero tras un periodo de calma se lleva la dirección más baja que resulte libre en ese momento.

El tamaño del grupo oculta el comportamiento. Un grupo de laboratorio una o dos direcciones mayor que el número de probadores parece determinista, porque el mismo portátil tiende a reconectarse en el mismo orden cada mañana. Añada una tercera máquina, cambie el tamaño del grupo o deje una sesión conectada durante la comida, y el patrón se rompe. La dirección nunca fue estable; la cola sí.

Cualquier cambio en la configuración point-to-site también reinicia el espacio de arrendamientos. Un tipo de autenticación distinto, un grupo redimensionado, un nuevo rango de grupo o una puerta de enlace que se derriba y se reconstruye envían a los clientes a un grupo que ya no se corresponde con sus direcciones antiguas. Nada de ese cambio toca su NSG, y por eso la avería parece espontánea.

Puede verlo ocurrir en aproximadamente un minuto. Conéctese, anote la dirección del túnel en los detalles de conexión del cliente, desconéctese, conecte una segunda máquina y vuelva a conectar la primera. La dirección que recupera depende de lo que tenga la segunda máquina, y ningún ajuste del portal restaurará la anterior a demanda.

Un NSG basado en la IP del cliente es en realidad una regla sobre el orden de conexión

La regla que la gente escribe primero es la obvia: una regla de entrada en la NIC de la VM de administración o en su subred, con la dirección interna del cliente VPN como origen. Es corta, pasa la prueba el día que se escribe y falla en cuanto el grupo tiene más de una dirección libre.

De ahí surgen dos modos de fallo, y solo uno parece un error. A un usuario legítimo se le deniega porque otra persona tiene en ese momento la dirección que la regla nombra, lo que llega como una molesta incidencia de soporte. O a un usuario no previsto se le permite porque heredó una dirección en la que la regla todavía confía, lo que no llega como nada hasta que alguien audita el acceso.

Como la regla sigue al arrendamiento, la política efectiva dice «la primera persona que se conecta obtiene acceso de administración». Eso es una descripción del orden de conexión disfrazada de intención, y ninguna higiene de reglas la hace expresar intención.

El arrendamiento del cliente y la dirección de la puerta de enlace son objetos distintos

La mayor parte de la confusión viene de una palabra. La puerta de enlace tiene una IP pública comparativamente estable; los clientes tienen direcciones privadas del grupo que no lo son. Para una puerta de enlace VPN no redundante por zonas, la IP pública se asigna dinámicamente, pero sobrevive a un cambio de tamaño, a un reinicio y al mantenimiento rutinario: cambia cuando la propia puerta de enlace se elimina y se vuelve a crear. Las SKU de puerta de enlace redundantes por zonas y zonales usan una IP pública de SKU Standard, y esa asignación tiene que ser estática.

Esa estabilidad es lo que un par local necesita en su configuración, y no dice nada sobre identificar a un cliente individual. Cuando un socio pregunta qué dirección verá, la respuesta es la IP pública de la puerta de enlace en site-to-site, o un rango NAT compartido: nunca el arrendamiento del túnel de un portátil.

Los grupos de pool le dan un rango contra el que merece la pena escribir reglas

Virtual WAN point-to-site admite grupos de usuarios, y a cada grupo se le puede asignar su propio grupo de direcciones de cliente. La pertenencia se decide por identidad, así que el rango en el que cae un cliente se vuelve predecible: operaciones en un rango, contratistas en otro, y el rango es algo que una regla de firewall o de NSG puede nombrar sin adivinar.

El conjunto de reglas resultante tiene una forma que puede revisar:

• un grupo por audiencia, dimensionado para picos de sesiones simultáneas y no por número de personas;
• la pertenencia al grupo se gestiona por identidad, no editando reglas cada vez que alguien se incorpora;
• reglas de NSG o de Azure Firewall escritas contra rangos de grupo, nunca contra arrendamientos individuales;
• un concentrador o una puerta de enlace separados para audiencias que nunca deben compartir un rango.

Poner un grupo entero en la lista de permitidos es honesto pero grueso: cada cliente conectado en ese rango obtiene el mismo acceso. Es una decisión de política que merece decirse en voz alta en lugar de descubrirse durante una revisión. Todo lo que aún necesite una respuesta por persona pertenece al recurso, mediante asignaciones de rol, no al filtro de paquetes.

Cuando el despliegue no puede pasar a Virtual WAN

Muchas puertas de enlace siguen siendo puertas de enlace VPN simples, y pasar a Virtual WAN no es un cambio trivial. La respuesta práctica es mover la decisión por usuario del filtro de paquetes a algo que ya sepa quién es el usuario.

La identidad a nivel de recurso es la versión más barata. Storage, SQL y Key Vault admiten todos autenticación de Entra ID con asignaciones de rol por usuario o por grupo, así que la VPN solo tiene que demostrar alcance de red. Un host de salto con cuentas nominales hace el mismo trabajo para tareas administrativas, porque el host registra a la persona y el túnel solo transporta paquetes. Registrar a los clientes en DNS y permitir el nombre en lugar del número sube la regla un nivel. La identidad de capa de aplicación — un sujeto de certificado, una declaración de token, una pertenencia a grupo — funciona cuando lo que debe decidir es la aplicación, no la red.

Para un socio que insiste en una dirección de origen fija, la respuesta es site-to-site o ExpressRoute con un prefijo de par definido. Ellos permiten el prefijo de par, la dirección que aparece en su lado pertenece a la puerta de enlace y no cambia cuando alguien reinicia un portátil.

Revise el grupo antes de editar otra lista de permitidos

Dos propiedades del grupo causan la mayor parte del comportamiento que la gente achaca al cliente. Un grupo demasiado pequeño recicla arrendamientos con rapidez, así que las direcciones parecen moverse constantemente y cualquier regla basada en dirección parece inestable por diseño. Un grupo que se solapa con los rangos locales o con el espacio de la red virtual crea una ambigüedad de enrutamiento que ninguna regla de firewall repara.

Ponga tres cosas en una página antes de tocar una regla: el grupo point-to-site, el espacio de direcciones de la red virtual y los rangos locales. No deben solaparse, y el grupo necesita sitio para cada cliente simultáneo más un margen para reconexiones.

Después cierre el ciclo en este orden:

• Conéctese desde dos máquinas en ambos órdenes y compare las direcciones; si pueden intercambiarse, ninguna regla basada en dirección es segura.
• Compruebe si la puerta de enlace es de Virtual WAN; si lo es, use grupos de pool en lugar de reglas por dirección.
• Pregunte qué ocurre cuando una regla acierta a la persona equivocada; si la respuesta es un incidente de acceso, mueva el control a la identidad.
• Registre qué rango pertenece a qué grupo en el mismo repositorio que las definiciones de NSG.
• Vuelva a probar tras cualquier cambio de grupo, autenticación o puerta de enlace, porque esos cambios reescriben la asignación sin anunciarlo.