RRAS en una VM de Azure no es compatible: compruebe antes de diseñar

Abre el portal, implementa Windows Server 2022 en una subred y el rol Remote Access se instala sin problemas. Esa secuencia demuestra que el instalador funciona, no que Microsoft sea compatible con la configuración. Las directrices publicadas de soporte de software de servidor para máquinas virtuales de Azure incluyen RRAS entre las características de Windows Server que no son compatibles en las VM de Azure, y eso es una decisión de arquitectura, no un detalle de resolución de problemas. Un túnel que se levanta no traslada el despliegue dentro del límite de soporte.

El recorrido siguiente comienza en la página de soporte y luego avanza hacia los requisitos y las opciones de sustitución.

Empiece en la página de soporte, no en el laboratorio

Lea las directrices de soporte de VM de Azure antes de dimensionar nada. Separan productos, roles y características admitidos en lugar de tratar Windows Server como un bloque indiferenciado. Fíjese en qué fila cae realmente la carga de trabajo prevista, porque dos componentes que en la consola parecen relacionados pueden estar en filas distintas.

Escriba la cita en el documento de diseño mientras la página está abierta. El estado de soporte es un hecho con una fuente, y una revisión de diseño que no pueda citarla será rebatida por quien tenga la demostración.

Separe el soporte del sistema operativo del de roles y características

Esas mismas directrices incluyen Network Policy and Access Services entre los roles admitidos mientras enumeran RRAS por separado como no compatible. Esas dos entradas describen cosas distintas, y fusionarlas en «el acceso remoto es compatible» es como se aprueba un proyecto basándose en una mala lectura. Que el sistema operativo sea compatible no dice nada sobre una característica que tiene su propia fila.

La limitación también es más estrecha de lo que a veces se cita. Se refiere a esa característica ejecutándose dentro de una VM de Azure; no significa que una red privada no pueda conectarse a Azure, ni dice que RRAS no sea compatible en todas partes. Un laboratorio antiguo que reenvía paquetes correctamente es evidencia sobre paquetes, no sobre la declaración de soporte.

Mantenga esas dos preguntas separadas durante el resto del proyecto: funciona y es compatible. Necesitará respuestas distintas y a veces propietarios distintos para cada una.

Escriba qué debe hacer realmente el diseño

Antes de elegir una sustitución, convierta la lista de sedes en requisitos con los que se pueda medir un producto:

• Los protocolos de túnel que ya hablan los dispositivos de las sucursales, y si alguna sede necesita enrutamiento dinámico.
• Los prefijos remotos, incluido cualquier espacio de direcciones solapado que necesite traducción en lugar de enrutamiento.
• El intercambio de rutas con Azure, y quién posee cada entrada de la tabla de rutas.
• El rendimiento y el número de conexiones que debe sostener la hora más cargada.
• El comportamiento de conmutación por error que han acordado los propietarios de las sedes, no solo el que usted pueda construir.

NAT es el elemento que se pasa por alto y luego decide todo el diseño. Un dispositivo que puede establecer IPsec aún puede traducir direcciones de forma distinta al despliegue de RRAS que sustituye, lo que cambia qué ve la sucursal como direcciones de origen y qué registran sus registros.

Lleve la lista a los propietarios de la red y confírmela antes de cualquier conversación sobre productos. Los requisitos ambiguos convierten toda comparación de proveedores en una discusión de preferencias.

Evalúe las sustituciones frente a esos requisitos

Los servicios de conectividad administrados de Azure y los dispositivos virtuales de red compatibles con proveedores deben puntuarse frente a la misma lista. No suponga que ninguno de los dos es un equivalente directo de una VM con RRAS solo porque pueda terminar IPsec: el modelo de NAT y la propiedad de las rutas y el diseño de alta disponibilidad deciden cómo se conectan las sedes existentes y adónde vuelven sus respuestas. Puntúe cada candidato sobre el papel frente a la lista y anote qué requisitos incumple, porque esa nota es lo que hace revisable la elección más adelante.

Un balanceador de carga delante de dos VM de dispositivo no es alta disponibilidad por sí mismo. Proporciona un front-end, no un estado de túnel sincronizado, y una conmutación por error que deja caer todas las sesiones es una decisión de diseño que alguien debe tomar a propósito. Pregunte al proveedor del dispositivo cuál es el patrón de alta disponibilidad admitido y si coincide con la disponibilidad prometida a las sedes. Pruebe la conmutación por error antes de que esas sedes dependan de ella, y trate cada sesión perdida como un hallazgo y no como una sorpresa.

Donde el requisito es realmente simple — una sede, un prefijo, sin solapamiento — un servicio administrado suele ganar en coste operativo. Donde la traducción y el enrutamiento dinámico están ambos en juego, la vía del dispositivo puede ser la única adecuada, y esa es una razón para planificar una migración más larga en lugar de conservar la VM no compatible.

Si ya hay una VM con RRAS en funcionamiento

El descubrimiento no es una razón para eliminarla. Planifique el cambio en torno a las dependencias que esa VM ha acumulado: rutas de las que dependen otras subredes, reglas de NAT que ocultan direcciones de origen y todo lo que la supervisión ha aprendido a esperar de su dirección. Conserve las rutas necesarias y una ruta de recuperación probada mientras el destino compatible se diseña y valida en paralelo.

Mantenga la soportabilidad y el diagnóstico técnico como hallazgos separados en todo momento. Una disposición no compatible también puede tener un error de enrutamiento corriente, y corregir ese error no cambia su estado de soporte. Ambas afirmaciones pertenecen al informe, y ninguna anula a la otra.

Cierre el recorrido registrando la cita de soporte, la lista de requisitos, la sustitución elegida y el orden de migración. Esos cuatro elementos son lo primero que pedirá un auditor o un nuevo miembro del equipo.