RRAS nunha VM de Azure non é compatible: comprobe antes de deseñar

Abre o portal, despregas Windows Server 2022 nunha subrede e o rol Remote Access instálase sen problemas. Esa secuencia demostra que o instalador funciona, non que Microsoft admita a configuración. As directrices publicadas de soporte de software de servidor para máquinas virtuais de Azure inclúen RRAS entre as funcións de Windows Server que non son compatibles nas VM de Azure, e iso é unha decisión de arquitectura, non un detalle de resolución de problemas. Un túnel que se levanta non traslada o despregamento dentro do límite de soporte.

O percorrido seguinte comeza na páxina de soporte e logo avanza cara aos requisitos e ás opcións de substitución.

Comece na páxina de soporte, non no laboratorio

Lea as directrices de soporte de VM de Azure antes de dimensionar nada. Separan produtos, roles e funcións admitidos en lugar de tratar Windows Server como un bloque indiferenciado. Fíxese en que fileira cae realmente a carga de traballo prevista, porque dous compoñentes que na consola parecen relacionados poden estar en fileiras distintas.

Escriba a cita no documento de deseño mentres a páxina está aberta. O estado de soporte é un feito cunha fonte, e unha revisión de deseño que non poida citarla será rebatida por quen teña a demostración.

Separe o soporte do sistema operativo do de roles e funcións

Esas mesmas directrices inclúen Network Policy and Access Services entre os roles admitidos mentres enumeran RRAS por separado como non compatible. Esas dúas entradas describen cousas distintas, e fusionalas en «o acceso remoto é compatible» é como se aproba un proxecto baseándose nunha mala lectura. Que o sistema operativo sexa compatible non di nada sobre unha función que ten a súa propia fileira.

A limitación tamén é máis estreita do que ás veces se cita. Refírese a esa función executándose dentro dunha VM de Azure; non significa que unha rede privada non poida conectarse a Azure, nin di que RRAS non sexa compatible en todas partes. Un laboratorio antigo que reenvía paquetes correctamente é evidencia sobre paquetes, non sobre a declaración de soporte.

Manteña esas dúas preguntas separadas durante o resto do proxecto: funciona e é compatible. Necesitará respostas distintas e ás veces propietarios distintos para cada unha.

Escriba que debe facer realmente o deseño

Antes de escoller unha substitución, converta a lista de sedes en requisitos cos que se poida medir un produto:

• Os protocolos de túnel que xa falan os dispositivos das sucursais, e se algunha sede necesita encamiñamento dinámico.
• Os prefixos remotos, incluído calquera espazo de enderezos solapado que necesite tradución en lugar de encamiñamento.
• O intercambio de rutas con Azure, e quen posúe cada entrada da táboa de rutas.
• O rendemento e o número de conexións que debe soster a hora máis cargada.
• O comportamento de conmutación por erro acordado polos propietarios das sedes, non só o que vostede poida construír.

NAT é o elemento que se pasa por alto e logo decide todo o deseño. Un dispositivo que pode establecer IPsec aínda pode traducir enderezos de forma distinta ao despregamento de RRAS que substitúe, o que cambia que ve a sucursal como enderezos de orixe e que rexistran os seus rexistros.

Leve a lista aos propietarios da rede e confírmea antes de calquera conversación sobre produtos. Os requisitos ambiguos converten calquera comparación de provedores nunha discusión de preferencias.

Avalíe as substitucións fronte a eses requisitos

Os servizos de conectividade xestionados de Azure e os dispositivos virtuais de rede compatibles con provedores deben puntuarse fronte á mesma lista. Non supoña que ningún dos dous é un equivalente directo dunha VM con RRAS só porque poida terminar IPsec: o modelo de NAT e a propiedade das rutas e o deseño de alta dispoñibilidade deciden como se conectan as sedes existentes e onde volven as súas respostas. Puntúe cada candidato sobre o papel fronte á lista e anote que requisitos incumpre, porque esa nota é o que fai revisable a elección máis adiante.

Un balanceador de carga diante de dúas VM de dispositivo non é alta dispoñibilidade por si mesmo. Proporciona un front-end, non un estado de túnel sincronizado, e unha conmutación por erro que deixa caer todas as sesións é unha decisión de deseño que alguén debe tomar a propósito. Pregunte ao provedor do dispositivo cal é o patrón de alta dispoñibilidade admitido e se coincide coa dispoñibilidade prometida ás sedes. Probe a conmutación por erro antes de que esas sedes dependan dela, e trate cada sesión perdida como un achado e non como unha sorpresa.

Onde o requisito é realmente simple — unha sede, un prefixo, sen solapamento — un servizo xestionado adoita gañar en custo operativo. Onde a tradución e o encamiñamento dinámico están ambos en xogo, a vía do dispositivo pode ser a única axeitada, e esa é unha razón para planificar unha migración máis longa en lugar de conservar a VM non compatible.

Se xa hai unha VM con RRAS en funcionamento

O descubrimento non é unha razón para eliminala. Planifique o cambio arredor das dependencias que esa VM acumulou: rutas das que dependen outras subredes, regras de NAT que ocultan enderezos de orixe e todo o que a monitorización aprendeu a esperar do seu enderezo. Conserve as rutas necesarias e unha vía de recuperación probada mentres o destino compatible se deseña e valida ao lado.

Manteña a soportabilidade e o diagnóstico técnico como achados separados en todo momento. Unha disposición non compatible tamén pode ter un erro de encamiñamento corrente, e corrixir ese erro non cambia o seu estado de soporte. Ambas afirmacións pertencen ao informe, e ningunha anula a outra.

Pechar o percorrido rexistrando a cita de soporte, a lista de requisitos, a substitución elixida e a orde de transición. Esas catro cousas son o primeiro que pedirá un auditor ou un novo membro do equipo.