Díganos qué opina sobre la experiencia de descarga del PDF.

Documentación de redes
Las redes son una parte fundamental de la plataforma del Centro de datos definido por
software (SDDC), y Windows Server 2016 proporciona tecnologías nuevas y mejoradas
de redes definidas por software (SDN) para ayudarle a pasar a una solución SDDC
desarrollada por completo para su organización.

Acerca de las redes

ｅ INFORMACIÓN GENERAL

Escenarios de redes que admite Windows Server

ｈ NOVEDADES

Novedades de redes

ｉ REFERENCIA

Bibliotecas de Windows Server

Contenido retirado de Windows Server 2003/2003 R2

Red definida por software

ｅ INFORMACIÓN GENERAL

Redes definidas por software (SDN)

Controladora de red

Equilibrio de carga de software (SLB) para SDN

Puerta de enlace RAS para SDN

Virtualización de función de red

Información general de Datacenter Firewall

｀ IMPLEMENTAR

Implementar una infraestructura SDN con scripts

Tecnologías de redes

ｅ INFORMACIÓN GENERAL

BranchCache

guía de red principal

DirectAccess

Sistema de nombres de dominio (DNS)

Protocolo de configuración dinámica de host (DHCP)

Virtualización de red de Hyper-V

Conmutador virtual de Hyper-V

Administración de direcciones IP (IPAM)

Equilibrio de carga de red (NLB)

Tecnologías de redes

ｅ INFORMACIÓN GENERAL

Servidor de directivas de redes

Shell de red (Netsh)

Ajuste de rendimiento del subsistema de red

Directiva de calidad de servicio (QoS)

Servicio de nombres Internet de Windows (WINS)

Acceso remoto

Red de contenedores de Windows

Redes privadas virtuales (VPN)

ｉ REFERENCIA

Proxy de aplicación web en Windows Server 2016

Guía de implementación del Acceso remoto con VPN de Always On

Redes de alto rendimiento

ｅ INFORMACIÓN GENERAL

Redes de alto rendimiento

Escenarios de redes que admite
Windows Server
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server (Canal
semestral), Windows Server 2016

En este tema se proporciona información sobre los escenarios admitidos y no admitidos

que puede o no realizar con esta versión de Windows Server 2016.

） Importante

Para todos los escenarios de producción, use los controladores de hardware

firmados más recientes del fabricante de equipos originales (OEM) o del proveedor
de hardware independiente (IHV).

Escenarios de redes admitidos

En esta sección se incluye información sobre los escenarios de red admitidos Windows
Server 2016, e incluye las siguientes categorías de escenarios.

Escenarios de redes definidas por software (SDN)

Escenarios de plataforma de red

Escenarios de servidor DNS

IPAM escenarios con DHCP y DNS

Escenarios de formación de equipos NIC

Cambiar escenarios de teaming incrustado (SET)

Escenarios de redes definidas por software (SDN)

Puede usar la siguiente documentación para implementar escenarios de SDN con
Windows Server 2016.

Implementación de una infraestructura de red definida por software con scripts

Para obtener más información, vea Redes definidas por software (SDN).

Escenarios de controladora de red

Los escenarios de controladora de red permiten:

Implemente y administre una instancia de varios nodos de Controladora de red.

Para más información, consulte Implementación de controladora de red mediante
Windows PowerShell.

Use Controladora de red para definir la directiva de red mediante programación

mediante la API REST Northbound.

Use Controladora de red para crear y administrar redes virtuales con Virtualización
de red de Hyper-V mediante la encapsulación NVGRE o VXLAN.

Para obtener más información, consulte Controladora de red.

Escenarios de virtualización de funciones de red (NFV)

Los escenarios de NFV le permiten:

Implemente y use un equilibrador de carga de software para distribuir el tráfico de

norte a sur.

Implemente y use un equilibrador de carga de software para distribuir el tráfico de

enlace este y oeste para las redes virtuales creadas con virtualización de red de
Hyper-V.

Implemente y use un equilibrador de carga de software NAT para redes virtuales

creadas con Virtualización de red de Hyper-V.

Implementación y uso de una puerta de enlace de reenvío de nivel 3

Implementación y uso de una puerta de enlace de red privada virtual (VPN) para
túneles IPsec de sitio a sitio (IKEv2)

Implemente y use una puerta de enlace de encapsulación de enrutamiento

genérico (GRE).

Implemente y configure el enrutamiento dinámico y el enrutamiento de tránsito

entre sitios mediante Protocolo de puerta de enlace de borde (BGP).

Configure la redundancia M+N para las puertas de enlace de sitio a sitio y de nivel
3 y para el enrutamiento BGP.
 Use Controladora de red para especificar acl en redes virtuales e interfaces de red.

Para más información, consulte Virtualización de funciones de red.

Escenarios de plataforma de red

Para los escenarios de esta sección, el equipo de Windows Server Networking admite el
uso de cualquier controlador Windows Server 2016 certificado. Póngase en contacto con
el fabricante de la tarjeta de interfaz de red (NIC) para asegurarse de que tiene las
actualizaciones de controladores más recientes.

Los escenarios de plataforma de red le permiten:

Use una NIC convergente para combinar el tráfico RDMA y Ethernet mediante un
único adaptador de red.

Cree una ruta de acceso de datos de baja latencia mediante Packet Direct,
habilitado en el conmutador virtual de Hyper-V y un único adaptador de red.

Configure SET para propagar los flujos de tráfico DIRECTO y RDMA de SMB entre
hasta dos adaptadores de red.

Para más información, consulte Acceso directo a memoria remota (RDMA) y Switch
Embedded Teaming (SET).

Escenarios de conmutador virtual de Hyper-V

Los escenarios de conmutador virtual de Hyper-V permiten:

Creación de un conmutador virtual de Hyper-V con una vNIC de acceso directo a

memoria remota (RDMA)

Creación de un conmutador virtual de Hyper-V con switch embedded teaming

(SET) y vNICs RDMA

Creación de un equipo set en el conmutador virtual de Hyper-V

Administración de un equipo SET mediante Windows PowerShell comandos

Para obtener más información, vea Acceso directo a memoria remota (RDMA) y Switch
Embedded Teaming (SET)

Escenarios de servidor DNS

Los escenarios de servidor DNS permiten:

Especificar la Geo-Location de tráfico basada en directivas DNS

Configuración de DNS de cerebro dividido mediante directivas DNS

Aplicación de filtros en consultas DNS mediante directivas DNS

Configuración del equilibrio de carga de aplicaciones mediante directivas DNS

Especificar respuestas DNS inteligentes en función de la hora del día

Configuración de directivas de transferencia de zona DNS

Configuración de directivas de servidor DNS en Active Directory Domain Services

(AD DS) integradas

Configuración de la limitación de la velocidad de respuesta

Especificar la autenticación basada en DNS de entidades con nombre (DANE)

Configuración de la compatibilidad con registros desconocidos en DNS

Para obtener más información, vea los temas Novedades del cliente DNS en Windows
Server 2016 y Novedades del servidor DNS en Windows Server 2016.

IPAM escenarios con DHCP y DNS

Los IPAM escenarios le permiten:

Detectar y administrar servidores DNS y DHCP y direcciones IP en varios bosques

Active Directory federados

Use IPAM para la administración centralizada de las propiedades DNS, incluidas las
zonas y los registros de recursos.

Defina directivas de control de acceso basadas en roles granulares y delegue IPAM

usuarios o grupos de usuarios para administrar el conjunto de propiedades DNS
que especifique.

Use los comandos Windows PowerShell para IPAM para automatizar la

configuración de control de acceso para DHCP y DNS.

Para obtener más información, vea Administrar IPAM.

Escenarios de formación de equipos NIC

Los escenarios de formación de equipos NIC permiten:

Creación de un equipo NIC en una configuración compatible

Eliminación de un equipo NIC

Adición de adaptadores de red al equipo NIC en una configuración compatible

Eliminación de adaptadores de red del equipo NIC

７ Nota

En Windows Server 2016, puede usar la formación de equipos NIC en Hyper-V; sin
embargo, en algunos casos, es posible que las colas de máquinas virtuales (VMQ)
no se habiliten automáticamente en los adaptadores de red subyacentes al crear un
equipo NIC. Si esto ocurre, puede usar el siguiente comando Windows PowerShell
para asegurarse de que VMQ está habilitado en los adaptadores de miembro del
equipo NIC: Set-NetAdapterVmq -Name <NetworkAdapterName> -Enable

Cambiar escenarios de teaming incrustado (SET)

SET es una solución alternativa de formación de equipos NIC que puede usar en
entornos que incluyen Hyper-V y la pila de redes definidas por software (SDN) en
Windows Server 2016. SET integra la funcionalidad de formación de equipos de NIC en
el conmutador virtual de Hyper-V.

Para obtener más información, vea Acceso directo a memoria remota (RDMA) y Switch
Embedded Teaming (SET)

Escenarios de redes no admitidos

Los siguientes escenarios de red no se admiten en Windows Server 2016.

Redes virtuales de inquilino basadas en VLAN.

IPv6 no se admite en el subyacente ni en la superposición.

Novedades de redes
Artículo • 21/12/2022 • Tiempo de lectura: 11 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

A continuación se proporciona información sobre las tecnologías de red nuevas o

mejoradas Windows Server 2016.

Este tema contiene las siguientes secciones:

Nuevas características y tecnologías de red

Nuevas características para tecnologías de red adicionales

Nuevas características y tecnologías de red

Las redes son una parte fundamental de la plataforma del Centro de datos definido por
software (SDDC), y Windows Server 2016 proporciona tecnologías nuevas y mejoradas
de redes definidas por software (SDN) para ayudarle a pasar a una solución SDDC
desarrollada por completo para su organización.

Al administrar redes como un recurso definido por software, puede describir los
requisitos de infraestructura de una aplicación una vez y, a continuación, elegir dónde se
ejecuta la aplicación: en el entorno local o en la nube. Esta coherencia significa que las
aplicaciones ahora son más fáciles de escalar y que puede ejecutar aplicaciones sin
problemas en cualquier lugar con la misma confianza en torno a la seguridad, el
rendimiento, la calidad del servicio y la disponibilidad. Las secciones siguientes
contienen información sobre estas nuevas características y tecnologías de red.

Infraestructura de redes definidas por software

Las siguientes son tecnologías de infraestructura de SDN nuevas o mejoradas:

Controladora de red. Como novedad de Windows Server 2016, Controladora de

red proporciona un punto de automatización centralizado y programable para
administrar, configurar, supervisar y solucionar problemas de la infraestructura de
red virtual y física en el centro de datos. Con Controladora de red puede
automatizar la configuración de la infraestructura de red, en vez de tener que
configurar de forma manual los dispositivos y servicios. Para más información,
consulte Controladora de red e Implementación de redes definidas por software
mediante scripts.
Conmutador virtual de Hyper-V. El conmutador virtual de Hyper-V se ejecuta en
hosts de Hyper-V y permite crear conmutación y enrutamiento distribuidos, así
como una capa de cumplimiento de directivas alineada y compatible con Microsoft
Azure. Para obtener más información, vea Conmutador virtual de Hyper-V.

Virtualización de funciones de red (NFV). En los centros de datos definidos por

software actuales, las funciones de red que realizan los dispositivos de hardware
(como equilibradores de carga, firewalls, enrutadores, conmutadores, entre otros)
se implementan cada vez más como aplicaciones virtuales. Esta “virtualización de
las funciones de red” es la progresión natural de la virtualización de los servidores
y de la red. Las aplicaciones virtuales están emergiendo rápidamente y creando un
mercado completamente nuevo. Siguen generando interés y generando impulso
tanto en las plataformas de virtualización como en los servicios en la nube. Las
siguientes tecnologías de NFV están disponibles en Windows Server 2016.

Firewall del centro de datos. Este firewall distribuido proporciona listas de

control de acceso (ACL) pormenorizados, lo que le permite aplicar directivas de
firewall en el nivel de interfaz de máquina virtual o en el nivel de subred. Para
más información, consulte Información general sobre el firewall del centro de
datos.

Puerta de enlace RAS. Puede usar la puerta de enlace RAS para enrutar el
tráfico entre redes virtuales y redes físicas, incluidas las conexiones VPN de sitio
a sitio desde el centro de datos en la nube a los sitios remotos de los inquilinos.
En concreto, puede implementar redes privadas virtuales (VPN) de sitio a sitio
(VPN) de Internet Key Exchange versión 2 (IKEv2), VPN de nivel 3 (L3) y puertas
de enlace de encapsulación de enrutamiento genérico (GRE). Además, ahora se
admiten los grupos de puertas de enlace y la redundancia de M+N de las
puertas de enlace. y Protocolo de puerta de enlace de borde (BGP) con
funcionalidades de reflector de rutas proporcionan enrutamiento dinámico
entre redes para todos los escenarios de puerta de enlace (VPN IKEv2, VPN GRE
y VPN L3). Para más información, consulte Novedades de la puerta de enlace
rasa y la puerta de enlace de RAS para SDN.

Software Load Balancer (SLB) y traducción de direcciones de red (NAT). El

equilibrador de carga de nivel 4 de norte sur y este-oeste y NAT mejora el
rendimiento al admitir Direct Server Return, con el que el tráfico de red devuelto
puede omitir el multiplexor de equilibrio de carga. Para más información,
consulte Equilibrio de carga de software (SLB) para SDN y Virtualización de
funciones de red.
 Protocolos estandarizados. Controladora de red Transferencia de estado
representacional (REST) en su interfaz de enlace norte con notación de objetos
JavaScript carga útiles (JSON). La interfaz de controladora de red de southbound
usa Open vSwitch Database Management Protocol (OVSDB).

Tecnologías de encapsulación flexibles. Estas tecnologías funcionan en el plano

de datos y admiten la LAN extensible virtual (VxLAN) y la encapsulación de
enrutamiento genérico de virtualización de red (NVGRE). Para más información,
consulte Tunelización GRE en Windows Server 2016. Para obtener más información
sobre SDN, vea Redes definidas por software (SDN).

Aspectos básicos de la escala de la nube

Ahora están disponibles los siguientes aspectos básicos de la escala de nube:

Tarjeta de interfaz de red (NIC) convergente. La NIC convergente permite usar un

único adaptador de red para la administración, el almacenamiento habilitado para
el acceso directo a memoria remota (RDMA) y el tráfico de inquilino. Esto reduce
los gastos de capital asociados a cada servidor del centro de datos, ya que necesita
menos adaptadores de red para administrar diferentes tipos de tráfico por
servidor.

Paquete directo. Packet Direct proporciona un alto rendimiento del tráfico de red
y una infraestructura de procesamiento de paquetes de baja latencia.

Switch Embedded Teaming (SET) (Cambiar la teaming insertadas [SET]). SET es

una solución de formación de equipos NIC que se integra en el conmutador virtual
de Hyper-V. SET permite la formación de equipos de hasta ocho NIC físicas en un
único equipo SET, lo que mejora la disponibilidad y proporciona conmutación por
error. En Windows Server 2016, puede crear equipos SET restringidos al uso de
Bloque de mensajes del servidor (SMB) y RDMA. Además, puede usar los equipos
SET para distribuir el tráfico de red para virtualización de red de Hyper-V. Para más
información, consulte Acceso directo a memoria remota (RDMA) y Switch
Embedded Teaming (SET).

Nuevas características para tecnologías de red

adicionales
Esta sección contiene información sobre las nuevas características de las conocidas
tecnologías de red.
DHCP
DHCP es una norma del Grupo de trabajo en ingeniería de Internet (IETF) diseñada para
reducir la carga administrativa y la complejidad de configurar hosts en una red TCP/IP,
como una intranet privada. Al usar el servicio del servidor DHCP, el proceso de
configuración de TCP/IP en clientes DHCP es automático. Para obtener más información,
vea Novedades de DHCP.

DNS
DNS es un sistema que se usa en redes TCP/IP para nombrar equipos y servicios de red.
Los nombres de DNS ubican equipos y servicios a través de nombres descriptivos.
Cuando un usuario escriba un nombre DNS en una aplicación, los servicios DNS pueden
traducir el nombre a otra información que está asociada a dicho nombre, como una
dirección IP.

En las secciones siguientes se proporciona información sobre el cliente DNS y el servidor

DNS.

Cliente DNS
A continuación se muestra una tecnología de cliente DNS nueva o mejorada:

Enlace de servicio de cliente DNS. En Windows 10, el servicio cliente DNS ofrece
compatibilidad mejorada para equipos con más de una interfaz de red. Para
obtener más información, vea Novedades del cliente DNS en Windows Server 2016

Servidor DNS
Estas son las tecnologías de servidor DNS nuevas o mejoradas:

Directivas DNS. Puede configurar directivas DNS para especificar cómo responde
un servidor DNS a las consultas DNS. Las respuestas DNS pueden basarse en la
dirección IP del cliente (ubicación), la hora del día y otros parámetros. Las
directivas DNS permiten DNS con localización, administración del tráfico, equilibrio
de carga, DNS de cerebro dividido y otros escenarios.

Compatibilidad de Nano Server con DNS basado en archivos. Puede implementar

el servidor DNS en Windows Server 2016 en una imagen de Nano Server. Esta
opción de implementación está disponible si usa DNS basado en archivos. Al
ejecutar el servidor DNS en una imagen de Nano Server, puede ejecutar los
 servidores DNS con una superficie reducida, un arranque rápido y una aplicación
de revisiones minimizada.

７ Nota

Active Directory DNS integrado no se admite en Nano Server.

Limitación de la velocidad de respuesta (RRL). Puede habilitar la limitación de la

velocidad de respuesta en los servidores DNS. Al hacerlo, evita la posibilidad de
que sistemas malintencionados utilicen los servidores DNS para iniciar un ataque
por denegación de servicio en un cliente DNS.

Autenticación basada en DNS de entidades con nombre (DANE). Puede usar los
registros TLSA (Autenticación de seguridad de la capa de transporte) para
proporcionar información a los clientes DNS que den su nombre de dominio a qué
entidad de certificación (CA) deben esperar un certificado. Esto evita ataques de
tipo "Man in the middle" en los que alguien podría dañar la memoria caché dns
para que apunte a su propio sitio web y proporcione un certificado que emitió
desde otra entidad de certificación.

Compatibilidad con registros desconocidos. Puede agregar registros que no sean

compatibles explícitamente con el servidor DNS Windows mediante la
funcionalidad de registro desconocida.

Sugerencias raíz de IPv6. Puede usar la compatibilidad nativa con sugerencias raíz
IPV6 para realizar la resolución de nombres de Internet mediante los servidores
raíz IPV6.

Compatibilidad con Windows PowerShell mejorada. Hay Windows PowerShell

cmdlets nuevos disponibles para el servidor DNS.

Para obtener más información, vea Novedades del servidor DNS en Windows Server
2016

Tunelización de GRE
La puerta de enlace ras ahora admite túneles de encapsulación de enrutamiento
genérico (GRE) de alta disponibilidad para conexiones de sitio a sitio y redundancia
M+N de puertas de enlace. GRE es un protocolo de túnel ligero que puede encapsular
una amplia variedad de protocolos de capa de red dentro de los vínculos de punto a
punto virtuales en una conexión entre redes de protocolo de Internet. Para más
información, consulte Tunelización GRE en Windows Server 2016.
Virtualización de red de Hyper-V
Introducido en Windows Server 2012, virtualización de red de Hyper-V (HNV) permite la
virtualización de redes de clientes sobre una infraestructura de red física compartida.
Con los cambios mínimos necesarios en el tejido de red físico, HNV proporciona a los
proveedores de servicios la agilidad necesaria para implementar y migrar cargas de
trabajo de inquilinos en cualquier lugar de las tres nubes: la nube del proveedor de
servicios, la nube privada o la nube pública Microsoft Azure. Para obtener más
información, vea Novedades de virtualización de red de Hyper-V en Windows Server
2016

IPAM
IPAM proporciona funcionalidades administrativas y de supervisión altamente
personalizables para la dirección IP y la infraestructura DNS en una red de la
organización. Con IPAM, puede supervisar, auditar y administrar servidores que ejecutan
el Protocolo de configuración dinámica de host (DHCP) y el Sistema de nombres de
dominio (DNS).

Administración mejorada de direcciones IP. IPAM funcionalidades se mejoran

para escenarios como el control de subredes IPv4 /32 e IPv6 /128 y la búsqueda de
intervalos y subredes de direcciones IP gratuitas en un bloque de direcciones IP.

Administración mejorada del servicio DNS. IPAM admite el registro de recursos

DNS, el reenviador condicional y la administración de zonas DNS para servidores
DNS integrados Active Directory dominio y servidores DNS con copia de seguridad
de archivos.

Administración integrada de DNS, DHCP y dirección IP (DDI). Se habilitan varias

experiencias nuevas y operaciones integradas de administración del ciclo de vida,
como la visualización de todos los registros de recursos DNS que pertenecen a una
dirección IP, el inventario automatizado de direcciones IP basadas en registros de
recursos DNS y la administración del ciclo de vida de las direcciones IP para las
operaciones DNS y DHCP.

Compatibilidad con varios Active Directory bosque de aplicaciones. Puede usar

IPAM para administrar los servidores DNS y DHCP de varios bosques de Active
Directory cuando hay una relación de confianza de dos vías entre el bosque donde
está instalado IPAM y cada uno de los bosques remotos.

Windows PowerShell compatibilidad con roles basados en Access Control. Puede

usar Windows PowerShell para establecer ámbitos de acceso en IPAM objetos.
Para obtener más información, vea Novedades de IPAM y Administración de IPAM.

Nuevas características de HPN en Windows

Server 2019
A continuación se proporciona información sobre las tecnologías de red nuevas o
mejoradas Windows Server 2019.

VRSS dinámico y VMMQ

Se aplica a: Azure Stack HCI, versión 20H2; Windows Server 2019

En el pasado, las colas de máquinas virtuales y las colas múltiples de máquinas virtuales
permitían un rendimiento mucho mayor para las máquinas virtuales individuales, ya que
los rendimientos de red alcanzaron por primera vez la marca de 10 GbE y más.
Desafortunadamente, el planeamiento, la base de datos, el ajuste y la supervisión
necesarios para el éxito se han convertido en una gran tarea. a menudo más de lo que el
administrador de TI pretende gastar.

Windows Server 2019 mejora estas optimizaciones al distribuir y optimizar

dinámicamente el procesamiento de cargas de trabajo de red según sea necesario.
Windows Server 2019 garantiza la máxima eficacia y elimina la carga de configuración
para los administradores de TI. Para más información, consulte Requisitos de red de host
para Azure Stack HCI.

Para más información, consulte:

Blog del anuncio

Guía de validación para el equipo de PRO

Fusión de segmentos de recepción (RSC) en el vSwitch

Se aplica a: Windows Server 2022, Windows Server 2019 y Windows 10,
versión 1809

La coalescing de segmentos de recepción (RSC) en vSwitch es una mejora que une

varios segmentos TCP en un segmento mayor antes de que los datos crucen el vSwitch.
El segmento grande mejora el rendimiento de las redes para las cargas de trabajo
virtuales.
Anteriormente, se trataba de una descarga implementada por la NIC.
Desafortunadamente, esto se deshabilitó en el momento en que se adjunta el
adaptador a un conmutador virtual. RSC en vSwitch en Windows Server 2019 y
Actualización de octubre de 2018 de Windows 10 elimina esta limitación.

De forma predeterminada, RSC en vSwitch está habilitado en conmutadores virtuales

externos.

Para más información, consulte:

Blog del anuncio

Guía de validación para el equipo de PRO
Orientación de red principal para
Windows Server
Artículo • 21/09/2022 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server, Windows
Server 2016

En este tema se proporciona información general sobre la guía de red principal para
Windows Server® 2016 y contiene las secciones siguientes.

Introducción a la red principal de Windows Server

Guía de red principal para Windows Server

Introducción a la red principal de Windows

Server
Una red principal es una colección de hardware, dispositivos y software de red que
proporciona los servicios fundamentales para satisfacer las necesidades de las
tecnologías de la información (TI) de la organización.

Una red principal de Windows Server le ofrece muchas ventajas, entre las que se
incluyen las siguientes.

Protocolos principales para la conexión de red entre equipos y otros dispositivos

compatibles con Protocolo de control de transmisión/Protocolo de Internet
(TCP/IP). TCP/IP es un conjunto de protocolos estándar pensado para conectar
equipos y crear redes. TCP/IP es el software de protocolo de redes suministrado
con los sistemas operativos de Microsoft® Windows® que implementa y admite
el conjunto de protocolos TCP/IP.

Direccionamiento IP automático de servidor de Protocolo de configuración

dinámica de host (DHCP). La configuración manual de direcciones IP en todos los
equipos de la red es una tarea que consume mucho tiempo y es menos flexible
que la opción de proporcionar dinámicamente a equipos y otros dispositivos
concesiones de direcciones IP desde un servidor DHCP.

Servicio de resolución de nombres del Sistema de nombres de dominio (DNS). Con

DNS, los usuarios, equipos, aplicaciones y servicios pueden usar el nombre de
 dominio completo de un equipo o un dispositivo para encontrar la dirección IP de
dicho equipo o dispositivo.

Un bosque, que es uno o más dominios de Active Directory que comparten las
mismas definiciones de clase y atributo (esquema), información de sitio y
replicación (configuración) y capacidades de búsqueda para todo el bosque
(catálogo global).

Un dominio raíz del bosque, que es el primer dominio creado en un nuevo bosque.
Los grupos Administradores de empresas y Administradores de esquema, que son
grupos administrativos para todo el bosque, se encuentran en el dominio raíz del
bosque. Además, un dominio raíz del bosque, como los demás dominios, es una
colección de objetos de equipo, usuario y grupo definidos por el administrador en
Servicios de dominio de Active Directory (AD DS). Estos objetos comparten una
base de datos de directorios común y directivas de seguridad. También comparten
relaciones de seguridad con otros dominios, si se agregan dominios a medida que
la organización crece. El servicio de directorio también almacena datos de
directorio y permite que los equipos, aplicaciones y usuarios autorizados tengan
acceso a los datos.

Una base de datos de cuentas de usuario y equipo. El servicio de directorio

proporciona una base de datos de cuentas de usuario centralizada que le permite
crear cuentas de usuario y equipo para las personas y equipos que están
autorizados para conectarse a la red y tener acceso a recursos de red, como
aplicaciones, bases de datos, carpetas y archivos compartidos e impresoras.

Una red principal también le permite escalar la red a medida que crece la organización y
cambian los requisitos de TI. Por ejemplo, con una red principal puede agregar
dominios, subredes IP, servicios de acceso remoto, servicios inalámbricos y otras
características y roles de servidor proporcionados por Windows Server 2016.

Guía de red principal para Windows Server

En Windows Server 2016 Core Network Guide (Guía de red principal de Windows Server
2016 core) se proporcionan instrucciones sobre cómo planear e implementar los
componentes principales necesarios para una red totalmente funcional y un nuevo
dominio Active Directory® en un bosque nuevo. Por medio de esta guía, podrá
implementar equipos configurados con los siguientes componentes de servidor de
Windows:

El rol de servidor Servicios de dominio de Active Directory (AD DS)

 El rol de servidor Sistema de nombres de dominio (DNS)

El rol de servidor Protocolo de configuración dinámica de host (DHCP)

El servicio de rol Servidor de directivas de redes (NPS) del rol de servidor Servicios
de acceso y directivas de redes

Rol de servidor Servidor web (IIS)

Conexiones de Protocolo de control de transmisión/Protocolo de Internet (TCP/IP)

versión 4 en servidores individuales.

Esta guía está disponible en la siguiente ubicación.

La Guía de red principal de la biblioteca Windows Server 2016 Technical Library.

Componentes de la red principal
Artículo • 07/02/2023 • Tiempo de lectura: 84 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En esta guía se proporcionan instrucciones sobre cómo planear e implementar los

componentes principales necesarios para una red totalmente funcional y un nuevo
dominio de Active Directory en un nuevo bosque.

En esta guía se incluyen las siguientes secciones:

Acerca de esta guía

Introducción a la red principal

Planeación de una red principal

Implementación de una red principal

Recursos técnicos adicionales

Apéndices A a E

Acerca de esta guía

Esta guía está diseñada para administradores de sistema y de red que están instalando
una nueva red o que desean crear una red basada en dominios para reemplazar una red
compuesta por grupos de trabajo. El escenario de implementación que se proporciona
en esta guía es particularmente útil si prevé la necesidad de agregar más servicios y
características a la red en el futuro.

Se recomienda que revise las guías de diseño e implementación de todas las

tecnologías que se usan en este escenario de implementación para ayudarle a
determinar si esta guía proporciona los servicios y la configuración que necesita.

Una red principal es una colección de hardware, dispositivos y software de red que
proporciona los servicios fundamentales para satisfacer las necesidades de las
tecnologías de la información (TI) de la organización.

Una red principal de Windows Server le ofrece muchas ventajas, entre las que se
incluyen las siguientes.
Protocolos principales para la conexión de red entre equipos y otros dispositivos
compatibles con Protocolo de control de transmisión/Protocolo de Internet
(TCP/IP). TCP/IP es un conjunto de protocolos estándar pensado para conectar
equipos y crear redes. TCP/IP es software de protocolo de red proporcionado con
sistemas operativos Microsoft Windows que implementa y admite el conjunto de
protocolos TCP/IP.

Asignación automática de dirección IP de Protocolo de configuración dinámica de

host (DHCP) a equipos y otros dispositivos que están configurados como clientes
DHCP. La configuración manual de direcciones IP en todos los equipos de la red es
una tarea que consume mucho tiempo y es menos flexible que la opción de
proporcionar dinámicamente a equipos y otros dispositivos configuraciones de
direcciones IP usando un servidor DHCP.

Servicio de resolución de nombres del Sistema de nombres de dominio (DNS). Con

DNS, los usuarios, equipos, aplicaciones y servicios pueden usar el nombre de
dominio completo de un equipo o un dispositivo para encontrar la dirección IP de
dicho equipo o dispositivo.

Un bosque, que es uno o más dominios de Active Directory que comparten las
mismas definiciones de clase y atributo (esquema), información de sitio y
replicación (configuración) y capacidades de búsqueda para todo el bosque
(catálogo global).

Un dominio raíz del bosque, que es el primer dominio creado en un nuevo bosque.
Los grupos Administradores de empresas y Administradores de esquema, que son
grupos administrativos para todo el bosque, se encuentran en el dominio raíz del
bosque. Además, un dominio raíz del bosque, como los demás dominios, es una
colección de objetos de equipo, usuario y grupo definidos por el administrador en
Servicios de dominio de Active Directory (AD DS). Estos objetos comparten una
base de datos de directorios común y directivas de seguridad. También comparten
relaciones de seguridad con otros dominios, si se agregan dominios a medida que
la organización crece. El servicio de directorio también almacena datos de
directorio y permite que los equipos, aplicaciones y usuarios autorizados tengan
acceso a los datos.

Una base de datos de cuentas de usuario y equipo. El servicio de directorio

proporciona una base de datos de cuentas de usuario centralizada que le permite
crear cuentas de usuario y equipo para las personas y equipos que están
autorizados para conectarse a la red y tener acceso a recursos de red, como
aplicaciones, bases de datos, carpetas y archivos compartidos e impresoras.
Una red principal también le permite escalar la red a medida que crece la organización y
cambian los requisitos de TI. Por ejemplo, con una red principal puede agregar
dominios, subredes IP, servicios de acceso remoto, servicios inalámbricos y otras
características y roles de servidor proporcionados por Windows Server 2016.

Requisitos de hardware de red

Para implementar correctamente una red principal, debe implementar el hardware de
red, incluido lo siguiente:

Cableado Ethernet, Fast Ethernet o Gigabyte Ethernet

Un concentrador, conmutador de nivel 2 o 3, enrutador u otro dispositivo que

realice la función de retransmitir tráfico de red entre equipos y dispositivos.

Equipos que satisfagan los requisitos mínimos de hardware para sus respectivos
sistemas operativos de cliente y servidor.

Qué no incluye esta guía

Esta guía no proporciona instrucciones para implementar lo siguiente:

Hardware de red, como cableado, enrutadores, conmutadores y concentradores

Recursos de red adicionales, como impresoras y servidores de archivos

Conectividad de Internet

Acceso remoto

Acceso inalámbrico

Implementación de equipos cliente

７ Nota

Los equipos que ejecutan sistemas operativos cliente Windows están configurados
de forma predeterminada para recibir concesiones de direcciones IP del servidor
DHCP. Por lo tanto, no es necesaria ninguna configuración adicional de DHCP o del
protocolo de Internet versión 4 (IPv4) de los equipos cliente.

Introducción a las tecnologías

En las siguientes secciones, se ofrece información general sobre las tecnologías
necesarias que se implementan para crear una red principal.

Active Directory Domain Services

Un directorio es una estructura jerárquica que almacena información sobre objetos en la
red, como usuarios y equipos. Un servicio de directorio, como AD DS, proporciona los
métodos para almacenar datos de directorio y poner dichos datos a disposición de los
usuarios y administradores de la red. Por ejemplo, AD DS almacena información acerca
de las cuentas de usuario, que incluye nombres, direcciones de correo electrónico,
contraseñas y números de teléfono, y permite que otros usuarios autorizados de la
misma red tengan acceso a dicha información.

DNS
DNS es un protocolo de resolución de nombres para redes TCP/IP, como Internet o una
red de organización. Los servidores DNS hospedan la información que permite a los
equipos cliente y a los servicios resolver nombres DNS alfanuméricos fácilmente
reconocibles en las direcciones IP que usan los equipos para comunicarse entre ellos.

DHCP
DHCP es un estándar IP que sirve para simplificar la administración de la configuración
IP del host. El estándar DHCP ofrece el uso de servidores DHCP como una forma de
administrar la asignación dinámica de direcciones IP y demás detalles de configuración
relacionados para los clientes habilitados para DHCP de la red.

DHCP le permite usar un servidor DHCP para asignar dinámicamente una dirección IP a
un equipo o a otro dispositivo (como una impresora) de la red local. Cada equipo de
una red TCP/IP debe tener una dirección IP única, ya que la dirección IP y su máscara de
subred relacionada identifican el equipo host y la subred a la cual está conectado el
equipo. Si usa DHCP, puede estar seguro de que todos los equipos que están
configurados como clientes DHCP reciben una dirección IP que sea apropiada para la
ubicación de red y la subred; además, al usar las opciones de DHCP, como puertas de
enlace y servidores DNS predeterminados, puede proporcionar de forma automática a
los clientes de DHCP la información que necesitan para funcionar correctamente en la
red.

En redes basadas en TCP/IP, DHCP reduce la complejidad y la cantidad de trabajo

administrativo necesario para la reconfiguración de los equipos.
TCP/IP
TCP/IP en Windows Server 2016 es lo siguiente:

Software de red basado en protocolos de red estándar del sector.

Un protocolo de red corporativa enrutable que admite la conexión del equipo

basado en Windows en entornos de red de área local (LAN) y de red de área
extensa (WAN).

Tecnologías y utilidades principales para la conexión del equipo basado en

Windows con sistemas distintos con el objetivo de compartir información.

Una base para obtener acceso a servicios globales de Internet, como World Wide
Web y servidores FTP (Protocolo de transferencia de archivos).

Un marco cliente/servidor entre plataformas escalable y sólido.

TCP/IP proporciona utilidades de TCP/IP básicas que permiten a los equipos basados en
Windows conectarse y compartir información con otros sistemas de Microsoft y
sistemas que no son de Microsoft, incluidos:

Windows Server 2016

Windows 10

Windows Server 2012 R2

Windows 8.1

Windows Server 2012

Windows 8

Windows Server 2008 R2

Windows 7

Windows Server 2008

Windows Vista

Hosts de Internet

Sistemas Apple Macintosh

Grandes sistemas (mainframes) IBM

 Sistemas UNIX y Linux

Sistemas OpenVMS

Impresoras listas para red

Tabletas y teléfonos móviles con tecnología Ethernet cableada o inalámbrica

802.11 habilitada

Introducción a la red principal

En la siguiente ilustración se muestra la topología de una red principal de Windows
Server.

７ Nota

En esta guía también se incluyen instrucciones para agregar a la topología de red

servidores opcionales Servidor de directivas de redes (NPS) y Servidor web (IIS) a
fin de conformar la base para soluciones de acceso a red seguro, como
implementaciones cableadas e inalámbricas 802.1X que se pueden implementar
usando las guías complementarias de red principal. Para obtener más información,
vea Implementación de características opcionales para la autenticación de acceso
a redes y servicios web.

Componentes de la red principal

A continuación se detallan los componentes de una red principal.

Enrutador

En esta guía de implementación se proporcionan instrucciones para implementar una

red principal con dos subredes separadas por un enrutador con reenvío de DHCP
habilitado. Sin embargo, se puede implementar un conmutador de nivel 2 o nivel 3, o un
concentrador, según los requisitos y recursos de los que se disponga. Si implementa un
conmutador, el conmutador debe ser capaz de reenviar DHCP o debe colocar un
servidor DHCP en cada subred. Si implementa un concentrador, estará implementando
una sola subred, por lo que no será necesario habilitar el reenvío de DHCP o colocar
otro ámbito en el servidor DHCP.

Configuración de TCP/IP estática

Los servidores de esta implementación se configuran con direcciones IPv4 estáticas. Los
equipos cliente se configuran de manera predeterminada para que reciban concesiones
de direcciones IP procedentes del servidor DHCP.

Catálogo global de Active Directory Domain Services y servidor

DNS DC1

Tanto Active Directory Domain Services (AD DS) como Sistema de nombres de dominio
(DNS) están instalados en este servidor, llamado DC1, que proporciona servicios de
resolución de nombres y directorios para todos los equipos y dispositivos de la red.

Servidor DHCP DHCP1

El servidor DHCP, llamado DHCP1, se configura con un ámbito que proporciona

concesiones de direcciones del protocolo de Internet (IP) a los equipos de la subred
local. Si se configura el reenvío de DHCP en los enrutadores, también se puede
configurar el servidor DHCP con otros ámbitos para que provea concesiones de
direcciones IP a los equipos de otras subredes.

Equipos cliente

Los equipos que ejecutan sistemas operativos cliente Windows se configuran de forma
predeterminada como clientes DHCP, que obtienen automáticamente las direcciones IP
y las opciones DHCP del servidor DHCP.
Planeación de una red principal
Antes de implementar una red principal, es necesario planear los siguientes elementos.

Planear subredes

Planear la configuración básica de todos los servidores

Planear la implementación de DC1

Planear el acceso al dominio

Planear la implementación de DHCP1

Las siguientes secciones contienen información más detallada sobre cada uno de estos
elementos.

７ Nota

Para obtener ayuda para planear la implementación, consulte también el Apéndice

E - Hoja de preparación del planeamiento de red principal.

Planear subredes
En una red con protocolo TCP/IP, los enrutadores sirven para interconectar el hardware
y software usados en los distintos segmentos de la red física llamados subredes. Los
enrutadores también se usan para reenviar paquetes IP entre cada una de las subredes.
Averigüe cuál es el diseño físico de la red, incluido el número de enrutadores y subredes
necesario, antes de continuar con las instrucciones de esta guía.

Además, para configurar los servidores en la red con direcciones IP estáticas, debe
determinar el intervalo de direcciones IP que desea usar para la subred en la que están
ubicados los servidores principales de la red. En esta guía, los intervalos de direcciones
IP privadas [Link] - [Link] y [Link] - [Link] se usan como ejemplos, pero
puede usar cualquier intervalo de direcciones IP privadas que prefiera.

） Importante

Después de seleccionar los intervalos de direcciones IP que desea usar para cada
subred, asegúrese de configurar los enrutadores con una dirección IP del mismo
intervalo de direcciones IP que se usó en la subred donde está instalado el
enrutador. Por ejemplo, si el enrutador está configurado de forma predeterminada
 con la dirección IP [Link], pero está instalando el enrutador en una subred
con un intervalo de direcciones IP de [Link]/24, debe volver a configurar el
enrutador para usar una dirección IP dentro del intervalo de direcciones IP
[Link]/24.

Los siguientes intervalos de direcciones IP privadas aparecen especificados en la

solicitud de comentarios (RFC) de Internet 1918:

[Link] - [Link]

[Link] - [Link]

[Link] - [Link]

Cuando se usan los intervalos de direcciones IP privadas especificados en la RFC 1918,

no se puede conectar directamente a Internet mediante una dirección IP privada, ya que
los enrutadores del proveedor de acceso a Internet (ISP) descartan automáticamente las
solicitudes cuya procedencia o destino es una de esas direcciones. Para agregar más
adelante conectividad a Internet a la red principal, deberá contratarla con un ISP para
obtener una dirección IP pública.

） Importante

Cuando se usan direcciones IP privadas, debe usar algún tipo de proxy o servidor
de traducción de direcciones de red (NAT) para convertir los intervalos de
direcciones IP privadas de la red local en una dirección IP pública que se pueda
enrutar en Internet. La mayoría de los enrutadores proporciona servicios NAT, de
modo que seleccionar un enrutador apto para NAT debe ser bastante simple.

Para obtener más información, vea la sección Planear la implementación de DHCP1.

Planear la configuración básica de todos los servidores

Para cada servidor de la red principal, debe cambiar el nombre del equipo y asignar y
configurar una dirección IPv4 estática y otras propiedades TCP/IP para el equipo.

Planear las convenciones de nomenclatura para equipos y

dispositivos
Para mantener la coherencia en toda la red, es una buena idea usar nombres coherentes
para servidores, impresoras y demás dispositivos. Los nombres de los equipos se
pueden usar para ayudar a los usuarios y administradores a identificar con facilidad el
propósito y la ubicación del servidor, impresora u otro dispositivo. Por ejemplo, si tiene
tres servidores DNS, uno en San Francisco, uno en Los Ángeles y otro en Chicago, puede
usar elnúmero deubicación- de la función- del servidor de convención de nomenclatura:

DNS-DEN-01. Este nombre representa el servidor DNS en Denver, Colorado. Si se

agregan más servidores DNS en Denver, se puede incrementar el valor numérico
del nombre, como en DNS-DEN-02 y DNS-DEN-03.

DNS-SPAS-01. Este nombre representa el servidor DNS en South Pasadena,

California.

DNS-ORL-01. Este nombre representa el servidor DNS en Orlando, Florida.

En esta guía, la convención de nomenclatura de servidores es muy simple y consiste en

la función del servidor principal y un número. Por ejemplo, el controlador de dominio se
denomina DC1 y el servidor DHCP, DHCP1.

Se recomienda elegir una convención de nomenclatura antes de instalar la red principal

con esta guía.

Planear direcciones IP estáticas

Antes de configurar cada equipo con una dirección IP estática, debe planear las
subredes y los intervalos de direcciones IP. Además, debe determinar las direcciones IP
de los servidores DNS. Si planea instalar un enrutador que proporcione acceso a otras
redes, como subredes adicionales o Internet, debe conocer la dirección IP del enrutador,
también llamado puerta de enlace predeterminada, para la configuración de direcciones
IP estáticas.

La siguiente tabla proporciona valores de ejemplo para la configuración de direcciones

IP estáticas.

Elementos de configuración Valores de ejemplo

Dirección IP [Link]

Máscara de subred [Link]

Puerta de enlace predeterminada (dirección IP del enrutador) [Link]

Servidor DNS preferido [Link]

７ Nota
 Si piensa implementar más de un servidor DNS, también puede planear la dirección
IP del servidor DNS alternativo.

Planear la implementación de DC1

A continuación se enumeran los principales pasos de planeación necesarios previos a la
instalación de Active Directory Domain Services (AD DS) y DNS en DC1.

Planear el nombre del dominio raíz del bosque

Uno de los primeros pasos en el proceso de diseño de AD DS es determinar cuántos

bosques requiere la organización. Un bosque es el contenedor de nivel superior de
AD DS y está compuesto de uno o más dominios que comparten un esquema común y
un catálogo global. Una organización puede tener varios bosques, pero en la mayoría
de las organizaciones el diseño con un único bosque es el modelo preferido y el más
sencillo de administrar.

Cuando se crea el primer controlador de dominio en la organización, se está creando el

primer dominio (también llamado dominio raíz del bosque) y el primer bosque. Sin
embargo, antes de realizar esta acción mediante esta guía, debe determinar cuál es el
mejor nombre de dominio para la organización. En la mayoría de los casos, se usa el
nombre de la organización como nombre del dominio y, muchas veces, dicho nombre
de dominio está registrado. Si piensa implementar servidores web basados en Internet
orientados externamente para proporcionar información y servicios a sus clientes o
socios, elija un nombre de dominio que aún no esté en uso y después regístrelo para
que sea propiedad de su organización.

Planear el nivel funcional del bosque

Durante la instalación de AD DS, debe elegir el nivel funcional del bosque que desea
usar. La funcionalidad de dominio y bosque, incluida en Active Directory de
Windows Server 2003, constituye una forma de habilitar las características de Active
Directory para todo el dominio o el bosque del entorno de red. Dependiendo del
entorno, hay disponibles varios niveles de funcionalidad del dominio y del bosque.

La funcionalidad de bosque habilita características en todos los dominios del bosque.

Existen los siguientes niveles funcionales de bosque disponibles:

Windows Server 2008 . Este nivel funcional de bosque solo admite controladores
de dominio que ejecutan Windows Server 2008 y versiones posteriores del sistema
operativo Windows Server.
 Windows Server 2008 R2 . Este nivel funcional de bosque admite controladores de
dominio de Windows Server 2008 R2 y controladores de dominio que ejecutan
versiones posteriores del sistema operativo Windows Server.

Windows Server 2012 . Este nivel funcional de bosque admite Windows Server
2012 controladores de dominio y controladores de dominio que ejecutan
versiones posteriores del sistema operativo Windows Server.

Windows Server 2012 R2 . Este nivel funcional de bosque admite Windows Server
2012 controladores de dominio R2 y controladores de dominio que ejecutan
versiones posteriores del sistema operativo Windows Server.

Windows Server 2016. Este nivel funcional de bosque solo admite Windows Server
2016 controladores de dominio y controladores de dominio que ejecutan
versiones posteriores del sistema operativo Windows Server.

Si va a implementar un nuevo dominio en un nuevo bosque y todos los controladores

de dominio se ejecutarán Windows Server 2016, se recomienda configurar AD DS con el
nivel funcional del bosque de Windows Server 2016 durante la instalación de AD DS.

） Importante

Tras elevar el nivel funcional del bosque, los controladores de dominio que
ejecutan sistemas operativos anteriores no podrán incorporarse al bosque. Por
ejemplo, si eleva el nivel funcional del bosque a Windows Server 2016, los
controladores de dominio que ejecutan Windows Server 2012 R2 o Windows Server
2008 no se pueden agregar al bosque.

En la siguiente tabla se proporcionan elementos de una configuración de ejemplo para

AD DS.

Elementos de configuración: Valores de ejemplo:

Nombre DNS completo Ejemplos:

- [Link]
- [Link]

Nivel funcional de bosque - Windows Server 2008

- Windows Server 2008 R2
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016
 Elementos de configuración: Valores de ejemplo:

Ubicación de la carpeta de bases de datos de Active Directory E:\Configuration\

Domain Services O bien, acepte la ubicación
predeterminada.

Ubicación de la carpeta de archivos de registro de Active E:\Configuration\

Directory Domain Services O bien, acepte la ubicación
predeterminada.

Ubicación de la carpeta SYSVOL de Active Directory Domain E:\Configuration\

Services O bien, acepte la ubicación
predeterminada.

Contraseña de administrador para el modo de restauración de J*p2leO4$F

directorios

Nombre del archivo de respuesta (opcional) AD DS_AnswerFile

Planear zonas DNS

En los servidores DNS principales integrados en Active Directory, se crea una zona de
búsqueda directa de forma predeterminada durante la instalación del rol Servidor DNS.
Una zona de búsqueda directa permite a los equipos y dispositivos consultar la
dirección IP de otro equipo o dispositivo a partir de su nombre DNS. Además de una
zona de búsqueda directa, se recomienda crear una zona de búsqueda DNS inversa. Con
una consulta de búsqueda DNS inversa, un equipo o dispositivo puede detectar el
nombre de otro equipo o dispositivo mediante su dirección IP. La implementación de
una zona de búsqueda inversa suele mejorar el rendimiento de DNS y aumenta
enormemente el acierto de las consultas DNS.

Cuando se crea una zona de búsqueda inversa, se configura en DNS el dominio in-
[Link], que se define en los estándares DNS y se reservó en el espacio de nombres
DNS de Internet para proporcionar una forma práctica y confiable de llevar a cabo
consultas inversas. Para crear el espacio de nombres inverso, se forman subdominios
dentro del dominio [Link], con la clasificación inversa de los números en la
notación decimal con punto de direcciones IP.

El dominio [Link] se aplica a todas las redes TCP/IP que están basadas en el
direccionamiento del protocolo de Internet versión 4 (IPv4). El Asistente para nueva
zona da por supuesto que se usa este dominio al crear una zona de búsqueda inversa.

Al ejecutar el Asistente para nueva zona, se recomienda realizar las siguientes

selecciones:
 Elementos de configuración Valores de ejemplo

Tipo de zona Se seleccionan Zona principal y Almacenar la

zona en Active Directory

Ámbito de replicación de zona de Active Para todos los servidores DNS en este dominio
Directory

Primera página del asistente Nombre de la Zona de búsqueda inversa para IPv4
zona de búsqueda inversa

Segunda página del asistente Nombre de la ID de red = 10.0.0.

zona de búsqueda inversa

Actualizaciones dinámicas Permitir solo actualizaciones dinámicas

seguras

Planear el acceso al dominio

Para iniciar sesión en el dominio, el equipo debe ser miembro del dominio y la cuenta
de usuario se debe crear en AD DS antes del intento de inicio de sesión.

７ Nota

Los equipos individuales que ejecutan Windows cuentan con una base de datos de
cuentas de usuario de grupos y usuarios locales que se conoce como la base de
datos de cuentas de usuario del Administrador de cuentas de seguridad (SAM).
Cuando crea una cuenta de usuario en el equipo local en la base de datos SAM,
puede iniciar sesión en el equipo local, pero no en un dominio. Las cuentas de
usuario de dominio se crean con Microsoft Management Console (MMC) de
Usuarios y equipos de Active Directory en un controlador de dominio, no con
grupos o usuarios locales en el equipo local.

Después del primer inicio de sesión correcto con las credenciales de inicio de sesión del
dominio, la configuración del inicio de sesión se conserva a menos que el equipo se
quite del dominio o la configuración del inicio de sesión se modifique manualmente.

Antes de iniciar una sesión en el dominio:

Cree cuentas de usuario en Usuarios y equipos de Active Directory. Cada usuario

debe tener una cuenta de usuario de Active Directory Domain Services en Usuarios
y equipos de Active Directory. Para obtener más información, vea Crear una cuenta
de usuario en Usuarios y equipos de Active Directory.
 Compruebe que la configuración de la dirección IP sea correcta. Para unir un
equipo a un dominio, el equipo debe tener una dirección IP. En esta guía, los
servidores se configuran con direcciones IP estáticas y los equipos cliente reciben
concesiones de direcciones IP procedentes del servidor DHCP. Por este motivo, se
debe implementar el servidor DHCP antes de unir los clientes al dominio. Para
obtener más información, vea Implementar DHCP1.

Una el equipo al dominio. Todos los equipos que proporcionen recursos de red o
tengan acceso a ellos deben unirse al dominio. Para obtener más información, vea
Unir equipos servidor al dominio e iniciar sesión y Unir equipos cliente al dominio
e iniciar sesión.

Planear la implementación de DHCP1

A continuación se describen los principales pasos de planeación necesarios previos a la
instalación del rol de servidor DHCP en DHCP1.

Planear servidores DHCP y reenvío DHCP

Como los mensajes DHCP son mensajes de difusión, los enrutadores no los reenvían
entre subredes. Si tiene varias subredes y desea proporcionar el servicio DHCP para
cada subred, realice una de las acciones siguientes:

Instalar un servidor DHCP en cada subred

Configurar los enrutadores para reenviar los mensajes de difusión DHCP entre
subredes y configurar múltiples ámbitos en el servidor DHCP, un ámbito por
subred.

En la mayoría de los casos, configurar los enrutadores para reenviar mensajes de

difusión DHCP es más rentable que implementar un servidor DHCP en cada segmento
físico de la red.

Planear intervalos de direcciones IP

Cada subred debe tener su propio intervalo de direcciones IP únicas. En un servidor

DHCP, dichos intervalos se representan con ámbitos.

Un ámbito es una agrupación administrativa de direcciones IP para equipos de una

subred que usa el servicio DHCP. El administrador crea primero un ámbito para cada
subred física y, a continuación, lo usa para definir los parámetros usados por los clientes.

Un ámbito tiene las siguientes propiedades:

 Un intervalo de direcciones IP desde el que incluir o excluir las direcciones usadas
para las ofertas de concesión de servicio DHCP.

Una máscara de subred, que determina el prefijo de subred para una dirección IP
determinada.

Un nombre de ámbito asignado al crearlo.

Valores de duración de la concesión, asignados a los clientes DHCP que reciben las
direcciones IP asignadas dinámicamente.

Todas las opciones de ámbito DHCP configuradas para la asignación a clientes

DHCP (por ejemplo, dirección IP del servidor DNS y dirección IP de la puerta de
enlace predeterminada o enrutador).

Las reservas se usan opcionalmente para garantizar que un cliente DHCP reciba
siempre la misma dirección IP.

Antes de implementar los servidores, cree una lista con las subredes y los intervalos de
direcciones IP que desea usar para cada subred.

Planear máscaras de subred

Las máscaras de subred sirven para distinguir los identificadores de red de los
identificadores de host dentro de una dirección IP. Cada máscara de subred es un
número de 32 bits que usa grupos de bits consecutivos de todo unos (1) para reconocer
el identificador de red y de todo ceros (0) para reconocer las partes del identificador de
host de una dirección IP.

Por ejemplo, la máscara de subred que se usa normalmente con la dirección IP

[Link] es el siguiente número binario de 32 bits:

11111111 11111111 00000000 00000000

Este número de máscara de subred está compuesto de 16 bits de unos seguidos de

16 bits de ceros, lo que indica que las secciones del identificador de red y del
identificador de host de esta dirección IP tienen ambas 16 bits de longitud.
Normalmente, esta máscara de subred se muestra en notación decimal con puntos
como [Link].

La siguiente tabla muestra máscaras de subred para las clases de direcciones de

Internet.
 Clase de dirección Bits para la máscara de subred Máscara de subred

Clase A 11111111 00000000 00000000 00000000 [Link]

Clase B 11111111 11111111 00000000 00000000 [Link]

Clase C 11111111 11111111 11111111 00000000 [Link]

Cuando se crea un ámbito en DHCP y se escribe el intervalo de direcciones IP para el

ámbito, DHCP proporciona estos valores predeterminados para las máscaras de subred.
Por lo general, los valores de la máscara de subred predeterminados son aceptables
para la mayoría de las redes que no tienen requisitos especiales y donde cada segmento
de red IP corresponde a una sola red física.

En ciertos casos, se pueden usar máscaras de subred personalizadas para implementar

las subredes IP. Con el establecimiento de subredes IP, se puede subdividir la parte del
identificador de host predeterminada de una dirección IP para especificar subredes, que
son subdivisiones del identificador de red basado en clases original.

Mediante la personalización de la longitud de la máscara de subred, se puede reducir el

número de bits que se usan para el identificador de host real.

Para evitar problemas de direccionamiento y enrutamiento, debería asegurarse de que

todos los equipos TCP/IP de un segmento de red usan la misma máscara de subred y de
que cada equipo o dispositivo tenga una dirección IP única.

Planear intervalos de exclusión

Cuando se crea un ámbito en un servidor DHCP, se especifica un intervalo de

direcciones IP que incluye todas las direcciones IP que el servidor DHCP está autorizado
a conceder a clientes DHCP, como equipos y otros dispositivos. Si después configura
manualmente algunos servidores y otros dispositivos con direcciones IP estáticas del
mismo intervalo de direcciones IP que está usando el servidor DHCP, puede crear
accidentalmente un conflicto de dirección IP en el que usted y el servidor DHCP tienen
asignada la misma dirección IP para diferentes dispositivos.

Para solucionar este problema, puede crear un intervalo de exclusión para el ámbito
DHCP. Un intervalo de exclusión es un intervalo contiguo de direcciones IP dentro del
intervalo de direcciones IP del ámbito que el servidor DHCP no puede usar. Si crea un
intervalo de exclusión, el servidor DHCP no asigna las direcciones en ese intervalo, lo
cual le permite asignar manualmente estas direcciones sin crear un conflicto de
direcciones IP.
El servidor DHCP puede excluir direcciones IP de la distribución creando un intervalo de
exclusión para cada ámbito. Las exclusiones se deberían usar para todos los dispositivos
que están configurados con una dirección IP estática. Las direcciones excluidas deberían
incluir todas las direcciones IP asignadas manualmente a otros servidores, clientes no
DHCP, estaciones de trabajo sin disco o clientes PPP y de Enrutamiento y acceso
remoto.

Se recomienda configurar el intervalo de exclusión con direcciones adicionales en

previsión de una futura ampliación de la red. La siguiente tabla proporciona un ejemplo
de intervalo de exclusión para un ámbito con un intervalo de direcciones IP de [Link]-
[Link] y una máscara de subred de [Link].

Elementos de configuración Valores de ejemplo

Dirección IP inicial del intervalo de exclusión [Link]

Dirección IP final del intervalo de exclusión [Link]

Planear la configuración estática de TCP/IP

Algunos dispositivos, como enrutadores, servidores DHCP y servidores DNS, se deben
configurar con una dirección IP estática. Además, es posible que tenga dispositivos
adicionales, como impresoras, para los que desee asegurarse de que tengan siempre la
misma dirección IP. Reúna en una lista los dispositivos que desee configurar
estáticamente para cada subred y, a continuación, planee el intervalo de exclusión que
desea usar en el servidor DHCP para asegurarse de que el servidor DHCP no conceda la
dirección IP de un dispositivo configurado estáticamente. Un intervalo de exclusión es
una secuencia limitada de direcciones IP dentro de un ámbito que está excluida de las
ofertas del servicio DHCP. Los intervalos de exclusión garantizan que el servidor no
ofrece ninguna de las direcciones incluidas en esos intervalos a los clientes DHCP de la
red.

Por ejemplo, si el intervalo de direcciones IP para una subred va de

[Link] a [Link] y tiene diez dispositivos que desea configurar con una
dirección IP estática, puede crear un intervalo de exclusión para el ámbito 192.168.0.x
que incluya diez o más direcciones IP: de [Link] a [Link].

En este ejemplo, se usan diez de las direcciones IP excluidas para configurar servidores y
otros dispositivos con direcciones IP estáticas, y quedan cinco direcciones IP más
disponibles para la configuración estática de nuevos dispositivos que puede que quiera
agregar en el futuro. Con este intervalo de exclusión, se ha dejado al servidor DHCP con
un grupo de direcciones que oscila entre [Link] y [Link].
En la siguiente tabla se proporcionan más elementos de configuración de ejemplo para
AD DS y DNS.

Elementos de configuración Valores de ejemplo

Enlaces de conexión de red Ethernet

Configuración del servidor DNS [Link]

Dirección IP del servidor DNS preferido [Link]

Valores del cuadro de diálogo Agregar ámbito 1. Subred principal

1. Nombre del ámbito 2. [Link]
2. Dirección IP inicial 3. [Link]
3. Dirección IP final 4. [Link]
4. Máscara de subred 5. [Link]
5. Puerta de enlace predeterminada (opcional) 6. 8 días
6. Duración de la concesión

Modo de funcionamiento del servidor DHCP IPv6 no habilitado.

Implementación de una red principal

Para implementar una red principal, los pasos básicos son los siguientes:

1. Configurar todos los servidores

2. Implementar DC1

3. Unir equipos servidor al dominio e iniciar sesión

4. Implementar DHCP1

5. Unir equipos cliente al dominio e iniciar sesión

6. Implementar características opcionales para la autenticación de acceso a redes y

servicios web

７ Nota

En esta guía se proporcionan comandos de Windows PowerShell equivalentes

para la mayoría de los procedimientos. Antes de ejecutar estas cmdlets en
Windows PowerShell, reemplace los valores de ejemplo por los valores
apropiados según su implementación de red. Además, debe introducir cada
cmdlet en una sola línea en Windows PowerShell, aunque en esta guía
 podrían aparecer cmdlets individuales en varias líneas debido a las
restricciones de formato y la visualización del documento con el explorador u
otra aplicación.
Los procedimientos de esta guía no incluyen instrucciones para los casos en
los que se abre el cuadro de diálogo Control de cuentas de usuario para
solicitar permiso para continuar. Si aparece este cuadro de diálogo en
respuesta a sus acciones mientras realiza los procedimientos de esta guía,
haga clic en Continuar.

Configurar todos los servidores

Antes de instalar otras tecnologías, como Active Directory Domain Services o DHCP, es
importante configurar los siguientes elementos.

Cambiar el nombre del equipo

Configuración de una dirección IP estática

Puede usar las secciones siguientes para realizar estas acciones en cada servidor.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Cambiar el nombre del equipo

Puede usar el procedimiento de esta sección para cambiar el nombre de un equipo.

Cambiar el nombre del equipo resulta útil para situaciones en las que el sistema
operativo ha creado automáticamente un nombre de equipo que no desea usar.

７ Nota

Para llevar a cabo este procedimiento con Windows PowerShell, abra PowerShell,
escriba los siguientes cmdlets en líneas separadas y después presione ENTRAR.
También debe reemplazar nombreDeEquipo por el nombre que quiera usar.

Rename-Computer nombreDeEquipo

Restart-Computer
Para cambiar el nombre de los equipos que ejecutan Windows Server
2016, Windows Server 2012 R2 y Windows Server 2012

1. En el Administrador del servidor, haga clic en Servidor local. El panel de detalles

muestra las propiedades del equipo.

2. En Propiedades, en Nombre del equipo, haga clic en el nombre de equipo

existente. Se abre el cuadro de diálogo Propiedades del sistema. Haga clic en
Cambiar. Se abre el cuadro de diálogo Cambios en el dominio o el nombre del
equipo.

3. En el cuadro de diálogo Cambios en el dominio o el nombre del equipo, escriba

un nombre nuevo para el equipo en Nombre del equipo. Por ejemplo, si desea
asignarle el nombre DC1, escriba DC1.

4. Haga clic dos veces en Aceptar y, a continuación, haga clic en Cerrar. Si desea
reiniciar el equipo de inmediato para completar el cambio de nombre, haga clic en
Reiniciar ahora. De lo contrario, haga clic en Reiniciar más tarde.

７ Nota

Para obtener información sobre cómo cambiar el nombre de los equipos que
ejecutan otros sistemas operativos de Microsoft, consulte el Apéndice A: Cambiar
el nombre de los equipos.

Configurar una dirección IP estática

Puede usar los procedimientos de este tema para configurar las propiedades del
Protocolo de Internet versión 4 (IPv4) de una conexión de red con una dirección IP
estática para equipos que ejecutan Windows Server 2016.

７ Nota

Para llevar a cabo este procedimiento con Windows PowerShell, abra PowerShell,
escriba los siguientes cmdlets en líneas separadas y después presione ENTRAR.
También debe reemplazar los nombres de interfaz y las direcciones IP de este
ejemplo por los valores que quiera usar para configurar el equipo.

New-NetIPAddress -IPAddress [Link] -InterfaceAlias "Ethernet" -

DefaultGateway [Link] -AddressFamily IPv4 -PrefixLength 24
 Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses

[Link]

Para configurar una dirección IP estática en equipos que ejecutan

Windows Server 2016, Windows Server 2012 R2 y Windows Server 2012

1. En la barra de tareas, haga clic con el botón secundario en el icono Red y después
haga clic en Abrir el Centro de redes y recursos compartidos.

2. En Centro de redes y recursos compartidos, haga clic en Cambiar configuración

del adaptador. Se abre la carpeta Conexiones de red y muestra las conexiones de
red disponibles.

3. En Conexiones de red, haga clic con el botón secundario en la conexión que desea
configurar y, a continuación, haga clic en Propiedades. Se abre el cuadro de
diálogo Propiedades de la conexión de red.

4. En el cuadro de diálogo Propiedades de la conexión de red, en Esta conexión usa

los siguientes elementos, seleccione Protocolo de Internet versión 4 (TCP/IPv4) y,
a continuación, haga clic en Propiedades. Se abre el cuadro de diálogo
Propiedades de protocolo de Internet versión 4 (TCP/IPv4).

5. En Propiedades de protocolo de Internet versión 4 (TCP/IPv4), en la pestaña

General, haga clic en Usar la siguiente dirección IP. En Dirección IP, escriba la
dirección IP que desea usar.

6. Presione el tabulador para colocar el cursor en Máscara de subred. Se escribe

automáticamente un valor predeterminado para la máscara de subred. Acepte la
máscara de subred predeterminada o escriba la máscara de subred que quiera
usar.

7. En Puerta de enlace predeterminada, escriba la dirección IP de la puerta de enlace

predeterminada.

７ Nota

Puerta de enlace predeterminada se debe configurar con la misma dirección

IP que use en la interfaz de red de área local (LAN) del enrutador. Por
ejemplo, si tiene un enrutador conectado a una red de área extensa (como
Internet) y a la red LAN, configure la interfaz LAN con la misma dirección IP
que vaya a especificar después como la puerta de enlace predeterminada. En
otro ejemplo, si tiene un enrutador que está conectado a dos redes LAN,
 donde la LAN A usa el intervalo de direcciones [Link]/24 y LAN B usa el
intervalo de direcciones [Link]/24, configure la dirección IP del
enrutador de la LAN A con una dirección de ese intervalo de direcciones (por
ejemplo, [Link]). Además, en el ámbito DHCP para este intervalo de
direcciones, configure la puerta de enlace predeterminada con la dirección IP
[Link]. En cuanto a la LAN B, configure su interfaz de enrutador con una
dirección de ese intervalo de direcciones (como [Link]) y después
configure el ámbito [Link]/24 de la LAN B con un valor de puerta de
enlace predeterminada de [Link].

8. En Servidor DNS preferido, escriba la dirección IP del servidor DNS. Si tiene

previsto usar el equipo local como servidor DNS preferido, escriba la dirección IP
de ese equipo.

9. En Servidor DNS alternativo, escriba la dirección IP del servidor DNS alternativo si

lo hay. Si tiene previsto usar el equipo local como servidor DNS alternativo, escriba
la dirección IP de ese equipo.

10. Haga clic en Aceptary, a continuación, en Cerrar.

７ Nota

Para obtener información sobre cómo configurar una dirección IP estática en

equipos que ejecutan otros sistemas operativos de Microsoft, consulte el Apéndice
B: Configuración de direcciones IP estáticas.

Implementar DC1
Para implementar DC1, que es el equipo que ejecuta Servicios de directorio de Active
Directory (AD DS) y DNS, debe realizar estos pasos en el siguiente orden:

Completar los pasos de la sección Configurar todos los servidores

Instalar AD DS y DNS para un bosque nuevo

Crear una cuenta de usuario en Usuarios y equipos de Active Directory

Asignar pertenencia a grupos

Configurar una zona de búsqueda inversa DNS

Privilegios administrativos
Si está instalando una red pequeña y es el único administrador, se recomienda que cree
una cuenta de usuario para usted mismo y que, después, agregue su cuenta de usuario
como miembro de Administradores de empresas y de Admins. del dominio. Al hacerlo,
puede actuar como el administrador para todos los recursos de red más fácilmente.
También se recomienda que inicie sesión con esta cuenta solo cuando necesite realizar
tareas administrativas y, asimismo, que cree una cuenta de usuario separada para
realizar tareas no relacionadas con TI.

Si tiene una organización de mayor tamaño con varios administradores, consulte la

documentación de AD DS para determinar la mejor pertenencia a grupos para
empleados de la organización.

Diferencias entre las cuentas de usuario de dominio y las cuentas de usuario en el

equipo local

Una de las ventajas de una infraestructura basada en dominio es que no tiene que crear
cuentas de usuario en cada equipo del dominio. Esto ocurre si es un equipo cliente o un
servidor.

Debido a esto, no debe crear cuentas de usuario en cada equipo en el dominio. Cree
todas las cuentas de usuario en Usuarios y equipos de Active Directory y recurra a los
procedimientos anteriores para asignar pertenencia a grupos. De manera
predeterminada, todas las cuentas de usuario son miembros del grupo Usuarios del
dominio.

Todos los miembros del grupo Usuarios del dominio pueden iniciar sesión en cualquier
equipo cliente después de que se haya unido al dominio.

Puede configurar cuentas de usuario para designar los días y horas en que se permite al
usuario iniciar sesión en el equipo. Igualmente, puede designar qué equipos puede
utilizar cada usuario. Para configurar estos parámetros, abra Usuarios y equipos de
Active Directory, busque la cuenta de usuario que desea configurar y haga doble clic en
ella. En Propiedades de la cuenta de usuario, haga clic en la pestaña Cuenta y después
en Horas de inicio de sesión o Iniciar sesión en.

Instalar AD DS y DNS para un bosque nuevo

Puede usar uno de los procedimientos siguientes para instalar Servicios de dominio de
Active Directory (AD DS) y DNS y para crear un nuevo dominio en un bosque nuevo.

El primer procedimiento proporciona instrucciones sobre cómo realizar estas acciones

mediante Windows PowerShell, mientras que el segundo procedimiento muestra cómo
instalar AD DS y DNS mediante Administrador del servidor.
 ） Importante

Cuando termine de realizar los pasos descritos en este procedimiento, el equipo se

reiniciará automáticamente.

Instalación de AD DS y DNS mediante Windows PowerShell

Puede usar los siguientes comandos para instalar y configurar AD DS y DNS. Debe
reemplazar el nombre de dominio de este ejemplo por el valor que desea usar para el
dominio.

７ Nota

Para obtener más información sobre estos comandos de Windows PowerShell,

consulte los siguientes temas de referencia.

Install-WindowsFeature
Install-ADDSForest

Para poder realizar este procedimiento debe pertenecer, como mínimo, al grupo
Administradores.

Ejecute Windows PowerShell como administrador, escriba el siguiente comando y

presione ENTRAR:

PowerShell

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools`

Cuando la instalación se ha completado correctamente, se muestra el siguiente mensaje

en Windows PowerShell.

Correcto Reinicio Código de Resultado de la característica

necesario salida

True No Correcto {Servicios de dominio de Active Directory,

Grupo P...

En Windows PowerShell, escriba el siguiente comando, reemplace el texto

[Link] por el nombre de dominio y presione ENTRAR:

PowerShell
 Install-ADDSForest -DomainName "[Link]"

Durante el proceso de instalación y configuración, que está visible en la parte

superior de la ventana Windows PowerShell, aparece el siguiente mensaje.
Después de que aparezca, escriba una contraseña y presione ENTRAR.

SafeModeAdministratorPassword:

Después de escribir una contraseña y presionar ENTRAR, aparece el siguiente

mensaje de confirmación. Escriba la misma contraseña y presione ENTRAR.

Confirme SafeModeAdministratorPassword:

Cuando aparezca el siguiente símbolo del sistema, escriba la letra Y y presione

ENTRAR.

The target server will be configured as a domain controller and

restarted when this operation is complete.
Do you want to continue with this operation?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

Si lo desea, puede leer los mensajes de advertencia que se muestran durante la

instalación normal y correcta de AD DS y DNS. Estos mensajes son normales y no
son una indicación del error de instalación.

Después de que la instalación se realice correctamente, aparece un mensaje que

indica que está a punto de cerrar la sesión del equipo para que el equipo pueda
reiniciarse. Si hace clic en Cerrar, se cierra inmediatamente el equipo y el equipo se
reinicia. Si no hace clic en Cerrar, el equipo se reinicia después de un período de
tiempo predeterminado.

Una vez reiniciado el servidor, puede comprobar la instalación correcta de

Servicios de dominio de Active Directory y DNS. Abra Windows PowerShell, escriba
el siguiente comando y presione ENTRAR.

PowerShell

Get-WindowsFeature

Los resultados de este comando se muestran en Windows PowerShell y deben ser

similares a los resultados de la imagen siguiente. Para las tecnologías instaladas, los
corchetes a la izquierda del nombre de la tecnología contienen el carácter X y el valor
de Estado de instalación es Instalado.

Instalación de AD DS y DNS mediante Administrador del servidor

1. En DC1, en Administrador del servidor, haga clic en Administrar y después, haga

clic en Agregar roles y características. Se abre el Asistente para agregar roles y
características.

2. En Antes de comenzar, haga clic en Siguiente.

７ Nota

La página Antes de comenzar del Asistente para agregar roles y

características no se muestra si ha seleccionado anteriormente Omitir esta
página de forma predeterminada al ejecutar el asistente.

3. En Seleccionar tipo de instalación, asegúrese de que la opción Instalación basada

en características o en roles está seleccionada y, a continuación, haga clic en
Siguiente.

4. En Seleccionar servidor de destino, asegúrese de que la opción Seleccionar un

servidor del grupo de servidores está seleccionada. En Grupo de servidores,
asegúrese de que el equipo local está seleccionado. Haga clic en Next.

5. En Seleccionar roles de servidor, en Roles, haga clic en Active Directory Domain

Services. En ¿Desea agregar características requeridas para Active Directory
Domain Services?, haga clic en Agregar características. Haga clic en Next.

6. En Seleccionar características, haga clic en Siguiente. En Active Directory Domain

Services, repase la información proporcionada y haga clic en Siguiente.
 7. En Confirmar selecciones de instalación, haga clic en Instalar. La página Progreso
de la instalación muestra el estado durante el proceso de instalación. Cuando el
proceso finalice, haga clic en Promover este servidor a controlador de dominio
en los detalles del mensaje. Se abre el Asistente para configuración de Active
Directory Domain Services.

8. En Configuración de implementación, seleccione Agregar un nuevo bosque. En

Nombre de dominio raíz, escriba el nombre de dominio completo (FQDN) del
dominio. Por ejemplo, si el FQDN es [Link], escriba [Link].
Haga clic en Next.

9. En Opciones del controlador de dominio, en Seleccionar nivel funcional del

nuevo bosque y dominio raíz, seleccione el nivel funcional del bosque y del
dominio que quiera usar. En Especificar capacidades del controlador de dominio,
asegúrese de que Servidor de Sistema de nombres de dominio (DNS) y Catálogo
global (GC) están seleccionados. En Contraseña y Confirmar contraseña, escriba la
contraseña del Modo de restauración de servicios de directorio (DSRM) que desea
usar. Haga clic en Next.

10. En Opciones de DNS, haga clic en Siguiente.

11. En Opciones adicionales, confirme el nombre NetBIOS asignado al dominio y

cámbielo solamente si es necesario. Haga clic en Next.

12. En Rutas de acceso, en Especificar la ubicación de la base de datos de AD DS,

archivos de registro y SYSVOL, haga lo siguiente:

Acepte los valores predeterminados.

Escriba las ubicaciones de las carpetas que desea usar para Carpeta de la
base de datos, Carpeta de archivos de registro y Carpeta SYSVOL.

13. Haga clic en Next.

14. En Revisar opciones, repase las selecciones realizadas.

15. Si desea exportar la configuración a un script de Windows PowerShell, haga clic en

Ver script. El script se abre en el Bloc de notas y puede guardarlo en la ubicación
de carpeta que desee. Haga clic en Next. Las selecciones realizadas se validan en
Comprobación de requisitos previos. Cuando finalice la comprobación, haga clic
en Instalar. Cuando Windows se lo solicite, haga clic en Cerrar. El servidor se
reinicia para completar la instalación de AD DS y DNS.

16. Para comprobar la instalación correcta, vea la consola de Administrador del

servidor después de reiniciar el servidor. Tanto AD DS como DNS deben aparecer
 en el panel izquierdo, como los elementos resaltados en la imagen siguiente.

Crear una cuenta de usuario en Usuarios y equipos de Active

Directory

Puede usar este procedimiento para crear una cuenta de usuario de dominio en el
complemento Microsoft Management Console (MMC) de Usuarios y equipos de Active
Directory.

El requisito mínimo para llevar a cabo este procedimiento consiste en pertenecer a

Admins. del dominio o grupo equivalente.

７ Nota

Para llevar a cabo este procedimiento con Windows PowerShell, abra PowerShell,
escriba el siguiente cmdlet en una línea y después presione ENTRAR. También debe
reemplazar el nombre de cuenta de usuario de este ejemplo por el valor que quiera
usar.

New-ADUser -SamAccountName User1 -AccountPassword (read-host "Set user

password" -assecurestring) -name "User1" -enabled $true -PasswordNeverExpires

$true -ChangePasswordAtLogon $false

Después de presionar ENTRAR, escriba la contraseña de la cuenta de usuario. Se

crea la cuenta y, de forma predeterminada, se concede pertenencia al grupo
Usuarios del dominio.

Con el siguiente cmdlet, puede asignar otras pertenencias a grupos para la nueva
cuenta de usuario. En el siguiente ejemplo se agrega Usuario1 a los grupos Admins.
del dominio y Administradores de empresas. Antes de ejecutar este comando,
 asegúrese de cambiar el nombre de la cuenta de usuario, el nombre del dominio y
los grupos para que coincidan con sus requisitos.

Add-ADPrincipalGroupMembership -Identity

"CN=User1,CN=Users,DC=corp,DC=contoso,DC=com" -MemberOf "CN=Enterprise

Admins,CN=Users,DC=corp,DC=contoso,DC=com","CN=Domain

Admins,CN=Users,DC=corp,DC=contoso,DC=com"

Para crear una cuenta de usuario

1. En DC1, en Administrador del servidor, haga clic en Herramientas y, a

continuación, haga clic en Usuarios y equipos de Active Directory . Se abre MMC
de Usuarios y equipos de Active Directory. Haga clic en el nodo de su dominio si
no está seleccionado. Por ejemplo, si el dominio es [Link], haga clic en
[Link].

2. En el panel de detalles, haga clic con el botón secundario en la carpeta a la que

desea agregar una cuenta de usuario.

¿Dónde?

carpeta Usuarios y equipos de Active Directory/nodo/ de dominio

3. Elija Nuevo y haga clic en Usuario. Se abre el cuadro de diálogo Nuevo objeto -
Usuario .

4. En Nombre, escriba el nombre del usuario.

5. En Iniciales, escriba las iniciales del usuario.

6. En Apellidos, escriba los apellidos del usuario.

7. Modifique Nombre completo para agregar iniciales o invertir el orden del nombre
y los apellidos.

8. En Nombre de inicio de sesión de usuario, escriba el nombre correspondiente.

Haga clic en Next.

9. En Nuevo objeto: usuario, en Contraseña y en Confirmar contraseña, escriba la

contraseña del usuario y, a continuación, seleccione las opciones apropiadas para
la contraseña.

10. Haga clic en Siguiente, revise la configuración de la nueva cuenta de usuario y, a

continuación, haga clic en Finalizar.
Asignar pertenencia a grupos

Puede usar este procedimiento para agregar un usuario, equipo o grupo a un grupo en
Microsoft Management Console (MMC) de Usuarios y equipos de Active Directory.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo Admins.

del dominio o grupo equivalente.

Para asignar la pertenencia a grupos

1. En DC1, en Administrador del servidor, haga clic en Herramientas y, a

continuación, haga clic en Usuarios y equipos de Active Directory . Se abre MMC
de Usuarios y equipos de Active Directory. Haga clic en el nodo de su dominio si
no está seleccionado. Por ejemplo, si el dominio es [Link], haga clic en
[Link].

2. En el panel de detalles, haga doble clic en la carpeta que contiene el grupo al cual
desea agregar un miembro.

¿Dónde?

/ Usuarios y equipos de Active Directory carpeta del nodomain/que contiene

el grupo

3. En el panel de detalles, haga clic con el botón secundario en el objeto que desea
agregar a un grupo (como un usuario o un equipo) y, a continuación, haga clic en
Propiedades. Se abre el cuadro de diálogo Propiedades del objeto. Haga clic en la
pestaña Miembro del.

4. En la pestaña Miembro del, haga clic en Agregar.

5. En Escriba los nombres de objeto que desea seleccionar, especifique el nombre

del grupo al que desea agregar el objeto y, a continuación, haga clic en Aceptar.

6. Para asignar pertenencia a grupos para otros usuarios, grupos o equipos, repita los
pasos 4 y 5 de este procedimiento.

Configurar una zona de búsqueda inversa DNS

Puede usar este procedimiento para configurar una zona de búsqueda inversa en el
Sistema de nombres de dominio (DNS).

El requisito mínimo para llevar a cabo este procedimiento es la pertenencia al grupo

Admins. del dominio.
 ７ Nota

Para organizaciones medianas y grandes, se recomienda configurar y usar el

grupo DNSAdmins en Usuarios y equipos de Active Directory. Para obtener
más información, vea Recursos técnicos adicionales.
Para llevar a cabo este procedimiento con Windows PowerShell, abra
PowerShell, escriba el siguiente cmdlet en una línea y después presione
ENTRAR. También debe reemplazar la zona de búsqueda inversa y los
nombres de archivos de zona de este ejemplo por los valores que quiera usar.
Asegúrese de invertir el identificador de red para el nombre de zona inversa.
Por ejemplo, si el identificador de red es 192.168.0, cree el nombre de zona de
búsqueda inversa [Link].

Add-DnsServerPrimaryZone [Link] -ZoneFile [Link]

Para configurar una zona de búsqueda inversa DNS

1. En DC1, en Administrador del servidor, haga clic en Herramientas y, a

continuación, en DNS. Se abre MMC de DNS.

2. En DNS, haga doble clic en el nombre del servidor para expandir el árbol (si aún no
aparece expandido). Por ejemplo, si el nombre del servidor DNS es DC1, haga
doble clic en DC1.

3. Seleccione Zonas de búsqueda inversa, haga clic con el botón secundario en

Zonas de búsqueda inversa y, a continuación, haga clic en Zona nueva. Se abrirá
el Asistente para nueva zona.

4. En el Asistente para nueva zona, haga clic en Siguiente.

5. En Tipo de zona, seleccione Zona principal.

6. Si el servidor DNS es un controlador de dominio grabable, asegúrese de que la

opción Almacenar la zona en Active Directory está seleccionada. Haga clic en
Next.

7. En Ámbito de replicación de zona de Active Directory, seleccione Para todos los

servidores DNS que se ejecutan en controladores de dominio en este dominio, a
menos que tenga un motivo específico para elegir una opción diferente. Haga clic
en Next.
 8. En la primera página del asistente Nombre de la zona de búsqueda inversa,
seleccione Zona de búsqueda inversa para IPv4. Haga clic en Next.

9. En la segunda página del asistente Nombre de la zona de búsqueda inversa,

realice una de las siguientes acciones:

En Id. de red, escriba el identificador de red del intervalo de direcciones IP.

Por ejemplo, si el intervalo de direcciones IP oscila entre [Link] y [Link],
escriba 10.0.0.

En Nombre de la zona de búsqueda inversa, el nombre de la zona de

búsqueda inversa para IPv4 se agrega automáticamente. Haga clic en Next.

10. En Actualización dinámica, seleccione el tipo de actualizaciones dinámicas que

desea permitir. Haga clic en Next.

11. En Finalización del Asistente para nueva zona, repase sus opciones y, a
continuación, haga clic en Finalizar.

Unir equipos servidor al dominio e iniciar sesión

Una vez que se haya instalado Active Directory Domain Services (AD DS) y se haya
creado una o más cuentas de usuario con permisos para unir un equipo al dominio,
puede unir servidores de red principal al dominio e iniciar sesión en los servidores para
instalar otras tecnologías, como el Protocolo de configuración dinámica de host (DHCP).

Haga lo siguiente en todos los servidores que vaya a implementar, a excepción del que
ejecute AD DS:

1. Completar los procedimientos descritos en Configurar todos los servidores.

2. Usar las instrucciones de los dos procedimientos siguientes para unir los servidores
al dominio e iniciar sesión en ellos para realizar más tareas de implementación:

７ Nota

Para llevar a cabo este procedimiento con Windows PowerShell, abra PowerShell,
escriba el siguiente cmdlet y después presione ENTRAR. También debe reemplazar
el nombre de dominio por el nombre que quiera usar.

Add-Computer -DomainName [Link]

Cuando se le pida, escriba el nombre de usuario y la contraseña de una cuenta que

tenga permiso para unir un equipo al dominio. Para reiniciar el equipo, escriba el
 siguiente comando y presione ENTRAR.

Restart-Computer

Para unir equipos que ejecutan Windows Server 2016, Windows Server
2012 R2 y Windows Server 2012 al dominio

1. En el Administrador del servidor, haga clic en Servidor local. En el panel de

detalles, haga clic en GRUPO DE TRABAJO. Se abre el cuadro de diálogo
Propiedades del sistema.

2. En el cuadro de diálogo Propiedades del sistema, haga clic en Cambiar. Se abre el

cuadro de diálogo Cambios en el dominio o el nombre del equipo.

3. En Nombre del equipo, en Miembro del, haga clic en Dominio y, a continuación,

escriba el nombre del dominio al que quiere unirse. Por ejemplo, si el nombre del
dominio es [Link], escriba [Link].

4. Haga clic en OK. Se abre el cuadro de diálogo Seguridad de Windows.

5. En Cambios en el dominio o el nombre del equipo, escriba el nombre del usuario

en Nombre de usuario y la contraseña en Contraseña y, a continuación, haga clic
en Aceptar. Se abrirá el cuadro de diálogo Cambios en el dominio o el nombre
del equipo y le dará la bienvenida al dominio. Haga clic en OK.

6. El cuadro de diálogo Cambios en el dominio o el nombre del equipo muestra un

mensaje que le indica que debe reiniciar el equipo para aplicar los cambios. Haga
clic en OK.

7. En el cuadro de diálogo Propiedades del sistema, en la pestaña Nombre del

equipo, haga clic en Cerrar. Se abrirá el cuadro de diálogo Microsoft Windows,
que muestra un mensaje que indica de nuevo que debe reiniciar el equipo para
aplicar los cambios. Haga clic en Reiniciar ahora.

７ Nota

Para obtener información sobre cómo unir equipos que ejecutan otros sistemas
operativos de Microsoft al dominio, vea Apéndice C: Unión de equipos al dominio.

Para iniciar sesión en el dominio mediante equipos que ejecutan

Windows Server 2016
 1. Cierre la sesión del equipo o reinicie el equipo.

2. Presione Ctrl+Alt+Supr. Aparecerá la pantalla de inicio de sesión.

3. En la esquina inferior izquierda, haga clic en Otro usuario.

4. En Nombre de usuario, escriba el nombre de usuario.

5. En Contraseña, escriba la contraseña del dominio y, a continuación, haga clic en la

flecha o presione Entrar.

７ Nota

Para obtener información sobre cómo iniciar sesión en el dominio mediante

equipos que ejecutan otros sistemas operativos de Microsoft, vea Apéndice D:
Inicio de sesión en el dominio.

Implementar DHCP1
Antes de implementar este componente de la red principal, debe hacer lo siguiente:

Completar los pasos de la sección Configurar todos los servidores

Realizar los pasos de la sección Unir equipos servidor al dominio e iniciar sesión

Para implementar DHCP1, que es el equipo que ejecuta el rol de servidor del Protocolo
de configuración dinámica de host (DHCP), debe completar estos pasos en el siguiente
orden:

Instalar el Protocolo de configuración dinámica de host (DHCP)

Crear y activar un nuevo ámbito DHCP

７ Nota

Para llevar a cabo estos procedimientos con Windows PowerShell, abra PowerShell,
escriba los siguientes cmdlets en líneas separadas y después presione ENTRAR.
También debe reemplazar el nombre de ámbito, los intervalos de inicio y
finalización de direcciones IP, la máscara de subred y otros valores de este ejemplo
por los valores que quiera usar.

Install-WindowsFeature DHCP -IncludeManagementTools

 Add-DhcpServerv4Scope -name "Corpnet" -StartRange [Link] -EndRange

[Link] -SubnetMask [Link] -State Active

Add-DhcpServerv4ExclusionRange -ScopeID [Link] -StartRange [Link] -

EndRange [Link]

Set-DhcpServerv4OptionValue -OptionID 3 -Value [Link] -ScopeID [Link] -

ComputerName [Link]

Add-DhcpServerv4Scope -name "Corpnet2" -StartRange [Link] -EndRange

[Link] -SubnetMask [Link] -State Active

Add-DhcpServerv4ExclusionRange -ScopeID [Link] -StartRange [Link] -

EndRange [Link]

Set-DhcpServerv4OptionValue -OptionID 3 -Value [Link] -ScopeID [Link] -

ComputerName [Link]

Set-DhcpServerv4OptionValue -DnsDomain [Link] -DnsServer [Link]

Add-DhcpServerInDC -DnsName [Link]

Instalar el Protocolo de configuración dinámica de host (DHCP)

Puede usar este procedimiento para instalar y configurar el rol de servidor DHCP con el
Asistente para agregar roles y características.

El requisito mínimo para llevar a cabo este procedimiento consiste en pertenecer a

Admins. del dominio o grupo equivalente.

Para instalar DHCP

1. En DHCP1, en Administrador del servidor, haga clic en Administrar y, a

continuación, haga clic en Agregar roles y características. Se abre el Asistente para
agregar roles y características.

2. En Antes de comenzar, haga clic en Siguiente.

７ Nota

La página Antes de comenzar del Asistente para agregar roles y

características no se muestra si ha seleccionado anteriormente Omitir esta
 página de forma predeterminada al ejecutar el asistente.

3. En Seleccionar tipo de instalación, asegúrese de que la opción Instalación basada

en características o en roles está seleccionada y, a continuación, haga clic en
Siguiente.

4. En Seleccionar servidor de destino, asegúrese de que la opción Seleccionar un

servidor del grupo de servidores está seleccionada. En Grupo de servidores,
asegúrese de que el equipo local está seleccionado. Haga clic en Next.

5. En Seleccionar roles de servidor, en Roles, seleccione Servidor DHCP. En ¿Desea

agregar características requeridas para servidor DHCP?, haga clic en Agregar
características. Haga clic en Next.

6. En Seleccionar características, haga clic en Siguiente. En Servidor DHCP, repase la

información proporcionada y haga clic en Siguiente.

7. En Confirmar selecciones de instalación, haga clic en Reiniciar automáticamente

el servidor de destino en caso necesario. Si se le pide confirmar la selección, haga
clic en Sí y, a continuación, haga clic en Instalar. La página Progreso de la
instalación muestra el estado durante el proceso de instalación. Cuando se
complete el proceso, el mensaje "Configuración necesaria. Se muestra la
instalación correcta en ComputerName", donde NombreDeEquipo es el nombre del
equipo en el que instaló el servidor DHCP. En la ventana del mensaje, haga clic en
Completar configuración de DHCP. Se abre el Asistente posterior a la instalación
de DHCP. Haga clic en Next.

8. En Autorización, escriba las credenciales que desea usar para autorizar el servidor
DHCP en Active Directory Domain Services y, a continuación, haga clic en
Confirmar. Cuando se haya completado la autorización, haga clic en Cerrar.

Crear y activar un nuevo ámbito DHCP

Puede usar este procedimiento para crear un nuevo ámbito DHCP por medio de
Microsoft Management Console (MMC) de DHCP. Cuando complete el procedimiento,
el ámbito se activa y el intervalo de exclusión que cree impide que el servidor DHCP
conceda direcciones IP que se usen para configurar estáticamente los servidores y otros
dispositivos que requieren una dirección IP estática.

El requisito mínimo para realizar este procedimiento consiste en pertenecer a

Administradores de DHCP o grupo equivalente.
Para crear y activar un nuevo ámbito DHCP

1. En DHCP1, en Administrador del servidor, haga clic en Herramientas y, a

continuación, haga clic en DHCP. Se abre MMC de DHCP.

2. En DHCP, expanda el nombre del servidor. Por ejemplo, si el nombre del servidor
DHCP es [Link], haga clic en la flecha abajo situada junto a
[Link].

3. Debajo del nombre del servidor, haga clic con el botón derecho en IPv4 y, a
continuación, haga clic en Nuevo ámbito. Se abre el Asistente para ámbito nuevo.

4. En Éste es el Asistente para ámbito nuevo, haga clic en Siguiente.

5. En Nombre de ámbito, en Nombre, escriba un nombre para el ámbito. Por

ejemplo, escriba Subred 1.

6. En Descripción, escriba una descripción del nuevo ámbito y haga clic en Siguiente.

7. En Intervalo de direcciones IP, realice lo siguiente:

a. En Dirección IP inicial, especifique la primera dirección IP del intervalo. Por

ejemplo, escriba [Link].

b. En Dirección IP final, especifique la última dirección IP del intervalo. Por

ejemplo, escriba [Link]. Los valores de los campos Longitud y Máscara de
subred se establecen automáticamente a partir de la dirección IP que haya
especificado en Dirección IP inicial.

c. Si fuera necesario, modifique los valores de Longitud o Máscara de subred para

su esquema de direcciones.

d. Haga clic en Next.

8. En Agregar exclusiones, realice lo siguiente:

a. En Dirección IP inicial, especifique la primera dirección IP del intervalo de

exclusión. Por ejemplo, escriba [Link].

b. En Dirección IP final, especifique la última dirección IP del intervalo de

exclusión. Por ejemplo, escriba [Link].

9. Haz clic en Agregar y, después, en Siguiente.

10. En Duración de la concesión, modifique los valores predeterminados relativos a

Días, Horas y Minutos según sea preciso para la red y, a continuación, haga clic en
Siguiente.
 11. En Configurar opciones DHCP, seleccione Configurar estas opciones ahora y
haga clic en Siguiente.

12. En Enrutador (puerta de enlace predeterminada), realice una de las acciones

siguientes:

Si no dispone de enrutadores en la red, haga clic en Siguiente.

En Dirección IP, escriba la dirección IP del enrutador o de la puerta de enlace

predeterminada. Por ejemplo, escriba [Link]. Haz clic en Agregar y, después,
en Siguiente.

13. En Nombre de dominio y servidores DNS, realice lo siguiente:

a. En Dominio primario, escriba el nombre del dominio DNS que los clientes usan
para la resolución de nombres. Por ejemplo, escriba [Link].

b. En Nombre del servidor, escriba el nombre del equipo DNS que los clientes
usan para la resolución de nombres. Por ejemplo, escriba DC1.

c. Haga clic en Resolver. La dirección IP del servidor DNS se agrega a Dirección IP.
Haga clic en Agregar, espere a que finalice la validación de la dirección IP del
servidor DNS y, a continuación, haga clic en Siguiente.

14. En Servidores WINS, haga clic en Siguiente, ya que no hay servidores WINS en la
red.

15. En Activar ámbito, seleccione Activar este ámbito ahora.

16. Haga clic en Siguientey después en Finalizar.

） Importante

Para crear ámbitos para otras subredes, repita este procedimiento. Use un intervalo
de direcciones IP diferente por cada subred que desee implementar y asegúrese de
que el reenvío de mensajes DHCP está habilitado en todos los enrutadores que
llevan a otras subredes.

Unir equipos cliente al dominio e iniciar sesión

７ Nota
 Para llevar a cabo este procedimiento con Windows PowerShell, abra PowerShell,
escriba el siguiente cmdlet y después presione ENTRAR. También debe reemplazar
el nombre de dominio por el nombre que quiera usar.

Add-Computer -DomainName [Link]

Cuando se le pida, escriba el nombre de usuario y la contraseña de una cuenta que

tenga permiso para unir un equipo al dominio. Para reiniciar el equipo, escriba el
siguiente comando y presione ENTRAR.

Restart-Computer

Para unir equipos que ejecutan Windows 10 al dominio

1. Inicie sesión en el equipo con la cuenta de administrador local.

2. En Buscar en la web y Windows, escriba System. En los resultados de la búsqueda,

haga clic en Sistema (Panel de control). Se abre el cuadro de diálogo Sistema.

3. En Sistema, haga clic en Configuración avanzada del sistema. Se abre el cuadro

de diálogo Propiedades del sistema. Haga clic en la ficha Nombre de equipo.

4. En Nombre de equipo, haga clic en Cambiar. Se abre el cuadro de diálogo

Cambios en el dominio o el nombre del equipo.

5. En Nombre de equipo/Cambios de dominio , en Miembro de , haga clic en

Dominioy, a continuación, escriba el nombre del dominio al que desea unirse. Por
ejemplo, si el nombre del dominio es [Link], escriba
[Link].

6. Haga clic en OK. Se abre el cuadro de diálogo Seguridad de Windows.

7. En Cambios en el dominio o el nombre del equipo, escriba el nombre del usuario

en Nombre de usuario y la contraseña en Contraseña y, a continuación, haga clic
en Aceptar. Se abrirá el cuadro de diálogo Cambios en el dominio o el nombre
del equipo y le dará la bienvenida al dominio. Haga clic en OK.

8. El cuadro de diálogo Cambios en el dominio o el nombre del equipo muestra un

mensaje que le indica que debe reiniciar el equipo para aplicar los cambios. Haga
clic en OK.

9. En el cuadro de diálogo Propiedades del sistema, en la pestaña Nombre del

equipo, haga clic en Cerrar. Se abrirá el cuadro de diálogo Microsoft Windows,
 que muestra un mensaje que indica de nuevo que debe reiniciar el equipo para
aplicar los cambios. Haga clic en Reiniciar ahora.

Para unir equipos que ejecutan Windows 8.1 al dominio

1. Inicie sesión en el equipo con la cuenta de administrador local.

2. Haga clic con el botón derecho en Inicioy, a continuación, haga clic en Sistema. Se
abre el cuadro de diálogo Sistema.

3. En Sistema, haga clic en Configuración avanzada del sistema. Se abre el cuadro

de diálogo Propiedades del sistema. Haga clic en la ficha Nombre de equipo.

4. En Nombre de equipo, haga clic en Cambiar. Se abre el cuadro de diálogo

Cambios en el dominio o el nombre del equipo.

5. En Nombre de equipo/Cambios de dominio , en Miembro de , haga clic en

Dominioy, a continuación, escriba el nombre del dominio al que desea unirse. Por
ejemplo, si el nombre del dominio es [Link], escriba
[Link].

6. Haga clic en OK. Se abre el cuadro de diálogo Seguridad de Windows.

7. En Cambios en el dominio o el nombre del equipo, escriba el nombre del usuario

en Nombre de usuario y la contraseña en Contraseña y, a continuación, haga clic
en Aceptar. Se abrirá el cuadro de diálogo Cambios en el dominio o el nombre
del equipo y le dará la bienvenida al dominio. Haga clic en OK.

8. El cuadro de diálogo Cambios en el dominio o el nombre del equipo muestra un

mensaje que le indica que debe reiniciar el equipo para aplicar los cambios. Haga
clic en OK.

9. En el cuadro de diálogo Propiedades del sistema, en la pestaña Nombre del

equipo, haga clic en Cerrar. Se abrirá el cuadro de diálogo Microsoft Windows,
que muestra un mensaje que indica de nuevo que debe reiniciar el equipo para
aplicar los cambios. Haga clic en Reiniciar ahora.

Para iniciar sesión en el dominio mediante equipos que ejecutan

Windows 10

1. Cierre la sesión del equipo o reinicie el equipo.

2. Presione Ctrl+Alt+Supr. Aparecerá la pantalla de inicio de sesión.

 3. En la parte inferior izquierda, haga clic en Otro usuario.

4. En Nombre de usuario, escriba su dominio y nombre de usuario con el formato

dominio\usuario. Por ejemplo, para iniciar sesión en el dominio de
[Link] con una cuenta llamada Usuario-01, escriba CORP\Usuario-01.

5. En Contraseña, escriba la contraseña del dominio y, a continuación, haga clic en la

flecha o presione Entrar.

Implementar características opcionales para la

autenticación de acceso a redes y servicios web
Si tiene previsto implementar servidores de acceso de red, como puntos de acceso
inalámbrico o servidores VPN, después de instalar la red principal, se recomienda
implementar tanto un NPS como un servidor web. Para las implementaciones de acceso
a redes, se recomienda usar métodos de autenticación segura basada en certificados.
Puede usar NPS para administrar directivas de acceso a redes e implementar métodos
de autenticación segura. Puede usar un servidor web para publicar la lista de revocación
de certificados (CRL) de la autoridad de certificación (CA) que suministra los certificados
para la autenticación segura.

７ Nota

Puede implementar certificados de servidor y otras características por medio de las

guías de red principal complementarias. Para obtener más información, vea
Recursos técnicos adicionales.

En la ilustración siguiente se muestra la topología de red de Windows Server Core con

servidores NPS y Web agregados.
En las siguientes secciones se proporciona información sobre cómo agregar servidores
NPS y web a la red.

Implementar NPS1

Implementar WEB1

Implementar NPS1
El Servidor de directivas de redes (NPS) se instala como un paso previo a la
implementación de otras tecnologías de acceso a redes, como servidores de red privada
virtual (VPN), puntos de acceso inalámbrico y conmutadores de autenticación 802.1X.

El servidor de directivas de red (NPS) permite configurar y administrar de forma

centralizada las directivas de red con las siguientes características: servidor de servicio
de acceso telefónico local de autenticación remota (RADIUS) y proxy RADIUS.

NPS es un componente opcional de una red principal, pero conviene instalarlo si se

cumple alguna de las siguientes condiciones:
 Tiene previsto expandir la red para incluir servidores de acceso remoto
compatibles con el protocolo RADIUS, como un equipo que ejecuta Windows
Server 2016, Windows Server 2012 R2, Windows Server 2012 , Windows Server
2008 R2 o Windows Server 2008 y enrutamiento y servicio de acceso remoto,
Puerta de enlace de Terminal Services o Puerta de enlace de Escritorio remoto.

Tiene previsto implementar la autenticación 802.1X para el acceso inalámbrico o

con cable.

Antes de implementar este servicio de rol, debe realizar los pasos siguientes en el
equipo que va a configurar como NPS.

Completar los pasos de la sección Configurar todos los servidores

Realizar los pasos de la sección Unir equipos servidor al dominio e iniciar sesión

Para implementar NPS1, que es el equipo que ejecuta el servicio de rol de Servidor de
directivas de redes (NPS) del rol de servidor de Servicios de acceso y directivas de redes,
debe completar estos pasos:

Planear la implementación de NPS1

Instalar el Servidor de directivas de redes (NPS)

Registro de NPS en el dominio predeterminado

７ Nota

En esta guía se proporcionan instrucciones para implementar NPS en un servidor

independiente o una máquina virtual denominada NPS1. Otro modelo de
implementación recomendado es la instalación de NPS en un controlador de
dominio. Si prefiere instalar NPS en un controlador de dominio en lugar de en un
servidor independiente, instale NPS en DC1.

Planear la implementación de NPS1

Si tiene previsto implementar servidores de acceso a la red, como puntos de acceso

inalámbrico o servidores VPN, después de implementar la red principal, se recomienda
implementar NPS.

Cuando NPS se usa como un servidor RADIUS, se encarga de autenticar y autorizar las
solicitudes de conexión a través de los servidores de acceso a la red. NPS también
permite configurar y administrar de forma centralizada las directivas de red que
determinan quién puede tener acceso a la red, cómo y cuándo.

A continuación se indican los pasos clave de planeación necesarios previos a la

instalación de NPS.

Planear la base de datos de cuentas de usuario. De forma predeterminada, si une

el servidor que ejecuta NPS a un dominio de Active Directory, NPS lleva a cabo las
tareas de autenticación y autorización mediante la base de datos de cuentas de
usuario de AD DS. En algunos casos, como sucede con las redes grandes que usan
NPS como un proxy RADIUS para reenviar solicitudes de conexión a otros
servidores RADIUS, puede que desee instalar NPS en un equipo que no sea
miembro del dominio.

Planear la contabilización de cuentas RADIUS. NPS permite registrar los datos de la

contabilización de cuentas en una base de datos SQL Server o en un archivo de
texto en el equipo local. Si desea usar el registro de SQL Server, planee la
instalación y configuración del servidor que ejecuta SQL Server.

Instalar el Servidor de directivas de redes (NPS)

Puede usar este procedimiento para instalar el servidor de directivas de red (NPS)
mediante el Asistente para agregar roles y características. NPS es un servicio de rol del
rol de servidor Servicios de acceso y directivas de redes.

７ Nota

De forma predeterminada, NPS escucha el tráfico RADIUS en los puertos 1812,

1813, 1645 y 1646 en todos los adaptadores de red instalados. Si firewall de
Windows con seguridad avanzada está habilitado al instalar NPS, las excepciones
de firewall para estos puertos se crean automáticamente durante el proceso de
instalación para el tráfico de Protocolo de Internet versión 6 (IPv6) e IPv4. Si los
servidores de acceso a la red están configurados para enviar tráfico RADIUS a
través de puertos distintos de estos valores predeterminados, quite las excepciones
creadas en firewall de Windows con seguridad avanzada durante la instalación de
NPS y cree excepciones para los puertos que usa para el tráfico RADIUS.

Credenciales administrativas

Para completar este procedimiento, debe ser miembro del grupo Admins. del dominio.

７ Nota
 Para llevar a cabo este procedimiento con Windows PowerShell, abra PowerShell,
escriba lo siguiente y después presione ENTRAR.

Install-WindowsFeature NPAS -IncludeManagementTools

Para instalar NPS

1. En NPS1, en Administrador del servidor, haga clic en Administrar y, a continuación,

haga clic en Agregar roles y características. Se abre el Asistente para agregar roles
y características.

2. En Antes de comenzar, haga clic en Siguiente.

７ Nota

La página Antes de comenzar del Asistente para agregar roles y

características no se muestra si ha seleccionado anteriormente Omitir esta
página de forma predeterminada al ejecutar el asistente.

3. En Seleccionar tipo de instalación, asegúrese de que la opción Instalación basada

en características o en roles está seleccionada y, a continuación, haga clic en
Siguiente.

4. En Seleccionar servidor de destino, asegúrese de que la opción Seleccionar un

servidor del grupo de servidores está seleccionada. En Grupo de servidores,
asegúrese de que el equipo local está seleccionado. Haga clic en Next.

5. En Seleccionar roles de servidor, en Roles, seleccione Directiva de red y Servicios

de acceso. Se abre un cuadro de diálogo en el que se pregunta si debe agregar
características necesarias para los servicios de acceso y directivas de red. Haz clic
en Agregar características requeridasy, a continuación, haz clic en Siguiente.

6. En Seleccionar características, haga clic en Siguiente. En Servicios de acceso y

directivas de redes, repase la información proporcionada y haga clic en Siguiente.

7. En Seleccionar servicios de rol, haga clic en Servidor de directivas de redes. En

¿Desea agregar características requeridas para Servidor de directivas de redes?,
haga clic en Agregar características. Haga clic en Next.

8. En Confirmar selecciones de instalación, haga clic en Reiniciar automáticamente

el servidor de destino en caso necesario. Si se le pide confirmar la selección, haga
clic en Sí y, a continuación, haga clic en Instalar. La página Progreso de la
 instalación muestra el estado durante el proceso de instalación. Cuando se
completa el proceso, se muestra el mensaje "Instalación correcta en
NombreDeEquipo" donde NombreDeEquipo es el nombre del equipo en el que
instaló el servidor de directivas de red. Haga clic en Cerrar.

Registro de NPS en el dominio predeterminado

Puede usar este procedimiento para registrar un NPS en el dominio donde el servidor es
miembro de dominio.

Los NPS deben registrarse en Active Directory para que tengan permiso para leer las
propiedades de acceso telefónico local de las cuentas de usuario durante el proceso de
autorización. Al registrar un NPS, se agrega el servidor al grupo servidores RAS e IAS en
Active Directory.

Credenciales administrativas

Para completar este procedimiento, debe ser miembro del grupo Admins. del dominio.

７ Nota

Para realizar este procedimiento mediante comandos de shell de red (Netsh) en

Windows PowerShell, abra PowerShell y escriba lo siguiente y presione ENTRAR.

netsh nps add registeredserver domain=[Link]

server=[Link]

Para registrar un NPS en su dominio predeterminado

1. En NPS1, en Administrador del servidor, haga clic en Herramientas y a

continuación, haga clic en Servidor de directivas de redes. Se abre MMC del
Servidor de directivas de redes.

2. Haga clic con el botón secundario en NPS (local) y, a continuación, haga clic en
Registrar servidor en Active Directory. Se abrirá el cuadro de diálogo Servidor de
directivas de redes.

3. En Servidor de directivas de redes, haga clic en Aceptar y, a continuación, en

Aceptar de nuevo.

Para obtener más información sobre el servidor de directivas de red, vea Servidor de
directivas de red (NPS).
Implementar WEB1
El rol Servidor web (IIS) en Windows Server 2016 proporciona una plataforma segura,
fácil de administrar, modular y extensible para hospedar de forma confiable sitios web,
servicios y aplicaciones. Con Internet Information Services (IIS), puede compartir
información con usuarios en Internet, una intranet o una extranet. IIS es una plataforma
web unificada que integra IIS, [Link], servicios FTP, PHP y Windows Communication
Foundation (WCF).

Además de permitirle publicar una CRL para el acceso por parte de equipos miembros
del dominio, el rol de servidor servidor web (IIS) le permite configurar y administrar
varios sitios web, aplicaciones web y sitios FTP. IIS también proporciona las siguientes
ventajas:

La seguridad web se refuerza gracias a una superficie reducida de servidor y al

aislamiento automático de aplicaciones.

Podrá implementar y ejecutar aplicaciones web de [Link], ASP clásico y PHP en

el mismo servidor de forma sencilla.

Se logra el aislamiento de aplicaciones al proporcionar a los procesos de trabajo

una identidad única y una configuración en espacio aislado de manera
predeterminada, lo que reduce aún más los riesgos de seguridad.

Podrá agregar y eliminar componentes IIS integrados e incluso reemplazarlos

fácilmente por módulos personalizados que se adapten a las necesidades del
cliente.

Aumenta la velocidad del sitio web mediante el almacenamiento en caché

dinámico integrado y la compresión mejorada.

Para implementar WEB1, que es el equipo que ejecuta el rol Servidor web (IIS), debe
hacer lo siguiente:

Completar los pasos de la sección Configurar todos los servidores

Realizar los pasos de la sección Unir equipos servidor al dominio e iniciar sesión

Instalar el rol de servidor del servidor web (IIS)

Instalar el rol de servidor del servidor web (IIS)

Para completar este procedimiento, debe pertenecer al grupo Administradores.

 ７ Nota

Para llevar a cabo este procedimiento con Windows PowerShell, abra PowerShell,
escriba lo siguiente y después presione ENTRAR.

Install-WindowsFeature Web-Server -IncludeManagementTools

1. En el Administrador del servidor, haz clic en Administrar y después haz clic en

Agregar roles y características. Se abre el Asistente para agregar roles y
características.

2. En Antes de comenzar, haga clic en Siguiente.

７ Nota

La página Antes de comenzar del Asistente para agregar roles y

características no se muestra si ha seleccionado anteriormente Omitir esta
página de forma predeterminada al ejecutar el asistente.

3. En la página Seleccionar tipo de instalación , haga clic en Siguiente.

4. En la página Seleccionar servidor de destino , asegúrese de que el equipo local

está seleccionado y, a continuación, haga clic en Siguiente.

5. En la página Seleccionar roles de servidor, desplácese hasta y seleccione Servidor

web (IIS). Se abre el cuadro de diálogo Agregar características necesarias para el
servidor web (IIS ). Haz clic en Agregar características requeridasy, a
continuación, haz clic en Siguiente.

6. Haga clic en Siguiente hasta haber aceptado todas las configuraciones

predeterminadas del servidor web y, a continuación, haga clic en Instalar.

7. Compruebe que todas las instalaciones se realizaron correctamente y, a

continuación, haga clic en Cerrar.

Recursos técnicos adicionales

Para obtener más información sobre las tecnologías de esta guía, vea los siguientes
recursos:

Windows Server 2016, Windows Server 2012 R2 y recursos de la biblioteca técnica de

Windows Server 2012
 Novedades de Servicios de dominio de Active Directory (AD DS) en Windows
Server 2016

Servicios de dominio de Active Directory información general en

[Link] .

Introducción al Sistema de nombres de dominio (DNS) en

[Link] .

Implementación del rol administradores de DNS

Introducción al Protocolo de configuración dinámica de host (DHCP) en

[Link] .

Introducción a los servicios de acceso y directivas de red en

[Link] .

Introducción al servidor web (IIS) en

[Link] .

Apéndices A a E
Las secciones siguientes contienen información de configuración adicional para equipos
que ejecutan sistemas operativos distintos de Windows Server 2016, Windows 10,
Windows Server 2012 y Windows 8. Además, se proporciona una hoja de cálculo de
preparación de red para ayudarle con la implementación.

1. Apéndice A - Cambiar el nombre de los equipos

2. Apéndice B - Configurar direcciones IP estáticas

3. Apéndice C: Unión de equipos al dominio

4. Apéndice D: Inicio de sesión en el dominio

5. Apéndice E - Hoja de preparación de planeación de una red principal

Apéndice A - Cambiar el nombre de los

equipos
Puede usar los procedimientos de esta sección para proporcionar equipos que ejecutan
Windows Server 2008 R2, Windows 7, Windows Server 2008 y Windows Vista con un
nombre de equipo diferente.
 Windows Server 2008 R2 y Windows 7

Windows Server 2008 y Windows Vista

Windows Server 2008 R2 y Windows 7

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo
Administradores o grupo equivalente.

Para cambiar el nombre de los equipos que ejecutan

Windows Server 2008 R2 y Windows 7

1. Haga clic en Inicio, haga clic con el botón secundario en Equipo y, después, haga
clic en Propiedades. Se abre el cuadro de diálogo Sistema.

2. En Configuración de nombre, dominio y grupo de trabajo del equipo, haga clic

en Cambiar configuración. Se abre el cuadro de diálogo Propiedades del sistema.

７ Nota

En equipos que ejecutan Windows 7, antes de que se abra el cuadro de

diálogo Propiedades del sistema , se abre el cuadro de diálogo Control de
cuentas de usuario y se solicita permiso para continuar. Haga clic en
Continuar para seguir.

3. Haga clic en Cambiar. Se abre el cuadro de diálogo Cambios en el dominio o el

nombre del equipo.

4. En Nombre de equipo, escriba el nombre del equipo. Por ejemplo, si desea

asignarle el nombre DC1, escriba DC1.

5. Haga clic dos veces en Aceptar, haga clic en Cerrar y, a continuación, haga clic en
Reiniciar ahora para reiniciar el equipo.

Windows Server 2008 y Windows Vista

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo
Administradores o grupo equivalente.

Para cambiar el nombre de los equipos que ejecutan

Windows Server 2008 y Windows Vista
 1. Haga clic en Inicio, haga clic con el botón secundario en Equipo y, después, haga
clic en Propiedades. Se abre el cuadro de diálogo Sistema.

2. En Configuración de nombre, dominio y grupo de trabajo del equipo, haga clic

en Cambiar configuración. Se abre el cuadro de diálogo Propiedades del sistema.

７ Nota

En equipos que ejecutan Windows Vista, antes de que se abra el cuadro de

diálogo Propiedades del sistema , se abre el cuadro de diálogo Control de
cuentas de usuario, solicitando permiso para continuar. Haga clic en
Continuar para seguir.

3. Haga clic en Cambiar. Se abre el cuadro de diálogo Cambios en el dominio o el

nombre del equipo.

4. En Nombre de equipo, escriba el nombre del equipo. Por ejemplo, si desea

asignarle el nombre DC1, escriba DC1.

5. Haga clic dos veces en Aceptar, haga clic en Cerrar y, a continuación, haga clic en
Reiniciar ahora para reiniciar el equipo.

Apéndice B - Configurar direcciones IP

estáticas
En este tema se incluyen los procedimientos necesarios para configurar direcciones IP
estáticas en equipos que ejecutan los siguientes sistemas operativos:

Windows Server 2008 R2

Windows Server 2008

Windows Server 2008 R2

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo
Administradores o grupo equivalente.

Para configurar una dirección IP estática en un equipo que ejecuta

Windows Server 2008 R2

1. Haga clic en Inicio y, a continuación, en Panel de control.

 2. En el Panel de control, haga clic en Red e Internet. Se abre Red e Internet.

En Red e Internet, haga clic en Centro de redes y recursos compartidos. Se abre

Centro de redes y recursos compartidos.

3. En Centro de redes y recursos compartidos, haga clic en Cambiar configuración

del adaptador. Se abre Conexiones de red.

4. En Conexiones de red, haga clic con el botón secundario en la conexión de red

que desea configurar y, a continuación, haga clic en Propiedades.

5. En Propiedades de conexión de área local, en Esta conexión usa los siguientes

elementos, seleccione Protocolo de Internet versión 4 (TCP/IPv4) y, a
continuación, haga clic en Propiedades. Se abre el cuadro de diálogo Propiedades
de protocolo de Internet versión 4 (TCP/IPv4).

6. En Propiedades de protocolo de Internet versión 4 (TCP/IPv4), en la pestaña

General, haga clic en Usar la siguiente dirección IP. En Dirección IP, escriba la
dirección IP que desea usar.

7. Presione el tabulador para colocar el cursor en Máscara de subred. Se escribe

automáticamente un valor predeterminado para la máscara de subred. Acepte la
máscara de subred predeterminada o escriba la máscara de subred que quiera
usar.

8. En Puerta de enlace predeterminada, escriba la dirección IP de la puerta de enlace

predeterminada.

9. En Servidor DNS preferido, escriba la dirección IP del servidor DNS. Si tiene

previsto usar el equipo local como servidor DNS preferido, escriba la dirección IP
de ese equipo.

10. En Servidor DNS alternativo, escriba la dirección IP del servidor DNS alternativo si
lo hay. Si tiene previsto usar el equipo local como servidor DNS alternativo, escriba
la dirección IP de ese equipo.

11. Haga clic en Aceptary, a continuación, en Cerrar.

Windows Server 2008

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo
Administradores o grupo equivalente.
Para configurar una dirección IP estática en un equipo que ejecuta
Windows Server 2008

1. Haga clic en Inicio y, a continuación, en Panel de control.

2. En el Panel de control, compruebe que la opción Vista Clásica está seleccionada y,

a continuación, haga doble clic en Centro de redes y recursos compartidos.

3. En Centro de redes y recursos compartidos, en Tareas, haga clic en Administrar

conexiones de red.

4. En Conexiones de red, haga clic con el botón secundario en la conexión de red

que desea configurar y, a continuación, haga clic en Propiedades.

5. En Propiedades de conexión de área local, en Esta conexión usa los siguientes

elementos, seleccione Protocolo de Internet versión 4 (TCP/IPv4) y, a
continuación, haga clic en Propiedades. Se abre el cuadro de diálogo Propiedades
de protocolo de Internet versión 4 (TCP/IPv4).

6. En Propiedades de protocolo de Internet versión 4 (TCP/IPv4), en la pestaña

General, haga clic en Usar la siguiente dirección IP. En Dirección IP, escriba la
dirección IP que desea usar.

7. Presione el tabulador para colocar el cursor en Máscara de subred. Se escribe

automáticamente un valor predeterminado para la máscara de subred. Acepte la
máscara de subred predeterminada o escriba la máscara de subred que quiera
usar.

8. En Puerta de enlace predeterminada, escriba la dirección IP de la puerta de enlace

predeterminada.

9. En Servidor DNS preferido, escriba la dirección IP del servidor DNS. Si tiene

previsto usar el equipo local como servidor DNS preferido, escriba la dirección IP
de ese equipo.

10. En Servidor DNS alternativo, escriba la dirección IP del servidor DNS alternativo si
lo hay. Si tiene previsto usar el equipo local como servidor DNS alternativo, escriba
la dirección IP de ese equipo.

11. Haga clic en Aceptary, a continuación, en Cerrar.

Apéndice C: Unión de equipos al dominio

Puede usar estos procedimientos para unir equipos que ejecutan Windows Server 2008
R2, Windows 7, Windows Server 2008 y Windows Vista al dominio.

Windows Server 2008 R2 y Windows 7

Windows Server 2008 y Windows Vista

） Importante

Para unir un equipo a un dominio, debe iniciar sesión en el equipo con la cuenta de
administrador local o, si inicia sesión en el equipo con una cuenta de usuario que
no tiene credenciales administrativas en el equipo local, debe proporcionar las
credenciales para la cuenta de administrador local durante el proceso de unión del
equipo al dominio. Además, debe tener una cuenta de usuario en el dominio al que
quiere unir el equipo. Durante el proceso de unión del equipo al dominio, se le
pedirán las credenciales de su cuenta de dominio (nombre de usuario y
contraseña).

Windows Server 2008 R2 y Windows 7

El requisito mínimo para completar este procedimiento es la pertenencia al grupo
Usuarios del dominio o grupo equivalente.

Para unir equipos que ejecutan Windows Server 2008 R2 y

Windows 7 al dominio

1. Inicie sesión en el equipo con la cuenta de administrador local.

2. Haga clic en Inicio, haga clic con el botón secundario en Equipo y, después, haga
clic en Propiedades. Se abre el cuadro de diálogo Sistema.

3. En Configuración de nombre, dominio y grupo de trabajo del equipo, haga clic

en Cambiar configuración. Se abre el cuadro de diálogo Propiedades del sistema.

７ Nota

En equipos que ejecutan Windows 7, antes de que se abra el cuadro de

diálogo Propiedades del sistema , se abre el cuadro de diálogo Control de
cuentas de usuario y se solicita permiso para continuar. Haga clic en
Continuar para seguir.
 4. Haga clic en Cambiar. Se abre el cuadro de diálogo Cambios en el dominio o el
nombre del equipo.

5. En Nombre del equipo, en Miembro del, seleccione Dominio y, a continuación,

escriba el nombre del dominio al que quiere unirse. Por ejemplo, si el nombre del
dominio es [Link], escriba [Link].

6. Haga clic en OK. Se abre el cuadro de diálogo Seguridad de Windows.

7. En Cambios en el dominio o el nombre del equipo, escriba el nombre del usuario

en Nombre de usuario y la contraseña en Contraseña y, a continuación, haga clic
en Aceptar. Se abrirá el cuadro de diálogo Cambios en el dominio o el nombre
del equipo y le dará la bienvenida al dominio. Haga clic en OK.

8. El cuadro de diálogo Cambios en el dominio o el nombre del equipo muestra un

mensaje que le indica que debe reiniciar el equipo para aplicar los cambios. Haga
clic en OK.

9. En el cuadro de diálogo Propiedades del sistema, en la pestaña Nombre del

equipo, haga clic en Cerrar. Se abrirá el cuadro de diálogo Microsoft Windows,
que muestra un mensaje que indica de nuevo que debe reiniciar el equipo para
aplicar los cambios. Haga clic en Reiniciar ahora.

Windows Server 2008 y Windows Vista

El requisito mínimo para completar este procedimiento es la pertenencia al grupo
Usuarios del dominio o grupo equivalente.

Para unir equipos que ejecutan Windows Server 2008 y

Windows Vista al dominio

1. Inicie sesión en el equipo con la cuenta de administrador local.

2. Haga clic en Inicio, haga clic con el botón secundario en Equipo y, después, haga
clic en Propiedades. Se abre el cuadro de diálogo Sistema.

3. En Configuración de nombre, dominio y grupo de trabajo del equipo, haga clic

en Cambiar configuración. Se abre el cuadro de diálogo Propiedades del sistema.

4. Haga clic en Cambiar. Se abre el cuadro de diálogo Cambios en el dominio o el

nombre del equipo.

5. En Nombre del equipo, en Miembro del, seleccione Dominio y, a continuación,

escriba el nombre del dominio al que quiere unirse. Por ejemplo, si el nombre del
 dominio es [Link], escriba [Link].

6. Haga clic en OK. Se abre el cuadro de diálogo Seguridad de Windows.

7. En Cambios en el dominio o el nombre del equipo, escriba el nombre del usuario

en Nombre de usuario y la contraseña en Contraseña y, a continuación, haga clic
en Aceptar. Se abrirá el cuadro de diálogo Cambios en el dominio o el nombre
del equipo y le dará la bienvenida al dominio. Haga clic en OK.

8. El cuadro de diálogo Cambios en el dominio o el nombre del equipo muestra un

mensaje que le indica que debe reiniciar el equipo para aplicar los cambios. Haga
clic en OK.

9. En el cuadro de diálogo Propiedades del sistema, en la pestaña Nombre del

equipo, haga clic en Cerrar. Se abrirá el cuadro de diálogo Microsoft Windows,
que muestra un mensaje que indica de nuevo que debe reiniciar el equipo para
aplicar los cambios. Haga clic en Reiniciar ahora.

Apéndice D: Inicio de sesión en el dominio

Puede usar estos procedimientos para iniciar sesión en el dominio mediante equipos
que ejecutan Windows Server 2008 R2, Windows 7, Windows Server 2008 y Windows
Vista.

Windows Server 2008 R2 y Windows 7

Windows Server 2008 y Windows Vista

Windows Server 2008 R2 y Windows 7

El requisito mínimo para completar este procedimiento es la pertenencia al grupo
Usuarios del dominio o grupo equivalente.

Iniciar sesión en el dominio con equipos que ejecutan

Windows Server 2008 R2 y Windows 7

1. Cierre la sesión del equipo o reinicie el equipo.

2. Presione Ctrl+Alt+Supr. Aparecerá la pantalla de inicio de sesión.

3. Haga clic en Cambiar de usuario y, a continuación, haga clic en Otro usuario.

4. En Nombre de usuario, escriba su dominio y nombre de usuario con el formato

dominio\usuario. Por ejemplo, para iniciar sesión en el dominio de
 [Link] con una cuenta llamada Usuario-01, escriba CORP\Usuario-01.

5. En Contraseña, escriba la contraseña del dominio y, a continuación, haga clic en la

flecha o presione Entrar.

Windows Server 2008 y Windows Vista

El requisito mínimo para completar este procedimiento es la pertenencia al grupo
Usuarios del dominio o grupo equivalente.

Iniciar sesión en el dominio con equipos que ejecutan

Windows Server 2008 y Windows Vista

1. Cierre la sesión del equipo o reinicie el equipo.

2. Presione Ctrl+Alt+Supr. Aparecerá la pantalla de inicio de sesión.

3. Haga clic en Cambiar de usuario y, a continuación, haga clic en Otro usuario.

4. En Nombre de usuario, escriba su dominio y nombre de usuario con el formato

dominio\usuario. Por ejemplo, para iniciar sesión en el dominio de
[Link] con una cuenta llamada Usuario-01, escriba CORP\Usuario-01.

5. En Contraseña, escriba la contraseña del dominio y, a continuación, haga clic en la

flecha o presione Entrar.

Apéndice E - Hoja de preparación de

planeación de una red principal
Puede usar esta Hoja de preparación de planeamiento de red para recopilar la
información necesaria para instalar una red principal. En este tema se proporcionan
tablas que contienen los elementos de configuración individuales de cada equipo
servidor para el que se debe suministrar información o valores específicos durante la
instalación o el proceso de configuración. Se incluyen valores de ejemplo para cada
elemento de configuración.

De cara a posibles tareas de planeamiento y seguimiento, también se proporcionan

espacios en cada tabla donde se pueden especificar los valores usados para la
implementación. Si se registran valores relacionados con la seguridad en estas tablas, se
debe almacenar la información en una ubicación segura.
Los siguientes vínculos llevan a las secciones de este tema que proporcionan elementos
de configuración y valores de ejemplo asociados con los procedimientos de
implementación presentados en esta guía.

1. Instalar Active Directory Domain Services y DNS

Configurar una zona de búsqueda inversa de DNS

2. Instalar DHCP

Crear un intervalo de exclusión en DHCP

Crear un nuevo ámbito DHCP

3. Instalar un Servidor de directivas de redes (opcional)

Instalar Active Directory Domain Services y DNS

Las tablas de esta sección muestran elementos de configuración para la preinstalación y
la instalación de Active Directory Domain Services (AD DS) y DNS.

Elementos de configuración de la preinstalación para AD DS y

DNS

Las siguientes tablas recogen elementos de configuración de la preinstalación tal y

como se describen en Configurar todos los servidores:

Configuración de una dirección IP estática

Elementos de configuración Valores de ejemplo Valores

Dirección IP [Link]

Máscara de subred [Link]

Puerta de enlace predeterminada [Link]

Servidor DNS preferido [Link]

Servidor DNS alternativo [Link]

Cambiar el nombre del equipo

Elemento de configuración Valor de ejemplo Value

Nombre del equipo DC1

Elementos de configuración de la instalación de AD DS y DNS

Elementos de configuración para el procedimiento de implementación de una red

principal de Windows Server Instalar AD DS y DNS para un bosque nuevo:

Elementos de configuración Valores de ejemplo Valores

Nombre DNS completo [Link]

Nivel funcional de bosque Windows Server 2003

Ubicación de la carpeta de bases de datos de Active E:\Configuration\

Directory Domain Services O bien, acepte la ubicación
predeterminada.

Ubicación de la carpeta de archivos de registro de E:\Configuration\

Active Directory Domain Services O bien, acepte la ubicación
predeterminada.

Ubicación de la carpeta SYSVOL de Active Directory E:\Configuration\

Domain Services O bien, acepte la ubicación
predeterminada.

Contraseña de administrador para el modo de J*p2leO4$F

restauración de directorios

Nombre del archivo de respuesta (opcional) AD DS_AnswerFile

Configurar una zona de búsqueda inversa de DNS

Elementos de Valores de ejemplo Valores

configuración

Tipo de zona: - Zona primaria

- Zona secundaria
- Zona de código auxiliar

Tipo de zona -Seleccionado

Almacenar la zona en - No seleccionado
Active Directory

Ámbito de replicación de - Para todos los servidores DNS de este bosque

zona de Active Directory - Para todos los servidores DNS de este dominio
- Para todos los controladores de dominio de este
dominio
- Para todos los controladores de dominio especificados
en el ámbito de esta partición de directorio
 Elementos de Valores de ejemplo Valores
configuración

Nombre de zona de - Zona de búsqueda inversa IPv4

búsqueda inversa - Zona de búsqueda inversa IPv6
(tipo de IP)

Nombre de zona de 10.0.0

búsqueda inversa
(identificador de red)

Instalar DHCP
Las tablas de esta sección muestran elementos de configuración para la preinstalación e
instalación de DHCP.

Elementos de configuración de la preinstalación para DHCP

Las siguientes tablas recogen elementos de configuración de la preinstalación tal y

como se describen en Configurar todos los servidores:

Configuración de una dirección IP estática

Elementos de configuración Valores de ejemplo Valores

Dirección IP [Link]

Máscara de subred [Link]

Puerta de enlace predeterminada [Link]

Servidor DNS preferido [Link]

Servidor DNS alternativo [Link]

Cambiar el nombre del equipo

Elemento de configuración Valor de ejemplo Valor

Nombre del equipo DHCP1

Elementos de configuración de la instalación de DHCP

Elementos de configuración para el procedimiento de implementación de una red

principal de Windows Server Instalar Protocolo de configuración dinámica de host
(DHCP):

Elementos de configuración Valores de ejemplo Valores

Enlaces de conexión de red Ethernet

Configuración del servidor DNS DC1

Dirección IP del servidor DNS preferido [Link]

Dirección IP del servidor DNS alternativo [Link]

Nombre de ámbito Corp1

Dirección IP inicial [Link]

Dirección IP final [Link]

Máscara de subred [Link]

Puerta de enlace predeterminada (opcional) [Link]

Duración de la concesión 8 días

Modo de funcionamiento del servidor DHCP IPv6 no habilitado.

Crear un intervalo de exclusión en DHCP

Elementos de configuración para crear un intervalo de exclusión al crear un ámbito en
DHCP.

Elementos de configuración Valores de ejemplo Valores

Nombre de ámbito Corp1

Descripción del ámbito Subred 1 de la oficina principal

Dirección IP inicial del intervalo de exclusión [Link]

Dirección IP final del intervalo de exclusión [Link]

Crear un nuevo ámbito DHCP

Elementos de configuración para el procedimiento de implementación de Windows

Server Core Crear y activar un nuevo ámbito DHCP:

Elementos de configuración Valores de ejemplo Valores

 Elementos de configuración Valores de ejemplo Valores

Nombre del nuevo ámbito Corp2

Descripción del ámbito Subred 2 de la oficina principal

(intervalo de direcciones IP) [Link]

Dirección IP inicial

(intervalo de direcciones IP) [Link]

Dirección IP final

Length 8

Máscara de subred [Link]

(Intervalo de exclusión) Dirección IP inicial [Link]

Dirección IP final del intervalo de exclusión [Link]

Duración de la concesión -8
Días -0
-0
Horas

Minutos

Enrutador (puerta de enlace predeterminada) [Link]

Dirección IP

Dominio DNS principal [Link]

Servidor DNS [Link]

Dirección IP

Instalar un Servidor de directivas de redes (opcional)

Las tablas de esta sección muestran elementos de configuración para la preinstalación e
instalación de NPS.

Elementos de configuración de la preinstalación

Las tres tablas siguientes muestran elementos de configuración de la preinstalación tal y

como se describen en Configurar todos los servidores:

Configuración de una dirección IP estática

Elementos de configuración Valores de ejemplo Valores

 Elementos de configuración Valores de ejemplo Valores

Dirección IP [Link]

Máscara de subred [Link]

Puerta de enlace predeterminada [Link]

Servidor DNS preferido [Link]

Servidor DNS alternativo [Link]

Cambiar el nombre del equipo

Elemento de configuración Valor de ejemplo Valor

Nombre del equipo NPS1

Elementos de configuración de la instalación del Servidor de

directivas de redes

Elementos de configuración para los procedimientos de implementación npS de red de

Windows Server Core Install Network Policy Server (NPS) y Register the NPS in the
Default Domain.

No se requieren más elementos de configuración para instalar y registrar NPS.

Orientación complementaria de red
principal
Artículo • 21/09/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Aunque la Guía de red principal de Windows Server 2016 proporciona instrucciones

sobre cómo implementar un nuevo bosque de Active Directory con un nuevo dominio
raíz y la infraestructura de red compatible, las guías complementarias proporcionan la
capacidad de agregar características a® la red.

Cada guía complementaria le permite cumplir un objetivo específico después de haber

implementado la red principal. En algunos casos, existen varias guías complementarias
que, cuando se implementan juntas y en el orden correcto, permiten alcanzar objetivos
muy complejos de una manera medida, rentable y razonable.

Si implementó el dominio y la red principal de Active Directory antes de encontrar la

guía de red principal, puede usar las guías complementarias de todas maneras para
agregar características a su red. Simplemente, use la guía de red principal como una lista
de requisitos previos y sepa que, para implementar otras características con las guías
complementarias, la red debe cumplir con los requisitos previos que proporciona la guía
de red principal.

Guía complementaria de red principal:

Implementación de certificados de servidor
para implementaciones cableadas e
inalámbricas 802.1X
En esta guía complementaria se explica cómo basar la red principal mediante la
implementación de certificados de servidor para equipos que ejecutan el servidor de
directivas de red (NPS), el servicio de acceso remoto (RAS) o ambos.

Los certificados de servidor son necesarios al implementar métodos de autenticación

basados en certificados con Protocolo de autenticación extensible (EAP) y EAP
protegido (PEAP) para la autenticación de acceso a la red. La implementación de
certificados de servidor con Servicios de certificados de Active Directory (AD CS) para
métodos de autenticación basados en certificados de EAP y PEAP ofrece las siguientes
ventajas:
 Enlace de la identidad del servidor NPS o RAS a una clave privada
Un método rentable y seguro para inscribir automáticamente certificados en
servidores NPS y RAS de miembro de dominio
Método eficaz para administrar certificados y entidades de certificación
Seguridad proporcionada por autenticación basada en certificados
Capacidad de ampliar el uso de certificados para otros propósitos

Para obtener instrucciones sobre cómo implementar certificados de servidor, consulte

Implementación de certificados de servidor para implementaciones cableadas e
inalámbricas de 802.1X.

Guía complementaria de red principal:

implementación Password-Based acceso
inalámbrico autenticado 802.1X
En esta guía complementaria se explica cómo basarse en la red principal
proporcionando instrucciones sobre cómo implementar el Acceso inalámbrico IEEE
802.1X autenticado mediante ieee 802.11 mediante el Protocolo de autenticación
extensible protegido\–Protocolo de autenticación de protocolo de enlace de desafío de
Microsoft versión 2 (PEAP-MS-CHAP v2).

El método de autenticación PEAP-MS-CHAP v2 requiere que los servidores de

autenticación que ejecutan servidor de directivas de red (NPS) presenten clientes
inalámbricos con un certificado de servidor para demostrar la identidad NPS al cliente;
sin embargo, la autenticación de usuario no se realiza mediante un certificado; en su
lugar, los usuarios proporcionan su nombre de usuario y contraseña de dominio.

Dado que PEAP-MS-CHAP v2 requiere que los usuarios proporcionen credenciales

basadas en contraseña en lugar de un certificado durante el proceso de autenticación,
suele ser más fácil y menos costoso implementar que EAP-TLS o PEAP-TLS.

Antes de usar esta guía para implementar el acceso inalámbrico con el método de
autenticación PEAP-MS-CHAP v2, debe hacer lo siguiente:

1. Siga las instrucciones de la Guía de red principal para implementar la

infraestructura de red principal o ya tiene las tecnologías que se presentan en esa
guía implementadas en la red.
2. Siga las instrucciones de la Guía complementaria de red principal Implementar
certificados de servidor para implementaciones cableadas e inalámbricas 802.1X, o
bien ya tiene las tecnologías que se presentan en esa guía implementadas en la
red.
Para obtener instrucciones sobre cómo implementar el acceso inalámbrico con PEAP-
MS-CHAP v2, consulte Deploy Password-Based 802.1X Authenticated Wireless Access
(Implementación del acceso inalámbrico autenticado por 802.1X).

Guía complementaria de red principal:

Implementación del modo de caché hospedada
de BranchCache
En esta guía complementaria se explica cómo implementar BranchCache en modo caché
hospedada en una o varias sucursales.

BranchCache es una tecnología de optimización de ancho de banda de red de área

extensa (WAN) que se incluye en algunas ediciones de los sistemas operativos Windows
Server 2016 y Windows 10, así como en versiones anteriores de Windows y Windows
Server.

Cuando implementa BranchCache en modo Caché hospedada, la memoria caché de

contenido en la sucursal se hospeda en uno o más equipos servidores que se
denominan servidores de caché hospedada. Los servidores de caché hospedada pueden
ejecutar cargas de trabajo además de hospedar la memoria caché, lo que permite usar
el servidor para varios fines en la sucursal.

El modo de caché hospedada en BranchCache aumenta la eficacia de la caché porque el

contenido está disponible incluso si el cliente que originalmente solicitó y almacenaba
en caché los datos está sin conexión. Dado que el servidor de caché hospedada está
siempre disponible, se almacena más contenido en caché, lo cual ofrece más ahorro de
ancho de banda WAN y se mejora la eficiencia de BranchCache.

Al implementar el modo de caché hospedada, todos los clientes de una sucursal de

varias subredes pueden acceder a una sola caché, que se almacena en el servidor de
caché hospedada, incluso si los clientes están en subredes diferentes.

Para obtener instrucciones sobre cómo implementar BranchCache en modo de caché

hospedada, consulte Implementación del modo de caché hospedada de BranchCache.
Implementación de certificados de
servidor para las implementaciones
cableadas e inalámbricas de 802.1X
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar esta guía para implementar certificados de servidor en los servidores de
infraestructura de Servidor de directivas de red y acceso remoto (NPS).

En esta guía se incluyen las siguientes secciones.

Requisitos previos para usar esta guía

Qué no incluye esta guía

Introducción a las tecnologías

Introducción a la implementación de certificados de servidor

Planeamiento de la implementación de certificados de servidor

Implementación de certificados de servidor

Certificados de servidor digital

En esta guía se proporcionan instrucciones para usar Servicios de certificados de Active
Directory (AD CS) para inscribir automáticamente certificados en servidores de
infraestructura de NPS y acceso remoto. AD CS permite crear una infraestructura de
clave pública (PKI) y proporcionar criptografía de clave pública, certificados digitales y
funcionalidades de firma digital para su organización.

Cuando se usan certificados de servidor digital para la autenticación entre equipos de la

red, los certificados proporcionan:

1. Confidencialidad a través del cifrado.

2. Integridad a través de firmas digitales.
3. Autenticación mediante la asociación de claves de certificado con cuentas de
equipo, usuario o dispositivo en una red de equipo.

Tipos de servidor
Con esta guía, puede implementar certificados de servidor en los siguientes tipos de
servidores.

Servidores que ejecutan el servicio de acceso remoto, que son servidores de

DirectAccess o de red privada virtual (VPN) estándar, y que son miembros del
grupo Servidores RAS e IAS .
Servidores que ejecutan el servicio Servidor de directivas de red (NPS) que son
miembros del grupo Servidores RAS e IAS .

Ventajas de la inscripción automática de certificados

La inscripción automática de certificados de servidor, también denominada inscripción
automática, proporciona las siguientes ventajas.

La AD CS de certificación (CA) inscribe automáticamente un certificado de servidor

en todos los servidores NPS y acceso remoto.
Todos los equipos del dominio reciben automáticamente el certificado de entidad
de certificación, que se instala en el almacén entidades de certificación raíz de
confianza en cada equipo miembro del dominio. Por este problema, todos los
equipos del dominio confían en los certificados emitidos por la entidad de
certificación. Esta confianza permite a los servidores de autenticación demostrar
sus identidades entre sí y participar en comunicaciones seguras.
Aparte de actualizar directiva de grupo, no es necesaria la reconfiguración manual
de cada servidor.
Cada certificado de servidor incluye tanto el propósito de autenticación de
servidor como el propósito de autenticación de cliente en las extensiones de uso
mejorado de clave (EKU).
Escalabilidad. Después de implementar la ca raíz Enterprise con esta guía, puede
expandir la infraestructura de clave pública (PKI) agregando Enterprise ca
subordinadas.
Capacidad de administración. Puede administrar AD CS mediante la consola de AD
CS o mediante Windows PowerShell comandos y scripts.
Simplicidad. Especifique los servidores que inscriben certificados de servidor
mediante Active Directory de grupo y pertenencia a grupos.
Al implementar certificados de servidor, los certificados se basan en una plantilla
que se configura con las instrucciones de esta guía. Esto significa que puede
personalizar diferentes plantillas de certificado para tipos de servidor específicos, o
bien puede usar la misma plantilla para todos los certificados de servidor que
quiera emitir.
Requisitos previos para usar esta guía
En esta guía se proporcionan instrucciones sobre cómo implementar certificados de
servidor mediante AD CS y el rol de servidor servidor web (IIS) en Windows Server 2016.
A continuación se indican los requisitos previos para realizar los procedimientos de esta
guía.

Debe implementar una red principal mediante la Guía de red principal de Windows
Server 2016 Core, o bien ya debe tener las tecnologías proporcionadas en la Guía
de red principal instalada y funcionando correctamente en la red. Estas tecnologías
incluyen TCP/IP v4, DHCP, Active Directory Domain Services (AD DS), DNS y NPS.

７ Nota

La Windows Server 2016 Core Network Guide (Guía de red principal) está
disponible en Windows Server 2016 Technical Library. Para obtener más
información, vea Guía de red principal.

Debe leer la sección de planeamiento de esta guía para asegurarse de que está
preparado para esta implementación antes de realizar la implementación.

Debe realizar los pasos de esta guía en el orden en que se presentan. No salte e
implemente la entidad de certificación sin realizar los pasos que conducen a la
implementación del servidor o se producirá un error en la implementación.

Debe estar preparado para implementar dos servidores nuevos en la red: un

servidor en el que instalará AD CS como una CA raíz de Enterprise y un servidor en
el que instalará servidor web (IIS) para que la ca pueda publicar la lista de
revocación de certificados (CRL) en el servidor web.

７ Nota

Está preparado para asignar una dirección IP estática a los servidores web y AD CS
que implemente con esta guía, así como para asignar un nombre a los equipos
según las convenciones de nomenclatura de la organización. Además, debe unir los
equipos a su dominio.

Qué no incluye esta guía

En esta guía no se proporcionan instrucciones completas para diseñar e implementar
una infraestructura de clave pública (PKI) mediante AD CS. Se recomienda revisar la
documentación AD CS y la documentación de diseño de PKI antes de implementar las
tecnologías de esta guía.

Introducción a las tecnologías

A continuación se muestra información general sobre tecnología AD CS y servidor web
(IIS).

Servicios de certificados de Active Directory

AD CS en Windows Server 2016 proporciona servicios personalizables para crear y
administrar los certificados X.509 que se usan en sistemas de seguridad de software que
emplean tecnologías de clave pública. Las organizaciones pueden AD CS mejorar la
seguridad enlazando la identidad de una persona, dispositivo o servicio a una clave
pública correspondiente. AD CS también incluye características que permiten
administrar la inscripción y revocación de certificados en una variedad de entornos
escalables.

Para obtener más información, vea Información general Servicios de certificados de

Active Directory eGuía de diseño de infraestructura de clave pública .

Servidor web (IIS)

El rol servidor web (IIS) de Windows Server 2016 proporciona una plataforma segura,
fácil de administrar, modular y extensible para hospedar sitios web, servicios y
aplicaciones de forma confiable. Con IIS, puede compartir información con usuarios de
Internet, una intranet o una extranet. IIS es una plataforma web unificada que integra IIS,
[Link], servicios FTP, PHP y Windows Communication Foundation (WCF).

Para obtener más información, vea Web Server (IIS) Overview.

Server Certificate Deployment Overview
Artículo • 21/12/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema se incluyen las siguientes secciones.

Componentes de implementación de certificados de servidor

Introducción al proceso de implementación de certificados de servidor

Componentes de implementación de
certificados de servidor
Puede usar esta guía para instalar Servicios de certificados de Active Directory (AD CS)
como una entidad de certificación raíz (CA) Enterprise e inscribir certificados de servidor
en servidores que ejecutan servidor de directivas de red (NPS), enrutamiento y servicio
de acceso remoto (RRAS) o NPS y RRAS.

Si implementa SDN con autenticación basada en certificados, los servidores deben usar
un certificado de servidor para demostrar sus identidades en otros servidores para que
logren comunicaciones seguras.

En la ilustración siguiente se muestran los componentes necesarios para implementar

certificados de servidor en servidores de la infraestructura de SDN.

７ Nota
 En la ilustración anterior, se muestran varios servidores: DC1, CA1, WEB1 y muchos
servidores SDN. En esta guía se proporcionan instrucciones para implementar y
configurar CA1 y WEB1, y para configurar DC1, que en esta guía se supone que ya
ha instalado en la red. Si aún no ha instalado el dominio de Active Directory, puede
hacerlo mediante la Guía de red principal para Windows Server 2016.

Para obtener más información sobre cada elemento que se muestra en la ilustración
anterior, vea lo siguiente:

CA1

WEB1

DC1

NPS1

CA1 que ejecuta el rol de servidor de AD CS

En este escenario, el Enterprise entidad de certificación raíz (CA) también es una CA
emisora. La ENTIDAD de certificación emite certificados a los equipos servidor que
tienen los permisos de seguridad correctos para inscribir un certificado. Servicios de
certificados de Active Directory (AD CS) está instalado en CA1.

En el caso de las redes más grandes o en las que los problemas de seguridad
proporcionan justificación, puede separar los roles de la ca raíz y la entidad de
certificación emisora, e implementar ca subordinadas que emiten CA.

En las implementaciones más seguras, la entidad de certificación raíz de Enterprise se

desconecta y se protege físicamente.

[Link]
Antes de instalar AD CS, configure el archivo [Link] con una configuración
específica para la implementación.

Copia de la plantilla de certificado de servidores RAS e IAS

Al implementar certificados de servidor, realiza una copia de la plantilla de certificado de

servidores RAS e IAS y, a continuación, configura la plantilla según sus requisitos y las
instrucciones de esta guía.
Utilice una copia de la plantilla en lugar de la plantilla original para que la configuración
de la plantilla original se conserve para su posible uso futuro. Configure la copia de la
plantilla de servidores RAS e IAS para que la entidad de certificación pueda crear
certificados de servidor que emite a los grupos en Usuarios y equipos de Active
Directory que especifique.

Configuración adicional de CA1

La ENTIDAD de certificación publica una lista de revocación de certificados (CRL) que los
equipos deben comprobar para asegurarse de que los certificados que se les presentan
como prueba de identidad son certificados válidos y no se han revocado. Debe
configurar la ENTIDAD de certificación con la ubicación correcta de la CRL para que los
equipos sepan dónde buscar la CRL durante el proceso de autenticación.

WEB1 que ejecuta el rol de servidor servicios web (IIS)

En el equipo que ejecuta el rol de servidor Servidor web (IIS), WEB1, debe crear una
carpeta en Windows Explorer para su uso como ubicación para la CRL y AIA.

Directorio virtual para la CRL y AIA

Después de crear una carpeta en Windows Explorer, debe configurar la carpeta como
directorio virtual en Internet Information Services (IIS) Manager, así como configurar la
lista de control de acceso para el directorio virtual para permitir que los equipos
accedan a AIA y CRL una vez publicados allí.

DC1 que ejecuta los roles de servidor de AD DS y DNS

DC1 es el controlador de dominio y el servidor DNS en la red.

directiva de grupo directiva de dominio predeterminada

Después de configurar la plantilla de certificado en la entidad de certificación, puede
configurar la directiva de dominio predeterminada en directiva de grupo para que los
certificados se inscriban automáticamente en servidores NPS y RAS. directiva de grupo
está configurado en AD DS en el servidor DC1.

Registro de recursos de alias DNS (CNAME)

Debe crear un registro de recursos de alias (CNAME) para el servidor web para
asegurarse de que otros equipos puedan encontrar el servidor, así como el AIA y la CRL
que se almacenan en el servidor. Además, el uso de un registro de recursos CNAME de
alias proporciona flexibilidad para que pueda usar el servidor web para otros fines,
como hospedar sitios web y FTP.

NPS1 que ejecuta el servicio de rol servidor de directivas

de red de la directiva de red y el rol de servidor de Access
Services
NpS se instala al realizar las tareas en la guía de red principal de Windows Server 2016,
por lo que antes de realizar las tareas de esta guía, ya debe tener uno o varios NPS
instalados en la red.

directiva de grupo aplicados y certificados inscritos en servidores

Después de configurar la plantilla de certificado y la inscripción automática, puede

actualizar directiva de grupo en todos los servidores de destino. En este momento, los
servidores inscriben el certificado de servidor de CA1.

Introducción al proceso de implementación de

certificados de servidor

７ Nota

Los detalles de cómo realizar estos pasos se proporcionan en la sección

Implementación de certificados de servidor.

El proceso de configuración de la inscripción de certificados de servidor se produce en

estas fases:

1. En WEB1, instale el rol Servidor web (IIS).

2. En DC1, cree un registro de alias (CNAME) para el servidor web, WEB1.

3. Configure el servidor web para hospedar la CRL desde la ENTIDAD de certificación

y, a continuación, publique la CRL y copie el certificado de ca raíz Enterprise en el
nuevo directorio virtual.

4. En el equipo en el que planea instalar AD CS, asigne al equipo una dirección IP

estática, cambie el nombre del equipo, una el equipo al dominio y, a continuación,
 inicie sesión en el equipo con una cuenta de usuario que sea miembro de los
grupos Administradores de dominio y administradores de Enterprise.

5. En el equipo en el que planea instalar AD CS, configure el archivo [Link] con

valores específicos de la implementación.

6. Instale el rol de servidor de AD CS y realice una configuración adicional de la

ENTIDAD de certificación.

7. Copie el certificado CRL y CA de CA1 en el recurso compartido en el servidor web

WEB1.

8. En la entidad de certificación, configure una copia de la plantilla de certificado de

servidores RAS e IAS. La entidad de certificación emite certificados basados en una
plantilla de certificado, por lo que debe configurar la plantilla para el certificado de
servidor antes de que la ENTIDAD de certificación pueda emitir un certificado.

9. Configurar la inscripción automática de certificados de servidor en una directiva de

grupo. Al configurar la inscripción automática, todos los servidores especificados
con pertenencias a grupos de Active Directory reciben automáticamente un
certificado de servidor cuando se actualiza directiva de grupo en cada servidor. Si
agrega más servidores posteriormente, éstos también recibirán automáticamente
un certificado de servidor.

10. Actualice directiva de grupo en servidores. Cuando se actualiza directiva de grupo,

los servidores reciben el certificado de servidor, que se basa en la plantilla que
configuró en el paso anterior. El servidor usa este certificado para demostrar su
identidad en equipos cliente y otros servidores durante el proceso de
autenticación.

７ Nota

Todos los equipos miembros del dominio reciben automáticamente el

certificado de la ENTIDAD de certificación raíz Enterprise sin la configuración
de la inscripción automática. Este certificado es diferente del certificado de
servidor que se configura y distribuye mediante la inscripción automática. El
certificado de la ENTIDAD de certificación se instala automáticamente en el
almacén de certificados de entidades de certificación raíz de confianza para
todos los equipos miembros del dominio para que confíen en los certificados
emitidos por esta ENTIDAD de certificación.

11. Compruebe que todos los servidores han inscrito un certificado de servidor válido.
Planeación de la implementación del
certificado de servidor
Artículo • 21/12/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Antes de implementar certificados de servidor, debe planear los siguientes elementos:

Planeación de la configuración básica del servidor

Planeación del acceso a un dominio

Planear la ubicación y el nombre del directorio virtual en el servidor web

Planeación de un registro de alias DNS (CNAME) para el servidor web

Planeamiento de la configuración de [Link]

Planeación de la configuración de las extensiones CDP y AIA en CA1

Planear la operación de copia entre la entidad de certificación y el servidor web

Planeación de la configuración de la plantilla de certificado de servidor en la

entidad de certificación

Planeación de la configuración básica del

servidor
Después de instalar Windows Server 2016 en los equipos que planea usar como entidad
de certificación y servidor web, debe cambiar el nombre del equipo y asignar y
configurar una dirección IP estática para el equipo local.

Para obtener más información, consulte la guía Windows Server 2016 Core Network.

Planeación del acceso a un dominio

Para iniciar sesión en el dominio, el equipo debe ser miembro del dominio y la cuenta
de usuario se debe crear en AD DS antes del intento de inicio de sesión. Además, la
mayoría de los procedimientos de esta guía requieren que la cuenta de usuario sea
miembro de los grupos Administradores de Enterprise o Administradores de dominio de
Usuarios y equipos de Active Directory, por lo que debe iniciar sesión en la entidad de
certificación con una cuenta que tenga la pertenencia a grupos adecuada.

Para obtener más información, consulte la guía Windows Server 2016 Core Network.

Planear la ubicación y el nombre del directorio

virtual en el servidor web
Para proporcionar acceso a la CRL y el certificado de entidad de certificación a otros
equipos, debe almacenar estos elementos en un directorio virtual en el servidor web. En
esta guía, el directorio virtual se encuentra en el servidor web WEB1. Esta carpeta está
en la unidad "C:" y se denomina "pki". Puede encontrar el directorio virtual en el servidor
web en cualquier ubicación de carpeta adecuada para la implementación.

Planeación de un registro de alias DNS

(CNAME) para el servidor web
Los registros de recursos de alias (CNAME) a veces se denominan registros de recursos
de nombre canónico. Con estos registros, puede usar más de un nombre para señalar a
un solo host, lo que facilita tareas como el hospedaje de un servidor FTP (Protocolo de
transferencia de archivos) y un servidor web en el mismo equipo. Por ejemplo, los
nombres de servidor conocidos (ftp, www) se registran mediante registros de recursos
de alias (CNAME) que se asignan al nombre de host del Sistema de nombres de
dominio (DNS), como WEB1, para el equipo servidor que hospeda estos servicios.

En esta guía se proporcionan instrucciones para configurar el servidor web para

hospedar la lista de revocación de certificados (CRL) de la entidad de certificación (CA).
Dado que es posible que también quiera usar el servidor web para otros fines, como
hospedar un ftp o un sitio web, es una buena idea crear un registro de recursos de alias
en DNS para el servidor web. En esta guía, el registro CNAME se denomina "pki", pero
puede elegir un nombre adecuado para la implementación.

Planeamiento de la configuración de
[Link]
Antes de instalar AD CS, debe configurar [Link] en la CA con información que sea
correcta para la implementación. Un archivo [Link] contiene la siguiente
información:
 [Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID=[Link].1455.67.89.5
Notice="Legal Policy Statement"
URL=[Link]
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=weeks
CRLPeriodUnits=1
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1

Debe planear los siguientes elementos para este archivo:

Dirección URL. El archivo [Link] de ejemplo tiene un valor de dirección URL

de [Link] . Esto se debe a que el servidor web
de esta guía se denomina WEB1 y tiene un registro de recursos CNAME de DNS de
pki. El servidor web también se une al [Link] web. Además, hay un
directorio virtual en el servidor web denominado "pki" donde se almacena la lista
de revocación de certificados. Asegúrese de que el valor que proporcione para la
dirección URL en el archivo [Link] apunta a un directorio virtual en el servidor
web del dominio.

RenewalKeyLength. La longitud de clave de renovación predeterminada para AD

CS en Windows Server 2012 es 2048. La longitud de clave que seleccione debe ser
lo más larga posible y, al mismo tiempo, proporcionar compatibilidad con las
aplicaciones que piensa usar.

RenewalValidityPeriodUnits. El archivo [Link] de ejemplo tiene un valor

RenewalValidityPeriodUnits de 5 años. Esto se debe a que la duración esperada de
la entidad de certificación es de unos diez años. El valor de
RenewalValidityPeriodUnits debe reflejar el período de validez general de la
entidad de certificación o el mayor número de años para los que desea
proporcionar la inscripción.

CRLPeriodUnits. El archivo [Link] de ejemplo tiene un valor CRLPeriodUnits

de 1. Esto se debe a que el intervalo de actualización de ejemplo para la lista de
revocación de certificados de esta guía es de 1 semana. En el valor de intervalo
que especifique con esta configuración, debe publicar la CRL en la ENTIDAD de
certificación en el directorio virtual del servidor web donde almacena la CRL y
 proporcionar acceso a ella para los equipos que se encuentran en el proceso de
autenticación.

AlternateSignatureAlgorithm. Este archivo [Link] implementa un mecanismo

de seguridad mejorado mediante la implementación de formatos de firma
alternativos. No debe implementar esta configuración si todavía tiene Windows XP
que requieren certificados de esta CA.

Si no tiene previsto agregar ninguna CA subordinada a la infraestructura de clave

pública más adelante y desea evitar la adición de cualquier CA subordinada, puede
agregar la clave PathLength al archivo [Link] con un valor de 0. Para agregar esta
clave, copie y pegue el código siguiente en el archivo:

[BasicConstraintsExtension]
PathLength=0
Critical=Yes

） Importante

No se recomienda cambiar ninguna otra configuración en el archivo [Link] a

menos que tenga una razón específica para hacerlo.

Planeación de la configuración de las

extensiones CDP y AIA en CA1
Al configurar los valores de Punto de distribución de lista de revocación de certificados
(CRL) y Acceso a la información de autoridad (AIA) en CA1, necesitará el nombre del
servidor web y el nombre de dominio. También necesita el nombre del directorio virtual
que cree en el servidor web donde se almacenan la lista de revocación de certificados
(CRL) y el certificado de la entidad de certificación.

La ubicación cdp que debe especificar durante este paso de implementación tiene el
formato:

http:\/\/*DNSAlias\
(CNAME\)RecordName*.*Domain*.com\/*VirtualDirectoryName*\/<CaName><CRLNameSuffix>

<DeltaCRLAllowed>.crl.
Por ejemplo, si el servidor web se denomina WEB1 y el registro CNAME del alias DNS
para el servidor web es "pki", el dominio es [Link] y el directorio virtual se
denomina pki, la ubicación cdp es:

http:\/\/[Link]\/pki\/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

La ubicación de AIA que debe especificar tiene el formato:

http:\/\/*DNSAlias\

(CNAME\)RecordName*.*Domain*.com\/*VirtualDirectoryName*\/<ServerDNSName>\_<CaName>
<CertificateName>.crt.

Por ejemplo, si el servidor web se denomina WEB1 y el registro CNAME del alias DNS
para el servidor web es "pki", el dominio es [Link] y el directorio virtual se
denomina pki, la ubicación de AIA es:

http:\/\/[Link]\/pki\/<ServerDNSName>\_<CaName><CertificateName>.crt

Planear la operación de copia entre la entidad

de certificación y el servidor web
Para publicar la CRL y el certificado de entidad de certificación de la ca en el directorio
virtual del servidor web, puede ejecutar el comando certutil -crl después de configurar
las ubicaciones CDP y AIA en la CA. Asegúrese de configurar las rutas de acceso
correctas en la pestaña Extensiones de propiedades de ca antes de ejecutar este
comando con las instrucciones de esta guía. Además, para copiar el certificado de
Enterprise CA en el servidor web, debe haber creado el directorio virtual en el servidor
web y configurado la carpeta como una carpeta compartida.

Planeación de la configuración de la plantilla

de certificado de servidor en la entidad de
certificación
Para implementar certificados de servidor inscritos automáticamente, debe copiar la
plantilla de certificado denominada RAS y el servidor IAS. De forma predeterminada,
esta copia se denomina Copia de RAS y servidor IAS. Si desea cambiar el nombre de
esta copia de plantilla, planee el nombre que desea usar durante este paso de
implementación.

７ Nota
Las tres últimas secciones de implementación de esta guía, que permiten
configurar la inscripción automática de certificados de servidor, actualizar directiva
de grupo en los servidores y comprobar que los servidores han recibido un
certificado de servidor válido de la CA, no requieren pasos de planeamiento
adicionales.
Implementación de certificados de
servidor
Artículo • 21/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Siga estos pasos para instalar una entidad de certificación raíz (CA) empresarial e
implementar certificados de servidor para su uso con PEAP y EAP.

） Importante

Antes de instalar Servicios de certificados de Active Directory, debe dar nombre al

equipo, configurar el equipo con una dirección IP estática y unir el equipo al
dominio. Después de instalar AD CS, no puede cambiar el nombre del equipo ni la
pertenencia al dominio del equipo, pero puede cambiar la dirección IP si es
necesario. Para obtener más información sobre cómo realizar estas tareas, consulte
la guía de Windows Server® 2016 Core Network.

Instalar la WEB1 de servidor web

Crear un registro de alias (CNAME) en DNS para WEB1

Configuración de WEB1 para distribuir listas de revocación de certificados (CRL)

Preparación del archivo INF CAPolicy

Instalar la entidad de certificación

Configuración de las extensiones CDP y AIA en CA1

Copiar el certificado de entidad de certificación y la CRL en el directorio virtual

Configurar la plantilla de certificado de servidor

Configurar la inscripción automática de certificados de servidor

Actualizar directiva de grupo

Comprobar la inscripción de servidor de un certificado de servidor

７ Nota
Los procedimientos de esta guía no incluyen instrucciones para los casos en que se
abre el cuadro de diálogo Control de cuentas de usuario para solicitar permiso
para continuar. Si aparece este cuadro de diálogo en respuesta a sus acciones
mientras realiza los procedimientos de esta guía, haga clic en Continuar.
Instalar la WEB1 de servidor web
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

El rol servidor web (IIS) de Windows Server 2016 proporciona una plataforma segura,
fácil de administrar, modular y extensible para hospedar sitios web, servicios y
aplicaciones de forma confiable. Con IIS, puede compartir información con usuarios de
Internet, una intranet o una extranet. IIS es una plataforma web unificada que integra IIS,
[Link], servicios FTP, PHP y Windows Communication Foundation (WCF).

Al implementar certificados de servidor, el servidor web proporciona una ubicación

donde puede publicar la lista de revocación de certificados (CRL) para la entidad de
certificación (CA). Después de la publicación, todos los equipos de la red pueden
acceder a la CRL para que puedan usar esta lista durante el proceso de autenticación
para comprobar que no se revocan los certificados presentados por otros equipos.

Si un certificado está en la CRL como revocado, se produce un error en el esfuerzo de

autenticación y el equipo está protegido contra la confianza de una entidad que tiene
un certificado que ya no es válido.

Antes de instalar el rol servidor web (IIS), asegúrese de que ha configurado el nombre
del servidor y la dirección IP y que ha unido el equipo al dominio.

Para instalar el rol de servidor web (IIS)

Para completar este procedimiento, debe pertenecer al grupo Administradores.

７ Nota

Para realizar este procedimiento mediante Windows PowerShell, abra PowerShell,

escriba el siguiente comando y presione ENTRAR. Install-WindowsFeature Web-
Server -IncludeManagementTools

1. En el Administrador del servidor, haga clic en Administrar y en Agregar roles y

características. Se abre el Asistente para agregar roles y características.
2. En Antes de comenzar, haga clic en Siguiente.

Nota La página Antes de comenzar del Asistente para agregar roles y características no
se muestra si previamente ha ejecutado el Asistente para agregar roles y características
y ha seleccionado Omitir esta página de forma predeterminada en ese momento.

3. En la página Tipo de instalación, haga clic en Siguiente.

4. En la página Selección del servidor , haga clic en Siguiente.
5. En la página Roles de servidor , seleccione Servidor web (IIS) y, a continuación,
haga clic en Siguiente.
6. Haga clic en Siguiente hasta haber aceptado todas las configuraciones
predeterminadas del servidor web y, a continuación, haga clic en Instalar.
7. Compruebe que todas las instalaciones se realizaron correctamente y, a
continuación, haga clic en Cerrar.
Crear un registro de alias (CNAME) en
DNS para WEB1
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para agregar un registro de recursos de nombre

canónico alias (CNAME) para el servidor web a una zona en DNS en el controlador de
dominio. Con los registros CNAME, puede usar más de un nombre para apuntar a un
único host, lo que facilita realizar tareas como hospedar un servidor de Protocolo de
transferencia de archivos (FTP) y un servidor web en el mismo equipo.

Por este motivo, puede usar el servidor web para hospedar la lista de revocación de
certificados (CRL) para la entidad de certificación (CA), así como para realizar servicios
adicionales, como FTP o servidor web.

Al realizar este procedimiento, reemplace Alias name y otras variables por valores
adecuados para la implementación.

Para realizar este procedimiento, debe ser miembro de administradores de dominio.

Para agregar un registro de recursos de alias

(CNAME) a una zona

７ Nota

Para realizar este procedimiento mediante Windows PowerShell, vea Add-

DnsServerResourceRecordCName.

1. En DC1, en Administrador del servidor, haga clic en Herramientas y, a

continuación, haga clic en DNS. Se abre microsoft Management Console (MMC)
del Administrador dns.

2. En el árbol de consola, haga doble clic en Zonas de búsqueda directa, haga clic
con el botón derecho en la zona de búsqueda directa donde desea agregar el
registro de recursos Alias y, a continuación, haga clic en Nuevo alias (CNAME). Se
abre el cuadro de diálogo Nuevo registro de recursos .

3. En Nombre de alias, escriba el nombre de alias pki.

4. Al escribir un valor para Nombre de alias, el nombre de dominio completo
(FQDN) rellena automáticamente en el cuadro de diálogo. Por ejemplo, si el
nombre del alias es "pki" y el dominio es [Link], el valor
[Link] se rellena automáticamente.

5. En Nombre de dominio completo (FQDN) para el host de destino, escriba el

FQDN del servidor web. Por ejemplo, si el servidor web se denomina WEB1 y el
dominio está [Link], escriba [Link].

6. Haga clic en Aceptar para agregar el nuevo registro a la zona.

Configurar WEB1 para distribuir listas de
revocación de certificados (CRL)
Artículo • 21/12/2022 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para configurar el servidor web WEB1 para distribuir las
CRL.

En las extensiones de la CA raíz, se indicó que la CRL de la CA raíz estaría disponible a

través de [Link] . Actualmente, no hay un directorio virtual
PKI en WEB1, por lo que se debe crear uno.

Para realizar este procedimiento, debe ser miembro de Administradores de dominio.

７ Nota

En el procedimiento siguiente, reemplace el nombre de la cuenta de usuario, el

nombre del servidor web, los nombres de carpeta y las ubicaciones, y otros valores
por los que sean adecuados para la implementación.

Para configurar WEB1 para distribuir certificados y CRL

1. En WEB1, ejecute Windows PowerShell administrador, escriba explorer c:\ y
presione ENTRAR. Windows Explorer se abre en la unidad C.

2. Cree una carpeta denominada PKI en la unidad C:. Para ello, haga clic en Inicioy, a
continuación, haga clic en Nueva carpeta. Se crea una nueva carpeta con el
nombre temporal resaltado. Escriba pki y presione ENTRAR.

3. En Windows, haga clic con el botón derecho en la carpeta que acaba de crear,
mantenga el cursor del mouse sobre Compartir con y, a continuación, haga clic en
Usuarios específicos. Se abre el cuadro de diálogo Archivos compartidos.

4. En Uso compartido de archivos, escriba Publicadores de certificadosy, a

continuación, haga clic en Agregar. El grupo Publicadores de certificados se
agrega a la lista. En la lista, en Nivel de permiso, haga clic en la flecha situada
junto a Publicadores de certificados y, a continuación, haga clic en Lectura y
escritura. Haga clic en Compartiry, a continuación, haga clic en Listo.
 5. Cierre el Explorador de Windows.

6. Abra la consola de IIS. En Administrador del servidor, haga clic en Herramientas y,

a continuación, haga clic en Administrador de Internet Information Services (IIS).

7. En el árbol Internet Information Services de consola del Administrador de Internet

Information Services (IIS), expanda WEB1. Si se le invita a ver una introducción a la
Plataforma web de Microsoft, haga clic en Cancelar.

8. Expanda Sitios y haga clic con el botón secundario en Default Web Site; a
continuación, haga clic en Agregar directorio virtual.

9. En Alias, escriba pki. En Ruta de acceso física , escriba C:\pki y haga clic en
Aceptar.

10. Habilite el acceso anónimo al directorio virtual pki para que cualquier cliente
pueda comprobar la validez de los certificados de entidad de certificación y las
CRL. Para ello:

a. En el panel Conexiones, asegúrese de que la opción pki esté activada.

b. En Página principal de pki, haga clic en Autenticación.

c. En el panel Acciones, haga clic en Editar permisos.

d. En la pestaña Seguridad, haga clic en Editar.

e. En el cuadro de diálogo Permisos de pki, haga clic en Agregar.

f. En Seleccionar usuarios, equipos, cuentas de servicio o grupos, escriba

ANONYMOUS LOGON; Todos y , a continuación, haga clic en Comprobar
nombres. Haga clic en OK.

g. Haga clic en Aceptar en el cuadro de diálogo Seleccionar usuarios, equipos,

cuentas de servicio o grupos.

h. Haga clic en Aceptar en el cuadro de diálogo Permisos para pki .

11. Haga clic en Aceptar en el cuadro de diálogo Propiedades de pki .

12. En el panel Página principal de pki, haga doble clic en Filtrado de solicitudes.

13. La pestaña Extensiones de nombre de archivo se selecciona de manera

predeterminada en el panel Filtrado de solicitudes. En el panel Acciones, haga clic
en Modificar configuración de característica.
14. En Modificar configuración del filtrado de solicitudes, active Permitir doble
escape y, a continuación, haga clic en Aceptar.

15. En el administrador Internet Information Services (IIS), haga clic en el nombre del
servidor web. Por ejemplo, si el servidor web se denomina WEB1, haga clic en
WEB1.

16. En Acciones, haga clic en Reiniciar. Los servicios de Internet se detienen y luego se
reinician.
Sintaxis [Link]
Artículo • 21/12/2022 • Tiempo de lectura: 10 minutos

Se aplica a: Windows Server 2016

[Link] es un archivo de configuración que define las extensiones, restricciones y

otras opciones de configuración que se aplican a un certificado de CA raíz y todos los
certificados emitidos por la ENTIDAD de certificación raíz. El archivo [Link] debe
instalarse en un servidor host antes de que comience la rutina de instalación de la
entidad de certificación raíz. Cuando se modifican las restricciones de seguridad en una
entidad de certificación raíz, se debe renovar el certificado raíz y se debe instalar un
archivo [Link] actualizado en el servidor antes de que comience el proceso de
renovación.

[Link] es:

Creado y definido manualmente por un administrador

Se utiliza durante la creación de certificados de entidad de certificación raíz y

subordinada

Se define en la entidad de certificación de firma en la que firma y emite el

certificado (no la ENTIDAD de certificación en la que se concede la solicitud).

Una vez que haya creado el archivo [Link], debe copiarlo en la carpeta
%systemroot% del servidor antes de instalar ADCS o renovar el certificado de CA.

[Link] permite especificar y configurar una amplia variedad de atributos y

opciones de CA. En la sección siguiente se describen todas las opciones para crear un
archivo .inf adaptado a sus necesidades específicas.

Estructura de archivos [Link]

Los términos siguientes se usan para describir la estructura del archivo .inf:

Sección : es un área del archivo que cubre un grupo lógico de claves. Los nombres
de sección de los archivos .inf se identifican entre corchetes. Muchas secciones,
pero no todas, se usan para configurar extensiones de certificado.

Clave : es el nombre de una entrada y aparece a la izquierda del signo igual.

Valor : es el parámetro y aparece a la derecha del signo igual.

En el ejemplo siguiente, [Version] es la sección, Signature es la clave y "$Windows NT$"
es el valor.

Ejemplo:

[Version]
Signature="$Windows NT$"

Versión
Identifica el archivo como un archivo .inf. La versión es la única sección necesaria y debe
estar al principio del archivo [Link].

PolicyStatementExtension
Enumera las directivas definidas por la organización y si son opcionales o obligatorias.
Varias directivas están separadas por comas. Los nombres tienen significado en el
contexto de una implementación específica o en relación con las aplicaciones
personalizadas que comprueban la presencia de estas directivas.

Para cada directiva definida, debe haber una sección que defina la configuración de esa
directiva en particular. Para cada directiva, debe proporcionar un identificador de objeto
definido por el usuario (OID) y el texto que quiera mostrar como la instrucción de
directiva o un puntero de dirección URL a la instrucción de directiva. La dirección URL
puede tener la forma de una dirección URL HTTP, FTP o LDAP.

Si va a tener texto descriptivo en la instrucción de directiva, las tres líneas siguientes de

[Link] tendrán el siguiente aspecto:

[InternalPolicy]
OID=[Link].1.1.1
Notice="Legal policy statement text"

Si va a usar una dirección URL para hospedar la instrucción de directiva de entidad de

certificación, las tres líneas siguientes tendría el siguiente aspecto:

[InternalPolicy]
OID=[Link].1.1.2
 URL=[Link]

Además:

Se admiten varias direcciones URL y claves de aviso.

Se admiten las claves de dirección URL y aviso en la misma sección de directiva.

Las direcciones URL con espacios o texto con espacios deben estar entre comillas.
Esto es así para la clave de dirección URL , independientemente de la sección en la
que aparezca.

Un ejemplo de varias notificaciones y direcciones URL en una sección de directiva

tendría el siguiente aspecto:

[InternalPolicy]
OID=[Link].1.1.1
URL=[Link]
URL=[Link]
Notice="Legal policy statement text"

CRLDistributionPoint
Puede especificar puntos de distribución de CRL (CDP) para un certificado de CA raíz en
[Link]. Después de instalar la ENTIDAD de certificación, puede configurar las
direcciones URL de CDP que la ENTIDAD de certificación incluye en cada certificado
emitido. El certificado de CA raíz muestra las direcciones URL especificadas en esta
sección del archivo [Link].

[CRLDistributionPoint]
URL=[Link]

Información adicional sobre esta sección:

Es compatible con:
HTTP
Direcciones URL de archivo
Direcciones URL LDAP
Varias direcciones URL
 ） Importante

No admite direcciones URL HTTPS.

Las comillas deben rodear las direcciones URL con espacios.

Si no se especifica ninguna dirección URL ( es decir, si la sección

[CRLDistributionPoint] existe en el archivo, pero está vacía, se omite la extensión
punto de distribución crL del certificado de ca raíz. Esto suele ser preferible al
configurar una entidad de certificación raíz. Windows no realiza la comprobación
de revocación en un certificado de entidad de certificación raíz, por lo que la
extensión CDP es superflua en un certificado de CA raíz.

La entidad de certificación puede publicar en FILE UNC, por ejemplo, en un recurso

compartido que representa la carpeta de un sitio web donde un cliente recupera a
través de HTTP.

Use esta sección solo si va a configurar una entidad de certificación raíz o renovar
el certificado de ca raíz. La ENTIDAD de certificación determina las extensiones de
CDP de CA subordinadas.

AuthorityInformationAccess
Puede especificar los puntos de acceso de información de autoridad en [Link]
para el certificado de CA raíz.

[AuthorityInformationAccess]
URL=[Link]

Algunas notas adicionales sobre la sección acceso a la información de autoridad:

Se admiten varias direcciones URL.

Se admiten direcciones URL HTTP, FTP, LDAP y FILE. No se admiten direcciones

URL HTTPS.

Esta sección solo se usa si va a configurar una entidad de certificación raíz o

renovar el certificado de ca raíz. Las extensiones de CA AIA subordinadas vienen
determinadas por la ENTIDAD de certificación que emitió el certificado de la
ENTIDAD de certificación subordinada.
 Las direcciones URL con espacios deben estar rodeadas de comillas.

Si no se especifica ninguna dirección URL ( es decir, si la sección

[AuthorityInformationAccess] existe en el archivo, pero está vacía, la extensión
acceso a la información de autoridad se omite del certificado de ca raíz. De nuevo,
esta sería la configuración preferida en el caso de un certificado de ENTIDAD de
certificación raíz, ya que no hay ninguna autoridad superior a una ca raíz a la que
tendría que hacer referencia un vínculo a su certificado.

certsrv_Server
Otra sección opcional de [Link] es [certsrv_server], que se usa para especificar la
longitud de la clave de renovación, el período de validez de la renovación y el período
de validez de la lista de revocación de certificados (CRL) para una ENTIDAD de
certificación que se está renuevando o instalando. No se requiere ninguna de las claves
de esta sección. Muchos de estos valores tienen valores predeterminados que son
suficientes para la mayoría de las necesidades y simplemente se pueden omitir del
archivo [Link]. Como alternativa, muchas de estas opciones se pueden cambiar
después de instalar la ENTIDAD de certificación.

Un ejemplo tendría el siguiente aspecto:

[certsrv_server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=Days
CRLPeriodUnits=2
CRLDeltaPeriod=Hours
CRLDeltaPeriodUnits=4
ClockSkewMinutes=20
LoadDefaultTemplates=True
AlternateSignatureAlgorithm=0
ForceUTF8=0
EnableKeyCounting=0

RenewalKeyLength establece el tamaño de clave solo para la renovación. Esto solo se

usa cuando se genera un nuevo par de claves durante la renovación del certificado de
entidad de certificación. El tamaño de clave del certificado de CA inicial se establece
cuando se instala la ENTIDAD de certificación.

Al renovar un certificado de entidad de certificación con un nuevo par de claves, la

longitud de la clave puede aumentarse o disminuirse. Por ejemplo, si ha establecido un
tamaño de clave de entidad de certificación raíz de 4096 bytes o superior y, a
continuación, descubre que tiene aplicaciones Java o dispositivos de red que solo
pueden admitir tamaños de clave de 2048 bytes. Tanto si aumenta o disminuye el
tamaño, debe volver a emitir todos los certificados emitidos por esa ENTIDAD de
certificación.

RenewalValidityPeriod y RenewalValidityPeriodUnits establecen la vigencia del nuevo

certificado de CA raíz al renovar el certificado de CA raíz anterior. Solo se aplica a una
entidad de certificación raíz. La duración del certificado de una ENTIDAD de certificación
subordinada viene determinada por su superior. RenewalValidityPeriod puede tener los
siguientes valores: Horas, Días, Semanas, Meses y Años.

CRLPeriod y CRLPeriodUnits establecen el período de validez de la CRL base. CRLPeriod

puede tener los siguientes valores: Horas, Días, Semanas, Meses y Años.

CRLDeltaPeriod y CRLDeltaPeriodUnits establecen el período de validez de la CRL delta.

CRLDeltaPeriod puede tener los siguientes valores: Horas, Días, Semanas, Meses y Años.

Cada una de estas opciones se puede configurar después de instalar la ENTIDAD de

certificación:

Certutil -setreg CACRLPeriod Weeks

Certutil -setreg CACRLPeriodUnits 1
Certutil -setreg CACRLDeltaPeriod Days
Certutil -setreg CACRLDeltaPeriodUnits 1

No olvide reiniciar Servicios de certificados de Active Directory para que los cambios
surtan efecto.

LoadDefaultTemplates solo se aplica durante la instalación de una CA de Enterprise.

Esta configuración, ya sea True o False (o 1 o 0), determina si la entidad de certificación
está configurada con cualquiera de las plantillas predeterminadas.

En una instalación predeterminada de la ENTIDAD de certificación, se agrega un

subconjunto de las plantillas de certificado predeterminadas a la carpeta Plantillas de
certificado en el complemento Entidad de certificación. Esto significa que tan pronto
como se inicie el servicio AD CS después de instalar el rol un usuario o equipo con
permisos suficientes puede inscribirse inmediatamente para un certificado.

Es posible que no quiera emitir ningún certificado inmediatamente después de instalar

una CA, por lo que puede usar la configuración LoadDefaultTemplates para evitar que
las plantillas predeterminadas se agreguen a la ca de Enterprise. Si no hay plantillas
configuradas en la ENTIDAD de certificación, no puede emitir ningún certificado.

AlternateSignatureAlgorithm configura la ENTIDAD de certificación para admitir el

formato de firma PKCS#1 V2.1 para las solicitudes de certificado y certificado de ca.
Cuando se establece en 1 en una entidad de certificación raíz, el certificado de ENTIDAD
de certificación incluirá el formato de firma PKCS#1 V2.1. Cuando se establece en una
entidad de certificación subordinada, la entidad de certificación subordinada creará una
solicitud de certificado que incluye el formato de firma PKCS#1 V2.1.

ForceUTF8 cambia la codificación predeterminada de nombres distintivos relativos

(RDN) en los nombres distintivos del firmante y del emisor a UTF-8. Solo los RDN que
admiten UTF-8, como los definidos como tipos de cadena de directorio por una RFC, se
ven afectados. Por ejemplo, el RDN para componente de dominio (DC) admite la
codificación como IA5 o UTF-8, mientras que el RDN de país (C) solo admite la
codificación como una cadena imprimible. Por lo tanto, la directiva ForceUTF8 afectará a
un RDN de DC, pero no afectará a un RDN de C.

EnableKeyCounting configura la ENTIDAD de certificación para incrementar un

contador cada vez que se usa la clave de firma de la entidad de certificación. No habilite
esta configuración a menos que tenga un módulo de seguridad de hardware (HSM) y un
proveedor de servicios criptográficos (CSP) asociado que admita el recuento de claves.
Ni el CSP seguro de Microsoft ni la clave de software de Microsoft Storage proveedor
(KSP) admiten el recuento de claves.

Creación del archivo [Link]

Antes de instalar AD CS, configure el archivo [Link] con una configuración
específica para la implementación.

Requisito previo: Debe ser miembro del grupo Administradores.

1. En el equipo en el que planea instalar AD CS, abra Windows PowerShell, escriba el

Bloc de notas c:\[Link] y presione ENTRAR.

2. Cuando se le pida que cree un archivo nuevo, haga clic en Sí.

3. Como contenido del archivo, escriba lo siguiente:

[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
 Policies=InternalPolicy
[InternalPolicy]
OID=[Link].1455.67.89.5
Notice="Legal Policy Statement"
URL=[Link]
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=weeks
CRLPeriodUnits=1
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1
[CRLDistributionPoint]
[AuthorityInformationAccess]

4. Haga clic en Archivoy, a continuación, haga clic en Guardar como.

5. Vaya a la carpeta %systemroot%.

6. Asegúrese de lo siguiente:

El Nombre de archivo está establecido en [Link]

Tipo esté establecido en Todos los archivos

Codificación sea ANSI

7. Haga clic en Save(Guardar).

8. Cuando se le pregunte si desea sobrescribir el archivo, haga clic en Sí.

 Ｕ Precaución

Asegúrese de guardar el archivo [Link] con la extensión inf. Si no

escribes específicamente .inf al final de un nombre de archivo y seleccionas
las opciones de la manera descrita, el archivo se guardará como un archivo de
texto y no se usará durante la instalación de la entidad de certificación.

9. Cierre el Bloc de notas.

） Importante

En [Link], puede ver que hay una línea que especifica la dirección URL
[Link] . La sección Internal Policy del archivo
[Link] se muestra como ejemplo de cómo se especificaría la ubicación de una
orden de prácticas de certificación (CPS). En esta guía, no se le indica que cree la
instrucción de práctica de certificado (CPS).
Instalar la entidad de certificación
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para instalar Servicios de certificados de Active Directory
(AD CS) para poder inscribir un certificado de servidor en servidores que ejecutan
servidor de directivas de red (NPS), servicio de enrutamiento y acceso remoto (RRAS) o
ambos.

） Importante

Antes de instalar Servicios de certificados de Active Directory, debe dar

nombre al equipo, configurar el equipo con una dirección IP estática y unir el
equipo al dominio. Para obtener más información sobre cómo realizar estas
tareas, consulte la guía de Windows Server 2016 Core Network.
Para realizar este procedimiento, el equipo en el que se va a instalar AD CS
debe unirse a un dominio donde están instalados los Servicios de dominio de
Active Directory (AD DS).

El requisito mínimo para completar este procedimiento es la pertenencia al grupo

Administradores de empresas y al grupo Admins. del dominio del dominio raíz.

７ Nota

Para realizar este procedimiento mediante Windows PowerShell, abra Windows

PowerShell escriba el siguiente comando y presione ENTRAR.

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

Una AD CS instalado, escriba el siguiente comando y presione ENTRAR.

Install-AdcsCertificationAuthority -CAType EnterpriseRootCA

Para instalar los Servicios de certificados de

Active Directory
 Sugerencia

Si desea usar Windows PowerShell para instalar Servicios de certificados de Active

Directory, consulte Install-AdcsCertificationAuthority for cmdlets and optional
parameters (Install-AdcsCertificationAuthority para cmdlets y parámetros
opcionales).

1. Inicie sesión como miembro del grupo Administradores de empresas y del grupo
Admins. del dominio del dominio raíz.

2. En el Administrador del servidor, haga clic en Administrar y en Agregar roles y

características. Se abre el Asistente para agregar roles y características.

3. En Antes de comenzar, haga clic en Siguiente.

７ Nota

La página Antes de comenzar del Asistente para agregar roles y

características no se muestra si ha seleccionado anteriormente Omitir esta
página de forma predeterminada al ejecutar el asistente.

4. En Seleccionar tipo de instalación, asegúrese de que la opción Instalación basada

en características o en roles está seleccionada y, a continuación, haga clic en
Siguiente.

5. En Seleccionar servidor de destino, asegúrese de que la opción Seleccionar un

servidor del grupo de servidores está seleccionada. En Grupo de servidores,
asegúrese de que el equipo local está seleccionado. Haga clic en Siguiente.

6. En Seleccionar roles de servidor, en Roles, seleccione Servicios de certificados de

Active Directory. Cuando se le pida que agregue las características necesarias,
haga clic en Agregar característicasy, a continuación, haga clic en Siguiente.

7. En Seleccionar características, haga clic en Siguiente.

8. En Servicios de certificados de Active Directory, lea la información proporcionada

y, a continuación, haga clic en Siguiente.

9. En Confirmar selecciones de instalación, haga clic en Instalar. No cierre el

asistente durante el proceso de instalación. Una vez completada la instalación,
haga clic en Configurar Servicios de certificados de Active Directory en el
servidor de destino. Se abre AD CS Asistente para configuración de archivos. Lea
 la información de credenciales y, si es necesario, proporcione las credenciales de
una cuenta que sea miembro del grupo Enterprise administradores. Haga clic en
Siguiente.

10. En Servicios de rol, haga clic en Entidad de certificacióny, a continuación, haga

clic en Siguiente.

11. En la página Tipo de instalación , compruebe que Enterprise ca está seleccionada

y, a continuación, haga clic en Siguiente.

12. En la página Especificar el tipo de ca , compruebe que la CA raíz está seleccionada

y, a continuación, haga clic en Siguiente.

13. En la página Especificar el tipo de la clave privada, compruebe que está

seleccionada la opción Crear una nueva clave privada y, a continuación, haga clic
en Siguiente.

14. En la página Criptografía para CA, mantenga la configuración predeterminada de

CSP (RSA#Microsoft Software Key Storage Provider) y el algoritmo hash (SHA2) y
determine la mejor longitud de caracteres clave para la implementación. Las
longitudes de caracteres clave grandes proporcionan una seguridad óptima; sin
embargo, pueden afectar al rendimiento del servidor y es posible que no sean
compatibles con las aplicaciones heredadas. Se recomienda mantener la
configuración predeterminada de 2048. Haga clic en Siguiente.

15. En la página Nombre de ca, mantenga el nombre común sugerido para la CA o

cámbie el nombre según sus requisitos. Asegúrese de que está seguro de que el
nombre de la entidad de certificación es compatible con sus convenciones y
propósitos de nomenclatura, ya que no puede cambiar el nombre de la entidad de
certificación después de haber instalado AD CS. Haga clic en Siguiente.

16. En la página Período de validez , en Especificar el período de validez, escriba el

número y seleccione un valor de tiempo (Años, Meses, Semanas o Días). Se
recomienda el valor predeterminado de cinco años. Haga clic en Siguiente.

17. En la página Base de datos de ca, en Especificar las ubicaciones de la base de

datos, especifique la ubicación de la carpeta para la base de datos de certificados y
el registro de la base de datos de certificados. Si especifica ubicaciones distintas de
las ubicaciones predeterminadas, asegúrese de que las carpetas estén protegidas
mediante listas de control de acceso (ACL) que impidan que usuarios o equipos no
autorizados tengan acceso a los archivos de registro y la base de datos de la
entidad de certificación. Haga clic en Siguiente.
18. En Confirmación, haga clic en Configurar para aplicar las selecciones y, a
continuación, haga clic en Cerrar.
Configurar las extensiones AIA y CDP en
CA1
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para configurar los valores de Punto de distribución de
lista de revocación de certificados (CRL) (CDP) y Acceso a la información de autoridad
(AIA) en CA1.

Para realizar este procedimiento, debe ser miembro de Administradores de dominio.

Para configurar las extensiones CDP y AIA en CA1

1. En Administrador del servidor, haga clic en Herramientas y, a continuación, haga
clic en Entidad de certificación.

2. En el árbol de consola de entidad de certificación, haga clic con el botón derecho

en corp-CA1-CAy, a continuación, haga clic en Propiedades.

７ Nota

El nombre de la entidad de certificación es diferente si no ha llamado al

equipo CA1 y el nombre de dominio es diferente del de este ejemplo. El
nombre de la entidad de certificación tiene el formato
dominioCAComputerName-CA.

3. Haga clic en la pestaña Extensiones. Asegúrese de que Select extension

(Seleccionar extensión) está establecido en CRL Distribution Point (CDP) (Punto
de distribución de CRL [CDP]) y, en Especificar ubicaciones desde las que los
usuarios pueden obtener una lista de revocación de certificados (CRL), haga lo
siguiente:

a. Seleccione la entrada y [Link]

<CRLNameSuffix><DeltaCRLAllowed>.crl , a continuación, haga clic [Link]

<ServerDNSName>\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl . En

Confirmar eliminación, haga clic en Sí.

 b. Seleccione la entrada y [Link]
<CRLNameSuffix><DeltaCRLAllowed>.crl , a continuación, haga clic
[Link]

<DeltaCRLAllowed>.crl . En Confirmar eliminación, haga clic en Sí.

c. Seleccione la entrada que comienza por la ruta de acceso ldap:///CN=

<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName> y, a continuación, haga

clic en ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName> . En
Confirmar eliminación, haga clic en Sí.

4. En Especificar ubicaciones desde las que los usuarios pueden obtener una lista
de revocación de certificados (CRL), haga clic en Agregar. Se abre el cuadro de
diálogo Agregar ubicación.

5. En Agregar ubicación, en Ubicación, escriba y, a continuación, haga clic en

Aceptar. Esto le devuelve al cuadro de diálogo Propiedades de la entidad de
certificación.

6. En la pestaña Extensiones , active las casillas siguientes:

Incluir en las CRL Los clientes lo usan para buscar las ubicaciones de CRL
diferenciales.

Incluir en la extensión CDP de los certificados emitidos

7. En Especificar ubicaciones desde las que los usuarios pueden obtener una lista
de revocación de certificados (CRL), haga clic en Agregar. Se abre el cuadro de
diálogo Agregar ubicación.

8. En Agregar ubicación, en Ubicación, escriba y, a continuación, haga clic en

Aceptar. Esto le devuelve al cuadro de diálogo Propiedades de la entidad de
certificación.

9. En la pestaña Extensiones , active las casillas siguientes:

Publicar las listas de revocación de certificados (CRL) en esta ubicación

Publicación de CRL diferenciales en esta ubicación

10. Cambie Seleccionar extensión a Acceso a la información de autoridad (AIA) y, en

Especificar ubicaciones desde las que los usuarios pueden obtener una lista de
revocación de certificados (CRL), haga lo siguiente:

a. Seleccione la entrada que comienza por la ruta de acceso ldap:///CN=

<CATruncatedName>,CN=AIA,CN=Public Key Services y, a continuación, haga clic en
 ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services . En Confirmar

eliminación, haga clic en Sí.

b. Seleccione la entrada y
[Link]
<CertificateName>.crt , a continuación, haga clic

[Link]

<CertificateName>.crt . En Confirmar eliminación, haga clic en Sí.

c. Seleccione la entrada y [Link]

<CaName><CertificateName>.crt , a continuación, haga clic [Link]
<ServerDNSName>\CertEnroll\<ServerDNSName><CaName><CertificateName>.crt . En

Confirmar eliminación, haga clic en Sí.

11. En Especificar ubicaciones desde las que los usuarios pueden obtener el
certificado para esta CA, haga clic en Agregar. Se abre el cuadro de diálogo
Agregar ubicación.

12. En Agregar ubicación, en Ubicación, escriba y, a continuación, haga clic en

Aceptar. Esto le devuelve al cuadro de diálogo Propiedades de la entidad de
certificación.

13. En la pestaña Extensiones , seleccione Incluir en la AIA de certificados emitidos.

14. Cuando se le pida que reinicie Servicios de certificados de Active Directory, haga
clic en No. Reiniciará el servicio más adelante.
Copia del certificado de entidad de
certificación y la CRL en el directorio
virtual
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para copiar la lista de revocación de certificados y

Enterprise certificado de entidad de certificación raíz de la entidad de certificación en un
directorio virtual del servidor web y para asegurarse de que AD CS está configurado
correctamente. Antes de ejecutar los comandos siguientes, asegúrese de reemplazar los
nombres de directorio y servidor por los adecuados para la implementación.

Para realizar este procedimiento, debe ser miembro de administradores de dominio.

Para copiar la lista de revocación de certificados de CA1 a WEB1

1. En CA1, ejecute Windows PowerShell como administrador y, a continuación,

publique la CRL con el siguiente comando:

Escriba certutil -crl y presione ENTRAR.

Para copiar el certificado CA1 en el recurso compartido de archivos en el

servidor web, escriba copy C:\Windows\system32\certsrv\certenroll\*.crt
\\WEB1\pki y presione ENTRAR.

Para copiar las listas de revocación de certificados en el recurso compartido

de archivos en el servidor web, escriba copy
C:\Windows\system32\certsrv\certenroll\*.crl \\WEB1\pki y presione

ENTRAR.

2. Para comprobar que las ubicaciones de la extensión CDP y AIA están configuradas
correctamente, escriba [Link] y presione ENTRAR. Se abre pkiview Enterprise
MMC PKI.

3. En el panel izquierdo, haga clic en el nombre de la entidad de certificación.

Por ejemplo, si el nombre de la entidad de certificación es corp-CA1-CA, haga clic

en corp-CA1-CA.
4. En la columna Estado del panel de resultados, compruebe que los valores de lo
siguiente muestran Ok:

Certificado de ENTIDAD de certificación

Ubicación de AIA n.º 1
Ubicación de CDP n.º 1

 Sugerencia

Si el estado de cualquier elemento no es correcto, haga lo siguiente:

Abra el recurso compartido en el servidor web para comprobar que los

archivos de lista de revocación de certificados y certificados se copiaron
correctamente en el recurso compartido. Si no se copiaron correctamente en
el recurso compartido, modifique los comandos de copia con el origen de
archivo correcto y el destino del recurso compartido y vuelva a ejecutar los
comandos.
Compruebe que ha escrito las ubicaciones correctas para cdp y AIA en la
pestaña Extensiones de CA. Asegúrese de que no haya espacios adicionales ni
otros caracteres en las ubicaciones proporcionadas.
Compruebe que copió el certificado CRL y ca en la ubicación correcta en el
servidor web y que la ubicación coincide con la ubicación proporcionada para
las ubicaciones de CDP y AIA en la CA.
Compruebe que ha configurado correctamente los permisos para la carpeta
virtual donde se almacenan el certificado de ENTIDAD de certificación y la
CRL.
Configurar la plantilla de certificado de
servidor
Artículo • 21/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para configurar la plantilla de certificado que Active
Directory® Certificate Services (AD CS) usa como base para los certificados de servidor
inscritos en servidores de la red.

Al configurar esta plantilla, puede especificar los servidores Active Directory grupo que
debería recibir automáticamente un certificado de servidor de AD CS.

El procedimiento siguiente incluye instrucciones para configurar la plantilla para emitir

certificados a todos los tipos de servidor siguientes:

Servidores que ejecutan el servicio de acceso remoto, incluidos los servidores de

puerta de enlace RAS, que son miembros del grupo Servidores RAS e IAS .
Servidores que ejecutan el servicio Servidor de directivas de red (NPS) que son
miembros del grupo Servidores RAS e IAS .

El requisito mínimo para completar este procedimiento es la pertenencia al grupo

Administradores de empresas y al grupo Admins. del dominio del dominio raíz.

Para configurar la plantilla de certificado

1. En CA1, en Administrador del servidor, haga clic en Herramientasy, a continuación,
haga clic en Entidad de certificación. Se abre la Microsoft Management Console
entidad de certificación (MMC).

2. En MMC, haga doble clic en el nombre de la entidad de certificación, haga clic con
el botón derecho en Plantillas de certificadoy, a continuación, haga clic en
Administrar.

3. Se abre la consola plantillas de certificado. Se mostrarán todas las plantillas de

certificado en el panel de detalles.

4. En el panel de detalles, haga clic en la plantilla RAS y el servidor IAS .

5. Haga clic en el menú Acción y, a continuación, haga clic en Duplicar plantilla. Se

abre el cuadro de diálogo Propiedades de la plantilla.
 6. Haga clic en la pestaña Security (Seguridad).

7. En la pestaña Seguridad , en Nombres de grupo o de usuario, haga clic en

Servidores RAS e IAS.

8. En Permisos para servidores RAS e IAS, en Permitir, asegúrese de que Inscribir

está seleccionado y, a continuación, active la casilla Inscripción automática. Haga
clic en Aceptar y cierre la MMC Plantillas de certificado.

9. En LA MMC de la entidad de certificación, haga clic en Plantillas de certificado. En

el menú Acción , seleccione Nuevoy, a continuación, haga clic en Plantilla de
certificado para emitir. Se abre el cuadro de diálogo Habilitar plantillas de
certificados.

10. En Habilitar plantillas de certificado, haga clic en el nombre de la plantilla de

certificado que acaba de configurar y, a continuación, haga clic en Aceptar. Por
ejemplo, si no ha cambiado el nombre predeterminado de la plantilla de
certificado, haga clic en Copiar del servidor RAS e IAS y, a continuación, haga clic
en Aceptar.
Configuración de la inscripción
automática de certificados
Artículo • 21/09/2022 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

７ Nota

Antes de realizar este procedimiento, debe configurar una plantilla de certificado

de servidor mediante el uso del complemento Plantillas de certificado de
Microsoft Management Console en una CA que ejecute AD CS. El requisito mínimo
para completar este procedimiento es la pertenencia al grupo Administradores de
empresas y al grupo Admins. del dominio del dominio raíz.

Configuración de la inscripción automática de

certificados de servidor
1. En el equipo donde AD DS está instalado, abra Windows PowerShell ®, escriba
mmc y presione ENTRAR. Se abre Microsoft Management Console.

2. En el menú Archivo , haga clic en Agregar o quitar complemento. Se abre el

cuadro de diálogo Agregar o quitar complementos.

3. En Complementos disponibles, desplácese hacia abajo hasta y haga doble clic en

Editor de administración de directivas de grupo. Se abre el cuadro directiva de
grupo seleccionar objeto.

） Importante

Asegúrese de seleccionar Editor de administración de directivas de grupo y

no directiva de grupo Management. Si selecciona administración directiva de
grupo, se producirá un error en la configuración con estas instrucciones y no
se inscribirá automáticamente un certificado de servidor en los NPS.

4. En Objeto de directiva de grupo, haga clic en Examinar. Se abre el cuadro de

diálogo Buscar un objeto de directiva de grupo.
 5. En Dominios, unidades organizativas y objetos de directiva de grupo vinculados,
haga clic en Directiva predeterminada de dominio y, a continuación, haga clic en
Aceptar.

6. Haz clic en Finalizar y, a continuación, en Aceptar.

7. Haga doble clic en Directiva predeterminada de dominio. En la consola de ,

expanda la siguiente ruta de acceso: Configuración del equipo, Directivas,
Windows Configuración, Seguridad Configuración y, a continuación, Directivas de
clave pública.

8. Haga clic en Directivas de clave pública. En el panel de detalles, haga doble clic en
Cliente de Servicios de servidor de certificados - Inscripción automática. Se abre
el cuadro de diálogo Propiedades. Configure los siguientes elementos y haga clic
en Aceptar:
a. En Modelo de configuración, seleccione Habilitado.
b. Active la casilla Renovar certificados expirados, actualizar certificados
pendientes y quitar certificados revocados.
c. Active la casilla Actualizar certificados que usan plantillas de certificado.

9. Haga clic en OK.

Configuración de la inscripción automática de

certificados de usuario
1. En el equipo donde AD DS está instalado, abra Windows PowerShell ®, escriba
mmc y presione ENTRAR. Se abre Microsoft Management Console.

2. En el menú Archivo , haga clic en Agregar o quitar complemento. Se abre el

cuadro de diálogo Agregar o quitar complementos.

3. En Complementos disponibles, desplácese hacia abajo hasta y haga doble clic en

Editor de administración de directivas de grupo. Se abre el cuadro directiva de
grupo seleccionar objeto.

） Importante

Asegúrese de seleccionar Editor de administración de directivas de grupo y

no directiva de grupo Management. Si selecciona administración directiva de
grupo, se producirá un error en la configuración con estas instrucciones y no
se inscribirá automáticamente un certificado de servidor en los NPS.
 4. En Objeto de directiva de grupo, haga clic en Examinar. Se abre el cuadro de
diálogo Buscar un objeto de directiva de grupo.

5. En Dominios, unidades organizativas y objetos de directiva de grupo vinculados,

haga clic en Directiva predeterminada de dominio y, a continuación, haga clic en
Aceptar.

6. Haz clic en Finalizar y, a continuación, en Aceptar.

7. Haga doble clic en Directiva predeterminada de dominio. En la consola, expanda

la siguiente ruta de acceso: Configuración del usuario, Directivas, Windows
Configuración, Seguridad Configuración.

8. Haga clic en Directivas de clave pública. En el panel de detalles, haga doble clic en
Cliente de Servicios de servidor de certificados - Inscripción automática. Se abre
el cuadro de diálogo Propiedades. Configure los siguientes elementos y haga clic
en Aceptar:
a. En Modelo de configuración, seleccione Habilitado.
b. Active la casilla Renovar certificados expirados, actualizar certificados
pendientes y quitar certificados revocados.
c. Active la casilla Actualizar certificados que usan plantillas de certificado.

9. Haga clic en OK.

Pasos a seguir
Actualizar directiva de grupo
Actualizar la directiva de grupo
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Se puede usar este procedimiento para actualizar manualmente la directiva de grupo en

el equipo local. Si la inscripción automática de certificados está configurada y funciona
correctamente, al actualizar la directiva de grupo, la entidad de certificación (CA)
inscribe un certificado para el equipo local de forma automática.

７ Nota

La directiva de grupo se actualiza automáticamente cuando reinicia el equipo del

miembro de dominio o cuando un usuario inicia sesión en el equipo del miembro
de dominio. Además, la directiva de grupo se actualiza periódicamente. De manera
predeterminada, esta actualización periódica se realiza cada 90 minutos con una
diferencia aleatoria de hasta 30 minutos.

La pertenencia a administradores, o equivalente, es el mínimo necesario para completar

este procedimiento.

Para actualizar la directiva de grupo en el

equipo local
1. En el equipo donde está instalado el servidor de directivas de red (NPS), abra
PowerShell con el icono de la barra de tareas.

2. En el símbolo del sistema de PowerShell, escriba gpupdate y presione Enter .

Comprobar la inscripción de servidor de
un certificado de servidor
Artículo • 21/12/2022 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para comprobar que los servidores del servidor de
directivas de red (NPS) han inscrito un certificado de servidor de la entidad de
certificación (CA).

７ Nota

La pertenencia al grupo Administradores de dominio es el mínimo necesario para

completar estos procedimientos.

Comprobar la inscripción del servidor de

directivas de red (NPS) de un certificado de
servidor
Dado que NPS se usa para autenticar y autorizar solicitudes de conexión de red, es
importante asegurarse de que el certificado de servidor que ha emitido para NPSs sea
válido cuando se usa en directivas de red.

Para comprobar que un certificado de servidor está configurado correctamente y está

inscrito en NPS, debe configurar una directiva de red de prueba y permitir que NPS
compruebe que NPS puede usar el certificado para la autenticación.

Para comprobar la inscripción de NPS de un certificado

de servidor
1. En el Administrador del servidor, haga clic en Herramientas y, a continuación, haga
clic en Servidor de directivas de redes. Se abre el servidor de directivas Microsoft
Management Console (MMC).

2. Haga doble clic en Directivas, haga clic con el botón derecho en Directivas de redy
haga clic en Nuevo. Se abre el asistente para nueva directiva de red.
3. En Especificar el nombre de la directiva de red y el tipo de conexión, en Nombre
de directiva, escriba Directiva de prueba. Asegúrese de que Tipo de servidor de
acceso a la red tiene el valor Sin especificar y, a continuación, haga clic en
Siguiente.

4. En Especificar condiciones, haga clic en Agregar. En Seleccionar condición, haga

clic Windows grupos y, a continuación, haga clic en Agregar.

5. En Grupos, haga clic en Agregar grupos. En Seleccionar grupo, escriba Usuarios

del dominio y presione ENTRAR. Haga clic en Aceptar y luego en Siguiente.

6. En Especificar permiso de acceso, asegúrese de que acceso concedido está

seleccionado y, a continuación, haga clic en Siguiente.

7. En Configurar métodos de autenticación, haga clic en Agregar. En Agregar EAP,

haga clic en Microsoft: EAP protegido (PEAP) y, a continuación, haga clic en
Aceptar. En Tipos de EAP, seleccione Microsoft: EAP protegido (PEAP) y, a
continuación, haga clic en Editar. Se abre el cuadro de diálogo Editar propiedades
de EAP protegidas.

8. En el cuadro de diálogo Editar propiedades de EAP protegidas, en Certificado

emitido para, NPS muestra el nombre del certificado de servidor con el formato
NombreDeEquipo. Dominio. Por ejemplo, si el NPS se denomina NPS-01 y el
dominio está [Link], NPS muestra el certificado [Link].
Además, en Emisor, se muestra el nombre de la entidad de certificación y, en
Fecha de expiración, se muestra la fecha de expiración del certificado de servidor.
Esto demuestra que nps ha inscrito un certificado de servidor válido que puede
usar para demostrar su identidad a los equipos cliente que intentan acceder a la
red a través de los servidores de acceso a la red, como servidores de red privada
virtual (VPN), puntos de acceso inalámbricos compatibles con 802.1X, servidores
de puerta de enlace de Escritorio remoto y conmutadores Ethernet compatibles
con 802.1X.

） Importante

Si NPS no muestra un certificado de servidor válido y proporciona el mensaje

de que este certificado no se encuentra en el equipo local, hay dos razones
posibles para este problema. Es posible que directiva de grupo actualizara
correctamente y el NPS no haya inscrito un certificado de la entidad de
certificación. En esta circunstancia, reinicie nps. Cuando se reinicia el equipo,
directiva de grupo se actualiza y puede volver a realizar este procedimiento
para comprobar que el certificado de servidor está inscrito. Si la directiva de
 grupo no resuelve este problema, la plantilla de certificado, la inscripción
automática del certificado o ambas no se configuran correctamente. Para
resolver estos problemas, comience al principio de esta guía y vuelva a
realizar todos los pasos para asegurarse de que la configuración que ha
proporcionado es precisa.

9. Cuando haya comprobado la presencia de un certificado de servidor válido, puede

hacer clic en Aceptar y Cancelar para salir del Asistente para nueva directiva de
red.

７ Nota

Dado que no está completando el asistente, la directiva de red de prueba no

se crea en NPS.
Implementación del acceso inalámbrico
autenticado mediante 802.1X basado en
contraseña
Artículo • 07/02/2023 • Tiempo de lectura: 24 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Esta es una guía complementaria de la Guía de red principal de Windows Server® 2016.
La Guía de red principal proporciona instrucciones para planear e implementar los
componentes necesarios para una red totalmente funcional y un nuevo dominio de
Active Directory® en un nuevo bosque.

En esta guía se explica cómo basarse en una red principal proporcionando instrucciones
sobre cómo implementar el acceso IEEE 802.11 inalámbrico autenticado mediante
802.1X del Instituto de ingenieros de electricidad y electrónica (IEEE) mediante el
protocolo de autenticación extensible protegido versión 2 (PEAP-MS-CHAP v2).

Dado que PEAP-MS-CHAP v2 requiere que los usuarios proporcionen credenciales

basadas en contraseña en lugar de un certificado durante el proceso de autenticación,
normalmente es más fácil y menos costoso implementar que EAP-TLS o PEAP-TLS.

７ Nota

En esta guía, IEEE 802.1X Authenticated Wireless Access with PEAP-MS-CHAP v2 is

abbreviated to "wireless access" and "WiFi access".

Acerca de esta guía

En esta guía, junto con las guías de requisitos previos que se describen a continuación,
se proporcionan instrucciones sobre cómo implementar la siguiente infraestructura de
acceso WiFi.

Uno o varios puntos de acceso inalámbricos (AP) compatibles con 802.11 802.1X.

usuarios y equipos de Servicios de dominio de Active Directory (AD DS).

Administración de directivas de grupo.

Uno o varios servidores de servidor de directivas de red (NPS).

 Certificados de servidor para equipos con NPS.

Equipos cliente inalámbricos que ejecutan Windows® 10, Windows 8.1 o Windows
8.

Dependencias de esta guía

Para implementar correctamente la red inalámbrica autenticada con esta guía, debe
tener un entorno de red y dominio con todas las tecnologías necesarias implementadas.
También debe tener certificados de servidor implementados en los NPS de
autenticación.

En las secciones siguientes se proporcionan vínculos a documentación que muestra

cómo implementar estas tecnologías.

Dependencias del entorno de red y dominio

Esta guía está diseñada para los administradores de red y del sistema que han seguido
las instrucciones de la guía de red principal de Windows Server 2016 para implementar
una red principal o para aquellos que han implementado previamente las tecnologías
principales incluidas en la red principal, incluidos AD DS, sistema de nombres de
dominio (DNS), protocolo de configuración dinámica de host (DHCP), TCP/IP, NPS y
servicio de nombres de Internet de Windows (WINS).

La guía de red principal de Windows Server 2016 está disponible en la biblioteca técnica
de Windows Server 2016.

Dependencias de certificados de servidor

Hay dos opciones disponibles para inscribir servidores de autenticación con certificados
de servidor para su uso con autenticación 802.1X: implementar su propia infraestructura
de clave pública mediante Servicios de certificados de Active Directory (AD CS) o usar
certificados de servidor inscritos por una entidad de certificación (CA) pública.

AD CS

Los administradores de red y del sistema que implementan la red inalámbrica

autenticada deben seguir las instrucciones de la guía complementaria de red principal
de Windows Server 2016, Implementar certificados de servidor para implementaciones
cableadas e inalámbricas 802.1X. En esta guía se explica cómo implementar y usar AD
CS para inscribir automáticamente certificados de servidor en equipos que ejecutan
NPS.

Esta guía está disponible en la siguiente ubicación.

La guía complementaria de red principal de Windows Server 2016 implementación

de certificados de servidor para implementaciones cableadas e inalámbricas 802.1X
en formato HTML en la biblioteca técnica.

CA pública

Puede adquirir certificados de servidor de una entidad de certificación pública, como

VeriSign, que los equipos cliente ya confían.

Un equipo cliente confía en una ENTIDAD de certificación cuando el certificado de ca

está instalado en el almacén de certificados de entidades de certificación raíz de
confianza. De forma predeterminada, los equipos que ejecutan Windows tienen varios
certificados de entidad de certificación pública instalados en su almacén de certificados
de entidades de certificación raíz de confianza.

Se recomienda que revise las guías de diseño e implementación de cada una de las
tecnologías que se usan en este escenario de implementación. Estas guías pueden
ayudarle a determinar si este escenario de implementación ofrece los servicios y la
configuración que necesita para la red de su organización.

Requisitos
A continuación se muestran los requisitos para implementar una infraestructura de
acceso inalámbrico mediante el escenario documentado en esta guía:

Antes de implementar este escenario, primero debe comprar puntos de acceso

inalámbrico compatibles con 802.1X para proporcionar cobertura inalámbrica en
las ubicaciones deseadas en su sitio. La sección de planeación de esta guía ayuda a
determinar las características que los PROVEEDORES deben admitir.

Servicios de dominio de Active Directory (AD DS) está instalado, al igual que las
demás tecnologías de red necesarias, según las instrucciones de la Guía de red
principal de Windows Server 2016.

AD CS se implementa y los certificados de servidor se inscriben en NPS. Estos

certificados son necesarios al implementar el método de autenticación basado en
certificados PEAP-MS-CHAP v2 que se usa en esta guía.
 Un miembro de su organización está familiarizado con los estándares IEEE 802.11
que son compatibles con los AP inalámbricos y los adaptadores de red inalámbrica
que están instalados en los equipos y dispositivos cliente de la red. Por ejemplo,
alguien de su organización está familiarizado con los tipos de frecuencia de radio,
la autenticación inalámbrica 802.11 (WPA2 o WPA) y los cifrados (AES o TKIP).

Qué no incluye esta guía

A continuación se muestran algunos elementos que esta guía no proporciona:

Guía completa para seleccionar puntos de acceso

inalámbricos compatibles con 802.1X
Dado que existen muchas diferencias entre marcas y modelos de AP inalámbricos
compatibles con 802.1X, esta guía no proporciona información detallada sobre:

Determinar qué marca o modelo de AP inalámbrico es más adecuado para sus

necesidades.

La implementación física de ap inalámbricos en la red.

Configuración avanzada de AP inalámbrica, como para redes de área local (VLAN)

virtuales inalámbricas.

Instrucciones sobre cómo configurar atributos específicos del proveedor del AP

inalámbrico en NPS.

Además, la terminología y los nombres de la configuración varían entre las marcas y los
modelos de AP inalámbricos, y es posible que no coincidan con los nombres de
configuración genéricos que se usan en esta guía. Para obtener los detalles de
configuración del AP inalámbrico, debe revisar la documentación del producto
proporcionada por el fabricante de sus AP inalámbricas.

Instrucciones para implementar certificados NPS

Hay dos alternativas para implementar certificados NPS. Esta guía no proporciona
instrucciones completas para ayudarle a determinar qué alternativa se adapte mejor a
sus necesidades. Sin embargo, en general, las opciones a las que se enfrenta son:

Adquirir certificados de una entidad de certificación pública, como VeriSign, que ya

son de confianza para los clientes basados en Windows. Esta opción suele
recomendarse para redes más pequeñas.
 Implementación de una infraestructura de clave pública (PKI) en la red mediante
AD CS. Esto se recomienda para la mayoría de las redes y las instrucciones para
implementar certificados de servidor con AD CS están disponibles en la guía de
implementación mencionada anteriormente.

Directivas de red NPS y otra configuración de NPS

A excepción de las opciones de configuración realizadas al ejecutar el Asistente para
configurar 802.1X , como se documenta en esta guía, esta guía no proporciona
información detallada para configurar manualmente condiciones, restricciones u otras
opciones de NPS.

DHCP
Esta guía de implementación no proporciona información sobre el diseño o la
implementación de subredes DHCP para redes LAN inalámbricas.

Introducción a las tecnologías

A continuación se muestran información general sobre tecnología para implementar el
acceso inalámbrico:

IEEE 802.1X
El estándar IEEE 802.1X define el control de acceso de red basado en puerto que se usa
para proporcionar acceso de red autenticado a redes Ethernet. Este control de acceso a
la red basado en puertos usa las características físicas de la infraestructura LAN
conmutada para autenticar los dispositivos conectados a un puerto LAN. Se puede
denegar el acceso al puerto si se produce un error en el proceso de autenticación.
Aunque este estándar fue diseñado para redes Ethernet cableadas, se ha adaptado para
su uso en 802.11 LAN inalámbricas.

Puntos de acceso inalámbricos compatibles con 802.1X

(AP)
Este escenario requiere la implementación de uno o varios AP inalámbricos compatibles
con 802.1X que son compatibles con el protocolo servicio de acceso telefónico local de
autenticación remota (RADIUS).
Las direcciones AP compatibles con 802.1X y RADIUS, cuando se implementan en una
infraestructura RADIUS con un servidor RADIUS como NPS, se denominan clientes
RADIUS.

Clientes inalámbricos
Esta guía proporciona detalles de configuración completos para proporcionar acceso
autenticado de 802.1X a los usuarios miembros del dominio que se conectan a la red
con equipos cliente inalámbricos que ejecutan Windows 10, Windows 8.1 y Windows 8.
Los equipos deben estar unidos al dominio para establecer correctamente el acceso
autenticado.

７ Nota

También puede usar equipos que ejecutan Windows Server 2016, Windows Server
2012 R2 y Windows Server 2012 como clientes inalámbricos.

Compatibilidad con estándares IEEE 802.11

Los sistemas operativos Windows y Windows Server compatibles proporcionan
compatibilidad integrada con redes inalámbricas 802.11. En estos sistemas operativos,
un adaptador de red inalámbrica 802.11 instalado aparece como una conexión de red
inalámbrica en el Centro de redes y uso compartido.

Aunque hay compatibilidad integrada con redes inalámbricas 802.11, los componentes
inalámbricos de Windows dependen de lo siguiente:

Las funciones del adaptador de red inalámbrica. El adaptador de red inalámbrica

instalado debe admitir el LAN inalámbrico o los estándares de seguridad
inalámbrica que necesita. Por ejemplo, si el adaptador de red inalámbrica no
admite Wi-Fi acceso protegido (WPA), no puede habilitar ni configurar opciones de
seguridad WPA.

Las funciones del controlador del adaptador de red inalámbrica. Para permitirle
configurar las opciones de red inalámbrica, el controlador para el adaptador de red
inalámbrica debe admitir la notificación de todas sus funcionalidades a Windows.
Compruebe que el controlador del adaptador de red inalámbrica está escrito para
las funcionalidades del sistema operativo. Asegúrese también de que el
controlador es la versión más actual comprobando Microsoft Update o el sitio web
del proveedor del adaptador de red inalámbrica.
En la tabla siguiente se muestran las frecuencias y velocidades de transmisión para los
estándares inalámbricos comunes IEEE 802.11.

Estándares Frecuencias Velocidades Uso

de
transmisión
de bits

802.11 Intervalo de 2 megabits Obsoleto. No se suele usar.

frecuencia por
industrial, científico segundo
y médico (ISM) de (Mbps)
banda S (2,4 a 2,5
GHz)

802.11b S-Band ISM 11 Mbps Se suele usar.

802.11a ISM de banda C (de 54 Mbps Normalmente no se usa debido a gastos y

5,725 a 5,875 GHz) intervalos limitados.

802.11g S-Band ISM 54 Mbps Ampliamente utilizado. Los dispositivos

802.11g son compatibles con dispositivos
802.11b.

802,11n C-Band y S-Band 250 MBps Los dispositivos basados en el estándar IEEE
\2,4 y 5,0 ISM 802.11n de ratificación previa se convirtieron
GHz en disponibles en agosto de 2007. Muchos
dispositivos 802.11n son compatibles con
dispositivos 802.11a, b y g.

802.11ac 5 GHz 6,93 Gbps 802.11ac, aprobado por ieee en 2014, es más
escalable y más rápido que 802.11n, y se
implementa donde los AP y los clientes
inalámbricos lo admiten.

Métodos de seguridad de red inalámbrica

Los métodos de seguridad de red inalámbrica son una agrupación informal de
autenticación inalámbrica (a veces denominada seguridad inalámbrica) y cifrado de
seguridad inalámbrica. La autenticación inalámbrica y el cifrado se usan en pares para
evitar que los usuarios no autorizados accedan a la red inalámbrica y para proteger las
transmisiones inalámbricas.

Al configurar las opciones de seguridad inalámbrica en las directivas de red inalámbrica

de directiva de grupo, hay varias combinaciones entre las que elegir. Sin embargo, solo
se admiten los estándares de autenticación WPA2-Enterprise, WPA-Enterprise y Open
con 802.1X para implementaciones inalámbricas autenticadas de 802.1X.
 ７ Nota

Al configurar directivas de red inalámbrica, debe seleccionar WPA2-Enterprise,

WPA-Enterprise o Abrir con 802.1X para obtener acceso a la configuración de EAP
necesaria para las implementaciones inalámbricas autenticadas 802.1X.

Autenticación inalámbrica

En esta guía se recomienda el uso de los siguientes estándares de autenticación

inalámbrica para implementaciones inalámbricas autenticadas de 802.1X.

Wi-Fi Protected Access – Enterprise (WPA-Enterprise) WPA es un estándar provisional

desarrollado por la Alianza WiFi para cumplir con el protocolo de seguridad inalámbrica
802.11. El protocolo WPA se desarrolló en respuesta a una serie de errores graves que se
detectaron en el protocolo anterior de privacidad equivalente cableada (WEP).

WPA-Enterprise proporciona una mayor seguridad a través de WEP mediante:

1. Requerir autenticación que use el marco EAP 802.1X como parte de la

infraestructura que garantiza la autenticación mutua centralizada y la
administración dinámica de claves

2. Mejora del valor de comprobación de integridad (ICV) con una comprobación de

integridad de mensajes (MIC), para proteger el encabezado y la carga

3. Implementación de un contador de fotogramas para desalentar los ataques de

reproducción

Wi-Fi Protected Access 2 – Enterprise (WPA2-Enterprise) Al igual que el estándar WPA-

Enterprise, WPA2-Enterprise usa el marco 802.1X y EAP. WPA2-Enterprise proporciona
una protección de datos más sólida para varios usuarios y redes administradas de gran
tamaño. WPA2-Enterprise es un protocolo sólido diseñado para evitar el acceso de red
no autorizado mediante la comprobación de los usuarios de red a través de un servidor
de autenticación.

Cifrado de seguridad inalámbrica

El cifrado de seguridad inalámbrica se usa para proteger las transmisiones inalámbricas
que se envían entre el cliente inalámbrico y el AP inalámbrico. El cifrado de seguridad
inalámbrica se usa junto con el método de autenticación de seguridad de red
seleccionado. De forma predeterminada, los equipos que ejecutan Windows 10,
Windows 8.1 y Windows 8 admiten dos estándares de cifrado:
 1. El Protocolo de integridad de clave temporal (TKIP) es un protocolo de cifrado
antiguo diseñado originalmente para proporcionar un cifrado inalámbrico más
seguro que lo proporcionado por el protocolo de privacidad equivalente
equivalente por cable (WEP) inherentemente débil. TKIP fue diseñado por el grupo
de tareas IEEE 802.11i y la Wi-Fi Alliance para reemplazar WEP sin necesidad de
reemplazar el hardware heredado. TKIP es un conjunto de algoritmos que
encapsula la carga WEP y permite a los usuarios de equipos WiFi heredados
actualizar a TKIP sin reemplazar el hardware. Al igual que WEP, TKIP usa el
algoritmo de cifrado de flujo RC4 como base. Sin embargo, el nuevo protocolo
cifra cada paquete de datos con una clave de cifrado única y las claves son mucho
más fuertes que las de WEP. Aunque TKIP es útil para actualizar la seguridad en
dispositivos más antiguos diseñados para usar solo WEP, no aborda todos los
problemas de seguridad que se enfrentan a las redes LAN inalámbricas y, en la
mayoría de los casos, no es lo suficientemente sólido para proteger las
transmisiones confidenciales de datos gubernamentales o corporativos.

2. Advanced Encryption Standard (AES) es el protocolo de cifrado preferido para el

cifrado de datos comerciales y gubernamentales. AES ofrece un mayor nivel de
seguridad de transmisión inalámbrica que TKIP o WEP. A diferencia de TKIP y WEP,
AES requiere hardware inalámbrico que admita el estándar AES. AES es un
estándar de cifrado de clave simétrica que usa tres cifrados de bloques, AES-128,
AES-192 y AES-256.

En Windows Server 2016, los siguientes métodos de cifrado inalámbrico basados en AES
están disponibles para la configuración en las propiedades de perfil inalámbrico al
seleccionar un método de autenticación de WPA2-Enterprise, que se recomienda.

1. AES-CCMP. El protocolo de código de autenticación de mensajes (CCMP) del

modo de cifrado de encadenamiento de bloques de contadores implementa el
estándar 802.11i y está diseñado para un cifrado de seguridad superior al
proporcionado por WEP y usa claves de cifrado AES de 128 bits.
2. AES-GCMP. Galois Counter Mode Protocol (GCMP) es compatible con 802.11ac, es
más eficaz que AES-CCMP y proporciona un mejor rendimiento para los clientes
inalámbricos. GCMP usa claves de cifrado AES de 256 bits.

） Importante

La privacidad de equivalencia por cable (WEP) fue el estándar de seguridad

inalámbrica original que se usó para cifrar el tráfico de red. No debe implementar
WEP en la red porque hay vulnerabilidades conocidas en esta forma de seguridad
obsoleta.
Active Directory Domain Services (AD DS)
AD DS proporciona una base de datos distribuida que almacena y administra
información acerca de los recursos de red y datos específicos de las aplicaciones
habilitadas para el uso de directorios. Los administradores pueden usar AD DS para
organizar los elementos de una red (por ejemplo, los usuarios, los equipos y otros
dispositivos) en una estructura de contención jerárquica. La estructura de contención
jerárquica incluye el bosque de Active Directory, los dominios del bosque y las unidades
organizativas de cada dominio. Un servidor que ejecuta AD DS se denomina controlador
de dominio.

AD DS contiene las cuentas de usuario, las cuentas de equipo y las propiedades de

cuenta requeridas por IEEE 802.1X y PEAP-MS-CHAP v2 para autenticar las credenciales
de usuario y evaluar la autorización de las conexiones inalámbricas.

Usuarios y equipos de Active Directory

Usuarios y equipos de Active Directory es un componente de AD DS que contiene
cuentas que representan entidades físicas, como un equipo, una persona o un grupo de
seguridad. Un grupo de seguridad es una colección de cuentas de usuario o equipo que
los administradores pueden administrar como una sola unidad. Las cuentas de usuario y
equipo que pertenecen a un grupo determinado se conocen como miembros del grupo.

Administración de directivas de grupo

directiva de grupo Management permite la administración de cambios y
configuraciones basados en directorios de la configuración del usuario y del equipo,
incluida la información de seguridad y usuario. Use directiva de grupo para definir
configuraciones para grupos de usuarios y equipos. Con directiva de grupo, puede
especificar la configuración de las entradas del Registro, seguridad, instalación de
software, scripts, redirección de carpetas, servicios de instalación remota e
Mantenimiento de Internet Explorer. La configuración de directiva de grupo que cree se
incluye en un objeto directiva de grupo (GPO). Al asociar un GPO con contenedores de
sistema de Active Directory seleccionados (sitios, dominios y UNIDADES organizativas),
puede aplicar la configuración del GPO a los usuarios y equipos de esos contenedores
de Active Directory. Para administrar directiva de grupo objetos en una empresa, puede
usar el Editor de administración de directiva de grupo Microsoft Management Console
(MMC).

En esta guía se proporcionan instrucciones detalladas sobre cómo especificar la

configuración en la extensión de directivas de red inalámbrica (IEEE 802.11) de directiva
de grupo Management. Las directivas de red inalámbrica (IEEE 802.11) configuran
equipos cliente inalámbricos miembros del dominio con la conectividad necesaria y la
configuración inalámbrica para el acceso inalámbrico autenticado 802.1X.

Certificados de servidor
Este escenario de implementación requiere certificados de servidor para cada NPS que
realiza la autenticación 802.1X.

Un certificado de servidor es un documento digital que se usa normalmente para la

autenticación y para proteger la información en redes abiertas. Un certificado enlaza de
manera segura una clave pública a la entidad que contiene la clave privada
correspondiente. Los certificados están firmados digitalmente por la entidad de
certificación emisora y se pueden emitir para un usuario, un equipo o un servicio.

Una entidad de certificación (CA) es una entidad responsable de establecer y garantizar

la autenticidad de las claves públicas pertenecientes a sujetos (normalmente usuarios o
equipos) u otras CA. Las actividades de una entidad de certificación pueden incluir el
enlace de claves públicas a nombres distintivos a través de certificados firmados, la
administración de números de serie de certificados y la revocación de certificados.

Servicios de certificados de Active Directory (AD CS) es un rol de servidor que emite
certificados como una ENTIDAD de certificación de red. Una infraestructura de
certificados de AD CS, también conocida como infraestructura de clave pública (PKI),
proporciona servicios personalizables para emitir y administrar certificados para la
empresa.

EAP, PEAP y PEAP-MS-CHAP v2

El Protocolo de autenticación extensible (EAP) amplía el Protocolo de punto a punto
(PPP) al permitir métodos de autenticación adicionales que usan intercambios de
credenciales e información de longitudes arbitrarias. Con la autenticación EAP, tanto el
cliente de acceso a la red como el autenticador (como NPS) deben admitir el mismo tipo
EAP para que se produzca una autenticación correcta. Windows Server 2016 incluye una
infraestructura de EAP, admite dos tipos EAP y la capacidad de pasar mensajes EAP a
NPS. Mediante el uso de EAP, puede admitir esquemas de autenticación adicionales,
conocidos como tipos EAP. Los tipos EAP admitidos por Windows Server 2016 son:

Seguridad de la capa de transporte (TLS)

Protocolo de autenticación de protocolo de enlace de desafío de Microsoft versión

2 (MS-CHAP v2)
 ） Importante

Los tipos de EAP seguros (como los basados en certificados) ofrecen una mejor
seguridad frente a ataques por fuerza bruta, ataques de diccionario y ataques de
adivinación de contraseñas que los protocolos de autenticación basados en
contraseñas (como CHAP o MS-CHAP versión 1).

EAP protegido (PEAP) usa TLS para crear un canal cifrado entre un cliente PEAP
autenticado, como un equipo inalámbrico y un autenticador PEAP, como un NPS u otros
servidores RADIUS. PEAP no especifica un método de autenticación, pero proporciona
seguridad adicional para otros protocolos de autenticación EAP (como EAP-MS-CHAP
v2) que pueden funcionar a través del canal cifrado TLS proporcionado por PEAP. PEAP
se usa como método de autenticación para los clientes de acceso que se conectan a la
red de su organización a través de los siguientes tipos de servidores de acceso a la red
(NAS):

Puntos de acceso inalámbrico compatibles con 802.1X

Conmutadores de autenticación compatibles con 802.1X

Equipos que ejecutan Windows Server 2016 y el servicio de acceso remoto (RAS)
configurados como servidores de red privada virtual (VPN), servidores de
DirectAccess o ambos

Equipos que ejecutan Windows Server 2016 y Servicios de Escritorio remoto

PEAP-MS-CHAP v2 es más fácil de implementar que EAP-TLS porque la autenticación de

usuario se realiza mediante credenciales basadas en contraseña (nombre de usuario y
contraseña), en lugar de certificados o tarjetas inteligentes. Solo se requiere NPS u otros
servidores RADIUS para tener un certificado. El NPS utiliza el certificado NPS durante el
proceso de autenticación para demostrar su identidad a los clientes PEAP.

En esta guía se proporcionan instrucciones para configurar los clientes inalámbricos y

sus NPS para usar PEAP-MS-CHAP v2 para el acceso autenticado 802.1X.

Servidor de directivas de redes

El servidor de directivas de red (NPS) permite configurar y administrar de forma
centralizada las directivas de red mediante el servidor de servicio de acceso telefónico
local de autenticación remota (RADIUS) y el proxy RADIUS. NPS es necesario cuando se
implementa el acceso inalámbrico 802.1X.
Al configurar los puntos de acceso inalámbricos 802.1X como clientes RADIUS en NPS,
NPS procesa las solicitudes de conexión enviadas por los AP. Durante el procesamiento
de solicitudes de conexión, NPS realiza la autenticación y la autorización. La
autenticación determina si el cliente ha presentado credenciales válidas. Si NPS
autentica correctamente el cliente solicitante, NPS determina si el cliente está autorizado
para realizar la conexión solicitada y permite o deniega la conexión. Esto se explica con
más detalle de la siguiente manera:

Authentication

La autenticación mutua de PEAP-MS-CHAP v2 correcta tiene dos partes principales:

1. El cliente autentica el NPS. Durante esta fase de autenticación mutua, NPS envía su
certificado de servidor al equipo cliente para que el cliente pueda comprobar la
identidad del NPS con el certificado. Para autenticar correctamente el NPS, el
equipo cliente debe confiar en la ENTIDAD de certificación que emitió el
certificado NPS. El cliente confía en esta ENTIDAD de certificación cuando el
certificado de la ENTIDAD de certificación está presente en el almacén de
certificados de entidades de certificación raíz de confianza en el equipo cliente.

Si implementa su propia entidad de certificación privada, el certificado de ca se

instala automáticamente en el almacén de certificados de entidades de
certificación raíz de confianza para el usuario actual y para el equipo local cuando
se actualiza directiva de grupo en el equipo cliente miembro del dominio. Si
decide implementar certificados de servidor desde una entidad de certificación
pública, asegúrese de que el certificado de ca pública ya está en el almacén de
certificados de entidades de certificación raíz de confianza.

2. NpS autentica al usuario. Después de que el cliente autentique correctamente el

NPS, el cliente envía las credenciales basadas en contraseña del usuario al NPS,
que comprueba las credenciales del usuario en la base de datos de cuentas de
usuario en Servicios de dominio de Active Directory (AD DS).

Si las credenciales son válidas y la autenticación se realiza correctamente, NPS inicia la

fase de autorización del procesamiento de la solicitud de conexión. Si las credenciales
no son válidas y se produce un error en la autenticación, NPS envía un mensaje de
rechazo de acceso y se deniega la solicitud de conexión.

Authorization

El servidor que ejecuta NPS realiza la autorización de la siguiente manera:

 1. NPS comprueba si hay restricciones en las propiedades de acceso telefónico de la
cuenta de usuario o equipo en AD DS. Cada cuenta de usuario y equipo de
Usuarios y equipos de Active Directory incluye varias propiedades, incluidas las
que se encuentran en la pestaña Acceso telefónico local. En esta pestaña, en
Permiso de acceso a la red, si el valor es Permitir acceso, el usuario o equipo está
autorizado para conectarse a la red. Si el valor es Denegar acceso, el usuario o
equipo no está autorizado para conectarse a la red. Si el valor es Controlar el
acceso a través de la directiva de red NPS, NPS evalúa las directivas de red
configuradas para determinar si el usuario o el equipo está autorizado para
conectarse a la red.

2. A continuación, NPS procesa sus directivas de red para buscar una directiva que
coincida con la solicitud de conexión. Si se encuentra una directiva coincidente,
NPS concede o deniega la conexión en función de la configuración de esa
directiva.

Si la autenticación y la autorización son correctas y si la directiva de red coincidente

concede acceso, NPS concede acceso a la red y el usuario y el equipo pueden
conectarse a los recursos de red para los que tienen permisos.

７ Nota

Para implementar el acceso inalámbrico, debe configurar directivas NPS. En esta

guía se proporcionan instrucciones para usar el asistente Configurar 802.1X en NPS
para crear directivas NPS para el acceso inalámbrico autenticado 802.1X.

Perfiles de arranque
En las redes inalámbricas autenticadas por 802.1X, los clientes inalámbricos deben
proporcionar credenciales de seguridad autenticadas por un servidor RADIUS para
conectarse a la red. Para EAP protegido [PEAP]-Microsoft Challenge Handshake
Authentication Protocol versión 2 [MS-CHAP v2], las credenciales de seguridad son un
nombre de usuario y una contraseña. Para EAP-Transport Seguridad de la capa [TLS] o
PEAP-TLS, las credenciales de seguridad son certificados, como certificados de usuario
cliente y equipo o tarjetas inteligentes.

Al conectarse a una red configurada para realizar la autenticación PEAP-MS-CHAP v2,

PEAP-TLS o EAP-TLS, de forma predeterminada, los clientes inalámbricos de Windows
también deben validar un certificado de equipo enviado por el servidor RADIUS. El
certificado de equipo que envía el servidor RADIUS para cada sesión de autenticación se
conoce normalmente como certificado de servidor.
Como se mencionó anteriormente, puede emitir sus servidores RADIUS su certificado de
servidor de una de estas dos maneras: desde una CA comercial (como VeriSign, Inc.,) o
desde una CA privada que implemente en la red. Si el servidor RADIUS envía un
certificado de equipo emitido por una CA comercial que ya tiene un certificado raíz
instalado en el almacén de certificados de entidades de certificación raíz de confianza
del cliente, el cliente inalámbrico puede validar el certificado de equipo del servidor
RADIUS, independientemente de si el cliente inalámbrico se ha unido al dominio de
Active Directory. En este caso, el cliente inalámbrico puede conectarse a la red
inalámbrica y, a continuación, puede unir el equipo al dominio.

７ Nota

El comportamiento que requiere que el cliente valide el certificado de servidor se

puede deshabilitar, pero no se recomienda deshabilitar la validación de certificados
de servidor en entornos de producción.

Los perfiles de arranque inalámbrico son perfiles temporales que están configurados de
forma que permitan a los usuarios de cliente inalámbrico conectarse a la red inalámbrica
autenticada 802.1X antes de que el equipo se una al dominio y/o antes de que el
usuario haya iniciado sesión correctamente en el dominio mediante un equipo
inalámbrico determinado por primera vez. En esta sección se resume el problema que se
produce al intentar unir un equipo inalámbrico al dominio o para que un usuario use un
equipo inalámbrico unido a un dominio por primera vez para iniciar sesión en el
dominio.

En el caso de las implementaciones en las que el usuario o el administrador de TI no

pueden conectar físicamente un equipo a la red Ethernet cableada para unir el equipo al
dominio, y el equipo no tiene el certificado de CA raíz necesario instalado en su almacén
de certificados de entidades de certificación raíz de confianza, puede configurar
clientes inalámbricos con un perfil de conexión inalámbrica temporal, llamado perfil de
arranque, para conectarse a la red inalámbrica.

Un perfil de arranque quita el requisito de validar el certificado de equipo del servidor

RADIUS. Esta configuración temporal permite al usuario inalámbrico unir el equipo al
dominio, en cuyo momento se aplican las directivas de red inalámbrica (IEEE 802.11) y el
certificado de CA raíz adecuado se instala automáticamente en el equipo.

Cuando se aplica directiva de grupo, se aplican uno o varios perfiles de conexión

inalámbrica que aplican el requisito de autenticación mutua en el equipo; el perfil de
arranque ya no es necesario y se quita. Después de unir el equipo al dominio y reiniciar
el equipo, el usuario puede usar una conexión inalámbrica para iniciar sesión en el
dominio.

Para obtener información general sobre el proceso de implementación de acceso

inalámbrico mediante estas tecnologías, consulta Información general sobre la
implementación de acceso inalámbrico.
Información general de implementación
de acceso inalámbrico
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En la ilustración siguiente se muestran los componentes necesarios para implementar el

acceso inalámbrico autenticado 802.1X con PEAP-MS-CHAP v2.

Componentes de implementación de acceso

inalámbrico
Se requiere la siguiente infraestructura para esta implementación de acceso inalámbrico:

Puntos de acceso inalámbrico compatibles con 802.1X

Después de que los servicios de infraestructura de red necesarios que admitan la red de
área local inalámbrica están en vigor, puede comenzar el proceso de diseño para la
ubicación de los AP inalámbricos. El proceso de diseño de implementación de AP
inalámbrico implica estos pasos:

Identifique las áreas de cobertura para los usuarios inalámbricos. Al identificar las
áreas de cobertura, asegúrese de identificar si desea proporcionar servicio
inalámbrico fuera del edificio y, si es así, determinar específicamente dónde están
esas áreas externas.

Determine cuántos AP inalámbricos se van a implementar para garantizar una

cobertura adecuada.

Determine dónde colocar los AP inalámbricos.

Seleccione las frecuencias de canal para los AP inalámbricos.

Active Directory Domain Services

Los siguientes elementos de AD DS son necesarios para la implementación de acceso
inalámbrico.

Usuarios y equipos
Use el complemento Usuarios y equipos de Active Directory para crear y administrar
cuentas de usuario, y para crear un grupo de seguridad inalámbrico que incluya a cada
miembro de dominio al que quiera conceder acceso inalámbrico.

Directivas de red inalámbrica (IEEE 802.11)

Puede usar la extensión de directivas de red inalámbrica (IEEE 802.11) de directiva de
grupo Management para configurar directivas que se aplican a los equipos inalámbricos
cuando intentan acceder a la red.

En directiva de grupo Editor de administración, al hacer clic con el botón derecho en

Directivas de red inalámbrica (IEEE 802.11), tiene las dos opciones siguientes para el
tipo de directiva inalámbrica que cree.
 Crear una nueva directiva de red inalámbrica para Windows Vista y versiones
posteriores

Crear una nueva directiva xp de Windows

 Sugerencia

Al configurar una nueva directiva de red inalámbrica, tiene la opción de cambiar el

nombre y la descripción de la directiva. Si cambia el nombre de la directiva, el
cambio se refleja en el panel Detalles de directiva de grupo Editor de
administración y en la barra de título del cuadro de diálogo de directiva de red
inalámbrica. Independientemente de cómo cambie el nombre de las directivas, la
nueva directiva inalámbrica XP siempre aparecerá en directiva de grupo Editor de
administración con el tipo que muestra XP. Otras directivas se muestran con el tipo
que muestra Vista y versiones posteriores.

La directiva de red inalámbrica para Windows Vista y versiones posteriores le permite

configurar, priorizar y administrar varios perfiles inalámbricos. Un perfil inalámbrico es
una colección de configuraciones de conectividad y seguridad que se usan para
conectarse a una red inalámbrica específica. Cuando directiva de grupo se actualiza en
los equipos cliente inalámbricos, los perfiles que crea en la directiva de red inalámbrica
se agregan automáticamente a la configuración en los equipos cliente inalámbricos a los
que se aplica la directiva de red inalámbrica.

Permitir conexiones a varias redes inalámbricas

Si tiene clientes inalámbricos que se mueven entre ubicaciones físicas de su

organización, como entre una oficina principal y una sucursal, es posible que desee que
los equipos se conecten a más de una red inalámbrica. En esta situación, puede
configurar un perfil inalámbrico que contenga las opciones de conectividad y seguridad
específicas para cada red.

Por ejemplo, suponga que su empresa tiene una red inalámbrica para la oficina
corporativa principal, con un identificador de conjunto de servicios (SSID) WlanCorp.

Su sucursal también tiene una red inalámbrica a la que también desea conectarse. La
sucursal tiene el SSID configurado como WlanBranch.

En este escenario, puede configurar un perfil para cada red, y los equipos u otros
dispositivos que se usan en la oficina corporativa y la sucursal pueden conectarse a
cualquiera de las redes inalámbricas cuando están físicamente en el alcance del área de
cobertura de una red.
Redes inalámbricas en modo mixto

Como alternativa, supongamos que la red tiene una combinación de equipos

inalámbricos y dispositivos que admiten diferentes estándares de seguridad. Quizás
algunos equipos más antiguos tienen adaptadores inalámbricos que solo pueden usar
WPA-Enterprise, mientras que los dispositivos más recientes pueden usar la WPA2-
Enterprise estándar más fuerte.

Puede crear dos perfiles diferentes que usen el mismo SSID y una configuración de
seguridad y conectividad casi idénticas.

En un perfil, puede establecer la autenticación inalámbrica en WPA2-Enterprise con AES

y, en el otro perfil, puede especificar WPA-Enterprise con TKIP.

Esto se conoce comúnmente como una implementación en modo mixto, y permite a los
equipos de diferentes tipos y funcionalidades inalámbricas compartir la misma red
inalámbrica.

Servidor de directivas de redes (NPS)

NPS le permite crear y aplicar directivas de acceso de red para la autenticación y
autorización de solicitudes de conexión.

Cuando se usa NPS como servidor RADIUS, se configuran servidores de acceso a la red,
como puntos de acceso inalámbricos, como clientes RADIUS en NPS. También configura
las directivas de red que NPS usa para autenticar a los clientes de acceso y autorizar sus
solicitudes de conexión.

Equipos cliente inalámbricos

Para esta guía, los equipos cliente inalámbricos son equipos y otros dispositivos
equipados con adaptadores de red inalámbrica IEEE 802.11 y que ejecutan Windows
cliente o sistemas operativos Windows Server.

Equipos servidor como clientes inalámbricos

De forma predeterminada, la funcionalidad de la red inalámbrica 802.11 está

deshabilitada en equipos que ejecutan Windows Server.

Para habilitar la conectividad inalámbrica en equipos que ejecutan sistemas operativos

de servidor, debe instalar y habilitar la característica de servicio WIRELESS LAN (WLAN)
mediante Windows PowerShell o el Asistente para agregar roles y características en
Administrador del servidor.
Al instalar la característica Wireless LAN Service , el nuevo servicio WLAN AutoConfig
se instala en Servicios. Una vez completada la instalación, debe reiniciar el servidor.

Una vez reiniciado el servidor, puede acceder a WLAN AutoConfig al hacer clic en Inicio,
Windows Herramientas administrativas y Servicios.

Después de instalar y reiniciar el servidor, el servicio WLAN AutoConfig se encuentra en

estado detenido con un tipo de inicio automático. Para iniciar el servicio, haz doble clic
en WLAN AutoConfig. En la pestaña General , haga clic en Inicioy, a continuación, haga
clic en Aceptar.

El servicio WLAN AutoConfig enumera los adaptadores inalámbricos y administra las

conexiones inalámbricas y los perfiles inalámbricos que contienen la configuración
necesaria para configurar el servidor para conectarse a una red inalámbrica.

Para obtener información general sobre la implementación de acceso inalámbrico,

consulta Proceso de implementación de acceso inalámbrico.
Proceso de implementación de acceso
inalámbrico
Artículo • 21/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

El proceso que se usa para implementar el acceso inalámbrico se produce en estas fases:

Fase 1: Implementación de AP
Planee, implemente y configure los AP para la conectividad de cliente inalámbrica y para
su uso con NPS. En función de sus preferencias y dependencias de red, puede
configurar previamente los valores en los AP inalámbricos antes de instalarlos en la red,
o bien puede configurarlos de forma remota después de la instalación.

Fase 2: configuración AD DS grupo de recursos

En AD DS, debe crear uno o varios grupos de seguridad de usuarios inalámbricos.

A continuación, identifique los usuarios a los que se permite el acceso inalámbrico a la

red.

Por último, agregue los usuarios a los grupos de seguridad de usuarios inalámbricos
adecuados que ha creado.

７ Nota

De forma predeterminada, la opción Permiso de acceso a la red en las propiedades

de acceso telefónico de la cuenta de usuario se configura con la opción Controlar
el acceso a través de la directiva de red NPS. A menos que tenga motivos
específicos para cambiar esta configuración, se recomienda mantener el valor
predeterminado. Esto le permite controlar el acceso a la red a través de las
directivas de red que configure en NPS.

Fase 3: directiva de grupo configuración

Configure la extensión de directivas de red inalámbrica (IEEE 802.11) directiva de grupo
mediante el Editor de administración de directivas de grupo Microsoft Management
Console (MMC).

Para configurar equipos miembros del dominio mediante la configuración de las

directivas de red inalámbrica, debe aplicar directiva de grupo. Cuando un equipo se une
por primera vez al dominio, directiva de grupo se aplica automáticamente. Si se realizan
cambios en directiva de grupo, la nueva configuración se aplica automáticamente:

Mediante directiva de grupo intervalos determinados previamente

Si un usuario de dominio cierra la sesión y vuelve a la red

Reiniciando el equipo cliente e iniciando sesión en el dominio

También puede forzar la directiva de grupo mientras ha iniciado sesión en un equipo

mediante la ejecución del comando gpupdate en el símbolo del sistema.

Fase 4: configuración de NPS

Use un asistente de configuración en NPS para agregar puntos de acceso inalámbricos
como clientes RADIUS y para crear las directivas de red que NPS usa al procesar
solicitudes de conexión.

Al usar el asistente para crear las directivas de red, especifique PEAP como tipo eap y el
grupo de seguridad de usuarios inalámbricos que se creó en la segunda fase.

Fase 5: Implementación de clientes

inalámbricos
Use equipos cliente para conectarse a la red.

En el caso de los equipos miembros del dominio que pueden iniciar sesión en la LAN
cableada, las opciones de configuración inalámbrica necesarias se aplican
automáticamente cuando directiva de grupo se actualiza.

Si ha habilitado la configuración en las directivas de red inalámbrica (IEEE 802.11) para

conectarse automáticamente cuando el equipo está dentro del intervalo de difusión de
la red inalámbrica, los equipos inalámbricos unidos a un dominio intentarán conectarse
automáticamente a la LAN inalámbrica.

Para conectarse a la red inalámbrica, los usuarios solo deben proporcionar sus
credenciales de nombre de usuario y contraseña de dominio cuando se lo soliciten
Windows.
Para planear la implementación de acceso inalámbrico, consulte Planeamiento de la
implementación de acceso inalámbrico.
Planificación de la implementación de
acceso inalámbrico
Artículo • 21/12/2022 • Tiempo de lectura: 17 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Antes de implementar el acceso inalámbrico, debe planear los siguientes elementos:

Instalación de puntos de acceso inalámbricos (AP) en la red

Acceso y configuración de cliente inalámbrico

En las secciones siguientes se proporcionan detalles sobre estos pasos de planeamiento.

Planeamiento de instalaciones de AP
inalámbricas
Al diseñar la solución de acceso a la red inalámbrica, debe hacer lo siguiente:

1. Determinar qué estándares deben admitir los AP inalámbricos

2. Determinar las áreas de cobertura en las que desea proporcionar un servicio
inalámbrico
3. Determinación de dónde desea buscar los AP inalámbricos

Además, debe planear un esquema de direcciones IP para las API inalámbricas y los
clientes inalámbricos. Consulte la sección Planeación de la configuración de aps
inalámbricos en NPS a continuación para obtener información relacionada.

Comprobación de la compatibilidad de LA AP inalámbrica

con los estándares
Con fines de coherencia y facilidad de implementación y administración de AP, se
recomienda implementar aps inalámbricos de la misma marca y modelo.

Los AP inalámbricos que implemente deben admitir lo siguiente:

IEEE 802.1X

Autenticación RADIUS
 Autenticación inalámbrica y cifrado. Se muestra en orden de más a menos
preferido:

1. WPA2-Enterprise con AES

2. WPA2-Enterprise con TKIP

3. WPA-Enterprise con AES

4. WPA-Enterprise con TKIP

７ Nota

Para implementar WPA2, debe usar adaptadores de red inalámbricos y AP

inalámbricos que también admitan WPA2. De lo contrario, use WPA-Enterprise.

Además, para proporcionar seguridad mejorada para la red, los AP inalámbricos deben
admitir las siguientes opciones de seguridad:

Filtros DHCP. La AP inalámbrica debe filtrar por los puertos IP para evitar la
transmisión de mensajes de difusión DHCP en aquellos casos en los que el cliente
inalámbrico está configurado como un servidor DHCP. El AP inalámbrico debe
impedir que el cliente envíe paquetes IP desde el puerto UDP 68 a la red.

Filtros DNS. La API inalámbrica debe filtrar por los puertos IP para evitar que un
cliente realice el trabajo como servidor DNS. El PUNTO de acceso inalámbrico debe
impedir que el cliente envíe paquetes IP desde el puerto TCP o UDP 53 a la red.

Aislamiento de cliente Si el punto de acceso inalámbrico proporciona

funcionalidades de aislamiento de cliente, debe habilitar la característica para
evitar posibles vulnerabilidades de suplantación de protocolo de resolución de
direcciones (ARP).

Identificar las áreas de cobertura de los usuarios

inalámbricos
Use dibujos arquitectónicos de cada planta para cada edificio a fin de identificar las
áreas en las que desea proporcionar cobertura inalámbrica. Por ejemplo, identifique las
oficinas, salas de conferencias, lobbies, restaurantes o oraciones adecuados.

En los dibujos, indique los dispositivos que interfieran con las señales inalámbricas,
como equipos médicos, cámaras de vídeo inalámbricas, teléfonos inalámbricos que
funcionan en el intervalo industrial, científico y médico (ISM) de 2,4 a 2,5 GHz, y
dispositivos Bluetooth habilitados.

En el dibujo, marque aspectos del edificio que podrían interferir con las señales
inalámbricas. Los objetos de metal usados en la construcción de un edificio pueden
afectar a la señal inalámbrica. Por ejemplo, los siguientes objetos comunes pueden
interferir con la propagación de señales: ascensores, calefacción y aire acondicionado, y
cejas de soporte concreto.

Consulte al fabricante de AP para obtener información sobre los orígenes que podrían
provocar atenuación de frecuencia de radio de AP inalámbrica. La mayoría de los puntos
de acceso proporcionan software de prueba que puede usar para comprobar la
intensidad de la señal, la tasa de errores y el rendimiento de los datos.

Determinación de dónde instalar los AP inalámbricos

En los dibujos arquitectónicos, localice los AP inalámbricos lo suficientemente cerca
como para proporcionar una amplia cobertura inalámbrica, pero lo suficientemente lejos
como para que no interfieran entre sí.

La distancia necesaria entre los puntos de acceso depende del tipo de antena AP y AP,
los aspectos del edificio que bloquean las señales inalámbricas y otras fuentes de
interferencia. Puede marcar las ubicaciones de AP inalámbricos para que cada AP
inalámbrico no esté a más de 300 pies de cualquier AP inalámbrico adyacente. Consulte
la documentación del fabricante de AP inalámbrico para ver las especificaciones de AP y
las directrices para la selección de ubicación.

Instale temporalmente direcciones IP inalámbricas en las ubicaciones especificadas en

los dibujos arquitectónicos. A continuación, con un portátil equipado con un adaptador
inalámbrico 802.11 y el software de encuesta del sitio que se suministra normalmente
con adaptadores inalámbricos, determine la intensidad de la señal dentro de cada área
de cobertura.

En las áreas de cobertura en las que la intensidad de la señal es baja, coloque el PUNTO
de acceso para mejorar la intensidad de señal para el área de cobertura, instale puntos
de acceso inalámbricos adicionales para proporcionar la cobertura necesaria, reubicar o
quitar orígenes de interferencias de señal.

Actualice los dibujos arquitectónicos para indicar la ubicación final de todos los AP
inalámbricos. Tener un mapa de ubicación de AP preciso le ayudará más adelante
durante las operaciones de solución de problemas o cuando desee actualizar o
reemplazar los AP.
Planeación de la configuración de cliente RADIUS de NPS
y AP inalámbrico
Puede usar NPS para configurar los AP inalámbricos individualmente o en grupos.

Si va a implementar una red inalámbrica grande que incluye muchos AP, es mucho más
fácil configurar los AP en grupos. Para agregar los AP como grupos de cliente RADIUS
en NPS, debe configurar los AP con estas propiedades.

Los AP inalámbricos se configuran con direcciones IP del mismo intervalo de

direcciones IP.

Los AP inalámbricos están configurados con el mismo secreto compartido.

Planear el uso de PEAP Fast Reconnect

En una infraestructura 802.1X, los puntos de acceso inalámbricos se configuran como
clientes RADIUS para servidores RADIUS. Cuando se implementa la reconexión rápida de
PEAP, no es necesario autenticar con cada nueva asociación un cliente inalámbrico que
se desenvía entre dos o más puntos de acceso.

La reconexión rápida de PEAP reduce el tiempo de respuesta para la autenticación entre

el cliente y el autenticador porque la solicitud de autenticación se reenvía desde el
nuevo punto de acceso al NPS que originalmente realizó la autenticación y autorización
para la solicitud de conexión de cliente.

Dado que el cliente PEAP y NPS usan propiedades de conexión de seguridad de la capa
de transporte (TLS) almacenadas previamente en caché (cuya colección se denomina
identificador TLS), nps puede determinar rápidamente que el cliente está autorizado
para una reconexión.

） Importante

Para que la reconexión rápida funcione correctamente, los AP deben configurarse

como clientes RADIUS del mismo NPS.

Si el NPS original deja de estar disponible o si el cliente se mueve a un punto de acceso

configurado como cliente RADIUS a otro servidor RADIUS, se debe realizar la
autenticación completa entre el cliente y el nuevo autenticador.

Configuración de AP inalámbrico
En la lista siguiente se resumen los elementos que se configuran normalmente en
direcciones IP inalámbricas compatibles con 802.1X:

７ Nota

Los nombres de los elementos pueden variar según la marca y el modelo y pueden
ser diferentes de los de la lista siguiente. Consulte la documentación de LA AP
inalámbrica para obtener detalles específicos de la configuración.

Identificador del conjunto de servicios (SSID). Este es el nombre de la red

inalámbrica (por ejemplo, ExampleWlan) y el nombre que se anuncia a los clientes
inalámbricos. Para reducir la confusión, el SSID que decida anunciar no debe
coincidir con el SSID que difunde ninguna red inalámbrica que se encuentra dentro
del intervalo de recepción de la red inalámbrica.

En los casos en los que se implementan varios PUNTOS de acceso inalámbricos

como parte de la misma red inalámbrica, configure cada AP inalámbrico con el
mismo SSID. En los casos en los que se implementan varios PUNTOS de acceso
inalámbricos como parte de la misma red inalámbrica, configure cada AP
inalámbrico con el mismo SSID.

En los casos en los que tenga que implementar redes inalámbricas diferentes para
satisfacer necesidades empresariales específicas, las API inalámbricas de una red
deben difundir un SSID diferente al SSID de las otras redes. Por ejemplo, si necesita
una red inalámbrica independiente para sus empleados e invitados, puede
configurar los AP inalámbricos para la red empresarial con el SSID establecido para
difundir ExampleWLAN. En el caso de la red invitada, puede establecer el SSID de
cada AP inalámbrico para difundir GuestWLAN. De este modo, los empleados e
invitados pueden conectarse a la red deseada sin confusión innecesaria.

 Sugerencia

Algunas API inalámbricas tienen la capacidad de difundir varios SSID para dar
cabida a implementaciones de varias redes. Las API inalámbricas que pueden
difundir varios SSID pueden reducir los costos de implementación y
mantenimiento operativo.

Autenticación inalámbrica y cifrado.

La autenticación inalámbrica es la autenticación de seguridad que se usa cuando el

cliente inalámbrico se asocia a un punto de acceso inalámbrico.
El cifrado inalámbrico es el cifrado de cifrado de seguridad que se usa con la
autenticación inalámbrica para proteger las comunicaciones que se envían entre la
AP inalámbrica y el cliente inalámbrico.

Dirección IP de AP inalámbrica (estática). En cada AP inalámbrico, configure una

dirección IP estática única. Si un servidor DHCP atiende la subred, asegúrese de
que todas las direcciones IP de AP se encuentran dentro de un intervalo de
exclusión DHCP para que el servidor DHCP no intente emitir la misma dirección IP
a otro equipo o dispositivo. Los intervalos de exclusión se documentan en el
procedimiento "Para crear y activar un nuevo ámbito DHCP" en la Guía de red
principal. Si planea configurar aps como clientes RADIUS por grupo en NPS, cada
AP del grupo debe tener una dirección IP del mismo intervalo de direcciones IP.

Nombre DNS. Algunos AP inalámbricos se pueden configurar con un nombre

DNS. Configure cada AP inalámbrico con un nombre único. Por ejemplo, si tiene un
AP inalámbrico implementado en un edificio de varias historias, podría nombrar
los tres primeros AP inalámbricos que se implementan en la tercera planta AP3-01,
AP3-02 y AP3-03.

Máscara de subred ap inalámbrica. Configure la máscara para designar qué parte

de la dirección IP es el identificador de red y qué parte de la dirección IP es el host.

Servicio DHCP de AP. Si la AP inalámbrica tiene un servicio DHCP integrado,

deshabilite esta opción.

Secreto compartido RADIUS. Use un secreto compartido RADIUS único para cada
AP inalámbrico a menos que planee configurar clientes NPS RADIUS en grupos, en
cuyo caso debe configurar todos los AP del grupo con el mismo secreto
compartido. Los secretos compartidos deben ser una secuencia aleatoria de al
menos 22 caracteres, con letras mayúsculas y minúsculas, números y signos de
puntuación. Para garantizar la aleatoriedad, puede usar un programa de
generación de caracteres aleatorios para crear los secretos compartidos. Se
recomienda registrar el secreto compartido para cada AP inalámbrico y
almacenarlo en una ubicación segura, como una oficina segura. Al configurar
clientes RADIUS en la consola NPS, creará una versión virtual de cada AP. El
secreto compartido que configure en cada AP virtual en NPS debe coincidir con el
secreto compartido en el AP físico real.

Dirección IP del servidor RADIUS. Escriba la dirección IP del NPS que desea usar
para autenticar y autorizar las solicitudes de conexión a este punto de acceso.

Puertos UDP. De forma predeterminada, NPS usa los puertos UDP 1812 y 1645
para los mensajes de autenticación RADIUS y los puertos UDP 1813 y 1646 para los
 mensajes de contabilidad RADIUS. Se recomienda no cambiar la configuración
predeterminada de los puertos UDP RADIUS.

VSA. Algunos AP inalámbricos requieren atributos específicos del proveedor (VSA)

para proporcionar funcionalidad de AP inalámbrica completa.

Filtrado DHCP. Configure direcciones IP inalámbricas para impedir que los clientes
inalámbricos envíen paquetes IP desde el puerto UDP 68 a la red. Consulte la
documentación de la API inalámbrica para configurar el filtrado DHCP.

Filtrado de DNS. Configure direcciones IP inalámbricas para impedir que los

clientes inalámbricos envíen paquetes IP desde el puerto TCP o UDP 53 a la red.
Consulte la documentación de la API inalámbrica para configurar el filtrado de
DNS.

Planeamiento de la configuración y el acceso

de cliente inalámbrico
Al planear la implementación del acceso inalámbrico autenticado por 802.1X, debe tener
en cuenta varios factores específicos del cliente:

Compatibilidad con la planeación de varios estándares.

Determine si todos los equipos inalámbricos usan la misma versión de Windows o

si son una combinación de equipos que ejecutan sistemas operativos diferentes. Si
son diferentes, asegúrese de que comprende las diferencias en los estándares
admitidos por los sistemas operativos.

Determine si todos los adaptadores de red inalámbricos de todos los equipos

cliente inalámbricos admiten los mismos estándares inalámbricos o si necesita
admitir distintos estándares. Por ejemplo, determine si algunos controladores de
hardware del adaptador de red admiten WPA2-Enterprise y AES, mientras que
otros solo admiten WPA-Enterprise y TKIP.

Planear el modo de autenticación de cliente. Los modos de autenticación definen

cómo Windows los clientes procesan las credenciales de dominio. Puede
seleccionar entre los tres modos de autenticación de red siguientes en las
directivas de red inalámbrica.

1. Reautenticación de usuarios. Este modo especifica que la autenticación

siempre se realiza mediante credenciales de seguridad basadas en el estado
actual del equipo. Cuando ningún usuario ha iniciado sesión en el equipo, la
autenticación se realiza mediante las credenciales del equipo. Cuando un
 usuario ha iniciado sesión en el equipo, la autenticación siempre se realiza
con las credenciales de usuario.

2. Sólo equipo. El modo de solo equipo especifica que la autenticación siempre

se realiza utilizando solo las credenciales del equipo.

3. Autenticación de usuario. El modo de autenticación de usuario especifica

que la autenticación solo se realiza cuando el usuario ha iniciado sesión en el
equipo. Cuando no hay ningún usuario que haya iniciado sesión en el equipo,
no se realizan intentos de autenticación.

Planear restricciones inalámbricas. Determine si desea proporcionar a todos los

usuarios inalámbricos el mismo nivel de acceso a la red inalámbrica o si desea
restringir el acceso a algunos de los usuarios inalámbricos. Puede aplicar
restricciones en NPS a grupos específicos de usuarios inalámbricos. Por ejemplo,
puede definir días y horas específicos a los que determinados grupos tienen
permiso de acceso a la red inalámbrica.

Métodos de planeamiento para agregar nuevos equipos inalámbricos. En el caso

de los equipos con capacidad inalámbrica que están unidos a su dominio antes de
implementar la red inalámbrica, si el equipo está conectado a un segmento de la
red cableada que no está protegido por 802.1X, las opciones de configuración
inalámbrica se aplican automáticamente después de configurar directivas de red
inalámbrica (IEEE 802.11) en el controlador de dominio y después de actualizar
directiva de grupo en el cliente inalámbrico.

Sin embargo, para los equipos que aún no están unidos a su dominio, debe
planear un método para aplicar la configuración necesaria para el acceso
autenticado mediante 802.1X. Por ejemplo, determine si desea unir el equipo al
dominio mediante uno de los métodos siguientes.

1. Conectar el equipo a un segmento de la red cableada que no está protegida

por 802.1X y, a continuación, une el equipo al dominio.

2. Proporcione a los usuarios inalámbricos los pasos y la configuración que

necesitan para agregar su propio perfil de arranque inalámbrico, lo que les
permite unir el equipo al dominio.

3. Asigne personal de IT para unir clientes inalámbricos al dominio.

Planificación de la compatibilidad con varios estándares

La extensión de directivas de red inalámbrica (IEEE 802.11) de directiva de grupo
proporciona una amplia gama de opciones de configuración para admitir una variedad
de opciones de implementación.

Puede implementar direcciones IP inalámbricas configuradas con los estándares que

desea admitir y, a continuación, configurar varios perfiles inalámbricos en directivas de
red inalámbrica (IEEE 802.11), con cada perfil que especifique un conjunto de estándares
que necesite.

Por ejemplo, si la red tiene equipos inalámbricos que admiten WPA2-Enterprise y AES,
otros equipos que admiten WPA-Enterprise y AES, y otros equipos que solo admiten
WPA-Enterprise y TKIP, debe determinar si desea:

Configure un único perfil para admitir todos los equipos inalámbricos mediante el
método de cifrado más débil que admiten todos los equipos( en este caso, WPA-
Enterprise y TKIP.
Configure dos perfiles para proporcionar la mejor seguridad posible que sea
compatible con cada equipo inalámbrico. En este caso, configuraría un perfil que
especifica el cifrado más seguro (WPA2-Enterprise y AES) y un perfil que usa el
cifrado más WPA-Enterprise y TKIP. En este ejemplo, es esencial colocar el perfil
que usa WPA2-Enterprise Y AES más alto en el orden de preferencia. Los equipos
que no pueden usar WPA2-Enterprise y AES saltarán automáticamente al siguiente
perfil en el orden de preferencia y procesarán el perfil que especifica WPA-
Enterprise y TKIP.

） Importante

Debe colocar el perfil con los estándares más seguros en la lista ordenada de
perfiles, ya que los equipos que se conectan usan el primer perfil que pueden usar.

Planeamiento del acceso restringido a la red inalámbrica

En muchos casos, es posible que quiera proporcionar a los usuarios inalámbricos
distintos niveles de acceso a la red inalámbrica. Por ejemplo, es posible que desee
permitir a algunos usuarios acceso sin restricciones, cualquier hora del día, todos los
días de la semana. Para otros usuarios, es posible que solo quiera permitir el acceso
durante las horas centrales, de lunes a viernes, y denegar el acceso el sábado y el
domingo.

En esta guía se proporcionan instrucciones para crear un entorno de acceso que coloca
a todos los usuarios inalámbricos en un grupo con acceso común a los recursos
inalámbricos. Cree un grupo de seguridad de usuarios inalámbricos en el complemento
Usuarios y equipos de Active Directory y, a continuación, haga que todos los usuarios a
los que quiera conceder acceso inalámbrico sea miembro de ese grupo.

Al configurar directivas de red NPS, se especifica el grupo de seguridad de usuarios

inalámbricos como el objeto que NPS procesa al determinar la autorización.

Sin embargo, si la implementación requiere compatibilidad con distintos niveles de

acceso, solo tiene que hacer lo siguiente:

1. Cree más de un grupo de seguridad de usuarios inalámbricos para crear grupos de

seguridad inalámbricos adicionales en Usuarios y equipos de Active Directory. Por
ejemplo, puede crear un grupo que contenga usuarios que tengan acceso
completo, un grupo para aquellos que solo tengan acceso durante el horario
laboral normal y otros grupos que se ajusten a otros criterios que coincidan con
sus requisitos.

2. Agregue usuarios a los grupos de seguridad adecuados que ha creado.

3. Configure directivas de red NPS adicionales para cada grupo de seguridad

inalámbrico adicional y configure las directivas para aplicar las condiciones y
restricciones que necesita para cada grupo.

Métodos de planeamiento para agregar nuevos equipos

inalámbricos
El método preferido para unir nuevos equipos inalámbricos al dominio y, a
continuación, iniciar sesión en el dominio es mediante una conexión cableada a un
segmento de la LAN que tiene acceso a los controladores de dominio y que no está
protegido por un conmutador Ethernet de autenticación 802.1X.

Sin embargo, en algunos casos, puede que no sea práctico usar una conexión cableada
para unir equipos al dominio o que un usuario use una conexión cableada para su
primer intento de inicio de sesión mediante equipos que ya están unidos al dominio.

Para unir un equipo al dominio mediante una conexión inalámbrica o para que los
usuarios inicien sesión en el dominio la primera vez mediante un equipo unido a un
dominio y una conexión inalámbrica, los clientes inalámbricos deben establecer primero
una conexión a la red inalámbrica en un segmento que tenga acceso a los controladores
de dominio de red mediante uno de los métodos siguientes.

1. Un miembro del personal de IT une un equipo inalámbrico al dominio y, a

continuación, configura un perfil inalámbrico de arranque de inicio de sesión
 único. Con este método, un administrador de TI conecta el equipo inalámbrico a la
red Ethernet cableada y, a continuación, une el equipo al dominio. A continuación,
el administrador distribuye el equipo al usuario. Cuando el usuario inicia el equipo,
las credenciales de dominio que especifican manualmente para el proceso de
inicio de sesión del usuario se usan para establecer una conexión a la red
inalámbrica e iniciar sesión en el dominio.

2. El usuario configura manualmente el equipo inalámbrico con perfil inalámbrico

de arranque y, a continuación, se une al dominio. Con este método, los usuarios
configuran manualmente sus equipos inalámbricos con un perfil inalámbrico de
arranque según las instrucciones de un administrador de TI. El perfil inalámbrico de
arranque permite a los usuarios establecer una conexión inalámbrica y, a
continuación, unir el equipo al dominio. Después de unir el equipo al dominio y
reiniciar el equipo, el usuario puede iniciar sesión en el dominio mediante una
conexión inalámbrica y sus credenciales de cuenta de dominio.

Para implementar el acceso inalámbrico, consulte Implementación de acceso

inalámbrico.
Implementación de acceso inalámbrico
Artículo • 21/12/2022 • Tiempo de lectura: 41 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Siga estos pasos para implementar el acceso inalámbrico:

Implementación y configuración de AP inalámbricas

Crear un grupo de seguridad de usuarios inalámbricos

Configurar directivas de red inalámbrica (IEEE 802.11)

Configuración de NPS

Unir nuevos equipos inalámbricos al dominio

Implementación y configuración de AP
inalámbricas
Siga estos pasos para implementar y configurar los AP inalámbricos:

Especificar frecuencias de canal ap inalámbrico

Configuración de AP inalámbricas

７ Nota

Los procedimientos de esta guía no incluyen instrucciones para los casos en que se
abre el cuadro de diálogo Control de cuentas de usuario para solicitar permiso
para continuar. Si aparece este cuadro de diálogo en respuesta a sus acciones
mientras realiza los procedimientos de esta guía, haga clic en Continuar.

Especificar frecuencias de canal ap inalámbrico

Al implementar varios AP inalámbricos en un único sitio geográfico, debe configurar los
AP inalámbricos que tienen señales superpuestas para usar frecuencias de canal únicas
para reducir la interferencia entre los AP inalámbricos.

Puede usar las siguientes directrices para ayudarle a elegir frecuencias de canal que no
entren en conflicto con otras redes inalámbricas en la ubicación geográfica de la red
inalámbrica.

Si hay otras organizaciones que tienen oficinas cerca o en el mismo edificio que su
organización, identifique si hay redes inalámbricas propiedad de esas
organizaciones. Averigüe tanto la ubicación como las frecuencias de canal
asignadas de sus AP inalámbricas, ya que necesita asignar diferentes frecuencias
de canal a los AP y necesita determinar la mejor ubicación para instalar el AP.

Identifique las señales inalámbricas superpuestas en los pisos adyacentes dentro

de su propia organización. Después de identificar las áreas de cobertura
superpuestas fuera y dentro de su organización, asigne frecuencias de canal para
los AP inalámbricos, lo que garantiza que se asignen diferentes frecuencias de
canal a los dos PUNTOS inalámbricos con cobertura superpuesta.

Configuración de AP inalámbricas
Usa la siguiente información junto con la documentación del producto proporcionada
por el fabricante del AP inalámbrico para configurar los AP inalámbricos.

Este procedimiento enumera los elementos configurados habitualmente en un AP

inalámbrico. Los nombres de los elementos pueden variar según la marca y el modelo y
pueden ser diferentes de los de la lista siguiente. Para obtener detalles específicos,
consulta la documentación del AP inalámbrico.

Para configurar los AP inalámbricos

SSID. Especifique el nombre de las redes inalámbricas (por ejemplo,
ExampleWLAN). Este es el nombre que se anuncia a los clientes inalámbricos.

Cifrado. Especifique WPA2-Enterprise (preferido) o WPA-Enterprise, y cifrado AES

(preferido) o cifrado TKIP, en función de las versiones admitidas por los
adaptadores de red del equipo cliente inalámbrico.

Dirección IP de AP inalámbrica (estática) . En cada AP, configure una dirección IP

estática única que se encuentre dentro del intervalo de exclusión del ámbito DHCP
de la subred. El uso de una dirección excluida de la asignación por DHCP impide
que el servidor DHCP asigne la misma dirección IP a un equipo u otro dispositivo.

Máscara de subred. Configure esta opción para que coincida con la configuración
de máscara de subred de la LAN a la que ha conectado el AP inalámbrico.

Nombre DNS. Algunos AP inalámbricos se pueden configurar con un nombre

DNS. El servicio DNS de la red puede resolver nombres DNS en una dirección IP.
 En cada AP inalámbrico que admita esta característica, escriba un nombre único
para la resolución DNS.

Servicio DHCP. Si el AP inalámbrico tiene un servicio DHCP integrado,

deshabilítelo.

Secreto compartido RADIUS. Use un secreto compartido RADIUS único para cada
AP inalámbrica, a menos que esté planeando configurar LOS AP como clientes
RADIUS en NPS por grupo. Si tiene previsto configurar puntos de acceso por
grupo en NPS, el secreto compartido debe ser el mismo para todos los miembros
del grupo. Además, cada secreto compartido que use debe ser una secuencia
aleatoria de al menos 22 caracteres que combine letras mayúsculas y minúsculas,
números y puntuación. Para garantizar la aleatoriedad, puede usar un generador
de caracteres aleatorios, como el generador de caracteres aleatorios que se
encuentra en el Asistente para configurar 802.1X de NPS, para crear los secretos
compartidos.

 Sugerencia

Registre el secreto compartido para cada AP inalámbrico y almacénelo en una

ubicación segura, como una caja fuerte de oficina. Debe conocer el secreto
compartido para cada AP inalámbrico al configurar clientes RADIUS en el NPS.

Dirección IP del servidor RADIUS. Escriba la dirección IP del servidor que ejecuta
NPS.

Puertos UDP. De forma predeterminada, NPS usa los puertos UDP 1812 y 1645
para los mensajes de autenticación y los puertos UDP 1813 y 1646 para
contabilizar mensajes. Se recomienda usar estos mismos puertos UDP en los AP,
pero si tiene un motivo válido para usar puertos diferentes, asegúrese de que no
solo configure los AP con los nuevos números de puerto, sino que también vuelva
a configurar todos los NPS para usar los mismos números de puerto que los AP. Si
los AP y los NPS no están configurados con los mismos puertos UDP, NPS no
puede recibir ni procesar solicitudes de conexión de los AP, y se producirá un error
en todos los intentos de conexión inalámbrica de la red.

VSA. Algunos AP inalámbricos requieren atributos específicos del proveedor (VSA)

para proporcionar una funcionalidad completa de AP inalámbrica. Los VSA se
agregan en la directiva de red NPS.

Filtrado DHCP. Configure los AP inalámbricos para impedir que los clientes
inalámbricos envíen paquetes IP desde el puerto UDP 68 a la red, tal y como lo
 documenta el fabricante del AP inalámbrico.

Filtrado de DNS. Configure los AP inalámbricos para impedir que los clientes
inalámbricos envíen paquetes IP desde el puerto TCP o UDP 53 a la red, tal como
lo documenta el fabricante de LA AP inalámbrica.

Crear grupos de seguridad para usuarios

inalámbricos
Siga estos pasos para crear uno o varios grupos de seguridad de usuarios inalámbricos
y, a continuación, agregue usuarios al grupo de seguridad de usuarios inalámbricos
adecuado:

Crear un grupo de seguridad de usuarios inalámbricos

Agregar usuarios al grupo de seguridad inalámbrica

Crear un grupo de seguridad de usuarios inalámbricos

Puede usar este procedimiento para crear un grupo de seguridad inalámbrica en el
complemento Usuarios y equipos de Active Directory Microsoft Management Console
(MMC).

El requisito mínimo para llevar a cabo este procedimiento consiste en pertenecer a

Admins. del dominio o grupo equivalente.

Para crear un grupo de seguridad de usuarios inalámbricos

1. Haga clic en Inicio, luego en Herramientas administrativas y, a continuación, haga

clic en Usuarios y equipos de Active Directory. Se abre el complemento Usuarios
y equipos de Active Directory. Haga clic en el nodo de su dominio si no está
seleccionado. Por ejemplo, si el dominio es [Link], haga clic en
[Link].

2. En el panel de detalles, haga clic con el botón derecho en la carpeta en la que

desea agregar un nuevo grupo (por ejemplo, haga clic con el botón derecho en
Usuarios), seleccione Nuevoy, a continuación, haga clic en Grupo.

3. En Nuevo objeto: grupo, en Nombre de grupo, escriba un nombre para el nuevo

grupo. Por ejemplo, escriba Grupo inalámbrico.

4. En Ámbito de grupo, seleccione una de las opciones siguientes:

 Local de dominio

Global

Universal

5. En Tipo de grupo, seleccione Seguridad.

6. Haga clic en OK.

Si necesita más de un grupo de seguridad para los usuarios inalámbricos, repita estos
pasos para crear grupos de usuarios inalámbricos adicionales. Más adelante, puede
crear directivas de red individuales en NPS para aplicar diferentes condiciones y
restricciones a cada grupo, proporcionándoles diferentes permisos de acceso y reglas
de conectividad.

Agregar usuarios al grupo de seguridad usuarios

inalámbricos
Puede usar este procedimiento para agregar un usuario, equipo o grupo al grupo de
seguridad inalámbrica en el complemento Usuarios y equipos de Active Directory
Microsoft Management Console (MMC).

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo Admins.

del dominio o grupo equivalente.

Para agregar usuarios al grupo de seguridad inalámbrica

1. Haga clic en Inicio, luego en Herramientas administrativas y, a continuación, haga
clic en Usuarios y equipos de Active Directory. Se abre MMC de Usuarios y
equipos de Active Directory. Haga clic en el nodo de su dominio si no está
seleccionado. Por ejemplo, si el dominio es [Link], haga clic en
[Link].

2. En el panel de detalles, haga doble clic en la carpeta que contiene el grupo de

seguridad inalámbrica.

3. En el panel de detalles, haga clic con el botón derecho en el grupo de seguridad

inalámbrica y, a continuación, haga clic en Propiedades. Se abre el cuadro de
diálogo Propiedades del grupo de seguridad.

4. En la pestaña Miembros , haga clic en Agregar y, a continuación, complete uno de

los procedimientos siguientes para agregar un equipo o agregar un usuario o
grupo.
Para agregar un usuario o grupo

1. En Escriba los nombres de objeto que desea seleccionar, escriba el nombre del
usuario o grupo que desea agregar y, a continuación, haga clic en Aceptar.

2. Para asignar la pertenencia a grupos a otros usuarios o grupos, repita el paso 1 de

este procedimiento.

Para agregar un equipo

1. Haga clic en Tipos de objeto. Se abre el cuadro de diálogo Tipos de objeto .

2. En Tipos de objeto, seleccione Equipos y, a continuación, haga clic en Aceptar.

3. En Escriba los nombres de objeto que desea seleccionar, escriba el nombre del
equipo que desea agregar y, a continuación, haga clic en Aceptar.

4. Para asignar la pertenencia a grupos a otros equipos, repita los pasos 1 a 3 de este
procedimiento.

Configurar directivas de red inalámbrica (IEEE

802.11)
Siga estos pasos para configurar las directivas de red inalámbrica (IEEE 802.11) directiva
de grupo extensión:

Abrir o agregar y abrir un objeto de directiva de grupo

Activar directivas predeterminadas de red inalámbrica (IEEE 802.11)

Configurar la nueva directiva de red inalámbrica

Abrir o agregar y abrir un objeto de directiva de grupo

De forma predeterminada, la característica de administración de directiva de grupo se
instala en los equipos que ejecutan Windows Server 2016 cuando se instala el rol de
servidor de Servicios de dominio de Active Directory (AD DS) y el servidor se configura
como controlador de dominio. El siguiente procedimiento que describe cómo abrir la
consola de administración de directiva de grupo (GPMC) en el controlador de dominio.
A continuación, el procedimiento describe cómo abrir un objeto de directiva de grupo
de nivel de dominio (GPO) existente para editarlo o crear un nuevo GPO de dominio y
abrirlo para su edición.
El requisito mínimo para llevar a cabo este procedimiento consiste en pertenecer a
Admins. del dominio o grupo equivalente.

Para abrir o agregar y abrir un objeto directiva de grupo

1. En el controlador de dominio, haga clic en Inicio, en Windows Herramientas

administrativas y, a continuación, en Administración de directiva de grupo. Se
abre la Consola de administración de directivas de grupo.

2. En el panel izquierdo, haga doble clic en su bosque. Por ejemplo, haga doble clic
en Bosque: [Link].

3. En el panel izquierdo, haz doble clic en Dominios y, a continuación, haz doble clic
en el dominio para el que deseas administrar un objeto de directiva de grupo. Por
ejemplo, haz doble clic en [Link].

4. Realice una de las siguientes acciones:

Para abrir un GPO de nivel de dominio existente para su edición, haga

doble clic en el dominio que contiene el objeto de directiva de grupo que
desea administrar, haga clic con el botón derecho en la directiva de dominio
que desea administrar, como la directiva de dominio predeterminada y, a
continuación, haga clic en Editar. se abre directiva de grupo Editor de
administración.

Para crear un nuevo objeto de directiva de grupo y abrirlo para su edición,

haga clic con el botón derecho en el dominio para el que desea crear un
nuevo objeto directiva de grupo y, a continuación, haga clic en Crear un GPO
en este dominio y vincularlo aquí.

En el cuadro Nuevo GPO, en Nombre, escribe un nombre para el nuevo

objeto de directiva de grupo y, a continuación, haz clic en Aceptar.

Haga clic con el botón derecho en el nuevo objeto directiva de grupo y, a

continuación, haga clic en Editar. se abre directiva de grupo Editor de
administración.

En la sección siguiente usará directiva de grupo Editor de administración para crear una
directiva inalámbrica.

Activar directivas predeterminadas de red inalámbrica

(IEEE 802.11)
En este procedimiento se describe cómo activar las directivas predeterminadas de red
inalámbrica (IEEE 802.11) mediante el Editor de administración de directiva de grupo
(GPME).

７ Nota

Después de activar las directivas de Windows Vista y versiones posteriores de las

directivas de red inalámbrica (IEEE 802.11) o la versión Windows XP, la opción de
versión se quita automáticamente de la lista de opciones al hacer clic con el botón
derecho en Directivas de red inalámbrica (IEEE 802.11). Esto ocurre porque después
de seleccionar una versión de directiva, la directiva se agrega en el panel de
detalles del GPME al seleccionar el nodo Directivas de red inalámbrica (IEEE
802.11). Este estado permanece a menos que elimine la directiva inalámbrica, en
cuyo momento la versión de la directiva inalámbrica vuelve al menú contextual de
las directivas de red inalámbrica (IEEE 802.11) en el GPME. Además, las directivas
inalámbricas solo se muestran en el panel de detalles de GPME cuando se
selecciona el nodo Directivas de red inalámbrica (IEEE 802.11).

El requisito mínimo para llevar a cabo este procedimiento consiste en pertenecer a

Admins. del dominio o grupo equivalente.

Para activar directivas predeterminadas de red inalámbrica (IEEE

802.11)
1. Siga el procedimiento anterior, Para abrir o agregar y abrir un objeto de directiva
de grupo para abrir el GPME.

2. En el GPME, en el panel izquierdo, haga doble clic en Configuración del equipo,

haga doble clic en Directivas, haga doble clic en Windows Configuración y, a
continuación, haga doble clic en Seguridad Configuración.
3. En Seguridad Configuración, haga clic con el botón derecho en Redes
inalámbricas (IEEE 802.11) Directivas y, a continuación, haga clic en Crear una
nueva directiva inalámbrica para Windows Vista y versiones posteriores.
 4. Se abre el cuadro de diálogo Nuevas propiedades de directiva de red inalámbrica
. En Nombre de directiva, escriba un nuevo nombre para la directiva o mantenga el
nombre predeterminado. Haga clic en Aceptar para guardar la directiva. La
directiva predeterminada se activa y se muestra en el panel de detalles del GPME
con el nuevo nombre que proporcionó o con el nombre predeterminado Nueva
directiva de red inalámbrica.

5. En el panel de detalles, haga doble clic en Nueva directiva de red inalámbrica para
abrirla.

En la sección siguiente, puede realizar la configuración de directivas, el orden de

preferencias de procesamiento de directivas y los permisos de red.

Configurar la nueva directiva de red inalámbrica

Puede usar los procedimientos de esta sección para configurar la directiva de red
inalámbrica (IEEE 802.11). Esta directiva le permite configurar las opciones de seguridad
y autenticación, administrar perfiles inalámbricos y especificar permisos para redes
inalámbricas que no están configuradas como redes preferidas.
 Configurar un perfil de conexión inalámbrica para PEAP-MS-CHAP v2

Establecer el orden de preferencia para perfiles de conexión inalámbrica

Definición de permisos de red

Configurar un perfil de conexión inalámbrica para PEAP-MS-CHAP

v2

Este procedimiento indica los pasos necesarios para configurar un perfil inalámbrico
PEAP-MS-CHAP v2.

La pertenencia a Administradores de dominio, o equivalente, es lo mínimo necesario

para completar este procedimiento.

Para configurar un perfil de conexión inalámbrica para PEAP-MS-

CHAP v2

1. En GPME, en el cuadro de diálogo de propiedades de red inalámbrica para la

directiva que acaba de crear, en la pestaña General y en Descripción, escriba una
breve descripción de la directiva.

2. Para especificar que wlan AutoConfig se usa para configurar la configuración del
adaptador de red inalámbrica, asegúrese de que está seleccionado usar Windows
servicio de configuración automática wlan para los clientes.

3. En Conectar a las redes disponibles en el orden de los perfiles que se enumeran

a continuación, haga clic en Agregar y, a continuación, seleccione Infraestructura.
Se abre el cuadro de diálogo Nuevas propiedades de perfil .

4. En el cuadro de diálogoNueva propiedades de perfil , en la pestaña Conexión , en

el campo Nombre del perfil, escriba un nuevo nombre para el perfil. Por ejemplo,
escriba [Link] perfil WLAN para Windows 10.

5. En Nombres de red (SSID), escriba el SSID que corresponde al SSID configurado

en los AP inalámbricos y, a continuación, haga clic en Agregar.

Si tu implementación utiliza varios SSID y cada AP inalámbrico usa la misma

configuración de seguridad inalámbrica, repite este paso para agregar el SSID a
cada AP inalámbrico al que desees aplicar este perfil.

Si tu implementación utiliza varios SSID y la configuración de seguridad de los

SSID no coincide, configura un perfil separado para cada grupo de SSID que utilice
la misma configuración de seguridad. Por ejemplo, si tienes un grupo de AP
 inalámbricos configurado para usar WPA2-Enterprise y AES, y otro grupo de AP
inalámbricos que usa WPA-Enterprise y TKIP, configura un perfil para cada grupo
de AP inalámbricos.

6. Si el texto predeterminado NEWSSID está presente, selecciónelo y, a continuación,

haga clic en Quitar.

7. Si implementaste puntos de acceso inalámbrico que están configurados para

suprimir la señal de difusión, selecciona Conectarse aunque la red no sea de
difusión.

７ Nota

Si se habilita esta opción se puede generar un riesgo de seguridad porque los

clientes inalámbricos van a buscar e intentar conexiones con cualquier red
inalámbrica. De manera predeterminada, esta configuración no está
habilitada.

8. Haz clic en la pestaña Seguridad, haz clic en Avanzadas y, luego, configura lo

siguiente:

a. Para configurar las opciones avanzadas de 802.1X, en IEEE 802.1X, activa la

opción Aplicar configuración 802.1X avanzada.

Cuando se aplica la configuración avanzada 802.1X, los valores

predeterminados de Max Eapol-Start Msgs, Held Period, Start Period y Auth
Period son suficientes para las implementaciones inalámbricas típicas. Por este
motivo, no es necesario cambiar los valores predeterminados a menos que
tenga un motivo específico para hacerlo.

b. Para habilitar el inicio de sesión único, activa la opción Habilitar inicio de sesión
único en esta red.

c. Los demás valores predeterminados de Inicio de sesión único son suficientes

para las implementaciones inalámbricas típicas.

d. En Movilidad rápida, si tu AP inalámbrico está configurado para la

autenticación previa, selecciona Esta red usa autenticación previa.

9. Para especificar que las comunicaciones inalámbricas cumplen los estándares FIPS
140-2, seleccione Realizar criptografía en modo certificado FIPS 140-2.

10. Haga clic en Aceptar para volver a la pestaña Seguridad. En Seleccionar los
métodos de seguridad de esta red, en Autenticación, seleccione WPA2-Enterprise
 si es compatible con los adaptadores de red de cliente inalámbrico y AP
inalámbrico. Si no lo es, selecciona WPA-Enterprise.

11. En Cifrado, si es compatible con el AP inalámbrico y los adaptadores de red del

cliente inalámbrico, seleccione AES-CCMP. Si usa puntos de acceso y adaptadores
de red inalámbrica que admiten 802.11ac, seleccione AES-GCMP. Si no lo es,
selecciona TKIP.

７ Nota

La configuración de autenticación y cifrado debe coincidir con las opciones

configuradas en los AP inalámbricos. La configuración predeterminada para el
modo de autenticación, los errores máximos de autenticación y la
información de usuario de caché para las conexiones posteriores a esta red
son suficientes para las implementaciones inalámbricas típicas.

12. En Seleccione un método de autenticación de red, elige EAP protegido (PEAP) y,

luego, haz clic en Propiedades. Se abre el cuadro de diálogo Propiedades de EAP
protegidas .

13. En Propiedades protegidas de EAP, confirme que se ha seleccionado Comprobar

la identidad del servidor validando el certificado .

14. En Entidades de certificación raíz de confianza, seleccione la entidad de

certificación raíz (CA) de confianza que emitió el certificado de servidor a NPS.

７ Nota

Esta configuración limita las CA raíz en las que confían los clientes a las CA
seleccionadas. Si no se seleccionan ca raíz de confianza, los clientes confiarán
en todas las CA raíz enumeradas en su almacén de certificados de entidades
de certificación raíz de confianza.

15. En la lista Seleccione el método de autenticación, elige Contraseña segura (EAP-

MS-CHAP v2).

16. Haga clic en Configurar. En el cuadro de diálogo Propiedades de MSCHAPv2 de

EAP, compruebe Usar automáticamente mi nombre y contraseña de inicio de
sesión de Windows (y dominio si existe) y haga clic en Aceptar.

17. Para habilitar la reconexión rápida de PEAP, asegúrese de que la opción Habilitar
reconexión rápida está seleccionada.
18. Para requerir TLV de cifrado de servidor en intentos de conexión, seleccione
Desconectar si el servidor no presenta TLV de cifrado.

19. Para especificar que la identidad de usuario se enmascara en la fase uno de la

autenticación, seleccione Habilitar privacidad de identidad y, en el cuadro de
texto, escriba un nombre de identidad anónimo o deje el cuadro de texto en
blanco.

[! NOTAS]

La directiva NPS para 802.1X Wireless debe crearse mediante la directiva

de solicitud de conexión NPS. Si la directiva NPS se crea mediante la
directiva de red NPS, la privacidad de identidad no funcionará.
La privacidad de la identidad de EAP se proporciona mediante
determinados métodos de EAP en los que se envía una identidad vacía o
anónima (diferente de la identidad real) en respuesta a la solicitud de
identidad de EAP. PEAP envía la identidad dos veces durante la
autenticación. En la primera fase, la identidad se envía en texto sin
formato y esta identidad se usa con fines de enrutamiento, no para la
autenticación de cliente. La identidad real, que se usa para la
autenticación, se envía durante la segunda fase de la autenticación,
dentro del túnel seguro que se establece en la primera fase. Si la casilla
Habilitar privacidad de identidad está activada, el nombre de usuario se
reemplaza por la entrada especificada en el cuadro de texto. Por ejemplo,
supongamos que Habilitar privacidad de identidad está seleccionada y
que el alias de privacidad de identidad anónimo se especifica en el
cuadro de texto. Para un usuario con un alias jdoe@[Link]
identidad real, la identidad enviada en la primera fase de autenticación se
cambiará a anonymous@[Link]. La parte del dominio de la
identidad de la primera fase no se modifica, ya que se usa con fines de
enrutamiento.

20. Haga clic en Aceptar para cerrar el cuadro de diálogo Propiedades de EAP
protegidas .

21. Haga clic en Aceptar para cerrar la pestaña Seguridad .

22. Si desea crear perfiles adicionales, haga clic en Agregar y repita los pasos
anteriores, tomando diferentes opciones para personalizar cada perfil para los
clientes inalámbricos y la red a los que desea aplicar el perfil. Cuando haya
terminado de agregar perfiles, haga clic en Aceptar para cerrar el cuadro de
diálogo Propiedades de directiva de red inalámbrica.
En la sección siguiente puede ordenar los perfiles de directiva para lograr una seguridad
óptima.

Establecer el orden de preferencia para los perfiles de conexión

inalámbrica
Puede usar este procedimiento si ha creado varios perfiles inalámbricos en la directiva
de red inalámbrica y desea ordenar los perfiles para lograr una eficacia y seguridad
óptimas.

Para garantizar que los clientes inalámbricos se conecten con el nivel de seguridad más
alto que pueden admitir, coloque sus directivas más restrictivas en la parte superior de
la lista.

Por ejemplo, si tiene dos perfiles, uno para los clientes que admiten WPA2 y otro para
los clientes que admiten WPA, coloque el perfil WPA2 más alto en la lista. Esto garantiza
que los clientes que admiten WPA2 usarán ese método para la conexión en lugar del
WPA menos seguro.

Este procedimiento proporciona los pasos para especificar el orden en el que se usan
perfiles de conexión inalámbrica para conectar clientes inalámbricos miembros del
dominio a redes inalámbricas.

La pertenencia a Administradores de dominio, o equivalente, es lo mínimo necesario

para completar este procedimiento.

Para establecer el orden de preferencia de los perfiles de

conexión inalámbrica

1. En GPME, en el cuadro de diálogo propiedades de red inalámbrica para la directiva

que acaba de configurar, haga clic en la pestaña General .

2. En la pestaña General, en Conectar a las redes disponibles en el orden de los

perfiles que se enumeran a continuación, seleccione el perfil que desea mover en
la lista y, a continuación, haga clic en el botón "flecha arriba" o "flecha abajo" para
mover el perfil a la ubicación deseada en la lista.

3. Repita el paso 2 para cada perfil que quiera mover en la lista.

4. Haga clic en Aceptar para guardar todos los cambios.

En la sección siguiente, puede definir permisos de red para la directiva inalámbrica.

Definir permisos de red
Puede configurar las opciones en la pestaña Permisos de red para los miembros del
dominio a los que se aplican las directivas de red inalámbrica (IEEE 802.11).

Solo puede aplicar las siguientes opciones para redes inalámbricas que no están
configuradas en la pestaña General de la página Propiedades de la directiva de red
inalámbrica :

Permitir o denegar conexiones a redes inalámbricas específicas que especifique

por tipo de red e Identificador del conjunto de servicios (SSID)

Permitir o denegar conexiones a redes ad hoc

Permitir o denegar conexiones a redes de infraestructura

Permitir o denegar a los usuarios ver los tipos de red (ad hoc o infraestructura) a
los que se les deniega el acceso.

Permitir o denegar a los usuarios crear un perfil que se aplique a todos los usuarios

Los usuarios solo pueden conectarse a redes permitidas mediante perfiles de

directiva de grupo

La pertenencia a administradores de dominio, o equivalente, es el mínimo necesario

para completar estos procedimientos.

Para permitir o denegar conexiones a redes inalámbricas

específicas

1. En GPME, en el cuadro de diálogo propiedades de red inalámbrica, haga clic en la

pestaña Permisos de red.

2. En la pestaña Permisos de red , haga clic en Agregar. Se abre el cuadro de diálogo

Nueva entrada de permisos .

3. En el cuadro de diálogo Nueva entrada de permiso , en el campo Nombre de red

(SSID), escriba el SSID de red de la red para la que desea definir permisos.

4. En Tipo de red, seleccione Infraestructura o Ad hoc.

７ Nota

Si no está seguro de si la red de difusión es una infraestructura o una red ad

hoc, puede configurar dos entradas de permisos de red, una para cada tipo
 de red.

5. En Permiso, seleccione Permitir o Denegar.

6. Haga clic en Aceptar para volver a la pestaña Permisos de red .

Para especificar permisos de red adicionales (opcional)

1. En la pestaña Permisos de red , configure cualquiera o todos los siguientes:

Para denegar el acceso de los miembros del dominio a las redes ad hoc,
seleccione Impedir conexiones a redes ad hoc.

Para denegar el acceso de los miembros del dominio a las redes de

infraestructura, seleccione Impedir conexiones a redes de infraestructura.

Para permitir que los miembros del dominio vean los tipos de red (ad hoc o
la infraestructura) a los que se les deniega el acceso, seleccione Permitir al
usuario ver las redes denegadas.

Para permitir que los usuarios creen perfiles que se apliquen a todos los
usuarios, seleccione Permitir que todos creen todos los perfiles de usuario.

Para especificar que los usuarios solo pueden conectarse a redes permitidas
mediante perfiles de directiva de grupo, seleccione Usar solo perfiles
directiva de grupo para redes permitidas.

Configuración de npS
Siga estos pasos para configurar NPS para realizar la autenticación 802.1X para el
acceso inalámbrico:

Registro de NPS en Servicios de dominio de Active Directory

Configurar una AP inalámbrica como un cliente RADIUS NPS

Crear directivas NPS para 802.1X Wireless mediante un asistente

Registro de NPS en Servicios de dominio de Active

Directory
Puede usar este procedimiento para registrar un servidor que ejecuta el servidor de
directivas de red (NPS) en Servicios de dominio de Active Directory (AD DS) en el
dominio donde el NPS es miembro. Para que se conceda permiso a NPS para leer las
propiedades de acceso telefónico telefónico de las cuentas de usuario durante el
proceso de autorización, cada NPS debe registrarse en AD DS. Al registrar un NPS, se
agrega el servidor al grupo de seguridad servidores RAS e IAS en AD DS.

７ Nota

Puede instalar NPS en un controlador de dominio o en un servidor dedicado.

Ejecute el siguiente comando Windows PowerShell para instalar NPS si aún no lo ha
hecho:

PowerShell

Install-WindowsFeature NPAS -IncludeManagementTools

La pertenencia a Administradores de dominio, o equivalente, es lo mínimo necesario

para completar este procedimiento.

Para registrar un NPS en su dominio predeterminado

1. En el NPS, en Administrador del servidor, haga clic en Herramientasy, a
continuación, haga clic en Servidor de directivas de red. Se abre el complemento
NPS.

2. Haga clic con el botón derecho en NPS (local) y, a continuación, haga clic en
Registrar servidor en Active Directory. Se abrirá el cuadro de diálogo Servidor de
directivas de redes.

3. En Servidor de directivas de redes, haga clic en Aceptar y, a continuación, en

Aceptar de nuevo.

Configurar una AP inalámbrica como un cliente RADIUS

NPS
Puede usar este procedimiento para configurar una AP, también conocida como
servidor de acceso a la red (NAS), como un cliente de servicio de acceso telefónico local
(RADIUS) de autenticación remota mediante el complemento NPS.

） Importante
 Los equipos cliente, como los equipos portátiles inalámbricos y otros equipos que
ejecutan sistemas operativos cliente, no son clientes RADIUS. Los clientes RADIUS
son servidores de acceso a la red,como puntos de acceso inalámbrico,
conmutadores compatibles con 802.1X, servidores de red privada virtual (VPN) y
servidores de acceso telefónico, ya que usan el protocolo RADIUS para
comunicarse con servidores RADIUS como NPS.

La pertenencia a Administradores de dominio, o equivalente, es lo mínimo necesario

para completar este procedimiento.

Para agregar un servidor de acceso de red como cliente RADIUS en

NPS

1. En el NPS, en Administrador del servidor, haga clic en Herramientasy, a

continuación, haga clic en Servidor de directivas de red. Se abre el complemento
NPS.

2. En el complemento NPS, haga doble clic en Clientes y servidores RADIUS. Haga

clic con el botón derecho en Clientes RADIUS y, a continuación, haga clic en
Nuevo.

3. En Nuevo cliente RADIUS, compruebe que la casilla Habilitar este cliente RADIUS
está activada.

4. En Nuevo cliente RADIUS, en Nombre descriptivo, escriba un nombre para

mostrar para el punto de acceso inalámbrico.

Por ejemplo, si desea agregar un punto de acceso inalámbrico (AP) denominado

AP-01, escriba AP-01.

5. En Dirección (IP o DNS), escriba la dirección IP o el nombre de dominio completo

(FQDN) para el NAS.

Si escribe el FQDN, para comprobar que el nombre es correcto y se asigna a una

dirección IP válida, haga clic en Comprobar y, a continuación, en Comprobar
dirección, en el campo Dirección , haga clic en Resolver. Si el nombre de FQDN se
asigna a una dirección IP válida, la dirección IP de ese NAS aparecerá
automáticamente en la dirección IP. Si el FQDN no se resuelve en una dirección IP,
recibirá un mensaje que indica que no se conoce dicho host. Si esto ocurre,
compruebe que tiene el nombre de AP correcto y que el AP está encendido y
conectado a la red.

Haga clic en Aceptar para cerrar Comprobar dirección.

 6. En Nuevo cliente RADIUS, en Secreto compartido, realice una de las siguientes
acciones:

Para configurar manualmente un secreto compartido RADIUS, seleccione

Manual y, a continuación, en Secreto compartido, escriba la contraseña
segura que también se escribe en el NAS. Vuelva a escribir el secreto
compartido en Confirmar secreto compartido.

Para generar automáticamente un secreto compartido, active la casilla

Generar y, a continuación, haga clic en el botón Generar . Guarde el secreto
compartido generado y, a continuación, use ese valor para configurar el NAS
para que pueda comunicarse con el NPS.

） Importante

El secreto compartido RADIUS que escriba para el AP virtual en NPS

debe coincidir exactamente con el secreto compartido RADIUS
configurado en el AP inalámbrico real. Si usa la opción NPS para generar
un secreto compartido RADIUS, debe configurar el AP inalámbrico real
coincidente con el secreto compartido RADIUS generado por NPS.

7. En Nuevo cliente RADIUS, en la pestaña Avanzadas , en Nombre del proveedor,

especifique el nombre del fabricante del NAS. Si no está seguro del nombre del
fabricante del NAS, seleccione Estándar RADIUS.

8. En Opciones adicionales, si usa algún método de autenticación distinto de EAP y

PEAP, y si el NAS admite el uso del atributo de autenticador de mensajes,
seleccione Access Request messages (Mensajes de solicitud de acceso) que
contenga el atributo Message-Authenticator.

9. Haga clic en OK. El NAS aparece en la lista de clientes RADIUS configurados en

NPS.

Crear directivas NPS para 802.1X Wireless mediante un

asistente
Puede usar este procedimiento para crear las directivas de solicitud de conexión y las
directivas de red necesarias para implementar puntos de acceso inalámbrico
compatibles con 802.1X como clientes de servicio de usuario de acceso telefónico local
de autenticación remota (RADIUS) en el servidor RADIUS que ejecuta el servidor de
directivas de red (NPS). Una vez que ejecute el asistente, se crean las siguientes
directivas:

Una directiva de solicitud de conexión

Una directiva de red

７ Nota

Puede ejecutar el Asistente para conexiones inalámbricas y cableadas seguras IEEE

802.1X cada vez que necesite crear nuevas directivas para el acceso autenticado
802.1X.

La pertenencia a Administradores de dominio, o equivalente, es lo mínimo necesario

para completar este procedimiento.

Creación de directivas para 802.1X autenticado inalámbrico

mediante un asistente

1. Abra el complemento NPS. Si aún no está seleccionado, haga clic en NPS (local). Si
está ejecutando el complemento MMC NPS y desea crear directivas en un NPS
remoto, seleccione el servidor.

2. En Introducción, en Configuración estándar, seleccione Servidor RADIUS para

conexiones inalámbricas o cableadas 802.1X. El texto y los vínculos situados
debajo del texto cambiarán para reflejar su selección.

3. Haga clic en Configurar 802.1X. Se abre el Asistente para configurar 802.1X.

4. En la página Seleccionar el Asistente para tipos de conexiones 802.1X , en Tipo de

conexiones 802.1X, seleccione Conexiones inalámbricas seguras y, en Nombre,
escriba un nombre para la directiva o deje el nombre predeterminado Conexiones
inalámbricas seguras. Haga clic en Next.

5. En la página Especificar conmutadores 802.1X , en clientes RADIUS, se muestran

todos los conmutadores 802.1X y los puntos de acceso inalámbrico que ha
agregado como clientes RADIUS en el complemento NPS. Realice alguna de las
acciones siguientes:

Para agregar servidores de acceso de red adicionales (NAS), como los AP

inalámbricos, en clientes RADIUS, haga clic en Agregar y, a continuación, en
Nuevo cliente RADIUS, escriba la información de: Nombre descriptivo,
Dirección (IP o DNS) y Secreto compartido.
 Para modificar la configuración de cualquier NAS, en clientes RADIUS,
seleccione el AP para el que desea modificar la configuración y, a
continuación, haga clic en Editar. Modifique la configuración según sea
necesario.

Para quitar un NAS de la lista, en clientes RADIUS, seleccione el NAS y, a

continuación, haga clic en Quitar.

２ Advertencia

Al quitar un cliente RADIUS desde el Asistente para configurar 802.1X ,

se elimina el cliente de la configuración de NPS. Todas las adiciones,
modificaciones y eliminaciones que realice en el Asistente para
configurar 802.1X para clientes RADIUS se reflejan en el complemento
NPS, en el nodo Clientes RADIUS bajo Clientes y servidores
NPSRADIUS / . Por ejemplo, si usa el asistente para quitar un
modificador 802.1X, el modificador también se quita del complemento
NPS.

6. Haga clic en Next. En la página Configurar un método de autenticación , en Tipo

(basado en el método de acceso y configuración de red), seleccione Microsoft:
Protected EAP (PEAP) y, a continuación, haga clic en Configurar.

 Sugerencia

Si recibe un mensaje de error que indica que no se encuentra un certificado

para su uso con el método de autenticación y ha configurado Servicios de
certificados de Active Directory para emitir automáticamente certificados a
servidores RAS e IAS en la red, asegúrese primero de que ha seguido los
pasos para registrar NPS en Servicios de dominio de Active Directory, siga
estos pasos para actualizar. directiva de grupo: haga clic en Inicio, haga clic
en Windows Sistema, haga clic en Ejecutary, en Abrir, escriba gpupdatey, a
continuación, presione ENTRAR. Cuando el comando devuelve resultados que
indican que tanto el usuario como el equipo directiva de grupo se han
actualizado correctamente, seleccione Microsoft: Protected EAP (PEAP) de
nuevo y, a continuación, haga clic en Configurar.

Si después de actualizar directiva de grupo sigue recibiendo el mensaje de

error que indica que no se encuentra un certificado para su uso con el
método de autenticación, el certificado no se muestra porque no cumple los
requisitos mínimos de certificado de servidor como se documenta en la Guía
 complementaria de red principal: Implementar certificados de servidor para
implementaciones cableadas e inalámbricas 802.1X. Si esto sucede, debe
interrumpir la configuración de NPS, revocar el certificado emitido a los NPS
y, a continuación, seguir las instrucciones para configurar un nuevo certificado
mediante la guía de implementación de certificados de servidor.

7. En la página Del Asistente para editar propiedades de EAP protegidas , en

Certificado emitido, asegúrese de que está seleccionado el certificado NPS
correcto y, a continuación, haga lo siguiente:

７ Nota

Compruebe que el valor de Issuer es correcto para el certificado seleccionado

en Certificado emitido. Por ejemplo, el emisor esperado para un certificado
emitido por una CA que ejecuta Servicios de certificados de Active Directory
(AD CS) denominado corp\DC1, en el dominio [Link], es corp-DC1-CA.

Para permitir que los usuarios se muevan con sus equipos inalámbricos entre
puntos de acceso sin necesidad de volver a autenticarse cada vez que asocien
a una nueva AP, seleccione Habilitar reconexión rápida.

Para especificar que los clientes inalámbricos que se conecten finalizarán el

proceso de autenticación de red si el servidor RADIUS no presenta cifrado de
tipo-longitud-valor (TLV), seleccione Desconectar clientes sin cryptobinding.

Para modificar la configuración de directiva para el tipo EAP, en Tipos de

EAP, haga clic en Editar, en Propiedades de MSCHAPv2 de EAP, modifique la
configuración según sea necesario y, a continuación, haga clic en Aceptar.

8. Haga clic en OK. El cuadro de diálogo Editar propiedades de EAP protegidas se

cierra y le devuelve al Asistente para configurar 802.1X . Haga clic en Next.

9. En Especificar grupos de usuarios, haga clic en Agregar y escriba el nombre del

grupo de seguridad que configuró para los clientes inalámbricos en el
complemento Usuarios y equipos de Active Directory. Por ejemplo, si llamaste a tu
grupo de seguridad inalámbrico Wireless Group, escribe Wireless Group. Haga clic
en Next.

10. Haga clic en Configurar para configurar atributos estándar RADIUS y atributos
específicos del proveedor para la RED virtual (VLAN) según sea necesario y según
lo especificado por la documentación proporcionada por el proveedor de
hardware de AP inalámbrico. Haga clic en Next.
 11. Revise los detalles del resumen de configuración y, a continuación, haga clic en
Finalizar.

Ahora se crean las directivas NPS y puede pasar a unir equipos inalámbricos al dominio.

Unir nuevos equipos inalámbricos al dominio

El método más sencillo para unir nuevos equipos inalámbricos al dominio es conectar
físicamente el equipo a un segmento de la LAN cableada (un segmento no controlado
por un conmutador 802.1X) antes de unir el equipo al dominio. Esto es más fácil porque
la configuración de directivas de grupo inalámbricas se aplica automáticamente e
inmediatamente y, si ha implementado su propia PKI, el equipo recibe el certificado de
CA y lo coloca en el almacén de certificados de entidades de certificación raíz de
confianza, lo que permite que el cliente inalámbrico confíe en NPSs con certificados de
servidor emitidos por la ENTIDAD de certificación.

Del mismo modo, después de unir un nuevo equipo inalámbrico al dominio, el método
preferido para que los usuarios inicien sesión en el dominio es realizar el inicio de sesión
mediante una conexión cableada a la red.

Otros métodos de unión a un dominio

En los casos en los que no resulta práctico unir equipos al dominio mediante una
conexión Ethernet cableada, o en los casos en los que el usuario no pueda iniciar sesión
en el dominio por primera vez mediante una conexión cableada, debe usar un método
alternativo.

Configuración del equipo del personal de TI. Un miembro del personal de TI se

une a un equipo inalámbrico al dominio y configura un perfil inalámbrico de
arranque de inicio de sesión único. Con este método, el administrador de TI
conecta el equipo inalámbrico a la red Ethernet cableada y une el equipo al
dominio. A continuación, el administrador distribuye el equipo al usuario. Cuando
el usuario inicia el equipo sin usar una conexión cableada, las credenciales de
dominio que especifican manualmente para el inicio de sesión de usuario se usan
para establecer una conexión a la red inalámbrica e iniciar sesión en el dominio.

Para obtener más información, consulte la sección Unirse al dominio e iniciar sesión
mediante el método de configuración del equipo del personal de TI.

Configuración del perfil inalámbrico de arranque por parte de los usuarios. El

usuario configura manualmente el equipo inalámbrico con un perfil inalámbrico de
arranque y se une al dominio, en función de las instrucciones adquiridas por un
 administrador de TI. El perfil inalámbrico de arranque permite al usuario establecer
una conexión inalámbrica y, a continuación, unirse al dominio. Después de unir el
equipo al dominio y reiniciar el equipo, el usuario puede iniciar sesión en el
dominio mediante una conexión inalámbrica y sus credenciales de cuenta de
dominio.

Para obtener más información, vea la sección Unirse al dominio e iniciar sesión con la
configuración de perfil inalámbrico de arranque por parte de los usuarios.

Unirse al dominio e iniciar sesión mediante el método de

configuración del equipo del personal de TI
Los usuarios miembros del dominio con equipos cliente inalámbricos unidos a un
dominio pueden usar un perfil inalámbrico temporal para conectarse a una red
inalámbrica autenticada por 802.1X sin conectarse primero a la LAN cableada. Este perfil
inalámbrico temporal se denomina perfil inalámbrico de arranque.

Un perfil inalámbrico de arranque requiere que el usuario especifique manualmente sus

credenciales de cuenta de usuario de dominio y no valida el certificado del servidor de
servicio de acceso telefónico local de autenticación remota (RADIUS) que ejecuta el
servidor de directivas de red (NPS).

Una vez establecida la conectividad inalámbrica, directiva de grupo se aplica en el

equipo cliente inalámbrico y se emite automáticamente un nuevo perfil inalámbrico. La
nueva directiva usa las credenciales de equipo y cuenta de usuario para la autenticación
de cliente.

Además, como parte de la autenticación mutua PEAP-MS-CHAP v2 mediante el nuevo

perfil en lugar del perfil de arranque, el cliente valida las credenciales del servidor
RADIUS.

Después de unir el equipo al dominio, use este procedimiento para configurar un perfil
inalámbrico de arranque de inicio de sesión único, antes de distribuir el equipo
inalámbrico al usuario miembro del dominio.

Para configurar un perfil inalámbrico de arranque de inicio de

sesión único

1. Cree un perfil de arranque mediante el procedimiento de esta guía denominado

Configurar un perfil de conexión inalámbrica para PEAP-MS-CHAP v2 y use las
siguientes opciones:
 Autenticación PEAP-MS-CHAP v2

Validar el certificado de servidor RADIUS deshabilitado

Inicio de sesión único habilitado

2. En las propiedades de la directiva de red inalámbrica en la que creó el nuevo perfil

de arranque, en la pestaña General , seleccione el perfil de arranque y, a
continuación, haga clic en Exportar para exportar el perfil a un recurso compartido
de red, una unidad flash USB u otra ubicación fácilmente accesible. El perfil se
guarda como un archivo *.xml en la ubicación que especifique.

3. Una el nuevo equipo inalámbrico al dominio (por ejemplo, a través de una

conexión Ethernet que no requiera autenticación IEEE 802.1X) y agregue el perfil
inalámbrico de arranque al equipo mediante el comando netsh wlan add profile .

７ Nota

Para obtener más información, vea Comandos netsh para la red de área local
inalámbrica (WLAN) en [Link]

4. Distribuya el nuevo equipo inalámbrico al usuario con el procedimiento "Iniciar

sesión en el dominio mediante equipos que ejecutan Windows 10".

Cuando el usuario inicia el equipo, Windows pide al usuario que escriba su nombre de
cuenta de usuario de dominio y contraseña. Dado que el inicio de sesión único está
habilitado, el equipo usa las credenciales de la cuenta de usuario de dominio para
establecer primero una conexión con la red inalámbrica y, a continuación, iniciar sesión
en el dominio.

Inicie sesión en el dominio mediante equipos que ejecutan

Windows 10
1. Cierre la sesión del equipo o reinicie el equipo.

2. Presione cualquier tecla en el teclado o haga clic en el escritorio. La pantalla de

inicio de sesión aparece con un nombre de cuenta de usuario local que se muestra
y un campo de entrada de contraseña debajo del nombre. No inicie sesión con la
cuenta de usuario local.

3. En la esquina inferior izquierda de la pantalla, haga clic en Otro usuario. Aparece la

pantalla De inicio de sesión del otro usuario con dos campos, uno para el nombre
de usuario y otro para la contraseña. Debajo del campo de contraseña se muestra
 el texto Sign on (Iniciar sesión en): y, a continuación, el nombre del dominio en el
que está unido el equipo. Por ejemplo, si el dominio se denomina [Link], el
texto lee Iniciar sesión en: EJEMPLO.

4. En Nombre de usuario, escriba el nombre de usuario de dominio.

5. En Contraseña, escriba la contraseña del dominio y, a continuación, haga clic en la

flecha o presione Entrar.

７ Nota

Si la pantalla Otro usuario no incluye el texto Iniciar sesión en: y el nombre de

dominio, debe escribir el nombre de usuario en el formato dominio\usuario. Por
ejemplo, para iniciar sesión en el dominio de [Link] con una cuenta llamada
Usuario-01, escriba ejemplo\Usuario-01.

Unirse al dominio e iniciar sesión mediante la

configuración del perfil inalámbrico de arranque por
parte de los usuarios
Con este método, completará los pasos de la sección Pasos generales y, a continuación,
proporcionará a los usuarios miembros del dominio las instrucciones sobre cómo
configurar manualmente un equipo inalámbrico con un perfil inalámbrico de arranque.
El perfil inalámbrico de arranque permite al usuario establecer una conexión inalámbrica
y, a continuación, unirse al dominio. Una vez unido el equipo al dominio y reiniciado, el
usuario puede iniciar sesión en el dominio a través de una conexión inalámbrica.

Pasos generales
1. Configure una cuenta de administrador de equipo local, en Panel de control, para
el usuario.

） Importante

Para unir un equipo a un dominio, el usuario debe iniciar sesión en el equipo

con la cuenta de administrador local. Como alternativa, el usuario debe
proporcionar las credenciales de la cuenta de administrador local durante el
proceso de unión del equipo al dominio. Además, el usuario debe tener una
cuenta de usuario en el dominio al que el usuario quiere unirse al equipo.
 Durante el proceso de unir el equipo al dominio, se le pedirá al usuario las
credenciales de la cuenta de dominio (nombre de usuario y contraseña).

2. Proporcione a los usuarios del dominio las instrucciones para configurar un perfil
inalámbrico de arranque, como se documenta en el siguiente procedimiento Para
configurar un perfil inalámbrico de arranque.

3. Además, proporcione a los usuarios las credenciales del equipo local (nombre de
usuario y contraseña) y credenciales de dominio (nombre de cuenta de usuario de
dominio y contraseña) en el formulario DomainName\UserName, así como los
procedimientos para "Unir el equipo al dominio" y "Iniciar sesión en el dominio",
como se documenta en la Guía de red principal de Windows Server 2016.

Para configurar un perfil inalámbrico de arranque

1. Use las credenciales proporcionadas por el administrador de red o el profesional
de soporte técnico de TI para iniciar sesión en el equipo con la cuenta de
administrador del equipo local.

2. Haga clic con el botón derecho en el icono de red en el escritorio y haga clic en
Abrir centro de red y uso compartido. Se abre Centro de redes y recursos
compartidos. En Cambiar la configuración de red, haga clic en Configurar una
nueva conexión o red. Se abre el cuadro de diálogo Configurar una conexión o
red .

3. Haga clic en Conectar manualmente a una red inalámbrica y, a continuación,

haga clic en Siguiente.

4. En Conexión manual a una red inalámbrica, en Nombre de red, escriba el nombre

de SSID del AP.

5. En Tipo de seguridad, seleccione la configuración proporcionada por el

administrador.

6. En Tipo de cifrado y Clave de seguridad, seleccione o escriba la configuración

proporcionada por el administrador.

7. Seleccione Iniciar esta conexión automáticamente y, a continuación, haga clic en

Siguiente.

8. En Agregado correctamenteSuSSID de red, haga clic en Cambiar configuración de

conexión.
 9. Haga clic en Cambiar configuración de conexión. Se abre el cuadro de diálogo
Propiedad Red inalámbrica SSID de red.

10. Haga clic en la pestaña Seguridad y, a continuación, en Elegir un método de

autenticación de red, seleccione EAP protegido (PEAP).

11. Haga clic en Configuración. Se abre la página Propiedades de EAP protegida

(PEAP ).

12. En la página Propiedades de EAP protegido (PEAP), asegúrese de que Validar

certificado de servidor no está seleccionado, haga clic en Aceptar dos veces y, a
continuación, haga clic en Cerrar.

13. Windows luego intenta conectarse a la red inalámbrica. La configuración del perfil
inalámbrico de arranque especifica que debe proporcionar sus credenciales de
dominio. Cuando Windows le pida un nombre de cuenta y una contraseña, escriba
las credenciales de la cuenta de dominio de la siguiente manera: Nombre de
dominio\Nombre de usuario, Contraseña de dominio.

Para unir un equipo al dominio

1. Inicie sesión en el equipo con la cuenta de administrador local.

2. En el cuadro de texto de búsqueda, escriba PowerShell. En los resultados de la

búsqueda, haga clic con el botón derecho en Windows PowerShell y, a
continuación, haga clic en Ejecutar como administrador. Windows PowerShell se
abre con un símbolo del sistema con privilegios elevados.

3. En Windows PowerShell, escriba el siguiente comando y presione ENTRAR.

Asegúrese de reemplazar la variable DomainName por el nombre del dominio al
que desea unirse.

Add-Computer DomainName

4. Cuando se le solicite, escriba el nombre de usuario y la contraseña de dominio y

haga clic en Aceptar.

5. Reinicie el equipo.

6. Siga las instrucciones de la sección anterior Iniciar sesión en el dominio mediante

equipos que ejecutan Windows 10.
Implementar el modo de caché
hospedada de BranchCache
Artículo • 21/12/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2 y Windows Server 2012.

En Windows Server 2016 Core Network Guide (Guía de red principal de Windows Server
2016 core) se proporcionan instrucciones para planear e implementar los componentes
principales necesarios para una red totalmente funcional y un nuevo dominio Active
Directory® en un bosque nuevo.

En esta guía se explica cómo compilar en la red principal proporcionando instrucciones

para implementar BranchCache en modo caché hospedada en una o varias sucursales
con un controlador de dominio de Read-Only donde los equipos cliente ejecutan
Windows ® 10, Windows 8.1 o Windows 8, y se unen al dominio.

） Importante

No use esta guía si planea implementar o si ya ha implementado un servidor de

caché hospedada de BranchCache que ejecuta Windows Server 2008 R2. En esta
guía se proporcionan instrucciones para implementar el modo de caché hospedada
con un servidor de caché hospedada que ejecuta Windows Server® 2016, Windows
Server 2012 R2 o Windows Server 2012.

En esta guía se incluyen las siguientes secciones.

Requisitos previos para usar esta guía

Acerca de esta guía

Qué no incluye esta guía

Introducción a las tecnologías

Información general sobre la implementación del modo de caché hospedada de

BranchCache

Planeamiento de la implementación del modo de caché hospedada de

BranchCache
 Implementación del modo de caché hospedada de BranchCache

Recursos adicionales

Requisitos previos para usar esta guía

Esta es una guía complementaria de la guía de Windows Server 2016 Core Network.
Para implementar BranchCache en modo de caché hospedada con esta guía, primero
tienes que hacer lo siguiente.

Implementa una red principal en tu oficina central usando la Guía de red principal,
o ten instaladas y funcionando correctamente en tu red las tecnologías
proporcionadas en la Guía de red principal de antemano. Estas tecnologías
incluyen TCP/IP v4, DHCP, Active Directory Domain Services (AD DS) y DNS.

７ Nota

La Windows Server 2016 core network está disponible en la biblioteca

Windows Server 2016 Technical Library.

Implemente servidores de contenido de BranchCache que ejecuten Windows

Server 2016, Windows Server 2012 R2 o Windows Server 2012 en la oficina
principal o en un centro de datos en la nube. Para obtener información sobre
cómo implementar servidores de contenido de BranchCache, consulte Recursos
adicionales.

Establece conexiones de área extensa de red (WAN) entre tu sucursal, tu oficina

central y, si procede, tus recursos en la nube, con una red privada virtual (VPN),
DirectAccess o con otro método de conexión.

Implemente equipos cliente en la sucursal que ejecuten uno de los siguientes

sistemas operativos, que proporcionan a BranchCache compatibilidad con Servicio
de transferencia inteligente en segundo plano (BITS), protocolo de transferencia de
hyper-text (HTTP) y bloque de mensajes de servidor (SMB).
Windows 10 Enterprise
Windows 10 Education
Windows 8.1 Enterprise
Windows 8 Enterprise

７ Nota
 En los siguientes sistemas operativos, BranchCache no admite la funcionalidad
HTTP y SMB, pero admite la funcionalidad BITS de BranchCache. - Windows 10 Pro,
solo compatibilidad con BITS Windows 8.1 Pro, solo compatibilidad con BITS
Windows 8 Pro, solo compatibilidad con BITS

Acerca de esta guía

Esta guía está diseñada para los administradores de redes y sistemas que han seguido
las instrucciones de la Guía de red de Windows Server 2016 Core o la Guía de red
principal de Windows Server 2012 para implementar una red principal, o para aquellos
que han implementado previamente las tecnologías incluidas en la Guía de red
principal, incluidos Active Directory Domain Services (AD DS), Domain Name Service
(DNS). Protocolo de configuración dinámica de host (DHCP) y TCP/IP v4.

Se recomienda que revise las guías de diseño e implementación de cada una de las
tecnologías que se usan en este escenario de implementación. Estas guías pueden
ayudarle a determinar si este escenario de implementación ofrece los servicios y la
configuración que necesita para la red de su organización.

Qué no incluye esta guía

Esta guía no proporciona información conceptual sobre BranchCache, incluyendo la
información sobre los modos y capacidades de BranchCache.

Esta guía no proporciona información sobre cómo implementar conexiones WAN u

otras tecnologías de tu sucursal, como DHCP, un RODC o un servidor VPN.

Además, esta guía no proporciona orientación sobre el hardware que debes usar
cuando implementas un servidor de caché hospedada. Es posible ejecutar otros
servicios y aplicaciones en tu servidor de caché hospedada, sin embargo tienes que
tomar la determinación, según la carga de trabajo, las capacidades de hardware y el
tamaño de la sucursal, de si quieres instalar el servidor de caché hospedada de
BranchCache en un equipo determinado y cuánto espacio en disco asignar a la caché.
En esta guía no se proporcionan instrucciones para configurar equipos que ejecutan
Windows 7. Si tiene equipos cliente que ejecutan Windows 7 en las sucursales, debe
configurarlos mediante procedimientos diferentes de los proporcionados en esta guía
para los equipos cliente que ejecutan Windows 10, Windows 8.1 y Windows 8.

Además, si tiene equipos que ejecutan Windows 7, debe configurar el servidor de caché
hospedada con un certificado de servidor emitido por una entidad de certificación en la
que confíen los equipos cliente. (Si todos los equipos cliente ejecutan Windows 10,
Windows 8.1 o Windows 8, no es necesario configurar el servidor de caché hospedada
con un certificado de servidor).

） Importante

Si los servidores de caché hospedada ejecutan Windows Server 2008 R2, use la
Guía de implementación de BranchCache de Windows Server 2008 R2 en lugar de
esta guía para implementar BranchCache en modo de caché hospedada. Aplique la
directiva de grupo que se describe en esa guía a todos los clientes de BranchCache
que ejecutan versiones de Windows de Windows 7 a Windows 10. Los equipos que
ejecutan Windows Server 2008 R2 no se pueden configurar mediante los pasos de
esta guía.

Introducción a las tecnologías

En esta guía complementaria, BranchCache es la única tecnología que necesitas para la
instalación y configuración. Tienes que ejecutar los comandos de Windows PowerShell
BranchCache en los servidores de contenido, como los servidores web y de archivos, sin
embargo, no necesitas cambiar o volver a configurar los servidores de contenido de
ninguna otra forma. Además, debe configurar equipos cliente mediante directiva de
grupo en los controladores de dominio que ejecutan AD DS en Windows Server 2016,
Windows Server 2012 R2 o Windows Server 2012.

BranchCache
BranchCache es una tecnología de optimización de ancho de banda de red de área
extensa (WAN) que se incluye en algunas ediciones de los sistemas operativos Windows
Server 2016 y Windows 10, así como en algunas ediciones de Windows Server 2012 R2,
Windows 8.1, Windows Server 2012, Windows 8, Windows Server 2008 R2 y Windows 7.

Para optimizar el ancho de banda wan cuando los usuarios acceden al contenido en
servidores remotos, BranchCache descarga el contenido solicitado por el cliente desde
la oficina principal o los servidores de contenido hospedados en la nube y almacena en
caché el contenido en ubicaciones de sucursales, lo que permite que otros equipos
cliente de las sucursales accedan al mismo contenido localmente en lugar de a través de
la WAN.

Cuando implementas BranchCache en modo de caché hospedada, tienes que configurar

los equipos cliente de la sucursal como clientes del modo de caché hospedada y
después tienes que implementar un servidor de caché hospedada en la sucursal. Esta
guía muestra cómo implementar tu servidor de caché hospedada con contenido con
hash y cargado previamente de tu sitio web así como servidores de contenido basados
en el servidor de archivos.

Directiva de grupo
directiva de grupo en Windows Server 2016, Windows Server 2012 R2 y Windows Server
2012 es una infraestructura que se usa para entregar y aplicar una o varias
configuraciones deseadas o configuraciones de directiva a un conjunto de usuarios y
equipos de destino dentro de un entorno Active Directory.

Esta infraestructura consta de un motor directiva de grupo y varias extensiones del lado
cliente (CSE) que son responsables de leer la configuración de directiva en los equipos
cliente de destino.

En este escenario se usa la directiva de grupo para configurar equipos cliente miembros
del dominio con el modo de caché hospedada de BranchCache.

Para continuar con esta guía, consulte Información general sobre la implementación del
modo de caché hospedada de BranchCache.
Información general de implementación
de modo de caché hospedada de
BranchCache
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2 y Windows Server 2012.

Puede usar esta guía para implementar un servidor de caché hospedado de

BranchCache en una sucursal donde los equipos están unidos a un dominio. Puede usar
este tema para obtener información general sobre el proceso de implementación del
modo de caché hospedada de BranchCache.

Esta introducción incluye la infraestructura de BranchCache que necesita, así como una
visión general paso a paso sencilla de la implementación.

Infraestructura de implementación del servidor

de caché hospedada
En esta implementación, el servidor de caché hospedado se implementa mediante
puntos de conexión de servicio en Servicios de dominio de Active Directory (AD DS) y
tiene la opción con BranchCache en Windows Server 2016, Windows Server 2012 R2 y
Windows Server 2012, para guardar previamente el contenido compartido en servidores
de contenido web y basados en archivos y, a continuación, cargar previamente el
contenido en los servidores de caché hospedados.

En la ilustración siguiente se muestra la infraestructura necesaria para implementar un

servidor de caché hospedado de BranchCache.
 ） Importante

Aunque esta implementación representa los servidores de contenido en un centro

de datos en la nube, puede usar esta guía para implementar un servidor de caché
hospedado de BranchCache, independientemente de dónde implemente los
servidores de contenido, en la oficina principal o en una ubicación en la nube.

HCS1 en la sucursal
Debe configurar este equipo como un servidor de caché hospedado. Si decide prehash
los datos del servidor de contenido para poder cargar previamente el contenido en los
servidores de caché hospedados, puede importar paquetes de datos que contengan el
contenido de los servidores web y de archivos.

WEB1 en el centro de datos en la nube

WEB1 es un servidor de contenido habilitado para BranchCache. Si decide guardar
previamente los datos del servidor de contenido para poder cargar previamente el
contenido en los servidores de caché hospedados, puede prehash el contenido
compartido en WEB1 y, a continuación, crear un paquete de datos que copie en HCS1.

FILE1 en el centro de datos en la nube

FILE1 es un servidor de contenido habilitado para BranchCache. Si decide prehash los
datos del servidor de contenido para poder cargar previamente el contenido en los
servidores de caché hospedados, puede prehash el contenido compartido en FILE1 y, a
continuación, crear un paquete de datos que copie en HCS1.

DC1 en la oficina principal

DC1 es un controlador de dominio y debe configurar la directiva de dominio
predeterminada u otra directiva más adecuada para la implementación, con la
configuración de branchCache directiva de grupo para habilitar la detección automática
de caché hospedada por punto de conexión de servicio.

Cuando los equipos cliente de la rama se han actualizado directiva de grupo y se aplica
esta configuración de directiva, localizan y comienzan a usar automáticamente el
servidor de caché hospedado en la sucursal.

Equipos cliente en la sucursal

Debe actualizar directiva de grupo en los equipos cliente para aplicar la nueva
configuración de directiva de grupo de BranchCache y permitir que los clientes busquen
y usen el servidor de caché hospedado.

Introducción al proceso de implementación del

servidor de caché hospedada

７ Nota

Los detalles de cómo realizar estos pasos se proporcionan en la sección

Implementación del modo de caché hospedada de BranchCache.

El proceso de implementación de un servidor de caché hospedada de BranchCache se

produce en estas fases:

７ Nota

Algunos de los pasos siguientes son opcionales, como los pasos que muestran
cómo prehash y cargar previamente el contenido en los servidores de caché
hospedados. Al implementar BranchCache en modo de caché hospedada, no es
necesario prehash de contenido en los servidores de contenido web y de archivos,
crear un paquete de datos e importar el paquete de datos para cargar previamente
los servidores de caché hospedados con contenido. Los pasos se indican como
opcionales en esta sección y en la sección Implementación del modo de caché
hospedada de BranchCache para que pueda omitirlos si lo prefiere.

1. En HCS1, use Windows PowerShell comandos para configurar el equipo como un

servidor de caché hospedado y para registrar un punto de conexión de servicio en
Active Directory.

2. (Opcional) En HCS1, si los valores predeterminados de BranchCache no coinciden

con los objetivos de implementación del servidor y la memoria caché hospedada,
configure la cantidad de espacio en disco que desea asignar para la caché
hospedada. Configure también la ubicación de disco que prefiera para la caché
hospedada.

3. (Opcional) Prehash content on content servers, create data packages, and preload
content on the hosted cache server.

７ Nota

El almacenamiento previo y la carga previa del contenido en el servidor de

caché hospedada es opcional; sin embargo, si decide prehash y precarga,
debe realizar todos los pasos siguientes que son aplicables a la
implementación. (Por ejemplo, si no tiene servidores web, no es necesario
realizar ninguno de los pasos relacionados con el almacenamiento provisional
y la carga previa del contenido del servidor web).

a. En WEB1, cree un paquete de datos para prehash web server content (Guardar
previamente el contenido del servidor web y crear un paquete de datos).

b. En FILE1, guarde previamente el contenido del servidor de archivos y cree un

paquete de datos.

c. Desde WEB1 y FILE1, copie los paquetes de datos en el servidor de caché

hospedado HCS1.

d. En HCS1, importe los paquetes de datos para cargar previamente la caché de

datos.

4. En DC1, configure equipos cliente de sucursal unidos a un dominio para el modo

de caché hospedada mediante la configuración de directiva de grupo con la
configuración de directiva de BranchCache.

5. En los equipos cliente, actualice directiva de grupo.

Para continuar con esta guía, consulte Planificación de la implementación del modo de
caché hospedada de BranchCache.
Información general de implementación
de modo de caché hospedada de
BranchCache
Artículo • 21/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2 y Windows Server 2012.

Puede usar este tema para planear la implementación de BranchCache en modo caché
hospedada.

） Importante

El servidor de caché hospedada debe ejecutar Windows Server 2016, Windows

Server 2012 R2 o Windows Server 2012.

Antes de implementar el servidor de caché hospedada, debe planear los siguientes

elementos:

Planeación de la configuración básica del servidor

Planeación del acceso a un dominio

Planear la ubicación y el tamaño de la caché hospedada

Planear el recurso compartido en el que se van a copiar los paquetes del servidor
de contenido

Planeamiento del almacenamiento previo y la creación de paquetes de datos en

servidores de contenido

Planeación de la configuración básica del

servidor
Si planea usar un servidor existente en la sucursal como servidor de caché hospedada,
no es necesario realizar este paso de planeamiento, ya que el equipo ya tiene un
nombre y tiene una configuración de dirección IP.
Después de instalar Windows Server 2016 en el servidor de caché hospedada, debe
cambiar el nombre del equipo y asignar y configurar una dirección IP estática para el
equipo local.

７ Nota

En esta guía, el servidor de caché hospedada se denomina HCS1, pero debe usar
un nombre de servidor adecuado para la implementación.

Planeación del acceso a un dominio

Si planea usar un servidor existente en la sucursal como servidor de caché hospedada,
no es necesario realizar este paso de planeamiento, a menos que el equipo no esté
unido actualmente al dominio.

Para iniciar sesión en el dominio, el equipo debe ser miembro del dominio y la cuenta
de usuario se debe crear en AD DS antes del intento de inicio de sesión. Además, debe
unir el equipo al dominio con una cuenta que tenga la pertenencia a grupo adecuada.

Planear la ubicación y el tamaño de la caché

hospedada
En HCS1, determine dónde se encuentra la caché hospedada en el servidor de caché
hospedada. Por ejemplo, decida la ubicación del disco duro, el volumen y la carpeta
donde planea almacenar la memoria caché.

Además, decida qué porcentaje de espacio en disco desea asignar para la caché
hospedada.

Planear el recurso compartido en el que se van

a copiar los paquetes del servidor de contenido
Después de crear paquetes de datos en los servidores de contenido, debe copiarlos a
través de la red en un recurso compartido en el servidor de caché hospedada.

Planee la ubicación de la carpeta y los permisos de uso compartido para la carpeta

compartida. Además, si los servidores de contenido hospedan una gran cantidad de
datos y los paquetes que cree serán archivos grandes, planee realizar la operación de
copia durante las horas de menor a mayor actividad para que la operación de copia no
consuma el ancho de banda WAN durante un tiempo en el que otros necesiten usar el
ancho de banda para las operaciones empresariales normales.

Planeamiento del almacenamiento previo y la

creación de paquetes de datos en servidores de
contenido
Antes de crear previamente contenido en los servidores de contenido, debe identificar
las carpetas y los archivos que contienen contenido que desea agregar al paquete de
datos.

Además, debe planear la ubicación de la carpeta local donde puede almacenar los
paquetes de datos antes de copiarlos en el servidor de caché hospedada.

Para continuar con esta guía, consulte Implementación del modo de caché hospedada
en BranchCache.
Implementación de modo de caché
hospedada de BranchCache
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2 y Windows Server 2012.

Puede usar este tema para obtener vínculos a temas de procedimientos detallados que
le guiarán por el proceso de implementación del modo de caché hospedada de
BranchCache.

Siga estos pasos para implementar el modo de caché hospedada de BranchCache.

Instalar la característica BranchCache y configurar el servidor de caché hospedada

por punto de conexión de servicio

Mover y cambiar el tamaño de la caché hospedada (opcional)

Prehash and Preload Content on the Hosted Cache Server (Opcional)

Configurar la detección automática de caché hospedada de cliente por punto de

conexión de servicio

７ Nota

Los procedimientos de esta guía no incluyen instrucciones para los casos en que se
abre el cuadro de diálogo Control de cuentas de usuario para solicitar permiso
para continuar. Si aparece este cuadro de diálogo en respuesta a sus acciones
mientras realiza los procedimientos de esta guía, haga clic en Continuar.

Para continuar con esta guía, consulte Instalación de la característica BranchCache y

Configuración del servidor de caché hospedada por punto de conexión de servicio.
Instalar la característica BranchCache y
configurar el servidor de caché
hospedada mediante el punto de
conexión de servicio
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2 y Windows Server 2012.

Puede usar este procedimiento para instalar la característica BranchCache en el servidor

de caché hospedada, HCS1, y para configurar el servidor para registrar un punto de
conexión de servicio (SCP) en Active Directory Domain Services (AD DS).

Al registrar servidores de caché hospedada con un SCP en AD DS, el SCP permite a los
equipos cliente configurados correctamente detectar automáticamente los servidores de
caché hospedada consultando AD DS el SCP. Más adelante en esta guía se
proporcionan instrucciones sobre cómo configurar equipos cliente para realizar esta
acción.

） Importante

Antes de realizar este procedimiento, debe unir el equipo al dominio y configurar el

equipo con una dirección IP estática.

Para llevar a cabo este procedimiento, debe ser miembro del grupo Administradores.

Para instalar la característica BranchCache y

configurar el servidor de caché hospedada
1. En el equipo servidor, ejecute Windows PowerShell administrador. Escriba el
siguiente comando y presione ENTRAR.

Install-WindowsFeature BranchCache
 2. Para configurar el equipo como servidor de caché hospedada después de instalar
la característica BranchCache y registrar un punto de conexión de servicio en AD
DS, escriba el siguiente comando en Windows PowerShell y presione ENTRAR.

Enable-BCHostedServer -RegisterSCP

3. Para comprobar la configuración del servidor de caché hospedada, escriba el

siguiente comando y presione ENTRAR.

Get-BCStatus

Los resultados del comando muestran el estado de todos los aspectos de la

instalación de BranchCache. A continuación se incluyen algunos de los valores de
BranchCache y el valor correcto para cada elemento:

BranchCacheIsEnabled: True

HostedCacheServerIsEnabled: True

HostedCacheScpRegistrationEnabled: True

4. Para prepararse para el paso de copiar los paquetes de datos de los servidores de
contenido a los servidores de caché hospedada, identifique un recurso compartido
existente en el servidor de caché hospedada o cree una carpeta y comparta la
carpeta para que sea accesible desde los servidores de contenido. Después de
crear los paquetes de datos en los servidores de contenido, copiará los paquetes
de datos en esta carpeta compartida en el servidor de caché hospedada.

5. Si va a implementar más de un servidor de caché hospedada, repita este

procedimiento en cada servidor.

Para continuar con esta guía, consulte Mover y cambiar el tamaño de la caché
hospedada (opcional).
Mover y cambiar el tamaño de la caché
hospedada (opcional)
Artículo • 21/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2 y Windows Server 2012.

Puede usar este procedimiento para mover la memoria caché hospedada a la unidad y
carpeta que prefiera, y para especificar la cantidad de espacio en disco que el servidor
de caché hospedada puede usar para la caché hospedada.

Este procedimiento es opcional. Si la ubicación de caché predeterminada

(%windir%\ServiceProfiles\NetworkService\AppData\Local\PeerDistPub) y el tamaño
(que es el 5 % del espacio total en disco duro) son adecuados para la implementación,
no es necesario cambiarlos.

Para realizar este procedimiento debe ser miembro del grupo de administradores.

Para mover y cambiar el tamaño de la caché hospedada

1. Abra Windows PowerShell con privilegios de administrador.

2. Escriba el siguiente comando para mover la caché hospedada a otra ubicación en

el equipo local y, a continuación, presione ENTRAR.

） Importante

Antes de ejecutar el comando siguiente, reemplace los valores de parámetro,

como –Path y –MoveTo, por los valores adecuados para la implementación.

Set-BCCache -Path C:\datacache –MoveTo D:\datacache

3. Escriba el siguiente comando para cambiar el tamaño de la caché hospedada

(específicamente la caché de datos) en el equipo local. Presione ENTRAR.

） Importante
 Antes de ejecutar el comando siguiente, reemplace los valores de parámetro,
como -Percentage, por los valores adecuados para la implementación.

Set-BCCache -Percentage 20

4. Para comprobar la configuración del servidor de caché hospedada, escriba el

siguiente comando y presione ENTRAR.

Get-BCStatus

Los resultados del comando muestran el estado de todos los aspectos de la

instalación de BranchCache. A continuación se incluyen algunos de los valores de
BranchCache y el valor correcto para cada elemento:

DataCache | CacheFileDirectoryPath: muestra la ubicación del disco duro que

coincide con el valor proporcionado con el parámetro –MoveTo del comando
SetBCCache. Por ejemplo, si proporcionó el valor D:\datacache, ese valor se
muestra en la salida del comando.

DataCache | MaxCacheSizeAsPercentageOfDiskVolume: muestra el número

que coincide con el valor proporcionado con el parámetro –Percentage del
comando SetBCCache. Por ejemplo, si proporcionó el valor 20, ese valor se
muestra en la salida del comando.

Para continuar con esta guía, consulte Prehash and Preload Content on the Hosted
Cache Server (Optional) (Prehash and Preload Content on the Hosted Cache Server
[Opcional]).
Aplicar previamente hash y precargar
contenido en el servidor de caché
hospedada (opcional)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2 y Windows Server 2012.

Puede usar los procedimientos de esta sección para crear previamente contenido en los
servidores de contenido, agregar el contenido a los paquetes de datos y, a continuación,
cargar previamente el contenido en los servidores de caché hospedada.

Estos procedimientos son opcionales porque no es necesario prehash ni precargar

contenido en los servidores de caché hospedada.

Si no carga previamente contenido, los datos se agregan a la caché hospedada

automáticamente a medida que los clientes lo descargan a través de la conexión WAN.

） Importante

Aunque estos procedimientos son colectivamente opcionales, si decide prehagar y

cargar previamente contenido en los servidores de caché hospedada, es necesario
realizar ambos procedimientos.

Crear paquetes de datos del servidor de contenido para contenido web y de

archivo (opcional)

Importar paquetes de datos en el servidor de caché hospedada (opcional)

Para continuar con esta guía, consulte Crear paquetes de datos del servidor de
contenido para contenido web y de archivos (opcional).
Crear contenido de paquetes de datos
de servidor para contenido web y de
archivos (opcional)
Artículo • 21/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2 y Windows Server 2012.

Puede usar este procedimiento para almacenar previamente contenido en servidores

web y de archivos y, a continuación, crear paquetes de datos para importarlos en el
servidor de caché hospedada.

Este procedimiento es opcional porque no es necesario prehash ni precargar contenido

en los servidores de caché hospedada. Si no carga previamente contenido, los datos se
agregan a la caché hospedada automáticamente a medida que los clientes lo descargan
a través de la conexión WAN.

En este procedimiento se proporcionan instrucciones para el prehaso de contenido en

servidores de archivos y servidores web. Si no tiene uno de esos tipos de servidores de
contenido, no tiene que realizar las instrucciones para ese tipo de servidor de contenido.

） Importante

Antes de realizar este procedimiento, debe instalar y configurar BranchCache en los

servidores de contenido. Además, si tiene previsto cambiar el secreto de servidor
en un servidor de contenido, debe hacerlo antes de realizar un hash previo al
contenido, ya que la modificación del secreto de servidor invalida los hashes
generados previamente.

Para llevar a cabo este procedimiento, debe ser miembro del grupo Administradores.

Para crear paquetes de datos del servidor de

contenido
1. En cada servidor de contenido, busque las carpetas y los archivos que desea crear
previamente y agregar a un paquete de datos. Identifique o cree una carpeta
donde quiera guardar el paquete de datos más adelante en este procedimiento.
 2. En el equipo servidor, abra Windows PowerShell con privilegios de administrador.

3. Realice una o ambas de las siguientes acciones, en función de los tipos de

servidores de contenido que tenga:

７ Nota

El valor del parámetro –Path es la carpeta donde se encuentra el contenido.

Debe reemplazar los valores de ejemplo de los comandos siguientes por una
ubicación de carpeta válida en el servidor de contenido que contenga los
datos que desea crear previamente y agregar a un paquete.

Si el contenido que desea prehaso está en un servidor de archivos, escriba el

siguiente comando y presione ENTRAR.

Publish-BCFileContent -Path D:\share -StageData

Si el contenido que desea prehaso está en un servidor web, escriba el

siguiente comando y presione ENTRAR.

Publish-BCWebContent –Path D:\inetpub\wwwroot -StageData

4. Cree el paquete de datos ejecutando el siguiente comando en cada uno de los

servidores de contenido. Reemplace el valor de ejemplo (D:\temp) del parámetro –
Destination por la ubicación que identificó o creó al principio de este
procedimiento.

Export-BCDataPackage –Destination D:\temp

5. Desde el servidor de contenido, acceda al recurso compartido en los servidores de

caché hospedada donde desea cargar previamente el contenido y copie los
paquetes de datos en los recursos compartidos de los servidores de caché
hospedada.

Para continuar con esta guía, consulte Importación de paquetes de datos en el servidor
de caché hospedada (opcional).
Importar paquetes de datos en el
servidor de caché hospedada (opcional)
Artículo • 21/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2 y Windows Server 2012.

Puede usar este procedimiento para importar paquetes de datos y cargar previamente
contenido en los servidores de caché hospedada.

Este procedimiento es opcional porque no es necesario prehash ni precargar contenido

en los servidores de caché hospedada.

Si no carga previamente contenido, los datos se agregan a la caché hospedada

automáticamente a medida que los clientes lo descargan a través de la conexión WAN.

Para realizar este procedimiento debe ser miembro del grupo de administradores.

Para importar paquetes de datos en el servidor

de caché hospedada
1. En el equipo servidor, abra Windows PowerShell con privilegios de administrador.

2. Escriba el siguiente comando, reemplazando el valor del parámetro –Path por la

ubicación de la carpeta donde ha almacenado los paquetes de datos y, a
continuación, presione ENTRAR.

Import-BCCachePackage –Path D:\temp\[Link]

3. Si tiene más de un servidor de caché hospedada donde desea cargar previamente

contenido, realice este procedimiento en cada servidor de caché hospedada.

Para continuar con esta guía, consulte Configuración de la detección automática de

caché hospedada de cliente por punto de conexión de servicio.
Configurar la detección automática de
caché hospedada de cliente mediante el
punto de conexión de servicio
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2 y Windows Server 2012.

Con este procedimiento puede usar directiva de grupo habilitar y configurar el modo de
caché hospedada de BranchCache en equipos unidos a un dominio que ejecutan los
siguientes sistemas operativos compatibles con BranchCache Windows.

Windows 10 Enterprise
Windows 10 Education
Windows 8.1 Enterprise
Windows 8 Enterprise

７ Nota

Para configurar equipos unidos a un dominio que ejecutan Windows Server 2008
R2 o Windows 7, consulte la Guía de implementación de BranchCache de Windows
Server 2008 R2.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo Admins.

del dominio o grupo equivalente.

Para usar directiva de grupo para configurar clientes para

el modo de caché hospedada
1. En un equipo en el que esté instalado el rol de servidor Active Directory Domain
Services, abra Administrador del servidor, seleccione el servidor local, haga clic en
Herramientasy , a continuación, haga clic en Directiva de grupo Administración.
Se abre la Consola de administración de directivas de grupo.

2. En la consola de administración de directiva de grupo, expanda la siguiente ruta de

acceso: Bosque:[Link], Dominios, [Link], Objetos directiva
de grupo, donde [Link] es el nombre del dominio donde se encuentran
las cuentas de equipo cliente de BranchCache que desea configurar.
 3. Haga clic con el botón secundario en Objetos de directiva de grupo y, a
continuación, haga clic en Nuevo. Se abre el cuadro de diálogo Nuevo GPO. En
Nombre, escriba un nombre para el nuevo objeto de directiva de grupo (GPO). Por
ejemplo, si desea asignar al objeto el nombre Equipos cliente de BranchCache,
escriba Equipos cliente de BranchCache. Haga clic en OK.

4. En la Consola de administración de directivas de grupo, asegúrese de que esté

seleccionada la opción Objetos de directiva de grupo y, en el panel de detalles,
haga clic con el botón secundario en el objeto de directiva de grupo que acaba de
crear. Por ejemplo, si ha asignado al objeto de directiva de grupo el nombre
Equipos cliente de BranchCache, haga clic con el botón secundario en Equipos
cliente de BranchCache. Haga clic en Editar. Se abre Editor de administración de
directivas de grupo consola.

5. En la consola Editor de administración de directivas de grupo, expanda la siguiente

ruta de acceso: Configuración del equipo, Directivas, Plantillas administrativas:
Definiciones de directiva (archivos ADMX) recuperadas del equipo local, Red,
BranchCache.

6. Haga clic en BranchCache y, a continuación, en el panel de detalles, haga doble

clic en Activar BranchCache. Se abre el cuadro de diálogo Activar BranchCache.

7. En el cuadro de diálogo Activar BranchCache, haga clic en Habilitado y, a

continuación, en Aceptar.

8. En la Editor de administración de directivas de grupo, asegúrese de que

BranchCache sigue seleccionado y, a continuación, en el panel de detalles, haga
doble clic en Habilitar la detección automática de caché hospedada por punto de
conexión de servicio. Se abre el cuadro de diálogo de configuración de directiva.

9. En el cuadro de diálogo Habilitar detección automática de caché hospedada por

punto de conexión de servicio , haga clic en Habilitadoy, a continuación, haga clic
en Aceptar.

10. Para permitir que los equipos cliente descarguen y en caché el contenido de los
servidores de contenido basados en el servidor de archivos de BranchCache: en la
consola de Editor de administración de directivas de grupo, asegúrese de que
BranchCache sigue seleccionado y, a continuación, en el panel de detalles, haga
doble clic en BranchCache para los archivos de red. Se abre el cuadro de diálogo
Configurar BranchCache para archivos de red.

11. En el cuadro de diálogo Configurar BranchCache para archivos de red, haga clic
en Habilitado. En Opciones, escriba un valor numérico, en milisegundos, para el
 tiempo máximo de latencia de red de ida y vuelta y, a continuación, haga clic en
Aceptar.

７ Nota

De forma predeterminada, los equipos cliente almacena en caché el

contenido de los servidores de archivos si la latencia de red de ida y vuelta es
superior a 80 milisegundos.

12. Para configurar la cantidad de espacio en disco duro asignado en cada equipo
cliente para la caché de BranchCache: en la consola de Editor de administración de
directivas de grupo, asegúrese de que BranchCache sigue seleccionado y, a
continuación, en el panel de detalles, haga doble clic en Establecer porcentaje de
espacio en disco usado para la caché del equipo cliente. Se abre el cuadro de
diálogo Establecer el porcentaje de espacio en disco usado por la memoria caché
del equipo cliente. Haga clic en Habilitado y, a continuación, en Opciones escriba
un valor numérico que represente el porcentaje de espacio en disco duro utilizado
en cada equipo cliente para la memoria caché de BranchCache. Haga clic en OK.

13. Para especificar la antigüedad predeterminada, en días, para los segmentos que
son válidos en la caché de datos de BranchCache en equipos cliente: en la consola
de Editor de administración de directivas de grupo, asegúrese de que
BranchCache sigue seleccionado y, a continuación, en el panel de detalles, haga
doble clic en Establecer la antigüedad de los segmentos de la caché de datos. Se
abre el cuadro de diálogo Establecer la antigüedad de los segmentos en la caché
de datos. Haga clic en Habilitado y, a continuación, en el panel de detalles, escriba
el número de días que prefiera. Haga clic en OK.

14. Configure opciones de directiva de BranchCache adicionales para los equipos

cliente según corresponda para la implementación.

15. Actualice directiva de grupo equipos cliente de sucursal ejecutando el comando

gpupdate /force o reiniciando los equipos cliente.

La implementación del modo de caché hospedada de BranchCache ya está completa.

Para obtener información adicional sobre las tecnologías de esta guía, consulte Recursos
adicionales.
Recursos adicionales de BranchCache
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2 y Windows Server 2012.

Para obtener más información sobre las tecnologías que se de abordan en esta guía,
consulte los siguientes recursos:

BranchCache en Windows Server 2016

Instalar y configurar servidores de contenido

Comandos de Windows PowerShell y Shell de red para BranchCache

directiva de grupo información general de Windows Server 2012 R2

Windows de implementación de BranchCache de Windows Server 2008 R2

BranchCache
Artículo • 21/12/2022 • Tiempo de lectura: 36 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema, destinado a los profesionales de tecnología de la información (TI), se

proporciona información general sobre BranchCache, incluidos los modos, las
características, las capacidades y la funcionalidad de BranchCache que se encuentran
disponibles en diferentes sistemas operativos.

７ Nota

Además de este tema, está disponible la siguiente documentación sobre

BranchCache.

Comandos de Windows PowerShell y Shell de red para BranchCache

Guía de implementación de BranchCache

¿A quién puede interesarle BranchCache?

Si es administrador de un sistema, arquitecto de soluciones de red o almacenamiento, u

otro profesional de TI, BranchCache podría interesarle bajo las siguientes circunstancias:

Diseña u ofrece asistencia técnica a una infraestructura de TI de una organización

que tiene dos o más ubicaciones físicas y una conexión de red de área extensa
(WAN) desde las sucursales a la oficina central.

Diseña u ofrece asistencia técnica a una infraestructura de TI para una organización

que implementó tecnologías de nube y los trabajadores usan una conexión WAN
para acceder a los datos y las aplicaciones en ubicaciones remotas.

Desea optimizar el uso del ancho de banda WAN reduciendo la cantidad de tráfico
de red entre las sucursales y la oficina central.

Ha implementado o planea implementar servidores de contenido en la oficina

central que coinciden con las configuraciones que se describen en este tema.

Los equipos cliente de las sucursales ejecutan Windows 10, Windows 8.1, Windows
8 o Windows 7 .

Este tema incluye las siguientes secciones:

 ¿Qué es la BranchCache?

BranchCache modes

Servidores de contenido habilitados para BranchCache

BranchCache y la nube

Versiones de la información de contenido

Cómo administra BranchCache las actualizaciones de contenido en los archivos

Guía de instalación de BranchCache

Versiones de sistemas operativo para BranchCache

Seguridad de BranchCache

Flujo de contenido y procesos

Seguridad de almacenamiento en caché

¿Qué es la BranchCache?
BranchCache es una tecnología de optimización de ancho de banda de área extensa
(WAN) que se incluye en algunas ediciones de los sistemas operativos Windows Server
2016 y Windows 10, así como en algunas ediciones de Windows Server 2012 R2,
Windows 8.1, Windows Server 2012, Windows 8, Windows Server 2008 R2 y Windows 7.
Para mejorar el ancho de banda de la WAN cuando los usuarios acceden a contenido de
servidores remotos, BranchCache obtiene el contenido de los servidores de contenido
de la oficina central o de la nube hospedada y lo almacena en la memoria caché de las
sucursales, lo que permite que los equipos cliente de dichas sucursales accedan al
contenido de forma local, y no a través de la WAN.

En las sucursales, el contenido se almacena en servidores configurados para hospedar la

memoria caché o, cuando no hay ningún servidor disponible en la sucursal, en equipos
cliente que ejecutan Windows 10, Windows 8.1, Windows 8 o Windows 7. Cuando un
equipo cliente haya solicitado y recibido un determinado contenido de la oficina central
y este se haya almacenado en caché en la sucursal, el resto de equipos de la sucursal
podrá disponer de este contenido de forma local y sin necesidad de descargarlo del
servidor de contenido a través de un vínculo WAN.

Cuando los equipos cliente posteriormente realizan solicitudes para el mismo

contenido, los clientes descargan información del contenido del servidor en lugar del
contenido en sí. La información de contenido se compone de hashes que se calculan
mediante fragmentos del contenido original y que son sumamente pequeños en
comparación con el contenido de los datos originales. Después, los equipos cliente usan
la información de contenido para ubicar el contenido de una memoria caché en la
sucursal, ya sea que la memoria caché se encuentre en un equipo cliente o en un
servidor. Los equipos y servidores cliente también usan información de contenido para
proteger el contenido almacenado en caché de manera que usuarios no autorizados no
puedan acceder a él.

BranchCache aumenta la productividad del usuario final al mejorar tanto el tiempo de

respuesta de las consultas de contenido en los clientes y servidores de las sucursales
como el rendimiento de la red, ya que reduce el tráfico en los vínculos WAN.

BranchCache modes
BranchCache cuenta con dos modos de operación: modo Caché distribuida y modo
Caché hospedada.

Cuando se implementa BranchCache en modo Caché distribuida, la caché de contenido

en la sucursal se distribuye entre los equipos cliente.

Cuando implementa BranchCache en modo Caché hospedada, la memoria caché de

contenido en la sucursal se hospeda en uno o más equipos servidores que se
denominan servidores de caché hospedada.

７ Nota

Se puede implementar BranchCache con ambos modos; sin embargo, solo se

puede usar un modo por sucursal. Por ejemplo, si tiene dos sucursales, una que
tiene un servidor y una que no, puede implementar BranchCache en modo Caché
hospedada en la oficina que tiene el servidor, e implementar BranchCache en modo
Caché distribuida en la oficina que solo tiene equipos cliente.

En la siguiente ilustración, se implementa BranchCache en ambos modos.

El modo Caché distribuida es el más apropiado para sucursales pequeñas que no tienen
un servidor local para usar como servidor de caché hospedada. El modo Caché
distribuida le permite implementar BranchCache sin hardware adicional en las
sucursales.

Si la sucursal donde desea implementar BranchCache contiene infraestructura adicional,

como uno o más servidores que ejecutan otras cargas de trabajo, implementar
BranchCache en modo Caché hospedada resulta beneficioso por los siguientes motivos:

Mayor disponibilidad de la memoria caché

El modo Caché hospedada aumenta la eficacia del almacenamiento en caché, ya que el
contenido se encuentra disponible incluso si el cliente que originalmente solicitó los
datos almacenados en caché está desconectado. Dado que el servidor de caché
hospedada está siempre disponible, se almacena más contenido en caché, lo cual ofrece
más ahorro de ancho de banda WAN y se mejora la eficiencia de BranchCache.

Almacenamiento en caché centralizado para sucursales

de varias subredes
El modo Caché distribuida funciona en una subred única. En una sucursal de varias
subredes que está configurada para el modo Caché distribuida no se puede compartir
un archivo descargado a una subred con equipos cliente de otras subredes.

Por este motivo, los clientes de otras subredes, que no pueden saber si el archivo ya se
descargó, obtienen el archivo del servidor de contenido de la oficina central, usando
ancho de banda WAN en el proceso.

Sin embargo, cuando implementan un modo Caché hospedada (este no es el caso),

todos los clientes de la sucursal de varias subredes pueden acceder a una memoria
caché única, que se almacena en el servidor de caché hospedada, aun si los clientes se
encuentran en subredes diferentes. Además, BranchCache en Windows Server 2016,
Windows Server 2012 R2 y Windows Server 2012 proporciona la capacidad de
implementar más de un servidor de caché hospedado por sucursal.

Ｕ Precaución

Si usa BranchCache para realizar almacenamiento en caché SMB de archivos y

carpetas, no deshabilite Archivos sin conexión. Si deshabilita Archivos sin conexión,
el almacenamiento en caché SMB no funcionará correctamente.

Servidores de contenido habilitados para

BranchCache
Al implementar BranchCache, el contenido de origen se almacena en servidores de
contenido habilitados para BranchCache en la oficina principal o en un centro de datos
en la nube. BranchCache admite los siguientes tipos de servidores de contenido:

７ Nota

Solo el contenido de origen ( es decir, el contenido que los equipos cliente

obtienen inicialmente de un servidor de contenido habilitado para BranchCache)
está acelerado por BranchCache. Los equipos cliente no almacenan en la memoria
caché el contenido que los equipos cliente obtienen directamente de otros
orígenes, como servidores web de Internet o de Windows Update ni en servidores
de caché hospedada y después lo comparten con otros equipos de la sucursal. Sin
embargo, si desea acelerar Windows Update contenido, puede instalar un servidor
de aplicaciones de Windows Server Update Services (WSUS) en la oficina principal o
en el centro de datos en la nube y configurarlo como un servidor de contenido de
BranchCache.
Servidores web
Los servidores web admitidos incluyen equipos que ejecutan Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012 o Windows Server 2008 R2 que tienen
instalado el rol de servidor Servidor web (IIS) y que usan el Protocolo de transferencia
de hipertexto (HTTP) o HTTP Secure (HTTPS).

Además, el servidor web debe tener la característica BranchCache instalada.

Servidores de archivos
Los servidores de archivos admitidos incluyen equipos que ejecutan Windows Server
2016, Windows Server 2012 R2, Windows Server 2012 o Windows Server 2008 R2 que
tienen instalado el rol de servidor Servicios de archivos y branchCache para el servicio
de rol Archivos de red.

Estos servidores de archivos usan el Bloque de mensajes del servidor (SMB) para
intercambiar información entre los equipos. Después de completar la instalación del
servidor de archivos, también debe compartir carpetas y habilitar la generación de hash
para carpetas compartidas usando la directiva de grupo o la directiva de equipo local
para habilitar BranchCache.

Servidores de aplicaciones
Los servidores de aplicaciones admitidos incluyen equipos que ejecutan Windows Server
2016, Windows Server 2012 R2, Windows Server 2012 o Windows Server 2008 R2 con
Servicio de transferencia inteligente en segundo plano (BITS) instalados y habilitados.

Además, el servidor web debe tener la característica BranchCache instalada. Como

ejemplos de servidores de aplicaciones, puede implementar Microsoft Windows Server
Update Services (WSUS) y Microsoft Endpoint Configuration Manager servidores de
punto de distribución de sucursales como servidores de contenido de BranchCache.

BranchCache y la nube
La nube ofrece grandes posibilidades de reducir los gastos operativos y alcanzar nuevos
niveles de escala, pero quitarle las cargas de trabajo a las personas que dependen de
ellas puede aumentar los costos de las redes y afectar a la productividad. Los usuarios
esperan un alto rendimiento y no les importa dónde se hospedan sus aplicaciones y
datos.
BranchCache puede mejorar el rendimiento de aplicaciones en red y reducir el consumo
de ancho de banda con una memoria caché de datos compartida. Mejora la
productividad en las sucursales y en las oficinas principales donde los trabajadores usan
servidores que están implementados en la nube.

Dado que BranchCache no requiere hardware nuevo ni cambios en la topología de red,

es una excelente solución para mejorar la comunicación entre las ubicaciones de la
oficina y las nubes pública y privada.

７ Nota

Dado que algunos servidores proxy web no pueden procesar encabezados de

codificación de contenido no estándar, se recomienda usar BranchCache con hyper
Text Transfer Protocol Secure (HTTPS) y no HTTP.

======= Para obtener más información sobre las tecnologías en la nube en Windows
Server 2016, vea Redes definidas por software (SDN).

Versiones de la información de contenido

Existen dos versiones de la información de contenido:

La información de contenido compatible con equipos que ejecutan Windows

Server 2008 R2 y Windows 7 se denomina versión 1 o V1. Con la segmentación de
archivos de BranchCache V1, los segmentos de archivo son más grandes que los
de V2 y tienen un tamaño fijo. Debido a estos tamaños fijos de segmento tan
voluminosos, cuando un usuario realiza un cambio que altera la longitud del
archivo, se invalida no solo el segmento con el cambio, sino todos los segmentos
del archivo por completo. En consecuencia, la siguiente llamada que efectúe otro
usuario de la sucursal en relación con el archivo modificado supondrá un escaso
ahorro de ancho de banda de WAN, dado que tanto el contenido modificado
como todo el contenido posterior al cambio se envía a través del vínculo WAN.

La información de contenido compatible con equipos que ejecutan Windows

Server 2016, Windows 10, Windows Server 2012 R2, Windows 8.1, Windows Server
2012 y Windows 8 se denomina versión 2 o V2. La información de contenido V2
emplea segmentos más pequeños y de tamaño variable que son más tolerantes a
los cambios en un archivo. Esto aumenta la posibilidad de poder reutilizar los
segmentos procedentes de una versión más antigua del archivo cuando los
usuarios acceden a una versión actualizada, lo que hace que obtengan del servidor
 de contenido únicamente la parte modificada del archivo y, por lo tanto, se use
menos ancho de banda de WAN.

En la siguiente tabla encontrará información sobre la versión de información de

contenido que se usa en función de los sistemas operativos de cliente, de servidor de
contenido y de servidor de caché hospedada que use en su implementación de
BranchCache.

７ Nota

En la tabla siguiente, el acrónimo "OS" significa sistema operativo.

Sistema operativo del SO de SO de servidor de caché Versión de

cliente servidor de hospedada información de
contenido contenido

Windows Server 2008 R2 Windows Windows Server 2012 o posterior; V1

y Windows 7 Server 2012 o ninguno para el modo de caché
superior distribuida

Windows Server 2012 o Windows Windows Server 2012 o posterior; V1

posterior; Windows 8 o Server 2008 R2 ninguno para el modo de caché
posterior distribuida

Windows Server 2012 o Windows Windows Server 2008 R2 V1

posterior; Windows 8 o Server 2012 o
posterior superior

Windows Server 2012 o Windows Windows Server 2012 o posterior; V2

posterior; Windows 8 o Server 2012 o ninguno para el modo de caché
posterior superior distribuida

Cuando tiene servidores de contenido y servidores de caché hospedados que ejecutan

Windows Server 2016, Windows Server 2012 R2 y Windows Server 2012, usan la versión
de información de contenido adecuada en función del sistema operativo del cliente de
BranchCache que solicita información.

Cuando los equipos que ejecutan Windows Server 2012 y Windows 8 o sistemas
operativos posteriores solicitan contenido, el contenido y los servidores de caché
hospedados usan información de contenido V2; cuando los equipos que ejecutan
Windows Server 2008 R2 y Windows 7 contenido de solicitud, los servidores de caché
hospedada y de contenido usan la información de contenido V1.

） Importante
 Cuando BranchCache se implementa en modo de caché distribuida, los clientes que
usen otras versiones de información de contenido no compartirán contenido entre
ellos. Por ejemplo, un equipo cliente que ejecuta Windows 7 y un equipo cliente
que ejecuta Windows 10 que están instalados en la misma sucursal no comparten
contenido entre sí.

Cómo administra BranchCache las

actualizaciones de contenido en los archivos
Cuando los usuarios de la sucursal modifican o actualizan el contenido de los
documentos, sus cambios se escriben directamente en el servidor de contenido de la
oficina principal sin la participación de BranchCache. Esto es así tanto si un usuario
descarga el documento del servidor de contenidos como si lo obtiene de una caché
hospedada o distribuida en la sucursal.

Cuando un cliente distinto de una sucursal solicita el archivo modificado, los nuevos
segmentos del archivo se descargan desde el servidor de la oficina central y se agregan
a la caché distribuida u hospedada de dicha sucursal. Debido a esto, los usuarios de las
sucursales siempre disponen de las versiones más recientes del contenido almacenado
en caché.

Guía de instalación de BranchCache

Puede usar Administrador del servidor en Windows Server 2016 para instalar la
característica BranchCache o el servicio de rol BranchCache para archivos de red del rol
de servidor servicios de archivos. Puede usar la siguiente tabla para determinar si debe
instalar el servicio de rol o la característica.

Funcionalidad Ubicación del Instalar este elemento de BranchCache

equipo

Servidor de contenido Centro de datos Característica BranchCache

(servidor de aplicaciones en la nube o en
basado en BITS) oficina central

Servidor de contenido Centro de datos Característica BranchCache

(servidor web) en la nube o en
oficina central

Servidor de contenido Centro de datos Servicio de rol BranchCache para archivos de red
(servidor de archivos que en la nube o en del rol de servidor Servicios de archivo
usa el protocolo SMB) oficina central
 Funcionalidad Ubicación del Instalar este elemento de BranchCache
equipo

Servidor de caché Sucursal Característica de BranchCache con modo de

hospedada servidor de caché hospedada habilitado

Equipo cliente habilitado Sucursal No se requiere instalación, simplemente habilite

para BranchCache BranchCache y un modo de BranchCache
(distribuida u hospedada) en el cliente

Para instalar el servicio de rol o la característica, abra el Administrador del servidor y

seleccione los equipos en los que desea habilitar la funcionalidad de BranchCache. En el
Administrador del servidor, haga clic en Administrar y en Agregar roles y
características. Se abre el asistente para Agregar roles y características. Cuando ejecute
el asistente, realice las siguientes selecciones:

En la página del asistente Seleccionar tipo de instalación, seleccione Instalación

basada en características o en roles.

En la página del asistente, seleccione Roles de servidor, si va a instalar un servidor

de archivos habilitado para BranchCache, expanda Servicios de archivos y
servicios de Storagey servicios iSCSI y, a continuación, seleccione BranchCache
para archivos de red. Para ahorrar espacio en disco, también puede seleccionar el
servicio de rol Desduplicación de datos y, a continuación, continuar con el
asistente para la instalación y finalización. Si no desea instalar un servidor de
archivos habilitado para BranchCache, no instale el rol File y Storage Services con
el servicio de rol BranchCache for Network Files.

En la página del asistente Seleccionar características, si va a instalar un servidor de

contenido que no es un servidor de archivos o está instalando un servidor de
caché hospedado, seleccione BranchCache y, a continuación, continúe con el
asistente para la instalación y finalización. Si no desea instalar un servidor de
contenido que no sea un servidor de archivos o un servidor de caché hospedada,
no instale la característica BranchCache.

Versiones de sistemas operativo para

BranchCache
La siguiente es una lista de los sistemas operativos compatibles con diferentes tipos de
funcionalidad de BranchCache.
Sistemas operativos para la funcionalidad de equipo
cliente de BranchCache
Los siguientes sistemas operativos proporcionan a BranchCache compatibilidad con
Servicio de transferencia inteligente en segundo plano (BITS), Protocolo de transferencia
de texto de Hyper (HTTP) y Bloque de mensajes del servidor (SMB).

Windows 10 Enterprise

Windows 10 Education

Windows 8.1 Enterprise

Windows 8 Enterprise

Windows 7 Enterprise

Windows 7 Ultimate

En los siguientes sistemas operativos, BranchCache no admite la funcionalidad HTTP y

SMB, pero admite la funcionalidad bits de BranchCache.

Windows 10 Pro, solo admite BITS

Windows 8.1 Pro, solo admite BITS

Windows 8 Pro, solo admite BITS

Windows 7 Pro, solo admite BITS

７ Nota

BranchCache no está disponible de forma predeterminada en los sistemas

operativos Windows Server 2008 o Windows Vista. Sin embargo, en estos sistemas
operativos, si descarga e instala la actualización Windows Management Framework,
la funcionalidad BranchCache solo está disponible para el protocolo Servicio de
transferencia inteligente en segundo plano (BITS). Para obtener más información y
descargar Windows Management Framework, consulte Windows Management
Framework (Windows PowerShell 2.0, WinRM 2.0 y BITS 4.0) en
/powershell/scripting/windows-powershell/install/the-windows-powershell-
powershell-2.0-engine.
Sistemas operativos para la funcionalidad de servidor de
contenido de BranchCache
Puede usar las familias de Windows Server 2016, Windows Server 2012 R2 y Windows
Server 2012 de sistemas operativos como servidores de contenido de BranchCache.

Además, la familia de sistemas operativos Windows Server 2008 R2 se puede usar como
servidores de contenido de BranchCache, con las siguientes excepciones:

BranchCache no se admite en instalaciones server Core de Windows Server 2008

R2 Enterprise con Hyper-V.

BranchCache no se admite en instalaciones server Core de Windows Server 2008

R2 Datacenter con Hyper-V.

Sistemas operativos para la funcionalidad de servidor de

caché hospedada de BranchCache
Puede usar las familias de Windows Server 2016, Windows Server 2012 R2 y Windows
Server 2012 de sistemas operativos como servidores de caché hospedados de
BranchCache.

Además, los siguientes sistemas operativos Windows Server 2008 R2 se pueden usar
como servidores de caché hospedados de BranchCache:

Windows Server 2008 R2 Enterprise

Windows Server 2008 R2 Enterprise con Hyper-V

Instalación de Windows Server 2008 R2 Enterprise Server Core

instalación de Windows Server 2008 R2 Enterprise Server Core con Hyper-V

Windows Server 2008 R2 for Itanium-Based Systems

Windows Server 2008 R2 Datacenter

Windows Server 2008 R2 Datacenter con Hyper-V

instalación de Windows Server 2008 R2 Datacenter Server Core con Hyper-V

Seguridad de BranchCache
BranchCache implementa un enfoque de diseño seguro que funciona a la perfección
junto con las arquitecturas de seguridad existentes, sin necesidad de contar con otros
equipos o configuraciones de seguridad complejas.

BranchCache no es invasivo y no modifica ningún proceso de autenticación o

autorización de Windows. Después de implementar BranchCache, la autenticación se
lleva a cabo de todas formas con las credenciales de dominio sin modificaciones en la
forma en que funciona la autorización con las listas de control de acceso (ACL). Además,
el resto de las configuraciones continúa funcionando como lo venía haciendo antes de
la implementación de BranchCache.

El modelo de seguridad de BranchCache se basa en la creación de metadatos que

adoptan la forma de una serie de hashes. Estos hashes también se denominan
información de contenido.

Una vez creada la información de contenido, se usa en intercambios de mensajes de

BranchCache en lugar de los datos reales, y se intercambia mediante los protocolos
admitidos (HTTP, HTTPS y SMB).

Los datos almacenados en la memoria caché se mantienen cifrados y los clientes que no
cuentan con permiso para acceder al contenido de la fuente original no pueden acceder
a ellos. Los clientes deben estar autenticados y autorizados por el origen de contenido
original antes de poder recuperar metadatos de contenido y deben poseer metadatos
de contenido para poder acceder a la memoria caché de la oficina local.

Cómo BranchCache genera información de contenido

Dado que la información de contenido se crea a partir de varios elementos, el valor de
la información del contenido es siempre única. Estos elementos son:

El contenido real (como páginas web o archivos compartidos) de los cuales derivan
los hashes.

Parámetros de configuración como el algoritmo hash y el tamaño de bloque. Para

generar información de contenido, el servidor de contenido divide el contenido en
segmentos y después subdivide esos segmentos en bloques. BranchCache usa
hashes criptográficos seguros para identificar y comprobar cada bloque y cada
segmento, al admitir el algoritmo hash SHA256.

Un secreto de servidor Todos los servidores de contenido deben estar

configurados con un secreto de servidor, que es un valor binario de longitud
arbitraria.
 ７ Nota

El uso de un secreto de servidor garantiza que los equipos cliente no puedan

generar la información de contenido por sí mismos. Esto impide que usuarios
malintencionados usen ataques de fuerza bruta con equipos cliente habilitados
para BranchCache para adivinar cambios menores en el contenido entre las
versiones en situaciones en las que el cliente tuvo acceso a una versión anterior
pero no a la versión actual.

Detalles de la información de contenido

BranchCache usa el secreto de servidor como clave para derivar un hash de contenido
específico que se envía a los clientes autorizados. Al aplicar un algoritmo hash al secreto
de servidor combinado y al hash de datos se genera este hash.

Este hash se denomina secreto de segmento. BranchCache usa secretos de segmento

para proteger las comunicaciones. Además, BranchCache crea una lista de hashes de
bloque, que es una lista de los bloques de datos con hash y el hash de datos, que se
genera al aplicar el hash a la lista de hashes de bloque.

La información de contenido incluye lo siguiente:

La lista de hashes de bloque:

BlockHashi = Hash(dataBlocki) 1<=i<=n

El hash de datos (HoD):

HoD = Hash(BlockHashList)

Secreto de segmento (Kp):

Kp = HMAC(Ks, HoD)

BranchCache usa el protocolo de almacenamiento en caché de contenido y el protocolo

de marco de recuperación para implementar los procesos necesarios para garantizar el
almacenamiento en caché y la recuperación de datos seguros entre cachés de
contenido.

Por otra parte, BranchCache maneja información de contenido con el mismo grado de
seguridad que emplea al manejar y transmitir el contenido real.
Flujo de contenido y procesos
El flujo de información de contenido y el contenido real se divide en cuatro fases:

1. Procesos de BranchCache: solicitud de contenido

2. Procesos de BranchCache: ubicación de contenido

3. Procesos de BranchCache: recuperación de contenido

4. Procesos de BranchCache: almacenamiento del contenido en caché

Estas fases se describen en las siguientes secciones.

Procesos de BranchCache: solicitud de

contenido
En la primera fase, el equipo cliente de la sucursal solicita contenido, por ejemplo, un
archivo o una página web, de un servidor de contenido en una ubicación remota, como
una oficina central. El servidor de contenido comprueba que el equipo cliente esté
autorizado a recuperar el contenido solicitado. Si el equipo cliente está autorizado y el
servidor de contenido y el cliente están habilitados para BranchCache, el servidor de
contenido genera información de contenido.

Después, el servidor de contenido envía información de contenido al equipo cliente

utilizando el mismo protocolo que hubiese usado para el contenido real.

Por ejemplo, si el equipo cliente solicitó una página web a través de HTTP, el servidor de
contenido envía la información de contenido con HTTP. Debido a ello, las garantías de
seguridad a nivel conexión del contenido y la información de contenido son idénticas.

Después de que se recibe la porción inicial de información de contenido (hash de datos

+ secreto de segmento), el equipo cliente realiza las siguientes acciones:

Usa el secreto de segmento (Kp) como clave de cifrado (Ke).

Genera el identificador de segmento (HoHoDk) a partir de HoD y Kp:

HoHoDk = HMAC(Kp, HoD + C), where C is the ASCII string "MS_P2P_CACHING" with

NUL terminator.

La principal amenaza en este nivel es el riesgo del secreto de segmento; sin embargo,
BranchCache cifra los bloques de datos de contenido para proteger el secreto de
segmento. BranchCache lo hace al utilizar la clave de cifrado que deriva del secreto de
segmento del segmento de contenido dentro del cual se encuentran los bloques de
contenido.

Este enfoque garantiza que una entidad que posee el secreto de servidor no pueda
descubrir el contenido real en el bloque de datos. El secreto de segmento se trata con el
mismo grado de seguridad que el segmento de texto sin formato mismo, ya que
conocer el secreto de segmento de un segmento determinado permite a una entidad
obtener el segmento de sus pares y después, descifrarlo. Conocer el secreto de servidor
no produce de inmediato ningún texto sin formato en particular, pero se puede usar
para derivar ciertos tipos de datos del texto cifrado y después, posiblemente exponer
algunos datos parcialmente conocidos a un ataque por adivinar mediante la fuerza
bruta. Por lo tanto, el secreto de servidor debe mantenerse en absoluta
confidencialidad.

Procesos de BranchCache: ubicación de

contenido
Una vez que el equipo cliente recibe información de contenido, el cliente usa el
identificador de segmento para ubicar el contenido solicitado en la memoria caché de la
sucursal, ya sea que esa memoria caché esté distribuida entre los equipos cliente o se
encuentre en un servidor de caché hospedada.

Si el equipo cliente está configurado para el modo Caché hospedada, se configura con
el nombre de equipo del servidor de caché hospedada y se pone en contacto con ese
servidor para recuperar el contenido.

Sin embargo, si el equipo cliente está configurado para el modo Caché distribuida, el
contenido podría almacenarse entre varias cachés en varios equipos de la sucursal. El
equipo cliente debe descubrir la ubicación del contenido antes de que se recupere el
contenido.

Cuando están configurados para el modo Caché distribuida, los equipos cliente ubican
el contenido mediante un protocolo de descubrimiento que se basa en el protocolo de
detección dinámica de servicios web (WS-Discovery). Los clientes envían mensajes de
sondeo de multidifusión de WS-Discovery para descubrir contenido almacenado en
caché a través de la red. Los mensajes de sondeo incluyen el identificador de segmento,
que permite a los clientes comprobar si el contenido solicitado coincide con el
contenido almacenado en la memoria caché. Los clientes que reciben el mensaje de
sondeo inicial responden ala cliente que realiza la consulta con mensajes que coincidan
con el sondeo de unidifusión si el identificador de segmento coincide con el contenido
almacenado localmente en la memoria caché.
El éxito del proceso de WS-Discovery depende de si el cliente que está realizando el
descubrimiento cuenta con la información de contenido correcta, que le proporcionó el
servidor de contenido, para el contenido que está solicitando.

La principal amenaza a los datos durante la fase de solicitud de contenido es la

divulgación de información, ya que el acceso a la información de contenido implica
acceso no autorizado al contenido. Para mitigar este riesgo, el proceso de
descubrimiento no revela la información de contenido a excepción del identificador de
segmento, que no revela nada sobre el segmento de texto sin formato que contiene el
contenido.

Además, otro equipo cliente en manos de un usuario malintencionado en la misma

subred de red puede ver el tráfico de descubrimiento de BranchCache hacia el origen de
contenido original que pasa por el enrutador.

Si el contenido solicitado no se encuentra en la sucursal, el cliente solicita el contenido

directamente del servidor de contenido a través del vínculo WAN:

Después de que se recibe el contenido, se agrega a la caché local ya sea en el equipo

cliente o en el servidor de caché hospedada. En este caso, la información de contenido
impide que un cliente o servidor de caché hospedada agregue a la caché local ningún
contenido que no coincida con los hashes. El proceso de comprobación de contenido
mediante hashes coincidentes garantiza que solo se agregue a la caché contenido
válido y se protege la integridad de la caché local.

Procesos de BranchCache: recuperación de

contenido
Una vez que un equipo cliente ubica el contenido deseado en el host de contenido, que
es un servidor de caché hospedada o un equipo cliente en modo Caché distribuida, el
equipo cliente inicia el proceso de recuperación de contenido.

En primer lugar, el equipo cliente envía una solicitud al host de contenido para el primer
bloque que requiere. La solicitud contiene el identificador de segmento y el rango de
bloques que identifican el contenido deseado. Ya que solo se devuelve un bloque, el
rango de bloques contiene un solo bloque. (Actualmente no se admiten solicitudes de
varios bloques). El cliente también almacena la solicitud en su lista de solicitudes
pendientes local.

Al recibir un mensaje de solicitud válido de un cliente, el host de contenido comprueba

si el bloque especificado en la solicitud existe en la caché de contenido del host de
contenido.
Si el host de contenido está en posesión del bloque de contenido, entonces el host de
contenido envía una respuesta que contiene el identificador de segmento, el
identificador de bloque, el bloque de datos cifrados y el vector de inicialización que se
usa para cifrar el bloque.

Si el host de contenido no se encuentra en posesión del bloque de contenido, el host de

contenido envía un mensaje de respuesta vacío. Esto informa al equipo cliente de que el
host de contenido no cuenta con el bloque solicitado. Un mensaje de respuesta vacío
contiene el identificador de segmento y el identificador de bloque del bloque solicitado,
junto con un bloque de datos de tamaño cero.

Cuando el equipo cliente recibe la respuesta del host de contenido, el cliente

comprueba que el mensaje corresponda a un mensaje de solicitud en su lista de
solicitudes pendientes. (El identificador de segmento y el índice de bloque deben
coincidir con los de una solicitud pendiente).

Si el proceso de comprobación es incorrecto y el equipo cliente no cuenta con un

mensaje de solicitud correspondiente en su lista de solicitudes pendientes, el equipo
cliente descarta el mensaje.

Si este proceso de comprobación es correcto y el equipo cliente cuenta con un mensaje

de solicitud correspondiente en su lista de solicitudes pendientes, el equipo cliente
descifra el bloque. A continuación, el cliente valida el bloque descifrado con el hash de
bloque adecuado de la información de contenido que el cliente obtuvo inicialmente del
servidor de contenido original.

Si la validación de bloque es correcta, el bloque descifrado se almacena en la memoria

caché.

Este proceso se repite hasta que el cliente cuente con todos los bloques requeridos.

７ Nota

Si los segmentos completos de contenido no existen en un equipo, el protocolo de

recuperación recupera y ensambla el contenido de una combinación de orígenes:
un conjunto de equipos cliente del modo de caché distribuida, un servidor de
caché hospedado y , si las memorias caché de sucursales no contienen el contenido
completo, el servidor de contenido original de la oficina principal.

Antes de que BranchCache envíe información de contenido o el contenido, se cifran los

datos. BranchCache cifra el bloque en el mensaje de respuesta. En Windows 7, el
algoritmo de cifrado predeterminado que usa BranchCache es AES-128, la clave de
cifrado es Ke y el tamaño de la clave es de 128 bits, según lo dicta el algoritmo de
cifrado.

BranchCache genera un vector de inicialización adecuado para el algoritmo de cifrado y

usa la clave de cifrado para cifrar el bloque. Después, BranchCache registra el algoritmo
de cifrado y el vector de inicialización en el mensaje.

Los servidores y los clientes nunca intercambian, comparten, ni se envían entre sí la

clave de cifrado. El cliente recibe la clave de cifrado del servidor de contenido que
alberga el contenido de origen. A continuación, descifra el bloque con el algoritmo de
cifrado y el vector de inicialización que recibió del servidor. En el protocolo de descarga
no hay ninguna otra autenticación o autorización explicita.

Amenazas para la seguridad

Las principales amenazas para la seguridad en este nivel incluyen:

Alteración de los datos:

Un cliente que sirve datos a un solicitante altera los datos. El modelo de seguridad
de BranchCache usa hashes para confirmar que ni el cliente ni el servidor alteraron
los datos.

Divulgación de información:

BranchCache envía contenido cifrado a cualquier cliente que especifique un

identificador de segmento apropiado. Los identificadores de segmento son
públicos, por lo tanto cualquier cliente puede recibir contenido cifrado. Sin
embargo, si un usuario malintencionado obtiene contenido cifrado, debe conocer
la clave de cifrado para descifrar el contenido. El protocolo de nivel superior realiza
la autenticación y, a continuación, proporciona la información de contenido al
cliente autenticado y autorizado. La seguridad de la información de contenido
equivale a la seguridad que se proporciona al contenido mismo, y BranchCache
nunca expone la información de contenido.

Un atacante examina los datos de la conexión para obtener el contenido.

BranchCache cifra todas las transferencias entre los clientes mediante AES128, con
la clave secreta Ke, lo que impide que se examinen los datos de la conexión. La
información de contenido que se descarga del servidor de contenido se protege
exactamente de la misma manera que los datos en sí; por lo tanto, no está ni más
ni menos protegida de la divulgación de información que si no se hubiese utilizado
BranchCache en absoluto.
 Denegación de servicio:

Un cliente se desborda con solicitudes de datos. Los protocolos de BranchCache

incorporan contadores y temporizadores de administración de colas para impedir
que los clientes se sobrecarguen.

Procesos de BranchCache: almacenamiento del

contenido en caché
En los equipos cliente en modo Caché distribuida y los servidores de caché hospedada
que se encuentran en las sucursales, las caché de contenido se acumulan con el paso
del tiempo a medida que se recupera el contenido a través de los vínculos WAN.

Cuando los equipos cliente están configurados con modo Caché hospedada, agregan
contenido a su propia caché local y también ofrecen datos al servidor de caché
hospedada. El protocolo de caché hospedada ofrece un mecanismo a los clientes que
informan al servidor de caché hospedada acerca de la disponibilidad del contenido y los
segmentos.

Para cargar contenido al servidor de caché hospedada, el cliente informa al servidor de

que tiene un segmento que está disponible. A continuación, el servidor de caché
hospedada recupera toda la información de contenido que está relacionada con el
segmento ofrecido y descarga los bloques dentro del segmento que realmente se
necesita. Este proceso se repite hasta que el cliente ya no tenga más segmentos que
ofrecer al servidor de caché hospedada.

Para actualizar el servidor de caché hospedada utilizando el protocolo de caché

hospedada, se deben cumplir los siguientes requisitos:

El equipo cliente debe contar con un conjunto de bloques dentro de un segmento

que pueda ofrecer al servidor de caché hospedada. El cliente debe suministrar
información de contenido para el segmento ofrecido; esta se compone del
identificador de segmento, el hash de datos del segmento, el secreto del
segmento y una lista de todos los hashes de bloque que contiene el segmento.

En el caso de los servidores de caché hospedados que ejecutan Windows Server

2008 R2, se requiere un certificado de servidor de caché hospedado y una clave
privada asociada, y la entidad de certificación (CA) que emitió el certificado debe
ser de confianza para los equipos cliente de la sucursal. Esto permite que el cliente
y el servidor participen correctamente en la autenticación del servidor HTTPS.

） Importante
 Los servidores de caché hospedados que ejecutan Windows Server 2016,
Windows Server 2012 R2 o Windows Server 2012 no requieren un certificado
de servidor de caché hospedado y una clave privada asociada.

El equipo cliente está configurado con el nombre de equipo del servidor de caché
hospedada y el número de puerto del Protocolo de control de transmisión (TCP)
en el cual el servidor de caché hospedada está escuchando el tráfico de
BranchCache. El certificado del servidor de caché hospedado está enlazado a este
puerto. El nombre de equipo del servidor de caché hospedada puede ser un
nombre de dominio completo (FQDN), si el servidor de caché hospedada es un
equipo miembro del dominio, o puede ser el nombre NetBIOS del equipo si el
servidor de caché hospedada no es un miembro del dominio.

El equipo cliente escucha activamente las solicitudes de bloque entrantes. El

puerto en el que se escucha se pasa como parte de los mensajes de oferta desde
el cliente al servidor de caché hospedada. Esto permite que el servidor de caché
hospedada use protocolos de BranchCache para conectarse al equipo cliente para
recuperar bloques de datos en el segmento.

Al iniciarse, el servidor de caché hospedada comienza a escuchar las solicitudes de

HTTP entrantes.

Si el servidor de caché hospedada está configurado para exigir la autenticación del

equipo cliente, se requiere que el cliente y el servidor de caché hospedada
admitan autenticación HTTPS.

Relleno de la memoria caché en modo de caché

hospedada
El proceso de agregar contenido a la memoria caché del servidor de caché hospedada
en una sucursal comienza cuando el cliente envía un INITIAL_OFFER_MESSAGE, que
incluye el identificador de segmento. El identificador de segmento de la solicitud
INITIAL_OFFER_MESSAGE se usa para recuperar el hash de segmento correspondiente
de datos, la lista de hash de bloques y el secreto de segmento de la caché de bloques
del servidor de caché hospedada. Si el servidor de caché hospedada ya cuenta con toda
la información de contenido de un segmento en particular, la respuesta a
INITIAL_OFFER_MESSAGE será OK y no se produce la solicitud de descarga de bloques.

Si el servidor de caché hospedada no cuenta con todos los bloques de datos ofrecidos
asociados con los hashes de bloque en el segmento, la respuesta a
INITIAL_OFFER_MESSAGE es INTERESTED (interesado). Después, el cliente envía un
SEGMENT_INFO_MESSAGE (mensaje de información del segmento) que describe el
único segmento que se está ofreciendo. El servidor de caché hospedada responde con
un mensaje OK e inicia la descarga de los bloques faltantes del equipo cliente que los
ofrece.

El hash de datos del segmento, la lista de hashes de bloque y el secreto del segmento
se usan para garantizar que el contenido que se descarga no esté modificado ni
alterado de otra manera. Los bloques descargados se agregan después a la memoria
caché del bloque del servidor de caché hospedada.

Seguridad de almacenamiento en caché

En esta sección se proporciona información sobre cómo BranchCache protege los datos
almacenados en caché en equipos cliente y en servidores de caché hospedada.

Seguridad de la memoria caché en el equipo cliente

La mayor amenaza a los datos almacenados en BranchCache es la alteración. Si un
atacante puede alterar el contenido y la información de contenido que se almacena en
caché, se la podría usar para intentar y iniciar un ataque contra los equipos que están
usando BranchCache. Los atacantes pueden iniciar un ataque al insertar software
malintencionado en lugar de otros datos. BranchCache mitiga esta amenaza al validar
todo el contenido que usa hashes de bloque encontrados en la información de
contenido. Si un atacante intenta alterar estos datos, se descartan y se reemplazan con
datos válidos de la fuente original.

Una segunda amenaza a los datos almacenados en BranchCache es la divulgación de

información. En modo Caché distribuida, el cliente solo almacena en memoria caché el
contenido que solicitó; sin embargo, esos datos se almacenan en texto no cifrado y
podrían estar en riesgo. Para ayudar a restringir el acceso de la memoria caché al
Servicio BranchCache solamente, la memoria caché local está protegida por permisos
del sistema de archivos que se especifican en una ACL.

Aunque la ACL es eficaz a la hora de impedir que usuarios no autorizados accedan a la

memoria caché, es posible que un usuario con privilegios administrativos obtenga
acceso a la memoria caché al modificar manualmente los permisos que se especifican
en la ACL. BranchCache no ofrece protección contra el uso malintencionado de una
cuenta administrativa.

Los datos que se almacenan en la caché de contenido no están cifrados, por lo tanto si
la fuga de datos representa una inquietud, puede usar tecnologías de cifrado como
BitLocker o el Sistema de cifrado de archivos (EFS) La memoria caché local que usa
BranchCache no aumenta la amenaza de la divulgación de información que soporta el
equipo de una sucursal; la memoria caché solo contiene copias de archivos que residen
sin cifrar en otra parte del disco.

El cifrado de todo el disco es particularmente importante en entornos en los que la

seguridad física del cliente es difícil de garantizar. Por ejemplo, cifrar todo el disco ayuda
a proteger los datos confidenciales de equipos móviles que podrían eliminarse del
entorno de la sucursal.

Seguridad de la memoria caché en el servidor de caché

hospedada
En modo Caché hospedada, la amenaza más importante a la seguridad del servidor de
caché hospedada es la divulgación de información. BranchCache en un entorno de
caché hospedada se comporta de una manera similar al modo Caché distribuida, con un
permiso de sistema de archivos que protege los datos almacenados en caché. La
diferencia es que el servidor de caché hospedada almacena todo el contenido que
solicita cualquier equipo habilitado para BranchCache de una sucursal, y no
simplemente los datos que solicita un solo cliente. Las consecuencias de la intrusión no
autorizada a esta memoria caché podría ser mucho más grave ya que hay muchos más
datos en riesgo.

En un entorno de caché hospedado en el que el servidor de caché hospedado se ejecuta

Windows Server 2008 R2, se recomienda el uso de tecnologías de cifrado como
BitLocker o EFS si alguno de los clientes de la sucursal puede acceder a datos
confidenciales a través del vínculo WAN. También es necesario impedir el acceso físico a
la memoria caché hospedada, ya que el cifrado del disco solo funciona cuando el
equipo está apagado cuando el atacante obtiene acceso físico. Si el equipo está
activado o en modo de suspensión, el cifrado del disco ofrece poca protección.

７ Nota

Los servidores de caché hospedados que ejecutan Windows Server 2016, Windows
Server 2012 R2 o Windows Server 2012 cifrar todos los datos de la memoria caché
de forma predeterminada, por lo que no se requiere el uso de tecnologías de
cifrado adicionales.

Aun si el cliente está configurado en modo Caché hospedada, de todas maneras

guardará los datos localmente en la memoria caché y es posible que desee realizar los
pasos necesarios para proteger la memoria caché local además de la memoria caché del
servidor de caché hospedada.
Comandos de Windows PowerShell y
Shell de red para BranchCache
Artículo • 24/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En Windows Server, puede configurar y administrar BranchCache mediante Windows

PowerShell comandos de Shell de red (Netsh) para BranchCache.

En versiones futuras Windows, es posible que Microsoft quite la funcionalidad Netsh

para BranchCache. Microsoft recomienda realizar la transición a Windows PowerShell si
actualmente usa netsh para configurar y administrar BranchCache y otras tecnologías de
red.

Las referencias de los comandos de Windows PowerShell y Netsh se encuentran en las

siguientes ubicaciones. Aunque ambas referencias de comandos se publicaron para
sistemas operativos antes de Windows Server 2016, estas referencias son precisas para
este sistema operativo.

Comandos Netsh para BranchCache en Windows Server 2008 R2

Cmdlets de BranchCache en Windows PowerShell

 Sugerencia

Para ver una lista de los comandos de Windows PowerShell para BranchCache en el
símbolo del sistema de Windows PowerShell, escriba Get-Command -Module
BranchCache en el símbolo del sistema de Windows PowerShell y, a continuación,
presione ENTRAR.
Guía de implementación de
BranchCache
Artículo • 21/12/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar esta guía para aprender a implementar BranchCache en Windows Server
2016.

Además de este tema, esta guía contiene las secciones siguientes.

Elección de un diseño de BranchCache

Implementar BranchCache

Información general sobre la implementación

de BranchCache
BranchCache es una tecnología de optimización de ancho de banda de red de área
extensa (WAN) que se incluye en algunas ediciones de Windows Server 2016, Windows
Server® 2012 R2, Windows Server® 2012, Windows Server® 2008 R2 y sistemas
operativos cliente de Windows relacionados.

Para mejorar el ancho de banda de la WAN, BranchCache copia el contenido de los

servidores de contenido de la oficina central y lo almacena en la memoria caché de las
sucursales, lo que permite que los equipos cliente de dichas sucursales tengan acceso al
contenido de forma local en lugar de hacerlo a través de la WAN.

En las sucursales, el contenido se almacena en caché en servidores que ejecutan la

característica BranchCache de Windows Server 2016, Windows Server 2012 R2, Windows
Server 2012 o Windows Server 2008 R2: o, si no hay servidores disponibles en la
sucursal, el contenido se almacena en caché en equipos cliente que ejecutan Windows
10 ®, Windows ® 8.1, Windows 8 o Windows 7® .

Una vez que un equipo cliente solicita y recibe contenido de la oficina principal o del
centro de datos en la nube y el contenido se almacena en caché en la sucursal, otros
equipos de la misma sucursal pueden obtener el contenido localmente en lugar de
ponerse en contacto con el servidor de contenido a través del vínculo WAN.

Ventajas de implementar BranchCache

BranchCache almacena en caché el contenido de archivos, web y aplicaciones en
ubicaciones de sucursales, lo que permite a los equipos cliente acceder a los datos
mediante la red de área local (LAN) en lugar de acceder al contenido a través de
conexiones WAN lentas.

BranchCache reduce el tráfico WAN y el tiempo necesario para que los usuarios de
sucursales abran archivos en la red. BranchCache siempre proporciona a los usuarios los
datos más recientes y protege la seguridad del contenido mediante el cifrado de las
memorias caché en el servidor de caché hospedada y en los equipos cliente.

Qué incluye esta guía

Esta guía de implementación permite implementar BranchCache en los siguientes
modos:

Modo Caché distribuida. En este modo, los equipos cliente de sucursal descargan
contenido de los servidores de contenido en la oficina principal o en la nube y, a
continuación, almacena en caché el contenido de otros equipos de la misma
sucursal. El modo Caché distribuida no requiere la existencia de un equipo servidor
en la sucursal.

Modo Caché hospedada. En este modo, los equipos cliente de sucursal descargan
contenido de los servidores de contenido en la oficina principal o en la nube, y un
servidor de caché hospedada recupera el contenido de los clientes. A continuación,
el servidor de caché hospedada almacena en memoria caché el contenido de otros
equipos cliente.

Esta guía también proporciona instrucciones sobre cómo implementar tres tipos de
servidores de contenido. Los servidores de contenido poseen el contenido de origen
que los equipos cliente de la sucursal descargan y se necesitan uno o varios servidores
de contenido para implementar BranchCache en cualquier modo. Los tipos de servidor
de contenido son:

Servidores de contenido basados en servidor web. Estos servidores de contenido

envían contenido a los equipos cliente de BranchCache utilizando los protocolos
HTTP y HTTPS. Estos servidores de contenido deben ejecutar versiones Windows
Server 2016, Windows Server 2012 R2, Windows Server 2012 o Windows Server
2008 R2 que admitan BranchCache y en las que esté instalada la característica
BranchCache.

Servidores de aplicaciones basados en BITS. Estos servidores de contenido envían

contenido a los equipos cliente de BranchCache utilizando el Servicio de
transferencia inteligente en segundo plano (BITS). Estos servidores de contenido
 deben ejecutar versiones Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012 o Windows Server 2008 R2 que admitan BranchCache y en
las que esté instalada la característica BranchCache.

Servidores de contenido basados en servidor de archivos. Estos servidores de

contenido deben ejecutar versiones de Windows Server 2016, Windows Server
2012 R2, Windows Server 2012 o Windows Server 2008 R2 que admitan
BranchCache y en las que esté instalado el rol de servidor Servicios de archivos.
Además, debe estar instalado y configurado el servicio de rol BranchCache para
archivos de red del rol de servidor Servicios de archivo. Estos servidores de
contenido envían contenido a los equipos cliente de BranchCache utilizando el
protocolo SMB (Bloque de mensajes del servidor).

Para obtener más información, vea Versiones del sistema operativo para BranchCache.

Requisitos de implementación de BranchCache

Estos son los requisitos para implementar BranchCache mediante esta guía.

Los servidores de contenido web y de archivos deben ejecutar uno de los

siguientes sistemas operativos para proporcionar funcionalidad de BranchCache:
Windows Server 2016, Windows Server 2012 R2 , Windows Server 2012 o Windows
Server 2008 R2 . Windows 8 y versiones posteriores siguen teniendo las ventajas
de BranchCache al acceder a servidores de contenido que ejecutan Windows
Server 2008 R2, pero no pueden usar las nuevas tecnologías de fragmentación y
hash en Windows Server 2016, Windows Server 2012 R2 y Windows Server 2012.

Los equipos cliente deben ejecutar Windows 10, Windows 8.1 o Windows 8 para
usar el modelo de implementación más reciente y las mejoras de fragmentación y
hash que se introdujeron con Windows Server 2012 .

Los servidores de caché hospedada deben ejecutar Windows Server 2016,

Windows Server 2012 R2 o Windows Server 2012 para usar las mejoras de
implementación y las características de escalado descritas en este documento. Un
equipo que ejecuta uno de estos sistemas operativos configurado como servidor
de caché hospedada puede seguir atienden equipos cliente que ejecutan Windows
7, pero para ello, debe estar equipado con un certificado que sea adecuado para
seguridad de la capa de transporte (TLS), como se describe en la guía de
implementación de Windows Server 2008 R2 y Windows 7 BranchCache.

Se Active Directory dominio para aprovechar las ventajas de la detección

automática directiva de grupo caché hospedada y de almacenamiento en caché,
pero no es necesario un dominio para usar BranchCache. Puede configurar
 equipos individuales mediante Windows PowerShell. Además, no es necesario que
los controladores de dominio ejecuten Windows Server 2012 o posterior para usar
la nueva configuración de BranchCache directiva de grupo; puede importar las
plantillas administrativas de BranchCache en controladores de dominio que
ejecutan sistemas operativos anteriores o puede crear los objetos de directiva de
grupo de forma remota en otros equipos que ejecutan Windows 10. Windows
Server 2016, Windows 8.1, Windows Server 2012 R2, Windows 8 o Windows Server
2012.

Active Directory se usan para limitar el ámbito de los servidores de caché

hospedada que se detectan automáticamente. Para detectar automáticamente un
servidor de caché hospedada, los equipos cliente y servidor deben pertenecer al
mismo sitio. BranchCache está diseñado para tener un impacto mínimo en clientes
y servidores y no impone requisitos de hardware adicionales más allá de los
necesarios para ejecutar sus respectivos sistemas operativos.

Historial y documentación de BranchCache

BranchCache se introdujo por primera vez en Windows 7® y Windows Server® 2008 R2

y se mejoró en Windows Server 2012, Windows 8 y sistemas operativos posteriores.

７ Nota

Si va a implementar BranchCache en sistemas operativos distintos de Windows

Server 2016, están disponibles los siguientes recursos de documentación.

Para obtener información sobre BranchCache en Windows 8, Windows 8.1,

Windows Server 2012 y Windows Server 2012 R2, vea Información general de
BranchCache.
Para obtener información sobre BranchCache en Windows 7 y Windows
Server 2008 R2, vea BranchCache para Windows Server 2008 R2.
Elegir un diseño de BranchCache
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información sobre los modos de BranchCache y
seleccionar los mejores modos para la implementación.

Puede usar esta guía para implementar BranchCache en los siguientes modos y
combinaciones de modo.

Todas las sucursales están configuradas para el modo de caché distribuida.

Todas las sucursales están configuradas para el modo de caché hospedada y

tienen un servidor de caché hospedado en el sitio.

Algunas sucursales están configuradas para el modo de caché distribuida y

algunas sucursales tienen un servidor de caché hospedado en el sitio y están
configurados para el modo de caché hospedada.

En la ilustración siguiente se muestra una instalación en modo dual, con una sucursal
configurada para el modo de caché distribuida y una sucursal configurada para el modo
de caché hospedada.
Antes de implementar BranchCache, seleccione el modo que prefiera para cada sucursal
de su organización.
Implementar BranchCache
Artículo • 29/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En las secciones siguientes se proporciona información sobre la implementación de

BranchCache en modos de caché distribuida y hospedada.

Instalar y configurar servidores de contenido

Implementar servidores de caché hospedada (opcional)

Prehashing and Preloading Content on Hosted Cache Servers (Opcional)

Configuración de equipos cliente de BranchCache

７ Nota

Los procedimientos de esta guía no incluyen instrucciones para los casos en los
que se abre el cuadro de diálogo Control de cuentas de usuario para solicitar
permiso para continuar. Si aparece este cuadro de diálogo en respuesta a sus
acciones mientras realiza los procedimientos de esta guía, haga clic en Continuar.
Instalar y configurar servidores de
contenido
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Al implementar BranchCache en modo de caché distribuida o en modo caché

hospedada, debe implementar uno o varios servidores de contenido en la oficina
principal o en la nube. Los servidores de contenido que son servidores web o servidores
de aplicaciones utilizan la característica BranchCache. Los servidores de contenido que
son servidores de archivos usan BranchCache para el servicio de rol de archivos de red
del rol de servidor Servicios de archivos Windows Server 2016.

Vea los temas siguientes para implementar servidores de contenido.

Instalar servidores de contenido que usan la característica BranchCache

Instalar servidores de contenido de Servicios de archivos

Instalar servidores de contenido que
utilizan la característica BranchCache
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Para implementar servidores de contenido que son servidores web del Protocolo de
transferencia de hipertexto seguro (HTTPS), servidores web del Protocolo de
transferencia de hipertexto (HTTP) y servidores de aplicaciones basados en el servicio de
transferencia inteligente en segundo plano (BITS), como Windows Server Update
Services (WSUS) y Microsoft Endpoint Configuration Manager servidores de sistema de
sitio de distribución de ramas, debe instalar la característica BranchCache, iniciar el
servicio BranchCache y (solo para servidores WSUS) realizar pasos de configuración
adicionales.

Vea los temas siguientes para implementar servidores de contenido.

Instalación de la característica BranchCache

Configuración de Windows Server Update Services de contenido de Windows

Server Update Services (WSUS)
Instalar la característica BranchCache
Artículo • 21/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para instalar la característica BranchCache e iniciar el

servicio BranchCache en un equipo que ejecute Windows Server® 2016, Windows
Server 2012 R2 o Windows Server 2012.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o un grupo equivalente.

Antes de realizar este procedimiento, se recomienda instalar y configurar la aplicación

basada en BITS o el servidor web.

７ Nota

Para realizar este procedimiento mediante Windows PowerShell, ejecute Windows

PowerShell como administrador, escriba los siguientes comandos en el símbolo del
sistema Windows PowerShell y presione ENTRAR.

Install-WindowsFeature BranchCache

Restart-Computer

Para instalar y habilitar la característica BranchCache

1. En el Administrador del servidor, haga clic en Administrar y en Agregar roles y
características. Se abre el asistente para Agregar roles y características. Haga clic
en Next.

2. En Seleccionar tipo de instalación, asegúrese de que está seleccionada la

instalación basada en características o en roles y, a continuación, haga clic en
Siguiente.

3. En Seleccionar servidor de destino, asegúrese de que está seleccionado el

servidor correcto y, a continuación, haga clic en Siguiente.

4. En Seleccionar roles de servidor, haz clic en Siguiente.

 5. En Seleccionar características, haga clic en BranchCachey, a continuación, haga
clic en Siguiente.

6. En Confirmar selecciones de instalación, haga clic en Instalar. En Progreso de la

instalación, continúa la instalación de la característica BranchCache. Una vez
completada la instalación, haga clic en Cerrar.

Después de instalar la característica BranchCache, se habilita el servicio BranchCache,

también denominado PeerDistSvc, y el tipo de inicio es Automático.
Configurar servidores de contenido de
Windows Server Update Services
(WSUS)
Artículo • 24/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Después de instalar la característica BranchCache e iniciar el servicio BranchCache, los

servidores WSUS se deben configurar para almacenar los archivos de actualización en el
equipo local.

Al configurar los servidores WSUS para almacenar los archivos de actualización en el

equipo local, tanto los metadatos de actualización como los archivos de actualización
son descargados por el servidor WSUS y almacenados directamente en él. Esto garantiza
que los equipos cliente de BranchCache reciban los archivos de actualización de
productos de Microsoft del servidor WSUS en lugar de hacerlo directamente desde el
sitio web de Microsoft Update.

Para más información sobre la sincronización de WSUS, consulte Configuración de

sincronizaciones de actualizaciones.
Instalar servidores de contenido de
Servicios de archivo
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Para implementar servidores de contenido que ejecutan el rol de servidor Servicios de

archivo, debe instalar el servicio de rol BranchCache para archivos de red del rol de
servidor Servicios de archivo. Además, debe habilitar BranchCache en recursos
compartidos de archivos según sus requisitos.

Durante la configuración del servidor de contenido, puede permitir la publicación de

contenido de BranchCache para todos los recursos compartidos de archivos, o puede
seleccionar un subconjunto de los recursos compartidos de archivos para su
publicación.

７ Nota

Al implementar un servidor de archivos habilitado para BranchCache o un servidor

web como servidor de contenido, la información de contenido ahora se calcula sin
conexión, mucho antes de que un cliente de BranchCache solicite un archivo.
Debido a esta mejora, no es necesario configurar la publicación hash para los
servidores de contenido, como hizo en la versión anterior de BranchCache.

Esta generación automática de hash proporciona un rendimiento más rápido y un

mayor ahorro de ancho de banda, ya que la información de contenido está lista
para el primer cliente que solicita el contenido y ya se han realizado cálculos.

Vea los temas siguientes para implementar servidores de contenido.

Configurar el rol de servidor de Servicios de archivo

Habilitar la publicación hash para servidores de archivos

Habilitar BranchCache en un recurso compartido de archivos (opcional)

Configurar el rol de servidor de
Servicios de archivo
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede implementar servidores de contenido basados en el servidor de archivos de

BranchCache en equipos que ejecutan Windows Server 2016 y el rol de servidor
Servicios de archivos con el servicio de rol BranchCache para archivos de red instalado.

Para instalar un servidor de contenido de BranchCache en un equipo que aún no

tenga instalados los Servicios de archivos, vea Instalar un nuevo servidor de
archivos como servidor de contenido.

Para instalar un servidor de contenido de BranchCache en un equipo que ya esté

configurado con el rol de servidor Servicios de archivos, vea Configurar un servidor
de archivos existente como servidor de contenido.
Instalar un nuevo servidor de archivos
como servidor de contenido
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para instalar el rol de servidor Servicios de archivos y el
servicio de rol BranchCache para archivos de red en un equipo que Windows Server
2016.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o un grupo equivalente.

７ Nota

Para realizar este procedimiento mediante Windows PowerShell, ejecute Windows

PowerShell como administrador, escriba los siguientes comandos en el símbolo del
sistema Windows PowerShell y presione ENTRAR.

Install-WindowsFeature FS-BranchCache -IncludeManagementTools

Restart-Computer

Para instalar el servicio de rol Desduplicación de datos, escriba el siguiente

comando y presione ENTRAR.

Install-WindowsFeature FS-Data-Deduplication -IncludeManagementTools

Para instalar los Servicios de archivo y el servicio de rol

BranchCache para archivos de red
1. En el Administrador del servidor, haga clic en Administrar y en Agregar roles y
características. Se abre el Asistente para agregar roles y características. En Antes
de comenzar, haga clic en Siguiente.

2. En Seleccionar tipo de instalación, asegúrese de que la instalación basada en

características o en roles está seleccionada y, a continuación, haga clic en
Siguiente.
3. En Seleccionar servidor de destino, asegúrese de que está seleccionado el
servidor correcto y, a continuación, haga clic en Siguiente.

4. En Seleccionar roles de servidor, en Roles, tenga en cuenta que el rol Servicios de

archivos y Storage ya está instalado; haga clic en la flecha situada a la izquierda del
nombre del rol para expandir la selección de servicios de rol y, a continuación,
haga clic en la flecha situada a la izquierda de Servicios de archivo e iSCSI.

5. Active las casillas Servidor de archivos yBranchCache para Archivos de red.

 Sugerencia

También se recomienda activar la casilla Desduplicación de datos.

Haga clic en Next.

6. En Seleccionar características, haga clic en Siguiente.

7. En Confirmar selecciones de instalación, revise las selecciones y, a continuación,

haga clic en Instalar. El panel Progreso de la instalación se muestra durante la
instalación. Una vez completada la instalación, haga clic en Cerrar.
Configurar un servidor de archivos
existente como servidor de contenido
Artículo • 24/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para instalar el servicio de rol BranchCache para
archivos de red del rol de servidor Servicios de archivos en un equipo que ejecute
Windows Server 2016.

） Importante

Si el rol de servidor Servicios de archivo no está instalado todavía, no siga este

procedimiento. En su lugar, vea Instalar un nuevo servidor de archivos como
servidor de contenido.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o un grupo equivalente.

７ Nota

Para realizar este procedimiento mediante Windows PowerShell, ejecute Windows

PowerShell como administrador, escriba los siguientes comandos en el símbolo del
sistema Windows PowerShell y presione ENTRAR.

Install-WindowsFeature FS-BranchCache -IncludeManagementTools

Para instalar el servicio de rol Desduplicación de datos, escriba el siguiente

comando y presione ENTRAR.

Install-WindowsFeature FS-Data-Deduplication -IncludeManagementTools

Para instalar el servicio de rol BranchCache para archivos

de red
1. En el Administrador del servidor, haga clic en Administrar y en Agregar roles y
características. Se abre el asistente para Agregar roles y características. Haga clic
en Next.
2. En Seleccionar tipo de instalación, asegúrese de que está seleccionada la
instalación basada en características o en roles y, a continuación, haga clic en
Siguiente.

3. En Seleccionar servidor de destino, asegúrese de que está seleccionado el

servidor correcto y, a continuación, haga clic en Siguiente.

4. En Seleccionar roles de servidor, en Roles, tenga en cuenta que el rol Servicios de

archivos y Storage ya está instalado; haga clic en la flecha situada a la izquierda del
nombre del rol para expandir la selección de servicios de rol y, a continuación,
haga clic en la flecha situada a la izquierda de Servicios de archivo e iSCSI.

5. Active la casilla branchcache para archivos de red.

 Sugerencia

Si aún no lo ha hecho, se recomienda activar también la casilla Desduplicación

de datos.

Haga clic en Next.

6. En Seleccionar características, haga clic en Siguiente.

7. En Confirmar selecciones de instalación, revise las selecciones y, a continuación,

haga clic en Instalar. El panel Progreso de la instalación se muestra durante la
instalación. Una vez completada la instalación, haga clic en Cerrar.
Habilitar la publicación de hash para
servidores de archivos
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede habilitar la publicación de hash para BranchCache en un servidor de archivos o en

varios servidores de archivos.

Para habilitar la publicación de hash en un servidor de archivos mediante el equipo

local directiva de grupo, vea Habilitar la publicación hash para servidores de
archivos miembros que no son de dominio.

Para habilitar la publicación de hash en varios servidores de archivos mediante

dominios directiva de grupo, vea Habilitar la publicación hash para servidores de
archivos de miembro de dominio.

７ Nota

Si tiene varios servidores de archivos y desea habilitar la publicación hash por

recurso compartido, en lugar de habilitar la publicación hash para todos los
recursos compartidos, puede usar las instrucciones del tema Habilitar publicación
hash para servidores de archivos miembros que no son de dominio.
Habilitar la publicación de hash para
servidores de archivos que no son
miembros del dominio
Artículo • 29/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para configurar la publicación hash para BranchCache
mediante el equipo local directiva de grupo en un servidor de archivos que ejecuta
Windows Server 2016 con el servicio de rol BranchCache para archivos de red del rol de
servidor Servicios de archivos instalado.

Este procedimiento está previsto para su uso en un servidor de archivos que no sea
miembro del dominio. Si realiza este procedimiento en un servidor de archivos que es
miembro del dominio y también configura BranchCache utilizando la directiva de grupo
de dominio, la configuración de esta directiva invalida la configuración de la directiva de
grupo local.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o un grupo equivalente.

７ Nota

Si tiene uno o más servidores de archivos que son miembros del dominio, puede
agregarlos a una unidad organizativa (OU) en Servicios de dominio de Active
Directory y utilizar después la directiva de grupo para configurar de una vez la
publicación de hash para todos los servidores de archivos, en lugar de configurar
individualmente cada servidor de archivos. Para obtener más información, vea
Habilitar la publicación hash para servidores de archivos de miembro de
dominio.

Para habilitar la publicación de hash para un servidor de

archivos
1. Abra Windows PowerShell, escriba mmv y presione ENTRAR. Se abrirá Microsoft
Management Console (MMC).
2. En MMC, en el menú Archivo, haga clic en Agregar o quitar complemento. Se
abre el cuadro de diálogo Agregar o quitar complementos.

3. En Agregar o quitar complementos, en Complementos disponibles, haga doble

clic en Editor de objetos de directiva de grupo. Se abre el Asistente para directivas
de grupo con el objeto Equipo local seleccionado. Haz clic en Finalizar y, a
continuación, en Aceptar.

4. En la Editor de directivas de grupo local MMC, expanda la siguiente ruta de acceso:

Directiva de equipo local, Configuración del equipo, Plantillas administrativas,
Red, Servidor Lanman. Haga clic en Servidor Lanman.

5. En el panel de detalles, haga doble clic en Publicación de hash para BranchCache.

Se abre el cuadro de diálogo Publicación de hash para BranchCache.

6. En el cuadro de diálogo Publicación de hash para BranchCache, haga clic en

Habilitado.

7. En Opciones, haga clic en Permitir publicación hash para todas las carpetas
compartidas y, a continuación, haga clic en una de las siguientes opciones:

a. Para habilitar la publicación hash para todas las carpetas compartidas de este
equipo, haga clic en Permitir publicación hash para todas las carpetas
compartidas.

b. Para habilitar la publicación de hash solamente para las carpetas compartidas

para las que se ha habilitado BranchCache, haga clic en Permitir la publicación
de hash solo para carpetas compartidas en las que BranchCache está
habilitado.

c. Para no permitir la publicación de hash para todas las carpetas compartidas del
equipo aunque se haya habilitado BranchCache en los recursos compartidos de
archivos, haga clic en No permitir la publicación de hash en ninguna carpeta
compartida.

8. Haga clic en OK.

Habilitar la publicación de hash para
servidores de archivos que son
miembros del dominio
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Cuando se usa Active Directory Domain Services (AD DS), puede usar el dominio
directiva de grupo para habilitar la publicación de hash de BranchCache para varios
servidores de archivos. Para ello, debe crear una unidad organizativa (OU), agregar
servidores de archivos a la unidad organizativa, crear una publicación hash de
BranchCache directiva de grupo Object (GPO) y, a continuación, configurar el GPO.

Vea los temas siguientes para habilitar la publicación de hash para varios servidores de
archivos.

Crear la unidad organizativa para servidores de archivos de BranchCache

Mover servidores de archivos a la unidad organizativa servidores de archivos de

BranchCache

Crear el objeto de directiva de grupo Publicación de hash para BranchCache

Configurar la publicación hash de BranchCache directiva de grupo objeto

Crear la unidad organizativa para
servidores de archivos de BranchCache
Artículo • 29/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede utilizar este procedimiento para crear una unidad organizativa (OU) en Servicios
de dominio de Active Directory (AD DS) para servidores de archivos de BranchCache.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo Admins.

del dominio o grupo equivalente.

Para crear la unidad organizativa para servidores de

archivos de BranchCache
1. En un equipo donde AD DS esté instalado, en Administrador del servidor, haga clic
en Herramientasy , a continuación, haga clic en Usuarios y equipos de Active
Directory. Se abre la Consola de usuarios y equipos de Active Directory.

2. En la Consola de usuarios y equipos de Active Directory, haga clic con el botón

secundario en el dominio al que desea agregar una unidad organizativa. Por
ejemplo, si el nombre del dominio es [Link], haga clic con el botón
secundario en [Link]. Seleccione Nuevo y haga clic en Unidad organizativa.
Se abre el cuadro de diálogo Nuevo objeto - Unidad organizativa .

3. En el cuadro de diálogo Nuevo objeto - Unidad organizativa , en Nombre, escriba

un nombre para la nueva unidad organizativa. Por ejemplo, si desea asignar a la
unidad organizativa el nombre Servidores de archivos de BranchCache, escriba
Servidores de archivos de BranchCache y, a continuación, haga clic en Aceptar.
Mover servidores de archivos a la
unidad organizativa para servidores de
archivos de BranchCache
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede utilizar este procedimiento para agregar servidores de archivos de BranchCache a

una unidad organizativa (OU) en Servicios de dominio de Active Directory (AD DS).

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo Admins.

del dominio o grupo equivalente.

７ Nota

Debe crear una unidad organizativa para servidores de archivos de BranchCache en

la Consola de usuarios y equipos de Active Directory antes de agregar cuentas de
equipo a la unidad organizativa con este procedimiento. Para obtener más
información, vea Crear la unidad organizativa de servidores de archivos de
BranchCache.

Para mover servidores de archivos a la unidad

organizativa para servidores de archivos de BranchCache
1. En un equipo donde AD DS esté instalado, en Administrador del servidor, haga clic
en Herramientasy , a continuación, haga clic en Usuarios y equipos de Active
Directory. Se abre la Consola de usuarios y equipos de Active Directory.

2. En la consola de usuarios y equipos de Active Directory, busque la cuenta de

equipo para un servidor de archivos de BranchCache, haga clic con el botón
primario para seleccionar la cuenta y, a continuación, arrastre y coloque la cuenta
de equipo en la unidad organizativa para servidores de archivos de BranchCache
que creó previamente. Por ejemplo, si creó anteriormente una unidad organizativa
denominada Servidores de archivos branchCache, arrastre y coloque la cuenta de
equipo en la unidad organizativa de servidores de archivos de BranchCache .

3. Repita el paso anterior para cada servidor de archivos de BranchCache en el

dominio que desea mover a la unidad organizativa.
Crear el objeto de directiva de grupo
Publicación de hash para BranchCache
Artículo • 24/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para crear la publicación hash de BranchCache directiva
de grupo object (GPO).

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo Admins.

del dominio o grupo equivalente.

７ Nota

Antes de realizar este procedimiento, debe crear la unidad organizativa para

servidores de archivos de BranchCache y mover los servidores de archivos a la
unidad organizativa. Para obtener más información, vea Habilitar la publicación
hash para servidores de archivos de miembro de dominio.

Para crear la publicación de hash de BranchCache

directiva de grupo objeto
1. Abra Windows PowerShell, escriba mmv y presione ENTRAR. Se abrirá Microsoft
Management Console (MMC).

2. En MMC, en el menú Archivo, haga clic en Agregar o quitar complemento. Se

abre el cuadro de diálogo Agregar o quitar complementos.

3. En Agregar o quitar complementos, en Complementos disponibles, haga doble

clic en Administración de directivas de grupo y, a continuación, haga clic en
Aceptar.

4. En MMC de Administración de directivas de grupo, expanda la ruta de acceso a la

unidad organizativa para servidores de archivos de BranchCache que creó
previamente. Por ejemplo, si el bosque se denomina [Link], el dominio se
denomina [Link] y la unidad organizativa se denomina Servidores de
archivos de BranchCache, expanda la siguiente ruta de acceso: administración de
directiva de grupo, bosque : [Link], dominios, [Link], servidores
de archivos de BranchCache.
5. Haga clic con el botón derecho en Servidores de archivos de BranchCache y, a
continuación, haga clic en Crear un GPO en este dominio y vincularlo aquí. Se
abre el cuadro de diálogo Nuevo GPO. En Nombre, escriba un nombre para el
nuevo GPO. Por ejemplo, si desea que el nombre del objeto sea Publicación de
hash para BranchCache, escriba Publicación de hash para BranchCache. Haga clic
en OK.
Configurar el objeto de directiva de
grupo Publicación de hash para
BranchCache
Artículo • 29/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para configurar el objeto directiva de grupo (GPO) de
publicación hash de BranchCache para que todos los servidores de archivos que agregó
a la unidad organizativa tengan aplicada la misma configuración de directiva de
publicación hash.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo Admins.

del dominio o grupo equivalente.

７ Nota

Antes de realizar este procedimiento, debe crear la unidad organizativa de

servidores de archivos de BranchCache, mover servidores de archivos a la unidad
organizativa y crear el GPO de publicación de hash de BranchCache. Para obtener
más información, vea Habilitar la publicación hash para servidores de archivos de
miembro de dominio.

Para configurar la publicación hash de BranchCache

directiva de grupo Objeto
1. Ejecute Windows PowerShell administrador, escriba mmc y presione ENTRAR. Se
abrirá Microsoft Management Console (MMC).

2. En MMC, en el menú Archivo, haga clic en Agregar o quitar complemento. Se

abre el cuadro de diálogo Agregar o quitar complementos.

3. En Agregar o quitar complementos, en Complementos disponibles, haga doble

clic en Administración de directivas de grupo y, a continuación, haga clic en
Aceptar.

4. En MMC de Administración de directivas de grupo, expanda la ruta de acceso al

objeto de directiva de grupo Publicación de hash para BranchCache que creó
 previamente. Por ejemplo, si el bosque se denomina [Link], el dominio se
denomina [Link] y el GPO se denomina BranchCache Hash Publication,
expanda la siguiente ruta de acceso: administración de directiva de grupo,
bosque : [Link], dominios, [Link], objetos directiva de grupo,
publicación hash de BranchCache.

5. Haga clic con el botón secundario en el objeto de directiva de grupo Publicación

de hash para BranchCache y haga clic en Editar. Se abre Editor de administración
de directivas de grupo consola de .

6. En la Editor de administración de directivas de grupo, expanda la siguiente ruta de

acceso: Configuración del equipo, Directivas, Plantillas administrativas, Red,
Servidor Lanman.

7. En la consola de Editor de administración de directivas de grupo, haga clic en

Servidor Lanman. En el panel de detalles, haga doble clic en Publicación de hash
para BranchCache. Se abre el cuadro de diálogo Publicación de hash para
BranchCache.

8. En el cuadro de diálogo Publicación de hash para BranchCache, haga clic en

Habilitado.

9. En Opciones, haga clic en Permitir publicación hash para todas las carpetas
compartidas y, a continuación, haga clic en una de las siguientes opciones:

a. Para habilitar la publicación hash para todas las carpetas compartidas para
todos los servidores de archivos que agregó a la unidad organizativa, haga clic
en Permitir publicación hash para todas las carpetas compartidas.

b. Para habilitar la publicación de hash solamente para las carpetas compartidas

para las que se ha habilitado BranchCache, haga clic en Permitir la publicación
de hash solo para carpetas compartidas en las que BranchCache está
habilitado.

c. Para no permitir la publicación de hash para todas las carpetas compartidas del
equipo aunque se haya habilitado BranchCache en los recursos compartidos de
archivos, haga clic en No permitir la publicación de hash en ninguna carpeta
compartida.

10. Haga clic en OK.

７ Nota
En la mayoría de los casos, debe guardar la consola MMC y actualizar la vista para
que se muestren los cambios de configuración realizados.
Habilitar BranchCache en un recurso
compartido de archivos (opcional)
Artículo • 29/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede utilizar este procedimiento para habilitar BranchCache en un recurso compartido

de archivos.

） Importante

No es necesario realizar este procedimiento si configura la publicación hash con el

valor Permitir publicación hash para todas las carpetas compartidas.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o un grupo equivalente.

Para habilitar BranchCache en un recurso compartido de

archivos
1. Abra Windows PowerShell, escriba mmv y presione ENTRAR. Se abrirá Microsoft
Management Console (MMC).

2. En MMC, en el menú Archivo, haga clic en Agregar o quitar complemento. Se

abre el cuadro de diálogo Agregar o quitar complementos.

3. En Agregar o quitar complementos, en Complementos disponibles, haga doble

clic en Carpetas compartidas. Se abre el Asistente para carpetas compartidas con
el objeto Equipo local seleccionado. Configure la vista que prefiera, haga clic en
Finalizary, a continuación, haga clic en Aceptar.

4. Haga doble clic en Carpetas compartidas (local) y, a continuación, haga clic en

Recursos compartidos.

5. En el panel de detalles, haga clic con el botón derecho en un recurso compartido y,

a continuación, haga clic en Propiedades. Se abre el cuadro de diálogo
Propiedades del recurso compartido.

6. En el cuadro de diálogo Propiedades , en la pestaña General , haga clic en Sin

conexión Configuración. Se abre el cuadro Configuración sin conexión.
7. Asegúrese de que solo los archivos y programas que especifiquen los usuarios
estén disponibles sin conexión y, a continuación, haga clic en Habilitar
BranchCache.

8. Haga clic en Aceptar dos veces.

Implementación de servidores de caché
hospedada (opcional)
Artículo • 29/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para instalar y configurar servidores de caché

hospedada de BranchCache que se encuentran en sucursales donde desea implementar
el modo de caché hospedada de BranchCache. Con BranchCache en Windows Server
2016, puede implementar varios servidores de caché hospedada en una sucursal.

） Importante

Este paso es opcional porque el modo de caché distribuida no requiere un equipo

de servidor de caché hospedada en sucursales. Si no planea implementar el modo
de caché hospedada en ninguna sucursal, no es necesario implementar un servidor
de caché hospedada y no es necesario realizar los pasos de este procedimiento.

Debe ser miembro de Administradores o equivalente para realizar este procedimiento.

Para instalar y configurar un servidor de caché

hospedada
1. En el equipo que desea configurar como servidor de caché hospedada, ejecute el
siguiente comando en un símbolo del sistema Windows PowerShell para instalar la
característica BranchCache.

Install-WindowsFeature BranchCache -IncludeManagementTools

2. Configure el equipo como un servidor de caché hospedada mediante uno de los

siguientes comandos:

Para configurar un equipo que no está unido a un dominio como servidor de

caché hospedada, escriba el siguiente comando en el símbolo del sistema
Windows PowerShell y presione ENTRAR.

Enable-BCHostedServer

Para configurar un equipo unido a un dominio como servidor de caché

hospedada y registrar un punto de conexión de servicio en Active Directory
 para la detección automática de servidores de caché hospedada por equipos
cliente, escriba el siguiente comando en el símbolo del sistema de Windows
PowerShell y presione ENTRAR.

Enable-BCHostedServer -RegisterSCP

3. Para comprobar la configuración correcta del servidor de caché hospedada, escriba

el siguiente comando en el símbolo del sistema Windows PowerShell y presione
ENTRAR.

Get-BCStatus

７ Nota

Después de ejecutar este comando, en la sección

HostedCacheServerConfiguration, el valor de HostedCacheServerIsEnabled
es True. Si configuró un servidor de caché hospedada unido a un dominio
para registrar un punto de conexión de servicio (SCP) en Active Directory, el
valor de HostedCacheScpRegistrationEnabled es True.
Aplicación de hash previo y carga previa
de contenido en servidores de caché
hospedada (opcional)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para forzar la creación de información de contenido

(también denominada hashes) en servidores web y de archivos habilitados para
BranchCache. También puede recopilar los datos de los servidores web y de archivos en
paquetes que se pueden transferir a servidores de caché hospedados remotos. Esto
proporciona la capacidad de cargar previamente contenido en servidores de caché
hospedada remota para que los datos estén disponibles para el primer acceso de
cliente.

Debe ser miembro de Administradores o equivalente para realizar este procedimiento.

Para prehash content and preload the content on hosted

cache servers (Para prehash content and preload the
content on hosted cache servers) (Para prehash content
and preload the content on hosted cache
1. Inicie sesión en el archivo o servidor web que contiene los datos que desea cargar
previamente e identifique las carpetas y los archivos que desea cargar en uno o
varios servidores de caché hospedados remotos.

2. Ejecute Windows PowerShell como administrador. Para cada carpeta y archivo,

Publish-BCFileContent Publish-BCWebContent ejecute el comando o el comando,

en función del tipo de servidor de contenido, para desencadenar la generación de

hash y agregar datos a un paquete de datos.

3. Después de agregar todos los datos al paquete de datos, Export-BCCachePackage

exporte mediante el comando para generar un archivo de paquete de datos.

4. Mueva el archivo de paquete de datos a los servidores de caché hospedados

remotamente mediante la tecnología de transferencia de archivos que elija. FTP,
SMB, HTTP, DVD y discos duros portátiles son transportes viables.
5. Importe el archivo de paquete de datos en los servidores de caché hospedada
remota mediante el Import-BCCachePackage comando .
Configuración de equipos cliente de
BranchCache
Artículo • 29/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar los temas siguientes para configurar equipos cliente que no son miembros
del dominio y miembros del dominio como clientes de caché distribuida de
BranchCache o en modo de caché hospedada.

Usar directiva de grupo para configurar equipos cliente miembros de dominio

Usar Windows PowerShell configurar equipos cliente que no son miembros del
dominio

Configuración de reglas de firewall para miembros que no son de dominio para

permitir el tráfico de BranchCache

Comprobar el equipo cliente Configuración

Usar directiva de grupo para configurar
equipos cliente miembros de dominio
Artículo • 21/12/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En esta sección, creará un objeto directiva de grupo para todos los equipos de la
organización, configurará equipos cliente miembro de dominio con modo de caché
distribuida o modo de caché hospedada y configurará Windows Firewall con seguridad
avanzada para permitir el tráfico de BranchCache.

Esta sección contiene los procedimientos siguientes.

1. Para crear un objeto directiva de grupo y configurar los modos de BranchCache

2. Para configurar el firewall Windows con reglas de tráfico de entrada de seguridad

avanzada

3. Para configurar el firewall Windows con reglas de tráfico saliente de seguridad

avanzada

 Sugerencia

En el procedimiento siguiente, se le indica que cree un objeto directiva de grupo en

la directiva de dominio predeterminada; sin embargo, puede crear el objeto en una
unidad organizativa (OU) u otro contenedor adecuado para la implementación.

Debe ser miembro de administradores de dominio o equivalente para realizar estos

procedimientos.

Para crear un objeto directiva de grupo y

configurar los modos de BranchCache
1. En un equipo en el que esté instalado Active Directory Domain Services de
servidor, en Administrador del servidor, haga clic en Herramientasy , a
continuación, haga clic directiva de grupo Administración. Se abre la Consola de
administración de directivas de grupo.
 2. En la consola de administración de directiva de grupo, expanda la siguiente ruta de
acceso: Bosque:[Link], Dominios, [Link], objetos directiva de grupo,
donde [Link] es el nombre del dominio donde se encuentran las cuentas de
equipo cliente de BranchCache que desea configurar.

3. Haga clic con el botón secundario en Objetos de directiva de grupo y, a

continuación, haga clic en Nuevo. Se abre el cuadro de diálogo Nuevo GPO. En
Nombre, escriba un nombre para el nuevo objeto directiva de grupo (GPO). Por
ejemplo, si desea asignar al objeto el nombre Equipos cliente de BranchCache,
escriba Equipos cliente de BranchCache. Haga clic en OK.

4. En la Consola de administración de directivas de grupo, asegúrese de que esté

seleccionada la opción Objetos de directiva de grupo y, en el panel de detalles,
haga clic con el botón secundario en el objeto de directiva de grupo que acaba de
crear. Por ejemplo, si ha asignado al objeto de directiva de grupo el nombre
Equipos cliente de BranchCache, haga clic con el botón secundario en Equipos
cliente de BranchCache. Haga clic en Editar. Se abre Editor de administración de
directivas de grupo consola de .

5. En la consola Editor de administración de directivas de grupo, expanda la siguiente

ruta de acceso: Configuración del equipo, Directivas, Plantillas administrativas:
Definiciones de directiva (archivos ADMX) recuperadas del equipo local, Red,
BranchCache.

6. Haga clic en BranchCache y, a continuación, en el panel de detalles, haga doble

clic en Activar BranchCache. Se abre el cuadro de diálogo configuración de
directiva.

7. En el cuadro de diálogo Activar BranchCache, haga clic en Habilitado y, a

continuación, en Aceptar.

8. Para habilitar el modo de caché distribuida de BranchCache, en el panel de

detalles, haga doble clic en Establecer el modo caché distribuida de BranchCache.
Se abre el cuadro de diálogo configuración de directiva.

9. En el cuadro de diálogo Establecer el modo Caché distribuida de BranchCache,

haga clic en Habilitado y, a continuación, haga clic en Aceptar.

10. Si tiene una o varias sucursales en las que va a implementar BranchCache en modo
de caché hospedada y ha implementado servidores de caché hospedada en esas
oficinas, haga doble clic en Habilitar la detección automática de caché hospedada
por punto de conexión de servicio. Se abre el cuadro de diálogo configuración de
directiva.
11. En el cuadro de diálogo Habilitar detección automática de caché hospedada por
punto de conexión de servicio , haga clic en Habilitadoy, a continuación, haga clic
en Aceptar.

７ Nota

Al habilitar la configuración de directiva Establecer caché distribuida de

BranchCache y Habilitar la detección automática de caché hospedada por
punto de conexión de servicio, los equipos cliente operan en modo de caché
distribuida de BranchCache a menos que encuentren un servidor de caché
hospedada en la sucursal, momento en el que funcionan en modo caché
hospedada.

12. Use los procedimientos siguientes para configurar las opciones de firewall en los
equipos cliente mediante directiva de grupo.

Para configurar el firewall Windows con reglas

de tráfico de entrada de seguridad avanzada
1. En la consola de administración de directiva de grupo, expanda la siguiente ruta de
acceso: Bosque:[Link], Dominios, [Link], objetos directiva de grupo,
donde [Link] es el nombre del dominio donde se encuentran las cuentas de
equipo cliente de BranchCache que desea configurar.

2. En la Consola de administración de directivas de grupo, asegúrese de que esté

seleccionada la opción Objetos de directiva de grupo y, en el panel de detalles,
haga clic con el botón secundario en el objeto de directiva de grupo Equipos
cliente de BranchCache creado anteriormente. Por ejemplo, si ha asignado al
objeto de directiva de grupo el nombre Equipos cliente de BranchCache, haga clic
con el botón secundario en Equipos cliente de BranchCache. Haga clic en Editar.
Se abre Editor de administración de directivas de grupo consola de .

3. En la consola Editor de administración de directivas de grupo, expanda la siguiente

ruta de acceso: Configuración del equipo, Directivas, Windows Configuración,
Seguridad Configuración, Firewall de Windows con seguridad avanzada, Firewall
de Windows con seguridad avanzada - LDAP, Entrante Reglas.

4. Haga clic con el botón secundario en Reglas de entrada y, a continuación, en

Nueva regla. Se abre el Asistente para nueva regla de entrada.
 5. En Tipo de regla, haga clic en Predefinido, expanda la lista de opciones y, a
continuación, haga clic en BranchCache - Content Retrieval (Usa HTTP). Haga clic
en Next.

6. En Reglas predefinidas, haga clic en Siguiente.

7. En Acción, asegúrese de que esté seleccionada la opción Permitir la conexión y, a

continuación, haga clic en Finalizar.

） Importante

Debe seleccionar la opción Permitir la conexión para que el cliente de

BranchCache pueda recibir tráfico en este puerto.

8. Para crear la excepción de firewall para WS-Discovery, vuelva a hacer clic con el
botón secundario en Reglas de entrada y, a continuación, haga clic en Nueva
regla. Se abre el Asistente para nueva regla de entrada.

9. En Tipo de regla, haga clic en Predefinido, expanda la lista de opciones y, a

continuación, haga clic en BranchCache : detección del mismo nivel (usa WSD).
Haga clic en Next.

10. En Reglas predefinidas, haga clic en Siguiente.

11. En Acción, asegúrese de que esté seleccionada la opción Permitir la conexión y, a

continuación, haga clic en Finalizar.

） Importante

Debe seleccionar la opción Permitir la conexión para que el cliente de

BranchCache pueda recibir tráfico en este puerto.

Para configurar el firewall Windows con reglas

de tráfico saliente de seguridad avanzada
1. En la consola de Editor de administración de directivas de grupo, haga clic con el
botón secundario en Reglas de salida y, a continuación, haga clic en Nueva regla.
Se abre el Asistente para nueva regla de salida.

2. En Tipo de regla, haga clic en Predefinido, expanda la lista de opciones y, a

continuación, haga clic en BranchCache - Content Retrieval (Usa HTTP). Haga clic
 en Next.

3. En Reglas predefinidas, haga clic en Siguiente.

4. En Acción, asegúrese de que esté seleccionada la opción Permitir la conexión y, a

continuación, haga clic en Finalizar.

） Importante

Debe seleccionar la opción Permitir la conexión para que el cliente de

BranchCache pueda enviar tráfico en este puerto.

5. Para crear la excepción de firewall para WS-Discovery, vuelva a hacer clic con el
botón secundario en Reglas de salida y, a continuación, haga clic en Nueva regla.
Se abre el Asistente para nueva regla de salida.

6. En Tipo de regla, haga clic en Predefinido, expanda la lista de opciones y, a

continuación, haga clic en BranchCache : detección del mismo nivel (usa WSD).
Haga clic en Next.

7. En Reglas predefinidas, haga clic en Siguiente.

8. En Acción, asegúrese de que esté seleccionada la opción Permitir la conexión y, a

continuación, haga clic en Finalizar.

） Importante

Debe seleccionar la opción Permitir la conexión para que el cliente de

BranchCache pueda enviar tráfico en este puerto.
Usar Windows PowerShell para
configurar equipos cliente que no son
miembros del dominio
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para configurar manualmente un equipo cliente de

BranchCache para el modo de caché distribuida o el modo de caché hospedada.

７ Nota

Si ha configurado equipos cliente de BranchCache utilizando la directiva de grupo,

la configuración de la directiva de grupo invalida cualquier configuración manual
de equipos cliente a los que se aplican las directivas.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o un grupo equivalente.

Para habilitar el modo de caché distribuida o hospedada

de BranchCache
1. En el equipo cliente de BranchCache que desea configurar, ejecute Windows
PowerShell como administrador y, a continuación, realice una de las siguientes
acciones.

Para configurar el equipo cliente para el modo de caché distribuida de

BranchCache, escriba el siguiente comando y presione ENTRAR.

Enable-BCDistributed

Para configurar el equipo cliente para el modo de caché hospedada de

BranchCache, escriba el siguiente comando y presione ENTRAR.

Enable-BCHostedClient

 Sugerencia
Si desea especificar los servidores de caché hospedada disponibles, use
-ServerNames el parámetro con una lista separada por comas de los
servidores de caché hospedada como valor de parámetro. Por ejemplo,
si tiene dos servidores de caché hospedados denominados HCS1 y
HCS2, configure el equipo cliente para el modo de caché hospedada con
el siguiente comando.

Enable-BCHostedClient -ServerNames HCS1,HCS2

Configurar reglas de firewall para que
los miembros que no son del dominio
permitan el tráfico de BranchCache
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede utilizar la información de este tema configurar productos de firewall de terceros y

configurar manualmente un equipo cliente con reglas de firewall que permitan la
ejecución de BranchCache en modo Caché distribuida.

７ Nota

Si ha configurado equipos cliente de BranchCache utilizando la directiva de

grupo, la configuración de la directiva de grupo invalida cualquier
configuración manual de equipos cliente a los que se aplican las directivas.
Si ha implementado BranchCache con DirectAccess, puede utilizar la
configuración que se incluye en este tema para configurar las reglas IPsec de
forma que permitan el tráfico de BranchCache.

El requisito mínimo para realizar estos cambios de configuración es la pertenencia al

grupo Administradores o un grupo equivalente.

[MS-PCCRD]: Almacenamiento en caché de

contenido del mismo nivel y protocolo de
detección de recuperación
Los clientes de caché distribuida deben permitir el tráfico entrante y saliente de MS-
PCCRD, que se transporta en el protocolo de detección dinámica de servicios web (WS-
Discovery).

La configuración del firewall debe permitir el tráfico de multidifusión además del tráfico
entrante y saliente. Puede utilizar la configuración siguiente para configurar las
excepciones de firewall para el modo Caché distribuida.

Multidifusión IPv4: [Link]

Multidifusión IPv6: FF02::C

Tráfico entrante: puerto local: 3702, puerto remoto: efímero

Tráfico saliente: puerto local: efímero, puerto remoto: 3702

Programa: %systemroot%\system32\[Link] (Servicio BranchCache [PeerDistSvc])

[MS-PCCRR]: Recuperación y almacenamiento

en caché de contenido del mismo nivel:
protocolo de recuperación
Los clientes de caché distribuida deben permitir el tráfico entrante y saliente de MS-
PCCRR, que se transporta en el protocolo HTTP 1.1 que se documenta en la solicitud de
comentarios (RFC) 2616.

La configuración del firewall debe permitir el tráfico entrante y saliente. Puede utilizar la
configuración siguiente para configurar las excepciones de firewall para el modo Caché
distribuida.

Tráfico entrante: puerto local: 80, puerto remoto: efímero

Tráfico saliente: puerto local: efímero, puerto remoto: 80

Comprobar el equipo cliente
Configuración
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para comprobar que el equipo cliente está configurado
correctamente para BranchCache.

７ Nota

Este procedimiento incluye los pasos para actualizar manualmente directiva de

grupo y para reiniciar el servicio BranchCache. No es necesario realizar estas
acciones si reinicia el equipo, ya que se producirán automáticamente en esta
circunstancia.

Debe ser miembro de Administradores o equivalente para realizar este procedimiento.

Para comprobar la configuración del equipo cliente de

BranchCache
1. Para actualizar directiva de grupo en el equipo cliente cuya configuración de
BranchCache desea comprobar, ejecute Windows PowerShell como administrador,
escriba el siguiente comando y presione ENTRAR.

gpupdate /force

2. Para los equipos cliente que están configurados en modo de caché hospedada y
están configurados para detectar automáticamente servidores de caché
hospedada por punto de conexión de servicio, ejecute los siguientes comandos
para detener y reiniciar el servicio BranchCache.

net stop peerdistsvc

net start peerdistsvc

3. Inspeccione el modo operativo actual de BranchCache mediante la ejecución del

comando siguiente.

Get-BCStatus
4. En Windows PowerShell, revise la salida del comando Get-BCStatus.

El valor de BranchCacheIsEnabled debe ser True.

En ClientSettings, el valor de CurrentClientMode debe ser DistributedClient o

HostedCacheClient, en función del modo que haya configurado con esta guía.

En ClientSettings, si configuró el modo de caché hospedada y proporcionó los

nombres de los servidores de caché hospedada durante la configuración, o si el
cliente ha ubicado automáticamente servidores de caché hospedada mediante
puntos de conexión de servicio, HostedCacheServerList debe tener un valor que
sea el mismo que el nombre o los nombres de los servidores de caché hospedada.
Por ejemplo, si el servidor de caché hospedada se denomina HCS1 y el dominio
[Link], el valor de HostedCacheServerListes [Link].

5. Si alguna de las configuraciones de BranchCache enumeradas anteriormente no

tiene los valores correctos, siga los pasos de esta guía para comprobar la
configuración de directiva de equipo local o directiva de grupo, así como las
excepciones de firewall que configuró, y asegúrese de que son correctas. Además,
reinicie el equipo o siga los pasos descritos en este procedimiento para actualizar
directiva de grupo y reiniciar el servicio BranchCache.
DirectAccess
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puedes usar este tema para obtener una breve descripción general de DirectAccess,
incluidos los sistemas operativos cliente y servidor que admiten DirectAccess y para
vínculos a documentación adicional de DirectAccess para Windows Server.

７ Nota

Además de este tema, está disponible la siguiente documentación de DirectAccess.

Rutas de acceso de implementación de DirectAccess en Windows Server

Requisitos previos para la implementación de DirectAccess
Configuraciones no compatibles de DirectAccess
Guías del laboratorio de pruebas de DirectAccess
Problemas conocidos de DirectAccess
Planeamiento de capacidad de DirectAccess
Unión a dominio sin conexión de DirectAccess
Solución de problemas de DirectAccess
Implementación de un solo servidor de DirectAccess con el Asistente para
introducción
Implementar un único servidor de DirectAccess con configuración avanzada
Agregar DirectAccess a una implementación de acceso remoto existente
(VPN)

DirectAccess permite la conectividad de los usuarios remotos a los recursos de red de la

organización sin necesidad de conexiones tradicionales de red privada virtual (VPN).
Con las conexiones de DirectAccess, los equipos cliente remotos siempre están
conectados a su organización: no es necesario que los usuarios remotos inicien y
detengan las conexiones, como se requiere con las conexiones VPN. Además, los
administradores de TI pueden administrar equipos cliente de DirectAccess siempre que
se ejecuten y conectados a Internet.

） Importante
 No intente implementar el acceso remoto en una máquina virtual (VM) en
Microsoft Azure. No se admite el uso del acceso remoto en Microsoft Azure. No se
puede usar el acceso remoto en una máquina virtual de Azure para implementar
VPN, DirectAccess ni ninguna otra característica de acceso remoto en Windows
Server 2016 o versiones anteriores de Windows Server. Para más información,
consulte Compatibilidad de software de servidor de Microsoft con máquinas
virtuales de Microsoft Azure .

DirectAccess solo admite clientes unidos a un dominio que incluyen compatibilidad con
el sistema operativo para DirectAccess.

Los siguientes sistemas operativos cliente admiten DirectAccess.

Windows 11 Enterprise

Windows 10 Enterprise

Windows 10 Enterprise rama de mantenimiento a largo plazo (LTSB) de Windows

10 Enterprise 2015

Windows 8.1 Enterprise

Sistema de nombres de dominio (DNS)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

El Sistema de nombres de dominio (DNS) es uno de los conjuntos de protocolos

estándar del sector que componen TCP/IP, y juntos el cliente DNS y el servidor DNS
proporcionan servicios de resolución de nombres de asignación de nombres de equipo
a IP a equipos y usuarios.

７ Nota

Además de este tema, está disponible el siguiente contenido DNS.

Novedades de Cliente DNS

Novedades del servidor DNS
Guía de escenarios de directiva DNS

En Windows Server 2016, DNS es un rol de servidor que se puede instalar mediante
comandos Administrador del servidor o Windows PowerShell. Si va a instalar un nuevo
bosque y dominio de Active Directory, DNS se instala automáticamente con Active
Directory como servidor de catálogo global para el bosque y el dominio.

Servicios de dominio de Active Directory (AD DS) usa DNS como mecanismo de
ubicación del controlador de dominio. Cuando se realiza cualquiera de las operaciones
principales de Active Directory, como la autenticación, la actualización o la búsqueda,
los equipos usan DNS para buscar controladores de dominio de Active Directory.
Además, los controladores de dominio usan DNS para localizarse entre sí.

El servicio cliente DNS se incluye en todas las versiones de cliente y servidor del sistema
operativo Windows y se ejecuta de forma predeterminada en la instalación del sistema
operativo. Al configurar una conexión de red TCP/IP con la dirección IP de un servidor
DNS, el cliente DNS consulta el servidor DNS para detectar controladores de dominio y
resolver nombres de equipo en direcciones IP. Por ejemplo, cuando un usuario de red
con una cuenta de usuario de Active Directory inicia sesión en un dominio de Active
Directory, el servicio cliente DNS consulta al servidor DNS para buscar un controlador de
dominio para el dominio de Active Directory. Cuando el servidor DNS responde a la
consulta y proporciona la dirección IP del controlador de dominio al cliente, el cliente se
pone en contacto con el controlador de dominio y el proceso de autenticación puede
comenzar.
El Windows Server 2016 los servicios de servidor DNS y cliente DNS usan el protocolo
DNS que se incluye en el conjunto de protocolos TCP/IP. DNS forma parte del nivel de
aplicación del modelo de referencia TCP/IP, como se muestra en la ilustración siguiente.
Sistema de nombres de dominio (DNS)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

El Sistema de nombres de dominio (DNS) es uno de los conjuntos de protocolos

estándar del sector que componen TCP/IP, y juntos el cliente DNS y el servidor DNS
proporcionan servicios de resolución de nombres de asignación de nombres de equipo
a IP a equipos y usuarios.

７ Nota

Además de este tema, está disponible el siguiente contenido DNS.

Novedades de Cliente DNS

Novedades del servidor DNS
Guía de escenarios de directiva DNS

En Windows Server 2016, DNS es un rol de servidor que se puede instalar mediante
comandos Administrador del servidor o Windows PowerShell. Si va a instalar un nuevo
bosque y dominio de Active Directory, DNS se instala automáticamente con Active
Directory como servidor de catálogo global para el bosque y el dominio.

Servicios de dominio de Active Directory (AD DS) usa DNS como mecanismo de
ubicación del controlador de dominio. Cuando se realiza cualquiera de las operaciones
principales de Active Directory, como la autenticación, la actualización o la búsqueda,
los equipos usan DNS para buscar controladores de dominio de Active Directory.
Además, los controladores de dominio usan DNS para localizarse entre sí.

El servicio cliente DNS se incluye en todas las versiones de cliente y servidor del sistema
operativo Windows y se ejecuta de forma predeterminada en la instalación del sistema
operativo. Al configurar una conexión de red TCP/IP con la dirección IP de un servidor
DNS, el cliente DNS consulta el servidor DNS para detectar controladores de dominio y
resolver nombres de equipo en direcciones IP. Por ejemplo, cuando un usuario de red
con una cuenta de usuario de Active Directory inicia sesión en un dominio de Active
Directory, el servicio cliente DNS consulta al servidor DNS para buscar un controlador de
dominio para el dominio de Active Directory. Cuando el servidor DNS responde a la
consulta y proporciona la dirección IP del controlador de dominio al cliente, el cliente se
pone en contacto con el controlador de dominio y el proceso de autenticación puede
comenzar.
El Windows Server 2016 los servicios de servidor DNS y cliente DNS usan el protocolo
DNS que se incluye en el conjunto de protocolos TCP/IP. DNS forma parte del nivel de
aplicación del modelo de referencia TCP/IP, como se muestra en la ilustración siguiente.
Novedades del servidor DNS en
Windows Server
Artículo • 21/12/2022 • Tiempo de lectura: 9 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema se describe la funcionalidad del servidor del Sistema de nombres de

dominio (DNS) nueva o modificada en Windows Server 2016.

En Windows Server 2016, el servidor DNS ofrece compatibilidad mejorada en las áreas
siguientes.

Funcionalidad Nueva o Descripción

mejorada

Directivas DNS Nuevo Puede configurar directivas DNS para especificar cómo responde
un servidor DNS a las consultas DNS. Las respuestas DNS pueden
basarse en la dirección IP del cliente (ubicación), la hora del día y
otros parámetros. Las directivas DNS permiten DNS con control de
ubicación, administración del tráfico, equilibrio de carga, DNS de
cerebro dividido y otros escenarios.

Limitación de Nuevo Puede habilitar la limitación de la velocidad de respuesta en los

la velocidad de servidores DNS. Al hacerlo, evita la posibilidad de que sistemas
respuesta malintencionados que usan los servidores DNS inicien un ataque
(RRL) por denegación de servicio en un cliente DNS.

Autenticación Nuevo Puede usar registros TLSA (autenticación de seguridad de la capa

basada en DNS de transporte) para proporcionar información a los clientes DNS
de entidades que den su nombre de dominio a qué entidad de certificación
con nombre deben esperar un certificado. Esto evita los ataques de tipo "Man
(DANE) in the middle" en los que alguien podría dañar la caché DNS para
que apunte a su propio sitio web y proporcione un certificado
emitido desde otra entidad de certificación.

Compatibilidad Nuevo Puede agregar registros que no sean compatibles explícitamente

con registros con el Windows DNS mediante la funcionalidad de registro
desconocidos desconocida.

Sugerencias Nuevo Puede usar la compatibilidad nativa con sugerencias raíz IPV6 para
raíz IPv6 realizar la resolución de nombres de Internet mediante los
servidores raíz IPV6.

Compatibilidad Se ha Hay Windows PowerShell cmdlets nuevos disponibles para el

con Windows mejorado servidor DNS.
PowerShell
Directivas DNS
Puede usar la directiva DNS para una administración de tráfico basada en Geo-Location,
respuestas DNS inteligentes basadas en la hora del día, para administrar un único
servidor DNS configurado para la implementación de cerebro dividido, aplicar filtros en
consultas DNS y mucho más. Los siguientes elementos proporcionan más detalles sobre
estas funcionalidades.

Equilibrio de carga de aplicaciones. Cuando haya implementado varias instancias

de una aplicación en ubicaciones diferentes, puede usar la directiva DNS para
equilibrar la carga de tráfico entre las distintas instancias de aplicación, asignando
dinámicamente la carga de tráfico para la aplicación.

Geo-Location basada en tráfico. Puede usar la directiva DNS para permitir que los
servidores DNS principales y secundarios respondan a las consultas de cliente DNS
en función de la ubicación geográfica del cliente y del recurso al que el cliente
intenta conectarse, proporcionando al cliente la dirección IP del recurso más
cercano.

DNS de cerebro dividido. Con DNS de cerebro dividido, los registros DNS se
dividen en distintos ámbitos de zona en el mismo servidor DNS y los clientes DNS
reciben una respuesta en función de si los clientes son clientes internos o externos.
Puede configurar DNS de cerebro dividido para Active Directory integradas o para
zonas en servidores DNS independientes.

Filtrado. Puede configurar la directiva DNS para crear filtros de consulta que se
basen en los criterios que proporcione. Los filtros de consulta de la directiva DNS
permiten configurar el servidor DNS para que responda de forma personalizada en
función de la consulta DNS y el cliente DNS que envía la consulta DNS.

Análisis forense. Puede usar la directiva DNS para redirigir clientes DNS
malintencionados a una dirección IP inexistente en lugar de dirigirlos al equipo al
que están intentando acceder.

Redireccionamiento basado en la hora del día. Puede usar la directiva DNS para
distribuir el tráfico de la aplicación entre diferentes instancias distribuidas
geográficamente de una aplicación mediante directivas DNS basadas en la hora
del día.

También puede usar directivas DNS para las Active Directory DNS integradas.

Para más información, consulte la Guía de escenarios de directivas DNS.

Limitación de la velocidad de respuesta
Puede configurar RRL para controlar cómo responder a las solicitudes a un cliente DNS
cuando el servidor recibe varias solicitudes dirigidas al mismo cliente. Al hacerlo, puede
evitar que alguien envíe un ataque de denegación de servicio (Dos) mediante los
servidores DNS. Por ejemplo, una red de bots puede enviar solicitudes al servidor DNS
mediante la dirección IP de un tercer equipo como solicitante. Sin RRL, los servidores
DNS podrían responder a todas las solicitudes, lo que desborda el tercer equipo. Al usar
RRL, puede configurar las siguientes opciones:

Respuestas por segundo. Este es el número máximo de veces que se da la misma

respuesta a un cliente en un segundo.

Errores por segundo. Este es el número máximo de veces que se envía una
respuesta de error al mismo cliente en un segundo.

Ventana. Este es el número de segundos durante los que se suspenden las

respuestas a un cliente si se realizan demasiadas solicitudes.

Velocidad de pérdidas. Esta es la frecuencia con la que el servidor DNS responde a

una consulta durante el tiempo en que se suspenden las respuestas. Por ejemplo,
si el servidor suspende las respuestas a un cliente durante 10 segundos y la tasa de
pérdidas es 5, el servidor sigue respondiendo a una consulta por cada 5 consultas
enviadas. Esto permite a los clientes legítimos obtener respuestas incluso cuando
el servidor DNS está aplicando la limitación de la velocidad de respuesta en su
subred o FQDN.

Velocidad de TC. Esto se usa para decir al cliente que intente conectarse con TCP
cuando se suspendan las respuestas al cliente. Por ejemplo, si la velocidad de TC es
3 y el servidor suspende las respuestas a un cliente determinado, el servidor emite
una solicitud de conexión TCP por cada 3 consultas recibidas. Asegúrese de que el
valor de la velocidad de TC es menor que la velocidad de pérdida, para dar al
cliente la opción de conectarse a través de TCP antes de las respuestas de pérdida.

Respuestas máximas. Este es el número máximo de respuestas que el servidor

emite a un cliente mientras se suspenden las respuestas.

Dominios de lista de permitidos. Se trata de una lista de dominios que se

excluirán de la configuración de RRL.

Permitir subredes. Se trata de una lista de subredes que se excluirán de la

configuración de RRL.
 Interfaces de servidor de lista de permitidos. Se trata de una lista de interfaces de
servidor DNS que se excluirán de la configuración de RRL.

Compatibilidad con DANE

Puede usar la compatibilidad con DANE (RFC 6394 y 6698) para especificar a los clientes
DNS de qué ENTIDAD de certificación deben esperar que se emita certificados para los
nombres de dominios hospedados en el servidor DNS. Esto evita una forma de ataque
de tipo "Man in the middle" en la que alguien puede dañar una caché DNS y apuntar un
nombre DNS a su propia dirección IP.

Por ejemplo, imagine que hospeda un sitio web seguro que usa SSL en
[Link] mediante un certificado de una entidad conocida denominada CA1.
Es posible que alguien pueda obtener un certificado para [Link] de una
entidad de certificación diferente, no tan conocida, denominada CA2. A continuación, la
entidad que hospeda el sitio web [Link] falso podría dañar la caché DNS
de un cliente o servidor para que apunte [Link] a su sitio falso. Al usuario
final se le presenta un certificado de CA2 y puede simplemente reconocerlo y
conectarse al sitio falso. Con DANE, el cliente realizaría una solicitud al servidor DNS
para [Link] solicitando el registro TLSA y aprendería que ca1 emite el certificado
para [Link] para [Link] . Si se presenta un certificado de otra
entidad de certificación, se anula la conexión.

Compatibilidad con registros desconocidos

Un "registro desconocido" es un RR cuyo formato RDATA no es conocido para el
servidor DNS. La compatibilidad recién agregada para los tipos de registro desconocido
(RFC 3597) significa que puede agregar los tipos de registro no admitidos a las zonas de
servidor DNS de Windows en el formato binario en conexión. La Windows de
almacenamiento en caché ya tiene la capacidad de procesar tipos de registros
desconocidos. Windows servidor DNS no realiza ningún procesamiento específico del
registro para los registros desconocidos, pero lo devuelve en respuestas si se reciben
consultas para él.

Sugerencias raíz IPv6

Las sugerencias raíz IPV6, tal y como publica IANA, se han agregado al Windows DNS.
Las consultas de nombres de Internet ahora pueden usar servidores raíz IPv6 para
realizar resoluciones de nombres.
Compatibilidad con Windows PowerShell
Los siguientes nuevos Windows PowerShell cmdlets y parámetros se presentan en
Windows Server 2016.

Add-DnsServerRecursionScope. Este cmdlet crea un nuevo ámbito de recursividad

en el servidor DNS. Las directivas DNS usan los ámbitos de recursividad para
especificar una lista de reenviadores que se usarán en una consulta DNS.

Remove-DnsServerRecursionScope. Este cmdlet quita los ámbitos de recursividad

existentes.

Set-DnsServerRecursionScope. Este cmdlet cambia la configuración de un ámbito

de recursión existente.

Get-DnsServerRecursionScope. Este cmdlet recupera información sobre los

ámbitos de recursividad existentes.

Add-DnsServerClientSubnet. Este cmdlet crea una nueva subred de cliente DNS.

Las directivas DNS usan subredes para identificar dónde se encuentra un cliente
DNS.

Remove-DnsServerClientSubnet. Este cmdlet quita las subredes de cliente DNS

existentes.

Set-DnsServerClientSubnet. Este cmdlet cambia la configuración de una subred de

cliente DNS existente.

Get-DnsServerClientSubnet. Este cmdlet recupera información sobre las subredes

de cliente DNS existentes.

Add-DnsServerQueryResolutionPolicy. Este cmdlet crea una nueva directiva de

resolución de consultas DNS. Las directivas de resolución de consultas DNS se
usan para especificar cómo o si se responde a una consulta, en función de criterios
diferentes.

Remove-DnsServerQueryResolutionPolicy. Este cmdlet quita las directivas DNS

existentes.

Set-DnsServerQueryResolutionPolicy. Este cmdlet cambia la configuración de una

directiva DNS existente.

Get-DnsServerQueryResolutionPolicy. Este cmdlet recupera información sobre las

directivas DNS existentes.
 Enable-DnsServerPolicy. Este cmdlet habilita las directivas DNS existentes.

Disable-DnsServerPolicy. Este cmdlet deshabilita las directivas DNS existentes.

Add-DnsServerZoneTransferPolicy. Este cmdlet crea una nueva directiva de

transferencia de zona de servidor DNS. Las directivas de transferencia de zona DNS
especifican si se debe denegar o omitir una transferencia de zona en función de
criterios diferentes.

Remove-DnsServerZoneTransferPolicy. Este cmdlet quita las directivas de

transferencia de zona de servidor DNS existentes.

Set-DnsServerZoneTransferPolicy. Este cmdlet cambia la configuración de una

directiva de transferencia de zona de servidor DNS existente.

Get-DnsServerResponseRateLimiting. Este cmdlet recupera la configuración de

RRL.

Set-DnsServerResponseRateLimiting. Este cmdlet cambia los settigns de RRL.

Add-DnsServerResponseRateLimitingExceptionlist. Este cmdlet crea una lista de

excepciones de RRL en el servidor DNS.

Get-DnsServerResponseRateLimitingExceptionlist. Este cmdlet recupera listas de

excceptiones de RRL.

Remove-DnsServerResponseRateLimitingExceptionlist. Este cmdlet quita una lista

de excepciones RRL existente.

Set-DnsServerResponseRateLimitingExceptionlist. Este cmdlet cambia las listas de

excepciones de RRL.

Add-DnsServerResourceRecord. Este cmdlet se actualizó para admitir el tipo de

registro desconocido.

Get-DnsServerResourceRecord. Este cmdlet se actualizó para admitir el tipo de

registro desconocido.

Remove-DnsServerResourceRecord. Este cmdlet se actualizó para admitir el tipo

de registro desconocido.

Set-DnsServerResourceRecord. Este cmdlet se actualizó para admitir el tipo de

registro desconocido.

Para obtener más información, vea los temas de referencia Windows Server 2016
Windows PowerShell comandos siguientes.
 Módulo DnsServer
Módulo DnsClient

Referencias adicionales
Novedades de Cliente DNS
Novedades del cliente DNS en Windows
Server 2016
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema se describe la funcionalidad de cliente del Sistema de nombres de dominio

(DNS) nueva o modificada en Windows 10 y Windows Server 2016 y versiones
posteriores de estos sistemas operativos.

Actualizaciones del cliente DNS

Enlace de servicio de cliente DNS: en Windows 10, el servicio cliente DNS ofrece
compatibilidad mejorada para equipos con más de una interfaz de red. En el caso de los
equipos con varias versiones, la resolución DNS se optimiza de las maneras siguientes:

Cuando se usa un servidor DNS configurado en una interfaz específica para

resolver una consulta DNS, el servicio cliente DNS se enlazará a esta interfaz antes
de enviar la consulta DNS.

Al enlazar a una interfaz específica, el cliente DNS puede especificar claramente la

interfaz donde se produce la resolución de nombres, lo que permite a las
aplicaciones optimizar las comunicaciones con el cliente DNS a través de esta
interfaz de red.

Si el servidor DNS que se usa se designa mediante una configuración directiva de

grupo de la tabla de directivas de resolución de nombres (NRPT), el servicio cliente
DNS no se enlaza a una interfaz específica.

７ Nota

Los cambios en el servicio cliente DNS de Windows 10 también están presentes en

equipos que ejecutan Windows Server 2016 versiones posteriores.

Referencias adicionales
Novedades del servidor DNS en Windows Server 2016
Introducción a DNS de difusión por
difusión
Artículo • 14/02/2023 • Tiempo de lectura: 9 minutos

Se aplica a: Windows Server 2022, Windows Server 2016, Windows Server 2019

En este tema se proporciona información sobre cómo funciona DNS de anycast.

¿Qué es Anycast?
Anycast es una tecnología que proporciona varias rutas de acceso de enrutamiento a un
grupo de puntos de conexión a los que se les asigna la misma dirección IP. Cada
dispositivo del grupo anuncia la misma dirección en una red y los protocolos de
enrutamiento se usan para elegir cuál es el mejor destino.

La difusión le permite escalar un servicio sin estado, como DNS o HTTP, colocando
varios nodos detrás de la misma dirección IP y usando el enrutamiento de múltiples
rutas de acceso igual a costo (ECMP) para dirigir el tráfico entre estos nodos. Cualquier
difusión es diferente de la unidifusión, en la que cada punto de conexión tiene su propia
dirección IP independiente.

¿Por qué usar Anycast con DNS?

Con DNS de difusión por error, puede habilitar un servidor DNS o un grupo de
servidores para responder a consultas DNS basadas en la ubicación geográfica de un
cliente DNS. Esto puede mejorar el tiempo de respuesta dns y simplificar la
configuración del cliente DNS. Dns de difusión por secuencias también proporciona una
capa adicional de redundancia y puede ayudar a protegerse frente a ataques por
denegación de servicio de DNS.

Funcionamiento de DNS de anycast

Dns de difusión funciona mediante protocolos de enrutamiento como el Protocolo de
puerta de enlace de borde (BGP) para enviar consultas DNS a un servidor DNS preferido
o a un grupo de servidores DNS (por ejemplo, un grupo de servidores DNS
administrados por un equilibrador de carga). Este diseño puede optimizar las
comunicaciones DNS mediante la obtención de respuestas DNS de un servidor DNS
más cercano a un cliente.
Con Anycast, los servidores que existen en varias ubicaciones geográficas anuncian una
única dirección IP idéntica a su puerta de enlace local (enrutador). Cuando un cliente
DNS inicia una consulta a la dirección anycast, se evalúan las rutas disponibles y la
consulta DNS se envía a la ubicación preferida. En general, esta ubicación es la más
cercana en función de la topología de red. Consulte el ejemplo siguiente.

Figura 1: Ejemplo de red de difusión de anycast

Cuatro servidores DNS (círculos azules), ubicados en diferentes sitios de una red,
cada uno anuncia la misma dirección IP de difusión de anycast a su dispositivo de
enrutamiento local (no se muestra).
Las rutas se comparten entre los dispositivos de la red (flechas negras).
Un dispositivo cliente DNS (círculo verde) envía una consulta DNS a la dirección IP
de anycast.
Un dispositivo de enrutamiento de la red recibe la solicitud DNS del cliente (no se
muestra).
El dispositivo de enrutamiento analiza las rutas disponibles a la dirección IP de
anycast y enruta la consulta DNS mediante la ruta más corta disponible.
La consulta DNS se envía al servidor DNS más cercano (flecha azul).

Dns de difusión se usa habitualmente hoy para enrutar el tráfico DNS para muchos
servicios DNS globales. Por ejemplo, el sistema de servidor DNS raíz depende en gran
medida de DNS de difusión de anycast. Anycast también funciona con muchos
protocolos de enrutamiento diferentes y se puede usar exclusivamente en intranets.

Demostración nativa de BGP de Windows

Server
En el procedimiento siguiente se muestra cómo se puede usar BGP nativo en Windows
Server con DNS de difusión por error.

Requisitos
Un dispositivo físico con el rol de Hyper-V instalado.
Windows Server 2012 R2, Windows 10 o posterior.
2 máquinas virtuales cliente (cualquier sistema operativo).
Se recomienda la instalación de herramientas bind para DNS, como la
excavación.
3 máquinas virtuales de servidor (Windows Server 2016 o Windows Server 2019).
Si el módulo Windows PowerShell LoopbackAdapter aún no está instalado en
las máquinas virtuales del servidor (DC001, DC002), se requiere temporalmente
acceso a Internet para instalar este módulo.

Configuración de Hyper-V
Configure el servidor de Hyper-V de la siguiente manera:

2 redes de conmutador virtual privadas están configuradas

Una red ficticia de Internet [Link]/24
Una red de intranet ficticia [Link]/24
2 máquinas virtuales cliente están conectadas a la red [Link]/24
2 máquinas virtuales de servidor están conectadas a la red [Link]/24
1 servidor es de doble casa y está conectado a las redes [Link]/24 y
[Link]/24.

Configuración de red de máquina virtual

Configure las opciones de red en las máquinas virtuales con las siguientes opciones:

1. Client1, client2

Client1: [Link]
Client2: [Link]
 Máscara de subred: [Link]
DNS: [Link]
Puerta de enlace: [Link]

2. Puerta de enlace (Windows Server)

NIC1: [Link], subred [Link]

NIC2: [Link], subred [Link]
DNS: [Link]
Puerta de enlace: [Link] (se puede omitir para la demostración)

3. DC001 (Windows Server)

NIC1: [Link]
Subred: [Link]
DNS: [Link]
Puerta de enlace: [Link]

4. DC002 (Windows Server)

NIC1: [Link]
Subred [Link]
DNS: [Link]*
Puerta de enlace: [Link]

*Use [Link] para DNS inicialmente al realizar la unión a un dominio para DC002 para
que pueda localizar el dominio de Active Directory en DC001.

Configurar el DNS
Use Administrador del servidor y la consola de administración de DNS o Windows
PowerShell para instalar los siguientes roles de servidor y crear una zona DNS estática
en cada uno de los dos servidores.

1. DC001, DC002

Instalar Servicios de dominio de Active Directory y promover al controlador de

dominio (opcional)
Instalación del rol DNS (obligatorio)
Cree una zona estática (no integrada de AD) denominada [Link] en DC001 y
DC002.
Agregue el servidor de nombres de registro estático único en la zona de tipo
"TXT".
Datos (texto) del registro TXT en DC001 = DC001
 Datos (texto) para el registro TXT en DC002 = DC002

Configuración de adaptadores de bucle invertido

Escriba los siguientes comandos en un símbolo del sistema de Windows PowerShell con
privilegios elevados en DC001 y DC002 para configurar adaptadores de bucle invertido.

７ Nota

El comando Install-Module requiere acceso a Internet. Esto se puede hacer

asignando temporalmente la máquina virtual a una red externa en Hyper-V.

PowerShell

$primary_interface = (Get-NetAdapter |?{$_.Status -eq "Up" -and

!$_.Virtual}).Name
$loopback_ipv4 = '[Link]'
$loopback_ipv4_length = '32'
$loopback_name = 'Loopback'
Install-Module -Name LoopbackAdapter -MinimumVersion [Link] -Force
Import-Module -Name LoopbackAdapter
New-LoopbackAdapter -Name $loopback_name -Force
$interface_loopback = Get-NetAdapter -Name $loopback_name
$interface_main = Get-NetAdapter -Name $primary_interface
Set-NetIPInterface -InterfaceIndex $interface_loopback.ifIndex -
InterfaceMetric "254" -WeakHostReceive Enabled -WeakHostSend Enabled -DHCP
Disabled
Set-NetIPInterface -InterfaceIndex $interface_main.ifIndex -WeakHostReceive
Enabled -WeakHostSend Enabled
Set-NetIPAddress -InterfaceIndex $interface_loopback.ifIndex -SkipAsSource
$True
Get-NetAdapter $loopback_name | Set-DNSClient –
RegisterThisConnectionsAddress $False
New-NetIPAddress -InterfaceAlias $loopback_name -IPAddress $loopback_ipv4 -
PrefixLength $loopback_ipv4_length -AddressFamily ipv4
Disable-NetAdapterBinding -Name $loopback_name -ComponentID ms_msclient
Disable-NetAdapterBinding -Name $loopback_name -ComponentID ms_pacer
Disable-NetAdapterBinding -Name $loopback_name -ComponentID ms_server
Disable-NetAdapterBinding -Name $loopback_name -ComponentID ms_lltdio
Disable-NetAdapterBinding -Name $loopback_name -ComponentID ms_rspndr

Configuración de enrutamiento de máquinas virtuales

Use los siguientes comandos Windows PowerShell en máquinas virtuales para
configurar el enrutamiento.

1. Puerta de enlace
 PowerShell

Install-WindowsFeature RemoteAccess -IncludeManagementTools

Install-RemoteAccess -VpnType RoutingOnly
Add-BgpRouter -BgpIdentifier “[Link]” -LocalASN 8075
Add-BgpPeer -Name "DC001" -LocalIPAddress [Link] -PeerIPAddress
[Link] -PeerASN 65511 –LocalASN 8075
Add-BgpPeer -Name "DC002" -LocalIPAddress [Link] -PeerIPAddress
[Link] -PeerASN 65511 –LocalASN 8075

2. DC001

PowerShell

Install-WindowsFeature RemoteAccess -IncludeManagementTools

Install-RemoteAccess -VpnType RoutingOnly
Add-BgpRouter -BgpIdentifier “[Link]” -LocalASN 65511
Add-BgpPeer -Name "Labgw" -LocalIPAddress [Link] -PeerIPAddress
[Link] -PeerASN 8075 –LocalASN 65511
Add-BgpCustomRoute -Network [Link]/24

3. DC002

PowerShell

Install-WindowsFeature RemoteAccess -IncludeManagementTools

Install-RemoteAccess -VpnType RoutingOnly
Add-BgpRouter -BgpIdentifier "[Link]" -LocalASN 65511
Add-BgpPeer -Name "Labgw" -LocalIPAddress [Link] -PeerIPAddress
[Link] -PeerASN 8075 –LocalASN 65511
Add-BgpCustomRoute -Network [Link]/24

Diagrama de resumen
Figura 2: Configuración del laboratorio para la demostración nativa de DNS de difusión
de BGP

Demostración de DNS de difusión por difusión

1. Comprobación del enrutamiento BGP en el servidor de puerta de enlace

PS C:\> Get-BgpRouteInformation

DestinationNetwork NextHop LearnedFromPeer State LocalPref MED

------------------ ------- --------------- ----- --------- ---
[Link]/24 [Link] DC001 Mejor
[Link]/24 [Link] DC002 Mejor

2. En client1 y client2, compruebe que puede alcanzar [Link].51.

PS C:\> ping [Link]

 Hacer ping a [Link] con 32 bytes de datos:
Respuesta de [Link]: bytes=32 veces<1ms TTL=126
Respuesta de [Link]: bytes=32 veces<1ms TTL=126
Respuesta de [Link]: bytes=32 veces<1ms TTL=126
Respuesta de [Link]: bytes=32 veces<1ms TTL=126

Estadísticas de ping para [Link]:

Paquetes: Enviados = 4, Recibido = 4, Perdido = 0 (0% pérdida),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 0 ms, Máximo = 0 ms, Promedio = 0 ms

７ Nota

Si se produce un error en el ping, compruebe también que no haya reglas de

firewall que bloqueen ICMP.

3. En client1 y client2, use nslookup o dig para consultar el registro TXT. Se muestran
ejemplos de ambos.

PS C:\> dig [Link] TXT +short

PS C:\> nslookup -type=txt [Link] [Link]

Un cliente muestra "DC001" y el otro cliente muestra "DC002", comprobando que

Anycast funciona correctamente. También puede consultar desde el servidor de
puerta de enlace.

4. A continuación, deshabilite el adaptador Ethernet en DC001.

PS C:\> (Get-NetAdapter).Name
Bucle invertido
Ethernet 2
PS C:\> Disable-NetAdapter "Ethernet 2"
Confirm
¿Está seguro de que desea realizar esta acción?
Disable-NetAdapter "Ethernet 2"
[Sí] Sí [A] Sí a todos [N] No [L] No a todos [S] Suspender [?] Ayuda (el valor
predeterminado es "Y"):
PS C:\> (Get-NetAdapter).Status

Subir
Disabled
 5. Confirme que los clientes DNS que anteriormente recibieron respuestas de DC001
han cambiado a DC002.

PS C:\> nslookup -type=txt [Link] [Link]

Servidor: UnKnown
Dirección: [Link]

[Link] text =

"DC001"
PS C:\> nslookup -type=txt [Link] [Link]

Servidor: UnKnown
Dirección: [Link]

[Link] text =

"DC002"

6. Confirme que la sesión BGP está inactiva en DC001 mediante Get-BgpStatistics en

el servidor de puerta de enlace.

7. Habilite de nuevo el adaptador Ethernet en DC001 y confirme que la sesión BGP se

restaura y los clientes reciben respuestas DNS de DC001 de nuevo.

７ Nota

Si no se usa un equilibrador de carga, un cliente individual usará el mismo servidor

DNS de back-end si está disponible. Esto crea una ruta de acceso BGP coherente
para el cliente. Para obtener más información, consulte la sección 4.4.3 de RFC4786:
Rutas de acceso de igual costo .

Preguntas más frecuentes

P: ¿Anycast DNS es una buena solución para usar en un entorno DNS local?
R: Dns de difusión funciona perfectamente con un servicio DNS local. Sin embargo,
anycast no es necesario para que el servicio DNS se escale.

P: ¿Cuál es el impacto de implementar DNS de Anycast en un entorno con un gran

número (por ejemplo: >50) de controladores de dominio?
R: No hay ningún impacto directo en la funcionalidad. Si se usa un equilibrador de
carga, no se requiere ninguna otra configuración en controladores de dominio.
P: ¿Es compatible una configuración dns de anycast compatible con el servicio al cliente
de Microsoft?
R: Si usa un equilibrador de carga que no es de Microsoft para reenviar consultas DNS,
Microsoft admite problemas relacionados con el servicio servidor DNS. Consulte al
proveedor del equilibrador de carga para ver los problemas relacionados con el reenvío
de DNS.

P: ¿Cuál es el procedimiento recomendado para DNS de Anycast con un gran número

(por ejemplo: >50) de controladores de dominio?
R: El procedimiento recomendado es usar un equilibrador de carga en cada ubicación
geográfica. Normalmente, los equilibradores de carga los proporciona un proveedor
externo.

P: ¿Anycast DNS y Azure DNS tienen una funcionalidad similar?

R: Azure DNS usa Anycast. Para usar Anycast con Azure DNS, configure el equilibrador
de carga para reenviar solicitudes al servidor DNS de Azure.
Información general de las directivas
DNS
Artículo • 21/12/2022 • Tiempo de lectura: 13 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información sobre la directiva DNS, que es nueva en
Windows Server 2016. Puede usar la directiva DNS para Geo-Location administración de
tráfico basada en el tráfico, respuestas DNS inteligentes basadas en la hora del día, para
administrar un único servidor DNS configurado para la implementación de cerebro
dividido, aplicar filtros en consultas DNS, etc. Los siguientes elementos proporcionan
más detalles sobre estas funcionalidades.

Equilibrio de carga de la aplicación. Cuando haya implementado varias instancias

de una aplicación en diferentes ubicaciones, puede usar la directiva DNS para
equilibrar la carga de tráfico entre las distintas instancias de aplicación, asignando
dinámicamente la carga de tráfico para la aplicación.

Geo-Location administración de tráfico basada en . Puede usar la directiva DNS

para permitir que los servidores DNS principal y secundario respondan a las
consultas de cliente DNS en función de la ubicación geográfica del cliente y del
recurso al que el cliente intenta conectarse, proporcionando al cliente la dirección
IP del recurso más cercano.

Dns de cerebro dividido. Con dns de cerebro dividido, los registros DNS se
dividen en diferentes ámbitos de zona en el mismo servidor DNS y los clientes
DNS reciben una respuesta en función de si los clientes son clientes internos o
externos. Puede configurar DNS de cerebro dividido para zonas integradas de
Active Directory o para zonas en servidores DNS independientes.

Filtrado. Puede configurar la directiva DNS para crear filtros de consulta basados
en criterios que proporcione. Los filtros de consulta en la directiva DNS permiten
configurar el servidor DNS para responder de forma personalizada en función de la
consulta DNS y el cliente DNS que envía la consulta DNS.

Análisis forense. Puede usar la directiva DNS para redirigir clientes DNS
malintencionados a una dirección IP inexistente en lugar de dirigirlos al equipo al
que están intentando acceder.

Hora del redireccionamiento basado en el día. Puede usar la directiva DNS para
distribuir el tráfico de la aplicación en diferentes instancias distribuidas
 geográficamente de una aplicación mediante directivas DNS basadas en la hora
del día.

Nuevos conceptos
Para crear directivas para admitir los escenarios enumerados anteriormente, es
necesario poder identificar grupos de registros en una zona, grupos de clientes de una
red, entre otros elementos. Estos elementos se representan mediante los siguientes
nuevos objetos DNS:

Subred de cliente: un objeto de subred de cliente representa una subred IPv4 o

IPv6 desde la que se envían consultas a un servidor DNS. Puede crear subredes
para definir más adelante las directivas que se aplicarán en función de la subred de
la que proceden las solicitudes. Por ejemplo, en un escenario de DNS de cerebro
dividido, la solicitud de resolución para un nombre como [Link] se
puede responder con una dirección IP interna a los clientes de subredes internas y
una dirección IP diferente a los clientes en subredes externas.

Ámbito de recursividad: los ámbitos de recursividad son instancias únicas de un

grupo de configuraciones que controlan la recursividad en un servidor DNS. Un
ámbito de recursividad contiene una lista de reenviadores y especifica si la
recursividad está habilitada. Un servidor DNS puede tener muchos ámbitos de
recursividad. Las directivas de recursividad del servidor DNS permiten elegir un
ámbito de recursividad para un conjunto de consultas. Si el servidor DNS no es
autoritativo para determinadas consultas, las directivas de recursividad del servidor
DNS le permiten controlar cómo resolver esas consultas. Puede especificar qué
reenviadores usar y si se va a usar la recursividad.

Ámbitos de zona: una zona DNS puede tener varios ámbitos de zona, con cada
ámbito de zona que contiene su propio conjunto de registros DNS. El mismo
registro puede estar presente en varios ámbitos, con diferentes direcciones IP.
Además, las transferencias de zona se realizan en el nivel de ámbito de zona. Esto
significa que los registros de un ámbito de zona de una zona primaria se
transferirán al mismo ámbito de zona en una zona secundaria.

Tipos de directiva
Las directivas DNS se dividen por nivel y tipo. Puede usar directivas de resolución de
consultas para definir cómo se procesan las consultas y directivas de transferencia de
zona para definir cómo se producen las transferencias de zona. Puede aplicar cada tipo
de directiva en el nivel de servidor o en el nivel de zona.
Directivas de resolución de consultas
Puede usar directivas de resolución de consultas DNS para especificar cómo administran
las consultas de resolución entrantes un servidor DNS. Cada directiva de resolución de
consultas DNS contiene los siguientes elementos:

Campo Descripción Valores

posibles

Nombre Nombre de la directiva - Hasta 256

caracteres
: puede contener
cualquier
carácter válido
para un nombre
de archivo.

State Estado de directiva - Habilitar (valor

predeterminado)
- Deshabilitado

Nivel Nivel de directiva - Servidor

- Zona

Orden de Una vez que una consulta se clasifica por nivel y se aplica, el - Valor numérico
procesamiento servidor busca la primera directiva para la que la consulta - Valor único por
coincide con los criterios y la aplica a la consulta. directiva que
contiene el
mismo nivel y se
aplica en el valor

Acción Acción que va a realizar el servidor DNS - Permitir (valor

predeterminado
para el nivel de
zona)
- Denegar (valor
predeterminado
en el nivel de
servidor)
- Omitir

Criterios Condición de directiva (AND/OR) y lista de criterios que se - Operador

deben cumplir para que se aplique la directiva Condition
(AND/OR)
- Lista de
criterios
(consulte la tabla
de criterios
siguiente)
 Campo Descripción Valores
posibles

Ámbito Lista de ámbitos de zona y valores ponderados por ámbito. - Lista de

Los valores ponderados se usan para la distribución del ámbitos de zona
equilibrio de carga. Por ejemplo, si esta lista incluye (por nombre) y
datacenter1 con un peso de 3 y datacenter2 con un peso de pesos
5, el servidor responderá con un registro del centro de
datos1 tres veces fuera de ocho solicitudes.

７ Nota

Las directivas de nivel de servidor solo pueden tener los valores Denegar o Omitir
como una acción.

El campo Criterios de directiva DNS se compone de dos elementos:

Nombre Descripción Valores de ejemplo

Subred de Nombre de una subred de cliente - EQ,España,Francia : se resuelve en true si la

cliente predefinida. Se usa para comprobar subred se identifica como España o Francia
la subred desde la que se envió la - NE,Canadá, México : se resuelve en true si
consulta. la subred del cliente es cualquier subred que
no sea Canadá y México.

Protocolo Protocolo de transporte usado en - EQ,TCP

de la consulta. Las posibles entradas - EQ,UDP
transporte son UDP y TCP

Protocolo Protocolo de red usado en la - EQ,IPv4

de consulta. Las posibles entradas son - EQ,IPv6
Internet IPv4 e IPv6

Dirección Dirección IP de la interfaz de red - EQ,[Link]

IP de la del servidor DNS entrante - EQ,[Link]
interfaz
del
servidor

FQDN FQDN de registro en la consulta, - EQ,[Link]: se resuelve en true

con la posibilidad de usar un solo si la consulta intenta resolver el FQDN de
carácter comodín [Link]
- EQ,*.[Link],*.[Link] : se
resuelve en true si la consulta es para
cualquier registro que termine en
[Link]
 Nombre Descripción Valores de ejemplo

Tipo de Tipo de registro que se consulta (A, - EQ,TXT,SRV : se resuelve en true si la

consulta SRV, TXT) consulta solicita un registro TXT O SRV.
- EQ,MX : se resuelve en true si la consulta
solicita un registro MX

Hora del Hora del día en que se recibe la - EQ,10:00-12:00,22:00-23:00 - se resuelve en

día consulta true si la consulta se recibe entre las 10 a. m.
y el mediodía, O entre las 10 p. m. y las 11 p.
m.

Con la tabla anterior como punto de partida, se podría usar la tabla siguiente para
definir un criterio que se usa para hacer coincidir las consultas de cualquier tipo de
registros, pero los registros SRV del dominio [Link] procedentes de un cliente de
la subred [Link]/24 a través de TCP entre 8 y 10 p. m. a través de la interfaz [Link]:

Nombre Valor

Subred de cliente EQ,[Link]/24

Protocolo de transporte EQ,TCP

Dirección IP de la interfaz del servidor EQ,[Link]

FQDN EQ,*.[Link]

Tipo de consulta NE,SRV

Hora del día EQ,20:00-22:00

Puede crear varias directivas de resolución de consultas del mismo nivel, siempre y
cuando tengan un valor diferente para el orden de procesamiento. Cuando hay varias
directivas disponibles, el servidor DNS procesa las consultas entrantes de la siguiente
manera:
Directivas de recursividad
Las directivas de recursividad son un tipo especial de directivas de nivel de servidor. Las
directivas de recursividad controlan cómo realiza el servidor DNS la recursividad de una
consulta. Las directivas de recursividad solo se aplican cuando el procesamiento de
consultas alcanza la ruta de acceso de recursividad. Puede elegir un valor de DENY o
IGNORE para la recursividad de un conjunto de consultas. Como alternativa, puede
elegir un conjunto de reenviadores para un conjunto de consultas.

Puede usar directivas de recursividad para implementar una configuración dns de

cerebro dividido. En esta configuración, el servidor DNS realiza la recursividad de un
conjunto de clientes para una consulta, mientras que el servidor DNS no realiza la
recursividad para otros clientes para esa consulta.

Las directivas de recursividad contienen los mismos elementos que contiene una
directiva de resolución de consultas DNS normal, junto con los elementos de la tabla
siguiente:

Nombre Descripción

Aplicar al recursividad Especifica que esta directiva solo se debe usar para la recursividad.

Ámbito de recursividad Nombre del ámbito de recursividad.

７ Nota

Las directivas de recursividad solo se pueden crear en el nivel de servidor.

Directivas de transferencia de zona

Las directivas de transferencia de zona controlan si el servidor DNS permite o no una
transferencia de zona. Puede crear directivas para la transferencia de zona en el nivel de
servidor o en el nivel de zona. Las directivas de nivel de servidor se aplican en cada
consulta de transferencia de zona que se produce en el servidor DNS. Las directivas de
nivel de zona solo se aplican en las consultas de una zona hospedada en el servidor
DNS. El uso más común para las directivas de nivel de zona es implementar listas
bloqueadas o seguras.

７ Nota

Las directivas de transferencia de zona solo pueden usar DENY o IGNORE como
acciones.
Puede usar la directiva de transferencia de zona de nivel de servidor siguiente para
denegar una transferencia de zona para el dominio de [Link] desde una subred
determinada:

Add-DnsServerZoneTransferPolicy -Name DenyTransferOfContosoToFabrikam -Zone

[Link] -Action DENY -ClientSubnet "EQ,[Link]/24"

Puede crear varias directivas de transferencia de zona del mismo nivel, siempre y
cuando tengan un valor diferente para el orden de procesamiento. Cuando hay varias
directivas disponibles, el servidor DNS procesa las consultas entrantes de la siguiente
manera:
Administración de directivas DNS
Puede crear y administrar directivas DNS mediante PowerShell. En los ejemplos
siguientes se describen diferentes escenarios de ejemplo que puede configurar a través
de directivas DNS:

Administración del tráfico

Puede dirigir el tráfico basado en un FQDN a distintos servidores en función de la
ubicación del cliente DNS. En el ejemplo siguiente se muestra cómo crear directivas de
administración de tráfico para dirigir a los clientes desde una subred determinada a un
centro de datos de Norteamérica y desde otra subred a un centro de datos europeo.

Add-DnsServerClientSubnet -Name "NorthAmericaSubnet" -IPv4Subnet

"[Link]/24"
Add-DnsServerClientSubnet -Name "EuropeSubnet" -IPv4Subnet "[Link]/24"
Add-DnsServerZoneScope -ZoneName "[Link]" -Name "NorthAmericaZoneScope"
Add-DnsServerZoneScope -ZoneName "[Link]" -Name "EuropeZoneScope"
Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name "www" -
IPv4Address "[Link]" -ZoneScope "EuropeZoneScope"
Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name "www" -
 IPv4Address "[Link]" -ZoneScope "NorthAmericaZoneScope"
Add-DnsServerQueryResolutionPolicy -Name "NorthAmericaPolicy" -Action ALLOW
-ClientSubnet "eq,NorthAmericaSubnet" -ZoneScope "NorthAmericaZoneScope,1" -
ZoneName "[Link]"
Add-DnsServerQueryResolutionPolicy -Name "EuropePolicy" -Action ALLOW -
ClientSubnet "eq,EuropeSubnet" -ZoneScope "EuropeZoneScope,1" -ZoneName
[Link]

Las dos primeras líneas del script crean objetos de subred de cliente para Norteamérica
y Europa. Las dos líneas posteriores a esa creación de un ámbito de zona dentro del
dominio de [Link], una para cada región. Las dos líneas posteriores crean un
registro en cada zona que asocia [Link] a una dirección IP diferente, una
para Europa, otra para Norteamérica. Por último, las últimas líneas del script crean dos
directivas de resolución de consultas DNS, una que se aplicará a la subred Norteamérica,
otra a la subred Europa.

Bloquear consultas para un dominio

Puede usar una directiva de resolución de consultas DNS para bloquear las consultas a
un dominio. En el ejemplo siguiente se bloquean todas las consultas para
[Link]:

Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicy" -Action IGNORE -

FQDN "EQ,*.[Link]"

Bloquear consultas desde una subred

También puede bloquear las consultas procedentes de una subred específica. El script
siguiente crea una subred para [Link]/24 y, a continuación, crea una directiva para
omitir todas las consultas procedentes de esa subred:

Add-DnsServerClientSubnet -Name "MaliciousSubnet06" -IPv4Subnet

[Link]/24
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicyMalicious06" -
Action IGNORE -ClientSubnet "EQ,MaliciousSubnet06"

Permitir recursividad para clientes internos

Puede controlar la recursividad mediante una directiva de resolución de consultas DNS.
El ejemplo siguiente se puede usar para habilitar la recursividad para clientes internos, al
tiempo que se deshabilita para clientes externos en un escenario de cerebro dividido.

Set-DnsServerRecursionScope -Name . -EnableRecursion $False

Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainPolicy" -Action ALLOW -
ApplyOnRecursion -RecursionScope "InternalClients" -ServerInterfaceIP
"EQ,[Link]"

La primera línea del script cambia el ámbito de recursividad predeterminado,

simplemente denominado "." (punto) para deshabilitar la recursividad. La segunda línea
crea un ámbito de recursividad denominado InternalClients con recursividad habilitada.
Y la tercera línea crea una directiva para aplicar el ámbito de recursividad recién creado
a cualquier consulta que llegue a través de una interfaz de servidor que tenga [Link]
como una dirección IP.

Creación de una directiva de transferencia de zona de

nivel de servidor
Puede controlar la transferencia de zona en un formulario más pormenorizado mediante
directivas de transferencia de zona DNS. El script de ejemplo siguiente se puede usar
para permitir transferencias de zona para cualquier servidor de una subred determinada:

Add-DnsServerClientSubnet -Name "AllowedSubnet" -IPv4Subnet [Link]/24

Add-DnsServerZoneTransferPolicy -Name "NorthAmericaPolicy" -Action IGNORE -
ClientSubnet "ne,AllowedSubnet"

La primera línea del script crea un objeto de subred denominado AllowedSubnet con el
bloque IP [Link]/24. La segunda línea crea una directiva de transferencia de zona
para permitir las transferencias de zona a cualquier servidor DNS de la subred creada
anteriormente.

Creación de una directiva de transferencia de zona de

nivel de zona
También puede crear directivas de transferencia de zona de nivel de zona. En el ejemplo
siguiente se omite cualquier solicitud de transferencia de zona para [Link]
procedente de una interfaz de servidor que tenga una dirección IP de [Link]:

Add-DnsServerZoneTransferPolicy -Name "InternalTransfers" -Action IGNORE -

ServerInterfaceIP "eq,[Link]" -PassThru -ZoneName "[Link]"

Escenarios de directiva DNS

Para obtener información sobre cómo usar la directiva DNS para escenarios específicos,
consulte los temas siguientes de esta guía.

Uso de directiva DNS para la administración del tráfico basada en la ubicación

geográfica con servidores principales
Uso de directiva DNS para la administración del tráfico basada en la ubicación
geográfica con implementaciones primarias-secundarias
Uso de la directiva de DNS para las respuestas DNS inteligentes basadas en la hora
del día
Respuestas DNS basadas en la hora del día con una instancia de Azure Cloud App
Server
Uso de la directiva DNS para la implementación de DNS de Split-Brain
Uso de la directiva DNS para Split-Brain DNS en Active Directory
Uso de la directiva DNS para aplicar filtros en consultas DNS
Uso de la directiva de DNS para el equilibrio de carga de aplicación
Uso de la directiva de DNS para equilibrio de carga de aplicación con
reconocimiento de ubicación geográfica

Uso de la directiva DNS en controladores de

dominio de Read-Only
La directiva DNS es compatible con Read-Only controladores de dominio. Tenga en
cuenta que es necesario reiniciar el servicio servidor DNS para que se carguen nuevas
directivas DNS en Read-Only controladores de dominio. Esto no es necesario en
controladores de dominio grabables.
Inicio rápido: Instalación y
configuración del servidor DNS
Artículo • 10/01/2023 • Tiempo de lectura: 8 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este inicio rápido se muestra cómo instalar y configurar un servidor DNS en Windows
Server. Instalará el rol servidor DNS para reenviar consultas DNS a servidores de
nombres de sugerencia raíz DNS, o opcionalmente a un servidor de nombres
ascendente.

Prerrequisitos
Para poder instalar y configurar el servidor DNS, el equipo debe cumplir los siguientes
requisitos previos:

Un equipo que ejecuta una versión de soporte técnico de Windows Server.

Una dirección IP estática.
Una cuenta que sea miembro del grupo Administradores o equivalente.

Instalación del servidor DNS

La instalación de un servidor del Sistema de nombres de dominio (DNS) implica agregar
el rol servidor DNS a un servidor de Windows Server existente.

 Sugerencia

Cuando instala Active Directory Domain Services(AD DS) con el Asistente para
instalación de Active Directory Domain Services, el asistente ofrece la opción de
instalar y configurar automáticamente un servidor DNS. La zona DNS resultante se
integra con el espacio de nombres de dominio de AD DS. Para más información,
consulte Descripción de la integración de Servicios de dominio de Active
Directory.

Para instalar el rol servidor DNS como servidor independiente, realice los pasos
siguientes:

PowerShell
 A continuación se muestra cómo instalar el rol servidor DNS mediante el comando
Install-WindowsFeature .

1. Ejecute PowerShell en el equipo en una sesión con privilegios elevados.

2. Para instalar el rol DNS, ejecute el siguiente comando. La instalación no

requiere un reinicio.

PowerShell

Install-WindowsFeature -Name DNS

Configuración del servidor DNS

Ahora que ha instalado el rol servidor DNS, puede configurar el servidor.

Configuración de interfaces
De forma predeterminada, un servidor DNS escuchará las solicitudes en todas las
interfaces de dirección IP. Puede configurar el servidor DNS para que escuche en una
interfaz de especificación mediante la GUI o mediante PowerShell.

PowerShell

Aquí se muestra cómo configurar la interfaz que se usa para escuchar las solicitudes
DNS mediante el comando Set-DNSServerSetting .

1. Ejecute PowerShell en el equipo en una sesión con privilegios elevados.

2. Busque la dirección IP existente de los equipos mediante la ejecución del

cmdlet Get-NetIPAddress . Anote la dirección IP que desea usar para el
servidor DNS.

PowerShell

Get-NetIPAddress | fl IPAddress,InterfaceAlias

3. Almacene la configuración actual del servidor DNS en una variable temporal,

establezca la propiedad ListeningIpAddress y aplique la nueva configuración
 mediante la ejecución de los siguientes comandos. Reemplace el marcador
<ip_address> de posición por la dirección IP que anotó anteriormente.

PowerShell

$DnsServerSettings = Get-DnsServerSetting -ALL

$[Link] = @("<ip_address>")
Set-DNSServerSetting $DnsServerSettings

Configurar sugerencias de raíz

Los servidores de sugerencias raíz se usan para ayudar a resolver la información de
direcciones DNS cuando el servidor DNS no puede resolver la consulta localmente
desde una zona hospedada o la caché del servidor DNS. Los servidores de nombres de
sugerencias raíz se rellenan de forma predeterminada en las nuevas instalaciones.

Puede editar la lista de servidores de nombres raíz si es necesario; para ello, vaya a la
pestaña Sugerencias raíz del cuadro de diálogo propiedades del servidor DNS o
mediante PowerShell.

No se admite la eliminación de todos los servidores de sugerencias raíz. En su lugar,

configure el servidor DNS para que no use el servidor de nombres de sugerencia raíz;
para ello, seleccione la opción Deshabilitar servidor de recursividad en la pestaña
Avanzadas de la consola de DNS Manager. Deshabilitar la recursividad también
deshabilita los reenviadores configurados. Como alternativa, desactive Usar sugerencias
raíz si no hay reenviadores disponibles en la pestaña Reenviadores .

PowerShell

A continuación se muestra cómo actualizar un servidor de nombres de sugerencia

raíz dns mediante el comando Set-DnsServerRootHint .

1. Ejecute PowerShell en el equipo en una sesión con privilegios elevados.

2. Busque la dirección IP existente de los equipos mediante la ejecución del

cmdlet Get-DnsServerRootHint . Anote el servidor de nombres que desea
actualizar.

PowerShell

Get-DnsServerRootHint
 3. Almacene la configuración actual del servidor DNS en una variable mediante
la ejecución de los siguientes comandos. Reemplace el marcador de posición
<root_hint_name_server> por el servidor de nombres de sugerencia raíz que

anotó anteriormente.

PowerShell

$RootHintServer = (Get-DnsServerRootHint | Where-Object

{$_.[Link] -match "
<root_hint_name_server>"} )

4. Establezca la propiedad Ipv4address en la variable temporal mediante la

ejecución de los siguientes comandos. Reemplace el marcador de posición
<ip_address> por la dirección IP actualizada.

PowerShell

$[Link][0].RecordData.Ipv4address = "
<ip_address>"

5. Ejecute los siguientes comandos para aplicar el registro actualizado.

PowerShell

Set-DnsServerRootHint $RootHintServer

6. Para comprobar las sugerencias raíz actualizadas, ejecute el siguiente

comando. Observará que el servidor de nombres tiene un punto final (.).

PowerShell

Get-DnsServerRootHint

Configure los reenviadores

Opcionalmente, puede configurar un reenviador para resolver la información de
direcciones DNS en lugar de reenviar el tráfico a los servidores raíz DNS. Puede agregar
reenviadores mediante la GUI o mediante el cmdlet de Set-DNSServerForwarder
PowerShell.

７ Nota
 Las sugerencias raíz dns no se usarán a menos que los reenviadores no respondan.

PowerShell

A continuación se muestra cómo instalar el rol de servidor DNS mediante el

comando Install-WindowsFeature .

1. Ejecute PowerShell en el equipo en una sesión con privilegios elevados.

2. Para configurar reenviadores DNS, reemplace los marcadores

<ip_forwarder_1> de posición y <ip_forwarder_2> por la dirección IP del
servidor DNS que se usará como reenviadores. A continuación, ejecute los
siguientes comandos.

PowerShell

$Forwarders = "<ip_forwarder_1>","<ip_forwarder_2>"
Set-DnsServerForwarder -IPAddress $Forwarders

Eliminación del rol de servidor DNS

Para quitar el rol servidor DNS, realice los pasos siguientes.

PowerShell

A continuación se muestra cómo desinstalar el rol servidor DNS mediante el

comando Uninstall-WindowsFeature .

1. En un símbolo del sistema de PowerShell con privilegios elevados, ejecute el

siguiente comando:

PowerShell

Uninstall-WindowsFeature -Name DNS

） Importante

Al quitar el servicio de rol de servidor DNS de un equipo Con Windows Server,

tenga en cuenta lo siguiente:
 Para un servidor DNS que hospeda zonas integradas de AD DS, estas zonas se
guardan o eliminan según su tipo de almacenamiento. Los datos de zona no
se eliminan a menos que el servidor DNS que desinstale sea el último servidor
DNS que hospeda esa zona.
En el caso de un servidor DNS que hospeda zonas DNS estándar, los archivos
de zona permanecen en el directorio %systemroot%\System32\Dns , pero no
se vuelven a cargar si se vuelve a instalar el servidor DNS. Si crea una nueva
zona con el mismo nombre que la zona antigua, el archivo de la zona antigua
se reemplaza con el archivo de la zona nueva.

Pasos siguientes
Ahora que ha instalado y configurado un servidor DNS, estos son algunos artículos que
pueden ayudarle a hacer más.

Introducción a las directivas DNS

Introducción a DNS de difusión
Protección de un cliente DNS en HTTPS
(DoH)
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

A partir de Windows Server 2022, el cliente DNS admite DNS a través de HTTPS (DoH).
Cuando DoH está habilitado, las consultas DNS entre Windows cliente DNS del servidor
y el servidor DNS pasan a través de una conexión HTTPS segura en lugar de en texto sin
formato. Al pasar la consulta DNS a través de una conexión cifrada, está protegida
contra la interceptación de terceros que no son de confianza.

Configuración del cliente DNS para admitir

DoH
Solo puede configurar el cliente de Windows Server para usar DoH si el servidor DNS
principal o secundario seleccionado para la interfaz de red está en la lista de servidores
DoH conocidos. Puede configurar el cliente DNS para requerir DoH, solicitar DoH o usar
solo consultas DNS de texto sin formato tradicionales. Para configurar el cliente DNS
para que admita DoH en Windows Server con Experiencia de escritorio, siga estos pasos:

1. En el panel de control de Windows Configuración, seleccione Internet de red&.

2. En la página Internet de & red, seleccione Ethernet.

3. En la pantalla Ethernet, seleccione la interfaz de red que desea configurar para

DoH.
4. En la pantalla Red, desplácese hacia abajo hasta configuración de DNS y
seleccione el botón Editar .

5. En la pantalla Editar configuración de DNS, seleccione Manual en la lista

desplegable Configuración de IP automática o manual. Esta configuración le
permite configurar los servidores DNS preferidos y DNS alternativos. Si las
direcciones de estos servidores están presentes en la lista de servidores DoH
conocidos, se habilitará la lista desplegable Cifrado DNS preferido . Puede elegir
entre las siguientes opciones para establecer el cifrado DNS preferido:

Solo cifrado (DNS a través de HTTPS). Cuando se elige esta configuración,

todo el tráfico de consulta DNS pasará a través de HTTPS. Esta configuración
proporciona la mejor protección para el tráfico de consultas DNS. Sin
embargo, también significa que la resolución DNS no se producirá si el
servidor DNS de destino no puede admitir consultas DoH.

Se permiten cifrados preferidos y no cifrados. Cuando se elige esta

configuración, el cliente DNS intentará usar DoH y, a continuación, revertirá a
consultas DNS sin cifrar si no es posible. Esta configuración proporciona la
mejor compatibilidad con los servidores DNS compatibles con DoH, pero no
se le proporcionará ninguna notificación si las consultas DNS se cambian de
DoH a texto sin formato.
 Solo sin cifrar. Todo el tráfico de consulta DNS al servidor DNS especificado
no se cifra. Esta configuración configura el cliente DNS para usar consultas
DNS de texto sin formato tradicionales.

6. Seleccione Guardar para aplicar la configuración de DoH al cliente DNS.

Si va a configurar la dirección del servidor DNS para un cliente mediante PowerShell

mediante el Set-DNSClientServerAddress cmdlet , la configuración de DoH dependerá
de si la configuración de reserva del servidor se encuentra en la lista de la tabla de
servidores DoH conocidos. En la actualidad, no se pueden configurar las opciones de
DoH para el cliente DNS en Windows Server 2022 mediante Windows Admin Center o
[Link].

Configuración de DoH a través de directiva de grupo

Windows Server 2022 local y configuración de dominio directiva de grupo incluyen la
directiva de resolución de nombres Configurar DNS a través de HTTPS (DoH). Puede
usarlo para configurar el cliente DNS para que use DoH. Esta directiva se encuentra en el
Computer Configuration\Policies\Administrative Templates\Network\DNS Client nodo .
Cuando está habilitada, esta directiva se puede configurar con las siguientes opciones:

Permitir DoH. Las consultas se realizarán mediante DoH si los servidores DNS
especificados admiten el protocolo. Si los servidores no admiten DoH, se emitirán
consultas no cifradas.

Prohibir DoH. Impedirá el uso de DoH con consultas de cliente DNS.

Requerir DoH. Requerirá que las consultas se realicen mediante DoH. Si los
servidores DNS configurados no admiten DoH, se producirá un error en la
resolución de nombres.

No habilite la opción Requerir doH para equipos unidos a un dominio, ya que Servicios
de dominio de Active Directory depende en gran medida de DNS, ya que el servicio
servidor DNS del servidor Windows no admite consultas DoH. Si necesita cifrar el tráfico
de consulta DNS en Servicios de dominio de Active Directory red, considere la
posibilidad de implementar reglas de seguridad de conexión basadas en IPsec para
proteger este tráfico. Consulte Protección de conexiones IPsec de un extremo a otro
mediante IKEv2 para obtener más información.

Determinar qué servidores DoH se encuentran

en la lista de servidores conocidos
Windows Server se incluye con una lista de servidores que se sabe que admiten DoH.
Puede determinar qué servidores DNS se encuentran en esta lista mediante el Get-
DNSClientDohServerAddress cmdlet de PowerShell.

La lista predeterminada de servidores DoH conocidos es la siguiente:

Propietario del servidor Direcciones IP del servidor DNS

Cloudflare [Link]
[Link]
2606:4700:4700::1111
2606:4700:4700::1001

Google [Link]
[Link]
2001:4860:4860::8888
2001:4860:4860::8844

Quad 9 [Link]
[Link]
2620:fe::fe
2620:fe::fe:9
Agregar un nuevo servidor DoH a la lista de
servidores conocidos
Puede agregar nuevos servidores DoH a la lista de servidores conocidos mediante el
Add-DnsClientDohServerAddress cmdlet de PowerShell. Especifique la dirección URL de la
plantilla DoH y si permitirá al cliente revertir a una consulta sin cifrar si se produce un
error en la consulta segura. La sintaxis de este comando es:

PowerShell

Add-DnsClientDohServerAddress -ServerAddress '<resolver-IP-address>' -

DohTemplate '<resolver-DoH-template>' -AllowFallbackToUdp $False -
AutoUpgrade $True

Uso de la tabla de directivas de resolución de

nombres con DoH
Puede usar la tabla de directivas de resolución de nombres (NRPT) para configurar
consultas en un espacio de nombres DNS específico para usar un servidor DNS
específico. Si se sabe que el servidor DNS admite DoH, las consultas relacionadas con
ese dominio se realizarán mediante DoH en lugar de de forma no cifrada.
Guía de escenarios de la directiva DNS
Artículo • 21/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Esta guía está pensada para que la usen los administradores de DNS, red y sistemas.

La directiva DNS es una nueva característica de DNS en Windows Server® 2016. Puede
usar esta guía para aprender a usar la directiva DNS para controlar cómo un servidor
DNS procesa las consultas de resolución de nombres en función de los distintos
parámetros que defina en las directivas.

Esta guía contiene información general de la directiva DNS, así como escenarios de
directivas DNS específicos que proporcionan instrucciones sobre cómo configurar el
comportamiento del servidor DNS para lograr sus objetivos, incluida la administración
del tráfico basada en la ubicación geográfica para servidores DNS principales y
secundarios, la alta disponibilidad de la aplicación, DNS de cerebro dividido, etc.

En esta guía se incluyen las siguientes secciones.

Introducción a las directivas DNS

Uso de directiva DNS para la administración del tráfico basada en la ubicación
geográfica con servidores principales
Uso de directiva DNS para la administración del tráfico basada en la ubicación
geográfica con implementaciones primarias-secundarias
Uso de la directiva de DNS para las respuestas DNS inteligentes basadas en la hora
del día
Respuestas DNS basadas en la hora del día con un servidor de aplicaciones en la
nube de Azure
Uso de la directiva DNS para la Split-Brain DNS
Uso de la directiva DNS Split-Brain DNS en Active Directory
Uso de la directiva DNS para aplicar filtros en consultas DNS
Uso de la directiva de DNS para el equilibrio de carga de aplicación
Uso de la directiva de DNS para equilibrio de carga de aplicación con
reconocimiento de ubicación geográfica
Uso de directiva DNS para la
administración del tráfico basada en la
ubicación geográfica con servidores
principales
Artículo • 21/12/2022 • Tiempo de lectura: 9 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para aprender a configurar la directiva DNS para permitir que los
servidores DNS principales respondan a las consultas de cliente DNS en función de la
ubicación geográfica del cliente y del recurso al que el cliente intenta conectarse,
proporcionando al cliente la dirección IP del recurso más cercano.

） Importante

En este escenario se muestra cómo implementar la directiva DNS para la

administración del tráfico basada en la ubicación geográfica cuando se usan solo
servidores DNS principales. También puede realizar la administración del tráfico
basado en la ubicación geográfica cuando tiene servidores DNS principales y
secundarios. Si tiene una implementación principal-secundaria, complete primero
los pasos de este tema y, a continuación, complete los pasos que se proporcionan
en el tema Uso de la directiva DNS para Geo-Location Administración de tráfico
basada en Primary-Secondary implementaciones.

Con las nuevas directivas DNS, puede crear una directiva DNS que permita al servidor
DNS responder a una consulta de cliente que solicite la dirección IP de un servidor web.
Las instancias del servidor web pueden encontrarse en diferentes centros de datos en
diferentes ubicaciones físicas. DNS puede evaluar las ubicaciones de cliente y servidor
web y, a continuación, responder a la solicitud de cliente proporcionando al cliente una
dirección IP del servidor web para un servidor web que se encuentra físicamente más
cerca del cliente.

Puede usar los siguientes parámetros de directiva DNS para controlar las respuestas del
servidor DNS a las consultas de los clientes DNS.

Subred de cliente. Nombre de una subred de cliente predefinida. Se usa para

comprobar la subred desde la que se envió la consulta.
 Protocolo de transporte. Protocolo de transporte usado en la consulta. Las
entradas posibles son UDP y TCP.
Protocolo de Internet. Protocolo de red usado en la consulta. Las posibles
entradas son IPv4 e IPv6.
Dirección IP de la interfaz del servidor. Dirección IP de la interfaz de red del
servidor DNS que recibió la solicitud DNS.
FQDN. Nombre de dominio completo (FQDN) del registro de la consulta, con la
posibilidad de usar un carácter comodín.
Tipo de consulta. Tipo de registro que se consulta (A, SRV, TXT, etc.).
Hora del día. Hora del día en que se recibe la consulta.

Puede combinar los siguientes criterios con un operador lógico (AND/OR) para formular
expresiones de directiva. Cuando estas expresiones coinciden, se espera que las
directivas realicen una de las siguientes acciones.

Ignore. El servidor DNS quita silenciosamente la consulta.

Denegar El servidor DNS responde a esa consulta con una respuesta de error.
Permitir El servidor DNS responde con la respuesta administrada por el tráfico.

Ejemplo de administración de tráfico basada en

Geo-Location
A continuación se muestra un ejemplo de cómo puede usar la directiva DNS para lograr
el redireccionamiento del tráfico en función de la ubicación física del cliente que realiza
una consulta DNS.

En este ejemplo se usan dos empresas ficticias: Contoso Cloud Services, que
proporciona soluciones de hospedaje de sitios web y de dominio, y Woodgrove Food
Services, que proporciona servicios de entrega de alimentos en varias ciudades de todo
el mundo y que tiene un sitio web denominado [Link].

Contoso Cloud Services tiene dos centros de datos, uno en Ee. UU. y otro en Europa. El
centro de datos europeo hospeda un portal de pedidos de alimentos para
[Link].

Para asegurarse de que [Link] clientes obtengan una experiencia dinámica

desde su sitio web, Woodgrove quiere que los clientes europeos se dirijan al centro de
datos europeo y a los clientes americanos dirigidos al centro de datos de EE. UU. Los
clientes ubicados en otro lugar del mundo se pueden dirigir a cualquiera de los centros
de datos.

En la ilustración siguiente se muestra este escenario.

Funcionamiento del proceso de resolución de
nombres DNS
Durante el proceso de resolución de nombres, el usuario intenta conectarse a
[Link] . Esto da como resultado una solicitud de resolución de
nombres DNS que se envía al servidor DNS configurado en las propiedades Conexión
de red en el equipo del usuario. Normalmente, este es el servidor DNS proporcionado
por el ISP local que actúa como solucionador de almacenamiento en caché y se conoce
como LDNS.

Si el nombre DNS no está presente en la caché local de LDNS, el servidor LDNS reenvía
la consulta al servidor DNS que es autoritativo para [Link]. El servidor DNS
autoritativo responde con el registro solicitado ([Link] ) al servidor
LDNS, que a su vez almacena en caché el registro localmente antes de enviarlo al
equipo del usuario.

Dado que Contoso Cloud Services usa directivas de servidor DNS, el servidor DNS
autoritativo que hospeda [Link] está configurado para devolver respuestas
administradas por tráfico basado en ubicación geográfica. Esto da como resultado la
dirección de los clientes europeos al centro de datos europeo y la dirección de los
clientes americanos al centro de datos de EE. UU., como se muestra en la ilustración.

En este escenario, el servidor DNS autoritativo normalmente ve la solicitud de resolución

de nombres procedente del servidor LDNS y, muy rara vez, del equipo del usuario. Por
este motivo, la dirección IP de origen en la solicitud de resolución de nombres tal como
la ve el servidor DNS autoritativo es el del servidor LDNS y no el del equipo del usuario.
Sin embargo, el uso de la dirección IP del servidor LDNS al configurar respuestas de
consulta basadas en ubicación geográfica proporciona una estimación justa de la
ubicación geográfica del usuario, ya que el usuario está consultando el servidor DNS de
su ISP local.

７ Nota

Las directivas DNS usan la dirección IP del remitente en el paquete UDP/TCP que
contiene la consulta DNS. Si la consulta llega al servidor principal a través de varios
saltos de resolución o LDNS, la directiva solo tendrá en cuenta la dirección IP del
último solucionador desde el que el servidor DNS recibe la consulta.

Configuración de la directiva DNS para las

respuestas de consulta basadas en Geo-
Location
Para configurar la directiva DNS para las respuestas de consulta basadas en ubicación
geográfica, debe realizar los pasos siguientes.

1. Creación de las subredes de cliente DNS

2. Crear los ámbitos de la zona
3. Agregar registros a los ámbitos de zona
4. Crear las directivas

７ Nota

Debe realizar estos pasos en el servidor DNS que sea autoritativo para la zona que
desea configurar. La pertenencia a DnsAdmins, o equivalente, es necesaria para
realizar los procedimientos siguientes.

En las secciones siguientes se proporcionan instrucciones de configuración detalladas.

） Importante

En las secciones siguientes se incluyen comandos de ejemplo Windows PowerShell

que contienen valores de ejemplo para muchos parámetros. Asegúrese de
reemplazar los valores de ejemplo de estos comandos por los valores adecuados
para la implementación antes de ejecutar estos comandos.
Creación de las subredes de cliente DNS
El primer paso es identificar las subredes o el espacio de direcciones IP de las regiones
para las que desea redirigir el tráfico. Por ejemplo, si desea redirigir el tráfico de ee. UU.
y Europa, debe identificar las subredes o los espacios de direcciones IP de estas
regiones.

Puede obtener esta información de mapas geo-IP. En función de estas distribuciones de

ip geográfica, debe crear las "subredes de cliente DNS". Una subred de cliente DNS es
una agrupación lógica de subredes IPv4 o IPv6 desde las que se envían consultas a un
servidor DNS.

Puede usar los siguientes comandos de Windows PowerShell para crear subredes de
cliente DNS.

PowerShell

Add-DnsServerClientSubnet -Name "USSubnet" -IPv4Subnet "[Link]/24"

Add-DnsServerClientSubnet -Name "EuropeSubnet" -IPv4Subnet "[Link]/24"

Para obtener más información, vea Add-DnsServerClientSubnet.

Crear ámbitos de zona

Una vez configuradas las subredes de cliente, debe particionar la zona cuyo tráfico
desea redirigir a dos ámbitos de zona diferentes, un ámbito para cada una de las
subredes de cliente DNS que ha configurado.

Por ejemplo, si desea redirigir el tráfico para el nombre DNS [Link] ,

debe crear dos ámbitos de zona diferentes en la zona de [Link], uno para ee.
UU. y otro para Europa.

Un ámbito de zona es una instancia única de la zona. Una zona DNS puede tener varios
ámbitos de zona, con cada ámbito de zona que contenga su propio conjunto de
registros DNS. El mismo registro puede estar presente en varios ámbitos, con
direcciones IP diferentes o las mismas direcciones IP.

７ Nota

De forma predeterminada, existe un ámbito de zona en las zonas DNS. Este ámbito
de zona tiene el mismo nombre que las operaciones DNS heredadas y de zona
 funcionan en este ámbito.

Puede usar los siguientes comandos Windows PowerShell para crear ámbitos de zona.

PowerShell

Add-DnsServerZoneScope -ZoneName "[Link]" -Name "USZoneScope"

Add-DnsServerZoneScope -ZoneName "[Link]" -Name "EuropeZoneScope"

Para obtener más información, vea Add-DnsServerZoneScope.

Agregar registros a los ámbitos de zona

Ahora debe agregar los registros que representan el host del servidor web en los dos
ámbitos de zona.

Por ejemplo, USZoneScope y EuropeZoneScope. En USZoneScope, puede agregar el

registro [Link] con la dirección IP [Link], que se encuentra en un
centro de datos de EE. UU.; y en EuropeZoneScope puede agregar el mismo registro
([Link] ) con la dirección IP [Link] en el centro de datos europeo.

Puede usar los siguientes comandos Windows PowerShell para agregar registros a los
ámbitos de zona.

PowerShell

Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name "www" -

IPv4Address "[Link]" -ZoneScope "USZoneScope"
Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name "www" -
IPv4Address "[Link]" -ZoneScope "EuropeZoneScope"

En este ejemplo, también debe usar los siguientes comandos de Windows PowerShell
para agregar registros al ámbito de zona predeterminado para asegurarse de que el
resto del mundo todavía puede acceder al servidor web [Link] desde
cualquiera de los dos centros de datos.

PowerShell

Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name "www" -

IPv4Address "[Link]"
Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name "www" -
IPv4Address "[Link]"
El parámetro ZoneScope no se incluye al agregar un registro en el ámbito
predeterminado. Esto es lo mismo que agregar registros a una zona DNS estándar.

Para obtener más información, vea Add-DnsServerResourceRecord.

Crear las directivas

Después de crear las subredes, las particiones (ámbitos de zona) y ha agregado
registros, debe crear directivas que conecten las subredes y las particiones, de modo
que, cuando una consulta procede de un origen en una de las subredes del cliente DNS,
se devuelve la respuesta de consulta desde el ámbito correcto de la zona. No se
requieren directivas para asignar el ámbito de zona predeterminado.

Puede usar los siguientes comandos Windows PowerShell para crear una directiva DNS
que vincule las subredes de cliente DNS y los ámbitos de zona.

PowerShell

Add-DnsServerQueryResolutionPolicy -Name "USPolicy" -Action ALLOW -

ClientSubnet "eq,USSubnet" -ZoneScope "USZoneScope,1" -ZoneName
"[Link]"
Add-DnsServerQueryResolutionPolicy -Name "EuropePolicy" -Action ALLOW -
ClientSubnet "eq,EuropeSubnet" -ZoneScope "EuropeZoneScope,1" -ZoneName
"[Link]"

Para obtener más información, vea Add-DnsServerQueryResolutionPolicy.

Ahora el servidor DNS está configurado con las directivas DNS necesarias para redirigir
el tráfico en función de la ubicación geográfica.

Cuando el servidor DNS recibe consultas de resolución de nombres, el servidor DNS

evalúa los campos de la solicitud DNS con respecto a las directivas DNS configuradas. Si
la dirección IP de origen de la solicitud de resolución de nombres coincide con
cualquiera de las directivas, el ámbito de zona asociado se usa para responder a la
consulta y el usuario se dirige al recurso más cercano geográficamente.

Puede crear miles de directivas DNS según los requisitos de administración del tráfico y
todas las directivas nuevas se aplican dinámicamente, sin reiniciar el servidor DNS, en las
consultas entrantes.
Uso de directiva DNS para la
administración del tráfico basada en la
ubicación geográfica con
implementaciones primarias-
secundarias
Artículo • 21/12/2022 • Tiempo de lectura: 9 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para aprender a crear una directiva DNS para la administración
del tráfico basada en la ubicación geográfica cuando la implementación de DNS incluye
servidores DNS principales y secundarios.

En el escenario anterior, Use DNS Policy for Geo-Location Based Traffic Management
with Primary Servers (Uso de la directiva DNS para la administración de tráfico basada
en Geo-Location con servidores principales), se proporcionan instrucciones para
configurar la directiva DNS para la administración del tráfico basada en la ubicación
geográfica en un servidor DNS principal. Sin embargo, en la infraestructura de Internet,
los servidores DNS se implementan ampliamente en un modelo secundario principal,
donde la copia grabable de una zona se almacena en servidores primarios
seleccionados y seguros, y las copias de solo lectura de la zona se mantienen en varios
servidores secundarios.

Los servidores secundarios usan los protocolos de transferencia de zona Transferencia

autoritativa (AXFR) y Transferencia de zona incremental (IXFR) para solicitar y recibir
actualizaciones de zona que incluyan nuevos cambios en las zonas de los servidores
DNS principales.

７ Nota

Para obtener más información sobre AXFR, consulte la solicitud del Grupo de tareas
de ingeniería de Internet (IETF) para comentarios 5936 . Para obtener más
información sobre IXFR, consulte la Solicitud de Comentarios 1995 del Grupo de
Trabajo de Ingeniería de Internet (IETF).
Ejemplo de administración de tráfico basada en
Primary-Secondary Geo-Location
A continuación se muestra un ejemplo de cómo puede usar la directiva DNS en una
implementación secundaria principal para lograr el redireccionamiento del tráfico en
función de la ubicación física del cliente que realiza una consulta DNS.

En este ejemplo se usan dos empresas ficticias: Contoso Cloud Services, que
proporciona soluciones de hospedaje de sitios web y de dominio, y Woodgrove Food
Services, que proporciona servicios de entrega de alimentos en varias ciudades de todo
el mundo y que tiene un sitio web denominado [Link].

Para asegurarse de que [Link] clientes obtengan una experiencia dinámica

desde su sitio web, Woodgrove quiere que los clientes europeos se dirijan al centro de
datos europeo y a los clientes americanos dirigidos al centro de datos de EE. UU. Los
clientes ubicados en otro lugar del mundo se pueden dirigir a cualquiera de los centros
de datos.

Contoso Cloud Services tiene dos centros de datos, uno en ee. UU. y otro en Europa, en
el que Contoso hospeda su portal de pedidos de alimentos para [Link].

La implementación de DNS de Contoso incluye dos servidores secundarios:

SecondaryServer1, con la dirección IP [Link]; y SecondaryServer2, con la dirección IP
[Link]. Estos servidores secundarios actúan como servidores de nombres en las dos
regiones diferentes, con SecondaryServer1 ubicado en Europa y SecondaryServer2
ubicados en ee. UU.

Hay una copia de zona de escritura principal en PrimaryServer (dirección IP [Link]),

donde se realizan los cambios de zona. Con las transferencias de zona normales a los
servidores secundarios, los servidores secundarios siempre están actualizados con los
nuevos cambios en la zona del servidor principal.

En la ilustración siguiente se muestra este escenario.

Funcionamiento del sistema de Primary-
Secondary DNS
Al implementar la administración del tráfico basada en la ubicación geográfica en una
implementación dns secundaria principal, es importante comprender cómo se producen
las transferencias normales de la zona secundaria principal antes de aprender sobre las
transferencias de nivel de ámbito de zona. En las secciones siguientes se proporciona
información sobre las transferencias de nivel de zona y ámbito de zona.

Transferencias de zona en una implementación principal-secundaria de DNS

Transferencias de nivel de ámbito de zona en una implementación principal-
secundaria de DNS

Transferencias de zona en una implementación principal-

secundaria de DNS
Puede crear una implementación principal-secundaria de DNS y sincronizar zonas con
los pasos siguientes.

1. Al instalar DNS, la zona principal se crea en el servidor DNS principal.

2. En el servidor secundario, cree las zonas y especifique los servidores principales.
3. En los servidores principales, puede agregar los servidores secundarios como
secundarias de confianza en la zona principal.
 4. Las zonas secundarias realizan una solicitud de transferencia de zona completa
(AXFR) y reciben la copia de la zona.
5. Cuando sea necesario, los servidores principales envían notificaciones a los
servidores secundarios sobre las actualizaciones de zona.
6. Los servidores secundarios realizan una solicitud de transferencia de zona
incremental (IXFR). Por este motivo, los servidores secundarios permanecen
sincronizados con el servidor principal.

Transferencias de nivel de ámbito de zona en una

implementación principal-secundaria de DNS
El escenario de administración del tráfico requiere pasos adicionales para dividir las
zonas en distintos ámbitos de zona. Por este motivo, se requieren pasos adicionales
para transferir los datos dentro de los ámbitos de zona a los servidores secundarios y
transferir directivas y subredes de cliente DNS a los servidores secundarios.

Después de configurar la infraestructura DNS con servidores primarios y secundarios,

DNS realiza automáticamente las transferencias de nivel de ámbito de zona mediante
los siguientes procesos.

Para garantizar la transferencia de nivel de ámbito de zona, los servidores DNS usan los
mecanismos de extensión para DNS (EDNS0) OPT RR. Todas las solicitudes de
transferencia de zona (AXFR o IXFR) de las zonas con ámbitos se originan con un EDNS0
OPT RR, cuyo identificador de opción se establece en "65433" de forma predeterminada.
Para obtener más información sobre EDNSO, consulte la solicitud IETF para comentarios
6891 .

El valor de OPT RR es el nombre del ámbito de zona para el que se envía la solicitud.
Cuando un servidor DNS principal recibe este paquete de un servidor secundario de
confianza, interpreta la solicitud como viene para ese ámbito de zona.

Si el servidor principal tiene ese ámbito de zona, responde con los datos de
transferencia (XFR) de ese ámbito. La respuesta contiene un OPT RR con el mismo
identificador de opción "65433" y el valor establecido en el mismo ámbito de zona. Los
servidores secundarios reciben esta respuesta, recuperan la información de ámbito de la
respuesta y actualizan ese ámbito concreto de la zona.

Después de este proceso, el servidor principal mantiene una lista de secundarias de

confianza que han enviado dicha solicitud de ámbito de zona para las notificaciones.

Para cualquier actualización adicional en un ámbito de zona, se envía una notificación

IXFR a los servidores secundarios, con el mismo OPT RR. El ámbito de zona que recibe
esa notificación realiza la solicitud IXFR que contiene ese OPT RR y el mismo proceso
que se ha descrito anteriormente.

Configuración de la directiva DNS para la

administración de tráfico basada en Primary-
Secondary Geo-Location
Antes de comenzar, asegúrese de haber completado todos los pasos del tema Uso de la
directiva DNS para Geo-Location Administración de tráfico basada en servidores
principales y el servidor DNS principal está configurado con zonas, ámbitos de zona,
subredes de cliente DNS y directiva DNS.

７ Nota

Las instrucciones de este tema para copiar subredes de cliente DNS, ámbitos de
zona y directivas DNS de servidores principales DNS a servidores secundarios DNS
son para la configuración y validación iniciales de DNS. En el futuro, es posible que
quiera cambiar la configuración de subredes de cliente DNS, ámbitos de zona y
directivas en el servidor principal. En esta circunstancia, puede crear scripts de
automatización para mantener los servidores secundarios sincronizados con el
servidor principal.

Para configurar la directiva DNS para las respuestas de consulta basadas en la ubicación
geográfica principal secundaria, debe realizar los pasos siguientes.

Creación de las zonas secundarias

Configuración del Configuración de transferencia de zona en la zona primaria
Copia de las subredes del cliente DNS
Crear los ámbitos de zona en el servidor secundario
Configuración de la directiva DNS

En las secciones siguientes se proporcionan instrucciones de configuración detalladas.

） Importante

En las secciones siguientes se incluyen comandos de ejemplo Windows PowerShell

que contienen valores de ejemplo para muchos parámetros. Asegúrese de
reemplazar los valores de ejemplo de estos comandos por los valores adecuados
para la implementación antes de ejecutar estos comandos.
 La pertenencia a DnsAdmins, o equivalente, es necesaria para realizar los
procedimientos siguientes.

Creación de las zonas secundarias

Puede crear la copia secundaria de la zona que desea replicar en SecondaryServer1 y
SecondaryServer2 (suponiendo que los cmdlets se ejecutan de forma remota desde un
único cliente de administración).

Por ejemplo, puede crear la copia secundaria de [Link] en

SecondaryServer1 y SecondarySesrver2.

Puede usar los siguientes comandos Windows PowerShell para crear las zonas
secundarias.

PowerShell

Add-DnsServerSecondaryZone -Name "[Link]" -ZoneFile

"[Link]" -MasterServers [Link] -ComputerName SecondaryServer1
Add-DnsServerSecondaryZone -Name "[Link]" -ZoneFile
"[Link]" -MasterServers [Link] -ComputerName SecondaryServer2

Para obtener más información, vea Add-DnsServerSecondaryZone.

Configuración del Configuración de transferencia de zona

en la zona primaria
Debe configurar los valores de zona principal para que:

1. Se permiten transferencias de zona desde el servidor principal a los servidores

secundarios especificados.
2. El servidor principal envía notificaciones de actualización de zona a los servidores
secundarios.

Puede usar los siguientes comandos de Windows PowerShell para configurar los valores
de transferencia de zona en la zona principal.

７ Nota

En el siguiente comando de ejemplo, el parámetro -Notify especifica que el

servidor principal enviará notificaciones sobre las actualizaciones a la lista de
secundarias seleccionada.
 PowerShell

Set-DnsServerPrimaryZone -Name "[Link]" -Notify Notify -

SecondaryServers "[Link],[Link]" -SecureSecondaries
TransferToSecureServers -ComputerName PrimaryServer

Para obtener más información, vea Set-DnsServerPrimaryZone.

Copia de las subredes del cliente DNS

Debe copiar las subredes de cliente DNS del servidor principal en los servidores
secundarios.

Puede usar los siguientes comandos de Windows PowerShell para copiar las subredes
en los servidores secundarios.

PowerShell

Get-DnsServerClientSubnet -ComputerName PrimaryServer | Add-

DnsServerClientSubnet -ComputerName SecondaryServer1
Get-DnsServerClientSubnet -ComputerName PrimaryServer | Add-
DnsServerClientSubnet -ComputerName SecondaryServer2

Para obtener más información, vea Add-DnsServerClientSubnet.

Crear los ámbitos de zona en el servidor secundario

Debe crear los ámbitos de zona en los servidores secundarios. En DNS, los ámbitos de
zona también comienzan a solicitar XFR desde el servidor principal. Con cualquier
cambio en los ámbitos de zona del servidor principal, se envía una notificación que
contiene la información del ámbito de zona a los servidores secundarios. Después, los
servidores secundarios pueden actualizar sus ámbitos de zona con cambios
incrementales.

Puede usar los siguientes comandos Windows PowerShell para crear los ámbitos de
zona en los servidores secundarios.

PowerShell

Get-DnsServerZoneScope -ZoneName "[Link]" -ComputerName

PrimaryServer|Add-DnsServerZoneScope -ZoneName "[Link]" -ComputerName
SecondaryServer1 -ErrorAction Ignore
Get-DnsServerZoneScope -ZoneName "[Link]" -ComputerName
PrimaryServer|Add-DnsServerZoneScope -ZoneName "[Link]" -ComputerName
SecondaryServer2 -ErrorAction Ignore
 ７ Nota

En estos comandos de ejemplo, se incluye el parámetro -ErrorAction Ignore ,

porque existe un ámbito de zona predeterminado en cada zona. El ámbito de zona
predeterminado no se puede crear ni eliminar. La canalización dará lugar a un
intento de crear ese ámbito y se producirá un error. Como alternativa, puede crear
los ámbitos de zona no predeterminados en dos zonas secundarias.

Para obtener más información, vea Add-DnsServerZoneScope.

Configuración de la directiva DNS

Una vez que haya creado las subredes, las particiones (ámbitos de zona) y haya
agregado registros, debe crear directivas que conecten las subredes y las particiones, de
modo que, cuando una consulta procede de un origen en una de las subredes del
cliente DNS, la respuesta de consulta se devuelve desde el ámbito correcto de la zona.
No se requieren directivas para asignar el ámbito de zona predeterminado.

Puede usar los siguientes comandos Windows PowerShell para crear una directiva DNS
que vincule las subredes de cliente DNS y los ámbitos de zona.

PowerShell

$policy = Get-DnsServerQueryResolutionPolicy -ZoneName "[Link]" -

ComputerName PrimaryServer
$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "[Link]" -
ComputerName SecondaryServer1
$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "[Link]" -
ComputerName SecondaryServer2

Para obtener más información, vea Add-DnsServerQueryResolutionPolicy.

Ahora los servidores DNS secundarios están configurados con las directivas DNS
necesarias para redirigir el tráfico en función de la ubicación geográfica.

Cuando el servidor DNS recibe consultas de resolución de nombres, el servidor DNS

evalúa los campos de la solicitud DNS con respecto a las directivas DNS configuradas. Si
la dirección IP de origen de la solicitud de resolución de nombres coincide con
cualquiera de las directivas, el ámbito de zona asociado se usa para responder a la
consulta y el usuario se dirige al recurso más cercano geográficamente.
Puede crear miles de directivas DNS según los requisitos de administración del tráfico y
todas las directivas nuevas se aplican dinámicamente, sin reiniciar el servidor DNS, en las
consultas entrantes.
Uso de la directiva de DNS para las
respuestas DNS inteligentes basadas en
la hora del día
Artículo • 21/12/2022 • Tiempo de lectura: 9 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para aprender a distribuir el tráfico de la aplicación entre
diferentes instancias distribuidas geográficamente de una aplicación mediante directivas
DNS basadas en la hora del día.

Este escenario es útil en situaciones en las que desea dirigir el tráfico en una zona
horaria a servidores de aplicaciones alternativos, como servidores web, que se
encuentran en otra zona horaria. Esto le permite equilibrar la carga del tráfico entre
instancias de aplicación durante períodos de tiempo máximo cuando los servidores
principales se sobrecargan con el tráfico.

Ejemplo de respuestas DNS inteligentes basadas en la

hora del día
A continuación se muestra un ejemplo de cómo puede usar la directiva DNS para
equilibrar el tráfico de la aplicación en función de la hora del día.

En este ejemplo se usa una empresa ficticia, Contoso Gift Services, que proporciona
soluciones de regalos en línea en todo el mundo a través de su sitio web,
[Link].

El sitio web de [Link] se hospeda en dos centros de datos, uno en

Seattle (Norteamérica) y otro en Dublín (Europa). Los servidores DNS están configurados
para enviar respuestas con reconocimiento de ubicación geográfica mediante la
directiva DNS. Con un aumento reciente en el negocio, [Link] tiene un
mayor número de visitantes cada día, y algunos de los clientes han notificado
problemas de disponibilidad del servicio.

Contoso Gift Services realiza un análisis del sitio y detecta que cada noche entre las 6 p.
m. y las 9 p. m. local, hay un aumento en el tráfico a los servidores web. Los servidores
web no se pueden escalar para controlar el aumento del tráfico en estas horas punta, lo
que da lugar a la denegación de servicio a los clientes. La misma sobrecarga de tráfico
de hora punta se produce en los centros de datos europeos y americanos. En otros
momentos del día, los servidores controlan los volúmenes de tráfico que están muy por
debajo de su capacidad máxima.

Para asegurarse de que [Link] clientes obtengan una experiencia

dinámica desde el sitio web, Contoso Gift Services quiere redirigir cierto tráfico de
Dublín a los servidores de aplicaciones de Seattle entre las 6 p. m. y las 9 p. m. en
Dublín; y quieren redirigir el tráfico de Seattle a los servidores de aplicaciones de Dublín
entre las 6 p. m. y las 9 p. m. en Seattle.

En la ilustración siguiente se muestra este escenario.

Funcionamiento de las respuestas DNS inteligentes

basadas en la hora del día
Cuando el servidor DNS se configura con la directiva DNS de hora del día, entre las 6 p.
m. y las 9 p. m. en cada ubicación geográfica, el servidor DNS hace lo siguiente.

Responde a las cuatro primeras consultas que recibe con la dirección IP del
servidor web en el centro de datos local.
Responde a la quinta consulta que recibe con la dirección IP del servidor web en el
centro de datos remoto.
Este comportamiento basado en directivas descarga veinte por ciento de la carga de
tráfico del servidor web local en el servidor web remoto, lo que facilita la tensión en el
servidor de aplicaciones local y mejora el rendimiento del sitio para los clientes.

Durante las horas de poca actividad, los servidores DNS realizan la administración
normal del tráfico basado en ubicaciones geográficas. Además, los clientes DNS que
envían consultas desde ubicaciones distintas de Norteamérica o Europa, el servidor DNS
equilibra el tráfico entre los centros de datos de Seattle y Dublín.

Cuando se configuran varias directivas DNS en DNS, son un conjunto ordenado de

reglas y el DNS los procesa de mayor prioridad a prioridad más baja. DNS usa la primera
directiva que coincide con las circunstancias, incluida la hora del día. Por este motivo, las
directivas más específicas deben tener mayor prioridad. Si crea directivas de hora de día
y les da prioridad alta en la lista de directivas, los procesos DNS y las usa primero si
coinciden con los parámetros de la consulta del cliente DNS y los criterios definidos en
la directiva. Si no coinciden, DNS mueve la lista de directivas para procesar las directivas
predeterminadas hasta que encuentre una coincidencia.

Para obtener más información sobre los tipos y criterios de directiva, consulte
Introducción a las directivas DNS.

Configuración de la directiva DNS para respuestas DNS

inteligentes basadas en la hora del día
Para configurar la directiva DNS para las respuestas de consulta basadas en el equilibrio
de carga de la aplicación a la hora del día, debe realizar los pasos siguientes.

Creación de subredes de cliente DNS

Creación de los ámbitos de zona
Agregar registros a los ámbitos de zona
Creación de las directivas DNS

７ Nota

Debe realizar estos pasos en el servidor DNS que es autoritativo para la zona que
desea configurar. La pertenencia a DnsAdmins, o equivalente, es necesaria para
realizar los procedimientos siguientes.

En las secciones siguientes se proporcionan instrucciones de configuración detalladas.

） Importante
 En las secciones siguientes se incluyen comandos de ejemplo Windows PowerShell
que contienen valores de ejemplo para muchos parámetros. Asegúrese de
reemplazar los valores de ejemplo de estos comandos por los valores adecuados
para la implementación antes de ejecutar estos comandos.

Creación de subredes de cliente DNS

El primer paso es identificar las subredes o el espacio de direcciones IP de las regiones

para las que desea redirigir el tráfico. Por ejemplo, si desea redirigir el tráfico de ee. UU.
y Europa, debe identificar las subredes o los espacios de direcciones IP de estas
regiones.

Puede obtener esta información de mapas geo-IP. En función de estas distribuciones de

IP geográfica, debe crear las "subredes de cliente DNS". Una subred de cliente DNS es
una agrupación lógica de subredes IPv4 o IPv6 desde las que se envían consultas a un
servidor DNS.

Puede usar los siguientes comandos de Windows PowerShell para crear subredes de
cliente DNS.

PowerShell

Add-DnsServerClientSubnet -Name "AmericaSubnet" -IPv4Subnet "[Link]/24",

"[Link]/24"

Add-DnsServerClientSubnet -Name "EuropeSubnet" -IPv4Subnet "[Link]/24",

"[Link]/24"

Para obtener más información, consulte Add-DnsServerClientSubnet.

Creación de los ámbitos de zona

Una vez configuradas las subredes de cliente, debe particionar la zona cuyo tráfico
desea redirigir a dos ámbitos de zona diferentes, un ámbito para cada una de las
subredes de cliente DNS que ha configurado.

Por ejemplo, si desea redirigir el tráfico para el nombre DNS

[Link] , debe crear dos ámbitos de zona diferentes en la zona
[Link], uno para ee. UU. y otro para Europa.

Un ámbito de zona es una instancia única de la zona. Una zona DNS puede tener varios
ámbitos de zona, con cada ámbito de zona que contiene su propio conjunto de
registros DNS. El mismo registro puede estar presente en varios ámbitos, con diferentes
direcciones IP o las mismas direcciones IP.

７ Nota

De forma predeterminada, existe un ámbito de zona en las zonas DNS. Este ámbito
de zona tiene el mismo nombre que la zona y las operaciones DNS heredadas
funcionan en este ámbito.

Puede usar los siguientes comandos de Windows PowerShell para crear ámbitos de
zona.

PowerShell

Add-DnsServerZoneScope -ZoneName "[Link]" -Name

"SeattleZoneScope"

Add-DnsServerZoneScope -ZoneName "[Link]" -Name

"DublinZoneScope"

Para obtener más información, vea Add-DnsServerZoneScope.

Agregar registros a los ámbitos de zona

Ahora debe agregar los registros que representan el host del servidor web en los dos
ámbitos de zona.

Por ejemplo, en SeattleZoneScope, el registro [Link] se agrega

con la dirección IP [Link], que se encuentra en un centro de datos de Seattle. Del
mismo modo, en DublinZoneScope, el registro [Link] se agrega
con la dirección IP [Link] en el centro de datos de Dublín.

Puede usar los siguientes comandos Windows PowerShell para agregar registros a los
ámbitos de zona.

PowerShell

Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name

"www" -IPv4Address "[Link]" -ZoneScope "SeattleZoneScope"

Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name

"www" -IPv4Address "[Link]" -ZoneScope "DublinZoneScope"
El parámetro ZoneScope no se incluye al agregar un registro en el ámbito
predeterminado. Esto es lo mismo que agregar registros a una zona DNS estándar.

Para obtener más información, vea Add-DnsServerResourceRecord.

Creación de las directivas DNS

Después de crear las subredes, las particiones (ámbitos de zona) y ha agregado
registros, debe crear directivas que conecten las subredes y las particiones, de modo
que, cuando una consulta procede de un origen en una de las subredes del cliente DNS,
se devuelve la respuesta de consulta desde el ámbito correcto de la zona. No se
requieren directivas para asignar el ámbito de zona predeterminado.

Después de configurar estas directivas DNS, el comportamiento del servidor DNS es el

siguiente:

1. Los clientes DNS europeos reciben la dirección IP del servidor web en el centro de
datos de Dublín en su respuesta de consulta DNS.
2. Los clientes DNS estadounidenses reciben la dirección IP del servidor web en el
centro de datos de Seattle en su respuesta de consulta DNS.
3. Entre las 6 p. m. y las 9 p. m. en Dublín, el 20 % de las consultas de los clientes
europeos reciben la dirección IP del servidor web en el centro de datos de Seattle
en su respuesta de consulta DNS.
4. Entre las 6 p. m. y las 9 p. m. en Seattle, el 20 % de las consultas de los clientes
estadounidenses reciben la dirección IP del servidor web en el centro de datos de
Dublín en su respuesta de consulta DNS.
5. La mitad de las consultas del resto del mundo reciben la dirección IP del centro de
datos de Seattle y la otra mitad reciben la dirección IP del centro de datos de
Dublín.

Puede usar los siguientes comandos Windows PowerShell para crear una directiva DNS
que vincule las subredes de cliente DNS y los ámbitos de zona.

７ Nota

En este ejemplo, el servidor DNS se encuentra en la zona horaria GMT, por lo que
los períodos de tiempo máximo de hora deben expresarse en la hora GMT
equivalente.

PowerShell
 Add-DnsServerQueryResolutionPolicy -Name "America6To9Policy" -Action ALLOW -
ClientSubnet "eq,AmericaSubnet" -ZoneScope
"SeattleZoneScope,4;DublinZoneScope,1" -TimeOfDay "EQ,01:00-04:00" -ZoneName
"[Link]" -ProcessingOrder 1

Add-DnsServerQueryResolutionPolicy -Name "Europe6To9Policy" -Action ALLOW -

ClientSubnet "eq,EuropeSubnet" -ZoneScope
"SeattleZoneScope,1;DublinZoneScope,4" -TimeOfDay "EQ,17:00-20:00" -ZoneName
"[Link]" -ProcessingOrder 2

Add-DnsServerQueryResolutionPolicy -Name "AmericaPolicy" -Action ALLOW -

ClientSubnet "eq,AmericaSubnet" -ZoneScope "SeattleZoneScope,1" -ZoneName
"[Link]" -ProcessingOrder 3

Add-DnsServerQueryResolutionPolicy -Name "EuropePolicy" -Action ALLOW -

ClientSubnet "eq,EuropeSubnet" -ZoneScope "DublinZoneScope,1" -ZoneName
"[Link]" -ProcessingOrder 4

Add-DnsServerQueryResolutionPolicy -Name "RestOfWorldPolicy" -Action ALLOW -

ZoneScope "DublinZoneScope,1;SeattleZoneScope,1" -ZoneName
"[Link]" -ProcessingOrder 5

Para obtener más información, vea Add-DnsServerQueryResolutionPolicy.

Ahora el servidor DNS está configurado con las directivas DNS necesarias para redirigir
el tráfico en función de la ubicación geográfica y la hora del día.

Cuando el servidor DNS recibe consultas de resolución de nombres, el servidor DNS

evalúa los campos de la solicitud DNS con respecto a las directivas DNS configuradas. Si
la dirección IP de origen de la solicitud de resolución de nombres coincide con
cualquiera de las directivas, el ámbito de zona asociado se usa para responder a la
consulta y el usuario se dirige al recurso más cercano geográficamente.

Puede crear miles de directivas DNS según los requisitos de administración del tráfico y
todas las directivas nuevas se aplican dinámicamente, sin reiniciar el servidor DNS, en las
consultas entrantes.
Respuestas DNS basadas en la hora del
día con un servidor de aplicaciones en la
nube de Azure
Artículo • 21/12/2022 • Tiempo de lectura: 7 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para aprender a distribuir el tráfico de la aplicación entre
diferentes instancias distribuidas geográficamente de una aplicación mediante directivas
DNS basadas en la hora del día.

Este escenario es útil en situaciones en las que desea dirigir el tráfico en una zona
horaria a servidores de aplicaciones alternativos, como servidores web hospedados en
Microsoft Azure, que se encuentran en otra zona horaria. Esto le permite equilibrar la
carga del tráfico entre instancias de aplicación durante períodos de tiempo máximo
cuando los servidores principales se sobrecargan con el tráfico.

７ Nota

Para obtener información sobre cómo usar la directiva DNS para respuestas DNS
inteligentes sin usar Azure, consulte Uso de la directiva DNS para respuestas DNS
inteligentes basadas en la hora del día.

Ejemplo de respuestas DNS inteligentes

basadas en la hora del día con Azure Cloud
App Server
A continuación se muestra un ejemplo de cómo puede usar la directiva DNS para
equilibrar el tráfico de la aplicación en función de la hora del día.

En este ejemplo se usa una empresa ficticia, Contoso Gift Services, que proporciona
soluciones de regalos en línea en todo el mundo a través de su sitio web,
[Link].

El sitio web de [Link] solo se hospeda en un único centro de datos

local en Seattle (con ip pública [Link]).
El servidor DNS también se encuentra en el centro de datos local.

Con un aumento reciente en el negocio, [Link] tiene un mayor

número de visitantes cada día, y algunos de los clientes han notificado problemas de
disponibilidad del servicio.

Contoso Gift Services realiza un análisis del sitio y detecta que cada noche entre las 6 p.
m. y la hora local de 9 p. m., hay un aumento en el tráfico al servidor web de Seattle. El
servidor web no puede escalar para controlar el aumento del tráfico en estas horas
punta, lo que da lugar a la denegación de servicio a los clientes.

Para asegurarse de que [Link] clientes obtengan una experiencia de

respuesta desde el sitio web, Contoso Gift Services decide que durante estas horas
alquilará una máquina virtual (VM) en Microsoft Azure para hospedar una copia de su
servidor web.

Contoso Gift Services obtiene una dirección IP pública de Azure para la máquina virtual
([Link]) y desarrolla la automatización para implementar el servidor web todos los
días en Azure entre las 5 y las 10 p. m., lo que permite un período de contingencia de
una hora.

７ Nota

Para más información sobre las máquinas virtuales de Azure, consulte Virtual
Machines documentación.

Los servidores DNS se configuran con ámbitos de zona y directivas DNS para que entre
las 5 y las 9 p.m. todos los días, el 30 % de las consultas se envíen a la instancia del
servidor web que se ejecuta en Azure.

En la ilustración siguiente se muestra este escenario.

Funcionamiento de las respuestas DNS
inteligentes basadas en la hora del día con App
de Azure Server
En este artículo se muestra cómo configurar el servidor DNS para responder a consultas
DNS con dos direcciones IP de servidor de aplicaciones diferentes: un servidor web está
en Seattle y el otro se encuentra en un centro de datos de Azure.

Después de la configuración de una nueva directiva DNS basada en las horas punta de 6
p.m. a 9 p.m. en Seattle, el servidor DNS envía setenta por ciento de las respuestas DNS
a los clientes que contienen la dirección IP del servidor web de Seattle y treinta por
ciento de las respuestas DNS a los clientes que contienen la dirección IP del servidor
web de Azure, de este modo, dirigir el tráfico de cliente al nuevo servidor web de Azure
e impedir que el servidor web de Seattle se sobrecargue.

En el resto de horas del día, el procesamiento de consultas normal tiene lugar y las
respuestas se envían desde el ámbito de zona predeterminado que contiene un registro
para el servidor web en el centro de datos local.

El TTL de 10 minutos en el registro de Azure garantiza que el registro ha expirado de la

memoria caché LDNS antes de quitar la máquina virtual de Azure. Una de las ventajas
de este escalado es que puede mantener los datos DNS en el entorno local y mantener
el escalado horizontal a Azure según requiera la demanda.

Configuración de la directiva DNS para

respuestas DNS inteligentes basadas en la hora
del día con App de Azure Servidor
Para configurar la directiva DNS para las respuestas de consulta basadas en el equilibrio
de carga de la aplicación a la hora del día, debe realizar los pasos siguientes.

Creación de los ámbitos de zona

Agregar registros a los ámbitos de zona
Creación de las directivas DNS

７ Nota

Debe realizar estos pasos en el servidor DNS que es autoritativo para la zona que
desea configurar. La pertenencia a DnsAdmins, o equivalente, es necesaria para
realizar los procedimientos siguientes.

En las secciones siguientes se proporcionan instrucciones de configuración detalladas.

） Importante

En las secciones siguientes se incluyen comandos de ejemplo Windows PowerShell

que contienen valores de ejemplo para muchos parámetros. Asegúrese de
reemplazar los valores de ejemplo de estos comandos por los valores adecuados
para la implementación antes de ejecutar estos comandos.

Creación de los ámbitos de zona

Un ámbito de zona es una instancia única de la zona. Una zona DNS puede tener varios
ámbitos de zona, con cada ámbito de zona que contiene su propio conjunto de
registros DNS. El mismo registro puede estar presente en varios ámbitos, con diferentes
direcciones IP o las mismas direcciones IP.

７ Nota
 De forma predeterminada, existe un ámbito de zona en las zonas DNS. Este ámbito
de zona tiene el mismo nombre que la zona y las operaciones DNS heredadas
funcionan en este ámbito.

Puede usar el siguiente comando de ejemplo para crear un ámbito de zona para
hospedar los registros de Azure.

Add-DnsServerZoneScope -ZoneName "[Link]" -Name

"AzureZoneScope"

Para obtener más información, consulte Add-DnsServerZoneScope.

Agregar registros a los ámbitos de zona

El siguiente paso consiste en agregar los registros que representan el host del servidor
web en los ámbitos de zona.

En AzureZoneScope, el registro [Link] se agrega con la

dirección IP [Link], que se encuentra en la nube pública de Azure.

Del mismo modo, en el ámbito de zona predeterminado ([Link]), se

agrega un registro ([Link]) con la dirección IP [Link] del
servidor web que se ejecuta en el centro de datos local de Seattle.

En el segundo cmdlet siguiente, no se incluye el parámetro –ZoneScope. Por este

motivo, los registros se agregan en el zonescope predeterminado.

Además, el TTL del registro de las máquinas virtuales de Azure se mantiene en 600 (10
minutos) para que el LDNS no lo almacene en caché durante más tiempo, lo que
interferiría con el equilibrio de carga. Además, las máquinas virtuales de Azure están
disponibles durante 1 hora adicional como contingencia para asegurarse de que incluso
los clientes con registros almacenados en caché puedan resolverse.

Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name

"www" -IPv4Address "[Link]" -ZoneScope "AzureZoneScope" –TimeToLive
600

Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name

"www" -IPv4Address "[Link]"
Para obtener más información, vea Add-DnsServerResourceRecord.

Creación de las directivas DNS

Una vez creados los ámbitos de zona, puede crear directivas DNS que distribuyan las
consultas entrantes en estos ámbitos para que se produzca lo siguiente.

1. De 6 p. m. a 9 p. m. diariamente, el 30 % de los clientes reciben la dirección IP del

servidor web en el centro de datos de Azure en la respuesta DNS, mientras que el
70 % de los clientes reciben la dirección IP del servidor web local de Seattle.
2. En todo momento, todos los clientes reciben la dirección IP del servidor web local
de Seattle.

La hora del día debe expresarse en la hora local del servidor DNS.

Puede usar el siguiente comando de ejemplo para crear la directiva DNS.

Add-DnsServerQueryResolutionPolicy -Name "Contoso6To9Policy" -Action ALLOW -

ZoneScope "[Link],7;AzureZoneScope,3" –TimeOfDay “EQ,18:00-
21:00” -ZoneName "[Link]" –ProcessingOrder 1

Para obtener más información, vea Add-DnsServerQueryResolutionPolicy.

Ahora el servidor DNS está configurado con las directivas DNS necesarias para redirigir
el tráfico al servidor web de Azure en función de la hora del día.

Anote la expresión:

-ZoneScope "[Link],7;AzureZoneScope,3" –TimeOfDay “EQ,18:00-

21:00”

Esta expresión configura el servidor DNS con una combinación ZoneScope y weight que
indica al servidor DNS que envíe la dirección IP del servidor web de Seattle setenta por
ciento del tiempo, al enviar la dirección IP del servidor web de Azure treinta por ciento
del tiempo.

Puede crear miles de directivas DNS según los requisitos de administración del tráfico y
todas las directivas nuevas se aplican dinámicamente, sin reiniciar el servidor DNS, en las
consultas entrantes.
Uso de la directiva DNS para Split-Brain
DNS en Active Directory
Artículo • 21/12/2022 • Tiempo de lectura: 7 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para aprovechar las funcionalidades de administración del tráfico
de las directivas DNS para implementaciones de cerebro dividido con zonas DNS
integradas de Active Directory en Windows Server 2016.

En Windows Server 2016, la compatibilidad con directivas DNS se amplía a las zonas
DNS integradas de Active Directory. La integración de Active Directory proporciona
funcionalidades de alta disponibilidad multimaestro al servidor DNS.

Anteriormente, este escenario requería que los administradores de DNS mantengan dos
servidores DNS diferentes, cada uno de los cuales proporciona servicios a cada conjunto
de usuarios, internos y externos. Si solo se delegaron algunos registros dentro de la
zona con cerebro dividido o ambas instancias de la zona (interna y externa) al mismo
dominio primario, esto se convirtió en un problema de administración.

７ Nota

Las implementaciones de DNS se dividen en cerebro cuando hay dos

versiones de una sola zona, una versión para los usuarios internos en la
intranet de la organización y una versión para los usuarios externos, que
suelen ser usuarios de Internet.
En el tema Uso de la directiva DNS para Split-Brain implementación de DNS
se explica cómo puede usar las directivas dns y los ámbitos de zona para
implementar un sistema DNS de cerebro dividido en un único servidor DNS
Windows Server 2016.

Ejemplo Split-Brain DNS en Active Directory

En este ejemplo se usa una empresa ficticia, Contoso, que mantiene un sitio web
profesional en [Link] .

El sitio tiene dos versiones, una para los usuarios internos donde están disponibles las
publicaciones de trabajos internos. Este sitio interno está disponible en la dirección IP
local [Link].

La segunda versión es la versión pública del mismo sitio, que está disponible en la
dirección IP pública [Link].

En ausencia de la directiva DNS, el administrador debe hospedar estas dos zonas en

servidores DNS de servidor Windows independientes y administrarlas por separado.

Con las directivas DNS, estas zonas ahora se pueden hospedar en el mismo servidor
DNS.

Si el servidor DNS para [Link] está integrado en Active Directory y está

escuchando en dos interfaces de red, el administrador dns de Contoso puede seguir los
pasos de este tema para lograr una implementación de cerebro dividido.

El administrador dns configura las interfaces del servidor DNS con las siguientes
direcciones IP.

El adaptador de red accesible desde Internet está configurado con una dirección IP
pública de [Link] para consultas externas.
El adaptador de red accesible desde la intranet está configurado con una dirección
IP privada de [Link] para consultas internas.

En la ilustración siguiente se muestra este escenario.

Funcionamiento de la directiva DNS para Split-
Brain DNS en Active Directory
Cuando el servidor DNS está configurado con las directivas DNS necesarias, cada
solicitud de resolución de nombres se evalúa con respecto a las directivas del servidor
DNS.

La interfaz de servidor se usa en este ejemplo como criterios para diferenciar entre los
clientes internos y externos.

Si la interfaz del servidor en la que se recibe la consulta coincide con cualquiera de las
directivas, el ámbito de zona asociado se usa para responder a la consulta.

Por lo tanto, en nuestro ejemplo, las consultas DNS para [Link] que
se reciben en la dirección IP privada ([Link]) reciben una respuesta DNS que contiene
una dirección IP interna; y las consultas DNS que se reciben en la interfaz de red pública
reciben una respuesta DNS que contiene la dirección IP pública en el ámbito de zona
predeterminado (es lo mismo que la resolución de consulta normal).

La compatibilidad con las actualizaciones de DNS dinámico (DDNS) y el scavenging solo

se admiten en el ámbito de zona predeterminado. Dado que los clientes internos tienen
servicio por el ámbito de zona predeterminado, los administradores dns de Contoso
pueden seguir usando los mecanismos existentes (DNS dinámicos o estáticos) para
actualizar los registros en [Link]. En el caso de los ámbitos de zona no
predeterminados (como el ámbito externo de este ejemplo), la compatibilidad con
DDNS o scavenging no está disponible.

Alta disponibilidad de directivas

Las directivas DNS no están integradas en Active Directory. Por este motivo, las
directivas DNS no se replican en los demás servidores DNS que hospedan la misma
zona integrada de Active Directory.

Las directivas DNS se almacenan en el servidor DNS local. Puede exportar fácilmente
directivas DNS de un servidor a otro mediante el ejemplo siguiente Windows PowerShell
comandos.

PowerShell

$policies = Get-DnsServerQueryResolutionPolicy -ZoneName "[Link]" -

ComputerName Server01
$policies | Add-DnsServerQueryResolutionPolicy -ZoneName "[Link]" -
ComputerName Server02
Para obtener más información, consulte los siguientes temas de referencia Windows
PowerShell.

Get-DnsServerQueryResolutionPolicy
Add-DnsServerQueryResolutionPolicy

Configuración de la directiva DNS para Split-

Brain DNS en Active Directory
Para configurar dns Split-Brain implementación mediante la directiva DNS, debe usar las
secciones siguientes, que proporcionan instrucciones de configuración detalladas.

Adición de la zona integrada de Active Directory

Puede usar el siguiente comando de ejemplo para agregar la zona de [Link]
integrada de Active Directory al servidor DNS.

PowerShell

Add-DnsServerPrimaryZone -Name "[Link]" -ReplicationScope "Domain" -

PassThru

Para obtener más información, vea Add-DnsServerPrimaryZone.

Crear los ámbitos de la zona

Puede usar esta sección para crear particiones de la zona [Link] para crear un
ámbito de zona externa.

Un ámbito de zona es una instancia única de la zona. Una zona DNS puede tener varios
ámbitos de zona, con cada ámbito de zona que contiene su propio conjunto de
registros DNS. El mismo registro puede estar presente en varios ámbitos, con diferentes
direcciones IP o las mismas direcciones IP.

Dado que va a agregar este nuevo ámbito de zona en una zona integrada de Active
Directory, el ámbito de zona y los registros que contiene se replicarán a través de Active
Directory en otros servidores de réplica del dominio.

De forma predeterminada, existe un ámbito de zona en cada zona DNS. Este ámbito de
zona tiene el mismo nombre que la zona y las operaciones DNS heredadas funcionan en
este ámbito. Este ámbito de zona predeterminado hospedará la versión interna de
[Link] .
Puede usar el siguiente comando de ejemplo para crear el ámbito de zona en el servidor
DNS.

PowerShell

Add-DnsServerZoneScope -ZoneName "[Link]" -Name "external"

Para obtener más información, vea Add-DnsServerZoneScope.

Agregar registros a los ámbitos de zona

El siguiente paso consiste en agregar los registros que representan el host del servidor
web en los dos ámbitos de zona: externos y predeterminados (para clientes internos).

En el ámbito de zona interna predeterminado, el registro [Link] se

agrega con la dirección IP [Link], que es una dirección IP privada; y en el ámbito de la
zona externa, se agrega el mismo registro ([Link]) con la dirección IP
pública [Link].

Los registros (tanto en el ámbito de zona interna predeterminado como en el ámbito de

la zona externa) se replicarán automáticamente en el dominio con sus respectivos
ámbitos de zona.

Puede usar el siguiente comando de ejemplo para agregar registros a los ámbitos de
zona en el servidor DNS.

PowerShell

Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name "[Link]" -

IPv4Address "[Link]" -ZoneScope "external"
Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name "[Link]" -
IPv4Address "[Link]”

７ Nota

El parámetro –ZoneScope no se incluye cuando el registro se agrega al ámbito de

zona predeterminado. Esta acción es la misma que agregar registros a una zona
normal.

Para obtener más información, vea Add-DnsServerResourceRecord.

Creación de las directivas DNS

Después de haber identificado las interfaces de servidor para la red externa y la red
interna y ha creado los ámbitos de zona, debe crear directivas DNS que conecten los
ámbitos de zona interna y externa.

７ Nota

En este ejemplo se usa la interfaz de servidor (el parámetro -ServerInterface en el

comando de ejemplo siguiente) como criterios para diferenciar entre los clientes
internos y externos. Otro método para diferenciar entre clientes externos e internos
es mediante el uso de subredes de cliente como criterios. Si puede identificar las
subredes a las que pertenecen los clientes internos, puede configurar la directiva
DNS para diferenciar en función de la subred del cliente. Para obtener información
sobre cómo configurar la administración del tráfico mediante criterios de subred de
cliente, consulte Uso de la directiva DNS para Geo-Location administración de
tráfico basada en servidores principales.

Después de configurar directivas, cuando se recibe una consulta DNS en la interfaz

pública, la respuesta se devuelve desde el ámbito externo de la zona.

７ Nota

No se requieren directivas para asignar el ámbito de zona interna predeterminado.

PowerShell

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action

ALLOW -ServerInterface "eq,[Link]" -ZoneScope "external,1" -ZoneName
[Link]

７ Nota

[Link] es la dirección IP en la interfaz de red pública.

Para obtener más información, vea Add-DnsServerQueryResolutionPolicy.

Ahora el servidor DNS está configurado con las directivas DNS necesarias para un
servidor de nombres de cerebro dividido con una zona DNS integrada de Active
Directory.

Puede crear miles de directivas DNS según los requisitos de administración del tráfico y
todas las directivas nuevas se aplican dinámicamente, sin reiniciar el servidor DNS, en las
consultas entrantes.
Uso de la directiva de DNS para la
implementación de DNS de cerebro
dividido
Artículo • 21/12/2022 • Tiempo de lectura: 9 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para aprender a configurar la directiva DNS en Windows Server®
2016 para las implementaciones de DNS de cerebro dividido, donde hay dos versiones
de una sola zona, una para los usuarios internos de la intranet de la organización y otra
para los usuarios externos, que suelen ser usuarios de Internet.

７ Nota

Para obtener información sobre cómo usar la directiva DNS para la implementación
de DNS de cerebro dividido con zonas DNS integradas de Active Directory,
consulte Uso de la directiva DNS para Split-Brain DNS en Active Directory.

Anteriormente, este escenario requería que los administradores de DNS mantengan dos
servidores DNS diferentes, cada uno proporcionando servicios a cada conjunto de
usuarios, interno y externo. Si solo se delegaron algunos registros dentro de la zona con
cerebro dividido o ambas instancias de la zona (interna y externa) al mismo dominio
primario, esto se convirtió en un problema de administración.

Otro escenario de configuración para la implementación de cerebro dividido es el

control de recursividad selectiva para la resolución de nombres DNS. En algunas
circunstancias, se espera que los servidores DNS de Enterprise realicen una resolución
recursiva a través de Internet para los usuarios internos, mientras que también deben
actuar como servidores de nombres autoritativos para usuarios externos y bloquear la
recursividad para ellos.

En este tema se incluyen las siguientes secciones.

Ejemplo de implementación de Split-Brain DNS

Ejemplo de control de recursividad selectiva de DNS

Ejemplo de implementación de Split-Brain DNS

A continuación se muestra un ejemplo de cómo puede usar la directiva DNS para lograr
el escenario descrito anteriormente de DNS de cerebro dividido.

Esta sección contiene los temas siguientes.

Funcionamiento de la implementación de Split-Brain DNS

Configuración de la implementación de dns Split-Brain

En este ejemplo se usa una empresa ficticia, Contoso, que mantiene un sitio web
profesional en [Link] .

El sitio tiene dos versiones, una para los usuarios internos donde están disponibles las
publicaciones de trabajos internos. Este sitio interno está disponible en la dirección IP
local [Link].

La segunda versión es la versión pública del mismo sitio, que está disponible en la
dirección IP pública [Link].

En ausencia de la directiva DNS, el administrador debe hospedar estas dos zonas en

servidores DNS de servidor Windows independientes y administrarlas por separado.

Con las directivas DNS, estas zonas ahora se pueden hospedar en el mismo servidor
DNS.

En la ilustración siguiente se muestra este escenario.

Funcionamiento de la implementación de Split-
Brain DNS
Cuando el servidor DNS está configurado con las directivas DNS necesarias, cada
solicitud de resolución de nombres se evalúa con las directivas del servidor DNS.

La interfaz de servidor se usa en este ejemplo como criterios para diferenciar entre los
clientes internos y externos.

Si la interfaz de servidor en la que se recibe la consulta coincide con cualquiera de las

directivas, el ámbito de zona asociado se usa para responder a la consulta.

Por lo tanto, en nuestro ejemplo, las consultas DNS para [Link] que
se reciben en la dirección IP privada ([Link]) reciben una respuesta DNS que contiene
una dirección IP interna; y las consultas DNS que se reciben en la interfaz de red pública
reciben una respuesta DNS que contiene la dirección IP pública en el ámbito de zona
predeterminado (es lo mismo que la resolución de consulta normal).

Configuración de la implementación de dns

Split-Brain
Para configurar la implementación de Split-Brain DNS mediante la directiva DNS, debe
seguir estos pasos.

Crear los ámbitos de zona

Agregar registros a los ámbitos de zona
Creación de las directivas DNS

En las secciones siguientes se proporcionan instrucciones de configuración detalladas.

） Importante

En las secciones siguientes se incluyen comandos de ejemplo Windows PowerShell

que contienen valores de ejemplo para muchos parámetros. Asegúrese de
reemplazar los valores de ejemplo de estos comandos por los valores adecuados
para la implementación antes de ejecutar estos comandos.

Crear los ámbitos de zona

Un ámbito de zona es una instancia única de la zona. Una zona DNS puede tener varios
ámbitos de zona, con cada ámbito de zona que contenga su propio conjunto de
registros DNS. El mismo registro puede estar presente en varios ámbitos, con
direcciones IP diferentes o las mismas direcciones IP.

７ Nota

De forma predeterminada, existe un ámbito de zona en las zonas DNS. Este ámbito
de zona tiene el mismo nombre que la zona y las operaciones DNS heredadas
funcionan en este ámbito. Este ámbito de zona predeterminado hospedará la
versión externa de [Link] .

Puede usar el siguiente comando de ejemplo para crear particiones del ámbito de zona
[Link] para crear un ámbito de zona interna. El ámbito de zona interna se usará
para mantener la versión interna de [Link] .

Add-DnsServerZoneScope -ZoneName "[Link]" -Name "internal"

Para obtener más información, consulte Add-DnsServerZoneScope.

Agregar registros a los ámbitos de zona

El siguiente paso consiste en agregar los registros que representan el host del servidor
web en los dos ámbitos de zona: interno y predeterminado (para clientes externos).

En el ámbito de la zona interna, el registro [Link] se agrega con la

dirección IP [Link], que es una dirección IP privada; y en el ámbito de zona
predeterminado, se agrega el mismo registro, [Link], con la
dirección IP [Link].

No se proporciona ningún parámetro –ZoneScope en los siguientes comandos de

ejemplo cuando se agrega el registro al ámbito de zona predeterminado. Esto es similar
a agregar registros a una zona de vainilla.

Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name "[Link]" -

IPv4Address "[Link]" Add-DnsServerResourceRecord -ZoneName "[Link]" -A -

Name "[Link]" -IPv4Address "[Link]” -ZoneScope "internal"

Para obtener más información, vea Add-DnsServerResourceRecord.

Creación de las directivas DNS

Después de haber identificado las interfaces de servidor para la red externa y la red
interna y ha creado los ámbitos de zona, debe crear directivas DNS que conecten los
ámbitos de zona interna y externa.

７ Nota

En este ejemplo se usa la interfaz de servidor como criterios para diferenciar entre
los clientes internos y externos. Otro método para diferenciar entre clientes
externos e internos es mediante el uso de subredes de cliente como criterios. Si
puede identificar las subredes a las que pertenecen los clientes internos, puede
configurar la directiva DNS para diferenciar en función de la subred del cliente. Para
obtener información sobre cómo configurar la administración del tráfico mediante
criterios de subred de cliente, consulte Uso de la directiva DNS para Geo-Location
Administración basada en tráfico con servidores principales.

Cuando el servidor DNS recibe una consulta en la interfaz privada, la respuesta de la

consulta DNS se devuelve del ámbito de la zona interna.

７ Nota

No se requieren directivas para asignar el ámbito de zona predeterminado.

En el siguiente comando de ejemplo, [Link] es la dirección IP de la interfaz de red

privada, como se muestra en la ilustración anterior.

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW -

ServerInterface "eq,[Link]" -ZoneScope "internal,1" -ZoneName [Link]

Para obtener más información, vea Add-DnsServerQueryResolutionPolicy.

Ejemplo de control de recursividad selectiva de

DNS
A continuación se muestra un ejemplo de cómo puede usar la directiva DNS para lograr
el escenario descrito anteriormente del control de recursividad selectiva de DNS.

Esta sección contiene los temas siguientes.

Funcionamiento del control de recursividad selectiva de DNS

Configuración del control de recursividad selectiva de DNS
En este ejemplo se usa la misma empresa ficticia que en el ejemplo anterior, Contoso,
que mantiene un sitio web profesional en [Link] .

En el ejemplo de implementación de cerebro dividido de DNS, el mismo servidor DNS

responde a los clientes externos e internos y les proporciona respuestas diferentes.

Algunas implementaciones de DNS pueden requerir que el mismo servidor DNS realice
una resolución de nombres recursiva para los clientes internos, además de actuar como
servidor de nombres autoritativo para clientes externos. Esta circunstancia se denomina
control de recursividad selectiva de DNS.

En versiones anteriores de Windows Server, habilitar la recursividad significaba que

estaba habilitado en todo el servidor DNS para todas las zonas. Dado que el servidor
DNS también está escuchando consultas externas, la recursividad está habilitada para
los clientes internos y externos, lo que hace que el servidor DNS sea un solucionador
abierto.

Un servidor DNS configurado como solucionador abierto podría ser vulnerable al

agotamiento de recursos y puede ser abusado por clientes malintencionados para crear
ataques de reflexión.

Por este motivo, los administradores dns de Contoso no quieren que el servidor DNS de
[Link] realice una resolución de nombres recursiva para clientes externos. Solo es
necesario controlar la recursividad para los clientes internos, mientras que el control de
recursividad se puede bloquear para los clientes externos.

En la ilustración siguiente se muestra este escenario.

Funcionamiento del control de recursividad selectiva de
DNS
Si se recibe una consulta para la que se recibe el servidor DNS de Contoso, como para
[Link] , la solicitud de resolución de nombres se evalúa con
respecto a las directivas del servidor DNS.

Dado que estas consultas no se encuentran en ninguna zona, no se evalúan las

directivas de nivel de zona (como se define en el ejemplo de cerebro dividido).

El servidor DNS evalúa las directivas de recursividad y las consultas que se reciben en la
interfaz privada coinciden con SplitBrainRecursionPolicy. Esta directiva apunta a un
ámbito de recursividad donde se habilita la recursividad.

A continuación, el servidor DNS realiza la recursividad para obtener la respuesta

[Link] de Internet y almacena en caché la respuesta localmente.

Si la consulta se recibe en la interfaz externa, no coinciden las directivas DNS y la

configuración de recursividad predeterminada , que en este caso es Deshabilitada , se
aplica.

Esto impide que el servidor actúe como una resolución abierta para clientes externos,
mientras que actúa como solucionador de almacenamiento en caché para clientes
internos.

Configuración del control de recursividad selectiva de

DNS
Para configurar el control de recursividad selectiva de DNS mediante la directiva DNS,
debe seguir estos pasos.

Creación de ámbitos de recursividad dns

Creación de directivas de recursividad dns

Creación de ámbitos de recursividad dns

Los ámbitos de recursividad son instancias únicas de un grupo de configuraciones que

controlan la recursividad en un servidor DNS. Un ámbito de recursividad contiene una
lista de reenviadores y especifica si la recursividad está habilitada. Un servidor DNS
puede tener muchos ámbitos de recursividad.

La configuración de recursividad heredada y la lista de reenviadores se conocen como el

ámbito de recursividad predeterminado. No se puede agregar ni quitar el ámbito de
recursividad predeterminado, identificado por el punto de nombre (".").

En este ejemplo, la configuración de recursividad predeterminada está deshabilitada,

mientras que se crea un nuevo ámbito de recursividad para los clientes internos donde
se habilita la recursividad.

PowerShell

Set-DnsServerRecursionScope -Name . -EnableRecursion $False

Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True

Para más información, consulte Add-DnsServerRecursionScope.

Creación de directivas de recursividad de DNS

Puede crear directivas de recursividad del servidor DNS para elegir un ámbito de
recursividad para un conjunto de consultas que coincidan con criterios específicos.

Si el servidor DNS no es autoritativo para algunas consultas, las directivas de

recursividad del servidor DNS le permiten controlar cómo resolver las consultas.

En este ejemplo, el ámbito de recursividad interno con recursividad habilitada está

asociado a la interfaz de red privada.

Puede usar el siguiente comando de ejemplo para configurar las directivas de

recursividad de DNS.

PowerShell

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainRecursionPolicy" -Action

ALLOW -ApplyOnRecursion -RecursionScope "InternalClients" -ServerInterfaceIP
"EQ,[Link]"

Para obtener más información, vea Add-DnsServerQueryResolutionPolicy.

Ahora el servidor DNS está configurado con las directivas DNS necesarias para un
servidor de nombres de cerebro dividido o un servidor DNS con el control de
recursividad selectivo habilitado para los clientes internos.

Puede crear miles de directivas DNS según los requisitos de administración del tráfico y
todas las directivas nuevas se aplican dinámicamente, sin reiniciar el servidor DNS, en las
consultas entrantes.

Para obtener más información, consulte Guía de escenarios de directivas dns.

Uso de la directiva de DNS para aplicar
filtros en las consultas DNS
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para aprender a configurar la directiva DNS en Windows Server®
2016 para crear filtros de consulta basados en los criterios que proporcione.

Los filtros de consulta de la directiva DNS permiten configurar el servidor DNS para que
responda de forma personalizada en función de la consulta DNS y el cliente DNS que
envía la consulta DNS.

Por ejemplo, puede configurar la directiva DNS con el filtro de consulta Lista de bloques
que bloquea las consultas DNS de dominios malintencionados conocidos, lo que impide
que DNS responda a las consultas de estos dominios. Dado que no se envía ninguna
respuesta desde el servidor DNS, se espera el tiempo de espera de la consulta DNS del
miembro de dominio malintencionado.

Otro ejemplo es crear un filtro de consulta Allow List que permita que solo un conjunto
específico de clientes resuelva determinados nombres.

Criterios de filtro de consulta

Puede crear filtros de consulta con cualquier combinación lógica (AND/OR/NOT) de los
criterios siguientes.

Nombre Descripción

Subred de cliente Nombre de una subred de cliente predefinida. Se usa para comprobar la
subred desde la que se envió la consulta.

Protocolo de Protocolo de transporte utilizado en la consulta. Los valores posibles

transporte son UDP y TCP.

protocolo Internet Protocolo de red usado en la consulta. Los valores posibles son IPv4 e
IPv6.

Dirección IP de la Dirección IP de la interfaz de red del servidor DNS que recibió la

interfaz del servidor solicitud DNS.

FQDN Nombre de dominio completo del registro en la consulta, con la

posibilidad de usar un comodín.
 Nombre Descripción

Tipo de consulta Tipo de registro que se consulta (A, SRV, TXT, etc.).

Hora del día Hora del día en que se recibe la consulta.

En los ejemplos siguientes se muestra cómo crear filtros para la directiva DNS que
bloqueen o permitan consultas de resolución de nombres DNS.

７ Nota

Los comandos de ejemplo de este tema usan Windows PowerShell comando Add-
DnsServerQueryResolutionPolicy. Para obtener más información, vea Add-
DnsServerQueryResolutionPolicy.

Bloquear consultas de un dominio

En algunas circunstancias, es posible que quiera bloquear la resolución de nombres DNS
para dominios que haya identificado como malintencionados o para dominios que no
cumplan las directrices de uso de su organización. Puede realizar consultas de bloqueo
para dominios mediante la directiva DNS.

La directiva que se configura en este ejemplo no se crea en ninguna zona determinada;

en su lugar, se crea una directiva de nivel de servidor que se aplica a todas las zonas
configuradas en el servidor DNS. Las directivas de nivel de servidor son las primeras que
se evalúan y, por tanto, las primeras que se deben coincidir cuando el servidor DNS
recibe una consulta.

El siguiente comando de ejemplo configura una directiva de nivel de servidor para

bloquear las consultas con el sufijo de dominio [Link].

Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicy" -Action IGNORE -FQDN

"EQ,*.[Link]" -PassThru

７ Nota

Al configurar el parámetro Action con el valor IGNORE, el servidor DNS está

configurado para quitar consultas sin ninguna respuesta. Esto hace que el cliente
DNS del dominio malintencionado se queme el tiempo de espera.
Bloquear consultas de una subred
Con este ejemplo, puede bloquear las consultas de una subred si se encuentra infectado
por algún malware y está intentando ponerse en contacto con sitios malintencionados
mediante el servidor DNS.

' Add-DnsServerClientSubnet -Name "MaliciousSubnet06" -IPv4Subnet [Link]/24 -

PassThru

Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicyMalicic06" -Action IGNORE

-ClientSubnet "EQ,MaliciousSubnet06" -PassThru '

En el ejemplo siguiente se muestra cómo puede usar los criterios de subred en

combinación con los criterios de FQDN para bloquear las consultas de determinados
dominios malintencionados de subredes infectados.

Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicyMalicious06" -Action

IGNORE -ClientSubnet "EQ,MaliciousSubnet06" –FQDN “EQ,*.[Link]” -

PassThru

Bloquear un tipo de consulta

Es posible que tenga que bloquear la resolución de nombres para determinados tipos
de consultas en los servidores. Por ejemplo, puede bloquear la consulta "ANY", que se
puede usar de forma malintencionada para crear ataques de amplificación.

Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicyQType" -Action IGNORE -

QType "EQ,ANY" -PassThru

Permitir consultas solo desde un dominio

No solo puede usar la directiva DNS para bloquear consultas, sino que también puede
usarlas para aprobar automáticamente consultas de dominios o subredes específicos. Al
configurar listas de permitidos, el servidor DNS solo procesa las consultas de dominios
permitidos, al tiempo que bloquea todas las demás consultas de otros dominios.

El comando de ejemplo siguiente permite que solo los equipos y dispositivos de

[Link] y los dominios secundarios consulten el servidor DNS.

Add-DnsServerQueryResolutionPolicy -Name "AllowListPolicyDomain" -Action IGNORE -

FQDN "NE,*.[Link]" -PassThru
Permitir consultas solo desde una subred
También puede crear listas de permitidos para subredes IP, de modo que se ignoren
todas las consultas que no se originaron en estas subredes.

Add-DnsServerClientSubnet -Name "AllowedSubnet06" -IPv4Subnet [Link]/24 -

PassThru Add-DnsServerQueryResolutionPolicy -Name "AllowListPolicySubnet” -Action

IGNORE -ClientSubnet "NE, AllowedSubnet06" -PassThru

Permitir solo determinados QTypes

Puede aplicar listas de permitidos a LAS CANTIDADES.

Por ejemplo, si tiene clientes externos que consultan la interfaz de servidor DNS
[Link], solo se pueden consultar determinados QTYP, mientras que hay otros QTYPEs
como registros SRV o TXT que usan los servidores internos para la resolución de
nombres o con fines de supervisión.

Add-DnsServerQueryResolutionPolicy -Name "AllowListQType" -Action IGNORE -QType

"NE,A,AAAA,MX,NS,SOA" –ServerInterface “EQ,[Link]” -PassThru

Puede crear miles de directivas DNS según sus requisitos de administración del tráfico y
todas las nuevas directivas se aplican dinámicamente (sin reiniciar el servidor DNS) en
las consultas entrantes.
Uso de la directiva de DNS para el
equilibrio de carga de aplicación
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para aprender a configurar la directiva DNS para realizar el
equilibrio de carga de la aplicación.

Las versiones anteriores de Windows DNS del servidor solo proporcionaron equilibrio
de carga mediante respuestas round robin; pero con DNS en Windows Server 2016,
puede configurar la directiva DNS para el equilibrio de carga de la aplicación.

Cuando haya implementado varias instancias de una aplicación, puede usar la directiva
DNS para equilibrar la carga de tráfico entre las distintas instancias de aplicación, lo que
asigna dinámicamente la carga de tráfico para la aplicación.

Ejemplo de equilibrio de carga de aplicaciones

A continuación se muestra un ejemplo de cómo puede usar la directiva DNS para el
equilibrio de carga de aplicaciones.

En este ejemplo se usa una empresa ficticia , Contoso Gift Services, que proporciona
servicios de regalos en línea y que tiene un sitio web denominado
[Link].

El sitio web de [Link] se hospeda en varios centros de datos que cada

uno tiene direcciones IP diferentes.

En Norteamérica, que es el mercado principal de Contoso Gift Services, el sitio web se

hospeda en tres centros de datos: Chicago, IL, Dallas, TX y Seattle, WA.

El servidor web de Seattle tiene la mejor configuración de hardware y puede controlar el

doble de carga que los otros dos sitios. Contoso Gift Services quiere que el tráfico de la
aplicación se dirija de la siguiente manera.

Dado que el servidor web de Seattle incluye más recursos, la mitad de los clientes
de la aplicación se dirigen a este servidor.
Un trimestre de los clientes de la aplicación se dirigen al centro de datos Dallas, TX
Un trimestre de los clientes de la aplicación se dirigen al centro de datos de
Chicago, IL,
En la ilustración siguiente se muestra este escenario.

Funcionamiento del equilibrio de carga de aplicaciones

Después de configurar el servidor DNS con la directiva DNS para el equilibrio de carga
de la aplicación mediante este escenario de ejemplo, el servidor DNS responde el 50 %
del tiempo con la dirección del servidor web de Seattle, el 25 % del tiempo con la
dirección del servidor web dallas y el 25 % del tiempo con la dirección del servidor web
de Chicago.

Por lo tanto, para cada cuatro consultas que recibe el servidor DNS, responde con dos
respuestas para Seattle y una para Dallas y Chicago.

Un posible problema con el equilibrio de carga con la directiva DNS es el

almacenamiento en caché de registros DNS por el cliente DNS y el solucionador/LDNS,
lo que puede interferir con el equilibrio de carga porque el cliente o la resolución no
envían una consulta al servidor DNS.

Puede mitigar el efecto de este comportamiento mediante un valor de período de vida

(TTL) bajo para los registros DNS que deben equilibrar la carga.

Cómo configurar el equilibrio de carga de aplicaciones

En las secciones siguientes se muestra cómo configurar la directiva DNS para el
equilibrio de carga de aplicaciones.
Crear los ámbitos de zona
Primero debe crear los ámbitos de la zona [Link] para los centros de
datos donde se hospedan.

Un ámbito de zona es una instancia única de la zona. Una zona DNS puede tener varios
ámbitos de zona, con cada ámbito de zona que contenga su propio conjunto de
registros DNS. El mismo registro puede estar presente en varios ámbitos, con
direcciones IP diferentes o las mismas direcciones IP.

７ Nota

De forma predeterminada, existe un ámbito de zona en las zonas DNS. Este ámbito
de zona tiene el mismo nombre que la zona y las operaciones DNS heredadas
funcionan en este ámbito.

Puede usar los siguientes comandos Windows PowerShell para crear ámbitos de zona.

PowerShell

Add-DnsServerZoneScope -ZoneName "[Link]" -Name

"SeattleZoneScope"
Add-DnsServerZoneScope -ZoneName "[Link]" -Name
"DallasZoneScope"
Add-DnsServerZoneScope -ZoneName "[Link]" -Name
"ChicagoZoneScope"

Para obtener más información, consulte Add-DnsServerZoneScope.

Agregar registros a los ámbitos de zona

Ahora debe agregar los registros que representan el host del servidor web en los
ámbitos de zona.

En SeattleZoneScope, puede agregar el registro [Link] con la

dirección IP [Link], que se encuentra en el centro de datos de Seattle.

En ChicagoZoneScope, puede agregar el mismo registro ([Link])

con la dirección IP [Link] en el centro de datos de Chicago.

Del mismo modo, en DallasZoneScope, puede agregar un registro

([Link]) con la dirección IP [Link] en el centro de datos de
Chicago.
Puede usar los siguientes comandos Windows PowerShell para agregar registros a los
ámbitos de zona.

PowerShell

Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name

"www" -IPv4Address "[Link]" -ZoneScope "SeattleZoneScope"
Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name
"www" -IPv4Address "[Link]" -ZoneScope "ChicagoZoneScope"
Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name
"www" -IPv4Address "[Link]" -ZoneScope "DallasZoneScope"

Para obtener más información, vea Add-DnsServerResourceRecord.

Creación de las directivas DNS

Después de crear las particiones (ámbitos de zona) y de haber agregado registros, debe
crear directivas DNS que distribuyan las consultas entrantes en estos ámbitos para que
el 50 % de las consultas de [Link] se respondan con la dirección IP del
servidor web en el centro de datos de Seattle y el resto se distribuyen equitativamente
entre los centros de datos de Chicago y Dallas.

Puede usar los siguientes comandos Windows PowerShell para crear una directiva DNS
que equilibre el tráfico de la aplicación entre estos tres centros de datos.

７ Nota

En el comando de ejemplo siguiente, la expresión –ZoneScope

"SeattleZoneScope,2; ChicagoZoneScope,1; DallasZoneScope,1" configura el
servidor DNS con una matriz que incluye la combinación <ZoneScope> de
parámetros , <weight> .

PowerShell

Add-DnsServerQueryResolutionPolicy -Name "AmericaPolicy" -Action ALLOW -

ZoneScope "SeattleZoneScope,2;ChicagoZoneScope,1;DallasZoneScope,1" -
ZoneName "[Link]"

Para obtener más información, vea Add-DnsServerQueryResolutionPolicy.

Ahora ha creado correctamente una directiva DNS que proporciona equilibrio de carga
de aplicaciones entre servidores web en tres centros de datos diferentes.
Puede crear miles de directivas DNS según los requisitos de administración del tráfico y
todas las directivas nuevas se aplican dinámicamente, sin reiniciar el servidor DNS, en las
consultas entrantes.
Uso de la directiva de DNS para
equilibrio de carga de aplicación con
reconocimiento de ubicación geográfica
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para aprender a configurar la directiva DNS para equilibrar la
carga de una aplicación con el reconocimiento de la ubicación geográfica.

En el tema anterior de esta guía, Usar directiva DNS para el equilibrio de carga de
aplicaciones, se usa un ejemplo de una empresa ficticia, Contoso Gift Services, que
proporciona servicios de obsequio en línea y que tiene un sitio web denominado
[Link]. Contoso Gift Services equilibra la carga de su aplicación web
en línea entre servidores de centros de datos de Norteamérica ubicados en Seattle, WA,
Chicago, IL y Dallas, TX.

７ Nota

Se recomienda que se familiarice con el tema Usar directiva DNS para el equilibrio
de carga de aplicaciones antes de seguir las instrucciones de este escenario.

En este tema se usa la misma infraestructura ficticia de red y empresa como base para
una nueva implementación de ejemplo que incluye el reconocimiento de la ubicación
geográfica.

En este ejemplo, Contoso Gift Services está expandiendo correctamente su presencia en

todo el mundo.

De forma Norteamérica, la empresa ahora tiene servidores web hospedados en centros

de datos europeos.

Los administradores dns de Contoso Gift Services quieren configurar el equilibrio de

carga de aplicaciones para los centros de datos europeos de forma similar a la
implementación de la directiva DNS en Estados Unidos, con el tráfico de aplicación
distribuido entre servidores web que se encuentran en Dublín, Irlanda, Ámsterdam,
Irlanda y otros lugares.
Los administradores de DNS también quieren que todas las consultas de otras
ubicaciones del mundo se distribuyen por igual entre todos sus centros de datos.

En las secciones siguientes puede aprender a lograr objetivos similares a los de los
administradores dns de Contoso en su propia red.

Configuración del equilibrio de carga de

aplicaciones con Geo-Location reconocimiento
En las secciones siguientes se muestra cómo configurar la directiva DNS para el
equilibrio de carga de aplicaciones con reconocimiento de ubicación geográfica.

） Importante

En las secciones siguientes se incluyen comandos Windows PowerShell ejemplo

que contienen valores de ejemplo para muchos parámetros. Asegúrese de
reemplazar los valores de ejemplo de estos comandos por los que son adecuados
para la implementación antes de ejecutar estos comandos.

Creación de subredes de cliente DNS

Primero debe identificar las subredes o el espacio de direcciones IP de las regiones
Norteamérica y Europa.

Puede obtener esta información de mapas de IP geográfica. En función de estas

distribuciones de IP geográfica, debe crear las subredes de cliente DNS.

Una subred de cliente DNS es una agrupación lógica de subredes IPv4 o IPv6 desde las
que se envían consultas a un servidor DNS.

Puede usar los siguientes comandos Windows PowerShell para crear subredes de cliente
DNS.

PowerShell

Add-DnsServerClientSubnet -Name "AmericaSubnet" -IPv4Subnet

[Link]/24,[Link]/24
Add-DnsServerClientSubnet -Name "EuropeSubnet" -IPv4Subnet
[Link]/24,[Link]/24

Para obtener más información, vea Add-DnsServerClientSubnet.

Creación de los ámbitos de zona
Una vez que las subredes de cliente están en su lugar, debe dividir la zona
[Link] en distintos ámbitos de zona, cada uno para un centro de
datos.

Un ámbito de zona es una instancia única de la zona. Una zona DNS puede tener varios
ámbitos de zona, y cada ámbito de zona contiene su propio conjunto de registros DNS.
El mismo registro puede estar presente en varios ámbitos, con direcciones IP diferentes
o las mismas direcciones IP.

７ Nota

De forma predeterminada, existe un ámbito de zona en las zonas DNS. Este ámbito
de zona tiene el mismo nombre que la zona y las operaciones DNS heredadas
funcionan en este ámbito.

En el escenario anterior sobre equilibrio de carga de aplicaciones se muestra cómo

configurar tres ámbitos de zona para los centros de datos Norteamérica.

Con los comandos siguientes, puede crear dos ámbitos de zona más, uno para los
centros de datos de Dublín y Ámsterdam.

Puede agregar estos ámbitos de zona sin realizar ningún cambio en los tres ámbitos de
Norteamérica existentes en la misma zona. Además, después de crear estos ámbitos de
zona, no es necesario reiniciar el servidor DNS.

Puede usar los siguientes comandos Windows PowerShell para crear ámbitos de zona.

PowerShell

Add-DnsServerZoneScope -ZoneName "[Link]" -Name

"DublinZoneScope"
Add-DnsServerZoneScope -ZoneName "[Link]" -Name
"AmsterdamZoneScope"

Para obtener más información, vea Add-DnsServerZoneScope.

Agregar registros a los ámbitos de zona

Ahora debe agregar los registros que representan el host del servidor web en los
ámbitos de zona.
Los registros de los centros de datos de Estados Unidos se agregaron en el escenario
anterior. Puede usar los siguientes comandos Windows PowerShell para agregar
registros a los ámbitos de zona de los centros de datos europeos.

PowerShell

Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name

"www" -IPv4Address "[Link]" -ZoneScope "DublinZoneScope”
Add-DnsServerResourceRecord -ZoneName "[Link]" -A -Name
"www" -IPv4Address "[Link]" -ZoneScope "AmsterdamZoneScope"

Para obtener más información, vea Add-DnsServerResourceRecord.

Creación de las directivas DNS

Después de haber creado las particiones (ámbitos de zona) y de haber agregado
registros, debe crear directivas DNS que distribuyan las consultas entrantes entre estos
ámbitos.

En este ejemplo, la distribución de consultas entre servidores de aplicaciones de

distintos centros de datos cumple los criterios siguientes.

1. Cuando se recibe la consulta DNS de un origen en una subred cliente de

Norteamérica, el 50 % de las respuestas DNS apuntan al centro de datos de
Seattle, el 25 % de las respuestas apuntan al centro de datos de Chicago y el 25 %
restante de las respuestas apuntan al centro de datos de Dallas.
2. Cuando se recibe la consulta DNS de un origen en una subred de cliente europea,
el 50 % de las respuestas DNS apuntan al centro de datos de Dublín y el 50 % de
las respuestas DNS apuntan al centro de datos de Ámsterdam.
3. Cuando la consulta procede de cualquier otro lugar del mundo, las respuestas DNS
se distribuyen entre los cinco centros de datos.

Puede usar los siguientes comandos Windows PowerShell para implementar estas
directivas DNS.

PowerShell

Add-DnsServerQueryResolutionPolicy -Name "AmericaLBPolicy" -Action ALLOW -

ClientSubnet "eq,AmericaSubnet" -ZoneScope
"SeattleZoneScope,2;ChicagoZoneScope,1; TexasZoneScope,1" -ZoneName
"[Link]" –ProcessingOrder 1
Add-DnsServerQueryResolutionPolicy -Name "EuropeLBPolicy" -Action ALLOW -
ClientSubnet "eq,EuropeSubnet" -ZoneScope
"DublinZoneScope,1;AmsterdamZoneScope,1" -ZoneName "[Link]"
-ProcessingOrder 2
Add-DnsServerQueryResolutionPolicy -Name "WorldWidePolicy" -Action ALLOW -
 FQDN "eq,*.[Link]" -ZoneScope "SeattleZoneScope,1;ChicagoZoneScope,1;
TexasZoneScope,1;DublinZoneScope,1;AmsterdamZoneScope,1" -ZoneName
"[Link]" -ProcessingOrder 3

Para obtener más información, vea Add-DnsServerQueryResolutionPolicy.

Ahora ha creado correctamente una directiva DNS que proporciona equilibrio de carga
de aplicaciones entre servidores web que se encuentran en cinco centros de datos
diferentes en varios continentes.

Puede crear miles de directivas DNS según sus requisitos de administración del tráfico y
todas las nuevas directivas se aplican dinámicamente (sin reiniciar el servidor DNS) en
las consultas entrantes.
Solución de problemas del sistema de
nombres de dominio (DNS)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Pruebe nuestro agente virtual : puede ayudarle a identificar y corregir rápidamente

problemas comunes de DNS.

Los problemas de resolución de nombres de dominio se pueden dividir en problemas

del lado cliente y del lado servidor. En general, debe comenzar con la solución de
problemas del lado cliente, a menos que determine durante la fase de ámbito que el
problema se está produciendo definitivamente en el lado servidor.

Solución de problemas de clientes DNS

Solución de problemas de servidores DNS

Recopilación de datos
Se recomienda recopilar datos simultáneamente en los lados del cliente y del servidor
cuando se produzca el problema. Sin embargo, en función del problema real, puede
iniciar la recopilación en un único conjunto de datos en el cliente DNS o en el servidor
DNS.

Para recopilar un diagnóstico de redes de Windows de un cliente afectado y su servidor

DNS configurado, siga estos pasos:

1. Inicie las capturas de red en el cliente y el servidor:

cmd

netsh trace start capture=yes tracefile=c:\%computername%_nettrace.etl

2. Borre la memoria caché DNS en el cliente DNS mediante la ejecución del siguiente
comando:

cmd

ipconfig /flushdns

3. Reproduzca el problema.
4. Detener y guardar seguimientos:

cmd

netsh trace stop

5. Guarde los archivos [Link] de cada equipo. Esta información será útil
cuando se comunique con Soporte técnico de Microsoft.
Solución de problemas de clientes DNS
Artículo • 21/12/2022 • Tiempo de lectura: 3 minutos

En este artículo se describe cómo solucionar problemas de clientes DNS.

Comprobación de la configuración de IP
1. Abra una ventana del símbolo del sistema como administrador en el equipo
cliente.

2. Ejecute el siguiente comando:

cmd

ipconfig /all

3. Compruebe que el cliente tiene una dirección IP válida, una máscara de subred y
una puerta de enlace predeterminada para la red a la que está conectado y que se
está utilizando.

4. Compruebe los servidores DNS que aparecen en la salida y compruebe que las
direcciones IP enumeradas son correctas.

5. Compruebe el sufijo DNS específico de la conexión en la salida y compruebe que

es correcto.

Si el cliente no tiene una configuración tcp/IP válida, use uno de los métodos siguientes:

En el caso de los clientes configurados dinámicamente, use el ipconfig /renew

comando para forzar manualmente al cliente a renovar su configuración de
direcciones IP con el servidor DHCP.

Para los clientes configurados estáticamente, modifique las propiedades de TCP/IP

del cliente para usar parámetros de configuración válidos o complete su
configuración de DNS para la red.

Comprobación de la conexión de red

Prueba de ping
Compruebe que el cliente puede ponerse en contacto con un servidor DNS preferido (o
alternativo) haciendo ping al servidor DNS preferido por su dirección IP.

Por ejemplo, si el cliente usa un servidor DNS preferido de [Link], ejecute este
comando en un símbolo del sistema:

cmd

ping [Link]

Si ningún servidor DNS configurado responde a un ping directo de su dirección IP, esto
indica que el origen del problema es más probable que haya conectividad de red entre
el cliente y los servidores DNS. Si este es el caso, siga los pasos básicos de solución de
problemas de red TCP/IP para solucionar el problema. Tenga en cuenta que se debe
permitir el tráfico ICMP a través del firewall para que el comando ping funcione.

Pruebas de consulta DNS

Si el cliente DNS puede hacer ping al equipo del servidor DNS, nslookup intente usar los
siguientes comandos para probar si el servidor puede responder a los clientes DNS.
Dado que nslookup no usa la caché DNS del cliente, la resolución de nombres usará el
servidor DNS configurado del cliente.

Prueba de un cliente

cmd

nslookup <client>

Por ejemplo, si el equipo cliente se denomina client1, ejecute este comando:

cmd

nslookup client1

Si no se devuelve una respuesta correcta, intente ejecutar el siguiente comando:

cmd

nslookup <fqdn of client>

Por ejemplo, si el FQDN está [Link], ejecute este comando:

 cmd

nslookup [Link].

７ Nota

Debe incluir el período final al ejecutar esta prueba.

Si Windows encuentra correctamente el FQDN pero no encuentra el nombre corto,

compruebe la configuración del sufijo DNS en la pestaña DNS de la configuración
avanzada de TCP/IP Configuración de la NIC. Para más información, consulte
Configuración de la resolución DNS.

Prueba del servidor DNS

cmd

nslookup <DNS Server>

Por ejemplo, si el servidor DNS se denomina DC1, ejecute este comando:

cmd

nslookup dc1

Si las pruebas anteriores se realizaron correctamente, esta prueba también debe ser
correcta. Si esta prueba no se realiza correctamente, compruebe la conectividad con el
servidor DNS.

Prueba del registro con errores

cmd

nslookup <failed internal record>

Por ejemplo, si el registro con errores se [Link], ejecute este comando:

cmd

nslookup [Link]
Prueba de una dirección de Internet pública

cmd

nslookup <external name>

Por ejemplo:

cmd

nslookup [Link]

Si las cuatro pruebas se realizaron correctamente, ejecute ipconfig /displaydns y

compruebe la salida del nombre que ha fallado. Si ve "El nombre no existe" en el
nombre con errores, se devuelve una respuesta negativa desde un servidor DNS y se
almacena en caché en el cliente.

Para resolver el problema, borre la memoria caché mediante la ejecución de ipconfig

/flushdns .

Paso siguiente
Si la resolución de nombres sigue teniendo errores, vaya a la sección Solución de
problemas de servidores DNS .
Solución de problemas de servidores
DNS
Artículo • 21/12/2022 • Tiempo de lectura: 10 minutos

Pruebe nuestro agente virtual : puede ayudarle a identificar y corregir rápidamente

problemas comunes de DNS.

En este artículo se describe cómo solucionar problemas en los servidores DNS.

Comprobación de la configuración de IP
1. Ejecute ipconfig /all en un símbolo del sistema y compruebe la dirección IP, la
máscara de subred y la puerta de enlace predeterminada.

2. Compruebe si el servidor DNS es autoritativo para el nombre que se está

buscando. Si es así, consulte Comprobación de problemas con datos autoritativos.

3. Ejecute el siguiente comando:

cmd

nslookup <name> <IP address of the DNS server>

Por ejemplo:

cmd

nslookup app1 [Link]

Si recibe un error o una respuesta de tiempo de espera, consulte Comprobación

de problemas de recursividad.

4. Vacíe la caché del solucionador. Para ello, ejecute el siguiente comando en una
ventana del símbolo del sistema administrativo:

cmd

dnscmd /clearcache

O bien, en una ventana de PowerShell administrativa, ejecute el siguiente cmdlet:

 PowerShell

Clear-DnsServerCache

5. Repita el paso 3.

Comprobación de problemas del servidor DNS

Registro de eventos
Compruebe los registros siguientes para ver si hay errores registrados:

Application

Sistema

Servidor DNS

Prueba mediante la consulta nslookup

Ejecute el siguiente comando y compruebe si el servidor DNS es accesible desde los
equipos cliente.

cmd

nslookup <client name> <server IP address>

Si el solucionador devuelve la dirección IP del cliente, el servidor no tiene ningún

problema.

Si el solucionador devuelve una respuesta "Error del servidor" o "Consulta

rechazada", es probable que la zona esté en pausa o que el servidor esté
sobrecargado. Para saber si está en pausa, compruebe la pestaña General de las
propiedades de la zona en la consola de DNS.

Si el solucionador devuelve una respuesta "Solicitud al servidor agota el tiempo de

espera" o "Sin respuesta del servidor", es probable que el servicio DNS no se esté
ejecutando. Intente reiniciar el servicio servidor DNS escribiendo lo siguiente en un
símbolo del sistema en el servidor:

cmd

net start DNS

Si el problema se produce cuando se ejecuta el servicio, es posible que el servidor no
escuche en la dirección IP que usó en la consulta nslookup. En la pestaña Interfaces de
la página de propiedades del servidor de la consola DNS, los administradores pueden
restringir un servidor DNS para que escuche solo en las direcciones seleccionadas. Si el
servidor DNS se ha configurado para limitar el servicio a una lista específica de sus
direcciones IP configuradas, es posible que la dirección IP que se usa para ponerse en
contacto con el servidor DNS no esté en la lista. Puede probar otra dirección IP en la
lista o agregar la dirección IP a la lista.

En raras ocasiones, el servidor DNS puede tener una configuración avanzada de

seguridad o firewall. Si el servidor se encuentra en otra red a la que solo se puede
acceder a través de un host intermedio (por ejemplo, un enrutador de filtrado de
paquetes o un servidor proxy), el servidor DNS podría usar un puerto no estándar para
escuchar y recibir solicitudes de cliente. De forma predeterminada, nslookup envía
consultas a servidores DNS en el puerto UDP 53. Por lo tanto, si el servidor DNS usa
cualquier otro puerto, se producirá un error en las consultas nslookup. Si cree que esto
podría ser el problema, compruebe si un filtro intermedio se usa intencionadamente
para bloquear el tráfico en puertos DNS conocidos. Si no es así, intente modificar los
filtros de paquetes o las reglas de puerto en el firewall para permitir el tráfico en el
puerto UDP/TCP 53.

Comprobación de problemas con datos

autoritativos
Compruebe si el servidor que devuelve la respuesta incorrecta es un servidor principal
para la zona (el servidor principal estándar de la zona o un servidor que usa la
integración de Active Directory para cargar la zona) o un servidor que hospeda una
copia secundaria de la zona.

Si el servidor es un servidor principal

El problema puede deberse a un error de usuario cuando los usuarios escriben datos en
la zona. O bien, podría deberse a un problema que afecta a la replicación de Active
Directory o a la actualización dinámica.

Si el servidor hospeda una copia secundaria de la zona

1. Examine la zona del servidor principal (el servidor desde el que este servidor extrae
las transferencias de zona).
 ７ Nota

Para determinar qué servidor es el servidor principal, examine las propiedades

de la zona secundaria en la consola DNS.

Si el nombre no es correcto en el servidor principal, vaya al paso 4.

2. Si el nombre es correcto en el servidor principal, compruebe si el número de serie

del servidor principal es menor o igual que el número de serie en el servidor
secundario. Si es así, modifique el servidor principal o el servidor secundario para
que el número de serie del servidor principal sea mayor que el número de serie del
servidor secundario.

3. En el servidor secundario, forzar una transferencia de zona desde dentro de la

consola DNS o ejecutando el siguiente comando:

cmd

dnscmd /zonerefresh <zone name>

Por ejemplo, si la zona está [Link], escriba: dnscmd /zonerefresh

[Link] .

4. Vuelva a examinar el servidor secundario para ver si la zona se ha transferido

correctamente. Si no es así, es probable que tenga un problema de transferencia
de zona. Para obtener más información, vea Problemas de transferencia de zona.

5. Si la zona se ha transferido correctamente, compruebe si los datos ahora son

correctos. Si no es así, los datos son incorrectos en la zona primaria. El problema
puede deberse a un error de usuario cuando los usuarios escriben datos en la
zona. O bien, podría deberse a un problema que afecta a la replicación de Active
Directory o a la actualización dinámica.

Comprobación de problemas de recursividad

Para que la recursividad funcione correctamente, todos los servidores DNS que se usan
en la ruta de acceso de una consulta recursiva deben poder responder y reenviar los
datos correctos. Si no pueden, se puede producir un error en una consulta recursiva por
cualquiera de los siguientes motivos:

La consulta excede el tiempo de espera antes de que pueda completarse.

 Un servidor que se usa durante la consulta no responde.

Un servidor que se usa durante la consulta proporciona datos incorrectos.

Inicie la solución de problemas en el servidor que se usó en la consulta original.

Compruebe si este servidor reenvía las consultas a otro servidor examinando la pestaña
Reenviadores de las propiedades del servidor en la consola DNS. Si la casilla Habilitar
reenviadores está activada y se muestran uno o varios servidores, este servidor reenvía
las consultas.

Si este servidor reenvía consultas a otro servidor, compruebe si hay problemas que
afectan al servidor al que este servidor reenvía las consultas. Para comprobar si hay
problemas, consulte Comprobación de problemas del servidor DNS. Cuando esa sección
le indica que realice una tarea en el cliente, realice en su lugar en el servidor.

Si el servidor está en buen estado y puede reenviar consultas, repita este paso y
examine el servidor al que este servidor reenvía las consultas.

Si este servidor no reenvía consultas a otro servidor, pruebe si este servidor puede
consultar un servidor raíz. Para ello, ejecute el siguiente comando:

cmd

nslookup
server <IP address of server being examined>
set q=NS

Si el solucionador devuelve la dirección IP de un servidor raíz, es probable que

tenga una delegación interrumpida entre el servidor raíz y el nombre o la dirección
IP que está intentando resolver. Siga el procedimiento Probar una delegación rota
para determinar dónde se ha roto la delegación.

Si el solucionador devuelve una respuesta "Solicitud al servidor agota el tiempo de

espera", compruebe si las sugerencias raíz apuntan a que funcionan los servidores
raíz. Para ello, use el procedimiento Para ver las sugerencias raíz actuales . Si las
sugerencias raíz apuntan a que funcionan los servidores raíz, es posible que tenga
un problema de red o que el servidor use una configuración de firewall avanzada
que impida que el solucionador consulte el servidor, como se describe en la
sección Comprobar problemas del servidor DNS . También es posible que el valor
predeterminado de tiempo de espera recursivo sea demasiado corto.

Prueba de una delegación interrumpida

Inicie las pruebas en el procedimiento siguiente consultando un servidor raíz válido. La
prueba le lleva a través de un proceso de consulta de todos los servidores DNS desde la
raíz hasta el servidor que está probando para una delegación rota.

1. En el símbolo del sistema del servidor que está probando, escriba lo siguiente:

cmd

nslookup
server <server IP address>
set norecursion
set querytype= <resource record type>
<FQDN>

７ Nota

El tipo de registro de recursos es el tipo de registro de recursos para el que

estaba consultando en la consulta original y FQDN es el FQDN para el que
estaba consultando (finalizado por un punto).

2. Si la respuesta incluye una lista de registros de recursos "NS" y "A" para servidores
delegados, repita el paso 1 para cada servidor y use la dirección IP de los registros
de recursos "A" como dirección IP del servidor.

Si la respuesta no contiene un registro de recursos "NS", tiene una

delegación interrumpida.

Si la respuesta contiene registros de recursos "NS", pero no hay registros de

recursos "A", escriba la recursividad establecida y consulte individualmente
los registros de recursos "A" de los servidores que aparecen en los registros
"NS". Si no encuentra al menos una dirección IP válida de un registro de
recursos "A" para cada registro de recursos de NS en una zona, tiene una
delegación interrumpida.

3. Si determina que tiene una delegación interrumpida, corrijala agregando o

actualizando un registro de recursos "A" en la zona primaria mediante una
dirección IP válida para un servidor DNS correcto para la zona delegada.

Para ver las sugerencias raíz actuales

1. Inicie la consola DNS.
 2. Agregue o conéctese al servidor DNS que produjo un error en una consulta
recursiva.

3. Haga clic con el botón derecho en el servidor y seleccione Propiedades.

4. Haga clic en Sugerencias raíz.

Compruebe la conectividad básica con los servidores raíz.

Si las sugerencias raíz parecen estar configuradas correctamente, compruebe que

el servidor DNS que se usa en una resolución de nombres con errores puede hacer
ping a los servidores raíz por dirección IP.

Si los servidores raíz no responden al ping por dirección IP, es posible que las
direcciones IP de los servidores raíz hayan cambiado. Sin embargo, es raro ver una
reconfiguración de los servidores raíz.

Problemas de transferencia de zona

Ejecute las siguientes comprobaciones:

Compruebe Visor de eventos para el servidor DNS principal y secundario.

Compruebe el servidor principal para ver si se niega a enviar la transferencia por

seguridad.

Compruebe la pestaña Transferencias de zona de las propiedades de zona en la

consola DNS. Si el servidor restringe las transferencias de zona a una lista de
servidores, como los enumerados en la pestaña Servidores de nombres de las
propiedades de zona, asegúrese de que el servidor secundario está en esa lista.
Asegúrese de que el servidor está configurado para enviar transferencias de zona.

Para comprobar si hay problemas en el servidor principal, siga los pasos descritos
en la sección Comprobar problemas del servidor DNS . Cuando se le pida que
realice una tarea en el cliente, realice la tarea en el servidor secundario en su lugar.

Compruebe si el servidor secundario está ejecutando otra implementación del

servidor DNS, como BIND. Si es así, el problema podría tener una de las siguientes
causas:

Es posible que el servidor principal de Windows esté configurado para enviar

transferencias de zona rápidas, pero es posible que el servidor secundario de
terceros no admita transferencias de zona rápida. Si este es el caso, deshabilite
las transferencias de zona rápida en el servidor principal desde la consola DNS
 activando la casilla Habilitar secundarias de enlace en la pestaña Avanzadas de
las propiedades del servidor.

Si una zona de búsqueda directa en el servidor Windows contiene un tipo de

registro (por ejemplo, un registro SRV) que el servidor secundario no admite, el
servidor secundario podría tener problemas al extraer la zona.

Compruebe si el servidor principal ejecuta otra implementación del servidor DNS, como
BIND. Si es así, es posible que la zona del servidor principal incluya registros de recursos
incompatibles que Windows no reconoce.

Si el servidor maestro o secundario ejecuta otra implementación de servidor DNS,

compruebe ambos servidores para asegurarse de que admiten las mismas
características. Puede comprobar el servidor Windows en la consola DNS en la pestaña
Opciones avanzadas de la página de propiedades del servidor. Además del cuadro
Habilitar secundarias de enlace, esta página incluye la lista desplegable Comprobación
de nombres. Esto le permite seleccionar la aplicación del cumplimiento estricto de RFC
para caracteres en nombres DNS.
Protocolo de configuración dinámica de
host (DHCP)
Artículo • 21/12/2022 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener una breve introducción a DHCP en Windows Server
2016.

７ Nota

Además de este tema, está disponible la siguiente documentación de DHCP.

Novedades de DHCP
Implementación de DHCP mediante Windows PowerShell

El Protocolo de configuración dinámica de host (DHCP) es un protocolo cliente/servidor

que proporciona automáticamente un host de Protocolo de Internet (IP) con su
dirección IP y otra información de configuración relacionada, como la máscara de
subred y la puerta de enlace predeterminada. Las RFC 2131 y 2132 definen DHCP como
un estándar de Internet Engineering Task Force (IETF) basado en el Protocolo de
arranque (BOOTP), un protocolo con el que DHCP comparte muchos detalles de
implementación. DHCP permite a los hosts obtener la información de configuración de
TCP/IP necesaria de un servidor DHCP.

Windows Server 2016 incluye el servidor DHCP, que es un rol de servidor de red
opcional que puede implementar en la red para concesiones de direcciones IP y otra
información a los clientes DHCP. Todos Windows sistemas operativos cliente basados en
el cliente de servidor remoto incluyen el cliente DHCP como parte de TCP/IP, y el cliente
DHCP está habilitado de forma predeterminada.

¿Por qué usar DHCP?

Todos los dispositivos de una red basada en TCP/IP deben tener una dirección IP de
unidifusión única para acceder a la red y sus recursos. Sin DHCP, las direcciones IP de los
equipos nuevos que se mueven de una subred a otra deben configurarse manualmente;
Las direcciones IP de los equipos que se quitan de la red deben reclamarse
manualmente.
Con DHCP, todo este proceso se automatiza y administra de forma centralizada. El
servidor DHCP mantiene un grupo de direcciones IP y concesiona una dirección a
cualquier cliente habilitado para DHCP cuando se inicia en la red. Dado que las
direcciones IP son dinámicas (concesionadas) en lugar de estáticas (asignadas
permanentemente), las direcciones que ya no están en uso se devuelven
automáticamente al grupo para su reasignación.

El administrador de red establece servidores DHCP que mantienen la información de

configuración de TCP/IP y proporcionan la configuración de direcciones a los clientes
habilitados para DHCP en forma de una oferta de concesión. El servidor DHCP almacena
la información de configuración en una base de datos que incluye:

Parámetros de configuración TCP/IP válidos para todos los clientes de la red.

Direcciones IP válidas, mantenidas en un grupo para la asignación a clientes, así

como direcciones excluidas.

IP reservada direcciones asociadas a clientes DHCP concretos. Esto permite la

asignación coherente de una única dirección IP a un solo cliente DHCP.

La duración de la concesión o el período de tiempo durante el que se puede usar

la dirección IP antes de que se requiera una renovación de concesión.

Un cliente habilitado para DHCP, al aceptar una oferta de concesión, recibe:

Dirección IP válida para la subred a la que se conecta.

Opciones DHCP solicitadas, que son parámetros adicionales que un servidor DHCP
está configurado para asignar a los clientes. Algunos ejemplos de opciones DHCP
son Enrutador (puerta de enlace predeterminada), Servidores DNS y Nombre de
dominio DNS.

Ventajas de DHCP
DHCP proporciona las siguientes ventajas.

Configuración confiable de direcciones IP. DHCP minimiza los errores de

configuración causados por la configuración manual de direcciones IP, como
errores tipográficos, o conflictos de direcciones causados por la asignación de una
dirección IP a más de un equipo al mismo tiempo.

Administración de red reducida. DHCP incluye las siguientes características para

reducir la administración de red:
Configuración de TCP/IP centralizada y automatizada.

La capacidad de definir configuraciones TCP/IP desde una ubicación central.

La capacidad de asignar un intervalo completo de valores de configuración

adicionales de TCP/IP mediante opciones DHCP.

El control eficaz de los cambios de dirección IP para los clientes que se deben
actualizar con frecuencia, como los de los dispositivos portátiles que se mueven
a diferentes ubicaciones de una red inalámbrica.

El reenvío de mensajes DHCP iniciales mediante un agente de retransmisión

DHCP, lo que elimina la necesidad de un servidor DHCP en cada subred.
Novedades del DHCP
Artículo • 21/12/2022 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema se describe la funcionalidad del Protocolo de configuración dinámica de

host (DHCP) nueva o modificada en Windows Server 2016.

DHCP es una norma del Grupo de trabajo en ingeniería de Internet (IETF) diseñada para
reducir la carga administrativa y la complejidad de configurar hosts en una red TCP/IP,
como una intranet privada. Al usar el servicio del servidor DHCP, el proceso de
configuración de TCP/IP en clientes DHCP es automático.

En las secciones siguientes se proporciona información sobre las nuevas características y

los cambios en la funcionalidad de DHCP.

Nuevas características del lado cliente DHCP en

la actualización Windows 10 mayo de 2020
El cliente DHCP de Windows 10 se actualizó en la actualización del 10 de mayo de 2020
(también conocida como Windows 10, versión 2004). Cuando ejecuta un cliente de
Windows y se conecta a Internet a través de un teléfono Android tethered, la conexión
debe marcarse como "medida". Anteriormente, las conexiones se marcaban como no
medidas. Tenga en cuenta que no todos los teléfonos con tether de Android se
detectarán como de uso medición y que algunas otras redes también pueden aparecer
como de uso medidor.

Además, el nombre tradicional del proveedor de cliente se ha actualizado para algunos

Windows basados en dispositivos. Este valor solía ser simplemente MSFT 5.0. Algunos
dispositivos aparecerán ahora como MSFT 5.0 XBOX.

Nuevas características del lado cliente DHCP en

la actualización Windows 10 abril de 2018
El cliente DHCP de Windows 10 se ha actualizado en la actualización de abril de 2018 de
Windows (también conocida como Windows 10, versión 1803) para leer y aplicar la
opción 119, la opción de búsqueda de dominio, desde el servidor DHCP al que se
conecta el sistema. La opción de búsqueda de dominio proporciona sufijos DNS para las
búsquedas DNS de nombres cortos. La opción DHCP 119 se especifica en RFC 3397 .
Opciones de selección de subred DHCP
DHCP ahora admite la opción 82 (sub option 5). Puede usar esta opción para permitir
que los clientes proxy DHCP y los agentes de retransmisión soliciten una dirección IP
para una subred específica.

Si usa un agente de retransmisión DHCP configurado con la opción DHCP 82, sub
option 5, el agente de retransmisión puede solicitar una concesión de direcciones IP
para clientes DHCP desde un intervalo de direcciones IP específico.

Para más información, consulte Opciones de selección de subred DHCP.

Nuevos eventos de registro para errores de

registro dns por parte del servidor DHCP
DHCP ahora incluye eventos de registro para circunstancias en las que se producirá un
error en los registros de registros DNS del servidor DHCP en el servidor DNS.

Para obtener más información, vea Eventos de registro DHCP para registros de DNS.

NAP DHCP no se admite en Windows Server

2016
Protección de acceso a redes (NAP) está en desuso en Windows Server 2012 R2 y, en
Windows Server 2016 el rol servidor DHCP ya no admite NAP. Para obtener más
información, vea Características eliminadas o en desuso en Windows Server 2012 R2.

La compatibilidad con NAP se introdujo en el rol servidor DHCP con Windows Server
2008 y se admite en sistemas operativos cliente y servidor de Windows antes de
Windows 10 y Windows Server 2016. En la tabla siguiente se resume la compatibilidad
con NAP en Windows Server.

Sistema operativo Compatibilidad con NAP

Windows Server 2008 Compatible

Windows Server 2008 R2 Compatible

Windows Server 2012 Compatible

Windows Server 2012 R2 Compatible

Windows Server 2016 No compatible

En una implementación nap, un servidor DHCP que ejecuta un sistema operativo
compatible con NAP puede funcionar como punto de cumplimiento de NAP para el
método de cumplimiento DHCP de NAP. Para obtener más información sobre DHCP en
NAP, vea Lista de comprobación: Implementar un diseño de cumplimiento DHCP.

En Windows Server 2016, los servidores DHCP no aplican directivas NAP y los ámbitos
DHCP no pueden estar habilitados para NAP. Los equipos cliente DHCP que también
son clientes NAP envían una instrucción de estado (SoH) con la solicitud DHCP. Si el
servidor DHCP se ejecuta Windows Server 2016, estas solicitudes se procesan como si
no hubiera ningún SoH. El servidor DHCP concede una concesión DHCP normal al
cliente.

Si los servidores que ejecutan Windows Server 2016 son servidores proxy RADIUS que
reenvía solicitudes de autenticación a un servidor de directivas de red (NPS) que admite
NAP, NPS evalúa estos clientes NAP como no compatibles con NAP y se produce un
error en el procesamiento de NAP.

Referencias adicionales
Protocolo de configuración dinámica de host (DHCP)
Opciones de selección de subred DHCP
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información sobre las nuevas opciones de selección
de subred DHCP.

DHCP ahora admite la opción 82 (sub option 5). Puede usar estas opciones para permitir
que los clientes proxy DHCP y los agentes de retransmisión soliciten una dirección IP
para una subred específica y desde un ámbito y un intervalo de direcciones IP
específicos. Para obtener más información, vea Opción 82 Sub option 5: RFC 3527 Link
Selection sub-option for the Relay Agent Information Option for DHCPv4 (Opción de
información del agente de retransmisión para DHCPv4).

Si usa un agente de retransmisión DHCP configurado con la opción DHCP 82, sub
option 5, el agente de retransmisión puede solicitar una concesión de direcciones IP
para clientes DHCP desde un intervalo de direcciones IP específico.

Option 82 Sub Option 5: Link Selection Sub

Option
La sub-opción Selección de vínculos del agente de retransmisión permite a un agente
de retransmisión DHCP especificar una subred IP desde la que el servidor DHCP debe
asignar direcciones IP y opciones.

Normalmente, los agentes de retransmisión DHCP se basan en el campo Dirección IP de

puerta de enlace (GIADDR) para comunicarse con servidores DHCP. Sin embargo,
GIADDR está limitado por sus dos funciones operativas:

1. Para informar al servidor DHCP sobre la subred en la que reside el cliente DHCP
que solicita la concesión de direcciones IP.
2. Para informar al servidor DHCP de la dirección IP que se usará para comunicarse
con el agente de retransmisión.

En algunos casos, la dirección IP que usa el agente de retransmisión para comunicarse

con el servidor DHCP puede ser diferente del intervalo de direcciones IP desde el que se
debe asignar la dirección IP del cliente DHCP.

La opción Sub selección de vínculo de la opción 82 es útil en esta situación, lo que

permite que el agente de retransmisión especifique explícitamente la subred desde la
que desea que se asigne la dirección IP en forma de DHCP v4, opción 82, subla opción
5.

７ Nota

Todas las direcciones IP del agente de retransmisión (GIADDR) deben formar parte
de un intervalo de direcciones IP de ámbito DHCP activo. Cualquier GIADDR fuera
de los intervalos de direcciones IP del ámbito DHCP se considera una retransmisión
no válida y Windows el servidor DHCP no reconocerá las solicitudes de cliente
DHCP de esos agentes de retransmisión.

Se puede crear un ámbito especial para "autorizar" agentes de retransmisión. Cree

un ámbito con el GIADDR (o varios si los GIADDR son direcciones IP secuenciales),
excluya las direcciones GIADDR de la distribución y, a continuación, active el
ámbito. Esto autorizará a los agentes de retransmisión a la vez que impedirá que se
asignen las direcciones GIADDR.

Escenarios de casos de uso

En este escenario, una red de la organización incluye un servidor DHCP y un punto de
acceso inalámbrico (AP) para los usuarios invitados. Las direcciones IP de cliente de
invitados se asignan desde el servidor DHCP de la organización; sin embargo, debido a
las restricciones de directivas de firewall, el servidor DHCP no puede acceder a la red
inalámbrica invitada o a los clientes inalámbricos con mensajes en formato ancho.

Para resolver esta restricción, el PUNTO de acceso se configura con la opción 5 de

selección de vínculos para especificar la subred desde la que quiere que se asigne la
dirección IP a los clientes invitados, mientras que en GIADDR también se especifica la
dirección IP de la interfaz interna que conduce a la red corporativa.
Eventos de registro DHCP para registros
DNS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Los registros de eventos del servidor DHCP ahora proporcionan información detallada
sobre los errores de registro de DNS.

７ Nota

En muchos casos, el motivo de los errores de registro de registros DNS por parte
de los servidores DHCP es que una zona Reverse-Lookup DNS está configurada
incorrectamente o no está configurada en absoluto.

Los siguientes nuevos eventos DHCP le ayudan a identificar fácilmente cuándo se están
generando errores en los registros DNS debido a una configuración errónea o a la falta
de una zona Reverse-Lookup DNS.

ID Evento Value

20317 [Link] Error %3 en el registro de reenvío de la dirección

IPv4 %1 y FQDN %2. Es probable que esto se
deba a que la zona de búsqueda directa para este
registro no existe en el servidor DNS.

20318 [Link] Error %3 en el registro de reenvío de la dirección

IPv4 %1 y FQDN %2.

20319 [Link] Error %3 en el registro PTR de la dirección IPv4

%1 y FQDN %2. Es probable que esto se deba a
que la zona de búsqueda inversa para este
registro no existe en el servidor DNS.

20320 [Link] Error %3 en el registro PTR de la dirección IPv4

%1 y FQDN %2.

20321 [Link] Error %3 en el registro de reenvío de la dirección

IPv6 %1 y FQDN %2. Es probable que esto se
deba a que la zona de búsqueda directa para este
registro no existe en el servidor DNS.
ID Evento Value

20322 [Link] Error %3 en el registro de reenvío de la dirección

IPv6 %1 y FQDN %2.

20323 [Link] Error %3 en el registro de registros PTR para la

dirección IPv6 %1 y FQDN %2. Es probable que
esto se deba a que la zona de búsqueda inversa
para este registro no existe en el servidor DNS.

20324 [Link] Error %3 en el registro de registros PTR para la

dirección IPv6 %1 y FQDN %2.

20325 [Link] Error de registro PTR para la dirección IPv4 %1 y

FQDN %2 con el error %3 (%4).

20326 [Link] Error de registro de reenvío para la dirección IPv6

%1 y FQDN %2 con el error %3 (%4)

20327 [Link] Error de registro PTR para la dirección IPv6 %1 y

FQDN %2 con el error %3 (%4).
Implementación de DHCP mediante
Windows PowerShell
Artículo • 21/12/2022 • Tiempo de lectura: 25 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En esta guía se proporcionan instrucciones sobre cómo usar Windows PowerShell para
implementar un servidor del Protocolo de configuración dinámica de host (DHCP)
versión 4 de Protocolo de internet (IP) que asigna automáticamente direcciones IP y
opciones DHCP a clientes DHCP IPv4 conectados a una o varias subredes de la red.

７ Nota

Para descargar este documento en formato de Word desde la Galería de TechNet,

consulte Implementación de DHCP mediante Windows PowerShell en Windows
Server 2016 .

El uso de servidores DHCP para asignar direcciones IP se guarda en sobrecarga

administrativa porque no es necesario configurar manualmente la configuración de
TCP/IP v4 para cada adaptador de red de cada equipo de la red. Con DHCP, la
configuración de TCP/IP v4 se realiza automáticamente cuando un equipo u otro cliente
DHCP está conectado a la red.

Puede implementar el servidor DHCP en un grupo de trabajo como un servidor

independiente o como parte de un dominio de Active Directory.

En esta guía se incluyen las siguientes secciones.

Introducción a la implementación de DHCP

Introducción a la tecnología
Planear la implementación de DHCP
Uso de esta guía en un laboratorio de pruebas
Implementación de DHCP
Comprobar la funcionalidad del servidor
comandos de Windows PowerShell para DHCP
Lista de comandos de Windows PowerShell en esta guía

Introducción a la implementación de DHCP

En la ilustración siguiente se muestra el escenario que puede implementar mediante
esta guía. El escenario incluye un servidor DHCP en un dominio de Active Directory. El
servidor está configurado para proporcionar direcciones IP a los clientes DHCP en dos
subredes diferentes. Las subredes están separadas por un enrutador que tiene
habilitado el reenvío DHCP.

Introducción a las tecnologías

En las secciones siguientes se proporcionan breves información general sobre DHCP y
TCP/IP.

Introducción a DHCP
DHCP es un estándar IP que sirve para simplificar la administración de la configuración
IP del host. El estándar DHCP ofrece el uso de servidores DHCP como una forma de
administrar la asignación dinámica de direcciones IP y demás detalles de configuración
relacionados para los clientes habilitados para DHCP de la red.

DHCP permite usar un servidor DHCP para asignar dinámicamente una dirección IP a un
equipo u otro dispositivo, como una impresora, en la red local, en lugar de configurar
manualmente todos los dispositivos con una dirección IP estática.

Cada equipo de una red TCP/IP debe tener una dirección IP única, ya que la dirección IP
y su máscara de subred relacionada identifican el equipo host y la subred a la cual está
conectado el equipo. Si usa DHCP, puede estar seguro de que todos los equipos que
están configurados como clientes DHCP reciben una dirección IP que sea apropiada
para la ubicación de red y la subred; además, al usar las opciones de DHCP, como
puertas de enlace y servidores DNS predeterminados, puede proporcionar de forma
automática a los clientes de DHCP la información que necesitan para funcionar
correctamente en la red.

En el caso de las redes basadas en TCP/IP, DHCP reduce la complejidad y la cantidad de

trabajo administrativo implicado en la configuración de equipos.

Introducción a TCP/IP
De forma predeterminada, todas las versiones del servidor Windows y los sistemas
operativos cliente Windows tienen la configuración de TCP/IP para las conexiones de
red ip versión 4 configuradas para obtener automáticamente una dirección IP y otra
información, denominadas opciones DHCP, desde un servidor DHCP. Por este motivo,
no es necesario configurar manualmente las opciones de TCP/IP a menos que el equipo
sea un equipo servidor u otro dispositivo que requiera una dirección IP estática
configurada manualmente.

Por ejemplo, se recomienda configurar manualmente la dirección IP del servidor DHCP y

las direcciones IP de los servidores DNS y controladores de dominio que ejecutan
Servicios de dominio de Active Directory (AD DS).

TCP/IP en Windows Server 2016 es el siguiente:

Software de red basado en protocolos de red estándar del sector.

Un protocolo de red corporativa enrutable que admite la conexión del equipo

basado en Windows en entornos de red de área local (LAN) y de red de área
extensa (WAN).

Tecnologías y utilidades principales para la conexión del equipo basado en

Windows con sistemas distintos con el objetivo de compartir información.

Una base para obtener acceso a servicios de Internet globales, como servidores de
Protocolo de transferencia de archivos (FTP) web y de transferencia de archivos.

Un marco cliente/servidor entre plataformas escalable y sólido.

TCP/IP proporciona utilidades de TCP/IP básicas que permiten a los equipos basados en
Windows conectarse y compartir información con otros sistemas de Microsoft y
sistemas que no son de Microsoft, incluidos:

Windows Server 2016

Windows 10
 Windows Server 2012 R2

Windows 8.1

Windows Server 2012

Windows 8

Windows Server 2008 R2

Windows 7

Windows Server 2008

Windows Vista

Hosts de Internet

Sistemas Apple Macintosh

Grandes sistemas (mainframes) IBM

sistemas UNIX y Linux

Sistemas OpenVMS

Impresoras listas para red

Tabletas y teléfonos móviles con tecnología Ethernet cableada o inalámbrica

802.11 habilitada

Planear la implementación de DHCP

A continuación se indican los pasos clave de planeación antes de instalar el rol de
servidor DHCP.

Planear servidores DHCP y reenvío DHCP

Como los mensajes DHCP son mensajes de difusión, los enrutadores no los reenvían
entre subredes. Si tiene varias subredes y desea proporcionar el servicio DHCP para
cada subred, realice una de las acciones siguientes:

Instalar un servidor DHCP en cada subred

Configurar los enrutadores para reenviar los mensajes de difusión DHCP entre
subredes y configurar múltiples ámbitos en el servidor DHCP, un ámbito por
 subred.

En la mayoría de los casos, configurar los enrutadores para reenviar mensajes de

difusión DHCP es más rentable que implementar un servidor DHCP en cada segmento
físico de la red.

Planear intervalos de direcciones IP

Cada subred debe tener su propio intervalo de direcciones IP únicas. En un servidor
DHCP, dichos intervalos se representan con ámbitos.

Un ámbito es una agrupación administrativa de direcciones IP para equipos de una

subred que usa el servicio DHCP. El administrador crea primero un ámbito para cada
subred física y, a continuación, lo usa para definir los parámetros usados por los clientes.

Un ámbito tiene las siguientes propiedades:

Un intervalo de direcciones IP desde el que incluir o excluir las direcciones usadas

para las ofertas de concesión de servicio DHCP.

Una máscara de subred, que determina el prefijo de subred para una dirección IP
determinada.

Un nombre de ámbito asignado al crearlo.

Valores de duración de la concesión, asignados a los clientes DHCP que reciben las
direcciones IP asignadas dinámicamente.

Todas las opciones de ámbito DHCP configuradas para la asignación a clientes

DHCP (por ejemplo, dirección IP del servidor DNS y dirección IP de la puerta de
enlace predeterminada o enrutador).

Las reservas se usan opcionalmente para garantizar que un cliente DHCP reciba
siempre la misma dirección IP.

Antes de implementar los servidores, cree una lista con las subredes y los intervalos de
direcciones IP que desea usar para cada subred.

Planear máscaras de subred

Las máscaras de subred sirven para distinguir los identificadores de red de los
identificadores de host dentro de una dirección IP. Cada máscara de subred es un
número de 32 bits que usa grupos de bits consecutivos de todo unos (1) para reconocer
el identificador de red y de todo ceros (0) para reconocer las partes del identificador de
host de una dirección IP.

Por ejemplo, la máscara de subred que se usa normalmente con la dirección IP

[Link] es el siguiente número binario de 32 bits:

11111111 11111111 00000000 00000000

Este número de máscara de subred está compuesto de 16 bits de unos seguidos de

16 bits de ceros, lo que indica que las secciones del identificador de red y del
identificador de host de esta dirección IP tienen ambas 16 bits de longitud.
Normalmente, esta máscara de subred se muestra en notación decimal con puntos
como [Link].

La siguiente tabla muestra máscaras de subred para las clases de direcciones de

Internet.

Clase de dirección Bits para la máscara de subred Máscara de subred

Clase A 11111111 00000000 00000000 00000000 [Link]

Clase B 11111111 11111111 00000000 00000000 [Link]

Clase C 11111111 11111111 11111111 00000000 [Link]

Cuando se crea un ámbito en DHCP y se escribe el intervalo de direcciones IP para el

ámbito, DHCP proporciona estos valores predeterminados para las máscaras de subred.
Por lo general, los valores de la máscara de subred predeterminados son aceptables
para la mayoría de las redes que no tienen requisitos especiales y donde cada segmento
de red IP corresponde a una sola red física.

En ciertos casos, se pueden usar máscaras de subred personalizadas para implementar

las subredes IP. Con el establecimiento de subredes IP, se puede subdividir la parte del
identificador de host predeterminada de una dirección IP para especificar subredes, que
son subdivisiones del identificador de red basado en clases original.

Mediante la personalización de la longitud de la máscara de subred, se puede reducir el

número de bits que se usan para el identificador de host real.

Para evitar problemas de direccionamiento y enrutamiento, debería asegurarse de que

todos los equipos TCP/IP de un segmento de red usan la misma máscara de subred y de
que cada equipo o dispositivo tenga una dirección IP única.
Planear intervalos de exclusión
Cuando se crea un ámbito en un servidor DHCP, se especifica un intervalo de
direcciones IP que incluye todas las direcciones IP que el servidor DHCP está autorizado
a conceder a clientes DHCP, como equipos y otros dispositivos. Si después configura
manualmente algunos servidores y otros dispositivos con direcciones IP estáticas del
mismo intervalo de direcciones IP que está usando el servidor DHCP, puede crear
accidentalmente un conflicto de dirección IP en el que usted y el servidor DHCP tienen
asignada la misma dirección IP para diferentes dispositivos.

Para solucionar este problema, puede crear un intervalo de exclusión para el ámbito
DHCP. Un intervalo de exclusión es un intervalo contiguo de direcciones IP dentro del
intervalo de direcciones IP del ámbito que el servidor DHCP no puede usar. Si crea un
intervalo de exclusión, el servidor DHCP no asigna las direcciones en ese intervalo, lo
cual le permite asignar manualmente estas direcciones sin crear un conflicto de
direcciones IP.

El servidor DHCP puede excluir direcciones IP de la distribución creando un intervalo de

exclusión para cada ámbito. Las exclusiones se deberían usar para todos los dispositivos
que están configurados con una dirección IP estática. Las direcciones excluidas deberían
incluir todas las direcciones IP asignadas manualmente a otros servidores, clientes no
DHCP, estaciones de trabajo sin disco o clientes PPP y de Enrutamiento y acceso
remoto.

Se recomienda configurar el intervalo de exclusión con direcciones adicionales en

previsión de una futura ampliación de la red. La siguiente tabla proporciona un ejemplo
de intervalo de exclusión para un ámbito con un intervalo de direcciones IP de [Link]-
[Link] y una máscara de subred de [Link].

Elementos de configuración Valores de ejemplo

Dirección IP inicial del intervalo de exclusión [Link]

Dirección IP final del intervalo de exclusión [Link]

Planear la configuración estática de TCP/IP

Algunos dispositivos, como enrutadores, servidores DHCP y servidores DNS, se deben
configurar con una dirección IP estática. Además, es posible que tenga dispositivos
adicionales, como impresoras, para los que desee asegurarse de que tengan siempre la
misma dirección IP. Reúna en una lista los dispositivos que desee configurar
estáticamente para cada subred y, a continuación, planee el intervalo de exclusión que
desea usar en el servidor DHCP para asegurarse de que el servidor DHCP no conceda la
dirección IP de un dispositivo configurado estáticamente. Un intervalo de exclusión es
una secuencia limitada de direcciones IP dentro de un ámbito que está excluida de las
ofertas del servicio DHCP. Los intervalos de exclusión garantizan que el servidor no
ofrece ninguna de las direcciones incluidas en esos intervalos a los clientes DHCP de la
red.

Por ejemplo, si el intervalo de direcciones IP para una subred va de

[Link] a [Link] y tiene diez dispositivos que desea configurar con una
dirección IP estática, puede crear un intervalo de exclusión para el ámbito 192.168.0.x
que incluya diez o más direcciones IP: de [Link] a [Link].

En este ejemplo, se usan diez de las direcciones IP excluidas para configurar servidores y
otros dispositivos con direcciones IP estáticas, y quedan cinco direcciones IP más
disponibles para la configuración estática de nuevos dispositivos que puede que quiera
agregar en el futuro. Con este intervalo de exclusión, se ha dejado al servidor DHCP con
un grupo de direcciones que oscila entre [Link] y [Link].

En la siguiente tabla se proporcionan más elementos de configuración de ejemplo para

AD DS y DNS.

Elementos de configuración Valores de ejemplo

Enlaces de conexión de red Ethernet

Configuración del servidor DNS [Link]

Dirección IP del servidor DNS preferido [Link]

Valores de ámbito 1. Subred principal

1. Nombre del ámbito 2. [Link]
2. Dirección IP inicial 3. [Link]
3. Dirección IP final 4. [Link]
4. Máscara de subred 5. [Link]
5. Puerta de enlace predeterminada (opcional) 6. 8 días
6. Duración de la concesión

Modo de funcionamiento del servidor DHCP IPv6 no habilitado.

Uso de esta guía en un laboratorio de pruebas

Puede usar esta guía para implementar DHCP en un laboratorio de pruebas antes de
implementarlo en un entorno de producción.

７ Nota
 Si no desea implementar DHCP en un laboratorio de pruebas, puede ir
directamente a la sección Implementar DHCP.

Los requisitos de su laboratorio difieren en función de si usa servidores físicos o

máquinas virtuales (VM) y si usa un dominio de Active Directory o la implementación de
un servidor DHCP independiente.

Puede usar la siguiente información para determinar los recursos mínimos que necesita
para probar la implementación de DHCP mediante esta guía.

Requisitos del laboratorio de pruebas con máquinas

virtuales
Para implementar DHCP en un laboratorio de pruebas con máquinas virtuales, necesita
los siguientes recursos.

Para la implementación de dominio o la implementación independiente, necesita un

servidor configurado como host de Hyper-V.

Implementación de dominio

Esta implementación requiere un servidor físico, un conmutador virtual, dos servidores

virtuales y un cliente virtual:

En el servidor físico, en el Administrador de Hyper-V, cree los siguientes elementos.

1. Un conmutador virtual interno . No cree un conmutador virtual externo , ya que si

el host de Hyper-V está en una subred que incluye un servidor DHCP, las máquinas
virtuales de prueba recibirán una dirección IP del servidor DHCP. Además, el
servidor DHCP de prueba que implemente podría asignar direcciones IP a otros
equipos de la subred donde está instalado el host de Hyper-V.
2. Una máquina virtual que ejecuta Windows Server 2016 configurada como
controlador de dominio con Servicios de dominio de Active Directory que está
conectada al conmutador virtual interno que creó. Para que coincida con esta guía,
este servidor debe tener una dirección IP configurada estáticamente de [Link].
Para obtener información sobre la implementación de AD DS, consulte la sección
Implementación de DC1 en la Guía de red principal de Windows Server 2016.
3. Una máquina virtual que ejecuta Windows Server 2016 que configurará como un
servidor DHCP mediante esta guía y que está conectada al conmutador virtual
interno que creó.
4. Una máquina virtual que ejecuta un sistema operativo cliente de Windows que
está conectado al conmutador virtual interno que creó y que usará para
 comprobar que el servidor DHCP está asignando dinámicamente las direcciones IP
y las opciones DHCP a los clientes DHCP.

Implementación de servidor DHCP independiente

Esta implementación requiere un servidor físico, un conmutador virtual, un servidor

virtual y un cliente virtual:

En el servidor físico, en el Administrador de Hyper-V, cree los siguientes elementos.

1. Un conmutador virtual interno . No cree un conmutador virtual externo , ya que si

el host de Hyper-V está en una subred que incluye un servidor DHCP, las máquinas
virtuales de prueba recibirán una dirección IP del servidor DHCP. Además, el
servidor DHCP de prueba que implemente podría asignar direcciones IP a otros
equipos de la subred donde está instalado el host de Hyper-V.
2. Una máquina virtual que ejecuta Windows Server 2016 que configurará como un
servidor DHCP mediante esta guía y que está conectada al conmutador virtual
interno que creó.
3. Una máquina virtual que ejecuta un sistema operativo cliente de Windows que
está conectado al conmutador virtual interno que creó y que usará para
comprobar que el servidor DHCP está asignando dinámicamente las direcciones IP
y las opciones DHCP a los clientes DHCP.

Requisitos del laboratorio de prueba con servidores

físicos
Para implementar DHCP en un laboratorio de prueba con servidores físicos, necesita los
siguientes recursos.

Implementación de dominio

Esta implementación requiere un concentrador o conmutador, dos servidores físicos y

un cliente físico:

1. Un concentrador Ethernet o conmutador al que puede conectar los equipos físicos

con cables Ethernet
2. Un equipo físico que ejecuta Windows Server 2016 configurado como controlador
de dominio con Servicios de dominio de Active Directory. Para que coincida con
esta guía, este servidor debe tener una dirección IP configurada estáticamente de
[Link]. Para obtener información sobre la implementación de AD DS, consulte la
sección Implementación de DC1 en la Guía de red principal de Windows Server
2016.
 3. Un equipo físico que ejecuta Windows Server 2016 que configurará como servidor
DHCP mediante esta guía.
4. Un equipo físico que ejecuta un sistema operativo cliente Windows que usará para
comprobar que el servidor DHCP asigna dinámicamente direcciones IP y opciones
DHCP a los clientes DHCP.

７ Nota

Si no tiene suficientes máquinas de prueba para esta implementación, puede usar

una máquina de prueba para AD DS y DHCP, pero esta configuración no se
recomienda para un entorno de producción.

Implementación de servidor DHCP independiente

Esta implementación requiere un concentrador o conmutador, un servidor físico y un

cliente físico:

1. Un concentrador Ethernet o conmutador al que puede conectar los equipos físicos

con cables Ethernet
2. Un equipo físico que ejecuta Windows Server 2016 que configurará como servidor
DHCP mediante esta guía.
3. Un equipo físico que ejecuta un sistema operativo cliente Windows que usará para
comprobar que el servidor DHCP asigna dinámicamente direcciones IP y opciones
DHCP a los clientes DHCP.

Implementación de DHCP
En esta sección se proporcionan comandos de ejemplo Windows PowerShell que puede
usar para implementar DHCP en un servidor. Antes de ejecutar estos comandos de
ejemplo en el servidor, debe modificar los comandos para que coincidan con la red y el
entorno.

Por ejemplo, antes de ejecutar los comandos, debe reemplazar los valores de ejemplo
de los comandos para los siguientes elementos:

Nombres de equipo
Intervalo de direcciones IP para cada ámbito que quiera configurar (1 ámbito por
subred)
Máscara de subred para cada intervalo de direcciones IP que quiera configurar
Nombre de ámbito para cada ámbito
Intervalo de exclusión para cada ámbito
 Valores de opción DHCP, como la puerta de enlace predeterminada, el nombre de
dominio y los servidores DNS o WINS
Nombres de interfaz

） Importante

Examine y modifique todos los comandos de su entorno antes de ejecutar el

comando.

¿Dónde instalar DHCP: en un equipo físico o en una

máquina virtual?
Puede instalar el rol de servidor DHCP en un equipo físico o en una máquina virtual
(VM) instalada en un host de Hyper-V. Si va a instalar DHCP en una máquina virtual y
desea que el servidor DHCP proporcione asignaciones de direcciones IP a los equipos
de la red física a la que está conectado el host de Hyper-V, debe conectar el adaptador
de red virtual de máquina virtual a un conmutador virtual de Hyper-V que sea Externo.

Para obtener más información, consulte la sección Creación de un conmutador virtual

con el Administrador de Hyper-V en el tema Creación de una red virtual.

Ejecutar Windows PowerShell como administrador

Puede usar el procedimiento siguiente para ejecutar Windows PowerShell con
privilegios de administrador.

1. En un equipo que ejecuta Windows Server 2016, haga clic en Inicio y, a

continuación, haga clic con el botón derecho en el icono de Windows PowerShell.
Aparece un menú.

2. En el menú, haga clic en Másy, a continuación, haga clic en Ejecutar como

administrador. Si se le solicita, escriba las credenciales de una cuenta que tenga
privilegios de administrador en el equipo. Si la cuenta de usuario con la que ha
iniciado sesión en el equipo es una cuenta de nivel de administrador, no recibirá
un mensaje de credenciales.

3. Windows PowerShell se abre con privilegios de administrador.

Cambiar el nombre del servidor DHCP y configurar una

dirección IP estática
Si aún no lo ha hecho, puede usar los siguientes comandos de Windows PowerShell
para cambiar el nombre del servidor DHCP y configurar una dirección IP estática para el
servidor.

Configuración de una dirección IP estática

Puede usar los siguientes comandos para asignar una dirección IP estática al servidor
DHCP y configurar las propiedades TCP/IP del servidor DHCP con la dirección IP correcta
del servidor DNS. También debe reemplazar los nombres de interfaz y las direcciones IP
de este ejemplo por los valores que quiera usar para configurar el equipo.

New-NetIPAddress -IPAddress [Link] -InterfaceAlias "Ethernet" -

DefaultGateway [Link] -AddressFamily IPv4 -PrefixLength 24
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses
[Link]

Para obtener más información sobre estos comandos, consulte los temas siguientes.

New-NetIPAddress
Set-DnsClientServerAddress

Cambiar el nombre del equipo

Puede usar los siguientes comandos para cambiar el nombre y, a continuación, reiniciar
el equipo.

Rename-Computer -Name DHCP1

Restart-Computer

Para obtener más información sobre estos comandos, consulte los temas siguientes.

Rename-Computer
Restart-Computer

Unir el equipo al dominio (opcional)

Si va a instalar el servidor DHCP en un entorno de dominio de Active Directory, debe
unir el equipo al dominio. Abra Windows PowerShell con privilegios de administrador y,
a continuación, ejecute el siguiente comando después de reemplazar el dominio
NetBios name CORP por un valor adecuado para su entorno.
 Add-Computer CORP

Cuando se le solicite, escriba las credenciales de una cuenta de usuario de dominio que
tenga permiso para unir un equipo al dominio.

Restart-Computer

Para obtener más información sobre el comando Add-Computer, consulte el tema

siguiente.

Add-Computer

Instalación de DHCP
Después de reiniciar el equipo, abra Windows PowerShell con privilegios de
administrador y, a continuación, instale DHCP ejecutando el siguiente comando.

Install-WindowsFeature DHCP -IncludeManagementTools

Para obtener más información sobre este comando, vea el tema siguiente.

Install-WindowsFeature

Creación de grupos de seguridad DHCP

Para crear grupos de seguridad, debe ejecutar un comando de Shell de red (netsh) en
Windows PowerShell y, a continuación, reiniciar el servicio DHCP para que los nuevos
grupos se activen.

Al ejecutar el siguiente comando netsh en el servidor DHCP, los grupos de seguridad

Administradores y usuarios DHCP de DHCP se crean en Usuarios y grupos locales en el
servidor DHCP.

netsh dhcp add securitygroups

El siguiente comando reinicia el servicio DHCP en el equipo local.

Restart-Service dhcpserver

Para obtener más información sobre estos comandos, consulte los temas siguientes.

Shell de red (Netsh)

Restart-Service

Autorización del servidor DHCP en Active Directory

(opcional)
Si va a instalar DHCP en un entorno de dominio, debe realizar los pasos siguientes para
autorizar al servidor DHCP para que funcione en el dominio.

７ Nota

Los servidores DHCP no autorizados que están instalados en dominios de Active

Directory no pueden funcionar correctamente y no alquilan direcciones IP a los
clientes DHCP. La deshabilitación automática de servidores DHCP no autorizados es
una característica de seguridad que impide que los servidores DHCP no
autorizados asignen direcciones IP incorrectas a los clientes de la red.

Puede usar el siguiente comando para agregar el servidor DHCP a la lista de servidores
DHCP autorizados en Active Directory.

７ Nota

Si no tiene un entorno de dominio, no ejecute este comando.

Add-DhcpServerInDC -DnsName [Link] -IPAddress [Link]

Para comprobar que el servidor DHCP está autorizado en Active Directory, puede usar el
siguiente comando.
 Get-DhcpServerInDC

A continuación se muestran los resultados de ejemplo que se muestran en Windows

PowerShell.

IPAddress DnsName
--------- -------
[Link] [Link]

Para obtener más información sobre estos comandos, consulte los temas siguientes.

Add-DhcpServerInDC
Get-DhcpServerInDC

Notificar a Administrador del servidor que la

configuración de DHCP posterior a la instalación está
completa (opcional)
Una vez completadas las tareas posteriores a la instalación, como crear grupos de
seguridad y autorizar el servidor DHCP en Active Directory, Administrador del servidor
podría seguir mostrando una alerta en la interfaz de usuario que indica que los pasos
posteriores a la instalación deben completarse mediante el Asistente para configuración
posterior a la instalación de DHCP.

Puede evitar que este mensaje innecesario e inexacto aparezca en Administrador del
servidor configurando la siguiente clave del Registro mediante este comando Windows
PowerShell.

Set-ItemProperty –Path
registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager\Roles\12 –Name
ConfigurationState –Value 2

Para obtener más información sobre este comando, vea el tema siguiente.

Set-ItemProperty

Establecer las opciones de configuración de actualización

dinámica de DNS de nivel de servidor (opcional)
Si desea que el servidor DHCP realice actualizaciones dinámicas de DNS para equipos
cliente DHCP, puede ejecutar el siguiente comando para configurar esta configuración.
Se trata de una configuración de nivel de servidor, no una configuración de nivel de
ámbito, por lo que afectará a todos los ámbitos que configure en el servidor. Este
comando de ejemplo también configura el servidor DHCP para eliminar los registros de
recursos DNS de los clientes cuando el cliente expira al menos.

Set-DhcpServerv4DnsSetting -ComputerName "[Link]" -

DynamicUpdates "Always" -DeleteDnsRRonLeaseExpiry $True

Puede usar el siguiente comando para configurar las credenciales que usa el servidor
DHCP para registrar o anular el registro de registros de cliente en un servidor DNS. En
este ejemplo se guarda una credencial en un servidor DHCP. El primer comando usa
Get-Credential para crear un objeto PSCredential y, a continuación, almacena el objeto
en la variable $Credential . El comando le pide el nombre de usuario y la contraseña,
por lo que debe asegurarse de proporcionar credenciales para una cuenta que tenga
permiso para actualizar los registros de recursos en el servidor DNS.

$Credential = Get-Credential
Set-DhcpServerDnsCredential -Credential $Credential -ComputerName
"[Link]"

Para obtener más información sobre estos comandos, consulte los temas siguientes.

Set-DhcpServerv4DnsSetting
Set-DhcpServerDnsCredential

Configuración del ámbito de la red corporativa

Una vez completada la instalación de DHCP, puede usar los siguientes comandos para
configurar y activar el ámbito corpnet, crear un intervalo de exclusión para el ámbito y
configurar las opciones de DHCP predeterminadas puerta de enlace, dirección IP del
servidor DNS y nombre de dominio DNS.

Add-DhcpServerv4Scope -name "Corpnet" -StartRange [Link] -EndRange

[Link] -SubnetMask [Link] -State Active
Add-DhcpServerv4ExclusionRange -ScopeID [Link] -StartRange [Link] -
EndRange [Link]
 Set-DhcpServerv4OptionValue -OptionID 3 -Value [Link] -ScopeID [Link] -
ComputerName [Link]
Set-DhcpServerv4OptionValue -DnsDomain [Link] -DnsServer [Link]

Para obtener más información sobre estos comandos, consulte los temas siguientes.

Add-DhcpServerv4Scope
Add-DhcpServerv4ExclusionRange
Set-DhcpServerv4OptionValue

Configurar el ámbito corpnet2 (opcional)

Si tiene una segunda subred conectada a la primera subred con un enrutador donde
está habilitado el reenvío DHCP, puede usar los siguientes comandos para agregar un
segundo ámbito, denominado Corpnet2 para este ejemplo. En este ejemplo también se
configura un intervalo de exclusión y la dirección IP de la puerta de enlace
predeterminada (la dirección IP del enrutador en la subred) de la subred Corpnet2.

Add-DhcpServerv4Scope -name "Corpnet2" -StartRange [Link] -EndRange

[Link] -SubnetMask [Link] -State Active
Add-DhcpServerv4ExclusionRange -ScopeID [Link] -StartRange [Link] -
EndRange [Link]
Set-DhcpServerv4OptionValue -OptionID 3 -Value [Link] -ScopeID [Link] -
ComputerName [Link]

Si tiene subredes adicionales que son administradas por este servidor DHCP, puede
repetir estos comandos, mediante valores diferentes para todos los parámetros de
comando, para agregar ámbitos para cada subred.

） Importante

Asegúrese de que todos los enrutadores entre los clientes DHCP y el servidor DHCP
estén configurados para el reenvío de mensajes DHCP. Consulte la documentación
del enrutador para obtener información sobre cómo configurar el reenvío DHCP.

Comprobar la funcionalidad del servidor

Para comprobar que el servidor DHCP proporciona una asignación dinámica de
direcciones IP a los clientes DHCP, puede conectar otro equipo a una subred con
servicio. Después de conectar el cable Ethernet al adaptador de red y encenderlo en el
equipo, solicitará una dirección IP desde el servidor DHCP. Puede comprobar la
configuración correcta mediante el comando ipconfig /all y revisar los resultados, o
realizando pruebas de conectividad, como intentar acceder a los recursos web con el
explorador o los recursos compartidos de archivos con Windows Explorer u otras
aplicaciones.

Si el cliente no recibe una dirección IP del servidor DHCP, realice los pasos de solución
de problemas siguientes.

1. Asegúrese de que el cable Ethernet esté conectado tanto en el equipo como en el

conmutador Ethernet, el concentrador o el enrutador.
2. Si ha conectado el equipo cliente a un segmento de red separado del servidor
DHCP por un enrutador, asegúrese de que el enrutador esté configurado para
reenviar mensajes DHCP.
3. Asegúrese de que el servidor DHCP está autorizado en Active Directory mediante
la ejecución del siguiente comando para recuperar la lista de servidores DHCP
autorizados de Active Directory. Get-DhcpServerInDC.
4. Asegúrese de que los ámbitos están activados abriendo la consola DHCP
(Administrador del servidor, Herramientas, DHCP), expandiendo el árbol del
servidor para revisar los ámbitos y, a continuación, haciendo clic con el botón
derecho en cada ámbito. Si el menú resultante incluye la selección Activar, haga
clic en Activar. (Si el ámbito ya está activado, la selección del menú lee Desactivar).

comandos de Windows PowerShell para DHCP

La referencia siguiente proporciona descripciones de comandos y sintaxis para todos los
comandos de Windows PowerShell del servidor DHCP para Windows Server 2016. En el
tema se enumeran los comandos en orden alfabético en función del verbo al principio
de los comandos, como Get o Set.

７ Nota

No puede usar comandos de Windows Server 2016 en Windows Server 2012 R2.

Módulo DhcpServer

La siguiente referencia proporciona descripciones de comandos y sintaxis para todos los

comandos de Windows PowerShell del servidor DHCP para Windows Server 2012 R2. En
el tema se enumeran los comandos en orden alfabético en función del verbo al principio
de los comandos, como Get o Set.
 ７ Nota

Puede usar Windows Server 2012 comandos R2 en Windows Server 2016.

Cmdlets de servidor DHCP en Windows PowerShell

Lista de comandos de Windows PowerShell en

esta guía
A continuación se muestra una lista sencilla de comandos y valores de ejemplo que se
usan en esta guía.

New-NetIPAddress -IPAddress [Link] -InterfaceAlias "Ethernet" -

DefaultGateway [Link] -AddressFamily IPv4 -PrefixLength 24
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses
[Link]
Rename-Computer -Name DHCP1
Restart-Computer

Add-Computer CORP
Restart-Computer

Install-WindowsFeature DHCP -IncludeManagementTools

netsh dhcp add securitygroups
Restart-Service dhcpserver

Add-DhcpServerInDC -DnsName [Link] -IPAddress [Link]

Get-DhcpServerInDC

Set-ItemProperty –Path
registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager\Roles\12 –Name
ConfigurationState –Value 2

Set-DhcpServerv4DnsSetting -ComputerName "[Link]" -

DynamicUpdates "Always" -DeleteDnsRRonLeaseExpiry $True

$Credential = Get-Credential
Set-DhcpServerDnsCredential -Credential $Credential -ComputerName
"[Link]"

rem At prompt, supply credential in form DOMAIN\user, password

rem Configure scope Corpnet

Add-DhcpServerv4Scope -name "Corpnet" -StartRange [Link] -EndRange
[Link] -SubnetMask [Link] -State Active
Add-DhcpServerv4ExclusionRange -ScopeID [Link] -StartRange [Link] -
EndRange [Link]
Set-DhcpServerv4OptionValue -OptionID 3 -Value [Link] -ScopeID [Link] -
ComputerName [Link]
Set-DhcpServerv4OptionValue -DnsDomain [Link] -DnsServer [Link]

rem Configure scope Corpnet2

Add-DhcpServerv4Scope -name "Corpnet2" -StartRange [Link] -EndRange
[Link] -SubnetMask [Link] -State Active
Add-DhcpServerv4ExclusionRange -ScopeID [Link] -StartRange [Link] -
EndRange [Link]
Set-DhcpServerv4OptionValue -OptionID 3 -Value [Link] -ScopeID [Link] -
ComputerName [Link]
Guía de solución de problemas del
Protocolo de configuración dinámica de
host (DHCP)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Para que cualquier dispositivo (como un equipo o teléfono) pueda funcionar en una red,
debe asignarse una dirección IP. Puede asignar una dirección IP de forma manual o
automática. El servicio DHCP (Microsoft o un servidor de terceros) controla la asignación
automática.

En este artículo, analizaremos los pasos generales de solución de problemas para el

cliente DHCP y el servidor IPv4 de Microsoft.

Más información
El procedimiento para la asignación de direcciones IPv4 suele implicar tres componentes
principales:

Un dispositivo cliente DHCP que tiene que obtener una dirección IP

Un servicio DHCP que proporciona direcciones IP al cliente en función de una

configuración específica

Un agente de retransmisión DHCP /IP Helper para enviar solicitudes de difusión

DHCP a un segmento de red diferente

Una comunicación de cliente a servidor DHCP consta de tres tipos de interacción entre
los dos sistemas del mismo nivel:

DORA basada en difusión (Detección, Oferta, Solicitud, Confirmación). Este

proceso consta de los pasos siguientes:

El cliente DHCP envía una solicitud de difusión de detección dhcp a todos los
servidores DHCP disponibles dentro del intervalo.

Se recibe una respuesta de difusión de oferta DHCP del servidor DHCP, que
ofrece una concesión de dirección IP disponible.

La solicitud de difusión del cliente DHCP solicita la concesión de dirección IP

ofrecida y la confirmación de difusión DHCP al final.
 Si el cliente y el servidor DHCP se encuentran en diferentes segmentos de red
lógica, un agente de retransmisión DHCP actúa como reenviador y envía los
paquetes de difusión DHCP entre pares.

Solicitudes de renovación dhcp de unidifusión: se envían directamente al servidor

DHCP desde el cliente DHCP para renovar la asignación de direcciones IP después
del 50 % del tiempo de concesión de la dirección IP.

Reenlace las solicitudes de difusión DHCP: se realizan en cualquier servidor DHCP

dentro del intervalo del cliente. Estos se envían después del 87,5 % de la duración
de concesión de la dirección IP porque esto indica que la solicitud de unidifusión
dirigida no funcionó. En cuanto al proceso de DORA, este proceso implica una
comunicación del agente de retransmisión DHCP.

Si un cliente DHCP de Microsoft no recibe una dirección IPv4 DHCP válida, es probable
que el cliente esté configurado para usar una dirección APIPA. Para obtener más
información, consulte el siguiente artículo de Knowledge Base: 220874 Cómo usar el
direccionamiento TCP/IP automático sin un servidor DHCP.

Toda la comunicación se realiza en los puertos UDP 67 y 68. Para obtener más
información, consulte el siguiente artículo de Knowledge Base: conceptos básicos de
169289 DHCP (Protocolo de configuración dinámica de host).
Conceptos básicos de DHCP (protocolo
de configuración dinámica de host)
Artículo • 21/12/2022 • Tiempo de lectura: 15 minutos

El Protocolo de configuración dinámica de host (DHCP) es un protocolo estándar

definido por RFC 1541 (que se sustituye por RFC 2131) que permite a un servidor
distribuir dinámicamente información de configuración y direccionamiento IP a los
clientes. Normalmente, el servidor DHCP proporciona al cliente al menos esta
información básica:

Dirección IP

Máscara de subred

Puerta de enlace predeterminada También se puede proporcionar otra

información, como direcciones de servidor del Servicio de nombres de dominio
(DNS) y Windows servidor del Servicio de nombres de Internet (WINS). El
administrador del sistema configura el servidor DHCP con las opciones que se
analizan en el cliente.

Más información
Los siguientes productos de Microsoft proporcionan funcionalidad de cliente DHCP:

Windows nt server 3.5, 3.51 y 4.0

Windows nt workstation versiones 3.5, 3.51 y 4.0

Windows 95

Microsoft Network Client versión 3.0 para MS-DOS

Cliente de Microsoft LAN Manager versión 2.2c para MS-DOS

Microsoft TCP/IP-32 for Windows for Workgroups versiones 3.11, 3.11a y 3.11b

Los distintos clientes DHCP admiten distintas opciones que pueden recibir del servidor
DHCP.

Los siguientes sistemas operativos de servidor de Microsoft proporcionan funcionalidad

de servidor DHCP:

Windows nt server versión 3.5

 Windows nt server versión 3.51

Windows nt server versión 4.0

Cuando un cliente se inicializa por primera vez después de configurarse para recibir
información dhcp, inicia una conversación con el servidor.

A continuación se muestra una tabla de resumen de la conversación entre el cliente y el

servidor, que va seguida de una descripción de nivel de paquete del proceso:

Source Dest Source Dest Packet

MAC addr MAC addr IP addr IP addr Description
-----------------------------------------------------------------
Client Broadcast [Link] [Link] DHCP Discover
DHCPsrvr Broadcast DHCPsrvr [Link] DHCP Offer
Client Broadcast [Link] [Link] DHCP Request
DHCPsrvr Broadcast DHCPsrvr [Link] DHCP ACK

La conversación detallada entre el cliente DHCP y el servidor DHCP es la siguiente:

DHCPDISCOVER
El cliente envía un paquete DHCPDISCOVER. A continuación se muestra un extracto de
una captura de monitor de red que muestra las partes IP y DHCP de un paquete
DHCPDISCOVER. En la sección IP, puede ver que la dirección de destino es
[Link] y la dirección de origen es [Link]. La sección DHCP identifica el
paquete como un paquete discover e identifica el cliente en dos lugares mediante la
dirección física de la tarjeta de red. Tenga en cuenta que los valores del campo DEDRDR
y el campo DHCP: Identificador de cliente son idénticos.

IP: ID = 0x0; Proto = UDP; Len: 328

IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
IP: Service Type = 0 (0x0)
IP: Precedence = Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: Total Length = 328 (0x148)
IP: Identification = 0 (0x0)
IP: Flags Summary = 0 (0x0)
IP: .......0 = Last fragment in datagram
IP: ......0. = May fragment datagram if necessary
 IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 128 (0x80)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x39A6
IP: Source Address = [Link]
IP: Destination Address = [Link]
IP: Data: Number of data bytes remaining = 308 (0x0134)

DHCP: Discover (xid=21274A1D)

DHCP: Op Code (op) = 1 (0x1)
DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
DHCP: Hardware Address Length (hlen) = 6 (0x6)
DHCP: Hops (hops) = 0 (0x0)
DHCP: Transaction ID (xid) = 556223005 (0x21274A1D)
DHCP: Seconds (secs) = 0 (0x0)
DHCP: Flags (flags) = 0 (0x0)
DHCP: 0............... = No Broadcast
DHCP: Client IP Address (ciaddr) = [Link]
DHCP: Your IP Address (yiaddr) = [Link]
DHCP: Server IP Address (siaddr) = [Link]
DHCP: Relay IP Address (giaddr) = [Link]
DHCP: Client Ethernet Address (chaddr) = 08002B2ED85E
DHCP: Server Host Name (sname) = <Blank>
DHCP: Boot File Name (file) = <Blank>
DHCP: Magic Cookie = [OK]
DHCP: Option Field (options)
DHCP: DHCP Message Type = DHCP Discover
DHCP: Client-identifier = (Type: 1) 08 00 2b 2e d8 5e
DHCP: Host Name = JUMBO-WS
DHCP: Parameter Request List = (Length: 7) 01 0f 03 2c 2e 2f 06
DHCP: End of this option field

DHCPOFFER
El servidor DHCP responde mediante el envío de un paquete DHCPOFFER. En la sección
IP del extracto de captura siguiente, la dirección de origen es ahora la dirección IP del
servidor DHCP y la dirección de destino es la dirección de difusión [Link]. La
sección DHCP identifica el paquete como una oferta. El campo YIADDR se rellena con la
dirección IP que el servidor ofrece al cliente. Tenga en cuenta que el campoDRDR
todavía contiene la dirección física del cliente solicitante. Además, vemos en la sección
Campo de opción DHCP las distintas opciones que envía el servidor junto con la
dirección IP. En este caso, el servidor envía la máscara de subred, la puerta de enlace
predeterminada (enrutador), el tiempo de concesión, la dirección del servidor WINS
(servicio de nombres NetBIOS) y el tipo de nodo NetBIOS.
IP: ID = 0x3C30; Proto = UDP; Len: 328
IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
IP: Service Type = 0 (0x0)
IP: Precedence = Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: Total Length = 328 (0x148)
IP: Identification = 15408 (0x3C30)
IP: Flags Summary = 0 (0x0)
IP: .......0 = Last fragment in datagram
IP: ......0. = May fragment datagram if necessary
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 128 (0x80)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x2FA8
IP: Source Address = [Link]
IP: Destination Address = [Link]
IP: Data: Number of data bytes remaining = 308 (0x0134)

DHCP: Offer (xid=21274A1D)

DHCP: Op Code (op) = 2 (0x2)
DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
DHCP: Hardware Address Length (hlen) = 6 (0x6)
DHCP: Hops (hops) = 0 (0x0)
DHCP: Transaction ID (xid) = 556223005 (0x21274A1D)
DHCP: Seconds (secs) = 0 (0x0)
DHCP: Flags (flags) = 0 (0x0)
DHCP: 0............... = No Broadcast
DHCP: Client IP Address (ciaddr) = [Link]
DHCP: Your IP Address (yiaddr) = [Link]
DHCP: Server IP Address (siaddr) = [Link]
DHCP: Relay IP Address (giaddr) = [Link]
DHCP: Client Ethernet Address (chaddr) = 08002B2ED85E
DHCP: Server Host Name (sname) = <Blank>
DHCP: Boot File Name (file) = <Blank>
DHCP: Magic Cookie = [OK]
DHCP: Option Field (options)
DHCP: DHCP Message Type = DHCP Offer
DHCP: Subnet Mask = [Link]
DHCP: Renewal Time Value (T1) = 8 Days, 0:00:00
DHCP: Rebinding Time Value (T2) = 14 Days, 0:00:00
DHCP: IP Address Lease Time = 16 Days, 0:00:00
DHCP: Server Identifier = [Link]
DHCP: Router = [Link]
DHCP: NetBIOS Name Service = [Link]
DHCP: NetBIOS Node Type = (Length: 1) 04
DHCP: End of this option field
DHCPREQUEST
El cliente responde a DHCPOFFER mediante el envío de una DHCPREQUEST. En la
sección IP de la captura siguiente, la dirección de origen del cliente sigue siendo [Link]
y el destino del paquete sigue siendo [Link].255. El cliente conserva [Link]
porque el cliente no ha recibido la comprobación del servidor de que es correcto
empezar a usar la dirección ofrecida. El destino todavía se difunde, ya que es posible
que más de un servidor DHCP haya respondido y que esté manteniendo una reserva
para una oferta realizada al cliente. Esto permite a los demás servidores DHCP saber que
pueden liberar sus direcciones ofrecidas y devolverlas a sus grupos disponibles. La
sección DHCP identifica el paquete como una solicitud y comprueba la dirección
ofrecida mediante el campo DHCP: Dirección solicitada. El campo DHCP: Identificador
de servidor muestra la dirección IP del servidor DHCP que ofrece la concesión.

IP: ID = 0x100; Proto = UDP; Len: 328

IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
IP: Service Type = 0 (0x0)
IP: Precedence = Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: Total Length = 328 (0x148)
IP: Identification = 256 (0x100)
IP: Flags Summary = 0 (0x0)
IP: .......0 = Last fragment in datagram
IP: ......0. = May fragment datagram if necessary
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 128 (0x80)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x38A6
IP: Source Address = [Link]
IP: Destination Address = [Link]
IP: Data: Number of data bytes remaining = 308 (0x0134)

DHCP: Request (xid=21274A1D)

DHCP: Op Code (op) = 1 (0x1)
DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
DHCP: Hardware Address Length (hlen) = 6 (0x6)
DHCP: Hops (hops) = 0 (0x0)
DHCP: Transaction ID (xid) = 556223005 (0x21274A1D)
DHCP: Seconds (secs) = 0 (0x0)
DHCP: Flags (flags) = 0 (0x0)
DHCP: 0............... = No Broadcast
DHCP: Client IP Address (ciaddr) = [Link]
DHCP: Your IP Address (yiaddr) = [Link]
DHCP: Server IP Address (siaddr) = [Link]
 DHCP: Relay IP Address (giaddr) = [Link]
DHCP: Client Ethernet Address (chaddr) = 08002B2ED85E
DHCP: Server Host Name (sname) = <Blank>
DHCP: Boot File Name (file) = <Blank>
DHCP: Magic Cookie = [OK]
DHCP: Option Field (options)
DHCP: DHCP Message Type = DHCP Request
DHCP: Client-identifier = (Type: 1) 08 00 2b 2e d8 5e
DHCP: Requested Address = [Link]
DHCP: Server Identifier = [Link]
DHCP: Host Name = JUMBO-WS
DHCP: Parameter Request List = (Length: 7) 01 0f 03 2c 2e 2f 06
DHCP: End of this option field

DHCPACK
El servidor DHCP responde a DHCPREQUEST con dhcpack, completando así el ciclo de
inicialización. La dirección de origen es la dirección IP del servidor DHCP y la dirección
de destino sigue siendo [Link]. El campo YIADDR contiene la dirección del
cliente y los campos DHCPDR y DHCP: Identificador de cliente son la dirección física de
la tarjeta de red en el cliente solicitante. La sección Opción DHCP identifica el paquete
como una ACK.

IP: ID = 0x3D30; Proto = UDP; Len: 328

IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
IP: Service Type = 0 (0x0)
IP: Precedence = Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: Total Length = 328 (0x148)
IP: Identification = 15664 (0x3D30)
IP: Flags Summary = 0 (0x0)
IP: .......0 = Last fragment in datagram
IP: ......0. = May fragment datagram if necessary
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 128 (0x80)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x2EA8
IP: Source Address = [Link]
IP: Destination Address = [Link]
IP: Data: Number of data bytes remaining = 308 (0x0134)

DHCP: ACK (xid=21274A1D)

DHCP: Op Code (op) = 2 (0x2)
 DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
DHCP: Hardware Address Length (hlen) = 6 (0x6)
DHCP: Hops (hops) = 0 (0x0)
DHCP: Transaction ID (xid) = 556223005 (0x21274A1D)
DHCP: Seconds (secs) = 0 (0x0)
DHCP: Flags (flags) = 0 (0x0)
DHCP: 0............... = No Broadcast
DHCP: Client IP Address (ciaddr) = [Link]
DHCP: Your IP Address (yiaddr) = [Link]
DHCP: Server IP Address (siaddr) = [Link]
DHCP: Relay IP Address (giaddr) = [Link]
DHCP: Client Ethernet Address (chaddr) = 08002B2ED85E
DHCP: Server Host Name (sname) = <Blank>
DHCP: Boot File Name (file) = <Blank>
DHCP: Magic Cookie = [OK]
DHCP: Option Field (options)
DHCP: DHCP Message Type = DHCP ACK
DHCP: Renewal Time Value (T1) = 8 Days, 0:00:00
DHCP: Rebinding Time Value (T2) = 14 Days, 0:00:00
DHCP: IP Address Lease Time = 16 Days, 0:00:00
DHCP: Server Identifier = [Link]
DHCP: Subnet Mask = [Link]
DHCP: Router = [Link]
DHCP: NetBIOS Name Service = [Link]
DHCP: NetBIOS Node Type = (Length: 1) 04
DHCP: End of this option field

Si el cliente ya tenía asignada una dirección IP DHCP y se reinicia, el cliente solicitará

específicamente la dirección IP concesionada previamente en un paquete
DHCPREQUEST especial. La dirección de origen es [Link] y el destino es la dirección de
difusión [Link]. Los clientes de Microsoft rellenarán el campo de opción DHCP
DHCP: Dirección solicitada con la dirección asignada previamente. Los clientes
estrictamente compatibles con RFC rellenarán el campo DEDDR con la dirección
solicitada. El servidor DHCP de Microsoft aceptará cualquiera de los dos.

IP: ID = 0x0; Proto = UDP; Len: 328

IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
IP: Service Type = 0 (0x0)
IP: Precedence = Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: Total Length = 328 (0x148)
IP: Identification = 0 (0x0)
IP: Flags Summary = 0 (0x0)
IP: .......0 = Last fragment in datagram
 IP: ......0. = May fragment datagram if necessary
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 128 (0x80)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x39A6
IP: Source Address = [Link]
IP: Destination Address = [Link]
IP: Data: Number of data bytes remaining = 308 (0x0134)

DHCP: Request (xid=2757554E)

DHCP: Op Code (op) = 1 (0x1)
DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
DHCP: Hardware Address Length (hlen) = 6 (0x6)
DHCP: Hops (hops) = 0 (0x0)
DHCP: Transaction ID (xid) = 660034894 (0x2757554E)
DHCP: Seconds (secs) = 0 (0x0)
DHCP: Flags (flags) = 0 (0x0)
DHCP: 0............... = No Broadcast
DHCP: Client IP Address (ciaddr) = [Link]
DHCP: Your IP Address (yiaddr) = [Link]
DHCP: Server IP Address (siaddr) = [Link]
DHCP: Relay IP Address (giaddr) = [Link]
DHCP: Client Ethernet Address (chaddr) = 08002B2ED85E
DHCP: Server Host Name (sname) = <Blank>
DHCP: Boot File Name (file) = <Blank>
DHCP: Magic Cookie = [OK]
DHCP: Option Field (options)
DHCP: DHCP Message Type = DHCP Request
DHCP: Client-identifier = (Type: 1) 08 00 2b 2e d8 5e
DHCP: Requested Address = [Link]
DHCP: Host Name = JUMBO-WS
DHCP: Parameter Request List = (Length: 7) 01 0f 03 2c 2e 2f 06
DHCP: End of this option field

En este momento, el servidor puede responder o no. El comportamiento del servidor

DHCP Windows NT depende de la versión del sistema operativo que se esté utilizando,
así como de otros factores, como el superscoping. Si el servidor determina que el cliente
puede seguir utilizando la dirección, permanecerá en modo silencioso o ACK la
DHCPREQUEST. Si el servidor determina que el cliente no puede tener la dirección,
enviará un NACK.

IP: ID = 0x3F1A; Proto = UDP; Len: 328

IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
IP: Service Type = 0 (0x0)
IP: Precedence = Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
 IP: .....0.. = Normal Reliability
IP: Total Length = 328 (0x148)
IP: Identification = 16154 (0x3F1A)
IP: Flags Summary = 0 (0x0)
IP: .......0 = Last fragment in datagram
IP: ......0. = May fragment datagram if necessary
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 128 (0x80)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x2CBE
IP: Source Address = [Link]
IP: Destination Address = [Link]
IP: Data: Number of data bytes remaining = 308 (0x0134)

DHCP: NACK (xid=74A005CE)

DHCP: Op Code (op) = 2 (0x2)
DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
DHCP: Hardware Address Length (hlen) = 6 (0x6)
DHCP: Hops (hops) = 0 (0x0)
DHCP: Transaction ID (xid) = 1956644302 (0x74A005CE)
DHCP: Seconds (secs) = 0 (0x0)
DHCP: Flags (flags) = 0 (0x0)
DHCP: 0............... = No Broadcast
DHCP: Client IP Address (ciaddr) = [Link]
DHCP: Your IP Address (yiaddr) = [Link]
DHCP: Server IP Address (siaddr) = [Link]
DHCP: Relay IP Address (giaddr) = [Link]
DHCP: Client Ethernet Address (chaddr) = 08002B2ED85E
DHCP: Server Host Name (sname) = <Blank>
DHCP: Boot File Name (file) = <Blank>
DHCP: Magic Cookie = [OK]
DHCP: Option Field (options)
DHCP: DHCP Message Type = DHCP NACK
DHCP: Server Identifier = [Link]
DHCP: End of this option field

A continuación, el cliente iniciará el proceso de detección, pero el paquete

DHCPDISCOVER seguirá intentando concesionar la misma dirección. En muchos casos, el
cliente recibirá la misma dirección, pero puede que no.

IP: ID = 0x100; Proto = UDP; Len: 328

IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
IP: Service Type = 0 (0x0)
IP: Precedence = Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: Total Length = 328 (0x148)
 IP: Identification = 256 (0x100)
IP: Flags Summary = 0 (0x0)
IP: .......0 = Last fragment in datagram
IP: ......0. = May fragment datagram if necessary
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 128 (0x80)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x38A6
IP: Source Address = [Link]
IP: Destination Address = [Link]
IP: Data: Number of data bytes remaining = 308 (0x0134)

DHCP: Discover (xid=3ED14752)

DHCP: Op Code (op) = 1 (0x1)
DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
DHCP: Hardware Address Length (hlen) = 6 (0x6)
DHCP: Hops (hops) = 0 (0x0)
DHCP: Transaction ID (xid) = 1053902674 (0x3ED14752)
DHCP: Seconds (secs) = 0 (0x0)
DHCP: Flags (flags) = 0 (0x0)
DHCP: 0............... = No Broadcast
DHCP: Client IP Address (ciaddr) = [Link]
DHCP: Your IP Address (yiaddr) = [Link]
DHCP: Server IP Address (siaddr) = [Link]
DHCP: Relay IP Address (giaddr) = [Link]
DHCP: Client Ethernet Address (chaddr) = 08002B2ED85E
DHCP: Server Host Name (sname) = <Blank>
DHCP: Boot File Name (file) = <Blank>
DHCP: Magic Cookie = [OK]
DHCP: Option Field (options)
DHCP: DHCP Message Type = DHCP Discover
DHCP: Client-identifier = (Type: 1) 08 00 2b 2e d8 5e
DHCP: Requested Address = [Link]
DHCP: Host Name = JUMBO-WS
DHCP: Parameter Request List = (Length: 7) 01 0f 03 2c 2e 2f 06
DHCP: End of this option field

La información dhcp obtenida por el cliente de un servidor DHCP tendrá un tiempo de

concesión asociado. El tiempo de concesión define cuánto tiempo el cliente puede usar
la información asignada por DHCP. Cuando la concesión alcanza determinados hitos, el
cliente intentará renovar su información dhcp.

Para ver información de IP en un Windows o Windows cliente de Workgroups, use la

utilidad IPCONFIG. Si el cliente es Windows 95, use WINIPCFG.

Referencias
Para obtener más información sobre DHCP, vea RFC1541 y RFC2131. Las RFC se pueden
obtener a través de Internet en numerosos sitios, por ejemplo: [Link]
[Link]/ y [Link]
Instrucciones generales para la solución
de problemas de DHCP
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Antes de empezar a solucionar problemas, compruebe los siguientes elementos. Pueden

ayudarle a encontrar la causa principal del problema.

Lista de comprobación
¿Cuándo comenzó el problema?

¿Hay algún mensaje de error?

¿El servidor DHCP funcionaba anteriormente o nunca ha funcionado? Si

funcionaba anteriormente, hizo cualquier cambio antes de que se iniciara el
problema. Por ejemplo, ¿se instaló una actualización? ¿Se ha realizado un cambio
en la infraestructura?

¿El problema es persistente o intermitente? Si es intermitente, ¿cuándo se ha

hecho por última vez?

¿Se producen errores de concesión de direcciones para todos los clientes o solo
para clientes específicos, como una subred de ámbito único?

¿Hay algún cliente en la misma subred de red que el servidor DHCP?

Si los clientes residen en la misma subred de red, ¿pueden obtener direcciones IP?

Si los clientes no están en la misma subred de red, ¿los enrutadores o

conmutadores VLAN están configurados correctamente para tener agentes de
retransmisión DHCP (también conocidos como asistentes de IP)?

¿El servidor DHCP es independiente o está configurado para alta disponibilidad,

como el ámbito dividido o la conmutación por error DHCP?

Compruebe los dispositivos intermedios para conocer características como

VRRP/HSRP, inspección ARP dinámica o el dispositivo DHCP que se sabe que causa
problemas.
Uso del direccionamiento automático
de TCP/IP sin un servidor DHCP
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

En este artículo se describe cómo usar el direccionamiento automático del Protocolo de

control de transmisión/Protocolo de Internet (TCP/IP) sin que un servidor dhcp
(Protocolo de configuración dinámica de host) esté presente en la red. Las versiones de
sistema operativo enumeradas en la sección "Se aplica a" de este artículo tienen una
característica denominada Direccionamiento IP privado automático (APIPA). Con esta
característica, un equipo Windows puede asignarse a sí mismo una dirección ip
(Protocolo de Internet) en caso de que un servidor DHCP no esté disponible o no exista
en la red. Esta característica dificulta la configuración y compatibilidad de una red de
área local (LAN) pequeña que ejecuta TCP/IP.

Más información

） Importante

Sigue meticulosamente los pasos que se describen en esta sección. Pueden

producirse problemas graves si modifica el Registro de manera incorrecta. Antes de
modificarlo, haz una copia de seguridad del registro para restaurarlo , por si se
produjeran problemas.

Un Windows basado en dispositivos que esté configurado para usar DHCP puede
asignarse automáticamente una dirección de Protocolo de Internet (IP) si un servidor
DHCP no está disponible. Por ejemplo, esto podría ocurrir en una red sin un servidor
DHCP o en una red si un servidor DHCP está temporalmente fuera de servicio para el
mantenimiento.

Internet Assigned Numbers Authority (IANA) ha reservado [Link]-[Link]

para el direccionamiento IP privado automático. Como resultado, APIPA proporciona
una dirección que se garantiza que no entra en conflicto con las direcciones enrutables.

Después de asignar una dirección IP al adaptador de red, el equipo puede usar TCP/IP
para comunicarse con cualquier otro equipo que esté conectado a la misma LAN y que
también esté configurado para APIPA o tenga la dirección IP establecida manualmente
en el intervalo de direcciones 169.254.x.y (donde x.y es el identificador único del cliente)
con una máscara de subred de [Link]. Tenga en cuenta que el equipo no puede
comunicarse con equipos de otras subredes o con equipos que no usan
direccionamiento IP privado automático. El direccionamiento IP privado automático está
habilitado de forma predeterminada.

Puede deshabilitarla en cualquiera de los casos siguientes:

La red usa enrutadores.

La red está conectada a Internet sin un servidor NAT o proxy.

A menos que haya deshabilitado los mensajes relacionados con DHCP, los mensajes
DHCP le proporcionarán una notificación cuando cambie entre el direccionamiento
DHCP y el direccionamiento IP privado automático. Si la mensajería DHCP está
deshabilitada accidentalmente, puede volver a activar los mensajes DHCP cambiando el
valor del valor PopupFlag en la siguiente clave del Registro de 00 a 01:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP

Tenga en cuenta que debe reiniciar el equipo para que el cambio suba efecto. También
puede determinar si el equipo usa APIPA mediante la herramienta Winipcfg de Windows
Edition, Windows 98 o Windows 98 Second Edition:

Haga clic en Inicio, haga clic en Ejecutar , escriba "winipcfg" (sin comillas) y, a
continuación, haga clic en Aceptar. Haga clic en Más información. Si el cuadro Dirección
de configuración automática de IP contiene una dirección IP dentro del intervalo
169.254.x.x, el direccionamiento IP privado automático está habilitado. Si el cuadro
Dirección IP existe, el direccionamiento IP privado automático no está habilitado
actualmente. Para Windows 2000, Windows XP o Windows Server 2003, puede
determinar si el equipo usa APIPA mediante el comando IPconfig en un símbolo del
sistema:

Haga clic en Inicio , haga clic en Ejecutar , escriba "cmd" (sin comillas) y, a continuación,
haga clic en Aceptar para abrir una ventana de línea de comandos de MS-DOS. Escriba
"ipconfig /all" (sin comillas) y presione la tecla ENTRAR. Si la línea "Autoconfiguration
Enabled" indica "Yes" (Sí) y "Autoconfiguration IP Address" (Dirección IP de
configuración automática) es 169.254.x.y (donde x.y es el identificador único del cliente),
el equipo usa APIPA. Si la línea "Autoconfiguration Enabled" indica "No", el equipo no
usa actualmente APIPA. Puede deshabilitar el direccionamiento IP privado automático
mediante cualquiera de los métodos siguientes.

Puede configurar la información de TCP/IP manualmente, lo que deshabilita DHCP por

completo. Puede deshabilitar el direccionamiento IP privado automático (pero no DHCP)
editando el Registro. Para ello, agregue la entrada del Registro DWORD
"IPAutoconfigurationEnabled" con un valor de 0x0 a la siguiente clave del Registro para
Windows Edition, Windows98 o Windows 98 Second
Edition: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP

Para Windows 2000, Windows XP y Windows Server 2003, APIPA se puede deshabilitar
agregando la entrada del Registro DWORD "IPAutoconfigurationEnabled" con un valor
de 0x0 a la siguiente clave del
Registro: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Inte
rfaces\<Adapter GUID>

７ Nota

La subclave GUID del adaptador es un identificador único global (GUID) para el

adaptador LAN del equipo.

Si se especifica un valor de 1 para la entrada DWORD IPAutoconfigurationEnabled, se

habilitará APIPA, que es el estado predeterminado cuando se omite este valor del
Registro.

Ejemplos de where APIPA may be useful

Ejemplo 1: sin dirección IP anterior y sin servidor DHCP

Cuando el Windows basado en dispositivos (configurado para DHCP) se está
inicializando, difunde tres o más mensajes de "detección". Si un servidor DHCP no
responde después de difundir varios mensajes de detección, Windows equipo se asigna
a sí mismo una dirección de clase B (APIPA). A continuación, Windows equipo mostrará
un mensaje de error al usuario del equipo (siempre que nunca se le haya asignado una
dirección IP de un servidor DHCP en el pasado). El Windows equipo enviará un mensaje
de detección cada tres minutos en un intento de establecer comunicaciones con un
servidor DHCP.

Ejemplo 2: Dirección IP anterior y ningún servidor DHCP

El equipo busca el servidor DHCP y, si no se encuentra ninguno, se intenta ponerse en
contacto con la puerta de enlace predeterminada. Si la puerta de enlace predeterminada
responde, el equipo Windows conserva la dirección IP concesionada previamente. Sin
embargo, si el equipo no recibe una respuesta de la puerta de enlace predeterminada o
si no se asigna ninguno, usa la característica de direccionamiento IP privado automático
para asignarse a sí mismo una dirección IP. Se presenta un mensaje de error al usuario y
se detectan los mensajes que se transmiten cada 3 minutos. Una vez que un servidor
DHCP está en línea, se genera un mensaje que indica que se han vuelto a establecer las
comunicaciones con un servidor DHCP.

Ejemplo 3: La concesión expira y no hay ningún servidor

DHCP
El Windows basado en el servidor intenta restablecer la concesión de la dirección IP. Si
el Windows no encuentra un servidor DCHP, se asigna a sí mismo una dirección IP
después de generar un mensaje de error. A continuación, el equipo difunde cuatro
mensajes de detección y, después de cada 5 minutos, repite todo el procedimiento
hasta que un servidor DHCP se vuelve en línea. A continuación, se genera un mensaje
que indica que las comunicaciones se han establecido de nuevo con el servidor DHCP.
Solución de problemas en el cliente
DHCP
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Pruebe nuestro agente virtual : puede ayudarle a identificar y corregir rápidamente

los problemas comunes de DHCP.

En este artículo se describe cómo solucionar problemas que se producen en clientes

DHCP.

Lista de comprobación de solución de

problemas
Compruebe los siguientes dispositivos y configuraciones:

Los cables están conectados y funcionan.

El filtrado de MAC está habilitado en los conmutadores a los que está conectado el
cliente.

El adaptador de red está habilitado.

El controlador de adaptador de red correcto está instalado y actualizado.

El servicio Cliente DHCP se ha iniciado y está en ejecución. Para comprobarlo,

ejecute el comando net start y busque el cliente DHCP.

No hay ningún firewall que bloquee los puertos UDP 67 y 68 en el equipo cliente.

Registros de eventos
Examine los eventos de cliente Microsoft-Windows-DHCP/Operational y Microsoft-
Windows-DHCP Client Events/Administración registros de eventos. Todos los eventos
relacionados con el servicio de cliente DHCP se envían a estos registros de eventos. Los
eventos de cliente Microsoft-Windows-DHCP se encuentran en el Visor de eventos en
Registros de aplicaciones y servicios.

El comando de PowerShell "Get-NetAdapter -IncludeHidden" proporciona la

información necesaria para interpretar los eventos que aparecen en los registros. Por
ejemplo, id. de interfaz, dirección MAC, etc.
datos, recopilación
Se recomienda recopilar datos simultáneamente en el cliente DHCP y en el lado servidor
cuando se produzca el problema. Sin embargo, dependiendo del problema real,
también puede iniciar la investigación mediante un único conjunto de datos en el
cliente DHCP o en el servidor DHCP.

Para recopilar datos del servidor y del cliente afectado, use Wireshark . Comience a
recopilar al mismo tiempo en el cliente DHCP y en los equipos del servidor DHCP.

Ejecute los siguientes comandos en el cliente que experimenta el problema:

Consola

ipconfig /release
ipconfig /renew

A continuación, detenga Wireshark en el cliente y el servidor. Compruebe los

seguimientos generados. Estos deben, al menos, indicarle en qué fase se detiene la
comunicación.
Solución de problemas en el servidor
DHCP
Artículo • 21/12/2022 • Tiempo de lectura: 3 minutos

Pruebe nuestro agente virtual : puede ayudarle a identificar y corregir rápidamente

los problemas comunes de DHCP.

En este artículo se describe cómo solucionar problemas que se producen en el servidor

DHCP.

Lista de comprobación de solución de

problemas
Utilice la siguiente configuración:

El servicio Servidor DHCP se ha iniciado y está en ejecución. Para comprobarlo,

ejecute el comando net start y busque Servidor DHCP.

El servidor DHCP está autorizado. Consulte el artículo sobre la autorización del

servidor DHCP de Windows en un escenario de unión a un dominio.

Compruebe que las concesiones de direcciones IP están disponibles en el ámbito

del servidor DHCP para la subred en la que está el cliente DHCP. Para ello, consulte
la estadística del ámbito adecuado en la consola de administración del servidor
DHCP.

Compruebe si se pueden encontrar BAD_ADDRESS listados en Concesiones de

direcciones.

Compruebe si algún dispositivo de la red tiene direcciones IP estáticas que no se

han excluido del ámbito de DHCP.

Compruebe que el servidor DHCP está enlazado a al menos una dirección IP y que
se encuentra dentro de la subred de los ámbitos desde los que se deben conceder
las direcciones IP (a menos que se use la retransmisión DHCP). Para ello, ejecute el
cmdlet Get-DhcpServerv4Binding o Get-DhcpServerv6Binding . Los enlaces de
conexión de servidor se configuran en la consola de administración del servidor
DHCP en Propiedades avanzadas de IPv4/IPv6.

Compruebe que solo el servidor DHCP escucha en los puertos UDP 67 y 68.
Ningún otro proceso o servicio (como WDS o PXE) deben ocupar estos puertos.
 Para ello, ejecute el comando netstat -anb .

Compruebe que se agrega la exención IPsec del servidor DHCP si está tratando
con un entorno implementado por IPsec.

Compruebe que se puede hacer ping a la dirección IP del agente de retransmisión

desde el servidor DHCP.

Enumere y compruebe los filtros y directivas DHCP configurados.

Registros de eventos
Compruebe los registros de eventos del servicio del servidor DHCP y del sistema
(registros de aplicaciones y servicios de>Microsoft>Windows>DHCP-Server) para ver
los problemas notificados relacionados con el problema observado. Dependiendo del
tipo de problema, un evento se registra en uno de los siguientes canales de eventos:
Eventos operativos del servidor DHCP Eventos operativos del servidor DHCP Eventos del
sistema dhcp Eventos del sistema del servidor DHCP Eventos de notificación del servidor
DHCP Eventos de auditoría del servidor DHCP

datos, recopilación

Registro de Servidor DHCP

Los registros de depuración del servicio Servidor DHCP proporcionan más información
sobre la asignación de concesión de direcciones IP y las actualizaciones dinámicas de
DNS que realiza el servidor DHCP. Estos registros se encuentran de forma
predeterminada en %windir%\System32\Dhcp. Para más información, consulte el
artículo sobre el análisis de archivos de registro de Servidor DHCP.

Seguimiento de la red
Un seguimiento de red correlacionado puede indicar lo que hacía el servidor DHCP en el
momento en que se registró el evento. Para crear este seguimiento, siga estos pasos:

1. Vaya a GitHub y descargue el archivo tss_tools.zip.

2. Copie el archivo Tss_tools.zip y expándalo en una ubicación en el disco local, como

en la carpeta C:\tools.
3. Ejecute el siguiente comando desde C:\tools en una ventana del símbolo del
sistema con privilegios elevados:

Consola

TSS Ron Trace <Stop:Evt:>20321:<Other:>DhcpAdminEvents NoSDP NoPSR

NoProcmon NoGPresult

７ Nota

En este comando, reemplace <Stop:Evt:> y <Other:> por el identificador de

evento y el canal de eventos en el que se va a centrar en en la sesión de
seguimiento. Los archivos Tss.cmd_ReadMe_Help.docx contenidos en el
archivo Tss_tools.zip proporcionan más información sobre todas las
configuraciones disponibles.

4. Una vez desencadenado el evento, la herramienta crea una carpeta denominada

C:\MS_DATA. Esta carpeta contendrá algunos archivos de salida útiles que
proporcionan información general sobre la configuración de red y dominio del
equipo. El archivo más interesante de esta carpeta es
%Computername%_date_time_packetcapture_InternetClient_dbg.etl. Mediante la
aplicación Network Monitor , puede cargar el archivo y establecer el filtro de
visualización en el protocolo "DHCP o DNS" para examinar lo que sucede en
segundo plano.
Protocolo de autenticación extensible
(EAP) para el acceso a la red
Artículo • 21/12/2022 • Tiempo de lectura: 29 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012, Windows 10, Windows 8.1

El Protocolo de autenticación extensible (EAP) es un marco arquitectónico que

proporciona extensibilidad para los métodos de autenticación para las tecnologías de
acceso a redes protegidas más usadas, como el acceso inalámbrico basado en IEEE
802.1X, el acceso cableado basado en IEEE 802.1X y las conexiones Protocolo punto a
punto (PPP), como redes privadas virtuales (VPN). EAP no es un método de
autenticación como MS-CHAP v2, sino un marco en el cliente de acceso y en el servidor
de autenticación que permite a los proveedores de servicios de red desarrollar e instalar
fácilmente nuevos métodos de autenticación conocidos como métodos EAP.

Métodos de autenticación
Este tema contiene información de configuración específica de los siguientes métodos
de autenticación de EAP: Tenga en cuenta que los métodos de autenticación EAP que se
usan dentro de los métodos EAP tunelados se conocen normalmente como métodos
internos o tipos de EAP.

EAP protegido (PEAP)

Esta sección contiene información de configuración de los dos métodos EAP

internos predeterminados que se proporcionan con PEAP.

EAP-Seguridad de la capa de transporte (TLS)

Al aparecer como tarjeta inteligente u otras propiedades de certificado en el

sistema operativo, EAP-TLS se puede implementar como un método interno
para PEAP o como un método EAP independiente. Cuando se configura como
un método de autenticación interno, la configuración de seguridad para EAP-
TLS es idéntica a la configuración que se usa para implementar EAP-TLS como
un método externo, excepto que se configura para que funcione dentro de
PEAP. Para obtener detalles de configuración, consulte Tarjeta inteligente u
otros elementos de configuración de propiedades de certificado.
 EAP-Protocolo de autenticación por desafío mutuo de Microsoft versión 2 (MS-
CHAP v2)

La contraseña segura EAP-MS-CHAP v2 es un tipo de EAP que se puede usar

con PEAP para la autenticación de red basada en contraseña. EAP-MsCHAP v2
también se puede usar como método independiente para VPN, pero solo como
un método interno PEAP para dispositivos inalámbricos.

EAP-Seguridad de la capa de transporte en túnel (TTLS)

EAP-Módulo de identidad del suscriptor (SIM), EAP-Contrato de autenticación y

claves (AKA) y EAP-AKA prima (AKA')

Habilita la autenticación mediante tarjetas SIM y se implementa cuando un cliente

adquiere un plan de servicio de banda ancha inalámbrica de un operador de red
móvil. Como parte del plan, el cliente normalmente recibe un perfil para red
inalámbrica preconfigurado para la autenticación de SIM.

En este tema se proporciona información sobre lo siguiente:

Opciones de configuración de EAP-SIM
Opciones de configuración de EAP-AKA y EAP-AKA

EAP-TLS, PEAP y EAP-TTLS

Puede obtener acceso a las propiedades de EAP para acceso inalámbrico y cableado
autenticado 802.1X de las siguientes formas:

Mediante la configuración de las extensiones de directivas de redes cableadas

(IEEE 802.3) y directivas de redes inalámbricas (IEEE 802.11) en directiva de grupo.

Mediante la configuración manual de conexiones inalámbricas o cableadas en

equipos cliente.

Puede obtener acceso a las propiedades de EAP para conexiones de red privada virtual
(VPN) de las siguientes formas:

Mediante el Kit de administración de Connection Manager (CMAK) para configurar

conexiones VPN.

Mediante la configuración manual de conexiones VPN en equipos cliente.

De manera predeterminada, puede configurar las opciones de EAP de los siguientes

métodos de autenticación para acceso cableado autenticado 802.1X, acceso inalámbrico
autenticado 802.1X y VPN:
 Microsoft: tarjeta inteligente u otro certificado (EAP-TLS)
Microsoft: EAP protegido (PEAP)
Microsoft: EAP-TTLS

Además, el método de autenticación de red MS-CHAP-V2 está disponible para VPN de

manera predeterminada.

Opciones de configuración de propiedades de

EAP protegidas
En esta sección se enumeran los valores que se pueden configurar para EAP protegido.

） Importante

Si se implementa el mismo tipo de autenticación para PEAP y EAP, se crea una

vulnerabilidad de seguridad. Al implementar PEAP y EAP (sin proteger), no use el
mismo tipo de autenticación. Por ejemplo, si implementa PEAP-TLS, no implemente
también EAP-TLS.

Comprobación de la identidad del servidor mediante la

validación del certificado
Este elemento especifica que el cliente comprueba que los certificados de servidor
presentados al equipo cliente tienen las firmas correctas, no han expirado y las emitió
una entidad de certificación raíz (CA) de confianza. La configuración predeterminada es
"enabled". Si deshabilita esta casilla, los equipos cliente no podrán comprobar la
identidad de los servidores durante el proceso de autenticación. Si no se produce la
autenticación del servidor, los usuarios se exponen a riesgos de seguridad graves,
incluida la posibilidad de que los usuarios puedan conectarse sin saberlo a una red no
autorizado.

Conectar a estos servidores

Este elemento permite especificar el nombre de los servidores Servicio de autenticación
remota telefónica de usuario (RADIUS) que proporcionan autenticación y autorización
de red. Tenga en cuenta que debe escribir el nombre exactamente como aparece en el
campo Asunto de cada certificado de servidor RADIUS o usar expresiones regulares
para especificar el nombre del servidor. La sintaxis completa de la expresión regular se
puede usar para especificar el nombre del servidor, pero para diferenciar una expresión
regular con la cadena literal, debe usar al menos un "" en la cadena especificada. Por
ejemplo, puede especificar [Link] para especificar el servidor RADIUS
[Link] o [Link].

Incluso si no se especifica ningún servidor RADIUS, el cliente comprueba que el emisor

del certificado de servidor RADIUS sea una entidad de certificación raíz de confianza.

Valores predeterminados:

Cableado e inalámbrico = no habilitado

VPN = habilitado

Entidades de certificación raíz de confianza

En este elemento se enumeran las entidades de certificación raíz de confianza. La lista se
basa en las CA raíz de confianza que están instaladas en el equipo y en los almacenes de
certificados de usuario. Puede especificar los certificados de CA raíz de confianza que
usan los suplicantes para determinar si confían en los servidores como, por ejemplo, el
servidor que ejecuta el Servidor de directivas de redes (NPS) o el servidor de
aprovisionamiento. Si no se selecciona ninguna CA raíz de confianza, el cliente 802.1X
comprueba que el certificado de equipo del servidor RADIUS haya sido emitido por una
CA raíz de confianza instalada. Si se seleccionan una o varias CA raíz de confianza, el
cliente 802.1X comprueba que el certificado de equipo del servidor RADIUS haya sido
emitido por una CA raíz de confianza seleccionada. Incluso si no se selecciona ninguna
entidad de certificación raíz de confianza, el cliente comprueba que el emisor del
certificado de servidor RADIUS sea una CA raíz de confianza.

Si tiene una infraestructura de clave pública (PKI) en la red y usa la CA para emitir
certificados para los servidores RADIUS, se agregará automáticamente el certificado de
CA a la lista de entidades de certificación raíz de confianza.

También puede adquirir un certificado de CA de un proveedor distinto de Microsoft.

Algunas CA raíz de confianza que no son de Microsoft proporcionan software al adquirir
el certificado, el cual instala automáticamente el certificado adquirido en el almacén de
certificados de entidades de certificación raíz de confianza. En este caso, la CA raíz de
confianza aparece automáticamente en la lista de CA raíz de confianza.

７ Nota

No especifiques un certificado de CA raíz de confianza que no aparezca en la lista

de los almacenes de certificados de entidades de certificación raíz de confianza
del equipo cliente para el Usuario actual y el Equipo local. Si designa un certificado
 que no esté instalado en los equipos cliente, se producirá un error de
autenticación.

Valor predeterminado = no habilitado, sin CA raíz de confianza seleccionadas

Notificaciones antes de conectar

Este elemento especifica si se notifica al usuario si no se especifica el nombre del
servidor o el certificado raíz, o si no se puede comprobar la identidad del servidor.

De forma predeterminada, se proporcionan las siguientes opciones:

Caso 1: No pedir al usuario que autorice nuevos servidores o entidades de

certificación raíz de confianza especifica que si:
El nombre de servidor no aparece en la lista Conectarse a estos servidores
o el certificado raíz se encuentra, pero no está seleccionado en la lista de
entidades de certificación raíz de confianza en Propiedades PEAP
o el certificado raíz no se encuentra en el equipo

no se notifica al usuario y se produce un error en el intento de conexión.

Caso 2: Informar al usuario si no se especificó el nombre del servidor o el

certificado raíz especifica que si:
El nombre de servidor no aparece en la lista Conectarse a estos servidores
o el certificado raíz se encuentra, pero no está seleccionado en la lista de
entidades de certificación raíz de confianza en Propiedades PEAP

a continuación, se le pregunta al usuario si debe aceptar el certificado raíz. Si el

usuario acepta el certificado, la autenticación continúa. Si el usuario rechaza el
certificado, se produce un error en el intento de conexión. En esta opción, si el
certificado raíz no está presente en el equipo, no se notifica al usuario y se
produce un error en los intentos de conexión.

Caso 3: Indica al usuario si no se puede comprobar la identidad del servidor

especifica que si:
El nombre de servidor no aparece en la lista Conectarse a estos servidores
o el certificado raíz se encuentra, pero no está seleccionado en la lista de
entidades de certificación raíz de confianza en Propiedades PEAP
o el certificado raíz no se encuentra en el equipo

a continuación, se le pregunta al usuario si debe aceptar el certificado raíz. Si el

usuario acepta el certificado, la autenticación continúa. Si el usuario rechaza el
certificado, se produce un error en el intento de conexión.
Selección del método de autenticación
Este elemento permite seleccionar el tipo de EAP que se va a usar con PEAP para la
autenticación de red. De forma predeterminada, hay dos tipos de EAP disponibles:
Contraseña segura (EAP-MSCHAP v2) y Tarjeta inteligente u otro certificado (EAP-TLS).
No obstante, EAP es un protocolo flexible que permite la inclusión de métodos EAP
adicionales y no está restringido a estos dos tipos.

Para más información, consulte:

Elementos de configuración de las propiedades de contraseña segura (EAP-

MSCHAP v2)

Tarjeta inteligente u otros elementos de configuración de propiedades de

certificado

Valor predeterminado = Contraseña segura (EAP-MSCHAP v2)

Configuración
Este elemento proporciona acceso a la configuración de propiedades para el tipo de
EAP especificado.

Habilitación de la reconexión rápida

Permite crear una asociación de seguridad nueva o actualizada de forma más eficaz o en
un número menor de recorridos de ida y vuelta, en el caso de que se estableciera
previamente una asociación de seguridad.

Para las conexiones VPN, la reconexión rápida usa la tecnología IKEv2 para ofrecer una
conectividad perfecta y coherente de la VPN cuando los usuarios pierden
temporalmente sus conexiones a Internet. Los usuarios que se conecten mediante
banda ancha móvil inalámbrica serán los que más se beneficien de esta funcionalidad.

Un ejemplo de esta ventaja es un escenario común en el que un usuario viaja en tren,

usa una tarjeta de banda ancha móvil inalámbrica para conectarse a Internet y, a
continuación, establece una conexión VPN con la red corporativa.

Cuando el tren pasa por un túnel, se pierde la conexión a Internet. Una vez que el tren
está fuera del túnel, la tarjeta de banda ancha móvil inalámbrica vuelve a conectarse
automáticamente a Internet.
La reconexión rápida vuelve a establecer automáticamente las conexiones VPN activas
cuando se vuelve a establecer la conectividad a Internet. Aunque la reconexión pueda
tardar algunos segundos, se realiza de manera transparente para los usuarios.

Valor predeterminado = habilitado

Aplicación de la protección de acceso a la red

Este elemento especifica que antes de permitir las conexiones a una red, las
comprobaciones de estado del sistema se realizan en los suplicadores eap para
determinar si cumplen los requisitos de mantenimiento del sistema.

Valor predeterminado = no habilitado

Desconectar si el servidor no presenta TLV de

cryptobinding
Este elemento especifica que los clientes que se conectan deben finalizar el proceso de
autenticación de red si el servidor RADIUS no presenta cryptobinding Type-Length-
Value (TLV). TLV de cryptobinding aumenta la seguridad del túnel TSL en PEAP mediante
la combinación de las autenticaciones de método interno y externo, de forma que los
atacantes no puedan realizar ataques de tipo "Man in the middle" al redirigir una
autenticación MS-CHAP v2 con el canal PEAP.

Valor predeterminado = no habilitado

Habilitar la privacidad de la identidad (Windows 8 solo)

Especifica que se configuren los clientes para que no puedan enviar su identidad antes
de que el cliente haya autenticado el servidor RADIUS y, de manera opcional,
proporciona un espacio para escribir un valor de identidad anónima. Por ejemplo, si
selecciona Habilitar privacidad de identidad y, a continuación, escribe "invitado" como
valor de identidad anónima, la respuesta de identidad de un usuario con identidad
alice@example se guest@example. Si selecciona Habilitar privacidad de identidad pero
no proporciona un valor de identidad anónimo, la respuesta de identidad del usuario
alice@example es .

Esta configuración solo se aplica a los equipos que ejecutan Windows 8 y versiones
anteriores.

Valor predeterminado = no habilitado

Proteger los elementos de configuración de las
propiedades de contraseña
Al comprobar Usar automáticamente mi nombre de inicio de sesión de Windows y la
contraseña (y el dominio si existen) se especifica que el nombre de inicio de sesión y la
contraseña Windows basados en el usuario actual se usan como credenciales de
autenticación de red.

Valores predeterminados:

Cableado e inalámbrico = habilitado

VPN = no habilitado

Tarjeta inteligente u otros elementos de

configuración de propiedades de certificado
En esta sección se enumeran los elementos que se pueden configurar para EAP-TLS.

Usar mi tarjeta inteligente

Este elemento especifica que los clientes que hacen solicitudes de autenticación deben
presentar un certificado de tarjeta inteligente para la autenticación de red.

Valores predeterminados:

Cableado e inalámbrico = no habilitado

VPN = habilitado

Usar un certificado en este equipo

Este elemento especifica que los clientes de autenticación deben usar un certificado
ubicado en los almacenes de certificados Usuario actual o Equipo local.

Valores predeterminados:

Cableado e inalámbrico = habilitado

VPN = no habilitado

Uso de la selección de certificados simple (recomendado)

Este elemento especifica si Windows los certificados que no es probable que cumplan
los requisitos de autenticación. Esto sirve para limitar la lista de certificados disponibles
al pedirle al usuario que se seleccione un certificado.

Valores predeterminados:

Cableado e inalámbrico = habilitado

VPN = no habilitado

Avanzado
Este elemento abre el cuadro de diálogo Configurar selección de certificado . Para
obtener más información sobre cómo configurar la selección de certificados, vea
Configurar nuevos elementos de configuración de selección de certificado.

Verificar la identidad del servidor validando el certificado

Este elemento especifica que el cliente comprueba que los certificados de servidor
presentados al equipo cliente tienen las firmas correctas, no han expirado y las emitió
una entidad de certificación raíz (CA) de confianza. No desactive esta casilla; de lo
contrario, los equipos cliente no comprueban la identidad de los servidores durante
el proceso de autenticación. Si no se lleva a cabo la autenticación del servidor, los
usuarios están expuestos a riesgos graves de seguridad, incluida la posibilidad de que
los usuarios se conecten sin saberlo a una red no autorizada.

Valor predeterminado = habilitado

Conectar a estos servidores

Este elemento permite especificar el nombre de los servidores RADIUS que
proporcionan autenticación y autorización de red. Tenga en cuenta que debe escribir el
nombre exactamente como aparece en el campo Asunto de cada certificado de servidor
RADIUS o usar expresiones regulares para especificar el nombre del servidor. La sintaxis
completa de la expresión regular se puede usar para especificar el nombre del servidor,
pero para diferenciar una expresión regular con la cadena literal, debe usar al menos un
"" en la cadena especificada. Por ejemplo, puede especificar [Link] para
especificar el servidor RADIUS [Link] o [Link].

Incluso si no se especifica ningún servidor RADIUS, el cliente comprueba que el emisor

del certificado de servidor RADIUS sea una entidad de certificación raíz de confianza.

Valores predeterminados:
 Cableado e inalámbrico = no habilitado
VPN = habilitado

Entidades de certificación raíz de confianza

En este elemento se enumeran las entidades de certificación raíz de confianza. La lista
se basa en las CA raíz de confianza que están instaladas en los almacenes de certificados
de usuario y equipo. Puede especificar los certificados de entidades de certificación raíz
de confianza que usan los suplicantes para determinar si confían en los servidores
como, por ejemplo, el servidor que ejecuta NPS o el servidor de aprovisionamiento. Si
no se selecciona ninguna CA raíz de confianza, el cliente 802.1X comprueba que el
certificado de equipo del servidor RADIUS haya sido emitido por una CA raíz de
confianza instalada. Si se seleccionan una o varias CA raíz de confianza, el cliente 802.1X
comprueba que el certificado de equipo del servidor RADIUS haya sido emitido por una
CA raíz de confianza seleccionada.

Si tiene una infraestructura de clave pública (PKI) en la red y usa la CA para emitir
certificados para los servidores RADIUS, se agregará automáticamente el certificado de
CA a la lista de entidades de certificación raíz de confianza.

También puede adquirir un certificado de CA de un proveedor distinto de Microsoft.

Algunas CA raíz de confianza que no son de Microsoft proporcionan software al adquirir
el certificado, el cual instala automáticamente el certificado adquirido en el almacén de
certificados de entidades de certificación raíz de confianza. En este caso, la CA raíz de
confianza aparece automáticamente en la lista de CA raíz de confianza. Incluso si no se
selecciona ninguna entidad de certificación raíz de confianza, el cliente comprueba que
el emisor del certificado de servidor RADIUS sea una CA raíz de confianza.

No especifiques un certificado de CA raíz de confianza que no aparezca en la lista de los

almacenes de certificados de entidades de certificación raíz de confianza del equipo
cliente para el Usuario actual y el Equipo local.

７ Nota

Si designa un certificado que no esté instalado en los equipos cliente, se producirá

un error de autenticación.

Valor predeterminado = no habilitado, ninguna entidad de certificación raíz de

confianza seleccionada

Ver certificado
Este elemento permite ver las propiedades del certificado seleccionado.

No pedir la intervención del usuario para autorizar

nuevos servidores o entidades de certificación de
confianza
Este elemento impide que se pida al usuario que confíe en un certificado de servidor si
ese certificado está configurado incorrectamente, no es de confianza o ambos (si está
habilitado). Se recomienda activar esta casilla para simplificar la experiencia del usuario
y para impedir que los usuarios seleccionen por error que confían en un servidor
implementado por un atacante.

Valor predeterminado = no habilitado

Usar un nombre de usuario distinto para la conexión

Este elemento especifica si se debe usar un nombre de usuario para la autenticación
que sea diferente del nombre de usuario del certificado.

Valor predeterminado = no habilitado

Elementos de configuración para configurar

Selección de certificado nuevo
Usa Selección de certificado nuevo para configurar los criterios que usan los equipos
cliente para seleccionar automáticamente el certificado correcto en el equipo cliente
para fines de autenticación. Al proporcionar la configuración a los equipos cliente de la
red a través de las directivas de redes cableadas (IEEE 802.3), las directivas de redes
inalámbricas (IEEE 802.11) o el Kit de administración de Connection Manager (CMAK)
para VPN, se aprovisiona automáticamente a los clientes con los criterios de
autenticación especificados.

En esta sección se enumeran los elementos de configuración de Nueva selección de

certificado, junto con una descripción de cada uno.

Emisor de certificados
Este elemento especifica si el filtrado del emisor de certificados está habilitado.

Valor predeterminado = no seleccionado

Lista Emisor de certificado
Se usa para especificar uno o varios emisores de certificado para los certificados.

Enumera los nombres de todos los emisores para los cuales están presentes los
certificados de entidad de certificación (CA) correspondientes en el almacén de
certificados de entidades de certificación raíz de confianza o entidades de
certificación intermedias de la cuenta del equipo local.

Incluye todas las entidades de certificación raíz y entidades de certificación

intermedias.

Contiene solo los emisores para los cuales existen certificados válidos
correspondientes en el equipo (por ejemplo, los certificados que no expiraron ni
fueron revocados).

La lista final de certificados habilitados para la autenticación contiene solo aquellos

certificados emitidos por alguno de los emisores seleccionados en esta lista.

Valor predeterminado = ninguno seleccionado

Uso mejorado de clave (EKU)

Puede seleccionar Todos los propósitos, Autenticación de cliente, Cualquier propósito
o cualquier combinación de estos. Especifica que cuando se selecciona una
combinación, todos los certificados que cumplen con al menos una de las tres
condiciones se consideran válidos para el fin de autenticar el cliente en el servidor. Si se
habilita el filtrado de EKU, se debe seleccionar una de estas opciones; de lo contrario, el
control de comando Aceptar estará deshabilitado.

Valor predeterminado = no habilitado

Todos los propósitos

Cuando se selecciona, este elemento especifica que los certificados que tienen el EKU
Todos los propósitos se consideran certificados válidos con el fin de autenticar el cliente
en el servidor.

Valor predeterminado = seleccionado cuando se selecciona Uso extendido de clave

(EKU)

Autenticación de clientes
Cuando se selecciona, este elemento especifica que los certificados que tienen el EKU
de autenticación de cliente y la lista especificada de EKU se consideran certificados
válidos para autenticar el cliente en el servidor.

Valor predeterminado = seleccionado cuando se selecciona Uso extendido de clave

(EKU)

Cualquier propósito
Cuando se selecciona, este elemento especifica que todos los certificados que tienen un
EKU de cualquier propósito y la lista especificada de EKU se consideran certificados
válidos para autenticar el cliente en el servidor.

Valor predeterminado = seleccionado cuando se selecciona Uso extendido de clave

(EKU)

Sumar
Este elemento abre el cuadro de diálogo Seleccionar EKUs, que le permite agregar EKUs
estándar, personalizadas o específicas del proveedor a la lista Autenticación de cliente o
Cualquier propósito.

Valor predeterminado = no aparecen EKU

Remove
Este elemento quita el EKU seleccionado de la lista Autenticación de cliente o Cualquier
propósito.

Valor predeterminado = N/D

７ Nota

Si Emisor de certificado y Uso mejorado de clave (EKU) están habilitados, solo

aquellos certificados que cumplen con las dos condiciones se consideran válidos
para el fin de autenticar el cliente con el servidor.

Seleccionar EKU
Puede seleccionar un EKU de la lista proporcionada o agregar un nuevo EKU.
 Elemento Detalles

Add Abre el cuadro de diálogo Agregar o editar EKU , que permite definir y agregar EKUs
(Agregar) personalizadas. En Seleccione los EKU de la lista siguiente, selecciona un EKU de la
lista y, a continuación, haz clic en Aceptar para agregar EKU a la lista Autenticación
del cliente o Cualquier propósito.

Edición Abre el cuadro de diálogo Agregar o editar EKU y le permite editar las EKU
personalizadas que ha agregado. No se pueden editar los EKU predeterminados
predefinidos.

Remove Quita el EKU personalizado seleccionado de la lista de EKU en el cuadro de diálogo

Seleccionar EKUs . No se pueden quitar los EKU predeterminados predefinidos.

Agregar o editar EKU

Elemento Detalles

Escriba el Proporciona un lugar para escribir el nombre del EKU personalizado.

nombre
del EKU

Escriba el Proporciona un lugar para escribir el OID del EKU. Solo se permiten dígitos
OID de numéricos, separadores y “.”. Se permiten los caracteres comodín, en cuyo caso se
EKU. permiten también todos los OID de los elementos secundarios de la jerarquía. Por
ejemplo, si se escribe [Link].4.1.311.*, se permiten [Link].[Link] y
[Link].[Link].2.1

Elementos de configuración de TTLS

EAP-TTLS es un método de túnel EAP basado en estándares que admite la autenticación
mutua y proporciona un túnel seguro para la autenticación de la inclusión de clientes
mediante métodos EAP y otros protocolos heredados. La adición de EAP-TTLS en
Windows Server 2012 solo proporciona compatibilidad del lado cliente, con el fin de
admitir la interoperación con los servidores RADIUS implementados más comúnmente
que admiten EAP-TTLS.

En esta sección se enumeran los elementos que se pueden configurar para EAP-TTLS.

Habilitar la privacidad de la identidad (Windows 8 solo)

Este elemento especifica que los clientes están configurados para que no puedan enviar
su identidad antes de que el cliente haya autenticado el servidor RADIUS y,
opcionalmente, proporciona un lugar para escribir un valor de identidad anónimo. Por
ejemplo, si selecciona Habilitar privacidad de identidad y, a continuación, escribe
"invitado" como valor de identidad anónima, la respuesta de identidad de un usuario
con identidad alice@example se guest@example. Si selecciona Habilitar privacidad de
identidad pero no proporciona un valor de identidad anónimo, la respuesta de
identidad del usuario alice@example es .

Esta configuración solo se aplica a los equipos que ejecutan Windows 8.

Valor predeterminado = no habilitado

Conectar a estos servidores

Este elemento permite especificar el nombre de los servidores RADIUS que
proporcionan autenticación y autorización de red. Tenga en cuenta que debe escribir el
nombre exactamente como aparece en el campo Asunto de cada certificado de servidor
RADIUS o usar expresiones regulares para especificar el nombre del servidor. La sintaxis
completa de la expresión regular puede usarse para especificar el nombre de servidor.
Pero para diferenciar una expresión regular con la cadena literal, debe usar al menos un
* en la cadena especificada. Por ejemplo, puedes especificar nps*.[Link] para
especificar el servidor RADIUS [Link] o [Link]. Incluso si no se
especifica ningún servidor RADIUS, el cliente comprueba que el emisor del certificado
de servidor RADIUS sea una entidad de certificación raíz de confianza.

Valor predeterminado = ninguno

Entidades de certificación raíz de confianza

En este elemento se enumeran las entidades de certificación raíz de confianza. La lista
se basa en las CA raíz de confianza que están instaladas en los almacenes de certificados
de usuario y equipo. Puede especificar los certificados de entidades de certificación raíz
de confianza que usan los suplicantes para determinar si confían en los servidores
como, por ejemplo, el servidor que ejecuta NPS o el servidor de aprovisionamiento. Si
no se selecciona ninguna CA raíz de confianza, el cliente 802.1X comprueba que el
certificado de equipo del servidor RADIUS haya sido emitido por una CA raíz de
confianza instalada. Si se seleccionan una o varias CA raíz de confianza, el cliente 802.1X
comprueba que el certificado de equipo del servidor RADIUS haya sido emitido por una
CA raíz de confianza seleccionada. Incluso si no se selecciona ninguna entidad de
certificación raíz de confianza, el cliente comprueba que el emisor del certificado de
servidor RADIUS sea una CA raíz de confianza.

Si tiene una infraestructura de clave pública (PKI) en la red y usa la CA para emitir
certificados para los servidores RADIUS, se agregará automáticamente el certificado de
CA a la lista de entidades de certificación raíz de confianza. Si se selecciona, el
certificado de CA raíz se instala en el equipo cliente cuando los equipos se unen al
dominio.

También puede adquirir un certificado de CA de un proveedor distinto de Microsoft.

Algunas CA raíz de confianza que no son de Microsoft proporcionan software al adquirir
el certificado, el cual instala automáticamente el certificado adquirido en el almacén de
certificados de entidades de certificación raíz de confianza. En este caso, la CA raíz de
confianza aparece automáticamente en la lista de CA raíz de confianza.

No especifiques un certificado de CA raíz de confianza que no aparezca en la lista de los

almacenes de certificados de entidades de certificación raíz de confianza del equipo
cliente para el Usuario actual y el Equipo local.

７ Nota

Si designa un certificado que no esté instalado en los equipos cliente, se producirá

un error de autenticación.

Valor predeterminado = no habilitado, sin CA raíz de confianza seleccionadas

No avisar al usuario si no se puede autorizar el servidor

Este elemento especifica (cuando no se selecciona) que si se produce un error en la
validación del certificado de servidor debido a cualquiera de los siguientes motivos, se
pide al usuario que acepte o rechace el servidor:

Un certificado raíz para el certificado de servidor no se encuentra o no se

selecciona en la lista de entidades de certificación raíz de confianza.
No se encuentra uno o varios de los certificados raíz intermedios de la cadena de
certificados.
El nombre de sujeto del certificado de servidor no coincide con ninguno de los
servidores que se especifican en la lista Conectarse a estos servidores.

Valor predeterminado = no seleccionado

Seleccione un método que no sea EAP para la

autenticación
Especifica si un método que no es EAP o un tipo de EAP se usa para la autenticación. Si
selecciona Seleccionar un método que no es EAP para la autenticación , seleccionar
un método EAP para la autenticación está deshabilitado. Si se selecciona Seleccione un
método que no sea EAP para la autenticación, se proporcionan los siguientes tipos de
autenticación que no sean EAP en la lista desplegable:

PAP
CHAP
MS-CHAP
MS-CHAP v2

Valores predeterminados:

Seleccione un método que no sea EAP para la autenticación = habilitado

Tipo que no sea de EAP = PAP

Usar automáticamente mi nombre de inicio y contraseña

de Windows
Cuando se habilita, este elemento usa Windows credenciales de inicio de sesión. Esta
casilla solo se activa si se selecciona MS-CHAP v2 en la lista desplegable Seleccione un
método que no sea EAP para la autenticación. Use automáticamente mi nombre
Windows inicio de sesión y la contraseña esté deshabilitada para los tipos de
autenticación PAP, CHAPy MS-CHAP.

Seleccione un método EAP para la autenticación

Este elemento especifica si se usa un tipo de EAP o un tipo que no es EAP para la
autenticación. Si selecciona Seleccionar un método EAP para la autenticación , se
deshabilita Seleccionar un método que no sea EAP para la autenticación. Si se
selecciona Seleccione un método que no sea EAP para la autenticación, se
proporcionan los siguientes tipos de autenticación que no sean EAP en la lista
desplegable de manera predeterminada:

Microsoft: tarjeta inteligente u otro certificado

Microsoft: MS-CHAP v2

MS-CHAP

MS-CHAP v2

７ Nota
 La lista desplegable Select an EAP method for authentication (Seleccionar un
método EAP para la autenticación) enumerará todos los métodos eap
instalados en el servidor, excepto peapy FAST tunnel. Los tipos de EAP se
enumeran en el orden en que el equipo los detecta.

Configuración
Abre el cuadro de diálogo de propiedades del tipo de EAP especificado. Para más
información sobre los tipos de EAP predeterminados, consulte Tarjeta inteligente u otros
elementos de configuración de propiedades de certificado o Elementos de
configuración de propiedades de contraseña segura (EAP-MSCHAP v2).

Opciones de configuración de EAP-SIM

EAP Módulo de identidad del suscriptor (SIM) se usa para la autenticación y distribución
de claves de sesión del Sistema global para comunicaciones móviles (GSM). EAP-SIM se
define en RFC 4186.

En la tabla siguiente se enumeran las opciones de configuración de EAP-SIM.

Elemento Descripción

Usar claves de Especifica que si se selecciona, el perfil usa un cifrado de alta seguridad.
cifrado seguras

No revelar la Si se habilita, fuerza al cliente para que genere un error en la autenticación si

identidad real las solicitudes del servidor de una identidad permanente a través del cliente
al servidor tienen una identidad de seudónimo con ellas. Las identidades de seudónimo se
cuando hay usan para dar privacidad a la identidad, de modo que la identidad real o
disponible una permanente de un usuario no se revele durante la autenticación.
de seudónimo

Habilitar el uso Proporciona un lugar para escribir el nombre de dominio kerberos. Si este
de dominios campo se deja en blanco con habilitar el uso de dominios seleccionados, el
kerberos dominio se deriva de la identidad internacional del suscriptor móvil (IMSI)
mediante el dominio kerberos [Link], tal y como se describe en el estándar
23.003 V6.8.0 de asociación de tercera generación Project (3GPP).

Especificar un Proporciona un lugar para escribir el nombre de dominio.

dominio
kerberos

Opciones de configuración de EAP-AKA

EAP Contrato de autenticación y claves (AKA) del Sistema universal de
telecomunicaciones móviles (UMTS) se usa para la autenticación y la distribución de
claves de sesión mediante el Módulo de identidad de suscriptor universal (USIM) de
UMTS. EAP AKA se define en RFC 4187.

En la tabla siguiente se enumeran las opciones de configuración de EAP-AKA.

Elemento Descripción

No revelar la Si se habilita, fuerza al cliente para que genere un error en la autenticación si

identidad real las solicitudes del servidor de una identidad permanente a través del cliente
al servidor tienen una identidad de seudónimo con ellas. Las identidades de seudónimo se
cuando hay usan para dar privacidad a la identidad, de modo que la identidad real o
disponible una permanente de un usuario no se revele durante la autenticación.
de seudónimo

Habilitar el uso Proporciona un lugar para escribir el nombre de dominio kerberos. Si este
de dominios campo se deja en blanco con habilitar el uso de dominios seleccionados, el
kerberos dominio se deriva de la identidad internacional del suscriptor móvil (IMSI)
mediante el dominio kerberos [Link], tal y como se describe en el estándar
23.003 V6.8.0 de asociación de tercera generación Project (3GPP).

Especificar un Proporciona un lugar para escribir el nombre de dominio kerberos.

dominio
kerberos

Opciones de configuración de EAP-AKA

EAP-AKA prima (AKA') es una versión modificada de EAP-AKA que se usa para habilitar
el acceso a las redes basadas en el Proyecto de asociación de tercera generación (3GPP)
mediante estándares que no sean de 3GPP, como:

WiFi (también conocido como wireless fidelity)

datos de evolución optimizados (EVDO)

Interoperabilidad mundial para acceso por microondas (WiMax)

EAP-AKA' se define en RFC 5448.

En la tabla siguiente se enumeran las opciones de configuración de EAP-AKA.

Elemento Descripción
 Elemento Descripción

No revelar la Si se habilita, fuerza al cliente para que genere un error en la autenticación si

identidad real las solicitudes del servidor de una identidad permanente a través del cliente
al servidor tienen una identidad de seudónimo con ellas. Las identidades de seudónimo se
cuando hay usan para dar privacidad a la identidad, de modo que la identidad real o
disponible una permanente de un usuario no se revele durante la autenticación.
de seudónimo

Habilitar el uso Proporciona un lugar para escribir el nombre de dominio kerberos. Si este
de dominios campo se deja en blanco con habilitar el uso de dominios seleccionados, el
kerberos dominio se deriva de la identidad internacional del suscriptor móvil (IMSI)
mediante el dominio kerberos [Link], tal y como se describe en el estándar
23.003 V6.8.0 de asociación de tercera generación Project (3GPP).

Especificar un Proporciona un lugar para escribir el nombre de dominio kerberos.

dominio
kerberos

Pasar por alto El cliente compara el nombre de red que conoce, con el nombre que envió el
error de servidor RADIUS durante la autenticación. Si no hay coincidencia, se omite si
coincidencia esta opción está seleccionada. Si no se selecciona, se produce un error en la
de nombres de autenticación.
red

Habilitar la Especifica que la reautenticación rápida está habilitada. La reautenticación

reautenticación rápida es útil cuando la autenticación de SIM se lleva a cabo con frecuencia. Las
rápida claves de cifrado que derivan de la autenticación completa se reutilizan. Como
resultado, no se requiere que el algoritmo de SIM se ejecute en cada uno de los
intentos de autenticación y el número de operaciones de red que derivan de
los intentos de autenticación frecuentes se reduce.

Recursos adicionales
Para obtener más información sobre la configuración inalámbrica autenticada en
directiva de grupo, consulte Administración de las directivas de redes inalámbricas
nuevas (IEEE 802.11) Configuración

Para obtener más información sobre la configuración cableada autenticada en directiva

de grupo, consulte Administración de las nuevas directivas de red cableada (IEEE 802.3)
Configuración

Para obtener información sobre la configuración avanzada para el acceso cableado

autenticado y el acceso inalámbrico autenticado, consulte Advanced Security
Configuración for Wired and Wireless Network Policies (Directivas de red cableadas e
inalámbricas).
Redes de alto rendimiento (HPN)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Azure Stack HCI, versiones
21H2 y 20H2

Las redes de alto rendimiento (HPN) desempeñan un papel en los requisitos de

procesamiento de datos en tiempo real. Por ejemplo, actividades como la replicación del
centro de datos, la recuperación ante desastres del centro de datos y la informática
distribuida de alto rendimiento requieren una transferencia de datos de gran volumen y
una latencia de red baja. Las HPN con funcionalidades de conexión dinámica hacen que
los recursos de red de alto rendimiento sea más accesibles y fáciles de administrar. Para
más información, consulte Requisitos de red de host para Azure Stack HCI.

Los temas de redes de alto rendimiento incluyen:

Descarga de la red y tecnologías de optimización

Funciones y tecnologías de solo software

Funciones y tecnologías integradas de software y hardware (SH)

Tecnologías y características de solo hardware

Propiedades avanzadas de NIC

RSC en vSwitch
Descarga de la red y tecnologías de
optimización
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Azure Stack HCI, versiones
21H2 y 20H2

En este tema, se proporciona información general sobre las distintas características de

descarga y optimización de red disponibles en Windows Server 2016 y se explica cómo
ayudan a mejorar la eficacia de las redes. Estas tecnologías incluyen características y
tecnologías de solo software (SO), características y tecnologías integradas de software y
hardware (SH) y características y tecnologías solo de hardware (HO). Para más
información, consulte Requisitos de red de host para Azure Stack HCI.

Las tres categorías de características de red disponibles en Windows Server 2016 son:

1. Características y tecnologías de solo software (SO): estas características se

implementan como parte del sistema operativo y son independientes de las NIC
subyacentes. En ocasiones, estas características requerirán cierto ajuste de la NIC
para un funcionamiento óptimo. Algunos ejemplos son las características de
Hyper-V, como vmQoS, ACL y características que no son de Hyper-V, como la
formación de equipos NIC.

2. Características y tecnologías integradas de software y hardware (SH): estas

características tienen componentes de software y hardware. El software está
estrechamente vinculado a las funcionalidades de hardware necesarias para que la
característica funcione. Algunos ejemplos son VMMQ, VMQ, descarga de suma de
comprobación IPv4 del lado de envío y RSS.

3. Características y tecnologías de solo hardware (HO): estas aceleraciones de

hardware mejoran el rendimiento de las redes junto con el software, pero no
forman parte de ninguna característica de software. Algunos ejemplos de estos son
Interrupt Moderation, Flow Control y Receive-side IPv4 Checksum Offload.

4. Propiedades avanzadas de NIC: puede administrar nic y todas las características a

través de Windows PowerShell mediante el cmdlet NetAdapter. También puede
administrar nic y todas las características mediante Network Panel de control
([Link]).

 Sugerencia
Las características y tecnologías de SO están disponibles en todas las
arquitecturas de hardware, independientemente de la velocidad de NIC o las
funcionalidades de NIC.

Las características SH y HO solo están disponibles cuando el adaptador de red

admite las características o tecnologías.
Funciones y tecnologías de solo
software
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Azure Stack HCI, versiones
21H2 y 20H2

Las características de solo software se implementan como parte del sistema operativo y
son independientes de las NIC subyacentes. A veces, estas características requieren
cierto ajuste de la NIC para un funcionamiento óptimo. Algunos ejemplos de estas son
características de Hyper-V, como la calidad de servicio de la máquina virtual (vmQoS),
las listas de Access Control (ACL) y las características que no son de Hyper-V, como la
formación de equipos NIC. Para más información, consulte Requisitos de red de host
para Azure Stack HCI.

Listas de control de acceso (ACL)

Una característica de Hyper-V y SDNv1 para administrar la seguridad de una máquina
virtual. Esta característica se aplica a la pila de Hyper-V no virtualizada y a la pila HVNv1.
Puede administrar las ACL de conmutador de Hyper-V mediante los cmdlets de
PowerShell Add-VMNetworkAdapterAcl y Remove-VMNetworkAdapterAcl .

ACL extendidas
Las ACL extendidas del conmutador virtual de Hyper-V permiten configurar las ACL de
puerto extendido del conmutador virtual de Hyper-V para proporcionar protección del
firewall y aplicar directivas de seguridad para las máquinas virtuales de inquilino en los
centros de datos. Dado que las ACL de puerto están configuradas en el conmutador
virtual de Hyper-V en lugar de en las máquinas virtuales, el administrador puede
administrar directivas de seguridad para todos los inquilinos de un entorno
multiinquilino.

Puede administrar las ACL extendidas del conmutador de Hyper-V mediante los cmdlets
de PowerShell Add-VMNetworkAdapterExtendedAcl y Remove-
VMNetworkAdapterExtendedAcl .

 Sugerencia
 Esta característica se aplica a la pila HNVv1. Para las ACL de la pila de SDN, consulte
acl de SDN de redes definidas por software a continuación.

Para obtener más información sobre las listas de Access Control de puertos extendidos
de esta biblioteca, vea Crear directivas de seguridad con listas de Access Control
puertos extendidos.

Formación de equipos NIC

La formación de equipos NIC, también denominada unión nic, es la agregación de varios
puertos NIC en una entidad que el host percibe como un único puerto NIC. La
formación de equipos NIC protege contra el error de un único puerto NIC (o el cable
conectado a él). También agrega tráfico de red para un rendimiento más rápido.

Con Windows Server 2016 tiene dos maneras de hacer la selección de equipos:

1. Windows Server 2012 solución de teaming

2. Windows Server 2016 Switch Embedded Teaming (SET)

RSC en vSwitch
Receive Segment Coalescing (RSC) en vSwitch es una característica que toma paquetes
que forman parte de la misma secuencia y llegan entre interrupciones de red y los
convierte en un único paquete antes de entregarlos al sistema operativo. El conmutador
virtual de Windows Server 2019 tiene esta característica. Para obtener más información
sobre esta característica, vea Receive Segment Coalescing in the vSwitch (Uso de la
coalición de segmentos de recepción en vSwitch).

ACL de redes definidas por software (SDN)

La extensión SDN de Windows Server 2016 formas mejoradas de admitir ACL. En la
Windows Server 2016 de SDN v2, se usan ACL de SDN en lugar de ACL y ACL
extendidas. Puede usar controladora de red para administrar las ACL de SDN.

Calidad de servicio (QoS) de SDN

La extensión SDN de Windows Server 2016 formas mejoradas de proporcionar control
de ancho de banda (reservas de salida, límites de salida y límites de entrada) en una
base de 5 tuplas. Normalmente, estas directivas se aplican en el nivel vNIC o vmNIC,
pero puede hacerlos mucho más específicos. En la Windows Server 2016 de SDN v2, se
usa qos de SDN en lugar de vmQoS. Puede usar controladora de red para administrar la
calidad de servicio de SDN.

Formación de equipos insertada en el

conmutador (SET)
SET es una solución alternativa de formación de equipos NIC que puede usar en
entornos que incluyen Hyper-V y la pila de redes definidas por software (SDN) en
Windows Server 2016. SET integra la funcionalidad de formación de equipos de NIC en
el conmutador virtual de Hyper-V. Para obtener información sobre Switch Embedded
Teaming en esta biblioteca, vea Acceso directo a memoria remota (RDMA) y Switch
Embedded Teaming (SET).

Ajuste de escala en lado de recepción virtual

(vRSS)
VRSS de software se usa para propagar el tráfico entrante destinado a una máquina
virtual entre varios procesadores lógicos (LPs) de la máquina virtual. VRSS de software
ofrece a la máquina virtual la capacidad de controlar más tráfico de red que un solo LP
podría controlar.

Calidad de servicio de la máquina virtual

(vmQoS)
La calidad de servicio de la máquina virtual es una característica de Hyper-V que permite
al conmutador establecer límites en el tráfico generado por cada máquina virtual.
También permite que una máquina virtual reserve una cantidad de ancho de banda en la
conexión de red externa para que una máquina virtual no pueda usar otra máquina
virtual para el ancho de banda. En la Windows Server 2016 de SDN v2, qos de SDN
reemplaza a vmQoS.

vmQoS puede establecer límites de salida y reservas de salida. Debe determinar el

modo de reserva de salida (peso relativo o ancho de banda absoluto) antes de crear el
conmutador de Hyper-V.

Determine el modo de reserva de salida con el parámetro –

MinimumBandwidthMode del cmdlet New-VMSwitch PowerShell.
 Establezca el valor del límite de salida con el parámetro –MaximumBandwidth en
Set-VMNetworkAdapter cmdlet de PowerShell.

Establezca el valor de la reserva de salida con cualquiera de los parámetros

siguientes del cmdlet set VMNetworkAdapter de PowerShell:

Si el parámetro –MinimumBandwidthMode del cmdlet New-VMSwitch es

Absoluto, establezca el parámetro –MinimumBandwidthAbsolute en el cmdlet
Set VMNetworkAdapter.

Si el parámetro –MinimumBandwidthMode del cmdlet New-VMSwitch es

Weight, establezca el parámetro –MinimumBandwidthWeight en el cmdlet Set
VMNetworkAdapter.

Debido a las limitaciones del algoritmo utilizado para esta característica, se recomienda
que el ancho de banda absoluto o de mayor peso no sea superior a 20 veces el peso
más bajo o ancho de banda absoluto. Si se necesita más control, considere la
posibilidad de usar la pila de SDN y SDN-QoS característica.
Funciones y tecnologías integradas de
software y hardware (SH)
Artículo • 21/12/2022 • Tiempo de lectura: 7 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Azure Stack HCI,
versiones 21H2 y 20H2

Estas características tienen componentes de software y hardware. El software está

estrechamente vinculado a las funcionalidades de hardware necesarias para que la
característica funcione. Entre los ejemplos se incluyen VMMQ, VMQ, Descarga de suma
de comprobación IPv4 de envío y RSS. Para más información, consulte Requisitos de red
de host para Azure Stack HCI.

 Sugerencia

Las características SH y HO están disponibles si la NIC instalada la admite. En las

descripciones de características siguientes se explica cómo saber si la NIC admite la
característica.

NIC convergente
La NIC convergente es una tecnología que permite que las NIC virtuales del host de
Hyper-V expongan los servicios RDMA para hospedar procesos. Windows Server 2016
ya no requiere NIC independientes para RDMA. La característica NIC convergente
permite que las NIC virtuales de la partición de host (vNIC) expongan RDMA a la
partición de host y compartan el ancho de banda de las NIC entre el tráfico RDMA y la
máquina virtual y otro tráfico TCP/UDP de forma justa y administrable.
Puede administrar la operación NIC convergente a través de VMM o Windows
PowerShell. Los cmdlets de PowerShell son los mismos que se usan para RDMA
(consulte a continuación).

Para usar la funcionalidad NIC convergente:

1. Asegúrese de configurar el host para DCB.

2. Asegúrese de habilitar RDMA en la NIC o, en el caso de un equipo SET, las NIC

están enlazadas al conmutador de Hyper-V.

3. Asegúrese de habilitar RDMA en las vNIC designadas para RDMA en el host.

Para obtener más información sobre RDMA y SET, consulte Acceso directo a memoria
remota (RDMA) y Switch Embedded Teaming (SET).

Data Center Bridging (DCB)

DCB es un conjunto de estándares del Instituto de Ingenieros eléctricos y electrónicos
(IEEE) que permiten tejidos convergentes en centros de datos. DCB proporciona
administración de ancho de banda basada en cola de hardware en un host con la
cooperación del conmutador adyacente. Todo el tráfico para el almacenamiento, las
redes de datos, el clúster Inter-Process comunicación (IPC) y la administración
comparten la misma infraestructura de red Ethernet. En Windows Server 2016, DCB se
puede aplicar a cualquier NIC individualmente y a las NIC enlazadas al conmutador de
Hyper-V.

Para DCB, Windows Server usa control de Flow basado en prioridad (PFC), estandarizado
en IEEE 802.1Qbb. PFC crea un tejido de red sin pérdida (casi) evitando el
desbordamiento dentro de las clases de tráfico. Windows Server también usa la
selección de transmisión mejorada (ETS), estandarizada en IEEE 802.1Qaz. ETS permite la
división del ancho de banda en partes reservadas para hasta ocho clases de tráfico.
Cada clase de tráfico tiene su propia cola de transmisión y, a través del uso de PFC,
puede iniciar y detener la transmisión dentro de una clase.

Virtualización de red de Hyper-V

Versión Descripción

v1 Introducido en Windows Server 2012, virtualización de red de Hyper-V (HNV) permite

(HNVv1) la virtualización de redes de clientes sobre una infraestructura de red física compartida.
Con los cambios mínimos necesarios en el tejido de red físico, HNV proporciona a los
proveedores de servicios la agilidad para implementar y migrar cargas de trabajo de
inquilino en cualquier lugar de las tres nubes: la nube del proveedor de servicios, la
nube privada o la nube pública Microsoft Azure.

v2 En Windows Server 2016 y System Center Virtual Machine Manager, Microsoft

NVGRE proporciona una solución de virtualización de red de un extremo a otro que incluye
(HNVv2 puerta de enlace ras, equilibrio de carga de software, controladora de red, etc. Para
NVGRE) obtener más información, consulte Introducción a la virtualización de red de Hyper-V
en Windows Server 2016.

v2 En Windows Server 2016, forma parte de la extensión SDN, que se administra a través
VxLAN de la controladora de red.
(HNVv2
VxLAN)

Descarga de tareas de IPsec (IPsecTO)

La descarga de tareas IPsec es una característica de NIC que permite al sistema
operativo usar el procesador en la NIC para el trabajo de cifrado IPsec.

） Importante

La descarga de tareas IPsec es una tecnología heredada que no es compatible con

la mayoría de los adaptadores de red y donde existe, está deshabilitada de forma
predeterminada.
Red de área local virtual privada (PVLAN).
Las PVLAN permiten la comunicación solo entre máquinas virtuales en el mismo
servidor de virtualización. Una red virtual privada no está enlazada a un adaptador de
red físico. Una red virtual privada está aislada de todo el tráfico de red externo en el
servidor de virtualización, así como del tráfico de red entre el sistema operativo de
administración y la red externa. Este tipo de red resulta útil cuando necesita crear un
entorno de red aislado como, por ejemplo, un dominio de prueba aislado. Las pilas de
Hyper-V y SDN solo admiten el modo de puerto aislado pvLAN.

Para obtener más información sobre el aislamiento pvLAN, consulte System Center: blog
de ingeniería de Virtual Machine Manager .

Acceso directo a memoria remota (RDMA)

RDMA es una tecnología de red que proporciona comunicación de alto rendimiento y
baja latencia que minimiza el uso de la CPU. RDMA admite redes de copia cero al
permitir que el adaptador de red transfiera datos directamente a la memoria de la
aplicación o desde ella. Compatible con RDMA significa que la NIC (física o virtual) es
capaz de exponer RDMA a un cliente RDMA. RdMA habilitado, por otro lado, significa
que una NIC compatible con RDMA expone la interfaz RDMA en la pila.

Para obtener más información sobre RDMA, consulte Acceso directo a memoria remota
(RDMA) y Switch Embedded Teaming (SET).

Receive Side Scaling (RSS)

RSS es una característica de NIC que separa diferentes conjuntos de secuencias y los
entrega a diferentes procesadores para su procesamiento. RSS paraleliza el
procesamiento de red, lo que permite que un host se escale a velocidades de datos muy
altas.

Para obtener más información, consulte Escalado lateral de recepción (RSS).

Virtualización de Input-Output raíz única (SR-

IOV)
SR-IOV permite que el tráfico de máquina virtual se mueva directamente de la NIC a la
máquina virtual sin pasar por el host de Hyper-V. SR-IOV es una mejora increíble en el
rendimiento de una máquina virtual, pero carece de la capacidad de que el host
administre esa canalización. Use solo SR-IOV cuando la carga de trabajo se comporte
bien, sea de confianza y, por lo general, la única máquina virtual del host.

El tráfico que usa SR-IOV omite el conmutador de Hyper-V, lo que significa que no se
aplicará ninguna directiva, por ejemplo, ACL o administración de ancho de banda. El
tráfico SR-IOV tampoco se puede pasar a través de ninguna funcionalidad de
virtualización de red, por lo que no se puede aplicar la encapsulación nv-GRE o VxLAN.
Use solo SR-IOV para cargas de trabajo de confianza en situaciones específicas. Además,
no puede usar las directivas de host, la administración de ancho de banda y las
tecnologías de virtualización.

En el futuro, dos tecnologías permitirían sr-IOV: tablas de Flow genéricas (GFT) y

descarga de QoS de hardware (administración de ancho de banda en la NIC), una vez
que las NIC de nuestro ecosistema las admiten. La combinación de estas dos
tecnologías haría que SR-IOV fuera útil para todas las máquinas virtuales, permitiría
aplicar directivas, virtualización y reglas de administración de ancho de banda, y podría
dar lugar a grandes saltos en la aplicación general de SR-IOV.

Para obtener más información, vea Información general sobre la virtualización de E/S
raíz única (SR-IOV).

Descarga tcp chimney

La descarga tcp chimney, también conocida como descarga del motor TCP (TOE), es una
tecnología que permite al host descargar todo el procesamiento TCP en la NIC. Dado
que la pila TCP del servidor Windows casi siempre es más eficaz que el motor de TOE,
no se recomienda usar la descarga de TCP Chimney.

） Importante

La descarga tcp chimney es una tecnología en desuso. Se recomienda no usar la

descarga de TCP Chimney, ya que Microsoft podría dejar de admitirla en el futuro.

Red de área local virtual (VLAN)

VLAN es una extensión del encabezado del marco Ethernet para habilitar la creación de
particiones de una LAN en varias VLAN, cada una con su propio espacio de direcciones.
En Windows Server 2016, las VLAN se establecen en puertos del conmutador de Hyper-
V o estableciendo interfaces de equipo en equipos de formación de equipos NIC.
Virtual Machine Queue (VMQ)
VMQs es una característica de NIC que asigna una cola para cada máquina virtual.
Siempre que tenga Hyper-V habilitado; También debe habilitar VMQ. En Windows
Server 2016, las VMQ usan conmutador de NIC vPorts con una sola cola asignada a
vPort para proporcionar la misma funcionalidad.

Cola múltiple de máquina virtual (VMMQ)

VMMQ es una característica de NIC que permite que el tráfico de una máquina virtual se
distribuya entre varias colas, cada una procesada por un procesador físico diferente. A
continuación, el tráfico se pasa a varias direcciones IP de la máquina virtual, ya que
estaría en vRSS, lo que permite entregar un ancho de banda de red considerable a la
máquina virtual.
Tecnologías y características de solo
hardware
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Azure Stack HCI, versiones
21H2 y 20H2

Estas aceleraciones de hardware mejoran el rendimiento de las redes junto con el

software, pero no forman parte de ninguna característica de software. Algunos ejemplos
de estos son Interrupt Moderation, Flow Control y Receive-side IPv4 Checksum Offload.
Para más información, consulte Requisitos de red de host para Azure Stack HCI.

 Sugerencia

Las características SH y HO están disponibles si la NIC instalada lo admite. En las

descripciones de características siguientes se explica cómo saber si la NIC admite la
característica.

Descarga de suma de comprobación de

direcciones
Las descargas de suma de comprobación de direcciones son una característica nic que
descarga el cálculo de sumas de comprobación de direcciones (IP, TCP, UDP) en el
hardware nic para enviar y recibir.

En la ruta de acceso de recepción, la descarga de suma de comprobación calcula las

sumas de comprobación en los encabezados IP, TCP y UDP (según corresponda) e indica
al sistema operativo si las sumas de comprobación pasaron, no se pudieron comprobar
o no. Si la NIC declara que las sumas de comprobación son válidas, el sistema operativo
acepta el paquete sin estado. Si la NIC declara que las sumas de comprobación no son
válidas o no están activadas, la pila IP/TCP/UDP calcula internamente las sumas de
comprobación de nuevo. Si se produce un error en la suma de comprobación calculada,
el paquete se descarta.

En la ruta de acceso de envío, la descarga de suma de comprobación calcula e inserta

las sumas de comprobación en el encabezado IP, TCP o UDP según corresponda.
Deshabilitar las descargas de suma de comprobación en la ruta de acceso de envío no
deshabilita el cálculo y la inserción de la suma de comprobación para los paquetes
enviados al controlador de minipuerto mediante la característica Descarga de envío
grande (LSO). Para deshabilitar todos los cálculos de descarga de suma de
comprobación, el usuario también debe deshabilitar LSO.

Administrar descargas de suma de comprobación de direcciones

En las propiedades avanzadas hay varias propiedades distintas:

Descarga de suma de comprobación IPv4

Descarga de suma de comprobación TCP (IPv4)

Descarga de suma de comprobación TCP (IPv6)

Descarga de suma de comprobación UDP (IPv4)

Descarga de suma de comprobación UDP (IPv6)

De forma predeterminada, todos ellos siempre están habilitados. Se recomienda

habilitar siempre todas estas descargaciones.

Las descargas de suma de comprobación se pueden administrar mediante Enable-

NetAdapterChecksumOffload y Disable-NetAdapterChecksumOffload cmdlets. Por
ejemplo, el siguiente cmdlet habilita los cálculos de suma de comprobación TCP (IPv4) y
UDP (IPv4):

PowerShell

Enable-NetAdapterChecksumOffload –Name * -TcpIPv4 -UdpIPv4

Sugerencias usar descargas de suma de comprobación de direcciones

Las descargas de suma de comprobación de direcciones siempre deben habilitarse

independientemente de la carga de trabajo o circunstancia. Esta tecnología más básica
de todas las tecnologías de descarga siempre mejora el rendimiento de la red. La
descarga de suma de comprobación también es necesaria para que otras
descargaciones sin estado funcionen, incluido el escalado del lado de recepción (RSS), la
conjunción de segmentos de recepción (RSC) y la descarga de envío grande (LSO).

Moderación de interrupciones (IM)

Im almacena en búfer varios paquetes recibidos antes de interrumpir el sistema
operativo. Cuando una NIC recibe un paquete, inicia un temporizador. Cuando el búfer
está lleno o el temporizador expira, lo que llegue primero, la NIC interrumpe el sistema
operativo.

Muchas NIC admiten algo más que solo on/off para la moderación de interrupciones. La
mayoría de las NIC admiten los conceptos de una velocidad baja, media y alta para la
mensajería instantánea. Las distintas tasas representan temporizadores más cortos o
más largos y ajustes de tamaño de búfer adecuados para reducir la latencia (moderación
de interrupciones baja) o reducir las interrupciones (moderación de interrupciones alta).

Hay un equilibrio entre reducir las interrupciones y retrasar excesivamente la entrega de

paquetes. Por lo general, el procesamiento de paquetes es más eficaz con la
moderación de interrupciones habilitada. Es posible que las aplicaciones de alto
rendimiento o baja latencia necesiten evaluar el impacto de deshabilitar o reducir la
moderación de interrupciones.

Tramas gigantes
Fotogramas gigantes es una característica de red y NIC que permite a una aplicación
enviar fotogramas que son mucho mayores que los 1500 bytes predeterminados.
Normalmente, el límite de fotogramas gigantes es de unos 9000 bytes, pero puede ser
menor.

No se han realizado cambios en la compatibilidad con fotogramas gigantes Windows

Server 2012 R2.

En Windows Server 2016 hay una nueva descarga: MTU_for_HNV. Esta nueva descarga
funciona con la configuración de Trama gigante para asegurarse de que el tráfico
encapsulado no requiere segmentación entre el host y el conmutador adyacente. Esta
nueva característica de la pila de SDN tiene la NIC que calcula automáticamente qué
MTU anunciar y qué MTU usar en la conexión. Estos valores para MTU son diferentes si
hay alguna descarga de HNV en uso. (En la tabla de compatibilidad de características,
tabla 1, MTU_for_HNV tendría las mismas interacciones que las cargas de HNVv2, ya que
está directamente relacionada con las descargaciones de HNVv2).

Descarga de envío grande (LSO)

LSO permite que una aplicación pase un bloque grande de datos a la NIC y la NIC divide
los datos en paquetes que caben dentro de la Unidad de transferencia máxima (MTU)
de la red.
Receive Segment Coalescing (RSC)
La coalescing de segmentos de recepción, también conocida como descarga de
recepción grande, es una característica nic que toma paquetes que forman parte de la
misma secuencia que llega entre interrupciones de red y las convierte en un único
paquete antes de entregarlos al sistema operativo. RSC no está disponible en las NIC
enlazadas al conmutador virtual de Hyper-V. Para obtener más información, vea Receive
Segment Coalescing (RSC).
Propiedades avanzadas de NIC
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Azure Stack HCI,
versiones 21H2 y 20H2

Puede administrar NIC y todas las características a través de Windows PowerShell

mediante el cmdlet NetAdapter. También puede administrar NIC y todas las
características mediante network Panel de control ([Link]). Para más información,
consulte Requisitos de red de host para Azure Stack HCI.

1. En Windows PowerShell, ejecute el Get‑NetAdapterAdvancedProperty cmdlet en

dos modelos o marcas diferentes de NIC.

Hay similitudes y diferencias en estas dos listas de propiedades avanzadas de NIC.

2. En network Panel de control ([Link]), haga lo siguiente:

a. Haga clic con el botón derecho en la NIC.

b. En el cuadro de diálogo de propiedades, haga clic en Configurar.

c. Haga clic en la pestaña Opciones avanzadas para ver las propiedades avanzadas.

Los elementos de esta lista se correlacionan con los elementos de la Get-

NetAdapterAdvancedProperties salida.
RSC en vSwitch
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Azure Stack HCI, versiones
21H2 y 20H2

La coalescing de segmentos de recepción (RSC) en vSwitch es una característica de

Windows Server 2019 y Actualización de octubre de 2018 de Windows 10 que ayuda a
reducir el uso de CPU del host y aumenta el rendimiento de las cargas de trabajo
virtuales mediante la conjunción de varios segmentos TCP en menos segmentos, pero
más grandes. Procesar menos segmentos grandes (unidos) es más eficaz que procesar
numerosos segmentos pequeños. Para más información, consulte Requisitos de red de
host para Azure Stack HCI.

Windows Server 2012 y versiones posteriores incluían una versión de descarga solo de
hardware (implementada en el adaptador de red físico) de la tecnología también
conocida como Coalescing de segmentos de recepción. Esta versión descargado de RSC
sigue estando disponible en versiones posteriores de Windows. Sin embargo, no es
compatible con las cargas de trabajo virtuales y se deshabilitó una vez que un
adaptador de red físico está conectado a un vSwitch. Para obtener más información
sobre la versión solo de hardware de RSC, vea Receive Segment Coalescing (RSC)
(Coalescing de segmentos de recepción [RSC]).

Escenarios que se benefician de RSC en vSwitch

Las cargas de trabajo cuya ruta de acceso a datos atraviesa un conmutador virtual se
benefician de esta característica.

Por ejemplo:

Nic virtuales de host que incluyen:

Red definida por software

Host de Hyper-V

Espacios de almacenamiento directo

NIC virtuales invitadas de Hyper-V

Puertas de enlace GRE de redes definidas por software

 Contenedor

Las cargas de trabajo que no son compatibles con esta característica incluyen:

Puertas de enlace IPSEC de red definidas por software

NIC virtuales habilitadas para SR-IOV

SMB directo

Configuración de RSC en vSwitch

De forma predeterminada, en vSwitches externos, RSC está habilitado.

Vea la configuración actual:

PowerShell

Get-VMSwitch -Name vSwitchName | Select-Object *RSC*

Habilitar o deshabilitar RSC en vSwitch

） Importante

Importante: RSC en vSwitch se puede habilitar y deshabilitar sobre la marcha sin

afectar a las conexiones existentes.

Deshabilitar RSC en vSwitch

PowerShell

Set-VMSwitch -Name vSwitchName -EnableSoftwareRsc $false

Volver a habilitar RSC en vSwitch

PowerShell

Set-VMSwitch -Name vSwitchName -EnableSoftwareRsc $True

Para más información, consulte Set-VMSwitch.

API del servicio Host Compute Network
(HCN) para máquinas virtuales y
contenedores
Artículo • 21/09/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019

La API de servicio de red de proceso de host (HCN) es una API de Win32 orientada al
público que proporciona acceso de nivel de plataforma para administrar redes virtuales,
puntos de conexión de red virtual y directivas asociadas. Juntos, esto proporciona
conectividad y seguridad para máquinas virtuales (VM) y contenedores que se ejecutan
en un Windows host.

Los desarrolladores usan la API del servicio HCN para administrar redes para máquinas
virtuales y contenedores en sus flujos de trabajo de aplicación. La API de HCN se ha
diseñado para proporcionar la mejor experiencia para los desarrolladores. Los usuarios
finales no interactúan directamente con estas API.

Características de HCN Service API

Se implementa como API de C hospedada por el servicio de red host (HNS) en
oncore/vm.

Proporciona la capacidad de crear, modificar, eliminar y enumerar objetos HCN

como redes, puntos de conexión, espacios de nombres y directivas. Las
operaciones se realizan en los identificadores de los objetos (por ejemplo, un
identificador de red) y internamente estos identificadores se implementan
mediante identificadores de contexto RPC.

Basado en esquemas. La mayoría de las funciones de la API definen parámetros de

entrada y salida como cadenas que contienen los argumentos de la llamada de
función como documentos JSON. Los documentos JSON se basan en esquemas
fuertemente con tipo y con versiones, estos esquemas forman parte de la
documentación pública.

Se proporciona una API de suscripción o devolución de llamada para permitir que

los clientes se registren para recibir notificaciones de eventos de todo el servicio,
como creaciones y eliminaciones de red.
 HCN API funciona en Puente de dispositivo de escritorio aplicaciones (también
llamadas Centennial) que se ejecutan en servicios del sistema. La API comprueba la
ACL recuperando el token de usuario del autor de la llamada.

 Sugerencia

La API del servicio HCN se admite en tareas en segundo plano y ventanas que no
están en primer plano.

Terminología: Host frente a Proceso

El servicio de proceso de host permite a los autores de llamadas crear y administrar
máquinas virtuales y contenedores en un solo equipo físico. Se denomina para seguir la
terminología del sector.

El host se usa ampliamente en el sector de virtualización para hacer referencia al

sistema operativo que proporciona recursos virtualizados.

El proceso se usa para hacer referencia a métodos de virtualización que son más
amplios que solo las máquinas virtuales. El servicio de red de proceso de host
permite a los autores de llamadas crear y administrar redes para máquinas
virtuales y contenedores en un solo equipo físico.

Documentos de configuración basados en

esquemas
Los documentos de configuración basados en esquemas bien definidos son un estándar
del sector establecido en el espacio de virtualización. La mayoría de las soluciones de
virtualización, como Docker y Kubernetes, proporcionan API basadas en documentos de
configuración. Varias iniciativas del sector, con la participación de Microsoft, impulsan
un ecosistema para definir y validar estos esquemas, como OpenAPI . Estas iniciativas
también impulsan la normalización de definiciones de esquema específicas para los
esquemas usados para los contenedores, como Open Container Initiative (OCI).

El lenguaje que se usa para crear documentos de configuración es JSON , que se usa
en combinación con:

Definiciones de esquema que definen un modelo de objetos para el documento

Validación de si un documento JSON se ajusta a un esquema
 Conversión automatizada de documentos JSON hacia y desde representaciones
nativas de estos esquemas en los lenguajes de programación usados por los
autores de llamada de las API

Las definiciones de esquema usadas con frecuencia son OpenAPI y esquema JSON ,
lo que le permite especificar las definiciones detalladas de las propiedades de un
documento, por ejemplo:

Conjunto válido de valores para una propiedad, como 0-100 para una propiedad
que representa un porcentaje.
Definición de enumeraciones, que se representan como un conjunto de cadenas
válidas para una propiedad.
Expresión regular para el formato esperado de una cadena.

Como parte de la documentación de las API de HCN, tenemos previsto publicar el

esquema de nuestros documentos JSON como una especificación de OpenAPI. Según
esta especificación, las representaciones específicas del lenguaje del esquema pueden
permitir el uso seguro de tipos de los objetos de esquema en el lenguaje de
programación utilizado por el cliente.

Ejemplo
A continuación se muestra un ejemplo de este flujo de trabajo para el objeto que
representa un controlador SCSI en el documento de configuración de una máquina
virtual.

enum IpamType
{
[NewIn("2.0")] Static,
[NewIn("2.0")] Dhcp,
};
class Ipam
{
// Type : dhcp
[NewIn("2.0"),OmitEmpty] IpamType Type;
[NewIn("2.0"),OmitEmpty] Subnet Subnets[];
};
class Subnet : [Link]
{
[NewIn("2.0"),OmitEmpty] string IpAddressPrefix;
[NewIn("2.0"),OmitEmpty] SubnetPolicy Policies[];
[NewIn("2.0"),OmitEmpty] Route Routes[];
};
enum SubnetPolicyType
{
 [NewIn("2.0")] VLAN
};
class SubnetPolicy
{
[NewIn("2.0"),OmitEmpty] SubnetPolicyType Type;
[NewIn("2.0"),OmitEmpty] [Link] Data;
};
class PolicySettings
{
[NewIn("2.0"),OmitEmpty] string Name;
};
class VlanPolicy : [Link]
{
[NewIn("2.0")] uint32 IsolationId;
};
class Route
{
[NewIn("2.0"),OmitEmpty] string NextHop;
[NewIn("2.0"),OmitEmpty] string DestinationPrefix;
[NewIn("2.0"),OmitEmpty] uint16 Metric;
};

 Sugerencia

Las anotaciones [NewIn("2.0") forman parte de la compatibilidad con el control de

versiones para las definiciones de esquema. A partir de esta definición interna,
generamos las especificaciones de OpenAPI para el esquema:

{
"swagger" : "2.0",
"info" : {
"version" : "2.1",
"title" : "HCN API"
},
"definitions": {
"Ipam": {
"type": "object",
"properties": {
"Type": {
"type": "string",
"enum": [
"Static",
"Dhcp"
],
"description": " Type : dhcp"
},
"Subnets": {
"type": "array",
"items": {
 "$ref": "#/definitions/Subnet"
}
}
}
},
"Subnet": {
"type": "object",
"properties": {
"ID": {
"type": "string",
"pattern": "^[0-9A-Fa-f]{8}-([0-9A-Fa-f]{4}-){3}[0-9A-
Fa-f]{12}$"
},
"IpAddressPrefix": {
"type": "string"
},
"Policies": {
"type": "array",
"items": {
"$ref": "#/definitions/SubnetPolicy"
}
},
"Routes": {
"type": "array",
"items": {
"$ref": "#/definitions/Route"
}
}
}
},
"SubnetPolicy": {
"type": "object",
"properties": {
"Type": {
"type": "string",
"enum": [
"VLAN",
"VSID"
]
},
"Data": {
"$ref": "#/definitions/PolicySettings"
}
}
},
"PolicySettings": {
"type": "object",
"properties": {
"Name": {
"type": "string"
}
}
},
"VlanPolicy": {
"type": "object",
 "properties": {
"Name": {
"type": "string"
},
"IsolationId": {
"type": "integer",
"format": "uint32"
}
}
},
"Route": {
"type": "object",
"properties": {
"NextHop": {
"type": "string"
},
"DestinationPrefix": {
"type": "string"
},
"Metric": {
"type": "integer",
"format": "uint16"
}
}
}
}
}

Puede usar herramientas, como Swagger , para generar representaciones específicas

del lenguaje del lenguaje de programación de esquema que usa un cliente. Swagger
admite una variedad de lenguajes, como C#, Go, Javascript y Python.

Ejemplo de código de C# generado para el objeto de nivel superior IPAM subnet.

Ejemplo de código Go generado para el nivel superior IPAM objeto Subnet. Docker
y Kubernetes usan Go, que son dos de los consumidores de las API del servicio de
red de proceso de host. Go tiene compatibilidad integrada para serializar tipos go
hacia y desde documentos JSON.

Además de la generación y validación de código, puede usar herramientas para

simplificar el trabajo con documentos JSON, es decir, Visual Studio Code .

Objetos de nivel superior definidos en el esquema HCN

Los objetos de nivel superior son:

HostComputeNetwork
HostComputeEndpoint
HostComputeNamespace
 HostComputeLoadBalancer

class HostComputeNetwork : [Link]

{
[NewIn("2.0"),OmitEmpty] [Link] Type;
[NewIn("2.0"),OmitEmpty] [Link]
Policies[];
[NewIn("2.0"),OmitEmpty] [Link]
MacPool;
[NewIn("2.0"),OmitEmpty] [Link] Dns;
[NewIn("2.0"),OmitEmpty] [Link]
Ipams[];
};
class HostComputeEndpoint : [Link]
{
[NewIn("2.0"),OmitEmpty] string
HostComputeNetwork;
[NewIn("2.0"),OmitEmpty] [Link]
Policies[];
[NewIn("2.0"),OmitEmpty] [Link]
IpConfigurations[];
[NewIn("2.0"),OmitEmpty] [Link] Dns;
[NewIn("2.0"),OmitEmpty] [Link]
Routes[];
[NewIn("2.0"),OmitEmpty] string
MacAddress;
};
class HostComputeNamespace : [Link]
{
[NewIn("2.0"),OmitEmpty] uint32
NamespaceId;
[NewIn("2.0"),OmitEmpty] Guid
NamespaceGuid;
[NewIn("2.0"),OmitEmpty] [Link] Type;
[NewIn("2.0"),OmitEmpty] [Link]
Resources[];
};
class HostComputeLoadBalancer : [Link]
{
[NewIn("2.0"), OmitEmpty] string
HostComputeEndpoints[];
[NewIn("2.0"), OmitEmpty] string
VirtualIPs[];
[NewIn("2.0"), OmitEmpty]
[Link] PortMappings[];
[NewIn("2.0"), OmitEmpty] [Link]
Policies[];
};
Pasos siguientes
Obtenga más información sobre los escenarios comunes de HCN.

Obtenga más información sobre los identificadores de contexto RPC para HCN.

Obtenga más información sobre los esquemas de documentos JSON de HCN.

Escenarios frecuentes
Artículo • 21/12/2022 • Tiempo de lectura: 10 minutos

Se aplica a: Windows Server 2022, Windows Server 2019

Escenario: HCN

Creación de un HCN
En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para crear una red de proceso de host en el host que se puede usar para conectar NIC
virtuales a Virtual Machines o contenedores.

C++

using unique_hcn_network = wil::unique_any<

HCN_NETWORK,
decltype(&HcnCloseNetwork),
HcnCloseNetwork>;
/// Creates a simple HCN Network, waiting synchronously to finish the task
void CreateHcnNetwork()
{
unique_hcn_network hcnnetwork;
wil::unique_cotaskmem_string result;
std::wstring settings = LR"(
{
"SchemaVersion": {
"Major": 2,
"Minor": 0
},
"Owner" : "WDAGNetwork",
"Flags" : 0,
"Type" : 0,
"Ipams" : [
{
"Type" : 0,
"Subnets" : [
{
"IpAddressPrefix" : "[Link]/24",
"Policies" : [
{
"Type" : "VLAN",
"IsolationId" : 100,
}
],
"Routes" : [
{
"NextHop" : "[Link]",
 "DestinationPrefix" : "[Link]/0",
}
]
}
],
},
],
"MacPool": {
"Ranges" : [
{
"EndMacAddress": "00-15-5D-52-CF-FF",
"StartMacAddress": "00-15-5D-52-C0-00"
}
],
},
"Dns" : {
"Suffix" : "[Link]",
"ServerList" : ["[Link]"],
}
}
})";
GUID networkGuid;
HRESULT result = CoCreateGuid(&networkGuid);
result = HcnCreateNetwork(
networkGuid, // Unique ID
settings.c_str(), // Compute system settings document
&hcnnetwork,
&result
);
if (FAILED(result))
{
// UnMarshal the result Json
// ErrorSchema
// {
// "ErrorCode" : <uint32>,
// "Error" : <string>,
// "Success" : <bool>,
// }
// Failed to create network
THROW_HR(result);
}
// Close the Handle
result = HcnCloseNetwork([Link]());
if (FAILED(result))
{
// UnMarshal the result Json
THROW_HR(result);
}
}

Eliminar un HCN
En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para abrir & eliminar una red de proceso de host.

C++

wil::unique_cotaskmem_string errorRecord;
GUID networkGuid; // Initialize it to appropriate network guid value
HRESULT hr = HcnDeleteNetwork(networkGuid, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Enumerar todas las redes

En este ejemplo se muestra cómo usar la API de servicio de red de proceso de host para
enumerar todas las redes de proceso de host.

C++

wil::unique_cotaskmem_string resultNetworks;
wil::unique_cotaskmem_string errorRecord;
// Filter to select Networks based on properties
std::wstring filter [] = LR"(
{
"Name" : "WDAG",
})";
HRESULT result = HcnEnumerateNetworks(filter.c_str(), &resultNetworks,
&errorRecord);
if (FAILED(result))
{
// UnMarshal the result Json
THROW_HR(result);
}

Consulta de las propiedades de red

En este ejemplo se muestra cómo usar host Compute Network Service API para
consultar las propiedades de red.

C++

unique_hcn_network hcnnetwork;
wil::unique_cotaskmem_string errorRecord;
wil::unique_cotaskmem_string properties;
std:wstring query = LR"(
 {
// Future
})";
GUID networkGuid; // Initialize it to appropriate network guid value
HRESULT hr = HcnOpenNetwork(networkGuid, &hcnnetwork, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
hr = HcnQueryNetworkProperties([Link](), query.c_str(),
&properties, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Escenario: punto de conexión de HCN

Creación de un punto de conexión de HCN

En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para crear un punto de conexión de red de proceso de host y, a continuación, agregarlo
a la máquina virtual o a un contenedor.

C++

using unique_hcn_endpoint = wil::unique_any<

HCN_ENDPOINT,
decltype(&HcnCloseEndpoint),
HcnCloseEndpoint>;
void CreateAndHotAddEndpoint()
{
unique_hcn_endpoint hcnendpoint;
unique_hcn_network hcnnetwork;
wil::unique_cotaskmem_string errorRecord;
std::wstring settings[] = LR"(
{
"SchemaVersion": {
"Major": 2,
"Minor": 0
},
"Owner" : "Sample",
"Flags" : 0,
"HostComputeNetwork" : "87fdcf16-d210-426e-959d-2a1d4f41d6d3",
"DNS" : {
"Suffix" : "[Link]",
"ServerList" : "[Link]",
}
 })";
GUID endpointGuid;
HRESULT result = CoCreateGuid(&endpointGuid);
result = HcnOpenNetwork(
networkGuid, // Unique ID
&hcnnetwork,
&errorRecord
);
if (FAILED(result))
{
// Failed to find network
THROW_HR(result);
}
result = HcnCreateEndpoint(
[Link](),
endpointGuid, // Unique ID
settings.c_str(), // Compute system settings document
&hcnendpoint,
&errorRecord
);
if (FAILED(result))
{
// Failed to create endpoint
THROW_HR(result);
}
// Can use the sample from HCS API Spec on how to attach this endpoint
// to the VM using AddNetworkAdapterToVm
result = HcnCloseEndpoint([Link]());
if (FAILED(result))
{
// UnMarshal the result Json
THROW_HR(result);
}
}

Eliminar un extremo
En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para eliminar un punto de conexión de red de proceso de host.

C++

wil::unique_cotaskmem_string errorRecord;
GUID endpointGuid; // Initialize it to appropriate endpoint guid value
HRESULT hr = HcnDeleteEndpoint(endpointGuid, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
Modificación de un punto de conexión
En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para modificar un punto de conexión de red de proceso de host.

C++

unique_hcn_endpoint hcnendpoint;
GUID endpointGuid; // Initialize it to appropriate endpoint guid value
HRESULT hr = HcnOpenEndpoint(endpointGuid, &hcnendpoint, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
std::wstring ModifySettingAddPortJson = LR"(
{
"ResourceType" : 0,
"RequestType" : 0,
"Settings" : {
"PortName" : "acbd341a-ec08-44c0-9d5e-61af0ee86902"
"VirtualNicName" : "641313e1-7ae8-4ddb-94e5-3215f3a0b218-
-87fdcf16-d210-426e-959d-2a1d4f41d6d1"
"VirtualMachineId" : "641313e1-7ae8-4ddb-94e5-3215f3a0b218"
}
}
)";
hr = HcnModifyEndpoint([Link](),
ModifySettingAddPortJson.c_str(), &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Enumerar todos los puntos de conexión

En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para enumerar todos los puntos de conexión de red de proceso de host.

C++

wil::unique_cotaskmem_string errorRecord;
wil::unique_cotaskmem_string resultEndpoints;
wil::unique_cotaskmem_string errorRecord;
// Filter to select Endpoint based on properties
std::wstring filter [] = LR"(
{
"Name" : "sampleNetwork",
})";
 result = HcnEnumerateEndpoints(filter.c_str(), &resultEndpoints,
&errorRecord);
if (FAILED(result))
{
THROW_HR(result);
}

Propiedades del punto de conexión de consulta

En este ejemplo se muestra cómo usar la API de servicio de red de proceso de host para
consultar todas las propiedades de un punto de conexión de red de proceso de host.

C++

unique_hcn_endpoint hcnendpoint;
wil::unique_cotaskmem_string errorRecord;
GUID endpointGuid; // Initialize it to appropriate endpoint guid value
HRESULT hr = HcnOpenEndpoint(endpointGuid, &hcnendpoint, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
wil::unique_cotaskmem_string properties;
std:wstring query = LR"(
{
// Future
})";
hr = HcnQueryEndpointProperties([Link](), query.c_str(),
&properties, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the errorRecord Json
THROW_HR(hr);
}

Escenario: Espacio de nombres HCN

Creación de un espacio de nombres HCN

En este ejemplo se muestra cómo usar la API de servicio de red de proceso de host para
crear un espacio de nombres de red de proceso de host en el host que se puede usar
para conectar el punto de conexión y los contenedores.

C++
 using unique_hcn_namespace = wil::unique_any<
HCN_NAMESPACE,
decltype(&HcnCloseNamespace),
HcnCloseNamespace>;
/// Creates a simple HCN Network, waiting synchronously to finish the task
void CreateHcnNamespace()
{
unique_hcn_namespace handle;
wil::unique_cotaskmem_string errorRecord;
std::wstring settings = LR"(
{
"SchemaVersion": {
"Major": 2,
"Minor": 0
},
"Owner" : "Sample",
"Flags" : 0,
"Type" : 0,
})";
GUID namespaceGuid;
HRESULT result = CoCreateGuid(&namespaceGuid);
result = HcnCreateNamespace(
namespaceGuid, // Unique ID
settings.c_str(), // Compute system settings document
&handle,
&errorRecord
);
if (FAILED(result))
{
// UnMarshal the result Json
// ErrorSchema
// {
// "ErrorCode" : <uint32>,
// "Error" : <string>,
// "Success" : <bool>,
// }
// Failed to create network
THROW_HR(result);
}
result = HcnCloseNamespace([Link]());
if (FAILED(result))
{
// UnMarshal the result Json
THROW_HR(result);
}
}

Eliminación de un espacio de nombres hcn

En este ejemplo se muestra cómo usar host Compute Network Service API para eliminar
un espacio de nombres de red de proceso de host.
 C++

wil::unique_cotaskmem_string errorRecord;
GUID namespaceGuid; // Initialize it to appropriate namespace guid value
HRESULT hr = HcnDeleteNamespace(namespaceGuid, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Modificación de un espacio de nombres hcn

En este ejemplo se muestra cómo usar host Compute Network Service API para
modificar un espacio de nombres de red de proceso de host.

C++

unique_hcn_namespace handle;
GUID namespaceGuid; // Initialize it to appropriate namespace guid value
HRESULT hr = HcnOpenNamespace(namespaceGuid, &handle, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
wil::unique_cotaskmem_string errorRecord;
static std::wstring ModifySettingAddEndpointJson = LR"(
{
"ResourceType" : 1,
"RequestType" : 0,
"Settings" : {
"EndpointId" : "87fdcf16-d210-426e-959d-2a1d4f41d6d1"
}
}
)";
hr = HcnModifyNamespace([Link](),
ModifySettingAddEndpointJson.c_str(), &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
hr = HcnCloseNamespace([Link]());
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
Enumerar todos los espacios de nombres
En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para enumerar todos los espacios de nombres de red de proceso de host.

C++

wil::unique_cotaskmem_string resultNamespaces;
wil::unique_cotaskmem_string errorRecord;
std::wstring filter [] = LR"(
{
// Future
})";
HRESULT hr = HcnEnumerateNamespace(filter.c_str(), &resultNamespaces,
&errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Propiedades del espacio de nombres de consulta

En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para consultar las propiedades del espacio de nombres de red de proceso de host.

C++

unique_hcn_namespace handle;
GUID namespaceGuid; // Initialize it to appropriate namespace guid value
HRESULT hr = HcnOpenNamespace(namespaceGuid, &handle, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
wil::unique_cotaskmem_string errorRecord;
wil::unique_cotaskmem_string properties;
std:wstring query = LR"(
{
// Future
})";
HRESULT hr = HcnQueryNamespaceProperties([Link](), query.c_str(),
&properties, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
Escenario: Equilibrador de carga de HCN

Creación de un equilibrador de carga de HCN

En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para crear una red de proceso de host Load Balancer en el host que se puede usar para
equilibrar la carga del punto de conexión en el proceso.

C++

using unique_hcn_loadbalancer = wil::unique_any<

HCN_LOADBALANCER,
decltype(&HcnCloseLoadBalancer),
HcnCloseLoadBalancer>;
/// Creates a simple HCN LoadBalancer, waiting synchronously to finish the
task
void CreateHcnLoadBalancer()
{
unique_hcn_loadbalancer handle;
wil::unique_cotaskmem_string errorRecord;
std::wstring settings = LR"(
{
"SchemaVersion": {
"Major": 2,
"Minor": 0
},
"Owner" : "Sample",
"HostComputeEndpoints" : [
"87fdcf16-d210-426e-959d-2a1d4f41d6d1"
],
"VirtualIPs" : [ "[Link]" ],
"PortMappings" : [
{
"Protocol" : 0,
"InternalPort" : 8080,
"ExternalPort" : 80,
}
],
"EnableDirectServerReturn" : true,
"InternalLoadBalancer" : false,
}
)";
GUID lbGuid;
HRESULT result = CoCreateGuid(&lbGuid);
HRESULT hr = HcnCreateLoadBalancer(
lbGuid, // Unique ID
settings.c_str(), // LoadBalancer settings document
&handle,
&errorRecord
);
if (FAILED(hr))
 {
// UnMarshal the result Json
// ErrorSchema
// {
// "ErrorCode" : <uint32>,
// "Error" : <string>,
// "Success" : <bool>,
// }
// Failed to create network
THROW_HR(hr);
}
hr = HcnCloseLoadBalancer([Link]());
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
}

Eliminación de un equilibrador de carga de HCN

En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para eliminar un Load Balancer de red de proceso de host.

C++

wil::unique_cotaskmem_string errorRecord;
GUID lbGuid; // Initialize it to appropriate loadbalancer guid value
HRESULT hr = HcnDeleteLoadBalancer(lbGuid , &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Modificación de un equilibrador de carga de HCN

En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para modificar un Load Balancer de red de proceso de host.

C++

unique_hcn_loadbalancer handle;
GUID lbGuid; // Initialize it to appropriate loadbalancer guid value
HRESULT hr = HcnOpenLoadBalancer(lbGuid, &handle, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
 }
wil::unique_cotaskmem_string errorRecord;
static std::wstring ModifySettingAddEndpointJson = LR"(
{
"ResourceType" : 1,
"RequestType" : 0,
"Settings" : {
"EndpointId" : "87fdcf16-d210-426e-959d-2a1d4f41d6d1"
}
}
)";
hr = HcnModifyLoadBalancer([Link](),
ModifySettingAddEndpointJson.c_str(), &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
hr = HcnCloseLoadBalancer([Link]());
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Enumerar todos los equilibradores de carga

En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para enumerar todas las Load Balancer de red de proceso de host.

C++

wil::unique_cotaskmem_string resultLoadBalancers;
wil::unique_cotaskmem_string errorRecord;
std::wstring filter [] = LR"(
{
// Future
})";
HRESULT result = HcnEnumerateLoadBalancers(filter.c_str(), &
resultLoadbalancers, &errorRecord);
if (FAILED(result))
{
// UnMarshal the result Json
THROW_HR(result);
}

Propiedades del equilibrador de carga de consultas

En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para consultar las propiedades de host Compute Network Load Balancer.

C++

unique_hcn_loadbalancer handle;
GUID lbGuid; // Initialize it to appropriate loadbalancer guid value
HRESULT hr = HcnOpenLoadBalancer(lbGuid, &handle, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
wil::unique_cotaskmem_string errorRecord;
wil::unique_cotaskmem_string properties;
std:wstring query = LR"(
{
"ID" : "",
"Type" : 0,
})";
hr = HcnQueryNProperties([Link](), query.c_str(), &properties,
&errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Escenario: Notificaciones de HCN

Registro y anulación del registro de notificaciones en

todo el servicio
En este ejemplo se muestra cómo usar la API del servicio de red de proceso de host
para registrar y anular el registro de las notificaciones en todo el servicio. Esto permite al
autor de la llamada recibir una notificación (a través de la función de devolución de
llamada que especificó durante el registro) siempre que se haya producido una
operación en todo el servicio, como un nuevo evento de creación de red.

C++

using unique_hcn_callback = wil::unique_any<

HCN_CALLBACK,
decltype(&HcnUnregisterServiceCallback),
HcnUnregisterServiceCallback>;
// Callback handle returned by registration api. Kept at
// global or module scope as it will automatically be
 // unregistered when it goes out of scope.
unique_hcn_callback g_Callback;
// Event notification callback function.
void
CALLBACK
ServiceCallback(
DWORD NotificationType,
void* Context,
HRESULT NotificationStatus,
PCWSTR NotificationData)
{
// Optional client context
UNREFERENCED_PARAMETER(context);
// Reserved for future use
UNREFERENCED_PARAMETER(NotificationStatus);
switch (NotificationType)
{
case HcnNotificationNetworkCreate:
// TODO: UnMarshal the NotificationData
//
// // Notification
// {
// "ID" : Guid,
// "Flags" : <uint32>,
// };
break;
case HcnNotificationNetworkDelete:
// TODO: UnMarshal the NotificationData
break;
Default:
// TODO: handle other events.
break;
}
}
/// Register for service-wide notifications
void RegisterForServiceNotifications()
{
THROW_IF_FAILED(HcnRegisterServiceCallback(
ServiceCallback,
nullptr,
&g_Callback));
}
/// Unregister from service-wide notifications
void UnregisterForServiceNotifications()
{
// As this is a unique_hcn_callback, this will cause
HcnUnregisterServiceCallback to be invoked
g_Callback.reset();
}

Pasos siguientes
Obtenga más información sobre los identificadores de contexto rpc para HCN.
Obtenga más información sobre los esquemas de documento JSON de HCN.
Identificadores de contexto RPC para
HCN
Artículo • 25/01/2023 • Tiempo de lectura: 13 minutos

Se aplica a: Windows Server 2022, Windows Server 2019

HCN_Network
Una red HCN es una entidad que se usa para representar una red de proceso de host y
sus directivas y recursos del sistema asociados. Normalmente, una red HCN puede
incluir:

Un conjunto de metadatos (id., nombre, tipo)

Un conmutador virtual
Un adaptador de red virtual de host (que actúa como puerta de enlace
predeterminada para la red)
Una instancia NAT (si es necesario para el tipo de red)
Un conjunto de grupos de subredes y MAC
Cualquier directiva para toda la red que se va a aplicar (por ejemplo, ACL)

Las entidades de red HCN se representan mediante HCN_NETWORK identificadores de

contexto RPC.

/// Handle to an operation

DECLARE_HANDLE(HCN_NETWORK);
/// Return a list of existing Networks
///
/// \param Query Optionally specifies a JSON document for a query
/// containing properties of the specific Networks to
/// return. By default, all networks are returned.
/// \retval Networks Receives a JSON document with the list of
Networks.
/// \retval ErrorRecord Optional, receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnEnumerateNetworks(
 _In_ PCWSTR Query,
_Outptr_ PWSTR* Networks,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Create a Network
///
/// \param Id Specifies the unique ID for the new Network.
/// \param Settings JSON document specifying the settings of the new
Network.
/// \retval Network Receives a handle to the new network.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnCreateNetwork(
_In_ REFGUID Id,
_In_ PCWSTR Settings,
_Out_ PHCN_NETWORK Network,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Opens a handle to an existing Network.
///
/// \param Id Unique ID of the existing network.
/// \retval Network Receives a handle to the network.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnOpenNetwork(
_In_ REFGUID Id,
_Out_ PHCN_NETWORK Network,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Modify the settings of a Network
///
/// \param Network Handle to a network.
/// \param Settings JSON document specifying the new settings of the
network.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnModifyNetwork(
_In_ HCN_NETWORK Network,
_In_ PCWSTR Settings,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Query Network properties
///
/// \param Network Handle to a network.
/// \param Query Optionally specifies a JSON document for a query
/// containing specific properties of the network
/// return. By default all properties are returned.
/// \retval Properties Receives a JSON document with Network properties.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnQueryNetworkProperties(
_In_ HCN_NETWORK Network,
_In_ PCWSTR Query,
_Outptr_ PWSTR* Properties,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Delete a Network
///
/// \param Id Unique ID of the existing network.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnDeleteNetwork(
_In_ REFGUID Id,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Close a handle to a Network
///
/// \param Network Handle to a network.
///
/// \returns S_OK if successful; HResult error code on failures.
 ///
HRESULT
WINAPI
HcnCloseNetwork(
_In_ HCN_NETWORK Network
);

HCN_Endpoint
Un punto de conexión de HCN es una entidad que se usa para representar un punto de
conexión IP en una red HCN y sus directivas y recursos del sistema asociados.
Normalmente, un punto de conexión de HCN consta de:

Un conjunto de metadatos (id., nombre, identificador de red primario)

Su identidad de red (dirección IP, dirección MAC)
Cualquier directiva específica del punto de conexión que se va a aplicar (ACL,
rutas)

Las entidades de punto de conexión de HCN se representan mediante HCN_ENDPOINT

identificadores de contexto RPC.

/// Handle to an operation

DECLARE_HANDLE(HCN_ENDPOINT);
/// Return a list of existing endpoints
///
/// \param Query Optionally specifies a JSON document for a query
/// containing properties of the specific endpoints
to
/// return. By default all Endpoints are returned.
/// \retval Endpoints Receives a JSON document with the list of
endpoints.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnEnumerateEndpoints(
_In_ PCWSTR Query,
_Outptr_ PWSTR* Endpoints,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Create an Endpoint
///
/// \param Id Specifies the unique ID for the new endpoint.
/// \param Network Handle to the network on which endpoint is to be
created.
/// \param Settings JSON document specifying the settings of the new
endpoint.
/// \retval Endpoint Receives a handle to the new endpoint.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnCreateEndpoint(
_In_ HCN_NETWORK Network,
_In_ REFGUID Id,
_In_ PCWSTR Settings,
_Out_ PHCN_ENDPOINT Endpoint,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Opens a handle to an existing Endpoint.
///
/// \param Id Unique ID of the existing endpoint.
/// \retval Endpoint Receives a handle to the endpoint.
/// \retval ErrorRecord Optional, receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnOpenEndpoint(
_In_ REFGUID Id,
_Out_ PHCN_ENDPOINT Endpoint,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Modify the settings of an Endpoint
///
/// \param Endpoint Handle to an endpoint.
/// \param Settings JSON document specifying the new settings of the
endpoint.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnModifyEndpoint(
_In_ HCN_ENDPOINT Endpoint,
_In_ PCWSTR Settings,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Query Endpoint properties
///
/// \param Endpoint Handle to an endpoint.
/// \param Query Optionally specifies a JSON document for a query
/// containing specific properties of the endpoint
/// return. By default all properties are returned.
/// \retval Properties Receives a JSON document with endpoint
properties.
/// \retval ErrorRecord Optional, receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnQueryEndpointProperties(
_In_ HCN_ENDPOINT Endpoint,
_In_ PCWSTR Query,
_Outptr_ PWSTR* Properties,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Delete an Endpoint
///
/// \param Id Unique ID of the existing endpoint.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnDeleteEndpoint(
_In_ REFGUID Id,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Close a handle to an endpoint
///
/// \param Endpoint Handle to an endpoint.
///
/// \returns S_OK if successful; HResult error code on failures.
///
 HRESULT
WINAPI
HcnCloseEndpoint(
_In_ HCN_ENDPOINT Endpoint
);

HCN_Namespace
Un espacio de nombres HCN es una entidad que se usa para representar un espacio de
nombres de red de proceso de host. Los espacios de nombres permiten tener entornos
de red aislados en un único host, donde cada espacio de nombres tiene sus propias
interfaces de red y tabla de enrutamiento, separadas de otros espacios de nombres.

Las entidades de espacio de nombres HCN se representan mediante HCN_NAMESPACE

identificadores de contexto RPC.

/// Handle to an operation

DECLARE_HANDLE(HCN_NAMESPACE);
/// Return a list of existing namespaces
///
/// \param Query Optionally specifies a JSON document for a query
/// containing properties of the specific namespaces
to
/// return. By default all Namespaces are returned.
/// \retval Namespaces Receives a JSON document with the list of
namespaces.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnEnumerateNamespaces(
_In_ PCWSTR Query,
_Outptr_ PWSTR* Namespaces,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Create a Namespace
///
/// \param Id Specifies the unique ID for the new namespace.
/// \param Settings JSON document specifying the settings of the new
namespace.
/// \retval Namespace Receives a handle to the new namespace.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnCreateNamespace(
_In_ REFGUID Id,
_In_ PCWSTR Settings,
_Out_ PHCN_NAMESPACE Namespace,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Opens a handle to an existing namespace.
///
/// \param Id Unique ID of the existing namespace.
/// \retval Namespace Receives a handle to the namespace.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnOpenNamespace(
_In_ REFGUID Id,
_Out_ PHCN_NAMESPACE Namespace,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Modify the settings of a namespace
///
/// \param Namespace Handle to a namespace.
/// \param Settings JSON document specifying the new settings of the
namespace.
/// \retval ErrorRecord Optional, receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnModifyNamespace(
_In_ HCN_NAMESPACE Namespace,
_In_ PCWSTR Settings,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Query Namespace properties
///
/// \param Namespace Handle to a namespace.
/// \param Query Optionally specifies a JSON document for a query
/// containing specific properties of the namespace
/// return. By default all properties are returned.
/// \retval Properties Receives a JSON document with Namespace
properties.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnQueryNamespaceProperties(
_In_ HCN_NAMESPACE Namespace,
_In_ PCWSTR Query,
_Outptr_ PWSTR* Properties,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Delete a Namespace
///
/// \param Id Unique ID of the existing namespace.
/// \retval ErrorRecord Optional. Receives a JSON document on failure
with extended result
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnDeleteNamespace(
_In_ REFGUID Id,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Close a handle to a Namespace
///
/// \param Namespace Handle to a namespace.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnCloseNamespace(
_In_ HCN_NAMESPACE Namespace
);
HCN_LoadBalancer
Un equilibrador de carga de HCN es una entidad que se usa para representar un
equilibrador de carga de red de proceso host. Los equilibradores de carga permiten
tener puntos de conexión de red de proceso de host con equilibrio de carga. Las
entidades LoadBalancer de HCN se representan mediante HCN_LOADBALANCER
identificadores de contexto RPC.

/// Handle to an operation

DECLARE_HANDLE(HCN_LOADBALANCER);
//////
/// LoadBalancer methods
/// Return a list of existing load balancers
///
/// \param Query Optionally specifies a JSON document for a query
/// containing properties of the specific load
balancers to
/// return. By default all load balancers are
returned.
/// \retval LoadBalancers Receives a JSON document with the list of load
balancers.
/// \retval ErrorRecord Optional. Receives a JSON document with extended
errorCode
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnEnumerateLoadBalancers(
_In_ PCWSTR Query,
_Outptr_ PWSTR* LoadBalancer,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Create a load balancer
///
/// \param Id Specifies the unique ID for the new load
balancer.
/// \param Settings JSON document specifying the settings of the new
load balancer.
/// \retval LoadBalancer Receives a handle to the new LoadBalancer.
/// \retval ErrorRecord Optional. Receives a JSON document with extended
errorCode
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnCreateLoadBalancer(
_In_ REFGUID Id,
_In_ PCWSTR Settings,
_Out_ PHCN_LOADBALANCER LoadBalancer,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Opens a handle to an existing LoadBalancer.
///
/// \param Id Unique ID of the existing load balancer.
/// \retval LoadBalancer Receives a handle to the load balancer.
/// \retval ErrorRecord Optional. Receives a JSON document with extended
errorCode
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnOpenLoadBalancer(
_In_ REFGUID Id,
_Out_ PHCN_LOADBALANCER LoadBalancer,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Modify the settings of a PolcyList
///
/// \param PolcyList Handle to a PolcyList.
/// \param Settings JSON document specifying the new settings of the
PolcyList.
/// \retval ErrorRecord Optional, receives a JSON document with extended
errorCode
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnModifyLoadBalancer(
_In_ HCN_LOADBALANCER LoadBalancer,
_In_ PCWSTR Settings,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Query LoadBalancer properties
///
/// \param LoadBalancer Handle to a load balancer.
/// \param Query Optionally specifies a JSON document for a query
/// containing specific properties of the load
balancer
/// return. By default all properties are returned.
 /// \retval Properties Receives a JSON document with LoadBalancer
properties.
/// \retval ErrorRecord Optional, receives a JSON document with extended
errorCode
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnQueryLoadBalancerProperties(
_In_ HCN_LOADBALANCER LoadBalancer,
_In_ PCWSTR Query,
_Outptr_ PWSTR* Properties,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Delete a LoadBalancer
///
/// \param Id Unique ID of the existing load balancer.
/// \retval ErrorRecord Optional. Receives a JSON document with extended
errorCode
/// information. The caller must release the buffer
using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnDeleteLoadBalancer(
_In_ REFGUID Id,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Close a handle to a LoadBalancer
///
/// \param LoadBalancer Handle to a load balancer.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnCloseLoadBalancer(
_In_ HCN_LOADBALANCER LoadBalancer

HCN_Notification_Callback
Las funciones proporcionan acceso a operaciones en todo el servicio, como las
notificaciones (por ejemplo, la recepción de notificaciones de una nueva creación de
red).
/// Registers a callback function to receive notifications of service-wide
events such as network
/// creations/deletions.
///
/// \param Callback Function pointer to notification callback.
/// \param Context Context pointer.
/// \retval CallbackHandle Receives a handle to a callback registered on
a service.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT WINAPI
HcnRegisterServiceCallback(
_In_ HCN_NOTIFICATION_CALLBACK Callback,
_In_ void* Context,
_Out_ HCN_CALLBACK* CallbackHandle
);
/// Unregisters from service-wide notifications
///
/// \retval CallbackHandle Handle to a callback registered on a service.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT WINAPI
HcnUnregisterServiceCallback(
_In_ HCN_CALLBACK CallbackHandle
);
Esquemas de documentos HCN JSON
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019

Esquema HCN
JSON

// Network
{
"Id" : <string>,
"Owner" : <string>,
"SchemaVersion" : {
"Major" : <uint32>,
"Minor" : <uint32>
},
"Flags" : <enum bit mask>,
// AsString; Values:
// "None" (0),
// "EnableDnsProxy" (1),
// "EnableDhcpServer" (2),
// "IsolateVSwitch" (8)
"Type" : <enum>,
// AsString; Values:
// "NAT" (0),
// "ICS" (1),
// "Transparent" (2)
"Ipams" : [ {
"Type" : <enum>,
// AsString; Values:
// "Static" (0),
// "Dhcp" (1)
"Subnets" : [ {
"IpAddressPrefix" : <ip prefix in CIDR>,
"Policies" : [ {
"Type" : <enum>,
// AsString; Values:
// "VLAN" (0)
"Data" : <any>
} ],
"Routes" : [ {
"NextHop" : <ip address of the next hop gateway>,
"DestinationPrefix" : <ip prefix in cidr>,
"Metric" : <route metric in uint8>,
} ],
} ],
} ],
"Policies" : [{
"Type" : <enum>,
 // AsString; Values:
// "NetAdapterName" (1),
// "InterfaceConstraint" (2)
"Data" : <any>
}],
"Dns" : {
"Suffix" : <local connection specific suffix>,
"Search" : [<list of additional suffixes>],
"ServerList" : [<string>],
"Options" : [<string>],
},
"MacPool" : {
"Ranges" : [ {
"StartMacAddress" : <string>,
"EndMacAddress" : <string>
} ],
},
}

Esquema de punto de conexión de HCN

JSON

// Endpoint
{
"Id" : <string>,
"Owner" : <string>,
"SchemaVersion" : {
"Major" : <uint32>,
"Minor" : <uint32>
},
"Flags" : <enum bit mask>,
// AsString; Values:
// "None" (0),
// "DisableInterComputeCommunication" (2)
"HostComputeNetwork" : <string>,
"MacAddress" : <string>,
"Policies" : [ {
"Type" : <enum>,
// AsString; Values:
// "PortMapping" (0),
// "ACL" (1)
"Data" : <any>
} ],
"Dns" : {
"Suffix" : <local connection specific suffix>,
"Search" : [<list of additional suffixes>],
"ServerList" : [<string>],
"Options" : [<string>],
},
"IPConfigurations" : [ {
"IPAddress" : <ip address>,
 "PrefixLength" : <prefix length uint16>,
} ],
"Routes" : [ {
"NextHop" : <ip address of the next hop gateway>,
"DestinationPrefix" : <ip prefix in cidr>,
"Metric" : <route metric in uint8>,
} ],
}

Esquema de directiva hcn

JSON

// VlanPolicy
{
"Type" : "VLAN",
"IsolationId" : <uint32>,
}
// PortMappingPolicy
{
"Type" : "PortMapping",
"Protocol" : <enum>,
// AsString; Values:
// "Unknown" (0),
// "ICMPv4" (1),
// "IGMP" (2),
// "TCP" (6),
// "UDP" (17),
// "ICMPv6" (58)
"InternalPort" : <uint16>,
"ExternalPort" : <uint16>,
}

Esquema del equilibrador de carga HCN

JSON

// Host Compute LoadBalancer

{
"Id" : <string>,
"Owner" : <string>,
"SchemaVersion" : {
"Major" : <uint32>,
"Minor" : <uint32>
},
"Flags" : <enum bit mask>,
// AsString; Values:
// "None" (0),
// "EnableDirectServerReturn" (1)
 // "EnableInternalLoadBalancer" (2)
"HostComputeEndpoints" : [<Host compute Endpoint id>],
"VirtualIPs" : [<Virtual IpAddress>],
"PortMappings" : [ {
"Type" : "PortMapping",
"Protocol" : <enum>,
// AsString; Values:
// "Unknown" (0),
// "ICMPv4" (1),
// "IGMP" (2),
// "TCP" (6),
// "UDP" (17),
// "ICMPv6" (58)
"InternalPort" : <uint16>,
"ExternalPort" : <uint16>,
} ],
"Policies" : [ {
"Type" : <enum>,
// AsString; Values:
// "SourceVirtualIp" (0),
"Data" : <any>
} ],
}

Esquema de espacio de nombres HCN

JSON

// Namespace
{
"Id" : <string>,
"Owner" : <string>,
"SchemaVersion" : {
"Major" : <uint32>,
"Minor" : <uint32>
},
"NamespaceId" : <uint32>,
"NamespaceGuid" : <guid>,
"Type" : <enum>,
// AsString; Values:
// "Host" (0),
// "HostDefault" (1),
// "Guest" (2),
// "GuestDefault" (3)
"Resources" : [ {
"Type" : <enum>,
// AsString; Values:
// "Container" (0),
// "Endpoint" (1)
"Data" : <any>
} ],
}
Esquema de notificación de HCN
JSON

// Notification
{
"ID" : Guid,
"Flags" : <uint32>,
};

Esquema de error de resultado

JSON

// ErrorSchema
{
"ErrorCode" : <uint32>,
"Error" : <string>,
"Success" : <bool>,
}
Ejemplo de código generado C#
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019

C#

/*
* HCN API
*
* No description provided (generated by Swagger Codegen
[Link]
*
* OpenAPI spec version: 2.1
*
* Generated by: [Link]
*/
using System;
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using SwaggerDateConverter = [Link];
namespace [Link]
{
/// <summary>
/// Ipam
/// </summary>
[DataContract]
public partial class Ipam : IEquatable<Ipam>, IValidatableObject
{
/// <summary>
/// Type : dhcp
/// </summary>
/// <value> Type : dhcp</value>
[JsonConverter(typeof(StringEnumConverter))]
public enum TypeEnum
{
/// <summary>
/// Enum Static for value: Static
/// </summary>
[EnumMember(Value = "Static")]
Static = 1,
/// <summary>
 /// Enum Dhcp for value: Dhcp
/// </summary>
[EnumMember(Value = "Dhcp")]
Dhcp = 2
}
/// <summary>
/// Type : dhcp
/// </summary>
/// <value> Type : dhcp</value>
[DataMember(Name="Type", EmitDefaultValue=false)]
public TypeEnum? Type { get; set; }
/// <summary>
/// Initializes a new instance of the <see cref="Ipam" /> class.
/// </summary>
/// <param name="Type"> Type : dhcp.</param>
/// <param name="Subnets">Subnets.</param>
public Ipam(TypeEnum? Type = default(TypeEnum?), List<Subnet>
Subnets = default(List<Subnet>))
{
[Link] = Type;
[Link] = Subnets;
}
/// <summary>
/// Gets or Sets Subnets
/// </summary>
[DataMember(Name="Subnets", EmitDefaultValue=false)]
public List<Subnet> Subnets { get; set; }
/// <summary>
/// Returns the string presentation of the object
/// </summary>
/// <returns>String presentation of the object</returns>
public override string ToString()
{
var sb = new StringBuilder();
[Link]("class Ipam {\n");
[Link](" Type: ").Append(Type).Append("\n");
[Link](" Subnets: ").Append(Subnets).Append("\n");
[Link]("}\n");
return [Link]();
}
/// <summary>
/// Returns the JSON string presentation of the object
/// </summary>
/// <returns>JSON string presentation of the object</returns>
public string ToJson()
{
return [Link](this, [Link]);
}
/// <summary>
/// Returns true if objects are equal
/// </summary>
/// <param name="input">Object to be compared</param>
/// <returns>Boolean</returns>
public override bool Equals(object input)
{
 return [Link](input as Ipam);
}
/// <summary>
/// Returns true if Ipam instances are equal
/// </summary>
/// <param name="input">Instance of Ipam to be compared</param>
/// <returns>Boolean</returns>
public bool Equals(Ipam input)
{
if (input == null)
return false;
return
(
[Link] == [Link] ||
([Link] != null &&
[Link]([Link]))
) &&
(
[Link] == [Link] ||
[Link] != null &&
[Link]([Link])
);
}
/// <summary>
/// Gets the hash code
/// </summary>
/// <returns>Hash code</returns>
public override int GetHashCode()
{
unchecked // Overflow is fine, just wrap
{
int hashCode = 41;
if ([Link] != null)
hashCode = hashCode * 59 + [Link]();
if ([Link] != null)
hashCode = hashCode * 59 + [Link]();
return hashCode;
}
}
/// <summary>
/// To validate all properties of the instance
/// </summary>
/// <param name="validationContext">Validation context</param>
/// <returns>Validation Result</returns>
IEnumerable<[Link]>
[Link](ValidationContext validationContext)
{
yield break;
}
}
}
/*
* HCN API
*
* No description provided (generated by Swagger Codegen
[Link]
*
* OpenAPI spec version: 2.1
*
* Generated by: [Link]
*/
using System;
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using [Link];
using SwaggerDateConverter = [Link];
namespace [Link]
{
/// <summary>
/// Subnet
/// </summary>
[DataContract]
public partial class Subnet : IEquatable<Subnet>, IValidatableObject
{
/// <summary>
/// Initializes a new instance of the <see cref="Subnet" /> class.
/// </summary>
/// <param name="ID">ID.</param>
/// <param name="IpAddressPrefix">IpAddressPrefix.</param>
/// <param name="Policies">Policies.</param>
/// <param name="Routes">Routes.</param>
public Subnet(string ID = default(string), string IpAddressPrefix =
default(string), List<SubnetPolicy> Policies = default(List<SubnetPolicy>),
List<Route> Routes = default(List<Route>))
{
[Link] = ID;
[Link] = IpAddressPrefix;
[Link] = Policies;
[Link] = Routes;
}
/// <summary>
/// Gets or Sets ID
/// </summary>
[DataMember(Name="ID", EmitDefaultValue=false)]
public string ID { get; set; }
/// <summary>
/// Gets or Sets IpAddressPrefix
/// </summary>
[DataMember(Name="IpAddressPrefix", EmitDefaultValue=false)]
public string IpAddressPrefix { get; set; }
/// <summary>
/// Gets or Sets Policies
 /// </summary>
[DataMember(Name="Policies", EmitDefaultValue=false)]
public List<SubnetPolicy> Policies { get; set; }
/// <summary>
/// Gets or Sets Routes
/// </summary>
[DataMember(Name="Routes", EmitDefaultValue=false)]
public List<Route> Routes { get; set; }
/// <summary>
/// Returns the string presentation of the object
/// </summary>
/// <returns>String presentation of the object</returns>
public override string ToString()
{
var sb = new StringBuilder();
[Link]("class Subnet {\n");
[Link](" ID: ").Append(ID).Append("\n");
[Link](" IpAddressPrefix:
").Append(IpAddressPrefix).Append("\n");
[Link](" Policies: ").Append(Policies).Append("\n");
[Link](" Routes: ").Append(Routes).Append("\n");
[Link]("}\n");
return [Link]();
}
/// <summary>
/// Returns the JSON string presentation of the object
/// </summary>
/// <returns>JSON string presentation of the object</returns>
public string ToJson()
{
return [Link](this, [Link]);
}
/// <summary>
/// Returns true if objects are equal
/// </summary>
/// <param name="input">Object to be compared</param>
/// <returns>Boolean</returns>
public override bool Equals(object input)
{
return [Link](input as Subnet);
}
/// <summary>
/// Returns true if Subnet instances are equal
/// </summary>
/// <param name="input">Instance of Subnet to be compared</param>
/// <returns>Boolean</returns>
public bool Equals(Subnet input)
{
if (input == null)
return false;
return
(
[Link] == [Link] ||
([Link] != null &&
[Link]([Link]))
 ) &&
(
[Link] == [Link] ||
([Link] != null &&
[Link]([Link]))
) &&
(
[Link] == [Link] ||
[Link] != null &&
[Link]([Link])
) &&
(
[Link] == [Link] ||
[Link] != null &&
[Link]([Link])
);
}
/// <summary>
/// Gets the hash code
/// </summary>
/// <returns>Hash code</returns>
public override int GetHashCode()
{
unchecked // Overflow is fine, just wrap
{
int hashCode = 41;
if ([Link] != null)
hashCode = hashCode * 59 + [Link]();
if ([Link] != null)
hashCode = hashCode * 59 +
[Link]();
if ([Link] != null)
hashCode = hashCode * 59 + [Link]();
if ([Link] != null)
hashCode = hashCode * 59 + [Link]();
return hashCode;
}
}
/// <summary>
/// To validate all properties of the instance
/// </summary>
/// <param name="validationContext">Validation context</param>
/// <returns>Validation Result</returns>
IEnumerable<[Link]>
[Link](ValidationContext validationContext)
{
// ID (string) pattern
Regex regexID = new Regex(@"^[0-9A-Fa-f]{8}-([0-9A-Fa-f]{4}-){3}
[0-9A-Fa-f]{12}$", [Link]);
if (false == [Link]([Link]).Success)
{
yield return new
[Link]("Invalid value for
ID, must match a pattern of " + regexID, new [] { "ID" });
}
 yield break;
}
}
}
Ejemplo de código generado Go
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019

Go

/*
* HCN API
*
* No description provided (generated by Swagger Codegen
[Link]
*
* API version: 2.1
* Generated by: Swagger Codegen ([Link]
[Link])
*/
package swagger
type Ipam struct {
// Type : dhcp
Type_ string `json:"Type,omitempty"`
Subnets []Subnet `json:"Subnets,omitempty"`
}
/*
* HCN API
*
* No description provided (generated by Swagger Codegen
[Link]
*
* API version: 2.1
* Generated by: Swagger Codegen ([Link]
[Link])
*/
package swagger
type Subnet struct {
ID string `json:"ID,omitempty"`
IpAddressPrefix string `json:"IpAddressPrefix,omitempty"`
Policies []SubnetPolicy `json:"Policies,omitempty"`
Routes []Route `json:"Routes,omitempty"`
}
Conmutador virtual de Hyper-V
Artículo • 21/12/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema se proporciona información general sobre el conmutador virtual de Hyper-

V, que proporciona la capacidad de conectar máquinas virtuales (VM) a redes externas
al host de Hyper-V, incluida la intranet de la organización e Internet.

También puede conectarse a redes virtuales en el servidor que ejecuta Hyper-V al

implementar redes definidas por software (SDN).

７ Nota

Además de este tema, está disponible la siguiente documentación del conmutador

virtual de Hyper-V.

Administración de conmutador virtual de Hyper-V

Acceso directo a memoria remota (RDMA) y Switch Embedded Teaming
(SET)
Cmdlets del equipo del conmutador de red en Windows PowerShell
Novedades de VMM 2016
Configurar el tejido de red de VMM
Foro de Hyper-V
Hyper-V: la extensión de conmutador virtual de WFP debe habilitarse si así
lo requieren las extensiones de terceros

Para obtener más información sobre otras tecnologías de red, consulte Redes en
Windows Server 2016.

El conmutador virtual de Hyper-V es un conmutador de red Ethernet de nivel 2 basado

en software que está disponible en el Administrador de Hyper-V al instalar el rol de
servidor de Hyper-V.

El conmutador virtual de Hyper-V incluye funcionalidades administradas y extensibles

mediante programación para conectar máquinas virtuales a redes virtuales y a la red
física. Además el conmutador virtual de Hyper-V exige la aplicación de la directiva en los
niveles de servicio, aislamiento y seguridad.
 ７ Nota

El conmutador virtual de Hyper-V solo admite Ethernet y no es compatible con

otras tecnologías de red de área local (LAN) por cable, como Infiniband y Canal de
fibra.

El conmutador virtual de Hyper-V incluye funcionalidades de aislamiento de inquilinos,

modelado del tráfico, protección contra máquinas virtuales malintencionadas y solución
de problemas simplificada.

Con compatibilidad integrada con controladores de filtro de especificación de interfaz

de dispositivo de red (NDIS) y controladores de llamada de plataforma de filtrado de
Windows (PMA), el conmutador virtual de Hyper-V permite a los proveedores de
software independientes (ISV) crear complementos extensibles, denominados
extensiones de conmutador virtual, que pueden proporcionar funcionalidades de
seguridad y redes mejoradas. Las extensiones de conmutador virtual que agregue se
enumerarán en la característica del Administrador de conmutadores virtuales del
Administrador de Hyper-V.

En la ilustración siguiente, una máquina virtual tiene una NIC virtual que está conectada
al conmutador virtual de Hyper-V a través de un puerto de conmutador.

Las funcionalidades del conmutador virtual de Hyper-V proporcionan más opciones

para aplicar aislamiento de inquilinos, dar forma y controlar el tráfico de red y emplear
medidas de protección contra máquinas virtuales malintencionadas.

７ Nota

En Windows Server 2016, una máquina virtual con una NIC virtual muestra con
precisión el rendimiento máximo de la NIC virtual. Para ver la velocidad de NIC
virtual en Conexiones de red, haga clic con el botón derecho en el icono de NIC
 virtual deseado y, a continuación, haga clic en Estado. Se abre el cuadro de diálogo
Estado de la NIC virtual. En Conexión, el valor de Speed coincide con la velocidad
de la NIC física instalada en el servidor.

Usos para el conmutador virtual de Hyper-V

A continuación se muestran algunos escenarios de casos de uso para el conmutador
virtual de Hyper-V.

Mostrar estadísticas: un desarrollador de un proveedor de nube hospedado

implementa un paquete de administración que muestra el estado actual del
conmutador virtual de Hyper-V. El paquete de administración puede consultar las
funcionalidades actuales de todo el conmutador, las opciones de configuración y las
estadísticas de redes de puertos individuales mediante WMI. Se muestra el estado del
conmutador para proporcionar a los administradores una vista rápida de este.

Seguimiento de recursos: una empresa de hospedaje vende servicios de hospedaje a

precios según el nivel de pertenencia. Los distintos niveles de pertenencia incluyen
niveles de rendimiento de red diferentes. El administrador asigna los recursos para
cumplir con los contratos de nivel de servicio de modo tal que la disponibilidad de la
red sea equilibrada. El administrador realiza un seguimiento de la información mediante
programación, como el uso actual del ancho de banda asignado y el número de canales
de cola de máquinas virtuales (VM) o IOV asignadas. El mismo programa también
registra mediante programación los recursos que se encuentran en uso, además de los
recursos por VM asignados para recursos o seguimiento de entradas dobles.

Administrar el orden de las extensiones de conmutador: una empresa ha instalado

extensiones en su host de Hyper-V para supervisar el tráfico y notificar la detección de
intrusiones. Durante el mantenimiento, es posible que, al actualizar algunas extensiones,
se modifique su orden. Se ejecuta un programa de script simple para volver a ordenar
las extensiones después de las actualizaciones.

La extensión de reenvío administra el identificador de VLAN: una importante empresa

de conmutadores está creando una extensión de reenvío que aplica todas las directivas
para las redes. Uno de los elementos que se administran son los identificadores de red
de área local virtual (VLAN). El conmutador virtual cede el control de la VLAN a una
extensión de reenvío. La instalación de la empresa switch llama mediante programación
a una interfaz de programación de aplicaciones (API) de Instrumental de administración
de Windows (WMI) que activa la transparencia, lo que indica al conmutador virtual de
Hyper-V que pase y no realice ninguna acción en las etiquetas VLAN.
Funcionalidad de conmutador virtual de Hyper-
V
A continuación, se enumeran algunas de las características principales incluidas en el
conmutador virtual de Hyper-V:

Protección contra intoxicación ARP/ND (suplantación de identidad): proporciona

protección contra una máquina virtual malintencionada mediante la suplantación
del Protocolo de resolución de direcciones (ARP) para robar direcciones IP de otras
máquinas virtuales. Proporciona protección contra ataques que pueden iniciarse
para IPv6 mediante la suplantación de detección de equipos cercanos (ND).

Protección de DHCP Guard: protege contra una máquina virtual malintencionada

que se representa como un servidor del Protocolo de configuración dinámica de
host (DHCP) para ataques de tipo "man in the middle".

ACL de puerto: proporciona filtrado de tráfico en función de los intervalos o

direcciones de protocolo de Internet (MAC) o de media Access Control (MAC), lo
que le permite configurar el aislamiento de red virtual.

Modo de tronco a una máquina virtual: permite a los administradores configurar

una máquina virtual específica como una aplicación virtual y, a continuación, dirigir
el tráfico desde varias VLAN a esa máquina virtual.

Supervisión del tráfico de red: permite a los administradores revisar el tráfico que
atraviesa el conmutador de red.

VLAN aislado (privado): permite a los administradores separar el tráfico en varias

vlan para establecer con más facilidad comunidades de inquilinos aisladas.

A continuación, se proporciona una lista de las funcionalidades que aumentan la

facilidad de uso del conmutador virtual de Hyper-V:

Compatibilidad con el límite de ancho de banda y la ráfaga: el ancho de banda

mínimo garantiza la cantidad de ancho de banda reservado. El ancho de banda
máximo limita la cantidad de ancho de banda que puede consumir una VM.

Compatibilidad explícita con el marcado de notificación de congestión (ECN): el

marcado ECN, también conocido como Data CenterTCP (DCTCP), permite que el
conmutador físico y el sistema operativo regulen el flujo de tráfico de forma que
los recursos de búfer del conmutador no estén inundados, lo que da lugar a un
mayor rendimiento del tráfico.
Diagnósticos: los diagnósticos permiten un seguimiento y supervisión sencillos de
eventos y paquetes a través del conmutador virtual.
Administración de direcciones IP (IPAM)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Administración de direcciones IP (IPAM) es un conjunto integrado de herramientas para

permitir el planeamiento, la implementación, la administración y la supervisión de un
extremo a otro de la infraestructura de direcciones IP, con una experiencia de usuario
completa. IPAM detecta automáticamente los servidores con infraestructura de
direcciones IP y los servidores del Sistema de nombres de dominio (DNS) de la red y
permite administrarlos desde una interfaz central.

７ Nota

Además de este tema, está disponible IPAM siguiente contenido.

Novedades de IPAM
Administrar IPAM
Administración de direcciones IP (IPAM) cmdlets de servidor en Windows
PowerShell
Novedades de IPAM
Artículo • 21/12/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema se describe la Administración de direcciones IP (IPAM) nueva o modificada

en Windows Server 2016.

IPAM proporciona funcionalidades administrativas y de supervisión altamente

personalizables para la dirección IP y la infraestructura DNS en una red Enterprise o
proveedor de servicios en la nube (CSP). Puede supervisar, auditar y administrar
servidores que ejecutan el Protocolo de configuración dinámica de host (DHCP) y el
Sistema de nombres de dominio (DNS) mediante IPAM.

Actualizaciones en IPAM Server

A continuación se incluyen las características nuevas y mejoradas para IPAM en
Windows Server 2016.

Característica/función Nueva o Descripción

mejorada

Administración Se ha IPAM funcionalidades se mejoran para escenarios como el

mejorada de mejorado control de subredes IPv4 /32 e IPv6 /128 y la búsqueda de
direcciones IP subredes e intervalos de direcciones IP gratuitos en un
bloque de direcciones IP.

Administración Nuevo IPAM admite el registro de recursos DNS, el reenviador

mejorada del servicio condicional y la administración de zonas DNS para
DNS servidores DNS unidos a Active Directory integrados y con
respaldo de archivos.

Administración Se ha Se habilitan varias experiencias nuevas y operaciones

integrada de DNS, mejorado integradas de administración del ciclo de vida, como la
DHCP y dirección IP visualización de todos los registros de recursos DNS que
(DDI) pertenecen a una dirección IP, el inventario automatizado
de direcciones IP basadas en registros de recursos DNS y la
administración del ciclo de vida de las direcciones IP para
las operaciones DNS y DHCP.
 Característica/función Nueva o Descripción
mejorada

Compatibilidad con Nuevo Puede usar IPAM para administrar los servidores DNS y
varios Active Directory DHCP de varios bosques de Active Directory cuando hay
bosque una relación de confianza de dos direcciones entre el
bosque donde está instalado IPAM y cada uno de los
bosques remotos.

Purgar datos de uso Nuevo Ahora puede reducir el tamaño IPAM base de datos
mediante la purga de los datos de uso de direcciones IP
anteriores a una fecha especificada.

Windows PowerShell Nuevo Puede usar Windows PowerShell para establecer ámbitos
compatibilidad con de acceso en IPAM objetos.
roles basados en
Access Control

Administración mejorada de direcciones IP

Las siguientes características mejoran las funcionalidades IPAM administración de
direcciones.

７ Nota

Para obtener la IPAM Windows PowerShell de comandos, vea cmdlets

Administración de direcciones IP (IPAM) Server en Windows PowerShell.

Compatibilidad con subredes /31, /32 y /128

IPAM en Windows Server 2016 ahora admite subredes /31, /32 y /128. Por ejemplo,
puede ser necesaria una subred de dos direcciones (/31 IPv4) para un vínculo de punto
a punto entre conmutadores. Además, algunos modificadores pueden requerir
direcciones de bucle bucle único (/32 para IPv4, /128 para IPv6).

Buscar subredes gratuitas con Find-IpamFreeSubnet

Este comando devuelve subredes que están disponibles para la asignación, dado un
bloque IP, la longitud del prefijo y el número de subredes solicitadas.

Si el número de subredes disponibles es menor que el número de subredes solicitadas,

las subredes disponibles se devuelven con una advertencia que indica que el número
disponible es menor que el número solicitado.
 ７ Nota

Esta función no asigna realmente las subredes, solo informa de su disponibilidad.

Sin embargo, la salida del cmdlet se puede canalizar al comando Add-IpamSubnet
para crear la subred.

Para obtener más información, vea Find-IpamFreeSubnet.

Buscar intervalos de direcciones gratuitos con Find-IpamFreeRange

Este nuevo comando devuelve los intervalos de direcciones IP disponibles según una
subred IP, el número de direcciones necesarias en el intervalo y el número de intervalos
solicitados.

El comando busca una serie continua de direcciones IP sin asignar que coincidan con el
número de direcciones solicitadas. El proceso se repite hasta que se encuentra el
número solicitado de intervalos o hasta que no hay más intervalos de direcciones
disponibles.

７ Nota

Esta función no asigna realmente los intervalos, solo informa de su disponibilidad.

Sin embargo, la salida del cmdlet se puede canalizar al comando Add-IpamRange
para crear el intervalo.

Para obtener más información, vea Find-IpamFreeRange.

Administración mejorada del servicio DNS

IPAM en Windows Server 2016 ahora admite la detección de servidores DNS unidos a
dominio basados en archivos en un bosque de Active Directory en el que IPAM se está
ejecutando.

Además, se han agregado las siguientes funciones DNS:

Zonas DNS y recopilación de registros de recursos (distintos de los que pertenecen

a DNSSEC) de servidores DNS que ejecutan Windows Server 2008 o posterior.

Configure (crear, modificar y eliminar) propiedades y operaciones en todos los

tipos de registros de recursos (distintos de los que pertenecen a DNSSEC).
 Configure (crear, modificar, eliminar) propiedades y operaciones en todos los tipos
de zonas DNS, incluidas las secundarias principales y las zonas de código auxiliar).

Tareas desencadenadas en zonas secundarias y de código auxiliar,

independientemente de si son zonas de búsqueda inversa o hacia delante. Por
ejemplo, tareas como Transferir desde maestro oTransferir nueva copia de zona
desde maestro.

Control de acceso basado en rol para la configuración dns admitida (registros DNS
y zonas DNS).

Recopilación y configuración de reenviadores condicionales (crear, eliminar, editar).

Administración integrada de DNS, DHCP y dirección IP

(DDI)
Al ver una dirección IP en el inventario de direcciones IP, tiene la opción en la vista
detalles para ver todos los registros de recursos DNS asociados a la dirección IP.

Como parte de la colección de registros de recursos DNS, IPAM recopila los registros
PTR para las zonas de búsqueda inversa de DNS. Para todas las zonas de búsqueda
inversa que están asignadas a cualquier intervalo de direcciones IP, IPAM crea los
registros de dirección IP para todos los registros PTR que pertenecen a esa zona en el
intervalo de direcciones IP asignado correspondiente. Si la dirección IP ya existe, el
registro PTR simplemente está asociado a esa dirección IP. Las direcciones IP no se
crean automáticamente si la zona de búsqueda inversa no está asignada a ningún
intervalo de direcciones IP.

Cuando se crea un registro PTR en una zona de búsqueda inversa mediante IPAM, el
inventario de direcciones IP se actualiza de la misma manera que se describió
anteriormente. Durante la recopilación posterior, dado que la dirección IP ya existirá en
el sistema, el registro PTR simplemente se asignará a esa dirección IP.

Compatibilidad con varios Active Directory bosque

En Windows Server 2012 R2, IPAM detectar y administrar servidores DNS y DHCP que
pertenecen al mismo bosque de Active Directory que el IPAM servidor. Ahora puede
administrar servidores DNS y DHCP que pertenecen a un bosque de AD diferente
cuando tiene una relación de confianza de dos direcciones con el bosque donde está
instalado el servidor IPAM servidor. Puede ir al cuadro de diálogo Configurar detección
de servidores y agregar dominios desde los otros bosques de confianza que quiera
administrar. Una vez detectados los servidores, la experiencia de administración es la
misma que para los servidores que pertenecen al mismo bosque donde IPAM está
instalado.

Para obtener más información, vea Administrar recursos en varios Active Directory
bosques.

Purgado de datos de utilización

Purgar datos de uso permite reducir el tamaño de la base IPAM de datos mediante la
eliminación de datos antiguos de uso de direcciones IP. Para realizar la eliminación de
datos, especifique una fecha y IPAM elimina todas las entradas de base de datos que
sean anteriores o iguales a la fecha que proporcione.

Para obtener más información, vea Purgar datos de uso.

Windows PowerShell compatibilidad con roles basados

en Access Control
Ahora puede usar Windows PowerShell para configurar el rol basado en Access Control.
Puede usar comandos Windows PowerShell para recuperar objetos DNS y DHCP en
IPAM y cambiar sus ámbitos de acceso. Por este problema, puede escribir scripts de
Windows PowerShell para asignar ámbitos de acceso a los objetos siguientes.

Espacio de direcciones IP

Bloque de direcciones IP

Subredes de direcciones IP

Intervalos de direcciones IP

Servidores DNS

Zonas DNS

Reenviadores condicionales DNS

Registros de recursos DNS

Servidores DHCP

Superámbitos DHCP

Ámbitos DHCP
Para obtener más información, vea Manage Role Based Access Control with Windows
PowerShell and Administración de direcciones IP (IPAM) Server Cmdlets in Windows
PowerShell (Administrar los cmdlets de servidor basados en rol con Administración de
direcciones IP (IPAM) en Windows PowerShell.
Administrar IPAM
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En esta guía se proporciona información de administración y solución de problemas

Administración de direcciones IP (IPAM) de Windows Server 2016.

En Windows Server 2016, IPAM admite el registro de recursos DNS, el reenviador

condicional y la administración de zonas DNS para servidores DNS unidos Active
Directory dominio y servidores DNS con copia de seguridad de archivos. Además, IPAM
control de acceso basado en rol y toda la funcionalidad de versiones anteriores de la
tecnología.

Esta guía incluye las siguientes secciones:

Administración de registros de recursos DNS

Administración de zonas DNS

Administración de recursos en varios Active Directory bosques

Purgar datos de uso

Rol basado en Access Control

Consulte también
Administración de direcciones IP (IPAM)
Administración de registros de recursos
DNS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema se proporciona información sobre cómo administrar registros de recursos

DNS mediante IPAM.

７ Nota

Además de este tema, los siguientes temas de administración de registros de

recursos DNS están disponibles en esta sección.

Adición de un registro de recursos DNS

Eliminación de registros de recursos DNS
Filtrar la vista de registros de recursos DNS
Visualización de registros de recursos DNS para una dirección IP específica

Introducción a la administración de registros

de recursos
Al implementar IPAM en Windows Server 2016, puede realizar la detección de servidores
para agregar servidores DHCP y DNS a la consola de administración del servidor de
IPAM. A continuación, el servidor IPAM recopila dinámicamente los datos DNS cada seis
horas de los servidores DNS que está configurado para administrar. IPAM mantiene una
base de datos local donde almacena estos datos DNS. IPAM le proporciona una
notificación del día y la hora en que se recopilaron los datos del servidor, así como
indicarle el día siguiente y la hora en que se producirá la recopilación de datos de los
servidores DNS.

La barra de estado amarilla de la ilustración siguiente muestra la ubicación de la interfaz

de usuario de IPAM notificaciones.
Los datos DNS recopilados incluyen información de registro de recursos y zona DNS.
Puede configurar IPAM para recopilar información de zona del servidor DNS preferido.
IPAM recopila zonas basadas en archivos y Active Directory.

７ Nota

IPAM recopila datos únicamente de servidores DNS de Microsoft unidos a un

dominio. Los servidores DNS de terceros y los servidores no unidos a un dominio
no son compatibles con IPAM.

A continuación se muestra una lista de los tipos de registros de recursos DNS

recopilados por IPAM.

Base de datos AFS

Dirección ATM

CNAME

DHCID

DNAME

Host A o AAAA

Información del host

ISDN

MX

Servidores de nombres

Puntero (PTR)

Persona responsable

Enrutar a través

Ubicación del servicio

SOA

SRV

Texto
 Servicios conocidos

WINS

WINS-R

X.25

En Windows Server 2016, IPAM proporciona integración entre el inventario de

direcciones IP, las zonas DNS y los registros de recursos DNS:

Puede usar IPAM para crear automáticamente un inventario de direcciones IP a

partir de registros de recursos DNS.

Puede crear manualmente un inventario de direcciones IP a partir de registros de

recursos DNS A y AAAA.

Puede ver los registros de recursos DNS para una zona DNS específica y filtrar los
registros en función del tipo, la dirección IP, los datos del registro de recursos y
otras opciones de filtrado.

IPAM crea automáticamente una asignación entre los intervalos de direcciones IP y

las zonas de búsqueda inversa de DNS.

IPAM crea direcciones IP para los registros PTR presentes en la zona de búsqueda
inversa y que se incluyen en ese intervalo de direcciones IP. También puede
modificar manualmente esta asignación si es necesario.

IPAM permite realizar las siguientes operaciones en los registros de recursos desde la
consola de IPAM.

Creación de registros de recursos DNS

Edición de registros de recursos DNS

Eliminación de registros de recursos DNS

Creación de registros de recursos asociados

IPAM registra automáticamente todos los cambios de configuración de DNS que realice
con la consola de IPAM.

Consulte también
Administrar IPAM
Adición de un registro de recursos DNS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para agregar uno o varios registros de recursos DNS nuevos
mediante la consola de cliente de IPAM.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Para agregar un registro de recursos DNS

1. En Administrador del servidor, haga clic en IPAM. Aparece la consola de cliente
IPAM.

2. En el panel de navegación, en MONITOR Y ADMINISTRACIÓN, haga clic en Zonas

DNS. El panel de navegación se divide en un panel de navegación superior y en un
panel de navegación inferior.

3. En el panel de navegación inferior, haga clic en Búsqueda directa. Todas las zonas
de búsqueda directa de DNS administradas IPAM se muestran en los resultados de
búsqueda del panel de visualización. Haga clic con el botón derecho en la zona
donde desea agregar un registro de recursos y, a continuación, haga clic en
Agregar registro de recursos DNS.
4. Se abre el cuadro de diálogo Agregar registros de recursos DNS . En Propiedades
del registro de recursos, haga clic en Servidor DNS y seleccione el servidor DNS
en el que desea agregar uno o varios registros de recursos nuevos. En Configurar
registros de recursos DNS, haga clic en Nuevo.

5. El cuadro de diálogo se expande para mostrar nuevo registro de recursos. Haga

clic en Tipo de registro de recurso.
6. Se muestra la lista de tipos de registros de recursos. Haga clic en el tipo de registro
de recursos que desea agregar.
7. En Nuevo registro de recursos, en Nombre, escriba un nombre de registro de
recursos. En Dirección IP, escriba una dirección IP y, a continuación, seleccione las
propiedades del registro de recursos adecuadas para la implementación. Haga clic
en Agregar registro de recursos.
8. Si no desea crear registros de recursos adicionales, haga clic en Aceptar. Si desea
crear registros de recursos adicionales, haga clic en Nuevo.
 9. El cuadro de diálogo se expande para mostrar nuevo registro de recursos. Haga
clic en Tipo de registro de recurso. Se muestra la lista de tipos de registros de
recursos. Haga clic en el tipo de registro de recursos que desea agregar.

10. En Nuevo registro de recursos, en Nombre, escriba un nombre de registro de

recursos. En Dirección IP, escriba una dirección IP y, a continuación, seleccione las
propiedades del registro de recursos adecuadas para la implementación. Haga clic
en Agregar registro de recursos.

11. Si desea agregar más registros de recursos, repita el proceso para crear registros.
Cuando haya terminado de crear nuevos registros de recursos, haga clic en
Aplicar.
12. El cuadro de diálogo Agregar registro de recursos muestra un resumen de
registros de recursos mientras IPAM crea los registros de recursos en el servidor
DNS especificado. Cuando los registros se crean correctamente, el estado del
registro es Correcto.

13. Haga clic en OK.

Consulte también
Administración de registros de recursosDNSAdministración de IPAM
Eliminación de registros de recursos
DNS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para eliminar uno o varios registros de recursos DNS mediante la
consola de cliente de IPAM.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Para eliminar registros de recursos DNS

1. En Administrador del servidor, haga clic en IPAM. Aparece la consola de cliente
IPAM.

2. En el panel de navegación, en MONITOR Y ADMINISTRACIÓN, haga clic en Zonas

DNS. El panel de navegación se divide en un panel de navegación superior y en un
panel de navegación inferior.

3. Haga clic para expandir Búsqueda directa y el dominio donde se encuentran los
registros de zona y recursos que desea eliminar. Haga clic en la zona y, en el panel
de presentación, haga clic en Vista actual. Haga clic en Registros de recursos.

4. En el panel de presentación, busque y seleccione los registros de recursos que

desea eliminar.
5. Haga clic con el botón derecho en los registros seleccionados y, a continuación,
haga clic en Eliminar registro de recursos DNS.

6. Se abre el cuadro de diálogo Eliminar registro de recursos DNS . Compruebe que

está seleccionado el servidor DNS correcto. Si no es así, haga clic en Servidor DNS
y seleccione el servidor desde el que desea eliminar los registros de recursos. Haga
clic en OK. IPAM elimina los registros de recursos del servidor DNS.
Consulte también
Administración de registros de recursosDNSAdministrar IPAM
Filtrado de la vista de registros de
recursos DNS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para filtrar la vista de los registros de recursos DNS en la consola
de cliente de IPAM.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Para filtrar la vista de registros de recursos DNS

1. En Administrador del servidor, haga clic en IPAM. Aparece la consola de cliente
IPAM.

2. En el panel de navegación, en MONITOR Y ADMINISTRACIÓN, haga clic en Zonas

DNS. El panel de navegación se divide en un panel de navegación superior y en un
panel de navegación inferior.

3. En el panel de navegación inferior, haga clic en Búsqueda directa. Todas las zonas
de búsqueda directa de DNS administradas IPAM se muestran en los resultados de
búsqueda del panel de visualización.

4. Haga clic en la zona cuyos registros desea ver y filtrar.

5. En el panel de presentación, haga clic en Vista actual y, a continuación, haga clic

en Registros de recursos. Los registros de recursos de la zona se muestran en el
panel de presentación.

6. En el panel de presentación, haga clic en Agregar criterios.

7. Seleccione un criterio en la lista desplegable. Por ejemplo, si desea ver un tipo de
registro específico, haga clic en Tipo de registro.

8. Haga clic en Agregar.

9. El tipo de registro se agrega como parámetro de búsqueda. Escriba texto para el
tipo de registro que desea buscar. Por ejemplo, si desea ver solo los registros SRV,
escriba SRV.
 10. Presione ENTRAR. Los registros de recursos DNS se filtran según los criterios y la
frase de búsqueda que especificó.

Consulte también
Administración de registros de recursosDNSAdministración de IPAM
Visualización de registros de recursos
DNS para una dirección IP específica
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para ver los registros de recursos DNS asociados a la dirección IP
que elija.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Para ver los registros de recursos de una dirección IP

1. En Administrador del servidor, haga clic en IPAM. Aparece la consola de cliente
IPAM.

2. En el panel de navegación, en ESPACIO DE DIRECCIONES IP, haga clic en

Inventario de direcciones IP. En el panel de navegación inferior, haga clic en IPv4
o IPv6. El inventario de direcciones IP aparece en la vista de búsqueda del panel de
visualización. Busque y seleccione la dirección IP cuyos registros de recursos DNS
desea ver.
 3. En la vista Detalles del panel de visualización, haga clic en Registros de recursos
DNS. Se muestran los registros de recursos asociados a la dirección IP
seleccionada.

Consulte también
Administración de registros de recursosDNSAdministrar IPAM
Administración de zonas DNS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema se proporciona información sobre cómo administrar zonas DNS mediante
la consola IPAM cliente.

７ Nota

Además de este tema, en esta sección están disponibles los IPAM de

administración de zonas DNS siguientes.

Creación de una zona DNS

Edición de una zona DNS
Visualización de registros de recursos DNS para una zona DNS
Visualización de zonas DNS

Al implementar IPAM en Windows Server 2016, puede usar IPAM para administrar zonas
DNS.

En la consola IPAM, puede ver los registros de recursos DNS de una zona DNS específica
y filtrar los registros en función del tipo, la dirección IP, los datos de registro de recursos
y otras opciones de filtrado. Además, puede editar registros de recursos DNS para zonas
específicas.

Consulte también
Administrar IPAM
Creación de un alias DNS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para crear una zona DNS mediante la consola de cliente de IPAM.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Creación de una zona DNS

1. En Administrador del servidor, haga clic en IPAM. Aparece la consola de cliente
IPAM.

2. En el panel de navegación, en MONITOR AND MANAGE, haga clic en Servidores

DNS y DHCP. En el panel de presentación, haga clic en Tipo de servidor y, a
continuación, haga clic en DNS. Todos los servidores DNS administrados por IPAM
se muestran en los resultados de la búsqueda.

3. Busque el servidor donde desea agregar una zona y haga clic con el botón
derecho en el servidor. Haga clic en Crear zona DNS.

4. Se abre el cuadro de diálogo Crear zona DNS . En Propiedades generales,

seleccione una categoría de zona, un tipo de zona y escriba un nombre en
Nombre de zona. Seleccione también los valores adecuados para la
 implementación en Propiedades avanzadas y, a continuación, haga clic en
Aceptar.

Consulte también
Administración de zonasDNSAdministrar IPAM
Edición de una zona DNS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para editar una zona DNS en la consola de cliente de IPAM.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Para editar una zona DNS

1. En Administrador del servidor, haga clic en IPAM. Aparece la consola de cliente
IPAM.

2. En el panel de navegación, en MONITOR Y ADMINISTRACIÓN, haga clic en Zonas

DNS. El panel de navegación se divide en un panel de navegación superior y en un
panel de navegación inferior.

3. En el panel de navegación inferior, realice una de las siguientes selecciones:

Búsqueda directa

Búsqueda inversa IPv4

Búsqueda inversa de IPv6

4. Por ejemplo, seleccione Búsqueda inversa IPv4.

5. En el panel de presentación, haga clic con el botón derecho en la zona que desea
editar y, a continuación, haga clic en Editar zona DNS.
6. Se abre el cuadro de diálogo Editar zona DNS con la página General seleccionada.
Si es necesario, edite las propiedades de zona general: servidor DNS, Categoría de
zona y Tipo de zona y, a continuación, haga clic en Aplicar o, si las modificaciones
están completas, Aceptar.

7. En el cuadro de diálogo Editar zona DNS , haga clic en Avanzado. Se abre la

página De propiedades de zona avanzada . Si es necesario, edite las propiedades
que desea cambiar y, a continuación, haga clic en Aplicar o, si las modificaciones
están completas, aceptar.
 8. Si es necesario, seleccione los nombres de página de propiedades de zona
adicionales (Servidores de nombres, SOA, Transferencias de zona), realice las
modificaciones y haga clic en Aplicar o Aceptar. Para revisar todas las ediciones de
la zona, haga clic en Resumeny, a continuación, haga clic en Aceptar.

Consulte también
Administración de zonasDNSAdministración de IPAM
Visualización de registros de recursos
DNS para una zona DNS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para ver los registros de recursos DNS de una zona DNS en la
consola de cliente de IPAM.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Para ver los registros de recursos DNS de una zona

1. En Administrador del servidor, haga clic en IPAM. Aparece la consola de cliente
IPAM.

2. En el panel de navegación, en MONITOR Y ADMINISTRACIÓN, haga clic en Zonas

DNS. El panel de navegación se divide en un panel de navegación superior y en un
panel de navegación inferior.

3. En el panel de navegación inferior, haga clic en Búsqueda directay, a continuación,

expanda la lista de dominios y zonas para buscar y seleccionar la zona que desea
ver. Por ejemplo, si tiene una zona denominada Dublín, haga clic en Dublín.
4. En el panel de presentación, la vista predeterminada es de los servidores DNS de la
zona. Para cambiar la vista, haga clic en Vista actual y, a continuación, haga clic en
Registros de recursos.

5. Se muestran los registros de recursos DNS de la zona. Para filtrar los registros,
escriba el texto que desea encontrar en Filtro.

6. Para filtrar los registros de recursos por tipo de registro, ámbito de acceso u otros
criterios, haga clic en Agregar criterios y, a continuación, realice selecciones de la
lista de criterios y haga clic en Agregar.
Consulte también
Administración de zonasDNSAdministrar IPAM
Visualización de zonas DNS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para ver las zonas DNS en la consola IPAM cliente.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Para ver las zonas DNS en la consola IPAM cliente

1. En Administrador del servidor, haga clic en IPAM. Aparece IPAM consola del
cliente.

2. En el panel de navegación, en SUPERVISAR Y ADMINISTRAR, haga clic en Zonas

DNS. El panel de navegación se divide en un panel de navegación superior y un
panel de navegación inferior.

3. En el panel de navegación inferior, realice una de las siguientes selecciones:

Búsqueda directa

Búsqueda inversa IPv4

Búsqueda inversa IPv6

Reenviador condicional

Consulte también
Administración de zonasDNSManage IPAM
Administración de recursos en varios
bosques de Active Directory
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para aprender a usar IPAM para administrar controladores de
dominio, servidores DHCP y servidores DNS en varios bosques de Active Directory.

Para usar IPAM para administrar recursos en bosques remotos de Active Directory, cada
bosque que quiera administrar debe tener una confianza bidireccional con el bosque
donde se instala IPAM.

Para iniciar el proceso de detección de diferentes bosques de Active Directory, abra

Administrador del servidor y haga clic en IPAM. En la consola de cliente de IPAM, haga
clic en Configurar detección de servidores y, a continuación, haga clic en Obtener
bosques. Esto inicia una tarea en segundo plano que detecta bosques de confianza y
sus dominios. Una vez completado el proceso de detección, haga clic en Configurar
detección de servidores, que abre el siguiente cuadro de diálogo.
７ Nota

Para el aprovisionamiento basado en directiva de grupo para un escenario entre

bosques de Active Directory, asegúrese de ejecutar el siguiente cmdlet Windows
PowerShell en el servidor IPAM y no en los controladores de dominio de confianza.
Por ejemplo, si el servidor de IPAM está unido al bosque [Link] y el
bosque de confianza está [Link], puede ejecutar el siguiente cmdlet de
Windows PowerShell en el servidor IPAM de [Link] para el
aprovisionamiento basado en directiva de grupo en el bosque de [Link].
Para ejecutar este cmdlet, debe ser miembro del grupo Administradores de
dominio en el bosque de [Link].

PowerShell

Invoke-IpamGpoProvisioning -Domain [Link] -GpoPrefixName

IPAMSERVER -IpamServerFqdn [Link]
En el cuadro de diálogo Configurar detección de servidores, haga clic en Seleccionar el
bosque y, a continuación, elija el bosque que desea administrar con IPAM. Seleccione
también los dominios que desea administrar y, a continuación, haga clic en Agregar.

En Seleccionar los roles de servidor que se van a detectar, para cada dominio que
quiera administrar, especifique el tipo de servidores que se van a detectar. Las opciones
son controlador de dominio, servidor DHCP y servidor DNS.

De forma predeterminada, se detectan controladores de dominio, servidores DHCP y

servidores DNS, por lo que si no desea detectar uno de estos tipos de servidores,
asegúrese de anular la selección de la casilla de esa opción.

En la ilustración de ejemplo anterior, el servidor de IPAM se instala en el bosque de

[Link] y se agrega el dominio raíz del bosque de [Link] para la
administración de IPAM. Los roles de servidor seleccionados permiten a IPAM detectar y
administrar controladores de dominio, servidores DHCP y servidores DNS en el dominio
raíz de [Link] y el dominio raíz [Link].

Después de especificar bosques, dominios y roles de servidor, haga clic en Aceptar.

IPAM realiza la detección y, cuando se completa la detección, puede administrar los
recursos en el bosque local y remoto.
Purgado de datos de utilización
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información sobre cómo eliminar datos de uso de la
base de IPAM datos.

Debe ser miembro de IPAM administradores, el grupo administradores del equipo local,
o equivalente, para realizar este procedimiento.

Para purgar la base IPAM datos

1. Abra Administrador del servidor y, a continuación, vaya a la interfaz IPAM cliente.
2. Vaya a una de las siguientes ubicaciones: Bloques de direcciones IP, Inventario de
direcciones IP o Grupos de intervalos de direcciones IP.
3. Haga clic en TAREASy, a continuación, haga clic en Purgar datos de uso. Se abre el
cuadro de diálogo Purgar datos de uso.
4. En Purgar todos los datos de uso en o antes, haga clic en Seleccionar una fecha.
5. Elija la fecha para la que desea eliminar todos los registros de base de datos en y
antes de esa fecha.
6. Haga clic en OK. IPAM elimina todos los registros especificados.
Control de acceso basado en rol
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema se proporciona información sobre el uso del control de acceso basado en
rol en IPAM.

７ Nota

Además de este tema, la siguiente documentación IPAM control de acceso está

disponible en esta sección.

Administración del control de acceso basado en roles con el Administrador

del servidor
Administración del control de acceso basado en roles con Windows
PowerShell

El control de acceso basado en rol permite especificar privilegios de acceso en varios

niveles, incluidos el servidor DNS, la zona DNS y los niveles de registro de recursos DNS.
Mediante el control de acceso basado en rol, puede especificar quién tiene un control
granular sobre las operaciones para crear, editar y eliminar diferentes tipos de registros
de recursos DNS.

Puede configurar el control de acceso para que los usuarios estén restringidos a los
permisos siguientes.

Los usuarios solo pueden editar registros de recursos DNS específicos

Los usuarios pueden editar registros de recursos DNS de un tipo específico, como
PTR o MX.

Los usuarios pueden editar registros de recursos DNS para zonas específicas

Consulte también
Administración de roles Access Control con Administrador del servidorAdministar roles
basados en Access Control con Windows PowerShellManage IPAM
Administración del control de acceso
basado en roles con el Administrador
del servidor
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar los temas siguientes para administrar el control de acceso basado en roles
mediante Administrador del servidor, que tiene una interfaz gráfica de usuario.

Crear un rol de usuario para Access Control

Creación de una directiva de acceso

Establecer el ámbito de acceso para una zona DNS

Establecer el ámbito de acceso para los registros de recursos DNS

Ver roles y permisos de rol

Como alternativa, puede usar Windows PowerShell para administrar IPAM control de
acceso basado en roles. Para obtener más información, vea Administrar roles basados
Access Control con Windows PowerShell.

Consulte también
Administrar IPAM
Crear un rol de usuario para Access
Control
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para crear un nuevo rol de usuario Access Control en la consola
de cliente de IPAM.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

７ Nota

Después de crear un rol, puede crear una directiva de acceso para asignar el rol a
un usuario específico o grupo de Active Directory. Para obtener más información,
vea Crear una directiva de acceso.

Para crear un rol

1. En Administrador del servidor, haga clic en IPAM. Aparece la consola de cliente
IPAM.

2. En el panel de navegación, haga clic en CONTROL DE ACCESO y, en el panel de

navegación inferior, haga clic en Roles.
3. Haga clic con el botón derecho en Rolesy, a continuación, haga clic en Agregar rol
de usuario.

4. Se abre el cuadro de diálogo Agregar o editar rol . En Nombre, escriba un nombre

para el rol que desactive la función de rol. Por ejemplo, si desea crear un rol que
permita a los administradores administrar registros de recursos SRV de DNS,
puede asignar el nombre IPAMSrv al rol. Si es necesario, desplácese hacia abajo en
Operaciones para buscar el tipo de operaciones que desea definir para el rol. En
este ejemplo, desplácese hacia abajo hasta operaciones de administración de
registros de recursos DNS.
5. Expanda Operaciones de administración de registros de recursos DNS y busque
operaciones de registro SRV.
6. Expanda y seleccione operaciones de registro SRV y, a continuación, haga clic en
Aceptar.
7. En la consola de cliente de IPAM, haga clic en el rol que acaba de crear. En la Vista
de detalles, se muestran las operaciones permitidas para el rol.
Consulte también
Access Control Basada enrolesAdministrar IPAM
Crear una directiva de acceso
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para crear una directiva de acceso en la consola de cliente de
IPAM.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

７ Nota

Puede crear una directiva de acceso para un usuario específico o para un grupo de
usuarios en Active Directory. Al crear una directiva de acceso, debe seleccionar un
rol integrado IPAM o un rol personalizado que haya creado. Para obtener más
información sobre los roles personalizados, vea Crear un rol de usuario para
Access Control.

Para crear una directiva de acceso

1. En Administrador del servidor, haga clic en IPAM. Aparece la consola de cliente
IPAM.

2. En el panel de navegación, haga clic en CONTROL DE ACCESO. En el panel de

navegación inferior, haga clic con el botón derecho en Directivas de acceso y, a
continuación, haga clic en Agregar directiva de acceso.
3. Se abre el cuadro de diálogo Agregar directiva de acceso . En Usuario
Configuración, haga clic en Agregar.
4. Se abre el cuadro de diálogo Seleccionar usuario o grupo . Haga clic en
Ubicaciones.
5. Se abre el cuadro de diálogo Ubicaciones . Vaya a la ubicación que contiene la
cuenta de usuario, seleccione la ubicación y haga clic en Aceptar. Se cierra el
cuadro de diálogo Ubicaciones .

6. En el cuadro de diálogo Seleccionar usuario o grupo , en Escriba el nombre de

objeto que desea seleccionar, escriba el nombre de la cuenta de usuario para la
que desea crear una directiva de acceso. Haga clic en OK.

7. En Agregar directiva de acceso, en User Configuración, El alias de usuario ahora

contiene la cuenta de usuario a la que se aplica la directiva. En Access
Configuración, haga clic en Nuevo.
8. En Agregar directiva de acceso, Access Configuración cambia a Nueva
configuración.
9. Haga clic en Seleccionar rol para expandir la lista de roles. Seleccione uno de los
roles integrados o, si ha creado nuevos roles, seleccione uno de los roles que ha
creado. Por ejemplo, si ha creado el rol IPAMSrv para aplicar al usuario, haga clic
en IPAMSrv.
10. Haga clic en Agregar configuración.
11. El rol se agrega a la directiva de acceso. Para crear directivas de acceso adicionales,
haga clic en Aplicar y repita estos pasos para cada directiva que quiera crear. Si no
desea crear directivas adicionales, haga clic en Aceptar.
12. En el panel de visualización de la consola de cliente IPAM, compruebe que se crea
la nueva directiva de acceso.
Consulte también
Access Control Administrar IPAMbasado en roles
Establecer el ámbito de acceso para una
zona DNS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para establecer el ámbito de acceso de una zona DNS mediante la
consola de cliente de IPAM.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Para establecer el ámbito de acceso de una zona DNS

1. En Administrador del servidor, haga clic en IPAM. Aparece la consola de cliente
IPAM.

2. En el panel de navegación, haga clic en Zonas DNS. En el panel de presentación,

haga clic con el botón derecho en la zona DNS para la que desea cambiar el
ámbito de acceso y, a continuación, haga clic en Establecer ámbito de acceso.

3. Se abre el cuadro de diálogo Establecer ámbito de acceso . Si es necesario para la

implementación, haga clic para anular la selección de Heredar ámbito de acceso
del elemento primario. En Seleccionar el ámbito de acceso, seleccione un
elemento y, a continuación, haga clic en Aceptar.
 4. En el panel de presentación IPAM consola de cliente, compruebe que se cambia el
ámbito de acceso de la zona.

Consulte también
Access Control Basada enrolesAdministrar IPAM
Establecer el ámbito de acceso para
registros de recursos DNS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para establecer el ámbito de acceso de los registros de recursos
DNS mediante la consola de cliente de IPAM.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Para establecer el ámbito de acceso para los registros de

recursos DNS
1. En Administrador del servidor, haga clic en IPAM. Aparece la consola de cliente
IPAM.

2. En el panel de navegación, haga clic en Zonas DNS. En el panel de navegación

inferior, expanda Búsqueda directa y busque y seleccione la zona que contiene los
registros de recursos cuyo ámbito de acceso desea cambiar.

3. En el panel de presentación, busque y seleccione los registros de recursos cuyo

ámbito de acceso desea cambiar.

4. Haga clic con el botón derecho en los registros de recursos DNS seleccionados y, a
continuación, haga clic en Establecer ámbito de acceso.
 5. Se abre el cuadro de diálogo Establecer ámbito de acceso . Si es necesario para la
implementación, haga clic para anular la selección de Heredar ámbito de acceso
del elemento primario. En Seleccionar el ámbito de acceso, seleccione un
elemento y, a continuación, haga clic en Aceptar.

Consulte también
Access Control Administrar IPAMbasado en roles
ver roles y permisos de rol
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para ver Access Control roles de usuario en la consola de cliente
de IPAM.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Para ver los roles de Access Control

1. En Administrador del servidor, haga clic en IPAM. Aparece la consola de cliente
IPAM.

2. En el panel de navegación, haga clic en CONTROL DE ACCESO.

3. En el panel de navegación inferior, haga clic en Roles. En el panel de presentación,

se muestran los roles.

4. Seleccione el rol cuyos permisos desea ver. En el panel de detalles inferior, se

muestran las operaciones permitidas para el rol.
Consulte también
Access Control Basada enrolesAdministrar IPAM
Administración del control de acceso
basado en roles con Windows
PowerShell
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información sobre cómo usar IPAM para administrar
el control de acceso basado en rol con Windows PowerShell.

７ Nota

Para obtener IPAM Windows PowerShell de comandos, vea los cmdlets ipamServer
en Windows PowerShell.

Los nuevos Windows PowerShell IPAM proporcionan la capacidad de recuperar y

cambiar los ámbitos de acceso de los objetos DNS y DHCP. En la tabla siguiente se
muestra el comando correcto que se usará para cada IPAM objeto.

IPAM objeto Comando Descripción

Servidor DNS Get-IpamDnsServer Este cmdlet devuelve el objeto de servidor

DNS en IPAM

Zona DNS Get-IpamDnsZone Este cmdlet devuelve el objeto de zona

DNS en IPAM

Registro de Get-IpamResourceRecord Este cmdlet devuelve el objeto de registro

recursos DNS de recursos DNS en IPAM

Reenviador Get- Este cmdlet devuelve el objeto de

condicional DNS IpamDnsConditionalForwarder reenviador condicional DNS en IPAM

Servidor DHCP Get-IpamDhcpServer Este cmdlet devuelve el objeto de servidor

DHCP en IPAM

Superámbito Get-IpamDhcpSuperscope Este cmdlet devuelve el objeto de

DHCP superáscope DHCP en IPAM

Ámbito DHCP Get-IpamDhcpScope Este cmdlet devuelve el objeto de ámbito

DHCP en IPAM
En el ejemplo siguiente de salida del comando, el Get-IpamDnsZone cmdlet Get-
IpamDnsZone zona DNS.

PS C:\Users\[Link]> Get-IpamDnsZone -ZoneType Forward -

ZoneName [Link]

ZoneName : [Link]
ZoneType : Forward
AccessScopePath : \Global\Dublin
IsSigned : False
DynamicUpdateStatus : None
ScavengeStaleRecords : False

Establecer ámbitos de acceso en IPAM objetos

Puede establecer ámbitos de acceso en IPAM objetos mediante el Set-IpamAccessScope
comando . Puede usar este comando para establecer el ámbito de acceso en un valor
específico para un objeto o para hacer que los objetos hereden el ámbito de acceso de
los objetos primarios. A continuación se encuentran los objetos que puede configurar
con este comando.

Ámbito DHCP

Servidor DHCP

Superámbito DHCP

Reenviador condicional DNS

Registros de recursos DNS

Servidor DNS

Zona DNS

IP Address Block

Intervalo de direcciones IP

Espacio de direcciones IP

Subred de dirección IP

A continuación se muestra la sintaxis del Set-IpamAccessScope comando.

NAME
Set-IpamAccessScope

SYNTAX
Set-IpamAccessScope [-IpamRange] -InputObject <ciminstance[]> [-
AccessScopePath <string>] [-IsInheritedAccessScope] [-PassThru] [-CimSession
<CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf] [-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamDnsServer] -InputObject <ciminstance[]> [-

AccessScopePath <string>] [-IsInheritedAccessScope] [-PassThru] [-CimSession
<CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf] [-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamDhcpServer] -InputObject <ciminstance[]> [-

AccessScopePath <string>] [-IsInheritedAccessScope] [-PassThru] [-CimSession
<CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf] [-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamDhcpSuperscope] -InputObject <ciminstance[]>

[-AccessScopePath <string>] [-IsInheritedAccessScope] [-PassThru] [-
CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf] [-
Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamDhcpScope] -InputObject <ciminstance[]> [-

AccessScopePath <string>] [-IsInheritedAccessScope] [-PassThru] [-CimSession
<CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf] [-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamDnsConditionalForwarder] -InputObject

<ciminstance[]> [-AccessScopePath <string>] [-IsInheritedAccessScope] [-
PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-
WhatIf] [-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamDnsResourceRecord] -InputObject

<ciminstance[]> [-AccessScopePath <string>] [-IsInheritedAccessScope] [-
PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-
WhatIf] [-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamDnsZone] -InputObject <ciminstance[]> [-

AccessScopePath <string>] [-IsInheritedAccessScope] [-PassThru] [-CimSession
<CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf] [-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamAddressSpace] -InputObject <ciminstance[]> [-

AccessScopePath <string>] [-IsInheritedAccessScope] [-PassThru] [-CimSession
<CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf] [-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamSubnet] -InputObject <ciminstance[]> [-

 AccessScopePath <string>] [-IsInheritedAccessScope] [-PassThru] [-CimSession
<CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf] [-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamBlock] -InputObject <ciminstance[]> [-

AccessScopePath <string>] [-IsInheritedAccessScope] [-PassThru] [-CimSession
<CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf] [-Confirm]
[<CommonParameters>]

En el ejemplo siguiente, el ámbito de acceso de la zona DNS [Link]

cambia de Dublín a Europa.

PS C:\Users\[Link]> Get-IpamDnsZone -ZoneType Forward -

ZoneName [Link]

ZoneName : [Link]
ZoneType : Forward
AccessScopePath : \Global\Dublin
IsSigned : False
DynamicUpdateStatus : None
ScavengeStaleRecords : False

PS C:\Users\[Link]> $a = Get-IpamDnsZone -ZoneType Forward -

ZoneName [Link]
PS C:\Users\[Link]> Set-IpamAccessScope -IpamDnsZone -
InputObject $a -AccessScopePath \Global\Europe -PassThru

ZoneName : [Link]
ZoneType : Forward
AccessScopePath : \Global\Europe
IsSigned : False
DynamicUpdateStatus : None
ScavengeStaleRecords : False
Equilibrio de carga de red
Artículo • 21/12/2022 • Tiempo de lectura: 8 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema, le proporcionamos información general sobre la característica Equilibrio

de carga de red (NLB) en Windows Server 2016. Puede usar NLB para administrar dos o
más servidores como un único clúster virtual. NLB mejora la disponibilidad y
escalabilidad de las aplicaciones de servidor de Internet, como las usadas en web, FTP,
firewall, proxy, red privada virtual (VPN) y otros servidores críticos.

７ Nota

Windows Server 2016 incluye un nuevo software inspirado en Azure Load Balancer
(SLB) como componente de la infraestructura de redes definidas por software
(SDN). Use SLB en lugar de NLB si usa SDN, usa cargas de trabajo que no son
Windows, necesita traducción de direcciones de red salientes (NAT) o necesita
equilibrio de carga basado en nivel 3 (L3) o no TCP. Puede seguir usando NLB con
Windows Server 2016 para implementaciones que no son de SDN. Para obtener
más información sobre SLB, consulte Equilibrio de carga de software (SLB) para
SDN.

La característica de equilibrio de carga de red (NLB) distribuye el tráfico por distintos

servidores mediante el protocolo de red TCP/IP. Al combinar en un solo clúster virtual
dos o más equipos que ejecutan aplicaciones, NLB ofrece confiabilidad y rendimiento
para los servidores web y otros servidores con una importancia decisiva.

Los servidores de un clúster NLB se denominan hosts y cada uno de ellos ejecuta una
copia independiente de las aplicaciones de servidor. NLB distribuye las solicitudes de
cliente entrantes entre los hosts que forman el clúster. Se puede configurar la carga que
administrará cada host. También se pueden agregar hosts de manera dinámica al clúster
para administrar los aumentos de carga. Además, NLB puede dirigir todo el tráfico a un
solo host especificado, que se denomina host predeterminado.

NLB permite que todos los equipos del clúster se dirijan al mismo conjunto de
direcciones IP y mantiene un conjunto de direcciones IP exclusivas y dedicadas para
cada host. En el caso de aplicaciones con equilibrio de carga, cuando se produce un
error en un host o éste se desconecta, la carga se redistribuye automáticamente entre
los equipos que siguen operativos. Cuando esté listo, el equipo sin conexión puede
volverse a unir de manera transparente al clúster y volver a recuperar su cuota de carga
de trabajo, lo que permite a los otros equipos del clúster administrar menos tráfico.

Aplicaciones prácticas
NLB es útil para garantizar que las aplicaciones sin estado, como un servidor web que
ejecuta Internet Information Services (IIS), estén disponibles con un tiempo de
inactividad mínimo y sean escalables (al agregar más servidores a medida que aumenta
la carga). En las secciones siguientes, se describe la manera en que NLB admite alta
disponibilidad, escalabilidad y capacidad de administración de los servidores en clúster
que ejecutan estas aplicaciones.

Alta disponibilidad
Un sistema con alta disponibilidad proporciona de un modo confiable un nivel de
servicio aceptable y un tiempo de inactividad mínimo. Para proporcionar una alta
disponibilidad, NLB incluye características integradas que pueden hacer de manera
automática lo siguiente:

Detectar un host de clúster que experimente un error o que se desconecte y luego

recuperarlo.

Equilibrar la carga de la red cuando se agregan o quitan hosts.

Recuperar y redistribuir la carga de trabajo en diez segundos.

Escalabilidad
La escalabilidad cuantifica en qué grado puede un equipo, servicio o aplicación
aumentar su capacidad y cubrir una mayor demanda de rendimiento. Para los clústeres
NLB, es la capacidad de agregar gradualmente uno o varios sistemas a un clúster
existente cuando la carga global del clúster supera sus posibilidades. Para admitir la
escalabilidad, se puede hacer lo siguiente con NLB:

Equilibrar las solicitudes de carga en el clúster NLB para los servicios TCP/IP
individuales.

Ser compatible con hasta 32 equipos en un solo clúster.

Equilibrar varias solicitudes de carga de servidor (desde el mismo cliente o desde

varios clientes) en varios hosts del clúster.
 Agregar hosts al clúster NLB a medida que aumenta la carga sin que se produzca
un error en el clúster.

Quitar hosts del clúster cuando disminuye la carga.

Habilitar el alto rendimiento y la sobrecarga baja mediante de una implementación

totalmente canalizada. La canalización permite enviar las solicitudes al clúster NLB
sin tener que esperar la respuesta a una solicitud anterior.

Facilidad de uso
Para admitir la capacidad de administración, se puede hacer lo siguiente con NLB:

Administre y configure varios clústeres NLB y los hosts de clúster desde un único
equipo mediante nlB Manager o los cmdlets de equilibrio de carga de red (NLB) en
Windows PowerShell.

Especificar el comportamiento del equilibrio de carga para un solo puerto IP o un

grupo de puertos mediante el uso de reglas de administración de puertos.

Definir reglas de puertos diferentes para cada sitio web. Si usa el mismo conjunto
de servidores con equilibrio de carga para varias aplicaciones o sitios web, las
reglas de puerto se basan en la dirección IP virtual de destino (mediante el uso de
clústeres virtuales).

Dirigir todas las solicitudes de cliente a un solo host mediante el uso de reglas
opcionales de un solo host. NLB enruta las solicitudes de clientes a un host
concreto que ejecuta aplicaciones específicas.

Bloquear el acceso de red no deseado para determinados puertos IP.

Habilitar la compatibilidad con el Protocolo de administración de grupos de

Internet (IGMP) en los hosts del clúster para controlar el desborde de los puertos
del conmutador (donde los paquetes de red entrantes se envían a todos los
puertos del conmutador) al operar en modo de multidifusión.

Iniciar, detener y controlar las acciones de NLB en forma remota mediante los
comandos o scripts de Windows PowerShell.

Ver el registro de eventos de Windows para comprobar si hay eventos de NLB. NLB
registra en el registro de eventos todas las acciones y los cambios que se han
realizado en el clúster.
Funcionalidad importante
NLB se instala como componente estándar del controlador de red de Windows Server.
Sus operaciones son transparentes para la pila de redes TCP/IP. En la ilustración
siguiente se muestra la relación entre NLB y otros componentes de software en una
configuración típica.

A continuación se muestran las características principales de NLB.

No se requieren cambios de hardware para la ejecución.

Proporciona herramientas de equilibrio de carga de red que permiten configurar y

administrar varios clústeres y todos los hosts desde un solo equipo remoto o local.

Permite a los clientes tener acceso al clúster mediante un solo nombre de Internet
lógico y una dirección IP virtual, conocida como la dirección IP del clúster
(conserva los nombres individuales de cada equipo). NLB permite la existencia de
varias direcciones IP virtuales para los servidores de hosts múltiples.

７ Nota

Al implementar máquinas virtuales como clústeres virtuales, NLB no requiere que

los servidores tengan varias direcciones IP virtuales.

NLB se puede enlazar a varios adaptadores de red, lo que permite configurar

varios clústeres independientes en cada host. La compatibilidad con varios
adaptadores de red difiere de los clústeres virtuales en que los clústeres virtuales le
permiten configurar varios clústeres en un único adaptador de red.
 No es necesario realizar modificaciones en las aplicaciones de servidor para que
puedan ejecutar un clúster NLB.

NLB se puede configurar para agregar de manera automática un host al clúster si

se produce un error en dicho clúster y posteriormente se vuelve a conectar en
línea. El host agregado puede comenzar a administrar nuevas solicitudes de
servidor de los clientes.

Permite desconectar los equipos para llevar a cabo el mantenimiento preventivo

sin alterar las operaciones del clúster en los demás hosts.

Requisitos de hardware
A continuación se muestran los requisitos de hardware para ejecutar un clúster NLB.

Todos los hosts del clúster deben residir en la misma subred.

No existe ningún tipo de limitación en cuanto al número de adaptadores de red en

cada host y los hosts diferentes pueden tener un número distinto de adaptadores.

Dentro de cada clúster, todos los adaptadores de red deben ser de unidifusión o
multidifusión. NLB no admite un entorno mixto de unidifusión y multidifusión
dentro de un solo clúster.

Si usa el modo de unidifusión, el adaptador de red que se utiliza para administrar

el tráfico del cliente al clúster debe admitir la aplicación de cambios en su
dirección de Media Access Control (MAC).

Requisitos de software
A continuación se muestran los requisitos de software para ejecutar un clúster NLB.

Solamente se puede usar TCP/IP en el adaptador para el cual se habilita en cada

host. No agregue ningún otro protocolo (por ejemplo, IPX) a este adaptador.

Las direcciones IP de los servidores del clúster deben ser estáticas.

７ Nota

El Protocolo de configuración dinámica de host (DHCP) no es compatible con NLB.

NLB deshabilita DHCP en cada interfaz que configura.
Información de instalación
Puede instalar NLB mediante Administrador del servidor o los comandos de Windows
PowerShell para NLB.

Opcionalmente, puede instalar las herramientas de equilibrio de carga de red para

administrar un clúster NLB local o remoto. Las herramientas incluyen Network Load
Balancing Manager y los comandos NLB Windows PowerShell.

Instalación con Administrador del servidor

En Administrador del servidor, puede usar el Asistente para agregar roles y
características para agregar la característica Equilibrio de carga de red. Cuando
complete el asistente, NLB está instalado y no es necesario reiniciar el equipo.

Instalación con Windows PowerShell

Para instalar NLB mediante Windows PowerShell, ejecute el siguiente comando en un
símbolo del sistema de Windows PowerShell con privilegios elevados en el equipo en el
que desea instalar NLB.

PowerShell

Install-WindowsFeature NLB -IncludeManagementTools

Una vez completada la instalación, no se requiere ningún reinicio del equipo.

Para obtener más información, consulta Install-WindowsFeature.

Administrador de equilibrio de carga de red

Para abrir el Administrador de equilibrio de carga de red en el Administrador del
servidor, haga clic en Herramientas y, luego, en Administrador de equilibrio de carga
de red.

Recursos adicionales
En la tabla siguiente se proporcionan vínculos a información adicional sobre la
característica NLB.
Tipo de Referencias
contenido

Implementación Guía | de implementación de equilibrio de carga de redConfiguración del

equilibrio de carga de red con Terminal Services

Operations Administración de clústeres | de equilibrio de carga de red Establecer

parámetros | de equilibrio de carga de redControl de hosts en clústeres de
equilibrio de carga de red

Solucionar Solución de problemas de clústeres de equilibrio de carga de red | Errores y

problemas eventos de clúster NLB

Herramientas y Cmdlets de NLB de Windows PowerShell

configuración

Recursos de la Foro sobre alta disponibilidad (clúster)

comunidad
Servidor de directivas de redes (NPS)
Artículo • 21/12/2022 • Tiempo de lectura: 14 minutos

Se aplica a: Windows Server 2022, Windows Server 2016, Windows Server 2019

Puede usar este tema para obtener información general sobre el servidor de directivas
de red en Windows Server 2016 y Windows Server 2019. NPS se instala al instalar la
característica Directiva de red y Access Services (NPAS) en Windows Server 2016 y Server
2019.

７ Nota

Además de este tema, está disponible la siguiente documentación de NPS.

Procedimientos recomendados del servidor de directivas de redes

Tareas iniciales con el servidor de directivas de redes
Planear el servidor de directivas de redes
Implementar el servidor de directivas de redes
Administrar el servidor de directivas de redes
Cmdlets del servidor de directivas de red (NPS) en Windows PowerShell
para Windows Server 2016 y Windows 10
Cmdlets del servidor de directivas de red (NPS) en Windows PowerShell
para Windows Server 2012 R2 y Windows 8.1
Cmdlets NPS en Windows PowerShell para Windows Server 2012 y Windows
8

El servidor de directivas de red (NPS) permite crear y aplicar directivas de acceso de red
en toda la organización para la autenticación y autorización de solicitudes de conexión.

También puede configurar NPS como proxy de servicio de acceso telefónico local de
autenticación remota (RADIUS) para reenviar solicitudes de conexión a un NPS remoto u
otro servidor RADIUS para que pueda equilibrar la carga de las solicitudes de conexión y
reenviarlas al dominio correcto para la autenticación y autorización.

NPS permite configurar y administrar de forma centralizada la autenticación,

autorización y contabilidad de acceso a la red con las siguientes características:

Servidor RADIUS. NPS realiza la autenticación centralizada, la autorización y la

contabilidad de conexiones inalámbricas, de autenticación, de acceso remoto y de
 red privada virtual (VPN). Cuando se usa NPS como un servidor RADIUS, se
configuran los servidores de acceso a la red, como los puntos de acceso
inalámbrico y los servidores VPN, como clientes RADIUS en NPS. Además, se
configuran las directivas de redes que usa NPS para autorizar las solicitudes de
conexión. También puede configurar la administración de cuentas RADIUS para
que NPS registre la información de las cuentas en archivos de registro del disco
duro local o en una base de datos de Microsoft SQL Server. Para obtener más
información, vea Servidor RADIUS.
Proxy RADIUS. Cuando se usa NPS como proxy RADIUS, se configuran directivas
de solicitud de conexión que indican al NPS qué solicitudes de conexión reenviar a
otros servidores RADIUS y a qué servidores RADIUS desea reenviar solicitudes de
conexión. También puede configurar NPS para que reenvíe datos de cuentas que
deben registrar uno o más equipos en un grupo de servidores RADIUS remotos.
Para configurar NPS como un servidor proxy RADIUS, consulte los temas
siguientes. Para obtener más información, vea Proxy RADIUS.
Configurar directivas de solicitud de conexión
Contabilidad RADIUS. Puede configurar NPS para registrar eventos en un archivo
de registro local o en una instancia local o remota de Microsoft SQL Server. Para
obtener más información, consulte Registro de NPS.

） Importante

La protección de acceso a la red (NAP), la entidad de registro de estado (HRA) y el

protocolo de autorización de credenciales de host (HCAP) han quedado en desuso
en Windows Server 2012 R2 y no están disponibles en Windows Server 2016. Si
tiene una implementación nap con sistemas operativos anteriores a Windows
Server 2016, no puede migrar la implementación de NAP a Windows Server 2016.

Puede configurar NPS con cualquier combinación de estas características. Por ejemplo,
puede configurar un NPS como servidor RADIUS para las conexiones VPN y también
como proxy RADIUS para reenviar algunas solicitudes de conexión a los miembros de
un grupo de servidores RADIUS remoto para la autenticación y autorización en otro
dominio.

Ediciones de Windows Server y NPS

NPS proporciona una funcionalidad diferente en función de la edición de Windows
Server que instale.
Windows Server 2016 o Windows Server 2019
Standard/Datacenter Edition
Con NPS en Windows Server 2016 Standard o Datacenter, puede configurar un número
ilimitado de clientes RADIUS y grupos de servidores RADIUS remotos. Además, puede
configurar los clientes RADIUS especificando un intervalo de direcciones IP.

７ Nota

La directiva de red de WIndows y Access Services característica no está disponible

en los sistemas instalados con una opción de instalación Server Core.

En las secciones siguientes se proporciona información más detallada sobre NPS como
servidor RADIUS y proxy.

Servidor y proxy RADIUS

Puede usar NPS como servidor RADIUS, un proxy RADIUS o ambos.

Servidor RADIUS
NPS es la implementación de Microsoft del estándar RADIUS especificado por el Grupo
de tareas de ingeniería de Internet (IETF) en RFC 2865 y 2866. Como servidor RADIUS,
NPS realiza la autenticación, la autorización y la administración de cuentas de la
conexión centralizada para muchos tipos de accesos de red, incluidos los conmutadores
de autenticación inalámbricos, los accesos telefónicos remotos y accesos remotos de
red privada virtual (VPN), y las conexiones de enrutador a enrutador.

７ Nota

Para obtener información sobre la implementación de NPS como un servidor

RADIUS, vea Implementar servidor de directivas de red.

NPS habilita el uso de un conjunto heterogéneo de equipos inalámbricos, de

conmutación, de acceso remoto o VPN. Puede usar NPS con el servicio de acceso
remoto, que está disponible en Windows Server 2016.

NPS usa un dominio de Servicios de dominio de Active Directory (AD DS) o la base de
datos de cuentas de usuario del Administrador de cuentas de seguridad (SAM) local
para autenticar las credenciales de usuario para los intentos de conexión. Cuando un
servidor que ejecuta NPS es miembro de un dominio de AD DS, NPS usa el servicio de
directorio como base de datos de cuenta de usuario y forma parte de una solución de
inicio de sesión único. El mismo conjunto de credenciales se usa para el control de
acceso a la red (autenticación y autorización del acceso a una red) y para iniciar sesión
en un dominio de AD DS.

７ Nota

NPS usa las propiedades de acceso telefónico de la cuenta de usuario y directivas

de red para autorizar una conexión.

Los proveedores de servicios Internet (ISP) y las organizaciones que mantienen el acceso
a la red tienen el cada vez mayor desafío de administrar todos los tipos de accesos a la
red desde un único punto de administración, independientemente del tipo de equipo
que se use para dicho acceso. El estándar RADIUS admite estas funcionalidades tanto en
entornos homogéneos como heterogéneos. RADIUS es un protocolo cliente-servidor
que permite al equipo de acceso a la red (usado como clientes RADIUS) enviar
solicitudes de autenticación y de cuentas a un servidor RADIUS.

Un servidor RADIUS tiene acceso a la información de las cuentas de usuario y puede

comprobar las credenciales de autenticación de los accesos a la red. Si se autentican las
credenciales de usuario y se autoriza el intento de conexión, el servidor RADIUS autoriza
el acceso de usuario en función de las condiciones especificadas y, a continuación,
registra la conexión de acceso a la red en un registro de contabilidad. El uso de RADIUS
permite que los datos de autenticación, autorización y cuentas del usuario se recopilen y
conserven en una ubicación centralizada, en lugar de hacerlo en cada servidor de
acceso.

Uso de NPS como servidor RADIUS

Puede usar NPS como un servidor RADIUS en los casos siguientes:

Usa un dominio de AD DS o la base de datos de cuentas de usuario SAM locales

como base de datos de cuentas de usuario para los clientes de acceso.
Usa acceso remoto en varios servidores de acceso telefónico, servidores VPN o
enrutadores de marcado a petición y quiere centralizar tanto la configuración de
directivas de red como el registro de conexiones y la contabilidad.
Cuando subcontrate con un proveedor de servicios el acceso telefónico, VPN o
inalámbrico. Los servidores de acceso usan RADIUS para autenticar y autorizar
conexiones realizadas por miembros de su organización.
 Cuando desee centralizar la autenticación, la autorización y las cuentas para un
grupo heterogéneo de servidores de acceso.

En la ilustración siguiente se muestra NPS como un servidor RADIUS para una variedad
de clientes de acceso.

Proxy RADIUS
Como proxy RADIUS, NPS reenvía mensajes de autenticación y contabilidad a NPS y a
otros servidores RADIUS. Puede usar NPS como proxy RADIUS para proporcionar el
enrutamiento de mensajes RADIUS entre clientes RADIUS (también denominados
servidores de acceso a la red) y servidores RADIUS que realizan la autenticación,
autorización y contabilidad del usuario para el intento de conexión.

Cuando se usa como proxy RADIUS, NPS es punto de conmutación o enrutamiento

central a través del cual fluyen los mensajes de acceso y cuentas RADIUS. NPS mantiene
en un registro de cuentas la información de los mensajes que se reenviaron.

Uso de NPS como proxy RADIUS

Puede usar NPS como proxy RADIUS si:

Usted es un proveedor de servicios que ofrece servicios de acceso telefónico, VPN

o de red inalámbrica subcontratados a varios clientes. Los NAS envían solicitudes
de conexión al proxy RADIUS nps. Basándose en la parte del dominio kerberos del
nombre de usuario de la solicitud de conexión, el proxy RADIUS NPS reenvía la
solicitud de conexión a un servidor RADIUS que mantiene el cliente y puede
autenticar y autorizar el intento de conexión.
 Quiere proporcionar autenticación y autorización para las cuentas de usuario que
no son miembros del dominio en el que NPS es miembro u otro dominio que tiene
una confianza bidireccional con el dominio en el que el NPS es miembro. Esto
incluye cuentas en dominios que no son de confianza, dominios con una confianza
unidireccional y demás bosques. En lugar de configurar los servidores de acceso
para que envíen las solicitudes de conexión a un servidor RADIUS NPS, puede
configurarlos para que envíen las solicitudes de conexión a un proxy RADIUS NPS.
El proxy RADIUS de NPS usa la parte del nombre de dominio kerberos del nombre
de usuario y reenvía la solicitud a un NPS en el dominio o bosque correctos. Los
intentos de conexión para las cuentas de usuario de un dominio o bosque se
pueden autenticar para nas en otro dominio o bosque.
Desea realizar la autenticación y autorización mediante una base de datos que no
es una base de datos de cuentas de Windows. En este caso, las solicitudes de
conexión que coincidan con un nombre de dominio kerberos especificado se
reenvían a un servidor RADIUS con acceso a una base de datos distinta de cuentas
de usuarios y datos de autorización. Los ejemplos de otras bases de datos de
usuarios incluyen bases de datos de Servicios de directorio Novell (NDS) y
Lenguaje de consulta estructurado (SQL).
Desea procesar una gran cantidad de solicitudes de conexión. En este caso, en
lugar de configurar los clientes RADIUS para intentar equilibrar las solicitudes de
conexión y las cuentas entre varios servidores RADIUS, puede configurarlos para
que envíen las solicitudes de conexión y cuentas a un proxy RADIUS NPS. El proxy
RADIUS NPS equilibra dinámicamente la carga de solicitudes de conexión y
cuentas entre varios servidores RADIUS y aumenta el procesamiento de grandes
cantidades de clientes RADIUS y autenticaciones por segundo.
Desea proporcionar autenticaciones y autorizaciones RADIUS para proveedores de
servicios externos y minimizar la configuración de firewall de intranet. El firewall de
intranet se encuentra entre la red perimetral (la red entre la intranet e Internet) y la
intranet. Al colocar un NPS en la red perimetral, el firewall entre la red perimetral y
la intranet debe permitir que el tráfico fluya entre NPS y varios controladores de
dominio. Al reemplazar el NPS por un proxy NPS, el firewall debe permitir que solo
fluya el tráfico RADIUS entre el proxy NPS y uno o varios NPS dentro de la intranet.

En la ilustración siguiente se muestra NPS como un proxy RADIUS entre los clientes
RADIUS y los servidores RADIUS.
Con NPS, las organizaciones también pueden subcontratar infraestructura de acceso a
un proveedor de servicios y, al mismo tiempo, mantener el control sobre la
autenticación, autorización y cuentas de usuarios.

Las configuraciones de NPS se pueden crear para los escenarios siguientes:

Acceso inalámbrico
Acceso remoto a la organización mediante acceso telefónico o de red privada
virtual (VPN)
Acceso inalámbrico o telefónico externo
Acceso a Internet
Acceso autenticado a recursos de una extranet para empresas asociadas

Ejemplos de configuraciones de servidor

RADIUS y proxy RADIUS
Los siguientes ejemplos de configuración muestran cómo se puede configurar NPS
como un servidor RADIUS y un proxy RADIUS.

NPS como servidor RADIUS. En este ejemplo, NPS se configura como un servidor
RADIUS, la directiva de solicitud de conexión predeterminada es la única directiva
configurada y el NPS local procesa todas las solicitudes de conexión. NpS puede
autenticar y autorizar a los usuarios cuyas cuentas están en el dominio de NPS y en
dominios de confianza.

NPS como proxy RADIUS. En este ejemplo, el NPS se configura como un proxy RADIUS
que reenvía solicitudes de conexión a grupos de servidores RADIUS remotos en dos
dominios que no son de confianza. Se elimina la directiva de solicitud de conexión
predeterminada y se crean dos nuevas directivas de solicitud de conexión para reenviar
solicitudes a cada uno de los dos dominios que no son de confianza. En este ejemplo,
NPS no procesa ninguna solicitud de conexión en el servidor local.

NPS como servidor RADIUS y proxy RADIUS. Además de la directiva predeterminada

de solicitud de conexión, que designa que las solicitudes de conexión se procesan
localmente, se crea una nueva directiva de solicitud de conexión que reenvía las
solicitudes de conexión a un servidor NPS u otro servidor RADIUS en un dominio que no
es de confianza. Esta segunda directiva se denomina directiva de proxy. En este ejemplo,
la directiva de proxy aparece la primera en la lista ordenada de directivas. Si la solicitud
de conexión coincide con la directiva de proxy, la solicitud de conexión se reenvía al
servidor RADIUS del grupo de servidores RADIUS remotos. Si la solicitud de conexión no
coincide con la directiva de proxy pero coincide con la directiva predeterminada de
solicitud de conexión, NPS procesa la solicitud de conexión en el servidor local. Si la
solicitud de conexión no coincide con ninguna de las dos directivas, se descarta.

NPS como servidor RADIUS con servidores de contabilidad remota. En este ejemplo,
el NPS local no está configurado para realizar la contabilidad y se revisa la directiva de
solicitud de conexión predeterminada para que los mensajes de contabilidad RADIUS se
reenvíen a un NPS u otro servidor RADIUS en un grupo de servidores RADIUS remoto.
Aunque los mensajes de contabilidad se reenvía, los mensajes de autenticación y
autorización no se reenvía, y el NPS local realiza estas funciones para el dominio local y
todos los dominios de confianza.

NPS con RADIUS remoto para Windows asignación de usuarios. En este ejemplo, NPS
actúa como servidor RADIUS y como proxy RADIUS para cada solicitud de conexión
individual ya que reenvía la solicitud de autenticación a un servidor RADIUS remoto y, al
mismo tiempo, usa la cuenta de usuario de Windows local para la autorización. Para
implementar esta configuración, se debe establecer el atributo Asignación de RADIUS
remota a usuario de Windows como una condición de la directiva de solicitud de
conexión. (Además, se debe crear una cuenta de usuario localmente en el servidor
RADIUS que tenga el mismo nombre que la cuenta de usuario remota con la que realiza
la autenticación el servidor RADIUS remoto).

Configuración
Para configurar NPS como un servidor RADIUS, puede usar la configuración estándar o
la configuración avanzada en la consola NPS o en Administrador del servidor. Para
configurar NPS como un proxy RADIUS, debe usar configuración avanzada.

Configuración estándar
Con la configuración estándar se proporcionan asistentes para ayudarle a configurar
NPS para los escenarios siguientes:

Servidor RADIUS para conexiones de acceso telefónico o VPN

Servidor RADIUS para conexiones 802.1X inalámbricas o por cable

Para configurar NPS con un asistente, abra la consola de NPS, seleccione uno de los
escenarios anteriores y haga clic en el vínculo que abre el asistente.

Configuración avanzada
Al usar la configuración avanzada, puede configurar NPS manualmente como servidor
RADIUS o proxy RADIUS.

Para configurar NPS mediante la configuración avanzada, abra la consola NPS y, a

continuación, haga clic en la flecha situada junto a Configuración avanzada para
expandir esta sección.

Se incluyen los siguientes elementos de configuración avanzada.

Configuración del servidor RADIUS

Para configurar NPS como un servidor RADIUS, debe configurar clientes RADIUS,
directivas de red y cuentas RADIUS.

Para obtener instrucciones sobre cómo realizar estas configuraciones, consulte los
temas siguientes.

Configurar clientes RADIUS

Configurar directivas de red
Configurar las cuentas de servidor de directivas de redes

Configuración del proxy RADIUS

Para configurar NPS como un proxy RADIUS, debe configurar clientes RADIUS, grupos
de servidores RADIUS remotos y directivas de solicitud de conexión.
Para obtener instrucciones sobre cómo realizar estas configuraciones, consulte los
temas siguientes.

Configurar clientes RADIUS

Configurar grupos de servidores RADIUS remotos
Configurar directivas de solicitud de conexión

Registro NPS
El registro NPS también se denomina contabilidad RADIUS. Configure el registro NPS
para sus requisitos si NPS se usa como servidor RADIUS, proxy o cualquier combinación
de estas configuraciones.

Para configurar el registro NPS, debe configurar los eventos que desea registrar y ver
con Visor de eventos y, a continuación, determinar qué otra información desea registrar.
Además, debe decidir si desea registrar información de cuentas y autenticación de
usuario en archivos de registro de texto almacenados en el equipo local o en una base
de datos de SQL Server en el equipo local o un equipo remoto.

Para obtener más información, vea Configurar la contabilidad del servidor de directivas
de red.
Procedimientos recomendados del
servidor de directivas de redes
Artículo • 21/12/2022 • Tiempo de lectura: 8 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información sobre los procedimientos
recomendados para implementar y administrar el servidor de directivas de red (NPS).

En las secciones siguientes se proporcionan procedimientos recomendados para

distintos aspectos de la implementación de NPS.

Control
Estos son los procedimientos recomendados para el registro de NPS.

Existen dos tipos de cuentas, o modos de registro, en NPS:

Registro de eventos para NPS. Puede usar el registro de eventos para registrar
eventos de NPS en los registros de eventos del sistema y de seguridad. Se usa
principalmente para supervisar y solucionar los intentos de conexión.

Registro de solicitudes de autenticación y contabilidad de usuarios. Puede registrar

las solicitudes de cuentas y autenticación de usuarios en archivos de registro con
formato de texto o formato de base de datos o bien registrarlas en un
procedimiento almacenado en una base de datos de SQL Server 2000. El registro
de solicitudes se usa principalmente con fines de facturación y análisis de
conexiones, y también es útil como herramienta de investigación de seguridad, lo
que proporciona un método para realizar un seguimiento de la actividad de un
atacante.

Para hacer un uso más efectivo del registro de NPS:

Active el registro (inicialmente) para los registros de autenticación y cuentas.

Modifique estas selecciones después de determinar qué es más apropiado para su
entorno.

Asegúrese de configurar el registro de eventos con una capacidad suficiente para

mantener sus registros.
 Realizar una copia de seguridad periódica de todos los archivos de registro porque
no se pueden volver a crear cuando están dañados o eliminados.

Use el atributo Class de RADIUS para registrar el uso y facilitar la identificación del
departamento o usuario al que debe cargarse el uso. Aunque el atributo Class que
se genera automáticamente es único para cada solicitud, es posible que se
produzcan registros duplicados en los casos en que la respuesta al servidor de
acceso se haya perdido y la solicitud se reenvíe. Es posible que tenga que eliminar
solicitudes duplicadas de sus registros para realizar un seguimiento preciso del
uso.

Si los servidores de acceso a la red y los servidores proxy RADIUS envían

periódicamente mensajes de solicitud de conexión ficticia a NPS para comprobar
que NPS está en línea, use la configuración del Registro de nombre de usuario
ping . Esta opción configura NPS para rechazar automáticamente estas solicitudes
de conexión falsas sin procesarlas. Además, NPS no registra las transacciones que
implican el nombre de usuario ficticio en ningún archivo de registro, lo que facilita
la interpretación del registro de eventos.

Deshabilite el reenvío de notificaciones nas. Puede deshabilitar el reenvío de

mensajes de inicio y de detenerse desde servidores de acceso de red (NAS) a
miembros de un grupo de servidores RADIUS remoto configurado en NPS. Para
obtener más información, vea Deshabilitar el reenvío de notificaciones NAS.

Para obtener más información, vea Configurar la contabilidad del servidor de directivas
de red.

Para ofrecer capacidad de conmutación por error y redundancia con el registro de

SQL Server, coloque dos equipos que ejecuten SQL Server en subredes diferentes.
Use el Asistente SQL Server crear publicación para configurar la replicación de
base de datos entre los dos servidores. Para obtener más información, consulte
SQL Server Technical Documentation y Replicación de SQL Server.

Authentication
A continuación, se incluyen recomendaciones para la autenticación.

Use métodos de autenticación basados en certificados, como el protocolo de

autenticación extensible protegido (PEAP) y el protocolo de autenticación
extensible (EAP) para una autenticación segura. No use métodos de autenticación
de solo contraseña porque son vulnerables a diversos ataques y no son seguros.
Para la autenticación inalámbrica segura, se recomienda usar PEAP-MS-CHAP v2,
 ya que NPS demuestra su identidad a los clientes inalámbricos mediante un
certificado de servidor, mientras que los usuarios demuestran su identidad con su
nombre de usuario y contraseña. Para obtener más información sobre el uso de
NPS en la implementación inalámbrica, vea Deploy Password-Based 802.1X
Authenticated Wireless Access .802.1X Authenticated Wireless Access
(Implementación del acceso inalámbrico autenticado por 802.1X).
Implemente su propia entidad de certificación (CA) con Active Directory®
Certificate Services (AD CS) cuando use métodos de autenticación seguros
basados en certificados, como PEAP y EAP, que requieren el uso de un certificado
de servidor en NPS. También puede usar su entidad de certificación para realizar
inscripciones de certificados de equipo y de usuario. Para obtener más información
sobre la implementación de certificados de servidor en servidores NPS y de acceso
remoto, vea Deploy Server Certificates for 802.1X Wired and Wireless Deployments
(Implementar certificados de servidor para implementaciones cableadas e
inalámbricas 802.1X).

） Importante

El servidor de directivas de red (NPS) no admite el uso de caracteres ASCII

extendidos dentro de las contraseñas.

Configuración del equipo cliente

A continuación, se incluyen recomendaciones para configurar el equipo cliente.

Configure automáticamente todos los equipos cliente del miembro de dominio

802.1X mediante directiva de grupo. Para obtener más información, vea la sección
"Configurar directivas de red inalámbrica (IEEE 802.11) " en el tema
Implementación de acceso inalámbrico.

Sugerencias de instalación
Estos son los procedimientos recomendados para instalar NPS.

Antes de instalar NPS, instale y pruebe cada uno de los servidores de acceso de
red mediante métodos de autenticación local antes de configurarlos como clientes
RADIUS en NPS.

Después de instalar y configurar NPS, guarde la configuración mediante Windows

PowerShell comando Export-NpsConfiguration. Guarde la configuración de NPS
 con este comando cada vez que vuelva a configurar nps.

Ｕ Precaución

El archivo de configuración NPS exportado contiene secretos compartidos sin

cifrar para clientes RADIUS y miembros de grupos de servidores RADIUS
remotos. Por este problema, asegúrese de guardar el archivo en una
ubicación segura.
El proceso de exportación no incluye la configuración de registro Microsoft
SQL Server en el archivo exportado. Si importa el archivo exportado a otro
NPS, debe configurar manualmente SQL Server registro en el nuevo servidor.

NPS de optimización del rendimiento

Estos son los procedimientos recomendados para la optimización del rendimiento de
NPS.

Para optimizar los tiempos de respuesta de autenticación y autorización de NPS y

reducir el tráfico de red, instale NPS en un controlador de dominio.

Cuando se usan nombres principales universales (UPN) o dominios de Windows

Server 2008 y Windows Server 2003, NPS usa el catálogo global para autenticar a
los usuarios. Para minimizar el tiempo que se tarda en hacerlo, instale NPS en un
servidor de catálogo global o en un servidor que se encuentra en la misma subred
que el servidor de catálogo global.

Cuando haya configurado grupos de servidores RADIUS remotos y, en Directivas

de solicitud de conexión nps, desactive la casilla Registrar información de
contabilidad en los servidores en la siguiente casilla de grupo de servidores
RADIUS remoto, estos grupos se seguirán enviados a los mensajes de inicio y de
detenerse de la notificación del servidor de acceso a la red (NAS). Esto genera un
tráfico de red innecesario. Para eliminar este tráfico, deshabilite el reenvío de
notificaciones NAS para servidores individuales de cada grupo de servidores
RADIUS remotos desactivando la casilla Reenviar inicio de red y detener
notificaciones a este servidor .

Uso de NPS en organizaciones grandes

Estos son los procedimientos recomendados para usar NPS en organizaciones grandes.
 Si usa directivas de red para restringir el acceso a todos los grupos, pero a
determinados grupos, cree un grupo universal para todos los usuarios a los que
desea permitir el acceso y, a continuación, cree una directiva de red que conceda
acceso a este grupo universal. No incluya a todos los usuarios directamente en el
grupo universal, especialmente si hay muchos usuarios en su red. En lugar de ello,
cree grupos separados que pertenezcan al grupo universal y agregue usuarios a
esos grupos.

Siempre que sea posible, use nombres principales de usuario para hacer referencia
a los usuarios. Un usuario puede tener el mismo nombre principal de usuario al
margen del dominio al que pertenezca. Esta práctica proporciona la escalabilidad
necesaria a las organizaciones que tienen un elevado número de dominios.

Si instaló el servidor de directivas de red (NPS) en un equipo que no sea un

controlador de dominio y nps recibe un gran número de solicitudes de
autenticación por segundo, puede mejorar el rendimiento de NPS si aumenta el
número de autenticaciones simultáneas permitidas entre nps y el controlador de
dominio. Para obtener más información, vea Aumentar las autenticaciones
simultáneas procesadas por NPS.

Problemas de seguridad
Estos son los procedimientos recomendados para reducir los problemas de seguridad.

Cuando administre un NPS de forma remota, no envíe datos confidenciales o

confidenciales (por ejemplo, secretos o contraseñas compartidos) a través de la red en
texto no cifrado. Hay dos métodos recomendados para la administración remota de
NPS:

Use Servicios de Escritorio remoto para acceder a NPS. Cuando se usa Servicios de
Escritorio remoto, los datos no se envían entre el cliente y el servidor. Solo se envía
la interfaz de usuario del servidor (por ejemplo, el escritorio del sistema operativo
y la imagen de la consola NPS) al cliente de Servicios de Escritorio remoto, que se
denomina Conexión a Escritorio remoto en Windows ® 10. El cliente envía la
entrada del teclado y del mouse, que el servidor que ha Servicios de Escritorio
remoto localmente. Cuando Servicios de Escritorio remoto los usuarios inician
sesión, solo pueden ver sus sesiones de cliente individuales, que administra el
servidor y son independientes entre sí. Además, la Conexión a Escritorio remoto
permite el cifrado de 128 bits entre cliente y servidor.

Usar el protocolo de seguridad de Internet (IPsec) para cifrar datos confidenciales.

Puede usar IPsec para cifrar la comunicación entre NPS y el equipo cliente remoto
 que usa para administrar NPS. Para administrar el servidor de forma remota, puede
instalar el Herramientas de administración remota del servidor para Windows 10
en el equipo cliente. Después de la instalación, use Microsoft Management
Console (MMC) para agregar el complemento NPS a la consola.

） Importante

Puede instalar Herramientas de administración remota del servidor para Windows

10 solo en la versión completa de Windows 10 Professional o Windows 10
Enterprise.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Tareas iniciales con el servidor de
directivas de redes
Artículo • 29/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar los temas de esta sección para obtener información sobre las características
y funcionalidades del servidor de directivas de red.

７ Nota

Para obtener documentación adicional del servidor de directivas de red, puede usar
las siguientes secciones de la biblioteca.

Planear el servidor de directivas de redes

Implementar el servidor de directivas de redes
Administrar el servidor de directivas de redes

Esta sección contiene los temas siguientes.

Procesamiento de solicitudes de conexión

Directivas de red
Plantillas de NPS
Clientes RADIUS
Procesamiento de solicitudes de
conexión
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información sobre el procesamiento de solicitudes
de conexión en el servidor de directivas de red en Windows Server 2016.

７ Nota

Además de este tema, está disponible la siguiente documentación de

procesamiento de solicitudes de conexión.

Directivas de solicitud de conexión

Nombres de dominio kerberos
Grupos de servidores RADIUS remotos

Puede usar el procesamiento de solicitudes de conexión para especificar dónde se

realiza la autenticación de las solicitudes de conexión: en el equipo local o en un
servidor RADIUS remoto que sea miembro de un grupo de servidores RADIUS remoto.

Si desea que el servidor local que ejecuta el servidor de directivas de red (NPS) realice la
autenticación para las solicitudes de conexión, puede usar la directiva de solicitud de
conexión predeterminada sin configuración adicional. Basándose en la directiva
predeterminada, NPS autentica a los usuarios y equipos que tienen una cuenta en el
dominio local y en dominios de confianza.

Si desea reenviar solicitudes de conexión a un NPS remoto u otro servidor RADIUS, cree
un grupo de servidores RADIUS remoto y, a continuación, configure una directiva de
solicitud de conexión que reenvíe las solicitudes a ese grupo de servidores RADIUS
remoto. Con esta configuración, NPS puede reenviar solicitudes de autenticación a
cualquier servidor RADIUS, y los usuarios con cuentas en dominios que no son de
confianza pueden ser autenticados.

La ilustración siguiente muestra la ruta de un mensaje de solicitud de acceso desde un

servidor de acceso a la red a un proxy RADIUS y, a continuación, a un servidor RADIUS
de un grupo del servidor RADIUS remoto. En el proxy RADIUS, el servidor de acceso a la
red se configura como un cliente RADIUS; y en cada servidor RADIUS, el proxy RADIUS
se configura como un cliente RADIUS.

７ Nota

Los servidores de acceso a la red que usa con NPS pueden ser dispositivos de
puerta de enlace compatibles con el protocolo RADIUS, como puntos de acceso
inalámbricos 802.1X y conmutadores de autenticación, servidores que ejecutan
acceso remoto configurados como servidores VPN o de acceso telefónico u otros
dispositivos compatibles con RADIUS.

Si desea que NPS procese algunas solicitudes de autenticación localmente y reenvíe

otras solicitudes a un grupo del servidor RADIUS remoto, configure más de una directiva
de solicitud de conexión.

Para configurar una directiva de solicitud de conexión que especifique qué NPS o grupo
de servidores RADIUS procesa las solicitudes de autenticación, consulte Directivas de
solicitud de conexión.

Para especificar NPS u otros servidores RADIUS a los que se reenvía las solicitudes de
autenticación, consulte Grupos de servidores RADIUS remotos.

NPS como un procesamiento de solicitudes de

conexión de servidor RADIUS
Cuando se usa NPS como servidor RADIUS, los mensajes RADIUS proporcionan
autenticación, autorización y contabilidad para las conexiones de acceso a la red de la
siguiente manera:

1. Los servidores de acceso, como los servidores de acceso telefónico a la red, los
servidores VPN y los puntos de acceso inalámbrico reciben solicitudes de conexión
de clientes de acceso.

2. El servidor de acceso, configurado para usar RADIUS como protocolo de

autenticación, autorización y contabilidad, crea un mensaje de Access-Request y lo
 envía al NPS.

3. NpS evalúa el mensaje de Access-Request.

4. Si es necesario, NPS envía un mensaje Access-Challenge al servidor de acceso. El

servidor de acceso procesa el desafío y envía un Access-Request actualizado al
NPS.

5. Las credenciales de usuario se comprueban y las propiedades de acceso telefónico

de la cuenta de usuario se obtienen por medio de una conexión segura con un
controlador de dominio.

6. El intento de conexión se autoriza con las propiedades de acceso telefónico de la

cuenta de usuario y las directivas de red.

7. Si el intento de conexión está autenticado y autorizado, NPS envía un mensaje de

Access-Accept al servidor de acceso. Si el intento de conexión no está autenticado
o no está autorizado, NPS envía un mensaje de Access-Reject al servidor de
acceso.

8. El servidor de acceso completa el proceso de conexión con el cliente de acceso y

envía un mensaje Accounting-Request al NPS, donde se registra el mensaje.

9. NpS envía un Accounting-Response al servidor de acceso.

７ Nota

Asimismo, el servidor de acceso envía mensajes de solicitud de registro de

actividad cuando la conexión se establece, cuando la conexión del cliente de
acceso se cierra y cuando el servidor de acceso se inicia y detiene.

NPS como procesamiento de solicitudes de

conexión de proxy RADIUS
Cuando NPS se usa como proxy RADIUS entre un cliente RADIUS y un servidor RADIUS,
los mensajes RADIUS para los intentos de conexión de acceso a la red se reenvían del
siguiente modo:

1. Los servidores de acceso, tales como los servidores de acceso telefónico a la red,
los servidores de red privada virtual (VPN) y los puntos de acceso inalámbrico,
reciben las solicitudes de conexión de los clientes de acceso.
 2. El servidor de acceso, configurado para usar RADIUS como protocolo de
autenticación, autorización y contabilidad, crea un mensaje de Access-Request y lo
envía al NPS que se usa como proxy RADIUS nps.

3. El proxy RADIUS NPS recibe el mensaje de solicitud de acceso y, basándose en las

directivas de solicitud de conexión configuradas localmente, determina adónde
reenviar el mensaje de solicitud de acceso.

4. El proxy RADIUS NPS reenvía el mensaje de solicitud de acceso al servidor RADIUS

correspondiente.

5. El servidor RADIUS evalúa el mensaje de solicitud de acceso.

6. Si es necesario, el servidor RADIUS envía un mensaje de desafío de acceso al proxy

RADIUS NPS, desde donde se reenvía al servidor de acceso. El servidor de acceso
procesa el desafío con el cliente de acceso y envía una solicitud de acceso
actualizada al proxy RADIUS NPS, desde donde se reenvía al servidor RADIUS.

7. El servidor RADIUS autentica y autoriza el intento de conexión.

8. Si se autentica y autoriza el intento de conexión, el servidor RADIUS envía un

mensaje de aceptación de acceso al proxy RADIUS NPS, desde donde se reenvía al
servidor de acceso. Si no se autentica o autoriza el intento de conexión, el servidor
RADIUS envía un mensaje de rechazo de acceso al proxy RADIUS NPS, desde
donde se reenvía al servidor de acceso.

9. El servidor de acceso completa el proceso de conexión con el cliente de acceso y

envía un mensaje de solicitud de registro de actividad al proxy RADIUS NPS. El
proxy RADIUS NPS registra los datos de cuentas y reenvía el mensaje al servidor
RADIUS.

10. El servidor RADIUS envía un mensaje de respuesta de cuenta al proxy RADIUS NPS,
desde donde se reenvía al servidor de acceso.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Directivas de solicitud de conexión
Artículo • 21/09/2022 • Tiempo de lectura: 18 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para aprender a usar directivas de solicitud de conexión NPS para
configurar nps como un servidor RADIUS, un proxy RADIUS o ambos.

７ Nota

Además de este tema, está disponible la siguiente documentación de directiva de

solicitud de conexión.

Configurar directivas de solicitud de conexión

Configurar grupos de servidores RADIUS remotos

Las directivas de solicitud de conexión son conjuntos de condiciones y configuraciones

que permiten a los administradores de red designar qué servidores de Servicio de
autenticación remota telefónica de usuario (RADIUS) realizan la autenticación y
autorización de las solicitudes de conexión que el servidor que ejecuta servidor de
directivas de red (NPS) recibe de los clientes RADIUS. Las directivas de solicitud de
conexión se pueden configurar para designar los servidores RADIUS que se usan para
las cuentas RADIUS.

Puede crear directivas de solicitud de conexión para que algunos mensajes de solicitud
RADIUS enviados desde clientes RADIUS se procesen localmente (NPS se usa como
servidor RADIUS) y otros tipos de mensajes se reenván a otro servidor RADIUS (NPS se
usa como proxy RADIUS).

Con las directivas de solicitud de conexión, puede usar NPS como servidor RADIUS o
como proxy RADIUS, en función de factores como los siguientes:

La hora del día y el día de la semana

El nombre de dominio kerberos en la solicitud de conexión
El tipo de conexión que se solicita
La dirección IP del cliente RADIUS

NPS Access-Request o reenvía los mensajes radius solo si la configuración del mensaje
entrante coincide con al menos una de las directivas de solicitud de conexión
configuradas en nps.
Si la configuración de directiva coincide y la directiva requiere que NPS procese el
mensaje, NPS actúa como un servidor RADIUS, autenticando y autorizando la solicitud
de conexión. Si la configuración de directiva coincide y la directiva requiere que NPS
reenvía el mensaje, NPS actúa como proxy RADIUS y reenvía la solicitud de conexión a
un servidor RADIUS remoto para su procesamiento.

Si la configuración de un mensaje entrante de solicitud de acceso RADIUS no coincide

como mínimo con una de las directivas de solicitud de conexión, se envía un mensaje de
rechazo de acceso al cliente RADIUS y se deniega el acceso al usuario o al equipo que
intenta conectarse a la red.

Ejemplos de configuración
En los ejemplos de configuración siguientes se muestra cómo puede usar directivas de
solicitud de conexión.

NPS como servidor RADIUS

La directiva de solicitud de conexión predeterminada es la única directiva configurada.
En este ejemplo, NPS se configura como un servidor RADIUS y nps local procesa todas
las solicitudes de conexión. NPS puede autenticar y autorizar a los usuarios cuyas
cuentas están en el dominio del dominio NPS y en dominios de confianza.

NPS como proxy RADIUS

La directiva de solicitud de conexión predeterminada se elimina y se crean dos nuevas
directivas de solicitud de conexión para reenviar solicitudes a dos dominios diferentes.
En este ejemplo, NPS se configura como un proxy RADIUS. NPS no procesa ninguna
solicitud de conexión en el servidor local. En su lugar, reenvía las solicitudes de conexión
a un servidor NPS o a otros servidores RADIUS configurados como miembros de grupos
de servidores RADIUS remotos.

NPS como servidor RADIUS y proxy RADIUS

Además de la directiva de solicitud de conexión predeterminada, se crea una nueva
directiva de solicitud de conexión que reenvía solicitudes de conexión a NPS u otro
servidor RADIUS en un dominio que no es de confianza. En este ejemplo, la directiva de
proxy aparece en primer lugar en la lista ordenada de directivas. Si la solicitud de
conexión coincide con la directiva de proxy, la solicitud de conexión se reenvía al
servidor RADIUS en el grupo de servidores remotos RADIUS. Si la solicitud de conexión
no coincide con la directiva proxy pero sí coincide con la directiva de solicitud de
conexión predeterminada, NPS procesa la solicitud de conexión en el servidor local. Si la
solicitud de conexión no coincide con ninguna de las dos directivas, se descarta.

NPS como servidor RADIUS con servidores de cuentas

remotas
En este ejemplo, el NPS local no está configurado para realizar la contabilidad y se
revisa la directiva de solicitud de conexión predeterminada para que los mensajes de
contabilidad RADIUS se reenván a un servidor NPS u otro servidor RADIUS en un grupo
de servidores RADIUS remoto. Aunque los mensajes de contabilidad se reenván, los
mensajes de autenticación y autorización no se reenvía, y nps local realiza estas
funciones para el dominio local y todos los dominios de confianza.

NPS con asignación de RADIUS remota a usuario de

Windows
En este ejemplo, NPS actúa como servidor RADIUS y como proxy RADIUS para cada
solicitud de conexión individual ya que reenvía la solicitud de autenticación a un
servidor RADIUS remoto y, al mismo tiempo, usa la cuenta de usuario de Windows local
para la autorización. Para implementar esta configuración, se debe establecer el atributo
Asignación de RADIUS remota a usuario de Windows como una condición de la
directiva de solicitud de conexión. (Además, se debe crear una cuenta de usuario local
que tenga el mismo nombre que la cuenta de usuario remota que será la que usará el
servidor RADIUS remoto para realizar la autenticación.)

Condiciones de la directiva de solicitud de

conexión
Las condiciones de la directiva de solicitud de conexión son uno o más atributos
RADIUS que se comparan con los atributos del mensaje de solicitud de acceso RADIUS
entrante. Si hay varias condiciones, entonces todas las condiciones del mensaje de
solicitud de conexión y de la directiva de solicitud de conexión deben coincidir para que
la directiva sea aplicada por NPS.

Los siguientes son los atributos de condición que se pueden configurar en las directivas
de solicitud de conexión.

Grupo de atributos propiedades de conexión

El grupo de atributos Propiedades de la conexión contiene los siguientes atributos.

Protocolo enmarcado. Se usa para designar el tipo de entramado para los

paquetes entrantes. Algunos ejemplos son Protocolo punto a punto (PPP), Serial
Line Internet Protocol (SLIP), Frame Relay y X.25.
Tipo de servicio. Se usa para designar el tipo de servicio que se solicita. Entre los
ejemplos se incluyen entramados (por ejemplo, conexiones PPP) y de inicio de
sesión (por ejemplo, conexiones Telnet). Para obtener más información acerca de
los tipos de servicio RADIUS, consulte la RFC 2865, que se refiere al Servicio de
autenticación remota telefónica de usuario (RADIUS).
Tipo de túnel. Se usa para designar el tipo de túnel que está creando el cliente
que realiza la solicitud. Entre los tipos de túnel se incluyen el protocolo de túnel
punto a punto (PPTP) y el protocolo de túnel de capa dos (L2TP).

Grupo de atributos Restricciones de día y hora

El grupo de atributos Restricciones de día y hora contiene un atributo de Restricciones
de día y hora. Con este atributo, puede designar el día de la semana y la hora del día del
intento de conexión. El día y la hora son relativos al día y la hora de NPS.

Grupo de atributos de puerta de enlace

El grupo de atributos Puerta de enlace contiene los siguientes atributos.

Se denomina Id. de estación. Se usa para designar el número de teléfono del

servidor de acceso a la red. Este atributo es una cadena de caracteres. Puede usar
una sintaxis de coincidencia de patrón para especificar códigos de área.
Identificador de NAS. Se usa para designar el nombre del servidor de acceso a la
red. Este atributo es una cadena de caracteres. Puede usar una sintaxis de
coincidencia de patrón para especificar identificadores de NAS.
Dirección IPv4 de NAS. Se usa para designar la dirección del Protocolo de Internet
versión 4 (IPv4) del servidor de acceso a la red (el cliente RADIUS). Este atributo es
una cadena de caracteres. Puede usar una sintaxis de coincidencia de patrón para
especificar redes IP.
Dirección IPv6 de NAS. Se usa para designar la dirección del Protocolo de Internet
versión 6 (IPv6) del servidor de acceso a la red (el cliente RADIUS). Este atributo es
una cadena de caracteres. Puede usar una sintaxis de coincidencia de patrón para
especificar redes IP.
Tipo de puerto NAS. Se usa para designar el tipo de medios usados por el cliente
de acceso. Algunos ejemplos son las líneas telefónicas análogas (conocidas como
 async), la red digital de servicios integrados (ISDN), los túneles o las redes privadas
virtuales (VPN), los conmutadores inalámbricos IEEE 802.11 y Ethernet.

Grupo de atributos de Identidad de máquina

El grupo de atributos ///Identidad del equipo contiene el atributo ///Identidad del
equipo. Mediante este atributo, puede especificar el método con el que se identifican
los clientes en la directiva.

Grupo de atributos propiedades de cliente RADIUS

El grupo de atributos Propiedades del cliente RADIUS contiene los siguientes atributos.

Identificador de la estación de llamada. Se usa para designar el número de

teléfono usado por quien llama (el cliente de acceso). Este atributo es una cadena
de caracteres. Puede usar una sintaxis de coincidencia de patrón para especificar
códigos de área. En las autenticaciones 802.1x, la dirección MAC normalmente se
rellena y puede coincidir con el cliente. Este campo se usa normalmente para
escenarios de omisión de direcciones Mac cuando la directiva de solicitud de
conexión está configurada para "Aceptar usuarios sin validar credenciales".
Nombre descriptivo del cliente. Se usa para designar el nombre del equipo cliente
RADIUS que solicita autenticación. Este atributo es una cadena de caracteres.
Puede usar una sintaxis de coincidencia de patrón para especificar nombres de
cliente.
Dirección IPv4 del cliente. Se usa para designar la dirección IPv4 del servidor de
acceso a la red (el cliente RADIUS). Este atributo es una cadena de caracteres.
Puede usar una sintaxis de coincidencia de patrón para especificar redes IP.
Dirección IPv6 del cliente. Se usa para designar la dirección IPv6 del servidor de
acceso a la red (el cliente RADIUS). Este atributo es una cadena de caracteres.
Puede usar una sintaxis de coincidencia de patrón para especificar redes IP.
Proveedor de cliente. Se usa para designar el proveedor del servidor de acceso a
la red que solicita autenticación. Un equipo que ejecuta el Servicio de
enrutamiento y acceso remoto es el fabricante de Microsoft NAS. Puede usar este
atributo para configurar directivas independientes para diferentes fabricantes de
NAS. Este atributo es una cadena de caracteres. Puede usar una sintaxis de
coincidencia de patrón.

Grupo de atributos de nombre de usuario

El grupo de atributos Nombre de usuario contiene el atributo Nombre de usuario. Con
este atributo, puede designar el nombre de usuario, o una parte del nombre de usuario,
que debe coincidir con el nombre de usuario proporcionado por el cliente de acceso en
el mensaje RADIUS. Este atributo es una cadena de caracteres que normalmente
contiene un nombre de dominio kerberos y un nombre de cuenta de usuario. Puede
usar una sintaxis de coincidencia de patrón para especificar nombres de usuario.

Configuración de la directiva de solicitud de

conexión
La configuración de la directiva de solicitud de conexión es un conjunto de propiedades
que se aplican a un mensaje RADIUS entrante. Configuración constan de los siguientes
grupos de propiedades.

Authentication
Control
Manipulación de atributos
Reenviando solicitud
Avanzado

En las secciones siguientes se proporcionan detalles adicionales sobre esta

configuración.

Authentication
Con esta configuración, puede invalidar la configuración de autenticación que se
configura en todas las directivas de red y puede designar los métodos y tipos de
autenticación necesarios para conectarse a la red.

） Importante

Si configura un método de autenticación en la directiva de solicitud de conexión

menos seguro que el método de autenticación que configure en la directiva de red,
se invalida el método de autenticación más seguro que configure en la directiva de
red. Por ejemplo, si tiene una directiva de red que requiere el uso del protocolo de
autenticación extensible protegido Protocol-Microsoft Challenge Handshake
Authentication Versión 2 (PEAP-MS-CHAP v2), que es un método de autenticación
basado en contraseña para la conexión inalámbrica segura, y también configura
una directiva de solicitud de conexión para permitir el acceso no autenticado, el
resultado es que no se requiere que ningún cliente se autentique mediante PEAP-
MS-CHAP v2. En este ejemplo, se concede a todos los clientes que se conectan a la
red un acceso no autenticado.
Control
Con esta configuración, puede configurar la directiva de solicitud de conexión para
reenviar información de contabilidad a un servidor NPS u otro servidor RADIUS en un
grupo de servidores RADIUS remoto para que el grupo de servidores RADIUS remoto
realice la contabilidad.

７ Nota

Si tiene varios servidores RADIUS y desea que la información de cuentas para todos
los servidores se almacene en una base de datos de cuentas RADIUS central, puede
usar la configuración de cuentas de la directiva de solicitud de conexión en una
directiva en cada servidor RADIUS para reenviar datos de cuentas de todos los
servidores a un servidor NPS o u otro servidor RADIUS que se designa como
servidor de cuentas.

La configuración de la cuenta de la directiva de solicitud de conexión funciona

independientemente de la configuración de contabilidad del NPS local. En otras
palabras, si configura nps local para registrar la información de contabilidad RADIUS en
un archivo local o en una base de datos Microsoft SQL Server, lo hará
independientemente de si configura una directiva de solicitud de conexión para reenviar
mensajes de contabilidad a un grupo de servidores RADIUS remoto.

Si desea que la información de contabilidad se haya registrado de forma remota, pero

no localmente, debe configurar el NPS local para que no realice la contabilidad, al
tiempo que configura la contabilidad en una directiva de solicitud de conexión para
reenviar los datos de contabilidad a un grupo de servidores RADIUS remoto.

Manipulación de atributos
Puede configurar un conjunto de reglas de búsqueda y reemplazo que manipulan las
cadenas de texto de uno de los atributos siguientes.

Nombre de usuario
Identificador de estación llamada
Identificador de estación que llama

El procesamiento de la regla de buscar y reemplazar se produce para uno de los

atributos precedentes antes de que el mensaje RADIUS se someta a la configuración de
autenticación y administración de cuentas. Las reglas de manipulación de atributos se
aplican a un solo atributo. No puede configurar reglas de manipulación de atributos
para cada atributo. Además, la lista de atributos que se pueden manipular es una lista
estática: no se pueden agregar atributos a la lista de atributos disponibles para su
manipulación.

７ Nota

Si usa el protocolo de autenticación MS-CHAP v2, no puede manipular el atributo

de Nombre de usuario si la directiva de solicitud de conexión se usa para reenviar
el mensaje RADIUS. La única excepción se produce cuando se usa un carácter de
barra diagonal inversa () y la manipulación solo afecta a la información de la
izquierda. El carácter de barra diagonal inversa se usa normalmente para indicar un
nombre de dominio (la información a la izquierda del carácter de barra diagonal
inversa) y el nombre de una cuenta de usuario dentro del dominio (la información a
la derecha del carácter de barra diagonal inversa). En este caso, sólo se permiten las
reglas de manipulación de atributos que modifican o reemplazan el nombre de
dominio.

Para obtener ejemplos de cómo manipular el nombre de dominio en el atributo Nombre

de usuario, vea la sección "Ejemplos para la manipulación del nombre de dominio en el
atributo de nombre de usuario" en el tema Usar expresiones regulares en NPS.

Reenviando solicitud
Puede establecer las siguientes opciones de reenvío de solicitud que se usan para
mensajes de solicitud de acceso de RADIUS:

Autentique las solicitudes en este servidor. Con esta configuración, NPS usa un
dominio de Windows NT 4.0, Active Directory o la base de datos de cuentas de
usuario del Administrador de cuentas de seguridad (SAM) local para autenticar la
solicitud de conexión. Esta configuración también especifica que la directiva de red
coincidente que se configura en NPS, junto con las propiedades de marcado de la
cuenta de usuario, sean usadas por NPS para autorizar la solicitud de conexión. En
este caso, NPS está configurado para actuar como servidor RADIUS.

Reenvía las solicitudes al siguiente grupo de servidores RADIUS remotos. Con

esta configuración, NPS reenvía las solicitudes de conexión al grupo de servidores
RADIUS remoto que especifique. Si NPS recibe un mensaje Access-Accept válido
que corresponde al mensaje Access-Request, el intento de conexión se considera
autenticado y autorizado. En este caso, NPS actúa como proxy RADIUS.
 Acepte usuarios sin validar las credenciales. Con esta configuración, NPS no
comprueba la identidad del usuario que intenta conectarse a la red y NPS no
intenta comprobar que el usuario o equipo tiene derecho a conectarse a la red.
Cuando NPS se configura para permitir el acceso no autenticado y recibe una
solicitud de conexión, NPS envía de inmediato un mensaje de aceptación de
acceso al cliente RADIUS y se concede al usuario o el equipo acceso a la red. Esta
configuración se usa para algunos tipos de tunelización obligatoria en las que el
cliente de acceso se tunela antes de que se autentiquen las credenciales de
usuario.

７ Nota

Esta opción de autenticación no se puede usar cuando el protocolo de

autenticación del cliente de acceso es MS-CHAP v2 o Autenticación extensible
Protocol-Transport Layer Security (EAP-TLS), que proporcionan autenticación
mutua. En la autenticación mutua, el cliente de acceso demuestra que es un cliente
de acceso válido al servidor de autenticación (NPS) y el servidor de autenticación
demuestra que es un servidor de autenticación válido para el cliente de acceso.
Cuando se usa esta opción de autenticación, se devuelve el mensaje de aceptación
de acceso. Sin embargo, el servidor de autenticación no proporciona validación al
cliente de acceso y se produce un error en la autenticación mutua.

Para obtener ejemplos de cómo usar expresiones regulares para crear reglas de
enrutamiento que reenvía mensajes RADIUS con un nombre de dominio kerberos
especificado a un grupo de servidores RADIUS remotos, vea la sección "Ejemplo de
reenvío de mensajes RADIUS por un servidor proxy" en el tema Usar expresiones
regulares en NPS.

Avanzado
Puede configurar propiedades avanzadas para especificar la serie de atributos RADIUS
que son:

Se agrega al mensaje de respuesta RADIUS cuando se usa NPS como servidor de

autenticación o contabilidad RADIUS. Cuando hay atributos especificados en una
directiva de red y la directiva de solicitud de conexión, los atributos que se envían
al mensaje de respuesta RADIUS son la combinación de ambos conjuntos de
atributos.
Se agrega al mensaje RADIUS cuando se usa NPS como autenticación RADIUS o
proxy de contabilidad. Si el atributo ya existe en el mensaje que se reenvía, se
 reemplaza por el valor del atributo especificado en la directiva de solicitud de
conexión.

Además, algunos atributos que están disponibles para la configuración en la directiva de

solicitud de conexión Configuración pestaña de la categoría Avanzadas proporcionan
funcionalidad especializada. Por ejemplo, puede configurar radius remoto para que
Windows asignación de usuarios cuando desee dividir la autenticación y autorización de
una solicitud de conexión entre dos bases de datos de cuentas de usuario.

El atributo Remote RADIUS to Windows User Mapping (RADIUS remoto para Windows
asignación de usuarios) especifica que Windows autorización para los usuarios
autenticados por un servidor RADIUS remoto. En otras palabras, un servidor RADIUS
remoto realiza la autenticación en una cuenta de usuario de una base de datos de
cuentas de usuario remota, pero nps local autoriza la solicitud de conexión en una
cuenta de usuario en una base de datos de cuentas de usuario local. Esto resulta útil
cuando se desea permitir el acceso a la red por parte de visitantes.

Por ejemplo, los visitantes de organizaciones asociadas pueden autenticarse mediante

su propio servidor RADIUS de organización asociada y, a continuación, usar una cuenta
de usuario de Windows en su organización para acceder a una red de área local invitado
(LAN) en la red.

Otros atributos que proporcionan funciones especializadas son:

MS-Quarantine-IPFilter y MS-Quarantine-Session-Timeout. Estos atributos se

usan al implementar el Control de cuarentena de acceso a la red (NAQC) con la
implementación de VPN de Enrutamiento y acceso remoto.
Passport-User-Mapping-UPN-Suffix. Este atributo permite autenticar solicitudes
de conexión con credenciales de cuenta de usuario de identificador Windows
Live™.
Tunnel-Tag. Este atributo designa el número de identificador de VLAN al que la
conexión debe ser asignada por el NAS cuando se implementan redes de área
local virtuales (VLAN).

Directiva de solicitud de conexión

predeterminada
Al instalar NPS se crea una directiva de solicitud de conexión predeterminada. Esta
directiva tiene la siguiente configuración.

Autenticación no se configura.
 Cuentas no se configura para reenviar información de cuentas a un grupo de
servidores remotos RADIUS.
Atributo no se configura con reglas de manipulación de atributos que reenvían
solicitudes de conexión a grupos de servidores remotos RADIUS.
La solicitud de reenvío está configurada para que las solicitudes de conexión se
autentiquen y autorice en el NPS local.
Los atributos de Opciones avanzadas no se configuran.

La directiva de solicitud de conexión predeterminada usa NPS como servidor RADIUS.

Para configurar un servidor que ejecuta NPS para funcionar como proxy RADIUS,
también debe configurar un grupo de servidores remotos RADIUS. Puede crear un
nuevo grupo de servidores RADIUS remotos mientras crea una nueva directiva de
solicitud de conexión mediante el Asistente para nueva directiva de solicitud de
conexión. Puede eliminar la directiva de solicitud de conexión predeterminada o
comprobar que la directiva de solicitud de conexión predeterminada es la última
directiva procesada por NPS colocándola en último lugar en la lista ordenada de
directivas.

７ Nota

Si NPS y el servicio de acceso remoto están instalados en el mismo equipo y el

servicio de acceso remoto está configurado para la autenticación y la contabilidad
de Windows, es posible que las solicitudes de autenticación y contabilidad de
acceso remoto se reenvía a un servidor RADIUS. Esto puede ocurrir cuando las
solicitudes de autenticación y contabilidad de acceso remoto coinciden con una
directiva de solicitud de conexión configurada para reenviarlas a un grupo de
servidores RADIUS remoto.
Nombres de dominio kerberos
Artículo • 18/01/2023 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información general sobre el uso de nombres de
dominio kerberos en el procesamiento de solicitudes de conexión del servidor de
directivas de red.

El atributo RADIUS de nombre de usuario es una cadena de caracteres que

normalmente contiene una ubicación de cuenta de usuario y un nombre de cuenta de
usuario. La ubicación de cuenta de usuario también se denomina dominio kerberos o
nombre de dominio kerberos, y es sinónimo del concepto de dominio, incluidos los
dominios DNS, los dominios de Active Directory® y los dominios de Windows NT 4.0.
Por ejemplo, si una cuenta de usuario está ubicada en la base de datos de cuentas de
usuarios para un dominio llamado [Link], [Link] es el nombre de dominio
kerberos.

En otro ejemplo, si el atributo User-Name RADIUS contiene el nombre

user1@[Link] usuario , user1 es el nombre de la cuenta de usuario y
[Link] es el nombre del dominio kerberos. Los nombres de dominio kerberos se
pueden presentar en el nombre de usuario como un prefijo o como un sufijo:

Example\user1. En este ejemplo, el nombre de dominio kerberos Example es un

prefijo; y también es el nombre de un dominio de Active Directory® Domain
Services (AD DS).

user1@[Link]. En este ejemplo, el nombre del dominio kerberos

[Link] es un sufijo; y es un nombre de dominio DNS o el nombre de un
dominio de AD DS.

Puede usar los nombres de dominio kerberos configurados en las directivas de solicitud
de conexión mientras diseña e implementa la infraestructura de RADIUS para garantizar
que las solicitudes de conexión se enrutan desde los clientes RADIUS, llamados también
servidores de acceso a la red, a servidores RADIUS que pueden autenticar y autorizar la
solicitud de conexión.

Cuando NPS se configura como un servidor RADIUS con la directiva de solicitud de

conexión predeterminada, NPS procesa las solicitudes de conexión para el dominio en el
que NPS es miembro y para dominios de confianza.
Para configurar NPS para que actúe como proxy RADIUS y reenvíe las solicitudes de
conexión a dominios que no son de confianza, debe crear una directiva de solicitud de
conexión nueva. En la nueva directiva de solicitud de conexión, debe configurar el
atributo de nombre de usuario con el nombre de dominio kerberos que se incluirá en el
atributo de nombre de usuario para las solicitudes de conexión que desea reenviar.
Además, debe configurar la directiva de solicitud de conexión con un grupo de
servidores RADIUS remoto. La directiva de solicitud de conexión permite a NPS calcular
las solicitudes de conexión que se reenvían al grupo de servidores RADIUS remoto
según la parte del dominio kerberos del atributo de nombre de usuario.

Adquisición del nombre de dominio kerberos

La parte del nombre de dominio kerberos incluida en el nombre de usuario se
suministra cuando el usuario escribe las credenciales basadas en contraseña durante un
intento de conexión o cuando se configura un perfil de Connection Manager (CM) en el
equipo del usuario para proporcionar el nombre de dominio kerberos automáticamente.

Puede designar que los usuarios de la red suministren el nombre de dominio kerberos
cuando escriban sus credenciales en los intentos de conexión a la red.

Por ejemplo, puede requerir que los usuarios escriban su nombre de usuario, incluido el
nombre de la cuenta de usuario y el nombre del dominio kerberos, en Nombre de
usuario en el cuadro de diálogo Conectar al realizar una conexión de red privada virtual
(VPN) o de acceso telefónico.

Además, si crea un paquete personalizado de conexiones de acceso telefónico con el Kit

de administración de Connection Manager (CMAK), puede ayudar a los usuarios al
agregar el nombre de dominio kerberos automáticamente al nombre de la cuenta de
usuario en los perfiles de CM que están instalados en equipos de usuarios. Por ejemplo,
puede especificar una sintaxis de nombre de dominio kerberos y nombre de usuario en
el perfil de CM de forma que el usuario sólo tenga que indicar el nombre de la cuenta
de usuario al escribir las credenciales. En este caso, el usuario no necesita saber o
recordar el dominio donde está ubicada la cuenta de usuario.

Durante el proceso de autenticación, después de que los usuarios escriban las

credenciales basadas en contraseña, el nombre de usuario pasa del cliente de acceso al
servidor de acceso a la red. El servidor de acceso a la red crea una solicitud de conexión
e incluye el nombre de dominio kerberos dentro del atributo RADIUS de nombre de
usuario en el mensaje de solicitud de acceso que se envía al servidor o al proxy RADIUS.

Si el servidor RADIUS es un NPS, el mensaje de Access-Request se evalúa con respecto

al conjunto de directivas de solicitud de conexión configuradas. Las condiciones de la
directiva de solicitud de conexión pueden incluir la especificación del contenido del
atributo de nombre de usuario.

Puede configurar un conjunto de directivas de solicitud de conexión que sean

específicas del nombre de dominio kerberos dentro del atributo de nombre de usuario
de los mensajes entrantes. Esto permite crear reglas de enrutamiento que reenvían
mensajes RADIUS con un nombre de dominio kerberos específico a un conjunto
determinado de servidores RADIUS cuando se usa NPS como proxy RADIUS.

Reglas de manipulación de atributos

Antes de que el mensaje RADIUS se procese localmente (cuando se usa NPS como
servidor RADIUS) o se reenvíe a otro servidor RADIUS (cuando se usa NPS como proxy
RADIUS), el atributo de nombre de usuario incluido en el mensaje se puede modificar
mediante reglas de manipulación de atributos. Puede configurar reglas de manipulación
de atributos para el atributo User-Name seleccionando Nombre de usuario en la
pestaña Condiciones de las propiedades de una directiva de solicitud de conexión. Las
reglas de manipulación de atributos de NPS usan una sintaxis de expresión regular.

７ Nota

La manipulación del dominio kerberos no funciona con PEAP.

El comportamiento deseado puede realizarse cambiando a EAP-TLS o EAP-
MSCHAPv2 para la autenticación o agregando un sufijo UPN al dominio para cada
nombre de dominio adicional que necesite resolver.

Puede configurar reglas de manipulación de atributos para el atributo de nombre de

usuario y cambiar lo siguiente:

Quitar el nombre de dominio kerberos del nombre de usuario (también se conoce

como eliminación de dominio kerberos). Por ejemplo, el nombre
user1@[Link] de usuario se cambia a user1.

Cambiar el nombre de dominio kerberos pero no la sintaxis. Por ejemplo, el

nombre user1@[Link] de usuario se cambia a user1@[Link].

Cambiar la sintaxis del nombre de dominio kerberos. Por ejemplo, el nombre de

usuario example\user1 se cambia a user1@[Link].

Una vez que el atributo de nombre de usuario se modifica según las reglas de
manipulación de atributos que ha configurado, la configuración adicional de la primera
directiva de solicitud de conexión coincidente se usa para determinar si:
 NpS procesa el mensaje Access-Request localmente (cuando NPS se usa como
servidor RADIUS).

El NPS reenvía el mensaje a otro servidor RADIUS (cuando NPS se usa como proxy
RADIUS).

Configuración del nombre de dominio

proporcionado por NPS
Cuando el nombre de usuario no contiene ningún nombre de dominio, NPS suministra
uno. De forma predeterminada, el nombre de dominio proporcionado por NPS es el
dominio del que es miembro el NPS. Puede especificar el nombre de dominio
suministrado por NPS mediante la siguiente configuración del Registro:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan\PPP\ControlProto
cols\BuiltIn\
Name: DefaultDomain
Type: REG_SZ
Value: the FQDN for the domain, like [Link]

Ｕ Precaución

Una modificación incorrecta del Registro puede provocar daños graves en el

sistema. Antes de realizar cambios en el Registro, debe hacer una copia de
seguridad de los datos de valor guardados en el equipo.

Algunos servidores de acceso a la red que no son de Microsoft eliminan o modifican el

nombre de dominio según especifica el usuario. Por eso, la solicitud de acceso a la red
se autentica con el dominio predeterminado, que es posible que no sea el dominio para
la cuenta de usuario. Para resolver este problema, configure los servidores RADIUS para
cambiar el nombre de usuario al formato correcto con el nombre de dominio exacto.
Grupos de servidores RADIUS remotos
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Al configurar servidor de directivas de red (NPS) como proxy Servicio de autenticación

remota telefónica de usuario (RADIUS), se usa NPS para reenviar las solicitudes de
conexión a servidores RADIUS que son capaces de procesar las solicitudes de conexión
porque pueden realizar autenticación y autorización en el dominio donde se encuentra
la cuenta de usuario o equipo. Por ejemplo, si desea reenviar solicitudes de conexión a
uno o varios servidores RADIUS en dominios que no son de confianza, puede configurar
NPS como un proxy RADIUS para reenviar las solicitudes a los servidores RADIUS
remotos en el dominio que no es de confianza.

７ Nota

Los grupos de servidores RADIUS remotos no están relacionados con los grupos de
Windows independientes.

Para configurar NPS como un proxy RADIUS, debe crear una directiva de solicitud de
conexión que contenga toda la información necesaria para que NPS evalúe qué
mensajes reenviar y dónde enviar los mensajes.

Al configurar un grupo de servidores RADIUS remotos en NPS y configurar una directiva

de solicitud de conexión con el grupo, se designa la ubicación donde NPS debe reenviar
las solicitudes de conexión.

Configuración de servidores RADIUS para un

grupo
Un grupo de servidores RADIUS remotos es un grupo con nombre que contiene uno o
varios servidores RADIUS. Si se configura más de un servidor, se puede especificar la
configuración de equilibrio de carga para determinar el orden en que el proxy usa los
servidores o para distribuir el flujo de mensajes RADIUS entre todos los servidores del
grupo para evitar sobrecargar a uno o varios servidores con demasiadas solicitudes de
conexión.

Cada servidor del grupo tiene la siguiente configuración.

 Nombre o dirección. Cada miembro del grupo debe tener un nombre único
dentro del grupo. El nombre puede ser una dirección IP o un nombre que se
pueda resolver en su dirección IP.

Autenticación y contabilidad. Puede reenviar solicitudes de autenticación,

solicitudes de contabilidad o ambas a cada miembro remoto del grupo de
servidores RADIUS.

Equilibrio de carga. Se usa una opción de prioridad para indicar el miembro del
grupo que es el servidor principal (la prioridad se establece en 1). Para los
miembros del grupo que tienen la misma prioridad, se usa una opción de peso
para calcular la frecuencia con que se envían mensajes RADIUS a cada servidor.
Puede usar configuraciones adicionales para configurar la forma en que NPS
detecta cuándo un miembro del grupo deja de estar disponible por primera vez y
cuando está disponible después de que se haya determinado que no está
disponible.

Después de configurar un grupo de servidores RADIUS remotos, puede especificar el

grupo en la configuración de autenticación y contabilidad de una directiva de solicitud
de conexión. Por ello, primero se debe configurar un grupo de servidores RADIUS
remotos. A continuación, se puede configurar la directiva de solicitud de conexión que
se usará con el recién creado grupo de servidores RADIUS remotos. Asimismo, mientras
crea la directiva de solicitud de conexión, se puede usar el asistente para nueva directiva
de solicitud de conexión para crear un nuevo grupo de servidores RADIUS remotos.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Directivas de red
Artículo • 21/09/2022 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información general sobre las directivas de red en
NPS.

７ Nota

Además de este tema, está disponible la siguiente documentación de directiva de

red.

Permiso de acceso
Configuración de directivas de red

Las directivas de red son conjuntos de condiciones, restricciones y valores de

configuración que le permiten designar quién está autorizado para conectarse a la red y
bajo qué condiciones podrá o no conectarse.

Al procesar solicitudes de conexión como servidor Servicio de autenticación remota

telefónica de usuario (RADIUS), NPS realiza la autenticación y autorización para la
solicitud de conexión. Durante el proceso de autenticación, NPS comprueba la identidad
del usuario o equipo que se está conectando a la red. Durante el proceso de
autorización, NPS determina si el usuario o equipo tiene permitido el acceso a la red.

Para realizar estas determinaciones, NPS usa directivas de red configuradas en la

consola de NPS. NPS también examina las propiedades de acceso telefónico de la
cuenta de usuario en Active Directory® Domain Services (AD DS) para realizar la
autorización.

Directivas de red: un conjunto ordenado de

reglas
Las directivas de red se pueden ver como unas reglas. Cada regla tiene un conjunto de
condiciones y valores de configuración. NPS compara las condiciones de la regla con las
propiedades de las solicitudes de conexión. Si se produce una coincidencia entre la
regla y la solicitud de conexión, los valores de configuración definidos en la regla se
aplican a la conexión.
Cuando hay varias directivas de red configuradas en NPS, son un conjunto ordenado de
reglas. NPS comprueba cada solicitud de conexión con la primera regla de la lista,
después con la segunda y así sucesivamente hasta que se encuentra una coincidencia.

Cada directiva de red tiene una configuración de estado de directiva que le permite
habilitar o deshabilitar la directiva. Si se deshabilita una directiva de red, NPS no
evaluará la directiva durante la autorización de solicitudes de conexión.

７ Nota

Si desea que NPS evalúe una directiva de red al realizar la autorización para las
solicitudes de conexión, debe configurar la opción Estado de directiva activando la
casilla Directiva habilitada.

Propiedades de las directivas de red

Existen cuatro categorías de propiedades para cada directiva de red:

Introducción
Estas propiedades permiten especificar si la directiva está habilitada, si la directiva
concede o deniega el acceso y si se requiere un método de conexión de red específico o
un tipo de servidor de acceso a la red (NAS) para las solicitudes de conexión. Las
propiedades de Introducción también le permiten especificar si se ignorarán las
propiedades de marcado de cuentas de usuario en AD DS. Si selecciona esta opción,
NPS sólo usará los valores de configuración de la directiva de red para determinar si la
conexión está autorizada.

Condiciones
Estas propiedades permiten especificar las condiciones que debe cumplir la solicitud de
conexión para que coincida con la directiva de red; si las condiciones configuradas en la
directiva coinciden con la solicitud de conexión, NPS aplicará a la conexión los valores
de configuración designados en la directiva de red. Por ejemplo, si especifica la
dirección IPv4 de NAS como condición de la directiva de red y NPS recibe una solicitud
de conexión de un NAS que tiene la dirección IP especificada, la condición de la
directiva coincide con la solicitud de conexión.

Restricciones
Las restricciones son parámetros adicionales de la directiva de red que deben coincidir
con la solicitud de conexión. Si la solicitud de conexión no cumple una de las
restricciones, NPS rechazará automáticamente la solicitud. A diferencia de la respuesta
de NPS a condiciones no coincidentes en la directiva de red, si no se encuentra una
restricción, NPS deniega la solicitud de conexión sin evaluar directivas de red
adicionales.

Configuración
Estas propiedades permiten especificar la configuración que NPS aplicará a la solicitud
de conexión si se cumplen todas las condiciones de la directiva de red.

Al agregar una nueva directiva de red mediante la consola NPS, debe usar el Asistente
para nueva directiva de red. Después de crear una directiva de red mediante el asistente,
puede personalizarla haciendo doble clic en la directiva en la consola nps para obtener
las propiedades de la directiva.

Para obtener ejemplos de sintaxis de coincidencia de patrones para especificar atributos

de directiva de red, vea Usar expresiones regulares en NPS.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Permiso de acceso
Artículo • 21/09/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

El permiso de acceso se configura en la pestaña Información general de cada directiva

de red del servidor de directivas de red (NPS).

Esta configuración permite configurar la directiva para conceder o denegar el acceso a

los usuarios si la solicitud de conexión coincide con las condiciones y restricciones de la
directiva de red.

La configuración del permiso de acceso tiene el efecto siguiente:

Conceder acceso. El acceso se concede si la solicitud de conexión cumple las

condiciones y restricciones configuradas en la directiva.
Denegar el acceso. El acceso se deniega si la solicitud de conexión cumple las
condiciones y restricciones configuradas en la directiva.

El permiso de acceso también se concede o se deniega en función de la configuración

de las propiedades de acceso telefónico de cada cuenta de usuario.

７ Nota

Las cuentas de usuario y sus propiedades, como las propiedades de acceso

telefónico, se configuran en Usuarios y equipos de Active Directory o en el
complemento Local Users and Groups Microsoft Management Console (MMC), en
función de si tiene Active Directory® Domain Services (AD DS) instalado.

La configuración de la cuenta de usuario Permiso de acceso a la red, que se configura

en las propiedades de acceso telefónico de las cuentas de usuario, invalida la
configuración del permiso de acceso de la directiva de red. Cuando el permiso de
acceso de red en una cuenta de usuario se establece en la opción Controlar el acceso a
través de la directiva de red NPS , la configuración de permiso de acceso de directiva de
red determina si se concede o se deniega el acceso al usuario.

７ Nota

En Windows Server 2016, el valor predeterminado de Permiso de acceso AD DS red

en las propiedades de acceso telefónico de la cuenta de usuario es Controlar el
acceso a través de la directiva de red NPS.
Cuando NPS evalúa las solicitudes de conexión en las directivas de red configuradas,
realiza las siguientes acciones:

Si las condiciones de la primera directiva no se cumplen, NPS evalúa la siguiente

directiva y continúa con este procedimiento hasta que encuentra una coincidencia
o hasta que se evalúan todas las directivas para comprobar las coincidencias.
Si se cumplen las condiciones y restricciones de una directiva, NPS concede o
deniega el acceso, en función del valor de la configuración permiso de acceso de
la directiva.
Si las condiciones de una directiva se cumplen, pero las restricciones no, NPS
rechaza la solicitud de conexión.
Si no se cumple ninguna condición de ninguna directiva, NPS rechaza la solicitud
de conexión.

Omitir las propiedades de acceso telefónico de

las cuentas de usuario
Puede configurar la directiva de red NPS para omitir las propiedades de acceso
telefónico de las cuentas de usuario activando o desactivando la casilla Omitir las
propiedades de acceso telefónico de la cuenta de usuario en la pestaña Información
general de una directiva de red.

Normalmente, cuando NPS autoriza una solicitud de conexión, comprueba las

propiedades de acceso telefónico de la cuenta de usuario, donde el valor de la opción
de permiso de acceso a redes puede determinar si el usuario está autorizado para
conectarse a la red. Cuando configure NPS para que omita las propiedades de acceso
telefónico de cuentas de usuario durante la autorización, la configuración de la directiva
de red determinará si se concede al usuario acceso a la red.

Las propiedades de acceso telefónico de las cuentas de usuario incluyen lo siguiente:

Permiso de acceso a redes

Id. del autor de la llamada
Opciones de devolución de llamada
Dirección IP estática
Rutas estáticas

Para permitir que NPS autentique y autorice varios tipos de conexiones, puede ser
necesario deshabilitar el procesamiento de propiedades de acceso telefónico de las
cuentas de usuario. Esto se puede hacer en aquellos casos en los que no se requieran
propiedades específicas de acceso telefónico.

Por ejemplo, las propiedades caller-ID, callback, static IP address y static routes están
diseñadas para un cliente que está marcando en un servidor de acceso a la red (NAS),
no para los clientes que se conectan a puntos de acceso inalámbrico. Es posible que un
punto de acceso inalámbrico que recibe esta configuración en un mensaje RADIUS de
NPS no pueda procesarlos, lo que puede provocar que el cliente inalámbrico se
desconecte.

Cuando NPS proporciona autenticación y autorización para los usuarios que están
marcando y accediendo a la red de la organización a través de puntos de acceso
inalámbrico, debe configurar las propiedades de acceso telefónico para admitir
conexiones de acceso telefónico (estableciendo propiedades de acceso telefónico) o
conexiones inalámbricas (no estableciendo propiedades de acceso telefónico).

Puede usar NPS para habilitar el procesamiento de propiedades de acceso telefónico

para la cuenta de usuario en algunos casos (como el acceso telefónico) y deshabilitar el
procesamiento de propiedades de acceso telefónico en otros casos (como el
conmutador de autenticación e inalámbrico 802.1X).

También puede usar Omitir las propiedades de acceso telefónico de la cuenta de

usuario para administrar el control de acceso de red a través de grupos y la
configuración de permisos de acceso en la directiva de red. Al activar la casilla Omitir las
propiedades de acceso telefónico de la cuenta de usuario, se omite el permiso de
acceso a la red en la cuenta de usuario.

La única desventaja para esta configuración es que no podrá usar las propiedades
adicionales de acceso telefónico de las cuentas de usuario, como el Id. del autor de la
llamada, la devolución de llamadas, la dirección IP estática y las rutas estáticas.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Plantillas NPS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Las plantillas del servidor de directivas de red (NPS) permiten crear elementos de
configuración, como clientes de Servicio de autenticación remota telefónica de usuario
(RADIUS) o secretos compartidos, que puede reutilizar en el NPS local y exportar para su
uso en otros NPS.

Las plantillas nps están diseñadas para reducir la cantidad de tiempo y costo que se
tarda en configurar NPS en uno o varios servidores. Los siguientes tipos de plantilla NPS
están disponibles para la configuración en Administración de plantillas:

Secretos compartidos
Clientes RADIUS
Servidores RADIUS remotos
Filtros IP
Grupos de servidores de corrección

La configuración de una plantilla es diferente de configurar nps directamente. La

creación de una plantilla no afecta a la funcionalidad de NPS. Solo cuando se selecciona
la plantilla en la ubicación adecuada de la consola NPS, la plantilla afecta a la
funcionalidad de NPS.

Por ejemplo, si configura un cliente RADIUS en la consola NPS en Servidores y clientes

RADIUS, ha modificado la configuración de NPS y ha realizado un paso en la
configuración de NPS para comunicarse con uno de los servidores de acceso a la red
(NAS). (El siguiente paso sería configurar el NAS para comunicarse con NPS). Sin
embargo, si configura una nueva plantilla de clientes RADIUS en la consola NPS en
Administración de plantillas en lugar de crear un nuevo cliente RADIUS en Clientes y
servidores RADIUS, ha creado una plantilla, pero aún no ha modificado la funcionalidad
de NPS. Para modificar la funcionalidad de NPS, debe seleccionar la plantilla en la
ubicación correcta en la consola de NPS.

Creación de plantillas
Para crear una plantilla, abra la consola NPS, haga clic con el botón derecho en un tipo
de plantilla, como Filtros IPy, a continuación, haga clic en Nuevo. Se abre un nuevo
cuadro de diálogo de propiedades de plantilla que le permite configurar la plantilla.
Uso de plantillas localmente
Para usar una plantilla que haya creado en Administración de plantillas, vaya a una
ubicación en la consola NPS donde se pueda aplicar la plantilla. Por ejemplo, si crea una
plantilla de secretos compartidos que desea aplicar a una configuración de cliente
RADIUS, en Clientes y servidores RADIUS y Clientes RADIUS, abra las propiedades del
cliente RADIUS. En Seleccionar una plantilla de secretos compartidos existente,
seleccione la plantilla que creó anteriormente en la lista de plantillas disponibles.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Clientes RADIUS
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Un servidor de acceso a la red (NAS) es un dispositivo que proporciona cierto nivel de

acceso a una red más grande. Un NAS que usa una infraestructura RADIUS es también
un cliente RADIUS, que envía solicitudes de conexión y mensajes de cuentas a un
servidor RADIUS para su autenticación, autorización y administración de cuentas.

７ Nota

Los equipos cliente, como equipos portátiles y otros equipos que ejecutan sistemas
operativos cliente, no son clientes RADIUS. Los clientes RADIUS son servidores de
acceso de red, como puntos de acceso inalámbricos, conmutadores de
autenticación 802.1X, servidores de red privada virtual (VPN) y servidores de acceso
telefónico, ya que usan el protocolo RADIUS para comunicarse con servidores
RADIUS, como servidores de servidor de directivas de red (NPS).

Para implementar NPS como un servidor RADIUS o un proxy RADIUS, debe configurar
clientes RADIUS en NPS.

Ejemplos de clientes RADIUS

Algunos ejemplos de servidores de acceso a la red son:

Servidores de acceso a la red que proporcionan conectividad de acceso remoto a

la red de una organización o a Internet. Un ejemplo es un equipo que ejecuta el
sistema operativo Windows Server 2016 y el servicio de acceso remoto que
proporciona servicios de acceso remoto tradicionales de acceso telefónico o de
red privada virtual (VPN) a una intranet de la organización.
Puntos de acceso inalámbrico que proporcionan acceso de nivel físico a la red de
una organización mediante tecnologías inalámbricas de recepción y transmisión.
Conmutadores que proporcionan acceso de nivel físico a la red de una
organización mediante tecnologías tradicionales de LAN, como Ethernet.
Servidores proxy RADIUS que reenvían las solicitudes de conexión a servidores
RADIUS que son miembros de un grupo de servidores RADIUS remotos
configurado en el proxy RADIUS.
Mensajes de solicitud de acceso de RADIUS
Los clientes RADIUS pueden crear mensajes de solicitud de acceso de RADIUS y
reenviarlos a un proxy RADIUS o un servidor RADIUS, o bien, pueden reenviar mensajes
de solicitud de acceso a un servidor RADIUS que han recibido de otro cliente RADIUS
pero que no han creado ellos mismos.

Los clientes RADIUS no procesan mensajes de solicitud de acceso mediante la

autenticación, autorización y administración de cuentas. Sólo los servidores RADIUS
realizan dichas funciones.

No obstante, se puede configurar el NPS como un proxy RADIUS y un servidor RADIUS

simultáneamente, de forma que procese algunos mensajes de solicitud de acceso y
reenvíe otros mensajes.

NPS como cliente RADIUS

NPS actúa como un cliente RADIUS cuando se configura como un proxy RADIUS para
reenviar mensajes de solicitud de acceso a otros servidores RADIUS para su
procesamiento. Cuando se usa un NPS como un proxy RADIUS, es necesario realizar los
siguientes pasos de configuración general:

1. Los servidores de acceso a la red, como los puntos de acceso inalámbrico y los
servidores VPN, están configurados con la dirección IP del proxy NPS como el
servidor RADIUS designado o el servidor de autenticación. Esto permite a los
servidores de acceso a la red, que crean mensajes de solicitud de acceso basados
en la información que reciben de los clientes de acceso, reenviar mensajes al proxy
NPS.

2. Para configurar el proxy NPS, se deben agregar todos los servidores de acceso a la
red como clientes RADIUS. Este paso de configuración permite al proxy NPS recibir
mensajes de los servidores de acceso a la red y comunicarse con ellos durante
toda la autenticación. Además, las directivas de solicitud de conexión establecidas
en el proxy NPS están configuradas para especificar qué mensajes de solicitud de
acceso se deben reenviar a uno o varios servidores RADIUS. Estas directivas
también están configuradas con un grupo de servidores RADIUS remotos, que
indica a NPS dónde debe enviar los mensajes que recibe de los servidores de
acceso a la red.

3. El servidor NPS u otros servidores RADIUS que son miembros del grupo de
servidores RADIUS remotos en el proxy NPS están configurados para recibir
 mensajes del proxy NPS. Esto se consigue configurando el proxy NPS como un
cliente RADIUS.

Propiedades del cliente RADIUS

Cuando agrega un cliente RADIUS a la configuración de NPS a través de la consola nps
o mediante el uso de los comandos netsh para los comandos NPS o Windows
PowerShell, está configurando NPS para recibir mensajes RADIUS Access-Request desde
un servidor de acceso a la red o un proxy RADIUS.

Cuando se configura un cliente RADIUS en NPS, se pueden designar las siguientes

propiedades:

Nombre del cliente

Nombre descriptivo para el cliente RADIUS, que facilite su identificación cuando se use
el complemento NPS o los comandos netsh para NPS.

Dirección IP
Dirección del protocolo de Internet versión 4 (IPv4) o nombre del Sistema de nombres
de dominio (DNS) del cliente RADIUS.

Client-Vendor
Proveedor del cliente RADIUS. De lo contrario, se puede usar el valor estándar de
RADIUS para el proveedor del cliente.

Secreto compartido
Cadena de texto que se usa como contraseña entre clientes RADIUS, servidores RADIUS
y servidores proxy RADIUS. Cuando se usa el atributo autenticador de mensaje, el
secreto compartido también se usa como clave para cifrar mensajes RADIUS. Esta
cadena debe estar configurada en el cliente RADIUS y en el complemento NPS.

Atributo de autenticador de mensaje

Tal como se describe en RFC 2869, acerca de las extensiones de RADIUS, es un hash de
Message Digest 5 (MD5) de todo el mensaje RADIUS. Si está presente el atributo de
autenticador de mensaje de RADIUS, se comprueba. Si la comprobación genera un
error, se descartará el mensaje RADIUS. Si la configuración del cliente requiere la
presencia del atributo de autenticador de mensaje y éste no está presente, se descartará
el mensaje RADIUS. Se recomienda usar el atributo de autenticador de mensaje.

７ Nota

El atributo message Authenticator es necesario y está habilitado de forma

predeterminada cuando se usa la autenticación del Protocolo de autenticación
extensible (EAP).

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Planear el servidor de directivas de
redes
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema se proporcionan vínculos a información sobre el planeamiento de

implementaciones de NPS y proxy.

７ Nota

Para obtener documentación adicional del servidor de directivas de red, puede usar
las siguientes secciones de biblioteca.

Tareas iniciales con el servidor de directivas de redes

Implementar el servidor de directivas de redes
Administrar el servidor de directivas de redes

Esta sección incluye los temas siguientes.

Planear NPS como servidor RADIUS

Planear NPS como proxy RADIUS
Planear NPS como servidor RADIUS
Artículo • 21/12/2022 • Tiempo de lectura: 18 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Al implementar servidor de directivas de red (NPS) como servidor Servicio de

autenticación remota telefónica de usuario (RADIUS), NPS realiza la autenticación,
autorización y contabilidad de las solicitudes de conexión para el dominio local y para
los dominios que confían en el dominio local. Puede usar estas directrices de
planeamiento para simplificar la implementación radius.

Estas directrices de planeamiento no incluyen circunstancias en las que quiera

implementar NPS como proxy RADIUS. Al implementar NPS como proxy RADIUS, NPS
reenvía las solicitudes de conexión a un servidor que ejecuta NPS u otros servidores
RADIUS en dominios remotos, dominios que no son de confianza o ambos.

Antes de implementar NPS como un servidor RADIUS en la red, use las siguientes
directrices para planear la implementación.

Planear la configuración de NPS.

Planear clientes RADIUS.

Planee el uso de métodos de autenticación.

Planear directivas de red.

Planear la contabilidad de NPS.

Planeación de la configuración de NPS

Debe decidir en qué dominio es miembro nps. Para entornos de varios dominios, un
NPS puede autenticar las credenciales de las cuentas de usuario del dominio del que es
miembro y para todos los dominios que confían en el dominio local de NPS. Para
permitir que NPS lea las propiedades de acceso telefónico de las cuentas de usuario
durante el proceso de autorización, debe agregar la cuenta de equipo de NPS al grupo
RAS y NPSs para cada dominio.

Después de haber determinado la pertenencia a un dominio de NPS, el servidor debe

configurarse para comunicarse con clientes RADIUS, también denominados servidores
de acceso a la red, mediante el protocolo RADIUS. Además, puede configurar los tipos
de eventos que NPS registra en el registro de eventos y puede escribir una descripción
para el servidor.

Pasos clave
Durante el planeamiento de la configuración de NPS, puede usar los pasos siguientes.

Determine los puertos RADIUS que nps usa para recibir mensajes RADIUS de
clientes RADIUS. Los puertos predeterminados son los puertos UDP 1812 y 1645
para los mensajes de autenticación RADIUS y los puertos 1813 y 1646 para los
mensajes de contabilidad RADIUS.

Si nps está configurado con varios adaptadores de red, determine los adaptadores
a través de los que desea que se permita el tráfico RADIUS.

Determine los tipos de eventos que desea que NPS registre en el registro de
eventos. Puede registrar solicitudes de autenticación rechazadas, solicitudes de
autenticación correctas o ambos tipos de solicitudes.

Determine si va a implementar más de un NPS. Para proporcionar tolerancia a

errores para la autenticación y la contabilidad basadas en RADIUS, use al menos
dos NPS. Un NPS se usa como servidor RADIUS principal y el otro como copia de
seguridad. A continuación, cada cliente RADIUS se configura en ambos NPS. Si el
NPS principal deja de estar disponible, los clientes RADIUS envían Access-Request
mensajes al NPS alternativo.

Planee el script usado para copiar una configuración de NPS en otros NPS para
ahorrar en sobrecarga administrativa y evitar la cofiguración incorrecta de un
servidor. NPS proporciona los comandos Netsh que permiten copiar todo o parte
de una configuración de NPS para su importación en otro NPS. Puede ejecutar los
comandos manualmente en el símbolo del sistema de Netsh. Sin embargo, si
guarda la secuencia de comandos como un script, puede ejecutar el script en una
fecha posterior si decide cambiar las configuraciones del servidor.

Planeación de clientes RADIUS

Los clientes RADIUS son servidores de acceso de red, como puntos de acceso
inalámbricos, servidores de red privada virtual (VPN), conmutadores compatibles con
802.1X y servidores de acceso telefónico. Los servidores proxy RADIUS, que reenvía
mensajes de solicitud de conexión a servidores RADIUS, también son clientes RADIUS.
NPS admite todos los servidores de acceso a la red y servidores proxy RADIUS que
cumplan el protocolo RADIUS, como se describe en RFC 2865, "Remote Authentication
Dial-in User Service (RADIUS)" y RFC 2866, "RADIUS Accounting".

） Importante

Los clientes de acceso, como los equipos cliente, no son clientes RADIUS. Solo los
servidores de acceso de red y los servidores proxy que admiten el protocolo
RADIUS son clientes RADIUS.

Además, tanto los puntos de acceso inalámbricos como los conmutadores deben ser
capaces de la autenticación 802.1X. Si desea implementar el Protocolo de autenticación
extensible (EAP) o el Protocolo de autenticación extensible protegido (PEAP), los puntos
de acceso y los conmutadores deben admitir el uso de EAP.

Para probar la interoperabilidad básica de las conexiones PPP para los puntos de acceso
inalámbricos, configure el punto de acceso y el cliente de acceso para que usen el
Protocolo de autenticación de contraseñas (PAP). Use protocolos de autenticación
basados en PPP adicionales, como PEAP, hasta que haya probado los que piensa usar
para el acceso a la red.

Pasos clave
Durante el planeamiento de los clientes RADIUS, puede seguir estos pasos.

Documente los atributos específicos del proveedor (VSA) que debe configurar en
NPS. Si los servidores de acceso de red requieren VSA, registre la información de
VSA para su uso posterior al configurar las directivas de red en NPS.

Documente las direcciones IP de los clientes RADIUS y nps para simplificar la

configuración de todos los dispositivos. Al implementar los clientes RADIUS, debe
configurarlos para que usen el protocolo RADIUS, con la dirección IP NPS
especificada como servidor de autenticación. Y al configurar NPS para que se
comunique con los clientes RADIUS, debe escribir las direcciones IP del cliente
RADIUS en el complemento NPS.

Cree secretos compartidos para la configuración en los clientes RADIUS y en el

complemento NPS. Debe configurar clientes RADIUS con un secreto compartido, o
contraseña, que también escribirá en el complemento NPS al configurar clientes
RADIUS en NPS.

Planear el uso de métodos de autenticación

NPS admite métodos de autenticación basados en contraseña y basados en certificados.
Sin embargo, no todos los servidores de acceso de red admiten los mismos métodos de
autenticación. En algunos casos, es posible que desee implementar un método de
autenticación diferente en función del tipo de acceso a la red.

Por ejemplo, es posible que quiera implementar el acceso inalámbrico y VPN para su
organización, pero usar un método de autenticación diferente para cada tipo de acceso:
EAP-TLS para conexiones VPN, debido a la fuerte seguridad que proporciona EAP con
seguridad de la capa de transporte (EAP-TLS) y PEAP-MS-CHAP v2 para conexiones
inalámbricas 802.1X.

PEAP con el protocolo de autenticación de desafío de Microsoft versión 2 (PEAP-MS-

CHAP v2) proporciona una característica denominada reconexión rápida diseñada
específicamente para su uso con equipos portátiles y otros dispositivos inalámbricos. La
reconexión rápida permite a los clientes inalámbricos moverse entre puntos de acceso
inalámbricos de la misma red sin que se vuelvan a autenticar cada vez que se asocian a
un nuevo punto de acceso. Esto proporciona una mejor experiencia para los usuarios
inalámbricos y les permite moverse entre puntos de acceso sin tener que volver a
escribir sus credenciales. Debido a la reconexión rápida y la seguridad que proporciona
PEAP-MS-CHAP v2, PEAP-MS-CHAP v2 es una opción lógica como método de
autenticación para las conexiones inalámbricas.

En el caso de las conexiones VPN, EAP-TLS es un método de autenticación basado en

certificados que proporciona una seguridad segura que protege el tráfico de red incluso
cuando se transmite a través de Internet desde equipos móviles o domésticas a los
servidores VPN de la organización.

Métodos de autenticación basados en certificados.

Los métodos de autenticación basados en certificados tienen la ventaja de proporcionar
una seguridad segura; y tienen la desventaja de ser más difíciles de implementar que los
métodos de autenticación basados en contraseña.

PEAP-MS-CHAP v2 y EAP-TLS son métodos de autenticación basados en certificados,

pero hay muchas diferencias entre ellos y la forma en que se implementan.

EAP-TLS
EAP-TLS usa certificados para la autenticación de cliente y servidor, y requiere que
implemente una infraestructura de clave pública (PKI) en su organización. La
implementación de una PKI puede ser compleja y requiere una fase de planeamiento
independiente del planeamiento del uso de NPS como servidor RADIUS.
Con EAP-TLS, NPS inscribe un certificado de servidor de una entidad de certificación
(CA) y el certificado se guarda en el equipo local en el almacén de certificados. Durante
el proceso de autenticación, la autenticación del servidor se produce cuando NPS envía
su certificado de servidor al cliente de acceso para demostrar su identidad al cliente de
acceso. El cliente de acceso examina varias propiedades de certificado para determinar
si el certificado es válido y es adecuado para su uso durante la autenticación del
servidor. Si el certificado de servidor cumple los requisitos mínimos de certificado de
servidor y lo emite una CA en la que confía el cliente de acceso, el cliente autentica
correctamente el NPS.

De forma similar, la autenticación de cliente se produce durante el proceso de

autenticación cuando el cliente envía su certificado de cliente a NPS para demostrar su
identidad a NPS. NpS examina el certificado y, si el certificado de cliente cumple los
requisitos mínimos de certificado de cliente y lo emite una ca en la que confía NPS, nps
autentica correctamente el cliente de acceso.

Aunque es necesario que el certificado de servidor se almacene en el almacén de

certificados de NPS, el certificado de cliente o de usuario se puede almacenar en el
almacén de certificados del cliente o en una tarjeta inteligente.

Para que este proceso de autenticación se realiza correctamente, es necesario que todos
los equipos tengan el certificado de entidad de certificación de su organización en el
almacén de certificados de entidades de certificación raíz de confianza para el equipo
local y el usuario actual.

PEAP-MS-CHAP v2
PEAP-MS-CHAP v2 usa un certificado para la autenticación del servidor y las
credenciales basadas en contraseña para la autenticación de usuario. Dado que los
certificados solo se usan para la autenticación del servidor, no es necesario implementar
una PKI para usar PEAP-MS-CHAP v2. Al implementar PEAP-MS-CHAP v2, puede
obtener un certificado de servidor para NPS de una de las dos maneras siguientes:

Puede instalar Servicios de certificados de Active Directory (AD CS) y, a

continuación, realizar la inscripción automática de certificados en NPS. Si usa este
método, también debe inscribir el certificado de entidad de certificación en los
equipos cliente que se conectan a la red para que confíen en el certificado emitido
para NPS.

Puede adquirir un certificado de servidor de una CA pública, como VeriSign. Si usa

este método, asegúrese de seleccionar una entidad de certificación que ya sea de
confianza para los equipos cliente. Para determinar si los equipos cliente confían
 en una CA, abra el complemento Certificados Microsoft Management Console
(MMC) en un equipo cliente y, a continuación, vea el almacén entidades de
certificación raíz de confianza para el equipo local y para el usuario actual. Si hay
un certificado de la ca en estos almacenes de certificados, el equipo cliente confía
en la CA y, por tanto, confiará en cualquier certificado emitido por la CA.

Durante el proceso de autenticación con PEAP-MS-CHAP v2, la autenticación del

servidor se produce cuando NPS envía su certificado de servidor al equipo cliente. El
cliente de acceso examina varias propiedades de certificado para determinar si el
certificado es válido y es adecuado para su uso durante la autenticación del servidor. Si
el certificado de servidor cumple los requisitos mínimos de certificado de servidor y lo
emite una CA en la que confía el cliente de acceso, el cliente autentica correctamente el
NPS.

La autenticación de usuario se produce cuando un usuario que intenta conectarse a la

red tipos de credenciales basadas en contraseña e intenta iniciar sesión. NPS recibe las
credenciales y realiza la autenticación y autorización. Si el usuario se autentica y autoriza
correctamente, y si el equipo cliente ha autenticado correctamente nps, se concede la
solicitud de conexión.

Pasos clave
Durante la planeación del uso de métodos de autenticación, puede seguir estos pasos.

Identifique los tipos de acceso a la red que planea ofrecer, como el acceso
inalámbrico, VPN, conmutador compatible con 802.1X y acceso telefónico.

Determine el método de autenticación o los métodos que desea usar para cada
tipo de acceso. Se recomienda usar los métodos de autenticación basados en
certificados que proporcionan una seguridad segura; sin embargo, puede que no
sea práctico implementar una PKI, por lo que otros métodos de autenticación
podrían proporcionar un mejor equilibrio de lo que necesita para la red.

Si va a implementar EAP-TLS, planee la implementación de PKI. Esto incluye

planear las plantillas de certificado que va a usar para certificados de servidor y
certificados de equipo cliente. También incluye determinar cómo inscribir
certificados en equipos de miembros de dominio y no miembros del dominio, y
determinar si desea usar tarjetas inteligentes.

Si va a implementar PEAP-MS-CHAP v2, determine si desea instalar AD CS para

emitir certificados de servidor a los NPS o si desea adquirir certificados de servidor
de una CA pública, como VeriSign.
Planeación de directivas de red
NPS usa directivas de red para determinar si las solicitudes de conexión recibidas de los
clientes RADIUS están autorizadas. NPS también usa las propiedades de acceso
telefónico de la cuenta de usuario para realizar una determinación de autorización.

Dado que las directivas de red se procesan en el orden en que aparecen en el

complemento NPS, planee colocar primero las directivas más restrictivas en la lista de
directivas. Para cada solicitud de conexión, NPS intenta hacer coincidir las condiciones
de la directiva con las propiedades de la solicitud de conexión. NPS examina cada
directiva de red en orden hasta que encuentra una coincidencia. Si no encuentra una
coincidencia, se rechaza la solicitud de conexión.

Pasos clave
Durante el planeamiento de las directivas de red, puede seguir estos pasos.

Determine el orden de procesamiento de NPS preferido de las directivas de red, de

más restrictivo a menos restrictivo.

Determine el estado de la directiva. El estado de la directiva puede tener el valor

habilitado o deshabilitado. Si la directiva está habilitada, NPS evalúa la directiva
mientras se realiza la autorización. Si la directiva no está habilitada, no se evalúa.

Determine el tipo de directiva. Debe determinar si la directiva está diseñada para

conceder acceso cuando la solicitud de conexión coincide con las condiciones de
la directiva o si la directiva está diseñada para denegar el acceso cuando la
solicitud de conexión coincide con las condiciones de la directiva. Por ejemplo, si
desea denegar explícitamente el acceso inalámbrico a los miembros de un grupo
de Windows, puede crear una directiva de red que especifique el grupo, el método
de conexión inalámbrica y que tenga una configuración de tipo de directiva de
Denegar acceso.

Determine si desea que NPS ignore las propiedades de acceso telefónico de las
cuentas de usuario que son miembros del grupo en el que se basa la directiva.
Cuando esta opción no está habilitada, las propiedades de acceso telefónico de las
cuentas de usuario invalidan la configuración que se configura en las directivas de
red. Por ejemplo, si se configura una directiva de red que concede acceso a un
usuario pero las propiedades de acceso telefónico de la cuenta de usuario para ese
usuario están establecidas para denegar el acceso, se deniega el acceso al usuario.
Pero si habilita la configuración de tipo de directiva Omitir las propiedades de
 acceso telefónico de la cuenta de usuario, se concederá acceso a la red al mismo
usuario.

Determine si la directiva usa la configuración de origen de la directiva. Esta

configuración le permite especificar fácilmente un origen para todas las solicitudes
de acceso. Los orígenes posibles son una puerta de enlace de Terminal Services
(puerta de enlace de TS), un servidor de acceso remoto (VPN o acceso telefónico),
un servidor DHCP, un punto de acceso inalámbrico y un servidor de entidad de
registro de estado. Como alternativa, puede especificar un origen específico del
proveedor.

Determine las condiciones que deben coincidir para que se aplique la directiva de
red.

Determine la configuración que se aplica si la solicitud de conexión coincide con

las condiciones de la directiva de red.

Determine si desea usar, modificar o eliminar las directivas de red

predeterminadas.

Planeamiento de la contabilidad de NPS

NPS proporciona la capacidad de registrar datos de contabilidad RADIUS, como
solicitudes de autenticación de usuario y contabilidad, en tres formatos: formato IAS,
formato compatible con la base de datos y Microsoft SQL Server registro.

El formato IAS y el formato compatible con la base de datos crean archivos de registro
en el NPS local en formato de archivo de texto.

SQL Server registro proporciona la capacidad de iniciar sesión en una base de datos
compatible con XML de SQL Server 2000 o SQL Server 2005, ampliando la contabilidad
RADIUS para aprovechar las ventajas del registro en una base de datos relacional.

Pasos clave
Durante el planeamiento de la contabilidad de NPS, puede usar los pasos siguientes.

Determine si desea almacenar datos de contabilidad nps en archivos de registro o

en una base de SQL Server datos.

Contabilidad de NPS mediante archivos de registro

locales
El registro de solicitudes de autenticación y contabilidad de usuarios en archivos de
registro se usa principalmente para el análisis de conexiones y la facturación, y también
es útil como herramienta de investigación de seguridad, lo que proporciona un método
para realizar el seguimiento de la actividad de un usuario malintencionado después de
un ataque.

Pasos clave
Durante el planeamiento de la contabilidad de NPS mediante archivos de registro
locales, puede seguir estos pasos.

Determine el formato de archivo de texto que desea usar para los archivos de
registro nps.

Elija el tipo de información que desea registrar. Puede registrar solicitudes de

contabilidad, solicitudes de autenticación y estado periódico.

Determine la ubicación del disco duro donde desea almacenar los archivos de
registro.

Diseñe la solución de copia de seguridad de archivos de registro. La ubicación del

disco duro donde se almacenan los archivos de registro debe ser una ubicación
que le permita realizar fácilmente una copia de seguridad de los datos. Además, la
ubicación del disco duro debe protegerse configurando la lista de control de
acceso (ACL) de la carpeta donde se almacenan los archivos de registro.

Determine la frecuencia con la que desea crear nuevos archivos de registro. Si

desea crear archivos de registro en función del tamaño de archivo, determine el
tamaño máximo de archivo permitido antes de que NPS cree un nuevo archivo de
registro.

Determine si desea que NPS elimine los archivos de registro más antiguos si el
disco duro se queda sin espacio de almacenamiento.

Determine la aplicación o las aplicaciones que desea usar para ver los datos de
contabilidad y generar informes.

Registro de SQL Server NPS

El registro SQL Server nps se usa cuando se necesita información de estado de sesión,
con fines de creación de informes y análisis de datos, y para centralizar y simplificar la
administración de los datos de contabilidad.
NPS proporciona la capacidad de usar el registro de SQL Server para registrar las
solicitudes de autenticación y contabilidad de usuarios recibidas de uno o varios
servidores de acceso a la red en un origen de datos en un equipo que ejecuta el motor
de escritorio de Microsoft SQL Server (MSDE 2000) o cualquier versión de SQL Server
posterior a SQL Server 2000.

Los datos de contabilidad se pasan desde NPS en formato XML a un procedimiento

almacenado de la base de datos, que admite tanto el lenguaje de consulta estructurado
(SQL) como XML (SQLXML). El registro de solicitudes de autenticación y contabilidad de
usuarios en una base de datos SQL Server compatible con XML permite que varios NPS
tengan un origen de datos.

Pasos clave
Durante el planeamiento de la contabilidad de NPS mediante nps SQL Server registro,
puede usar los pasos siguientes.

Determine si usted u otro miembro de su organización tiene experiencia de

desarrollo de bases de datos relacionales SQL Server 2000 o SQL Server 2005 y
cómo usar estos productos para crear, modificar, administrar y administrar bases
de datos SQL Server.

Determine si SQL Server está instalado en NPS o en un equipo remoto.

Diseñe el procedimiento almacenado que usará en la base de datos SQL Server

para procesar los archivos XML entrantes que contienen datos de contabilidad nps.

Diseñe el flujo SQL Server de replicación de base de datos.

Determine la aplicación o las aplicaciones que desea usar para ver los datos de
contabilidad y generar informes.

Planee usar servidores de acceso a la red que envíen el atributo Class en todas las
solicitudes de contabilidad. El atributo Class se envía al cliente RADIUS en un
mensaje Access-Accept y es útil para correlacionar los mensajes Accounting-
Request con sesiones de autenticación. Si el servidor de acceso de red envía el
atributo Class en los mensajes de solicitud de contabilidad, se puede usar para
coincidir con los registros de contabilidad y autenticación. La combinación de los
atributos Unique-Serial-Number, Service-Reboot-Time y Server-Address debe ser
una identificación única para cada autenticación que acepte el servidor.

Planee el uso de servidores de acceso a la red que admitan la contabilidad

provisional.
Planee el uso de servidores de acceso a la red que envían mensajes de
contabilidad y de contabilidad.

Planee el uso de servidores de acceso a la red que admitan el almacenamiento y

reenvío de datos de contabilidad. Los servidores de acceso a la red que admiten
esta característica pueden almacenar datos de contabilidad cuando el servidor de
acceso a la red no puede comunicarse con nps. Cuando nps está disponible, el
servidor de acceso a la red reenvía los registros almacenados al NPS, lo que
proporciona una mayor confiabilidad en la contabilidad de los servidores de
acceso a la red que no proporcionan esta característica.

Planee configurar siempre el atributo Acct-Interim-Interval en las directivas de red.

El atributo Acct-Interim-Interval establece el intervalo (en segundos) entre cada
actualización provisional que envía el servidor de acceso a la red. Según RFC 2869,
el valor del atributo Acct-Interim-Interval no debe ser inferior a 60 segundos, ni un
minuto, y no debe ser inferior a 600 segundos o 10 minutos. Para obtener más
información, vea RFC 2869, "Extensiones RADIUS".

Asegúrese de que el registro del estado periódico está habilitado en los NPS.
Planear NPS como proxy RADIUS
Artículo • 21/12/2022 • Tiempo de lectura: 11 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Al implementar servidor de directivas de red (NPS) como proxy Servicio de autenticación

remota telefónica de usuario (RADIUS), NPS recibe solicitudes de conexión de clientes
RADIUS, como servidores de acceso a la red u otros servidores proxy RADIUS, y, a
continuación, reenvía estas solicitudes de conexión a servidores que ejecutan NPS u
otros servidores RADIUS. Puede usar estas directrices de planeamiento para simplificar
la implementación de RADIUS.

Estas directrices de planeamiento no incluyen las circunstancias en las que desea

implementar NPS como servidor RADIUS. Al implementar NPS como servidor RADIUS,
NPS realiza la autenticación, autorización y contabilidad de las solicitudes de conexión
para el dominio local y para los dominios que confían en el dominio local.

Antes de implementar NPS como proxy RADIUS en la red, use las siguientes directrices
para planear la implementación.

Planear la configuración de NPS.

Planear clientes RADIUS.

Planear grupos de servidores RADIUS remotos.

Planear reglas de manipulación de atributos para el reenvío de mensajes.

Planear directivas de solicitud de conexión.

Planear la contabilidad de NPS.

Planeación de la configuración de NPS

Cuando se usa NPS como proxy RADIUS, NPS reenvía las solicitudes de conexión a un
servidor NPS u otros servidores RADIUS para su procesamiento. Por este problema, la
pertenencia al dominio del proxy NPS es irrelevante. No es necesario registrar el proxy
en Active Directory Domain Services (AD DS) porque no necesita acceso a las
propiedades de acceso telefónico de las cuentas de usuario. Además, no es necesario
configurar directivas de red en un proxy NPS porque el proxy no realiza la autorización
para las solicitudes de conexión. El proxy NPS puede ser un miembro de dominio o
puede ser un servidor independiente sin pertenencia a un dominio.
NPS debe configurarse para comunicarse con clientes RADIUS, también denominados
servidores de acceso de red, mediante el protocolo RADIUS. Además, puede configurar
los tipos de eventos que NPS registra en el registro de eventos y puede escribir una
descripción para el servidor.

Pasos clave
Durante el planeamiento de la configuración del proxy NPS, puede seguir estos pasos.

Determine los puertos RADIUS que usa el proxy NPS para recibir mensajes RADIUS
de clientes RADIUS y para enviar mensajes RADIUS a miembros de grupos de
servidores RADIUS remotos. Los puertos predeterminados del Protocolo de
datagramas de usuario (UDP) son 1812 y 1645 para los mensajes de autenticación
RADIUS y los puertos UDP 1813 y 1646 para los mensajes de contabilidad RADIUS.

Si el proxy NPS está configurado con varios adaptadores de red, determine los
adaptadores sobre los que desea permitir el tráfico RADIUS.

Determine los tipos de eventos que desea que NPS registre en el registro de
eventos. Puede registrar solicitudes de conexión rechazadas, solicitudes de
conexión correctas o ambas.

Determine si va a implementar más de un proxy NPS. Para proporcionar tolerancia

a errores, use al menos dos servidores proxy NPS. Un proxy NPS se usa como
proxy RADIUS principal y el otro como copia de seguridad. A continuación, cada
cliente RADIUS se configura en ambos servidores proxy NPS. Si el proxy NPS
principal deja de estar disponible, los clientes RADIUS envían Access-Request
mensajes al proxy NPS alternativo.

Planee el script que se usa para copiar una configuración de proxy NPS en otros
servidores proxy NPS para ahorrar en sobrecarga administrativa y evitar la
configuración incorrecta de un servidor. NPS proporciona los comandos Netsh que
permiten copiar todo o parte de una configuración de proxy NPS para importarla a
otro proxy NPS. Puede ejecutar los comandos manualmente en el símbolo del
sistema de Netsh. Sin embargo, si guarda la secuencia de comandos como un
script, puede ejecutarlo en una fecha posterior si decide cambiar las
configuraciones de proxy.

Planeación de clientes RADIUS

Los clientes RADIUS son servidores de acceso a la red, como puntos de acceso
inalámbricos, servidores de red privada virtual (VPN), conmutadores compatibles con
802.1X y servidores de acceso telefónico. Los servidores proxy RADIUS, que reenvía
mensajes de solicitud de conexión a servidores RADIUS, también son clientes RADIUS.
NPS admite todos los servidores de acceso a la red y servidores proxy RADIUS que
cumplen con el protocolo RADIUS, como se describe en RFC 2865, "Remote
Authentication Dial-in User Service (RADIUS)" y RFC 2866, "RADIUS Accounting".

Además, tanto los puntos de acceso inalámbricos como los conmutadores deben ser
capaces de realizar la autenticación 802.1X. Si desea implementar el Protocolo de
autenticación extensible (EAP) o el Protocolo de autenticación extensible protegido
(PEAP), los puntos de acceso y los conmutadores deben admitir el uso de EAP.

Para probar la interoperabilidad básica de las conexiones PPP para los puntos de acceso
inalámbricos, configure el punto de acceso y el cliente de acceso para que usen el
Protocolo de autenticación de contraseña (PAP). Use protocolos de autenticación
basados en PPP adicionales, como PEAP, hasta que haya probado los que piensa usar
para el acceso a la red.

Pasos clave
Durante el planeamiento de los clientes RADIUS, puede seguir estos pasos.

Documente los atributos específicos del proveedor (VSA) que debe configurar en
NPS. Si los NAS requieren VSA, registre la información de VSA para su uso
posterior al configurar las directivas de red en NPS.

Documente las direcciones IP de los clientes RADIUS y el proxy NPS para

simplificar la configuración de todos los dispositivos. Al implementar los clientes
RADIUS, debe configurarlos para que usen el protocolo RADIUS, con la dirección IP
del proxy NPS especificada como servidor de autenticación. Y al configurar NPS
para que se comunique con los clientes RADIUS, debe escribir las direcciones IP
del cliente RADIUS en el complemento NPS.

Cree secretos compartidos para la configuración en los clientes RADIUS y en el

complemento NPS. Debe configurar clientes RADIUS con un secreto compartido, o
contraseña, que también escribirá en el complemento NPS al configurar clientes
RADIUS en NPS.

Planeación de grupos de servidores RADIUS

remotos
Cuando se configura un grupo de servidores RADIUS remoto en un proxy NPS, se le
pide al proxy NPS dónde enviar algunos o todos los mensajes de solicitud de conexión
que recibe de servidores de acceso a la red y servidores proxy NPS u otros servidores
proxy RADIUS.

Puede usar NPS como proxy RADIUS para reenviar solicitudes de conexión a uno o
varios grupos de servidores RADIUS remotos, y cada grupo puede contener uno o varios
servidores RADIUS. Si desea que el proxy NPS reenvía mensajes a varios grupos,
configure una directiva de solicitud de conexión por grupo. La directiva de solicitud de
conexión contiene información adicional, como reglas de manipulación de atributos,
que indica al proxy NPS qué mensajes se enviarán al grupo de servidores RADIUS
remoto especificado en la directiva.

Puede configurar grupos de servidores RADIUS remotos mediante los comandos Netsh
para NPS, configurando grupos directamente en el complemento NPS en Grupos de
servidores RADIUS remotos o ejecutando el Asistente para nueva directiva de solicitud
de conexión.

Pasos clave
Durante el planeamiento de grupos de servidores RADIUS remotos, puede seguir estos
pasos.

Determine los dominios que contienen los servidores RADIUS a los que desea que
el proxy NPS reenvía las solicitudes de conexión. Estos dominios contienen las
cuentas de usuario de los usuarios que se conectan a la red a través de los clientes
RADIUS que implemente.

Determine si necesita agregar nuevos servidores RADIUS en dominios donde

RADIUS aún no está implementado.

Documente las direcciones IP de los servidores RADIUS que desea agregar a los
grupos de servidores RADIUS remotos.

Determine cuántos grupos de servidores RADIUS remotos necesita crear. En

algunos casos, es mejor crear un grupo de servidores RADIUS remoto por dominio
y, a continuación, agregar los servidores RADIUS para el dominio al grupo. Sin
embargo, puede haber casos en los que tenga una gran cantidad de recursos en
un dominio, incluido un gran número de usuarios con cuentas de usuario en el
dominio, un gran número de controladores de dominio y un gran número de
servidores RADIUS. O bien, el dominio podría abarcar una gran área geográfica, lo
que hace que tenga servidores de acceso a la red y servidores RADIUS en
 ubicaciones que están alejadas entre sí. En estos y posiblemente otros casos,
puede crear varios grupos de servidores RADIUS remotos por dominio.

Cree secretos compartidos para la configuración en el proxy NPS y en los

servidores RADIUS remotos.

Planear reglas de manipulación de atributos

para el reenvío de mensajes
Las reglas de manipulación de atributos, que se configuran en las directivas de solicitud
de conexión, permiten identificar los mensajes de Access-Request que desea reenviar a
un grupo de servidores RADIUS remoto específico.

Puede configurar NPS para reenviar todas las solicitudes de conexión a un grupo de
servidores RADIUS remoto sin usar reglas de manipulación de atributos.

Sin embargo, si tiene más de una ubicación a la que desea reenviar las solicitudes de
conexión, debe crear una directiva de solicitud de conexión para cada ubicación y, a
continuación, configurar la directiva con el grupo de servidores RADIUS remoto al que
desea reenviar los mensajes, así como con las reglas de manipulación de atributos que
le digan a NPS qué mensajes reenviar.

Puede crear reglas para los atributos siguientes.

Called-Station-ID. Número de teléfono del servidor de acceso a la red (NAS). El

valor de este atributo es una cadena de caracteres. Puede usar una sintaxis de
coincidencia de patrón para especificar códigos de área.

Calling-Station-ID. Número de teléfono utilizado por el autor de la llamada. El

valor de este atributo es una cadena de caracteres. Puede usar una sintaxis de
coincidencia de patrón para especificar códigos de área.

Nombre de usuario. El nombre de usuario proporcionado por el cliente de acceso

y que el NAS incluye en el mensaje Access-Request RADIUS. El valor de este
atributo es una cadena de caracteres que normalmente contiene un nombre de
dominio y un nombre de cuenta de usuario.

Para reemplazar o convertir correctamente nombres de dominio en el nombre de

usuario de una solicitud de conexión, debe configurar reglas de manipulación de
atributos para el atributo User-Name en la directiva de solicitud de conexión adecuada.

Pasos clave
Durante el planeamiento de las reglas de manipulación de atributos, puede usar los
pasos siguientes.

Planee el enrutamiento de mensajes desde el NAS a través del proxy a los

servidores RADIUS remotos para comprobar que tiene una ruta de acceso lógica
con la que reenviar mensajes a los servidores RADIUS.

Determine uno o varios atributos que desea usar para cada directiva de solicitud
de conexión.

Documente las reglas de manipulación de atributos que planea usar para cada
directiva de solicitud de conexión y haga coincidir las reglas con el grupo de
servidores RADIUS remoto al que se reenván los mensajes.

Planear directivas de solicitud de conexión

La directiva de solicitud de conexión predeterminada se configura para NPS cuando se
usa como servidor RADIUS. Se pueden usar directivas de solicitud de conexión
adicionales para definir condiciones más específicas, crear reglas de manipulación de
atributos que indiquen a NPS qué mensajes reenviar a grupos de servidores RADIUS
remotos y especificar atributos avanzados. Use el Asistente para nueva directiva de
solicitud de conexión para crear directivas de solicitud de conexión comunes o
personalizadas.

Pasos clave
Durante el planeamiento de las directivas de solicitud de conexión, puede seguir estos
pasos.

Elimine la directiva de solicitud de conexión predeterminada en cada servidor que

ejecute NPS que funcione únicamente como proxy RADIUS.

Planee las condiciones y la configuración adicionales necesarias para cada

directiva, combinando esta información con el grupo de servidores RADIUS
remoto y las reglas de manipulación de atributos planeadas para la directiva.

Diseñe el plan para distribuir directivas de solicitud de conexión comunes a todos

los servidores proxy NPS. Cree directivas comunes a varios servidores proxy NPS
en un NPS y, a continuación, use los comandos Netsh para NPS para importar las
directivas de solicitud de conexión y la configuración del servidor en todos los
demás servidores proxy.
Planeamiento de la contabilidad de NPS
Al configurar NPS como proxy RADIUS, puede configurarlo para realizar cuentas RADIUS
mediante archivos de registro de formato NPS, archivos de registro de formato
compatible con la base de datos o registro de SQL Server NPS.

También puede reenviar mensajes de contabilidad a un grupo de servidores RADIUS

remoto que realice la contabilidad mediante uno de estos formatos de registro.

Pasos clave
Durante el planeamiento de la contabilidad de NPS, puede usar los pasos siguientes.

Determine si desea que el proxy NPS realice servicios de contabilidad o reenvía

mensajes de contabilidad a un grupo de servidores RADIUS remoto para la
contabilidad.

Planee deshabilitar la contabilidad de proxy NPS local si tiene previsto reenviar

mensajes de contabilidad a otros servidores.

Planee los pasos de configuración de la directiva de solicitud de conexión si tiene

previsto reenviar mensajes de contabilidad a otros servidores. Si deshabilita la
contabilidad local para el proxy NPS, cada directiva de solicitud de conexión que
configure en ese proxy debe tener habilitado y configurado correctamente el
reenvío de mensajes de contabilidad.

Determine el formato de registro que desea usar: archivos de registro con formato
IAS, archivos de registro de formato compatibles con la base de datos o registro
de SQL Server NPS.

Para configurar el equilibrio de carga para NPS como proxy RADIUS, vea Equilibrio de
carga del servidor proxy NPS.
Implementar el servidor de directivas de
redes
Artículo • 17/01/2023 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información sobre la implementación del servidor de
directivas de red.

７ Nota

Para obtener documentación adicional del servidor de directivas de red, puede usar
las siguientes secciones de biblioteca.

Tareas iniciales con el servidor de directivas de redes

Planear el servidor de directivas de redes
Administrar el servidor de directivas de redes

La guía de red principal de Windows Server 2016 incluye una sección sobre la
planeación e instalación del servidor de directivas de red (NPS) y las tecnologías
presentadas en la guía sirven como requisitos previos para implementar NPS en un
dominio de Active Directory. Para obtener más información, consulte la sección "Deploy
NPS1" (Implementar NPS1) en la guía de red principal de Windows Server 2016.

Implementación de certificados NPS para el

acceso VPN y 802.1X
Si quiere implementar métodos de autenticación como el Protocolo de autenticación
extensible (EAP) y EAP protegido que requieren el uso de certificados de servidor en
NPS, puede implementar certificados NPS con la guía Deploy Server Certificates for
802.1X Wired and Wireless Deployments (Implementar certificados de servidor para
implementaciones cableadas e inalámbricas de 802.1X).

Implementación de NPS para el acceso

inalámbrico 802.1X
Para implementar NPS para el acceso inalámbrico, puede usar la guía Implementar
Password-Based 802.1X Acceso inalámbrico autenticado.

Implementación de NPS para el acceso VPN de

Windows 10
Puede usar NPS para procesar solicitudes de conexión para conexiones de red privada
virtual (VPN) AlwaysOn para empleados remotos que usan equipos y dispositivos que
ejecutan Windows 10.

Para obtener más información, consulte el Tutorial de implementación de VPN alwaysOn

de acceso remoto para Windows Server 2016 y Windows 10.
Administrar el servidor de directivas de
red (NPS)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar los temas de esta sección para administrar el servidor de directivas de red.

７ Nota

Para obtener documentación adicional del servidor de directivas de red, puede usar
las siguientes secciones de biblioteca.

Tareas iniciales con el servidor de directivas de redes

Planear el servidor de directivas de redes
Implementar el servidor de directivas de redes

Esta sección contiene los temas siguientes.

Administración del Servidor de directivas de redes con Herramientas de

administración
Configurar directivas de solicitud de conexión
Configuración de firewalls para el tráfico RADIUS
Configuración de directivas de red
Configurar las cuentas de servidor de directivas de redes
Configurar clientes RADIUS
Configurar grupos de servidores RADIUS remotos
Administrar certificados usados con NPS
Administrar NPS
Administración de plantillas NPS
Administración del Servidor de
directivas de redes con Herramientas de
administración
Artículo • 21/12/2022 • Tiempo de lectura: 9 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información sobre las herramientas que puede usar
para administrar sus NPS.

Después de instalar NPS, puede administrar NPSs:

Localmente, mediante el complemento NPS Microsoft Management Console

(MMC), la consola NPS estática en Herramientas administrativas, comandos
Windows PowerShell o comandos de Shell de red (Netsh) para NPS.
Desde un NPS remoto, mediante el complemento MMC NPS, los comandos netsh
para NPS, los comandos Windows PowerShell para NPS o conexión a Escritorio
remoto.
Desde una estación de trabajo remota, mediante la conexión a Escritorio remoto
en combinación con otras herramientas, como EL MMC de NPS o Windows
PowerShell.

７ Nota

En Windows Server 2016, puede administrar el NPS local mediante la consola NPS.
Para administrar NPS remotos y locales, debe usar el complemento MMC NPS.

７ Nota

La consola NPS y el complemento MMC NPS tienen un límite de 256 caracteres

para todas las configuraciones que toman un valor de cadena. Esto incluye todas
las opciones que se pueden configurar mediante expresiones regulares. Para
configurar valores de cadena que superen los 256 caracteres, puede usar los
comandos NPS de NETSH. Los valores de cadena configurados que superan los 256
caracteres no se pueden editar en la consola NPS ni en el complemento MMC NPS
sin invalidarlos.
En las secciones siguientes se proporcionan instrucciones sobre cómo administrar los
NPS locales y remotos.

Configuración del NPS local mediante la

consola NPS
Después de instalar NPS, puede usar este procedimiento para administrar el NPS local
mediante el MMC de NPS.

Credenciales administrativas

Para completar este procedimiento, debe pertenecer al grupo Administradores.

Para configurar el NPS local mediante la consola NPS

1. En el Administrador del servidor, haga clic en Herramientas y, a continuación, haga
clic en Servidor de directivas de redes. Se abre la consola NPS.

2. En la consola nps, haga clic en NPS (local). En el panel de detalles, elija

Configuración estándar o Configuración avanzada y, a continuación, realice una
de las siguientes acciones en función de la selección:

Si elige Configuración estándar, seleccione un escenario de la lista y siga las

instrucciones para iniciar un asistente de configuración.
Si elige Configuración avanzada, haga clic en la flecha para expandir
Opciones de configuración avanzada y, a continuación, revise y configure las
opciones disponibles en función de la funcionalidad NPS que desee: servidor
RADIUS, proxy RADIUS o ambos.

Administrar varios NPS mediante el

complemento MMC de NPS
Puede usar este procedimiento para administrar el NPS local y varios NPS remotos
mediante el complemento MMC de NPS.

Antes de realizar el procedimiento siguiente, debe instalar NPS en el equipo local y en

equipos remotos.

Dependiendo de las condiciones de red y del número de NPS que administre mediante
el complemento MMC NPS, la respuesta del complemento MMC podría ser lenta.
Además, el tráfico de configuración de NPS se envía a través de la red durante una
sesión de administración remota mediante el complemento NPS. Asegúrese de que la
red sea físicamente segura y que los usuarios malintencionados no tengan acceso a este
tráfico de red.

Credenciales administrativas

Para completar este procedimiento, debe pertenecer al grupo Administradores.

Para administrar varios NPS mediante el complemento

NPS
1. Para abrir MMC, ejecute Windows PowerShell como administrador. En Windows
PowerShell, escriba mmc y presione ENTRAR. Se abre Microsoft Management
Console.
2. En MMC, en el menú Archivo, haga clic en Agregar o quitar complemento. Se
abre el cuadro de diálogo Agregar o quitar complementos.
3. En Agregar o quitar complementos, en Complementos disponibles, desplácese
hacia abajo en la lista, haga clic en Servidor de directivas de red y, a continuación,
haga clic en Agregar. Se abre el cuadro de diálogo Seleccionar equipo.
4. En Seleccionar equipo, compruebe que el equipo local (el equipo en el que se
ejecuta esta consola) está seleccionado y, a continuación, haga clic en Aceptar. El
complemento para el NPS local se agrega a la lista en Complementos
seleccionados.
5. En Agregar o quitar complementos, en Complementos disponibles, asegúrese de
que el servidor de directivas de red todavía está seleccionado y, a continuación,
haga clic en Agregar. Se abre de nuevo el cuadro de diálogo Seleccionar equipo .
6. En Seleccionar equipo, haga clic en Otro equipo y, a continuación, escriba la
dirección IP o el nombre de dominio completo (FQDN) del NPS remoto que desea
administrar mediante el complemento NPS. Opcionalmente, puede hacer clic en
Examinar para examinar el directorio del equipo que desea agregar. Haga clic en
Aceptar.
7. Repita los pasos 5 y 6 para agregar más NPS al complemento NPS. Cuando haya
agregado todos los NPS que desea administrar, haga clic en Aceptar.
8. Para guardar el complemento NPS para su uso posterior, haga clic en Archivo y, a
continuación, haga clic en Guardar. En el cuadro de diálogo Guardar como, vaya a
la ubicación del disco duro donde desea guardar el archivo, escriba un nombre
para el archivo de Microsoft Management Console (.msc) y, a continuación, haga
clic en Guardar.
Administrar un NPS mediante conexión a
Escritorio remoto
Puede usar este procedimiento para administrar un NPS remoto mediante conexión a
Escritorio remoto.

Mediante la conexión a Escritorio remoto, puede administrar de forma remota los NPS
que ejecutan Windows Server 2016. También puede administrar de forma remota NPS
desde un equipo que ejecute Windows 10 o sistemas operativos cliente windows
anteriores.

Puede usar la conexión a Escritorio remoto para administrar varios NPS mediante uno
de los dos métodos.

1. Cree una conexión de Escritorio remoto a cada uno de los NPS individualmente.
2. Use Escritorio remoto para conectarse a un NPS y, a continuación, use el MMC NPS
en ese servidor para administrar otros servidores remotos. Para obtener más
información, vea la sección anterior Manage Multiple NPSs by Using the NPS
MMC Snap-in.

Credenciales administrativas

Para completar este procedimiento, debe ser miembro del grupo Administradores del
NPS.

Para administrar un NPS mediante conexión a Escritorio

remoto
1. En cada NPS que quiera administrar de forma remota, en Administrador del
servidor, seleccione Servidor local. En el panel de detalles de Administrador del
servidor, vea la configuración escritorio remoto y realice una de las siguientes
acciones.
a. Si el valor de la configuración de Escritorio remoto es Habilitado, no es
necesario realizar algunos de los pasos descritos en este procedimiento. Vaya al
paso 4 para empezar a configurar los permisos de usuario de Escritorio remoto.
b. Si la configuración de Escritorio remoto es Deshabilitada, haga clic en la
palabra Deshabilitado. Se abre el cuadro de diálogo Propiedades del sistema
en la pestaña Remoto .
2. En Escritorio remoto, haga clic en Permitir conexiones remotas a este equipo. Se
abre el cuadro de diálogo Conexión a Escritorio remoto . Realice una de las
acciones siguientes.
 a. Para personalizar las conexiones de red permitidas, haga clic en Firewall de
Windows con seguridad avanzada y, a continuación, configure las opciones
que desea permitir.
b. Para habilitar la conexión a Escritorio remoto para todas las conexiones de red
en el equipo, haga clic en Aceptar.
3. En Propiedades del sistema, en Escritorio remoto, decida si habilitar Permitir
conexiones solo desde equipos que ejecutan Escritorio remoto con
autenticación de nivel de red y realizar la selección.
4. Haga clic en Seleccionar usuarios. Se abre el cuadro de diálogo Usuarios de
Escritorio remoto .
5. En Usuarios de Escritorio remoto, para conceder permiso a un usuario para
conectarse de forma remota a NPS, haga clic en Agregar y escriba el nombre de
usuario de la cuenta del usuario. Haga clic en Aceptar.
6. Repita el paso 5 para cada usuario para el que quiera conceder permiso de acceso
remoto al NPS. Cuando haya terminado de agregar usuarios, haga clic en Aceptar
para cerrar el cuadro de diálogo Usuarios de Escritorio remoto y aceptar de nuevo
para cerrar el cuadro de diálogo Propiedades del sistema .
7. Para conectarse a un NPS remoto que ha configurado mediante los pasos
anteriores, haga clic en Inicio, desplácese hacia abajo en la lista alfabética y, a
continuación, haga clic en Accesorios de Windows y en Conexión a Escritorio
remoto. Se abre el cuadro de diálogo Conexión a Escritorio remoto .
8. En el cuadro de diálogo Conexión a Escritorio remoto , en Equipo, escriba el
nombre NPS o la dirección IP. Si lo prefiere, haga clic en Opciones, configure
opciones de conexión adicionales y, a continuación, haga clic en Guardar para
guardar la conexión para su uso repetido.
9. Haga clic en Conectar y, cuando se le solicite, proporcione credenciales de cuenta
de usuario para una cuenta que tenga permisos para iniciar sesión en y configurar
NPS.

Uso de comandos NPS de Netsh para

administrar un NPS
Puede usar comandos en el contexto de NPS de Netsh para mostrar y establecer la
configuración de la base de datos de autenticación, autorización, contabilidad y
auditoría usada tanto por NPS como por el servicio de acceso remoto. Use comandos en
el contexto de Netsh NPS para:

Configure o vuelva a configurar un NPS, incluidos todos los aspectos de NPS que
también están disponibles para la configuración mediante la consola NPS en la
interfaz de Windows.
 Exporte la configuración de un NPS (el servidor de origen), incluidas las claves del
Registro y el almacén de configuración de NPS, como un script de Netsh.
Importe la configuración en otro NPS mediante un script netsh y el archivo de
configuración exportado desde el NPS de origen.

Puede ejecutar estos comandos desde el símbolo del sistema de Windows Server 2016 o
desde Windows PowerShell. También puede ejecutar comandos netsh nps en scripts y
archivos por lotes.

Credenciales administrativas

Para llevar a cabo este procedimiento, debe pertenecer al grupo de administradores del
equipo local.

Para especificar el contexto de NPS de Netsh en un NPS

1. Abra el símbolo del sistema o Windows PowerShell.
2. Escriba netsh y presione ENTRAR.
3. Escriba nps y presione ENTRAR.
4. Para ver una lista de comandos disponibles, escriba un signo de interrogación (?) y
presione ENTRAR.

Para obtener más información sobre los comandos de Netsh NPS, consulte Comandos
netsh para el servidor de directivas de red en Windows Server 2008 o descargue toda la
referencia técnica de Netsh de la Galería de TechNet. Esta descarga es la referencia
técnica completa del Shell de red para Windows Server 2008 y Windows Server 2008 R2.
El formato es la Ayuda de Windows (*.chm) en un archivo ZIP. Estos comandos siguen
presentes en Windows Server 2016 y Windows 10, por lo que puede usar netsh en estos
entornos, aunque se recomienda usar Windows PowerShell.

Uso de Windows PowerShell para administrar

NPS
Puede usar comandos de Windows PowerShell para administrar NPS. Para obtener más
información, consulte los siguientes temas de referencia de comandos de Windows
PowerShell.

Cmdlets del servidor de directivas de red (NPS) en Windows PowerShell. Puede

usar estos comandos netsh en Windows Server 2012 R2 o sistemas operativos
posteriores.
Módulo NPS. Puede usar estos comandos netsh en Windows Server 2016.
Para obtener más información sobre la administración de NPS, vea Administrar el
servidor de directivas de red (NPS).
Configuración de las directivas de
solicitud de conexión
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para crear y configurar directivas de solicitud de conexión que
designen si nps local procesa las solicitudes de conexión o las reenvía al servidor
RADIUS remoto para su procesamiento.

Las directivas de solicitud de conexión son conjuntos de condiciones y configuraciones

que permiten a los administradores de red designar qué servidores de Servicio de
autenticación remota telefónica de usuario (RADIUS) realizan la autenticación y
autorización de las solicitudes de conexión que el servidor que ejecuta servidor de
directivas de red (NPS) recibe de los clientes RADIUS.

La directiva de solicitud de conexión predeterminada usa NPS como servidor RADIUS y

procesa localmente todas las solicitudes de autenticación.

Para configurar un servidor que ejecute NPS para que funcione como proxy RADIUS y
reenvíe las solicitudes de conexión a otros NPS o servidores RADIUS, debe configurar un
grupo remoto de servidores RADIUS además de agregar una nueva directiva de solicitud
de conexión que especifique las condiciones y configuraciones con las que deben
coincidir las solicitudes de conexión.

Puede crear un nuevo grupo de servidores remotos RADIUS mientras crea una nueva
directiva de solicitud de conexión con el asistente para Nueva directiva de solicitud de
conexión.

Si no desea que NPS actúe como servidor RADIUS y procese las solicitudes de conexión
localmente, puede eliminar la directiva de solicitud de conexión predeterminada.

Si quiere que NPS actúe como servidor RADIUS, que procese las solicitudes de conexión
localmente y, como proxy RADIUS, reenvía algunas solicitudes de conexión a un grupo
de servidores RADIUS remoto, agregue una nueva directiva mediante el procedimiento
siguiente y, a continuación, compruebe que la directiva de solicitud de conexión
predeterminada es la última directiva procesada al colocarla en último lugar en la lista
de directivas.
Adición de una directiva de solicitud de
conexión
La pertenencia a Administradores de dominio, o equivalente, es lo mínimo necesario
para completar este procedimiento.

Para agregar una nueva directiva de solicitud de conexión

1. En Administrador del servidor, haga clic en Herramientasy, a continuación, haga
clic en Servidor de directivas de red para abrir la consola NPS.
2. En el árbol de consola, haga doble clic en Directivas.
3. Haga clic con el botón derecho en Directivas de solicitud de conexióny, a
continuación, haga clic en Nueva directiva de solicitud de conexión.
4. Use el Asistente para nueva directiva de solicitud de conexión para configurar la
directiva de solicitud de conexión y, si no lo hizo anteriormente, un grupo remoto
de servidores RADIUS.

Para obtener más información sobre cómo administrar NPS, vea Administrar el servidor
de directivas de red.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Configuración del firewall para el tráfico
RADIUS
Artículo • 24/09/2022 • Tiempo de lectura: 9 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Los firewalls se pueden configurar para permitir o bloquear tipos de tráfico IP en el

equipo o dispositivo en el que se ejecuta el firewall. Si los firewall no se configuran
correctamente para permitir el tráfico RADIUS entre clientes RADIUS, proxy RADIUS y
servidores RADIUS, pueden producirse errores en la autenticación del acceso a la red e
impedir a los usuarios el acceso a los recursos de red.

Es posible que tenga que configurar dos tipos de firewalls para permitir el tráfico
RADIUS:

Windows Defender firewall con seguridad avanzada en el servidor local que

ejecuta servidor de directivas de red (NPS).
Los firewalls que se ejecuten en otros equipos o dispositivos de hardware

Windows firewall en nps local

De forma predeterminada, NPS envía y recibe tráfico RADIUS mediante los puertos
1812, 1813, 1645 y 1646 del Protocolo de datagramas de usuario (UDP). Windows
Defender firewall en NPS debe configurarse automáticamente con excepciones, durante
la instalación de NPS, para permitir que este tráfico RADIUS se envíe y reciba.

Con Server 2019, esta excepción de firewall requiere una modificación en el

identificador de seguridad de la cuenta de servicio para detectar y permitir eficazmente
el tráfico RADIUS. Si no se ejecuta este cambio de identificador de seguridad, el firewall
quitará el tráfico RADIUS. En un símbolo del sistema con privilegios elevados, ejecute sc
sidtype IAS unrestricted . Este comando cambia el servicio IAS (RADIUS) para usar un
SID único en lugar de compartirlo con otros servicios DE SERVICIO DE RED.

Por lo tanto, si usa los puertos UDP predeterminados, no es necesario cambiar la

configuración del firewall de Windows Defender para permitir el tráfico RADIUS hacia y
desde NPS.

En algunos casos, puede que desee cambiar los puertos que NPS usa para el tráfico
RADIUS. Si configura NPS y los servidores de acceso a la red para enviar y recibir tráfico
RADIUS en puertos distintos de los predeterminados, debe realizar las siguientes
acciones:

Quite las excepciones que permiten el tráfico RADIUS en los puertos

predeterminados.
Cree nuevas excepciones que permitan el tráfico RADIUS en los nuevos puertos.

Para obtener más información, vea Configurar la información de puerto UDP de NPS.

Otros firewalls
En la configuración más común, el firewall está conectado a Internet y NPS es un recurso
de intranet que está conectado a la red perimetral.

Para llegar al controlador de dominio dentro de la intranet, nps podría tener:

Una interfaz en la red perimetral y una interfaz en la intranet (el enrutamiento IP

no está habilitado).
Una sola interfaz en la red perimetral. En esta configuración, NPS se comunica con
los controladores de dominio a través de otro firewall que conecta la red
perimetral a la intranet.

Configuración del firewall de Internet

El firewall que está conectado a Internet debe configurarse con filtros de entrada y
salida en su interfaz de Internet (y, opcionalmente, su interfaz perimetral de red), para
permitir el reenvío de mensajes RADIUS entre los clientes NPS y RADIUS o servidores
proxy en Internet. Se pueden usar otros filtros para permitir el paso de tráfico a los
servidores web, servidores VPN y otros tipos de servidores de la red perimetral.

Se pueden configurar filtros de paquetes de entrada y salida independientes en la

interfaz de Internet y la interfaz de la red perimetral.

Configuración de filtros de entrada en la interfaz de

Internet
Configure los siguientes filtros de paquetes de entrada en la interfaz de Internet del
firewall para permitir los siguientes tipos de tráfico:

Dirección IP de destino de la interfaz de red perimetral y el puerto de destino UDP

de 1812 (0x714) del NPS. Este filtro permite el tráfico de autenticación RADIUS
desde clientes RADIUS basados en Internet a NPS. Este es el puerto UDP
 predeterminado que usa NPS, tal como se define en RFC 2865. Si usa otro puerto,
sustituya ese número de puerto por 1812.
Dirección IP de destino de la interfaz de red perimetral y el puerto de destino UDP
de 1813 (0x715) del NPS. Este filtro permite el tráfico de cuentas RADIUS desde
clientes RADIUS basados en Internet a NPS. Este es el puerto UDP predeterminado
que usa NPS, tal como se define en RFC 2866. Si usa otro puerto, sustituya ese
número de puerto por 1813.
(Opcional) Dirección IP de destino de la interfaz de red perimetral y puerto de
destino UDP de 1645 (0x66D) del NPS. Este filtro permite el tráfico de
autenticación RADIUS desde clientes RADIUS basados en Internet a NPS. Éste es el
puerto UDP que usan los clientes RADIUS antiguos.
(Opcional) Dirección IP de destino de la interfaz de red perimetral y puerto de
destino UDP de 1646 (0x66E) del NPS. Este filtro permite el tráfico de cuentas
RADIUS desde clientes RADIUS basados en Internet a NPS. Éste es el puerto UDP
que usan los clientes RADIUS antiguos.

Configuración de filtros de salida en la interfaz de

Internet
Configure los siguientes filtros de salida en la interfaz de Internet del firewall para
permitir los siguientes tipos de tráfico:

Dirección IP de origen de la interfaz de red perimetral y el puerto de origen UDP

de 1812 (0x714) del NPS. Este filtro permite el tráfico de autenticación RADIUS
desde nps a clientes RADIUS basados en Internet. Este es el puerto UDP
predeterminado que usa NPS, tal como se define en RFC 2865. Si usa otro puerto,
sustituya ese número de puerto por 1812.
Dirección IP de origen de la interfaz de red perimetral y puerto de origen UDP de
1813 (0x715) del NPS. Este filtro permite el tráfico de cuentas RADIUS desde nps a
clientes RADIUS basados en Internet. Este es el puerto UDP predeterminado que
usa NPS, tal como se define en RFC 2866. Si usa otro puerto, sustituya ese número
de puerto por 1813.
(Opcional) Dirección IP de origen de la interfaz de red perimetral y puerto de
origen UDP de 1645 (0x66D) del NPS. Este filtro permite el tráfico de autenticación
RADIUS desde nps a clientes RADIUS basados en Internet. Éste es el puerto UDP
que usan los clientes RADIUS antiguos.
(Opcional) Dirección IP de origen de la interfaz de red perimetral y puerto de
origen UDP de 1646 (0x66E) del NPS. Este filtro permite el tráfico de cuentas
RADIUS desde nps a clientes RADIUS basados en Internet. Éste es el puerto UDP
que usan los clientes RADIUS antiguos.
Configuración de filtros de entrada en la interfaz de red
perimetral
Configure los siguientes filtros de entrada en la interfaz de Internet del firewall para
permitir los siguientes tipos de tráfico:

Dirección IP de origen de la interfaz de red perimetral y el puerto de origen UDP

de 1812 (0x714) del NPS. Este filtro permite el tráfico de autenticación RADIUS
desde nps a clientes RADIUS basados en Internet. Este es el puerto UDP
predeterminado que usa NPS, tal como se define en RFC 2865. Si usa otro puerto,
sustituya ese número de puerto por 1812.
Dirección IP de origen de la interfaz de red perimetral y puerto de origen UDP de
1813 (0x715) del NPS. Este filtro permite el tráfico de cuentas RADIUS desde nps a
clientes RADIUS basados en Internet. Este es el puerto UDP predeterminado que
usa NPS, tal como se define en RFC 2866. Si usa otro puerto, sustituya ese número
de puerto por 1813.
(Opcional) Dirección IP de origen de la interfaz de red perimetral y puerto de
origen UDP de 1645 (0x66D) del NPS. Este filtro permite el tráfico de autenticación
RADIUS desde nps a clientes RADIUS basados en Internet. Éste es el puerto UDP
que usan los clientes RADIUS antiguos.
(Opcional) Dirección IP de origen de la interfaz de red perimetral y puerto de
origen UDP de 1646 (0x66E) del NPS. Este filtro permite el tráfico de cuentas
RADIUS desde nps a clientes RADIUS basados en Internet. Éste es el puerto UDP
que usan los clientes RADIUS antiguos.

Configuración de filtros de salida en la interfaz de red

perimetral
Configure los siguientes filtros de paquetes de salida en la interfaz de red perimetral del
firewall para permitir los siguientes tipos de tráfico:

Dirección IP de destino de la interfaz de red perimetral y el puerto de destino UDP

de 1812 (0x714) del NPS. Este filtro permite el tráfico de autenticación RADIUS
desde clientes RADIUS basados en Internet a NPS. Este es el puerto UDP
predeterminado que usa NPS, tal como se define en RFC 2865. Si usa otro puerto,
sustituya ese número de puerto por 1812.
Dirección IP de destino de la interfaz de red perimetral y el puerto de destino UDP
de 1813 (0x715) del NPS. Este filtro permite el tráfico de cuentas RADIUS desde
clientes RADIUS basados en Internet a NPS. Este es el puerto UDP predeterminado
que usa NPS, tal como se define en RFC 2866. Si usa otro puerto, sustituya ese
número de puerto por 1813.
 (Opcional) Dirección IP de destino de la interfaz de red perimetral y puerto de
destino UDP de 1645 (0x66D) del NPS. Este filtro permite el tráfico de
autenticación RADIUS desde clientes RADIUS basados en Internet a NPS. Éste es el
puerto UDP que usan los clientes RADIUS antiguos.
(Opcional) Dirección IP de destino de la interfaz de red perimetral y puerto de
destino UDP de 1646 (0x66E) del NPS. Este filtro permite el tráfico de cuentas
RADIUS desde clientes RADIUS basados en Internet a NPS. Éste es el puerto UDP
que usan los clientes RADIUS antiguos.

Para mayor seguridad, puede usar las direcciones IP de cada cliente RADIUS que envía
los paquetes a través del firewall para definir filtros para el tráfico entre el cliente y la
dirección IP del NPS en la red perimetral.

Filtros en la interfaz de red perimetral

Configure los siguientes filtros de paquetes de entrada en la interfaz de red perimetral
del firewall de la intranet para permitir los siguientes tipos de tráfico:

Dirección IP de origen de la interfaz de red perimetral del NPS. Este filtro permite
el tráfico desde nps en la red perimetral.

Configure los siguientes filtros de salida en la interfaz de la red perimetral del firewall de
la intranet para permitir los siguientes tipos de tráfico:

Dirección IP de destino de la interfaz de red perimetral del NPS. Este filtro permite
el tráfico a NPS en la red perimetral.

Filtros en la interfaz de la intranet

Configure los siguientes filtros de entrada en la interfaz de intranet del firewall para
permitir los siguientes tipos de tráfico:

Dirección IP de destino de la interfaz de red perimetral del NPS. Este filtro permite
el tráfico a NPS en la red perimetral.

Configure los siguientes filtros de paquetes de salida en la interfaz de intranet del

firewall para permitir los siguientes tipos de tráfico:

Dirección IP de origen de la interfaz de red perimetral del NPS. Este filtro permite
el tráfico desde nps en la red perimetral.

Para obtener más información sobre cómo administrar NPS, vea Administrar el servidor
de directivas de red.
Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Configurar las directivas de red
Artículo • 21/09/2022 • Tiempo de lectura: 13 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para configurar directivas de red en NPS.

Add a Network Policy

El servidor de directivas de red (NPS) usa directivas de red y las propiedades de acceso
telefónico de las cuentas de usuario para determinar si una solicitud de conexión está
autorizada para conectarse a la red.

Puede usar este procedimiento para configurar una nueva directiva de red en la consola
NPS o en la consola de acceso remoto.

Proceso de autorización
Cuando NPS autoriza una solicitud de conexión, compara la solicitud con cada una de
las directivas de red de la lista ordenada de directivas, comenzando por la primera y,
posteriormente, desplazándose en sentido descendente por el resto de las directivas. Si
NPS encuentra una directiva cuyas condiciones coinciden con la solicitud de conexión,
usa la directiva coincidente y las propiedades de acceso telefónico de la cuenta de
usuario para realizar la autorización. Si las propiedades de acceso telefónico de la
cuenta de usuario se configuran para conceder acceso o controlar el acceso a través de
la directiva de red y la solicitud de conexión se autoriza, NPS aplica los valores
configurados en la directiva de red para la conexión.

Si NPS no encuentra una directiva de red que coincida con la solicitud de conexión, la
solicitud se rechazará a menos que las propiedades de acceso telefónico de la cuenta de
usuario se hayan configurado para conceder acceso.

Si las propiedades de acceso telefónico de la cuenta de usuario se configuran para

denegar el acceso, NPS rechazará la solicitud de conexión.

Configuración importante
Cuando se usa el Asistente para nueva directiva de red para crear una directiva de red,
el valor especificado en Método de conexión de red se usa para configurar
automáticamente la condición Tipo de directiva:
 Si mantiene el valor predeterminado de No especificado, NPS evalúa la directiva
de red que crea para todos los tipos de conexión de red que usan cualquier tipo
de servidor de acceso a la red (NAS).
Si especifica un método de conexión a red, NPS sólo evalúa la directiva de red si la
solicitud de conexión se origina en el tipo de servidor de acceso a red que haya
especificado.

En la página Permiso de acceso, debe seleccionar Acceso concedido si desea que la

directiva permita a los usuarios conectarse a la red. Si desea que la directiva impida que
los usuarios se conecten a la red, seleccione Acceso denegado.

Si desea que las propiedades de acceso telefónico de la cuenta de usuario de Active

Directory® Domain Services (AD DS) determinen el permiso de acceso, puede activar la
casilla Access is determined by User Dial-in properties (El acceso viene determinado
por las propiedades de acceso telefónico de usuario).

La pertenencia a Administradores de dominio, o equivalente, es lo mínimo necesario

para completar este procedimiento.

Para agregar una directiva de red

1. Abra la consola NPS y, a continuación, haga doble clic en Directivas.

2. En el árbol de consola, haga clic con el botón derecho en Directivas de red y haga
clic en Nuevo. Se abre el asistente para nueva directiva de red.

3. Use este asistente para crear una directiva.

Creación de directivas de red para acceso

telefónico o VPN con un asistente
Puede usar este procedimiento para crear las directivas de solicitud de conexión y las
directivas de red necesarias para implementar servidores de acceso telefónico o
servidores de red privada virtual (VPN) como clientes Servicio de autenticación remota
telefónica de usuario (RADIUS) en el servidor NPS RADIUS.

７ Nota

Los equipos cliente, como equipos portátiles y otros equipos que ejecutan sistemas
operativos cliente, no son clientes RADIUS. Los clientes RADIUS son servidores de
acceso a la red, como puntos de acceso inalámbricos, conmutadores de
autenticación 802.1X, servidores de red privada virtual (VPN) y servidores de acceso
 telefónico, ya que estos dispositivos usan el protocolo RADIUS para comunicarse
con servidores RADIUS como NPSs.

En este procedimiento se explica cómo abrir el Asistente para nuevas conexiones de

acceso telefónico o de red privada virtual en NPS.

Una vez que ejecute el asistente, se crean las siguientes directivas:

Una directiva de solicitud de conexión

Una directiva de red

Puede ejecutar el asistente para nuevas conexiones de acceso telefónico o de red

privada virtual cada vez que necesite crear nuevas directivas para servidores de acceso
telefónico y servidores VPN.

La ejecución del Asistente para nuevas conexiones de acceso telefónico o de red privada
virtual no es el único paso necesario para implementar servidores VPN o de acceso
telefónico como clientes RADIUS en nps. Ambos métodos de acceso a la red precisan la
implementación de componentes adicionales de hardware y software.

La pertenencia a Administradores de dominio, o equivalente, es lo mínimo necesario

para completar este procedimiento.

Para crear directivas para acceso telefónico o VPN con un

asistente
1. Abra la consola de NPS. Si aún no está seleccionada, haga clic en NPS (local). Si
desea crear directivas en un NPS remoto, seleccione el servidor.

2. En Tareas inicialesconfiguración estándar, seleccione Servidor RADIUS para

Conexiones VPN o acceso telefónico. El texto y los vínculos del texto cambian
para reflejar la selección.

3. Haga clic en Configurar VPN o Acceso telefónico con un asistente. Se abre el

asistente para nueva conexión de acceso telefónico o de red privada virtual.

4. Siga las instrucciones del asistente para completar la creación de las nuevas
directivas.

Crear directivas de red para 802.1X cableada o

inalámbrica con un asistente
Puede usar este procedimiento para crear la directiva de solicitud de conexión y la
directiva de red necesarias para implementar conmutadores de autenticación 802.1X o
puntos de acceso inalámbricos 802.1X como clientes Servicio de autenticación remota
telefónica de usuario (RADIUS) en el servidor NPS RADIUS.

En este procedimiento se explica cómo iniciar el Asistente para nuevas conexiones

cableadas e inalámbricas seguras IEEE 802.1X en NPS.

Una vez que ejecute el asistente, se crean las siguientes directivas:

Una directiva de solicitud de conexión

Una directiva de red

Puede ejecutar el asistente para Nuevas conexiones cableadas e inalámbricas seguras

IEEE 802.1X todas las veces que necesite para crear nuevas directivas para acceso
802.1X.

La ejecución del asistente New IEEE 802.1X Secure Wired and Wireless Connections
(Nuevas conexiones cableadas e inalámbricas seguras IEEE 802.1X) no es el único paso
necesario para implementar conmutadores de autenticación 802.1X y puntos de acceso
inalámbrico como clientes RADIUS en nps. Ambos métodos de acceso a la red precisan
la implementación de componentes adicionales de hardware y software.

La pertenencia a Administradores de dominio, o equivalente, es lo mínimo necesario

para completar este procedimiento.

Para crear directivas para conexiones cableadas o

inalámbricas 802.1X con un asistente
1. En nps, en Administrador del servidor, haga clic en Herramientasy, a continuación,
haga clic en Servidor de directivas de red. Se abre la consola NPS.

2. Si aún no está seleccionada, haga clic en NPS (local). Si desea crear directivas en
un NPS remoto, seleccione el servidor.

3. En Tareas inicialesconfiguración estándar, seleccione Servidor RADIUS para

conexiones inalámbricas o cableadas 802.1X. El texto y los vínculos del texto
cambian para reflejar la selección.

4. Haga clic en Configurar 802.1X mediante un asistente. Se abre el asistente para

Nuevas conexiones cableadas e inalámbricas seguras IEEE 802.1X.

5. Siga las instrucciones del asistente para completar la creación de las nuevas
directivas.
Configurar NPS para omitir las propiedades de
acceso telefónico de la cuenta de usuario
Use este procedimiento para configurar una directiva de red NPS para omitir las
propiedades de acceso telefónico de las cuentas de usuario Active Directory durante el
proceso de autorización. Las cuentas de usuario de Usuarios y equipos de Active
Directory tienen propiedades de acceso telefónico que NPS evalúa durante el proceso
de autorización, a menos que la propiedad Permiso de acceso a la red de la cuenta de
usuario esté establecida en Controlar el acceso a través de la directiva de red NPS.

Hay dos circunstancias en las que puede que desee configurar NPS para omitir las
propiedades de acceso telefónico de las cuentas de usuario en Active Directory:

Si desea simplificar la autorización de NPS mediante la directiva de red, pero no

todas las cuentas de usuario tienen la propiedad Permiso de acceso de red
establecida en Control del acceso a través de la directiva de red NPS. Por ejemplo,
algunas cuentas de usuario podrían tener la propiedad Permiso de acceso de red
de la cuenta de usuario establecida en Denegar acceso o Permitir acceso.

Cuando otras propiedades de acceso telefónico de cuentas de usuario no son

aplicables al tipo de conexión configurado en la directiva de red. Por ejemplo, las
propiedades que no sean la configuración De permiso de acceso a la red solo son
aplicables a las conexiones VPN o de acceso telefónico, pero la directiva de red
que va a crear es para conexiones inalámbricas o de conmutador de autenticación.

Puede usar este procedimiento para configurar NPS para omitir las propiedades de
acceso telefónico de la cuenta de usuario. Si una solicitud de conexión coincide con la
directiva de red en la que está activada esta casilla, NPS no usa las propiedades de
acceso telefónico de la cuenta de usuario para determinar si el usuario o equipo está
autorizado para acceder a la red. solo se usa la configuración de la directiva de red para
determinar la autorización.

La pertenencia a administradores, o equivalente, es el mínimo necesario para completar

este procedimiento.

1. En nps, en Administrador del servidor, haga clic en Herramientasy, a continuación,

haga clic en Servidor de directivas de red. Se abre la consola NPS.

2. Haga doble clic en Directivas, haga clic en Directivas de redy, a continuación, en el

panel de detalles, haga doble clic en la directiva que desea configurar.

3. En el cuadro de diálogo Propiedades de la directiva, en la pestaña Información

general, en Permiso de acceso, active la casilla Omitir las propiedades de acceso
 telefónico de la cuenta de usuario y, a continuación, haga clic en Aceptar.

Para configurar NPS para omitir las propiedades de

acceso telefónico de la cuenta de usuario

Configuración de NPS para VLAN

Mediante el uso de servidores de acceso a la red y NPS con vlan en Windows Server
2016, puede proporcionar a los grupos de usuarios acceso solo a los recursos de red
adecuados para sus permisos de seguridad. Por ejemplo, puede proporcionar a los
visitantes acceso inalámbrico a Internet sin permitirles acceder a la red de la
organización.

Además, las VLAN permiten agrupar lógicamente los recursos de red que existen en
diferentes ubicaciones físicas o en subredes físicas diferentes. Por ejemplo, los miembros
del departamento de ventas y sus recursos de red, como equipos cliente, servidores e
impresoras, pueden encontrarse en varios edificios diferentes de la organización, pero
puede colocar todos estos recursos en una VLAN que use el mismo intervalo de
direcciones IP. A continuación, la VLAN funciona, desde la perspectiva del usuario final,
como una sola subred.

También puede usar VLAN cuando quiera segregar una red entre distintos grupos de
usuarios. Una vez que haya determinado cómo desea definir los grupos, puede crear
grupos de seguridad en el complemento Usuarios y equipos de Active Directory y, a
continuación, agregar miembros a los grupos.

Configuración de una directiva de red para VLAN

Puede usar este procedimiento para configurar una directiva de red que asigne usuarios
a una VLAN. Cuando se usa hardware de red con vlan, como enrutadores,
conmutadores y controladores de acceso, puede configurar la directiva de red para
indicar a los servidores de acceso que coloquen miembros de grupos de Active
Directory específicos en VLAN específicas. Esta capacidad de agrupar los recursos de red
lógicamente con VLAN proporciona flexibilidad al diseñar e implementar soluciones de
red.

Al configurar los valores de una directiva de red NPS para su uso con VLAN, debe
configurar los atributos Tunnel-Medium-Type, Tunnel-Pvt-Group-ID, Tunnel-Typey
Tunnel-Tag.
Este procedimiento se proporciona como una guía; la configuración de red puede
requerir una configuración diferente de la que se describe a continuación.

La pertenencia a administradores, o equivalente, es el mínimo necesario para completar

este procedimiento.

Para configurar una directiva de red para VLAN

1. En nps, en Administrador del servidor, haga clic en Herramientasy, a continuación,
haga clic en Servidor de directivas de red. Se abre la consola NPS.

2. Haga doble clic en Directivas, haga clic en Directivas de redy, a continuación, en el

panel de detalles, haga doble clic en la directiva que desea configurar.

3. En el cuadro de diálogo Propiedades de directiva, haga clic en Configuración

pestaña.

4. En Propiedades de directiva, en Configuración, en Atributos RADIUS, asegúrese

de que estándar está seleccionado.

5. En el panel de detalles, en Atributos, el atributo Service-Type se configura con un

valor predeterminado de Framed. De forma predeterminada, para las directivas
con métodos de acceso de VPN y acceso telefónico, el atributo Framed-Protocol
se configura con un valor de PPP. Para especificar atributos de conexión
adicionales necesarios para las VLAN, haga clic en Agregar. Se abre el cuadro de
diálogo Agregar atributo RADIUS estándar.

6. En Agregar atributo RADIUS estándar, en Atributos, desplácese hacia abajo hasta

y agregue los atributos siguientes:

Tunnel de tipo medio. Seleccione un valor adecuado para las selecciones

anteriores que ha realizado para la directiva. Por ejemplo, si la directiva de
red que está configurando es una directiva inalámbrica, seleccione Valor : 802
(incluye todos los 802 medios más el formato canónico Ethernet).

Tunnel-Pvt-Group-ID. Escriba el entero que representa el número de VLAN al

que se asignarán los miembros del grupo.

Tunnel-Type. Seleccione Redes LAN virtuales (VLAN).

7. En Agregar atributo RADIUS estándar, haga clic en Cerrar.

8. Si el servidor de acceso a la red (NAS) requiere el uso del atributo Tunnel-Tag, siga
estos pasos para agregar el atributo Tunnel-Tag a la directiva de red. Si la
 documentación de NAS no menciona este atributo, no lo agregue a la directiva. Si
es necesario, agregue los atributos de la manera siguiente:

En Propiedades de directiva, en Configuración, en Atributos RADIUS, haga

clic en Específico del proveedor.

En el panel de detalles, haga clic en Agregar. Se abre el cuadro de diálogo

Agregar atributo específico del proveedor.

En Atributos, desplácese hacia abajo hasta y seleccione Tunnel-Tag y, a

continuación, haga clic en Agregar. Se abre el cuadro de diálogo
Información de atributo.

En Valor de atributo, escriba el valor que obtuvo de la documentación de

hardware.

Configuración del tamaño de carga de EAP

En algunos casos, los enrutadores o firewalls descartan paquetes porque están
configurados para descartar paquetes que requieren fragmentación.

Al implementar NPS con directivas de red que usan el Protocolo de autenticación

extensible (EAP) con seguridad de la capa de transporte (TLS) o EAP-TLS, como método
de autenticación, la unidad de transmisión máxima (MTU) predeterminada que NPS usa
para las cargas de EAP es de 1500 bytes.

Este tamaño máximo para la carga de EAP puede crear mensajes RADIUS que requieren
fragmentación por parte de un enrutador o firewall entre nps y un cliente RADIUS. Si
este es el caso, un enrutador o firewall situado entre el cliente RADIUS y NPS podría
descartar de forma silenciosa algunos fragmentos, lo que provocaría un error de
autenticación y la incapacidad del cliente de acceso para conectarse a la red.

Use el procedimiento siguiente para reducir el tamaño máximo que NPS usa para las
cargas de EAP ajustando el atributo Framed-MTU de una directiva de red a un valor no
mayor que 1344.

La pertenencia a administradores, o equivalente, es el mínimo necesario para completar

este procedimiento.

Para configurar el atributo Framed-MTU

1. En nps, en Administrador del servidor, haga clic en Herramientasy, a continuación,
haga clic en Servidor de directivas de red. Se abre la consola NPS.
 2. Haga doble clic en Directivas, haga clic en Directivas de redy, a continuación, en el
panel de detalles, haga doble clic en la directiva que desea configurar.

3. En el cuadro de diálogo Propiedades de directiva, haga clic en Configuración

pestaña.

4. En Configuración, en Atributos RADIUS, haga clic en Estándar. En el panel de

detalles, haga clic en Agregar. Se abre el cuadro de diálogo Agregar atributo
RADIUS estándar.

5. En Atributos, desplácese hacia abajo hasta y haga clic en Framed-MTU y, a

continuación, haga clic en Agregar. Se abre el cuadro de diálogo Información de
atributo.

6. En Valor de atributo, escriba un valor igual o menor que 1344. Haga clic en
Aceptar, en Cerrary, a continuación, en Aceptar.

Para más información sobre las directivas de red, consulte Directivas de red.

Para obtener ejemplos de sintaxis de coincidencia de patrones para especificar atributos

de directiva de red, vea Usar expresiones regulares en NPS.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Configurar las cuentas de servidor de
directivas de redes
Artículo • 21/12/2022 • Tiempo de lectura: 11 minutos

Hay tres tipos de registro para el Servidor de directivas de redes (NPS):

Registro de eventos. Se usa principalmente para la auditoría y la solución de

problemas de intentos de conexión. Puede configurar el registro de eventos NPS
obteniendo las propiedades de NPS en la consola de NPS.

Registro de solicitudes de autenticación y contabilidad de usuario en un archivo

local. Se usa principalmente para realizar el análisis de las conexiones y para la
facturación. Además, resulta útil como herramienta de investigación de seguridad,
ya que le proporciona un método para realizar un seguimiento de la actividad de
un usuario malintencionado después de un ataque. Puede configurar el registro de
archivos local mediante el Asistente para configuración de contabilidad.

Registro de solicitudes de autenticación y contabilidad de usuarios en una base

Microsoft SQL Server de datos compatible con XML. Se usa para permitir que
varios servidores que ejecuten NPS tengan un origen de datos. Además, ofrece las
ventajas de usar una base de datos relacional. Puede configurar el SQL Server
mediante el Asistente para configuración de contabilidad.

Usar el Asistente para configuración de

contabilidad
Mediante el Asistente para configuración de contabilidad, puede configurar las cuatro
opciones de contabilidad siguientes:

SQL solo el registro. Con esta configuración, puede configurar un vínculo de datos
a un SQL Server que permita a NPS conectarse y enviar datos de contabilidad al
SQL servidor. Además, el asistente puede configurar la base de datos en SQL
Server para asegurarse de que la base de datos es compatible con el registro de
servidor nps SQL servidor.
Solo registro de texto. Con esta configuración, puede configurar NPS para
registrar los datos de contabilidad en un archivo de texto.
Registro paralelo. Con esta configuración, puede configurar la base de datos SQL
Server de datos. También puede configurar el registro de archivos de texto para
 que NPS se registra simultáneamente en el archivo de texto y en la base SQL
Server datos.
SQL registro con copia de seguridad. Con esta configuración, puede configurar la
base de datos SQL Server de datos. Además, puede configurar el registro de
archivos de texto que NPS usa si SQL Server error en el registro.

Además de esta configuración, tanto el registro SQL Server como el registro de texto
permiten especificar si NPS sigue procesando solicitudes de conexión si se produce un
error en el registro. Puede especificarlo en la sección Acción de error de registro en
propiedades de registro de archivos locales, en propiedades de registro de servidor de
SQL y mientras ejecuta el Asistente para configuración de cuentas.

Para ejecutar el Asistente para configuración de

contabilidad
Para ejecutar el Asistente para configuración de contabilidad, complete los pasos
siguientes:

1. Abra la consola NPS o el complemento NPS Microsoft Management Console

(MMC).
2. En el árbol de consola, haga clic en Contabilidad.
3. En el panel de detalles, en Contabilidad, haga clic en Configurar contabilidad.

Configuración de las propiedades del archivo

de registro nps
Puede configurar el servidor de directivas de red (NPS) para realizar cuentas de Servicio
de autenticación remota telefónica de usuario (RADIUS) para las solicitudes de
autenticación de usuario, los mensajes de Access-Accept, los mensajes de Access-Reject,
las solicitudes y respuestas de contabilidad y las actualizaciones periódicas del estado.
Puede usar este procedimiento para configurar los archivos de registro en los que desea
almacenar los datos de contabilidad.

Para obtener más información sobre cómo interpretar los archivos de registro, vea
Interpretación de archivos de registro de formato de base de datos NPS.

Para evitar que los archivos de registro llenen el disco duro, se recomienda mantenerlos
en una partición diferente de la del sistema. A continuación se proporciona más
información sobre cómo configurar la contabilidad de NPS:
 Para enviar los datos del archivo de registro para que sean recopilados por otro
proceso, puede configurar NPS para que escriba en una canalización con nombre.
Para usar canalizaciones con nombre, establezca la carpeta del archivo de registro
en \.\pipe o \NombreDeEquipo\canalización. El programa de servidor de
canalización con nombre crea una canalización con nombre denominada
\.\pipe\[Link] para aceptar los datos. En el cuadro de diálogo de propiedades
de Archivo local, en Crear un nuevo archivo de registro, seleccione Nunca (tamaño
de archivo ilimitado) al utilizar canalizaciones con nombre.

El directorio de archivo de registro se puede crear mediante variables de entorno

del sistema (en lugar de variables de usuario), como %unidadDelSistema%,
%raízDelSistema% y %windir%. Por ejemplo, la ruta de acceso siguiente, mediante
la variable de entorno %windir%, busca el archivo de registro en el directorio del
sistema en la subcarpeta \System32\Logs (es decir, %windir%\System32\Logs).

El cambio de los formatos de archivo de registro no hace que se cree otro registro.
Si cambia los formatos de archivo de registro, el archivo que está activo en el
momento del cambio contendrá una mezcla de ambos formatos (los registros al
principio del registro tendrán el formato anterior, mientras que los que están en el
final del registro tendrán el formato nuevo).

Si la cuenta RADIUS presenta un error debido a que el disco duro está lleno o por
otros motivos, NPS deja de procesar las solicitudes de conexión, con lo que impide
que los usuarios tengan acceso a los recursos de red.

NPS proporciona la capacidad de registro en una base de datos de Microsoft®

SQL Server™ además de, o en lugar de, registro en un archivo local.

La pertenencia al grupo Administradores de dominio es el mínimo necesario para

realizar este procedimiento.

Para configurar las propiedades del archivo de registro

nps
1. Abra la consola NPS o el complemento NPS Microsoft Management Console
(MMC).
2. En el árbol de consola, haga clic en Contabilidad.
3. En el panel de detalles, en Propiedades del archivo de registro, haga clic en
Cambiar propiedades del archivo de registro. Se abre el cuadro de diálogo
Propiedades del archivo de registro.
4. En Propiedades del archivo de registro, en la Configuración, en Registrar la
siguiente información, asegúrese de que decide registrar suficiente información
 para lograr sus objetivos de contabilidad. Por ejemplo, si los registros necesitan
realizar la correlación de sesión, active todas las casillas.
5. En Acción de error de registro, seleccione Si se produce un error en el registro,
descarte las solicitudes de conexión si desea que NPS detenga el procesamiento
de mensajes Access-Request cuando los archivos de registro estén llenos o no
estén disponibles por algún motivo. Si desea que NPS siga procesando solicitudes
de conexión si se produce un error en el registro, no active esta casilla.
6. En el cuadro de diálogo Propiedades del archivo de registro , haga clic en la
pestaña Archivo de registro .
7. En la pestaña Archivo de registro, en Directorio, escriba la ubicación donde desea
almacenar los archivos de registro nps. La ubicación predeterminada es la carpeta
raízDelSistema\System32\archivosDeRegistro.
Si no proporciona una instrucción de ruta de acceso completa en el directorio del
archivo de registro, se usa la ruta de acceso predeterminada. Por ejemplo, si
escribe NPSLogFile en el directorio del archivo de registro, el archivo se encuentra
en %systemroot%\System32\NPSLogFile.
8. En Formato, haga clic en Compatible con DTS. Si lo prefiere, puede seleccionar un
formato de archivo heredado, como ODBC (heredado) o IAS (heredado).
Los tipos de archivo heredados ODBC e IAS contienen un subconjunto de la
información que NPS envía a su base de SQL Server datos. El formato XML del
tipo de archivo compatible con DTS es idéntico al formato XML que USA NPS para
importar datos en su base de SQL Server datos. Por lo tanto, el formato de archivo
compatible con DTS proporciona una transferencia de datos más eficaz y completa
a la base de datos SQL Server estándar para NPS.
9. En Crear un nuevo archivo de registro, para configurar NPS para iniciar nuevos
archivos de registro a intervalos especificados, haga clic en el intervalo que desea
usar:

Para un gran volumen de transacciones y actividad de registro, haga clic en

Diariamente.
Para volúmenes de transacciones menores y actividad de registro, haga clic
en Semanalo Mensual.
Para almacenar todas las transacciones en un archivo de registro, haga clic en
Nunca (tamaño de archivo ilimitado).
Para limitar el tamaño de cada archivo de registro, haga clic en Cuando el
archivo de registro alcance este tamaño y, a continuación, escriba un tamaño
de archivo, después del cual se crea un nuevo registro. El tamaño
predeterminado es 10 megabytes (MB).

10. Si desea que NPS elimine los archivos de registro antiguos para crear espacio en
disco para los nuevos archivos de registro cuando el disco duro esté cerca de su
 capacidad, asegúrese de que cuando el disco esté lleno, elimine los archivos de
registro más antiguos seleccionados. Sin embargo, esta opción no está disponible
si el valor de Crear un nuevo archivo de registro es Nunca (tamaño de archivo
ilimitado). Además, si el archivo de registro más antiguo es el archivo de registro
actual, no se elimina.

Configuración del registro de SQL Server NPS

Puede usar este procedimiento para registrar datos de contabilidad RADIUS en una
base de datos local o remota que ejecute Microsoft SQL Server.

７ Nota

NPS da formato a los datos de contabilidad como un documento XML que envía al
procedimiento almacenado report_event en la base de datos SQL Server que
designe en NPS. Para SQL Server el registro funcione correctamente, debe tener un
procedimiento almacenado denominado report_event en la base de datos de SQL
Server que pueda recibir y analizar los documentos XML de NPS.

La pertenencia a Administradores de dominio, o equivalente, es lo mínimo necesario

para completar este procedimiento.

Para configurar SQL Server registro en NPS

1. Abra la consola NPS o el complemento NPS Microsoft Management Console
(MMC).
2. En el árbol de consola, haga clic en Contabilidad.
3. En el panel de detalles, en SQL Server propiedades de registro, haga clic en
Cambiar SQL Server propiedades de registro. Se abre SQL Server cuadro de
diálogo Propiedades de registro.
4. En Registrar la siguiente información, seleccione la información que desea
registrar:

Para registrar todas las solicitudes de contabilidad, haga clic en Solicitudes

de contabilidad.
Para registrar las solicitudes de autenticación, haga clic en Solicitudes de
autenticación.
Para registrar el estado de la contabilidad periódica, haga clic en Estado de
contabilidad periódica.
 Para registrar el estado periódico, como las solicitudes de contabilidad
provisionales, haga clic en Estado periódico.

5. Para configurar el número de sesiones simultáneas permitidas entre el servidor que

ejecuta NPS y SQL Server, escriba un número en Número máximo de sesiones
simultáneas.
6. Para configurar el origen SQL Server datos, en SQL Server, haga clic en Configurar.
Se abre el cuadro de diálogo Propiedades de vínculo de datos . En la pestaña
Conexión, especifique lo siguiente:

Para especificar el nombre del servidor en el que se almacena la base de

datos, escriba o seleccione un nombre en Seleccionar o escriba un nombre
de servidor.
Para especificar el método de autenticación con el que iniciar sesión en el
servidor, haga clic en Usar Windows seguridad integrada de NT. O bien,
haga clic en Usar un nombre de usuario y una contraseña específicos y
escriba las credenciales en Nombre de usuario y Contraseña.
Para permitir una contraseña en blanco, haga clic en Contraseña en blanco.
Para almacenar la contraseña, haga clic en Permitir guardar contraseña.
Para especificar a qué base de datos conectarse en el equipo que ejecuta SQL
Server, haga clic en Seleccionar la base de datos en el servidor y, a
continuación, seleccione un nombre de base de datos de la lista.

7. Para probar la conexión entre NPS y SQL Server, haga clic en Probar conexión.
Haga clic en Aceptar para cerrar Propiedades de vínculo de datos.
8. En Acción de error de registro, seleccione Habilitar el registro de archivos de texto
para la conmutación por error si desea que NPS continúe con el registro de
archivos de texto si SQL Server error en el registro.
9. En la acción Error de registro, seleccione Si se produce un error en el registro,
descarte las solicitudes de conexión si desea que NPS deje de procesar mensajes
Access-Request cuando los archivos de registro estén llenos o no estén
disponibles por algún motivo. Si desea que NPS siga procesando solicitudes de
conexión si se produce un error en el registro, no active esta casilla.

Ping user-name
Algunos servidores proxy RADIUS y servidores de acceso a la red envían periódicamente
solicitudes de autenticación y contabilidad (conocidas como solicitudes de ping) para
comprobar que nps está presente en la red. Estas solicitudes ping incluyen nombres de
usuario ficticios. Cuando NPS procesa dichas solicitudes, los archivos de registro de
eventos y cuentas se llenan de registros de rechazos de acceso, lo que hace más difícil
realizar un seguimiento de los registros válidos.

Al configurar una entrada del Registro para hacer ping al nombre de usuario, NPS
coincide con el valor de entrada del Registro con el valor de nombre de usuario de las
solicitudes de ping de otros servidores. Una entrada del Registro ping user-name
especifica el nombre de usuario ficticio (o un patrón de nombre de usuario, con
variables, que coincide con el nombre de usuario ficticio) enviado por servidores proxy
RADIUS y servidores de acceso a la red. Cuando NPS recibe solicitudes de ping que
coinciden con el valor de entrada del Registro de nombre de usuario ping, NPS rechaza
las solicitudes de autenticación sin procesar la solicitud. NPS no registra las
transacciones relacionadas con el nombre de usuario ficticio de los archivos de registro,
lo que facilita la interpretación del registro de eventos.

El nombre de usuario ping no está instalado de forma predeterminada. Debe agregar

ping user-name al registro. Puede agregar una entrada al Registro mediante el Editor
del Registro.

Ｕ Precaución

la modificación incorrecta del Registro puede dañar gravemente el sistema. Antes

de realizar cambios en el Registro, debe hacer una copia de seguridad de los datos
de valor guardados en el equipo.

Para agregar ping user-name al registro

Un miembro del grupo administradores local puede agregar el nombre de usuario ping
a la siguiente clave del Registro como un valor de cadena:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IAS\Parameters

Nombre:
Tipo:
Datos: Nombre de usuario

 Sugerencia

Para indicar más de un nombre de usuario para un valor de nombre de usuario

ping , escriba un patrón de nombre, como un nombre DNS, incluidos los caracteres
comodín, en Datos.
Configurar clientes RADIUS
Artículo • 21/12/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para configurar servidores de acceso de red como clientes
RADIUS en NPS.

Al agregar un nuevo servidor de acceso a la red (servidor VPN, punto de acceso

inalámbrico, conmutador de autenticación o servidor de acceso telefónico) a la red,
debe agregar el servidor como cliente RADIUS en NPS y, a continuación, configurar el
cliente RADIUS para que se comunique con nps.

） Importante

Los equipos y dispositivos cliente, como equipos portátiles, tabletas, teléfonos y

otros equipos que ejecutan sistemas operativos cliente, no son clientes RADIUS.
Los clientes RADIUS son servidores de acceso de red, como puntos de acceso
inalámbricos, conmutadores compatibles con 802.1X, servidores de red privada
virtual (VPN) y servidores de acceso telefónico, ya que usan el protocolo RADIUS
para comunicarse con servidores RADIUS, como servidores de servidor de
directivas de red (NPS).

Este paso también es necesario cuando nps es miembro de un grupo de servidores

RADIUS remoto que está configurado en un proxy NPS. En esta circunstancia, además
de realizar los pasos de esta tarea en el proxy NPS, debe hacer lo siguiente:

En el proxy NPS, configure un grupo de servidores RADIUS remoto que contenga

nps.
En el SERVIDOR NPS remoto, configure el proxy NPS como un cliente RADIUS.

Para realizar los procedimientos de este tema, debe tener al menos un servidor de
acceso de red (servidor VPN, punto de acceso inalámbrico, conmutador de
autenticación o servidor de acceso telefónico) o un proxy NPS instalado físicamente en
la red.

Configuración del servidor de acceso a la red

Use este procedimiento para configurar servidores de acceso a la red para su uso con
NPS. Al implementar servidores de acceso de red (NAS) como clientes RADIUS, debe
configurar los clientes para que se comuniquen con los NPS donde se configuran los
NAS como clientes.

En este procedimiento se proporcionan instrucciones generales sobre la configuración

que debe usar para configurar los NAS. Para obtener instrucciones específicas sobre
cómo configurar el dispositivo que va a implementar en la red, consulte la
documentación del producto NAS.

Para configurar el servidor de acceso a la red

1. En el NAS, en configuración RADIUS, seleccione Autenticación RADIUS en el
puerto 1812 del Protocolo de datagramas de usuario (UDP) y Cuentas RADIUS en
el puerto UDP 1813.
2. En Servidor de autenticación o servidor RADIUS, especifique el NPS por dirección
IP o nombre de dominio completo (FQDN), en función de los requisitos del NAS.
3. En Secreto o Secreto compartido, escriba una contraseña segura. Al configurar el
NAS como cliente RADIUS en NPS, usará la misma contraseña, por lo que no la
olvide.
4. Si usa PEAP o EAP como método de autenticación, configure el NAS para que use
la autenticación EAP.
5. Si va a configurar un punto de acceso inalámbrico, en SSID, especifique un
identificador de conjunto de servicios (SSID), que es una cadena alfanumérica que
actúa como nombre de red. Este nombre se difunde mediante puntos de acceso a
clientes inalámbricos y es visible para los usuarios en sus zonas de acceso de
fidelidad inalámbrica (Wi-Fi).
6. Si va a configurar un punto de acceso inalámbrico, en 802.1X y WPA, habilite la
autenticación IEEE 802.1X si desea implementar PEAP-MS-CHAP v2, PEAP-TLS o
EAP-TLS.

Agregar el servidor de acceso de red como

cliente RADIUS en NPS
Use este procedimiento para agregar un servidor de acceso a la red como cliente
RADIUS en NPS. Puede usar este procedimiento para configurar un NAS como cliente
RADIUS mediante la consola NPS.

Para completar este procedimiento, debe pertenecer al grupo Administradores.

Para agregar un servidor de acceso de red como cliente

RADIUS en NPS
 1. En NPS, en Administrador del servidor, haga clic en Herramientasy, a continuación,
haga clic en Servidor de directivas de red. Se abre la consola NPS.
2. En la consola NPS, haga doble clic en Clientes y servidores RADIUS. Haga clic con
el botón derecho en Clientes RADIUSy, a continuación, haga clic en Nuevo cliente
RADIUS.
3. En Nuevo cliente RADIUS, compruebe que la casilla Habilitar este cliente RADIUS
está activada.
4. En Nuevo cliente RADIUS, en Nombre descriptivo, escriba un nombre para
mostrar para el NAS. En Dirección (IP o DNS), escriba la dirección IP de NAS o el
nombre de dominio completo (FQDN). Si escribe el FQDN, haga clic en Comprobar
si desea comprobar que el nombre es correcto y se asigna a una dirección IP
válida.
5. En Nuevo cliente RADIUS, en Proveedor, especifique el nombre del fabricante de
NAS. Si no está seguro del nombre del fabricante de NAS, seleccione RADIUS
estándar.
6. En Nuevo cliente RADIUS, en Secreto compartido, realice una de las siguientes
acciones:

Asegúrese de que manual está seleccionado y, a continuación, en Secreto

compartido, escriba la contraseña segura que también se escribe en el NAS.
Vuelva a escribir el secreto compartido en Confirmar secreto compartido.
Seleccione Generar y, a continuación, haga clic en Generar para generar
automáticamente un secreto compartido. Guarde el secreto compartido
generado para la configuración en el NAS para que pueda comunicarse con
nps.

7. En Nuevo cliente RADIUS, en Opciones adicionales, si usa métodos de

autenticación distintos de EAP y PEAP, y si su NAS admite el uso del atributo
autenticador de mensajes, seleccione Mensajes de solicitud de acceso debe
contener el atributo Message Authenticator.
8. Haga clic en OK. El NAS aparece en la lista de clientes RADIUS configurados en
NPS.

Configuración de clientes RADIUS por intervalo

de direcciones IP en Windows Server 2016
datacenter
Si está ejecutando Windows Server 2016 Datacenter, puede configurar clientes RADIUS
en NPS por intervalo de direcciones IP. Esto le permite agregar un gran número de
clientes RADIUS (como puntos de acceso inalámbrico) a la consola NPS a la vez, en
lugar de agregar cada cliente RADIUS individualmente.

No puede configurar clientes RADIUS por intervalo de direcciones IP si ejecuta NPS en

Windows Server 2016 Estándar.

Use este procedimiento para agregar un grupo de servidores de acceso de red (NAS)
como clientes RADIUS que están configurados con direcciones IP del mismo intervalo
de direcciones IP.

Todos los clientes RADIUS del intervalo deben usar la misma configuración y el mismo
secreto compartido.

Para completar este procedimiento, debe pertenecer al grupo Administradores.

Para configurar clientes RADIUS por intervalo de

direcciones IP
1. En NPS, en Administrador del servidor, haga clic en Herramientasy, a continuación,
haga clic en Servidor de directivas de red. Se abre la consola NPS.
2. En la consola NPS, haga doble clic en Clientes y servidores RADIUS. Haga clic con
el botón derecho en Clientes RADIUSy, a continuación, haga clic en Nuevo cliente
RADIUS.
3. En Nuevo cliente RADIUS, en Nombre descriptivo, escriba un nombre para
mostrar para la colección de NAS.
4. En Dirección (IP o DNS), escriba el intervalo de direcciones IP para los clientes
RADIUS mediante la notación de enrutamiento de Inter-Domain sin clases (CIDR).
Por ejemplo, si el intervalo de direcciones IP de los NAS es [Link], escriba
[Link]/16.
5. En Nuevo cliente RADIUS, en Proveedor, especifique el nombre del fabricante de
NAS. Si no está seguro del nombre del fabricante de NAS, seleccione RADIUS
estándar.
6. En Nuevo cliente RADIUS, en Secreto compartido, realice una de las siguientes
acciones:

Asegúrese de que manual está seleccionado y, a continuación, en Secreto

compartido, escriba la contraseña segura que también se escribe en el NAS.
Vuelva a escribir el secreto compartido en Confirmar secreto compartido.
Seleccione Generar y, a continuación, haga clic en Generar para generar
automáticamente un secreto compartido. Guarde el secreto compartido
generado para la configuración en el NAS para que pueda comunicarse con
nps.
 7. En Nuevo cliente RADIUS, en Opciones adicionales, si usa métodos de
autenticación distintos de EAP y PEAP, y si todos los NAS admiten el uso del
atributo autenticador de mensajes, seleccione Los mensajes de solicitud de acceso
deben contener el atributo Message Authenticator.
8. Haga clic en OK. Los NAS aparecen en la lista de clientes RADIUS configurados en
NPS.

Para obtener más información, vea Clientes RADIUS.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Configurar grupos de servidores
RADIUS remotos
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para configurar grupos de servidores RADIUS remotos cuando
desee configurar NPS para que actúe como servidor proxy y reenviar solicitudes de
conexión a otros NPS para su procesamiento.

Adición de un grupo de servidores remotos

RADIUS
Puede usar este procedimiento para agregar un nuevo grupo de servidores remotos
RADIUS en el complemento Servidor de directivas de redes (NPS).

Al configurar NPS como proxy RADIUS, crea una nueva directiva de solicitud de
conexión que NPS usa para determinar cuáles son las solicitudes de conexión que se
deben reenviar a otros servidores RADIUS. Además, la directiva de solicitud de conexión
se configura especificando un grupo de servidores RADIUS remoto que contiene uno o
varios servidores RADIUS, que indica a NPS dónde enviar las solicitudes de conexión
que coinciden con la directiva de solicitud de conexión.

７ Nota

Además, puede configurar un nuevo grupo de servidores remotos RADIUS durante

el proceso de creación de una nueva directiva de solicitud de conexión.

La pertenencia a Administradores de dominio, o equivalente, es lo mínimo necesario

para completar este procedimiento.

Para agregar un grupo de servidores RADIUS remoto

1. En Administrador del servidor, haga clic en Herramientasy, a continuación, haga
clic en Servidor de directivas de red para abrir la consola NPS.
2. En el árbol de consola, haga doble clic en Clientes y servidores RADIUS, haga clic
con el botón derecho en Grupos de servidores RADIUS remotosy, a continuación,
haga clic en Nuevo.
 3. Se abre el cuadro de diálogo Nuevo grupo de servidores RADIUS remotos. En
Nombre del grupo, escriba un nombre para el grupo de servidores RADIUS
remoto.
4. En Servidores RADIUS, haga clic en Agregar. Se abre el cuadro de diálogo
Agregar servidores RADIUS . Escriba la dirección IP del servidor RADIUS que desea
agregar al grupo o escriba el nombre de dominio completo (FQDN) del servidor
RADIUS y, a continuación, haga clic en Comprobar.
5. En Agregar servidores RADIUS, haga clic en la pestaña Autenticación/
contabilidad. En Secreto compartido y Confirmar secreto compartido, escriba el
secreto compartido. Debe usar el mismo secreto compartido al configurar el
equipo local como cliente RADIUS en el servidor remoto RADIUS.
6. Si no usa el Protocolo de autenticación extensible (EAP) para la autenticación, haga
clic en Solicitud debe contener el atributo autenticador del mensaje. EAP usa el
Message-Authenticator de forma predeterminada.
7. Compruebe que los números de puertos de autenticación y cuentas sean los
correctos para su implementación.
8. Si usa un secreto compartido diferente para la contabilidad, en Contabilidad,
desactive la casilla Usar el mismo secreto compartido para la autenticación y la
contabilidad y, a continuación, escriba el secreto compartido de contabilidad en
Secreto compartido y Confirmar secreto compartido.
9. Si no desea reenviar los mensajes de inicio y de detenerse del servidor de acceso
de red al servidor RADIUS remoto, desactive la casilla Reenviar el inicio y detenerse
las notificaciones del servidor de acceso a este servidor .

Para obtener más información sobre cómo administrar NPS, vea Administrar el servidor
de directivas de red.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Administrar los certificados que se usan
con NPS
Artículo • 29/09/2022 • Tiempo de lectura: 7 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Si implementa un método de autenticación basado en certificados, como Autenticación

extensible Protocol-Transport Layer Security (EAP-TLS), Autenticación extensible
protegida Protocol-Transport Seguridad de capa (PEAP-TLS) y PEAP-Microsoft Challenge
Handshake Authentication Protocol versión 2 (MS-CHAP v2), debe inscribir un
certificado de servidor en todos los NPS. El certificado de servidor debe:

Cumpla los requisitos mínimos de certificados de servidor, tal como se describe en

Configurar plantillas de certificado para los requisitos de PEAP y EAP.

Debe emitirla una entidad de certificación (CA) de confianza para los equipos
cliente. Una entidad de certificación es de confianza cuando su certificado existe
en entidades de certificación raíz de confianza almacén de certificados para el
usuario actual y el equipo local.

Las instrucciones siguientes ayudan a administrar certificados NPS en implementaciones

en las que la CA raíz de confianza es una CA de terceros, como Verisign, o es una CA
que ha implementado para la infraestructura de clave pública (PKI) mediante Servicios
de certificados de Active Directory (AD CS).

Cambiar la expiración del identificador TLS

almacenado en caché
Durante los procesos de autenticación iniciales para EAP-TLS, PEAP-TLS y PEAP-MS-
CHAP v2, NPS almacena en caché una parte de las propiedades de conexión TLS del
cliente que se conecta. El cliente también almacena en caché una parte de las
propiedades de conexión TLS de NPS.

Cada colección individual de estas propiedades de conexión TLS se denomina

identificador TLS.

Los equipos cliente pueden almacenar en caché los identificadores TLS para varios
autenticadores, mientras que los NPS pueden almacenar en caché los identificadores
TLS de muchos equipos cliente.
Los identificadores TLS almacenados en caché en el cliente y el servidor permiten que el
proceso de reauauticación se produzca más rápidamente. Por ejemplo, cuando un
equipo inalámbrico se vuelve a autenticar con un NPS, nps puede examinar el
identificador TLS para el cliente inalámbrico y puede determinar rápidamente que la
conexión del cliente es una reconexión. NPS autoriza la conexión sin realizar la
autenticación completa.

En consecuencia, el cliente examina el identificador TLS para NPS, determina que se

trata de una reconexión y no necesita realizar la autenticación del servidor.

En equipos que ejecutan Windows 10 y Windows Server 2016, la expiración

predeterminada del identificador TLS es de 10 horas.

En algunas circunstancias, es posible que desee aumentar o disminuir el tiempo de

expiración del identificador TLS.

Por ejemplo, es posible que desee reducir el tiempo de expiración del identificador TLS
en circunstancias en las que un administrador revoca el certificado de un usuario y el
certificado ha expirado. En este escenario, el usuario todavía puede conectarse a la red
si nps tiene un identificador TLS almacenado en caché que no ha expirado. Reducir la
expiración del identificador TLS podría ayudar a impedir que estos usuarios con
certificados revocados se vuelvan a conectar.

７ Nota

La mejor solución para este escenario es deshabilitar la cuenta de usuario en Active

Directory o quitar la cuenta de usuario del grupo de Active Directory al que se
concede permiso para conectarse a la red en la directiva de red. Sin embargo, la
propagación de estos cambios en todos los controladores de dominio también
podría retrasarse debido a la latencia de replicación.

Configurar la hora de expiración del

identificador TLS en los equipos cliente
Puede usar este procedimiento para cambiar la cantidad de tiempo que los equipos
cliente almacena en caché el identificador TLS de un NPS. Después de autenticar
correctamente un NPS, los equipos cliente almacenarán en caché las propiedades de
conexión TLS de NPS como un identificador TLS. El identificador TLS tiene una duración
predeterminada de 10 horas (36 000 000 milisegundos). Puede aumentar o disminuir el
tiempo de expiración del identificador TLS mediante el procedimiento siguiente.
La pertenencia a administradores, o equivalente, es el mínimo necesario para completar
este procedimiento.

） Importante

Este procedimiento debe realizarse en nps, no en un equipo cliente.

Para configurar la hora de expiración del identificador

TLS en los equipos cliente
1. En nps, abra el Editor del Registro.

2. Vaya a la clave del

RegistroHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityPro
viders\SCHANNEL

3. En el menú Editar , haga clic en Nuevoy, a continuación, haga clic en Clave.

4. Escriba ClientCacheTime y presione ENTRAR.

5. Haga clic con el botón derecho en ClientCacheTime, haga clic en Nuevoy, a

continuación, haga clic en Valor DWORD (32 bits).

6. Escriba la cantidad de tiempo, en milisegundos, que desea que los equipos cliente
almacenarán en caché el identificador TLS de un NPS después del primer intento
de autenticación correcta por parte de NPS.

Configuración de la hora de expiración del

identificador TLS en NPS
Use este procedimiento para cambiar la cantidad de tiempo que los NPS almacena en
caché el identificador TLS de los equipos cliente. Después de autenticar correctamente
un cliente de acceso, los NPS almacena en caché las propiedades de conexión TLS del
equipo cliente como un identificador TLS. El identificador TLS tiene una duración
predeterminada de 10 horas (36 000 000 milisegundos). Puede aumentar o disminuir el
tiempo de expiración del identificador TLS mediante el procedimiento siguiente.

La pertenencia a administradores, o equivalente, es el mínimo necesario para completar

este procedimiento.

） Importante
 Este procedimiento debe realizarse en nps, no en un equipo cliente.

Para configurar la hora de expiración del identificador

TLS en NPS
1. En nps, abra el Editor del Registro.

2. Vaya a la clave del

RegistroHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityPro
viders\SCHANNEL

3. En el menú Editar , haga clic en Nuevoy, a continuación, haga clic en Clave.

4. Escriba ServerCacheTime y presione ENTRAR.

5. Haga clic con el botón derecho en ServerCacheTime, haga clic en Nuevoy, a

continuación, haga clic en Valor DWORD (32 bits).

6. Escriba la cantidad de tiempo, en milisegundos, que desea que los NPS

almacenarán en caché el identificador TLS de un equipo cliente después del primer
intento de autenticación correcto por parte del cliente.

Obtención del hash SHA-1 de un certificado de

entidad de certificación raíz de confianza
Use este procedimiento para obtener el hash de algoritmo hash seguro (SHA-1) de una
entidad de certificación raíz (CA) de confianza de un certificado instalado en el equipo
local. En algunas circunstancias, como al implementar directiva de grupo, es necesario
designar un certificado mediante el hash SHA-1 del certificado.

Al usar directiva de grupo, puede designar uno o varios certificados de entidad de

certificación raíz de confianza que los clientes deben usar para autenticar el NPS
durante el proceso de autenticación mutua con EAP o PEAP. Para designar un certificado
de entidad de certificación raíz de confianza que los clientes deben usar para validar el
certificado de servidor, puede escribir el hash SHA-1 del certificado.

Este procedimiento muestra cómo obtener el hash SHA-1 de un certificado de entidad

de certificación raíz de confianza mediante el complemento Certificates Microsoft
Management Console (MMC).

Para completar este procedimiento, debe ser miembro del grupo Usuarios en el equipo
local.
Para obtener el hash SHA-1 de un certificado de entidad
de certificación raíz de confianza
1. En el cuadro de diálogo Ejecutar o Windows PowerShell, escriba mmc y presione
ENTRAR. Se abrirá Microsoft Management Console (MMC). En MMC, haga clic en
Archivo y, a continuación, en Agregar o quitar complemento. Se abre el cuadro
de diálogo Agregar o quitar complementos.

2. En Agregar o quitar complementos, en Complementos disponibles, haga doble

clic en Certificados. Se abre el asistente para complemento Certificados. Haga clic
en Cuenta de equipo y, a continuación, en Siguiente.

3. En Seleccionar equipo, asegúrese de que está seleccionado Equipo local ( el

equipo en el que se ejecuta esta consola), haga clic en Finalizary , a continuación,
haga clic en Aceptar.

4. En el panel izquierdo, haga doble clic en Certificados (equipo local) y, a

continuación, haga doble clic en entidades de certificación raíz de confianza
carpeta.

5. La carpeta Certificates es una subcarpeta de la entidades de certificación raíz de

confianza carpeta. Haga clic en la carpeta Certificados.

6. En el panel de detalles, vaya al certificado de la entidad de certificación raíz de

confianza. Haga doble clic en el certificado. Se abre el cuadro de diálogo
Certificado.

7. En el cuadro de diálogo Certificado, haga clic en la pestaña Detalles.

8. En la lista de campos, desplácese hasta y seleccione Huella digital.

9. En el panel inferior, se muestra la cadena hexadecimal que es el hash SHA-1 de su

certificado. Seleccione el hash SHA-1 y, a continuación, presione el método
abreviado de teclado Windows para el comando Copiar (CTRL+C) para copiar el
hash en el portapapeles Windows texto.

10. Abra la ubicación en la que desea pegar el hash SHA-1, busque correctamente el
cursor y presione el método abreviado de teclado Windows para el comando
Pegar (CTRL+V).

Para obtener más información sobre los certificados y NPS, vea Configurar plantillas de
certificado para los requisitos de PEAP y EAP.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Configurar plantillas de certificado para
los requisitos de PEAP y EAP
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Todos los certificados que se usan para la autenticación de acceso a la red con la
autenticación extensible Protocol-Transport Layer Security (EAP-TLS), la autenticación
extensible protegida Protocol-Transport Layer Security (PEAP-TLS) y el protocolo de
autenticación de protocolo de enlace de desafío de PEAP-Microsoft versión 2 (MS-CHAP
v2) deben cumplir los requisitos de los certificados X.509 y trabajar para las conexiones
que usan Secure Socket Layer/Transport Level Security (SSL/TLS). Los certificados de
cliente y de servidor tienen requisitos adicionales.

） Importante

En este tema se proporcionan instrucciones para configurar plantillas de certificado.

Para usar estas instrucciones, es necesario que haya implementado su propia
infraestructura de clave pública (PKI) con Servicios de certificados de Active
Directory (AD CS).

Requisitos mínimos para certificados de

servidor
Con PEAP-MS-CHAP v2, PEAP-TLS o EAP-TLS como método de autenticación, NPS debe
usar un certificado de servidor que cumpla los requisitos mínimos de certificado de
servidor.

Los equipos cliente se pueden configurar para validar certificados de servidor mediante
la opción Validar certificado de servidor en el equipo cliente o en directiva de grupo.

El equipo cliente acepta el intento de autenticación del servidor cuando el certificado de

servidor cumple los siguientes requisitos:

El nombre de sujeto contiene un valor. Si emite un certificado al servidor que

ejecuta el servidor de directivas de red (NPS) que tiene un nombre de sujeto en
blanco, el certificado no está disponible para autenticar el NPS. Para configurar la
plantilla de certificado con un nombre de sujeto:
 1. Abra las plantillas de certificado.
2. En el panel de detalles, haga clic con el botón derecho en la plantilla de
certificado que desea cambiar y, a continuación, haga clic en Propiedades .
3. Haga clic en la pestaña Nombre del sujeto y, a continuación, haga clic en
Compilar a partir de Active Directory información.
4. En Formato de nombre de sujeto, seleccione un valor distinto de Ninguno.

El certificado de equipo en el servidor se encadena a una entidad de certificación

raíz (CA) de confianza y no da error a ninguna de las comprobaciones realizadas
por CryptoAPI y que se especifican en la directiva de acceso remoto o la directiva
de red.

El certificado de equipo para el servidor NPS o VPN se configura con el propósito

autenticación del servidor en extensiones de uso extendido de claves (EKU). (El
identificador de objeto para la autenticación del servidor es [Link].[Link].1).

Configure el certificado de servidor con la configuración de criptografía necesaria:

1. Abra las plantillas de certificado.

2. En el panel de detalles, haga clic con el botón derecho en la plantilla de
certificado que desea cambiar y, a continuación, haga clic en Propiedades.
3. Haga clic en la pestaña Criptografía y asegúrese de configurar lo siguiente:
Categoría del proveedor: Proveedor de Storage clave
Nombre del algoritmo: RSA
Proveedores: Proveedor de criptografía de plataforma de Microsoft
Tamaño mínimo de clave: 2048
Algoritmo hash: SHA2
4. Haga clic en Next.

Si se usa la extensión de nombre alternativo de sujeto (SubjectAltName), debe

contener el nombre DNS del servidor. Para configurar la plantilla de certificado con
el nombre del sistema de nombres de dominio (DNS) del servidor de inscripción:

1. Abra las plantillas de certificado.

2. En el panel de detalles, haga clic con el botón derecho en la plantilla de
certificado que desea cambiar y, a continuación, haga clic en Propiedades .
3. Haga clic en la pestaña Nombre del sujeto y, a continuación, haga clic en
Compilar a partir de Active Directory información.
4. En Incluir esta información en el nombre de sujeto alternativo, seleccione
Nombre DNS.

Al usar PEAP y EAP-TLS, los NPS muestran una lista de todos los certificados instalados
en el almacén de certificados del equipo, con las siguientes excepciones:
 No se muestran los certificados que no contienen el propósito de autenticación de
servidor en extensiones EKU.

No se muestran los certificados que no contienen un nombre de sujeto.

No se muestran los certificados de inicio de sesión de tarjeta inteligente y basados

en el Registro.

Para más información, consulte Implementación de certificados de servidor para

implementaciones cableadas e inalámbricas 802.1X.

Requisitos mínimos para certificados de cliente

Con EAP-TLS o PEAP-TLS, el servidor acepta el intento de autenticación del cliente
cuando el certificado cumple los siguientes requisitos:

El certificado de cliente lo emite una ca de empresa o se asigna a una cuenta de

usuario o equipo en Active Directory Domain Services (AD DS).

El certificado de usuario o equipo en las cadenas de cliente a una CA raíz de

confianza, incluye el propósito de autenticación de cliente en las extensiones EKU
(el identificador de objeto para la autenticación de cliente es [Link].[Link].2) y no
produce ningún error en las comprobaciones que realiza CryptoAPI y que se
especifican en la directiva de acceso remoto o la directiva de red ni en las
comprobaciones de identificador de objeto de certificado que se especifican en la
directiva de red nps.

El cliente 802.1X no usa certificados basados en el Registro que sean certificados

de inicio de sesión de tarjeta inteligente o protegidos con contraseña.

Para los certificados de usuario, la extensión de nombre alternativo de sujeto

(SubjectAltName) del certificado contiene el nombre principal del usuario (UPN).
Para configurar el UPN en una plantilla de certificado:

1. Abra las plantillas de certificado.

2. En el panel de detalles, haga clic con el botón derecho en la plantilla de
certificado que desea cambiar y, a continuación, haga clic en Propiedades.
3. Haga clic en la pestaña Nombre del sujeto y, a continuación, haga clic en
Compilar a partir de Active Directory información.
4. En Incluir esta información en el nombre de sujeto alternativo, seleccione
Nombre principal de usuario (UPN).

Para los certificados de equipo, la extensión Nombre alternativo del firmante

(SubjectAltName) del certificado debe contener el nombre de dominio completo
 (FQDN) del cliente, que también se denomina nombre DNS. Para configurar este
nombre en la plantilla de certificado:

1. Abra las plantillas de certificado.

2. En el panel de detalles, haga clic con el botón derecho en la plantilla de
certificado que desea cambiar y, a continuación, haga clic en Propiedades.
3. Haga clic en la pestaña Nombre del sujeto y, a continuación, haga clic en
Compilar a partir de Active Directory información.
4. En Incluir esta información en el nombre de sujeto alternativo, seleccione
Nombre DNS.

Con PEAP-TLS y EAP-TLS, el cliente muestra una lista de todos los certificados instalados
en el complemento Certificados, con las siguientes excepciones:

Los clientes inalámbricos no muestran certificados de inicio de sesión de tarjeta

inteligente y basados en el Registro.

Los clientes inalámbricos y los clientes VPN no muestran certificados protegidos

con contraseña.

No se muestran los certificados que no contienen el propósito de autenticación de

cliente en extensiones EKU.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Administrar NPS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar los temas de esta sección para administrar NPS.

７ Nota

Para obtener documentación adicional del servidor de directivas de red, puede usar
las siguientes secciones de biblioteca.

Tareas iniciales con el servidor de directivas de redes

Implementar el servidor de directivas de redes

Esta sección contiene los temas siguientes.

Configuración de NPS en un equipo de varios equipos en casa

Configuración de la información de puerto UDP de NPS
Deshabilitación del reenvío de notificaciones nas
Exportar una configuración de NPS para importar en otro servidor
Aumentar las autenticaciones simultáneas procesadas por NPS
Instalar el servidor de directivas de red
Equilibrio de carga del servidor proxy NPS
Registrar un NPS en un dominio de Active Directory
Anular el registro de NPS de un dominio de Active Directory
Uso de expresiones regulares en NPS
Comprobar la configuración después de los cambios de NPS
Configuración de NPS en un equipo de
host múltiple
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para configurar un NPS con varios adaptadores de red.

Si usa varios adaptadores de red en un servidor que ejecuta NPS (Servidor de directivas
de redes), puede configurar lo siguiente:

Los adaptadores de red que envían y no envían y reciben Servicio de autenticación

remota telefónica de usuario tráfico (RADIUS).
En función de cada adaptador de red, si NPS supervisa el tráfico RADIUS del
protocolo de Internet versión 4 (IPv4), IPv6 o ambos, IPv4 e IPv6.
Los números de puerto UDP sobre los que se envía y recibe el tráfico RADIUS en
función del protocolo (IPv4 o IPv6) y del adaptador de red.

De forma predeterminada, NPS escucha el tráfico RADIUS en los puertos 1812, 1813,
1645 y 1646 para ambos protocolos IPv6 e IPv4, y para todos los adaptadores de red
instalados. Dado que NPS usa automáticamente todos los adaptadores de red para el
tráfico RADIUS, solo tiene que especificar los adaptadores de red que desea que NPS
use para el tráfico RADIUS cuando desee impedir que NPS use un adaptador de red
específico.

７ Nota

Si desinstala IPv4 o IPv6 en un adaptador de red, NPS no supervisará el tráfico

RADIUS para el protocolo desinstalado.

En un NPS que tenga varios adaptadores de red instalados, puede configurar NPS para
enviar y recibir tráfico RADIUS solo en los adaptadores que especifique.

Por ejemplo, un adaptador de red instalado en NPS podría dar lugar a un segmento de
red que no contiene clientes RADIUS, mientras que un segundo adaptador de red
proporciona a NPS una ruta de acceso de red a sus clientes RADIUS configurados. En
este escenario, es importante dirigir NPS para que use el segundo adaptador de red
para todo el tráfico RADIUS.
En otro ejemplo, si nps tiene tres adaptadores de red instalados, pero solo quiere que
NPS use dos de los adaptadores para el tráfico RADIUS, puede configurar la información
de puerto solo para los dos adaptadores. Al excluir la configuración de puertos para el
tercer adaptador, evita que NPS use el adaptador para el tráfico RADIUS.

Uso de un adaptador de red

Para configurar NPS para que escuche y envíe tráfico RADIUS en un adaptador de red,
use la sintaxis siguiente en el cuadro de diálogo Propiedades del servidor de directivas
de red en la consola NPS:

Sintaxis de tráfico IPv4: IPAddress:UDPport , donde IPAddress es la dirección IPv4

configurada en el adaptador de red a través del que desea enviar tráfico RADIUS, y
UDPport es el número de puerto RADIUS que desea usar para la autenticación
RADIUS o el tráfico de contabilidad.
Sintaxis de tráfico IPv6: [IPv6Address] : UDPport , donde se requieren los corchetes
alrededor de IPv6Address, IPv6Address es la dirección IPv6 que está configurada
en el adaptador de red a través del cual desea enviar tráfico RADIUS, y UDPport es
el número de puerto RADIUS que desea usar para la autenticación RADIUS o el
tráfico de contabilidad.

Los siguientes caracteres pueden usarse como delimitadores para configurar la

información de direcciones IP y puertos UDP:

Delimitador de dirección/puerto: dos puntos (:)

Delimitador de puerto: coma (,)
Delimitador de interfaz: punto y coma (;)

Configuración de servidores de acceso a la red

Asegúrese de que los servidores de acceso a la red están configurados con los mismos
números de puerto UDP RADIUS que configura en los NPS. Los puertos UDP estándar
de RADIUS definidos en las RFC 2865 y 2866 son 1812 para autenticación y 1813 para
cuentas; sin embargo, algunos servidores de acceso están configurados de forma
predeterminada para usar el puerto UDP 1645 para las solicitudes de autenticación y el
puerto UDP 1646 para las solicitudes de cuentas.

） Importante

Si no usa los números de puerto RADIUS predeterminados, debe configurar

excepciones en el firewall para el equipo local para permitir el tráfico RADIUS en los
 nuevos puertos. Para obtener más información, vea Configurar firewalls para el
tráfico RADIUS.

Configuración de NPS multihomed

Puede usar el procedimiento siguiente para configurar nps de varios locales.

La pertenencia a Administradores de dominio, o equivalente, es lo mínimo necesario

para completar este procedimiento.

Para especificar el adaptador de red y puertos UDP que

usa NPS para el tráfico RADIUS
1. En administrador del servidor, haga clic en Herramientasy, a continuación, haga
clic en Servidor de directivas de red para abrir la consola NPS.

2. Haga clic con el botón derecho en Servidor de directivas de redy, a continuación,

haga clic en Propiedades.

3. Haga clic en la pestaña Puertos y anteponer la dirección IP del adaptador de red

que desea usar para el tráfico RADIUS a los números de puerto existentes. Por
ejemplo, si desea usar la dirección IP [Link] y los puertos RADIUS 1812 y 1645
para las solicitudes de autenticación, cambie la configuración del puerto de
1812,1645 a [Link]:1812,1645. Si los puertos UDP de autenticación y cuentas
RADIUS son distintos de los valores predeterminados, cambie la configuración de
los puertos según corresponda.

4. Para usar varios valores de puertos para las solicitudes de autenticación y cuentas,
separe los números de puerto con comas.

Para obtener más información sobre los puertos UDP de NPS, vea Configurar la
información de puerto UDP de NPS.

Para obtener más información sobre NPS, vea Servidor de directivas de red.
Configurar la información del puerto
UDP de NPS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar el procedimiento siguiente para configurar los puertos que usa el servidor
de directivas de red (NPS) para la autenticación de Servicio de autenticación remota
telefónica de usuario (RADIUS) y el tráfico de contabilidad.

De forma predeterminada, NPS escucha el tráfico RADIUS en los puertos 1812, 1813,
1645 y 1646 para el protocolo de Internet versión 6 (IPv6) y versión 4 (IPv4) para todos
los adaptadores de red instalados.

７ Nota

Si desinstala IPv4 o IPv6 en un adaptador de red, NPS no supervisará el tráfico

RADIUS para el protocolo desinstalado.

Los valores de puerto 1812 para la autenticación y 1813 para la contabilidad son
puertos estándar RADIUS definidos por el Grupo de tareas de ingeniería de Internet
(IETF) en RFC 2865 y 2866. Sin embargo, de forma predeterminada, muchos servidores
de acceso usan los puertos 1645 para las solicitudes de autenticación y 1646 para las
solicitudes de cuentas. Con independencia de los números de puerto que decida usar,
asegúrese de que NPS y el servidor de acceso estén configurados para usarlos.

[IMPORTANTE] Si no usa los números de puerto predeterminados de RADIUS, debe

configurar excepciones en el firewall del equipo local para permitir el tráfico RADIUS
en los nuevos puertos. Para obtener más información, vea Configurar firewalls para
el tráfico RADIUS.

La pertenencia a Administradores de dominio, o equivalente, es lo mínimo necesario

para completar este procedimiento.

Para configurar la información de puerto UDP

de NPS
1. Abra la consola de NPS.
 2. Haga clic con el botón derecho en Servidor de directivas de redy, a continuación,
haga clic en Propiedades.
3. Haga clic en la pestaña Puertos y examine la configuración de los puertos. Si los
puertos UDP de autenticación RADIUS y cuentas RADIUS varían de los valores
predeterminados proporcionados (1812 y 1645 para la autenticación y 1813 y 1646
para la contabilidad), escriba la configuración del puerto en Autenticación y
contabilidad.
4. Para usar varios valores de puertos para las solicitudes de autenticación y cuentas,
separe los números de puerto con comas.

Para obtener más información sobre cómo administrar NPS, vea Administrar el servidor
de directivas de red.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Deshabilitación del reenvío de
notificaciones nas en NPS
Artículo • 24/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este procedimiento para deshabilitar el reenvío de mensajes de inicio y de

detenerse desde servidores de acceso a la red (NAS) a miembros de un grupo de
servidores RADIUS remoto configurado en NPS.

Cuando haya configurado grupos de servidores RADIUS remotos y, en Directivas de

solicitud de conexión nps, desactive la casilla Reenviar solicitudes de contabilidad a este
grupo de servidores RADIUS remoto, estos grupos seguirán en envío de mensajes de
inicio y de detenerse de notificación de NAS.

Esto genera un tráfico de red innecesario. Para eliminar este tráfico, deshabilite el
reenvío de notificaciones NAS para servidores individuales en cada grupo de servidores
RADIUS remoto.

Para completar este procedimiento, debe pertenecer al grupo Administradores.

Para deshabilitar el reenvío de notificaciones NAS

1. En el Administrador del servidor, haga clic en Herramientas y, a continuación, haga
clic en Servidor de directivas de redes. Se abre la consola NPS.

2. En la consola NPS, haga doble clic en Clientes y servidores RADIUS, haga clic en
Grupos de servidores RADIUS remotosy, a continuación, haga doble clic en el
grupo de servidores RADIUS remoto que desea configurar. Se abre el cuadro de
diálogo Propiedades del grupo de servidores RADIUS remoto.

3. Haga doble clic en el miembro del grupo que desea configurar y, a continuación,
haga clic en la pestaña Autenticación/ contabilidad.

4. En Contabilidad, desactive la casilla Reenviar el servidor de acceso a la red para

iniciar y detener las notificaciones a este servidor y, a continuación, haga clic en
Aceptar.

5. Repita los pasos 3 y 4 para todos los miembros del grupo que quiera configurar.
Para obtener más información sobre cómo administrar NPS, vea Administrar el servidor
de directivas de red.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Exportar una configuración de NPS para
importar en otro servidor
Artículo • 29/09/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede exportar toda la configuración de NPS , incluidos los clientes y servidores

RADIUS, la directiva de red, la directiva de solicitud de conexión, el registro y la
configuración de registro, desde un NPS para su importación en otro NPS.

Use una de las siguientes herramientas para exportar la configuración de NPS:

En Windows Server 2016, Windows Server 2012 R2 y Windows Server 2012, puede
usar Netsh o puede usar Windows PowerShell.
En Windows Server 2008 R2 y Windows Server 2008, use Netsh.

） Importante

No utilice este procedimiento si la base de datos NPS de origen tiene un número

de versión mayor que el número de versión de la base de datos NPS de destino.
Puede ver el número de versión de la base de datos NPS desde la presentación del
comando netsh nps show config .

Dado que las configuraciones de NPS no se cifran en el archivo XML exportado, enviarlo
a través de una red podría suponer un riesgo para la seguridad, por lo que debe tomar
precauciones al mover el archivo XML del servidor de origen a los servidores de destino.
Por ejemplo, agregue el archivo a un archivo de archivo cifrado protegido con
contraseña antes de moverlo. Además, almacene el archivo en una ubicación segura
para evitar que usuarios malintencionados accedan a él.

７ Nota

Si SQL Server el registro se configura en el NPS de origen, SQL Server la

configuración de registro no se exporta al archivo XML. Después de importar el
archivo en otro NPS, debe configurar manualmente SQL Server registro.
Exportar e importar la configuración de NPS
mediante Windows PowerShell
Para Windows Server 2012 versiones posteriores del sistema operativo, puede exportar
la configuración de NPS mediante Windows PowerShell.

La sintaxis de comando para exportar la configuración de NPS es la siguiente.

PowerShell

Export-NpsConfiguration -Path <filename>

En la tabla siguiente se enumeran los parámetros del cmdlet Export-NpsConfiguration

en Windows PowerShell. Se requieren parámetros en negrita.

Parámetro Descripción

Path Especifica el nombre y la ubicación del archivo XML al que desea exportar la
configuración de NPS.

Credenciales administrativas

Para completar este procedimiento, debe pertenecer al grupo Administradores.

Ejemplo de exportación
En el ejemplo siguiente, la configuración de NPS se exporta a un archivo XML ubicado
en la unidad local. Para ejecutar este comando, ejecute Windows PowerShell
administrador en el NPS de origen, escriba el siguiente comando y presione Entrar.

PowerShell

Export-NpsConfiguration –Path c:\[Link]

Para obtener más información, vea Export-NpsConfiguration.

Después de exportar la configuración de NPS, copie el archivo XML en el servidor de

destino.

La sintaxis de comando para importar la configuración de NPS en el servidor de destino

es la siguiente.

PowerShell
 Import-NpsConfiguration [-Path] <String> [ <CommonParameters>]

Ejemplo de importación
El comando siguiente importa la configuración del archivo denominado
C:\[Link] a NPS. Para ejecutar este comando, ejecute Windows PowerShell
administrador en el NPS de destino, escriba el siguiente comando y presione Entrar.

PowerShell

Import-NpsConfiguration -Path "C:\[Link]"

Para obtener más información, vea Import-NpsConfiguration.

Exportación e importación de la configuración

de NPS mediante Netsh
Puede usar Network Shell (Netsh) para exportar la configuración de NPS mediante el
comando netsh nps export .

Cuando se ejecuta el comando netsh nps import , NPS se actualiza automáticamente

con las opciones de configuración actualizadas. No es necesario detener NPS en el
equipo de destino para ejecutar el comando netsh nps import ; sin embargo, si la
consola NPS o el complemento NPS MMC están abiertos durante la importación de la
configuración, los cambios en la configuración del servidor no son visibles hasta que
actualice la vista.

７ Nota

Cuando use el comando netsh nps export , debe proporcionar el parámetro de

comando exportPSK con el valor YES. Este parámetro y valor expresan que
comprende que está exportando la configuración de NPS y que el archivo XML
exportado contiene secretos compartidos sin cifrar para clientes RADIUS y
miembros de grupos de servidores RADIUS remotos.

Credenciales administrativas

Para completar este procedimiento, debe pertenecer al grupo Administradores.

Para copiar una configuración de NPS en otro NPS
mediante comandos Netsh
1. En el NPS de origen, abra símbolo del sistema, escriba netsh y presione Entrar.

2. En el símbolo del sistema de netsh , escriba nps y presione Entrar.

3. En el símbolo del sistema netsh nps , escriba export filename="path\[Link]"

exportPSK=YES, donde path es la ubicación de la carpeta donde desea guardar el
archivo de configuración nps y file es el nombre del archivo XML que desea
guardar. Presione Entrar.

Esto almacena los valores de configuración (incluida la configuración del Registro)

en un archivo XML. La ruta de acceso puede ser relativa o absoluta, o puede ser
una ruta de acceso de convención de nomenclatura universal (UNC). Después de
presionar Entrar, aparece un mensaje que indica si la exportación al archivo se ha
realizado correctamente.

4. Copie el archivo que creó en el NPS de destino.

5. En un símbolo del sistema en el NPS de destino, escriba netsh nps import

filename="path\[Link]"y presione Entrar. Aparece un mensaje que indica si la
importación del archivo XML se ha realizado correctamente.

Referencias adicionales
Shell de red (Netsh)
Aumentar las autenticaciones
simultáneas procesadas por NPS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener instrucciones sobre cómo configurar las
autenticaciones simultáneas del servidor de directivas de red.

Si instaló el servidor de directivas de red (NPS) en un equipo distinto de un controlador

de dominio y NPS recibe un gran número de solicitudes de autenticación por segundo,
puede mejorar el rendimiento de NPS aumentando el número de autenticaciones
simultáneas permitidas entre nps y el controlador de dominio.

Para ello, debe editar la siguiente clave del Registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Agregue un nuevo valor DWORD denominado MaxConcurrentApi y asígnele un valor

de 150.

Ｕ Precaución

Si asigna un valor a MaxConcurrentApi demasiado alto, el NPS podría colocar una

carga excesiva en el controlador de dominio.

Para obtener más información sobre MaxConcurrentApi, consulte How to do

performance tuning for NTLM authentication by using the MaxConcurrentApi setting
(Cómo realizar el ajuste del rendimiento para la autenticación NTLM mediante la
configuración MaxConcurrentApi).

Para obtener más información sobre cómo administrar NPS, vea Administrar el servidor
de directivas de red.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Instalar el servidor de directivas de red
Artículo • 29/09/2022 • Tiempo de lectura: 2 minutos

Puede usar este tema para instalar el servidor de directivas de red (NPS) mediante
Windows PowerShell o el Asistente para agregar roles y características. NPS es un
servicio de rol del rol de servidor Servicios de acceso y directivas de redes.

７ Nota

De forma predeterminada, NPS escucha el tráfico RADIUS en los puertos 1812,

1813, 1645 y 1646 en todos los adaptadores de red instalados. Si Windows Firewall
con seguridad avanzada está habilitado al instalar NPS, las excepciones de firewall
para estos puertos se crean automáticamente durante el proceso de instalación
para el tráfico IPv6 (Protocolo de Internet versión 6) e IPv4. Si los servidores de
acceso de red están configurados para enviar tráfico RADIUS a través de puertos
distintos de estos valores predeterminados, quite las excepciones creadas en
firewall de Windows con seguridad avanzada durante la instalación de NPS y cree
excepciones para los puertos que usa para el tráfico RADIUS.

Credenciales administrativas

Para completar este procedimiento, debe ser miembro del grupo Admins. del dominio.

Para instalar NPS mediante Windows

PowerShell
Para realizar este procedimiento mediante Windows PowerShell, ejecute Windows
PowerShell administrador, escriba el siguiente comando y presione ENTRAR.

Install-WindowsFeature NPAS -IncludeManagementTools

Para instalar NPS mediante Administrador del

servidor
1. En NPS1, en Administrador del servidor, haga clic en Administrar y, a continuación,
haga clic en Agregar roles y características. Se abre el Asistente para agregar roles
y características.

2. En Antes de comenzar, haga clic en Siguiente.

 ７ Nota

La página Antes de comenzar del Asistente para agregar roles y

características no se muestra si ha seleccionado anteriormente Omitir esta
página de forma predeterminada al ejecutar el asistente.

3. En Seleccionar tipo de instalación, asegúrese de que la opción Instalación basada

en características o en roles está seleccionada y, a continuación, haga clic en
Siguiente.

4. En Seleccionar servidor de destino, asegúrese de que la opción Seleccionar un

servidor del grupo de servidores está seleccionada. En Grupo de servidores,
asegúrese de que el equipo local está seleccionado. Haga clic en Next.

5. En Seleccionar roles de servidor, en Roles, seleccione Directiva de red y Access

Services. Se abre un cuadro de diálogo que pregunta si debe agregar
características necesarias para la directiva de red Access Services. Haga clic en
Agregar característicasy, a continuación, haga clic en Siguiente.

6. En Seleccionar características, haga clic en Siguiente. En Servicios de acceso y

directivas de redes, repase la información proporcionada y haga clic en Siguiente.

7. En Seleccionar servicios de rol, haga clic en Servidor de directivas de redes. En

¿Desea agregar características requeridas para Servidor de directivas de redes?,
haga clic en Agregar características. Haga clic en Next.

8. En Confirmar selecciones de instalación, haga clic en Reiniciar automáticamente

el servidor de destino en caso necesario. Si se le pide confirmar la selección, haga
clic en Sí y, a continuación, haga clic en Instalar. La página Progreso de la
instalación muestra el estado durante el proceso de instalación. Cuando se
complete el proceso, se mostrará el mensaje "Instalación correcta en
NombreDeEquipo", donde NombreDeEquipo es el nombre del equipo en el que
instaló el servidor de directivas de red. Haga clic en Cerrar.

Para obtener más información, vea Administrar NPS.

Equilibrio de carga del servidor proxy
NPS
Artículo • 29/09/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Servicio de autenticación remota telefónica de usuario (RADIUS), que son servidores de

acceso de red como servidores de red privada virtual (VPN) y puntos de acceso
inalámbrico, crean solicitudes de conexión y las envían a servidores RADIUS como NPS.
En algunos casos, un NPS podría recibir demasiadas solicitudes de conexión a la vez, lo
que resulta en un rendimiento degradado o una sobrecarga. Cuando se sobrecarga un
NPS, es una buena idea agregar más NPS a la red y configurar el equilibrio de carga.
Cuando se distribuyen uniformemente las solicitudes de conexión entrantes entre varios
NPS para evitar la sobrecarga de uno o varios NPS, se denomina equilibrio de carga.

El equilibrio de carga es especialmente útil para:

Las organizaciones que usan la autenticación extensible Protocol-Transport

seguridad de capa de acceso (EAP-TLS) o el Protocolo de autenticación extensible
protegido (PEAP)-TLS para la autenticación. Dado que estos métodos de
autenticación usan certificados para la autenticación del servidor y para la
autenticación de usuarios o equipos cliente, la carga en servidores y servidores
proxy RADIUS es mayor que cuando se usan métodos de autenticación basados en
contraseña.
Organizaciones que necesitan mantener la disponibilidad continua del servicio.
Proveedores de servicios de Internet (ISP) que externalizaron el acceso VPN para
otras organizaciones. Los servicios VPN externalizados pueden generar un gran
volumen de tráfico de autenticación.

Hay dos métodos que puede usar para equilibrar la carga de solicitudes de conexión
enviadas a los NPS:

Configure los servidores de acceso de red para enviar solicitudes de conexión a

varios servidores RADIUS. Por ejemplo, si tiene 20 puntos de acceso inalámbricos y
dos servidores RADIUS, configure cada punto de acceso para enviar solicitudes de
conexión a ambos servidores RADIUS. Puede equilibrar la carga y proporcionar
conmutación por error en cada servidor de acceso de red configurando el servidor
de acceso para enviar solicitudes de conexión a varios servidores RADIUS en un
orden de prioridad especificado. Este método de equilibrio de carga suele ser el
 más adecuado para organizaciones pequeñas que no implementan un gran
número de clientes RADIUS.
Use NPS configurado como proxy RADIUS para equilibrar la carga de las
solicitudes de conexión entre varios NPS u otros servidores RADIUS. Por ejemplo,
si tiene 100 puntos de acceso inalámbrico, un proxy NPS y tres servidores RADIUS,
puede configurar los puntos de acceso para enviar todo el tráfico al proxy NPS. En
el proxy NPS, configure el equilibrio de carga para que el proxy distribuya
uniformemente las solicitudes de conexión entre los tres servidores RADIUS. Este
método de equilibrio de carga es mejor para organizaciones medianas y grandes
que tienen muchos clientes y servidores RADIUS.

En muchos casos, el mejor enfoque para el equilibrio de carga es configurar clientes

RADIUS para enviar solicitudes de conexión a dos servidores proxy NPS y, a
continuación, configurar los servidores proxy NPS para equilibrar la carga entre los
servidores RADIUS. Este enfoque proporciona conmutación por error y equilibrio de
carga para servidores proxy NPS y RADIUS.

Prioridad y peso del servidor RADIUS

Durante el proceso de configuración del proxy NPS, puede crear grupos de servidores
RADIUS remotos y, a continuación, agregar servidores RADIUS a cada grupo. Para
configurar el equilibrio de carga, debe tener más de un servidor RADIUS por grupo de
servidores RADIUS remotos. Al agregar miembros del grupo o después de crear un
servidor RADIUS como miembro del grupo, puede acceder al cuadro de diálogo
Agregar servidor RADIUS para configurar los siguientes elementos en la pestaña
Equilibrio de carga:

Prioridad. Prioridad especifica el orden de importancia del servidor RADIUS para el

servidor proxy NPS. El nivel de prioridad debe tener asignado un valor que sea un
entero, como 1, 2 o 3. Cuanto menor sea el número, mayor será la prioridad que el
proxy NPS da al servidor RADIUS. Por ejemplo, si al servidor RADIUS se le asigna la
prioridad más alta de 1, el proxy NPS envía primero las solicitudes de conexión al
servidor RADIUS; Si los servidores con prioridad 1 no están disponibles, NPS envía
las solicitudes de conexión a los servidores RADIUS con prioridad 2, y así
sucesivamente. Puede asignar la misma prioridad a varios servidores RADIUS y, a
continuación, usar la configuración Peso para equilibrar la carga entre ellos.

Peso. NPS usa esta configuración de peso para determinar cuántas solicitudes de
conexión se envían a cada miembro del grupo cuando los miembros del grupo
tienen el mismo nivel de prioridad. La configuración de peso debe tener asignado
un valor entre 1 y 100, y el valor representa un porcentaje del 100 por ciento. Por
 ejemplo, si el grupo de servidores RADIUS remoto contiene dos miembros que
tienen un nivel de prioridad de 1 y una clasificación ponderada de 50, el proxy NPS
reenvía el 50 % de las solicitudes de conexión a cada servidor RADIUS.

Configuración avanzada. Esta configuración de conmutación por error

proporciona una manera de que NPS determine si el servidor RADIUS remoto no
está disponible. Si NPS determina que un servidor RADIUS no está disponible,
puede empezar a enviar solicitudes de conexión a otros miembros del grupo. Con
esta configuración puede configurar el número de segundos que el proxy NPS
espera una respuesta del servidor RADIUS antes de considerar la solicitud
descartada. el número máximo de solicitudes descartadas antes de que el proxy
NPS identifique el servidor RADIUS como no disponible; y el número de segundos
que pueden transcurrir entre las solicitudes antes de que el proxy NPS identifique
el servidor RADIUS como no disponible.

Configuración del equilibrio de carga del proxy

NPS
Antes de configurar el equilibrio de carga, cree un plan de implementación que incluya
cuántos grupos de servidores RADIUS remotos necesita, qué servidores son miembros
de cada grupo determinado y la configuración Prioridad y Peso de cada servidor.

７ Nota

En los pasos siguientes se supone que ya ha implementado y configurado

servidores RADIUS.

Para configurar NPS para que actúe como servidor proxy y reenviar solicitudes de
conexión de clientes RADIUS a servidores RADIUS remotos, debe realizar las siguientes
acciones:

1. Implemente los clientes RADIUS (servidores VPN, servidores de acceso telefónico,

servidores de puerta de enlace de Terminal Services, conmutadores de
autenticación 802.1X y puntos de acceso inalámbrico 802.1X) y configúrelos para
enviar solicitudes de conexión a los servidores proxy NPS.

2. En el proxy NPS, configure los servidores de acceso a la red como clientes RADIUS.
Para obtener más información, vea Configurar clientes RADIUS.

3. En el proxy NPS, cree uno o varios grupos de servidores RADIUS remotos. Durante
este proceso, agregue servidores RADIUS a los grupos de servidores RADIUS
 remotos. Para obtener más información, vea Configurar grupos de servidores
RADIUS remotos.

4. En el proxy NPS, para cada servidor RADIUS que agregue a un grupo de servidores
RADIUS remoto, haga clic en la pestaña Equilibrio de carga del servidor RADIUS y,
a continuación, configure las opciones Prioridad, Peso y Opciones avanzadas.

5. En el proxy NPS, configure directivas de solicitud de conexión para reenviar

solicitudes de autenticación y contabilidad a grupos de servidores RADIUS
remotos. Debe crear una directiva de solicitud de conexión por grupo de
servidores RADIUS remotos. Para obtener más información, vea Configurar
directivas de solicitud de conexión.
Registrar un NPS en un dominio de
Active Directory
Artículo • 29/09/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para registrar un servidor que ejecuta servidor de directivas de red
Windows Server 2016 en el dominio predeterminado de NPS o en otro dominio.

Registrar un NPS en su dominio

predeterminado
Puede usar este procedimiento para registrar un NPS en el dominio donde el servidor es
miembro del dominio.

Los NPS deben registrarse en Active Directory para que tengan permiso para leer las
propiedades de acceso telefónico de las cuentas de usuario durante el proceso de
autorización. Al registrar un NPS, se agrega el servidor al grupo Servidores RAS e IAS en
Active Directory.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Para registrar un NPS en su dominio predeterminado

1. En nps, en Administrador del servidor, haga clic en Herramientasy, a continuación,
haga clic en Servidor de directivas de red. Se abre la consola del servidor de
directivas de red.

2. Haga clic con el botón derecho en NPS (local) y, a continuación, haga clic en
Registrar servidor en Active Directory. Se abrirá el cuadro de diálogo Servidor de
directivas de redes.

3. En Servidor de directivas de redes, haga clic en Aceptar y, a continuación, en

Aceptar de nuevo.

Registrar un NPS en otro dominio

Para proporcionar a un NPS permiso para leer las propiedades de acceso telefónico de
las cuentas de usuario de Active Directory, el NPS debe estar registrado en el dominio
donde residen las cuentas.

Puede usar este procedimiento para registrar un NPS en un dominio donde nps no sea
miembro del dominio.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Para registrar un NPS en otro dominio

1. En el controlador de dominio, en Administrador del servidor, haga clic en
Herramientasy, a continuación, haga clic en Usuarios y equipos de Active
Directory. Se abre la Consola de usuarios y equipos de Active Directory.

2. En el árbol de consola, vaya al dominio donde desea que NPS lea la información
de la cuenta de usuario y, a continuación, haga clic en la carpeta Usuarios.

3. En el panel de detalles, haga clic con el botón derecho en Ras y servidores IAS y, a
continuación, haga clic en Propiedades. Se abre el cuadro de diálogo
Propiedades de servidores RAS e IAS .

4. En el cuadro de diálogo Propiedades de servidores RAS e IAS , haga clic en la

pestaña Miembros, agregue cada uno de los NPS que desea registrar en el
dominio y, a continuación, haga clic en Aceptar.

Para registrar un NPS en otro dominio mediante

comandos Netsh para NPS
1. Abra el símbolo del sistema o Windows PowerShell.

2. Escriba lo siguiente en el símbolo del sistema: netsh nps add

registeredserverdomainserver y presione ENTRAR.

７ Nota

En el comando anterior, dominio es el nombre de dominio DNS del dominio donde

desea registrar el NPS y servidor es el nombre del equipo NPS.
Anular el registro de NPS de un dominio
de Active Directory
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En el proceso de administración de la implementación de NPS, puede resultar útil mover

un NPS a otro dominio, reemplazar un NPS o retirar un NPS.

Al mover o retirar un NPS, puede anular el registro de NPS en los dominios de Active
Directory donde nps tiene permiso para leer las propiedades de las cuentas de usuario
en Active Directory.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

Para anular el registro de nps

1. En el controlador de dominio, en Administrador del servidor, haga clic en
Herramientasy, a continuación, haga clic en Usuarios y equipos de Active
Directory. Se abre la Consola de usuarios y equipos de Active Directory.

2. Haga clic en Usuariosy, a continuación, haga doble clic en Servidores RAS e IAS.

3. Haga clic en la pestaña Miembros y, a continuación, seleccione el NPS que desea

anular del registro.

4. Haga clic en Quitar, haga clic en Síy, a continuación, haga clic en Aceptar.
Usar expresiones regulares de NPS
Artículo • 18/01/2023 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

En este tema se explica el uso de expresiones regulares para la coincidencia de patrones

en NPS en Windows Server. Puede usar esta sintaxis para especificar las condiciones de
los atributos de directiva de red y dominios kerberos de RADIUS.

７ Nota

La consola NPS y el complemento MMC de NPS tienen un límite de 256 caracteres

para todas las configuraciones que toman un valor de cadena. Esto incluye todas
las opciones que se pueden configurar mediante expresiones regulares. Para
configurar valores de cadena que superen los 256 caracteres, use comandos NPS
de NETSH. Los valores de cadena configurados que superen los 256 caracteres no
se pueden editar en la consola NPS ni en el complemento MMC de NPS sin
invalidarlos.

Referencia para la coincidencia de patrón

Use la tabla siguiente como referencia cuando vaya a crear expresiones regulares con
sintaxis de coincidencia de patrón. Tenga en cuenta que los patrones de expresiones
regulares suelen estar rodeados por barras diagonales (/).

Carácter Descripción Ejemplo

\ Indica que el carácter siguiente es un carácter /n/ matches the character "n"
especial o que se debe interpretar literalmente. while the sequence /\n/ matches
a line feed or newline
character.

^ Coincide con el principio de entrada o línea.

$ Coincide con el final de entrada o línea.

* Coincide con el carácter anterior ninguna o más /zo*/ matches either "z" or
veces. "zoo."

+ Coincide con el carácter anterior una o más /zo+/ matches "zoo" but not
veces. "z."
Carácter Descripción Ejemplo

? Coincide con el carácter anterior una vez o /a?ve?/ matches the "ve" in
ninguna. "never."

. Coincide con cualquier carácter sencillo,

excepto con un carácter de línea nueva.

(pattern) Coincide con "pattern" y recuerda la

coincidencia.
Para coincidir con los caracteres literales ( y )
(paréntesis), use \( o \) .

x | y Coincide con x o y.

{n} Coincide exactamente con n veces (n es un /o{2}/ does not match the "o" in
entero no negativo). "Bob," but matches the first two
instances of the letter o in
"foooood."

{n,} Coincide con al menos n veces (n es un entero /o{2,}/ does not match the "o"
no negativo). in "Bob" but matches all of the
instances of the letter o in
"foooood." /o{1,}/ is equivalent
to /o+/.

{n,m} Coincide con al menos n y al menos m veces (m /o{1,3}/ matches the first three
y n son enteros no negativos). instances of the letter o in
"fooooood."

[xyz] Coincide con cualquiera de los caracteres /[abc]/ matches the "a" in
incluidos (un juego de caracteres). "plain."

[^xyz] Coincide con cualquiera de los caracteres no /[^abc]/ matches the "p" in
incluidos (un juego de caracteres negativos). "plain."

\b Coincide con un límite de palabra (por ejemplo, /ea*r\b/ matches the "er" in
un espacio). "never early."

\B Coincide si no es un límite de palabra. /ea*r\B/ matches the "ear" in

"never early."

\d Coincide con un carácter de dígito (equivalente

a dígitos de 0 a 9).

\D Coincide con un carácter nondigit (equivalente

a [^0-9] ).

\f Coincide con un carácter de avance de página.

 Carácter Descripción Ejemplo

\n Coincide con un carácter de salto de línea.

\r Coincide con un carácter de retorno de carro.

\s Coincide con cualquier carácter de espacio en

blanco, incluido el espacio, la tabulación y la
fuente de formularios (equivalente a [
\f\n\r\t\v] ).

\S Coincide con cualquier carácter de espacio no

en blanco (equivalente a [^ \f\n\r\t\v] ).

\t Coincide con un carácter de tabulación.

\v Coincide con un carácter de tabulación vertical.

\w Coincide con cualquier carácter de palabra,

incluido el carácter de subrayado (equivalente a
[A-Za-z0-9_] ).

\W Coincide con cualquier carácter que no sea de

palabra, excepto el carácter de subrayado
(equivalente a [^A-Za-z0-9_] ).

\num Hace referencia a coincidencias recordadas ( ? \1 reemplaza lo que se almacena

num , donde num es un entero positivo). Esta en la primera coincidencia
opción solo se puede usar en el cuadro de recordada.
texto Reemplazar al configurar la manipulación
de atributos.

/n/ Permite la inserción de códigos ASCII en

expresiones regulares ( ?n , donde n es un valor
de escape octal, hexadecimal o decimal).

Ejemplos de atributos de directiva de red

Los ejemplos siguientes describen el uso de la sintaxis de coincidencia de patrón para
especificar atributos de directiva de red:

Para especificar todos los números de teléfono del código de área 899, la sintaxis
es:

899.*

Para especificar un intervalo de direcciones IP que comienzan por 192.168.1, la

sintaxis es:
 192\.168\.1\..+

Ejemplos de tratamiento del nombre de

territorio en el atributo User Name

７ Nota

La manipulación del dominio kerberos no funciona con PEAP.

El comportamiento deseado puede realizarse cambiando a EAP-TLS o EAP-
MSCHAPv2 para la autenticación o agregando un sufijo UPN al dominio para cada
nombre de dominio adicional que necesite resolver.

En los ejemplos siguientes se describe el uso de la sintaxis de coincidencia de patrones

para manipular nombres de dominio kerberos para el atributo Nombre de usuario, que
se encuentra en la pestaña Atributo de las propiedades de una directiva de solicitud de
conexión.

Para quitar la parte de dominio kerberos del atributo User Name

En un escenario de acceso telefónico subcontratado en el que un proveedor de servicios

de Internet (ISP) enruta las solicitudes de conexión a una organización NPS, el proxy
RADIUS de ISP puede requerir un nombre de dominio kerberos para enrutar la solicitud
de autenticación. Sin embargo, es posible que el NPS no reconozca la parte del nombre
de dominio kerberos del nombre de usuario. Por lo tanto, el proxy RADIUS de ISP debe
quitar el nombre del dominio kerberos antes de que se reenvíe al NPS de la
organización.

Encontrar: @microsoft\.com

Sustituya:

Para reemplazar por user@[Link]\usuario

Encontrar: (.*)@(.*)

Reemplazar: $2\$1

Para reemplazar domain\user por specific_domain\user

Encontrar: (.*)\\(.*)

Reemplazar: specific_domain \$2

Para reemplazar al usuario por user@specific_domain

Encontrar: $

Reemplazar: @specific_domain

Ejemplo de reenvío de mensajes RADIUS por

parte de un servidor proxy
Puede crear reglas de enrutamiento que reenvíen mensajes RADIUS con un nombre de
territorio específico a un conjunto determinado de servidores RADIUS cuando NPS se
use como un proxy RADIUS. A continuación, se indica la sintaxis recomendada para el
enrutamiento de solicitudes en función del nombre de territorio.

Nombre netBIOS: WCOAST

Patrón: ^wcoast\\

En el ejemplo siguiente, [Link] es un sufijo único de nombre principal de

usuario (UPN) para el [Link] de dominio DNS o Active Directory. Con el
patrón proporcionado, el proxy NPS puede enrutar mensajes basados en el nombre
NetBIOS de dominio o el sufijo UPN.

Nombre netBIOS: WCOAST

Sufijo UPN: [Link]
Patrón: ^wcoast\\|@wcoast\.microsoft\.com$

Para obtener más información sobre cómo administrar NPS, vea Administrar el servidor
de directivas de red.

Para obtener más información sobre NPS, vea Servidor de directivas de red (NPS).
Comprobar la configuración después de
los cambios de NPS
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para comprobar la configuración de NPS después de un cambio
de nombre o dirección IP en el servidor.

Comprobar la configuración después de un

cambio de dirección IP de NPS
Puede haber circunstancias en las que necesite cambiar la dirección IP de un servidor
NPS o proxy, como cuando mueve el servidor a otra subred IP.

Si cambia una dirección IP de proxy o NPS, es necesario volver a configurar partes de la

implementación de NPS.

Use las siguientes directrices generales para comprobar que un cambio de dirección IP
no interrumpe la autenticación de acceso a la red, la autorización o la contabilidad en la
red para servidores NPS RADIUS y servidores proxy RADIUS.

Debe ser miembro de administradores, o equivalente, para realizar estos

procedimientos.

Para comprobar la configuración después de un cambio

de dirección IP de NPS
1. Vuelva a configurar todos los clientes RADIUS, como los puntos de acceso
inalámbricos y los servidores VPN, con la nueva dirección IP del NPS.

2. Si nps es miembro de un grupo de servidores RADIUS remotos, vuelva a configurar

el proxy NPS con la nueva dirección IP del NPS.

3. Si ha configurado nps para usar SQL Server registro, compruebe que la

conectividad entre el equipo que ejecuta SQL Server y nps sigue funcionando
correctamente.

4. Si ha implementado IPsec para proteger el tráfico RADIUS entre nps y un proxy

NPS u otros servidores o dispositivos, vuelva a configurar la directiva IPsec o la
 regla de seguridad de conexión en firewall de Windows con seguridad avanzada
para usar la nueva dirección IP de NPS.

5. Si el NPS está en varios entornos y ha configurado el servidor para enlazarse a un

adaptador de red específico, vuelva a configurar la configuración del puerto NPS
con la nueva dirección IP.

Para comprobar la configuración después de un cambio

de dirección IP del proxy NPS
1. Vuelva a configurar todos los clientes RADIUS, como los puntos de acceso
inalámbricos y los servidores VPN, con la nueva dirección IP del proxy NPS.

2. Si el proxy NPS está en varios entornos y ha configurado el proxy para enlazarse a

un adaptador de red específico, vuelva a configurar la configuración del puerto
NPS con la nueva dirección IP.

3. Vuelva a configurar todos los miembros de todos los grupos de servidores RADIUS
remotos con la dirección IP del servidor proxy. Para realizar esta tarea, en cada NPS
que tenga el proxy NPS configurado como cliente RADIUS:

a. Haga doble clic en NPS (local), haga doble clic en Clientes y servidores RADIUS,
haga clic en Clientes RADIUSy, a continuación, en el panel de detalles, haga doble
clic en el cliente RADIUS que desea cambiar.

b. En Propiedades del cliente RADIUS, en Dirección (IP o DNS), escriba la nueva

dirección IP del proxy NPS.

4. Si ha configurado el proxy NPS para usar el registro de SQL Server, compruebe

que la conectividad entre el equipo que ejecuta SQL Server y el proxy NPS sigue
funcionando correctamente.

Comprobar la configuración después de

cambiar el nombre de un NPS
Puede haber circunstancias en las que necesite cambiar el nombre de un servidor NPS o
proxy, como cuando se rediseñan las convenciones de nomenclatura para los servidores.

Si cambia un nombre de proxy o NPS, es necesario volver a configurar partes de la

implementación de NPS.
Use las siguientes directrices generales para comprobar que un cambio de nombre de
servidor no interrumpe la autenticación, autorización o contabilidad del acceso a la red.

Debe ser miembro de Administradores, o equivalente, para realizar este procedimiento.

Para comprobar la configuración después de un cambio

de nombre de proxy o NPS
1. Si NPS es miembro de un grupo de servidores RADIUS remoto y el grupo está
configurado con nombres de equipo en lugar de direcciones IP, vuelva a
configurar el grupo de servidores RADIUS remoto con el nuevo nombre NPS.

2. Si los métodos de autenticación basados en certificados se implementan en NPS,

el cambio de nombre invalida el certificado de servidor. Puede solicitar un nuevo
certificado al administrador de la entidad de certificación (CA) o, si el equipo es un
equipo miembro del dominio y va a realizar la inscripción automática de
certificados en miembros del dominio, puede actualizar directiva de grupo para
obtener un nuevo certificado mediante la inscripción automática. Para actualizar
directiva de grupo:

a. Abra el símbolo del sistema o Windows PowerShell.

b. Escriba gpupdate y presione ENTRAR.

3. Una vez que tenga un nuevo certificado de servidor, solicite al administrador de la

entidad de certificación que revoque el certificado antiguo.

Una vez revocado el certificado antiguo, NPS lo seguirá utilizando hasta que expire
el certificado antiguo. De forma predeterminada, el certificado antiguo sigue
siendo válido durante un tiempo máximo de una semana y 10 horas. Este período
de tiempo puede ser diferente en función de si la expiración de la lista de
revocación de certificados (CRL) y la expiración de la hora de caché de seguridad
de la capa de transporte (TLS) se han modificado de sus valores predeterminados.
La expiración de CRL predeterminada es de una semana; El tiempo de expiración
predeterminado de la caché TLS es de 10 horas.

Sin embargo, si desea configurar NPS para que use el nuevo certificado
inmediatamente, puede volver a configurar manualmente las directivas de red con
el nuevo certificado.

4. Una vez expirado el certificado anterior, NPS comienza a usar automáticamente el

nuevo certificado.
5. Si ha configurado nps para usar SQL Server registro, compruebe que la
conectividad entre el equipo que ejecuta SQL Server y nps sigue funcionando
correctamente.
Recopilación de datos de usuario del
servidor de directivas de red
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

En este documento se explica cómo buscar información de usuario recopilada por el

servidor de directivas de red (NPS) en caso de que quiera quitarla.

７ Nota

Si le interesa ver o eliminar datos personales, revise las instrucciones de Microsoft

en el sitio Solicitudes del titular de los datos de Windows para el RGPD. Si quiere
obtener información general sobre el RGPD, vea la sección sobre RGPD del Portal
de confianza del servicio .

Información recopilada por NPS

Timestamp
Marca de tiempo del evento
Nombre de usuario
Nombre de usuario completo
Dirección IP de cliente
Proveedor del cliente
Nombre descriptivo del cliente
Tipo de autenticación
Muchos otros campos relacionados con el protocolo RADIUS

Recopilación de datos de NPS

Si los datos de contabilidad están habilitados y configurados, los registros de los
intentos de autenticación de NPS de un usuario se pueden obtener de SQL Server o de
los archivos de registro según la configuración.

Si los datos de contabilidad están configurados para SQL Server, consulte todos los
registros WHERE User_Name = '<username>' .

Si los datos de contabilidad están configurados para un archivo de registro, busque en

el archivo de registro <username> para buscar todas las entradas de registro.
La directiva de red Access Services las entradas del registro de eventos se consideran
duplicados para los datos de contabilidad y no es necesario recopilar.

Si los datos de contabilidad no están habilitados, los registros de los intentos de

autenticación de NPS de un usuario se pueden obtener de la directiva de red y Access
Services de eventos mediante la búsqueda de <username> .
Administrar plantillas NPS
Artículo • 21/12/2022 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar plantillas de servidor de directivas de red (NPS) para crear elementos de
configuración, como clientes de Servicio de autenticación remota telefónica de usuario
(RADIUS) o secretos compartidos, que puede reutilizar en el NPS local y exportar para su
uso en otros NPS.

Administración de plantillas proporciona un nodo en la consola NPS donde puede crear,

modificar, eliminar, duplicar y ver el uso de plantillas NPS. Las plantillas nps están
diseñadas para reducir la cantidad de tiempo y costo que se tarda en configurar NPS en
uno o varios servidores.

Los siguientes tipos de plantilla NPS están disponibles para la configuración en

Administración de plantillas.

Secretos compartidos. Este tipo de plantilla permite especificar un secreto

compartido que puede reutilizar (seleccionando la plantilla en la ubicación
adecuada en la consola NPS) al configurar clientes y servidores RADIUS.

Clientes RADIUS. Este tipo de plantilla permite configurar opciones de cliente

RADIUS que puede reutilizar seleccionando la plantilla en la ubicación adecuada
en la consola NPS.

Servidores RADIUS remotos. Esta plantilla permite configurar opciones de servidor

RADIUS remotas que puede reutilizar seleccionando la plantilla en la ubicación
adecuada en la consola NPS.

Filtros IP. Esta plantilla permite crear filtros IPv4 (Protocolo de Internet versión 4) y
Protocolo de Internet versión 6 (IPv6) que puede reutilizar (seleccionando la
plantilla en la ubicación adecuada en la consola nps) al configurar directivas de
red.

Creación de una plantilla nps

La configuración de una plantilla es diferente de configurar nps directamente. La
creación de una plantilla no afecta a la funcionalidad de NPS. Solo cuando se selecciona
la plantilla en la ubicación adecuada en la consola NPS y se aplica la plantilla, la plantilla
afecta a la funcionalidad de NPS.
Por ejemplo, si configura un cliente RADIUS en la consola NPS en Servidores y clientes
RADIUS, modifique la configuración de NPS y tome un paso en la configuración de NPS
para comunicarse con uno de los servidores de acceso a la red. (El siguiente paso
consiste en configurar el servidor de acceso a la red (NAS) para comunicarse con NPS).

Sin embargo, si configura una nueva plantilla de clientes RADIUS en la consola NPS en
Administración de plantillas en lugar de crear un nuevo cliente RADIUS en Clientes y
servidores RADIUS, ha creado una plantilla, pero aún no ha modificado la funcionalidad
de NPS. Para modificar la funcionalidad de NPS, debe aplicar la plantilla desde la
ubicación correcta en la consola de NPS.

En el procedimiento siguiente se proporcionan instrucciones sobre cómo crear una

plantilla.

La pertenencia a administradores, o equivalente, es el mínimo necesario para completar

este procedimiento.

Para crear una plantilla nps

1. En nps, en Administrador del servidor, haga clic en Herramientasy, a continuación,
haga clic en Servidor de directivas de red. Se abre la consola NPS.

2. En la consola NPS, expanda Administración de plantillas, haga clic con el botón

derecho en un tipo de plantilla, como Clientes RADIUSy, a continuación, haga clic
en Nuevo.

3. Se abre un nuevo cuadro de diálogo de propiedades de plantilla que puede usar

para configurar la plantilla.

Aplicación de una plantilla nps

Para usar una plantilla que haya creado en Administración de plantillas, vaya a una
ubicación de la consola NPS donde pueda aplicar la plantilla. Por ejemplo, si desea
aplicar una plantilla de secretos compartidos a una configuración de cliente RADIUS,
puede usar el procedimiento siguiente.

La pertenencia a administradores, o equivalente, es el mínimo necesario para completar

este procedimiento.

Para aplicar una plantilla nps

 1. En nps, en Administrador del servidor, haga clic en Herramientasy, a continuación,
haga clic en Servidor de directivas de red. Se abre la consola NPS.

2. En la consola NPS, expanda Clientes y servidores RADIUSy, a continuación,

expanda Clientes RADIUS.

[Link] clientes RADIUS, en el panel de detalles, haga clic con el botón derecho en el
cliente RADIUS al que desea aplicar la plantilla NPS y, a continuación, haga clic en
Propiedades.

4. En el cuadro de diálogo de propiedades del cliente RADIUS, en Seleccionar una

plantilla de secretos compartidos existente, seleccione la plantilla que desea
aplicar en la lista de plantillas.

Exportación o importación de plantillas NPS

Puede exportar plantillas para usarlas en otros NPS, o bien puede importar plantillas en
Administración de plantillas para usarlas en el equipo local.

La pertenencia a administradores, o equivalente, es el mínimo necesario para completar

este procedimiento.

Para exportar o importar plantillas nps

1. Para exportar plantillas NPS, en la consola NPS, haga clic con el botón derecho en
Administración de plantillasy, a continuación, haga clic en Exportar plantillas a un
archivo.

2. Para importar plantillas NPS, en la consola NPS, haga clic con el botón derecho en
Administración de plantillasy ,a continuación, haga clic en Importar plantillas desde
un equipo o Importar plantillas desde un archivo.
Shell de red (netsh)
Artículo • 26/01/2023 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016;
Azure Stack HCI, versiones 21H2 y 20H2

Shell de red (netsh) es una utilidad de línea de comandos que permite configurar y
mostrar el estado de varios componentes y roles de servidor de comunicaciones de red
tras instalarlos en equipos que ejecutan Windows Server.

Algunas tecnologías de cliente, como el cliente del Protocolo de configuración dinámica

de host (DHCP) y BranchCache, también proporcionan comandos netsh que permiten
configurar equipos cliente que ejecutan Windows 10.

En la mayoría de los casos, los comandos netsh proporcionan la misma funcionalidad

que está disponible cuando se usa el complemento Microsoft Management Console
(MMC) para cada función de servidor de red o característica de red. Por ejemplo, puede
configurar el servidor de directivas de red (NPS) mediante el complemento MMC NPS o
los comandos netsh en el contexto de netsh nps .

Además, hay comandos netsh para tecnologías de red, como para IPv6, puente de red y
llamada a procedimiento remoto (RPC), que no están disponibles en Windows Server
como complemento MMC.

） Importante

Se recomienda usar Windows PowerShell para administrar las tecnologías de red en

Windows Server y Windows 10, en lugar de shell de red. Network Shell se incluye
por compatibilidad con los scripts y se admite su uso.

Referencia técnica de Netsh

La referencia del comando netsh proporciona una lista completa de comandos netsh,
incluida la sintaxis, los parámetros y los ejemplos. Puede usar esta referencia para
compilar scripts y archivos por lotes mediante comandos netsh para la administración
local o remota de tecnologías y dispositivos de red.
Sintaxis, contextos y formatos de
comandos netsh
Artículo • 21/09/2022 • Tiempo de lectura: 8 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Puedes usar este tema para aprender cómo especificar contextos y subcontextos de
netsh, comprender la sintaxis de netsh y el formato de los comandos, y cómo ejecutar
comandos netsh en equipos locales y remotos.

Netsh es una utilidad de scripting de línea de comandos que permite mostrar o

modificar la configuración de red de un equipo actualmente en ejecución. Los
comandos netsh se pueden ejecutar escribiendo comandos en el símbolo del sistema de
netsh y se pueden usar en archivos por lotes o scripts. Los equipos remotos y locales se
pueden configurar mediante los comandos netsh.

Netsh también proporciona una característica de scripting que permite ejecutar un

grupo de comandos en modo de lotes con un equipo especificado. Con netsh se puede
guardar un script de configuración en un archivo de texto para archivarlo y así
configurar otros equipos.

Contextos de Netsh
Netsh interactúa con otros componentes del sistema operativo mediante archivos de
biblioteca de vínculos dinámicos (DLL).

Cada archivo DLL de la aplicación auxiliar netsh proporciona un amplio conjunto de

características denominado contexto, que es un grupo de comandos específicos de un
rol o característica del servidor de red. Estos contextos amplían la funcionalidad de
netsh al proporcionar compatibilidad con la configuración y la supervisión de uno o
varios servicios, utilidades o protocolos. Por ejemplo, [Link] da a netsh el
contexto y el conjunto de comandos necesarios para configurar y administrar los
servidores DHCP.

Obtención de una lista de contextos

Para obtener una lista de contextos de netsh, puedes abrir el símbolo del sistema o
Windows PowerShell en un equipo que ejecute Windows Server 2016 o Windows 10.
Escriba el comando netsh y presione ENTRAR. Escribe /? y presiona ENTRAR.

A continuación tienes una salida de ejemplo para estos comandos en un equipo que
ejecuta Windows Server 2016 Datacenter.

PS C:\Windows\system32> netsh
netsh>/?

The following commands are available:

Commands in this context:

.. - Goes up one context level.
? - Displays a list of commands.
abort - Discards changes made while in offline mode.
add - Adds a configuration entry to a list of entries.
advfirewall - Changes to the `netsh advfirewall' context.
alias - Adds an alias.
branchcache - Changes to the `netsh branchcache' context.
bridge - Changes to the `netsh bridge' context.
bye - Exits the program.
commit - Commits changes made while in offline mode.
delete - Deletes a configuration entry from a list of entries.
dhcpclient - Changes to the `netsh dhcpclient' context.
dnsclient - Changes to the `netsh dnsclient' context.
dump - Displays a configuration script.
exec - Runs a script file.
exit - Exits the program.
firewall - Changes to the `netsh firewall' context.
help - Displays a list of commands.
http - Changes to the `netsh http' context.
interface - Changes to the `netsh interface' context.
ipsec - Changes to the `netsh ipsec' context.
ipsecdosprotection - Changes to the `netsh ipsecdosprotection' context.
lan - Changes to the `netsh lan' context.
namespace - Changes to the `netsh namespace' context.
netio - Changes to the `netsh netio' context.
offline - Sets the current mode to offline.
online - Sets the current mode to online.
popd - Pops a context from the stack.
pushd - Pushes current context on stack.
quit - Exits the program.
ras - Changes to the `netsh ras' context.
rpc - Changes to the `netsh rpc' context.
set - Updates configuration settings.
show - Displays information.
trace - Changes to the `netsh trace' context.
unalias - Deletes an alias.
wfp - Changes to the `netsh wfp' context.
winhttp - Changes to the `netsh winhttp' context.
winsock - Changes to the `netsh winsock' context.
 The following sub-contexts are available:
advfirewall branchcache bridge dhcpclient dnsclient firewall http
interface ipsec ipsecdosprotection lan namespace netio ras rpc trace wfp
winhttp winsock

To view help for a command, type the command, followed by a space, and
then type ?.

Subcontextos
Los contextos netsh pueden contener comandos y contextos adicionales, denominados
subcontextos. Por ejemplo, en el contexto Routing, puedes cambiar a los subcontextos IP
e IPv6.

Para mostrar una lista de comandos y subcontextos que puede usar dentro de un
contexto, en el símbolo del sistema de netsh, escriba el nombre del contexto y, a
continuación, escriba /? o ayuda. Por ejemplo, para mostrar una lista de subcontextos y
comandos que puede usar en el contexto de enrutamiento, en el símbolo del sistema de
netsh (es decir, netsh), escriba una de las siguientes opciones:

routing /?

routing help

Para realizar tareas en otro contexto sin cambiar el contexto actual, escribe la ruta de
acceso de contexto del comando que quieres usar en el símbolo del sistema de netsh.
Por ejemplo, para agregar una interfaz denominada "Conexión de área local" en el
contexto de IGMP sin cambiar primero al contexto de IGMP, en el símbolo del sistema
de Netsh, escribe:

routing ip igmp add interface "Conexión de área local" startupqueryinterval=21

Ejecución de comandos netsh

Para ejecutar un comando netsh, debes iniciar netsh desde el símbolo del sistema; para
ello, escribe netsh y presiona Entrar. Luego, puedes cambiar al contexto que contiene el
comando que quieres usar. Los contextos que están disponibles dependen de los
componentes de red que hayas instalado. Por ejemplo, si escribes dhcp en el símbolo
del sistema de netsh y presionas Entrar, netsh cambia al contexto del servidor DHCP. Sin
embargo, si no tienes DHCP instalado, aparece el siguiente mensaje:

No se encuentra el comando: dhcp.

Leyenda de formato
Puede usar la siguiente leyenda de formato para interpretar y usar la sintaxis correcta
del comando netsh al ejecutar el comando en el símbolo del sistema de netsh o en un
archivo o script por lotes.

El texto en cursiva es información que debes proporcionar mientras escribes el

comando. Por ejemplo, si un comando tiene un parámetro denominado -
NombreDeUsuario, tienes que escribir el nombre de usuario real.
El texto en negrita es información que debes escribir tal cual se muestra mientras
escribes el comando.
El texto seguido de puntos suspensivos (...) es un parámetro que se puede repetir
varias veces en una línea de comandos.
El texto entre corchetes [ ] es un elemento opcional.
El texto que se encuentra entre llaves { } con opciones separadas por una
canalización proporciona un conjunto de opciones entre las que debe seleccionar
solo una, como {enable|disable} .
El texto con formato de fuente Courier es código o la salida del programa.

Ejecución de comandos netsh desde el símbolo

del sistema o Windows PowerShell
Para iniciar el shell de red y escribir netsh en el símbolo del sistema o en Windows
PowerShell, puedes usar el siguiente comando.

netsh
Netsh es una utilidad de scripting de línea de comandos que permite mostrar o
modificar, local o remotamente, la configuración de red de un equipo actualmente en
ejecución. Si se usa sin parámetros, netsh abre [Link] símbolo del sistema (es decir,
netsh).

Syntax
netsh[ -aAliasFile] [ -cContext ] [-rRemoteComputer] [ -u [ DomainName\ ] UserName ] [
-pPassword | *] [{NetshCommand-fScriptFile}]

Parámetros

-a
Opcional. Especifica que se te devuelve al símbolo del sistema netsh después de
ejecutar ArchivoDeAlias.

AliasFile

Opcional. Especifica el nombre del archivo de texto que contiene uno o más comandos
netsh.

-c

Opcional. Especifica que netsh entra en el contexto de netsh especificado.

Context

Opcional. Especifica el contexto de netsh que quieres especificar.

-r

Opcional. Especifica que quieres que el comando se ejecute en un equipo remoto.

） Importante

Si usas algunos comandos netsh de forma remota en otro equipo con el parámetro
netsh –r, el servicio Registro remoto debe estar en ejecución en el equipo remoto.
Si no está en ejecución, Windows muestra un mensaje de error "No se encontró la
ruta de red".

RemoteComputer

Opcional. Especifica el equipo remoto que quieres configurar.

-u

Opcional. Especifica que quieres ejecutar el comando netsh en una cuenta de usuario.

DomainName\\

Opcional. Especifica el dominio donde se encuentra la cuenta de usuario. El valor

predeterminado es el dominio local si no se especifica DomainName \.

UserName

Opcional. Especifica el nombre de la cuenta de usuario.

-p
Opcional. Especifica que quieres proporcionar una contraseña para la cuenta de usuario.

Password

Opcional. Especifica la contraseña de la cuenta de usuario que especificó con -

uUserName.

NetshCommand

Opcional. Especifica el comando netsh que quieres ejecutar.

-f

Opcional. Sale de netsh después de ejecutar el script que se designa con

ArchivoDeScript.

ScriptFile

Opcional. Especifica el script que quieres ejecutar.

/?

Opcional. Muestra la ayuda en el símbolo del sistema de netsh.

７ Nota

Si especificas -r seguido de otro comando, -r ejecuta el comando en el equipo

remoto y, luego, vuelve al símbolo del sistema [Link]. Si especificas -r sin otro
comando, -r se abre en modo remoto. El proceso es similar al uso de set machine
en el símbolo del sistema de netsh. Cuando usas -r , estableces el equipo de
destino para la instancia actual de -r únicamente. Después de salir de netsh y
volver a entrar, el equipo de destino se restablece como equipo local. Puedes
ejecutar comandos netsh en un equipo remoto si especificas un nombre de equipo
almacenado en WINS, un nombre de UNC, un nombre de Internet que deba
resolver el servidor DNS, o una dirección IP.

Escritura de valores de cadena de parámetros para comandos netsh

A lo largo de la referencia de los comandos netsh, hay comandos que contienen

parámetros para los que se requiere un valor de cadena.

En el caso donde un valor de cadena contenga espacios entre caracteres, como los
valores de cadena que se componen de más de una palabra, es necesario escribir el
valor de cadena entre comillas. Por ejemplo, para un parámetro denominado interface
con un valor de cadena de Wireless Network Connection, usa comillas alrededor del
valor de cadena:

interface="Wireless Network Connection"

Archivo por lotes de ejemplo de shell de
red (Netsh)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Puede usar este tema para obtener información sobre cómo crear un archivo por lotes
que realice varias tareas mediante Netsh en Windows Server. En este archivo por lotes
de ejemplo, se utiliza el contexto netsh wins.

Información general sobre el archivo por lotes

de ejemplo
Puede usar comandos netsh para Windows Internet Name Service (WINS) en archivos
por lotes y otros scripts para automatizar las tareas. En el siguiente archivo por lotes de
ejemplo se muestra cómo usar los comandos Netsh para WINS a fin de realizar una
serie de tareas relacionadas.

En este archivo por lotes de ejemplo, WINS-A es un servidor WINS con la dirección IP
[Link] y WINS-B es un servidor WINS con la dirección IP [Link].

El archivo por lotes de ejemplo realiza las siguientes tareas.

Agrega un registro de nombre dinámico con la dirección IP [Link],

MY_RECORD [04h], a WINS-A
Establece WINS-B como asociado de replicación de inserción/extracción de WINS-
A
Se conecta a WINS-B y, a continuación, establece WINS-A como un asociado de
replicación de inserción/extracción de WINS-B.
Inicia una replicación de inserción de WINS-A a WINS-B
Se conecta a WINS-B para comprobar que el nuevo registro, MY_RECORD, se
replicó correctamente

Archivo por lotes de ejemplo de Netsh

En el siguiente archivo por lotes de ejemplo, las líneas que contienen comentarios van
precedidas de "rem" para indicar que se trata de un comentario. Netsh omite los
comentarios.

rem: Begin example batch file.

rem two WINS servers:
rem (WINS-A) [Link]
rem (WINS-B) [Link]

rem 1. Connect to (WINS-A), and add the dynamic name MY\_RECORD \[04h\] to
the (WINS-A) database.
netsh wins server [Link] add name Name=MY\_RECORD EndChar=04 IP=
{[Link]}

rem 2. Connect to (WINS-A), and set (WINS-B) as a push/pull replication

partner of (WINS-A).
netsh wins server [Link] add partner Server=[Link] Type=2

rem 3. Connect to (WINS-B), and set (WINS-A) as a push/pull replication

partner of (WINS-B).
netsh wins server [Link] add partner Server=[Link] Type=2

rem 4. Connect back to (WINS-A), and initiate a push replication to (WINS-

B).
netsh wins server [Link] init push Server=[Link] PropReq=0

rem 5. Connect to (WINS-B), and check that the record MY_RECORD [04h] was
replicated successfully.
netsh wins server [Link] show name Name=MY_RECORD EndChar=04

rem 6. End example batch file.

Comandos Netsh WINS utilizados en el archivo

por lotes de ejemplo
En la siguiente sección se enumeran los comandos netsh wins que se usan en este
procedimiento de ejemplo.

server. Desplaza el contexto actual de la línea de comandos WINS al servidor

especificado por su nombre o dirección IP.
add name. Registra un nombre en el servidor WINS.
add partner. Agrega un asociado de replicación en el servidor WINS.
init push. Inicia y envía un desencadenador de inserción a un servidor WINS.
show name. Muestra información detallada de un registro determinado en la base
de datos del servidor WINS.
Referencias adicionales
Shell de red (Netsh)
Comandos netsh http
Artículo • 21/12/2022 • Tiempo de lectura: 8 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Usa netsh http para consultar y configurar los parámetros y las opciones de [Link].

 Sugerencia

Si usa Windows PowerShell en un equipo que ejecuta Windows Server o

Windows 10, escriba netsh y presione ENTRAR. En el símbolo del sistema de netsh,
escribe http y presiona Entrar para obtener el símbolo del sistema de netsh http.

netsh http>

Los comandos netsh http disponibles son:

add iplisten
add sslcert
add timeout
add urlacl
delete cache
delete iplisten
delete sslcert
delete timeout
delete urlacl
flush logbuffer
show cachestate
show iplisten
show servicestate
show sslcert
show timeout
show urlacl

add iplisten
Agrega una nueva dirección IP a la lista de escucha de IP, sin incluir el número de
puerto.
Sintaxis

PowerShell

add iplisten [ ipaddress= ] IPAddress

Parámetros

Parámetro Descripción Requisito

ipaddress Dirección IPv4 o IPv6 que se va a agregar a la lista de escucha de IP. La Requerido
lista de escucha de IP se utiliza para establecer el ámbito de la lista de
direcciones a las que se enlaza el servicio HTTP. "[Link]" significa
cualquier dirección IPv4 y "::" significa cualquier dirección IPv6.

Ejemplos

A continuación se muestran cuatro ejemplos del comando add iplisten.

add iplisten ipaddress=fe80::1

add iplisten ipaddress=[Link]
add iplisten ipaddress=[Link]
add iplisten ipaddress=::

add sslcert
Agrega un nuevo enlace de certificado de servidor SSL y las directivas de certificado de
cliente correspondientes para una dirección IP y un puerto.

Sintaxis

PowerShell

add sslcert [ ipport= ] IPAddress:port [ certhash= ] CertHash [ appid= ]

GUID [ [ certstorename= ] CertStoreName [ verifyclientcertrevocation= ]
enable | disable [verifyrevocationwithcachedclientcertonly= ] enable |
disable [ usagecheck= ] enable | disable [ revocationfreshnesstime= ] U-Int
[ urlretrievaltimeout= ] U-Int [sslctlidentifier= ] SSLCTIdentifier [
sslctlstorename= ] SLCtStoreName [ dsmapperusage= ] enable | disable [
clientcertnegotiation= ] enable | disable ] ]

Parámetros

Parámetro Descripción Requisito

Parámetro Descripción Requisito

ipport Especifica la dirección IP y el puerto Requerido

para el enlace. Un carácter de dos
puntos (:) se utiliza como delimitador
entre la dirección IP y el número de
puerto.

certhash Especifica el hash SHA del certificado. Requerido

Este hash tiene una longitud de
20 bytes y se especifica como una
cadena hexadecimal.

appid Especifica el GUID para identificar la Requerido

aplicación propietaria.

certstorename Especifica el nombre del almacén del Opcional

certificado. El valor predeterminado es
MY. El certificado debe almacenarse en
el contexto del equipo local.

verifyclientcertrevocation Especifica la activación o desactivación Opcional

de la comprobación de la revocación de
certificados de cliente.

verifyrevocationwithcachedclientcertonly Especifica si el uso únicamente del Opcional

certificado de cliente almacenado en
memoria caché para la comprobación
de la revocación está habilitado o
deshabilitado.

usagecheck Especifica si la comprobación del uso Opcional

está habilitada o deshabilitada. Está
habilitada de forma predeterminada.

revocationfreshnesstime Especifica el intervalo de tiempo, en Opcional

segundos, para buscar una lista de
revocación de certificados (CRL)
actualizada. Si este valor es cero, la
nueva CRL solo se actualizará si expira
la anterior.

urlretrievaltimeout Especifica el intervalo de tiempo de Opcional

espera (en milisegundos) después del
intento de recuperar la lista de
revocación de certificados para la
dirección URL remota.
 Parámetro Descripción Requisito

sslctlidentifier Especifica la lista de emisores de Opcional

certificados en los que se puede confiar.
Esta lista puede ser un subconjunto de
los emisores de certificados que son de
confianza para el equipo.

sslctlstorename Especifica el nombre del almacén de Opcional

certificados en LOCAL_MACHINE donde
se almacena SslCtlIdentifier.

dsmapperusage Especifica si los asignadores de DS Opcional

están habilitados o deshabilitados. De
forma predeterminada, están
deshabilitados.

clientcertnegotiation Especifica si la negociación del Opcional

certificado está habilitada o
deshabilitada. De forma
predeterminada, está deshabilitada.

Ejemplos

El siguiente es un ejemplo del comando add sslcert.

add sslcert ipport=[Link]:443

certhash=0102030405060708090A0B0C0D0E0F1011121314 appid={00112233-4455-
6677-8899- AABBCCDDEEFF}

add timeout
Agrega un tiempo de espera global al servicio.

Sintaxis

PowerShell

add timeout [ timeouttype= ] IdleConnectionTimeout | HeaderWaitTimeout [

value=] U-Short

Parámetros

Parámetro Descripción

timeouttype Tipo de tiempo de espera del valor de configuración.

 Parámetro Descripción

value Valor del tiempo de espera (en segundos) Si el valor está en notación hexadecimal,
agrega el prefijo 0x.

Ejemplos

A continuación se muestran dos ejemplos del comando add timeout.

add timeout timeouttype=idleconnectiontimeout value=120

add timeout timeouttype=headerwaittimeout value=0x40

add urlacl
Agrega una entrada de reserva de localizador uniforme de recursos (URL). Este comando
reserva la dirección URL para usuarios y cuentas que no son administradores. La lista
DACL puede especificarse mediante un nombre de cuenta NT con los parámetros listen
y delegate o mediante una cadena SDDL.

Sintaxis

PowerShell

add urlacl [ url= ] URL [ [user=] User [ [ listen= ] yes | no [ delegate= ]

yes | no ] | [ sddl= ] SDDL ]

Parámetros

Parámetro Descripción Requisito

url Especifica el localizador uniforme de recursos (URL) completo. Requerido

user Especifica el nombre del usuario o el grupo de usuarios. Requerido

listen Especifica uno de los siguientes valores: yes, permite al usuario Opcional
registrar direcciones URL. Este es el valor predeterminado. no: deniega
al usuario el registro de direcciones URL.

delegate Especifica uno de los siguientes valores: yes, permite al usuario delegar Opcional
direcciones URL. no: deniega al usuario la delegación de direcciones
URL. Este es el valor predeterminado.

sddl Especifica una cadena SDDL que describe la lista DACL. Opcional

Ejemplos
A continuación se muestran cuatro ejemplos del comando add urlacl.

add urlacl url=[Link] user=DOMAIN\user

add urlacl url=[Link] user=DOMAIN\user
listen=yes
add urlacl url=[Link] user=DOMAIN\user
delegate=no
add urlacl url=[Link] sddl=...

delete cache
Elimina todas las entradas, o una entrada especificada, de la memoria caché de URI del
kernel del servicio HTTP.

Sintaxis

PowerShell

delete cache [ [ url= ] URL [ [recursive= ] yes | no ]

Parámetros

Parámetro Descripción Requisito

url Especifica el localizador uniforme de recursos (URL) completo que Opcional

quieres eliminar.

recursive Especifica si se quitan todas las entradas de la caché de direcciones Opcional

URL. yes: quita todas las entradas. no: no quita todas las entradas.

Ejemplos

A continuación se muestran dos ejemplos del comando delete cache.

delete cache url=[Link] recursive=yes

delete cache

delete iplisten
Elimina una dirección IP de la lista de escucha de IP. La lista de escucha de IP se utiliza
para establecer el ámbito de la lista de direcciones a las que se enlaza el servicio HTTP.
Sintaxis

PowerShell

delete iplisten [ ipaddress= ] IPAddress

Parámetros

Parámetro Descripción Requisito

ipaddress Dirección IPv4 o IPv6 que se va a eliminar de la lista de escucha de IP. Requerido
La lista de escucha de IP se utiliza para establecer el ámbito de la lista
de direcciones a las que se enlaza el servicio HTTP. "[Link]" significa
cualquier dirección IPv4 y "::" significa cualquier dirección IPv6. No
incluye el número de puerto.

Ejemplos

A continuación se muestran cuatro ejemplos del comando delete iplisten.

delete iplisten ipaddress=fe80::1

delete iplisten ipaddress=[Link]
delete iplisten ipaddress=[Link]
delete iplisten ipaddress=::

delete sslcert
Elimina los enlaces de certificado de servidor SSL y las directivas de certificado de cliente
correspondientes para una dirección IP y un puerto.

Sintaxis

PowerShell

delete sslcert [ ipport= ] IPAddress:port

Parámetros

Parámetro Descripción Requisito

ipport Especifica la dirección IPv4 o IPv6 y el puerto para los que se eliminan Requerido
los enlaces de certificado SSL. Un carácter de dos puntos (:) se utiliza
como delimitador entre la dirección IP y el número de puerto.
Ejemplos

A continuación se muestran tres ejemplos del comando delete sslcert.

delete sslcert ipport=[Link]:443

delete sslcert ipport=[Link]:443
delete sslcert ipport=[::]:443

delete timeout
Elimina un tiempo de espera global y hace que el servicio vuelva a los valores
predeterminados.

Sintaxis

PowerShell

delete timeout [ timeouttype= ] idleconnectiontimeout | headerwaittimeout

Parámetros

Parámetro Descripción Requisito

timeouttype Especifica el tipo de opción de tiempo de espera. Requerido

Ejemplos

A continuación se muestran dos ejemplos del comando delete timeout.

delete timeout timeouttype=idleconnectiontimeout

delete timeout timeouttype=headerwaittimeout

delete urlacl
Elimina las reservas de direcciones URL.

Sintaxis

PowerShell

delete urlacl [ url= ] URL

Parámetros

Parámetro Descripción Requisito

url Especifica el localizador uniforme de recursos (URL) completo que Requerido

quieres eliminar.

Ejemplos

A continuación se muestran dos ejemplos del comando delete urlacl.

delete urlacl url=[Link]

delete urlacl url=[Link]

flush logbuffer
Vacía los búferes internos de los archivos de registro.

Sintaxis

PowerShell

flush logbuffer

show cachestate
Enumera los recursos de URI en caché y sus propiedades asociadas. Este comando
muestra todos los recursos y sus propiedades asociadas que se han almacenados en la
caché de respuesta HTTP, o muestra un único recurso y sus propiedades asociadas.

Sintaxis

PowerShell

show cachestate [ [url= ] URL]

Parámetros

Parámetro Descripción Requisito

url Especifica la dirección URL completa que quieres mostrar. Si no se Opcional

especifica, se muestran todas las direcciones URL. La dirección URL
también puede ser un prefijo para las direcciones URL registradas.
Ejemplos

A continuación se muestran dos ejemplos del comando show cachestate:

show cachestate url=[Link]

show cachestate

show iplisten
Muestra todas las direcciones IP en la lista de escucha IP. La lista de escucha de IP se
utiliza para establecer el ámbito de la lista de direcciones a las que se enlaza el servicio
HTTP. "[Link]" significa cualquier dirección IPv4 y "::" significa cualquier dirección IPv6.

Sintaxis

PowerShell

show iplisten

show servicestate
Muestra una instantánea del servicio HTTP.

Sintaxis

PowerShell

show servicestate [ [ view= ] session | requestq ] [ [ verbose= ] yes | no ]

Parámetros

Parámetro Descripción Requisito

Vista Especifica si se va a ver una instantánea del estado del servicio HTTP en Opcional
función de la sesión del servidor o de las colas de solicitudes.

Verbose Especifica si se va a mostrar información detallada con información Opcional

sobre propiedades.

Ejemplos

A continuación se muestran dos ejemplos del comando show servicestate.

 show servicestate view="session"
show servicestate view="requestq"

show sslcert
Muestra enlaces de certificado de servidor de Capa de sockets seguros (SSL) y las
directivas de certificado de cliente correspondientes para una dirección IP y un puerto.

Sintaxis

PowerShell

show sslcert [ ipport= ] IPAddress:port

Parámetros

Parámetro Descripción Requisito

ipport Especifica la dirección IPv4 o IPv6 y el puerto para los que se muestran Requerido
los enlaces de certificado SSL. Un carácter de dos puntos (:) se utiliza
como delimitador entre la dirección IP y el número de puerto. Si no
especificas ipport, se muestran todos los enlaces.

Ejemplos

A continuación se muestran cinco ejemplos del comando show sslcert.

show sslcert ipport=[fe80::1]:443

show sslcert ipport=[Link]:443
show sslcert ipport=[Link]:443
show sslcert ipport=[::]:443
show sslcert

show timeout
Muestra los valores de tiempo de espera en segundos del servicio HTTP.

Sintaxis

PowerShell

show timeout
show urlacl
Muestra las listas de control de acceso discrecional (DACL) de la dirección URL reservada
especificada o de todas las direcciones URL reservadas.

Sintaxis

PowerShell

show urlacl [ [url= ] URL]

Parámetros

Parámetro Descripción Requisito

url Especifica la dirección URL completa que quieres mostrar. Si no se Opcional

especifica, se muestran todas las direcciones URL.

Ejemplos

A continuación se muestran tres ejemplos del comando show urlacl.

show urlacl url=[Link]

show urlacl url=[Link]
show urlacl
Comandos de proxy de puerto de la
interfaz de netsh
Artículo • 21/12/2022 • Tiempo de lectura: 11 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Usa los comandos de proxy de puerto de la interfaz de netsh para que funcionen como
servidores proxy entre las redes y aplicaciones IPv4 e IPv6. Puedes usar estos comandos
para establecer el servicio de proxy de las siguientes maneras:

Mensajes de equipos y aplicaciones configurados con IPv4 enviados a otros

equipos y aplicaciones configurados con IPv4.

Mensajes de equipos y aplicaciones configurados con IPv4 enviados a equipos y

aplicaciones configurados con IPv6.

Mensajes de equipos y aplicaciones configurados con IPv6 enviados a equipos y

aplicaciones configurados con IPv4.

Mensajes de equipos y aplicaciones configurados con IPv6 enviados a otros

equipos y aplicaciones configurados con IPv6.

Al escribir archivos por lotes o scripts con estos comandos, cada comando debe
comenzar con netsh interface portproxy. Por ejemplo, al usar el comando delete
v4tov6 para especificar que el servidor proxy de puerto elimina un puerto y una
dirección IPv4 de la lista de direcciones IPv4 en las que el servidor escucha, el archivo
por lotes o script deben usar la siguiente sintaxis:

PowerShell

netsh interface portproxy delete v4tov6 listenport= {Integer | ServiceName}

[[listenaddress=] {IPv4Address| HostName}] [[protocol=]tcp]

Los comandos disponibles de proxy de puerto de la interfaz de netsh son:

add v4tov4

add v4tov6

add v6tov4

add v6tov6
 delete v4tov4

delete v4tov6

delete v6tov6

reset ipv4

reset ipv6

set v4tov4

set v4tov6

setv6tov4

set v6tov6

show all

show v4tov4

show v4tov6

show v6tov4

show v6tov6

add v4tov4
El servidor proxy de puerto escucha los mensajes enviados a un puerto y una dirección
IPv4 específicos. Asigna un puerto y una dirección IPv4 para enviar los mensajes
recibidos después de establecer una conexión TCP independiente.

Sintaxis
PowerShell

add v4tov4 listenport= {Integer | ServiceName} [[connectaddress=]

{IPv4Address | HostName}] [[connectport=] {Integer | ServiceName}]
[[listenaddress=] {IPv4Address | HostName}] [[protocol=]tcp]

Parámetros

Parámetro Descripción
 Parámetro Descripción

listenport Especifica el puerto IPv4, por número de puerto o nombre de servicio, en el

que se va a escuchar.

connectaddress Especifica la dirección IPv4 a la que se va a conectar. Los valores aceptables son
la dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del equipo.
Si no se especifica una dirección, el valor predeterminado es el equipo local.

connectport Especifica el puerto IPv4, por número de puerto o nombre de servicio, al cual
conectarse. Si no se especifica connectport, el valor predeterminado es el valor
de listenport en el equipo local.

listenaddress Especifica la dirección IPv4 a la cual escuchar. Los valores aceptables son la
dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del equipo. Si
no se especifica una dirección, el valor predeterminado es el equipo local.

protocol Especifica el protocolo que se va a usar.

add v4tov6
El servidor proxy de puerto escucha los mensajes enviados a un puerto y una dirección
IPv4 específicos y asigna un puerto y una dirección IPv6 para enviar los mensajes
recibidos después de establecer una conexión TCP independiente.

Sintaxis
PowerShell

add v4tov6 listenport= {Integer | ServiceName} [[connectaddress=]

{IPv6Address | HostName} [[connectport=] {Integer | ServiceName}]
[[listenaddress=] {IPv4Address | HostName} [[protocol=]tcp]

Parámetros

Parámetro Descripción

listenport Especifica el puerto IPv4, por número de puerto o nombre de servicio, en el

que se va a escuchar.

connectaddress Especifica la dirección IPv6 a la que se va a conectar. Los valores aceptables son
la dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del equipo.
Si no se especifica una dirección, el valor predeterminado es el equipo local.
 Parámetro Descripción

connectport Especifica el puerto IPv6, por número de puerto o nombre de servicio, al cual
conectarse. Si no se especifica connectport, el valor predeterminado es el valor
de listenport en el equipo local.

listenaddress Especifica la dirección IPv4 en la cual escuchar. Los valores aceptables son la
dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del equipo. Si
no se especifica una dirección, el valor predeterminado es el equipo local.

protocol Especifica el protocolo que se va a usar.

add v6tov4
El servidor proxy de puerto escucha los mensajes enviados a un puerto y una dirección
IPv6 específicos y asigna un puerto y una dirección IPv4 a la cual enviar los mensajes
recibidos después de establecer una conexión TCP independiente.

Sintaxis
PowerShell

add v6tov4 listenport= {Integer | ServiceName} [[connectaddress=]

{IPv4Address | HostName} [[connectport=] {Integer | ServiceName}]
[[listenaddress=] {IPv6Address | HostName} [[protocol=]tcp]

Parámetros

Parámetro Descripción

listenport Especifica el puerto IPv6, por número de puerto o nombre de servicio, en el

que se va a escuchar.

connectaddress Especifica la dirección IPv4 a la que se va a conectar. Los valores aceptables son
la dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del equipo.
Si no se especifica una dirección, el valor predeterminado es el equipo local.

connectport Especifica el puerto IPv4, por número de puerto o nombre de servicio, al cual
conectarse. Si no se especifica connectport, el valor predeterminado es el valor
de listenport en el equipo local.

listenaddress Especifica la dirección IPv6 a la que se va a escuchar. Los valores aceptables

son la dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del
equipo. Si no se especifica una dirección, el valor predeterminado es el equipo
local.
 Parámetro Descripción

protocol Especifica el protocolo que se va a usar.

add v6tov6
El servidor proxy de puerto escucha los mensajes enviados a un puerto y una dirección
IPv6 específicos y asigna un puerto y una dirección IPv6 a la cual enviar los mensajes
recibidos después de establecer una conexión TCP independiente.

Sintaxis
PowerShell

add v6tov6 listenport= {Integer | ServiceName} [[connectaddress=]

{IPv6Address | HostName} [[connectport=] {Integer | ServiceName}]
[[listenaddress=] {IPv6Address | HostName} [[protocol=]tcp]

Parámetros

Parámetro Descripción

listenport Especifica el puerto IPv6, por número de puerto o nombre de servicio, en el

que se va a escuchar.

connectaddress Especifica la dirección IPv6 a la que se va a conectar. Los valores aceptables son
la dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del equipo.
Si no se especifica una dirección, el valor predeterminado es el equipo local.

connectport Especifica el puerto IPv6, por número de puerto o nombre de servicio, al cual
conectarse. Si no se especifica connectport, el valor predeterminado es el valor
de listenport en el equipo local.

listenaddress Especifica la dirección IPv6 a la que se va a escuchar. Los valores aceptables

son la dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del
equipo. Si no se especifica una dirección, el valor predeterminado es el equipo
local.

protocol Especifica el protocolo que se va a usar.

delete v4tov4
El servidor proxy de puerto elimina una dirección IPv4 de la lista de puertos y
direcciones IPv4 en los que el servidor escucha.

Sintaxis
PowerShell

delete v4tov4 listenport= {Integer | ServiceName} [[listenaddress=]

{IPv4Address | HostName} [[protocol=]tcp]

Parámetros

Parámetro Descripción

listenport Especifica el puerto IPv4 que se va a eliminar.

listenaddress Especifica la dirección IPv4 que se va a eliminar. Si no se especifica una dirección,

el valor predeterminado es el equipo local.

protocol Especifica el protocolo que se va a usar.

delete v4tov6
El servidor proxy de puerto elimina un puerto y una dirección IPv4 de la lista de
direcciones IPv4 en las que el servidor escucha.

Sintaxis
PowerShell

delete v4tov6 listenport= {Integer | ServiceName} [[listenaddress=]

{IPv4Address | HostName} [[protocol=]tcp]

Parámetros

Parámetro Descripción

listenport Especifica el puerto IPv4 que se va a eliminar.

listenaddress Especifica la dirección IPv4 que se va a eliminar. Si no se especifica una dirección,

el valor predeterminado es el equipo local.
 Parámetro Descripción

protocol Especifica el protocolo que se va a usar.

delete v6tov4
El servidor proxy de puerto elimina un puerto y una dirección IPv6 de la lista de
direcciones IPv6 en las que el servidor escucha.

Sintaxis
PowerShell

delete v6tov4 listenport= {Integer | ServiceName} [[listenaddress=]

{IPv6Address | HostName} [[protocol=]tcp]

Parámetros

Parámetro Descripción

listenport Especifica el puerto IPv6 que se va a eliminar.

listenaddress Especifica la dirección IPv6 que se va a eliminar. Si no se especifica una dirección,

el valor predeterminado es el equipo local.

protocol Especifica el protocolo que se va a usar.

delete v6tov6
El servidor proxy de puerto elimina una dirección IPv6 de la lista de direcciones IPv6 en
las que el servidor escucha.

Sintaxis
PowerShell

delete v6tov6 listenport= {Integer | ServiceName} [[listenaddress=]

{IPv6Address | HostName} [[protocol=]tcp]

Parámetros
 Parámetro Descripción

listenport Especifica el puerto IPv6 que se va a eliminar.

listenaddress Especifica la dirección IPv6 que se va a eliminar. Si no se especifica una dirección,

el valor predeterminado es el equipo local.

protocol Especifica el protocolo que se va a usar.

reset-ipv4
Restablece el estado de configuración de IPv4.

Sintaxis
PowerShell

netsh int ipv4 reset

reset-ipv6
Restablece el estado de configuración de IPv6.

Sintaxis
PowerShell

netsh int ipv6 reset

set v4tov4
Modifica los valores de parámetro de una entrada existente en el servidor proxy de
puerto creada con el comando add v4tov4, o agrega una nueva entrada a la lista, que
asigna pares puerto/dirección.

Sintaxis
PowerShell
 set v4tov4 listenport= {Integer | ServiceName} [[connectaddress=]
{IPv4Address | HostName} [[connectport=] {Integer | ServiceName}]
[[listenaddress=] {IPv4Address | HostName} [[protocol=]tcp]

Parámetros

Parámetro Descripción

listenport Especifica el puerto IPv4, por número de puerto o nombre de servicio, en el

que se va a escuchar.

connectaddress Especifica la dirección IPv4 a la que se va a conectar. Los valores aceptables son
la dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del equipo.
Si no se especifica una dirección, el valor predeterminado es el equipo local.

connectport Especifica el puerto IPv4, por número de puerto o nombre de servicio, al cual
conectarse. Si no se especifica connectport, el valor predeterminado es el valor
de listenport en el equipo local.

listenaddress Especifica la dirección IPv4 a la cual escuchar. Los valores aceptables son la
dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del equipo. Si
no se especifica una dirección, el valor predeterminado es el equipo local.

protocol Especifica el protocolo que se va a usar.

set v4tov6
Modifica los valores de parámetro de una entrada existente en el servidor proxy de
puerto creada con el comando add v4tov6, o agrega una nueva entrada a la lista, que
asigna pares puerto/dirección.

Sintaxis
PowerShell

set v4tov6 listenport= {Integer | ServiceName} [[connectaddress=]

{IPv6Address | HostName} [[connectport=] {Integer | ServiceName}]
[[listenaddress=] {IPv4Address | HostName} [[protocol=]tcp]

Parámetros

Parámetro Descripción
 Parámetro Descripción

listenport Especifica el puerto IPv4, por número de puerto o nombre de servicio, en el

que se va a escuchar.

connectaddress Especifica la dirección IPv6 a la que se va a conectar. Los valores aceptables son
la dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del equipo.
Si no se especifica una dirección, el valor predeterminado es el equipo local.

connectport Especifica el puerto IPv6, por número de puerto o nombre de servicio, al cual
conectarse. Si no se especifica connectport, el valor predeterminado es el valor
de listenport en el equipo local.

listenaddress Especifica la dirección IPv4 en la cual escuchar. Los valores aceptables son la
dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del equipo. Si
no se especifica una dirección, el valor predeterminado es el equipo local.

protocol Especifica el protocolo que se va a usar.

set v6tov4
Modifica los valores de parámetro de una entrada existente en el servidor proxy de
puerto creada con el comando add v6tov4, o agrega una nueva entrada a la lista, que
asigna pares puerto/dirección.

Sintaxis
PowerShell

set v6tov4 listenport= {Integer | ServiceName} [[connectaddress=]

{IPv4Address | HostName} [[connectport=] {Integer | ServiceName}]
[[listenaddress=] {IPv6Address | HostName} [[protocol=]tcp]

Parámetros

Parámetro Descripción

listenport Especifica el puerto IPv6, por número de puerto o nombre de servicio, en el

que se va a escuchar.

connectaddress Especifica la dirección IPv4 a la que se va a conectar. Los valores aceptables son
la dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del equipo.
Si no se especifica una dirección, el valor predeterminado es el equipo local.
 Parámetro Descripción

connectport Especifica el puerto IPv4, por número de puerto o nombre de servicio, al cual
conectarse. Si no se especifica connectport, el valor predeterminado es el valor
de listenport en el equipo local.

listenaddress Especifica la dirección IPv6 a la que se va a escuchar. Los valores aceptables

son la dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del
equipo. Si no se especifica una dirección, el valor predeterminado es el equipo
local.

protocol Especifica el protocolo que se va a usar.

set v6tov6
Modifica los valores de parámetro de una entrada existente en el servidor proxy de
puerto creada con el comando add v6tov6, o agrega una nueva entrada a la lista, que
asigna pares puerto/dirección.

Sintaxis
PowerShell

set v6tov6 listenport= {Integer | ServiceName} [[connectaddress=]

{IPv6Address | HostName} [[connectport=] {Integer | ServiceName}]
[[listenaddress=] {IPv6Address | HostName} [[protocol=]tcp]

Parámetros

Parámetro Descripción

listenport Especifica el puerto IPv6, por número de puerto o nombre de servicio, en el

que se va a escuchar.

connectaddress Especifica la dirección IPv6 a la que se va a conectar. Los valores aceptables son
la dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del equipo.
Si no se especifica una dirección, el valor predeterminado es el equipo local.

connectport Especifica el puerto IPv6, por número de puerto o nombre de servicio, al cual
conectarse. Si no se especifica connectport, el valor predeterminado es el valor
de listenport en el equipo local.
 Parámetro Descripción

listenaddress Especifica la dirección IPv6 a la que se va a escuchar. Los valores aceptables

son la dirección IP, el nombre de NetBIOS del equipo o el nombre DNS del
equipo. Si no especificas una dirección, el valor predeterminado es el equipo
local.

protocol Especifica el protocolo que se va a usar.

mostrar todas
Muestra todos los parámetros de proxy de puerto, incluidos los pares de
puerto/dirección para v4tov4, v4tov6, v6tov4 y v6tov6.

Sintaxis
show all

show v4tov4
Muestra los parámetros de proxy de puerto de v4tov4.

Sintaxis
show v4tov4

show v4tov6
Muestra los parámetros de proxy de puerto de v4tov6.

Sintaxis
show v4tov6

show v6tov4
Muestra los parámetros de proxy de puerto de v6tov4.

Sintaxis
show v6tov4

show v6tov6
Muestra los parámetros de proxy de puerto de v6tov6.

Sintaxis
show v6tov6
Comandos netsh mbn
Artículo • 21/12/2022 • Tiempo de lectura: 15 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Usa netsh mbn para consultar y configurar los parámetros y las opciones de banda
ancha móvil.

 Sugerencia

Puedes obtener ayuda sobre el comando de netsh mbn con

netsh mbn /?

Los comandos netsh mbn disponibles son:

add
connect
delete
disconnect
diagnose
dump
help
set
show
test

agregar
Agrega una entrada de configuración a una tabla.

Los comandos netsh mbn add disponibles son:

dmprofile
profile

dmprofile
Agrega un perfil de configuración de DM al almacén de datos de perfil.
Sintaxis

PowerShell

add dmprofile [interface=]<string> [name=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

name Nombre del archivo XML de perfil. Es el nombre del archivo XML que Requerido
contiene los datos del perfil.

Ejemplo

PowerShell

add dmprofile interface="Cellular" name="[Link]"

perfil
Agrega un perfil de red al almacén de datos de perfil.

Sintaxis

PowerShell

add profile [interface=]<string> [name=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

name Nombre del archivo XML de perfil. Es el nombre del archivo XML que Requerido
contiene los datos del perfil.

Ejemplo

PowerShell
 add profile interface="Cellular" name="[Link]"

connect
Se conecta a una red de banda ancha móvil.

Sintaxis

PowerShell

connect [interface=]<string> [connmode=]tmp|name [name=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

connmode Especifica cómo se proporcionan los parámetros de conexión. Puede Requerido

solicitar la conexión mediante un archivo XML de perfil, o con el
nombre de perfil para el archivo XML de perfil que se ha almacenado
previamente en el almacén de datos de perfil de banda ancha móvil
mediante el comando "netsh mbn add profile". En el caso anterior, el
parámetro connmode debe contener "tmp" como valor. Mientras que
en este último caso, será "name".

name Nombre del archivo XML de perfil. Es el nombre del archivo XML que Requerido
contiene los datos del perfil.

Ejemplos

PowerShell

connect interface="Cellular" connmode=tmp name=d:\[Link]

connect interface="Cellular" connmode=name name=MyProfileName

Eliminar
Elimina una entrada de configuración de una tabla.

Los comandos netsh mbn delete disponibles son:

dmprofile
 profile

dmprofile
Elimina un perfil de configuración de DM del almacén de datos de perfil.

Sintaxis

PowerShell

delete dmprofile [interface=]<string> [name=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

name Nombre del archivo XML de perfil. Es el nombre del archivo XML que Requerido
contiene los datos del perfil.

Ejemplo

PowerShell

delete dmprofile interface="Cellular" name="myProfileName"

perfil
Elimina un perfil de red del almacén de datos de perfil.

Sintaxis

PowerShell

delete profile [interface=]<string> [name=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".
 Parámetro Descripción Requisito

name Nombre del archivo XML de perfil. Es el nombre del archivo XML que Requerido
contiene los datos del perfil.

Ejemplo

PowerShell

delete profile interface="Cellular" name="myProfileName"

diagnose
Ejecuta diagnósticos para problemas básicos de telefonía móvil.

Sintaxis

PowerShell

diagnose [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

diagnose interface="Cellular"

desconectar
Se desconecta de una red de banda ancha móvil.

Sintaxis

PowerShell

disconnect [interface=]<string>
Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

disconnect interface="Cellular"

dump
Muestra un script de configuración.

Crea un script que contiene la configuración actual. Si se guarda en un archivo, este

script se puede usar para restaurar la configuración modificada.

Sintaxis

PowerShell

dump

ayuda
Muestra una lista de comandos.

Sintaxis

PowerShell

help

set
Establece la información de configuración.

Los comandos netsh mbn set disponibles son:

acstate
 dataenablement
dataroamcontrol
enterpriseapnparams
highestconncategory
powerstate
profileparameter
slotmapping
tracing

acstate
Establece el estado de conexión automática de datos de banda ancha móvil para la
interfaz especificada.

Sintaxis

PowerShell

set acstate [interface=]<string> [state=]autooff|autoon|manualoff|manualon

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

name El estado de conexión automática que se va a establecer. Uno de los Requerido

siguientes valores:
autooff: Token de conexión automática desactivado.
autoon: Token de conexión automática activado.
manualoff: Token de conexión manual desactivado.
manualon: Token de conexión manual activado.

Ejemplo

PowerShell

set acstate interface="Cellular" state=autoon

dataenablement
Activa o desactiva los datos de banda ancha móvil para el conjunto de perfiles y la
interfaz dados.
Sintaxis

PowerShell

set dataenablement [interface=]<string> [profileset=]internet|mms|all

[mode=]yes|no

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

profileset Nombre del conjunto de perfiles. Requerido

mode Uno de los siguientes valores: Requerido

yes: Habilita el conjunto de perfiles de destino.
no: Deshabilita el conjunto de perfiles de destino.

Ejemplo

PowerShell

set dataenablement interface="Cellular" profileset=mms mode=yes

dataroamcontrol
Establece el estado de control de itinerancia de los datos de banda ancha móvil para el
conjunto de perfiles y la interfaz dados.

Sintaxis

PowerShell

set dataroamcontrol [interface=]<string> [profileset=]internet|mms|all

[state=]none|partner|all

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

profileset Nombre del conjunto de perfiles. Requerido

 Parámetro Descripción Requisito

mode Uno de los siguientes valores: Obligatorio

none: Solo el operador local.
partner: Solo los operadores local y asociados.
all: Los operadores local, asociados y de itinerancia.

Ejemplo

PowerShell

set dataroamcontrol interface="Cellular" profileset=mms mode=partner

enterpriseapnparams
Establece los parámetros de enterpriseAPN de datos de banda ancha móvil para la
interfaz especificada.

Sintaxis

PowerShell

set enterpriseapnparams [interface=]<string> [allowusercontrol=]yes|no|nc

[allowuserview=]yes|no|nc [profileaction=]add|delete|modify|nc

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

allowusercontrol Uno de los siguientes valores: Requerido

yes: Permitir al usuario controlar enterpriseAPN.
no: No permitir al usuario controlar enterpriseAPN.
nc: Sin cambios.

allowuserview Uno de los siguientes valores: Requerido

yes: Permitir al usuario ver enterpriseAPN.
no: No permitir al usuario ver enterpriseAPN.
nc: Sin cambios.
 Parámetro Descripción Requisito

profileaction Uno de los siguientes valores: Requerido

add: Se agrega un perfil de enterpriseAPN.
delete: Se elimina un perfil de enterpriseAPN.
modify: Se modifica un perfil de enterpriseAPN.
nc: Sin cambios.

Ejemplo

PowerShell

set enterpriseapnparams interface="Cellular" profileset=mms mode=yes

highestconncategory
Establece la categoría de conexión más elevada de los datos de banda ancha móvil para
la interfaz especificada.

Sintaxis

PowerShell

set highestconncategory [interface=]<string>

[highestcc=]admim|user|operator|device

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

highestcc Uno de los siguientes valores: Obligatorio

admin: Perfiles aprovisionados por el administrador.
user: Perfiles aprovisionados por el usuario.
operator: Perfiles aprovisionados por el operador.
device: Perfiles aprovisionados por el dispositivo.

Ejemplo

PowerShell

set highestconncategory interface="Cellular" highestcc=operator

powerstate
Activa o desactiva la radio de banda ancha móvil para la interfaz especificada.

Sintaxis

PowerShell

set powerstate [interface=]<string> [state=]on|off

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

state Uno de los siguientes valores: Obligatorio

on: Enciende el transceptor de radio.
off: apague el transceptor de radio.

Ejemplo

PowerShell

set powerstate interface="Cellular" state=on

profileparameter
Establece parámetros en un perfil de red de banda ancha móvil.

Sintaxis

PowerShell

set profileparameter [name=]<string> [[interface=]<string>]

[[cost]=default|unrestricted|fixed|variable]

Parámetros

Parámetro Descripción Requisito

name Nombre del perfil que se va a modificar. Si se especifica la interfaz, solo Requerido
se modifica el perfil de esa interfaz.
 Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Opcional

muestran en el comando "netsh mbn show interfaces".

cost Costo asociado al perfil. Opcional

Observaciones

Se debe especificar al menos un parámetro entre el nombre de la interfaz y el costo.

Ejemplo

PowerShell

set profileparameter name="profile 1" cost=default

slotmapping
Establece la asignación de ranura del módem de banda ancha móvil para la interfaz
especificada.

Sintaxis

PowerShell

set slotmapping [interface=]<string> [slotindex=]<integer>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

slotindex Índice de ranura que se va a establecer. Requerido

Ejemplo

PowerShell

set slotmapping interface="Cellular" slotindex=1

tracing
Habilita o deshabilita el seguimiento.

Sintaxis

PowerShell

set tracing [mode=]yes|no

Parámetros

Parámetro Descripción Requisito

mode Uno de los siguientes valores: Requerido

yes: Habilita el seguimiento para la banda ancha móvil.
no: Deshabilita el seguimiento para la banda ancha móvil.

Ejemplo

PowerShell

set tracing mode=yes

mostrar
Muestra información de red de banda ancha móvil.

Los comandos netsh mbn show disponibles son:

acstate
capability
connection
dataenablement
dataroamcontrol
dmprofiles
enterpriseapnparams
highestconncategory
homeprovider
interfaces
netlteattachinfo
pin
pinlist
preferredproviders
profiles
 profilestate
provisionedcontexts
purpose
radio
readyinfo
signal
slotmapping
slotstatus
smsconfig
tracing
visibleproviders

acstate
Muestra el estado de conexión automática de datos de banda ancha móvil para la
interfaz especificada.

Sintaxis

PowerShell

show acstate [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show acstate interface="Cellular"

capability
Muestra la información de capacidad de la interfaz especificada.

Sintaxis

PowerShell
 show capability [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show capability interface="Cellular"

connection
Muestra la información de conexión actual para la interfaz especificada.

Sintaxis

PowerShell

show connection [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show connection interface="Cellular"

dataenablement
Muestra el estado de habilitación de datos de banda ancha móvil para la interfaz
especificada.
Sintaxis

PowerShell

show dataenablement [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show dataenablement interface="Cellular"

dataroamcontrol
Muestra el estado de control de itinerancia de datos de banda ancha móvil para la
interfaz especificada.

Sintaxis

PowerShell

show dataroamcontrol [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show dataroamcontrol interface="Cellular"

dmprofiles
Muestra una lista de perfiles de configuración de DM configurados en el sistema.

Sintaxis

PowerShell

show dmprofiles [[name=]<string>] [[interface=]<string>]

Parámetros

Parámetro Descripción Requisito

name Nombre del perfil que se mostrará. Opcional

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Opcional

muestran en el comando "netsh mbn show interfaces".

Observaciones

Muestra los datos de perfil o enumera los perfiles del sistema.

Si se indica el nombre del perfil, se mostrará el contenido del perfil. De lo contrario, se

enumerarán los perfiles para la interfaz.

Si se indica el nombre de la interfaz, solo se mostrará el perfil especificado en la interfaz

dada. De lo contrario, se mostrará el primer perfil coincidente.

Ejemplo

PowerShell

show dmprofiles name="profile 1" interface="Cellular"

show dmprofiles name="profile 2"
show dmprofiles

enterpriseapnparams
Muestra los parámetros de enterpriseAPN de datos de banda ancha móvil para la
interfaz especificada.

Sintaxis

PowerShell
 show enterpriseapnparams [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show enterpriseapnparams interface="Cellular"

highestconncategory
Muestra la categoría de conexión más elevada de los datos de banda ancha móvil para
la interfaz especificada.

Sintaxis

PowerShell

show highestconncategory [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show highestconncategory interface="Cellular"

homeprovider
Muestra la información del proveedor principal para la interfaz especificada.
Sintaxis

PowerShell

show homeprovider [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show homeprovider interface="Cellular"

interfaces
Muestra una lista de interfaces de banda ancha móvil en el sistema. No hay parámetros
para este comando.

Sintaxis

PowerShell

show interfaces

netlteattachinfo
Muestra la información de datos adjuntos de LTE de la red de banda ancha móvil para la
interfaz dada.

Sintaxis

PowerShell

show netlteattachinfo [interface=]<string>

Parámetros
 Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show netlteattachinfo interface="Cellular"

pin
Muestra la información de PIN para la interfaz especificada.

Sintaxis

PowerShell

show pin [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show pin interface="Cellular"

pinlist
Muestra la información de la lista de PIN para la interfaz especificada.

Sintaxis

PowerShell

show pinlist [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show pinlist interface="Cellular"

preferredproviders
Muestra la lista de proveedores preferidos para la interfaz especificada.

Sintaxis

PowerShell

show preferredproviders [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show preferredproviders interface="Cellular"

profiles
Muestra una lista de perfiles configurados en el sistema.

Sintaxis

PowerShell
 show profiles [[name=]<string>] [[interface=]<string>] [[purpose=]<string>]

Parámetros

Parámetro Descripción Requisito

name Nombre del perfil que se mostrará. Opcional

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Opcional

muestran en el comando "netsh mbn show interfaces".

purpose Propósito Opcional

Observaciones

Si se indica el nombre del perfil, se mostrará el contenido del perfil. De lo contrario, se

enumerarán los perfiles para la interfaz.

Si se indica el nombre de la interfaz, solo se mostrará el perfil especificado en la interfaz

dada. De lo contrario, se mostrará el primer perfil coincidente.

Si se proporciona el propósito, solo se mostrarán los perfiles con el GUID de propósito

coincidente. De lo contrario, los perfiles no se filtrarán por propósito. La cadena puede
ser un GUID entre llaves o una de las siguientes cadenas: internet, supl, mms, ims o
allhost.

Ejemplo

PowerShell

show profiles interface="Cellular" purpose="{00000000-0000-0000-0000-

000000000000}"
show profiles name="profile 1" interface="Cellular"
show profiles name="profile 2"
show profiles

profilestate
Muestra el estado de un perfil de banda ancha móvil para la interfaz especificada.

Sintaxis

PowerShell

show profilestate [interface=]<string> [name=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

name Nombre del perfil. Es el nombre del perfil que tiene el estado que se va Requerido
a mostrar.

Ejemplo

PowerShell

show profilestate interface="Cellular" name="myProfileName"

provisionedcontexts
Muestra la información de contextos aprovisionados para la interfaz especificada.

Sintaxis

PowerShell

show provisionedcontexts [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show provisionedcontexts interface="Cellular"

purpose
Muestra los GUID del grupo de propósitos que se pueden usar para filtrar los perfiles en
el dispositivo. No hay parámetros para este comando.
Sintaxis

PowerShell

show purpose

radio
Muestra la información de estado de la radio para la interfaz especificada.

Sintaxis

PowerShell

show radio [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show radio interface="Cellular"

readyinfo
Muestra la información de estado listo para la interfaz especificada.

Sintaxis

PowerShell

show readyinfo [interface=]<string>

Parámetros

Parámetro Descripción Requisito

 Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show readyinfo interface="Cellular"

signal
Muestra la información de la señal para la interfaz especificada.

Sintaxis

PowerShell

show signal [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show signal interface="Cellular"

slotmapping
Muestra la asignación de ranura del módem de banda ancha móvil para la interfaz
especificada.

Sintaxis

PowerShell

show slotmapping [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show slotmapping interface="Cellular"

slotstatus
Muestra el estado de ranura del módem de banda ancha móvil para la interfaz
especificada.

Sintaxis

PowerShell

show slotstatus [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show slotstatus interface="Cellular"

smsconfig
Muestra la información de configuración de SMS para la interfaz especificada.

Sintaxis
 PowerShell

show smsconfig [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".

Ejemplo

PowerShell

show smsconfig interface="Cellular"

tracing
Muestra si el seguimiento de banda ancha móvil está habilitado o deshabilitado.

Sintaxis

PowerShell

show tracing

visibleproviders
Muestra la lista de proveedores visibles para la interfaz especificada.

Sintaxis

PowerShell

show visibleproviders [interface=]<string>

Parámetros

Parámetro Descripción Requisito

interface Nombre de la interfaz. Es uno de los nombres de interfaz que se Requerido

muestran en el comando "netsh mbn show interfaces".
Ejemplo

PowerShell

show visibleproviders interface="Cellular"

test
Ejecuta pruebas para un área de características específica mientras se recopilan
registros.

Sintaxis

test [feature=<feature area>] [testPath=<path>] [taefPath=<path>] [param=

<test input params>]

Parámetros

Etiqueta Value ¿Es opcional?

feature Área de características de las admitidas Obligatorio

que se indican a continuación

testpath Ruta de acceso que contiene los archivos Opcional si el servidor HLK está instalado
binarios de prueba

taefpath Ruta de acceso que contiene los archivos Opcional si el servidor HLK está instalado
binarios TAEF

param Parámetros separados por comas que se Requerido para ciertas áreas de
usarán para las pruebas características y opcional para otras

Comentarios:

Las áreas de características admitidas son:

conectividad
potencia
radio
esim
sms
dssa
lte
 bringup

Algunas pruebas requieren parámetros adicionales que se deben proporcionar en el

campo param . A continuación se enumeran los parámetros necesarios para las
características.

connectivity: AccessString, UserName (si corresponde), Password (si corresponde)

radio: AccessString, UserName (si corresponde), Password (si corresponde)
esim: ActivationCode
bringup: AccessString, UserName (si corresponde), Password (si corresponde)

Ejemplos

test feature=connectivity param="AccessString=internet"

test feature=lte testpath="C:\\data\\test\\bin"
taefpath="C:\\data\\test\\bin"
test feature=lte
Ajuste de rendimiento del subsistema
de red
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Puede usar este tema para obtener información general sobre el subsistema de red y
para vínculos a otros temas de esta guía.

７ Nota

Además de este tema, en las secciones siguientes de esta guía se proporcionan

recomendaciones de optimización del rendimiento para dispositivos de red y la pila
de red.

Elección de un adaptador de red

Configurar el orden de las interfaces de red
Adaptadores de red de optimización del rendimiento
Contadores de rendimiento relacionados con la red
Herramientas de rendimiento de las cargas de trabajo de la red

El ajuste del rendimiento del subsistema de red, especialmente para cargas de trabajo
intensivas en red, puede implicar cada capa de la arquitectura de red, que también se
denomina pila de red. Estas capas se dividen ampliamente en las secciones siguientes.

1. Interfaz de red. Esta es la capa más baja de la pila de red y contiene el controlador
de red que se comunica directamente con el adaptador de red.

2. Especificación de interfaz de controlador de red (NDIS). NDIS expone interfaces

para el controlador debajo de él y para las capas situadas encima, como la pila de
protocolos.

3. Pila de protocolos. La pila de protocolos implementa protocolos como TCP/IP y

UDP/IP. Estas capas exponen la interfaz de la capa de transporte para las capas por
encima de ellas.

4. Controladores del sistema. Normalmente, son clientes que usan una extensión de
datos de transporte (TDX) o una interfaz del kernel winsock (WSK) para exponer
 interfaces a aplicaciones en modo de usuario. La interfaz WSK se introdujo en
Windows Server 2008 y Windows ® Vista, y lo expone [Link]. La interfaz mejora
el rendimiento eliminando el cambio entre el modo de usuario y el modo kernel.

5. Aplicaciones en modo de usuario. Normalmente, estas son soluciones de

Microsoft o aplicaciones personalizadas.

En la tabla siguiente se proporciona una ilustración vertical de las capas de la pila de

red, incluidos ejemplos de elementos que se ejecutan en cada capa.
Elección de un adaptador de red
Artículo • 21/12/2022 • Tiempo de lectura: 11 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Puede usar este tema para conocer algunas de las características de los adaptadores de
red que podrían afectar a las opciones de compra.

Las aplicaciones que consumen mucha red requieren adaptadores de red de alto
rendimiento. En esta sección se exploran algunas consideraciones para elegir
adaptadores de red, así como cómo configurar diferentes opciones de adaptador de red
para lograr el mejor rendimiento de red.

 Sugerencia

Puede configurar las opciones del adaptador de red mediante Windows

PowerShell. Para obtener más información, consulte Cmdlets de adaptador de red
en Windows PowerShell.

Funcionalidades de descarga
La descarga de tareas desde la unidad de procesamiento central (CPU) al adaptador de
red puede reducir el uso de CPU en el servidor, lo que mejora el rendimiento general
del sistema.

La pila de red de los productos de Microsoft puede descargar una o varias tareas en un
adaptador de red si selecciona un adaptador de red que tenga las funcionalidades de
descarga adecuadas. En la tabla siguiente se proporciona una breve introducción a las
distintas funcionalidades de descarga que están disponibles en Windows Server 2016.

Tipo de Descripción
descarga

Cálculo de La pila de red puede descargar el cálculo y la validación de sumas de

suma de comprobación del Protocolo de control de transmisión (TCP) en las rutas de
comprobación acceso de envío y recepción de código. También puede descargar el cálculo y la
para TCP validación de sumas de comprobación IPv4 e IPv6 en las rutas de acceso de
envío y recepción de código.
 Tipo de Descripción
descarga

Cálculo de La pila de red puede descargar el cálculo y la validación de sumas de

suma de comprobación del Protocolo de datagramas de usuario (UDP) en las rutas de
comprobación acceso de envío y recepción de código.
para UDP

Cálculo de La pila de red puede descargar el cálculo y la validación de sumas de

suma de comprobación de IPv4 en rutas de acceso de envío y recepción de código.
comprobación
para IPv4

Cálculo de La pila de red puede descargar el cálculo y la validación de sumas de

suma de comprobación IPv6 en rutas de acceso de código de envío y recepción.
comprobación
para IPv6

Segmentación La capa de transporte TCP/IP admite la descarga de envío grande v2 (LSOv2).

de paquetes Con LSOv2, la capa de transporte TCP/IP puede descargar la segmentación de
TCP grandes paquetes TCP grandes al adaptador de red.

Receive Side RSS es una tecnología de controlador de red que permite la distribución eficaz
Scaling (RSS) del procesamiento de recepción de red en varias CPU en sistemas
multiprocesador. Más adelante en este tema se proporciona más información
sobre RSS.

Receive RSC es la capacidad de agrupar paquetes para minimizar el procesamiento de

Segment encabezados necesario para que el host realice. Un máximo de 64 KB de carga
Coalescing recibida se puede fusionar en un único paquete mayor para su procesamiento.
(RSC) Más adelante en este tema se proporciona más información sobre RSC.

Escalado del lado de recepción

Windows Server 2016, Windows Server 2012, Windows Server 2012 R2, Windows Server
2008 R2 y Windows Server 2008 admiten el escalado en lado de recepción (RSS).

Algunos servidores se configuran con varios procesadores lógicos que comparten

recursos de hardware (por ejemplo, un núcleo físico) y que se tratan como pares de
multiproceso simultáneo (SMT). Intel Hyper-Threading Technology es un ejemplo. RSS
dirige el procesamiento de red hasta un procesador lógico por núcleo. Por ejemplo, en
un servidor con Intel Hyper-Threading, 4 núcleos y 8 procesadores lógicos, RSS no usa
más de 4 procesadores lógicos para el procesamiento de red.

RSS distribuye paquetes de E/S de red entrantes entre procesadores lógicos para que
los paquetes que pertenecen a la misma conexión TCP se procesen en el mismo
procesador lógico, que conserva la ordenación.
RSS también equilibra la carga del tráfico de unidifusión UDP y multidifusión, y enruta
los flujos relacionados (que se determinan mediante el hash de las direcciones de origen
y destino) al mismo procesador lógico, conservando el orden de las llegadas
relacionadas. Esto ayuda a mejorar la escalabilidad y el rendimiento de escenarios
intensivos de recepción para servidores que tienen menos adaptadores de red que los
procesadores lógicos aptos.

Configuración de RSS
En Windows Server 2016, puede configurar RSS mediante cmdlets de Windows
PowerShell y perfiles RSS.

Puede definir perfiles RSS mediante el parámetro –Profile del cmdlet Set-
NetAdapterRss Windows PowerShell.

Windows PowerShell comandos para la configuración RSS

Los siguientes cmdlets permiten ver y modificar parámetros RSS por adaptador de red.

７ Nota

Para obtener una referencia detallada de comandos para cada cmdlet, incluida la
sintaxis y los parámetros, puede hacer clic en los vínculos siguientes. Además,
puede pasar el nombre del cmdlet a Get-Help en el símbolo del sistema Windows
PowerShell para obtener detalles sobre cada comando.

Disable-NetAdapterRss. Este comando deshabilita RSS en el adaptador de red que

especifique.

Enable-NetAdapterRss. Este comando habilita RSS en el adaptador de red que

especifique.

Get-NetAdapterRss. Este comando recupera las propiedades RSS del adaptador de

red que especifique.

Set-NetAdapterRss. Este comando establece las propiedades RSS en el adaptador

de red que especifique.

Perfiles RSS

Puede usar el parámetro –Profile del cmdlet Set-NetAdapterRss para especificar qué
procesadores lógicos se asignan al adaptador de red. Los valores disponibles para este
parámetro son:

Más cercano. Se prefieren los números de procesador lógicos que están cerca del
procesador RSS base del adaptador de red. Con este perfil, el sistema operativo
podría reequilibrar los procesadores lógicos dinámicamente en función de la
carga.

Más cercanoStático. Se prefieren los números de procesador lógicos cerca del

procesador RSS base del adaptador de red. Con este perfil, el sistema operativo no
reequilibra los procesadores lógicos dinámicamente en función de la carga.

NUMA. Por lo general, los números de procesador lógicos se seleccionan en

distintos nodos NUMA para distribuir la carga. Con este perfil, el sistema operativo
podría reequilibrar los procesadores lógicos dinámicamente en función de la
carga.

NUMAStatic. Este es el perfil predeterminado. Por lo general, los números de

procesador lógicos se seleccionan en distintos nodos NUMA para distribuir la
carga. Con este perfil, el sistema operativo no reequilibrará los procesadores
lógicos dinámicamente en función de la carga.

Conservador. RSS usa tan pocos procesadores como sea posible para mantener la
carga. Esta opción ayuda a reducir el número de interrupciones.

Según el escenario y las características de la carga de trabajo, también puede usar otros
parámetros del cmdlet Set-NetAdapterRss Windows PowerShell para especificar lo
siguiente:

En función del adaptador de red, cuántos procesadores lógicos se pueden usar

para RSS.
Desplazamiento inicial del intervalo de procesadores lógicos.
Nodo desde el que el adaptador de red asigna memoria.

A continuación se muestran los parámetros Set-NetAdapterRss adicionales que puede

usar para configurar RSS:

７ Nota

En la sintaxis de ejemplo de cada parámetro siguiente, el nombre del adaptador de

red Ethernet se usa como valor de ejemplo para el parámetro –Name del comando
Set-NetAdapterRss . Al ejecutar el cmdlet, asegúrese de que el nombre del
adaptador de red que use sea adecuado para su entorno.
 * MaxProcessors: establece el número máximo de procesadores RSS que se van a
usar. Esto garantiza que el tráfico de la aplicación esté enlazado a un número
máximo de procesadores en una interfaz determinada. Sintaxis de ejemplo:

Set-NetAdapterRss –Name "Ethernet" –MaxProcessors <value>

* BaseProcessorGroup: establece el grupo de procesadores base de un nodo

NUMA. Esto afecta a la matriz de procesadores que usa RSS. Sintaxis de ejemplo:

Set-NetAdapterRss –Name "Ethernet" –BaseProcessorGroup <value>

* MaxProcessorGroup: establece el grupo de procesadores Max de un nodo

NUMA. Esto afecta a la matriz de procesadores que usa RSS. Establecer esto
restringiría un grupo de procesadores máximo para que el equilibrio de carga se
alinee dentro de un grupo k. Sintaxis de ejemplo:

Set-NetAdapterRss –Name "Ethernet" –MaxProcessorGroup <value>

* BaseProcessorNumber: establece el número de procesador base de un nodo

NUMA. Esto afecta a la matriz de procesadores que usa RSS. Esto permite la
creación de particiones de procesadores entre adaptadores de red. Este es el
primer procesador lógico del intervalo de procesadores RSS asignados a cada
adaptador. Sintaxis de ejemplo:

Set-NetAdapterRss –Name "Ethernet" –BaseProcessorNumber <Byte Value>

* NumaNode: nodo NUMA del que cada adaptador de red puede asignar
memoria. Esto puede estar dentro de un grupo k o de grupos k diferentes. Sintaxis
de ejemplo:

Set-NetAdapterRss –Name "Ethernet" –NumaNodeID <value>

* NumberofReceiveQueues: si los procesadores lógicos parecen infrautilizarse

para el tráfico de recepción (por ejemplo, como se ve en el Administrador de
tareas), puede intentar aumentar el número de colas RSS del valor predeterminado
de 2 al máximo admitido por el adaptador de red. El adaptador de red puede tener
opciones para cambiar el número de colas RSS como parte del controlador.
Sintaxis de ejemplo:

Set-NetAdapterRss –Name "Ethernet" –NumberOfReceiveQueues <value>

Para obtener más información, haga clic en el siguiente vínculo para descargar Redes
escalables: eliminando el cuello de botella de procesamiento de recepción: Introducción
a RSS en formato de Word.
Descripción del rendimiento de RSS
La optimización de RSS requiere comprender la configuración y la lógica de equilibrio
de carga. Para comprobar que la configuración rss ha tenido efecto, puede revisar la
salida al ejecutar el cmdlet Get-NetAdapterRss Windows PowerShell. A continuación se
muestra un ejemplo de salida de este cmdlet.

PS C:\Users\Administrator> get-netadapterrss
Name : testnic 2
InterfaceDescription : Broadcom BCM5708C NetXtreme II GigE (NDIS
VBD Client) #66
Enabled : True
NumberOfReceiveQueues : 2
Profile : NUMAStatic
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:15
MaxProcessors : 8

IndirectionTable: [Group:Number]:
0:0 0:4 0:0 0:4 0:0 0:4 0:0 0:4
…
(# indirection table entries are a power of 2 and based on # of processors)
…
0:0 0:4 0:0 0:4 0:0 0:4 0:0
0:4

Además de los parámetros de eco establecidos, el aspecto clave de la salida es la salida

de la tabla de direccionamiento indirecto. La tabla de direccionamiento indirecto
muestra los cubos de tabla hash que se usan para distribuir el tráfico entrante. En este
ejemplo, la notación n:c designa el par de índices Numa K-Group:CPU que se usa para
dirigir el tráfico entrante. Vemos exactamente 2 entradas únicas (0:0 y 0:4), que
representan k-group 0/cpu0 y k-group 0/cpu 4, respectivamente.

Solo hay un grupo k para este sistema (k-group 0) y una entrada de tabla de
direccionamiento indirecto n (donde n <= 128). Dado que el número de colas de
recepción se establece en 2, solo se eligen 2 procesadores (0:0, 0:4), aunque el número
máximo de procesadores esté establecido en 8. En efecto, la tabla de direccionamiento
indirecto está hashando el tráfico entrante para usar solo 2 CPU de los 8 que están
disponibles.

Para utilizar completamente las CPU, el número de colas de recepción RSS debe ser
igual o mayor que Max Processors. En el ejemplo anterior, la cola de recepción debe
establecerse en 8 o superior.
Formación de equipos NIC y RSS
RSS se puede habilitar en un adaptador de red que se asocia con otra tarjeta de interfaz
de red mediante Formación de equipos NIC. En este escenario, solo se puede configurar
el adaptador de red físico subyacente para usar RSS. Un usuario no puede establecer
cmdlets RSS en el adaptador de red en equipo.

Receive Segment Coalescing (RSC)

La fusión de segmentos de recepción (RSC) ayuda al rendimiento al reducir el número
de encabezados IP que se procesan para una cantidad determinada de datos recibidos.
Se debe usar para ayudar a escalar el rendimiento de los datos recibidos agrupando (o
fusionando) los paquetes más pequeños en unidades más grandes.

Este enfoque puede afectar a la latencia con ventajas que se ven principalmente en las
ganancias de rendimiento. Se recomienda RSC para aumentar el rendimiento de las
cargas de trabajo pesadas recibidas. Considere la posibilidad de implementar
adaptadores de red que admitan RSC.

En estos adaptadores de red, asegúrese de que RSC está activado (esta es la

configuración predeterminada), a menos que tenga cargas de trabajo específicas (por
ejemplo, baja latencia, redes de bajo rendimiento) que muestren la ventaja de que RSC
está desactivada.

Descripción de los diagnósticos de RSC

Puede diagnosticar RSC mediante los cmdlets de Windows PowerShell Get-
NetAdapterRsc y Get-NetAdapterStatistics.

A continuación se muestra un ejemplo de salida al ejecutar el cmdlet Get-

NetAdapterRsc.

PS C:\Users\Administrator> Get-NetAdapterRsc

Name IPv4Enabled IPv6Enabled IPv4Operational

IPv6Operational IPv4FailureReason IPv6Failure
Reason
---- ----------- ----------- --------------- ---
------------ ----------------- ------------
Ethernet True False True
False NoFailure NicProperties
El cmdlet Get muestra si RSC está habilitado en la interfaz y si TCP permite que RSC esté
en un estado operativo. El motivo del error proporciona detalles sobre el error al
habilitar RSC en esa interfaz.

En el escenario anterior, IPv4 RSC es compatible y operativo en la interfaz. Para

comprender los errores de diagnóstico, puede ver los bytes o excepciones fusionados
causados. Esto proporciona una indicación de los problemas de fusión.

A continuación se muestra un ejemplo de salida al ejecutar el cmdlet Get-

NetAdapterStatistics.

PS C:\Users\Administrator> $x = Get-NetAdapterStatistics "myAdapter"

PS C:\Users\Administrator> $[Link]

CoalescedBytes : 0
CoalescedPackets : 0
CoalescingEvents : 0
CoalescingExceptions : 0

RSC y Virtualización

RSC solo se admite en el host físico cuando el adaptador de red del host no está
enlazado al conmutador virtual de Hyper-V. RSC está deshabilitado por el sistema
operativo cuando el host está enlazado al conmutador virtual de Hyper-V. Además, las
máquinas virtuales no obtienen la ventaja de RSC porque los adaptadores de red virtual
no admiten RSC.

RSC se puede habilitar para una máquina virtual cuando está habilitada la virtualización
de entrada/salida raíz única (SR-IOV). En este caso, las funciones virtuales admiten la
funcionalidad RSC; por lo tanto, las máquinas virtuales también reciben la ventaja de
RSC.

Recursos del adaptador de red

Algunos adaptadores de red administran activamente sus recursos para lograr un
rendimiento óptimo. Varios adaptadores de red permiten configurar manualmente los
recursos mediante la pestaña Redes avanzadas del adaptador. Para estos adaptadores,
puede establecer los valores de varios parámetros, incluido el número de búferes de
recepción y los búferes de envío.
La configuración de recursos del adaptador de red se simplifica mediante el uso de los
siguientes cmdlets de Windows PowerShell.

Get-NetAdapterAdvancedProperty

Set-NetAdapterAdvancedProperty

Enable-NetAdapter

Enable-NetAdapterBinding

Enable-NetAdapterChecksumOffload

Enable-NetAdapterIPSecOffload

Enable-NetAdapterLso

Enable-NetAdapterPowerManagement

Enable-NetAdapterQos

Enable-NetAdapterRDMA

Enable-NetAdapterSriov

Para obtener más información, consulte Cmdlets de adaptador de red en Windows

PowerShell.

Para obtener vínculos a todos los temas de esta guía, consulte Optimización del
rendimiento del subsistema de red.
Configuración del orden de las
interfaces de red
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En Windows Server 2016 y Windows 10, puede usar la métrica de interfaz para
configurar el orden de las interfaces de red.

Esto es diferente de las versiones anteriores de Windows y Windows Server, que le

permitían configurar el orden de enlace de los adaptadores de red mediante la interfaz
de usuario o los comandos INetCfgComponentBindings::MoveBefore e
INetCfgComponentBindings::MoveAfter. Estos dos métodos para ordenar interfaces de
red no están disponibles en Windows Server 2016 y Windows 10.

En su lugar, puede usar el nuevo método para establecer el orden enumerado de los
adaptadores de red mediante la configuración de la métrica de interfaz de cada
adaptador. Puede configurar la métrica de interfaz mediante el comando Set-
NetIPInterface Windows PowerShell.

Cuando se eligen las rutas de tráfico de red y se ha configurado el parámetro

InterfaceMetric del comando Set-NetIPInterface , la métrica general que se usa para
determinar la preferencia de interfaz es la suma de la métrica de ruta y la métrica de la
interfaz. Normalmente, la métrica de interfaz da preferencia a una interfaz determinada,
como el uso de cable si están disponibles tanto cableadas como inalámbricas.

El siguiente Windows PowerShell ejemplo de comando muestra el uso de este

parámetro.

PowerShell

Set-NetIPInterface -InterfaceIndex 12 -InterfaceMetric 15

El orden en que los adaptadores aparecen en una lista viene determinado por la métrica
de interfaz IPv4 o IPv6. Para obtener más información, vea Función
GetAdaptersAddresses.

Para obtener vínculos a todos los temas de esta guía, consulte Optimización del
rendimiento del subsistema de red.
Ajustar el rendimiento de los
adaptadores de red
Artículo • 21/12/2022 • Tiempo de lectura: 16 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Use la información de este tema para optimizar los adaptadores de red de rendimiento
para equipos que ejecutan Windows Server 2016 versiones posteriores. Si los
adaptadores de red proporcionan opciones de optimización, puede usar estas opciones
para optimizar el rendimiento de la red y el uso de recursos.

La configuración de ajuste correcta para los adaptadores de red depende de las

siguientes variables:

El adaptador de red y su conjunto de características

El tipo de carga de trabajo que realiza el servidor
Los recursos de hardware y software del servidor
Los objetivos de rendimiento para el servidor

En las siguientes secciones se describen algunas de las opciones de ajuste del

rendimiento.

Habilitación de características de descarga

Activar las características de descarga del adaptador de red suele ser beneficioso. Sin
embargo, es posible que el adaptador de red no sea lo suficientemente eficaz como
para controlar las funcionalidades de descarga con alto rendimiento.

） Importante

No use las características de descarga Descarga de tareas de IPsec o Descarga tcp-

descarga. Estas tecnologías están en desuso en Windows Server 2016 y podrían
afectar negativamente al rendimiento del servidor y las redes. Además, es posible
que Microsoft no sea compatible con estas tecnologías en el futuro.

Por ejemplo, considere un adaptador de red que tiene recursos de hardware limitados.
En ese caso, habilitar las características de descarga de segmentación podría reducir el
rendimiento máximo sostenible del adaptador. Sin embargo, si el rendimiento reducido
es aceptable, debe continuar con la habilitación de las características de descarga de
segmentación.

７ Nota

Algunos adaptadores de red requieren que habilite las características de descarga

de forma independiente para las rutas de acceso de envío y recepción.

Habilitación del escalado en el lado de

recepción (RSS) para servidores web
RSS puede mejorar la escalabilidad y el rendimiento web cuando hay menos
adaptadores de red que procesadores lógicos en el servidor. Cuando todo el tráfico web
pasa por los adaptadores de red compatibles con RSS, el servidor puede procesar las
solicitudes web entrantes de diferentes conexiones simultáneamente entre diferentes
CPU.

） Importante

Evite usar adaptadores de red no RSS y adaptadores de red compatibles con RSS
en el mismo servidor. Debido a la lógica de distribución de carga en RSS y el
Protocolo de transferencia de hipertexto (HTTP), el rendimiento podría degradarse
gravemente si un adaptador de red no compatible con RSS acepta tráfico web en
un servidor que tiene uno o varios adaptadores de red compatibles con RSS. En
este caso, debes usar adaptadores de red compatibles con RSS o deshabilitar RSS
en la pestaña Propiedades avanzadas de las propiedades del adaptador de red.

Para determinar si un adaptador de red es compatible con RSS, puedes ver la

información de RSS en la pestaña Propiedades avanzadas de las propiedades del
adaptador de red.

Perfiles RSS y colas RSS

El perfil predefinido de RSS predeterminado es NUMAStatic, que difiere del valor
predeterminado que usaban las versiones anteriores Windows. Antes de empezar a usar
perfiles RSS, revise los perfiles disponibles para saber cuándo son beneficiosos y cómo
se aplican a su entorno de red y hardware.
Por ejemplo, si abre Administrador de tareas y revisa los procesadores lógicos en el
servidor y parecen infrautilizados para el tráfico de recepción, puede intentar aumentar
el número de colas RSS del valor predeterminado de dos al máximo que admite el
adaptador de red. Quizás el adaptador de red tenga opciones para cambiar el número
de colas RSS como parte del controlador.

Aumento de los recursos del adaptador de red

En el caso de los adaptadores de red que permiten configurar manualmente recursos
como búferes de recepción y envío, debe aumentar los recursos asignados.

Algunos adaptadores de red establecen un valor bajo para los búferes de recepción
para conservar la memoria asignada del host. El valor bajo produce la pérdida de
paquetes y un menor rendimiento. Por lo tanto, en escenarios con un alto volumen de
recepción, te recomendamos que aumentes el valor del búfer de recepción al máximo.

７ Nota

Si un adaptador de red no expone la configuración manual de recursos, configura

dinámicamente los recursos o los recursos se establecen en un valor fijo que no se
puede cambiar.

Habilitación de la moderación de interrupciones

Para controlar la moderación de interrupciones, algunos adaptadores de red exponen
diferentes niveles de moderación de interrupciones, distintos parámetros de uso de la
agrupación de búferes (a veces por separado para los búferes de envío y recepción) o
ambos.

Debe considerar la posibilidad de interrumpir la moderación para cargas de trabajo

enlazadas a la CPU. Al usar la moderación de interrupciones, tenga en cuenta el
equilibrio entre el ahorro y la latencia de CPU del host frente al mayor ahorro de CPU
del host debido a más interrupciones y menor latencia. Si el adaptador de red no realiza
la moderación de interrupciones, pero expone la agrupación de búferes, puede mejorar
el rendimiento si aumenta el número de búferes coalesados para permitir más búferes
por envío o recepción.

Optimización del rendimiento para el

procesamiento de paquetes de baja latencia
Muchos adaptadores de red ofrecen opciones para optimizar la latencia inducida por el
sistema operativo. La latencia es el tiempo que transcurre desde que el controlador de
red procesa un paquete de entrada hasta que lo envía de vuelta. Este tiempo suele
medirse en microsegundos. En comparación, el tiempo de transmisión en transmisiones
de paquetes en grandes distancias suele medirse en milisegundos (un orden de
magnitud mayor). Este ajuste no reducirá el tiempo que un paquete está en tránsito.

Las siguientes son algunas sugerencias de ajuste para redes con una sensibilidad de
microsegundos.

Establece el BIOS del equipo en Alto rendimiento, con C-states deshabilitado. Sin
embargo, ten en cuenta que esto depende del BIOS y del sistema, y que algunos
sistemas proporcionarán un rendimiento mayor si el sistema operativo controla la
administración de la energía. Puede comprobar y ajustar la configuración de
administración de energía Configuración o mediante el comando powercfg. Para
obtener más información, vea Powercfg Command-Line Opciones.

Establece el perfil de administración de energía del sistema operativo en Sistema

de alto rendimiento.

７ Nota

Esta configuración no funciona correctamente si el BIOS del sistema se ha

establecido para deshabilitar el control del sistema operativo de la
administración de energía.

Habilite las descargaciones estáticas. Por ejemplo, habilite las configuraciones

Sumas de comprobación UDP, Sumas de comprobación TCP y Enviar descarga
grande (LSO).

Si el tráfico se transmite por secuencias múltiples, por ejemplo, al recibir tráfico de

multidifusión de gran volumen, habilite RSS.

Deshabilita la opción Moderación de interrupciones para los controladores de

tarjetas de red que requieran la menor latencia posible. Recuerde que esta
configuración puede usar más tiempo de CPU y representa un contrasalimiento.

Administra las interrupciones y DPC de los adaptadores de red en un procesador

de núcleo que comparta la memoria caché de la CPU con el núcleo usado por el
programa (subproceso de usuario) que está administrando el paquete. Para ello, se
puede usar el ajuste de la afinidad de la CPU para dirigir un proceso a
determinados procesadores lógicos junto con la configuración de RSS. Cuando se
usa el mismo núcleo para la interrupción, el DPC y el subproceso del modo de
 usuario, el rendimiento es menor porque la carga aumenta debido a que el ISR,
DPC y el subproceso luchan por usar el núcleo.

Interrupciones de la administración del sistema

Muchos sistemas de hardware usan interrupciones de administración del sistema (SMI)
para diversas funciones de mantenimiento, como la generación de informes de errores
de memoria de código de corrección de errores (ECC), el mantenimiento de la
compatibilidad USB heredada, el control del ventilador y la administración de la
configuración de energía controlada por BIOS.

El SMI es la interrupción de prioridad más alta en el sistema y coloca la CPU en un modo

de administración. Este modo adelanta todas las demás actividades mientras SMI
ejecuta una rutina de servicio de interrupción, normalmente contenida en bios.

Desafortunadamente, este comportamiento puede dar lugar a picos de latencia de 100

microsegundos o más.

Si necesitas lograr la menor latencia, debes solicitar a tu proveedor de hardware una

versión del BIOS que reduzca los SMI al mínimo posible. Estas versiones de BIOS se
conocen con frecuencia como "BIOS de baja latencia" o "BIOS sin SMI". En algunos
casos, no es posible que una plataforma de hardware elimine por completo la actividad
de SMI porque se usa para controlar funciones esenciales (por ejemplo, ventiladores de
refrigeración).

７ Nota

El sistema operativo no puede controlar las SMI porque el procesador lógico se

ejecuta en un modo de mantenimiento especial, lo que impide la intervención del
sistema operativo.

OPTIMIZACIÓN DEL RENDIMIENTO TCP

Puede usar los siguientes elementos para optimizar el rendimiento de TCP.

Ajuste automático de la ventana de recepción TCP

En Windows Vista, Windows Server 2008 y versiones posteriores de Windows, la pila de
red de Windows usa una característica denominada nivel de ajuste automático de la
ventana de recepción TCP para negociar el tamaño de la ventana de recepción TCP. Esta
característica puede negociar un tamaño de ventana de recepción definido para cada
comunicación TCP durante el protocolo de enlace TCP.

En versiones anteriores de Windows, la pila de red Windows usaba una ventana de

recepción de tamaño fijo (65 535 bytes) que limitaba el rendimiento potencial general
de las conexiones. El rendimiento total factible de las conexiones TCP podría limitar los
escenarios de uso de red. El ajuste automático de la ventana de recepción TCP permite
que estos escenarios usen completamente la red.

Para una ventana de recepción TCP con un tamaño determinado, puede usar la ecuación
siguiente para calcular el rendimiento total de una sola conexión.

Rendimiento total factible en bytesTamaño de la ventana de recepción TCP en bytes *

(1 / latencia de conexión en segundos)

Por ejemplo, para una conexión que tiene una latencia de 10 ms, el rendimiento total
factible es de solo 51 Mbps. Este valor es razonable para una infraestructura de red
corporativa grande. Sin embargo, mediante el ajuste automático para ajustar la ventana
de recepción, la conexión puede lograr la velocidad de línea completa de una conexión
de 1 Gbps.

Algunas aplicaciones definen el tamaño de la ventana de recepción TCP. Si la aplicación

no define el tamaño de la ventana de recepción, la velocidad del vínculo determina el
tamaño de la siguiente manera:

Menos de 1 megabit por segundo (Mbps): 8 kilobytes (KB)

De 1 Mbps a 100 Mbps: 17 KB
De 100 Mbps a 10 gigabits por segundo (Gbps): 64 KB
10 Gbps o más rápido: 128 KB

Por ejemplo, en un equipo que tenga instalado un adaptador de red de 1 Gbps, el

tamaño de la ventana debe ser de 64 KB.

Esta característica también hace un uso completo de otras características para mejorar el
rendimiento de la red. Estas características incluyen el resto de las opciones tcp
definidas en RFC 1323 . Con estas características, los equipos basados Windows
pueden negociar tamaños de ventana de recepción TCP que son más pequeños, pero
que se escalan en un valor definido, según la configuración. Este comportamiento es
más fácil de controlar para los dispositivos de red.

７ Nota
 Puede experimentar un problema en el que el dispositivo de red no es compatible
con la opción de escalado de ventanas TCP, tal como se define en RFC 1323 y,
por lo tanto, no admite el factor de escala. En tales casos, consulte este kb
934430, Se produce un error en la conectividad de red al intentar usar Windows
Vista detrás de un dispositivo de firewall o ponerse en contacto con el equipo de
soporte técnico del proveedor de dispositivos de red.

Revisión y configuración del nivel de ajuste automático de la

ventana de recepción TCP
Puede usar comandos netsh o cmdlets Windows PowerShell para revisar o modificar el
nivel de ajuste automático de la ventana de recepción TCP.

７ Nota

A diferencia de las versiones de Windows anteriores a Windows 10 o Windows

Server 2019, ya no puede usar el Registro para configurar el tamaño de la ventana
de recepción TCP. Para obtener más información sobre la configuración en desuso,
vea Parámetros TCP en desuso.

７ Nota

Para obtener información detallada sobre los niveles de ajuste automático

disponibles, consulte Niveles de ajuste automático.

Para usar netsh para revisar o modificar el nivel de ajuste automático

Para revisar la configuración actual, abra una ventana del símbolo del sistema y ejecute
el siguiente comando:

cmd

netsh interface tcp show global

La salida de este comando debe ser similar a la siguiente:

Querying active state...

TCP Global Parameters

 -----
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : default
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Initial RTO : 3000
Receive Segment Coalescing State : enabled
Non Sack Rtt Resiliency : disabled
Max SYN Retransmissions : 2
Fast Open : enabled
Fast Open Fallback : enabled
Pacing Profile : off

Para modificar la configuración, ejecute el siguiente comando en el símbolo del sistema:

cmd

netsh interface tcp set global autotuninglevel=<Value>

７ Nota

En el comando anterior, <>< representa el nuevo valor para el nivel de ajuste

automático.

Para obtener más información sobre este comando, vea Comandos Netsh para el
Protocolo de control de transmisión de interfaz.

Para usar PowerShell para revisar o modificar el nivel de ajuste automático

Para revisar la configuración actual, abra una ventana de PowerShell y ejecute el

siguiente cmdlet.

PowerShell

Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal

La salida de este cmdlet debe ser similar a la siguiente.

SettingName AutoTuningLevelLocal
----------- --------------------
Automatic
InternetCustom Normal
DatacenterCustom Normal
 Compat Normal
Datacenter Normal
Internet Normal

Para modificar la configuración, ejecute el siguiente cmdlet en el símbolo del sistema de

PowerShell.

PowerShell

Set-NetTCPSetting -AutoTuningLevelLocal <Value>

７ Nota

En el comando anterior, <>< representa el nuevo valor para el nivel de ajuste

automático.

Para más información sobre estos cmdlets, consulte los siguientes artículos:

Get-NetTCPSetting
Set-NetTCPSetting

Ajuste automático de niveles

Puede establecer el ajuste automático de la ventana de recepción en cualquiera de los
cinco niveles. El nivel predeterminado es Normal. En la tabla siguiente se describen los
niveles.

Nivel Valor Comentarios

hexadecimal

Normal (opción 0x8 (factor de Establezca la ventana de recepción TCP para que crezca para
predeterminada) escala de 8) dar cabida a casi todos los escenarios.

Disabled No hay factor Establezca la ventana de recepción TCP en su valor

de escala predeterminado.
disponible

Restringidos 0x4 (factor de Establezca la ventana de recepción TCP para que crezca más
escala de 4) allá de su valor predeterminado, pero limite ese crecimiento
en algunos escenarios.

Altamente 0x2 (factor de Establezca la ventana de recepción TCP para que crezca más
restringido escala de 2) allá de su valor predeterminado, pero lo hace de forma muy
conservadora.
 Nivel Valor Comentarios
hexadecimal

Habilitación de 0xE (factor de Establezca la ventana de recepción TCP para que crezca para
características escala de 14) dar cabida a escenarios extremos.

Si usa una aplicación para capturar paquetes de red, la aplicación debe notificar datos
similares a los siguientes para diferentes configuraciones de nivel de ajuste automático
de ventana.

Nivel de ajuste automático: Normal (estado predeterminado)

Frame: Number = 492, Captured Frame Length = 66, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-
F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
+ Ipv4: Src = [Link], Dest = [Link], Next Protocol = TCP,
Packet ID = 2667, Total IP Length = 52
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60975, DstPort=Microsoft-
DS(445), PayloadLen=0, Seq=4075590425, Ack=0, Win=64240 ( Negotiating
scale factor 0x8 ) = 64240
SrcPort: 60975
DstPort: Microsoft-DS(445)
SequenceNumber: 4075590425 (0xF2EC9319)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 128 (0x80)
+ Flags: ......S. -----------------------------------------------------
----> SYN Flag set
Window: 64240 ( Negotiating scale factor 0x8 ) = 64240 ---------> TCP
Receive Window set as 64K as per NIC Link bitrate. Note it shows the
0x8 Scale Factor.
Checksum: 0x8182, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 8 ----------------------------->
Scale factor, defined by AutoTuningLevel
+ NoOption:
+ NoOption:
+ SACKPermitted:

Nivel de ajuste automático: Deshabilitado

Frame: Number = 353, Captured Frame Length = 62, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-
F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
+ Ipv4: Src = [Link], Dest = [Link], Next Protocol = TCP,
 Packet ID = 2576, Total IP Length = 48
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60956, DstPort=Microsoft-
DS(445), PayloadLen=0, Seq=2315885330, Ack=0, Win=64240 ( ) = 64240
SrcPort: 60956
DstPort: Microsoft-DS(445)
SequenceNumber: 2315885330 (0x8A099B12)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 112 (0x70)
+ Flags: ......S. -----------------------------------------------------
----> SYN Flag set
Window: 64240 ( ) = 64240 ----------------------------------------> TCP
Receive Window set as 64K as per NIC Link bitrate. Note there is no
Scale Factor defined. In this case, Scale factor is not being sent as a
TCP Option, so it will not be used by Windows.
Checksum: 0x817E, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ NoOption:
+ SACKPermitted:

Nivel de ajuste automático: restringido

Frame: Number = 3, Captured Frame Length = 66, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-
F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
+ Ipv4: Src = [Link], Dest = [Link], Next Protocol = TCP,
Packet ID = 2319, Total IP Length = 52
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60890, DstPort=Microsoft-
DS(445), PayloadLen=0, Seq=1966088568, Ack=0, Win=64240 ( Negotiating
scale factor 0x4 ) = 64240
SrcPort: 60890
DstPort: Microsoft-DS(445)
SequenceNumber: 1966088568 (0x75302178)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 128 (0x80)
+ Flags: ......S. -----------------------------------------------------
----> SYN Flag set
Window: 64240 ( Negotiating scale factor 0x4 ) = 64240 ---------> TCP
Receive Window set as 64K as per NIC Link bitrate. Note it shows the
0x4 Scale Factor.
Checksum: 0x8182, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 4 ------------------------------->
Scale factor, defined by AutoTuningLevel.
+ NoOption:
 + NoOption:
+ SACKPermitted:

Nivel de ajuste automático: altamente restringido

Frame: Number = 115, Captured Frame Length = 66, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-
F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
+ Ipv4: Src = [Link], Dest = [Link], Next Protocol = TCP,
Packet ID = 2388, Total IP Length = 52
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60903, DstPort=Microsoft-
DS(445), PayloadLen=0, Seq=1463725706, Ack=0, Win=64240 ( Negotiating
scale factor 0x2 ) = 64240
SrcPort: 60903
DstPort: Microsoft-DS(445)
SequenceNumber: 1463725706 (0x573EAE8A)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 128 (0x80)
+ Flags: ......S. -----------------------------------------------------
----> SYN Flag set
Window: 64240 ( Negotiating scale factor 0x2 ) = 64240 ---------> TCP
Receive Window set as 64K as per NIC Link bitrate. Note it shows the
0x2 Scale Factor.
Checksum: 0x8182, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 2 ------------------------------>
Scale factor, defined by AutoTuningLevel
+ NoOption:
+ NoOption:
+ SACKPermitted:

Nivel de ajuste automático: Experimental

Frame: Number = 238, Captured Frame Length = 66, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-
F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
+ Ipv4: Src = [Link], Dest = [Link], Next Protocol = TCP,
Packet ID = 2490, Total IP Length = 52
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60933, DstPort=Microsoft-
DS(445), PayloadLen=0, Seq=2095111365, Ack=0, Win=64240 ( Negotiating
scale factor 0xe ) = 64240
SrcPort: 60933
DstPort: Microsoft-DS(445)
SequenceNumber: 2095111365 (0x7CE0DCC5)
AcknowledgementNumber: 0 (0x0)
 + DataOffset: 128 (0x80)
+ Flags: ......S. -----------------------------------------------------
----> SYN Flag set
Window: 64240 ( Negotiating scale factor 0xe ) = 64240 ---------> TCP
Receive Window set as 64K as per NIC Link bitrate. Note it shows the
0xe Scale Factor.
Checksum: 0x8182, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 14 ----------------------------->
Scale factor, defined by AutoTuningLevel
+ NoOption:
+ NoOption:
+ SACKPermitted:

Parámetros TCP en desuso

La siguiente configuración del Registro de Windows Server 2003 ya no se admite y se
omite en versiones posteriores.

TcpWindowSize
NumTcbTablePartitions
MaxHashTableSize

Todas estas configuraciones se encontraban en la siguiente subclave del Registro:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Plataforma de filtrado de Windows

Windows Vista y Windows Server 2008 introdujeron Windows Filtering Platform (WFP).
WFP proporciona API a proveedores de software independientes (ISV) que no son de
Microsoft para crear filtros de procesamiento de paquetes. Algunos ejemplos son
firewall y software antivirus.

７ Nota

Un filtro WFP mal escrito puede reducir significativamente el rendimiento de red de

un servidor. Para obtener más información, vea Porting Packet-Processing Drivers
and Apps to WFP en el Windows Centro de desarrollo.

Para obtener vínculos a todos los temas de esta guía, consulte Optimización del
rendimiento del subsistema de red.
Contadores de rendimiento
relacionados con la red
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En este tema se enumeran los contadores que son pertinentes para administrar el
rendimiento de la red y contiene las secciones siguientes.

Uso de recursos

Posibles problemas de red

Rendimiento de la coalescencia del lado de recepción (RSC)

Uso de recursos
Los siguientes contadores de rendimiento son relevantes para el uso de recursos de red.

IPv4, IPv6

Datagramas recibidos/s

Datagramas enviados/s

TCPv4, TCPv6

Segmentos recibidos por segundo

Segmentos enviados por segundo

Segmentos retransmitido/seg.

Interfaz de red(*), adaptador de red(*)

Bytes recibidos por segundo

Bytes enviados por segundo

Paquetes recibidos por segundo

Paquetes enviados por segundo

 Longitud de la cola de salida

Este contador es la longitud de la cola de paquetes de salida (en paquetes). Si

es mayor que 2, se producen retrasos. Debe encontrar el cuello de botella y
eliminarlo si es posible. Dado que NDIS pone en cola las solicitudes, esta
longitud siempre debe ser 0.

Información del procesador

% de tiempo de procesador

Interrupciones/seg.

DPC en cola/seg.

Este contador es una velocidad media a la que se agregaron DPC a la cola DPC
del procesador lógico. Cada procesador lógico tiene su propia cola DPC. Este
contador mide la velocidad a la que se agregan los DPC a la cola, no el número
de DPC de la cola. Muestra la diferencia entre los valores observados en las dos
últimas muestras, divididos por la duración del intervalo de muestra.

Posibles problemas de red

Los siguientes contadores de rendimiento son pertinentes para posibles problemas de
red.

Interfaz de red(*), adaptador de red(*)

Paquetes recibidos descartados

Paquetes recibidos con errores

Paquetes de salida descartados

Paquetes de salida con errores

WFPv4, WFPv6
Paquetes descartados/s

UDPv4, UDPv6
Errores recibidos de datagramas

TCPv4, TCPv6

Errores de conexión
 Restablecimiento de conexiones

Directiva de QoS de red

Paquetes descartados

Paquetes descartados/s

Actividad de tarjeta de interfaz de red por procesador

Indicaciones de recepción de recursos bajos/s

Paquetes recibidos con pocos recursos/s

Microsoft Winsock BSP

Datagramas eliminados

Datagramas eliminados/s

Conexiones rechazadas

Conexiones rechazadas/s

Rendimiento de la coalescencia del lado de

recepción (RSC)
Los siguientes contadores de rendimiento son relevantes para el rendimiento de RSC.

Adaptador de red (*)

Conexiones RSC activas TCP

Tamaño promedio de paquetes de TCP RSC

Paquetes de TCP RSC coalesced/s

Excepciones de TCP RSC/seg.

Para obtener vínculos a todos los temas de esta guía, consulte Optimización del
rendimiento del subsistema de red.
Herramientas de rendimiento de las
cargas de trabajo de la red
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Puede usar este tema para obtener información sobre las herramientas de rendimiento.

Este tema contiene secciones sobre la herramienta Tráfico de cliente a servidor y El

tamaño de la ventana TCP/IP.

Herramienta de tráfico de cliente a servidor

La herramienta Client to Server Traffic (ctsTraffic) proporciona la capacidad de crear y
comprobar el tráfico de red.

Para obtener más información y descargar la herramienta, vea ctsTraffic (Tráfico de

cliente a servidor).

Tamaño de la ventana TCP/IP

Para los adaptadores de 1 GB, la configuración que se muestra en la tabla anterior debe
proporcionar un buen rendimiento porque NTttcp establece el tamaño de ventana TCP
predeterminado en 64 K a través de una opción de procesador lógico específica
(SO_RCVBUF) para la conexión. Esto proporciona un buen rendimiento en una red de
baja latencia.

En cambio, para redes de alta latencia o para adaptadores de 10 GB, el valor

predeterminado de tamaño de ventana TCP para NTttcp produce un rendimiento
inferior al óptimo. En ambos casos, debe ajustar el tamaño de la ventana TCP para
permitir el producto de retraso de ancho de banda mayor.

Puede establecer estáticamente el tamaño de la ventana TCP en un valor grande

mediante la opción -rb . Esta opción deshabilita el ajuste automático de la ventana TCP
y se recomienda usarlo solo si el usuario entiende completamente el cambio resultante
en el comportamiento de TCP/IP. De forma predeterminada, el tamaño de la ventana
TCP se establece en un valor suficiente y solo se ajusta bajo una carga elevada o a través
de vínculos de alta latencia.
Para más información, consulte Optimización del rendimiento del subsistema de red.
Requisitos de red de host para Azure
Stack HCI
Artículo • 27/01/2023 • Tiempo de lectura: 16 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2

En este tema se describen las consideraciones y los requisitos de redes de host para Azure
Stack HCI. Para información sobre las arquitecturas de los centros de datos y las conexiones
físicas entre servidores, consulte Requisitos de red física.

Para obtener información sobre cómo simplificar las redes de host mediante Network ATC,
consulte Simplificación de las redes de host con Network ATC.

Tipos de tráfico de red

El tráfico de red de Azure Stack HCI se puede clasificar por su finalidad prevista:

Tráfico de administración: Tráfico desde o hacia el clúster local. Por ejemplo, el tráfico
de réplicas de almacenamiento o el tráfico usado por el administrador para la
administración del clúster, como Escritorio remoto, Windows Admin Center, Active
Directory, etc.
Tráfico de proceso: tráfico que se origina en una máquina virtual o se destina a esta.
Tráfico de almacenamiento: Tráfico mediante Bloque de mensajes del servidor (SMB);
por ejemplo, Espacios de almacenamiento directo o migración en vivo basada en
SMB. Este tráfico es el tráfico de nivel 2 y no es enrutable.

） Importante

La réplica de almacenamiento usa tráfico SMB no basado en RDMA. Esto y la

naturaleza direccional del tráfico (vertical de arriba abajo) lo alinean estrechamente
con el de tráfico de "administración" enumerado anteriormente, similar al de un
recurso compartido de archivos tradicional.

Selección de un adaptador de red

Los adaptadores de red se clasifican por los tipos de tráfico de red (consulte más arriba)
con los que se pueden usar. Al revisar el catálogo de Windows Server , la certificación de
Windows Server 2022 ahora indica uno o varios de los siguientes roles. Antes de comprar
un servidor para Azure Stack HCI, debe tener al menos un adaptador clasificado para la
administración, el proceso y el almacenamiento, ya que los tres tipos de tráfico son
necesarios en Azure Stack HCI. Luego, puede usar Network ATC para configurar los
adaptadores para los tipos de tráfico adecuados.

Para más información sobre esta clasificación de NIC basada en roles, consulte este
vínculo .

） Importante

No se admite el uso de un adaptador fuera de su tipo de tráfico clasificado.

Nivel Rol de administración Rol de proceso Rol de almacenamiento

Distinción basada en roles Administración Proceso estándar Almacenamiento estándar

Premio máximo No es aplicable Proceso prémium Almacenamiento prémium

７ Nota

La clasificación más alta de cualquier adaptador de nuestro ecosistema contendrá las

clasificaciones Administración, Proceso prémium y Almacenamiento prémium.

Requisitos para controladores

Los controladores de bandeja de entrada no se admiten con Azure Stack HCI. Para
identificar si el adaptador usa un controlador de bandeja de entrada, ejecute el siguiente
cmdlet. Un adaptador usa un controlador de bandeja de entrada si la propiedad
DriverProvider es Microsoft.

Powershell

Get-NetAdapter -Name <AdapterName> | Select *Driver*

Introducción a las funcionalidades principales del
adaptador de red
Las principales funcionalidades del adaptador de red que aprovecha Azure Stack HCI
incluyen:

Varias colas dinámicas de máquinas virtuales (VMMQ dinámico o [Link])

Acceso directo a memoria remota (RDMA)
RDMA de invitado
Formación de equipos insertada en el conmutador (SET)

VMMQ dinámico
Todos los adaptadores de red con la calificación Compute (Premium) admiten Dynamic
VMMQ. VMMQ dinámico requiere el uso de la funcionalidad Formación de equipos
insertada en el conmutador.

Tipos de tráfico aplicables: proceso

Certificaciones necesarias: Proceso (Premium)

VMMQ dinámico es una tecnología inteligente de la recepción. Se basa en sus

predecesores Virtual machine Queue (VMQ), Ajuste de escala de recepción virtual (vRSS) y
VMMQ, para ofrecer tres mejoras principales:

Optimiza la eficiencia del host con menos núcleos de CPU.

Ajusta automáticamente el procesamiento del tráfico de red a los núcleos de CPU, lo
que permite a las máquinas virtuales cumplir y mantener el rendimiento esperado.
Permite que las cargas de trabajo "en ráfagas" reciban la cantidad esperada de tráfico.

Para más información sobre VMMQ dinámico, consulte la entrada de blog Aceleraciones
sintéticas .

RDMA
RDMA es una descarga de la pila de red en el adaptador de red. Permite que el tráfico de
almacenamiento del bloque de mensajes del servidor omita el sistema operativo en el
procesamiento.

RDMA habilita redes de alto rendimiento y baja latencia al tiempo que usa el mínimo de
recursos de CPU del host. Estos recursos de CPU del host se pueden usar para ejecutar
máquinas virtuales o contenedores adicionales.

Tipos de tráfico aplicables: almacenamiento del host

Certificaciones necesarias: Almacenamiento (estándar)

Todos los adaptadores con calificación storage (Estándar) o Storage (Premium) admiten
RDMA del lado host. Para obtener más información sobre el uso de RDMA con cargas de
trabajo de invitado, consulte la sección "RDMA invitado" más adelante en este artículo.

Azure Stack HCI admite RDMA con las implementaciones del protocolo RDMA de área
extensa de Internet (iWARP) o RDMA a través del protocolo Ethernet convergente (RoCE).

） Importante

Los adaptadores RDMA solo funcionan con otros adaptadores RDMA que
implementan el mismo protocolo RDMA (iWARP o RoCE).

No todos los adaptadores de red de los proveedores admiten RDMA. En la tabla siguiente
se enumeran los proveedores (en orden alfabético) que ofrecen adaptadores RDMA
certificados. Sin embargo, hay proveedores de hardware no incluidos en esta lista que
también admiten RDMA. Consulte el Catálogo de Windows Server para buscar
adaptadores con la calificación Storage (Estándar) o Storage (Premium) que requieren
compatibilidad con RDMA.

７ Nota

InfiniBand (IB) no es compatible con Azure Stack HCI.

Proveedor de NIC iWARP RoCE

Broadcom No Sí

Intel Sí Sí (algunos modelos)

Marvell (Qlogic) Sí Sí

Nvidia No Sí

Para más información sobre la implementación de RDMA para el host, se recomienda

encarecidamente usar Network ATC. Para obtener información sobre la implementación
manual, consulte el repositorio de GitHub de SDN .

iWARP
iWARP usa el Protocolo de control de transmisión (TCP) y se puede mejorar opcionalmente
con el Control de flujo basado en prioridades (PFC) y el Servicio de transmisión mejorada
(ETS).
Use iWARP si:

No tiene experiencia en la administración de redes RDMA.

No administra o no está incómodo administrando los conmutadores de la parte
superior del bastidor (ToR).
No va a administrar la solución después de la implementación.
Ya tiene implementaciones con iWARP.
No está seguro de qué opción elegir.

RoCE

RoCE usa el Protocolo de datagramas de usuario (UDP) y requiere PFC y ETS para
proporcionar confiabilidad.

Use RoCE si:

Ya tiene implementaciones con RoCE en el centro de datos.

Está familiarizado con la administración de los requisitos de red de DCB.

RDMA de invitado
RDMA de invitado permite que las cargas de trabajo de SMB de las máquinas virtuales
disfruten de las mismas ventajas que con el uso de RDMA en los hosts.

Tipos de tráfico aplicables: almacenamiento basado en invitado

Certificaciones necesarias: Proceso (Premium)

Las principales ventajas de usar RDMA de invitado son:

Descarga del procesamiento del tráfico de red de la CPU a la NIC.

Latencia extremadamente baja.
Capacidad de proceso elevada.

Para más información, descargue el documento del repositorio de GitHub de SDN .

SET
SET es una tecnología de formación de equipos basada en software que se ha incluido en
el sistema operativo Windows Server desde Windows Server 2016. SET requiere un
adaptador compute (Estándar) o Compute (Premium).

Tipos de tráfico aplicables: proceso, almacenamiento y administración

Certificaciones necesarias: Proceso (estándar) o proceso (Premium)

SET es la única tecnología de formación de equipos admitida por Azure Stack HCI. SET
funciona bien con el tráfico de proceso, almacenamiento y administración.

） Importante

Azure Stack HCI no admite la formación de equipos NIC con el equilibrio de carga o la
conmutación por error (LBFO) más antiguos. Consulte la entrada de blog Formación
de equipos en Azure Stack HCI para más información sobre LBFO en Azure Stack
HCI.

SET es importante para Azure Stack HCI, ya que es la única tecnología de formación de
equipos que permite:

La formación de equipos de adaptadores RDMA (si es necesario).

RDMA de invitado.
VMMQ dinámico.
Otras características principales de Azure Stack HCI (consulte Formación de equipos
en Azure Stack HCI ).

SET requiere el uso de adaptadores simétricos (idénticos). Los adaptadores de red

simétricos son los que tienen los mismos valores de:

marca (proveedor)
modelo (versión)
velocidad (rendimiento)
configuración

En 22H2, Network ATC detectará e informará automáticamente si los adaptadores que ha

elegido son asimétricos. La manera más fácil de identificar manualmente si los adaptadores
son simétricos es si las velocidades y las descripciones de la interfaz son coincidencias
exactas . Solo se admite una diferencia en el número que aparece en la descripción. Use el
cmdlet Get-NetAdapterAdvancedProperty para asegurarse de que la configuración que se
indica muestra los mismos valores de propiedad.

Consulte la tabla siguiente para obtener un ejemplo de las descripciones de interfaz que
solo se diferencian el número (#):

Nombre Descripción de la interfaz Velocidad del vínculo

NIC1 Network Adapter #1 25 Gbps

NIC2 Network Adapter #2 25 Gbps

NIC3 Network Adapter #3 25 Gbps

 Nombre Descripción de la interfaz Velocidad del vínculo

NIC4 Network Adapter #4 25 Gbps

７ Nota

SET solo admite la configuración independiente del conmutador mediante algoritmos

de equilibrio de carga de puerto dinámico o de Hyper-V. Para el mejor rendimiento, se
recomienda usar el puerto de Hyper-V en todas las NIC que funcionan a 10 Gbps o
más. Network ATC realiza todas las configuraciones necesarias para SET.

Consideraciones sobre el tráfico RDMA

Si implementa DCB, debe asegurarse de que la configuración de PFC y ETS se implementa
correctamente en todos los puertos de red, incluidos los conmutadores de red. DCB es
obligatorio para RoCE y opcional para iWARP.

Para información detallada sobre cómo implementar RDMA, descargue el documento del
repositorio de GitHub de SDN .

Las implementaciones de Azure Stack HCI basadas en RoCE requieren la configuración de

tres clases de tráfico PFC, incluida la clase de tráfico predeterminada, en el tejido y en
todos los hosts.

Clase de tráfico del clúster

Esta clase de tráfico garantiza que haya suficiente ancho de banda reservado para los
latidos de clúster:

Requerido: sí
PFC habilitado: no
Prioridad de tráfico recomendada: Prioridad 7
Reserva de ancho de banda recomendada:
Redes RDMA de 10 GbE o menos = 2 %
Redes RDMA de 25 GbE o más = 1 %

Clase de tráfico RDMA

Esta clase de tráfico garantiza que haya suficiente ancho de banda reservado para las
comunicaciones de RDA sin pérdida mediante el bloque de mensajes del servidor directo:

Requerido: sí
 PFC habilitado: sí
Prioridad de tráfico recomendada: Prioridad 3 o 4
Reserva de ancho de banda recomendada: 50 %

Clase de tráfico predeterminada

Esta clase de tráfico incluye el resto del tráfico no definido en el clúster o las clases de
tráfico RDMA, incluido el tráfico de las máquinas virtuales y el tráfico de administración:

Requerido: predeterminado (no se necesita ninguna configuración en el host)

Control de flujo (PFC) habilitado: no
Clase de tráfico recomendada: predeterminada (Prioridad 0)
Reserva de ancho de banda recomendada: predeterminada (no se requiere
configuración del host)

Modelos de tráfico de almacenamiento

El bloque de mensajes del servidor ofrece muchas ventajas como protocolo de
almacenamiento para Azure Stack HCI, incluido SMB multicanal. SMB multicanal no se
abarca en este artículo, pero es importante comprender que el tráfico se multiplexa en cada
vínculo posible que pueda usar SMB multicanal.

７ Nota

Se recomienda usar varias subredes y VLAN para separar el tráfico de almacenamiento

en Azure Stack HCI.

Considere el ejemplo siguiente de un clúster de cuatro nodos. Cada servidor tiene dos
puertos de almacenamiento (lado izquierdo y derecho). Dado que cada adaptador se
encuentra en la misma subred y VLAN, SMB multicanal distribuirá las conexiones entre
todos los vínculos disponibles. Por lo tanto, el puerto del lado izquierdo del primer servidor
([Link]) establecerá una conexión con el puerto del lado izquierdo del segundo
servidor ([Link]). El puerto del lado derecho del primer servidor ([Link]) se
conectará al puerto del lado derecho del segundo servidor. Se establecen conexiones
similares para el tercer y cuarto servidor.

Sin embargo, esto crea conexiones innecesarias y produce congestión en el vínculo interno
(grupo de agregación de vínculos de varios chasis o MC-LAG) que conecta los
conmutadores ToR (marcados con X). Observe el diagrama siguiente:
 

El enfoque recomendado es usar subredes y VLAN independientes para cada conjunto de

adaptadores. En el diagrama siguiente, los puertos de la derecha ahora usan la subred
192.168.2.x/24 y la VLAN2. Esto permite que el tráfico de los puertos de la izquierda
permanezca en TOR1 y que el tráfico de los puertos del lado derecho permanezca en TOR2.
 

Asignación de ancho de banda para el tráfico

En la tabla siguiente se muestran asignaciones de ancho de banda de ejemplo de varios
tipos de tráfico, con velocidades de adaptador comunes, en Azure Stack HCI. Tenga en
cuenta que se trata de un ejemplo de una solución convergente en la que todos los tipos de
tráfico (proceso, almacenamiento y administración) se ejecutan en los mismos adaptadores
físicos y la formación de equipos se realiza mediante SET.

Dado que este caso de uso supone la mayoría de las restricciones, representa una buena
base de referencia. Sin embargo, si se tienen en cuenta las permutaciones de número de
adaptadores y velocidades, se debe considerar un ejemplo y no un requisito auxiliar.

En este ejemplo se realizan las suposiciones siguientes:

Hay dos adaptadores por equipo.

Tráfico de Capa de bus de almacenamiento (SBL), Volumen compartido de clúster

(CSV) e Hyper-V (Migración en vivo):
Se usan los mismos adaptadores físicos.
 Se usa el bloque de mensajes del servidor.

El bloque de mensajes del servidor tiene una asignación de ancho de banda del 50 %
mediante DCB.
El tráfico de SBL y CSV es el tráfico de prioridad más alta y recibe el 70 % de la
reserva de ancho de banda de SMB.
La migración en vivo (LM) está limitada mediante el cmdlet Set-SMBBandwidthLimit
y recibe el 29 % del ancho de banda restante.

Si el ancho de banda disponible para la migración en vivo es mayor o igual a

5 Gbps y los adaptadores de red son compatibles, use RDMA. Para ello, use el
siguiente cmdlet:

Powershell

Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

Si el ancho de banda disponible para la migración en vivo es menor que 5 Gbps,

use la compresión para reducir los tiempos sin disponibilidad. Para ello, use el
siguiente cmdlet:

Powershell

Set-VMHost -VirtualMachineMigrationPerformanceOption Compression

Si usa RDMA con tráfico de migración en vivo, asegúrese de que este tráfico no
consume todo el ancho de banda asignado a la clase de tráfico RDMA mediante un
límite de ancho de banda de bloque de mensajes del servidor. Preste atención, ya que
este cmdlet toma la entrada en bytes por segundo (Bps), mientras que los
adaptadores de red se muestran en bits por segundo (bps). Por ejemplo, use el
siguiente cmdlet para establecer un límite de ancho de banda de 6 Gbps:

Powershell

Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB

７ Nota

En este ejemplo, 750 MBps equivalen a 6 Gbps.

Esta es la tabla de asignación de ancho de banda de ejemplo:

 Velocidad Ancho de Reserva SBL/CSV Ancho % para Ancho de % Ancho
de NIC banda de % de banda Migración banda para de banda
agrupado ancho de en vivo máximo latidos para
de SBL/CSV para la latidos
banda migración
para en vivo
SMB**

10 Gbps 20 Gbps 10 Gbps 70% 7 Gbps ** 200 Mbps

25 Gbps 50 Gbps 25 Gbps 70% 17,5 Gbps 29% 7,25 Gbps 1% 250 MBps

40 Gbps 80 Gbps 40 Gbps 70% 28 Gbps 29% 11,6 Gbps 1% 400 MBps

50 Gbps 100 Gbps 50 Gbps 70% 35 Gbps 29% 14,5 Gbps 1% 500 Mbps

100 Gbps 200 Gbps 100 Gbps 70% 70 Gbps 29% 29 Gbps 1% 1 Gbps

200 Gbps 400 Gbps 200 Gbps 70% 140 Gbps 29% 58 Gbps 1% 2 Gbps

* Se debe usar compresión en lugar de RDMA, ya que la asignación de ancho de banda

para el tráfico de migración en vivo es menor que 5 Gbps.

** El 50 % es una reserva de ancho de banda de ejemplo.

Clústeres extendidos
Los clústeres extendidos proporcionan recuperación ante desastres que abarca varios
centros de datos. En su forma más sencilla, una red de clústeres extendidos de Azure Stack
HCI tiene el siguiente aspecto:


Requisitos de clúster extendido
Los clústeres extendidos tienen los siguientes requisitos y características:

RDMA está limitado a un único sitio y no se admite entre diferentes sitios o subredes.

Los servidores del mismo sitio deben residir en el mismo bastidor y en el mismo límite
de capa 2.

La comunicación de host entre sitios tiene que atravesar un límite de capa 3; no se

admiten las topologías de capa 2 extendidas.

Tener suficiente ancho de banda para ejecutar las cargas de trabajo en el otro sitio. En
caso de conmutación por error, el sitio alternativo tendrá que ejecutar todo el tráfico.
Se recomienda aprovisionar los sitios al 50 % de su capacidad de red disponible. Esto
no es un requisito si se puede tolerar un rendimiento menor durante una
conmutación por error.

La replicación entre sitios (tráfico vertical de arriba abajo) puede usar las mismas NIC
físicas que el almacenamiento local (tráfico horizontal de derecha a izquierda). Si se
usan los mismos adaptadores físicos, estos adaptadores deben estar en equipo con
SET. Los adaptadores también deben tener NIC virtuales adicionales aprovisionadas
para el tráfico enrutable entre sitios.

Los adaptadores usados para la comunicación entre sitios:

Pueden ser físicos o virtuales (vNIC de host). Si los adaptadores son virtuales, debe
aprovisionar una NIC virtual en su propia subred y VLAN por cada NIC física.

Deben estar en su propia subred y VLAN, que pueden enrutar entre sitios.

Se debe deshabilitar RDMA mediante el cmdlet Disable-NetAdapterRDMA . Se

recomienda requerir explícitamente que la réplica de almacenamiento use
interfaces específicas con el cmdlet Set-SRNetworkConstraint .

Debe cumplir los requisitos adicionales para la réplica de almacenamiento.

Ejemplo de clúster extendido

En el ejemplo siguiente se muestra una configuración de clúster extendido. Para asegurarse
de que una NIC virtual específica esté asignada a un adaptador físico específico, use el
cmdlet Set-VMNetworkAdapterTeammapping.
 

A continuación se muestran los detalles de la configuración de clúster extendido de

ejemplo.

７ Nota

La configuración exacta, incluidos los nombres de NIC, las direcciones IP y VLAN,

puede diferir de lo que se muestra. Esto se usa solo como configuración de referencia
y se adapta al entorno.

SitioA: replicación local, RDMA habilitado, no enrutable entre sitios.

nombre del Nombre de NIC NIC física VLAN IP y subred Ámbito del
nodo virtual (asignada) tráfico

NodeA1 vSMB01 pNIC01 711 [Link]/24 Solo sitio

local

NodeA2 vSMB01 pNIC01 711 [Link]/24 Solo sitio

local
 nombre del Nombre de NIC NIC física VLAN IP y subred Ámbito del
nodo virtual (asignada) tráfico

NodeA1 vSMB02 pNIC02 712 [Link]/24 Solo sitio

local

NodeA2 vSMB02 pNIC02 712 [Link]/24 Solo sitio

local

SitioB: replicación local, RDMA habilitado, no enrutable entre sitios.

nombre del Nombre de NIC NIC física VLAN IP y subred Ámbito del
nodo virtual (asignada) tráfico

NodeB1 vSMB01 pNIC01 711 [Link]/24 Solo sitio

local

NodeB2 vSMB01 pNIC01 711 [Link]/24 Solo sitio

local

NodeB1 vSMB02 pNIC02 712 [Link]/24 Solo sitio

local

NodeB2 vSMB02 pNIC02 712 [Link]/24 Solo sitio

local

SitioA: replicación extendida, RDMA deshabilitado, enrutable entre

sitios.

nombre del Nombre de NIC NIC física IP y Ámbito del tráfico

nodo virtual (asignada) subred

NodeA1 Stretch1 pNIC01 [Link]/8 Enrutable entre

sitios

NodeA2 Stretch1 pNIC01 [Link]/8 Enrutable entre

sitios

NodeA1 Stretch2 pNIC02 [Link]/8 Enrutable entre

sitios

NodeA2 Stretch2 pNIC02 [Link]/8 Enrutable entre

sitios

SitioB: replicación extendida, RDMA deshabilitado, enrutable entre

sitios
nombre del Nombre de NIC NIC física IP y Ámbito del tráfico
nodo virtual (asignada) subred

NodeB1 Stretch1 pNIC01 [Link]/8 Enrutable entre

sitios

NodeB2 Stretch1 pNIC01 [Link]/8 Enrutable entre

sitios

NodeB1 Stretch2 pNIC02 [Link]/8 Enrutable entre

sitios

NodeB2 Stretch2 pNIC02 [Link]/8 Enrutable entre

sitios

Pasos siguientes
Obtenga información acerca de los requisitos del conmutador de red y de la red física.
Consulte Requisitos de red física para Azure Stack HCI.
Obtenga información sobre cómo simplificar las redes de host mediante Network
ATC. Consulte Simplificación de las redes de host con Network ATC.
Consulte Aspectos básicos de las redes de clústeres de conmutación por error .
Para la implementación, consulte Creación de un clúster de Azure Stack HCI mediante
Windows Admin Center.
Para la implementación, consulte Creación de un clúster de Azure Stack HCI mediante
Windows PowerShell.
Supervisión de paquetes (Pktmon)
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows 10, Azure Stack
Hub, Azure, Azure Stack HCI, versiones 21H2 y 20H2

El Monitor de paquetes (Pktmon) es una herramienta de diagnóstico de red integrada

entre componentes para Windows. Se puede usar para la captura de paquetes, la
detección de colocación de paquetes, el filtrado de paquetes y el recuento. La
herramienta es especialmente útil en escenarios de virtualización, como redes de
contenedor y SDN, ya que proporciona visibilidad dentro de la pila de redes. Está
disponible en la caja a través del comando [Link] y a través de extensiones de
Windows Admin Center.

Información general
Cualquier máquina que se comunique a través de la red tiene al menos un adaptador de
red. Todos los componentes entre este adaptador y una aplicación forman una pila de
redes: un conjunto de componentes de red que procesan y mueven el tráfico de red. En
escenarios tradicionales, la pila de redes es pequeña y todo el enrutamiento y cambio
de paquetes se produce en dispositivos externos.

Sin embargo, con la llegada de la virtualización de red, se ha multiplicado el tamaño de

la pila de redes. Esta pila de red extendida ahora incluye componentes como el
conmutador virtual que controla el procesamiento y la conmutación de paquetes. Este
entorno flexible permite un uso de recursos mucho mejor y aislamiento de seguridad,
pero también deja más espacio para los errores de configuración que pueden ser
difíciles de diagnosticar. El Monitor de paquetes proporciona la visibilidad mejorada
dentro de la pila de redes que a menudo se necesita para identificar estos errores.
El Monitor de paquetes intercepta los paquetes en varias ubicaciones en toda la pila de
redes, exponiendo la ruta de paquetes. Si un componente compatible de la pila de redes
quitó un paquete, el Monitor de paquetes notificará esa eliminación de paquetes. Esto
permite a los usuarios diferenciar entre un componente que es el destino previsto para
un paquete y un componente que interfiere con un paquete. Además, el Monitor de
paquetes notificará las razones de caída; por ejemplo, error de coincidencia de MTU o
VLAN filtrado, etc. Estas razones de caída proporcionan la causa principal del problema
sin necesidad de agotar todas las posibilidades. El Monitor de paquetes también
proporciona contadores de paquetes para cada punto de interceptación, lo que permite
un examen de flujo de paquetes de alto nivel sin necesidad de realizar análisis de
registros que consumen mucho tiempo.
Prácticas recomendadas
Use estos procedimientos recomendados para simplificar el análisis de red.

Compruebe la ayuda de la línea de comandos en busca de argumentos y

funcionalidades (por ejemplo, pktmon start help).
Configure filtros de paquetes que coincidan con su escenario (pktmon filter add).
Compruebe los contadores de paquetes durante el experimento para ver los
contadores de alto nivel (contadores pktmon).
Examine el registro para obtener un análisis detallado (formato pktmon
[Link]).

Funcionalidad
El Monitor de paquetes ofrece la siguiente funcionalidad:

Supervisión y recuento de paquetes en varias ubicaciones a lo largo de la pila de

redes
Detección de caídas de paquetes en varias ubicaciones de pila
Filtrado flexible de paquetes en tiempo de ejecución con compatibilidad con
encapsulación
Compatibilidad general de registro y seguimiento (eventos ETW y WPP)
Análisis de registros TXT basado en el análisis de paquetes TcpDump
 Varios modos de registro: en tiempo real, gran volumen en memoria, varios
archivos, circulares
Compatibilidad con el tipo de medio de banda ancha móvil, Wi-Fi y Ethernet
Compatibilidad con formato PCAPNG

Comenzar con el Monitor de paquetes

Los siguientes recursos están disponibles para ayudarle a empezar a usar el Monitor de
paquetes.

Sintaxis y formato del comando Pktmon

El Monitor de paquetes está disponible en la caja a través de [Link] comando en
vibranium OS (compilación 19041). Puede usar este tema para aprender a comprender
la sintaxis pktmon, los comandos, el formato y la salida.

Extensión de la supervisión de paquetes en Windows

Admin Center
La extensión de supervisión de paquetes le permite operar y consumir el Monitor de
paquetes a través de Windows Admin Center. La extensión le ayuda a diagnosticar la red
mediante la captura y visualización del tráfico de red a través de la pila de redes en un
registro que es fácil de seguir y manipular. Puede usar este tema para aprender a operar
la herramienta y comprender su salida.

Extensión de diagnóstico de ruta de acceso de datos de

SDN en Windows Admin Center
SdN Data Path Diagnostics es una herramienta dentro de la extensión de supervisión de
SDN de Windows Admin Center. La herramienta automatiza las capturas de paquetes
basadas en el Monitor de paquetes según varios escenarios de SDN y presenta la salida
en una sola vista que es fácil de seguir y manipular. Puede usar este tema para aprender
a operar la herramienta y comprender su salida.

Soporte técnico del Monitor de red de Microsoft

(Netmon)
El Monitor de paquetes genera registros en formato ETL. Estos registros se pueden
analizar mediante Microsoft Network Monitor (Netmon) mediante analizadores
especiales. En este tema se explica cómo analizar los archivos ETL generados por el
Monitor de paquetes en Netmon.

Soporte técnico de Wireshark (formato pcapng)

El Monitor de paquetes puede convertir registros en formato pcapng. Estos registros se
pueden analizar mediante Wireshark (o cualquier analizador de pcapng). En este tema
se explica el resultado esperado y cómo aprovecharlo.

Proporcionar comentarios al equipo de

ingeniería
Informe de los errores o envíe comentarios a través del centro de opiniones mediante
los pasos siguientes:

1. Inicie el Centro de opiniones a través del menú Inicio .

2. Seleccione el botón Notificar un problema o el botón Sugerir una característica .

3. Proporcione un título de comentarios significativo en el cuadro Resumir el

problema .

4. Proporcione detalles y pasos para reproducir el problema en el cuadro

Proporcionar más detalles .

5. Seleccione Red e Internet como la categoría superior y, a continuación, Monitor

de paquetes ([Link]) como sub categoría.

6. Para ayudarnos a identificar y corregir el error más rápido, capture capturas de

pantalla, adjunte el registro de salida de pktmon o vuelva a crear el problema.

7. Haga clic en Enviar.

Después de enviar los comentarios o errores, el equipo de ingeniería podrá echar un

vistazo a los comentarios y abordarlos.
Formato de comandos Pktmon
Artículo • 21/12/2022 • Tiempo de lectura: 11 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows 10, Azure Stack
Hub, Azure, Azure Stack HCI, versiones 21H2 y 20H2

El Monitor de paquetes (Pktmon) es una herramienta de diagnóstico de red integrada

entre componentes para Windows. Se puede usar para la captura de paquetes, la
detección de caídas de paquetes, el filtrado de paquetes y el recuento. La herramienta
es especialmente útil en escenarios de virtualización, como redes de contenedor y SDN,
ya que proporciona visibilidad dentro de la pila de redes. El Monitor de paquetes está
disponible en caja a través de [Link] comando en Windows 10 y Windows Server
2019 (versión 1809 y posteriores). Puede usar este tema para aprender a comprender la
sintaxis pktmon, el formato de comandos y la salida. Para obtener una lista completa de
los comandos, consulte sintaxis pktmon.

Inicio rápido
Siga estos pasos para empezar a trabajar en escenarios genéricos:

1. Identifique el tipo de paquetes necesarios para la captura, como direcciones IP,

puertos o protocolos específicos asociados al paquete.

2. Compruebe la sintaxis para aplicar filtros de captura y aplique los filtros de los
paquetes identificados en el paso anterior.

PowerShell

C:\Test> pktmon filter add help

C:\Test> pktmon filter add <filters>

3. Inicie la captura y habilite el registro de paquetes.

PowerShell

C:\Test> pktmon start -c

4. Reproduzca el problema que se está diagnosticando. Contadores de consulta para

confirmar la presencia del tráfico esperado y para obtener una vista de alto nivel
de cómo fluye el tráfico en la máquina.
 PowerShell

C:\Test> pktmon counters

5. Detenga la captura y recupere los registros en formato txt para su análisis.

PowerShell

C:\Test> pktmon stop

C:\Test> pktmon etl2txt <etl file>

Consulte Analizar salida del Monitor de paquetes para obtener instrucciones sobre
cómo analizar la salida txt.

Capturar filtros
Se recomienda encarecidamente aplicar filtros antes de iniciar cualquier captura de
paquetes, ya que la solución de problemas de conectividad a un destino determinado es
más fácil cuando se centra en una única secuencia de paquetes. Capturar todo el tráfico
de red puede hacer que la salida sea demasiado ruidosa para analizar. Para que se
notifique un paquete, debe coincidir con todas las condiciones especificadas en al
menos un filtro. Se admiten hasta 32 filtros a la vez.

Por ejemplo, el siguiente conjunto de filtros capturará cualquier tráfico ICMP de o a la

dirección IP [Link], así como cualquier tráfico en el puerto 53.

PowerShell

C:\Test> pktmon filter add -i [Link] -t icmp

C:\Test> pktmon filter add -p 53

Funcionalidad de filtrado
El Monitor de paquetes admite el filtrado por direcciones MAC, direcciones IP,
puertos, EtherType, protocolo de transporte e id. de VLAN.

El Monitor de paquetes no distinguirá entre el origen o el destino cuando se trata

de direcciones MAC, direcciones IP o filtros de puerto.

Para filtrar aún más los paquetes TCP, se puede proporcionar una lista opcional de
marcas TCP para que coincidan. Las marcas admitidas son FIN, SYN, RST, PSH, ACK,
URG, ECE y CWR.
 Por ejemplo, el siguiente filtro capturará todos los paquetes SYN enviados o
recibidos por la dirección IP [Link]:

PowerShell

C:\Test> pktmon filter add -i [Link] -t tcp syn

El Monitor de paquetes puede aplicar un filtro a los paquetes internos

encapsulados, además del paquete externo si se agregó la marca [-e] a cualquier
filtro. Los métodos de encapsulación admitidos son VXLAN, GRE, NVGRE e IP en IP.
El puerto VXLAN personalizado es opcional y el valor predeterminado es 4789.

Para más información, consulte sintaxis de filtro pktmon.

Captura de paquetes y eventos generales

El Monitor de paquetes puede capturar paquetes a través del parámetro [-c] con el
comando start. Esto habilitará la captura y el registro de paquetes, así como los
contadores de paquetes. Para habilitar los contadores de paquetes solo sin registrar el
paquete, agregue el parámetro [-o] al comando start. Para obtener más información
sobre los contadores de paquetes, consulte la sección Contadores de paquetes a
continuación.

Puede seleccionar componentes para supervisar a través del parámetro [--comp]. Solo
puede ser NIC o una lista de identificadores de componentes y tiene como valor
predeterminado todos los componentes. También puede filtrar por estado de
propagación de paquetes (quitados o paquetes que fluyen) mediante el parámetro [--
type].

Junto con la captura de paquetes, el Monitor de paquetes permite capturar eventos

generales como eventos ETW y WPP declarando el parámetro [-t] y especificando los
proveedores a través del parámetro [-p]. Use "pktmon stop" para detener toda la
recopilación de datos.

Por ejemplo, el siguiente comando capturará paquetes de solo los adaptadores de red:

PowerShell

C:\Test> pktmon start -c --comp nics

El siguiente comando capturará solo los paquetes descartados que pasan por los
componentes 4 y 5 y los registrará:
 PowerShell

C:\Test> pktmon start -c --comp 4,5 --type drop

Este comando capturará paquetes y eventos de registro del proveedor "Microsoft-

Windows-TCPIP":

PowerShell

C:\Test> pktmon start --capture --trace -p Microsoft-Windows-TCPIP

Funcionalidad de registro de paquetes

El Monitor de paquetes admite varios modos de registro:
Circular: los paquetes nuevos sobrescriben los más antiguos cuando se alcanza
el tamaño máximo del archivo. Este es el modo de registro predeterminado.
Varios archivos: se crea un nuevo archivo de registro cuando se alcanza el
tamaño máximo del archivo. Los archivos de registro se numeran
secuencialmente: [Link], [Link], etc. Aplique este modo de registro
para mantener todo el registro, pero tenga cuidado con el uso del
almacenamiento. Nota: use la marca de tiempo de creación de archivos de cada
archivo de registro como indicación de un período de tiempo específico en la
captura.
En tiempo real: los paquetes se muestran en pantalla en tiempo real. No se crea
ningún archivo de registro. Use Ctrl+C para detener la supervisión.
Memoria: los eventos se escriben en un búfer de memoria circular. El tamaño
del búfer se especifica a través del parámetro [-s]. El contenido del búfer se
escribe en un archivo de registro después de detener la captura. Use este modo
de registro para escenarios muy ruidosos para capturar una gran cantidad de
tráfico en una cantidad muy corta de tiempo en el búfer de memoria. Con
cualquier otro modo de registro, es posible que se pierda algún tráfico.

Especifique la cantidad del paquete que se va a registrar a través del parámetro [-

p]. Registre el paquete completo de cada paquete independientemente de su
tamaño estableciendo ese parámetro en 0. El valor predeterminado es de 128
bytes que deben incluir los encabezados de la mayoría de los paquetes.

Especifique el tamaño del archivo de registro mediante el parámetro [-s ]. Este será
el tamaño máximo del archivo en un modo de registro circular antes de que el
Monitor de paquetes comience a sobrescribir los paquetes más antiguos con los
más recientes. También será el tamaño máximo de cada archivo en el modo de
 registro de varios archivos antes de que el Monitor de paquetes cree un nuevo
archivo para registrar los siguientes paquetes. También puede usar este parámetro
para establecer el tamaño del búfer para el modo de registro de memoria.

Para obtener más información, consulte sintaxis de inicio de pktmon.

Análisis y formato de paquetes

El Monitor de paquetes genera archivos de registro en formato ETL. Hay varias maneras
de dar formato al archivo ETL para su análisis:

Convierta el registro en formato de texto (la opción predeterminada) y analícelo

con la herramienta editor de texto como [Link]. Los datos del
paquete se mostrarán en formato TCPDump. Siga la guía siguiente para aprender a
analizar la salida en el archivo de texto.
Convertir el registro en formato pcapng para analizarlo mediante Wireshark*
Abra el archivo ETL con Network Monitor*

７ Nota

*Use los hipervínculos anteriores para aprender a analizar y analizar los registros
del Monitor de paquetes en Wireshark y Network Monitor.

Para obtener más información, consulte sintaxis de formato pktmon.

Análisis de la salida del Monitor de paquetes

El Monitor de paquetes captura una instantánea del paquete por cada componente de
la pila de red. En consecuencia, habrá varias instantáneas de cada paquete
(representadas en la imagen debajo por las líneas del cuadro azul). Cada una de estas
instantáneas de paquetes se representa mediante un par de líneas (cuadros rojos y
verdes). Hay al menos una línea que incluye algunos datos sobre la instancia de paquete
a partir de la marca de tiempo. Justo después, hay al menos una línea (en negrita en la
imagen siguiente) para mostrar el paquete sin formato analizado en formato de texto
(sin una marca de tiempo); podría ser varias líneas si el paquete está encapsulado, como
el paquete en el cuadro verde.
Para correlacionar todas las instantáneas de los mismos paquetes, supervise los valores
PktGroupId y PktNumber (resaltados en amarillo); todas las instantáneas del mismo
paquete deben tener estos 2 valores en común. El valor Apariencia (resaltado en azul)
actúa como contador para cada instantánea posterior del mismo paquete. Por ejemplo,
la primera instantánea del paquete (donde el paquete apareció por primera vez en la
pila de redes) tiene el valor 1 para su apariencia, la siguiente instantánea tiene el valor 2,
etc.

Cada instantánea de paquete tiene un identificador de componente (subrayado en la

imagen anterior) que indica el componente asociado a la instantánea. Para resolver el
nombre del componente y los parámetros, busque este identificador de componente en
la lista de componentes en la parte inferior del archivo de registro. Una parte de la tabla
components se muestra en la imagen siguiente resaltando "Componente 1" en amarillo
(este fue el componente donde se capturó la última instantánea anterior). Los
componentes con 2 bordes notificarán 2 instantáneas en cada borde (como las
instantáneas con la apariencia 3 y la apariencia 4, por ejemplo, en la imagen anterior).

En la parte inferior de cada archivo de registro, la lista de filtros se presenta como se

muestra en la imagen siguiente (resaltada en azul). Cada filtro muestra los parámetros
especificados (PROTOCOLO ICMP en el ejemplo siguiente) y ceros para el resto de los
parámetros.
En el caso de los paquetes descartados, la palabra "drop" aparece antes de cualquiera
de las líneas que representan la instantánea donde se quitó el paquete. Cada paquete
quitado también proporciona un valor dropReason. Este parámetro dropReason
proporciona una breve descripción del motivo de la colocación de paquetes; por
ejemplo, error de coincidencia de MTU, VLAN filtrado, etc.

Contadores de paquetes
Los contadores del Monitor de paquetes proporcionan una vista de alto nivel del tráfico
de red en toda la pila de redes sin necesidad de analizar un registro, lo que puede ser
un proceso costoso. Examine los patrones de tráfico consultando contadores de
paquetes con contadores pktmon después de iniciar la captura del Monitor de
paquetes. Restablezca los contadores a cero mediante el restablecimiento de pktmon o
detenga la supervisión conjuntamente mediante la detención de pktmon.

Los contadores se organizan mediante pilas de enlace con adaptadores de red en

la parte superior y protocolos de la parte inferior.
Tx/Rx: los contadores se separan en dos columnas para las instrucciones de envío
(Tx) y recepción (Rx).
Bordes: los componentes notifican la propagación de paquetes cuando un
paquete cruza el límite del componente (borde). Cada componente puede tener
uno o varios bordes. Los controladores de minipuerto suelen tener un solo borde
superior, los protocolos tienen un solo borde inferior y los controladores de filtro
tienen bordes superiores e inferiores.
Gotas: los contadores de colocación de paquetes se notifican en la misma tabla.
En el ejemplo siguiente, se inició una nueva captura y, a continuación, se usó el
comando pktmon counters para consultar los contadores antes de detener la captura.
Los contadores muestran un único paquete que lo hace fuera de la pila de red,
empezando desde la capa de protocolo hasta el adaptador de red físico, y su respuesta
vuelve en la otra dirección. Si falta el ping o la respuesta, es fácil detectarlo a través de
los contadores.

En el ejemplo siguiente, las caídas se notifican en la columna "Contador". Recupere el

último motivo de colocación de cada componente solicitando datos de contadores en
formato JSON mediante contadores pktmon --json o analice el registro de salida para
obtener información más detallada.

Como se muestra en estos ejemplos, los contadores podrían proporcionar una gran
cantidad de información a través de un diagrama que se puede analizar con solo un
aspecto rápido.

Para obtener más información, consulte sintaxis de contadores de pktmon.

Diseño de pila de redes

Examine el diseño de la pila de red a través de la lista pktmon de comandos.
El comando muestra los componentes de red (controladores) organizados por enlaces
de adaptadores.

Un enlace típico consta de:

Una sola tarjeta de interfaz de red (NIC)

Algunos controladores de filtro (posiblemente cero)
Uno o varios controladores de protocolo (TCP/IP u otros)

Cada componente se identifica de forma única mediante un identificador de

componente del Monitor de paquetes, que se usa para dirigir componentes individuales
para la supervisión.

７ Nota

Los identificadores no son persistentes y pueden cambiar entre reinicios y como

reinicios del controlador del Monitor de paquetes.

Es posible que algunos identificadores que aparecen en la salida del Monitor de

paquetes no aparezcan en la lista de componentes. Esto se debe a la agregación de
algunos componentes en un único identificador para facilitar la selección y
visualización de ellos. Para buscar los identificadores originales de estos
componentes, use pktmon list --json y busque la propiedad SecondaryId en la
salida.
Para obtener más información, consulte sintaxis de lista de pktmon.
Extensión de la supervisión de paquetes
en Windows Admin Center
Artículo • 21/12/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows 10, Azure Stack
Hub, Azure, Azure Stack HCI, versiones 21H2 y 20H2

La extensión de supervisión de paquetes le permite operar y consumir el Monitor de

paquetes a través de Windows Admin Center. La extensión le ayuda a diagnosticar la red
mediante la captura y visualización del tráfico de red a través de la pila de redes en un
registro que es fácil de seguir y manipular.

¿Qué es el Monitor de paquetes (Pktmon)?

El Monitor de paquetes (Pktmon) es una herramienta de diagnóstico de red integrada
entre componentes para Windows. Se puede usar para la captura de paquetes, la
detección de colocación de paquetes, el filtrado de paquetes y el recuento. La
herramienta es especialmente útil en escenarios de virtualización, como redes de
contenedor y SDN, ya que proporciona visibilidad dentro de la pila de redes.

¿Qué es Windows Admin Center?

Windows Admin Center es una herramienta de administración basada en explorador
implementada localmente que permite administrar los servidores de Windows sin
dependencias de Azure o en la nube. Windows Admin Center ofrece el control total de
todos los aspectos de tu infraestructura de servidores y es especialmente útil para la
administración de servidores en redes privadas que no están conectadas a Internet.
Windows Admin Center es la evolución moderna de herramientas de administración
como el Administrador de servidores y MMC.

Antes de comenzar
Para usar la herramienta, el servidor de destino debe ejecutar Windows Server
2019, versión 1903 o posterior.
Instalación de Windows Admin Center
Agregue un servidor a Windows Admin Center:

1. Haga clic en + Agregar en Todas las conexiones.

 2. Elija agregar una conexión de servidor.
3. Escriba el nombre del servidor y, si se le solicita, las credenciales que se van a
usar.
4. Haga clic en Enviar para finalizar.

El servidor se agregará a la lista de conexiones en la página Información general .

Introducción
Para llegar a la herramienta, vaya al servidor que creó en el paso anterior y, a
continuación, vaya a la extensión "Supervisión de paquetes".

Aplicación de filtros
Se recomienda encarecidamente aplicar filtros antes de iniciar cualquier captura de
paquetes, ya que la solución de problemas de conectividad con un destino determinado
es más fácil al centrarse en una sola secuencia de paquetes. Por otro lado, capturar todo
el tráfico de red puede hacer que la salida sea demasiado ruidosa para analizar. En
consecuencia, la extensión le guía primero al panel de filtros antes de iniciar la captura.
Para omitir este paso, haga clic en Siguiente para empezar a capturar sin filtros. El panel
filtros le guía para agregar filtros en 3 pasos.

1. Filtrado por componentes de pila de red

Si desea capturar el tráfico que pasa solo a través de componentes específicos, el

primer paso del panel filtros muestra el diseño de la pila de red para que pueda
seleccionar los componentes por los que filtrar. También es un excelente lugar para
analizar y comprender el diseño de la pila de redes de la máquina.
 

2. Filtrado por parámetros de paquete

En el segundo paso, el panel permite filtrar los paquetes por sus parámetros. Para
que se notifique un paquete, debe coincidir con todas las condiciones
especificadas en al menos un filtro; Se admiten hasta 8 filtros a la vez. Para cada
filtro, puede especificar parámetros de paquete como direcciones MAC,
direcciones IP, puertos, ethertype, protocolo de transporte, id. de VLAN.

Cuando se especifican dos MAC, DIRECCIONES IP o puertos, la herramienta

no distinguirá entre el origen o el destino; capturará paquetes que tienen
ambos valores, ya sea como destino o como origen. Sin embargo, los filtros
de visualización pueden hacer esa distinción; consulte la sección Mostrar
filtros a continuación.
Para filtrar aún más los paquetes TCP, se puede proporcionar una lista
opcional de marcas TCP para que coincidan. Las marcas admitidas son FIN,
SYN, RST, PSH, ACK, URG, ECE y CWR.
Si la casilla de encapsulación está activada, la herramienta aplica el filtro a los
paquetes internos encapsulados, además del paquete externo. Los métodos
de encapsulación admitidos son VXLAN, GRE, NVGRE e IP en IP. El puerto
VXLAN personalizado es opcional y el valor predeterminado es 4789.
 

3. Filtrado por estado de flujo de paquetes

El Monitor de paquetes capturará los paquetes que fluyen y quitan de forma

predeterminada. Para capturar solo en paquetes descartados, seleccione Paquetes
descartados.

Después, se muestra un resumen de todas las condiciones de filtro seleccionadas

para su revisión. Podrá recuperar esa vista después de iniciar la captura a través del
botón Condiciones de captura .
 

Registro de captura
Los resultados se muestran en una tabla que muestra los parámetros principales de los
paquetes capturados: marca de tiempo, Dirección IP de orígenes, Puerto de origen,
Dirección IP de destino, Puerto de destino, Ethertype, Protocolo, Marcas TCP, si el
paquete se quitó y el motivo de la eliminación.

La marca de tiempo de cada uno de estos paquetes también es un hipervínculo

que le redirigirá a otra página donde puede encontrar más información sobre el
paquete seleccionado. Consulte la sección Página de detalles a continuación.
Todos los paquetes quitados tienen un valor "True" en la pestaña Eliminado , un
motivo de colocación y se muestran en texto rojo para que sean más fáciles de
identificar.
Todas las pestañas se pueden ordenar de forma ascendente y descendente.
Puede buscar un valor en cualquier columna del registro mediante la barra de
búsqueda.
Puede reiniciar la captura con los mismos filtros elegidos mediante el botón
Reiniciar .
 

Details page
En esta página se presenta una instantánea del paquete a medida que fluye por cada
componente de la pila de redes local. Esta vista muestra la ruta de acceso del flujo de
paquetes y le permite investigar cómo cambian los paquetes a medida que se procesan
por cada componente que pasan.

Las instantáneas de paquetes se agrupan por cada pila de adaptadores o

conmutadores; Es decir, las instantáneas de paquetes capturadas por un adaptador
o conmutador, sus controladores de filtro y sus controladores de protocolo se
agruparán bajo el nombre del adaptador o conmutador. Esto facilitará el
seguimiento del flujo del paquete de un adaptador al otro.
Cuando se selecciona una instantánea, se muestran más detalles sobre esta
instantánea específica, incluidos los encabezados de paquete sin formato.
Todos los paquetes quitados tienen un valor "True" en la pestaña Eliminado , un
motivo de colocación y se muestran en texto rojo para que sean más fáciles de
identificar.
 

Mostrar filtros
Los filtros de visualización permiten filtrar el registro después de capturar los paquetes.
Para cada filtro, puede especificar parámetros de paquete como direcciones MAC,
direcciones IP, puertos, ethertype y protocolo de transporte. A diferencia de los filtros
de captura:

Los filtros de visualización pueden distinguir entre el origen y el destino de las

direcciones IP, las direcciones MAC y los puertos.
Los filtros de visualización se pueden eliminar y editar después de aplicarlos para
cambiar la vista del registro.
Los filtros de visualización se invierten en los registros guardados.
 

Guardar característica
El botón Guardar permite guardar el registro en el equipo local, en el equipo remoto o
en ambos. Los filtros de visualización se invertirán en el registro guardado.

Si el registro se guarda en el equipo local, podrá guardarlo en varios formatos:

Formato Etl que se puede analizar mediante Microsoft Network Monitor. Nota:
Consulte esta página para obtener más información.
Formato de texto que se puede analizar mediante cualquier editor de texto
como [Link].
Formato Pcapng que se puede analizar mediante herramientas como Wireshark.
La mayoría de los metadatos del Monitor de paquetes se perderán durante esta
conversión. Consulte esta página para obtener más información.
 

Característica abierta
La característica abierta le permitirá volver a abrir cualquiera de los cinco últimos
registros guardados para analizarlos a través de la herramienta.


Extensión de los diagnósticos de ruta de
acceso de datos SDN en Windows
Admin Center
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows 10, Azure Stack
Hub, Azure, Azure Stack HCI, versiones 21H2 y 20H2

SdN Data Path Diagnostics es una herramienta dentro de la extensión de supervisión de

SDN de Windows Admin Center que automatiza las capturas de paquetes basadas en el
Monitor de paquetes según varios escenarios de SDN y presenta la salida en una sola
vista que es fácil de seguir y manipular.

¿Qué es el Monitor de paquetes (Pktmon)?

El Monitor de paquetes (Pktmon) es una herramienta de diagnóstico de red integrada
entre componentes para Windows. Se puede usar para la captura de paquetes, la
detección de caídas de paquetes, el filtrado de paquetes y el recuento. La herramienta
es especialmente útil en escenarios de virtualización, como redes de contenedor y SDN,
ya que proporciona visibilidad dentro de la pila de redes.

¿Qué es Windows Admin Center?

Windows Admin Center es una herramienta de administración basada en explorador
implementada localmente que le permite administrar los servidores de Windows sin
dependencias en la nube o de Azure. Windows Admin Center ofrece el control total de
todos los aspectos de tu infraestructura de servidores y es especialmente útil para la
administración de servidores en redes privadas que no están conectadas a Internet.
Windows Admin Center es la evolución moderna de herramientas de administración
como el Administrador de servidores y MMC.

Antes de comenzar
Para usar la herramienta, el servidor de destino debe ejecutarse Windows Server
2019 versión 1903 (19H1) y versiones posteriores.
Instalación de Windows Admin Center
Agregue un clúster a Windows Admin Center:
 1. Haga clic en + Agregar en Todas las conexiones.
2. Elija agregar una conexión de clúster de Hyper-Converged.
3. Escriba el nombre del clúster y, si se le solicita, las credenciales que se van a
usar.
4. Active Configure the Network Controller (Configurar controladora de red )
para continuar.
5. Escriba el URI de controladora de red y haga clic en Validar.
6. Haga clic en Agregar para finalizar.

El clúster se agregará a la lista de conexiones. Haga clic en él para iniciar el panel.

Introducción
Para ir a la herramienta, vaya al clúster que creó en el paso anterior y, a continuación, a
la extensión "supervisión de SDN", a la pestaña "Diagnóstico de ruta de acceso de
datos".

Selección de escenarios
En la primera página se enumeran todos los escenarios de SDN clasificados como
escenarios de carga de trabajo y escenarios de infraestructura, como se muestra en la
imagen siguiente. Para empezar, seleccione el escenario de SDN que debe
diagnosticarse.
 

Parámetros de escenario
Después de elegir el escenario, rellene una lista de parámetros obligatorios y opcionales
para iniciar la captura. Estos parámetros básicos apuntarán la herramienta a la conexión
que debe diagnosticarse. A continuación, la herramienta usará estos parámetros para
que las consultas ejecuten una captura correcta, sin intervención del usuario para
averiguar el flujo de paquetes esperado, las máquinas implicadas en el escenario, su
ubicación en el clúster o los filtros de captura que se aplicarán en cada máquina. Los
parámetros obligatorios permiten que la captura se ejecute y los parámetros opcionales
ayudan a filtrar algún ruido.


Registro de captura
Después de iniciar la captura, la extensión mostrará una lista de las máquinas donde se
inicia la captura. Es posible que se le pida que inicie sesión en estas máquinas si no se
guardaron las credenciales. Puede empezar a reproducir el ping o el problema que está
intentando diagnosticar mediante la captura de los paquetes relativos. Una vez
capturados los paquetes, la extensión mostrará marcas junto a las máquinas donde se
capturaron los paquetes.

Después de detener la captura, los registros de todas las máquinas se mostrarán en una
sola página, divididas por el título de la máquina. Cada título incluirá el nombre de la
máquina, su rol en el escenario y su host en el caso de máquinas virtuales (VM).
 

Los resultados se muestran en una tabla que muestra los parámetros principales de los
paquetes capturados: marca de tiempo, Dirección IP de orígenes, Puerto de origen,
Dirección IP de destino, Puerto de destino, Ethertype, Protocolo, Marcas TCP, si el
paquete se quitó y el motivo de la eliminación.

La marca de tiempo de cada uno de estos paquetes también es un hipervínculo

que le redirigirá a una página diferente donde puede encontrar más información
sobre el paquete seleccionado. Consulte la sección Página de detalles a
continuación.
Todos los paquetes descartados tienen un valor "True" en la pestaña Quitado , un
motivo de colocación y se muestra en texto rojo para facilitar la identificación.
Todas las pestañas se pueden ordenar de forma ascendente y descendente.
Puede buscar un valor en cualquier columna del registro mediante la barra de
búsqueda.
Puede reiniciar la captura con los mismos filtros elegidos mediante el botón
Reiniciar .

Details page
La información de esta página es especialmente valiosa si tiene problemas de
propagación de paquetes incorrectos o problemas de configuración incorrectas, ya que
puede investigar el flujo del paquete a través de cada componente de la pila de red.
Para cada salto de paquete, hay detalles que incluyen los parámetros del paquete, así
como los detalles del paquete sin procesar.
 Los saltos se agrupan en función de los componentes implicados. Cada adaptador
y los controladores de la parte superior se agrupan por el nombre del adaptador.
Esto facilita el seguimiento del paquete en un nivel alto a través de estos títulos de
grupo.
Todos los paquetes descartados también se mostrarán en texto rojo para facilitar
su identificación.

Seleccione un salto para ver más detalles. En escenarios de encapsulación y NAT

(traducción de direcciones de red), esta característica le permite ver el cambio de
paquetes a medida que pasa a través de la pila de redes y comprobar si hay problemas
de configuración incorrecta.


Desplácese hacia abajo para ver los detalles del paquete sin procesar:

Filtros de visualización
Los filtros de visualización permiten filtrar el registro después de capturar los paquetes.
Para cada filtro, puede especificar parámetros de paquete como direcciones MAC,
direcciones IP, puertos, ethertype y protocolo de transporte.

Los filtros de visualización pueden distinguir entre el origen y el destino de las

direcciones IP, las direcciones MAC y los puertos.
Los filtros de visualización se pueden eliminar y editar después de aplicarlos para
cambiar la vista del registro.
Los filtros de visualización se invierten en los registros guardados.
 

Guardar
El botón Guardar le permite guardar el registro en la máquina local para realizar análisis
adicionales a través de otras herramientas. Los filtros de visualización se invertirán en el
registro guardado. Los registros se pueden guardar en varios formatos:

Formato ETL que se puede analizar mediante Microsoft Network Monitor. Nota:
Consulte esta página para obtener más información.
Formato de texto que se puede analizar mediante cualquier editor de texto como
[Link].
Formato Pcapng que se puede analizar mediante herramientas como Wireshark.
La mayoría de los metadatos del Monitor de paquetes se perderán durante esta
conversión. Nota: Consulte esta página para obtener más información.

Compatibilidad de Pktmon con
Microsoft Network Monitor (Netmon)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows 10, Azure Stack
Hub, Azure, Azure Stack HCI, versiones 21H2 y 20H2

El Monitor de paquetes (Pktmon) genera registros en formato ETL. Estos registros se

pueden analizar mediante Microsoft Network Monitor (Netmon) mediante analizadores
especiales. En este tema se explica cómo analizar los archivos ETL generados por el
Monitor de paquetes en Netmon.

Configuración y configuración de Network

Monitor
Siga estos pasos para instalar y configurar Netmon para analizar los archivos ETL
generados por el Monitor de paquetes:

1. Instale Network Monitor 3.4 .

2. Inicie monitor de red con privilegios elevados y establezca Windows como perfil
de analizador activo en (Herramientas/ Opciones/Perfiles de analizador).
3. Copie etl_Microsoft-[Link] de aquí a
"%PROGRAMDATA%\Microsoft\Network Monitor 3\NPL\NetworkMonitor
Parsers\Windows"
4. Copie stub_etl_Microsoft-[Link] de aquí a
"%PROGRAMDATA%\Microsoft\Network Monitor 3\NPL\NetworkMonitor
Parsers\Windows\Stubs"
5. Cambie el nombre de stub_etl_Microsoft-[Link] a
etl_Microsoft-[Link]
6. Incluya etl_Microsoft-[Link] en
NetworkMonitor_Parsers_sparser.npl en "%PROGRAMDATA%\Microsoft\Network
Monitor 3\NPL\NetworkMonitor Parsers"
7. Reinicie monitor de red con privilegios elevados para volver a generar los
analizadores.
Compatibilidad con Pktmon para
Wireshark (pcapng)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows 10, Azure Stack
Hub, Azure, Azure Stack HCI, versiones 21H2 y 20H2

El Monitor de paquetes (Pktmon) puede convertir registros en formato pcapng. Estos

registros se pueden analizar mediante Wireshark (o cualquier analizador de pcapng); sin
embargo, podría faltar parte de la información crítica en los archivos pcapng. En este
tema se explica el resultado esperado y cómo aprovecharlo.

Sintaxis Pktmon pcapng

Use los siguientes comandos para convertir la captura de pktmon en formato pcapng.

PowerShell

C:\Test> pktmon pcapng help

pktmon pcapng [Link] [-o [Link]]
Convert log file to pcapng format.
Dropped packets are not included by default.

-o, --out
Name of the formatted pcapng file.

-d, --drop-only
Convert dropped packets only.

-c, --component-id
Filter packets by a specific component ID.

Example: pktmon pcapng C:\tmp\[Link] -d -c nics

Filtrado de salida
Toda la información sobre los informes de colocación de paquetes y el flujo de paquetes
a través de la pila de red se perderá en la salida de pcapng. Por lo tanto, el contenido
del registro debe filtrarse cuidadosamente para dicha conversión. Por ejemplo:

El formato Pcapng no distingue entre un paquete que fluye y un paquete

descartado. Para separar todos los paquetes de la captura de paquetes
descartados, genere dos archivos pcapng; que contiene todos los paquetes
("pktmon pcapng [Link] --out [Link]") y otro que solo contiene
paquetes descartados ("pktmon pcapng [Link] --drop-only --out [Link]").
De este modo, podrá analizar los paquetes descartados en un registro
independiente.
El formato Pcapng no distingue entre distintos componentes de red en los que se
capturó un paquete. Para estos escenarios multicapa, especifique el identificador
de componente deseado en la salida pcapng "pktmon pcapng [Link] --
component-id 5". Repita este comando para cada conjunto de identificadores de
componente que le interesen.
Directiva de calidad de servicio (QoS)
Artículo • 21/12/2022 • Tiempo de lectura: 7 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar la directiva de QoS como punto central de administración de ancho de

banda de red en toda la infraestructura de Active Directory mediante la creación de
perfiles de QoS, cuya configuración se distribuye con directiva de grupo.

７ Nota

Además de este tema, está disponible la siguiente documentación de la directiva

de QoS.

Introducción con la directiva de QoS

Administrar la directiva de QoS
Preguntas más frecuentes sobre la directiva de QoS

Las directivas de QoS se aplican a una sesión de inicio de sesión de usuario o a un

equipo como parte de un objeto de directiva de grupo (GPO) que ha vinculado a un
contenedor de Active Directory, como un dominio, un sitio o una unidad organizativa
(OU).

La administración del tráfico de QoS se produce por debajo del nivel de aplicación, lo
que significa que no es necesario modificar las aplicaciones existentes para beneficiarse
de las ventajas proporcionadas por las directivas de QoS.

Sistemas operativos que admiten la directiva de

QoS
Puede usar la directiva de QoS para administrar el ancho de banda de los equipos o
usuarios con los siguientes sistemas operativos de Microsoft.

Windows Server 2016

Windows 10
Windows Server 2012 R2
Windows 8.1
Windows Server 2012
Windows 8
 Windows Server 2008 R2
Windows 7
Windows Server 2008
Windows Vista

Ubicación de la directiva de QoS en directiva de grupo

En Windows Server 2016 directiva de grupo Editor de administración, la ruta de acceso a
la directiva de QoS para la configuración del equipo es la siguiente.

| de directiva de dominio predeterminada | de configuración del equipo Directivas |

Windows Configuración | QoS basado en directivas

Esta ruta de acceso se muestra en la siguiente imagen.

En Windows Server 2016 directiva de grupo Editor de administración, la ruta de acceso a

la directiva de QoS para la configuración de usuario es la siguiente.

| de directiva de dominio predeterminada | de configuración de usuario Directivas |

Windows Configuración | QoS basado en directivas

De forma predeterminada, no se configura ninguna directiva de QoS.

¿Por qué usar la directiva QoS?

A medida que aumenta el tráfico en la red, es cada vez más importante equilibrar el
rendimiento de la red con el costo del servicio, pero el tráfico de red no suele ser fácil
de priorizar y administrar.

En la red, las aplicaciones críticas y sensibles a la latencia deben competir por el ancho
de banda de red frente al tráfico de prioridad inferior. Al mismo tiempo, algunos
usuarios y equipos con requisitos de rendimiento de red específicos pueden requerir
niveles de servicio diferenciados.
Los desafíos de proporcionar niveles de rendimiento de red predecibles y rentables a
menudo aparecen primero a través de conexiones de red de área extensa (WAN) o con
aplicaciones sensibles a la latencia, como la voz sobre IP (VoIP) y el streaming de vídeo.
Sin embargo, el objetivo final de proporcionar niveles de servicio de red predecibles se
aplica a cualquier entorno de red (por ejemplo, una red de área local de una empresa) y
a más que las aplicaciones voIP, como las aplicaciones de línea de negocio
personalizadas de su empresa.

QoS basado en directivas es la herramienta de administración de ancho de banda de

red que proporciona control de red basado en aplicaciones, usuarios y equipos.

Al usar la directiva de QoS, las aplicaciones no necesitan escribirse para interfaces de

programación de aplicaciones específicas (API). Esto le ofrece la posibilidad de usar QoS
con aplicaciones existentes. Además, QoS basado en directivas aprovecha la
infraestructura de administración existente, ya que QoS basado en directivas está
integrado en directiva de grupo.

Definir la prioridad de QoS a través de un

punto de código de servicios diferenciados
(DSCP)
Puede crear directivas de QoS que definan la prioridad del tráfico de red con un valor de
punto de código de servicios diferenciados (DSCP) que asigne a diferentes tipos de
tráfico de red.

El DSCP permite aplicar un valor (0–63) dentro del campo Tipo de servicio (TOS) en el
encabezado de un paquete IPv4 y dentro del campo Clase de tráfico en IPv6.

El valor DSCP proporciona clasificación del tráfico de red en el nivel de Protocolo de

Internet (IP), que los enrutadores usan para decidir el comportamiento de puesta en
cola del tráfico.

Por ejemplo, puede configurar enrutadores para colocar paquetes con valores DSCP
específicos en una de las tres colas: prioridad alta, mejor esfuerzo o menor que el mejor
esfuerzo.

El tráfico de red crítico, que se encuentra en la cola de alta prioridad, tiene preferencia
sobre otro tráfico.

Limitar el uso de ancho de banda de red por aplicación

con velocidad de limitación
También puede limitar el tráfico de red saliente de una aplicación especificando una
velocidad de limitación en la directiva de QoS.

Una directiva QoS que define los límites de limitación determina la velocidad del tráfico
de red saliente. Por ejemplo, para administrar los costos wan, un departamento de TI
podría implementar un contrato de nivel de servicio que especifique que un servidor de
archivos nunca puede proporcionar descargas más allá de una tarifa específica.

Uso de la directiva de QoS para aplicar valores de DSCP y

velocidades de limitación
También puede usar la directiva de QoS para aplicar valores de DSCP y velocidades de
limitación para el tráfico de red saliente a lo siguiente:

Envío de la ruta de acceso de la aplicación y del directorio

Direcciones IPv4 o IPv6 de origen y destino o prefijos de dirección

Protocolo: protocolo de control de transmisión (TCP) y protocolo de datagramas

de usuario (UDP)

Puertos y intervalos de puertos de origen y destino (TCP o UDP)

Grupos específicos de usuarios o equipos a través de la implementación en

directiva de grupo

Mediante el uso de estos controles, puede especificar una directiva de QoS con un valor
DSCP de 46 para una aplicación VoIP, lo que permite a los enrutadores colocar paquetes
VoIP en una cola de baja latencia, o puede usar una directiva de QoS para limitar un
conjunto de tráfico saliente de servidores a 512 kilobytes por segundo (KBps) al enviar
desde el puerto TCP 443.

También puede aplicar la directiva de QoS a una aplicación determinada que tenga
requisitos de ancho de banda especiales. Para obtener más información, consulte
Escenarios de directiva de QoS.

Ventajas de la directiva de QoS

Con la directiva de QoS, puede configurar y aplicar directivas de QoS que no se pueden
configurar en enrutadores y conmutadores. La directiva de QoS proporciona las
siguientes ventajas.
1. Nivel de detalle: Es difícil crear directivas de QoS de nivel de usuario en
enrutadores o conmutadores, especialmente si el equipo del usuario está
configurado mediante la asignación de direcciones IP dinámicas o si el equipo no
está conectado a puertos fijos de conmutador o enrutador, como suele ser el caso
de los equipos portátiles. Por el contrario, la directiva de QoS facilita la
configuración de una directiva QoS de nivel de usuario en un controlador de
dominio y propaga la directiva al equipo del usuario.

2. Flexibilidad. Independientemente de dónde o cómo se conecte un equipo a la red,

se aplica la directiva QoS: el equipo puede conectarse mediante WiFi o Ethernet
desde cualquier ubicación. En el caso de las directivas de QoS de nivel de usuario,
la directiva de QoS se aplica en cualquier dispositivo compatible en cualquier
ubicación en la que el usuario inicie sesión.

3. Seguridad: Si el departamento de TI cifra el tráfico de los usuarios de un extremo a

otro mediante la seguridad del protocolo de Internet (IPsec), no puede clasificar el
tráfico en enrutadores en función de ninguna información sobre la capa IP del
paquete (por ejemplo, un puerto TCP). Sin embargo, mediante el uso de la
directiva de QoS, puede clasificar los paquetes en el dispositivo final para indicar la
prioridad de los paquetes en el encabezado IP antes de que se cifren las cargas IP
y se envíen los paquetes.

4. Rendimiento: Algunas funciones de QoS, como la limitación, se realizan mejor

cuando están más cerca del origen. La directiva de QoS mueve estas funciones de
QoS más cercanas al origen.

5. Manejabilidad: La directiva de QoS mejora la capacidad de administración de red

de dos maneras:

a. Dado que se basa en directiva de grupo, puede usar la directiva de QoS para
configurar y administrar un conjunto de directivas de QoS de usuario o equipo
siempre que sea necesario y en un equipo de controlador de dominio central.

b. La directiva de QoS facilita la configuración del usuario o equipo

proporcionando un mecanismo para especificar directivas por localizador uniforme
de recursos (URL) en lugar de especificar directivas basadas en las direcciones IP
de cada uno de los servidores donde se deben aplicar las directivas de QoS. Por
ejemplo, supongamos que la red tiene un clúster de servidores que comparten una
dirección URL común. Mediante el uso de la directiva de QoS, puede crear una
directiva basada en la dirección URL común, en lugar de crear una directiva para
cada servidor del clúster, con cada directiva basada en la dirección IP de cada
servidor.
Para el siguiente tema de esta guía, consulte Introducción con la directiva de QoS.
Tareas iniciales con la directiva QoS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar los temas siguientes para empezar a trabajar con la directiva de calidad de
servicio (QoS).

Funcionamiento de la directiva QoS

Arquitectura de directivas QoS
Escenarios de directiva de QoS

Para obtener el primer tema de esta guía, vea Directiva de calidad de servicio (QoS).
Funcionamiento de la directiva de QoS
Artículo • 21/12/2022 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Al iniciar u obtener la configuración de usuario o equipo actualizada directiva de grupo

configuración de QoS, se produce el siguiente proceso.

1. El directiva de grupo recupera la configuración de usuario o equipo directiva de

grupo configuración de Active Directory.

2. El directiva de grupo de datos informa a la extensión de Client-Side QoS de que se

han realizado cambios en las directivas de QoS.

3. La extensión de Client-Side QoS envía una notificación de eventos de directiva de

QoS al módulo de inspección de QoS.

4. El módulo de inspección de QoS recupera las directivas qoS de usuario o equipo y

las almacena.

Cuando se crea un nuevo punto de conexión de la capa de transporte (conexión TCP o

tráfico UDP), se produce el siguiente proceso.

1. El componente Capa de transporte de la pila TCP/IP informa al módulo de

inspección de QoS.

2. El módulo de inspección de QoS compara los parámetros del punto de conexión

de la capa de transporte con las directivas de QoS almacenadas.

3. Si se encuentra una coincidencia, el módulo de inspección de QoS se pone en

contacto con [Link] para crear un flujo, una estructura de datos que contiene el
valor DSCP y la configuración de limitación del tráfico de la directiva qoS
correspondiente. Si hay varias directivas de QoS que coinciden con los parámetros
del punto de conexión de la capa de transporte, se usa la directiva de QoS más
específica.

4. [Link] almacena el flujo y devuelve un número de flujo correspondiente al flujo

al módulo de inspección de QoS.

5. El módulo de inspección de QoS devuelve el número de flujo a la capa de

transporte.
 6. La capa de transporte almacena el número de flujo con el punto de conexión de la
capa de transporte.

Cuando se envía un paquete correspondiente a un punto de conexión de la capa de

transporte marcado con un número de flujo, se produce el siguiente proceso.

1. La capa de transporte marca internamente el paquete con el número de flujo.

2. La capa de red [Link] para el valor DSCP correspondiente al número de flujo del
paquete.

3. [Link] devuelve el valor DSCP a la capa de red.

4. La capa de red cambia el campo IPv4 TOS o el campo Clase de tráfico IPv6 al valor
DSCP especificado por [Link] y, en el caso de los paquetes IPv4, calcula la suma
de comprobación final del encabezado IPv4.

5. La capa de red entrega el paquete a la capa de tramas.

6. Dado que el paquete se ha marcado con un número de flujo, la capa de tramas

entrega el paquete [Link] a través de NDIS 6.x.

7. [Link] usa el número de flujo del paquete para determinar si es necesario limitar
el paquete y, si es así, programa el paquete para su envío.

8. [Link] entrega el paquete inmediatamente (si no hay ninguna limitación de

tráfico) o como programado (si hay limitación de tráfico) a NDIS 6.x para la
transmisión a través del adaptador de red adecuado.

Estos procesos de QoS basada en directivas proporcionan las siguientes ventajas.

La inspección del tráfico para determinar si se aplica una directiva de QoS se

realiza por punto de conexión de la capa de transporte, en lugar de por paquete.

No hay ningún impacto en el rendimiento del tráfico que no coincida con una
directiva de QoS.

No es necesario modificar las aplicaciones para aprovechar el servicio diferenciado

basado en DSCP o la limitación del tráfico.

Las directivas de QoS se pueden aplicar al tráfico protegido con IPsec.

Para el siguiente tema de esta guía, consulte Arquitectura de directivas qoS.

Para el primer tema de esta guía, vea Directiva de calidad de servicio (QoS).
Arquitectura de directivas de QoS
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información sobre la arquitectura de la directiva de
QoS.

En la ilustración siguiente se muestra la arquitectura de QoS basado en directivas.

La arquitectura de QoS basada en directivas consta de los siguientes componentes:

directiva de grupo servicio de cliente. Un servicio Windows que administra la

configuración de usuario y equipo directiva de grupo.

directiva de grupo motor. Componente del servicio cliente de directiva de grupo

que recupera la configuración de usuario y equipo directiva de grupo de Active
 Directory al iniciarse y comprueba periódicamente si hay cambios (de forma
predeterminada, cada 90 minutos). Si se detectan cambios, el motor de directiva
de grupo recupera la nueva configuración de directiva de grupo. El motor de
directiva de grupo procesa los GPO entrantes e informa a la extensión del lado
cliente de QoS cuando se actualizan las directivas de QoS.

Extensión del lado cliente de QoS. Componente del servicio cliente de directiva de
grupo que espera una indicación del motor de directiva de grupo que las
directivas de QoS han cambiado e informa al módulo de inspección de QoS.

Pila TCP/IP. La pila TCP/IP que incluye compatibilidad integrada con IPv4 e IPv6 y
admite Windows Plataforma de filtrado.

Inspección de QoS. Módulo Un componente dentro de la pila TCP/IP que espera

indicaciones de cambios de directiva de QoS de la extensión del lado cliente de
QoS, recupera la configuración de directiva de QoS e interactúa con la capa de
transporte y [Link] para marcar internamente el tráfico que coincide con las
directivas de QoS.

NDIS 6.x. Interfaz estándar entre los controladores de red en modo kernel y el
sistema operativo en los sistemas operativos Windows Server y Client. NDIS 6.x
admite filtros ligeros, que es un modelo de controlador simplificado para
controladores intermedios NDIS y controladores de miniporte que proporcionan
un mejor rendimiento.

Interfaz del proveedor de red (NPI) de QoS. Interfaz para que los controladores
en modo kernel interactúen con [Link].

[Link]. Un controlador de filtro ligero NDIS 6.x que controla la programación de

paquetes para QoS basado en directivas y para el tráfico de aplicaciones que usan
las API genéricas de QoS (GQoS) y control de tráfico (TC). [Link] reemplazaron
[Link] en Windows Server 2003 y Windows XP. [Link] se instala con el
componente Programador de paquetes QoS de las propiedades de una conexión
de red o adaptador.

Para ver el tema siguiente de esta guía, consulte Escenarios de directiva de QoS.

Para el primer tema de esta guía, consulte Directiva de calidad de servicio (QoS).
Escenarios de directiva de QoS
Artículo • 21/12/2022 • Tiempo de lectura: 10 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para revisar escenarios hipotéticos que muestran cómo, cuándo y
por qué usar la directiva QoS.

Los dos escenarios de este tema son:

1. Priorizar el tráfico de red para una aplicación de línea de negocio

2. Priorizar el tráfico de red para una aplicación de servidor HTTP

７ Nota

Algunas secciones de este tema contienen pasos generales que puede realizar para
realizar las acciones descritas. Para obtener instrucciones más detalladas sobre
cómo administrar la directiva de QoS, consulte Administración de la directiva de
QoS.

Escenario 1: Priorizar el tráfico de red para una

aplicación de línea de negocio
En este escenario, un departamento de TI tiene varios objetivos que pueden lograr
mediante la directiva de QoS:

Proporcionar un mejor rendimiento de red para aplicaciones críticas.

Proporcionar un mejor rendimiento de red para un conjunto clave de usuarios
mientras usan una aplicación específica.
Asegúrese de que la aplicación de copia de seguridad de datos de toda la empresa
no impida el rendimiento de la red mediante el uso de demasiado ancho de banda
a la vez.

El departamento de TI decide configurar la directiva de QoS para priorizar aplicaciones

específicas mediante el uso de valores de punto de código de servicio de diferenciación
(DSCP) para clasificar el tráfico de red y configurar sus enrutadores para proporcionar
tratamiento preferente para el tráfico de mayor prioridad.

７ Nota
 Para obtener más información sobre DSCP, vea la sección Definición de la prioridad
de QoS a través de un punto de código Servicios diferenciados en el tema Directiva
de calidad de servicio (QoS).

Además de los valores dscp, las directivas de QoS pueden especificar una velocidad de
limitación. La limitación tiene el efecto de limitar todo el tráfico saliente que coincide
con la directiva de QoS a una velocidad de envío específica.

Configuración de directiva de QoS

Con tres objetivos independientes por lograr, el administrador de TI decide crear tres
directivas de QoS diferentes.

Directiva de QoS para servidores de aplicaciones LOB

La primera aplicación crítica para la que el departamento de TI crea una directiva de
QoS es una aplicación de planeamiento de recursos Enterprise (ERP) en toda la empresa.
La aplicación ERP se hospeda en varios equipos que ejecutan Windows Server 2016. En
Active Directory Domain Services, estos equipos son miembros de una unidad
organizativa (OU) que se creó para servidores de aplicaciones de línea de negocio (LOB).
El componente del lado cliente para la aplicación ERP se instala en equipos que ejecutan
Windows 10 y Windows 8.1.

En directiva de grupo, un administrador de TI selecciona el objeto directiva de grupo

(GPO) en el que se aplicará la directiva de QoS. Mediante el asistente para directivas de
QoS, el administrador de TI crea una directiva de QoS denominada "Directiva loB de
servidor" que especifica un valor DSCP de prioridad alta de 44 para todas las
aplicaciones, cualquier dirección IP, TCP y UDP, y el número de puerto.

La directiva qoS solo se aplica a los servidores lob vinculando el GPO a la unidad
organizativa que contiene solo estos servidores, a través de la herramienta Consola de
administración de directivas de grupo (GPMC). Esta directiva de LOB del servidor inicial
aplica el valor DSCP de prioridad alta cada vez que el equipo envía tráfico de red. Esta
directiva de QoS se puede editar más adelante (en la herramienta Editor de objetos de
directiva de grupo) para incluir los números de puerto de la aplicación ERP, lo que limita
la directiva para que se aplique solo cuando se usa el número de puerto especificado.

Directiva de QoS para el grupo financiero

Aunque muchos grupos de la empresa acceden a la aplicación ERP, el grupo financiero

depende de esta aplicación cuando se trabaja con los clientes y el grupo requiere un
alto rendimiento constante de la aplicación.

Para asegurarse de que el grupo financiero puede admitir a sus clientes, la directiva QoS
debe clasificar el tráfico de estos usuarios como de alta prioridad. Sin embargo, la
directiva no debe aplicarse cuando los miembros del grupo financiero usan aplicaciones
que no son la aplicación ERP.

Por este problema, el departamento de TI define una segunda directiva de QoS

denominada "Directiva de LOB de cliente" en la herramienta Editor de objetos de
directiva de grupo que aplica un valor DSCP de 60 cuando el grupo de usuarios
financieros ejecuta la aplicación ERP.

Directiva de QoS para una aplicación de copia de seguridad

Se ejecuta una aplicación de copia de seguridad independiente en todos los equipos.

Para asegurarse de que el tráfico de la aplicación de copia de seguridad no usa todos
los recursos de red disponibles, el departamento de TI crea una directiva de datos de
copia de seguridad. Esta directiva de copia de seguridad especifica un valor DSCP de 1
en función del nombre ejecutable de la aplicación de copia de seguridad, que es
[Link].

Se crea e implementa un tercer GPO para todos los equipos cliente del dominio. Cada
vez que la aplicación de copia de seguridad envía datos, se aplica el valor DSCP de
prioridad baja, incluso si se origina en equipos del departamento financiero.

７ Nota

El tráfico de red sin una directiva qoS se envía con un valor DSCP de 0.

Directivas de escenario
En la tabla siguiente se resumen las directivas de QoS para este escenario.

Nombre de Valor Velocidad Aplicado a unidades Descripción

la directiva DSCP de organizativas
limitación

[Sin 0 None [Sin implementación] Mejor tratamiento de esfuerzo

directiva] (valor predeterminado) para el
tráfico sin clasificar.
 Nombre de Valor Velocidad Aplicado a unidades Descripción
la directiva DSCP de organizativas
limitación

Datos de 1 None Todos los clientes Aplica un valor DSCP de prioridad

copia de baja para estos datos masivos.
seguridad

LoB del 44 None Unidad organizativa Aplica DSCP de alta prioridad para
servidor del equipo para el tráfico de servidor ERP
servidores ERP

LOB de 60 None Grupo de usuarios Aplica DSCP de alta prioridad para

cliente financieros el tráfico de cliente ERP.

７ Nota

Los valores DSCP se representan en formato decimal.

Con las directivas de QoS definidas y aplicadas mediante directiva de grupo, el tráfico
de red saliente recibe el valor DSCP especificado por la directiva. A continuación, los
enrutadores proporcionan un tratamiento diferencial basado en estos valores DSCP
mediante la cola. Para este departamento de TI, los enrutadores se configuran con
cuatro colas: alta prioridad, prioridad media, mejor esfuerzo y prioridad baja.

Cuando el tráfico llega al enrutador con valores DSCP de "directiva de LOB de servidor"
y "directiva loB de cliente", los datos se colocan en colas de alta prioridad. El tráfico con
un valor DSCP de 0 recibe el mejor nivel de servicio. Los paquetes con un valor DSCP de
1 (de la aplicación de copia de seguridad) reciben un tratamiento de prioridad baja.

Requisitos previos para priorizar una aplicación de línea

de negocio
Para completar esta tarea, asegúrese de cumplir los siguientes requisitos:

Los equipos implicados ejecutan sistemas operativos compatibles con QoS.

Los equipos implicados son miembros de un Active Directory Domain Services (AD
DS) para que se puedan configurar mediante directiva de grupo.

Las redes TCP/IP se configuran con enrutadores configurados para DSCP (RFC
2474). Para obtener más información, vea RFC 2474 .

Se cumplen los requisitos de credenciales administrativas.

Credenciales administrativas
Para completar esta tarea, debe poder crear e implementar directiva de grupo Objetos.

Configuración del entorno de prueba para priorizar una aplicación

de línea de negocio
Para configurar el entorno de prueba, realice las siguientes tareas.

Cree un AD DS con clientes y usuarios agrupados en unidades organizativas. Para

obtener instrucciones sobre cómo implementar AD DS, consulte la Guía de red
principal.

Configure los enrutadores para poner en cola diferencialmente en función de los

valores DSCP. Por ejemplo, el valor 44 de DSCP entra en una cola "Platinum" y
todos los demás se ponderan en cola imparcial.

７ Nota

Puede ver los valores dscp mediante capturas de red con herramientas como
Monitor de red. Después de realizar una captura de red, puede observar el campo
TOS en los datos capturados.

Pasos para priorizar una aplicación de línea de negocio

Para priorizar una aplicación de línea de negocio, realice las siguientes tareas:

1. Cree y vincule un objeto directiva de grupo (GPO) con una directiva QoS.

2. Configure los enrutadores para tratar diferencialmente una aplicación de línea de

negocio (mediante la cola) en función de los valores de DSCP seleccionados. Los
procedimientos de esta tarea variarán en función del tipo de enrutadores que
tenga.

Escenario 2: Priorizar el tráfico de red para una

aplicación de servidor HTTP
En Windows Server 2016, QoS basada en directivas incluye las directivas basadas en url
de la característica. Las directivas de dirección URL permiten administrar el ancho de
banda de los servidores HTTP.
Muchas Enterprise aplicaciones se desarrollan y hospedan en servidores web de Internet
Information Services (IIS), y se accede a las aplicaciones web desde exploradores en
equipos cliente.

En este escenario, suponga que administra un conjunto de servidores IIS que hospedan
vídeos de entrenamiento para todos los empleados de la organización. El objetivo es
asegurarse de que el tráfico de estos servidores de vídeo no sobrecargará la red y
asegurarse de que el tráfico de vídeo se diferencia del tráfico de voz y datos en la red.

La tarea es similar a la tarea del escenario 1. Diseñará y configurará las opciones de

administración del tráfico, como el valor DSCP para el tráfico de vídeo y la tasa de
limitación igual que lo haría para las aplicaciones de línea de negocio. Pero al especificar
el tráfico, en lugar de proporcionar el nombre de la aplicación, solo debe escribir la
dirección URL a la que responderá la aplicación de servidor HTTP: por ejemplo,
[Link]

７ Nota

No puede usar directivas QoS basadas en URL para priorizar el tráfico de red de los
equipos que ejecutan Windows sistemas operativos que se publicaron antes de
Windows 7 y Windows Server 2008 R2.

Reglas de precedencia para directivas basadas en URL

Todas las direcciones URL siguientes son válidas y se pueden especificar en la directiva
qoS y aplicarse simultáneamente a un equipo o a un usuario:

[Link]

[Link]

[Link]

[Link]

Pero, ¿cuál recibirá prioridad? Las reglas son sencillas. Las directivas basadas en url se
priorizan en un orden de lectura de izquierda a derecha. Por lo tanto, desde la prioridad
más alta a la prioridad más baja, los campos de dirección URL son:

1. Esquema de dirección URL

2. Host de dirección URL

3. Puerto de dirección URL

4. Ruta de acceso URL

Los detalles son los siguientes:

1. Esquema de dirección URL

https:// tiene una prioridad mayor que https:// .

2. Host de dirección URL

Desde la prioridad más alta a la más baja, son:

1. Nombre de host

2. Dirección IPv6

3. Dirección IPv4

4. Wildcard (Carácter comodín)

En el caso del nombre de host, un nombre de host con más elementos de puntos (más
profundidad) tiene una prioridad más alta que un nombre de host con menos
elementos de puntos. Por ejemplo, entre los siguientes nombres de host:

[Link] (profundidad = 6)

[Link] (profundidad = 4)

entrenamiento (profundidad = 1)

library (profundidad = 1)

[Link] tiene la prioridad más alta y

[Link] la prioridad más alta siguiente. El
entrenamiento y la biblioteca comparten la misma prioridad más baja.

3. Puerto de dirección URL

Un número de puerto específico o implícito tiene una prioridad mayor que un puerto
comodín.

4. Ruta de acceso URL

Al igual que un nombre de host, una ruta de acceso url puede constar de varios
elementos. El que tiene más elementos siempre tiene una prioridad mayor que el que
tiene menos. Por ejemplo, las rutas de acceso siguientes se enumeran por prioridad:

1. /ebooks/tech/windows/networking/qos

2. /ebooks/tech/windows/

3. /ebooks

4. /

Si un usuario decide incluir todos los subdirectorios y archivos que sigue a una ruta de
dirección URL, esta ruta de acceso de dirección URL tendrá una prioridad menor de la
que tendría si no se realizara la elección.

Un usuario también puede optar por especificar una dirección IP de destino en una
directiva basada en url. La dirección IP de destino tiene una prioridad menor que
cualquiera de los cuatro campos de dirección URL descritos anteriormente.

Directiva de Resuple
Se especifica una directiva de Cargouple por identificador de protocolo, dirección IP de
origen, puerto de origen, dirección IP de destino y puerto de destino. Una directiva
Deeuple siempre tiene una prioridad mayor que cualquier directiva basada en
direcciones URL.

Si ya se aplica una directiva de Wcfuple para un usuario, una nueva directiva basada en
url no provocará conflictos en ninguno de los equipos cliente de ese usuario.

Para el siguiente tema de esta guía, consulte Administración de la directiva qoS.

Para obtener el primer tema de esta guía, vea Directiva de calidad de servicio (QoS).
Administración de la directiva qos
Artículo • 21/09/2022 • Tiempo de lectura: 20 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información sobre el uso del Asistente para
directivas de QoS para crear, editar o eliminar una directiva de QoS.

７ Nota

Además de este tema, está disponible la siguiente documentación de

administración de directivas de QoS.

Errores y eventos de directiva de QoS

En Windows sistemas operativos, la directiva QoS combina la funcionalidad de QoS

basada en estándares con la capacidad de administración de directiva de grupo. La
configuración de esta combinación facilita la aplicación de directivas de QoS para
directiva de grupo objetos. Windows incluye un Asistente para directivas de QoS para
ayudarle a realizar las siguientes tareas.

Crear una directiva QoS

Ver, editar o eliminar una directiva QoS

Crear una directiva QoS

Antes de crear una directiva de QoS, es importante que comprenda los dos controles de
QoS clave que se usan para administrar el tráfico de red:

Valor de DSCP

Velocidad de limitación

Priorización del tráfico con DSCP

Como se indicó en el ejemplo de aplicación de línea de negocio anterior, puede definir
la prioridad del tráfico de red saliente mediante Especificar valor DSCP para configurar
una directiva de QoS con un valor DSCP específico.
Como se describe en RFC 2474, DSCP permite especificar valores de 0 a 63 dentro del
campo TOS de un paquete IPv4 y dentro del campo Clase de tráfico en IPv6. Los
enrutadores de red usan el valor DSCP para clasificar los paquetes de red y ponerlos en
cola adecuadamente.

７ Nota

De forma predeterminada, Windows tráfico tiene un valor DSCP de 0.

El número de colas y su comportamiento de asignación de prioridades deben diseñarse

como parte de la estrategia de QoS de la organización. Por ejemplo, su organización
puede optar por tener cinco colas: tráfico sensible a la latencia, tráfico de control, tráfico
crítico para la empresa, tráfico de mejor esfuerzo y tráfico de transferencia de datos
masivos.

Limitar el tráfico
Junto con los valores de DSCP, la limitación es otro control clave para administrar el
ancho de banda de red. Como se mencionó anteriormente, puede usar la opción
Especificar velocidad de limitación para configurar una directiva de QoS con una tasa de
limitación específica para el tráfico saliente. Mediante el uso de la limitación, una
directiva de QoS limita el tráfico de red saliente a una velocidad de limitación
especificada. Tanto el límite como el marcado de DSCP se pueden utilizar en conjunto
para administrar el tráfico de manera eficaz.

７ Nota

De forma predeterminada, la casilla Especificar velocidad del acelerador no está

activada.

Para crear una directiva QoS, edite la configuración de un objeto directiva de grupo
(GPO) desde la herramienta Consola de administración de directivas de grupo (GPMC).
A continuación, GPMC abre el Editor de objetos de directiva de grupo.

Los nombres de las directivas QoS deben ser exclusivos. La forma en que se aplican las
directivas a los servidores y los usuarios finales depende de dónde se almacene la
directiva qoS en el Editor de objetos de directiva de grupo:

Una directiva QoS en Configuración del equipo\Windows Configuración\Directiva

qoS se aplica a los equipos, independientemente del usuario que haya iniciado
 sesión actualmente. Por lo general, se utilizan directivas Qos basadas en equipos
para los equipos de servidores.

Una directiva qos en configuración de usuario\Windows Configuración\directiva de

QoS se aplica a los usuarios después de haber iniciado sesión,
independientemente del equipo en el que haya iniciado sesión.

Para crear una nueva directiva de QoS con el Asistente para

directivas de QoS

En Editor de objetos de directiva de grupo, haga clic con el botón derecho en

cualquiera de los nodos de directiva de QoS y, a continuación, haga clic en Crear
una nueva directiva.

Asistente (página 1): Perfil de directiva

En la primera página del Asistente para directivas de QoS, puede especificar un nombre
de directiva y configurar cómo QoS controla el tráfico de red saliente.

Para configurar la página Perfil de directiva del Asistente para

directiva basada en QoS

1. En Nombre de directiva, escriba un nombre para la directiva QoS. El nombre debe

identificar de forma única la directiva.

2. Opcionalmente, use Especificar valor de DSCP para habilitar el marcado DSCP y, a

continuación, configure un valor DSCP entre 0 y 63.

3. De forma opcional, use Especificar velocidad del acelerador para habilitar el límite
de tráfico y configurar la velocidad del acelerador. El valor de la velocidad del
acelerador debe ser mayor que 1 y es posible especificar unidades de kilobytes por
segundo (KB/s) o megabytes por segundo (MBps).

4. Haga clic en Next.

Asistente (página 2): Nombre de la aplicación

En la segunda página del Asistente para directivas QoS, puede aplicar la directiva a
todas las aplicaciones, a una aplicación específica identificada por su nombre ejecutable,
a una ruta de acceso y a un nombre de aplicación, o a las aplicaciones de servidor HTTP
que controlan las solicitudes de una dirección URL específica.
 Todas las aplicaciones especifican que la configuración de administración del
tráfico de la primera página del Asistente para directivas de QoS se aplica a todas
las aplicaciones.

Solo las aplicaciones con este nombre ejecutable especifican que la configuración
de administración del tráfico de la primera página del Asistente para directivas de
QoS es para una aplicación específica. El nombre del archivo ejecutable debe
terminar con la extensión .exe.

Solo las aplicaciones de servidor HTTP que responden a las solicitudes de esta
dirección URL especifican que la configuración de administración del tráfico de la
primera página del Asistente para directivas qoS solo se aplica a determinadas
aplicaciones de servidor HTTP.

Opcionalmente, puede especificar la ruta de acceso de la aplicación. Para especificar la

ruta de acceso de una aplicación, incluya la ruta de acceso con el nombre de la
aplicación. La ruta de acceso puede incluir variables de entorno. Por ejemplo,
%ProgramFiles%\ruta de acceso de aplicación\[Link], o c:\archivos de
programa\ruta de acceso de aplicación\[Link].

７ Nota

La ruta de acceso de la aplicación no puede incluir una ruta de acceso que se

resuelva como un vínculo simbólico.

La dirección URL debe cumplir con RFC 1738 , en forma de . Puede usar un carácter
comodín, ‘*' , para <hostname> y/o <port> , por ejemplo, [Link]
[Link] , pero el carácter comodín no puede denotar una subcadena de

<hostname> o <port> .

En otras palabras, ni [Link] ni [Link] son válidos.

Opcionalmente, puede comprobar Incluir subdirectorios y archivos para realizar la

búsqueda de coincidencias en todos los subdirectorios y archivos que se encuentran
después de una dirección URL. Por ejemplo, si esta opción está activada y la dirección
URL es [Link] , la directiva qoS considerará las solicitudes para
[Link] una buena coincidencia.

Para configurar la página Nombre de la aplicación del Asistente

para directivas qoS
 1. En Esta directiva qos se aplica a, seleccione Todas las aplicaciones o Solo
aplicaciones con este nombre ejecutable.

2. Si selecciona Sólo las aplicaciones con el siguiente nombre de archivo ejecutable,

especifique un archivo ejecutable que termine con la extensión de nombre de
archivo .exe.

3. Haga clic en Next.

Asistente (página 3): Direcciones IP

En la tercera página del Asistente para directivas de QoS, puede especificar condiciones
de dirección IP para la directiva QoS, lo que incluye lo siguiente:

Todas las direcciones IPv4 o IPv6 de origen o direcciones IPv4 o IPv6 de orígenes
específicos

Todas las direcciones IPv4 o IPv6 de destino o direcciones IPv4 o IPv6 de destino
específicas

Si selecciona Sólo para el siguiente prefijo o dirección IP de origen: o Sólo para el

siguiente prefijo o dirección IP de destino:, debe escribir una de las siguientes
opciones:

Una dirección IPv4, como [Link]

Un prefijo de dirección IPv4 mediante la notación de longitud de prefijo de red,

como [Link]/24

Una dirección IPv6, como 3ffe:ffff::1

Prefijo de dirección IPv6, como 3ffe:ffff::/48

Si selecciona Solo para la siguiente dirección IP de origen y Solo para la siguiente

dirección IP de destino, tanto las direcciones como los prefijos de dirección deben estar
basados en IPv4 o IPv6.

Si especificó la dirección URL de las aplicaciones de servidor HTTP en la página del

asistente anterior, observará que la dirección IP de origen de la directiva QoS en esta
página del asistente está atenuada.

Esto es cierto porque la dirección IP de origen es la dirección del servidor HTTP y no se

puede configurar aquí. Por otro lado, todavía puede personalizar la directiva
especificando la dirección IP de destino. Esto permite crear directivas diferentes para
distintos clientes mediante las mismas aplicaciones de servidor HTTP.
Para configurar la página Direcciones IP del Asistente para
directivas qoS

1. En Esta directiva de QoS se aplica a (origen), seleccione Cualquier dirección IP de

origen o Solo para la siguiente dirección IP de origen.

2. Si seleccionó Solo la siguiente dirección de origen IP, especifique una dirección O

prefijo IPv4 o IPv6.

3. En Esta directiva de QoS se aplica a (destino), seleccione Cualquier dirección de

destino o Solo para la siguiente dirección de destino IP.

4. Si seleccionó Solo para la siguiente dirección de destino IP, especifique una

dirección O prefijo IPv4 o IPv6 que se corresponda con el tipo de dirección o
prefijo especificado para la dirección de origen.

5. Haga clic en Next.

Asistente (página 4): Protocolos y puertos

En la cuarta página del Asistente para directivas de QoS, puede especificar los tipos de
tráfico y los puertos controlados por la configuración de la primera página del asistente.
Puede especificar:

Tráfico TCP, tráfico UDP o ambos

Todos los puertos de origen, un intervalo de puertos de origen o un puerto de

origen específico

Todos los puertos de destino, un intervalo de puertos de destino o un puerto de

destino específico

Para configurar la página Protocolos y puertos del Asistente para

directivas de QoS
1. En Seleccione el protocolo para el que se aplica esta directiva de QoS, seleccione
TCP, UDP o TCP y UDP.

2. En Especifique el número de puerto de origen, seleccione Cualquier puerto de

origen o Desde este intervalo o número de puerto de origen.

3. Si seleccionó Desde este número de puerto de origen, escriba un número de

puerto entre 1 y 65535.
 Opcionalmente, puede especificar un intervalo de puertos, con el formato
"Low:High", donde Low y High representan los límites inferior y superior del
intervalo de puertos, ambos inclusive. Bajo y Alto deben ser un número entre 1 y
65535. No se permite ningún espacio entre el carácter de dos puntos (:) y los
números.

4. En Especifique el número de puerto de destino, seleccione A cualquier puerto de

destino o A este intervalo o número de puerto de destino.

5. Si seleccionó A este intervalo o número de puerto de destino en el paso anterior,

escriba un número de puerto entre 1 y 65535.

Para completar la creación de la nueva directiva de QoS, haga clic en Finalizar en la

página Protocolos y puertos del Asistente para directivas de QoS. Una vez finalizada, la
nueva directiva de QoS se muestra en el panel de detalles del Editor de objetos de
directiva de grupo.

Para aplicar la configuración de directiva de QoS a usuarios o equipos, vincule el GPO en

el que se encuentran las directivas de QoS a un contenedor de Active Directory Domain
Services, como un dominio, un sitio o una unidad organizativa (OU).

Ver, editar o eliminar una directiva de QoS

Las páginas del Asistente para directivas de QoS descritas anteriormente corresponden
a las páginas de propiedades que se muestran al ver o editar las propiedades de una
directiva.

Para visualizar las propiedades de una directiva QoS

Haga clic con el botón derecho en el nombre de la directiva en el panel de Editor
de objetos de directiva de grupo y, a continuación, haga clic en Propiedades.

El Editor de objetos de directiva de grupo muestra la página de propiedades con

las fichas siguientes:

Perfil de directiva

Nombre de la aplicación

Direcciones IP

Protocolos y puertos
Para editar una directiva QoS
Haga clic con el botón derecho en el nombre de la directiva en el panel de Editor
de objetos de directiva de grupo y, a continuación, haga clic en Editar directiva
existente.

El Editor de objetos de directiva de grupo muestra el cuadro de diálogo Editar una

directiva de QoS existente.

Para eliminar una directiva de QoS

Haga clic con el botón derecho en el nombre de la directiva en el panel de Editor
de objetos de directiva de grupo y, a continuación, haga clic en Eliminar directiva.

Informes de GPMC de directiva de QoS

Después de aplicar varias directivas de QoS en toda la organización, puede ser útil o
necesario revisar periódicamente cómo se aplican las directivas. Se puede ver un
resumen de las directivas de QoS para un usuario o equipo específico mediante
informes de GPMC.

Para ejecutar el Asistente directiva de grupo resultados para un

informe de directivas de QoS
En GPMC, haga clic con el botón derecho directiva de grupo nodo Resultados y, a
continuación, seleccione la opción de menú directiva de grupo Resultados.

Una vez directiva de grupo resultados, haga clic en Configuración pestaña. En la

Configuración, las directivas de QoS se pueden encontrar en los nodos "Configuración
del equipo\Windows Configuración\Directiva de QoS" y "Configuración de
usuario\Windows Configuración\Directiva de QoS".

En la Configuración, las directivas de QoS aparecen por sus nombres de directiva qoS
con su valor DSCP, velocidad de limitación, condiciones de directiva y GPO ganador
enumerado en la misma fila.

La directiva de grupo resultados identifica de forma única el GPO ganador. Cuando

varios GPO tienen directivas de QoS con el mismo nombre de directiva de QoS, se aplica
el GPO con la prioridad de GPO más alta. Este es el GPO ganador. No se aplican las
directivas qoS en conflicto (identificadas por el nombre de la directiva) que están
asociadas a un GPO de prioridad inferior. Tenga en cuenta que las prioridades de GPO
definen qué directivas de QoS se implementan en el sitio, el dominio o la unidad
organizativa, según corresponda. Después de la implementación, en el nivel de usuario
o equipo, las reglas de precedencia de directivas de QoS determinan qué tráfico se
permite y bloquea.

El valor dscp de la directiva QoS, la velocidad de limitación y las condiciones de la

directiva también están visibles en Editor de objetos de directiva de grupo (GPOE)

Configuración avanzada para usuarios móviles y remotos

Con la directiva de QoS, el objetivo es administrar el tráfico en la red de una empresa.
En escenarios móviles, es posible que los usuarios envíen tráfico dentro o fuera de la red
empresarial. Dado que las directivas de QoS no son pertinentes mientras están fuera de
la red de la empresa, las directivas de QoS solo se habilitan en las interfaces de red que
están conectadas a la empresa para Windows 8, Windows 7 o Windows Vista.

Por ejemplo, un usuario podría conectar su equipo portátil a la red de su empresa a

través de una red privada virtual (VPN) desde una cafetería. Para VPN, la interfaz de red
física (por ejemplo, inalámbrica) no tendrá aplicadas directivas de QoS. Sin embargo, la
interfaz VPN tendrá directivas de QoS aplicadas porque se conecta a la empresa. Si el
usuario entra más adelante en la red de otra empresa que no tiene una relación de
confianza de AD DS, las directivas de QoS no se habilitarán.

Tenga en cuenta que estos escenarios móviles no se aplican a las cargas de trabajo del
servidor. Por ejemplo, un servidor con varios adaptadores de red podría estar en el
borde de la red de una empresa. El departamento de TI podría optar por que las
directivas de QoS limiten el tráfico que se va a la empresa. sin embargo, este adaptador
de red que envía este tráfico de salida no se conecta necesariamente a la red
empresarial. Por esta razón, las directivas de QoS siempre están habilitadas en todas las
interfaces de red de un equipo que ejecuta Windows Server 2012.

７ Nota

La habilitación selectiva solo se aplica a las directivas de QoS y no a la

configuración avanzada de QoS que se describe a continuación en este documento.

Configuración avanzada de QoS

La configuración avanzada de QoS proporciona controles adicionales para que los
administradores de TI administren el consumo de red del equipo y los distintivos DSCP.
La configuración avanzada de QoS solo se aplica en el nivel de equipo, mientras que las
directivas de QoS se pueden aplicar en los niveles de equipo y usuario.
Para configurar opciones avanzadas de QoS
1. Haga clic en Configuración del equipoy, a continuación, Windows Configuración
en directiva de grupo.

2. Haga clic con el botón derecho en Directiva de QoSy, a continuación, haga clic en
Configuración avanzada de QoS Configuración.

En la ilustración siguiente se muestran las dos pestañas avanzadas de

configuración de QoS: Tráfico TCP entrante y Invalidación de marcado DSCP.

７ Nota

Las opciones avanzadas Configuración QoS son configuraciones de directiva de

grupo de equipo.

Configuración avanzada de QoS: tráfico TCP entrante

El tráfico TCP entrante controla el consumo de ancho de banda TCP en el lado del
receptor, mientras que las directivas de QoS afectan al tráfico TCP y UDP saliente.

Al establecer un nivel de rendimiento inferior en la pestaña Tráfico TCP entrante, TCP

limitará el tamaño de la ventana de recepción TCP anunciada. El efecto de esta
configuración será el aumento de las tasas de rendimiento y el uso de vínculos para las
conexiones TCP con mayores anchos de banda o latencias (producto de retraso de
ancho de banda). De forma predeterminada, los equipos que ejecutan Windows Server
2012, Windows 8, Windows Server 2008 R2, Windows Server 2008 y Windows Vista se
establecen en el nivel de rendimiento máximo.

La ventana de recepción TCP ha cambiado en Windows Server 2012, Windows 8,

Windows Server 2008 R2, Windows Server 2008 y Windows Vista desde versiones
anteriores de Windows. Las versiones anteriores de Windows limitaban la ventana del
lado de recepción TCP a un máximo de 64 kilobytes (KB), mientras que Windows Server
2012, Windows 8, Windows Server 2008 R2, Windows Server 2008 y Windows Vista
escalaban dinámicamente la ventana del lado de recepción hasta 16 megabytes (MB). En
el control Tráfico TCP de entrada, puede controlar el nivel de rendimiento de entrada
estableciendo el valor máximo al que puede crecer la ventana de recepción TCP. Los
niveles corresponden a los siguientes valores máximos.

Nivel de rendimiento de entrada Máximo

0 64 KB
 Nivel de rendimiento de entrada Máximo

1 256 KB

2 1 MB

3 16 MB

El tamaño real de la ventana puede ser un valor igual o menor que el máximo, en
función de las condiciones de red.

Para establecer la ventana del lado de recepción TCP

1. En Editor de objetos de directiva de grupo, haga clic en Directiva de equipo local,

haga clic en Windows Configuración, haga clic con el botón derecho en Directiva
qoSy, a continuación, haga clic en QoS Configuración.

2. En Rendimiento de recepción de TCP, seleccione Configurar el rendimiento de

recepción de TCP y, a continuación, seleccione el nivel de rendimiento que desee.

3. Vincule el GPO a la unidad organizativa.

Configuración avanzada de QoS: invalidación de marcado DSCP

La invalidación de marcado DSCP restringe la capacidad de las aplicaciones para

especificar (o "marcar" ) valores DSCP distintos de los especificados en las directivas de
QoS. Al especificar que las aplicaciones pueden establecer valores DSCP, las aplicaciones
pueden establecer valores DSCP distintos de cero.

Al especificar Omitir, las aplicaciones que usan las API de QoS tendrán sus valores DSCP
establecidos en cero y solo las directivas de QoS pueden establecer valores DSCP.

De forma predeterminada, los equipos que ejecutan Windows Server 2016, Windows 10,
Windows Server 2012 R2, Windows 8.1, Windows Server 2012, Windows 8, Windows
Server 2008 R2, Windows Server 2008 y Windows Vista permiten a las aplicaciones
especificar valores DSCP; las aplicaciones y los dispositivos que no usan las API de QoS
no se invalidan.

Valores multimedia inalámbricos y DSCP

Wi-Fi Alliance ha establecido una certificación para Multimedia inalámbrico (WMM)

que define cuatro categorías de acceso (WMM_AC) para priorizar el tráfico de red
transmitido en una red inalámbrica Wi-Fi red inalámbrica. Las categorías de acceso
incluyen (en orden de prioridad más alta a menor): voz, vídeo, mejor esfuerzo y fondo;
respectivamente abreviados como VO, VI, BE y BK. La especificación WMM define qué
valores DSCP se corresponden con cada una de las cuatro categorías de acceso:

Valor DSCP WMM Access Category

48-63 Voz (VO)

32-47 Vídeo (VI)

24-31, 0-7 Mejor esfuerzo (BE)

8-23 Fondo (BK)

Puede crear directivas de QoS que usen estos valores DSCP para asegurarse de que los
equipos portátiles con adaptadores inalámbricos de Wi-Fi Certified™ for WMM reciben
un control prioritario cuando se asocian a Wi-Fi Certified para puntos de acceso WMM.

Reglas de precedencia de directiva de QoS

De forma similar a las prioridades de GPO, las directivas de QoS tienen reglas de
precedencia para resolver conflictos cuando se aplican varias directivas de QoS a un
conjunto específico de tráfico. Para el tráfico TCP o UDP saliente, solo se puede aplicar
una directiva de QoS a la vez, lo que significa que las directivas de QoS no tienen un
efecto acumulativo, por ejemplo, donde se suman las tasas de limitación.

En general, la directiva QoS con las condiciones más adecuadas gana. Cuando se aplican
varias directivas de QoS, las reglas se clasifican en tres categorías: nivel de usuario frente
a nivel de equipo; la aplicación frente a la cadena de red; y entre la cadena de red.

Por red, nos refieremos a la dirección IP de origen, la dirección IP de destino, el puerto

de origen, el puerto de destino y el protocolo (TCP/UDP).

La directiva QoS de nivel de usuario tiene prioridad sobre la directiva QoS de nivel de
equipo

Esta regla facilita en gran medida la administración de GPO de QoS por parte de los
administradores de red, especialmente para las directivas basadas en grupos de
usuarios. Por ejemplo, si el administrador de red quiere definir una directiva de QoS
para un grupo de usuarios, puede crear y distribuir un GPO a ese grupo. No tienen que
preocuparse por los equipos en los que los usuarios han iniciado sesión y si esos
equipos tendrán definidas directivas de QoS en conflicto, ya que, si existe un conflicto, la
directiva de nivel de usuario siempre tiene prioridad.
 ７ Nota

Una directiva qoS de nivel de usuario solo es aplicable al tráfico generado por ese
usuario. Otros usuarios de un equipo específico, y el propio equipo, no estarán
sujetos a ninguna directiva de QoS definida para ese usuario.

Especificidad de la aplicación y prioridad sobre la red

Cuando varias directivas QoS coinciden con el tráfico específico, se aplica la directiva
más específica. Entre las directivas que identifican las aplicaciones, una directiva que
incluye la ruta de acceso del archivo de la aplicación de envío se considera más
específica que otra directiva que solo identifica el nombre de la aplicación (sin ruta de
acceso). Si se siguen aplicando varias directivas con aplicaciones, las reglas de
precedencia usan la cadena de red para encontrar la mejor coincidencia.

Como alternativa, varias directivas de QoS pueden aplicarse al mismo tráfico

especificando condiciones que no se superponen. Entre las condiciones de las
aplicaciones y la red, la directiva que especifica la aplicación se considera más específica
y se aplica.

Por ejemplo, policy_A solo especifica un nombre de aplicación ([Link]) y policy_B

especifica la dirección IP de destino [Link]/24. Cuando estas directivas de QoS
están en conflicto ([Link] envía tráfico a una dirección IP dentro del intervalo de
[Link]/24), policy_A se aplica.

La mayor especificidad tiene prioridad dentro de la red

En el caso de los conflictos de directivas dentro de la red, la directiva con las

condiciones más adecuadas tiene prioridad. Por ejemplo, suponga policy_C especifica la
dirección IP de origen "any", la dirección IP de destino [Link], el puerto de origen
"any", el puerto de destino "any" y el protocolo "TCP".

A continuación, suponga policy_D especifica la dirección IP de origen "any", la dirección

IP de destino [Link], el puerto de origen "any", el puerto de destino 80 y el protocolo
"TCP". A policy_C y policy_D las conexiones con el destino [Link]:80. Dado que la
directiva de QoS aplica la directiva con las condiciones de coincidencia más específicas,
policy_D tiene prioridad en este ejemplo.

Sin embargo, las directivas de QoS pueden tener el mismo número de condiciones. Por
ejemplo, varias directivas pueden especificar solo una parte (pero no la misma) de la
red. Entre la cadena de red, el orden siguiente es de mayor a menor prioridad:

Dirección IP de origen
 Dirección IP de destino

Puerto de origen

Puerto de destino

Protocolo (TCP o UDP)

Dentro de una condición específica, como la dirección IP, se trata una dirección IP más
específica con mayor prioridad; Por ejemplo, una dirección IP [Link] es más
específica que [Link]/24.

Diseñe las directivas de QoS de la forma más específica posible para simplificar la
capacidad de la organización de comprender qué directivas están en vigor.

Para el siguiente tema de esta guía, consulte Errores y eventos de directiva de QoS.

Para el primer tema de esta guía, vea Directiva de calidad de servicio (QoS).
Mensajes de eventos y errores de
directiva de QoS
Artículo • 21/12/2022 • Tiempo de lectura: 7 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

A continuación se muestra el error y los mensajes de evento asociados a la directiva de

QoS.

Mensajes informativos
A continuación se muestra una lista de mensajes informativos de la directiva QoS.

Atributo Value

MessageId 16500

Gravedad Informativo

SymbolicName EVENT_EQOS_INFO_MACHINE_POLICY_REFRESH_NO_CHANGE

Lenguaje Inglés

Message Las directivas de QoS del equipo se actualizaron correctamente. No se han

detectado cambios.

Atributo Value

MessageId 16501

Gravedad Informativo

SymbolicName EVENT_EQOS_INFO_MACHINE_POLICY_REFRESH_WITH_CHANGE

Lenguaje Inglés

Message Las directivas de QoS del equipo se actualizaron correctamente. Se detectaron

cambios en la directiva.

Atributo Value

MessageId 16502

Gravedad Informativo
Atributo Value

SymbolicName EVENT_EQOS_INFO_USER_POLICY_REFRESH_NO_CHANGE

Lenguaje Inglés

Message Las directivas de QoS de usuario se actualizaron correctamente. No se han

detectado cambios.

Atributo Value

MessageId 16503

Gravedad Informativo

SymbolicName EVENT_EQOS_INFO_USER_POLICY_REFRESH_WITH_CHANGE

Lenguaje Inglés

Message Las directivas de QoS de usuario se actualizaron correctamente. Se detectaron

cambios en la directiva.

Atributo Value

MessageId 16504

Gravedad Informativo

SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_NOT_CONFIGURED

Lenguaje Inglés

Message La configuración avanzada de QoS para el nivel de rendimiento TCP entrante se

actualizó correctamente. Ninguna directiva de QoS especifica el valor de
configuración. Se aplicará el valor predeterminado del equipo local.

Atributo Value

MessageId 16505

Gravedad Informativo

SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_OFF

Lenguaje Inglés

Message La configuración avanzada de QoS para el nivel de rendimiento TCP entrante se

actualizó correctamente. El valor de configuración es Nivel 0 (rendimiento
mínimo).
Atributo Value

MessageId 16506

Gravedad Informativo

SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_HIGHLY_RESTRICTED

Lenguaje Inglés

Message La configuración avanzada de QoS para el nivel de rendimiento TCP entrante se

actualizó correctamente. El valor de configuración es Nivel 1.

Atributo Value

MessageId 16507

Gravedad Informativo

SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_RESTRICTED

Lenguaje Inglés

Message La configuración avanzada de QoS para el nivel de rendimiento TCP entrante se

actualizó correctamente. El valor de configuración es Nivel 2.

Atributo Value

MessageId 16508

Gravedad Informativo

SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_NORMAL

Lenguaje Inglés

Message La configuración avanzada de QoS para el nivel de rendimiento TCP entrante se

actualizó correctamente. El valor de configuración es Nivel 3 (rendimiento
máximo).

Atributo Value

MessageId 16509

Gravedad Informativo

SymbolicName EVENT_EQOS_INFO_APP_MARKING_NOT_CONFIGURED

Lenguaje Inglés
Atributo Value

Message La configuración avanzada de QoS para las invalidaciones de marcado DSCP se

actualizó correctamente. No se especifica el valor de configuración. Las
aplicaciones pueden establecer valores DSCP independientemente de las
directivas de QoS.

Atributo Value

MessageId 16510

Gravedad Informativo

SymbolicName EVENT_EQOS_INFO_APP_MARKING_IGNORED

Lenguaje Inglés

Message La configuración avanzada de QoS para las invalidaciones de marcado DSCP se

actualizó correctamente. Las solicitudes de marcado DSCP de la aplicación se
omitirán. Solo las directivas de QoS pueden establecer valores DSCP.

Atributo Value

MessageId 16511

Gravedad Informativo

SymbolicName EVENT_EQOS_INFO_APP_MARKING_ALLOWED

Lenguaje Inglés

Message La configuración avanzada de QoS para las invalidaciones de marcado DSCP se

actualizó correctamente. Las aplicaciones pueden establecer valores DSCP
independientemente de las directivas de QoS.

Atributo Value

MessageId 16512

Gravedad Informativo

SymbolicName EVENT_EQOS_INFO_LOCAL_SETTING_DONT_USE_NLA

Lenguaje Inglés

Message Se ha deshabilitado la aplicación selectiva de directivas de QoS basadas en la

categoría de red de dominio. Las directivas de QoS se aplicarán a todas las
interfaces de red.
Mensajes de advertencia
A continuación se muestra una lista de mensajes de advertencia de directiva de QoS.

Atributo Value

MessageId 16600

Gravedad Advertencia

SymbolicName EVENT_EQOS_WARNING_TEST_1

Lenguaje Inglés

Message EQOS: "Testing"[, con una cadena] "%2".

Atributo Value

MessageId 16601

Gravedad Advertencia

SymbolicName EVENT_EQOS_WARNING_TEST_2

Lenguaje Inglés

Message EQOS: "Testing"[, con dos cadenas, string1 is] "%2"[, string2 is] "%3".

Atributo Value

MessageId 16602

Gravedad Advertencia

SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_VERSION

Lenguaje Inglés

Message La directiva QoS del equipo "%2" tiene un número de versión no válido. Esta
directiva no se aplicará.

Atributo Value

MessageId 16603

Gravedad Advertencia

SymbolicName EVENT_EQOS_WARNING_USER_POLICY_VERSION

Lenguaje Inglés
Atributo Value

Message La directiva qoS de usuario "%2" tiene un número de versión no válido. Esta
directiva no se aplicará.

Atributo Value

MessageId 16604

Gravedad Advertencia

SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_PROFILE_NOT_SPECIFIED

Lenguaje Inglés

Message La directiva qoS del equipo "%2" no especifica un valor DSCP ni una tasa de
limitación. Esta directiva no se aplicará.

Atributo Value

MessageId 16605

Gravedad Advertencia

SymbolicName EVENT_EQOS_WARNING_USER_POLICY_PROFILE_NOT_SPECIFIED

Lenguaje Inglés

Message La directiva de QoS de usuario "%2" no especifica un valor DSCP ni una tasa de
limitación. Esta directiva no se aplicará.

Atributo Value

MessageId 16606

Gravedad Advertencia

SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_QUOTA_EXCEEDED

Lenguaje Inglés

Message Se superó el número máximo de directivas de QoS del equipo. No se aplicarán

la directiva de QoS "%2" y las directivas de QoS del equipo subsiguientes.

Atributo Value

MessageId 16607

Gravedad Advertencia
Atributo Value

SymbolicName EVENT_EQOS_WARNING_USER_POLICY_QUOTA_EXCEEDED

Lenguaje Inglés

Message Se superó el número máximo de directivas qoS de usuario. No se aplicarán la

directiva de QoS "%2" y las directivas de QoS de usuario subsiguientes.

Atributo Value

MessageId 16608

Gravedad Advertencia

SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_CONFLICT

Lenguaje Inglés

Message La directiva de QoS del equipo "%2" podría estar en conflicto con otras
directivas de QoS. Consulte la documentación para conocer las reglas sobre qué
directiva se aplicará.

Atributo Value

MessageId 16609

Gravedad Advertencia

SymbolicName EVENT_EQOS_WARNING_USER_POLICY_CONFLICT

Lenguaje Inglés

Message La directiva de QoS de usuario "%2" podría estar en conflicto con otras
directivas de QoS. Consulte la documentación para conocer las reglas sobre qué
directiva se aplicará.

Atributo Value

MessageId 16610

Gravedad Advertencia

SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_NO_FULLPATH_APPNAME

Lenguaje Inglés
 Atributo Value

Message Se omitió la directiva qoS del equipo "%2" porque no se puede procesar la ruta
de acceso de la aplicación. La ruta de acceso de la aplicación puede no ser
válida, contener una letra de unidad no válida o contener una unidad asignada
a la red.

Atributo Value

MessageId 16611

Gravedad Advertencia

SymbolicName EVENT_EQOS_WARNING_USER_POLICY_NO_FULLPATH_APPNAME

Lenguaje Inglés

Message Se omitió la directiva de QoS de usuario "%2" porque no se puede procesar la

ruta de acceso de la aplicación. La ruta de acceso de la aplicación puede no ser
válida, contener una letra de unidad no válida o contener una unidad asignada
a la red.

mensajes de error
A continuación se muestra una lista de mensajes de error de directiva de QoS.

Atributo Value

MessageId 16700

Gravedad Error

SymbolicName EVENT_EQOS_ERROR_MACHINE_POLICY_REFERESH

Lenguaje Inglés

Message No se pudieron actualizar las directivas de QoS del equipo. Código de error:
"%2".

Atributo Value

MessageId 16701

Gravedad Error

SymbolicName EVENT_EQOS_ERROR_USER_POLICY_REFERESH

Lenguaje Inglés
Atributo Value

Message No se pudieron actualizar las directivas de QoS de usuario. Código de error:

"%2".

Atributo Value

MessageId 16702

Gravedad Error

SymbolicName EVENT_EQOS_ERROR_OPENING_MACHINE_POLICY_ROOT_KEY

Lenguaje Inglés

Message QoS no pudo abrir la clave raíz de nivel de máquina para las directivas de QoS.
Código de error: "%2".

Atributo Value

MessageId 16703

Gravedad Error

SymbolicName EVENT_EQOS_ERROR_OPENING_USER_POLICY_ROOT_KEY

Lenguaje Inglés

Message QoS no pudo abrir la clave raíz de nivel de usuario para las directivas de QoS.
Código de error: "%2".

Atributo Value

MessageId 16704

Gravedad Error

SymbolicName EVENT_EQOS_ERROR_MACHINE_POLICY_KEYNAME_TOO_LONG

Lenguaje Inglés

Message Una directiva QoS de equipo supera la longitud máxima de nombre permitida.
La directiva ofending se muestra en la clave raíz de la directiva QoS de nivel de
equipo, con el índice "%2".

Atributo Value

MessageId 16705

Gravedad Error
Atributo Value

SymbolicName EVENT_EQOS_ERROR_USER_POLICY_KEYNAME_TOO_LONG

Lenguaje Inglés

Message Una directiva QoS de usuario supera la longitud máxima permitida del nombre.
La directiva ofending se muestra en la clave raíz de la directiva QoS de nivel de
usuario, con el índice "%2".

Atributo Value

MessageId 16706

Gravedad Error

SymbolicName EVENT_EQOS_ERROR_MACHINE_POLICY_KEYNAME_SIZE_ZERO

Lenguaje Inglés

Message Una directiva QoS de equipo tiene un nombre de longitud cero. La directiva
ofending se muestra en la clave raíz de la directiva QoS de nivel de equipo, con
el índice "%2".

Atributo Value

MessageId 16707

Gravedad Error

SymbolicName EVENT_EQOS_ERROR_USER_POLICY_KEYNAME_SIZE_ZERO

Lenguaje Inglés

Message Una directiva QoS de usuario tiene un nombre de longitud cero. La directiva
ofending se muestra en la clave raíz de la directiva QoS de nivel de usuario, con
el índice "%2".

Atributo Value

MessageId 16708

Gravedad Error

SymbolicName EVENT_EQOS_ERROR_OPENING_MACHINE_POLICY_SUBKEY

Lenguaje Inglés
Atributo Value

Message QoS no pudo abrir la subclave del Registro para una directiva QoS del equipo.
La directiva se muestra en la clave raíz de la directiva QoS de nivel de equipo,
con el índice "%2".

Atributo Value

MessageId 16709

Gravedad Error

SymbolicName EVENT_EQOS_ERROR_OPENING_USER_POLICY_SUBKEY

Lenguaje Inglés

Message QoS no pudo abrir la subclave del Registro para una directiva QoS de usuario.
La directiva se muestra en la clave raíz de la directiva QoS de nivel de usuario,
con el índice "%2".

Atributo Value

MessageId 16710

Gravedad Error

SymbolicName EVENT_EQOS_ERROR_PROCESSING_MACHINE_POLICY_FIELD

Lenguaje Inglés

Message QoS no pudo leer o validar el campo "%2" para la directiva de QoS del equipo
"%3".

Atributo Value

MessageId 16711

Gravedad Error

SymbolicName EVENT_EQOS_ERROR_PROCESSING_USER_POLICY_FIELD

Lenguaje Inglés

Message QoS no pudo leer o validar el campo "%2" para la directiva de QoS de usuario
"%3".

Atributo Value

MessageId 16712
 Atributo Value

Gravedad Error

SymbolicName EVENT_EQOS_ERROR_SETTING_TCP_AUTOTUNING

Lenguaje Inglés

Message QoS no pudo leer o establecer el nivel de rendimiento TCP entrante, código de
error: "%2".

Atributo Value

MessageId 16713

Gravedad Error

SymbolicName EVENT_EQOS_ERROR_SETTING_APP_MARKING

Lenguaje Inglés

Message QoS no pudo leer o establecer la configuración de invalidación de marca DSCP,

código de error: "%2".

Para el siguiente tema de esta guía, consulte Preguntas más frecuentes sobre la directiva
qoS.

Para el primer tema de esta guía, vea Directiva de calidad de servicio (QoS).
Preguntas más frecuentes sobre la
directiva de QoS
Preguntas más frecuentes

Se aplica a: Windows Server 2016

A continuación se encuentran las preguntas más frecuentes (y las respuestas a esas

preguntas) para la directiva de QoS.

¿Qué sistema operativo necesita

ejecutar mi controlador de dominio
para usar la directiva qoS?
Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server
2008 R2 o Windows Server 2008

¿Qué sistemas operativos admiten la

aplicación de la directiva qoS al usuario
o equipo?
Puede aplicar directivas de QoS a usuarios o equipos que ejecutan Windows Server
2016, Windows 10, Windows Server 2012 R2, Windows 8.1, Windows Server 2012,
Windows 8, Windows Server 2008 R2, Windows Server 2008 y Windows Vista.

¿Las directivas de QoS se aplican al

remitente o receptor del tráfico?
Las directivas de QoS se deben aplicar en el equipo de envío para que afecten a su
tráfico saliente. Para afectar al tráfico bidireccional de dos equipos, las directivas de QoS
deben aplicarse a ambos equipos.
¿Qué ocurre si las directivas de QoS en
conflicto se implementan en el mismo
equipo?
Si se aplican varias directivas, la directiva QoS más específica tiene prioridad. Por
ejemplo, se aplica una directiva que indica una dirección de host ([Link]) en lugar
de una dirección de red menos específica ([Link]/16). Si una directiva de nivel de
equipo y de nivel de usuario tiene la misma especificidad, se aplica la directiva QoS de
nivel de usuario en lugar de la directiva QoS de nivel de equipo.

¿Está habilitada la directiva de QoS de

forma predeterminada?
No, la directiva de QoS no está habilitada de forma predeterminada. Debe crear
directivas de QoS manualmente para habilitar QoS. Para más información, consulte
Administración de la directiva de QoS.

Para el primer tema de esta guía, vea Directiva de calidad de servicio (QoS).
Redes definidas por software (SDN)
Obtenga información sobre las características, la tecnología y la implementación de
Redes definidas por software (SDN).

Acerca de Redes definidas por software

ｅ INFORMACIÓN GENERAL

Introducción a las Redes definidas por software (SDN)

Seguridad para SDN

ｈ NOVEDADES

Novedades de SDN para Windows Server 2019

ｐ CONCEPTO

Componentes clave de la arquitectura de SDN

ｑ VIDEO

Mecánica de SDN de Microsoft

Introducción

ｂ INTRODUCCIÓN

Planear una infraestructura de SDN

Implementar una infraestructura de SDN

Administrar una infraestructura de SDN

ｅ INFORMACIÓN GENERAL

Solución de problemas y diagnóstico de una infraestructura de SDN

Recursos de aprendizaje de SDN

ｄ CURSOS

Solución de problemas para configurar opciones de ancho de banda de VPN de puerta de

enlace RAS de SDN en VMM

Hoja de datos de Redes definidas por software de Microsoft

Tecnologías de SDN
Artículo • 21/12/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Los temas de esta sección proporcionan información general e información técnica

sobre las tecnologías de redes definidas por software que se incluyen en Windows
Server.

Controladora de red
La controladora de red proporciona un punto de automatización centralizado y
programable para administrar, configurar, supervisar y solucionar problemas de la
infraestructura de red virtual y física del centro de datos. Con la controladora de red,
puede automatizar la configuración de la infraestructura de red en lugar de realizar la
configuración manual de los dispositivos y servicios de red.

La controladora de red es un servidor escalable y de alta disponibilidad y proporciona

dos interfaces de programación de aplicaciones (API):

1. API de Southbound : permite que la controladora de red se comunique con la red.

2. API northbound : permite comunicarse con la controladora de red.

Puede usar Windows PowerShell, la API Transferencia de estado representacional (REST)

o una aplicación de administración para administrar la siguiente infraestructura de red
física y virtual:

MV Hyper-V y conmutadores virtuales

Conmutadores de red físicos
Enrutadores de red físicos
Software de firewall
Puertas de enlace de VPN, incluidas las puertas de enlace multitente del Servicio
de acceso remoto (RAS)
Equilibradores de carga

Virtualización de red de Hyper-V

Virtualización de red de Hyper-V (HNV) ayuda a abstraer las aplicaciones y cargas de
trabajo de la red física mediante redes virtuales. Las redes virtuales proporcionan el
aislamiento multiempresa necesario mientras se ejecutan en un tejido de red física
compartida, con lo que aumenta la utilización de recursos. Para asegurarse de que
puede llevar adelante sus inversiones existentes, puede configurar redes virtuales en el
engranaje de red existente. Además, las redes virtuales son compatibles con redes de
área local (VLAN) virtuales.

Conmutador virtual de Hyper-V

El conmutador virtual de Hyper-V es un conmutador de red Ethernet de nivel 2 basado
en software que está disponible en el Administrador de Hyper-V después de instalar el
rol de servidor de Hyper-V. El conmutador incluye mediante programación
funcionalidades extensibles y administradas para conectar máquinas virtuales a la red
física y a redes virtuales. Además, el conmutador virtual de Hyper-V proporciona
cumplimiento de directivas para los niveles de seguridad, aislamiento y servicio.

También puede implementar el conmutador virtual de Hyper-V con Switch Embedded

Teaming (SET) y Remote Direct Memory Access (RDMA). Para obtener más información,
vea la sección Acceso directo a memoria remota (RDMA) y Switch Embedded Teaming
(SET) en este tema.

Servicio DNS interno (iDNS) para SDN

Las máquinas virtuales hospedadas (VM) y las aplicaciones requieren DNS para
comunicarse dentro de sus redes y con recursos externos en Internet. Con iDNS, puede
proporcionar a los inquilinos servicios de resolución de nombres DNS para recursos
aislados, de espacio de nombres local y de Internet.

Virtualización de funciones de red

Los dispositivos de hardware, como equilibradores de carga, firewalls, enrutadores y
conmutadores, se están convirtiendo cada vez más en aplicaciones virtuales. Microsoft
tiene redes virtualizadas, conmutadores, puertas de enlace, NAT, equilibradores de carga
y firewalls. Esta “virtualización de las funciones de red” es la progresión natural de la
virtualización de los servidores y de la red. Las aplicaciones virtuales están emergiendo
rápidamente y creando un mercado completamente nuevo. Siguen generando interés y
generando impulso tanto en las plataformas de virtualización como en los servicios en la
nube.

Están disponibles las siguientes tecnologías de virtualización de funciones de red.

 Software Load Balancer (SLB) y traducción de direcciones de red (NAT). Mejore el
rendimiento al admitir Direct Server Return en el que el tráfico de red devuelto
puede omitir el multiplexor de equilibrio de carga. Para más información, consulte
Equilibrio de carga de software /(SLB/) para SDN.

Firewall del centro de datos. Proporcione listas de control de acceso

pormenorizados (ACL), lo que le permite aplicar directivas de firewall en el nivel de
interfaz de máquina virtual o en el nivel de subred. Para más información, consulte
Introducción al firewall del centro de datos.

Puerta de enlace ras para SDN. Enruta el tráfico de red entre la red física y los
recursos de red de máquina virtual, independientemente de la ubicación. Puede
enrutar el tráfico de red en la misma ubicación física o en muchas ubicaciones
diferentes. Para más información, consulte Puerta de enlace de RAS para SDN.

Acceso directo a memoria remota (RDMA) y

Switch Embedded Teaming (SET)
En Windows Server 2016, puede habilitar RDMA en adaptadores de red enlazados a un
conmutador virtual de Hyper-V con o sin Switch Embedded Teaming (SET). Esto le
permite usar menos adaptadores de red cuando desea usar RDMA y SET al mismo
tiempo.

SET es una solución alternativa de formación de equipos NIC que puede usar en
entornos que incluyen Hyper-V y la pila de redes definidas por software (SDN) en
Windows Server 2016. SET integra parte de la funcionalidad de formación de equipos
NIC en el conmutador virtual de Hyper-V.

SET permite agrupar entre uno y ocho adaptadores de red Ethernet físicos en uno o
varios adaptadores de red virtual basados en software. Estos adaptadores de red
virtuales proporcionan un rendimiento rápido y tolerancia a errores en caso de que se
produzca un error en el adaptador de red. Todos los adaptadores de red miembro set
deben estar instalados en el mismo host físico de Hyper-V para colocarse en un equipo.

Además, puede usar comandos de Windows PowerShell para habilitar Data Center
Bridging (DCB), crear un conmutador virtual de Hyper-V con una NIC virtual RDMA
(vNIC) y crear un conmutador virtual de Hyper-V con VNIC SET y RDMA. Para más
información, consulte Acceso directo a memoria remota (RDMA) y Switch Embedded
Teaming (SET).

Protocolo de puerta de enlace de borde (BGP)

Protocolo de puerta de enlace de borde (BGP) es un protocolo de enrutamiento
dinámico que aprende automáticamente las rutas entre sitios que usan conexiones VPN
de sitio a sitio. Por lo tanto, BGP reduce la configuración manual de los enrutadores. Al
configurar la puerta de enlace rasa, BGP le permite administrar el enrutamiento del
tráfico de red entre las redes de vm de los inquilinos y los sitios remotos.

Equilibrio de carga de software (SLB) para SDN

Los proveedores de servicios en la nube (SSP) y las empresas que implementan SDN
pueden usar el equilibrio de carga de software (SLB) para distribuir uniformemente el
tráfico de red de inquilinos e inquilinos entre los recursos de red virtual. El SLB de
Windows Server permite habilitar múltiples servidores para que hospeden la misma
carga de trabajo, lo que proporciona alta disponibilidad y escalabilidad.

Contenedores de Windows Server

Windows Server Containers son un método ligero de virtualización de sistema operativo
que separa aplicaciones o servicios de otros servicios que se ejecutan en el mismo host
de contenedor. Cada contenedor tiene su propio sistema operativo, procesos, sistema
de archivos, registro y direcciones IP, que puede conectarse a redes virtuales.

System Center
Implemente y administre la infraestructura de SDN con Virtual Machine Management
(VMM)y Operations Manager. Con VMM, aprovisiona y administra los recursos
necesarios para crear e implementar máquinas virtuales y servicios en nubes privadas.
Con Operations Manager, supervisa servicios, dispositivos y operaciones en toda la
empresa para identificar problemas que requieren una acción inmediata.
Virtualización de red de Hyper-V
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Introducido en Windows Server 2012, Virtualización de red de Hyper-V (HNV) permite la

virtualización de redes de clientes sobre una infraestructura de red física compartida.
Con los cambios mínimos necesarios en el tejido de red físico, HNV proporciona a los
proveedores de servicios la agilidad para implementar y migrar cargas de trabajo de
inquilino en cualquier lugar de las tres nubes: la nube del proveedor de servicios, la
nube privada o la nube pública Microsoft Azure.

Para obtener más información, vea los temas siguientes:

Información general de virtualización de red de Hyper-V en Windows Server 2016

Novedades de virtualización de red de Hyper-V en Windows Server 2016

¿Sabía que Microsoft Azure proporciona una funcionalidad similar en la nube?

Obtenga más información sobre soluciones de virtualización de Microsoft Azure .

Cree una solución de virtualización híbrida en Microsoft Azure:

- Conectar una red local a Azure a través de vpn de sitio a sitio y extensión de
Active Directory a un controlador de dominio de máquina virtual iaaS en Azure |
Información general sobre virtualización
de red de Hyper-V en Windows Server
Artículo • 21/12/2022 • Tiempo de lectura: 14 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En Windows Server y Virtual Machine Manager, Microsoft proporciona una solución de

virtualización de red de un extremo a otro. Hay cinco componentes principales que
componen la solución de virtualización de red de Microsoft:

Windows Azure Pack for Windows Server proporciona un portal orientado a

inquilinos para crear redes virtuales y un portal administrativo para administrar
redes virtuales.

Virtual Machine Manager (VMM) proporciona administración centralizada del

tejido de red.

Controladora de red de Microsoft proporciona un punto de automatización

centralizado y programable para administrar, configurar, supervisar y solucionar
problemas de la infraestructura de red virtual y física del centro de datos.

Virtualización de red de Hyper-V proporciona la infraestructura necesaria para

virtualizar el tráfico de red.

Las puertas de enlace de Virtualización de red de Hyper-V proporcionan

conexiones entre redes virtuales y físicas.

En este tema se presentan conceptos y se explican las principales ventajas y

funcionalidades de virtualización de red de Hyper-V (una parte de la solución de
virtualización de red general) en Windows Server 2016. Se explica de qué manera la
virtualización de red beneficia tanto a las nubes privadas dirigidas a la consolidación de
la carga de trabajo de la empresa como a los proveedores de servicios de nube pública
de infraestructura como Servicio (IaaS).

Para obtener más detalles técnicos sobre la virtualización de redes Windows Server
2016, consulte Detalles técnicos de virtualización de red de Hyper-V en Windows Server
2016.

¿Quiere decir que

 Información general sobre virtualización de red de Hyper-V ( Windows Server
2012 R2 )

Información general de Hyper-V

Introducción al conmutador virtual de Hyper-V

Descripción de la característica
Virtualización de red de Hyper-V proporciona "redes virtuales" (denominada red de vm)
a las máquinas virtuales de forma similar a cómo la virtualización de servidores
(hipervisor) proporciona "máquinas virtuales" al sistema operativo. La virtualización de
red desacopla las redes virtuales de la infraestructura de red física y quita las
restricciones de la asignación de VLAN y dirección IP jerárquica del aprovisionamiento
de máquinas virtuales. Esta flexibilidad permite a los clientes pasar fácilmente a las
nubes IaaS y permite a los proveedores de servicios de hosting y a administradores de
centros de datos administrar sus infraestructuras y, al mismo tiempo, mantener el
aislamiento multiempresa necesario, los requisitos de seguridad y la compatibilidad con
direcciones IP de máquinas virtuales superpuestas.

Los clientes desean extender a la perfección sus centros de datos a la nube. Hoy existen
muchos desafíos técnicos en la creación de dichas arquitecturas de nube híbrida
perfectas. Uno de los mayores obstáculos a los que se enfrentan los clientes es volver a
usar sus topologías de red existentes (subredes, direcciones IP, servicios de red, entre
otros) en la nube y el puente entre sus recursos locales y sus recursos en la nube.
Virtualización de red de Hyper-V ofrece el concepto de una red de VM que es
independiente de la red física subyacente. Con este concepto de red de VM, que se
compone de una o más subredes virtuales, la ubicación exacta en la red física de
máquinas virtuales conectadas a una red virtual está desacoplada de la topología de red
virtual. Como resultado, los clientes pueden mover fácilmente sus subredes virtuales a la
nube, y al mismo tiempo, preservar las direcciones IP y la topología existentes en la
nube de manera que los servicios existentes continúen funcionando sin tener en cuenta
la ubicación física de las subredes. Es decir, Virtualización de red de Hyper-V hace
posible una nube híbrida perfecta.

Además de la nube híbrida, muchas organizaciones consolidan sus centros de datos y

crean nubes privadas para obtener internamente el beneficio de eficiencia y
escalabilidad de las arquitecturas de nube. Virtualización de red de Hyper-V permite una
mayor flexibilidad y eficacia para las nubes privadas al desacoblar la topología de red de
una unidad de negocio (al hacerlo virtual) de la topología de red física real. De esta
manera, las unidades de negocio pueden compartir fácilmente una nube privada interna
y, al mismo tiempo, estar aisladas entre sí y seguir manteniendo las topologías de red
existentes. El equipo de operaciones del centro de datos cuenta con la flexibilidad
necesaria para implementar y mover dinámicamente cargas de trabajo en cualquier
parte del centro de datos sin interrupciones del servidor, al proporcionar mejores
eficiencias operativas y un centro de datos general más efectivo.

Para los propietarios de cargas de trabajo, la principal ventaja es que ahora pueden
mover sus "topologías" de carga de trabajo a la nube sin cambiar sus direcciones IP ni
volver a escribir sus aplicaciones. Por ejemplo, la aplicación LOB típica de tres niveles se
compone de un nivel cliente, un nivel de lógica comercial y un nivel de base de datos. A
través de la directiva, Virtualización de red de Hyper-V admite clientes que incorporan
todos los niveles de la nube, o partes de los tres niveles de la nube, y al mismo tiempo
mantiene la topología de enrutamiento y las direcciones IP de los servicios (es decir,
direcciones IP de máquinas virtuales) sin necesidad de cambiar las aplicaciones.

Para los propietarios de infraestructura, la flexibilidad adicional en la ubicación de la

máquina virtual permite mover cargas de trabajo en cualquier parte en los centros de
datos sin cambiar las máquinas virtuales ni reconfigurar las redes. Por ejemplo,
Virtualización de red de Hyper-V permite la migración en vivo entre subredes para que
una máquina virtual pueda migrar a cualquier parte del centro de datos sin
interrupciones en el servicio. Anteriormente, la migración en vivo se limitaba a la
restricción de la misma subred donde se podían ubicar las máquinas virtuales. La
migración en vivo entre subredes permite a los administradores consolidar cargas de
trabajo en base a requisitos de recursos dinámicos y eficiencia energética, y también
albergar el mantenimiento de la infraestructura sin interrumpir el tiempo de
funcionamiento de la carga de trabajo del cliente.

Aplicaciones prácticas
Con el éxito de los centros de datos virtualizados, las organizaciones de TI y los
proveedores de hospedaje (proveedores que ofrecen colocación o alquileres de
servidores físicos) comenzaron a ofrecer infraestructuras virtualizadas más flexibles que
permiten ofrecer a sus clientes instancias de servidor a petición. A esta nueva clase de
servicio se la denomina infraestructura como Servicio (IaaS). Windows Server 2016
proporciona todas las funcionalidades de plataforma necesarias para permitir a los
clientes empresariales crear nubes privadas y realizar la transición a un modelo
operativo de IT como servicio. Windows Server 2016 permite a los proveedores de
servicios de host crear nubes públicas y ofrecer soluciones de IaaS a sus clientes.
Cuando se combina Virtual Machine Manager y Windows Azure Pack para administrar la
directiva de virtualización de red de Hyper-V, Microsoft proporciona una solución en la
nube eficaz.
Windows Server 2016 Virtualización de red de Hyper-V proporciona virtualización de
red controlada por software basada en directivas que reduce la sobrecarga de
administración a la que se enfrentan las empresas cuando expanden nubes IaaS
dedicadas, y proporciona a los proveedores de servicios de host en la nube una mayor
flexibilidad y escalabilidad para administrar máquinas virtuales con el fin de lograr un
mayor uso de los recursos.

Un escenario de IaaS que cuenta con máquinas virtuales de diferentes divisiones

organizativas (nube dedicada) o diferentes clientes (nube hospedada) requiere
aislamiento seguro. La solución actual, las redes de área local virtual (VLAN), pueden
presentar desventajas significativas en este escenario.

Vlan

Actualmente, las VLAN son el mecanismo que la mayoría de las organizaciones usan
para admitir la reutilización del espacio de direcciones y el aislamiento de inquilinos.
Una VLAN usa etiquetas explícitas (ID de VLAN) en los encabezados de trama Ethernet y
depende de los conmutadores Ethernet para aplicar el aislamiento y restringir los nodos
de red con el mismo ID de VLAN. Las principales desventajas con VLAN son las
siguientes:

Mayor riesgo de una interrupción inadvertida debido a la tediosa reconfiguración

de conmutadores de producción siempre que las máquinas virtuales o los límites
de aislamiento se muevan en el centro de datos dinámico.

Escalabilidad limitada ya que existe un número máximo de 4094 VLAN y los

conmutadores tradicionales no admiten más de 1000 identificadores de VLAN.

Restringido dentro de una sola subred IP, que limita la cantidad de nodos dentro
de una sola VLAN y restringe la colocación de maquinas virtuales en base a
ubicaciones físicas. Si bien las VLAN se pueden expandir entre los sitios, toda la
VLAN debe estar en la misma subred.

Asignación de dirección IP

Además de las desventajas que presentan las VLAN, la asignación de direcciones IP de

máquina virtual presenta problemas, entre los que se incluyen:

Las ubicaciones físicas en la infraestructura de red del centro de datos determinan

las direcciones IP de las máquinas virtuales. Como resultado, pasar a la nube
generalmente implica cambiar las direcciones IP de las cargas de trabajo de
servicio.
 Las directivas están unidas a direcciones IP, como las reglas de firewall, los
servicios de directorio y detección de recursos, etc. Cambiar las direcciones IP
requiere actualizar todas las directivas asociadas.

La implementación de máquinas virtuales y el aislamiento del tráfico dependen de

la topología.

Cuando los administradores de red de centro de datos planifican el diseño físico del
centro de datos, debe tomar decisiones al respecto en los casos en los que las subredes
se colocarán y se enrutarán físicamente. Estas decisiones se basan en la tecnología IP y
Ethernet que influyen en las posibles direcciones IP admitidas para máquinas virtuales
que se ejecutan en un servidor o blade determinado conectado a un bastidor en
particular del centro de datos. Cuando se proporciona y se coloca una máquina virtual
en el centro de datos, la misma debe cumplir con estas elecciones y restricciones en lo
que a la dirección IP respecta. Por lo tanto, el resultado típico es que los administradores
del centro de datos asignen nuevas direcciones IP a las máquinas virtuales.

El problema con este requisito es que además de ser una dirección, existe información
semántica asociada con una dirección IP. Por ejemplo, es posible que una subred
contenga determinados servicios o esté en una ubicación física distinta. Las reglas de
firewall, las directivas de control de acceso, las asociaciones de seguridad de IPsec están
comúnmente asociadas con direcciones IP. Cambiar las direcciones IP obliga a los
propietarios de máquinas virtuales a ajustar todas las directivas que se basaban en la
dirección IP original. Esta sobrecarga de cambio de numeración es tan alta que muchas
empresas optan por implementar únicamente servicios nuevos en la nube, dejando de
lado las aplicaciones heredadas.

Virtualización de red de Hyper-V desacopla las redes virtuales para las máquinas
virtuales del cliente de la infraestructura de red física. Como resultado, permite a las
máquinas virtuales de clientes mantener las direcciones IP originales, y al mismo tiempo,
permite a los administradores de centros de datos proporcionar máquinas virtuales de
clientes en cualquier parte del centro de datos sin reconfigurar direcciones IP físicas o ID
de VLAN. La siguiente sección resume la funcionalidad clave.

Funcionalidad importante
A continuación se muestra una lista de las funcionalidades, ventajas y funcionalidades
clave de virtualización de red de Hyper-V en Windows Server 2016:

Habilita la selección de ubicación de carga de trabajo flexible: aislamiento de red

y re-uso de direcciones IP sin VLAN
Virtualización de red de Hyper-V desacopla las redes virtuales del cliente de la
infraestructura de red física de los hosts, lo que proporciona libertad para las
colocaciones de cargas de trabajo dentro de los centros de datos. La colocación de
carga de trabajo de máquina virtual ya no se limita a la asignación de direcciones
IP o a requisitos de aislamiento VLAN de las redes físicas, ya que se aplica dentro
de los hosts Hyper-V en base a directivas de virtualización multiempresa definidas
por el software.

Máquinas virtuales de diferentes clientes con direcciones IP superpuestas ahora

pueden implementarse en el mismo servidor host sin necesidad de recurrir a
tediosas configuraciones de VLAN y sin tener que violar la jerarquía de direcciones
IP. Esto puede optimizar la migración de las cargas de trabajo del cliente en
proveedores de hospedaje IaaS compartido, lo que permite a los clientes mover
estas cargas de trabajo sin modificación, que incluye dejar intactas las direcciones
IP de las máquinas virtuales. Para el proveedor de hospedaje, admitir varios
clientes que desean extender el espacio de dirección de red existente al centro de
datos IaaS compartido es un ejercicio complejo que implica configurar y mantener
VLAN aisladas para que cada cliente garantice la coexistencia de espacios de
direcciones posiblemente superpuestas. Con Virtualización de red de Hyper-V,
admitir direcciones superpuestas es más fácil y requiere menos reconfiguración de
red por parte del proveedor de hospedaje.

Además, el mantenimiento y las actualizaciones de infraestructura física se pueden

realizar sin causar tiempo de inactividad de las cargas de trabajo del cliente. Con
Virtualización de red de Hyper-V, las máquinas virtuales en un host, bastidor,
subred, VLAN o clúster completo específico pueden migrar sin necesidad de
realizar un cambio de dirección IP física o una reconfiguración importante.

Permite movimientos más fáciles de las cargas de trabajo a una nube IaaS
compartida

Con Virtualización de red de Hyper-V, las direcciones IP y las configuraciones de

máquinas virtuales se mantienen intactas. Esto permite a las organizaciones de TI
mover las cargas de trabajo con mayor facilidad desde los centros de datos a un
proveedor de hospedaje de IaaS compartido con mínima reconfiguración de la
carga de trabajo o de las herramientas y directivas de infraestructura. En los casos
en los que existe conectividad entre los dos centros de datos, los administradores
de TI pueden continuar usando sus herramientas sin reconfigurarlas.

Permite la migración en vivo entre subredes

Tradicionalmente, la migración en vivo de cargas de trabajo de máquinas virtuales

se ha limitado a la misma subred IP o VLAN porque el cruce de subredes requería
que el sistema operativo invitado de la máquina virtual cambiara su dirección IP.
Este cambio de dirección quiebra la comunicación existente e interrumpe los
servicios que se ejecutan en la máquina virtual. Con virtualización de red de Hyper-
V, las cargas de trabajo se pueden migrar en vivo desde servidores que ejecutan
Windows Server 2016 en una subred a servidores que ejecutan Windows Server
2016 en una subred diferente sin cambiar las direcciones IP de la carga de trabajo.
Virtualización de red de Hyper-V garantiza que cambie la ubicación de la máquina
virtual debido a que se actualiza y se sincroniza la migración en vivo entre los
hosts que tienen comunicaciones continuas con la máquina virtual migrada.

Permite una administración más fácil del servidor desacoplado y la

administración de la red

La colocación de la carga de trabajo del servidor se simplifica ya que la migración y

la colocación de las cargas de trabajo son independientes de las configuraciones
de redes físicas subyacentes. Los administradores de los servidores pueden
centrarse en la administración de servicios y de servidores y los administradores de
servidores pueden centrarse en la administración general de la infraestructura y el
tráfico de red. Esto permite a los administradores de servidores de centros de
datos implementar y migrar máquinas virtuales sin cambiar las direcciones IP de
las máquinas virtuales. La sobrecarga se reduce ya que Virtualización de red de
Hyper-V permite que se produzca la colocación de máquinas virtuales
independientemente de la topología de red, reduciendo la necesidad de que los
administradores de red participen en colocaciones que podrían cambiar los límites
de aislamiento.

Simplifica la red y mejora la utilización de recursos del servidor o de la red

La rigidez de las VLAN y la dependencia de la colocación de máquinas virtuales en

una infraestructura de red física genera sobreaprovisionamiento e infrautilización.
Al romper con la dependencia, el aumento de flexibilidad de colocación de carga
de trabajo de máquinas virtuales puede simplificar la administración de red y
mejorar la utilización de recursos de red y de servidor. Tenga en cuenta que
Virtualización de red de Hyper-V admite VLAN en el contexto del centro de datos
físico. Por ejemplo, es posible que un centro de datos desee que todo el tráfico de
Virtualización de red de Hyper-V se encuentre en una VLAN específica.

Es compatible con la infraestructura existente y la tecnología emergente

Virtualización de red de Hyper-V se puede implementar en el centro de datos

actual, pero es compatible con las tecnologías emergentes de "red plana" del
centro de datos.
 Por ejemplo, HNV en Windows Server 2016 admite el formato de encapsulación
VXLAN y open vSwitch Database Management Protocol (OVSDB) como la interfaz
SouthBound (SBI).

Proporciona interoperabilidad y disponibilidad del ecosistema

Virtualización de red de Hyper-V admite varias configuraciones para la

comunicación con recursos existentes, como la conectividad entre instalaciones, la
red de área de almacenamiento (SAN), el acceso a recursos no virtualizados, etc.
Microsoft se compromete a trabajar con socios del ecosistema para dar soporte
técnico y mejorar la experiencia de Virtualización de red de Hyper-V en términos
de rendimiento, escalabilidad y funcionalidad de administración.

Configuración basada en directivas

Las directivas de virtualización de Windows Server 2016 se configuran a través de

La controladora de red de Microsoft. La controladora de red tiene una API restful
northbound y una Windows PowerShell para configurar la directiva. Para obtener
más información sobre la controladora de red de Microsoft, vea Controladora de
red.

Requisitos de software
Virtualización de red de Hyper-V mediante Microsoft Network Controller requiere
Windows Server 2016 y el rol de Hyper-V.

Vea también
Para más información sobre virtualización de red de Hyper-V Windows Server 2016 los
vínculos siguientes:

Tipo de contenido Referencias

Recursos de - Blog de arquitectura de nube privada

comunidad - Hacer preguntas: cloudnetfb@[Link]

RFC - VXLAN - RFC 7348

Tecnologías - Controladora de red

relacionadas - Información general sobre virtualización de red de Hyper-V ( Windows
Server 2012 R2 )
detalles técnicos de Virtualización de
red de Hyper-V en Windows Server
Artículo • 21/12/2022 • Tiempo de lectura: 27 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

La virtualización de servidores permite que se ejecuten varias instancias de servidor al

mismo tiempo en un solo host físico; aunque las instancias del servidor estén aisladas
entre sí. Cada máquina virtual básicamente funciona como si fuera el único servidor que
se ejecuta en el equipo físico.

La virtualización de red proporciona una funcionalidad similar, en la que varias redes

virtuales (potencialmente con direcciones IP superpuestas) se ejecutan en la misma
infraestructura de red física y cada red virtual funciona como si fuera la única red virtual
que se ejecuta en la infraestructura de red compartida. La Figura 1 muestra esta
relación.

Figura 1: Virtualización de servidor frente a virtualización de red

Conceptos de la virtualización de red de Hyper-

V
En Virtualización de red de Hyper-V (HNV), un cliente o inquilino se define como el
"propietario" de un conjunto de subredes IP que se implementan en una empresa o un
centro de datos. Un cliente puede ser una empresa o empresa con varios
departamentos o unidades de negocio en un centro de datos privado que requiera
aislamiento de red o un inquilino en un centro de datos público hospedado por un
proveedor de servicios. Cada cliente puede tener una o varias redes virtuales en el
centro de datos y cada red virtual consta de una o varias subredes virtuales.

Hay dos implementaciones de HNV que estarán disponibles en Windows Server 2016:
HNVv1 y HNVv2.

HNVv1

HNVv1 es compatible con Windows Server 2012 R2 y System Center 2012 R2

Virtual Machine Manager (VMM). La configuración de HNVv1 se basa en los
cmdlets de administración y Windows PowerShell WMI (facilitados a través de
System Center VMM) para definir la configuración de aislamiento y la dirección del
cliente (CA): red virtual, a asignaciones y enrutamiento de direcciones físicas (PA).
No se han agregado características adicionales a HNVv1 en Windows Server 2016
y no se planea ninguna característica nueva.
SET Teaming y HNV V1 no son compatibles con la plataforma.

o Para usar puertas de enlace NVGRE de alta disponibilidad, los usuarios deben
usar el equipo lbfo o ningún equipo. Or

o Use puertas de enlace implementadas de controladora de red con el

conmutador en equipo SET.

HNVv2

En HNVv2 se incluye un número significativo de características nuevas que se

implementan mediante la extensión de reenvío de azure Virtual Filtering Platform
(VFP) en el conmutador de Hyper-V. HNVv2 está totalmente integrado con
Microsoft Azure Stack, que incluye la nueva controladora de red en la pila de redes
definidas por software (SDN). La directiva de red virtual se define a través de la
controladora de red de Microsoft mediante una API RESTful NorthBound (NB) y se
rellena en un agente host a través de varias interfaces de southbound (SBI),
incluido OVSDB. La directiva de programas del Agente host en la extensión VFP del
conmutador de Hyper-V donde se aplica.

） Importante

Este tema se centra en HNVv2.

Virtual network
Cada red virtual consta de una o varias subredes virtuales. Una red virtual forma un
límite de aislamiento en el que las máquinas virtuales de una red virtual solo se
pueden comunicar entre sí. Tradicionalmente, este aislamiento se aplicaba
mediante VLAN con un intervalo de direcciones IP segregadas y 802.1q Tag o
VLAN ID. Pero con HNV, el aislamiento se aplica mediante la encapsulación NVGRE
o VXLAN para crear redes superpuestas con la posibilidad de superponer subredes
IP entre clientes o inquilinos.

Cada red virtual tiene un identificador de dominio de enrutamiento único (RDID)

en el host. Este RDID se asigna aproximadamente a un identificador de recurso
para identificar el recurso REST de red virtual en la controladora de red. Se hace
referencia al recurso REST de red virtual mediante un espacio de nombres
identificador uniforme de recursos (URI) con el identificador de recurso anexado.

Subredes virtuales
Una subred virtual implementa la semántica de la subred IP de capa 3 para las
máquinas virtuales de la misma subred virtual. La subred virtual forma un dominio
de difusión (similar a una VLAN) y se aplica el aislamiento mediante el campo
Identificador de red de inquilino de NVGRE (TNI) o identificador de red VXLAN
(VNI).

Cada subred virtual pertenece a una sola red virtual (RDID) y se le asigna un
identificador de subred virtual (VSID) único mediante la clave TNI o VNI en el
encabezado de paquete encapsulado. El VSID debe ser único dentro del centro de
datos y está comprendido entre 4096 y 2^24-2.

Una ventaja clave de la red virtual y el dominio de enrutamiento es que permite a los
clientes traer sus propias topologías de red (por ejemplo, subredes IP) a la nube. En la
figura 2 se muestra un ejemplo en el que Contoso Corp tiene dos redes independientes,
R&D Net y Sales Net. Dado que estas redes cuentan con identificadores de dominio de
enrutamiento diferentes, no pueden interactuar entre sí. Es decir, Contoso R&D Net está
aislado de Contoso Sales Net, aunque ambos son propiedad de Contoso Corp. Contoso
R&D Net contiene tres subredes virtuales. Tenga en cuenta que el RDID y el VSID son
únicos dentro de un centro de datos.
Figura 2: Redes del cliente y subredes virtuales

Reenvío de capa 2

En la figura 2, las máquinas virtuales de VSID 5001 pueden reenviar sus paquetes a
máquinas virtuales que también están en VSID 5001 a través del conmutador de Hyper-
V. Los paquetes entrantes de una máquina virtual en VSID 5001 se envían a un VPort
específico en el conmutador de Hyper-V. Las reglas de entrada (por ejemplo, encap) y
las asignaciones (por ejemplo, el encabezado de encapsulación) se aplican mediante el
conmutador de Hyper-V para estos paquetes. A continuación, los paquetes se reenvía a
otro VPort en el conmutador de Hyper-V (si la máquina virtual de destino está
conectada al mismo host) o a otro conmutador de Hyper-V en otro host (si la máquina
virtual de destino se encuentra en un host diferente).

Enrutamiento de capa 3

Del mismo modo, las máquinas virtuales de VSID 5001 pueden tener sus paquetes
enrutados a máquinas virtuales en VSID 5002 o VSID 5003 por el enrutador distribuido
de HNV que está presente en el VSwitch de cada host de Hyper-V. Al entregar el
paquete al conmutador de Hyper-V, HNV actualiza el VSID del paquete entrante al VSID
de la máquina virtual de destino. Esto solo sucederá si ambos VSID se encuentran en el
mismo RDID. Por lo tanto, los adaptadores de red virtual con RDID1 no pueden enviar
paquetes a adaptadores de red virtual con RDID2 sin atravesar una puerta de enlace.

７ Nota

En la descripción del flujo de paquetes anterior, el término "máquina virtual"

significa realmente el adaptador de red virtual en la máquina virtual. El caso más
común es que una máquina virtual contenga un solo adaptador de red virtual. En
este caso, las palabras "máquina virtual" y "adaptador de red virtual" pueden
significar conceptualmente lo mismo.
Cada subred virtual define una subred de IP de capa 3 y un límite de dominio de
difusión (L2) de capa 2 similar a una VLAN. Cuando una máquina virtual difunde un
paquete, HNV usa replicación de unidifusión (UR) para realizar una copia del paquete
original y reemplazar la dirección IP de destino y MAC por las direcciones de cada
máquina virtual que se encuentran en el mismo VSID.

７ Nota

Cuando Windows Server 2016 se distribuye, las multidifusión y subred se

implementarán mediante la replicación de unidifusión. No se admite el
enrutamiento de multidifusión entre subredes e IGMP.

Además de ser un dominio de difusión, el VSID proporciona aislamiento. Un adaptador

de red virtual en HNV está conectado a un puerto de conmutador de Hyper-V que
tendrá reglas de ACL aplicadas directamente al puerto (recurso REST
virtualNetworkInterface) o a la subred virtual (VSID) de la que forma parte.

El puerto del conmutador de Hyper-V debe tener aplicada una regla de ACL. Esta ACL
podría ser ALLOW ALL, DENY ALL o ser más específica para permitir solo determinados
tipos de tráfico en función de la coincidencia de 5 tuplas (IP de origen, IP de destino,
puerto de origen, puerto de destino, protocolo).

７ Nota

Las extensiones de conmutador de Hyper-V no funcionarán con HNVv2 en la nueva

pila redes definidas por software (SDN). HNVv2 se implementa mediante la
extensión del conmutador azure Virtual Filtering Platform (VFP), que no se puede
usar junto con ninguna otra extensión de conmutador de terceros.

Cambio y enrutamiento en Virtualización de

red de Hyper-V
HNVv2 implementa la conmutación correcta de nivel 2 (L2) y la semántica de
enrutamiento de capa 3 (L3) para funcionar igual que un conmutador físico o enrutador
funcionaría. Cuando una máquina virtual conectada a una red virtual HNV intenta
establecer una conexión con otra máquina virtual en la misma subred virtual (VSID),
primero tendrá que aprender la dirección MAC de ca de la máquina virtual remota. Si
hay una entrada ARP para la dirección IP de la máquina virtual de destino en la tabla
ARP de la máquina virtual de origen, se usa la dirección MAC de esta entrada. Si no
existe una entrada, la máquina virtual de origen enviará una difusión ARP con una
solicitud para la dirección MAC correspondiente a la dirección IP de la máquina virtual
de destino que se devolverá. El conmutador de Hyper-V interceptará esta solicitud y la
enviará al agente host. El Agente host buscará en su base de datos local una dirección
MAC correspondiente para la dirección IP de la máquina virtual de destino solicitada.

７ Nota

El Agente de host, que actúa como servidor OVSDB, usa una variante del esquema
VTEP para almacenar asignaciones de CA-PA, tabla MAC, etc.

Si hay disponible una dirección MAC, el Agente de host inserta una respuesta ARP y la
devuelve a la máquina virtual. Después de que la pila de redes de la máquina virtual
tenga toda la información de encabezado L2 necesaria, el marco se envía al puerto de
Hyper-V correspondiente en el conmutador V. Internamente, el conmutador de Hyper-V
prueba este fotograma con las reglas de coincidencia de tupla N asignadas al puerto V y
aplica determinadas transformaciones al marco en función de estas reglas. Lo más
importante es que se aplica un conjunto de transformaciones de encapsulación para
construir el encabezado de encapsulación mediante NVGRE o VXLAN, en función de la
directiva definida en la controladora de red. En función de la directiva programada por
el Agente de host, se usa una asignación de CA-PA para determinar la dirección IP del
host de Hyper-V donde reside la máquina virtual de destino. El conmutador de Hyper-V
garantiza que las reglas de enrutamiento y las etiquetas VLAN correctas se apliquen al
paquete externo para que llegue a la dirección PA remota.

Si una máquina virtual conectada a una red virtual de HNV quiere crear una conexión
con una máquina virtual en otra subred virtual (VSID), el paquete debe enrutarse en
consecuencia. HNV supone una topología de estrella en la que solo hay una dirección IP
en el espacio de CA que se usa como próximo salto para alcanzar todos los prefijos IP
(lo que significa una ruta o puerta de enlace predeterminada). Actualmente, esto aplica
una limitación a una única ruta predeterminada y no se admiten rutas no
predeterminadas.

Enrutamiento entre subredes virtuales

En una red física, una subred IP es un dominio de nivel 2 (L2) donde los equipos
(virtuales y físicos) pueden comunicarse directamente entre sí. El dominio L2 es un
dominio de difusión donde las entradas de ARP (mapa de direcciones IP:MAC) se
aprenden a través de solicitudes ARP que se difunden en todas las interfaces y las
respuestas de ARP se envían de vuelta al host solicitante. El equipo usa la información
mac aprendida de la respuesta de ARP para construir completamente el marco L2,
incluidos los encabezados Ethernet. Sin embargo, si una dirección IP está en una subred
L3 diferente, la solicitud ARP no cruza este límite L3. En su lugar, una interfaz de
enrutador L3 (próximo salto o puerta de enlace predeterminada) con una dirección IP en
la subred de origen debe responder a estas solicitudes ARP con su propia dirección
MAC.

En las redes de Windows estándar, un administrador puede crear rutas estáticas y

asignarlas a una interfaz de red. Además, normalmente se configura una "puerta de
enlace predeterminada" para que sea la dirección IP del próximo salto en una interfaz
donde se envían los paquetes destinados a la ruta predeterminada ([Link]/0). Los
paquetes se envían a esta puerta de enlace predeterminada si no existen rutas
específicas. Normalmente se trata del enrutador de la red física. HNV usa un enrutador
integrado que forma parte de cada host y tiene una interfaz en cada VSID para crear un
enrutador distribuido para las redes virtuales.

Dado que HNV asume una topología de estrella, el enrutador distribuido de HNV actúa
como una única puerta de enlace predeterminada para todo el tráfico que va entre
subredes virtuales que forman parte de la misma red VSID. La dirección usada como
puerta de enlace predeterminada tiene como valor predeterminado la dirección IP más
baja del VSID y se asigna al enrutador distribuido de HNV. Este enrutador distribuido
permite que todo el tráfico dentro de una red VSID se enrute adecuadamente porque
cada host puede enrutar directamente el tráfico al host adecuado sin necesidad de un
intermediario. Esto es especialmente cierto cuando dos máquinas virtuales que se
encuentran en la misma subred de VM, pero en diferentes subredes virtuales, están en
el mismo host físico. Como verá más adelante en esta sección, el paquete nunca debe
abandonar el host físico.

Enrutamiento entre subredes PA

A diferencia de HNVv1, que asignó una dirección IP PA para cada subred virtual (VSID),
HNVv2 ahora usa una dirección IP pa por Switch-Embedded miembro del equipo de NIC
de Teaming (SET). La implementación predeterminada supone un equipo de dos NIC y
asigna dos direcciones IP PA por host. Un único host tiene direcciones IP de PA
asignadas desde la misma subred lógica del proveedor (PA) en la misma VLAN. Dos
máquinas virtuales de inquilino en la misma subred virtual pueden encontrarse en dos
hosts diferentes que están conectados a dos subredes lógicas de proveedor diferentes.
HNV construirá los encabezados IP externos para el paquete encapsulado en función de
la asignación de CA-PA. Sin embargo, se basa en la pila TCP/IP del host en ARP para la
puerta de enlace pa predeterminada y, a continuación, compila los encabezados
Ethernet externos basados en la respuesta de ARP. Normalmente, esta respuesta ARP
procede de la interfaz SVI en el conmutador físico o enrutador L3 donde está conectado
el host. Por lo tanto, HNV se basa en el enrutador L3 para enrutar los paquetes
encapsulados entre subredes lógicas o VLAN del proveedor.

Enrutamiento fuera de una red virtual

La mayoría de las implementaciones de clientes requerirán comunicación desde el
entorno de HNV a los recursos que no forman parte de dicho entorno. Se requieren
puertas de enlace de Virtualización de red para permitir la comunicación entre los dos
entornos. Las infraestructuras que requieren una puerta de enlace de HNV incluyen la
nube privada y la nube híbrida. Básicamente, las puertas de enlace de HNV son
necesarias para el enrutamiento de nivel 3 entre redes internas y externas (físicas)
(incluida NAT) o entre diferentes sitios o nubes (privadas o públicas) que usan un túnel
VPN o GRE de IPSec.

Las puertas de enlace pueden venir en diferentes factores de forma físicos. Se pueden
compilar en Windows Server 2016, incorporarse en un conmutador Top of Rack (TOR)
que actúa como una puerta de enlace VXLAN, a la que se accede a través de una IP
virtual (VIP) anunciada por un equilibrador de carga, poner en otros dispositivos de red
existentes o puede ser un nuevo dispositivo de red independiente.

Para obtener más información sobre Windows opciones de puerta de enlace ras,
consulte Puerta de enlace ras.

Encapsulación de paquetes
Cada adaptador de red virtual en HNV está asociado a dos direcciones IP:

Dirección del cliente (CA) La dirección IP asignada por el cliente, en función de su

infraestructura de intranet. Esta dirección permite al cliente intercambiar el tráfico
de red con la máquina virtual como si no se hubiera movido a una nube pública o
privada. La CA está visible para la máquina virtual y el cliente puede obtener
acceso a ella.

Dirección del proveedor (PA) La dirección IP asignada por el proveedor de

hospedaje o los administradores del centro de datos en función de su
infraestructura de red física. La PA aparece en los paquetes de la red que se
intercambian con el servidor que ejecuta Hyper-V que hospeda la máquina virtual.
La PA está visible en la red física, pero no lo está para la máquina virtual.

Las CA mantienen la topología de red del cliente, que está virtualizada y desacoplada de
la topología y las direcciones de red física subyacente real, tal como lo implementan las
PA. En el siguiente diagrama se muestra la relación conceptual entre las CA de máquinas
virtuales y las PA de infraestructura de red como resultado de la virtualización de red.

Figura 6: Diagrama conceptual de virtualización de red a través de una infraestructura

física

En el diagrama, las máquinas virtuales del cliente envían paquetes de datos en el

espacio de ca, que atraviesan la infraestructura de red física a través de sus propias
redes virtuales o "túneles". En el ejemplo anterior, los túneles se pueden considerar
como "sobres" alrededor de los paquetes de datos de Contoso y Fabrikam con etiquetas
de envío verdes (direcciones PA) que se entregarán desde el host de origen de la
izquierda al host de destino de la derecha. La clave es cómo los hosts determinan las
"direcciones de envío" (PA) correspondientes a Contoso y las CA de Fabrikam, cómo se
coloca el "sobre" en torno a los paquetes y cómo los hosts de destino pueden
desencapsular los paquetes y entregar correctamente a las máquinas virtuales de
destino de Contoso y Fabrikam.

Esta simple comparación destacó los aspectos clave de la virtualización de red:

La CA de cada máquina virtual se asigna a una PA de host físico. Puede haber

varios CA asociados a la misma PA.

Las máquinas virtuales envían paquetes de datos en los espacios de CA, que se
colocan en un "sobre" con un par de origen y destino pa basado en la asignación.

Las asignaciones de CA-PA deben permitir a los hosts diferenciar paquetes de

diferentes equipos virtuales del cliente.

Como resultado, el mecanismo para virtualizar la red es virtualizar las direcciones de red
que utilizan las máquinas virtuales. La controladora de red es responsable de la
asignación de direcciones y el agente host mantiene la base de datos de asignación
mediante el esquema de MS_VTEP. En la próxima sección se describe el mecanismo real
de virtualización de direcciones.

Virtualización de red a través de virtualización

de direcciones
HNV implementa redes de inquilinos de superposición mediante la encapsulación de
enrutamiento genérico de virtualización de red (NVGRE) o la red de área local virtual
eXtensible (VXLAN). VXLAN es el valor predeterminado.

Red de área local virtual de eXtensible (VXLAN)

El protocolo Virtual eXtensible Local Area Network (VXLAN) (RFC 7348 ) ha sido
ampliamente adoptado en el mercado, con soporte de proveedores como Cisco,
Brocade, Arista, Dell, HP y otros. El protocolo VXLAN usa UDP como transporte. El
puerto de destino UDP asignado por IANA para VXLAN es 4789 y el puerto de origen
UDP debe ser un hash de información del paquete interno que se usará para la
propagación de ECMP. Después del encabezado UDP, se anexa un encabezado VXLAN
al paquete que incluye un campo reservado de 4 bytes seguido de un campo de 3 bytes
para el identificador de red VXLAN (VNI) - VSID, seguido de otro campo reservado de 1
byte. Después del encabezado VXLAN, se anexa el marco CA L2 original (sin el marco
ETHERNET FCS de CA).
Encapsulación de enrutamiento genérico (NVGRE)
Este mecanismo de virtualización de red usa la encapsulación de enrutamiento genérico
(NVGRE) como parte del encabezado de túnel. En NVGRE, el paquete de la máquina
virtual se encapsula dentro de otro paquete. El encabezado de este nuevo paquete tiene
las direcciones IP PA de origen y de destino apropiadas, además del identificador de
subred virtual, que se almacena en el campo Clave del encabezado GRE, como se
muestra en la Figura 7.

Figura 7: Virtualización de red - Encapsulación NVGRE

El identificador de subred virtual permite a los hosts identificar la máquina virtual del
cliente para cualquier paquete determinado, aunque las PA y las ca de los paquetes se
superpongan. Esto permite a las máquinas virtuales del mismo host compartir una sola
PA, como se muestra en la Figura 7.

Compartir la PA tiene un gran impacto en la escalabilidad de la red. La cantidad de

direcciones IP y MAC que la infraestructura de red necesita detectar puede reducirse
sustancialmente. Por ejemplo, si cada host extremo tiene un promedio de 30 máquinas
virtuales, la cantidad de direcciones IP y MAC que debe detectar la infraestructura de
red se reduce en un factor de 30. Los identificadores de subred virtual insertados en los
paquetes también permiten la fácil correlación de paquetes con los clientes reales.

El esquema de uso compartido de PA para Windows Server 2012 R2 es una PA por VSID
por host. Para Windows Server 2016 el esquema es un pa por miembro del equipo de
NIC.

Con Windows Server 2016 y versiones posteriores, HNV es totalmente compatible con
NVGRE y VXLAN de fábrica; no requiere actualizar o comprar hardware de red nuevo,
como NIC (adaptadores de red), conmutadores o enrutadores. Esto se debe a que estos
paquetes en la conexión son paquetes IP normales en el espacio pa, que es compatible
con la infraestructura de red actual. Sin embargo, para obtener el mejor rendimiento,
use NIC compatibles con los controladores más recientes que admiten descargas de
tareas.

Ejemplo de implementación multiinquilino

En el diagrama siguiente se muestra una implementación de ejemplo de dos clientes
ubicados en un centro de datos en la nube con la relación CA-PA definida por las
directivas de red.

Figura 8: Ejemplo de implementación multiempresa

Considere el ejemplo en la Figura 8. Antes de pasar al servicio IaaS compartido del

proveedor de hospedaje:

Contoso Corp ejecutó un servidor SQL Server (llamado SQL) en la dirección IP

[Link] y un servidor web (llamado Web) en la dirección IP [Link], que usa
SQL Server para transacciones de bases de datos.

Fabrikam Corp ejecutó un servidor SQL Server, también llamado SQL y asignó la
dirección IP [Link] y un servidor web, también llamado Web y también la
dirección IP [Link] que usa SQL Server para transacciones de bases de datos.

Se supone que el proveedor de servicios de hospedaje ha creado previamente la red

lógica del proveedor (PA) a través de la controladora de red para que se corresponda
con su topología de red física. La controladora de red asigna dos direcciones IP DE PA
desde el prefijo IP de la subred lógica donde están conectados los hosts. La
controladora de red también indica la etiqueta VLAN adecuada para aplicar las
direcciones IP.
Con la controladora de red, Contoso Corp y Fabrikam Corp crean su red virtual y
subredes respaldadas por la red lógica del proveedor (PA) especificada por el proveedor
de servicios de hospedaje. Contoso Corp y Fabrikam Corp mueven sus respectivos
servidores SQL Server y sus servidores web al mismo servicio IaaS compartido del
proveedor de hospedaje donde, casualmente, ejecutan las máquinas virtuales SQL en el
host 1 de Hyper-V y las máquinas virtuales (IIS7) Web en el host 2 de Hyper-V. Todas las
máquinas virtuales conservan las direcciones IP de intranet originales (sus CA).

A ambas empresas se les asigna el siguiente identificador de subred virtual (VSID) por la
controladora de red, como se indica a continuación. El agente host en cada uno de los
hosts de Hyper-V recibe las direcciones IP de PA asignadas de la controladora de red y
crea dos vNIC de host PA en un compartimiento de red no predeterminado. Se asigna
una interfaz de red a cada una de estas vNIC de host donde se asigna la dirección IP de
PA, como se muestra a continuación:

VSID y PAs de las máquinas virtuales de Contoso Corp: VSID es 5001, SQL PA es
[Link], La PA web es [Link]

VsID y PAs de las máquinas virtuales de Fabrikam Corp: VSID es 6001, SQL PA es
[Link], Web PA es [Link]

La controladora de red rellena todas las directivas de red (incluida la asignación de CA-
PA) al agente host de SDN, que mantendrá la directiva en un almacén persistente (en
tablas de base de datos de OVSDB).

Cuando la máquina virtual web de Contoso Corp ([Link].12) en el host de Hyper-V 2

crea una conexión TCP a la SQL Server en [Link], ocurre lo siguiente:

ARP de máquina virtual para la dirección MAC de destino de [Link]

La extensión VFP del vSwitch intercepta este paquete y lo envía al agente host de
SDN.

El agente host de SDN busca en su almacén de directivas la dirección MAC de la

versión [Link].

Si se encuentra un MAC, el agente de host inserta una respuesta ARP de nuevo en

la máquina virtual.

Si no se encuentra un MAC, no se envía ninguna respuesta y la entrada ARP de la

máquina virtual para [Link] se marca como inaccesible.

La máquina virtual ahora construye un paquete TCP con los encabezados

ETHERNET y IP de CA correctos y los envía al vSwitch.
 La extensión de reenvío de VFP en vSwitch procesa este paquete a través de las
capas de VFP (descritas a continuación) asignadas al puerto vSwitch de origen en
el que se recibió el paquete y crea una nueva entrada de flujo en la tabla de flujo
unificada de VFP.

El motor VFP realiza la búsqueda de reglas o de tabla de flujo para cada capa (por
ejemplo, capa de red virtual) en función de los encabezados IP y Ethernet.

La regla coincidente de la capa de red virtual hace referencia a un espacio de

asignación ca-PA y realiza la encapsulación.

El tipo de encapsulación (VXLAN o NVGRE) se especifica en la capa de red virtual

junto con el VSID.

En el caso de la encapsulación de VXLAN, se construye un encabezado UDP

externo con el VSID de 5001 en el encabezado VXLAN. Un encabezado IP externo
se construye con la dirección PA de origen y destino asignada al host de Hyper-V 2
([Link]) y al host de Hyper-V 1 ([Link]), respectivamente en función
del almacén de directivas del agente host de SDN.

A continuación, este paquete fluye a la capa de enrutamiento de PA en VFP.

La capa de enrutamiento de PA en VFP hará referencia al compartimiento de red

usado para el tráfico del espacio PA y un identificador de VLAN y usará la pila
TCP/IP del host para reenviar el paquete pa al host de Hyper-V 1 correctamente.

Tras la recepción del paquete encapsulado, el host 1 de Hyper-V recibe el paquete

en el compartimiento de red PA y lo reenvía al vSwitch.

El VFP procesa el paquete a través de sus capas de VFP y crea una nueva entrada
de flujo en la tabla de flujo unificado de VFP.

El motor VFP coincide con las reglas de entrada de la capa de red virtual y quita los
encabezados Ethernet, IP y VXLAN del paquete encapsulado externo.

A continuación, el motor VFP reenvía el paquete al puerto vSwitch al que está

conectada la máquina virtual de destino.

Un proceso similar para el tráfico entre las máquinas virtuales de Fabrikam Corp Web y
SQL usa la configuración de la directiva de HNV de Fabrikam Corp. Como resultado, con
HNV, las máquinas virtuales de Fabrikam Corp y Contoso Corp interactúan como si
estuviesen en las intranet originales. Nunca pueden interactuar entre sí aunque usen las
mismas direcciones IP.
Las direcciones independientes (CA y CA), la configuración de directiva de los hosts de
Hyper-V y la traducción de direcciones entre la ENTIDAD de certificación y la PA para el
tráfico de máquina virtual entrante y saliente aíslan estos conjuntos de servidores
mediante la clave NVGRE o el VLXAN VNID. Además, las asignaciones de virtualización y
la transformación desacoplan la arquitectura de la red virtual de la infraestructura de la
red física. Si bien Contoso SQL y Web y Fabrikam SQL y Web residen en sus propias
subredes IP CA (10.1.1/24), las implementaciones físicas se producen en dos hosts de
diferentes subredes PA, 192.168.1/24 y 192.168.2/24, respectivamente. La implicación es
que el aprovisionamiento de máquinas virtuales entre subredes y la migración en vivo
son posibles con HNV.

Arquitectura de Virtualización de red de Hyper-

V
En Windows Server 2016, HNVv2 se implementa mediante azure Virtual Filtering
Platform (VFP), que es una extensión de filtrado NDIS dentro del conmutador de Hyper-
V. El concepto clave de VFP es el de un motor de flujo de Match-Action con una API
interna expuesta al agente de host de SDN para programar la directiva de red. El propio
agente de host de SDN recibe la directiva de red de la controladora de red a través de
los canales de comunicación OVSDB y WCF SouthBound. No solo es la directiva de red
virtual (por ejemplo, la asignación de CA-PA) programada mediante VFP, sino también
una directiva adicional, como ACL, QoS, etc.

La jerarquía de objetos para la extensión de reenvío de vSwitch y VFP es la siguiente:

Vswitch

Administración externa de NIC

Descargas de hardware NIC

Reglas de reenvío global

Port

Egress capa de reenvío para el anclaje del cabello

Listas de espacios para asignaciones y grupos NAT

Tabla de Flow unificada

Capa VFP

Flow tabla
 Grupo

Regla
Las reglas pueden hacer referencia a espacios

En la VFP, se crea una capa por tipo de directiva (por ejemplo, Virtual Network) y es un
conjunto genérico de tablas de reglas y flujos. No tiene ninguna funcionalidad intrínseca
hasta que se asignen reglas específicas a esa capa para implementar dicha
funcionalidad. A cada capa se le asigna una prioridad y las capas se asignan a un puerto
por prioridad ascendente. Las reglas se organizan en grupos basados principalmente en
la dirección y la familia de direcciones IP. A los grupos también se les asigna una
prioridad y, como máximo, una regla de un grupo puede coincidir con un flujo
determinado.

La lógica de reenvío para vSwitch con la extensión VFP es la siguiente:

Procesamiento de entrada (entrada desde el punto de vista del paquete que entra
en un puerto)

Reenvío

Egress procesamiento (salida desde el punto de vista del paquete que sale de un
puerto)

VFP admite el reenvío interno de MAC para los tipos de encapsulación NVGRE y VXLAN,
así como el reenvío basado en MAC VLAN externo.

La extensión VFP tiene una ruta de acceso lenta y una ruta de acceso rápida para el
recorrido de paquetes. El primer paquete de un flujo debe atravesar todos los grupos de
reglas de cada capa y realizar una búsqueda de reglas que sea una operación costosa.
Sin embargo, una vez que se registra un flujo en la tabla de flujo unificado con una lista
de acciones (según las reglas coincidentes), todos los paquetes posteriores se
procesarán en función de las entradas de la tabla de flujo unificada.

El agente host programa la directiva de HNV. Cada adaptador de red de máquina virtual
se configura con una dirección IPv4. Estas son las CA que utilizarán las máquinas
virtuales para comunicarse entre sí y se pueden transportar en los paquetes IP desde las
máquinas virtuales. HNV encapsula el marco de entidad de certificación en un marco PA
en función de las directivas de virtualización de red almacenadas en la base de datos del
agente host.
Figura 9: Arquitectura de HNV

Resumen
Los centros de datos basados en la nube pueden proporcionar muchos beneficios como
mayor escalabilidad y mejor utilización de los recursos. Advertir estos beneficios
potenciales requiere una tecnología que fundamentalmente aborde los problemas de
escalabilidad multiempresa en un entorno dinámico. HNV se diseñó para abordar estos
problemas y también mejorar la eficacia operativa del centro de datos al desacoplar la
topología de red virtual para la topología de red física. Basándose en un estándar
existente, HNV se ejecuta en el centro de datos actual y funciona con su infraestructura
VXLAN existente. Los clientes con HNV ahora pueden consolidar sus centros de datos
en una nube privada o ampliar sin problemas sus centros de datos a un entorno del
proveedor de servidores de hospedaje con una nube híbrida.

Vea también
Para más información sobre HNVv2, consulte los vínculos siguientes:
Tipo de Referencias
contenido

Recursos de - Blog de arquitectura de nube privada

comunidad - Formule preguntas: cloudnetfb@[Link]

RFC - NVGRE Draft RFC

- VXLAN: RFC 7348

Tecnologías - Para obtener Virtualización de red de Hyper-V detalles técnicos en Windows

relacionadas Server 2012 R2 , consulte Virtualización de red de Hyper-V detalles técnicos.
- Controladora de red
Novedades de Virtualización de red de
Hyper-V en Windows Server
Artículo • 21/12/2022 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En este tema se describe la funcionalidad de virtualización de red de Hyper-V (HNV)

nueva o modificada en Windows Server.

Actualizaciones en HNV
HNV ofrece compatibilidad mejorada en las siguientes áreas:

Característica/función Nueva o Descripción

mejorada

Conmutador de Hyper-V Nuevo La directiva de HNV se puede programar a través

programable de la controladora de red de Microsoft.

Compatibilidad con la Nuevo HNV ahora admite la encapsulación VXLAN.

encapsulación de VXLAN

Interoperabilidad de Load Nuevo HNV está totalmente integrado con microsoft

Balancer de software (SLB) Software Load Balancer.

Encabezados Ethernet IEEE Se ha Compatible con los estándares IEEE Ethernet

compatibles mejorado

Conmutador de Hyper-V programable

HNV es un bloque de creación fundamental de la solución de redes definidas por
software (SDN) actualizada de Microsoft y está totalmente integrada en la pila de SDN.

La nueva controladora de red de Microsoft inserta directivas de HNV en un agente host

que se ejecuta en cada host mediante open vSwitch Database Management Protocol
(OVSDB) como la interfaz southbound (SBI). El Agente de host almacena esta directiva
mediante una personalización del esquema VTEP y programas reglas de flujo
complejas en un motor de flujo eficaz en el conmutador de Hyper-V.

El motor de flujo dentro del conmutador de Hyper-V es el mismo motor que se usa en
Microsoft Azure ™, que se ha demostrado a gran escala en la nube pública de Microsoft
Azure. Además, toda la pila de SDN a través de la controladora de red y el proveedor de
recursos de red (detalles próximamente) es coherente con Microsoft Azure, lo que
aporta la eficacia de la nube pública Microsoft Azure a nuestros clientes de proveedor
de servicios de hospedaje y empresa.

７ Nota

Para obtener más información sobre OVSDB, consulte RFC 7047 .

El conmutador de Hyper-V admite reglas de flujo sin estado y con estado basadas en
una simple "acción de coincidencia" dentro del motor de flujo de Microsoft.

Compatibilidad con la encapsulación de VXLAN

El protocolo Virtual eXtensible Local Area Network (VXLAN - RFC 7348 ) ha sido
ampliamente adoptado en el mercado, con soporte de proveedores como Cisco,
Brocade, Dell, HP y otros. HNV también admite este esquema de encapsulación
mediante el modo de distribución MAC a través de La controladora de red de Microsoft
para programar asignaciones de direcciones IP de red de superposición de inquilinos
(dirección de cliente o CA) a las direcciones IP de red subyacentes físicas (dirección del
proveedor o PA). Las descargas de tareas NVGRE y VXLAN se admiten para mejorar el
rendimiento a través de controladores de terceros.

Interoperabilidad de Load Balancer de software (SLB)

Windows Server 2016 incluye un equilibrador de carga de software (SLB) con
compatibilidad total con el tráfico de red virtual e interacción sin problemas con HNV. El
SLB se implementa a través del motor de flujo eficaz en el conmutador v-Switch del
plano de datos y se controla mediante la controladora de red para las asignaciones de
IP virtual (VIP) / IP dinámica (DIP).

Encabezados Ethernet IEEE compatibles

HNV implementa encabezados Ethernet L2 correctos para garantizar la
interoperabilidad con dispositivos físicos y virtuales de terceros que dependen de
protocolos estándar del sector. Microsoft garantiza que todos los paquetes transmitidos
tengan valores compatibles en todos los campos para garantizar esta interoperabilidad.
Además, se requerirá compatibilidad con jumbo Frames (MTU > 1780) en la red física L2
para tener en cuenta la sobrecarga de paquetes introducida por los protocolos de
encapsulación (NVGRE, VXLAN) a la vez que se garantiza que los invitados Virtual
Machines conectados a un HNV Virtual Network mantener una MTU de 1514.

Referencias adicionales
Información general sobre Virtualización de red de Hyper-V

Detalles técnicos de la Virtualización de red de Hyper-V

Redes definidas por software

Servicio DNS interno (iDNS) para SDN
Artículo • 21/12/2022 • Tiempo de lectura: 7 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versiones
21H2 y 20H2

Si trabaja para un proveedor de servicios en la nube (CSP) o Enterprise que planea implementar redes definidas
por software (SDN) en Windows Server, puede proporcionar servicios DNS a las cargas de trabajo de inquilino
hospedadas mediante DNS interno (iDNS), que se integra con SDN.

Las máquinas virtuales hospedadas y las aplicaciones requieren DNS para comunicarse dentro de sus propias
redes y con recursos externos en Internet. Con iDNS, puede proporcionar a los inquilinos servicios de resolución
de nombres DNS para su espacio de nombres aislado, local y para los recursos de Internet.

Dado que el servicio iDNS no es accesible desde redes virtuales de inquilino, aparte del proxy de iDNS, el
servidor no es vulnerable a actividades malintencionadas en redes de inquilinos.

Características clave

A continuación se muestran las características clave de iDNS.

Proporciona servicios de resolución de nombres DNS compartidos para cargas de trabajo de inquilino
Servicio DNS autoritativo para la resolución de nombres y el registro DNS en el espacio de nombres del
inquilino
Servicio DNS recursivo para la resolución de los nombres de Internet de las máquinas virtuales de los
inquilinos.
Si lo desea, puede configurar el hospedaje simultáneo de los nombres de tejido e inquilino.
Una solución DNS rentable: los inquilinos no necesitan implementar su propia infraestructura DNS.
Alta disponibilidad con la integración de Active Directory, que es necesaria.

Además de estas características, si le preocupa mantener abiertos los servidores DNS integrados de AD a
Internet, puede implementar servidores iDNS detrás de otro solucionador recursivo en la red perimetral.

Dado que iDNS es un servidor centralizado para todas las consultas DNS, un CSP o Enterprise también puede
implementar firewalls DNS de inquilino, aplicar filtros, detectar actividades malintencionadas y auditar
transacciones en una ubicación central.

Infraestructura de iDNS
La infraestructura de iDNS incluye servidores iDNS e proxy iDNS.

Servidores iDNS
iDNS incluye un conjunto de servidores DNS que hospedan datos específicos del inquilino, como registros de
recursos DNS de máquina virtual.

Los servidores de iDNS son los servidores autoritativos de sus zonas DNS internas y también actúan como una
resolución de nombres públicos cuando las máquinas virtuales de los inquilinos intentan conectarse a recursos
externos.

Todos los nombres de host de las máquinas virtuales en redes virtuales se almacenan como registros de recursos
DNS en la misma zona. Por ejemplo, si implementa iDNS para una zona denominada [Link], los registros
de recursos DNS de las máquinas virtuales de esa red se almacenan en la zona [Link].

Los nombres de dominio completos (FQDN) de las máquinas virtuales de los inquilinos se componen del
nombre del equipo y de la cadena del sufijo DNS de la red virtual, en formato GUID. Por ejemplo, si tiene una
máquina virtual de inquilino denominada TENANT1 que se encuentra en el Virtual Network contoso,local, el
FQDN de la máquina virtual es TENANT1. [Link], donde vn-guid es la cadena de sufijo DNS para
el Virtual Network.

７ Nota

Si es administrador de tejido, puede usar la infraestructura de CSP o Enterprise DNS como servidores iDNS
en lugar de implementar nuevos servidores DNS específicamente para su uso como servidores iDNS. Tanto
si implementa nuevos servidores para iDNS como si usa la infraestructura existente, iDNS se basa en Active
Directory para proporcionar alta disponibilidad. Por lo tanto, los servidores iDNS deben integrarse con
Active Directory.

Proxy de iDNS
El proxy de iDNS es un servicio de Windows que se ejecuta en cada host y que reenvía el inquilino Virtual
Network tráfico DNS al servidor iDNS.

En la ilustración siguiente se muestran las rutas de tráfico DNS de las redes virtuales del inquilino a través del
proxy iDNS al servidor iDNS e Internet.
Cómo implementar iDNS
Al implementar SDN en Windows Server 2016 mediante scripts, iDNS se incluye automáticamente en la
implementación.

Para obtener más información, vea los siguientes temas.

Implementación de una infraestructura de red definida por software con scripts

Descripción de los pasos de implementación de iDNS

Puede usar esta sección para comprender cómo se instala y configura iDNS al implementar SDN mediante
scripts.

A continuación se muestra un resumen de los pasos necesarios para implementar iDNS.

７ Nota

Si ha implementado SDN mediante scripts, no es necesario realizar ninguno de estos pasos. Los pasos se
proporcionan únicamente con fines informativos y de solución de problemas.
Paso 1: Implementación de DNS
Puede implementar un servidor DNS mediante el siguiente ejemplo Windows PowerShell comando.

PowerShell

Install-WindowsFeature DNS -IncludeManagementTools

Paso 2: Configurar la información de iDNS en controladora de red

Este segmento de script es una llamada DE REST realizada por el administrador a Controladora de red,
informándolo sobre la configuración de la zona iDNS, como la dirección IP del iDNSServer y la zona que se usa
para hospedar los nombres de iDNS.

Url: [Link]
Method: PUT
{
"properties": {
"connections": [
{
"managementAddresses": [
"[Link]"
],
"credential": {
"resourceRef": "/credentials/iDnsServer-Credentials"
},
"credentialType": "usernamePassword"
}
],
"zone": "[Link]"
}
}

７ Nota

Se trata de un extracto de la sección Configuración de configureIDns en SDNExpress.ps1. Para más

información, consulte Deploy a Software Defined Network infrastructure using scripts (implementación de
una infraestructura de red definida por software mediante scripts).

Paso 3: Configurar el servicio proxy de iDNS

El servicio proxy de iDNS se ejecuta en cada uno de los hosts de Hyper-V, lo que proporciona el puente entre las
redes virtuales de inquilinos y la red física donde se encuentran los servidores iDNS. Las siguientes claves del
Registro deben crearse en cada host de Hyper-V.

Puerto DNS: Puerto fijo 53

Clave del Registro =

HKLM\SYSTEM\CurrentControlSet\Services\NcHostAgent\Parameters\Plugins\Vnet\InfraServices\DnsProxyService"
ValueName = "Port"
ValueData = 53
ValueType = "Dword"
Puerto de proxy DNS: Puerto fijo 53

Clave del Registro =

HKLM\SYSTEM\CurrentControlSet\Services\NcHostAgent\Parameters\Plugins\Vnet\InfraServices\DnsProxyService"
ValueName = "ProxyPort"
ValueData = 53
ValueType = "Dword"

DIRECCIÓN IP DNS: Dirección IP fija configurada en la interfaz de red, en caso de que el inquilino elija usar el
servicio iDNS.

Clave del Registro =

HKLM\SYSTEM\CurrentControlSet\Services\NcHostAgent\Parameters\Plugins\Vnet\InfraServices\DnsProxyService"
ValueName = "IP"
ValueData = "[Link]"
ValueType = "String"

Dirección Mac: Dirección de Access Control multimedia del servidor DNS

Clave del Registro =

HKLM\SYSTEM\CurrentControlSet\Services\NcHostAgent\Parameters\Plugins\Vnet\InfraServices\DnsProxyService
ValueName = "MAC"
ValueData = "aa-bb-cc-aa-bb-cc"
ValueType = "String"

Dirección del servidor IDNS: Lista separada por comas de servidores iDNS.

Clave del Registro: HKLM\SYSTEM\CurrentControlSet\Services\DNSProxy\Parameters

ValueName = "Reenviadores"
ValueData = "[Link]"
ValueType = "String"

７ Nota

Este es un extracto de la sección Configuración de ConfigureIDnsProxy en SDNExpress.ps1. Para más

información, consulte Deploy a Software Defined Network infrastructure using scripts (implementación de
una infraestructura de red definida por software mediante scripts).

Paso 4: Reiniciar el servicio del agente host de controladora de red

Puede usar el siguiente comando Windows PowerShell para reiniciar el servicio del agente de host de
controladora de red.

PowerShell

Restart-Service nchostagent -Force

Para obtener más información, consulte Restart-Service.

Habilitación de reglas de firewall para el servicio de proxy DNS

Puede usar el siguiente comando Windows PowerShell para crear una regla de firewall que permita que las
excepciones del proxy se comuniquen con la máquina virtual y el servidor iDNS.
 PowerShell

Enable-NetFirewallRule -DisplayGroup 'DNS Proxy Firewall'

Para obtener más información, consulte Enable-NetFirewallRule.

Validación del servicio iDNS

Para validar el servicio iDNS, debe implementar una carga de trabajo de inquilino de ejemplo.

Para más información, consulte Creación de una máquina virtual y Conectar en un inquilino Virtual Network o
VLAN.

Si desea que la máquina virtual del inquilino use el servicio iDNS, debe dejar en blanco la configuración del
servidor DNS de interfaces de red de la máquina virtual y permitir que las interfaces usen DHCP.

Una vez iniciada la máquina virtual con dicha interfaz de red, recibe automáticamente una configuración que
permite a la máquina virtual usar iDNS y la máquina virtual comienza inmediatamente a realizar la resolución de
nombres mediante el servicio iDNS.

Si configura la máquina virtual del inquilino para usar el servicio iDNS dejando en blanco el servidor DNS de
interfaz de red y la información del servidor DNS alternativo, controladora de red proporciona la máquina virtual
con una dirección IP y realiza un registro de nombres DNS en nombre de la máquina virtual con el servidor
iDNS.

La controladora de red también informa al proxy iDNS sobre la máquina virtual y los detalles necesarios para
realizar la resolución de nombres para la máquina virtual.

Cuando la máquina virtual inicia una consulta DNS, el proxy actúa como reenviador de la consulta desde el
Virtual Network al servicio iDNS.

El proxy DNS también garantiza que las consultas de máquina virtual del inquilino estén aisladas. Si el servidor
iDNS es autoritativo para la consulta, el servidor iDNS responde con una respuesta autoritativa. Si el servidor
iDNS no es autoritativo para la consulta, realiza una recursividad dns para resolver los nombres de Internet.

７ Nota

Esta información se incluye en la sección Configuration AttachToVirtualNetwork en SDNExpressTenant.ps1.

Para más información, consulte Deploy a Software Defined Network infrastructure using scripts
(implementación de una infraestructura de red definida por software mediante scripts).
¿Qué es Controladora de red?
Artículo • 23/01/2023 • Tiempo de lectura: 5 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2; Windows Server 2022,
Windows Server 2019, Windows Server 2016

Controladora de red es la piedra angular en la administración de redes definidas por

software (SDN). Es un rol del servidor, altamente escalable, que proporciona un punto
de automatización programable y centralizado para administrar, configurar, supervisar y
solucionar problemas de la infraestructura de red virtual.

Mediante el uso de Controladora de red, puede automatizar la configuración y

administración de la infraestructura de red en lugar de realizar la configuración manual
de los dispositivos y servicios de red.

Funcionamiento de Controladora de red

Controladora de red proporciona una interfaz de programación de aplicaciones (API)
que permite a Controladora de red comunicarse con dispositivos, servicios y
componentes de red y administrarlos (Southbound API), y una segunda API que permite
a las aplicaciones de administración indicar a Controladora de red qué valores de red y
servicios son necesarios (Northbound API).

Con Southbound API, Controladora de red puede administrar dispositivos y servicios de

red, y recopilar toda la información que necesite sobre la red. Controladora de red
supervisa continuamente el estado de los dispositivos y servicios de red, y garantiza la
corrección de cualquier desfase de configuración con respecto al estado deseado.

La API Northbound de Controladora de red se implementa como una interfaz REST.

Proporciona la posibilidad de administrar la red del centro de datos desde las
aplicaciones de administración. Para la administración, los usuarios pueden usar la API
REST directamente o usar la instancia de Windows PowerShell basada en ella, o
aplicaciones de administración con una interfaz gráfica de usuario como Windows
Admin Center o System Center Virtual Machine Manager.

Para más información sobre estos cmdlets de PowerShell, consulte la referencia sobre
NetworkController.

Características de Controladora de red

Controladora de red le permite administrar características de SDN como redes virtuales,
firewalls, equilibrador de carga de software y puerta de enlace de RAS. A continuación
se muestran algunas de sus numerosas características.

Administración de red virtual

Esta característica de Controladora de red le permite implementar y configurar la
virtualización de red de Hyper-V, configurar adaptadores de red virtuales en máquinas
virtuales individuales y almacenar y distribuir directivas de red virtual. Con esta
característica, puede crear redes virtuales y subredes, conectar máquinas virtuales a
estas redes y habilitar la comunicación entre las máquinas virtuales de la misma red
virtual.

Controladora de red admite redes basadas en red de área local virtual (VLAN),
virtualización de red para encapsulación de enrutamiento genérico (NVGRE) y red de
área local virtual extensible (VXLAN).

Administración del firewall

Esta característica de Controladora de red le permite configurar y administrar reglas de
control de acceso de permiso o denegación en el firewall para las máquinas virtuales de
carga de trabajo, tanto para el tráfico interno (horizontal de derecha a izquierda) como
externo (vertical de arriba a abajo) del centro de datos. Las reglas de firewall se asocian
en el puerto vSwitch de las máquinas virtuales de carga de trabajo y, por tanto, se
distribuyen entre las cargas de trabajo del centro de datos y se mueven junto con las
cargas de trabajo.

Puede utilizar Northbound API para definir las reglas de firewall para el tráfico entrante
y saliente de las máquinas virtuales de carga de trabajo. También puede configurar cada
regla de firewall para que registre el tráfico al que permite o deniega el paso.

Administración del equilibrador de carga de

software
El equilibrador de carga de software le permite habilitar varios servidores para que
hospeden la misma carga de trabajo, lo que proporciona una alta disponibilidad y
escalabilidad. Con el equilibrador de carga de software, puede configurar y administrar
el equilibrio de carga, la traducción de direcciones de red de entrada y el acceso de
salida a Internet de las cargas de trabajo conectadas a redes VLAN y a redes virtuales
tradicionales.
Administración de la puerta de enlace
La puerta de enlace de Servicio de acceso remoto (RAS) le permite implementar,
configurar y administrar máquinas virtuales que pertenecen a un grupo de puertas de
enlace, lo que proporciona conectividad de red externa a las cargas de trabajo del
cliente. Con las puertas de enlace, se admiten los siguientes tipos de conectividad entre
las redes virtuales y remotas:

Conectividad de puerta de enlace de red privada virtual (VPN) de sitio a sitio

mediante IPsec
Conectividad de puerta de enlace de VPN de sitio a sitio mediante la
encapsulación de enrutamiento genérico (GRE)
Funcionalidad de reenvío de nivel 3

Las conexiones de puerta de enlace admiten Protocolo de puerta de enlace de borde

(BGP) para la administración de rutas dinámicas.

Encadenamiento de aplicaciones virtuales

Esta característica de Controladora de red le permite conectar aplicaciones de red virtual
a sus redes virtuales. Estos dispositivos se pueden usar en firewalls avanzados, equilibrio
de carga, detección y prevención de intrusiones y muchos otros servicios de red. Puede
añadir aplicaciones virtuales que realicen funciones de enrutamiento definido por el
usuario y de creación de reflejo del puerto. Con el enrutamiento definido por el usuario,
la aplicación virtual se usa como un enrutador entre las subredes virtuales de la red
virtual. Con la creación de reflejo del puerto, todo el tráfico de red que entra o sale del
puerto supervisado se duplica y se envía a una aplicación virtual para su análisis.

Para más información acerca de las rutas definidas por el usuario, consulte Uso de
aplicaciones virtuales de red en una red virtual.

Consideraciones sobre la implementación de

Controladora de red
No implemente el rol del servidor Controladora de red en hosts físicos.
Controladora de red debe implementarse en sus propias máquinas virtuales
dedicadas.

Puede implementar Controladora de red en entornos de dominio y en entornos

que no pertenecen a un dominio. En entornos de dominio, Controladora de red
 autentica los usuarios y dispositivos de red mediante Kerberos. En entornos que no
son de dominio, debe implementar certificados para la autenticación.

Es fundamental que las implementaciones de Controladora de red proporcionen

alta disponibilidad y la posibilidad de escalar o reducir verticalmente con facilidad
según las necesidades del centro de datos. Use al menos tres máquinas virtuales
para proporcionar alta disponibilidad a la aplicación Controladora de red.

Para lograr una alta disponibilidad y escalabilidad, Controladora de red se basa en

Service Fabric. Service Fabric proporciona una plataforma de sistemas distribuidos
que se usa para crear aplicaciones escalables, confiables y fáciles de administrar
para la nube. Más información acerca de Controladora de red como una aplicación
de Service Fabric.

Pasos siguientes
Para obtener información relacionada, consulte:

Plan de implementación de Controladora de red

Implementación de controladora de red con Windows PowerShell
SDN en Azure Stack HCI y Windows Server
Alta disponibilidad de la controladora
de red
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Puede usar este tema para obtener información sobre la configuración de alta
disponibilidad y escalabilidad de controladora de red para redes definidas por software
(SDN).

Al implementar SDN en el centro de datos, puede usar controladora de red para

implementar, supervisar y administrar de forma centralizada muchos elementos de red,
como puertas de enlace ras, equilibradores de carga de software, directivas de redes
virtuales para la comunicación de inquilinos, directivas de firewall del centro de datos,
calidad de servicio (QoS) para directivas sdN, directivas de redes híbridas, etc.

Dado que La controladora de red es la piedra angular de la administración de SDN, es

fundamental que las implementaciones de controladora de red proporcionen alta
disponibilidad y la capacidad de escalar o reducir fácilmente los nodos de controladora
de red con sus necesidades del centro de datos.

Aunque puede implementar Controladora de red como un único clúster de máquinas,

para lograr una alta disponibilidad y conmutación por error, debe implementar
Controladora de red en un clúster de varias máquinas con un mínimo de tres máquinas.

７ Nota

Puede implementar controladora de red en equipos de servidor o en máquinas

virtuales (VM) que ejecutan Windows Server 2016 Datacenter Edition. Si
implementa controladora de red en máquinas virtuales, las máquinas virtuales
deben ejecutarse en hosts de Hyper-V que también ejecuten Datacenter Edition. La
controladora de red no está disponible en Windows Server 2016 edición Standard.

Controladora de red como una aplicación de

Service Fabric
Para lograr una alta disponibilidad y escalabilidad, Controladora de red se basa en
Service Fabric. Service Fabric proporciona una plataforma de sistemas distribuidos para
crear aplicaciones escalables, confiables y fácilmente administradas.

Como plataforma, Service Fabric proporciona funcionalidad necesaria para crear un

sistema distribuido escalable. Proporciona hospedaje de servicios en varias instancias
del sistema operativo, sincronizando información de estado entre instancias, eligiendo
un líder, detección de errores, equilibrio de carga, etc.

７ Nota

Para obtener información sobre Service Fabric en Azure, consulte Introducción a

Azure Service Fabric.

Al implementar controladora de red en varias máquinas, la controladora de red se

ejecuta como una sola aplicación de Service Fabric en un clúster de Service Fabric.
Puede formar un clúster de Service Fabric conectando un conjunto de instancias de
sistema operativo.

La aplicación controladora de red se compone de varios servicios de Service Fabric con

estado. Cada servicio es responsable de una función de red, como la administración de
redes físicas, la administración de redes virtuales, la administración de firewalls o la
administración de puertas de enlace.

Cada servicio Service Fabric tiene una réplica principal y dos réplicas secundarias. La
réplica de servicio principal procesa las solicitudes, mientras que las dos réplicas de
servicio secundarias proporcionan alta disponibilidad en circunstancias en las que la
réplica principal está deshabilitada o no está disponible por algún motivo.

En la ilustración siguiente se muestra un clúster de controladora de red Service Fabric

con cinco máquinas. Cuatro servicios se distribuyen entre las cinco máquinas: servicio de
firewall, servicio de puerta de enlace, servicio de equilibrio de carga de software (SLB) y
servicio de red virtual (Vnet). Cada uno de los cuatro servicios incluye una réplica de
servicio principal y dos réplicas de servicio secundarias.
Ventajas de usar Service Fabric
A continuación se muestran las principales ventajas de usar Service Fabric para clústeres
de Controladora de red.

Alta disponibilidad y escalabilidad

Dado que La controladora de red es el núcleo de una red del centro de datos, debe ser
resistente al error y ser lo suficientemente escalable como para permitir cambios ágiles
en las redes del centro de datos a lo largo del tiempo. Las siguientes características
proporcionan estas capacidades:

Conmutación por error rápida. Service Fabric proporciona una conmutación por
error extremadamente rápida. Varias réplicas de servicio secundaria activa siempre
están disponibles. Si una instancia del sistema operativo deja de estar disponible
debido a un error de hardware, una de las réplicas secundarias se promueve
inmediatamente a la réplica principal.
Agilidad de escala. Puede escalar fácilmente y rápidamente estos servicios de
confianza desde algunas instancias hasta miles de instancias y, a continuación,
volver a reducir a unas pocas instancias, en función de sus necesidades de
recursos.

Almacenamiento persistente
La aplicación Controladora de red tiene grandes requisitos de almacenamiento para su
configuración y estado. La aplicación también debe poder usarse en interrupciones
planeadas y no planeadas. Para ello, Service Fabric proporciona un almacén Key-Value
Store (KVS) que es un almacén replicado, transaccional y persistente.

Modularidad
La controladora de red está diseñada con una arquitectura modular, con cada uno de
los servicios de red, como el servicio de redes virtuales y el servicio de firewall,
integrados como servicios individuales.

Esta arquitectura de aplicación proporciona las siguientes ventajas.

1. La modularidad de la controladora de red permite el desarrollo independiente de

cada uno de los servicios admitidos, a medida que evolucionan las necesidades.
Por ejemplo, el servicio equilibrio de carga de software se puede actualizar sin
afectar a ninguno de los demás servicios o al funcionamiento normal de la
controladora de red.
2. La modularidad de la controladora de red permite agregar nuevos servicios a
medida que evoluciona la red. Se pueden agregar nuevos servicios a la
controladora de red sin afectar a los servicios existentes.

７ Nota

En Windows Server 2016, no se admite la adición de servicios de terceros a la

controladora de red.

Service Fabric modularidad usa esquemas de modelo de servicio para maximizar la

facilidad de desarrollo, implementación y mantenimiento de una aplicación.

Opciones de implementación de la
controladora de red
Para implementar controladora de red mediante System Center Virtual Machine
Manager (VMM), consulte Configuración de una controladora de red SDN en el tejido
de VMM.

Para implementar la controladora de red mediante scripts, consulte Implementación de

una infraestructura de red definida por software mediante scripts.

Para implementar controladora de red mediante Windows PowerShell, consulte

Implementación de controladora de red mediante Windows PowerShell
Para obtener más información sobre controladora de red, consulte Controladora de red.
Instalación del rol de servidor de
controladora de red mediante
Administrador del servidor
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En este tema se proporcionan instrucciones sobre cómo instalar el rol de servidor

controladora de red mediante Administrador del servidor.

） Importante

No implemente el rol del servidor Controladora de red en hosts físicos. Para

implementar la controladora de red, debe instalar el rol de servidor controladora de
red en una máquina virtual (VM) de Hyper-V instalada en un host de Hyper-V.
Después de instalar la controladora de red en máquinas virtuales en tres hosts de
Hyper-V diferentes, debe habilitar los hosts de Hyper-V para redes definidas por
software (SDN) agregando los hosts a La controladora de red mediante el comando
Windows PowerShell comando New-NetworkControllerServer. Al hacerlo, permite
funcionar al equilibrador de carga de las redes definidas por software. Para obtener
más información, vea New-NetworkControllerServer.

Después de instalar controladora de red, debe usar Windows PowerShell comandos para
una configuración adicional de controladora de red. Para obtener más información,
consulte Implementación de controladora de red mediante Windows PowerShell.

Para instalar controladora de red

1. En el Administrador del servidor, haga clic en Administrar y en Agregar roles y
características. Se abre el asistente para Agregar roles y características. Haga clic
en Next.

2. En Seleccionar tipo de instalación, mantenga la configuración predeterminada y

haga clic en Siguiente.

3. En Seleccionar servidor de destino, elija el servidor donde desea instalar

controladora de red y, a continuación, haga clic en Siguiente.
4. En Seleccionar roles de servidor, en Roles, haga clic en Controladora de red.

5. Se abre el cuadro de diálogo Agregar características necesarias para controladora

de red . Haga clic en Agregar características.

6. En Seleccionar roles de servidor, haga clic en Siguiente.

7. En Seleccionar características, haga clic en Siguiente.

8. En Controladora de red , haga clic en Siguiente.

9. En Confirmar selecciones de instalación, revise las opciones. La instalación de la

controladora de red requiere que reinicie el equipo una vez que se ejecute el
asistente. Por este motivo, haga clic en Reiniciar el servidor de destino
automáticamente si es necesario. Se abre el cuadro de diálogo Asistente para
agregar roles y características . Haga clic en Sí.
 10. En Confirmar selecciones de instalación, haga clic en Instalar.

11. El rol de servidor controladora de red se instala en el servidor de destino y, a

continuación, se reinicia el servidor.

12. Después de reiniciar el equipo, inicie sesión en el equipo y compruebe la

instalación de controladora de red viendo Administrador del servidor.

Consulte también
Controladora de red
Pasos posteriores a la implementación
para la Controladora de red
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Al instalar controladora de red, puede elegir implementaciones kerberos o no Kerberos.

En el caso de las implementaciones que no son de Kerberos, debe configurar

certificados.

Configuración de certificados para

implementaciones que no son de Kerberos
Si los equipos o máquinas virtuales (VM) de Controladora de red y el cliente de
administración no están unidos a un dominio, debe configurar la autenticación basada
en certificados siguiendo estos pasos.

Cree un certificado en la controladora de red para la autenticación del equipo. El

nombre del sujeto del certificado debe ser el mismo que el nombre DNS del
equipo o la máquina virtual de controladora de red.

Cree un certificado en el cliente de administración. La controladora de red debe

confiar en este certificado.

Inscriba un certificado en el equipo o la máquina virtual de controladora de red. El

certificado debe cumplir los siguientes requisitos.

Tanto el propósito de autenticación de servidor como el propósito de

autenticación de cliente deben configurarse en las extensiones Uso mejorado
de claves (EKU) o Directivas de aplicación. El identificador de objeto para la
autenticación del servidor es [Link].[Link].1. El identificador de objeto para la
autenticación de cliente es [Link].[Link].2.

El nombre del sujeto del certificado debe resolverse en:

Dirección IP del equipo o la máquina virtual de controladora de red, si

controladora de red se implementa en un solo equipo o máquina virtual.
 La dirección IP rest, si controladora de red se implementa en varios equipos,
varias máquinas virtuales o ambos.

Todos los clientes REST deben confiar en este certificado. El certificado también
debe ser de confianza para el multiplexor de equilibrio de carga de software
(SLB) (MUX) y los equipos host de conexión sur administrados por controladora
de red.

El certificado se puede inscribir mediante una entidad de certificación (CA) o

puede ser un certificado autofirmado. Los certificados autofirmados no se
recomiendan para las implementaciones de producción, pero son aceptables
para entornos de laboratorio de pruebas.

El mismo certificado debe aprovisionarse en todos los nodos de controladora

de red. Después de crear el certificado en un nodo, puede exportarlo (con clave
privada) e importarlo en los demás nodos.

Para obtener más información, consulte Controladora de red.

Virtualización de función de red
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Puede usar este tema para obtener información sobre la virtualización de funciones de
red, lo que le permite implementar aplicaciones de red virtuales como El firewall del
centro de datos, la puerta de enlace RAS multiinquilino y el multiplexador de equilibrio
de carga de software (SLB) (MUX).

７ Nota

Además de este tema, está disponible la siguiente documentación sobre

virtualización de funciones de red.

Información general de Datacenter Firewall

Puerta de enlace RAS para SDN
Equilibrio de carga de software (SLB) para SDN

En los centros de datos definidos por software de hoy en día, las funciones de red que
realizan los dispositivos de hardware (como equilibradores de carga, firewalls,
enrutadores, conmutadores, etc.) se virtualizan cada vez más como aplicaciones
virtuales. Esta “virtualización de las funciones de red” es la progresión natural de la
virtualización de los servidores y de la red. Las aplicaciones virtuales están emergentes
rápidamente y crean un nuevo mercado. Siguen generando interés y ganando impulso
tanto en plataformas de virtualización como en servicios en la nube.

Microsoft incluía una puerta de enlace independiente como una aplicación virtual a
partir de Windows Server 2012 R2 . Para obtener más información, vea Puerta de enlace
de Windows Server. Ahora, con Windows Server 2016 Microsoft continúa expandiendo e
invirtiendo en el mercado de virtualización de funciones de red.

Ventajas de la aplicación virtual

Una aplicación virtual es dinámica y fácil de cambiar porque es una máquina virtual
pregenerada y personalizada. Puede ser una o varias máquinas virtuales empaquetadas,
actualizadas y mantenidas como una unidad. Junto con las redes definidas por software
(SDN), obtendrá la agilidad y flexibilidad necesarias en la infraestructura basada en la
nube actual. Por ejemplo:

SDN presenta la red como un recurso dinámico y agrupado.

SDN facilita el aislamiento del inquilino.

SDN maximiza la escala y el rendimiento.

Las aplicaciones virtuales permiten una expansión de la capacidad sin problemas y

la movilidad de cargas de trabajo.

Las aplicaciones virtuales minimizan la complejidad operativa.

Las aplicaciones virtuales permiten a los clientes adquirir, implementar y

administrar fácilmente soluciones preintegradas.

Los clientes pueden mover fácilmente la aplicación virtual en cualquier lugar de

la nube.

Los clientes pueden escalar o reducir verticalmente las aplicaciones virtuales de

forma dinámica en función de la demanda.

Para obtener más información sobre Microsoft SDN, consulte Redes definidas por
software.

¿Qué funciones de red se virtualizan?

El marketplace para las funciones de red virtualizadas está creciendo rápidamente. Se
están virtualizando las siguientes funciones de red:

Seguridad

Firewall

Antivirus

DDoS (denegación de servicio distribuida)

IPS/IDS (Sistema de prevención de intrusiones/Sistema de detección de

intrusiones)

Optimizadores de aplicaciones o WAN

Edge

Puerta de enlace de sitio a sitio

 Puertas de enlace L3

Enrutadores

Modificadores

NAT

Equilibradores de carga (no necesariamente en el perímetro)

Proxy HTTP

Por qué Microsoft es una excelente plataforma

para aplicaciones virtuales

La plataforma Microsoft se ha diseñado para ser una excelente plataforma para compilar
e implementar aplicaciones virtuales. El motivo es el siguiente:

Microsoft proporciona funciones de red virtualizadas clave con Windows Server

2016.

Puede implementar una aplicación virtual desde el proveedor que prefiera.

Puede implementar, configurar y administrar las aplicaciones virtuales con la

controladora de red de Microsoft que incluye Windows Server 2016. Para obtener
más información sobre la controladora de red, consulte Controladora de red.

Hyper-V puede hospedar los principales sistemas operativos invitados que

necesita.
Virtualización de funciones de red en Windows
Server 2016

Funciones de aplicaciones virtuales proporcionadas por

Microsoft
Las siguientes aplicaciones virtuales se proporcionan con Windows Server 2016:

Equilibrador de carga de software

Un equilibrador de carga de nivel 4 que funciona a escala del centro de datos. Se trata
de una versión similar del equilibrador de carga de Azure que se ha implementado a
escala en el entorno de Azure. Para obtener más información sobre microsoft Software
Load Balancer, consulte Equilibrio de carga de software (SLB) para SDN. Para obtener
más información sobre Microsoft Azure Servicios de equilibrio de carga, consulte
Microsoft Azure Servicios de equilibrio de carga .

Puerta de enlace. La puerta de enlace ras proporciona todas las combinaciones de las
siguientes funciones de puerta de enlace.

Puerta de enlace de sitio a sitio

La puerta de enlace ras proporciona una puerta de enlace de borde (BGP)

compatible con puertas de enlace multiinquilino que permite a los inquilinos
acceder y administrar sus recursos a través de conexiones VPN de sitio a sitio
desde sitios remotos y que permite el flujo de tráfico de red entre los recursos
virtuales en la nube y las redes físicas del inquilino. Para más información sobre la
puerta de enlace ras, consulte Alta disponibilidad de puerta de enlace ras y puerta
de enlace ras.

Puerta de enlace de reenvío

La puerta de enlace ras enruta el tráfico entre las redes virtuales y la red física del
proveedor de hospedaje. Por ejemplo, si los inquilinos crean una o varias redes
virtuales y necesitan acceso a los recursos compartidos de la red física en el
proveedor de hospedaje, la puerta de enlace de reenvío puede enrutar el tráfico
entre la red virtual y la red física para proporcionar a los usuarios que trabajan en
la red virtual con los servicios que necesitan. Para más información, consulte Alta
disponibilidad de puerta de enlace ras y puerta de enlace ras.

Puertas de enlace de túnel GRE

 Los túneles basados en GRE habilitan la conectividad entre redes virtuales de
inquilinos y redes externas. Dado que el protocolo GRE es ligero y la
compatibilidad con GRE está disponible en la mayoría de los dispositivos de red, se
convierte en una opción ideal para la tunelización donde no se requiere el cifrado
de datos. La compatibilidad con GRE de los túneles de sitio a sitio (S2S) soluciona
el problema de reenvío entre redes virtuales de inquilinos y redes externas de
inquilinos mediante una puerta de enlace de varios inquilinos. Para obtener más
información sobre los túneles GRE, consulte Tunelización gre en Windows Server
2016.

Plano de control de enrutamiento con BGP

El control de enrutamiento de virtualización de red de Hyper-V (HNV) es la entidad

lógica y centralizada en el plano de control, que lleva todas las rutas del plano de
dirección del cliente y aprende dinámicamente y, a continuación, actualiza los
enrutadores distribuidos de puerta de enlace ras en la red virtual. Para más información,
consulte Alta disponibilidad de puerta de enlace ras y puerta de enlace ras.

Firewall multiinquilino distribuido

El firewall protege la capa de red de redes virtuales. Las directivas se aplican en el puerto
SDN-vSwitch de cada máquina virtual de inquilino. Protege todos los flujos de tráfico:
este-oeste y norte-sur. Las directivas se insertan a través del portal de inquilinos y la
controladora de red las distribuye a todos los hosts aplicables. Para más información
sobre el firewall multiinquilino distribuido, consulte Introducción al firewall del centro de
datos.
¿Qué es un firewall del centro de datos?
Artículo • 23/01/2023 • Tiempo de lectura: 2 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2; Windows Server 2022,
Windows Server 2019, Windows Server 2016

El firewall del centro de datos es un firewall de redes definidas por software (SDN)
multiinquilino, del nivel de red, 5-tuplas (protocolo, números de puerto de origen y de
destino, direcciones IP de origen y de destino) y con estado. El firewall del centro de
datos protege los flujos de tráfico horizontales de derecha a izquierda y verticales de
arriba abajo en el nivel de red de las redes virtuales y redes VLAN tradicionales.

Funcionamiento del firewall del centro de datos

Para habilitar y configurar El firewall del centro de datos, cree grupos de seguridad de
red (NSG) que se apliquen a una subred o a una interfaz de red. Las directivas del
firewall se aplican en el puerto vSwitch de cada máquina virtual de inquilino. Las
directivas se insertan mediante el portal del inquilino y Controladora de red las
distribuye a todos los hosts aplicables.

Los administradores de inquilinos pueden instalar y configurar directivas de firewall para

ayudar a proteger sus redes contra tráfico no deseado procedente de redes de Internet
e intranet.
El administrador del proveedor de servicios o el administrador de inquilinos puede
administrar las directivas del firewall del centro de datos mediante Controladora de red
y las API de Northbound. También puede configurar y administrar las directivas del
firewall del centro de datos mediante Windows Admin Center.

Ventajas de los proveedores de servicios en la

nube
El firewall del centro de datos ofrece las siguientes ventajas para los proveedores de
servicios criptográficos (CSP):

Una solución de firewall basada en software, muy escalable, administrable y de

fácil diagnóstico que se puede ofrecer a los inquilinos.

Libertad para trasladar máquinas virtuales de inquilino a distintos hosts de proceso

sin interrumpir las directivas del firewall de inquilino.

Se implementa como un firewall del agente de host del puerto vSwitch.

Las máquinas virtuales de inquilino obtienen las directivas asignadas a su

firewall del agente de host de vSwitch.

Las reglas del firewall se configuran en cada puerto vSwitch,

independientemente del host real que ejecuta la máquina virtual.
 Ofrece protección a las máquinas virtuales de inquilinos independientemente del
sistema operativo invitado del inquilino.

Ventajas para los inquilinos

El firewall del centro de datos ofrece las siguientes ventajas para los inquilinos:

Posibilidad de definir reglas de firewall para ayudar a proteger cargas de trabajo

con conexión a Internet y cargas de trabajo internas en redes.

Posibilidad de definir reglas de firewall para ayudar a proteger el tráfico entre

máquinas virtuales en la misma subred de nivel 2 (L2), así como entre máquinas
virtuales en subredes L2 diferentes.

Posibilidad de definir reglas de firewall para ayudar a proteger y aislar el tráfico de

red entre las redes locales de inquilinos y sus redes virtuales en el proveedor de
servicios.

Posibilidad de aplicar directivas de firewall a redes VLAN tradicionales y redes

virtuales basadas en superposición

Pasos siguientes
Para obtener información relacionada, consulte:

Uso del firewall del centro de datos para configurar listas de control de acceso con
Windows Admin Center
Uso del firewall del centro de datos para configurar ACL con PowerShell
SDN en Azure Stack HCI y Windows Server
Módulo de Learn: Implementación de Firewall de centro de datos y Equilibrador de
carga de software en Azure Stack HCI
¿Qué es la puerta de enlace del servicio
de acceso remoto (RAS) para redes
definidas por software?
Artículo • 23/01/2023 • Tiempo de lectura: 5 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2; Windows Server 2022,
Windows Server 2019, Windows Server 2016

La puerta de enlace de RAS es un enrutador compatible con el Protocolo de puerta de

enlace de borde (BGP), basado en software y diseñado para los proveedores de servicios
en la nube (CSP) y las empresas que hospedan redes virtuales multiinquilino con la
virtualización de red de Hyper-V (HNV). Puede usar la puerta de enlace de RAS para
enrutar el tráfico de red entre una red virtual y otra red, ya sea local o remota.

La puerta de enlace de RAS requiere Controladora de red, ya que este rol realiza la
implementación de grupos de puertas de enlace, configura las conexiones de inquilino
en cada puerta de enlace y cambia los flujos de tráfico de red a una puerta de enlace en
espera en caso de error de una puerta de enlace.

７ Nota

La arquitectura multiempresa es la capacidad que tiene una infraestructura en la

nube de admitir las cargas de trabajo de las máquinas virtuales de varios inquilinos
aislándolas unas de otras y permitiendo que todas las cargas de trabajo se ejecuten
en la misma infraestructura. Las distintas cargas de trabajo de un inquilino
individual pueden interconectarse y administrarse de manera remota, pero estos
sistemas no se interconectan con las cargas de trabajo de los demás inquilinos, ni
tampoco pueden los demás inquilinos administrarlas de manera remota.

Características
La puerta de enlace de RAS ofrece una serie de características para redes privadas
virtuales (VPN), tunelización, reenvío y enrutamiento dinámico.

VPN de sitio a sitio (IPsec)

Esta característica de puerta de enlace de RAS le permite conectar dos redes en
diferentes ubicaciones físicas a través de Internet mediante una conexión de red privada
virtual de sitio a sitio (S2S). Se trata de una conexión cifrada que usa el protocolo VPN
IKEv2.

Para los proveedores de servicios en la nube que hospedan muchos inquilinos en su

centro de datos, la puerta de enlace de RAS proporciona una solución de puerta de
enlace multiinquilino que permite a los inquilinos acceder a sus recursos y
administrarlos mediante conexiones VPN de sitio a sitio desde sitios remotos. La puerta
de enlace de RAS permite el flujo de tráfico de red entre los recursos virtuales del centro
de datos y la red física.

Túneles de sitio a sitio basados en la encapsulación de

enrutamiento genérico (GRE)
Los túneles basados en la encapsulación de enrutamiento genérico (GRE) permiten la
conectividad entre redes virtuales de inquilino y redes externas. Dado que el protocolo
GRE es ligero y la compatibilidad con GRE está disponible para la mayoría de los
dispositivos de red, es una opción ideal para la tunelización en aquellos casos donde no
se requiere el cifrado de datos.

La compatibilidad con GRE en túneles de sitio a sitio resuelve el problema del reenvío
entre redes virtuales de inquilinos y redes externas de inquilinos mediante una puerta
de enlace multiinquilino.

Reenvío de capa 3
El reenvío de capa 3 (L3) permite la conectividad entre la infraestructura física del centro
de datos y la infraestructura virtualizada de la nube de virtualización de red de Hyper-V.
Mediante una conexión de reenvío de nivel 3, las máquinas virtuales de red de
inquilinos pueden conectarse a una red física a través de la puerta de enlace de SDN, la
cual ya está configurada en un entorno de redes definidas por software. En este caso, la
puerta de enlace de SDN actúa como un enrutador entre la red virtualizada y la red
física.

Enrutamiento dinámico con BGP

BGP reduce la necesidad de configuración de enrutamiento manual en los enrutadores,
ya que es un protocolo de enrutamiento dinámico y aprende automáticamente las rutas
entre sitios que están conectados mediante conexiones VPN de sitio a sitio. Si su
organización tiene varios sitios que están conectados mediante enrutadores habilitados
para BGP, como la puerta de enlace de RAS, el BGP permitirá a los enrutadores calcular
y usar rutas válidas entre sí automáticamente en caso de que se produzcan
interrupciones o errores en la red.

El reflector de rutas BGP incluido con la puerta de enlace de RAS proporciona una
alternativa a la topología de malla completa BGP necesaria para la sincronización de
rutas entre los enrutadores. Para más información, consulte ¿Qué es el reflector de
rutas?

Funcionamiento de la puerta de enlace de RAS

La puerta de enlace de RAS enruta el tráfico de red entre la red física y los recursos de la
red de VM, independientemente de la ubicación. Puede enrutar el tráfico de red en la
misma ubicación física o en muchas ubicaciones diferentes.

Puede implementar la puerta de enlace de RAS en grupos de alta disponibilidad que

usan varias características a la vez. Los grupos de puertas de enlace contienen varias
instancias de puerta de enlace de RAS para la alta disponibilidad y la conmutación por
error.

Puede escalar o reducir verticalmente un grupo de puertas de enlace fácilmente

agregando o quitando máquinas virtuales de puerta de enlace del grupo. La eliminación
o adición de puertas de enlace no interrumpe los servicios que proporciona un grupo.
También puede agregar y quitar grupos de puertas de enlace completos. Para más
información, consulte Alta disponibilidad de la puerta de enlace de RAS.

Cada grupo de puertas de enlace proporciona redundancia M + N. Esto significa que se

realiza una copia de seguridad de "M" máquinas virtuales de puertas de enlace activas
mediante "N" máquinas virtuales de puerta de enlace en espera. La redundancia M + N
proporciona más flexibilidad a la hora de determinar el nivel de confiabilidad que
necesita al implementar la puerta de enlace de RAS.

Puede asignar una sola dirección IP pública a todos los grupos o a un subconjunto de
grupos. Al hacerlo, se reduce en gran medida el número de direcciones IP públicas que
se deben usar, ya que es posible que todos los inquilinos se conecten a la nube en una
única dirección IP.

Pasos siguientes
Para obtener información relacionada, consulte:

Arquitectura de implementación de la puerta de enlace de RAS

Introducción a la controladora de red
Plan de implementación de Controladora de red
SDN en Azure Stack HCI y Windows Server
Arquitectura de implementación de
puerta de enlace de RAS
Artículo • 21/12/2022 • Tiempo de lectura: 14 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Puede usar este tema para obtener información sobre la implementación del proveedor
de servicios en la nube (CSP) de la puerta de enlace ras, incluidos los grupos de puertas
de enlace de RAS, los reflectores de ruta y la implementación de varias puertas de
enlace para inquilinos individuales.

En las secciones siguientes se proporcionan breves información general sobre algunas

de las nuevas características de la puerta de enlace ras para que pueda comprender
cómo usar estas características en el diseño de la implementación de la puerta de
enlace.

Además, se proporciona una implementación de ejemplo, incluida la información sobre

el proceso de agregar nuevos inquilinos, la sincronización de rutas y el enrutamiento del
plano de datos, la puerta de enlace y la conmutación por error del reflector de ruta, etc.

En este tema se incluyen las siguientes secciones.

Uso de nuevas características de puerta de enlace ras para diseñar la

implementación

Implementación de ejemplo

Agregar nuevos inquilinos y emparejamiento de direcciones de cliente (CA)

espacio EBGP

Enrutamiento de sincronización de rutas y enrutamiento del plano de datos

Cómo responde la controladora de red a la puerta de enlace ras y la conmutación

por error del reflector de rutas

Ventajas del uso de nuevas características de puerta de enlace ras

Uso de nuevas características de puerta de

enlace ras para diseñar la implementación
La puerta de enlace de RAS incluye varias características nuevas que cambian y mejoran
la forma en que se implementa la infraestructura de puerta de enlace en el centro de
datos.

Reflector de ruta BGP

La funcionalidad De reflector de ruta del Protocolo de puerta de enlace de borde (BGP)
ahora se incluye con la puerta de enlace RAS y proporciona una alternativa a la
topología de malla completa BGP que normalmente es necesaria para la sincronización
de rutas entre enrutadores. Con la sincronización de malla completa, todos los
enrutadores de BGP deben conectarse con todos los demás enrutadores de la topología
de enrutamiento. Sin embargo, cuando se usa el reflector de rutas, este es el único
enrutador que se conecta con todos los demás enrutadores, denominados clientes del
reflector de rutas de BGP, lo que simplifica la sincronización de rutas y reduce el tráfico
de red. El reflector de rutas aprende todas las rutas, calcula las mejores rutas y
redistribuye las mejores rutas a sus clientes de BGP.

Para obtener más información, consulte Novedades de la puerta de enlace de RAS.

Grupos de puertas de enlace

En Windows Server 2016, puede crear muchos grupos de puertas de enlace de
diferentes tipos. Los grupos de puertas de enlace contienen muchas instancias de
puerta de enlace ras y enrutan el tráfico de red entre redes físicas y virtuales.

Para obtener más información, consulte Novedades de la puerta de enlace ras y alta
disponibilidad de puerta de enlace de RAS.

Escalabilidad del grupo de puertas de enlace

Puede escalar o reducir verticalmente un grupo de puertas de enlace fácilmente
agregando o quitando máquinas virtuales de puerta de enlace del grupo. La eliminación
o adición de puertas de enlace no interrumpe los servicios que proporciona un grupo.
También puede agregar y quitar grupos de puertas de enlace completos.

Para obtener más información, consulte Novedades de la puerta de enlace ras y alta
disponibilidad de puerta de enlace de RAS.

Redundancia del grupo de puertas de enlace de M+N

Cada grupo de puertas de enlace es redundante de M+N. Esto significa que se realiza
una copia de seguridad de un número "M" de máquinas virtuales de puerta de enlace
activas mediante un número "N" de máquinas virtuales de puerta de enlace en espera.
La redundancia M + N proporciona más flexibilidad a la hora de determinar el nivel de
confiabilidad que necesita al implementar la puerta de enlace de RAS.

Para obtener más información, consulte Novedades de la puerta de enlace ras y alta
disponibilidad de puerta de enlace de RAS.

Implementación de ejemplo
En la ilustración siguiente se proporciona un ejemplo con el emparejamiento de eBGP a
través de conexiones VPN de sitio a sitio configuradas entre dos inquilinos, Contoso y
Woodgrove, y el centro de datos de CSP de Fabrikam.

En este ejemplo, Contoso requiere ancho de banda de puerta de enlace adicional, lo

que conduce a la decisión de diseño de la infraestructura de puerta de enlace para
finalizar el sitio de Contoso Los Ángeles en GW3 en lugar de GW2. Por este motivo, las
conexiones VPN de Contoso de diferentes sitios finalizan en el centro de datos de CSP
en dos puertas de enlace diferentes.

Ambas puertas de enlace, GW2 y GW3, fueron las primeras puertas de enlace ras
configuradas por controladora de red cuando el CSP agregó los inquilinos contoso y
Woodgrove a su infraestructura. Por este motivo, estas dos puertas de enlace se
configuran como reflectores de ruta para estos clientes correspondientes (o inquilinos).
GW2 es el reflector de ruta de Contoso y GW3 es el reflector de ruta woodgrove,
además de ser el punto de terminación de puerta de enlace ras de CSP para la conexión
VPN con el sitio HQ de Contoso Los Ángeles.
 ７ Nota

Una puerta de enlace ras puede enrutar el tráfico de red virtual y físico para un
máximo de cien inquilinos diferentes, en función de los requisitos de ancho de
banda de cada inquilino.

Como reflectores de ruta, GW2 envía rutas de espacio de CA de Contoso a la

controladora de red y GW3 envía rutas de espacio de CA de Woodgrove a la
controladora de red.

Controladora de red inserta directivas de virtualización de red de Hyper-V en las redes

virtuales Contoso y Woodgrove, así como directivas ras a las puertas de enlace de RAS y
las directivas de equilibrio de carga a los multiplexadores (MUX) configurados como un
grupo de equilibrio de carga de software.

Adición de nuevos inquilinos y el

emparejamiento de eBGP del espacio de
direcciones de cliente (CA)
Al firmar un nuevo cliente y agregar el cliente como un nuevo inquilino en el centro de
datos, puede usar el siguiente proceso, gran parte del cual se realiza automáticamente
mediante el controlador de red y los enrutadores eBGP de puerta de enlace ras.

1. Aprovisione una nueva red virtual y cargas de trabajo según los requisitos del
inquilino.

2. Si es necesario, configure la conectividad remota entre el inquilino remoto

Enterprise sitio y su red virtual en el centro de datos. Al implementar una conexión
VPN de sitio a sitio para el inquilino, controladora de red selecciona
automáticamente una máquina virtual de puerta de enlace RAS disponible en el
grupo de puertas de enlace disponibles y configura la conexión.

3. Al configurar la máquina virtual de puerta de enlace ras para el nuevo inquilino, la

controladora de red también configura la puerta de enlace ras como un enrutador
BGP y la designa como reflector de ruta para el inquilino. Esto es cierto incluso en
circunstancias en las que la puerta de enlace ras actúa como puerta de enlace, o
como puerta de enlace y reflector de ruta, para otros inquilinos.

4. Dependiendo de si el enrutamiento de espacio de CA está configurado para usar

redes configuradas estáticamente o enrutamiento BGP dinámico, controladora de
 red configura las rutas estáticas correspondientes, vecinos de BGP o ambas en la
máquina virtual de puerta de enlace ras y el reflector de ruta.

７ Nota

Una vez que la controladora de red haya configurado una puerta de

enlace ras y un reflector de ruta para el inquilino, siempre que el mismo
inquilino requiera una nueva conexión VPN de sitio a sitio, controladora
de red comprueba la capacidad disponible en esta máquina virtual de
puerta de enlace ras. Si la puerta de enlace original puede atender la
capacidad necesaria, la nueva conexión de red también se configura en
la misma máquina virtual de puerta de enlace ras. Si la máquina virtual
de puerta de enlace ras no puede controlar la capacidad adicional,
Controladora de red selecciona una nueva máquina virtual de puerta de
enlace RAS disponible y configura la nueva conexión en ella. Esta nueva
máquina virtual de puerta de enlace ras asociada con el inquilino se
convierte en el cliente del reflector de ruta de la puerta de enlace ras del
inquilino original.

Dado que los grupos de puertas de enlace de RAS están detrás de los
SLA de software, las direcciones VPN de sitio a sitio de los inquilinos
usan una única dirección IP pública, denominada dirección IP virtual
(VIP), que los SLA traducen en una dirección IP interna del centro de
datos, denominada dirección IP dinámica (DIP), para una puerta de
enlace RAS que enruta el tráfico para el inquilino de Enterprise. Esta
asignación de direcciones IP públicas a privadas mediante SLB garantiza
que los túneles VPN de sitio a sitio se establecen correctamente entre
los sitios de Enterprise y las puertas de enlace ras de CSP y los
reflectores de ruta.

Para obtener más información sobre SLB, VIP y DIP, consulte Equilibrio
de carga de software (SLB) para SDN.

5. Después de establecer el túnel VPN de sitio a sitio entre el sitio de Enterprise y la

puerta de enlace ras del centro de datos de CSP para el nuevo inquilino, las rutas
estáticas asociadas a los túneles se aprovisionan automáticamente en los lados
Enterprise y CSP del túnel.
 6. Con el enrutamiento BGP del espacio de CA, también se establece el
emparejamiento de eBGP entre los sitios de Enterprise y el reflector de ruta de
puerta de enlace ras de CSP.

Enrutamiento de sincronización de rutas y

enrutamiento del plano de datos
Después de establecer el emparejamiento de eBGP entre Enterprise sitios y el reflector
de ruta de puerta de enlace ras de CSP, el reflector de ruta aprende todas las rutas de
Enterprise mediante el enrutamiento BGP dinámico. El Reflector de ruta sincroniza estas
rutas entre todos los clientes de Route Reflector para que todos estén configurados con
el mismo conjunto de rutas.

El reflector de ruta también actualiza estas rutas consolidadas, mediante la

sincronización de rutas, a controladora de red. Después, la controladora de red traduce
las rutas a las directivas de virtualización de red de Hyper-V y configura la red de tejido
para asegurarse de que se aprovisiona el enrutamiento de ruta de acceso de datos de
un extremo a otro. Este proceso hace que la red virtual del inquilino sea accesible desde
el inquilino Enterprise sitios.

En el caso del enrutamiento del plano de datos, los paquetes que llegan a las máquinas
virtuales de puerta de enlace ras se enrutan directamente a la red virtual del inquilino,
ya que las rutas necesarias ahora están disponibles con todas las máquinas virtuales de
puerta de enlace RAS participantes.

De forma similar, con las directivas de virtualización de red de Hyper-V en vigor, la red
virtual del inquilino enruta los paquetes directamente a las máquinas virtuales de puerta
de enlace ras (sin necesidad de conocer el reflector de ruta) y, a continuación, a los sitios
Enterprise a través de los túneles VPN de sitio a sitio.

Permita los intervalos de direcciones IP para la región de Azure de su suscripción y para

el oeste de EE. devuelve el tráfico de la red virtual del inquilino al inquilino remoto
Enterprise sitio omite los SLA, un proceso denominado Direct Server Return (DSR).

Cómo responde la controladora de red a la

puerta de enlace ras y la conmutación por error
del reflector de rutas
A continuación se muestran dos posibles escenarios de conmutación por error: uno para
los clientes de reflector de ruta de puerta de enlace ras y otro para los reflectores de
ruta de puerta de enlace RAS, incluida la información sobre cómo controladora de red
controla la conmutación por error para las máquinas virtuales en cualquiera de las
configuraciones.

Error de máquina virtual de un cliente de reflector de ruta

BGP de puerta de enlace RAS
La controladora de red realiza las siguientes acciones cuando se produce un error en un
cliente reflector de ruta de puerta de enlace RAS.

７ Nota

Cuando una puerta de enlace ras no es un reflector de ruta para la infraestructura

BGP de un inquilino, es un cliente de Reflector de ruta en la infraestructura BGP del
inquilino.

La controladora de red selecciona una máquina virtual de puerta de enlace ras en

espera disponible y aprovisiona la nueva máquina virtual de puerta de enlace ras
con la configuración de la máquina virtual de puerta de enlace RAS con errores.

La controladora de red actualiza la configuración de SLB correspondiente para

asegurarse de que los túneles VPN de sitio a sitio de los sitios de inquilino a la
puerta de enlace ras con errores se establecen correctamente con la nueva puerta
de enlace ras.

La controladora de red configura el cliente reflector de ruta BGP en la nueva puerta

de enlace.

La controladora de red configura el nuevo cliente de reflector de ruta BGP de

puerta de enlace ras como activo. La puerta de enlace ras inicia inmediatamente el
emparejamiento con el reflector de ruta del inquilino para compartir información
de enrutamiento y para habilitar el emparejamiento de eBGP para el sitio de
Enterprise correspondiente.

Error de máquina virtual para un reflector de ruta BGP de

puerta de enlace ras
La controladora de red realiza las siguientes acciones cuando se produce un error en un
reflector de ruta BGP de puerta de enlace RAS.
 La controladora de red selecciona una máquina virtual de puerta de enlace ras en
espera disponible y aprovisiona la nueva máquina virtual de puerta de enlace ras
con la configuración de la máquina virtual de puerta de enlace RAS con errores.

La controladora de red configura el reflector de ruta en la nueva máquina virtual

de puerta de enlace ras y asigna a la nueva máquina virtual la misma dirección IP
que usó la máquina virtual con errores, lo que proporciona integridad de ruta a
pesar del error de la máquina virtual.

La controladora de red actualiza la configuración de SLB correspondiente para

asegurarse de que los túneles VPN de sitio a sitio de los sitios de inquilino a la
puerta de enlace ras con errores se establecen correctamente con la nueva puerta
de enlace ras.

La controladora de red configura la nueva máquina virtual del reflector de ruta

BGP de puerta de enlace ras como activa.

El reflector de ruta se activa inmediatamente. Se establece el túnel VPN de sitio a

sitio a la Enterprise, y el reflector de ruta usa el emparejamiento eBGP y
intercambia rutas con los enrutadores de sitio de Enterprise.

Después de la selección de rutas BGP, el reflector de ruta BGP de puerta de enlace

ras actualiza los clientes del reflector de ruta de inquilino en el centro de datos y
sincroniza las rutas con controladora de red, lo que hace que la ruta de acceso de
datos de un extremo a otro esté disponible para el tráfico del inquilino.

Ventajas del uso de nuevas características de

puerta de enlace ras
A continuación se muestran algunas de las ventajas de usar estas nuevas características
de puerta de enlace ras al diseñar la implementación de puerta de enlace ras.

Escalabilidad de puerta de enlace ras

Dado que puede agregar tantas máquinas virtuales de puerta de enlace RAS como
necesite a los grupos de puertas de enlace ras, puede escalar fácilmente la
implementación de puerta de enlace ras para optimizar el rendimiento y la capacidad. Al
agregar máquinas virtuales a un grupo, puede configurar estas puertas de enlace ras
con conexiones VPN de sitio a sitio de cualquier tipo (IKEv2, L3, GRE), lo que elimina los
cuellos de botella de capacidad sin tiempo de ingestión.

Administración simplificada de puerta de enlace de sitio de Enterprise

Cuando el inquilino tiene varios sitios de Enterprise, el inquilino puede configurar todos
los sitios con una dirección IP DE VPN de sitio a sitio remota y una única dirección IP de
vecino remoto: la dirección IP del reflector de ruta BGP del centro de datos de CSP RAS
Gateway BGP Route Reflector vip para ese inquilino. Esto simplifica la administración de
puertas de enlace para los inquilinos.

Corrección rápida del error de puerta de enlace

Para garantizar una respuesta de conmutación por error rápida, puede configurar el
tiempo de parámetro Keepalive de BGP entre las rutas perimetrales y el enrutador de
control a un intervalo de tiempo corto, como menos o igual que diez segundos. Con
este breve intervalo de mantenimiento activo, si se produce un error en un enrutador
perimetral BGP de puerta de enlace RAS, el error se detecta rápidamente y la
controladora de red sigue los pasos proporcionados en las secciones anteriores. Esta
ventaja podría reducir la necesidad de un protocolo de detección de errores
independiente, como el protocolo detección de reenvío bidireccional (BFD).
Alta disponibilidad de la puerta de
enlace de RAS
Artículo • 21/12/2022 • Tiempo de lectura: 15 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Puede usar este tema para obtener información sobre las configuraciones de alta
disponibilidad para la puerta de enlace multiinquilino ras para redes definidas por
software (SDN).

En este tema se incluyen las siguientes secciones.

Introducción a la puerta de enlace ras

Introducción a los grupos de puertas de enlace

Introducción a la implementación de puerta de enlace de RAS

Integración de puerta de enlace ras con controladora de red

Introducción a la puerta de enlace ras

Si su organización es un proveedor de servicios en la nube (CSP) o un Enterprise con
varios inquilinos, puede implementar la puerta de enlace ras en modo multiinquilino
para proporcionar enrutamiento de tráfico de red hacia y desde redes virtuales y físicas,
incluido Internet.

Puede implementar la puerta de enlace ras en modo multiinquilino como puerta de

enlace perimetral para enrutar el tráfico de red del cliente del inquilino a redes virtuales
y recursos de inquilino.

Al implementar varias instancias de máquinas virtuales de puerta de enlace ras que

proporcionan alta disponibilidad y conmutación por error, va a implementar un grupo
de puertas de enlace. En Windows Server 2012 R2, todas las máquinas virtuales de
puerta de enlace formaron un único grupo, lo que dificultaba un poco la separación
lógica de la implementación de la puerta de enlace. Windows Server 2012 puerta de
enlace de R2 ofreció una implementación de redundancia 1:1 para las máquinas
virtuales de puerta de enlace, lo que dio lugar a una infrautilización de la capacidad
disponible para las conexiones VPN de sitio a sitio (S2S).
Este problema se resuelve en Windows Server 2016, que proporciona varios grupos de
puertas de enlace, que pueden ser de diferentes tipos para la separación lógica. El
nuevo modo de redundancia de M+N permite una configuración de conmutación por
error más eficaz.

Para obtener más información general sobre la puerta de enlace ras, consulte Puerta de
enlace ras.

Introducción a los grupos de puertas de enlace

En Windows Server 2016, puede implementar puertas de enlace en uno o varios grupos.

En la ilustración siguiente se muestran diferentes tipos de grupos de puertas de enlace

que proporcionan enrutamiento de tráfico entre redes virtuales.

Cada grupo tiene las siguientes propiedades.

Cada grupo tiene redundancia de M+N. Esto significa que se realiza una copia de
seguridad de un número "M" de máquinas virtuales de puerta de enlace activas
mediante un número "N" de máquinas virtuales de puerta de enlace en espera. El
valor de N (puertas de enlace en espera) siempre es menor o igual que M (puertas
de enlace activas).

Un grupo puede realizar cualquiera de las funciones de puerta de enlace

individuales ( Clave de Internet Exchange versión 2 (IKEv2) S2S, Nivel 3 (L3) y
Encapsulación de enrutamiento genérico (GRE) o el grupo puede realizar todas
estas funciones.

Puede asignar una sola dirección IP pública a todos los grupos o a un subconjunto
de grupos. Al hacerlo, se reduce en gran medida el número de direcciones IP
públicas que se deben usar, ya que es posible que todos los inquilinos se conecten
 a la nube en una única dirección IP. En la sección siguiente sobre alta
disponibilidad y equilibrio de carga se describe cómo funciona.

Puede escalar o reducir verticalmente un grupo de puertas de enlace fácilmente

agregando o quitando máquinas virtuales de puerta de enlace del grupo. La
eliminación o adición de puertas de enlace no interrumpe los servicios que
proporciona un grupo. También puede agregar y quitar grupos de puertas de
enlace completos.

Las conexiones de un solo inquilino pueden finalizar en varios grupos y varias

puertas de enlace de un grupo. Sin embargo, si un inquilino tiene conexiones que
finalizan en un grupo de puertas de enlace de tipo All , no puede suscribirse a
otros grupos de puertas de enlace de tipo All o individual.

Los grupos de puertas de enlace también proporcionan la flexibilidad necesaria para

habilitar escenarios adicionales:

Grupos de inquilinos únicos: puede crear un grupo para que lo use un inquilino.

Si vende servicios en la nube a través de canales de asociados (revendedores),

puede crear conjuntos de grupos independientes para cada revendedor.

Varios grupos pueden proporcionar la misma función de puerta de enlace, pero

capacidades diferentes. Por ejemplo, puede crear un grupo de puertas de enlace
que admita conexiones IKEv2 S2S de alto rendimiento y de bajo rendimiento.

Introducción a la implementación de puerta de

enlace de RAS
En la ilustración siguiente se muestra una implementación típica del proveedor de
servicios en la nube (CSP) de la puerta de enlace ras.
Con este tipo de implementación, los grupos de puertas de enlace se implementan
detrás de una Load Balancer de software (SLB), lo que permite al CSP asignar una única
dirección IP pública para toda la implementación. Varias conexiones de puerta de enlace
de un inquilino pueden finalizar en varios grupos de puertas de enlace, y también en
varias puertas de enlace dentro de un grupo. Esto se ilustra a través de las conexiones
S2S de IKEv2 en el diagrama anterior, pero también se aplica a otras funciones de puerta
de enlace, como las puertas de enlace L3 y GRE.

En la ilustración, el dispositivo MT BGP es una puerta de enlace multiinquilino RAS con

BGP. BGP multiinquilino se usa para el enrutamiento dinámico. El enrutamiento de un
inquilino está centralizado: un único punto, denominado reflector de ruta (RR), controla
el emparejamiento BGP para todos los sitios de inquilino. El rr se distribuye entre todas
las puertas de enlace de un grupo. Esto da como resultado una configuración en la que
las conexiones de un inquilino (ruta de acceso de datos) finalizan en varias puertas de
enlace, pero el RR del inquilino (punto de emparejamiento BGP: ruta de acceso de
control) solo está en una de las puertas de enlace.

El enrutador BGP se separa en el diagrama para representar este concepto de

enrutamiento centralizado. La implementación de BGP de puerta de enlace también
proporciona enrutamiento de tránsito, lo que permite a la nube actuar como punto de
tránsito para el enrutamiento entre dos sitios de inquilino. Estas funcionalidades BGP
son aplicables a todas las funciones de puerta de enlace.

Integración de puerta de enlace ras con

controladora de red
La puerta de enlace ras está totalmente integrada con la controladora de red en
Windows Server 2016. Cuando se implementa la puerta de enlace ras y la controladora
de red, la controladora de red realiza las siguientes funciones.
 Implementación de los grupos de puerta de enlace

Configuración de conexiones de inquilino en cada puerta de enlace

Cambiar el tráfico de red fluye a una puerta de enlace en espera en caso de error
de puerta de enlace

En las secciones siguientes se proporciona información detallada sobre la puerta de

enlace ras y la controladora de red.

Aprovisionamiento y equilibrio de carga de conexiones de puerta de enlace (IKEv2,

L3 y GRE)

Alta disponibilidad para IKEv2 S2S

Alta disponibilidad para GRE

Alta disponibilidad para puertas de enlace de reenvío L3

Aprovisionamiento y equilibrio de carga de conexiones

de puerta de enlace (IKEv2, L3 y GRE)
Cuando un inquilino solicita una conexión de puerta de enlace, la solicitud se envía a la
controladora de red. La controladora de red se configura con información sobre todos
los grupos de puerta de enlace, incluida la capacidad de cada grupo y cada puerta de
enlace de cada grupo. La controladora de red selecciona el grupo y la puerta de enlace
correctos para la conexión. Esta selección se basa en el requisito de ancho de banda de
la conexión. La controladora de red usa un algoritmo de "mejor ajuste" para elegir las
conexiones de forma eficaz en un grupo. El punto de emparejamiento BGP para la
conexión también se designa en este momento si se trata de la primera conexión del
inquilino.

Después de que la controladora de red seleccione una puerta de enlace RAS para la
conexión, la controladora de red aprovisiona la configuración necesaria para la conexión
en la puerta de enlace. Si la conexión es una conexión IKEv2 S2S, la controladora de red
también aprovisiona una regla de traducción de direcciones de red (NAT) en el grupo de
SLB; esta regla NAT del grupo de SLB dirige las solicitudes de conexión del inquilino a la
puerta de enlace designada. Los inquilinos se diferencian por la dirección IP de origen,
que se espera que sea única.

７ Nota
 Las conexiones L3 y GRE omiten el SLB y se conectan directamente con la puerta de
enlace RAS designada. Estas conexiones requieren que el enrutador del punto de
conexión remoto (u otro dispositivo de terceros) esté configurado correctamente
para conectarse con la puerta de enlace ras.

Si el enrutamiento BGP está habilitado para la conexión, la puerta de enlace ras inicia el
emparejamiento BGP y las rutas se intercambian entre puertas de enlace locales y en la
nube. Las rutas aprendidas por BGP (o que están configuradas estáticamente si no se
usa BGP) se envían a controladora de red. A continuación, la controladora de red enruta
las rutas a los hosts de Hyper-V en los que se instalan las máquinas virtuales del
inquilino. En este momento, el tráfico de inquilinos se puede enrutar al sitio local
correcto. La controladora de red también crea directivas de virtualización de red de
Hyper-V asociadas que especifican ubicaciones de puerta de enlace y las reduce a los
hosts de Hyper-V.

Alta disponibilidad para IKEv2 S2S

Una puerta de enlace ras en un grupo consta de conexiones y emparejamiento BGP de
distintos inquilinos. Cada grupo tiene puertas de enlace activas "M" y puertas de enlace
en espera "N".

La controladora de red controla el error de las puertas de enlace de la siguiente manera.

La controladora de red hace ping constantemente a las puertas de enlace de todos

los grupos y puede detectar una puerta de enlace con errores o errores. La
controladora de red puede detectar los siguientes tipos de errores de puerta de
enlace ras.

Error de máquina virtual de puerta de enlace ras

Error del host de Hyper-V en el que se ejecuta la puerta de enlace ras

Error del servicio de puerta de enlace ras

La controladora de red almacena la configuración de todas las puertas de enlace

activas implementadas. La configuración consta de opciones de conexión y de
enrutamiento.

Cuando se produce un error en una puerta de enlace, afecta a las conexiones de

inquilino en la puerta de enlace, así como a las conexiones de inquilino que se
encuentran en otras puertas de enlace, pero cuyo RR reside en la puerta de enlace
con errores. El tiempo de in down de las últimas conexiones es menor que el
 anterior. Cuando la controladora de red detecta una puerta de enlace con errores,
realiza las siguientes tareas.

Quita las rutas de las conexiones afectadas de los hosts de proceso.

Quita las directivas de virtualización de red de Hyper-V en estos hosts.

Selecciona una puerta de enlace en espera, la convierte en una puerta de enlace

activa y configura la puerta de enlace.

Cambia las asignaciones NAT del grupo de SLB para que apunten las
conexiones a la nueva puerta de enlace.

Simultáneamente, a medida que la configuración aparece en la nueva puerta de

enlace activa, se vuelven a establecer las conexiones S2S de IKEv2 y el
emparejamiento BGP. Las conexiones y el emparejamiento BGP se pueden iniciar
mediante la puerta de enlace en la nube o la puerta de enlace local. Las puertas de
enlace actualizan sus rutas y las envían a controladora de red. Una vez que la
controladora de red aprende las nuevas rutas detectadas por las puertas de enlace,
la controladora de red envía las rutas y las directivas de virtualización de red de
Hyper-V asociadas a los hosts de Hyper-V donde residen las máquinas virtuales de
los inquilinos afectados por errores. Esta actividad de controladora de red es
similar a la circunstancia de una nueva configuración de conexión, solo se produce
a mayor escala.

Alta disponibilidad para GRE

El proceso de respuesta de conmutación por error de puerta de enlace ras por
controladora de red, incluida la detección de errores, la copia de la configuración de
conexión y enrutamiento en la puerta de enlace en espera, la conmutación por error del
enrutamiento BGP o el enrutamiento estático de las conexiones afectadas (incluida la
retirada y la reutilización de rutas en hosts de proceso y el emparejamiento de BGP) y la
reconfiguración de las directivas de virtualización de red de Hyper-V en hosts de
proceso es la misma para las puertas de enlace y las conexiones gre. Sin embargo, el
nuevo establecimiento de conexiones GRE se produce de forma diferente y la solución
de alta disponibilidad para GRE tiene algunos requisitos adicionales.
En el momento de la implementación de la puerta de enlace, a cada máquina virtual de
puerta de enlace ras se le asigna una dirección IP dinámica (DIP). Además, a cada
máquina virtual de puerta de enlace también se le asigna una dirección IP virtual (VIP)
para la alta disponibilidad de GRE. Las DIRECCIONES VIP solo se asignan a puertas de
enlace en grupos que pueden aceptar conexiones GRE y no a grupos que no son de
GRE. Las DIRECCIONES VIP asignadas se anuncian en la parte superior de los
conmutadores de bastidor (TOR) mediante BGP, que luego anuncia aún más las VIP en
la red física en la nube. Esto hace que las puertas de enlace sean accesibles desde los
enrutadores remotos o dispositivos de terceros donde reside el otro extremo de la
conexión GRE. Este emparejamiento BGP es diferente del emparejamiento BGP de nivel
de inquilino para el intercambio de rutas de inquilino.

En el momento del aprovisionamiento de conexiones GRE, controladora de red

selecciona una puerta de enlace, configura un punto de conexión GRE en la puerta de
enlace seleccionada y devuelve la dirección VIP de la puerta de enlace asignada. A
continuación, esta VIP se configura como la dirección del túnel GRE de destino en el
enrutador remoto.

Cuando se produce un error en una puerta de enlace, controladora de red copia la

dirección VIP de la puerta de enlace con errores y otros datos de configuración en la
puerta de enlace en espera. Cuando la puerta de enlace en espera se activa, anuncia la
dirección VIP a su conmutador TOR y más en la red física. Los enrutadores remotos
siguen conectando túneles GRE a la misma VIP y la infraestructura de enrutamiento
garantiza que los paquetes se enrutan a la nueva puerta de enlace activa.

Alta disponibilidad para puertas de enlace de reenvío L3

Una puerta de enlace de reenvío L3 de virtualización de red de Hyper-V es un puente
entre la infraestructura física del centro de datos y la infraestructura virtualizada en la
nube de virtualización de red de Hyper-V. En una puerta de enlace de reenvío L3
multiinquilino, cada inquilino usa su propia red lógica etiquetada VLAN para la
conectividad con la red física del inquilino.

Cuando un nuevo inquilino crea una nueva puerta de enlace L3, La puerta de enlace de
controladora de red Service Manager selecciona una máquina virtual de puerta de
enlace disponible y configura una nueva interfaz de inquilino con una dirección IP de
espacio de dirección de cliente (CA) de alta disponibilidad (desde la red lógica
etiquetada de VLAN del inquilino). La dirección IP se usa como dirección IP del mismo
nivel en la puerta de enlace remota (red física) y es el próximo salto para llegar a la red
de virtualización de red de Hyper-V del inquilino.

A diferencia de las conexiones de red IPsec o GRE, el conmutador TOR no aprenderá la

VLAN del inquilino etiquetada dinámicamente. El enrutamiento de la red etiquetada
VLAN del inquilino debe configurarse en el conmutador TOR y todos los conmutadores
intermedios y enrutadores entre la infraestructura física y la puerta de enlace para
garantizar la conectividad de un extremo a otro. A continuación se muestra un ejemplo
de configuración de CSP Virtual Network como se muestra en la ilustración siguiente.

Red Subnet ID. DE Puerta de enlace

VLAN predeterminada

Red lógica L3 de Contoso [Link]/24 1001 [Link]

Red lógica L3 de [Link]/24 1002 [Link]

Woodgrove

A continuación se muestran configuraciones de puerta de enlace de inquilinos de

ejemplo, como se muestra en la ilustración siguiente.

Nombre del Dirección IP de puerta de ID. DE Dirección IP del mismo

inquilino enlace L3 VLAN nivel

Contoso [Link] 1001 [Link]

Woodgrove [Link] 1002 [Link]

A continuación se muestra la ilustración de estas configuraciones en un centro de datos

de CSP.
Los errores de puerta de enlace, la detección de errores y el proceso de conmutación
por error de puerta de enlace en el contexto de una puerta de enlace de reenvío L3 son
similares a los procesos de puertas de enlace IKEv2 y GRE RAS Gateway. Las diferencias
están en la forma en que se controlan las direcciones IP externas.

Cuando el estado de la máquina virtual de la puerta de enlace se vuelve incorrecto,

Controladora de red selecciona una de las puertas de enlace en espera del grupo y
vuelve a aprovisionar las conexiones de red y el enrutamiento en la puerta de enlace en
espera. Al mover las conexiones, la dirección IP de espacio de CA de alta disponibilidad
de la puerta de enlace de reenvío L3 también se mueve a la nueva máquina virtual de
puerta de enlace junto con la dirección IP BGP del espacio de CA del inquilino.

Dado que la dirección IP de emparejamiento L3 se mueve a la nueva máquina virtual de

puerta de enlace durante la conmutación por error, la infraestructura física remota
puede conectarse de nuevo a esta dirección IP y, posteriormente, llegar a la carga de
trabajo virtualización de red de Hyper-V. Para el enrutamiento dinámico de BGP, a
medida que la dirección IP BGP del espacio de CA se mueve a la nueva máquina virtual
de puerta de enlace, el enrutador BGP remoto puede volver a establecer el
emparejamiento y aprender todas las rutas de virtualización de red de Hyper-V de
nuevo.

７ Nota

Debe configurar por separado los conmutadores TOR y todos los enrutadores
intermedios para poder usar la red lógica etiquetada VLAN para la comunicación
de inquilinos. Además, la conmutación por error L3 está restringida solo a los
bastidores que están configurados de esta manera. Por este motivo, el grupo de
puertas de enlace L3 debe configurarse cuidadosamente y la configuración manual
debe completarse por separado.
¿Qué es el equilibrador de carga de
software (SLB) para SDN?
Artículo • 23/01/2023 • Tiempo de lectura: 13 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2; Windows Server 2022,
Windows Server 2019, Windows Server 2016

Los proveedores de servicios en la nube (CSP) y las empresas que implementan redes
definidas por software (SDN) pueden usar el equilibrador de carga de software (SLB)
para distribuir uniformemente el tráfico de red del inquilino y del cliente del inquilino
entre los recursos de la red virtual. SLB permite que varios servidores hospeden la
misma carga de trabajo, lo que proporciona alta disponibilidad y escalabilidad.

El equilibrador de carga para software puede proporcionar un borde unificado

multiinquilino mediante una integración con tecnologías de SDN, como la puerta de
enlace RAS, el firewall del centro de datos y el reflector de rutas.

７ Nota

La controladora de red no admite multiinquilinos para las redes VLAN. Sin

embargo, puede usar redes VLAN con equilibrador de carga de software para
cargas de trabajo administradas por el proveedor de servicios como, por ejemplo,
la infraestructura del centro de datos y los servidores web de alta densidad.

Mediante el equilibrador de carga de software, puede escalar horizontalmente las

funcionalidades de equilibrio de carga mediante máquinas virtuales que actúan como
equilibradores de carga de software en los mismos servidores de proceso de Hyper-V
que usa para las otras cargas de trabajo de las máquinas virtuales. Por este motivo, el
equilibrador de carga de software admite la creación y eliminación rápidas de los
puntos de conexión de equilibrio de carga según sea necesario para las operaciones de
CSP. Además, el equilibrador de carga de software admite decenas de gigabytes por
clúster, proporciona un modelo de aprovisionamiento simple y es fácil de escalar y
reducir horizontalmente.

Para obtener información sobre cómo administrar las directivas de equilibrador de carga
de software mediante Windows Admin Center, consulte Administración del equilibrador
de carga de software para SDN.
¿Qué incluye el equilibrador de carga de
software?
El equilibrador de carga de software incluye las siguientes funcionalidades:

Servicios de equilibrio de carga de nivel 4 para el tráfico TCP/UDP vertical de arriba

abajo y horizontal de derecha a izquierda.

Equilibrio de carga del tráfico de redes públicas y redes internas.

Compatibilidad con direcciones IP dinámicas en redes de área local virtuales y en

las redes virtuales que se crean mediante la virtualización de red de Hyper-V.

Compatibilidad con el sondeo de estado.

Listo para el escalado en la nube, incluida la funcionalidad de escalabilidad

horizontal y escalado vertical para multiplexores y agentes de host.

Para obtener más información, consulte Características del equilibrador de carga de

software en este artículo.

Funcionamiento del equilibrador de carga de

software
El equilibrador de carga de software funciona mediante la asignación de direcciones IP
virtuales a las DIP que forman parte de un conjunto de recursos del servicio en la nube
del centro de datos.

Las direcciones IP virtuales son direcciones IP únicas que proporcionan acceso público a
un grupo de máquinas virtuales con equilibrio de carga. Por ejemplo, las direcciones IP
virtuales son direcciones IP que se exponen en Internet para que los inquilinos y los
clientes de inquilinos puedan conectarse a los recursos de inquilino del centro de datos
en la nube.

Las DIP son las direcciones IP de las máquinas virtuales que forman parte de un grupo
con equilibrio de carga situado detrás de la dirección IP virtual. Las DIP se asignan
dentro de la infraestructura en la nube a los recursos del inquilino.

Las direcciones IP virtuales se encuentran en el multiplexor que actúa como equilibrador

de carga de software (MUX). El MUX consta de una o varias máquinas virtuales.
Controladora de red proporciona cada MUX con cada dirección IP virtual y, a su vez,
cada MUX usa Protocolo de puerta de enlace de borde (BGP) para anunciar cada
dirección IP virtual a los enrutadores de la red física como una ruta /32. BGP permite
que los enrutadores de la red física:

Sepan que hay una dirección IP virtual disponible en cada uno de los MUX, incluso
si estos se encuentran en distintas subredes de una red de nivel 3.

Distribuyan la carga de cada dirección IP virtual en todos los MUX disponibles

mediante el enrutamiento multidireccional de igual costo (ECMP).

Detecten automáticamente un error o eliminación del MUX y dejen de enviar

tráfico al MUX con errores.

Distribuyan la carga del MUX con errores o eliminado entre los MUX que
funcionen correctamente.

Cuando el tráfico público llega desde Internet, el MUX que actúa como equilibrador de
carga de software examina el tráfico, que contiene la dirección IP virtual como destino, y
asigna y reescribe el tráfico para que llegue a una DIP individual. En el tráfico de red de
entrada, esta transacción se realiza mediante un proceso de dos pasos que se divide
entre las máquinas virtuales del MUX y el host de Hyper-V donde se encuentra la DIP de
destino:

1. Equilibrio de carga: el MUX usa la dirección IP virtual para seleccionar una DIP,
encapsula el paquete y reenvía el tráfico al host de Hyper-V donde se encuentra la
DIP.

2. Traducción de direcciones de red: el host de Hyper-V quita la encapsulación del

paquete, traduce la dirección IP virtual en una DIP, vuelve a asignar los puertos y
reenvía el paquete a la máquina virtual de la DIP.

El MUX sabe cómo asignar las direcciones IP virtuales a las DIP correctas gracias a las
directivas de equilibrio de carga que se definen mediante Controladora de red. Estas
reglas incluyen el protocolo, el puerto de front-end, el puerto de back-end y el
algoritmo de distribución (5, 3 o 2 tuplas).

Cuando las máquinas virtuales del inquilino responden y envían el tráfico de red saliente
de nuevo a Internet o a las ubicaciones de los inquilinos remotos, y dado que el host de
Hyper-V realiza la traducción de direcciones de red, el tráfico ignora el MUX y va
directamente al enrutador perimetral desde el host de Hyper-V. A este proceso en el
que se ignora el MUX se le denomina Direct Server Return (DSR).

Una vez establecido el flujo de tráfico de red inicial, el tráfico de red entrante ignorará
completamente el MUX del equilibrador de carga de software.
En la ilustración siguiente, un equipo cliente realiza una consulta DNS para la dirección
IP de un sitio de SharePoint de una empresa, en este caso, una empresa ficticia
denominada Contoso. Se produce el siguiente proceso:

1. El servidor DNS devuelve la dirección IP virtual [Link] al cliente.

2. El cliente envía una solicitud HTTP a la dirección IP virtual.

3. La red física tiene varias rutas de acceso disponibles para llegar a la dirección IP
virtual ubicada en cualquier MUX. Cada enrutador a lo largo del proceso usa ECMP
para elegir el siguiente segmento de la ruta hasta que la solicitud llega a un MUX.

4. El MUX que recibe la solicitud comprueba las directivas configuradas y observa

que hay dos DIP disponibles, [Link] y [Link], en una red virtual para enviar
la solicitud a la dirección IP virtual [Link]

5. El MUX selecciona la DIP [Link] y encapsula los paquetes con VXLAN para
poder enviarlos al host que contiene la DIP mediante la dirección de red física del
host.

6. El host recibe el paquete encapsulado y lo inspecciona. Quita la encapsulación y

vuelve a escribir el paquete para que el destino sea ahora la DIP [Link] en
lugar de la dirección IP virtual y, a continuación, envía el tráfico a la máquina virtual
de la DIP.

7. La solicitud llega al sitio de SharePoint de Contoso en la granja de servidores 2. El

servidor genera una respuesta y la envía al cliente mediante su propia dirección IP
como origen.

8. El host intercepta el paquete saliente en el conmutador virtual que recuerda que el

cliente, ahora el destino, realizó la solicitud original a la dirección IP virtual. El host
reescribe el origen del paquete para que sea la dirección IP virtual, de modo que el
cliente no vea la dirección DIP.

9. El host reenvía el paquete directamente a la puerta de enlace predeterminada de la

red física la cual usa su tabla de enrutamiento estándar para reenviar el paquete al
cliente, que finalmente recibe la respuesta.
Equilibrio de carga del tráfico interno del centro de datos
Cuando se equilibra la carga del tráfico de red interno al centro de datos como, por
ejemplo, entre recursos de inquilino que se ejecutan en servidores diferentes y que
pertenecen a la misma red virtual, el conmutador virtual de Hyper-V al que se conectan
las máquinas virtuales realiza la traducción de direcciones de red.

Con el equilibrio de carga del tráfico interno, el MUX envía y procesa la primera
solicitud, y selecciona la dirección DIP adecuada y, a continuación, enruta el tráfico hacia
esta. A partir de ese momento, el flujo de tráfico establecido ignora al MUX y va
directamente desde una máquina virtual a otra.

Sondeos de estado
El equilibrador de carga de software incluye sondeos de estado para validar el estado de
la infraestructura de red entre los cuales se incluyen los siguientes:

Sondeo TCP a puerto

Sondeo HTTP a puerto y dirección URL

A diferencia de un dispositivo de equilibrio de carga tradicional en el que el sondeo se

origina en el dispositivo y se desplaza por la conexión a la dirección DIP, el sondeo del
equilibrador de carga de software se origina en el host donde se encuentra la dirección
DIP y va directamente desde el agente de host del equilibrador de carga de software a
la dirección DIP, con lo que se distribuye aún más el trabajo entre los hosts.

Infraestructura del equilibrador de carga de

software
Antes de poder configurar el equilibrador de carga de software, primero debe
implementar Controladora de red y una o varias máquinas virtuales del multiplexor que
actúe como equilibrador de carga de software.

Además, debe configurar los hosts de Azure Stack HCI con el conmutador virtual de
Hyper-V habilitado para redes definidas por software y asegurarse de que se está
ejecutando el agente de host del equilibrador de carga de software. Los enrutadores
que atienden a los hosts deben admitir el enrutamiento ECMP y el Protocolo de puerta
de enlace de borde, y se deben configurar para que acepten las solicitudes de
emparejamiento BGP de los MUX del equilibrador de carga de software.

En la ilustración siguiente se proporciona información general de la infraestructura del

equilibrador de carga de software.

Las secciones siguientes proporcionan más información sobre estos elementos de la

infraestructura del equilibrador de carga.

Controladora de red
Controladora de red hospeda el administrador del equilibrador de carga de software y
realiza las siguientes acciones para lograr ese equilibrio:

Procesa los comandos del equilibrador de carga de software que se incorporan

mediante Northbound API desde Windows Admin Center, System Center,
Windows PowerShell o cualquier otra aplicación de administración de redes.

Calcula la directiva para la distribución a los hosts de Azure Stack HCI y los MUX
que actúan como equilibrador de carga de software.

Proporciona el estado de mantenimiento de la infraestructura del equilibrador de

carga de software.
Puede usar Windows Admin Center o Windows PowerShell para instalar y configurar
Controladora de red y el resto de la infraestructura del equilibrador de carga de
software.

Multiplexor (MUX) que actúa como equilibrador de carga

de software
Este MUX procesa el tráfico de red entrante y asigna las direcciones IP virtuales a las
direcciones DIP y, a continuación, reenvía el tráfico a la dirección DIP correcta. Cada
MUX usa también BGP para publicar rutas de VIP a los enrutadores perimetrales. La
conexión persistente de BGP notifica a los MUX cuando se produce un error en uno de
ellos, lo que permite al resto de MUX activos redistribuir la carga. Esto proporciona
principalmente equilibrio de carga para los equilibradores de carga.

Agente de host del equilibrador de carga de software

Cuando implemente el equilibrador de carga de software, debe usar Windows Admin
Center, System Center, Windows PowerShell o cualquier otra aplicación de
administración para implementar el agente de host del equilibrador de carga de
software en cada servidor host.

El agente de host del equilibrador de carga de software escucha las actualizaciones de

directivas del equilibrador que proceden de Controladora de red. Además, programa las
reglas para el equilibrador de carga de software en los conmutadores virtuales de
Hyper-V habilitados para SDN que están configurados en el equipo local.

Conmutador virtual de Hyper-V habilitado para SDN

Para que un conmutador virtual sea compatible con el equilibrador de carga de
software, la extensión de la plataforma de filtrado virtual (VFP) debe estar habilitada en
el conmutador virtual. Esto se realiza automáticamente mediante los scripts de
PowerShell de implementación de SDN, el asistente de implementación de Windows
Admin Center y la implementación de System Center Virtual Machine Manager
(SCVMM).

Para más información sobre cómo habilitar VFP en conmutadores virtuales, consulte los
comandos de Windows PowerShell Get-VMSystemSwitchExtension y Enable-
VMSwitchExtension.

El conmutador virtual de Hyper-V habilitado para SDN realiza las siguientes acciones
para el equilibrador de carga de software:
 Procesa la ruta de acceso de datos para el equilibrador de carga de software.

Recibe el tráfico de red entrante del MUX.

Ignora al MUX para el tráfico de red saliente y lo envía al enrutador mediante

Direct Server Return.

Enrutador BGP
El enrutador BGP realiza las siguientes acciones para el equilibrador de carga de
software:

Enruta el tráfico entrante al MUX mediante ECMP.

En el caso del tráfico de red saliente, usa la ruta que el host proporciona.

Escucha las actualizaciones de ruta para las direcciones VIP del MUX que actúa
como equilibrador de carga de software.

Elimina estos MUX de la rotación de equilibradores de carga de software si se

produce un error en la conexión persistente.

Características del equilibrador de carga de

software
En las secciones siguientes se describen algunas de las características y funcionalidades
del equilibrador de carga de software.

Funcionalidad básica
Los equilibradores de carga de software proporcionan servicios de equilibrio de
carga de nivel 4 para el tráfico TCP/UDP vertical de arriba abajo y horizontal de
derecha a izquierda.

Puede usar el equilibrador de carga de software en una red basada en

virtualización de red de Hyper-V.

Puede usar el equilibrador de carga de software con una red basada en VLAN para
las máquinas virtuales DIP conectadas a un conmutador virtual de Hyper-V
habilitado para SDN.

Una instancia del equilibrador de carga de software puede administrar varios

inquilinos.
 El equilibrador de carga de software y las direcciones DIP admiten una ruta de
acceso de devolución de baja latencia y escalable, tal y como la implementa Direct
Server Return.

El equilibrador de carga de software funciona también cuando se usa Switch

Embedded Teaming (SET) o la virtualización de entrada/salida de raíz única (SR-
IOV).

El equilibrador de carga de software incluye compatibilidad con el protocolo de

Internet versión 6 (IPv6) y la versión 4 (IPv4).

En escenarios de puerta de enlace de sitio a sitio, el equilibrador de carga de

software proporciona funcionalidad de traducción de direcciones de red para
permitir que todas las conexiones de sitio a sitio utilicen una única dirección IP
pública.

Escala y rendimiento
Listo para el escalado en la nube, incluida la funcionalidad de escalado horizontal y
escalado vertical para multiplexores y agentes de host.

Un módulo de Controladora de red del administrador del equilibrador de carga de

software activo puede admitir ocho instancias de MUX.

Alta disponibilidad
Puede implementar el equilibrador de carga de software en más de dos nodos en
una configuración activa/activa.

Los MUX se pueden agregar y quitar del grupo de MUX sin que ello afecte al
servicio del equilibrador de carga de software. Esto mantiene la disponibilidad del
equilibrador de carga de software cuando se están revisando MUX individuales.

Las instancias individuales de MUX tienen un tiempo de actividad del 99 por

ciento.

Los datos de seguimiento de estado están disponibles para las entidades de

administración.

Pasos siguientes
Para obtener información relacionada, consulte:
Administración del equilibrador de carga de software para SDN
SDN en Azure Stack HCI y Windows Server
Módulo de Learn: Implementación de Firewall de centro de datos y Equilibrador de
carga de software en Azure Stack HCI
Introducción a las redes de
contenedores
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En este tema, se proporciona información general sobre la pila de redes para

contenedores de Windows e incluye vínculos a instrucciones adicionales sobre la
creación, configuración y administración de redes de contenedores.

Windows Server Containers son un método ligero de virtualización de sistema operativo

que separa aplicaciones o servicios de otros servicios que se ejecutan en el mismo host
de contenedor. Windows contenedores funcionan de forma similar a las máquinas
virtuales. Cuando se habilita, cada contenedor tiene una vista independiente del sistema
operativo, los procesos, el sistema de archivos, el registro y las direcciones IP, que se
pueden conectar a redes virtuales.

Un Windows comparte un kernel con el host de contenedor y todos los contenedores

que se ejecutan en el host. Debido al espacio compartido del kernel, estos contenedores
requieren la misma versión y configuración de kernel. Los contenedores proporcionan
aislamiento de aplicaciones a través de la tecnología de aislamiento de procesos y
espacios de nombres.

） Importante

Windows contenedores no proporcionan un límite de seguridad agresivo y no se

deben usar para aislar código que no es de confianza.

Con Windows contenedores, puede implementar un host de Hyper-V, donde puede

crear una o varias máquinas virtuales en los hosts de máquina virtual. Dentro de los
hosts de máquina virtual, se crean contenedores y el acceso de red se realiza a través de
un conmutador virtual que se ejecuta dentro de la máquina virtual. Puede usar
imágenes reutilizables almacenadas en un repositorio para implementar el sistema
operativo y los servicios en contenedores. Cada contenedor tiene un adaptador de red
virtual que se conecta a un conmutador virtual y reenvía el tráfico entrante y saliente.
Puede asociar puntos de conexión de contenedor a una red de host local (como NAT), la
red física o la red virtual superpuesta creada a través de la pila de SDN.
Para aplicar el aislamiento entre contenedores en el mismo host, cree un
compartimiento de red para cada contenedor Windows Server y Hyper-V. Los
contenedores de Windows Server usan una vNIC de host para conectarse al conmutador
virtual. Los contenedores de Hyper-V usan una NIC de máquina virtual sintética (no
expuesta a la máquina virtual de utilidad) para conectarse al conmutador virtual.

Temas relacionados
Windows redes de contenedores: aprenda a crear y administrar redes de
contenedores para implementaciones sin superposición o SDN.

Conectar puntos de conexión de contenedor a una red virtual de inquilino:

aprenda a crear y administrar redes de contenedor para redes virtuales
superpuestas con SDN.
Planeamiento de una infraestructura de
red definida por software
Artículo • 23/01/2023 • Tiempo de lectura: 15 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2; Windows Server 2022,
Windows Server 2019, Windows Server 2016

Obtenga información sobre cómo planear la implementación de una infraestructura de

red definida por software en la que se incluyan los requisitos previos de hardware y
software. En este tema se incluyen los requisitos de planeamiento de la configuración de
red física y lógica, el enrutamiento, las puertas de enlace, el hardware de red, etc.
También incluye consideraciones sobre la extensión de una infraestructura de SDN y el
uso de una implementación por fases.

７ Nota

SDN no se admite en clústeres extendidos (multisitio).

Requisitos previos
Hay varios requisitos previos de hardware y software para una infraestructura de SDN,
entre los que se incluyen:

Grupos de seguridad y registro DNS dinámico. Debe preparar el centro de datos

para la implementación del rol Controladora de red, para lo cual se necesita un
conjunto de máquinas virtuales. Para poder implementar Controladora de red,
debe configurar los grupos de seguridad y el registro DNS dinámico.

Para más información acerca de la implementación de Controladora de red para el

centro de datos, consulte Requisitos de implementación de Controladora de red.

Red física. Necesita acceso a los dispositivos de red física para configurar las redes
de área local virtual, el enrutamiento y el Protocolo de puerta de enlace de borde
(BGP). En este tema se proporcionan instrucciones para la configuración manual de
conmutadores, así como opciones para usar el emparejamiento BGP en
conmutadores y enrutadores de nivel 3, o en una máquina virtual de servidor de
enrutamiento y acceso remoto (RRAS).
 Hosts de proceso físico. Estos hosts ejecutan Hyper-V y son necesarios para
hospedar una infraestructura de SDN y máquinas virtuales de inquilino. Se necesita
un hardware de red específico en estos hosts para obtener el mejor rendimiento,
como se indica en la sección siguiente.

Requisitos de hardware de SDN

En esta sección se proporcionan requisitos de hardware para conmutadores físicos al
planear un entorno de SDN.

Conmutadores y enrutadores

Al seleccionar un conmutador físico y un enrutador para su entorno de SDN, asegúrese

de que admite el siguiente conjunto de funcionalidades:

Configuración de MTU del switchport (obligatorio)

MTU establecidas en >= 1674 bytes (incluido el encabezado L2-Ethernet)
Protocolos L3 (obligatorio)
Enrutamiento multidireccional de igual costo (ECMP)
ECMP basado en BGP (IETF RFC 4271)

Las implementaciones deben admitir las instrucciones obligatorias de los siguientes

estándares IETF:

RFC 2545: extensiones multiprotocolo BGP-4 para el enrutamiento entre dominios

IPv6
RFC 4760: extensiones multiprotocolo para BGP-4
RFC 4893: compatibilidad con BGP para el espacio de números del sistema
autónomo de cuatro octetos
RFC 4456: Reflejo de rutas BGP: una alternativa al protocolo BGP interno de malla
completa (IBGP)
RFC 4724: mecanismo de reinicio estable para BGP

Se requieren los siguientes protocolos de etiquetado:

VLAN: aislamiento de varios tipos de tráfico

Tronco 802.1q

Los elementos siguientes proporcionan control de vínculos:

Calidad de servicio (QoS) (solo se requiere PFC si se usa RoCE)

Selección de tráfico mejorada (802.1Qaz)
Control de flujo basado en prioridades (PFC) (802.1p/Q y 802.1Qbb)
Los siguientes elementos proporcionan disponibilidad y redundancia:

Disponibilidad del conmutador (obligatorio)

Se requiere un enrutador de alta disponibilidad para realizar funciones de puerta
de enlace. Puede proporcionarlo mediante el uso de un conmutador o enrutador
de varios chasis, o tecnologías como el protocolo de redundancia de enrutador
virtual (VRRP).

Configuración de la red física y lógica

Cada host de proceso físico requiere conectividad de red a través de uno o varios
adaptadores de red conectados a un puerto del conmutador físico. Una VLAN de
nivel 2 admite redes divididas en varios segmentos de red lógica.

 Sugerencia

Use VLAN 0 para redes lógicas en modo de acceso o sin etiquetar.

） Importante

Las redes definidas por software de Windows Server 2016 admiten el

direccionamiento IPv4 para las redes subyacentes y superpuestas. No se admite
IPv6. Windows Server 2019 admite el direccionamiento IPv4 e IPv6.

Redes lógicas
En esta sección se describen los requisitos de planeamiento de la infraestructura de red
definida por software para la red lógica de administración y la red lógica del proveedor
de virtualización de red de Hyper-V (HNV). Incluye detalles sobre el aprovisionamiento
de redes lógicas adicionales para que usen puertas de enlace y el equilibrador de carga
de software, así como una topología de red de ejemplo.

Proveedor de administración y de virtualización de red de Hyper-V

(HNV)
Todos los hosts de proceso físicos deben tener acceso a la red lógica de administración
y a la red lógica del proveedor de HNV. Por lo que respecta al planeamiento de
direcciones IP, cada host de proceso físico debe tener al menos una dirección IP
asignada desde la red lógica de administración. Controladora de red requiere una
dirección IP reservada desde esta red para que sirva como dirección IP de Transferencia
de estado representacional (REST).

La red del proveedor de HNV sirve como la red física subyacente para el tráfico de
inquilino este-oeste (interno-interno), el tráfico de inquilino norte-sur (externo-interno)
y para intercambiar información sobre el emparejamiento BGP con la red física.

Un servidor DHCP puede asignar automáticamente direcciones IP para la red de

administración, o el usuario puede asignar direcciones IP estáticas de forma manual. La
pila de la red definida por software asigna automáticamente direcciones IP para la red
lógica del proveedor de HNV para los hosts de Hyper-V individuales de un grupo de
direcciones IP. Controladora de red especifica y administra el grupo de direcciones IP.

７ Nota

Controladora de red asigna una dirección IP del proveedor de HNV a un host de

proceso físico solo después de que el agente de host de Controladora de red
reciba la directiva de red de una máquina virtual de inquilino específica.

Si... En ese caso...

Las redes lógicas El host de proceso físico debe conectarse a un puerto del conmutador
usan VLAN. troncal que tenga acceso a las VLAN. Es importante tener en cuenta que
los adaptadores de red físicos del host del equipo no deben tener
activado ningún filtrado de VLAN.

Está usando Debe conectar todos los miembros del equipo de tarjeta de interfaz de
Switched-Embedded red de ese host concreto al mismo dominio de difusión de nivel 2.
Teaming (SET) y
tiene varios
miembros de un
equipo de tarjeta de
interfaz de red
como, por ejemplo,
adaptadores de red.

El host de proceso Asegúrese de que la red lógica de administración tenga suficientes

físico ejecuta direcciones IP para cada máquina virtual hospedada. Además, asegúrese
máquinas virtuales de que la red lógica del proveedor de HNV tiene suficientes direcciones IP
de infraestructura para asignarlas a cada máquina virtual de infraestructura de SLB/MUX y de
adicionales como puerta de enlace. Aunque Controladora de red administra la reserva de IP,
Controladora de red, si se produce un error al reservar una nueva dirección IP debido a una
SLB/Multiplexor falta de disponibilidad, se pueden generar direcciones IP duplicadas en la
(MUX) o puerta de red.
enlace.
Para más información acerca de la virtualización de red de Hyper-V (HNV) que puede
usar para virtualizar redes en una implementación de Microsoft SDN, consulte
Virtualización de red de Hyper-V.

Puertas de enlace y equilibrador de carga de software (SLB)

Debe crear y aprovisionar redes lógicas adicionales para usar las puertas de enlace y el
equilibrador de carga de software. Asegúrese de obtener los prefijos IP, identificadores
de VLAN y direcciones IP de puerta de enlace correctos para estas redes.

Red lógica Descripción

Red lógica de La red lógica de IP virtual (VIP) pública debe usar prefijos de subred IP que sean
VIP pública enrutables fuera del entorno de nube (normalmente enrutable a Internet). Estas
son las direcciones IP de front-end que usan los clientes externos para acceder a
los recursos de las redes virtuales, incluida la red lógica de IP virtual de front-end
para la puerta de enlace de sitio a sitio. No es necesario que asigne una VLAN a
esta red.

Red lógica de No es necesario que la red lógica de IP virtual privada sea enrutable fuera de la
VIP privada nube. Esto se debe a que solo la usan las redes lógicas de IP virtual a las que se
puede acceder desde clientes de la nube internos como, por ejemplo, los
servicios privados. No es necesario que asigne una VLAN a esta red.

Red lógica de La red VIP de encapsulación de enrutamiento genérico (GRE) es una subred que
IP virtual de existe únicamente para definir redes VIP. Las VIP se asignan a las máquinas
encapsulación virtuales de puerta de enlace que se ejecutan en el tejido de SDN para un tipo
de de conexión GRE de sitio a sitio (S2S). No es necesario que configure
enrutamiento previamente esta red en los conmutadores físicos o el enrutador, ni que le
genérico asigne una VLAN.

Ejemplo de topología de red

Cambie los prefijos de subred IP de ejemplo y los identificadores de VLAN para su
entorno.

Nombre de Subnet Máscara Id. de Puerta de Reserva (ejemplos)

red VLAN en enlace
tronco
 Nombre de Subnet Máscara Id. de Puerta de Reserva (ejemplos)
red VLAN en enlace
tronco

Administración [Link] 24 7 [Link] [Link]: enrutador

[Link]:
Controladora de red
[Link]: host de
proceso 1
[Link]: host de
proceso 2
10.184.108.X: host de
proceso X

Proveedor de [Link] 23 11 [Link] [Link]: enrutador

HNV [Link]: SLB/MUX1
[Link]: Gateway1

VIP pública [Link] 27 NA [Link] [Link]: enrutador

[Link]: IP virtual de
VPN de sitio a sitio de
IPSec

VIP privadas [Link] 27 NA [Link] [Link]: puerta de

enlace predeterminada
(enrutador)

VIP GRE [Link] 24 NA [Link] [Link]: puerta de

enlace predeterminada

Infraestructura de enrutamiento
La información de enrutamiento (por ejemplo, el próximo salto) de las subredes VIP se
anuncia mediante las puertas de enlace de SLB/MUX y del servidor de acceso remoto
(RAS) en la red física mediante el emparejamiento BGP interno. Las redes lógicas de IP
virtual no tienen una VLAN asignada y no están preconfiguradas en el conmutador de
nivel 2 (como, por ejemplo, el conmutador de la parte superior del rack).

Debe crear un par BGP en el enrutador que la infraestructura de SDN use para recibir las
rutas de las redes lógicas de IP virtual anunciadas por las puertas de enlace de SLB/MUX
y RAS. El emparejamiento BGP solo tiene que producirse en una dirección (desde la
puerta de enlace SLB/MUX o RAS hasta el par BGP externo). Por encima del primer nivel
de enrutamiento, puede utilizar rutas estáticas u otro protocolo de enrutamiento
dinámico como Abrir primero la ruta de acceso más corta (OSPF). Sin embargo, como se
indicó anteriormente, el prefijo de subred IP para las redes lógicas de IP virtual debe ser
enrutable desde la red física al par BGP externo.
El emparejamiento BGP normalmente se configura en un conmutador o enrutador
administrado como parte de la infraestructura de red. El par BGP también puede
configurarse en un servidor de Windows Server con el rol RAS instalado en un modo de
solo enrutamiento. El enrutador BGP del mismo nivel de la infraestructura de red se
debe configurar para usar sus propios números de sistema autónomo (ASN) y permitir
el emparejamiento de un ASN que esté asignado a los componentes de la SDN (puertas
de enlace de SLB/MUX y RAS).

Debe obtener la siguiente información del enrutador físico o del administrador de red
que controla ese enrutador:

ASN del enrutador

Dirección IP del enrutador

７ Nota

El SLB o MUX no admite ASN de cuatro bytes. Debe asignar ASN de dos bytes al
SLB o MUX, y al enrutador al que se conecta. Puede usar ASN de cuatro bytes en
otros lugares de su entorno.

El usuario o el administrador de red deben configurar el enrutador BGP del mismo nivel
para que acepte conexiones desde el ASN y la dirección IP, o desde la dirección de
subred de la red lógica del proveedor de HNV que esté usando la puerta de enlace de
RAS y SLB o MUX.

Para más información, consulte Protocolo de puerta de enlace de borde (BGP).

Puertas de enlace predeterminadas

Las máquinas configuradas para conectarse a varias redes como, por ejemplo, las
máquinas virtuales de hosts físicos, SLB/MUX y puertas de enlace solo deben tener una
puerta de enlace predeterminada configurada. Use las siguientes puertas de enlace
predeterminadas para los hosts y las máquinas virtuales de la infraestructura:

En el caso de los hosts de Hyper-V, use la red de administración como la puerta de

enlace predeterminada.
En el caso de las máquinas virtuales de Controladora de red, use la red de
administración como puerta de enlace predeterminada.
En el caso de las máquinas virtuales de SLB/MUX, use la red de administración
como la puerta de enlace predeterminada.
 En el caso de las máquinas virtuales de puerta de enlace, use la red del proveedor
de HNV como puerta de enlace predeterminada. Esto se debe establecer en la NIC
de front-end de las máquinas virtuales de puerta de enlace.

Conmutadores y enrutadores
Para ayudar a configurar el conmutador físico o enrutador, hay disponible un conjunto
de archivos de configuración de ejemplo para diversos modelos y proveedores de
conmutadores en el repositorio de GitHub de Microsoft SDN . Se proporciona un
archivo Léame y comandos comprobados de la interfaz de la línea de comandos (CLI)
para conmutadores específicos.

Para conocer los requisitos detallados de conmutadores y enrutadores, consulte la

sección de requisitos de hardware de SDN anterior.

Compute
Todos los hosts de Hyper-V deben tener instalado el sistema operativo adecuado, estar
habilitados para Hyper-V y usar un conmutador virtual externo de Hyper-V con al
menos un adaptador físico conectado a la red lógica de administración. El host debe ser
accesible a través de una dirección IP de administración asignada a la NIC virtual del
host de administración.

Puede usar cualquier tipo de almacenamiento que sea compatible con Hyper-V,
compartido o local.

 Sugerencia

Es conveniente usar el mismo nombre para todos los conmutadores virtuales, pero
no es obligatorio. Si tiene previsto usar scripts para la implementación, consulte el
comentario asociado a la variable vSwitchName en el archivo config.psd1.

Requisitos de proceso del host

A continuación se muestran los requisitos mínimos de hardware y software para los
cuatro hosts físicos usados en la implementación de ejemplo.

administrador de Requisitos de hardware Requisitos de software

flujos de trabajo
 administrador de Requisitos de hardware Requisitos de software
flujos de trabajo

Host físico de Hyper-V CPU de 4 núcleos a 2,66 GHz Sistema operativo: Como se
32 GB de RAM define en la sección
300 GB de espacio en disco "Se aplica a" que aparece al
Un adaptador de red físico de principio de este tema.
1 Gb/s (o más rápido) Rol de Hyper-V instalado

Requisitos del rol de máquina virtual de infraestructura

de SDN
En la tabla siguiente se enumeran los requisitos de los roles de máquina virtual.

Rol Requisitos de Requisitos Requisitos de disco

CPU virtual de memoria

Controladora de red (tres nodos) 4 vCPU 4 GB como 75 GB para la unidad

mínimo de sistema operativo
(se
recomiendan
8 GB)

SLB/MUX (tres nodos) 8 vCPU Se 75 GB para la unidad

recomiendan de sistema operativo
8 GB

Puerta de enlace RAS 8 vCPU Se 75 GB para la unidad

(grupo único de puerta de enlace recomiendan de sistema operativo
de tres nodos, dos activos, uno 8 GB
pasivo)

Enrutador BGP de puerta de enlace de 2 CPU 2 GB 75 GB para la unidad

RAS virtuales de sistema operativo
para el emparejamiento de SLB/MUX
(como alternativa, use el conmutador
para la parte superior del rack
como enrutador BGP)

Si usa System Center Virtual Machine Manager (VMM) para la implementación, se

necesitarán recursos de máquinas virtuales de infraestructura adicionales para VMM y
otras infraestructuras que no sean de SDN. Para más información, consulte Requisitos
del sistema para System Center Virtual Machine Manager.

Ampliación de la infraestructura
Los requisitos de tamaño y recursos de la infraestructura dependen de las máquinas
virtuales de carga de trabajo de inquilino que planea hospedar. Los requisitos de CPU,
memoria y disco de las máquinas virtuales de infraestructura (por ejemplo: Controladora
de red, SLB, puerta de enlace, etc.) se definen en la tabla anterior. Puede agregar más
máquinas virtuales de infraestructura para realizar un escalado según sea necesario. Sin
embargo, las máquinas virtuales de los inquilinos que se ejecutan en los hosts de Hyper-
V tienen sus propios requisitos de CPU, memoria y disco que se deben tener en cuenta.

Si las máquinas virtuales de la carga de trabajo de los inquilinos empiezan a consumir

demasiados recursos en los hosts de Hyper-V físicos, puede ampliar la infraestructura
mediante la incorporación de hosts físicos adicionales. Puede usar Windows Admin
Center, VMM o scripts de PowerShell para crear nuevos recursos de servidor a través de
Controladora de red. El método que se utilice depende de la implementación inicial de
la infraestructura. Si necesita agregar más direcciones IP para la red del proveedor de
HNV, puede crear nuevas subredes lógicas (con los grupos de direcciones IP
correspondientes) que los hosts puedan usar.

Implementación por fases

En función de sus requisitos, puede que necesite implementar un subconjunto de la
infraestructura de SDN. Por ejemplo, si solo quiere hospedar cargas de trabajo de
clientes en su centro de datos y no se requiere comunicación externa, puede
implementar Controladora de red y omitir la implementación de máquinas virtuales de
SLB/MUX y puerta de enlace. A continuación se describen los requisitos de
infraestructura de la característica de red para una implementación por fases de la
infraestructura de SDN.

Característica Requisitos para la Requisitos de red

implementación

Administración de red lógica Controladora de red Ninguno

Grupos de seguridad de red (NSG) (para
la red basada en VLAN)
Calidad de servicio (para redes basadas
en VLAN)

Redes virtuales Controladora de red VLAN, subred y enrutador

Enrutamiento definido por el usuario de PA de HNV
Listas de control de acceso (para red
virtual)
Subredes cifradas
Calidad de servicio (para redes virtuales)
Emparejamiento de redes virtuales de
Azure
 Característica Requisitos para la Requisitos de red
implementación

Traducción de direcciones de red Controladora de red BGP en la red de PA de

entrantes o salientes SLB/MUX HNV
Equilibrio de carga Subredes de IP virtual
privadas y públicas

Conexiones de puerta de enlace de GRE Controladora de red BGP en la red de PA de

SLB/MUX HNV
Puerta de enlace Subredes de IP virtual
privadas y públicas
Subred de IP virtual de
GRE

Conexiones de puerta de enlace de IPSec Controladora de red BGP en la red de PA de

SLB/MUX HNV
Puerta de enlace Subredes de IP virtual
privadas y públicas

Conexiones de puerta de enlace L3 Controladora de red BGP en la red de PA de

SLB/MUX HNV
Puerta de enlace Subredes de IP virtual
privadas y públicas
VLAN, subred y enrutador
de inquilino
BGP en la VLAN de
inquilino opcional

Pasos siguientes
Para obtener información relacionada, consulte:

Requisitos de implementación de Controladora de red

SDN en Azure Stack HCI
Módulo de Learn: Planeación e implementación de la infraestructura de SDN en
Azure Stack HCI
Plan de implementación de
Controladora de red
Artículo • 23/01/2023 • Tiempo de lectura: 4 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2; Windows Server 2022,
Windows Server 2019, Windows Server 2016

La planeación de la implementación de Controladora de red mediante Windows Admin

Center requiere un conjunto de máquinas virtuales que ejecuten el sistema operativo de
Azure Stack HCI o Windows Server. Controladora de red es un rol del servidor escalable
y de alta disponibilidad que requiere un mínimo de tres máquinas virtuales para
proporcionar alta disponibilidad en la red.

７ Nota

Es recomendable implementar Controladora de red en sus propias máquinas

virtuales dedicadas.

Requisitos de Controladora de red

Se requiere lo siguiente para implementar Controladora de red:

Un disco duro virtual para el sistema operativo de Azure Stack HCI para crear las
máquinas virtuales de Controladora de red.

Un nombre de dominio y credenciales para unir las máquinas virtuales de

Controladora de red a un dominio.

Al menos un conmutador virtual que configure mediante el asistente para la

creación de clústeres de Windows Admin Center.

Una configuración de red física que coincida con una de las opciones de topología
de esta sección.

Windows Admin Center crea la configuración en el host de Hyper-V. Sin embargo,

la red de administración debe conectarse a los adaptadores físicos del host de
acuerdo con una de las tres opciones siguientes:

Opción 1: La red de administración está físicamente separada de las redes de carga

de trabajo. Esta opción usa un solo conmutador virtual para el proceso y el
almacenamiento:

Opción 2: La red de administración está físicamente separada de las redes de

carga de trabajo. Esta opción usa un único conmutador virtual solo para el
proceso:

Opción 3: La red de administración está físicamente separada de las redes de

carga de trabajo. Esta opción usa dos conmutadores virtuales, uno para el proceso
y otro para el almacenamiento:


 También puede agrupar los adaptadores físicos de administración para que usen el
mismo conmutador de administración. En este caso, se recomienda seguir usando
una de las opciones de esta sección.

Información de la red de administración que utiliza Controladora de red para

comunicarse con Windows Admin Center y los hosts de Hyper-V.

Direccionamiento basado en DHCP o en la red estática para las máquinas virtuales

de la controladora de red.

El nombre de dominio completo de Transferencia de estado representacional

(REST) para Controladora de red que usan los clientes de administración para
comunicarse con Controladora de red.

７ Nota

Windows Admin Center no admite actualmente la autenticación de

Controladora de red para la comunicación con clientes REST ni para la
comunicación entre las máquinas virtuales de Controladora de red. Puede
usar la autenticación basada en Kerberos si usa PowerShell para
implementarla y administrarla.

Actualizaciones dinámicas de DNS

Puede implementar los nodos de clúster de Controladora de red en la misma subred o
en subredes diferentes. Si planea implementar los nodos de clúster de Controladora de
red en distintas subredes, debe proporcionar el nombre DNS de REST de Controladora
de red durante el proceso de implementación.

Habilitación de actualizaciones dinámicas de DNS para

una zona
Para habilitar las actualizaciones dinámicas de DNS para una zona, realice los pasos
siguientes:

1. En el servidor DNS, abra la consola del Administrador de DNS.

2. En el panel izquierdo, seleccione Zonas de búsqueda directa.
3. Haga clic con el botón derecho en la zona que hospeda el registro de nombres del
controlador de red y, a continuación, haga clic en Propiedades.
4. En la pestaña General, junto a Actualizaciones dinámicas, seleccione Secure only
(Solo proteger).
Restricción de las actualizaciones dinámicas a los nodos
del controlador de red
Para restringir las actualizaciones dinámicas del registro de nombres del controlador de
red solo a los nodos del controlador de red, realice los pasos siguientes:

1. En el servidor DNS, abra la consola del Administrador de DNS.

2. En el panel izquierdo, seleccione Zonas de búsqueda directa.
3. Haga clic con el botón derecho en la zona que hospeda el registro de nombres del
controlador de red y, a continuación, haga clic en Propiedades.
4. En la pestaña Seguridad, seleccione Avanzado.
5. Seleccione Agregar.
6. Elija Seleccionar una entidad de seguridad.
7. En el cuadro de diálogo Seleccionar usuario, equipo, cuenta de servicio o grupo,
seleccione Tipos de objeto. Seleccione Equipos y haga clic en Aceptar.
8. En el cuadro de diálogo Seleccionar usuario, equipo, cuenta de servicio o grupo,
escriba el nombre de equipo de uno de los nodos del controlador de red y haga
clic en Aceptar.
9. En Tipo, seleccione Permitir.
10. En Permisos, seleccione Control total.
11. Haga clic en OK.
12. Repita los pasos del 5 al 11 para todos los equipos del clúster del controlador de
red.

Pasos siguientes
Ahora está listo para implementar Controladora de red en las máquinas virtuales.

Vea también
Creación de un clúster de Azure Stack HCI
Implementación de una infraestructura de SDN mediante SDN Express
Introducción a la controladora de red
Alta disponibilidad de Controladora de red
Implementación de una infraestructura
de red definida por software
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Implemente la infraestructura de redes definidas por software (SDN) de Microsoft.

Estas implementaciones incluyen todas las tecnologías que necesita para una
infraestructura totalmente funcional, incluida la virtualización de red de Hyper-V (HNV),
los controladores de red, los equilibradores de carga de software (SLB/MUX) y las
puertas de enlace.

Configuración de la infraestructura de SDN en

el tejido de VMM
Configurar una infraestructura de Redes definidas por software (SDN) en el tejido
de VMM

Use este método si desea incorporar System Center Virtual Machine Manager
(VMM) para administrar la infraestructura de SDN.

Implementación de la infraestructura de SDN

mediante scripts
Implementación de una infraestructura de red definida por software con scripts

Use este método si no desea usar VMM para administrar la infraestructura de SDN
o si tiene otro método de administración.

Implementación de tecnologías de SDN

individuales en lugar de una infraestructura
completa
Si desea implementar tecnologías de SDN individuales en lugar de una infraestructura
completa, consulte: Implementación de tecnologías de red definidas por software
mediante Windows PowerShell.

Temas relacionados
Redes definidas por software (SDN)
Tecnologías sdn
Planear SDN
Administrar SDN
Seguridad para SDN
Solucionar problemas de SDN
Implementación de una infraestructura
de red definida por software con scripts
Artículo • 21/12/2022 • Tiempo de lectura: 9 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En este tema, implementará una infraestructura de red definida por software (SDN) de
Microsoft mediante scripts. La infraestructura incluye una controladora de red de alta
disponibilidad (HA), una Load Balancer de software de alta disponibilidad (SLB)/MUX,
redes virtuales y listas de Access Control asociadas (ACL). Además, otro script
implementa una carga de trabajo de inquilino para que valide la infraestructura de SDN.

Si desea que las cargas de trabajo de inquilino se comuniquen fuera de sus redes
virtuales, puede configurar reglas NAT de SLB, túneles de puerta de enlace de sitio a
sitio o reenvío de nivel 3 para enrutar entre cargas de trabajo virtuales y físicas.

También puede implementar una infraestructura de SDN mediante Virtual Machine

Manager (VMM). Para obtener más información, consulte Configuración de una
infraestructura de red definida por software (SDN) en el tejido de VMM.

Anterior a la implementación

） Importante

Antes de comenzar la implementación, debe planear y configurar los hosts y la

infraestructura de red física. Para más información, consulta Planeación de una
infraestructura de red definida por software.

Todos los hosts de Hyper-V deben tener instalado Windows Server 2019 o 2016.

Pasos de implementación
Empiece por configurar el conmutador virtual de Hyper-V (servidores físicos) del host de
Hyper-V y la asignación de direcciones IP. Se puede usar cualquier tipo de
almacenamiento compatible con Hyper-V, compartido o local.

Instalación de redes de host

1. Instale los controladores de red más recientes disponibles para el hardware NIC.

2. Instale el rol de Hyper-V en todos los hosts (para obtener más información,
consulte Comenzar con Hyper-V en Windows Server 2016.

PowerShell

Install-WindowsFeature -Name Hyper-V -ComputerName <computer_name> -

IncludeManagementTools -Restart

3. Cree el conmutador virtual de Hyper-V.

Use el mismo nombre de modificador para todos los hosts, por ejemplo,
sdnSwitch. Configure al menos un adaptador de red o, si usa SET, configure al
menos dos adaptadores de red. La propagación de entrada máxima se produce
cuando se usan dos NIC.

PowerShell

New-VMSwitch "<switch name>" -NetAdapterName "<NetAdapter1>" [, "

<NetAdapter2>" -EnableEmbeddedTeaming $True] -AllowManagementOS $True

 Sugerencia

Puede omitir los pasos 4 y 5 si tiene NIC de administración independientes.

4. Consulte el tema de planeación (Planear una infraestructura de red definida por

software) y trabaje con el administrador de red para obtener el identificador VLAN
de la VLAN de administración. Adjunte la vNIC de administración del conmutador
virtual recién creado a la VLAN de administración. Este paso se puede omitir si el
entorno no usa etiquetas VLAN.

PowerShell

Set-VMNetworkAdapterIsolation -ManagementOS -IsolationMode Vlan -

DefaultIsolationID <Management VLAN> -AllowUntaggedTraffic $True

5. Consulte el tema de planeación (Planear una infraestructura de red definida por

software) y trabaje con el administrador de red para usar asignaciones DE IP
estáticas o DHCP para asignar una dirección IP a la vNIC de administración de la
vSwitch recién creada. En el ejemplo siguiente se muestra cómo crear una
dirección IP estática y asignarla a la vNIC de administración del vSwitch:
 PowerShell

New-NetIPAddress -InterfaceAlias "vEthernet (<switch name>)" -IPAddress

<IP> -DefaultGateway <Gateway IP> -AddressFamily IPv4 -PrefixLength
<Length of Subnet Mask - for example: 24>

6. [Opcional] Implemente una máquina virtual para hospedar Servicios de dominio de

Active Directory (instalar Servicios de dominio de Active Directory (nivel 100) y un
servidor DNS.

a. Conectar la máquina virtual del servidor Active Directory/DNS a la VLAN de

administración:

PowerShell

Set-VMNetworkAdapterIsolation -VMName "<VM Name>" -Access -VlanId

<Management VLAN> -AllowUntaggedTraffic $True

b. Instale Servicios de dominio de Active Directory y DNS.

７ Nota

La controladora de red admite certificados Kerberos y X.509 para la

autenticación. En esta guía se usan ambos mecanismos de autenticación para
distintos fines (aunque solo se requiere uno).

7. Una todos los hosts de Hyper-V al dominio. Asegúrese de que la entrada del
servidor DNS para el adaptador de red que tiene una dirección IP asignada a los
puntos de red de administración a un servidor DNS que pueda resolver el nombre
de dominio.

PowerShell

Set-DnsClientServerAddress -InterfaceAlias "vEthernet (<switch name>)"

-ServerAddresses <DNS Server IP>

a. Haga clic con el botón derecho en Inicio, haga clic en Sistemay, a continuación,
haga clic en Cambiar Configuración. b. Haga clic en Cambiar. c. Haga clic en
Dominio y especifique el nombre de dominio. """" d. Haga clic en Aceptar. e.
Escriba el nombre de usuario y las credenciales de contraseña cuando se le solicite.
f. Reinicie el servidor.
Validación
Siga estos pasos para validar que las redes de host están configuradas correctamente.

1. Asegúrese de que el conmutador de máquina virtual se creó correctamente:

PowerShell

Get-VMSwitch "<switch name>"

2. Compruebe que la vNIC de administración en el conmutador de máquina virtual

está conectada a la VLAN de administración:

７ Nota

Solo es relevante si el tráfico de administración e inquilino comparten la

misma NIC.

PowerShell

Get-VMNetworkAdapterIsolation -ManagementOS

3. Valide todos los hosts de Hyper-V y los recursos de administración externos, por
ejemplo, servidores DNS.

Asegúrese de que son accesibles a través de ping mediante su dirección IP de

administración o el nombre de dominio completo (FQDN).

ping <Hyper-V Host IP>

ping <Hyper-V Host FQDN>

4. Ejecute el siguiente comando en el host de implementación y especifique el FQDN

de cada host de Hyper-V para asegurarse de que las credenciales de Kerberos
usadas proporcionan acceso a todos los servidores.

winrm id -r:<Hyper-V Host FQDN>

Ejecución de scripts de SDN Express

1. Vaya al repositorio de GitHub SDN de Microsoft para los archivos de instalación.

2. Descargue los archivos de instalación del repositorio en el equipo de

implementación designado. Haga clic en Clonar o descargar y, a continuación,
haga clic en Descargar ZIP.

７ Nota

El equipo de implementación designado debe ejecutar Windows Server 2016

o versiones posteriores.

3. Expanda el archivo ZIP y copie la carpeta SDNExpress en la carpeta del equipo de

C:\ implementación.

4. Comparta la C:\SDNExpress carpeta como "SDNExpress" con permiso para que

Todos los usuarioslean y escriban.

5. Vaya a la carpeta C:\SDNExpress .

Verá las siguientes carpetas:

Nombre de Descripción
carpeta

AgentConf Contiene copias nuevas de esquemas OVSDB usados por el agente de host
de SDN en cada host de Hyper-V Windows Server 2016 para programar la
directiva de red.

Certificados Ubicación compartida temporal para el archivo de certificado NC.

Imágenes Vacía, coloque la imagen de vhdx de Windows Server 2016 aquí.

Herramientas Utilidades para solucionar problemas y depurar. Copiado en los hosts y

máquinas virtuales. Se recomienda colocar monitor de red o Wireshark aquí
para que esté disponible si es necesario.
 Nombre de Descripción
carpeta

Scripts Scripts de implementación.

- SDNExpress.ps1
Implementa y configura el tejido, incluidas las máquinas virtuales de
controladora de red, las máquinas virtuales mux de SLB, los grupos de
puertas de enlace y las máquinas virtuales de puerta de enlace de HNV
correspondientes a los grupos.
- FabricConfig.psd1
Plantilla de archivo de configuración para el script SDNExpress. Lo
personalizará para su entorno.
- SDNExpressTenant.ps1
Implementa una carga de trabajo de inquilino de ejemplo en una red virtual
con una VIP con equilibrio de carga.
También aprovisiona una o varias conexiones de red (VPN de IPSec S2S,
GRE, L3) en las puertas de enlace perimetrales del proveedor de servicios
que están conectadas a la carga de trabajo de inquilino creada
anteriormente. Las puertas de enlace IPSec y GRE están disponibles para la
conectividad a través de la dirección IP VIP correspondiente y la puerta de
enlace de reenvío L3 a través del grupo de direcciones correspondiente.
Este script también se puede usar para eliminar la configuración
correspondiente con una opción Deshacer.
- TenantConfig.psd1
Un archivo de configuración de plantilla para la carga de trabajo del
inquilino y la configuración de la puerta de enlace de S2S.
- SDNExpressUndo.ps1
Limpia el entorno de tejido y lo restablece a un estado inicial.
- SDNExpressEnterpriseExample.ps1
Aprovisiona uno o varios entornos de sitio empresarial con una puerta de
enlace de acceso remoto y (opcionalmente) una máquina virtual
empresarial correspondiente por sitio. Las puertas de enlace empresariales
IPSec o GRE se conectan a la dirección IP IP correspondiente de la puerta
de enlace del proveedor de servicios para establecer los túneles S2S. La
puerta de enlace de reenvío L3 se conecta a través de la dirección IP del
mismo nivel correspondiente.
Este script también se puede usar para eliminar la configuración
correspondiente con una opción Deshacer.
- EnterpriseConfig.psd1
Un archivo de configuración de plantilla para la puerta de enlace de sitio a
sitio Enterprise y la configuración de máquina virtual cliente.

TenantApps Archivos usados para implementar cargas de trabajo de inquilino de

ejemplo.

6. Compruebe que el archivo VHDX de Windows Server 2016 está en la carpeta

Imágenes.
 7. Personalice el archivo SDNExpress\scripts\FabricConfig.psd1 cambiando las <<
etiquetas Replace >> por valores específicos para ajustarse a la infraestructura de
laboratorio, incluidos los nombres de host, los nombres de dominio, los nombres
de usuario y las contraseñas, y la información de red de las redes enumeradas en
el tema Planning Network.

8. Cree un registro host A en DNS para NetworkControllerRestName (FQDN) y

NetworkControllerRestIP.

9. Ejecute el script como usuario con credenciales de administrador de dominio:

SDNExpress\scripts\SDNExpress.ps1 -ConfigurationDataFile
FabricConfig.psd1 -Verbose

10. Para deshacer todas las operaciones, ejecute el siguiente comando:

SDNExpress\scripts\SDNExpressUndo.ps1 -ConfigurationDataFile
FabricConfig.psd1 -Verbose

Validación

Suponiendo que el script de SDN Express se ejecutó hasta su finalización sin notificar
errores, puede realizar el siguiente paso para asegurarse de que los recursos de tejido
se han implementado correctamente y están disponibles para la implementación del
inquilino.

Use herramientas de diagnóstico para asegurarse de que no haya errores en los

recursos de tejido de la controladora de red.

Debug-NetworkControllerConfigurationState -NetworkController <FQDN of

Network Controller Rest Name>

Implementación de una carga de trabajo de inquilino de

ejemplo con el equilibrador de carga de software
Ahora que se han implementado recursos de tejido, puede validar la implementación de
SDN de un extremo a otro mediante la implementación de una carga de trabajo de
inquilino de ejemplo. Esta carga de trabajo de inquilino consta de dos subredes virtuales
(nivel web y nivel de base de datos) protegidas a través de reglas de lista de Access
Control (ACL) mediante el firewall distribuido de SDN. La subred virtual del nivel web es
accesible a través de SLB/MUX mediante una dirección IP virtual (VIP). El script
implementa automáticamente dos máquinas virtuales de nivel web y una máquina
virtual de nivel de base de datos y las conecta a las subredes virtuales.

1. Personalice el archivo SDNExpress\scripts\TenantConfig.psd1 cambiando las <<

etiquetas Replace >> por valores específicos (por ejemplo: nombre de imagen
VHD, nombre REST de controladora de red, nombre vSwitch, etc. como se definió
anteriormente en el archivo FabricConfig.psd1).

2. Ejecute el script. Por ejemplo:

SDNExpress\scripts\SDNExpressTenant.ps1 -ConfigurationDataFile
TenantConfig.psd1 -Verbose

3. Para deshacer la configuración, ejecute el mismo script con el parámetro deshacer

. Por ejemplo:

SDNExpress\scripts\SDNExpressTenant.ps1 -Undo -ConfigurationDataFile

TenantConfig.psd1 -Verbose

Validación
Para validar que la implementación del inquilino se realizó correctamente, haga lo
siguiente:

1. Inicie sesión en la máquina virtual del nivel de base de datos e intente hacer ping a
la dirección IP de una de las máquinas virtuales de nivel web (asegúrese de que
Windows Firewall está desactivado en máquinas virtuales de nivel web).

2. Compruebe los recursos de inquilino de la controladora de red para ver si hay

errores. Ejecute lo siguiente desde cualquier host de Hyper-V con conectividad de
nivel 3 a la controladora de red:

Debug-NetworkControllerConfigurationState -NetworkController <FQDN of

Network Controller REST Name>
3. Para comprobar que el equilibrador de carga se está ejecutando correctamente,
ejecute lo siguiente desde cualquier host de Hyper-V:

wget <VIP IP address>/[Link] -disablekeepalive -usebasicparsing

donde <VIP IP address> es la dirección IP IP VIP de nivel web que configuró en el

archivo TenantConfig.psd1.

 Sugerencia

Busque la VIPIP variable en TenantConfig.psd1.

Ejecute esto varias veces para ver el conmutador del equilibrador de carga entre
los DIP disponibles. También puede observar este comportamiento mediante un
explorador web. Vaya a <VIP IP address>/[Link] . Cierre el explorador y abra
una nueva instancia y vuelva a examinar. Verá la página azul y la página verde
alternativa, excepto cuando el explorador almacena en caché la página antes de
que se agote el tiempo de espera de la memoria caché.
Implementación de tecnologías de red
definidas por software mediante
Windows PowerShell
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Puede usar los temas de esta sección para implementar tecnologías de SDN individuales
mediante Windows PowerShell.

Esta sección contiene el tema siguiente:

Implementación de controladora de red con Windows PowerShell

Implementación de controladora de red
con Windows PowerShell
Artículo • 21/12/2022 • Tiempo de lectura: 15 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En este tema se proporcionan instrucciones sobre el uso de Windows PowerShell para

implementar la controladora de red en una o varias máquinas virtuales que ejecutan
Windows Server 2019 o 2016.

） Importante

No implemente el rol del servidor Controladora de red en hosts físicos. Para

implementar controladora de red, debe instalar el rol de servidor controladora de
red en una máquina virtual (VM) de Hyper-V instalada en un host de Hyper-V.
Después de instalar controladora de red en máquinas virtuales en tres hosts de
Hyper-V diferentes, debe habilitar los hosts de Hyper-V para redes definidas por
software (SDN) agregando los hosts a Controladora de red mediante el comando
Windows PowerShell Comando New-NetworkControllerServer. Al hacerlo, permite
funcionar al equilibrador de carga de las redes definidas por software. Para obtener
más información, vea New-NetworkControllerServer.

En este tema se incluyen las siguientes secciones.

Instalación del rol del servidor Controladora de red

Configuración del clúster de Controladora de red

Configuración de la aplicación de Controladora de red

Validación de la implementación de Controladora de red

Comandos de Windows PowerShell adicionales para controladora de red

Script de configuración de Controladora de red de ejemplo

Pasos posteriores a la implementación para implementaciones que no son

kerberos
Instalación del rol del servidor Controladora de
red
Puede usar este procedimiento para instalar el rol de servidor controladora de red en
una máquina virtual (VM).

） Importante

No implemente el rol del servidor Controladora de red en hosts físicos. Para

implementar controladora de red, debe instalar el rol de servidor controladora de
red en una máquina virtual (VM) de Hyper-V instalada en un host de Hyper-V. Una
vez que haya instalado Controladora de red en las máquinas virtuales de tres hosts
de Hyper-V diferentes, debe habilitar estos para redes definidas por software (SDN)
agregando los hosts a Controladora de red. Al hacerlo, permite funcionar al
equilibrador de carga de las redes definidas por software.

El requisito mínimo para realizar este procedimiento es la pertenencia al grupo

Administradores o grupo equivalente.

７ Nota

Si desea usar Administrador del servidor en lugar de Windows PowerShell para

instalar Controladora de red, consulte Instalación del rol del servidor Controladora
de red mediante Administrador del servidor

Para instalar controladora de red mediante Windows PowerShell, escriba los siguientes
comandos en un símbolo del sistema de Windows PowerShell y presione ENTRAR.

Install-WindowsFeature -Name NetworkController -IncludeManagementTools

La instalación de Controladora de red requiere que reinicie el equipo. Para ello, escriba
el siguiente comando y presione ENTRAR.

Restart-Computer

Configuración del clúster de Controladora de

red
El clúster de Controladora de red proporciona alta disponibilidad y escalabilidad a la
aplicación de Controladora de red, aplicación que puede configurar después de crear el
clúster y que se hospeda en la parte superior del clúster.

７ Nota

Puede realizar los procedimientos de las secciones siguientes directamente en la

máquina virtual donde instaló controladora de red, o bien puede usar las
Herramientas de administración remota del servidor para Windows Server 2016
para realizar los procedimientos desde un equipo remoto que ejecuta Windows
Server 2016 o Windows 10. Además, la pertenencia a administradores, o
equivalente, es el mínimo necesario para realizar este procedimiento. Si el equipo o
la máquina virtual en el que instaló la controladora de red está unido a un dominio,
la cuenta de usuario debe ser miembro de los usuarios del dominio.

Puede crear un clúster de Controladora de red mediante la creación de un objeto de

nodo y, posteriormente, la configuración del clúster.

Creación de un objeto de nodo

Debe crear un objeto de nodo para cada máquina virtual que sea miembro del clúster
de Controladora de red.

Para crear un objeto de nodo, escriba el siguiente comando en el símbolo del sistema
Windows PowerShell y presione ENTRAR. Asegúrese de agregar valores para cada
parámetro adecuado para la implementación.

New-NetworkControllerNodeObject -Name <string> -Server <String> -FaultDomain

<string>-RestInterface <string> [-NodeCertificate <X509Certificate2>]

En la tabla siguiente se proporcionan descripciones para cada parámetro del comando

New-NetworkControllerNodeObject .

Parámetro Descripción

Nombre El parámetro Name especifica el nombre descriptivo del servidor que desea
agregar al clúster.

Servidor El parámetro Server especifica el nombre de host, el nombre de dominio

completo o la dirección IP del servidor que desea agregar al clúster. En los
equipos unidos a dominios se requiere el nombre de dominio completo.
 Parámetro Descripción

FaultDomain El parámetro FaultDomain especifica el dominio de error del servidor que se va

a agregar al clúster. Este parámetro define los servidores que pueden
experimentar errores al mismo tiempo que el servidor que se va a agregar al
clúster. Este error puede deberse a las dependencias físicas compartidas como,
por ejemplo, las fuentes de alimentación y las redes. Los dominios de error
suelen representar jerarquías que están relacionadas con estas dependencias
compartidas, con más servidores con más probabilidades de experimentar
errores conjuntamente desde un punto superior del árbol de dominios de error.
Durante el tiempo de ejecución, Controladora de red considera los dominios de
error del clúster e intenta propagar los servicios de Controladora de red para
que estén en dominios de error independientes. Este proceso ayuda a
garantizar, en caso de error de cualquier dominio de error, que no se ponga en
peligro la disponibilidad del servicio y su estado. Los dominios de error se
especifican en un formato jerárquico. Por ejemplo: "Fd:/DC1/Rack1/Host1",
donde DC1 es el nombre del centro de datos, Rack1 es el nombre del bastidor y
Host1 es el nombre del host en el que está colocado el nodo.

RestInterface El parámetro RestInterface especifica el nombre de la interfaz en el nodo

donde finaliza la comunicación de transferencia de estado representacional
(REST). Esta interfaz de Controladora de red recibe solicitudes de Northbound
API desde el nivel de administración de la red.

NodeCertificate El parámetro NodeCertificate especifica el certificado que usa Controladora de

red para la autenticación del equipo. El certificado es necesario si usa la
autenticación basada en certificados para la comunicación dentro del clúster. El
certificado también se utiliza para el cifrado del tráfico entre los servicios de
Controladora de red. El nombre del firmante del certificado debe ser el mismo
que el nombre DNS del nodo.

Configuración del clúster

Para configurar el clúster, escriba el siguiente comando en el símbolo del sistema
Windows PowerShell y presione ENTRAR. Asegúrese de agregar valores para cada
parámetro adecuado para la implementación.

Install-NetworkControllerCluster -Node <NetworkControllerNode[]> -

ClusterAuthentication <ClusterAuthentication> [-ManagementSecurityGroup
<string>][-DiagnosticLogLocation <string>][-LogLocationCredential
<PSCredential>] [-CredentialEncryptionCertificate <X509Certificate2>][-
Credential <PSCredential>][-CertificateThumbprint <String>] [-UseSSL][-
ComputerName <string>][-LogSizeLimitInMBs<UInt32>] [-
LogTimeLimitInDays<UInt32>]
En la tabla siguiente se proporcionan descripciones para cada parámetro del comando
Install-NetworkControllerCluster .

Parámetro Descripción

ClusterAuthentication El parámetro ClusterAuthentication especifica el tipo de

autenticación que se usa para proteger la comunicación entre
los nodos y también se usa para el cifrado del tráfico entre los
servicios de Controladora de red. Los valores admitidos son
Kerberos, X509 y Ninguno. La autenticación Kerberos usa
cuentas de dominio y solo se puede usar si los nodos de
Controladora de red están unidos a un dominio. Si especifica la
autenticación basada en X509, debe proporcionar un certificado
en el objeto NetworkControllerNode. Además, debe
aprovisionar el certificado manualmente antes de ejecutar este
comando.

ManagementSecurityGroup El parámetro ManagementSecurityGroup especifica el nombre

del grupo de seguridad que contiene los usuarios que pueden
ejecutar los cmdlets de administración desde un equipo remoto.
Esto solo es aplicable si ClusterAuthentication es Kerberos. Debe
especificar un grupo de seguridad de un dominio y no un grupo
de seguridad en el equipo local.

Nodo El parámetro Node especifica la lista de nodos de controladora

de red que creó mediante el comando New-
NetworkControllerNodeObject .

DiagnosticLogLocation El parámetro DiagnosticLogLocation especifica la ubicación del

recurso compartido donde se cargan periódicamente los
registros de diagnóstico. Si no especifica un valor para este
parámetro, los registros se almacenan localmente en cada nodo.
Los registros se almacenan localmente en la carpeta
%systemdrive%\Windows\tracing\SDNDiagnostics. Los registros
del clúster se almacenan localmente en la carpeta
%systemdrive%\ProgramData\Microsoft\Service
Fabric\log\Traces.

LogLocationCredential El parámetro LogLocationCredential especifica las credenciales

necesarias para acceder a la ubicación del recurso compartido
donde se almacenan los registros.
Parámetro Descripción

CredentialEncryptionCertificate El parámetro CredentialEncryptionCertificate especifica el

certificado que usa Controladora de red para cifrar las
credenciales que se emplean para acceder a los archivos
binarios de Controladora de red y al valor de
LogLocationCredential, si se especifica. El certificado debe
aprovisionarse en todos los nodos de Controladora de red antes
de ejecutar este comando y el mismo certificado debe
inscribirse en todos los nodos del clúster. Se recomienda usar
este parámetro para proteger los registros y los archivos
binarios de Controladora de red en entornos de producción. Sin
este parámetro, las credenciales se almacenan en texto no
cifrado y cualquier usuario no autorizado podría hacer un uso
inadecuado de ellas.

Credential: Este parámetro solo es necesario si ejecuta este comando desde

un equipo remoto. El parámetro Credential especifica una
cuenta de usuario que tiene permiso para ejecutar este
comando en el equipo de destino.

CertificateThumbprint Este parámetro solo es necesario si ejecuta este comando desde

un equipo remoto. El parámetro CertificateThumbprint
especifica el certificado de clave pública digital (X509) de una
cuenta de usuario que tiene permiso para ejecutar este
comando en el equipo de destino.

UseSSL Este parámetro solo es necesario si ejecuta este comando desde

un equipo remoto. El parámetro UseSSL especifica el protocolo
de capa de sockets seguros (SSL) que se emplea para establecer
una conexión con el equipo remoto. De forma predeterminada,
no se usa SSL.

ComputerName El parámetro ComputerName especifica el nodo de

Controladora de red en el que se ejecuta este comando. Si no
especifica un valor para este parámetro, se utiliza el equipo local
de manera predeterminada.

LogSizeLimitInMBs Este parámetro especifica el tamaño máximo del registro, en

MB, que puede almacenar Controladora de red. Los registros se
almacenan de manera circular. Si se proporciona
DiagnosticLogLocation, el valor predeterminado de este
parámetro es 40 GB. Si no se proporciona
DiagnosticLogLocation, los registros se almacenan en los nodos
de Controladora de red y el valor predeterminado de este
parámetro es 15 GB.
 Parámetro Descripción

LogTimeLimitInDays Este parámetro especifica el límite de duración, en días, durante

el que se almacenan los registros. Los registros se almacenan de
manera circular. El valor predeterminado para este parámetro es
3 días.

Configuración de la aplicación de Controladora

de red
Para configurar la aplicación Controladora de red, escriba el siguiente comando en el
símbolo del sistema Windows PowerShell y presione ENTRAR. Asegúrese de agregar
valores para cada parámetro que sea adecuado para la implementación.

Install-NetworkController -Node <NetworkControllerNode[]> -

ClientAuthentication <ClientAuthentication> [-ClientCertificateThumbprint
<string[]>] [-ClientSecurityGroup <string>] -ServerCertificate
<X509Certificate2> [-RESTIPAddress <String>] [-RESTName <String>] [-
Credential <PSCredential>][-CertificateThumbprint <String> ] [-UseSSL]

En la tabla siguiente se proporcionan descripciones para cada parámetro del comando

Install-NetworkController .

Parámetro Descripción

ClientAuthentication El parámetro ClientAuthentication especifica el tipo de

autenticación que se usa para proteger la comunicación entre REST
y Controladora de red. Los valores admitidos son Kerberos, X509 y
Ninguno. La autenticación Kerberos usa cuentas de dominio y solo
se puede usar si los nodos de Controladora de red están unidos a
un dominio. Si especifica la autenticación basada en X509, debe
proporcionar un certificado en el objeto NetworkControllerNode.
Además, debe aprovisionar el certificado manualmente antes de
ejecutar este comando.

Nodo El parámetro Node especifica la lista de nodos de controlador de

red que creó mediante el comando New-
NetworkControllerNodeObject .

ClientCertificateThumbprint Este parámetro solo es necesario cuando se usa la autenticación

basada en certificados para los clientes de Controladora de red. El
parámetro ClientCertificateThumbprint especifica la huella digital
del certificado que está inscrito en los clientes en el nivel de
Northbound.
Parámetro Descripción

ServerCertificate El parámetro ServerCertificate especifica el certificado que usa

Controladora de red para demostrar su identidad a los clientes. El
certificado de servidor debe incluir el propósito de autenticación
del servidor en las extensiones de uso mejorado de clave y debe
emitirse para Controladora de red mediante una entidad de
certificación de confianza para los clientes.

RESTIPAddress No es necesario especificar un valor para RESTIPAddress con una

implementación de un solo nodo de Controladora de red. En el
caso de implementaciones de varios nodos, el parámetro
RESTIPAddress especifica la dirección IP del punto de conexión de
REST en la notación CIDR. Por ejemplo: [Link]/24. El valor
Nombre de sujeto de ServerCertificate debe resolverse en el valor
del parámetro RESTIPAddress. Este parámetro debe especificarse
para todas las implementaciones de Controladora de red de varios
nodos cuando todos los nodos están en la misma subred. Si los
nodos están en subredes diferentes, debe usar el parámetro
RestName en lugar de usar RESTIPAddress.

RestName No es necesario especificar un valor para RestName con una

implementación de un solo nodo de Controladora de red. La única
vez que debe especificar un valor para RestName es cuando las
implementaciones de varios nodos tienen nodos que están en
subredes diferentes. En el caso de implementaciones de varios
nodos, el parámetro RestName especifica el nombre de dominio
completo del clúster de Controladora de red.

ClientSecurityGroup El parámetro ClientSecurityGroup especifica el nombre del grupo

de seguridad de Active Directory cuyos miembros son clientes de
Controladora de red. Este parámetro solo es necesario si se usa la
autenticación Kerberos para ClientAuthentication. El grupo de
seguridad debe contener las cuentas desde las que se accede a las
API REST y debe crear el grupo de seguridad y agregar miembros
antes de ejecutar este comando.

Credential: Este parámetro solo es necesario si ejecuta este comando desde un

equipo remoto. El parámetro Credential especifica una cuenta de
usuario que tiene permiso para ejecutar este comando en el equipo
de destino.

CertificateThumbprint Este parámetro solo es necesario si ejecuta este comando desde un

equipo remoto. El parámetro CertificateThumbprint especifica el
certificado de clave pública digital (X509) de una cuenta de usuario
que tiene permiso para ejecutar este comando en el equipo de
destino.
 Parámetro Descripción

UseSSL Este parámetro solo es necesario si ejecuta este comando desde un

equipo remoto. El parámetro UseSSL especifica el protocolo de
capa de sockets seguros (SSL) que se emplea para establecer una
conexión con el equipo remoto. De forma predeterminada, no se
usa SSL.

Después de completar la configuración de la aplicación de Controladora de red, la

implementación de esta ha finalizado.

Validación de la implementación de
Controladora de red
Para validar la implementación de Controladora de red, puede agregar una credencial a
Controladora de red y, a continuación, recuperarla.

Si usa Kerberos como mecanismo clientAuthentication, la pertenencia a

ClientSecurityGroup que creó es el mínimo necesario para realizar este procedimiento.

Procedimiento:

1. En un equipo cliente, si usa Kerberos como mecanismo clientAuthentication, inicie

sesión con una cuenta de usuario que sea miembro de clientSecurityGroup.

2. Abra Windows PowerShell, escriba los siguientes comandos para agregar una
credencial a Controladora de red y presione ENTRAR. Asegúrese de agregar
valores para cada parámetro que sea adecuado para la implementación.

$cred=New-Object
[Link]
$[Link]="usernamepassword"
$[Link]="admin"
$[Link]="abcd"

New-NetworkControllerCredential -ConnectionUri
[Link] -Properties $cred -ResourceId cred1

3. Para recuperar la credencial que agregó a controladora de red, escriba el siguiente

comando y presione ENTRAR. Asegúrese de agregar valores para cada parámetro
que sea adecuado para la implementación.
 Get-NetworkControllerCredential -ConnectionUri
[Link] -ResourceId cred1

4. Revise la salida de este comando, la cual debería ser similar a la del ejemplo
siguiente.

Tags :
ResourceRef : /credentials/cred1
CreatedTime : 1/1/0001 12:00:00 AM
InstanceId : e16ffe62-a701-4d31-915e-7234d4bc5a18
Etag : W/"1ec59631-607f-4d3e-ac78-94b0822f3a9d"
ResourceMetadata :
ResourceId : cred1
Properties :
[Link]

７ Nota

Al ejecutar el comando Get-NetworkControllerCredential , puede asignar la

salida del comando a una variable mediante el operador dot para enumerar
las propiedades de las credenciales. Por ejemplo, $cred. Propiedades.

Comandos de Windows PowerShell adicionales

para controladora de red
Después de implementar la controladora de red, puede usar Windows PowerShell
comandos para administrar y modificar la implementación. A continuación se muestran
algunos de los cambios que puede realizar en su implementación.

Modificar la configuración del nodo, el clúster y la aplicación de Controladora de

red

Eliminar el clúster y la aplicación de Controladora de red

Administrar nodos de clúster de Controladora de red, incluida la adición,

eliminación, habilitación y deshabilitación de nodos.

En la tabla siguiente se proporciona la sintaxis de Windows PowerShell comandos que

puede usar para realizar estas tareas.
Tarea Get-Help Sintaxis

Modificar la Set- Set-NetworkControllerCluster [-

configuración NetworkControllerCluster ManagementSecurityGroup <string>][-Credential
del clúster de <PSCredential>] [-computerName <string>][-
Controladora CertificateThumbprint <String> ] [-UseSSL]
de red

Modificar la Set-NetworkController Set-NetworkController [-ClientAuthentication

configuración <ClientAuthentication>] [-Credential
de la <PSCredential>] [-ClientCertificateThumbprint
aplicación de <string[]>] [-ClientSecurityGroup <string>] [-
Controladora ServerCertificate <X509Certificate2>] [-
de red RestIPAddress <String>] [-ComputerName
<String>][-CertificateThumbprint <String> ] [-
UseSSL]

Modificar la Set-NetworkControllerNode Set-NetworkControllerNode -Name <string> > [-

configuración RestInterface <string>] [-NodeCertificate
del nodo de <X509Certificate2>] [-Credential
Controladora <PSCredential>] [-ComputerName <string>][-
de red CertificateThumbprint <String> ] [-UseSSL]

Modificar la Set- Set-NetworkControllerDiagnostic [-LogScope

configuración NetworkControllerDiagnostic <string>] [-DiagnosticLogLocation <string>] [-
de LogLocationCredential <PSCredential>] [-
diagnóstico UseLocalLogLocation] >] [-LogLevel <loglevel>]
de [-LogSizeLimitInMBs <uint32>] [-
Controladora LogTimeLimitInDays <uint32>] [-Credential
de red <PSCredential>] [-ComputerName <string>][-
CertificateThumbprint <String> ] [-UseSSL]

Quitar la Uninstall-NetworkController Uninstall-NetworkController [-Credential

aplicación de <PSCredential>][-ComputerName <string>] [-
Controladora CertificateThumbprint <String> ] [-UseSSL]
de red

Quitar el Uninstall- Uninstall-NetworkControllerCluster [-

clúster de NetworkControllerCluster Credential <PSCredential>][-ComputerName
Controladora <string>][-CertificateThumbprint <String> ] [-
de red UseSSL]

Agregar un Add-NetworkControllerNode Add-NetworkControllerNode -FaultDomain

nodo al <String> -Name <String> -RestInterface <String>
clúster de -Server <String> [-CertificateThumbprint
Controladora <String> ] [-ComputerName <String> ] [-
de red Credential <PSCredential> ] [-Force] [-
NodeCertificate <X509Certificate2> ] [-
PassThru] [-UseSsl]
 Tarea Get-Help Sintaxis

Deshabilitar Disable- Disable-NetworkControllerNode -Name <String>

un nodo de NetworkControllerNode [-CertificateThumbprint <String> ] [-
clúster de ComputerName <String> ] [-Credential
Controladora <PSCredential> ] [-PassThru] [-UseSsl]
de red

Habilitar un Enable- Enable-NetworkControllerNode -Name <String> [-

nodo de NetworkControllerNode CertificateThumbprint <String> ] [-ComputerName
clúster de <String> ] [-Credential <PSCredential> ] [-
Controladora PassThru] [-UseSsl]
de red

Quitar un Remove- Remove-NetworkControllerNode [-

nodo de NetworkControllerNode CertificateThumbprint <String> ] [-ComputerName
controladora <String> ] [-Credential <PSCredential> ] [-
de red de un Force] [-Name <String> ] [-PassThru] [-UseSsl]
clúster

７ Nota

Windows PowerShell comandos de controladora de red se encuentran en la

biblioteca de TechNet en cmdlets de controladora de red.

Script de configuración de Controladora de red

de ejemplo
En el siguiente script de configuración de ejemplo se muestra cómo crear un clúster de
Controladora de red de varios nodos e instalar la aplicación de Controladora de red.
Además, la variable $cert selecciona un certificado del almacén de certificados del
equipo local que coincide con la cadena de nombre del firmante
"[Link]".

$a = New-NetworkControllerNodeObject -Name Node1 -Server [Link]

-FaultDomain fd:/rack1/host1 -RestInterface Internal
$b = New-NetworkControllerNodeObject -Name Node2 -Server [Link]
-FaultDomain fd:/rack1/host2 -RestInterface Internal
$c = New-NetworkControllerNodeObject -Name Node3 -Server [Link]
-FaultDomain fd:/rack1/host3 -RestInterface Internal

$cert= get-item Cert:\LocalMachine\My | get-ChildItem | where {$_.Subject -

imatch "[Link]" }
 Install-NetworkControllerCluster -Node @($a,$b,$c) -ClusterAuthentication
Kerberos -DiagnosticLogLocation \\share\Diagnostics -
ManagementSecurityGroup Contoso\NCManagementAdmins -
CredentialEncryptionCertificate $cert
Install-NetworkController -Node @($a,$b,$c) -ClientAuthentication Kerberos -
ClientSecurityGroup Contoso\NCRESTClients -ServerCertificate $cert -
RestIpAddress [Link]/24

Pasos posteriores a la implementación para

implementaciones que no son kerberos
Si no usa Kerberos con la implementación de Controladora de red, debe implementar
certificados.

Para más información, consulte los pasos posteriores a la implementación de

Controladora de red.
Administrar SDN
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Puede usar los temas de esta sección para administrar redes definidas por software,
incluidas las cargas de trabajo de inquilino y las redes virtuales.

７ Nota

Para obtener documentación adicional sobre redes definidas por software, puede
usar las secciones de biblioteca siguientes.

Tecnologías sdn
Planear SDN
Implementar SDN
Seguridad para SDN
Solucionar problemas de SDN

Esta sección contiene los temas siguientes.

Administración de redes virtuales de inquilino

Administración de cargas de trabajo de inquilino
Actualizar, realizar copias de seguridad y restaurar la infraestructura de red
definida por software
Administración de redes virtuales de
inquilinos
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar los temas de esta sección para administrar redes virtuales de virtualización
de red de Hyper-V de inquilino después de haber implementado redes definidas por
software mediante el tema Implementación de una infraestructura de red definida por
software mediante scripts.

Esta sección contiene los temas siguientes.

Descripción del uso de redes virtuales y VLAN

Use Access Control listas de control de acceso (ACL) para administrar el tráfico de
red del centro de datos Flow
Creación, eliminación o actualización de redes virtuales de inquilino
Agregar una puerta de enlace virtual a un inquilino Virtual Network
Conexión de puntos de conexión de contenedor a una red virtual de inquilino
Comprender el uso de redes virtuales y
VLAN
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En este tema, aprenderá sobre las redes virtuales de virtualización de red de Hyper-V y
cómo difieren de las redes de área local virtual (VLAN). Con la virtualización de red de
Hyper-V, se crean redes virtuales superpuestas, también denominadas redes virtuales.

Las redes definidas por software (SDN) en Windows Server 2016 se basan en la directiva
de programación para superponer redes virtuales dentro de un conmutador virtual de
Hyper-V. Puede crear redes virtuales superpuestas, también denominadas redes
virtuales, con Virtualización de red de Hyper-V.

Al implementar virtualización de red de Hyper-V, las redes superpuestas se crean

encapsulando el marco Ethernet de capa 2 de la máquina virtual del inquilino original
con un encabezado de superposición (o túnel) (por ejemplo, VXLAN o NVGRE) y
encabezados Ip de capa 3 y Ethernet de capa 2 desde la red subyacente (o física). Las
redes virtuales superpuestas se identifican mediante un identificador de Virtual Network
(VNI) de 24 bits para mantener el aislamiento del tráfico de inquilino y permitir
direcciones IP superpuestas. La VNI se compone de un identificador de subred virtual
(VSID), un identificador de conmutador lógico y un identificador de túnel.

Además, a cada inquilino se le asigna un dominio de enrutamiento (similar al

enrutamiento y reenvío virtual - VRF) para que varios prefijos de subred virtual (cada
uno representado por una VNI) se puedan enrutar directamente entre sí. No se admite
el enrutamiento entre inquilinos (o dominio de enrutamiento cruzado) sin pasar por una
puerta de enlace.

La red física en la que se tunela el tráfico encapsulado de cada inquilino se representa

mediante una red lógica denominada red lógica del proveedor. Esta red lógica del
proveedor consta de una o varias subredes, cada una representada por un prefijo IP y,
opcionalmente, una etiqueta VLAN 802.1q.

Puede crear redes lógicas y subredes adicionales con fines de infraestructura para llevar
tráfico de administración, tráfico de almacenamiento, tráfico de migración en vivo, etc.

Microsoft SDN no admite el aislamiento de redes de inquilinos mediante VLAN. El

aislamiento de inquilinos se logra únicamente mediante la superposición de redes
virtuales y encapsulación de virtualización de red de Hyper-V.
Configuración de grupos de seguridad
de red con PowerShell
Artículo • 23/01/2023 • Tiempo de lectura: 9 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2; Windows Server 2022,
Windows Server 2019, Windows Server 2016

En este tema se proporcionan instrucciones para configurar grupos de seguridad de red

(NSG) para administrar el flujo de tráfico de datos mediante Datacenter Firewall para
redes definidas por software (SDN) en Azure Stack HCI mediante Windows PowerShell.
Para habilitar y configurar El firewall del centro de datos, cree grupos de seguridad de
red que se apliquen a una subred o a una interfaz de red. En los scripts de ejemplo de
este tema se usan los comandos de Windows PowerShell exportados del módulo
NetworkController. También puede usar Windows Admin Center para configurar y
administrar grupos de seguridad de red.

Configuración del firewall del centro de datos

para permitir todo el tráfico
Una vez que implemente SDN, debe probar la conectividad de red básica en el nuevo
entorno. Para ello, cree una regla para el firewall del centro de datos que permita todo
el tráfico de red, sin restricciones.

Use las entradas de la tabla siguiente para crear un conjunto de reglas que permitan
todo el tráfico de red entrante y saliente.

IP de IP de Protocolo Puerto de Puerto de Dirección Acción Priority

origen destino origen destino

* * All * * Entrada Allow 100

* * All * * Salida Allow 110

En este ejemplo, creará un grupo de seguridad de red con dos reglas:

1. AllowAll_Inbound : permite que todo el tráfico de red pase a la interfaz de red

donde está configurado este grupo de seguridad de red.
2. AllowAllOutbound: permite que todo el tráfico pase fuera de la interfaz de red.
Este grupo de seguridad de red, identificado por el identificador de recurso
"AllowAll-1" ya está listo para usarse en subredes virtuales e interfaces de red.
En primer lugar, conéctese a uno de los nodos del clúster. Para ello, abra una sesión de
PowerShell:

PowerShell

Enter-PSSession <server-name>

A continuación, ejecute el siguiente script para crear el grupo de seguridad de red:

PowerShell

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "*"
$[Link] = "100"
$[Link] = "Inbound"
$[Link] = "Enabled"
$aclrule1 = new-object [Link]
$[Link] = $ruleproperties
$[Link] = "AllowAll_Inbound"
$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "*"
$[Link] = "110"
$[Link] = "Outbound"
$[Link] = "Enabled"
$aclrule2 = new-object [Link]
$[Link] = $ruleproperties
$[Link] = "AllowAll_Outbound"
$acllistproperties = new-object
[Link]
$[Link] = @($aclrule1, $aclrule2)
New-NetworkControllerAccessControlList -ResourceId "AllowAll" -Properties
$acllistproperties -ConnectionUri <NC REST FQDN>

７ Nota

La referencia de comandos de Windows PowerShell para la Controladora de red se

encuentra en el tema Cmdlets de la Controladora de red.
Uso de grupos de seguridad de red para limitar
el tráfico en una subred
En este ejemplo, creará un grupo de seguridad de red que impide que las máquinas
virtuales (VM) dentro de la subred [Link]/24 se comuniquen entre sí. Este tipo de
grupo de seguridad de red es útil para limitar la capacidad de un atacante de distribuir
lateralmente dentro de la subred, a la vez que permite que las máquinas virtuales
reciban solicitudes desde fuera de la subred, así como para comunicarse con otros
servicios en otras subredes.

IP de origen IP de destino Protocolo Puerto Puerto Dirección Acción Priority

de de
origen destino

[Link] * All * * Entrada Allow 100

* [Link] All * * Salida Allow 101

[Link]/24 * All * * Entrada Block 102

* [Link]/24 All * * Salida Block 103

* * All * * Entrada Allow 104

* * All * * Salida Allow 105

El grupo de seguridad de red creado por el script de ejemplo siguiente, identificado por
la subred de identificador de recurso Subnet-192-168-0-0, ahora se puede aplicar a una
subred de red virtual que use la dirección de subred "[Link]/24". Cualquier interfaz
de red conectada a esa subred de red virtual obtiene automáticamente las reglas de
grupo de seguridad de red anteriores aplicadas.

A continuación se muestra un script de ejemplo para crear este grupo de seguridad de

red mediante la API REST de controladora de red:

PowerShell

import-module networkcontroller
$ncURI = "[Link]
$aclrules = @()

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "[Link]"
$[Link] = "*"
$[Link] = "100"
$[Link] = "Inbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "AllowRouter_Inbound"
$aclrules += $aclrule

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "[Link]"
$[Link] = "101"
$[Link] = "Outbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "AllowRouter_Outbound"
$aclrules += $aclrule

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Deny"
$[Link] = "[Link]/24"
$[Link] = "*"
$[Link] = "102"
$[Link] = "Inbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "DenySubnet_Inbound"
$aclrules += $aclrule

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Deny"
$[Link] = "*"
$[Link] = "[Link]/24"
$[Link] = "103"
$[Link] = "Outbound"
 $[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "DenySubnet_Outbound"

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "*"
$[Link] = "104"
$[Link] = "Inbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "AllowAll_Inbound"
$aclrules += $aclrule

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "*"
$[Link] = "105"
$[Link] = "Outbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "AllowAll_Outbound"
$aclrules += $aclrule

$acllistproperties = new-object
[Link]
$[Link] = $aclrules

New-NetworkControllerAccessControlList -ResourceId "Subnet-192-168-0-0" -

Properties $acllistproperties -ConnectionUri $ncURI

Adición de un grupo de seguridad de red a una

interfaz de red
Una vez que haya creado un grupo de seguridad de red y lo haya asignado a una
subred virtual, es posible que desee invalidar ese grupo de seguridad de red
predeterminado en la subred virtual con un grupo de seguridad de red específico para
una interfaz de red individual. A partir de Windows Server 2019 Datacenter, puede
aplicar grupos de seguridad de red específicos directamente a interfaces de red
conectadas a redes lógicas SDN, además de redes virtuales sdN. Si tiene grupos de
seguridad de red establecidos en la subred virtual conectada a la interfaz de red, se
aplican ambos grupos de seguridad de red y se priorizan los grupos de seguridad de
red de la interfaz de red por encima de los grupos de seguridad de red de subred
virtual.

En este ejemplo, se muestra cómo agregar un grupo de seguridad de red a una red
virtual.

 Sugerencia

También es posible agregar un grupo de seguridad de red al mismo tiempo que se

crea la interfaz de red.

1. Obtenga o cree la interfaz de red a la que agregará el grupo de seguridad de red.

PowerShell

$nic = get-networkcontrollernetworkinterface -ConnectionUri $uri -

ResourceId "MyVM_Ethernet1"

2. Obtenga o cree el grupo de seguridad de red que agregará a la interfaz de red.

PowerShell

$acl = get-networkcontrolleraccesscontrollist -ConnectionUri $uri -

ResourceId "AllowAllACL"

3. Asigne el grupo de seguridad de red a la propiedad AccessControlList de la

interfaz de red.

PowerShell

$[Link][0].[Link] =
$acl

4. Agregue la interfaz de red en la Controladora de red.

 PowerShell

new-networkcontrollernetworkinterface -ConnectionUri $uri -Properties

$[Link] -ResourceId $[Link]

Eliminación de un grupo de seguridad de red

de una interfaz de red
En este ejemplo, se muestra cómo quitar un grupo de seguridad de red de una interfaz
de red. Al quitar un grupo de seguridad de red, se aplica el conjunto predeterminado de
reglas a la interfaz de red. El conjunto predeterminado de reglas permite todo el tráfico
saliente, pero bloquea el entrante. Si desea permitir todo el tráfico entrante, debe seguir
el ejemplo anterior para agregar un grupo de seguridad de red que permita todo el
tráfico entrante y saliente.

1. Obtenga la interfaz de red de la que quitará el grupo de seguridad de red.

PowerShell

$nic = get-networkcontrollernetworkinterface -ConnectionUri $uri -

ResourceId "MyVM_Ethernet1"

2. Asigne $null a la propiedad AccessControlList de ipConfiguration.

PowerShell

$[Link][0].[Link] =
$null

3. Agregue el objeto de la interfaz de red en la Controladora de red.

PowerShell

new-networkcontrollernetworkinterface -ConnectionUri $uri -Properties

$[Link] -ResourceId $[Link]

Auditoría de firewall
A partir de Windows Server 2019, la auditoría de firewall es una nueva funcionalidad del
firewall del centro de datos que registra cualquier flujo que procesan las reglas de
firewall de SDN. Se registran todos los grupos de seguridad de red que tienen
habilitado el registro. Los archivos de registro deben estar en una sintaxis coherente con
los registros de flujo de Azure Network Watcher. Estos registros se pueden usar para
realizar diagnósticos o archivar para su posterior análisis.

A continuación se incluye un script de ejemplo para habilitar la auditoría de firewall en

los servidores host. Actualice las variables del principio y ejecútelo en un clúster de
Azure Stack HCI con la Controladora de red implementada:

PowerShell

$logpath = "C:\test\log1"
$servers = @("sa18n22-2", "sa18n22-3", "sa18n22-4")
$uri = "[Link]

# Create log directories on the hosts

invoke-command -Computername $servers {
param(
$Path
)
mkdir $path -force
} -argumentlist $LogPath

# Set firewall auditing settings on Network Controller

$AuditProperties = new-object
[Link]
$[Link] = $logpath
set-networkcontrollerauditingsettingsconfiguration -connectionuri $uri -
properties $AuditProperties -force | out-null

# Enable logging on each server

$servers = get-networkcontrollerserver -connectionuri $uri
foreach ($s in $servers) {
$[Link] = @("Firewall")
new-networkcontrollerserver -connectionuri $uri -resourceid
$[Link] -properties $[Link] -force | out-null
}

Una vez habilitado, aparece un nuevo archivo en el directorio especificado de cada host
aproximadamente una vez por hora. Debe procesar periódicamente estos archivos y
quitarlos de los hosts. El archivo actual tiene una longitud igual a cero y se bloquea
hasta que se vacía en la marca de hora siguiente:

syntax

PS C:\test\log1> dir

Directory: C:\test\log1

Mode LastWriteTime Length Name

---- ------------- ------ ----
-a---- 7/19/2018 6:28 AM 17055
 SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]
-a---- 7/19/2018 7:28 AM 7880
SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]
-a---- 7/19/2018 8:28 AM 7867
SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]
-a---- 7/19/2018 9:28 AM 10949
SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]
-a---- 7/19/2018 9:28 AM 0
SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]

Estos archivos contienen una secuencia de eventos de flujo; por ejemplo:

syntax

{
"records": [
{
"properties":{
"Version":"1.0",
"flows":[
{
"flows":[
{
"flowTuples":
["1531963580,[Link],[Link],138,138,U,I,A"],
"portId":"9",
"portName":"7290436D-0422-498A-8EB8-
C6CF5115DACE"
}
],
"rule":"Allow_Inbound"
}
]
},
"operationName":"NetworkSecurityGroupFlowEvents",
"resourceId":"394f647d-2ed0-4c31-87c5-389b8c0c8132",
"time":"20180719:L012620622",
"category":"NetworkSecurityGroupFlowEvent",
"systemId":"d8b3b697-5355-40e2-84d2-1bf2f0e0dc4a"
},

Tenga en cuenta que el registro solo tiene lugar para las reglas que tienen el valor
Logging definido como Enabled; por ejemplo:

syntax
{
"Tags": null,
"ResourceRef": "/accessControlLists/AllowAll",
"InstanceId": "4a63e1a5-3264-4986-9a59-4e77a8b107fa",
"Etag": "W/\"1535a780-0fc8-4bba-a15a-093ecac9b88b\"",
"ResourceMetadata": null,
"ResourceId": "AllowAll",
"Properties": {
"ConfigurationState": null,
"ProvisioningState": "Succeeded",
"AclRules": [
{
"ResourceMetadata": null,
"ResourceRef":
"/accessControlLists/AllowAll/aclRules/AllowAll_Inbound",
"InstanceId": "ba8710a8-0f01-
422b-9038-d1f2390645d7",
"Etag": "W/\"1535a780-0fc8-
4bba-a15a-093ecac9b88b\"",
"ResourceId":
"AllowAll_Inbound",
"Properties": {
"Protocol":
"All",

"SourcePortRange": "0-65535",

"DestinationPortRange": "0-65535",
"Action":
"Allow",

"SourceAddressPrefix": "*",

"DestinationAddressPrefix": "*",
"Priority":
"101",

"Description": null,
"Type":
"Inbound",
"Logging":
"Enabled",

"ProvisioningState": "Succeeded"
}
},
{
"ResourceMetadata": null,
"ResourceRef":
"/accessControlLists/AllowAll/aclRules/AllowAll_Outbound",
"InstanceId": "068264c6-2186-
4dbc-bbe7-f504c6f47fa8",
"Etag": "W/\"1535a780-0fc8-
4bba-a15a-093ecac9b88b\"",
 "ResourceId":
"AllowAll_Outbound",
"Properties": {
"Protocol":
"All",

"SourcePortRange": "0-65535",

"DestinationPortRange": "0-65535",
"Action":
"Allow",

"SourceAddressPrefix": "*",

"DestinationAddressPrefix": "*",
"Priority":
"110",

"Description": null,
"Type":
"Outbound",
"Logging":
"Enabled",

"ProvisioningState": "Succeeded"
}
}
],
"IpConfigurations": [

],
"Subnets": [
{
"ResourceMetadata": null,
"ResourceRef":
"/virtualNetworks/10_0_1_0/subnets/Subnet1",
"InstanceId": "00000000-0000-
0000-0000-000000000000",
"Etag": null,
"ResourceId": null,
"Properties": null
}
]
}
}

Pasos siguientes
Para obtener información relacionada, consulte:

Introducción al firewall del centro de datos

Introducción a la controladora de red
SDN en Azure Stack HCI y Windows Server
Creación, eliminación o actualización de
redes virtuales de inquilinos
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En este tema, aprenderá a crear, eliminar y actualizar redes virtuales de virtualización de

red de Hyper-V después de implementar redes definidas por software (SDN).
Virtualización de red de Hyper-V ayuda a aislar las redes de inquilino para que cada red
de inquilinos sea una entidad independiente. Cada entidad no tiene ninguna posibilidad
de conexión cruzada a menos que configure cargas de trabajo de acceso público.

Cree una nueva red virtual.

La creación de una red virtual para un inquilino la coloca dentro de un dominio de
enrutamiento único en el host de Hyper-V. Debajo de cada red virtual, hay al menos una
subred virtual. Las subredes virtuales se definen mediante un prefijo IP y hacen
referencia a una ACL definida previamente.

Los pasos para crear una nueva red virtual son:

1. Identifique los prefijos de dirección IP desde los que desea crear las subredes
virtuales.
2. Identifique la red del proveedor lógico en la que se tunelizó el tráfico del inquilino.
3. Cree al menos una subred virtual para cada prefijo IP que identificó en el paso 1.
4. (Opcional) Agregue las ACL creadas anteriormente a las subredes virtuales o
agregue conectividad de puerta de enlace para los inquilinos.

En la tabla siguiente se incluyen identificadores de subred y prefijos de ejemplo para

dos inquilinos ficticios. El inquilino Fabrikam tiene dos subredes virtuales, mientras que
el inquilino de Contoso tiene tres subredes virtuales.

Nombre del inquilino Id. de subred virtual Prefijo de subred virtual

Fabrikam 5001 [Link]/24

Fabrikam 5002 [Link]/20

Contoso 6001 [Link]/24

 Nombre del inquilino Id. de subred virtual Prefijo de subred virtual

Contoso 6002 [Link]/24

Contoso 6003 [Link]/24

El siguiente script de ejemplo usa Windows PowerShell comandos exportados desde el

módulo NetworkController para crear la red virtual de Contoso y una subred:

Powershell

import-module networkcontroller
$URI = "[Link]

#Find the HNV Provider Logical Network

$logicalnetworks = Get-NetworkControllerLogicalNetwork -ConnectionUri $uri

foreach ($ln in $logicalnetworks) {
if ($[Link] -eq "True") {
$HNVProviderLogicalNetwork = $ln
}
}

#Find the Access Control List to user per virtual subnet

$acllist = Get-NetworkControllerAccessControlList -ConnectionUri $uri -

ResourceId "AllowAll"

#Create the Virtual Subnet

$vsubnet = new-object [Link]

$[Link] = "Contoso_WebTier"
$[Link] = new-object
[Link]
$[Link] = $acllist
$[Link] = "[Link]/24"

#Create the Virtual Network

$vnetproperties = new-object
[Link]
$[Link] = new-object
[Link]
$[Link] = @("[Link]/24")
$[Link] = $HNVProviderLogicalNetwork
$[Link] = @($vsubnet)
New-NetworkControllerVirtualNetwork -ResourceId "Contoso_VNet1" -
ConnectionUri $uri -Properties $vnetproperties
Modificar una instancia de Virtual Network
Puede usar Windows PowerShell para actualizar una red o subred virtual existentes.

Al ejecutar el siguiente script de ejemplo, los recursos actualizados son simplemente

PUT a Controladora de red con el mismo identificador de recurso. Si el inquilino
Contoso quiere agregar una nueva subred virtual ([Link]/24) a su red virtual, usted o
el administrador de Contoso pueden usar el siguiente script.

PowerShell

$acllist = Get-NetworkControllerAccessControlList -ConnectionUri $uri -

ResourceId "AllowAll"

$vnet = Get-NetworkControllerVirtualNetwork -ResourceId "Contoso_VNet1" -

ConnectionUri $uri

$[Link] += "[Link]/24"

$vsubnet = new-object [Link]

$[Link] = "Contoso_DBTier"
$[Link] = new-object
[Link]
$[Link] = $acllist
$[Link] = "[Link]/24"

$[Link] += $vsubnet

New-NetworkControllerVirtualNetwork -ResourceId "Contoso_VNet1" -

ConnectionUri $uri -properties $[Link]

Eliminar una red virtual

Puede usar Windows PowerShell para eliminar un Virtual Network.

En el ejemplo Windows PowerShell siguiente se elimina un inquilino Virtual Network

mediante la emisión de una eliminación HTTP al URI del identificador de recurso.

PowerShell

Remove-NetworkControllerVirtualNetwork -ResourceId "Contoso_Vnet1" -

ConnectionUri $uri
Adición de una puerta de enlace virtual
a una red virtual de inquilino
Artículo • 21/12/2022 • Tiempo de lectura: 10 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Aprenda a usar Windows PowerShell cmdlets y scripts para proporcionar conectividad

de sitio a sitio para las redes virtuales del inquilino. En este tema, agregará puertas de
enlace virtuales de inquilino a instancias de puerta de enlace RAS que son miembros de
grupos de puertas de enlace mediante controladora de red. La puerta de enlace ras
admite hasta cien inquilinos, en función del ancho de banda usado por cada inquilino.
La controladora de red determina automáticamente la mejor puerta de enlace ras que
se usará al implementar una nueva puerta de enlace virtual para los inquilinos.

Cada puerta de enlace virtual corresponde a un inquilino determinado y consta de una o

varias conexiones de red (túneles VPN de sitio a sitio) y, opcionalmente, conexiones del
Protocolo de puerta de enlace de borde (BGP). Al proporcionar conectividad de sitio a
sitio, los clientes pueden conectar su red virtual de inquilino a una red externa, como
una red empresarial de inquilinos, una red de proveedor de servicios o Internet.

Al implementar una puerta de enlace virtual de inquilino, tiene las siguientes

opciones de configuración:

Opciones de conexión de red Opciones de configuración de BGP

Red privada virtual virtual (VPN) de IPSec Configuración del enrutador BGP
de sitio a sitio Configuración del mismo nivel de BGP
Encapsulación de enrutamiento genérico Configuración de directivas de
(GRE) enrutamiento de BGP
Reenvío de capa 3

En el Windows PowerShell scripts y comandos de ejemplo de este tema se muestra

cómo implementar una puerta de enlace virtual de inquilino en una puerta de enlace ras
con cada una de estas opciones.

） Importante

Antes de ejecutar cualquiera de los comandos y scripts de ejemplo Windows

PowerShell proporcionados, debe cambiar todos los valores de variable para que
los valores sean adecuados para la implementación.

1. Compruebe que el objeto del grupo de puertas de enlace existe en la controladora

de red.

PowerShell

$uri = "[Link]

# Retrieve the Gateway Pool configuration

$gwPool = Get-NetworkControllerGatewayPool -ConnectionUri $uri

# Display in JSON format

$gwPool | ConvertTo-Json -Depth 2

2. Compruebe que la subred usada para enrutar paquetes fuera de la red virtual del
inquilino existe en controladora de red. También se recupera la subred virtual que
se usa para el enrutamiento entre la puerta de enlace de inquilino y la red virtual.

PowerShell

$uri = "[Link]

# Retrieve the Tenant Virtual Network configuration

$Vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -
ResourceId "Contoso_Vnet1"

# Display in JSON format

$Vnet | ConvertTo-Json -Depth 4

# Retrieve the Tenant Virtual Subnet configuration

$RoutingSubnet = Get-NetworkControllerVirtualSubnet -ConnectionUri $uri
-ResourceId "Contoso_WebTier" -VirtualNetworkID $[Link]

# Display in JSON format

$RoutingSubnet | ConvertTo-Json -Depth 4

3. Cree un nuevo objeto para la puerta de enlace virtual del inquilino y, a

continuación, actualice la referencia del grupo de puertas de enlace. También se
especifica la subred virtual que se usa para el enrutamiento entre la puerta de
enlace y la red virtual. Después de especificar la subred virtual, actualice el resto de
las propiedades del objeto de puerta de enlace virtual y agregue la nueva puerta
de enlace virtual para el inquilino.

PowerShell
 # Create a new object for Tenant Virtual Gateway
$VirtualGWProperties = New-Object
[Link]

# Update Gateway Pool reference

$[Link] = @()
$[Link] += $gwPool

# Specify the Virtual Subnet that is to be used for routing between the
gateway and Virtual Network
$[Link] = @()
$[Link] += $RoutingSubnet

# Update the rest of the Virtual Gateway object properties

$[Link] = "Dynamic"
$[Link] = @()
$[Link] = @()

# Add the new Virtual Gateway for tenant

$virtualGW = New-NetworkControllerVirtualGateway -ConnectionUri $uri -
ResourceId "Contoso_VirtualGW" -Properties $VirtualGWProperties -Force

4. Cree una conexión VPN de sitio a sitio con reenvío de IPsec, GRE o nivel 3 (L3).

 Sugerencia

Opcionalmente, puede combinar todos los pasos anteriores y configurar una

puerta de enlace virtual de inquilino con las tres opciones de conexión. Para
más información, consulte Configuración de una puerta de enlace con los
tres tipos de conexión (IPsec, GRE, L3) y BGP.

Conexión de red de sitio a sitio de VPN de IPsec

PowerShell

# Create a new object for Tenant Network Connection

$nwConnectionProperties = New-Object
[Link]

# Update the common object properties

$[Link] = "IPSec"
$[Link] = 10000
$[Link] = 10000

# Update specific properties depending on the Connection Type

$[Link] = New-Object
[Link]
$[Link] = "PSK"
$[Link] = "P@ssw0rd"
 $[Link] = New-Object
[Link]
$[Link]
ecy = "PFS2048"
$[Link]
sformationConstant = "SHA256128"
$[Link]
onConstant = "DES3"
$[Link]
= 1233
$[Link]
nds = 500
$[Link]
s = 2000

$[Link] = New-Object
[Link]
$[Link]
= "Group2"
$[Link]
= "SHA256"
$[Link]
= "AES256"
$[Link] =
1234
$[Link]
= 2000

# L3 specific configuration (leave blank for IPSec)

$[Link] = @()
$[Link] = @()

# Update the IPv4 Routes that are reachable over the site-to-site VPN
Tunnel
$[Link] = @()
$ipv4Route = New-Object [Link]
$[Link] = "[Link]/32"
$[Link] = 10
$[Link] += $ipv4Route

# Tunnel Destination (Remote Endpoint) Address

$[Link] = "[Link]"

# Add the new Network Connection for the tenant

New-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri
$uri -VirtualGatewayId $[Link] -ResourceId
"Contoso_IPSecGW" -Properties $nwConnectionProperties -Force

Conexión de red de sitio a sitio de VPN de GRE

PowerShell
 # Create a new object for the Tenant Network Connection
$nwConnectionProperties = New-Object
[Link]

# Update the common object properties

$[Link] = "GRE"
$[Link] = 10000
$[Link] = 10000

# Update specific properties depending on the Connection Type

$[Link] = New-Object
[Link]
$[Link] = 1234

# Update the IPv4 Routes that are reachable over the site-to-site VPN
Tunnel
$[Link] = @()
$ipv4Route = New-Object [Link]
$[Link] = "[Link]/32"
$[Link] = 10
$[Link] += $ipv4Route

# Tunnel Destination (Remote Endpoint) Address

$[Link] = "[Link]"

# L3 specific configuration (leave blank for GRE)

$nwConnectionProperties.L3Configuration = New-Object
[Link].L3Configuration
$[Link] = @()
$[Link] = @()

# Add the new Network Connection for the tenant

New-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri
$uri -VirtualGatewayId $[Link] -ResourceId
"Contoso_GreGW" -Properties $nwConnectionProperties -Force

Conexión de red de reenvío L3

Para que una conexión de red de reenvío L3 funcione correctamente, debe

configurar una red lógica correspondiente.

a. Configure una red lógica para la conexión de red de reenvío L3.

PowerShell

# Create a new object for the Logical Network to be used for L3

Forwarding
$lnProperties = New-Object
[Link]

$[Link] = $false
 $[Link] = @()

# Create a new object for the Logical Subnet to be used for L3

Forwarding and update properties
$logicalsubnet = New-Object
[Link]
$[Link] = "Contoso_L3_Subnet"
$[Link] = New-Object
[Link]
$[Link] = 1001
$[Link] = "[Link]/25"
$[Link] = "[Link]"

$[Link] += $logicalsubnet

# Add the new Logical Network to Network Controller

$vlanNetwork = New-NetworkControllerLogicalNetwork -ConnectionUri
$uri -ResourceId "Contoso_L3_Network" -Properties $lnProperties -
Force

b. Cree un objeto JSON de conexión de red y agréguelo a controladora de red.

PowerShell

# Create a new object for the Tenant Network Connection

$nwConnectionProperties = New-Object
[Link]

# Update the common object properties

$[Link] = "L3"
$[Link] = 10000
$[Link] = 10000

# GRE specific configuration (leave blank for L3)

$[Link] = New-Object
[Link]

# Update specific properties depending on the Connection Type

$nwConnectionProperties.L3Configuration = New-Object
[Link].L3Configuration
$[Link] =
$[Link][0]

$[Link] = @()
$localIPAddress = New-Object
[Link]
$[Link] = "[Link]"
$[Link] = 25
$[Link] += $localIPAddress

$[Link] = @("[Link]")
 # Update the IPv4 Routes that are reachable over the site-to-site VPN
Tunnel
$[Link] = @()
$ipv4Route = New-Object [Link]
$[Link] = "[Link]/32"
$[Link] = 10
$[Link] += $ipv4Route

# Add the new Network Connection for the tenant

New-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri
$uri -VirtualGatewayId $[Link] -ResourceId
"Contoso_L3GW" -Properties $nwConnectionProperties -Force

5. Configure la puerta de enlace como un enrutador BGP y agréguela a controladora

de red.

a. Agregue un enrutador BGP para el inquilino.

PowerShell

# Create a new object for the Tenant BGP Router

$bgpRouterproperties = New-Object
[Link]

# Update the BGP Router properties

$[Link] = "0.64512"
$[Link] = "[Link]"
$[Link] = @("[Link]")

# Add the new BGP Router for the tenant

$bgpRouter = New-NetworkControllerVirtualGatewayBgpRouter -
ConnectionUri $uri -VirtualGatewayId $[Link] -
ResourceId "Contoso_BgpRouter1" -Properties $bgpRouterProperties -
Force

b. Agregue un par BGP para este inquilino, correspondiente a la conexión de red

VPN de sitio a sitio agregada anteriormente.

PowerShell

# Create a new object for Tenant BGP Peer

$bgpPeerProperties = New-Object
[Link]

# Update the BGP Peer properties

$[Link] = "[Link]"
$[Link] = 64521
$[Link] = "0.64521"
 # Add the new BGP Peer for tenant
New-NetworkControllerVirtualGatewayBgpPeer -ConnectionUri $uri -
VirtualGatewayId $[Link] -BgpRouterName
$[Link] -ResourceId "Contoso_IPSec_Peer" -Properties
$bgpPeerProperties -Force

(Paso opcional) Configuración de una puerta

de enlace con los tres tipos de conexión (IPsec,
GRE, L3) y BGP
Opcionalmente, puede combinar todos los pasos anteriores y configurar una puerta de
enlace virtual de inquilino con las tres opciones de conexión:

PowerShell

# Create a new Virtual Gateway Properties type object

$VirtualGWProperties = New-Object
[Link]

# Update GatewayPool reference

$[Link] = @()
$[Link] += $gwPool

# Specify the Virtual Subnet that is to be used for routing between GW and
VNET
$[Link] = @()
$[Link] += $RoutingSubnet

# Update some basic properties

$[Link] = "Dynamic"

# Update Network Connection object(s)

$[Link] = @()

# IPSec Connection configuration

$ipSecConnection = New-Object
[Link]
$[Link] = "Contoso_IPSecGW"
$[Link] = New-Object
[Link]
$[Link] = "IPSec"
$[Link] = 10000
$[Link] = 10000

$[Link] = New-Object
[Link]

$[Link] = "PSK"
$[Link] = "P@ssw0rd"

$[Link] = New-Object
[Link]

$[Link]
cy = "PFS2048"
$[Link]
formationConstant = "SHA256128"
$[Link]
nConstant = "DES3"
$[Link] =
1233
$[Link]
ds = 500
$[Link]
= 2000

$[Link] = New-Object
[Link]

$[Link] =
"Group2"
$[Link] =
"SHA256"
$[Link]
= "AES256"
$[Link] =
1234
$[Link]
= 2000

$[Link] = @()
$[Link] = @()

$[Link] = @()

$ipv4Route = New-Object [Link]

$[Link] = "[Link]/32"
$[Link] = 10
$[Link] += $ipv4Route

$[Link] = "[Link]"

# GRE Connection configuration

$greConnection = New-Object
[Link]
$[Link] = "Contoso_GreGW"

$[Link] = New-Object
[Link]
$[Link] = "GRE"
$[Link] = 10000
$[Link] = 10000
$[Link] = New-Object
[Link]
$[Link] = 1234

$[Link] = @()
$[Link] = @()

$[Link] = @()

$ipv4Route = New-Object [Link]

$[Link] = "[Link]/32"
$[Link] = 10
$[Link] += $ipv4Route

$[Link] = "[Link]"

$[Link].L3Configuration = New-Object
[Link].L3Configuration

# L3 Forwarding connection configuration

$l3Connection = New-Object
[Link]
$[Link] = "Contoso_L3GW"

$[Link] = New-Object
[Link]
$[Link] = "L3"
$[Link] = 10000
$[Link] = 10000

$[Link] = New-Object
[Link]
$[Link].L3Configuration = New-Object
[Link].L3Configuration
$[Link] =
$[Link][0]

$[Link] = @()
$localIPAddress = New-Object
[Link]
$[Link] = "[Link]"
$[Link] = 25
$[Link] += $localIPAddress

$[Link] = @("[Link]")

$[Link] = @()
$ipv4Route = New-Object [Link]
$[Link] = "[Link]/32"
$[Link] = 10
$[Link] += $ipv4Route

# Update BGP Router Object

$[Link] = @()
$bgpRouter = New-Object [Link]
$[Link] = "Contoso_BgpRouter1"
$[Link] = New-Object
[Link]

$[Link] = "0.64512"
$[Link] = "[Link]"
$[Link] = @("[Link]")

$[Link] = @()

# Create BGP Peer Object(s)

# BGP Peer for IPSec Connection
$bgpPeer_IPSec = New-Object [Link]
$bgpPeer_IPSec.ResourceId = "Contoso_IPSec_Peer"

$bgpPeer_IPSec.Properties = New-Object
[Link]
$bgpPeer_IPSec.[Link] = "[Link]"
$bgpPeer_IPSec.[Link] = 64521
$bgpPeer_IPSec.[Link] = "0.64521"

$[Link] += $bgpPeer_IPSec

# BGP Peer for GRE Connection

$bgpPeer_Gre = New-Object [Link]
$bgpPeer_Gre.ResourceId = "Contoso_Gre_Peer"

$bgpPeer_Gre.Properties = New-Object
[Link]
$bgpPeer_Gre.[Link] = "[Link]"
$bgpPeer_Gre.[Link] = 64522
$bgpPeer_Gre.[Link] = "0.64522"

$[Link] += $bgpPeer_Gre

# BGP Peer for L3 Connection

$bgpPeer_L3 = New-Object [Link]
$bgpPeer_L3.ResourceId = "Contoso_L3_Peer"

$bgpPeer_L3.Properties = New-Object
[Link]
$bgpPeer_L3.[Link] = "[Link]"
$bgpPeer_L3.[Link] = 64523
$bgpPeer_L3.[Link] = "0.64523"

$[Link] += $bgpPeer_L3

$[Link] += $bgpRouter

# Finally Add the new Virtual Gateway for tenant

New-NetworkControllerVirtualGateway -ConnectionUri $uri -ResourceId
"Contoso_VirtualGW" -Properties $VirtualGWProperties -Force
Modificación de una puerta de enlace para una
red virtual
Recuperar la configuración del componente y almacenarla en una variable

PowerShell

$nwConnection = Get-NetworkControllerVirtualGatewayNetworkConnection -
ConnectionUri $uri -VirtualGatewayId "Contoso_VirtualGW" -ResourceId
"Contoso_IPSecGW"

Navegue por la estructura de variables para llegar a la propiedad necesaria y

establézcala en el valor de actualizaciones.

PowerShell

$[Link] = "C0mplexP@ssW0rd"

Adición de la configuración modificada para reemplazar la configuración anterior en

controladora de red

PowerShell

New-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri $uri -

VirtualGatewayId "Contoso_VirtualGW" -ResourceId $[Link] -
Properties $[Link] -Force

Eliminación de una puerta de enlace de una red

virtual
Puede usar los siguientes comandos de Windows PowerShell para quitar características
de puerta de enlace individuales o toda la puerta de enlace.

Eliminación de una conexión de red

PowerShell

Remove-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri $uri

-VirtualGatewayId "Contoso_VirtualGW" -ResourceId "Contoso_IPSecGW" -Force

Quitar un par BGP

PowerShell
 Remove-NetworkControllerVirtualGatewayBgpPeer -ConnectionUri $uri -
VirtualGatewayId "Contoso_VirtualGW" -BgpRouterName "Contoso_BgpRouter1" -
ResourceId "Contoso_IPSec_Peer" -Force

Quitar un enrutador BGP

PowerShell

Remove-NetworkControllerVirtualGatewayBgpRouter -ConnectionUri $uri -

VirtualGatewayId "Contoso_VirtualGW" -ResourceId "Contoso_BgpRouter1" -Force

Eliminación de una puerta de enlace

PowerShell

Remove-NetworkControllerVirtualGateway -ConnectionUri $uri -ResourceId

"Contoso_VirtualGW" -Force
Conexión de puntos de conexión de
contenedor a una red virtual de
inquilino
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En este tema, se muestra cómo conectar puntos de conexión de contenedor a una red
virtual de inquilino existente creada a través de SDN. Use el controlador de red l2bridge
(y, opcionalmente, l2tunnel) disponible con el complemento libnetwork de Windows
para Docker para crear una red de contenedor en la máquina virtual del inquilino.

En el tema Controladores de red de contenedor, hemos analizado los varios

controladores de red que están disponibles a través de Docker en Windows. Para SDN,
use los controladores l2bridgey l2tunnel . Para ambos controladores, cada punto de
conexión de contenedor está en la misma subred virtual que la máquina virtual del host
de contenedor (inquilino).

El servicio de redes de host (HNS), a través del complemento de nube privada, asigna
dinámicamente las direcciones IP para los puntos de conexión de contenedor. Los
puntos de conexión de contenedor tienen direcciones IP únicas, pero comparten la
misma dirección MAC de la máquina virtual del host de contenedor (inquilino) debido a
la traducción de direcciones de nivel 2.

La directiva de red (ACL, encapsulación y QoS) para estos puntos de conexión de

contenedor se aplica en el host físico de Hyper-V tal como lo recibe la controladora de
red y se define en los sistemas de administración de nivel superior.

Las diferencias entre los controladores l2bridgey l2tunnel son:

l2bridge l2tunnel
l2bridge l2tunnel

Puntos de conexión de contenedor que residen TODO el tráfico de red entre dos puntos de
en: conexión de contenedor se reenvía al host físico
La misma máquina virtual del host de de Hyper-V independientemente del host o
contenedor y en la misma subred tienen subred. La directiva de red se aplica al tráfico de
todo el tráfico de red puenteado dentro red entre subredes y entre host.
del conmutador virtual de Hyper-V.
Las diferentes máquinas virtuales de host
de contenedor o en subredes diferentes
reenván su tráfico al host físico de
Hyper-V.

La directiva de red no se aplica, ya que el

tráfico de red entre contenedores en el mismo
host y en la misma subred no fluye al host
físico. La directiva de red solo se aplica al
tráfico de red entre host o entre subredes.

７ Nota

Estos modos de red no funcionan para conectar puntos de conexión de contenedor

de Windows a una red virtual de inquilino en la nube pública de Azure.

Prerrequisitos
Una infraestructura de SDN implementada con la controladora de red.

Se ha creado una red virtual de inquilino.

Una máquina virtual de inquilino implementada con la característica Windows

container habilitada, Docker instalado y la característica Hyper-V habilitada. La
característica Hyper-V es necesaria para instalar varios archivos binarios para redes
l2bridge y l2tunnel.

PowerShell

# To install HyperV feature without checks for nested virtualization

dism /Online /Enable-Feature /FeatureName:Microsoft-Hyper-V /All

７ Nota

La virtualización anidada y la exposición de extensiones de virtualización no son

necesarias a menos que se usen contenedores de Hyper-V.
Flujo de trabajo
1. Agregue varias configuraciones ip a un recurso de NIC de máquina virtual existente
mediante controladora de red (host de Hyper-V)2. Habilite el proxy de red en el host
para asignar direcciones IP de CA para los puntos de conexión de contenedor (host de
Hyper-V)3. Instale el complemento de nube privada para asignar direcciones IP de
entidad de certificación a los puntos de conexión de contenedor (VM de host de
contenedor)4. Creación de una red l2bridgeo l2tunnel mediante Docker (máquina virtual
de host de contenedor)

７ Nota

No se admiten varias configuraciones de IP en los recursos nic de máquina virtual

creados mediante System Center Virtual Machine Manager. Se recomienda para
estos tipos de implementaciones que cree el recurso nic de máquina virtual fuera
de banda mediante La controladora de red de PowerShell.

1. Agregar varias configuraciones de IP

En este paso, se supone que la NIC de máquina virtual de la máquina virtual del
inquilino tiene una configuración ip con la dirección IP [Link] y está asociada a un
identificador de recurso de red virtual de "VNet1" y un recurso de subred de máquina
virtual de "Subnet1" en la subred IP [Link]/24. Agregamos 10 direcciones IP para
contenedores de [Link] a [Link].

PowerShell

Import-Module NetworkController

# Specify Network Controller REST IP or FQDN

$uri = "<NC REST IP or FQDN>"
$vnetResourceId = "VNet1"
$vsubnetResourceId = "Subnet1"

$vmnic= Get-NetworkControllerNetworkInterface -ConnectionUri $uri | where

{$_.[Link] -eq
"[Link]" }
$vmsubnet = Get-NetworkControllerVirtualSubnet -VirtualNetworkId
$vnetResourceId -ResourceId $vsubnetResourceId -ConnectionUri $uri

# For this demo, we will assume an ACL has already been defined; any ACL can
be applied here
$allowallacl = Get-NetworkControllerAccessControlList -ConnectionUri $uri -
 ResourceId "AllowAll"

foreach ($i in 1..10)

{
$newipconfig = new-object
[Link]
$props = new-object
[Link]
s

$resourceid = "IP_192_168_1_1"
if ($i -eq 10)
{
$resourceid += "10"
$ipstr = "[Link]"
}
else
{
$resourceid += "0$i"
$ipstr = "[Link]$i"
}

$[Link] = $resourceid
$[Link] = $ipstr

$[Link] = "Static"
$[Link] = new-object [Link]
$[Link] = $[Link]
$[Link] = new-object
[Link]
$[Link] = $[Link]

$[Link] = $props
$[Link] += $newipconfig
}

New-NetworkControllerNetworkInterface -ResourceId $[Link] -

Properties $[Link] -ConnectionUri $uri

2. Habilitación del proxy de red

En este paso, habilitará el proxy de red para asignar varias direcciones IP para la
máquina virtual del host de contenedor.

Para habilitar el proxy de red, ejecute el script ConfigureMCNP.ps1 en el host de

Hyper-V que hospeda la máquina virtual del host de contenedor (inquilino).

PowerShell

PS C:\> ConfigureMCNP.ps1
3. Instalación del complemento de nube privada
En este paso, instalará un complemento para permitir que el HNS se comunique con el
proxy de red en el host de Hyper-V.

Para instalar el complemento, ejecute el script InstallPrivateCloudPlugin.ps1dentro de

la máquina virtual del host de contenedor (inquilino).

PowerShell

PS C:\> InstallPrivateCloudPlugin.ps1

4. Creación de una red de contenedor l2bridge

En este paso, usará el comando en docker network create la máquina docker network
create para crear una red l2bridge.

PowerShell

# Create the container network

C:\> docker network create -d l2bridge --subnet="[Link]/24" --
gateway="[Link]" MyContainerOverlayNetwork

# Attach a container to the MyContainerOverlayNetwork

C:\> docker run -it --network=MyContainerOverlayNetwork <image> <cmd>

７ Nota

La asignación de IP estática no se admite con redes de contenedor l2bridge o

l2tunnel cuando se usa con la pila de SDN de Microsoft.

Más información
Para más información sobre la implementación de una infraestructura de SDN, consulte
Implementación de una infraestructura de red definida por software.
Configuración del cifrado para una
subred virtual
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

El cifrado de red virtual permite el cifrado del tráfico de red virtual entre máquinas
virtuales que se comunican entre sí dentro de subredes marcadas como "Cifrado
habilitado". También utiliza la Seguridad de la capa de transporte de datagrama (DTLS)
en la subred virtual para cifrar los paquetes. DTLS protege frente a las interceptaciones,
alteraciones y falsificaciones realizadas por cualquier persona con acceso a la red física.

El cifrado de red virtual requiere:

Certificados de cifrado instalados en cada uno de los hosts de Hyper-V habilitados

para SDN.
Objeto de credencial de la controladora de red que hace referencia a la huella
digital de ese certificado.
La configuración de cada una de las redes virtuales contiene subredes que
requieren cifrado.

Una vez habilitado el cifrado en una subred, todo el tráfico de red dentro de esa subred
se cifra automáticamente, además de cualquier cifrado de nivel de aplicación que
también pueda tener lugar. El tráfico que cruza entre subredes, incluso si está marcado
como cifrado, se envía sin cifrar automáticamente. Cualquier tráfico que cruce el límite
de la red virtual también se envía sin cifrar.

７ Nota

Al comunicarse con otra máquina virtual en la misma subred, tanto si está

conectado como conectado posteriormente, el tráfico se cifra automáticamente.

 Sugerencia

Si debe restringir las aplicaciones para que solo se comuniquen en la subred

cifrada, puede usar Access Control Listas (ACL) solo para permitir la comunicación
dentro de la subred actual. Para obtener más información, consulte Uso de listas
 de Access Control (ACL) para administrar el tráfico de red del centro de datos
Flow.

Paso 1. Creación del certificado de cifrado

Cada host debe tener instalado un certificado de cifrado. Puede usar el mismo
certificado para todos los inquilinos o generar uno único para cada inquilino.

1. Generación del certificado

$subjectName = "EncryptedVirtualNetworks"
$cryptographicProviderName = "Microsoft Base Cryptographic Provider
v1.0";
[int] $privateKeyLength = 1024;
$sslServerOidString = "[Link].[Link].1";
$sslClientOidString = "[Link].[Link].2";
[int] $validityPeriodInYear = 5;

$name = new-object -com "X509Enrollment.CX500DistinguishedName.1"

$[Link]("CN=" + $SubjectName, 0)

#Generate Key
$key = new-object -com "X509Enrollment.CX509PrivateKey.1"
$[Link] = $cryptographicProviderName
$[Link] = 1 #X509KeySpec.XCN_AT_KEYEXCHANGE
$[Link] = $privateKeyLength
$[Link] = 1
$[Link] = 0x2
#X509PrivateKeyExportFlags.XCN_NCRYPT_ALLOW_EXPORT_FLAG
$[Link]()

#Configure Eku
$serverauthoid = new-object -com "[Link].1"
$[Link]($sslServerOidString)
$clientauthoid = new-object -com "[Link].1"
$[Link]($sslClientOidString)
$ekuoids = new-object -com "[Link].1"
$[Link]($serverauthoid)
$[Link]($clientauthoid)
$ekuext = new-object -com
"X509Enrollment.CX509ExtensionEnhancedKeyUsage.1"
$[Link]($ekuoids)

# Set the hash algorithm to sha512 instead of the default sha1

$hashAlgorithmObject = New-Object -ComObject [Link]
$[Link](
$ObjectIdGroupId.XCN_CRYPT_HASH_ALG_OID_GROUP_ID,
$ObjectIdPublicKeyFlags.XCN_CRYPT_OID_INFO_PUBKEY_ANY,
 $[Link], "SHA512")

#Request Certificate
$cert = new-object -com
"X509Enrollment.CX509CertificateRequestCertificate.1"

$[Link](2, $key, "")

$[Link] = $name
$[Link] = $[Link]
$[Link] = (get-date).ToUniversalTime()
$[Link] = $[Link]($validityPeriodInYear);
$[Link]($ekuext)
$[Link] = $hashAlgorithmObject
$[Link]()

$enrollment = new-object -com "X509Enrollment.CX509Enrollment.1"

$[Link]($cert)
$certdata = $[Link](0)
$[Link](2, $certdata, 0, "")

Después de ejecutar el script, aparece un nuevo certificado en Mi almacén:

PS D:\> dir cert:\\localmachine\my

PSParentPath:
[Link]\Certificate::localmachine\my

Thumbprint Subject
---------- -------
84857CBBE7A1C851A80AE22391EB2C39BF820CE7 CN=MyNetwork
5EFF2CE51EACA82408572A56AE1A9BCC7E0843C6 CN=EncryptedVirtualNetworks

2. Exporte el certificado a un archivo.

Necesita dos copias del certificado, una con la clave privada y otra sin.

$subjectName = "EncryptedVirtualNetworks"
$cert = Get-ChildItem cert:\localmachine\my | ? {$_.Subject -eq
"CN=$subjectName"}
[[Link]]::WriteAllBytes("c:\$[Link]",
$[Link]("PFX", "secret"))
Export-Certificate -Type CERT -FilePath "c:\$[Link]" -cert
$cert

3. Instalar los certificados en cada uno de los hosts de Hyper-v

 PS C:\> dir c:\$subjectname.*

Directory: C:\

Mode LastWriteTime Length Name

---- ------------- ------ ----
-a---- 9/22/2017 4:54 PM 543
[Link]
-a---- 9/22/2017 4:54 PM 1706
[Link]

4. Instalación en un host de Hyper-V

$server = "Server01"

$subjectname = "EncryptedVirtualNetworks"
copy c:\$SubjectName.* \\$server\c$
invoke-command -computername $server -ArgumentList
$subjectname,"secret" {
param (
[string] $SubjectName,
[string] $Secret
)
$certFullPath = "c:\$[Link]"

# create a representation of the certificate file

$certificate = new-object
[Link].X509Certificates.X509Certificate2
$[Link]($certFullPath)

# import into the store

$store = new-object
[Link].X509Certificates.X509Store("Root",
"LocalMachine")
$[Link]("MaxAllowed")
$[Link]($certificate)
$[Link]()

$certFullPath = "c:\$[Link]"
$certificate = new-object
[Link].X509Certificates.X509Certificate2
$[Link]($certFullPath, $Secret,
"MachineKeySet,PersistKeySet")

# import into the store

$store = new-object
[Link].X509Certificates.X509Store("My",
"LocalMachine")
$[Link]("MaxAllowed")
$[Link]($certificate)
 $[Link]()

# Important: Remove the certificate files when finished

remove-item C:\$[Link]
remove-item C:\$[Link]
}

5. Repita el proceso para cada servidor de su entorno.

Después de repetir para cada servidor, debe tener un certificado instalado en la

raíz y mi almacén de cada host de Hyper-V.

6. Compruebe la instalación del certificado.

Compruebe los certificados comprobando el contenido de los almacenes de

certificados My y Root:

PS C:\> enter-pssession Server1

[Server1]: PS C:\> get-childitem

cert://localmachine/my,cert://localmachine/root | ? {$_.Subject -eq
"CN=EncryptedVirtualNetworks"}

PSParentPath:
[Link]\Certificate::localmachine\my

Thumbprint Subject
---------- -------
5EFF2CE51EACA82408572A56AE1A9BCC7E0843C6 CN=EncryptedVirtualNetworks

PSParentPath:
[Link]\Certificate::localmachine\root

Thumbprint Subject
---------- -------
5EFF2CE51EACA82408572A56AE1A9BCC7E0843C6 CN=EncryptedVirtualNetworks

7. Anote la huella digital.

Debe anotar la huella digital porque la necesita para crear el objeto de credencial
de certificado en la controladora de red.

Paso 2. Creación de la credencial de certificado

Después de instalar el certificado en cada uno de los hosts de Hyper-V conectados a la
controladora de red, ahora debe configurar la controladora de red para usarla. Para ello,
debe crear un objeto de credencial que contenga la huella digital del certificado desde
la máquina con los módulos de PowerShell de controladora de red instalados.

///Replace with the thumbprint from your certificate

$thumbprint = "5EFF2CE51EACA82408572A56AE1A9BCC7E0843C6"

$uri = "[Link]

///Replace with your Network Controller URI

Import-module networkcontroller

$credproperties = new-object
[Link]
$[Link] = "X509Certificate"
$[Link] = $thumbprint
New-networkcontrollercredential -connectionuri $uri -resourceid
"EncryptedNetworkCertificate" -properties $credproperties -force

 Sugerencia

Puede reutilizar esta credencial para cada red virtual cifrada, o bien puede
implementar y usar un certificado único para cada inquilino.

Paso 3. Configuración de un Virtual Network

para el cifrado
En este paso se supone que ya ha creado un nombre de red virtual "Mi red" y que
contiene al menos una subred virtual. Para obtener información sobre la creación de
redes virtuales, consulte Creación, eliminación o actualización de redes virtuales de
inquilino.

７ Nota

Al comunicarse con otra máquina virtual en la misma subred, tanto si está

conectado como conectado posteriormente, el tráfico se cifra automáticamente.

1. Recupere los objetos Virtual Network y Credential de la controladora de red:

 $vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -
ResourceId "MyNetwork"
$certcred = Get-NetworkControllerCredential -ConnectionUri $uri -
ResourceId "EncryptedNetworkCertificate"

2. Agregue una referencia a la credencial del certificado y habilite el cifrado en

subredes individuales:

$[Link] = $certcred

# Replace the Subnets index with the value corresponding to the subnet
you want encrypted.
# Repeat for each subnet where encryption is needed
$[Link][0].[Link] = $true

3. Coloque el objeto Virtual Network actualizado en la controladora de red:

New-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId

$[Link] -Properties $[Link] -force

¡Felicitaciones! * Ya ha terminado una vez completados estos pasos.

Medición de salida en una red virtual
Artículo • 21/12/2022 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Un aspecto fundamental de la monetización de redes en la nube es poder facturar por

uso del ancho de banda de red. Los datos salientes se cobran en función de la cantidad
total de datos que se mueven fuera del centro de datos a través de Internet en un ciclo
de facturación determinado.

Egress medición del tráfico de red SDN en Windows Server 2019 permite ofrecer
medidores de uso para las transferencias de datos salientes. El tráfico de red que sale de
cada red virtual pero permanece dentro del centro de datos se puede realizar por
separado para que se pueda excluir de los cálculos de facturación. Los paquetes
enlazados a direcciones IP de destino que no están incluidos en uno de los intervalos de
direcciones no facturadas se realiza un seguimiento como transferencias de datos
salientes facturadas.

Intervalos de direcciones no facturadas de red

virtual (lista de permitidos de intervalos IP)
Puede encontrar intervalos de direcciones sin facturar en la propiedad
UnbilledAddressRanges de una red virtual existente. De forma predeterminada, no se
agregan intervalos de direcciones.

PowerShell

import-module NetworkController
$uri = "[Link]

(Get-NetworkControllerVirtualNetwork -ConnectionURI $URI -ResourceId

"VNet1").properties

La salida tendrá un aspecto similar al siguiente:

AddressSpace : [Link]
DhcpOptions :
UnbilledAddressRanges :
ConfigurationState :
ProvisioningState : Succeeded
 Subnets : {21e71701-9f59-4ee5-b798-2a9d8c2762f0, 5f4758ef-
9f96-40ca-a389-35c414e996cc,
29fe67b8-6f7b-486c-973b-8b9b987ec8b3}
VirtualNetworkPeerings :
EncryptionCredential :
LogicalNetwork : [Link]

Ejemplo: Administración de los intervalos de

direcciones sin facturar de una red virtual
Puede administrar el conjunto de prefijos de subred IP para excluir de la medición de
salida facturada estableciendo la propiedad UnbilledAddressRange de una red virtual.
Cualquier tráfico enviado por interfaces de red en la red virtual con una dirección IP de
destino que coincida con uno de los prefijos no se incluirá en la propiedad
BilledEgressBytes.

1. Actualice la propiedad UnbilledAddressRanges para que contenga las subredes a

las que no se facturará el acceso.

PowerShell

$vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -

ResourceID "VNet1"
$[Link] = "[Link]/24,[Link]/24"

 Sugerencia

Si agrega varias subredes IP, use una coma entre cada una de las subredes IP.
No incluya ningún espacio antes o después de la coma.

2. Actualice el Virtual Network con la propiedad UnbilledAddressRanges modificada.

PowerShell

New-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId

"VNet1" -Properties $[Link] -PassInnerException

La salida tendrá un aspecto similar al siguiente:

Confirm
Performing the operation 'New-NetworkControllerVirtualNetwork' on
 entities of type
'[Link]' via
'[Link] Are
you sure you want to continue?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y

Tags :
ResourceRef : /virtualNetworks/VNet1
InstanceId : 29654b0b-9091-4bed-ab01-e172225dc02d
Etag : W/"6970d0a3-3444-41d7-bbe4-36327968d853"
ResourceMetadata :
ResourceId : VNet1
Properties :
[Link]

3. Compruebe el Virtual Network para ver los unbilledAddressRanges configurados.

PowerShell

(Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceID

"VNet1").properties

La salida tendrá ahora un aspecto similar al siguiente:

AddressSpace :
[Link]
DhcpOptions :
UnbilledAddressRanges : [Link]/24,[Link]/24
ConfigurationState :
ProvisioningState : Succeeded
Subnets : {21e71701-9f59-4ee5-b798-2a9d8c2762f0,
5f4758ef-9f96-40ca-a389-35c414e996cc,
29fe67b8-6f7b-486c-973b-8b9b987ec8b3}
VirtualNetworkPeerings :
EncryptionCredential :
LogicalNetwork :
[Link]

Comprobar el uso de salida no facturado de

una red virtual facturada
Después de configurar la propiedad UnbilledAddressRanges , puede comprobar el uso
de salida facturada y no facturada de cada subred dentro de una red virtual. Egress el
tráfico se actualiza cada cuatro minutos con el total de bytes de los intervalos facturados
y no facturados.

Las siguientes propiedades están disponibles para cada subred virtual:

UnbilledEgressBytes muestra el número de bytes sin facturar enviados por

interfaces de red conectadas a esta subred virtual. Los bytes no facturados son
bytes enviados a intervalos de direcciones que forman parte de la propiedad
UnbilledAddressRanges de la red virtual primaria.

BilledEgressBytes muestra el número de bytes facturados enviados por interfaces

de red conectadas a esta subred virtual. Los bytes facturados son bytes enviados a
intervalos de direcciones que no forman parte de la propiedad
UnbilledAddressRanges de la red virtual primaria.

Use el ejemplo siguiente para consultar el uso de salida:

PowerShell

(Get-NetworkControllerVirtualNetwork -ConnectionURI $URI -ResourceId

"VNet1").[Link] | ft
AddressPrefix,BilledEgressBytes,UnbilledEgressBytes

La salida tendrá un aspecto similar al siguiente:

AddressPrefix BilledEgressBytes UnbilledEgressBytes

------------- ----------------- -------------------
[Link]/29 16827067 0
[Link]/24 781733019 0
[Link]/24 0 0
Administración de cargas de trabajo de
inquilinos
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Este tema contiene vínculos a documentación que le permite administrar cargas de

trabajo de inquilino mediante la adición de máquinas virtuales de inquilino, el uso de
aplicaciones virtuales de red, la configuración del equilibrio de carga de software, etc.

Esta sección incluye los temas siguientes.

Creación de una máquina virtual y Conectar a un inquilino Virtual Network o VLAN

Configuración de Calidad de servicio para un adaptador de red de máquina virtual
de inquilino
Configuración de listas de control de acceso (ACL) de Datacenter Firewall
Configuración del software Load Balancer equilibrio de carga y traducción de
direcciones de red (NAT)
Uso de aplicaciones virtuales de red en un Virtual Network
Agrupación en clústeres invitados en Virtual Network
Creación de una máquina virtual y
conexión a una red VLAN o red virtual
de inquilino
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En este tema, creará una máquina virtual de inquilino y la conectará a una red virtual
que creó con virtualización de red de Hyper-V o a una red de área local virtual (VLAN).
Puede usar Windows PowerShell cmdlets de Controladora de red para conectarse a una
red virtual o NetworkControllerRESTWrappers para conectarse a una VLAN.

Use los procesos descritos en este tema para implementar aplicaciones virtuales. Con
algunos pasos adicionales, puede configurar dispositivos para procesar o inspeccionar
paquetes de datos que fluyen hacia o desde otras máquinas virtuales en la Virtual
Network.

Las secciones de este tema incluyen comandos de ejemplo Windows PowerShell que
contienen valores de ejemplo para muchos parámetros. Asegúrese de reemplazar los
valores de ejemplo de estos comandos por los valores adecuados para la
implementación antes de ejecutar estos comandos.

Requisitos previos
1. Adaptadores de red de máquina virtual creados con direcciones MAC estáticas
durante la vigencia de la máquina virtual.

Si la dirección MAC cambia durante la vigencia de la máquina virtual, la

controladora de red no puede configurar la directiva necesaria para el adaptador
de red. No configurar la directiva de la red impide que el adaptador de red
procese el tráfico de red y se produzca un error en toda la comunicación con la
red.

2. Si la máquina virtual requiere acceso a la red durante el inicio, no inicie la máquina

virtual hasta después de establecer el identificador de interfaz en el puerto del
adaptador de red de la máquina virtual. Si inicia la máquina virtual antes de
establecer el identificador de interfaz y la interfaz de red no existe, la máquina
 virtual no puede comunicarse en la red en la controladora de red y todas las
directivas aplicadas.

3. Si necesita ACL personalizadas para esta interfaz de red, cree la ACL ahora
mediante instrucciones del tema Uso de listas de Access Control (ACL) para
administrar el tráfico de red del centro de datos Flow

Asegúrese de que ya ha creado un Virtual Network antes de usar este comando de

ejemplo. Para obtener más información, vea Crear, eliminar o actualizar redes virtuales
de inquilino.

Creación de una máquina virtual y conexión a

un Virtual Network mediante los cmdlets de
controlador de red de Windows PowerShell
1. Cree una máquina virtual con un adaptador de red de máquina virtual que tenga
una dirección MAC estática.

PowerShell

New-VM -Generation 2 -Name "MyVM" -Path "C:\VMs\MyVM" -

MemoryStartupBytes 4GB -VHDPath "C:\VMs\MyVM\Virtual Hard
Disks\[Link]" -SwitchName "SDNvSwitch"

Set-VM -Name "MyVM" -ProcessorCount 4

Set-VMNetworkAdapter -VMName "MyVM" -StaticMacAddress "00-11-22-33-44-

55"

2. Obtenga la red virtual que contiene la subred a la que desea conectar el adaptador
de red.

Powershell

$vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -

ResourceId "Contoso_WebTier"

3. Cree un objeto de interfaz de red en controladora de red.

 Sugerencia

En este paso, usará la ACL personalizada.

 PowerShell

$vmnicproperties = New-Object
[Link]
$[Link] = "001122334455"
$[Link] = "Static"
$[Link] = $true

$[Link] = New-Object
[Link]
$[Link] = @("[Link]", "[Link]")

$ipconfiguration = New-Object
[Link]
$[Link] = "MyVM_IP1"
$[Link] = New-Object
[Link]
erties
$[Link] = "[Link]"
$[Link] = "Static"

$[Link] = New-Object
[Link]
$[Link] =
$[Link][0].ResourceRef

$[Link] = @($ipconfiguration)
New-NetworkControllerNetworkInterface –ResourceID "MyVM_Ethernet1" –
Properties $vmnicproperties –ConnectionUri $uri

4. Obtenga instanceId para la interfaz de red de la controladora de red.

PowerShell

$nic = Get-NetworkControllerNetworkInterface -ConnectionUri $uri -

ResourceId "MyVM_Ethernet1"

5. Establezca el identificador de interfaz en el puerto del adaptador de red de

máquina virtual de Hyper-V.

７ Nota

Debe ejecutar estos comandos en el host de Hyper-V donde está instalada la

máquina virtual.

PowerShell

#Do not change the hardcoded IDs in this section, because they are
fixed values and must not change.
 $FeatureId = "9940cd46-8b06-43bb-b9d5-93d50381fd56"

$vmNics = Get-VMNetworkAdapter -VMName "MyVM"

$CurrentFeature = Get-VMSwitchExtensionPortFeature -FeatureId

$FeatureId -VMNetworkAdapter $vmNics

if ($CurrentFeature -eq $null) {

$Feature = Get-VMSystemSwitchExtensionPortFeature -FeatureId
$FeatureId

$[Link] = "{$($[Link])}"
$[Link] = "{56785678-a0e5-4a26-bc9b-
c0cba27311a3}"
$[Link] = "TestCdn"
$[Link] = 1111
$[Link] = "Testprofile"
$[Link] = "{1FA41B39-B444-4E43-B35A-
E1F7985FD548}"
$[Link] = "NetworkController"
$[Link] = 1

Add-VMSwitchExtensionPortFeature -VMSwitchExtensionFeature
$Feature -VMNetworkAdapter $vmNics
} else {
$[Link] = "{$($[Link])}"
$[Link] = 1

Set-VMSwitchExtensionPortFeature -VMSwitchExtensionFeature
$CurrentFeature -VMNetworkAdapter $vmNics
}

6. Inicie la máquina virtual.

PowerShell

Get-VM -Name "MyVM" | Start-VM

Ha creado correctamente una máquina virtual, ha conectado la máquina virtual a un

inquilino Virtual Network e iniciado la máquina virtual para que pueda procesar cargas
de trabajo de inquilino.

Creación de una máquina virtual y conexión a

una VLAN mediante
NetworkControllerRESTWrappers
1. Cree la máquina virtual y asigne una dirección MAC estática a la máquina virtual.
 PowerShell

New-VM -Generation 2 -Name "MyVM" -Path "C:\VMs\MyVM" -

MemoryStartupBytes 4GB -VHDPath "C:\VMs\MyVM\Virtual Hard
Disks\[Link]" -SwitchName "SDNvSwitch"

Set-VM -Name "MyVM" -ProcessorCount 4

Set-VMNetworkAdapter -VMName "MyVM" -StaticMacAddress "00-11-22-33-44-

55"

2. Establezca el identificador de VLAN en el adaptador de red de la máquina virtual.

PowerShell

Set-VMNetworkAdapterIsolation –VMName "MyVM" -AllowUntaggedTraffic

$true -IsolationMode VLAN -DefaultIsolationId 123

3. Obtenga la subred de red lógica y cree la interfaz de red.

PowerShell

$logicalnet = Get-NetworkControllerLogicalNetwork -ConnectionUri $uri

-ResourceId "00000000-2222-1111-9999-000000000002"

$vmnicproperties = New-Object
[Link]
$[Link] = "00-1D-C8-B7-01-02"
$[Link] = "Static"
$[Link] = $true

$[Link] = New-Object
[Link]
$[Link] =
$[Link][0].DNSServers

$ipconfiguration = New-Object
[Link]
$[Link] = "MyVM_Ip1"
$[Link] = New-Object
[Link]
erties
$[Link] = "[Link]"
$[Link] = "Static"

$[Link] = New-Object
[Link]
$[Link] =
$[Link][0].ResourceRef

$[Link] = @($ipconfiguration)
 $vnic = New-NetworkControllerNetworkInterface –ResourceID
"MyVM_Ethernet1" –Properties $vmnicproperties –ConnectionUri $uri

$[Link]

4. Establezca instanceId en el puerto de Hyper-V.

PowerShell

#The hardcoded Ids in this section are fixed values and must not
change.
$FeatureId = "9940cd46-8b06-43bb-b9d5-93d50381fd56"

$vmNics = Get-VMNetworkAdapter -VMName "MyVM"

$CurrentFeature = Get-VMSwitchExtensionPortFeature -FeatureId

$FeatureId -VMNetworkAdapter $vmNics

if ($CurrentFeature -eq $null) {

$Feature = Get-VMSystemSwitchExtensionFeature -FeatureId $FeatureId

$[Link] = "{$InstanceId}"
$[Link] = "{56785678-a0e5-4a26-bc9b-
c0cba27311a3}"
$[Link] = "TestCdn"
$[Link] = 1111
$[Link] = "Testprofile"
$[Link] = "{1FA41B39-B444-4E43-B35A-
E1F7985FD548}"
$[Link] = "NetworkController"
$[Link] = 1

Add-VMSwitchExtensionFeature -VMSwitchExtensionFeature $Feature -

VMNetworkAdapter $vmNics
} else {
$[Link] = "{$InstanceId}"
$[Link] = 1

Set-VMSwitchExtensionPortFeature -VMSwitchExtensionFeature
$CurrentFeature -VMNetworkAdapter $vmNics
}

5. Inicie la máquina virtual.

PowerShell

Get-VM -Name "MyVM" | Start-VM

Ha creado correctamente una máquina virtual, ha conectado la máquina virtual a una

VLAN e iniciado la máquina virtual para que pueda procesar cargas de trabajo de
inquilino.
Configuración de la calidad de servicio
(QoS) para un adaptador de red de
máquina virtual
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Puede configurar la calidad de servicio (QoS) de redes definidas por software (SDN) para
un adaptador de red de máquina virtual (VM) con el fin de limitar el ancho de banda en
una interfaz virtual para evitar que una máquina virtual de tráfico elevado se deba a otro
tráfico de red de máquina virtual. También puede configurar sdn qos para reservar una
cantidad específica de ancho de banda para una máquina virtual para asegurarse de que
la máquina virtual puede enviar tráfico independientemente de otro tráfico en la red.
Esto se puede aplicar a las máquinas virtuales conectadas a redes VLAN tradicionales,
así como a las máquinas virtuales conectadas a redes superpuestas de SDN.

También puede configurar la descarga de QoS para aplicar reglas de QoS en el

adaptador de red físico en lugar de en el conmutador virtual, lo que da lugar a un
menor uso de la CPU y un cumplimiento mejorado. La descarga de QoS es una
funcionalidad opcional que se encuentra en las NIC certificadas de Windows Server
2022 que han logrado la calificación adicional (AQ) de Windows Server Software-
Defined Data Center (SDDC) Premium. Para más información, consulte Selección de un
adaptador de red.

Límites de ancho de banda de QoS de SDN

Sdn QoS proporciona la configuración del ancho de banda máximo permitido del lado
de envío o del lado de recepción para las máquinas virtuales. Esto es compatible con las
máquinas virtuales conectadas a una red VLAN tradicional, así como las máquinas
virtuales conectadas a una red virtual SDN. Una vez establecida, la máquina virtual no
podrá enviar ni recibir tráfico por encima de los límites máximos configurados. En el
caso de una máquina virtual, puede configurar un límite de envío, un límite del lado de
recepción o ambos.

Las opciones que se pueden configurar a través de QoS de SDN son:

 OutboundReservedValue : si el modo es "absoluto", el valor indica el ancho de
banda, en Mbps, garantizado para el puerto virtual para la transmisión (salida). Si
outboundReservedMode el modo es "weight", el valor indica la parte ponderada del

ancho de banda garantizado.

OutboundMaximumMbps : indica el ancho de banda máximo permitido del lado

de envío, en Mbps, para el puerto virtual (salida).

InboundMaximumMbps : indica el ancho de banda del lado de recepción máximo

permitido para el puerto virtual (entrada) en Mbps.

Directivas de QoS de SDN

Una vez que la controladora de red para SDN está configurado, puede continuar e
implementar las directivas de QoS. En la actualidad, puede hacerlo mediante cmdlets de
PowerShell de controladora de red.

Para todos los scripts de ejemplo que se usan a continuación, -ConnectionUri es el URI
rest de la controladora de red. Por ejemplo: [Link] .

Paso 1: Configuración global de QoS

Ejecute el siguiente comando de PowerShell en un equipo de controladora de red o en
un cliente de administración de Controladora de red. Esto permitirá que la configuración
global configure las directivas de QoS a través de la controladora de red:

PowerShell

$vswitchConfig=
[[Link]]::new()
$qos=[[Link]]::new()
$[Link]=$true
$[Link] =$qos
Set-NetworkControllerVirtualSwitchConfiguration -ConnectionUri $uri -
Properties $vswitchConfig

Paso 2: Configurar directivas de QoS

En primer lugar, deberá identificar la interfaz de red de la máquina virtual de carga de
trabajo en la que desea aplicar la directiva:

PowerShell
 $NwInterface=Get-NetworkControllerNetworkInterface -ConnectionUri $uri -
ResourceId Vnet-VM2_Net_Adapter_0

A continuación, configure el rendimiento máximo de entrada y salida permitido en la

interfaz de red:

PowerShell

$[Link]=
[[Link]]::ne
w()
$[Link] ="1000"
New-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId
$[Link] -Properties $[Link]

Descarga de QoS (opcional)

Puede configurar la NIC física para usar la descarga de QoS. Si el adaptador admite la
descarga de QoS, asegúrese de que está habilitado mediante uno de estos dos
métodos:

ATC de red (recomendado)

Habilitación manual mediante las propiedades del adaptador

Uso de ATC de red

La descarga de QoS se habilita automáticamente en todos los adaptadores con el tipo
Compute de intención. Para más información, consulte Simplificación de las redes de

host con Network ATC.

７ Nota

Esta opción solo está disponible para Azure Stack HCI suscriptores.

Uso de la habilitación manual

La habilitación manual se realiza mediante los cmdlets integrados que se usan para
administrar las propiedades del adaptador físico.

） Importante
 Debe asegurarse de que está QosOffload habilitado en todas las NIC físicas del
equipo en todos los host. Sin esto, la regla de QoS se aplicará a través del
conmutador virtual y dará como resultado una menor eficacia.

Use los siguientes cmdlets para comprobar si los adaptadores admiten QosOffload y, a
continuación, modifique las propiedades del adaptador:

PowerShell

Get-NetAdapterAdvancedProperty -Name <physical NIC Name> -RegistryKeyword

*QosOffload
Enable QosOffload for your adapters:
Set-NetAdapterAdvancedProperty -Name <physical NIC Name> -RegistryKeyword
*QosOffload -RegistryValue 1

Configuración de qos de hardware

Puede configurar la QoS de hardware mediante configuraciones y directivas.

Paso 1: Configuración global de QoS

Realice los pasos siguientes en un equipo de controladora de red o en un cliente de
administración de controladora de red. Esto habilitará la configuración global para
configurar las directivas de QoS a través de la controladora de red.

PowerShell

$vswitchConfig=
[[Link]]::new()
$qos=[[Link]]::new()
$[Link]=$true
$[Link] =$qos
Set-NetworkControllerVirtualSwitchConfiguration -ConnectionUri $uri -
Properties $vswitchConfig

Paso 2: Configuración de directivas de QoS

En primer lugar, identifique la interfaz de red de máquina virtual de carga de trabajo en
la que desea aplicar la directiva:

PowerShell
 $NwInterface=Get-NetworkControllerNetworkInterface -ConnectionUri $uri -
ResourceId Vnet-VM2_Net_Adapter_0

A continuación, configure el rendimiento máximo de salida permitido en la interfaz de

red. En el ejemplo siguiente se crea una regla de QoS que limita el tráfico saliente de
una interfaz de máquina virtual a 1 Gbps.

） Importante

Qos Offload solo admite OutboundMaximumMbps. No puede usar

OutboundReservedValue o InboundMaximumMbps con qos offload.

PowerShell

$[Link]=
[[Link]]::ne
w()
$[Link]. EnableHardwareLimits=$true
$[Link] ="1000"
New-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId
$[Link] -Properties $[Link]

７ Nota

Durante la migración en vivo, es posible que una máquina virtual se mueva a un

host que no admita la descarga de QoS. En este escenario, la migración en vivo se
realizará correctamente, pero QoS se reservará a QoS de SDN.
Configuración de grupos de seguridad
de red con PowerShell
Artículo • 23/01/2023 • Tiempo de lectura: 9 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2; Windows Server 2022,
Windows Server 2019, Windows Server 2016

En este tema se proporcionan instrucciones para configurar grupos de seguridad de red

(NSG) para administrar el flujo de tráfico de datos mediante Datacenter Firewall para
redes definidas por software (SDN) en Azure Stack HCI mediante Windows PowerShell.
Para habilitar y configurar El firewall del centro de datos, cree grupos de seguridad de
red que se apliquen a una subred o a una interfaz de red. En los scripts de ejemplo de
este tema se usan los comandos de Windows PowerShell exportados del módulo
NetworkController. También puede usar Windows Admin Center para configurar y
administrar grupos de seguridad de red.

Configuración del firewall del centro de datos

para permitir todo el tráfico
Una vez que implemente SDN, debe probar la conectividad de red básica en el nuevo
entorno. Para ello, cree una regla para el firewall del centro de datos que permita todo
el tráfico de red, sin restricciones.

Use las entradas de la tabla siguiente para crear un conjunto de reglas que permitan
todo el tráfico de red entrante y saliente.

IP de IP de Protocolo Puerto de Puerto de Dirección Acción Priority

origen destino origen destino

* * All * * Entrada Allow 100

* * All * * Salida Allow 110

En este ejemplo, creará un grupo de seguridad de red con dos reglas:

1. AllowAll_Inbound : permite que todo el tráfico de red pase a la interfaz de red

donde está configurado este grupo de seguridad de red.
2. AllowAllOutbound: permite que todo el tráfico pase fuera de la interfaz de red.
Este grupo de seguridad de red, identificado por el identificador de recurso
"AllowAll-1" ya está listo para usarse en subredes virtuales e interfaces de red.
En primer lugar, conéctese a uno de los nodos del clúster. Para ello, abra una sesión de
PowerShell:

PowerShell

Enter-PSSession <server-name>

A continuación, ejecute el siguiente script para crear el grupo de seguridad de red:

PowerShell

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "*"
$[Link] = "100"
$[Link] = "Inbound"
$[Link] = "Enabled"
$aclrule1 = new-object [Link]
$[Link] = $ruleproperties
$[Link] = "AllowAll_Inbound"
$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "*"
$[Link] = "110"
$[Link] = "Outbound"
$[Link] = "Enabled"
$aclrule2 = new-object [Link]
$[Link] = $ruleproperties
$[Link] = "AllowAll_Outbound"
$acllistproperties = new-object
[Link]
$[Link] = @($aclrule1, $aclrule2)
New-NetworkControllerAccessControlList -ResourceId "AllowAll" -Properties
$acllistproperties -ConnectionUri <NC REST FQDN>

７ Nota

La referencia de comandos de Windows PowerShell para la Controladora de red se

encuentra en el tema Cmdlets de la Controladora de red.
Uso de grupos de seguridad de red para limitar
el tráfico en una subred
En este ejemplo, creará un grupo de seguridad de red que impide que las máquinas
virtuales (VM) dentro de la subred [Link]/24 se comuniquen entre sí. Este tipo de
grupo de seguridad de red es útil para limitar la capacidad de un atacante de distribuir
lateralmente dentro de la subred, a la vez que permite que las máquinas virtuales
reciban solicitudes desde fuera de la subred, así como para comunicarse con otros
servicios en otras subredes.

IP de origen IP de destino Protocolo Puerto Puerto Dirección Acción Priority

de de
origen destino

[Link] * All * * Entrada Allow 100

* [Link] All * * Salida Allow 101

[Link]/24 * All * * Entrada Block 102

* [Link]/24 All * * Salida Block 103

* * All * * Entrada Allow 104

* * All * * Salida Allow 105

El grupo de seguridad de red creado por el script de ejemplo siguiente, identificado por
la subred de identificador de recurso Subnet-192-168-0-0, ahora se puede aplicar a una
subred de red virtual que use la dirección de subred "[Link]/24". Cualquier interfaz
de red conectada a esa subred de red virtual obtiene automáticamente las reglas de
grupo de seguridad de red anteriores aplicadas.

A continuación se muestra un script de ejemplo para crear este grupo de seguridad de

red mediante la API REST de controladora de red:

PowerShell

import-module networkcontroller
$ncURI = "[Link]
$aclrules = @()

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "[Link]"
$[Link] = "*"
$[Link] = "100"
$[Link] = "Inbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "AllowRouter_Inbound"
$aclrules += $aclrule

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "[Link]"
$[Link] = "101"
$[Link] = "Outbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "AllowRouter_Outbound"
$aclrules += $aclrule

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Deny"
$[Link] = "[Link]/24"
$[Link] = "*"
$[Link] = "102"
$[Link] = "Inbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "DenySubnet_Inbound"
$aclrules += $aclrule

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Deny"
$[Link] = "*"
$[Link] = "[Link]/24"
$[Link] = "103"
$[Link] = "Outbound"
 $[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "DenySubnet_Outbound"

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "*"
$[Link] = "104"
$[Link] = "Inbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "AllowAll_Inbound"
$aclrules += $aclrule

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "*"
$[Link] = "105"
$[Link] = "Outbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "AllowAll_Outbound"
$aclrules += $aclrule

$acllistproperties = new-object
[Link]
$[Link] = $aclrules

New-NetworkControllerAccessControlList -ResourceId "Subnet-192-168-0-0" -

Properties $acllistproperties -ConnectionUri $ncURI

Adición de un grupo de seguridad de red a una

interfaz de red
Una vez que haya creado un grupo de seguridad de red y lo haya asignado a una
subred virtual, es posible que desee invalidar ese grupo de seguridad de red
predeterminado en la subred virtual con un grupo de seguridad de red específico para
una interfaz de red individual. A partir de Windows Server 2019 Datacenter, puede
aplicar grupos de seguridad de red específicos directamente a interfaces de red
conectadas a redes lógicas SDN, además de redes virtuales sdN. Si tiene grupos de
seguridad de red establecidos en la subred virtual conectada a la interfaz de red, se
aplican ambos grupos de seguridad de red y se priorizan los grupos de seguridad de
red de la interfaz de red por encima de los grupos de seguridad de red de subred
virtual.

En este ejemplo, se muestra cómo agregar un grupo de seguridad de red a una red
virtual.

 Sugerencia

También es posible agregar un grupo de seguridad de red al mismo tiempo que se

crea la interfaz de red.

1. Obtenga o cree la interfaz de red a la que agregará el grupo de seguridad de red.

PowerShell

$nic = get-networkcontrollernetworkinterface -ConnectionUri $uri -

ResourceId "MyVM_Ethernet1"

2. Obtenga o cree el grupo de seguridad de red que agregará a la interfaz de red.

PowerShell

$acl = get-networkcontrolleraccesscontrollist -ConnectionUri $uri -

ResourceId "AllowAllACL"

3. Asigne el grupo de seguridad de red a la propiedad AccessControlList de la

interfaz de red.

PowerShell

$[Link][0].[Link] =
$acl

4. Agregue la interfaz de red en la Controladora de red.

 PowerShell

new-networkcontrollernetworkinterface -ConnectionUri $uri -Properties

$[Link] -ResourceId $[Link]

Eliminación de un grupo de seguridad de red

de una interfaz de red
En este ejemplo, se muestra cómo quitar un grupo de seguridad de red de una interfaz
de red. Al quitar un grupo de seguridad de red, se aplica el conjunto predeterminado de
reglas a la interfaz de red. El conjunto predeterminado de reglas permite todo el tráfico
saliente, pero bloquea el entrante. Si desea permitir todo el tráfico entrante, debe seguir
el ejemplo anterior para agregar un grupo de seguridad de red que permita todo el
tráfico entrante y saliente.

1. Obtenga la interfaz de red de la que quitará el grupo de seguridad de red.

PowerShell

$nic = get-networkcontrollernetworkinterface -ConnectionUri $uri -

ResourceId "MyVM_Ethernet1"

2. Asigne $null a la propiedad AccessControlList de ipConfiguration.

PowerShell

$[Link][0].[Link] =
$null

3. Agregue el objeto de la interfaz de red en la Controladora de red.

PowerShell

new-networkcontrollernetworkinterface -ConnectionUri $uri -Properties

$[Link] -ResourceId $[Link]

Auditoría de firewall
A partir de Windows Server 2019, la auditoría de firewall es una nueva funcionalidad del
firewall del centro de datos que registra cualquier flujo que procesan las reglas de
firewall de SDN. Se registran todos los grupos de seguridad de red que tienen
habilitado el registro. Los archivos de registro deben estar en una sintaxis coherente con
los registros de flujo de Azure Network Watcher. Estos registros se pueden usar para
realizar diagnósticos o archivar para su posterior análisis.

A continuación se incluye un script de ejemplo para habilitar la auditoría de firewall en

los servidores host. Actualice las variables del principio y ejecútelo en un clúster de
Azure Stack HCI con la Controladora de red implementada:

PowerShell

$logpath = "C:\test\log1"
$servers = @("sa18n22-2", "sa18n22-3", "sa18n22-4")
$uri = "[Link]

# Create log directories on the hosts

invoke-command -Computername $servers {
param(
$Path
)
mkdir $path -force
} -argumentlist $LogPath

# Set firewall auditing settings on Network Controller

$AuditProperties = new-object
[Link]
$[Link] = $logpath
set-networkcontrollerauditingsettingsconfiguration -connectionuri $uri -
properties $AuditProperties -force | out-null

# Enable logging on each server

$servers = get-networkcontrollerserver -connectionuri $uri
foreach ($s in $servers) {
$[Link] = @("Firewall")
new-networkcontrollerserver -connectionuri $uri -resourceid
$[Link] -properties $[Link] -force | out-null
}

Una vez habilitado, aparece un nuevo archivo en el directorio especificado de cada host
aproximadamente una vez por hora. Debe procesar periódicamente estos archivos y
quitarlos de los hosts. El archivo actual tiene una longitud igual a cero y se bloquea
hasta que se vacía en la marca de hora siguiente:

syntax

PS C:\test\log1> dir

Directory: C:\test\log1

Mode LastWriteTime Length Name

---- ------------- ------ ----
-a---- 7/19/2018 6:28 AM 17055
 SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]
-a---- 7/19/2018 7:28 AM 7880
SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]
-a---- 7/19/2018 8:28 AM 7867
SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]
-a---- 7/19/2018 9:28 AM 10949
SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]
-a---- 7/19/2018 9:28 AM 0
SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]

Estos archivos contienen una secuencia de eventos de flujo; por ejemplo:

syntax

{
"records": [
{
"properties":{
"Version":"1.0",
"flows":[
{
"flows":[
{
"flowTuples":
["1531963580,[Link],[Link],138,138,U,I,A"],
"portId":"9",
"portName":"7290436D-0422-498A-8EB8-
C6CF5115DACE"
}
],
"rule":"Allow_Inbound"
}
]
},
"operationName":"NetworkSecurityGroupFlowEvents",
"resourceId":"394f647d-2ed0-4c31-87c5-389b8c0c8132",
"time":"20180719:L012620622",
"category":"NetworkSecurityGroupFlowEvent",
"systemId":"d8b3b697-5355-40e2-84d2-1bf2f0e0dc4a"
},

Tenga en cuenta que el registro solo tiene lugar para las reglas que tienen el valor
Logging definido como Enabled; por ejemplo:

syntax
{
"Tags": null,
"ResourceRef": "/accessControlLists/AllowAll",
"InstanceId": "4a63e1a5-3264-4986-9a59-4e77a8b107fa",
"Etag": "W/\"1535a780-0fc8-4bba-a15a-093ecac9b88b\"",
"ResourceMetadata": null,
"ResourceId": "AllowAll",
"Properties": {
"ConfigurationState": null,
"ProvisioningState": "Succeeded",
"AclRules": [
{
"ResourceMetadata": null,
"ResourceRef":
"/accessControlLists/AllowAll/aclRules/AllowAll_Inbound",
"InstanceId": "ba8710a8-0f01-
422b-9038-d1f2390645d7",
"Etag": "W/\"1535a780-0fc8-
4bba-a15a-093ecac9b88b\"",
"ResourceId":
"AllowAll_Inbound",
"Properties": {
"Protocol":
"All",

"SourcePortRange": "0-65535",

"DestinationPortRange": "0-65535",
"Action":
"Allow",

"SourceAddressPrefix": "*",

"DestinationAddressPrefix": "*",
"Priority":
"101",

"Description": null,
"Type":
"Inbound",
"Logging":
"Enabled",

"ProvisioningState": "Succeeded"
}
},
{
"ResourceMetadata": null,
"ResourceRef":
"/accessControlLists/AllowAll/aclRules/AllowAll_Outbound",
"InstanceId": "068264c6-2186-
4dbc-bbe7-f504c6f47fa8",
"Etag": "W/\"1535a780-0fc8-
4bba-a15a-093ecac9b88b\"",
 "ResourceId":
"AllowAll_Outbound",
"Properties": {
"Protocol":
"All",

"SourcePortRange": "0-65535",

"DestinationPortRange": "0-65535",
"Action":
"Allow",

"SourceAddressPrefix": "*",

"DestinationAddressPrefix": "*",
"Priority":
"110",

"Description": null,
"Type":
"Outbound",
"Logging":
"Enabled",

"ProvisioningState": "Succeeded"
}
}
],
"IpConfigurations": [

],
"Subnets": [
{
"ResourceMetadata": null,
"ResourceRef":
"/virtualNetworks/10_0_1_0/subnets/Subnet1",
"InstanceId": "00000000-0000-
0000-0000-000000000000",
"Etag": null,
"ResourceId": null,
"Properties": null
}
]
}
}

Pasos siguientes
Para obtener información relacionada, consulte:

Introducción al firewall del centro de datos

Introducción a la controladora de red
SDN en Azure Stack HCI y Windows Server
Configuración del equilibrador de carga
de software para el equilibrio de carga y
la traducción de direcciones de red
(NAT)
Artículo • 21/12/2022 • Tiempo de lectura: 7 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Puede usar este tema para aprender a usar el equilibrador de carga de software de
redes definidas por software (SDN) para proporcionar traducción de direcciones de red
salientes (NAT), NAT de entrada o equilibrio de carga entre varias instancias de una
aplicación.

Introducción al software Load Balancer

SdN Software Load Balancer (SLB) ofrece alta disponibilidad y rendimiento de red a las
aplicaciones. Es un equilibrador de carga de nivel 4 (TCP, UDP) que distribuye el tráfico
entrante entre instancias de servicio correctas en servicios en la nube o máquinas
virtuales definidas en un conjunto de equilibrador de carga.

Configure SLB para hacer lo siguiente:

Equilibre la carga del tráfico entrante externo a una red virtual a máquinas virtuales
(VM), también denominada equilibrio de carga de VIP pública.
Equilibrio de carga del tráfico entrante entre máquinas virtuales de una red virtual,
entre máquinas virtuales en servicios en la nube o entre equipos locales y
máquinas virtuales en una red virtual entre locales.
Reenvíe el tráfico de red de la máquina virtual desde la red virtual a destinos
externos mediante la traducción de direcciones de red (NAT), también denominada
NAT de salida.
Reenvíe el tráfico externo a una máquina virtual específica, también denominada
NAT de entrada.

Ejemplo: Creación de una vip pública para

equilibrar la carga de un grupo de dos
máquinas virtuales en una red virtual
En este ejemplo, creará un objeto de equilibrador de carga con una VIP pública y dos
máquinas virtuales como miembros del grupo para atender solicitudes a la VIP. Este
código de ejemplo también agrega un sondeo de estado HTTP para detectar si uno de
los miembros del grupo deja de responder.

1. Prepare el objeto del equilibrador de carga.

PowerShell

import-module NetworkController

$URI = "[Link]

$LBResourceId = "LB2"

$LoadBalancerProperties = new-object
[Link]

2. Asigne una dirección IP de front-end, denominada normalmente ip virtual (VIP).

La dirección IP virtual debe ser de una dirección IP sin usar en uno de los grupos
de direcciones IP de red lógicas que se proporcionan al administrador del
equilibrador de carga.

PowerShell

$VIPIP = "[Link]"
$VIPLogicalNetwork = get-networkcontrollerlogicalnetwork -
ConnectionUri $uri -resourceid "PublicVIP" -PassInnerException

$FrontEndIPConfig = new-object
[Link]
$[Link] = "FE1"
$[Link] =
"/loadBalancers/$LBResourceId/frontendIPConfigurations/$($FrontEndIPCon
[Link])"

$[Link] = new-object
[Link]
Properties
$[Link] = new-object
[Link]
$[Link] =
$[Link][0].ResourceRef
$[Link] = $VIPIP
$[Link] = "Static"

$[Link] += $FrontEndIPConfig
3. Asigne un grupo de direcciones de back-end, que contiene las direcciones IP
dinámicas (DIP) que componen los miembros del conjunto de máquinas virtuales
con equilibrio de carga.

PowerShell

$BackEndAddressPool = new-object
[Link]
$[Link] = "BE1"
$[Link] =
"/loadBalancers/$LBResourceId/backendAddressPools/$($BackEndAddressPool
.ResourceId)"

$[Link] = new-object
[Link]
rties

$[Link] += $BackEndAddressPool

4. Defina un sondeo de estado que usa el equilibrador de carga para determinar el

estado de mantenimiento de los miembros del grupo de back-end.

En este ejemplo, se define un sondeo HTTP que consulta a RequestPath de

"/[Link]". La consulta se ejecuta cada 5 segundos, según lo especificado por la
propiedad IntervalInSeconds.

El sondeo de estado debe recibir un código de respuesta HTTP de 200 para 11

consultas consecutivas para que el sondeo considere que la dirección IP de back-
end es correcta. Si la dirección IP de back-end no está en buen estado, no recibe
tráfico del equilibrador de carga.

） Importante

No bloquee el tráfico hacia o desde la primera dirección IP de la subred para

las listas (ACL) de Access Control que aplique a la dirección IP de back-end
porque ese es el punto de origen de los sondeos.

Use el ejemplo siguiente para definir un sondeo de estado.

PowerShell

$Probe = new-object
[Link]
$[Link] = "Probe1"
$[Link] =
 "/loadBalancers/$LBResourceId/Probes/$($[Link])"

$[Link] = new-object
[Link]
$[Link] = "HTTP"
$[Link] = "80"
$[Link] = "/[Link]"
$[Link] = 5
$[Link] = 11

$[Link] += $Probe

5. Defina una regla de equilibrio de carga para enviar tráfico que llegue a la dirección
IP de front-end a la dirección IP de back-end. En este ejemplo, el grupo de back-
end recibe tráfico TCP al puerto 80.

Use el ejemplo siguiente para definir una regla de equilibrio de carga:

PowerShell

$Rule = new-object
[Link]
$[Link] = "webserver1"

$[Link] = new-object
[Link]
$[Link] += $FrontEndIPConfig
$[Link] = $BackEndAddressPool
$[Link] = "TCP"
$[Link] = 80
$[Link] = 80
$[Link] = 4
$[Link] = $Probe

$[Link] += $Rule

6. Agregue la configuración del equilibrador de carga a Controladora de red.

Use el ejemplo siguiente para agregar la configuración del equilibrador de carga a

Controladora de red:

PowerShell

$LoadBalancerResource = New-NetworkControllerLoadBalancer -
ConnectionUri $URI -ResourceId $LBResourceId -Properties
$LoadBalancerProperties -Force -PassInnerException

7. Siga el ejemplo siguiente para agregar las interfaces de red a este grupo de back-
end.
Ejemplo: Uso de SLB para NAT de salida
En este ejemplo, configurará el SLB con un grupo de back-end para proporcionar la
funcionalidad NAT de salida para una máquina virtual en el espacio de direcciones
privadas de una red virtual para llegar a Internet.

1. Cree las propiedades del equilibrador de carga, la dirección IP de front-end y el

grupo de back-end.

PowerShell

import-module NetworkController
$URI = "[Link]

$LBResourceId = "OutboundNATMMembers"
$VIPIP = "[Link]"

$VIPLogicalNetwork = get-networkcontrollerlogicalnetwork -
ConnectionUri $uri -resourceid "PublicVIP" -PassInnerException

$LoadBalancerProperties = new-object
[Link]

$FrontEndIPConfig = new-object
[Link]
$[Link] = "FE1"
$[Link] =
"/loadBalancers/$LBResourceId/frontendIPConfigurations/$($FrontEndIPCon
[Link])"

$[Link] = new-object
[Link]
Properties
$[Link] = new-object
[Link]
$[Link] =
$[Link][0].ResourceRef
$[Link] = $VIPIP
$[Link] = "Static"

$[Link] += $FrontEndIPConfig

$BackEndAddressPool = new-object
[Link]
$[Link] = "BE1"
$[Link] =
"/loadBalancers/$LBResourceId/backendAddressPools/$($BackEndAddressPool
.ResourceId)"
$[Link] = new-object
[Link]
rties
 $[Link] += $BackEndAddressPool

2. Defina la regla NAT de salida.

PowerShell

$OutboundNAT = new-object
[Link]
$[Link] = "onat1"

$[Link] = new-object
[Link]
es
$[Link] += $FrontEndIPConfig
$[Link] = $BackEndAddressPool
$[Link] = "ALL"

$[Link] += $OutboundNAT

3. Agregue el objeto del equilibrador de carga en Controladora de red.

PowerShell

$LoadBalancerResource = New-NetworkControllerLoadBalancer -
ConnectionUri $URI -ResourceId $LBResourceId -Properties
$LoadBalancerProperties -Force -PassInnerException

4. Siga el ejemplo siguiente para agregar las interfaces de red a las que desea
proporcionar acceso a Internet.

Ejemplo: Adición de interfaces de red al grupo

de back-end
En este ejemplo, agregará interfaces de red al grupo de back-end. Debe repetir este
paso para cada interfaz de red que pueda procesar las solicitudes realizadas a la
DIRECCIÓN VIP.

También puede repetir este proceso en una sola interfaz de red para agregarlo a varios
objetos del equilibrador de carga. Por ejemplo, si tiene un objeto de equilibrador de
carga para una VIP de servidor web y un objeto de equilibrador de carga independiente
para proporcionar NAT de salida.

1. Obtenga el objeto del equilibrador de carga que contiene el grupo de back-end

para agregar una interfaz de red.
 PowerShell

$lbresourceid = "LB2"
$lb = get-networkcontrollerloadbalancer -connectionuri $uri -resourceID
$LBResourceId -PassInnerException

2. Obtenga la interfaz de red y agregue el grupo backendaddress a la matriz

loadbalancerbackendaddresspools.

PowerShell

$nic = get-networkcontrollernetworkinterface -connectionuri $uri -

resourceid 6daca142-7d94-0000-1111-c38c0141be06 -PassInnerException
$[Link][0].[Link]
ssPools += $[Link][0]

3. Coloque la interfaz de red para aplicar el cambio.

PowerShell

new-networkcontrollernetworkinterface -connectionuri $uri -resourceid

6daca142-7d94-0000-1111-c38c0141be06 -properties $[Link] -force
-PassInnerException

Ejemplo: Usar el Load Balancer de software

para reenviar el tráfico
Si necesita asignar una dirección IP virtual a una única interfaz de red en una red virtual
sin definir puertos individuales, puede crear una regla de reenvío L3. Esta regla reenvía
todo el tráfico hacia y desde la máquina virtual a través de la VIP asignada contenida en
un objeto PublicIPAddress.

Si definió la VIP y dip como la misma subred, esto equivale a realizar el reenvío L3 sin
NAT.

７ Nota

Este proceso no requiere que cree un objeto de equilibrador de carga. La

asignación de PublicIPAddress a la interfaz de red es suficiente información para
que el Load Balancer de software realice su configuración.

1. Cree un objeto de dirección IP pública para que contenga la dirección VIP.

 PowerShell

$publicIPProperties = new-object
[Link]
$[Link] = "[Link]"
$[Link] = "static"
$[Link] = 4
$publicIP = New-NetworkControllerPublicIpAddress -ResourceId "MyPIP" -
Properties $publicIPProperties -ConnectionUri $uri -Force -
PassInnerException

2. Asigne PublicIPAddress a una interfaz de red.

PowerShell

$nic = get-networkcontrollernetworkinterface -connectionuri $uri -

resourceid 6daca142-7d94-0000-1111-c38c0141be06
$[Link][0].[Link] =
$publicIP
New-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId
$[Link] -Properties $[Link] -PassInnerException

Ejemplo: Usar el Load Balancer de software

para reenviar el tráfico con una VIP asignada
dinámicamente
En este ejemplo se repite la misma acción que en el ejemplo anterior, pero asigna
automáticamente la dirección VIP del grupo disponible de VIP en el equilibrador de
carga en lugar de especificar una dirección IP específica.

1. Cree un objeto de dirección IP pública para que contenga la dirección VIP.

PowerShell

$publicIPProperties = new-object
[Link]
$[Link] = "dynamic"
$[Link] = 4
$publicIP = New-NetworkControllerPublicIpAddress -ResourceId "MyPIP" -
Properties $publicIPProperties -ConnectionUri $uri -Force -
PassInnerException

2. Consulte el recurso PublicIPAddress para determinar qué dirección IP se asignó.

PowerShell
 (Get-NetworkControllerPublicIpAddress -ConnectionUri $uri -ResourceId
"MyPIP").properties

La propiedad IpAddress contiene la dirección asignada. El resultado será similar al

siguiente:

Counters : {}
ConfigurationState :
IpAddress : [Link]
PublicIPAddressVersion : IPv4
PublicIPAllocationMethod : Dynamic
IdleTimeoutInMinutes : 4
DnsSettings :
ProvisioningState : Succeeded
IpConfiguration :
PreviousIpConfiguration :

3. Asigne PublicIPAddress a una interfaz de red.

PowerShell

$nic = get-networkcontrollernetworkinterface -connectionuri $uri -

resourceid 6daca142-7d94-0000-1111-c38c0141be06
$[Link][0].[Link] =
$publicIP
New-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId
$[Link] -Properties $[Link] -PassInnerException

Ejemplo: Quitar una dirección PublicIP que

se usa para reenviar el tráfico y devolverla al
grupo de VIP
En este ejemplo se quita el recurso PublicIPAddress creado por los ejemplos
anteriores. Una vez quitado PublicIPAddress, la referencia a PublicIPAddress se
quitará automáticamente de la interfaz de red, el tráfico dejará de reenviarse y la
dirección IP se devolverá al grupo de VIP públicas para volver a usarse.

4. Eliminación de PublicIP

PowerShell
Remove-NetworkControllerPublicIPAddress -ConnectionURI $uri -ResourceId
"MyPIP"
Uso de dispositivos virtuales de red en
una red virtual
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En este tema, aprenderá a implementar aplicaciones virtuales de red en redes virtuales

de inquilino. Puede agregar aplicaciones virtuales de red a redes que realizan funciones
de enrutamiento y creación de reflejo de puertos definidas por el usuario.

Tipos de aplicaciones virtuales de red

Puede usar uno de los dos tipos de aplicaciones virtuales:

1. Enrutamiento definido por el usuario : reemplaza los enrutadores distribuidos de

la red virtual por las funcionalidades de enrutamiento de la aplicación virtual. Con
el enrutamiento definido por el usuario, la aplicación virtual se usa como un
enrutador entre las subredes virtuales de la red virtual.

2. Creación de reflejo del puerto: todo el tráfico de red que entra o sale del puerto
supervisado se duplica y se envía a una aplicación virtual para su análisis.

Implementación de una aplicación virtual de

red
Para implementar una aplicación virtual de red, primero debe crear una máquina virtual
que contenga el dispositivo y, a continuación, conectar la máquina virtual a las subredes
de red virtual adecuadas. Para más información, consulte Creación de una máquina
virtual de inquilino y Conectar a un inquilino Virtual Network o VLAN.

Algunos dispositivos requieren varios adaptadores de red virtual. Normalmente, un

adaptador de red dedicado a la administración del dispositivo mientras que otros
adaptadores procesan el tráfico. Si el dispositivo requiere varios adaptadores de red,
debe crear cada interfaz de red en controladora de red. También debe asignar un
identificador de interfaz en cada host para cada uno de los adaptadores adicionales que
se encuentran en subredes virtuales diferentes.
Una vez que haya implementado la aplicación virtual de red, puede usar el dispositivo
para el enrutamiento definido, portar la creación de reflejos o ambos.

Ejemplo: enrutamiento definido por el usuario

Para la mayoría de los entornos, solo necesita las rutas del sistema ya definidas por el
enrutador distribuido de la red virtual. Sin embargo, es posible que tenga que crear una
tabla de enrutamiento y agregar una o varias rutas en casos específicos, como:

Tunelización forzada a Internet a través de la red local.

Uso de aplicaciones virtuales en su entorno.

En estos escenarios, debe crear una tabla de enrutamiento y agregar rutas definidas por
el usuario a la tabla. Puede tener varias tablas de enrutamiento y puede asociar la
misma tabla de enrutamiento a una o varias subredes. Solo puede asociar cada subred a
una sola tabla de enrutamiento. Todas las máquinas virtuales de una subred usan la
tabla de enrutamiento asociada a la subred.

Las subredes se basan en las rutas del sistema hasta que se asocia una tabla de
enrutamiento a la subred. Una vez que existe una asociación, el enrutamiento se realiza
en función de la coincidencia de prefijo más larga (LPM) entre las rutas definidas por el
usuario y las rutas del sistema. Si hay más de una ruta con la misma coincidencia de
LPM, primero se selecciona la ruta definida por el usuario antes de la ruta del sistema.

Procedimiento:

1. Cree las propiedades de la tabla de rutas, que contiene todas las rutas definidas
por el usuario.

Las rutas del sistema se siguen aplicando según las reglas definidas anteriormente.

PowerShell

$routetableproperties = new-object
[Link]

2. Agregue una ruta a las propiedades de la tabla de enrutamiento.

Cualquier ruta destinada a la subred [Link]/8 se enruta a la aplicación virtual en

[Link]. El dispositivo debe tener un adaptador de red virtual conectado a la
red virtual con esa dirección IP asignada a una interfaz de red.

PowerShell
 $route = new-object [Link]
$[Link] = "0_0_0_0_0"
$[Link] = new-object
[Link]
$[Link] = "[Link]/0"
$[Link] = "VirtualAppliance"
$[Link] = "[Link]"
$[Link] += $route

 Sugerencia

Si desea agregar más rutas, repita este paso para cada ruta que quiera definir.

3. Agregue la tabla de enrutamiento a Controladora de red.

PowerShell

$routetable = New-NetworkControllerRouteTable -ConnectionUri $uri -

ResourceId "Route1" -Properties $routetableproperties

4. Aplique la tabla de enrutamiento a la subred virtual.

Al aplicar la tabla de rutas a la subred virtual, la primera subred virtual de la red

Tenant1_Vnet1 usa la tabla de rutas. Puede asignar la tabla de rutas a tantas
subredes de la red virtual como desee.

PowerShell

$vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -

ResourceId "Tenant1_VNet1"
$[Link][0].[Link] = $routetable
new-networkcontrollervirtualnetwork -connectionuri $uri -properties
$[Link] -resourceId $[Link]

En cuanto aplique la tabla de enrutamiento a la red virtual, el tráfico se reenvía a la

aplicación virtual. Debe configurar la tabla de enrutamiento en la aplicación virtual para
reenviar el tráfico de una manera adecuada para su entorno.

Ejemplo: Creación de reflejo del puerto

En este ejemplo, configurará el tráfico de MyVM_Ethernet1 para reflejar
Appliance_Ethernet1. Se supone que ha implementado dos máquinas virtuales, una
como el dispositivo y la otra como la máquina virtual que se va a supervisar con la
creación de reflejo.

El dispositivo debe tener una segunda interfaz de red para la administración. Después
de habilitar la creación de reflejo como destino en Appliciance_Ethernet1, ya no recibe
tráfico destinado a la interfaz IP configurada allí.

Procedimiento:

1. Obtenga la red virtual en la que se encuentran las máquinas virtuales.

PowerShell

$vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -

ResourceId "Tenant1_VNet1"

2. Obtenga las interfaces de red de controladora de red para el origen y el destino de

la creación de reflejo.

PowerShell

$dstNic = get-networkcontrollernetworkinterface -ConnectionUri $uri -

ResourceId "Appliance_Ethernet1"
$srcNic = get-networkcontrollernetworkinterface -ConnectionUri $uri -
ResourceId "MyVM_Ethernet1"

3. Cree un objeto serviceinsertionproperties para contener las reglas de creación de

reflejo del puerto y el elemento que representa la interfaz de destino.

PowerShell

$portmirror =
[[Link]]::new()
$[Link] = 1

4. Cree un objeto serviceinsertionrules para que contenga las reglas que deben
coincidir para que el tráfico se envíe al dispositivo.

Las reglas definidas a continuación coinciden con todo el tráfico, tanto entrante
como saliente, que representa un reflejo tradicional. Puede ajustar estas reglas si
está interesado en crear reflejo de un puerto específico o de origen o destinos
específicos.

PowerShell
 $[Link] =
[[Link][]]::new(1)

$[Link][0] =
[[Link]]::new()
$[Link][0].ResourceId = "Rule1"
$[Link][0].Properties =
[[Link]]::n
ew()

$[Link][0].[Link] = "Port
Mirror Rule"
$[Link][0].[Link] = "All"
$[Link][0].[Link] =
"0"
$[Link][0].[Link] =
"65535"
$[Link][0].[Link]
rt = "0"
$[Link][0].[Link]
= "65535"
$[Link][0].[Link] = "*"
$[Link][0].[Link] =
"*"

5. Cree un objeto serviceinsertionelements para que contenga la interfaz de red del

dispositivo reflejado.

PowerShell

$[Link] =
[[Link][]]::new(1)

$[Link][0] =
[[Link]]::new()
$[Link][0].ResourceId = "Element1"
$[Link][0].Properties =
[[Link]]
::new()

$[Link][0].[Link] = "Port
Mirror Element"
$[Link][0].[Link] =
$dstNic
$[Link][0].[Link] = 1

6. Agregue el objeto de inserción de servicio en Controladora de red.

Al emitir este comando, se detiene todo el tráfico a la interfaz de red del

dispositivo especificada en el paso anterior.
 PowerShell

$portMirror = New-NetworkControllerServiceInsertion -ConnectionUri $uri

-Properties $portmirror -ResourceId "MirrorAll"

7. Actualice la interfaz de red del origen que se va a reflejar.

PowerShell

$[Link][0].[Link] =
$portMirror
$srcNic = New-NetworkControllerNetworkInterface -ConnectionUri $uri -
Properties $[Link] -ResourceId $[Link]

Después de completar estos pasos, la interfaz Appliance_Ethernet1 refleja el tráfico de la

interfaz MyVM_Ethernet1.
Clústeres invitados en una red virtual
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Las máquinas virtuales conectadas a una red virtual solo pueden usar las direcciones IP
que la controladora de red ha asignado para comunicarse en la red. Las tecnologías de
agrupación en clústeres que requieren una dirección IP flotante, como los clústeres de
conmutación por error de Microsoft, requieren algunos pasos adicionales para funcionar
correctamente.

El método para hacer que la dirección IP flotante sea accesible es usar una dirección IP
virtual (VIP) de software Load Balancer (SLB). El equilibrador de carga de software debe
configurarse con un sondeo de estado en un puerto de esa dirección IP para que SLB
dirija el tráfico a la máquina que tiene esa dirección IP.

Ejemplo: Configuración del equilibrador de

carga
En este ejemplo se supone que ya ha creado las máquinas virtuales que se convertirán
en nodos de clúster y las ha asociado a un Virtual Network. Para obtener instrucciones,
consulte Creación de una máquina virtual y Conectar a un inquilino Virtual Network o
VLAN.

En este ejemplo, creará una dirección IP virtual ([Link]) para representar la

dirección IP flotante del clúster y configurará un sondeo de estado para supervisar el
puerto TCP 59999 para determinar qué nodo es el activo.

1. Seleccione la dirección VIP.

Prepare asignando una dirección IP VIP, que puede ser cualquier dirección
reservada o sin usar en la misma subred que los nodos del clúster. La dirección VIP
debe coincidir con la dirección flotante del clúster.

PowerShell

$VIP = "[Link]"
$subnet = "Subnet2"
$VirtualNetwork = "MyNetwork"
$ResourceId = "MyNetwork_InternalVIP"
2. Cree el objeto de propiedades del equilibrador de carga.

PowerShell

$LoadBalancerProperties = new-object
[Link]

3. Cree una dirección IP de front-end.

PowerShell

$[Link] += $FrontEnd = new-

object
[Link]
$[Link] = new-object
[Link]
Properties
$[Link] = "Frontend1"
$[Link] =
"/loadBalancers/$ResourceId/frontendIPConfigurations/$($[Link]
ceId)"
$[Link] = new-object
[Link]
$[Link] =
"/VirtualNetworks/MyNetwork/Subnets/Subnet2"
$[Link] = $VIP
$[Link] = "Static"

4. Cree un grupo de back-end para que contenga los nodos del clúster.

PowerShell

$BackEnd = new-object
[Link]
$[Link] = new-object
[Link]
rties
$[Link] = "Backend1"
$[Link] =
"/loadBalancers/$ResourceId/backendAddressPools/$($[Link])"
$[Link] += $BackEnd

5. Agregue un sondeo para detectar en qué nodo de clúster está activa la dirección
flotante.

７ Nota
 La consulta de sondeo en la dirección permanente de la máquina virtual en el
puerto definido a continuación. El puerto solo debe responder en el nodo
activo.

PowerShell

$[Link] += $lbprobe = new-object

[Link]
$[Link] = new-object
[Link]

$[Link] = "Probe1"
$[Link] =
"/loadBalancers/$ResourceId/Probes/$($[Link])"
$[Link] = "TCP"
$[Link] = "59999"
$[Link] = 5
$[Link] = 11

6. Agregue las reglas de equilibrio de carga para el puerto TCP 1433.

Puede modificar el protocolo y el puerto según sea necesario. También puede

repetir este paso varias veces para otros puertos y protocolos en esta VIP. Es
importante que EnableFloatingIP esté establecido en $true porque esto indica al
equilibrador de carga que envíe el paquete al nodo con la DIRECCIÓN VIP original
en su lugar.

PowerShell

$[Link] += $lbrule = new-object

[Link]
$[Link] = new-object
[Link]
$[Link] = "Rules1"

$[Link] += $FrontEnd
$[Link] = $BackEnd
$[Link] = "TCP"
$[Link] = $[Link] = 1433
$[Link] = 4
$[Link] = $true
$[Link] = $lbprobe

7. Cree el equilibrador de carga en controladora de red.

PowerShell
 $lb = New-NetworkControllerLoadBalancer -ConnectionUri $URI -ResourceId
$ResourceId -Properties $LoadBalancerProperties -Force

8. Agregue los nodos de clúster al grupo de back-end.

Puede agregar tantos nodos al grupo como necesite para el clúster.

PowerShell

# Cluster Node 1

$nic = get-networkcontrollernetworkinterface -connectionuri $uri -

resourceid "ClusterNode1_Network-Adapter"
$[Link][0].[Link]
ssPools += $[Link][0]
$nic = new-networkcontrollernetworkinterface -connectionuri $uri -
resourceid $[Link] -properties $[Link] -force

# Cluster Node 2

$nic = get-networkcontrollernetworkinterface -connectionuri $uri -

resourceid "ClusterNode2_Network-Adapter"
$[Link][0].[Link]
ssPools += $[Link][0]
$nic = new-networkcontrollernetworkinterface -connectionuri $uri -
resourceid $[Link] -properties $[Link] -force

Una vez que haya creado el equilibrador de carga y agregado las interfaces de red
al grupo de back-end, estará listo para configurar el clúster.

9. (Opcional) Si usa un clúster de conmutación por error de Microsoft, continúe con

el ejemplo siguiente.

Ejemplo 2: Configuración de un clúster de

conmutación por error de Microsoft
Puede usar los pasos siguientes para configurar un clúster de conmutación por error.

1. Instale y configure las propiedades de un clúster de conmutación por error.

PowerShell

add-windowsfeature failover-clustering -IncludeManagementTools

Import-module failoverclusters

$ClusterName = "MyCluster"
 $ClusterNetworkName = "Cluster Network 1"
$IPResourceName =
$ILBIP = "[Link]"

$nodes = @("DB1", "DB2")

2. Cree el clúster en un nodo.

PowerShell

New-Cluster -Name $ClusterName -NoStorage -Node $nodes[0]

3. Detenga el recurso del clúster.

PowerShell

Stop-ClusterResource "Cluster Name"

4. Establezca la dirección IP del clúster y el puerto de sondeo.

La dirección IP debe coincidir con la dirección IP de front-end usada en el ejemplo

anterior y el puerto de sondeo debe coincidir con el puerto de sondeo en el
ejemplo anterior.

PowerShell

Get-ClusterResource "Cluster IP Address" | Set-ClusterParameter -

Multiple
@{"Address"="$ILBIP";"ProbePort"="59999";"SubnetMask"="[Link]"
;"Network"="$ClusterNetworkName";"EnableDhcp"=0}

5. Inicie los recursos del clúster.

PowerShell

Start-ClusterResource "Cluster IP Address" -Wait 60

Start-ClusterResource "Cluster Name" -Wait 60

6. Agregue los nodos restantes.

PowerShell

Add-ClusterNode $nodes[1]
El clúster está activo. El tráfico que va a la VIP en el puerto especificado se dirige al
nodo activo.
Actualización, copia de seguridad y
restauración de la infraestructura de
SDN
Artículo • 21/12/2022 • Tiempo de lectura: 8 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En este tema, aprenderá a actualizar, realizar copias de seguridad y restaurar una

infraestructura de SDN.

Actualización de la infraestructura de SDN

La infraestructura de SDN se puede actualizar de Windows Server 2016 a Windows
Server 2019. Para el orden de actualización, siga la misma secuencia de pasos que se
mencionó en la sección "Actualizar la infraestructura de SDN". Antes de la actualización,
se recomienda realizar una copia de seguridad de la base de datos de controladora de
red.

En el caso de las máquinas de controladora de red, use el cmdlet Get-

NetworkControllerNode para comprobar el estado del nodo una vez completada la
actualización. Asegúrese de que el nodo vuelve al estado "Up" antes de actualizar los
demás nodos. Una vez que haya actualizado todos los nodos de controladora de red, la
controladora de red actualiza los microservicios que se ejecutan en el clúster de
controladora de red en un plazo de una hora. Puede desencadenar una actualización
inmediata mediante el cmdlet update-networkcontroller.

Instale la misma Windows actualizaciones en todos los componentes del sistema

operativo del sistema operativo del sistema de redes definidas por software (SDN), que
incluye:

Hosts de Hyper-V habilitados para SDN

Máquinas virtuales de controladora de red
Máquinas virtuales mux de Load Balancer de software
Máquinas virtuales de puerta de enlace ras

） Importante
 Si usa System Center Virtual Manager, debe actualizarlo con los paquetes
acumulativos de actualizaciones más recientes.

Al actualizar cada componente, puede usar cualquiera de los métodos estándar para
instalar Windows actualizaciones. Sin embargo, para garantizar un tiempo de inactividad
mínimo para las cargas de trabajo y la integridad de la base de datos de controladora
de red, siga estos pasos:

1. Actualice las consolas de administración.

Instale las actualizaciones en cada uno de los equipos en los que use el módulo de
PowerShell de controladora de red. Incluir en cualquier lugar en el que tenga
instalado el rol de RSAT-NetworkController por sí mismo. Excluyendo las propias
máquinas virtuales de controladora de red; los actualizará en el paso siguiente.

2. En la primera máquina virtual de controladora de red, instale todas las

actualizaciones y reinicie.

3. Antes de continuar con la siguiente máquina virtual de controladora de red, use el

get-networkcontrollernode cmdlet para comprobar el estado del nodo que ha

actualizado y reiniciado.

4. Durante el ciclo de reinicio, espere a que el nodo Controladora de red deje de

funcionar y vuelva a volver a subir.

Después de reiniciar la máquina virtual, puede tardar varios minutos antes de

volver al estado Activo . Para obtener un ejemplo de la salida, consulte

5. Instale las actualizaciones en cada máquina virtual de SLB Mux de uno en uno para
garantizar la disponibilidad continua de la infraestructura del equilibrador de
carga.

6. Actualice los hosts de Hyper-V y las puertas de enlace ras, empezando por los
hosts que contienen las puertas de enlace ras que están en modo en espera .

Las máquinas virtuales de puerta de enlace ras no se pueden migrar en vivo sin
perder las conexiones de inquilino. Durante el ciclo de actualización, debe tener
cuidado de minimizar el número de veces que las conexiones de inquilino
conmutan por error a una nueva puerta de enlace ras. Al coordinar la actualización
de hosts y puertas de enlace ras, cada inquilino conmuta por error una vez, como
máximo.

a. Evacue el host de máquinas virtuales que son capaces de migrar en vivo.

 Las máquinas virtuales de puerta de enlace ras deben permanecer en el host.

b. Instale actualizaciones en cada máquina virtual de puerta de enlace en este host.

c. Si la actualización requiere que la máquina virtual de puerta de enlace se reinicie,

reinicie la máquina virtual.

d. Instale las actualizaciones en el host que contiene la máquina virtual de puerta

de enlace que se acaba de actualizar.

e. Reinicie el host si es necesario para las actualizaciones.

f. Repita para cada host adicional que contenga una puerta de enlace en espera.

Si no quedan puertas de enlace en espera, siga estos mismos pasos para todos los
hosts restantes.

Ejemplo: Uso del cmdlet get-networkcontrollernode

En este ejemplo, verá la salida del get-networkcontrollernode cmdlet ejecutado desde
una de las máquinas virtuales de controladora de red.

El estado de los nodos que ve en la salida de ejemplo es:

[Link] = Abajo
[Link] = Arriba
[Link] = Arriba

） Importante

Debe esperar varios minutos hasta que el estado del nodo cambie a Up antes de
actualizar los nodos adicionales, de uno en uno.

Una vez que haya actualizado todos los nodos de controladora de red, la controladora
de red actualiza los microservicios que se ejecutan en el clúster de controladora de red
en un plazo de una hora.

 Sugerencia

Puede desencadenar una actualización inmediata mediante el update-

networkcontroller cmdlet .

PowerShell
 PS C:\> get-networkcontrollernode
Name : [Link]
Server : [Link]
FaultDomain : fd:/[Link]
RestInterface : Ethernet
NodeCertificate :
Status : Down

Name : [Link]
Server : [Link]
FaultDomain : fd:/ [Link]
RestInterface : Ethernet
NodeCertificate :
Status : Up

Name : [Link]
Server : [Link]
FaultDomain : fd:/ [Link]
RestInterface : Ethernet
NodeCertificate :
Status : Up

Ejemplo: Uso del cmdlet update-networkcontroller

En este ejemplo, verá la salida del update-networkcontroller cmdlet para forzar la
actualización de la controladora de red.

） Importante

Ejecute este cmdlet cuando no tenga más actualizaciones para instalar.

PowerShell

PS C:\> update-networkcontroller
NetworkControllerClusterVersion NetworkControllerVersion
------------------------------- ------------------------
10.1.1 10.1.15

Copia de seguridad de la infraestructura de

SDN
Las copias de seguridad periódicas de la base de datos de controladora de red
garantizan la continuidad empresarial en caso de desastre o pérdida de datos. La copia
de seguridad de las máquinas virtuales de controladora de red no es suficiente porque
no garantiza que la sesión continúe en varios nodos de controladora de red.

Requisitos:

Un recurso compartido de SMB y credenciales con permisos de lectura y escritura

para el recurso compartido y el sistema de archivos.
Opcionalmente, puede usar una cuenta de servicio administrada de grupo (GMSA)
si la controladora de red también se instaló mediante una GMSA.

Procedimiento:

1. Use el método de copia de seguridad de la máquina virtual que prefiera o use

Hyper-V para exportar una copia de cada máquina virtual de controladora de red.

La copia de seguridad de la máquina virtual de controladora de red garantiza que

los certificados necesarios para descifrar la base de datos están presentes.

2. Si usa System Center Virtual Machine Manager (SCVMM), detenga el servicio

SCVMM y haga una copia de seguridad a través de SQL Server.

El objetivo aquí es asegurarse de que no se realicen actualizaciones en SCVMM

durante este tiempo, lo que podría crear una incoherencia entre la copia de
seguridad de controladora de red y SCVMM.

） Importante

No vuelva a iniciar el servicio SCVMM hasta que se complete la copia de

seguridad de la controladora de red.

3. Haga una copia de seguridad de la base de datos de controladora de red con el

new-networkcontrollerbackup cmdlet .

4. Compruebe la finalización y el éxito de la copia de seguridad con el get-

networkcontrollerbackup cmdlet .

5. Si usa SCVMM, inicie el servicio SCVMM.

Ejemplo: Copia de seguridad de la base de datos de

controladora de red
PowerShell
 $URI = "[Link]
$Credential = Get-Credential

# Get or Create Credential object for File share user

$ShareUserResourceId = "BackupUser"

$ShareCredential = Get-NetworkControllerCredential -ConnectionURI $URI -

Credential $Credential | Where {$_.ResourceId -eq $ShareUserResourceId }
If ($ShareCredential -eq $null) {
$CredentialProperties = New-Object
[Link]
$[Link] = "usernamePassword"
$[Link] = "contoso\alyoung"
$[Link] = "<Password>"

$ShareCredential = New-NetworkControllerCredential -ConnectionURI $URI -

Credential $Credential -Properties $CredentialProperties -ResourceId
$ShareUserResourceId -Force
}

# Create backup

$BackupTime = (get-date).ToString("s").Replace(":", "_")

$BackupProperties = New-Object
[Link]
$[Link] =
"\\fileshare\backups\NetworkController\$BackupTime"
$[Link] = $ShareCredential

$Backup = New-NetworkControllerBackup -ConnectionURI $URI -Credential

$Credential -Properties $BackupProperties -ResourceId $BackupTime -Force

Ejemplo: Comprobación del estado de una operación de

copia de seguridad de controladora de red
PowerShell

PS C:\ > Get-NetworkControllerBackup -ConnectionUri $URI -Credential

$Credential -ResourceId $[Link]
| ConvertTo-JSON -Depth 10
{
"Tags": null,
"ResourceRef": "/networkControllerBackup/2017-04-25T16_53_13",
"InstanceId": "c3ea75ae-2892-4e10-b26c-a2243b755dc8",
"Etag": "W/\"0dafea6c-39db-401b-bda5-d2885ded470e\"",
"ResourceMetadata": null,
"ResourceId": "2017-04-25T16_53_13",
"Properties": {
"BackupPath":
"\\\\fileshare\backups\NetworkController\\2017-04-25T16_53_13",
"ErrorMessage": "",
"FailedResourcesList": [

],
"SuccessfulResourcesList": [

"/networking/v1/credentials/11ebfc10-438c-4a96-a1ee-8a048ce675be",

"/networking/v1/credentials/41229069-85d4-4352-be85-034d0c5f4658",

"/networking/v1/credentials/b2a82c93-2583-4a1f-91f8-232b801e11bb",

"/networking/v1/credentials/BackupUser",

"/networking/v1/credentials/fd5b1b96-b302-4395-b6cd-ed9703435dd1",

"/networking/v1/virtualNetworkManager/configuration",

"/networking/v1/virtualSwitchManager/configuration",

"/networking/v1/accessControlLists/f8b97a4c-4419-481d-b757-a58483512640",

"/networking/v1/logicalnetworks/24fa1af9-88d6-4cdc-aba0-66e38c1a7bb8",

"/networking/v1/logicalnetworks/48610528-f40b-4718-938e-99c2be76f1e0",

"/networking/v1/logicalnetworks/89035b49-1ee3-438a-8d7a-f93cbae40619",

"/networking/v1/logicalnetworks/a9c8eaa0-519c-4988-acd6-11723e9efae5",

"/networking/v1/logicalnetworks/d4ea002c-c926-4c57-a178-461d5768c31f",

"/networking/v1/macPools/11111111-1111-1111-1111-111111111111",

"/networking/v1/loadBalancerManager/config",

"/networking/v1/publicIPAddresses/2c502b2d-b39a-4be1-a85a-55ef6a3a9a1d",

"/networking/v1/GatewayPools/Default",

"/networking/v1/servers/4c4c4544-0058-5810-8056-b4c04f395931",

"/networking/v1/servers/4c4c4544-0058-5810-8057-b4c04f395931",

"/networking/v1/servers/4c4c4544-0058-5910-8056-b4c04f395931",

"/networking/v1/networkInterfaces/058430d3-af43-4328-a440-56540f41da50",

"/networking/v1/networkInterfaces/08756090-6d55-4dec-98d5-80c4c5a47db8",

"/networking/v1/networkInterfaces/2175d74a-aacd-44e2-80d3-03f39ea3bc5d",

"/networking/v1/networkInterfaces/2400c2c3-2291-4b0b-929c-9bb8da55851a",
"/networking/v1/networkInterfaces/4c695570-6faa-4e4d-a552-0b36ed3e0962",

"/networking/v1/networkInterfaces/7e317638-2914-42a8-a2dd-3a6d966028d6",

"/networking/v1/networkInterfaces/834e3937-f43b-4d3c-88be-d79b04e63bce",

"/networking/v1/networkInterfaces/9d668fe6-b1c6-48fc-b8b1-b3f98f47d508",

"/networking/v1/networkInterfaces/ac4650ac-c3ef-4366-96e7-d9488fb661ba",

"/networking/v1/networkInterfaces/b9f23e35-d79e-495f-a1c9-fa626b85ae13",

"/networking/v1/networkInterfaces/fdd929f1-f64f-4463-949a-77b67fe6d048",

"/networking/v1/virtualServers/15a891ee-7509-4e1d-878d-de0cb4fa35fd",

"/networking/v1/virtualServers/57416993-b410-44fd-9675-727cd4e98930",

"/networking/v1/virtualServers/5f8aebdc-ee5b-488f-ac44-dd6b57bd316a",

"/networking/v1/virtualServers/6c812217-5931-43dc-92a8-1da3238da893",

"/networking/v1/virtualServers/d78b7fa3-812d-4011-9997-aeb5ded2b431",

"/networking/v1/virtualServers/d90820a5-635b-4016-9d6f-bf3f1e18971d",

"/networking/v1/loadBalancerMuxes/5f8aebdc-ee5b-488f-ac44-
dd6b57bd316a_suffix",

"/networking/v1/loadBalancerMuxes/d78b7fa3-812d-4011-9997-
aeb5ded2b431_suffix",

"/networking/v1/loadBalancerMuxes/d90820a5-635b-4016-9d6f-
bf3f1e18971d_suffix",

"/networking/v1/Gateways/15a891ee-7509-4e1d-878d-de0cb4fa35fd_suffix",

"/networking/v1/Gateways/57416993-b410-44fd-9675-727cd4e98930_suffix",

"/networking/v1/Gateways/6c812217-5931-43dc-92a8-1da3238da893_suffix",

"/networking/v1/virtualNetworks/b3dbafb9-2655-433d-b47d-a0e0bbac867a",

"/networking/v1/virtualNetworks/d705968e-2dc2-48f2-a263-76c7892fb143",

"/networking/v1/loadBalancers/24fa1af9-88d6-4cdc-aba0-
66e38c1a7bb8_10.127.132.2",

"/networking/v1/loadBalancers/24fa1af9-88d6-4cdc-aba0-
66e38c1a7bb8_10.127.132.3",

"/networking/v1/loadBalancers/24fa1af9-88d6-4cdc-aba0-
66e38c1a7bb8_10.127.132.4"
],
"InProgressResourcesList": [
 ],
"ProvisioningState": "Succeeded",
"Credential": {
"Tags": null,
"ResourceRef":
"/credentials/BackupUser",
"InstanceId": "00000000-0000-0000-
0000-000000000000",
"Etag": null,
"ResourceMetadata": null,
"ResourceId": null,
"Properties": null
}
}
}

Restauración de la infraestructura de SDN a

partir de una copia de seguridad
Al restaurar todos los componentes necesarios a partir de la copia de seguridad, el
entorno de SDN vuelve a un estado operativo.

） Importante

Los pasos varían en función del número de componentes restaurados.

1. Si es necesario, vuelva a implementar hosts de Hyper-V y el almacenamiento

necesario.

2. Si es necesario, restaure las máquinas virtuales de la controladora de red, las

máquinas virtuales de puerta de enlace RAS y las máquinas virtuales mux desde la
copia de seguridad.

3. Detenga el agente de host nc y el agente host de SLB en todos los hosts de Hyper-
V:

stop-service slbhostagent

stop-service nchostagent

4. Detenga las máquinas virtuales de puerta de enlace ras.

 5. Detenga las máquinas virtuales de SLB Mux.

6. Restaure la controladora de red con el new-networkcontrollerrestore cmdlet .

7. Compruebe la propiedad ProvisioningState de restauración para saber cuándo se

completó correctamente la restauración.

8. Si usa SCVMM, restaure la base de datos de SCVMM mediante la copia de

seguridad que se creó al mismo tiempo que la copia de seguridad de la
controladora de red.

9. Si desea restaurar máquinas virtuales de carga de trabajo desde la copia de

seguridad, hála ahora.

10. Compruebe el estado del sistema con el cmdlet debug-

networkcontrollerconfigurationstate.

PowerShell

$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController
"[Link] -Credential $cred

Fetching ResourceType: accessControlLists

Fetching ResourceType: servers
Fetching ResourceType: virtualNetworks
Fetching ResourceType: networkInterfaces
Fetching ResourceType: virtualGateways
Fetching ResourceType: loadbalancerMuxes
Fetching ResourceType: Gateways

Ejemplo: Restauración de una base de datos de

controladora de red
PowerShell

$URI = "[Link]
$Credential = Get-Credential

$ShareUserResourceId = "BackupUser"
$ShareCredential = Get-NetworkControllerCredential -ConnectionURI $URI -
Credential $Credential | Where {$_.ResourceId -eq $ShareUserResourceId }

$RestoreProperties = New-Object
[Link]
$[Link] =
"\\fileshare\backups\NetworkController\2017-04-25T16_53_13"
$[Link] = $ShareCredential
 $RestoreTime = (Get-Date).ToString("s").Replace(":", "_")
New-NetworkControllerRestore -ConnectionURI $URI -Credential $Credential -
Properties $RestoreProperties -ResourceId $RestoreTime -Force

Ejemplo: Comprobación del estado de una restauración

de base de datos de controladora de red
PowerShell

PS C:\ > get-networkcontrollerrestore -connectionuri $uri -credential $cred

-ResourceId $restoreTime | convertto-json -depth 10
{
"Tags": null,
"ResourceRef": "/networkControllerRestore/2017-04-26T15_04_44",
"InstanceId": "22edecc8-a613-48ce-a74f-0418789f04f6",
"Etag": "W/\"f14f6b84-80a7-4b73-93b5-59a9c4b5d98e\"",
"ResourceMetadata": null,
"ResourceId": "2017-04-26T15_04_44",
"Properties": {
"RestorePath":
"\\\\sa18fs\\sa18n22\\NetworkController\\2017-04-25T16_53_13",
"ErrorMessage": null,
"FailedResourcesList": null,
"SuccessfulResourcesList": null,
"ProvisioningState": "Succeeded",
"Credential": null
}
}

Para obtener información sobre los mensajes de estado de configuración que pueden
aparecer, consulte Solución de problemas de la pila de redes definida por software
Windows Server 2016.
Proteger la controladora de red
Artículo • 23/01/2023 • Tiempo de lectura: 10 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2; Windows Server 2022,
Windows Server 2019, Windows Server 2016

En este tema aprenderá a configurar la seguridad para toda la comunicación entre

Controladora de red y otros softwares y dispositivos.

Las rutas de comunicación que puede proteger incluyen la comunicación northbound

en el plano de administración, la comunicación de clúster entre las máquinas virtuales
(VM) de Controladora de red en un clúster, y la comunicación southbound en el plano
de datos.

1. Comunicación northbound. Controladora de red se comunica en el plano de

administración con software de administración compatible con SDN (redes
definidas por software), como Windows PowerShell y System Center Virtual
Machine Manager (SCVMM). Estas herramientas de administración le proporcionan
la capacidad de definir la directiva de red y crear un estado objetivo para la red,
con el que puede comparar la configuración de red real para poner la
configuración real en paridad con el estado objetivo.

2. Comunicación de clúster de Controladora de red. Al configurar tres o más

máquinas virtuales como nodos de clúster de Controladora de red, estos nodos se
comunican entre sí. Esta comunicación puede estar relacionada con la
sincronización y replicación de datos entre nodos o con una comunicación
específica entre los servicios de Controladora de red.

3. Comunicación southbound. Controladora de red se comunica en el plano de

datos con la infraestructura de SDN y otros dispositivos, como equilibradores de
carga de software, puertas de enlace y máquinas host. Puede usar Controladora de
red para configurar y administrar estos dispositivos southbound para que
mantengan el estado objetivo que ha configurado para la red.

Comunicación northbound
Controladora de red admite la autenticación, la autorización y el cifrado para la
comunicación northbound. En las secciones siguientes se proporciona información
sobre cómo configurar estas opciones de seguridad.
Authentication
Al configurar la autenticación para la comunicación northbound de Controladora de red,
permite que los nodos de clúster de Controladora de red y los clientes de
administración comprueben la identidad del dispositivo con el que se comunican.

Controladora de red admite los siguientes tres modos de autenticación entre los
clientes de administración y los nodos de Controladora de red.

７ Nota

Si va a implementar controladora de red con System Center Virtual Machine

Manager, solo se admite el modo Kerberos.

1. Kerberos. Use la autenticación Kerberos al unir el cliente de administración y todos

los nodos de clúster de Controladora de red a un dominio de Active Directory. El
dominio de Active Directory debe tener cuentas de dominio usadas para la
autenticación.

2. X509. Use X509 para la autenticación basada en certificados para los clientes de
administración que no están unidos a un dominio de Active Directory. Debe
inscribir certificados en todos los nodos de clúster de Controladora de red y
clientes de administración. Además, todos los nodos y clientes de administración
deben confiar en los certificados de los demás.

3. No. Use None con fines de prueba en un entorno de prueba y, por lo tanto, no se
recomienda su uso en un entorno de producción. Al elegir este modo, no se realiza
ninguna autenticación entre nodos y clientes de administración.

Puede configurar el modo de autenticación para la comunicación northbound mediante

el comando install-NetworkController de Windows PowerShell con el parámetro
ClientAuthentication.

Autorización
Al configurar la autorización para la comunicación northbound de Controladora de red,
permite que los nodos de clúster de Controladora de red y los clientes de
administración comprueben que el dispositivo con el que se comunican es de confianza
y tiene permiso para participar en la comunicación.

Use los siguientes métodos de autorización para cada uno de los modos de
autenticación admitidos por Controladora de red.
 1. Kerberos. Cuando use el método de autenticación Kerberos, defina los usuarios y
equipos autorizados para comunicarse con Controladora de red mediante la
creación de un grupo de seguridad en Active Directory y, a continuación,
agregando los usuarios y equipos autorizados al grupo. Puede configurar
Controladora de red para usar el grupo de seguridad para la autorización
mediante el parámetro ClientSecurityGroup del comando Install-
NetworkController de Windows PowerShell. Después de instalar Controladora de
red puede cambiar el grupo de seguridad mediante el comando Set-
NetworkController con el parámetro -ClientSecurityGroup. Si usa SCVMM, debe
proporcionar el grupo de seguridad como parámetro durante la implementación.

2. X509. Cuando se usa el método de autenticación X509, Controladora de red solo

acepta solicitudes de clientes de administración cuyas huellas digitales de
certificado conoce. Puede configurar estas huellas digitales mediante el parámetro
ClientCertificateThumbprint del comando Install-NetworkController de Windows
PowerShell. Puede agregar otras huellas digitales de cliente en cualquier momento
mediante el comando Set-NetworkController.

3. No. Al elegir este modo, no se realiza ninguna autenticación entre nodos y clientes
de administración. Use None con fines de prueba en un entorno de prueba y, por
lo tanto, no se recomienda su uso en un entorno de producción.

Cifrado
La comunicación northbound usa Capa de sockets seguros (SSL) para crear un canal
cifrado entre los clientes de administración y los nodos de Controladora de red. El
cifrado SSL para la comunicación northbound incluye los siguientes requisitos:

Todos los nodos de controladora de red deben tener un certificado idéntico que
incluya los fines de autenticación de servidor y autenticación de cliente en
extensiones de uso mejorado de clave (EKU).

El URI usado por los clientes de administración para comunicarse con Controladora
de red debe ser el nombre del firmante del certificado. El nombre del firmante del
certificado debe contener el nombre de dominio completo (FQDN) o la dirección
IP del punto de conexión de REST de Controladora de red.

Si los nodos de Controladora de red están en subredes diferentes, el nombre del

firmante de sus certificados debe ser el mismo que el valor usado para el
parámetro RestName en el comando Install-NetworkController de Windows
PowerShell.

Todos los clientes de administración deben confiar en el certificado SSL.

Configuración y inscripción de certificados SSL
Debe inscribir manualmente el certificado SSL en los nodos de Controladora de red.

Una vez inscrito el certificado, puede configurar Controladora de red para usar el
certificado con el parámetro -ServerCertificate del comando Install-NetworkController
de Windows PowerShell. Si ya ha instalado Controladora de red, puede actualizar la
configuración en cualquier momento mediante el comando Set-NetworkController.

７ Nota

Si usa SCVMM, debe agregar el certificado como un recurso de biblioteca. Para

obtener más información, consulte Configuración de una controladora de red de
SDN en el tejido de VMM.

Comunicación de clúster de Controladora de

red
Controladora de red admite la autenticación, la autorización y el cifrado para la
comunicación entre sus nodos. La comunicación se realiza a través de Windows
Communication Foundation (WCF) y TCP.

Puede configurar este modo con el parámetro ClusterAuthentication del comando

Install-NetworkControllerCluster de Windows PowerShell.

Para obtener más información consulte Install-NetworkControllerCluster.

Authentication
Al configurar la autenticación para la comunicación de clúster de Controladora de red,
permite que los nodos de clúster de Controladora de red comprueben la identidad de
los demás nodos con los que se comunican.

Controladora de red admite los tres modos siguientes de autenticación entre sus nodos.

７ Nota

Si implementa Controladora de red mediante SCVMM, solo se admite el modo

Kerberos.
 1. Kerberos. Puede usar la autenticación Kerberos cuando todos los nodos de clúster
de Controladora de red están unidos a un dominio de Active Directory, con
cuentas de dominio usadas para la autenticación.

2. X509. X509 es la autenticación basada en certificados. Puede usar la autenticación

X509 cuando los nodos de clúster de Controladora de red no están unidos a un
dominio de Active Directory. Para usar X509 debe inscribir certificados en todos los
nodos de clúster de Controladora de red y todos los nodos deben confiar en los
certificados. Además, el nombre del firmante del certificado inscrito en cada nodo
debe ser el mismo que el nombre DNS del nodo.

3. No. Al elegir este modo, no se realiza ninguna autenticación entre los nodos de
Controladora de red. Este modo solo se proporciona con fines de prueba y no se
recomienda para su uso en un entorno de producción.

Autorización
Al configurar la autorización para la comunicación de clúster de Controladora de red,
permite que los nodos de clúster de Controladora de red comprueben que los nodos
con los que se comunican son de confianza y tienen permiso para participar en la
comunicación.

Para cada uno de los modos de autenticación admitidos por Controladora de red, se
usan los métodos de autorización siguientes.

1. Kerberos. Los nodos de Controladora de red aceptan solicitudes de comunicación

solo de otras cuentas de máquina de Controladora de red. Puede configurar estas
cuentas al implementar Controladora de red mediante el parámetro Name del
comando New-NetworkControllerNodeObject de Windows PowerShell.

2. X509. Los nodos de Controladora de red aceptan solicitudes de comunicación solo

de otras cuentas de máquina de Controladora de red. Puede configurar estas
cuentas al implementar Controladora de red mediante el parámetro Name del
comando New-NetworkControllerNodeObject de Windows PowerShell.

3. No. Al elegir este modo no se realiza ninguna autorización entre los nodos de
Controladora de red. Este modo solo se proporciona con fines de prueba y no se
recomienda para su uso en un entorno de producción.

Cifrado
La comunicación entre los nodos de Controladora de red se cifra mediante el cifrado de
nivel de transporte de WCF. Esta forma de cifrado se usa cuando los métodos de
autenticación y autorización son certificados Kerberos o X509. Para obtener más
información, vea los siguientes temas.

Procedimiento para proteger un servicio con credenciales de Windows

Procedimiento para proteger un servicio con certificados X.509.

Comunicación southbound
Controladora de red interactúa con diferentes tipos de dispositivos para la
comunicación southbound. Estas interacciones usan protocolos diferentes. Por este
motivo, hay diferentes requisitos para la autenticación, la autorización y el cifrado en
función del tipo de dispositivo y protocolo que usa Controladora de red para
comunicarse con el dispositivo.

En la tabla siguiente se proporciona información sobre la interacción de Controladora

de red con diferentes dispositivos southbound.

Dispositivo o servicio southbound Protocolo Autenticación usada

Equilibrador de carga de software WCF (MUX), TCP (Host) Certificados

Firewall OVSDB Certificados

Puerta de enlace WinRM Kerberos, certificados

Redes virtuales OVSDB, WCF Certificados

Enrutamiento definido por el usuario OVSDB Certificados

Para cada uno de estos protocolos, el mecanismo de comunicación se describe en la

siguiente sección.

Authentication
Para la comunicación southbound se usan los siguientes protocolos y métodos de
autenticación.

1. WCF/TCP/OVSDB. Para estos protocolos, la autenticación se realiza mediante

certificados X509. Tanto Controladora de red como el multiplexor (MUX) de
equilibrio de carga de software (SLB) o las máquinas host del mismo nivel
presentan sus certificados entre sí para la autenticación mutua. El nodo del mismo
nivel remoto debe confiar en cada certificado.
 Para la autenticación southbound puede usar el mismo certificado SSL configurado
para cifrar la comunicación con los clientes northbound. También debe configurar
un certificado en los dispositivos MUX SLB y host. El nombre del firmante del
certificado debe ser el mismo que el nombre DNS del dispositivo.

2. WinRM. Para este protocolo, la autenticación se realiza mediante Kerberos (para

máquinas unidas a un dominio) y mediante certificados (para máquinas no unidas
a un dominio).

Autorización
Para la comunicación southbound se usan los siguientes protocolos y métodos de
autorización.

1. WCF/TCP. Para estos protocolos la autorización se basa en el nombre del firmante

de la entidad del mismo nivel. Controladora de red almacena el nombre DNS del
dispositivo del mismo nivel y lo usa para la autorización. Este nombre DNS debe
coincidir con el nombre del firmante del dispositivo en el certificado. Del mismo
modo, el certificado de Controladora de red debe coincidir con el nombre DNS de
Controladora de red almacenado en el dispositivo del mismo nivel.

2. WinRM. Si se usa Kerberos, la cuenta de cliente de WinRM debe estar presente en

un grupo predefinido en Active Directory o en el grupo Administradores locales en
el servidor. Si se usan certificados, el cliente presenta un certificado al servidor que
el servidor autoriza mediante el nombre del firmante o emisor, y el servidor usa
una cuenta de usuario asignada para realizar la autenticación.

3. OVSDB. No se proporciona ninguna autorización para este protocolo.

Cifrado
Para la comunicación southbound se usan los siguientes métodos de cifrado para los
protocolos.

1. WCF/TCP/OVSDB. Para estos protocolos el cifrado se realiza mediante el

certificado inscrito en el cliente o servidor.

2. WinRM. El tráfico de WinRM se cifra de forma predeterminada mediante el

proveedor de compatibilidad para seguridad (SSP) de Kerberos. Puede configurar
Cifrado adicional, en forma de SSL, en el servidor WinRM.
Administración de certificados para
redes definidas por software
Artículo • 23/01/2023 • Tiempo de lectura: 12 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2; Windows Server 2022,
Windows Server 2019, Windows Server 2016

Puede usar este tema para aprender a administrar certificados para las comunicaciones
Northbound y Southbound de la Controladora de red al implementar redes definidas
por software (SDN) en Windows Server 2019 o 2016 Datacenter y si usa System Center
Virtual Machine Manager (SCVMM) como cliente de administración de SDN.

７ Nota

Para información general sobre la Controladora de red, consulte ¿Qué es la

Controladora de red?

Si no usa Kerberos para proteger la comunicación de la Controladora de red, puede usar

certificados X.509 para la autenticación, la autorización y el cifrado.

SDN en Windows Server 2019 y 2016 Datacenter admite certificados X.509 autofirmados
y firmados por la entidad de certificación (CA). En este tema se proporcionan
instrucciones paso a paso para crear estos certificados y aplicarlos para proteger los
canales de comunicación Northbound de la Controladora de red con clientes de
administración y de comunicaciones Southbound con dispositivos de red, como
Software Load Balancer (SLB).

Al usar la autenticación basada en certificados, debe inscribir un certificado en los nodos

de la Controladora de red que se usan de las maneras siguientes.

1. Cifrado de la comunicación Northbound con Capa de sockets seguros (SSL) entre

nodos de la Controladora de red y clientes de administración, como System Center
Virtual Machine Manager.
2. Autenticación entre nodos de la Controladora de red y dispositivos y servicios
Southbound, como hosts de Hyper-V y equilibradores de carga de software (SLA).

Creación e inscripción de un certificado X.509

Puede crear e inscribir un certificado autofirmado o un certificado emitido por una
entidad de certificación.

７ Nota

Cuando use SCVMM para implementar la Controladora de red, debe especificar el

certificado X.509 que se usa para cifrar las comunicaciones Northbound durante la
configuración de la plantilla de servicio de la Controladora de red.

La configuración del certificado debe incluir los siguientes valores.

El valor del cuadro de texto RestEndPoint debe ser el nombre de dominio

completo (FQDN) o la dirección IP de la Controladora de red.
El valor RestEndPoint debe coincidir con el nombre del firmante (Nombre común,
CN) del certificado X.509.

Creación de un certificado X.509 autofirmado

Puede crear un certificado X.509 autofirmado y exportarlo con la clave privada
(protegida con una contraseña) siguiendo estos pasos para implementaciones de uno y
varios nodos de la Controladora de red.

Al crear certificados autofirmados, puede usar las instrucciones siguientes.

Puede usar la dirección IP del punto de conexión REST de la Controladora de red

como parámetro DnsName, pero no se recomienda porque requiere que todos los
nodos de la Controladora de red se encuentren en una sola subred de
administración (por ejemplo, en un solo bastidor).
En el caso de implementaciones de la Controladora de red de varios nodos, el
nombre DNS que especifique se convertirá en el FQDN del clúster de Controladora
de red (los registros del host A de DNS se crean automáticamente).
En el caso de implementaciones de la Controladora de red de un solo nodo, el
nombre DNS puede ser el nombre de host de la Controladora de red seguido del
nombre de dominio completo.

Nodo múltiple
Puede usar el comando New-SelfSignedCertificate de Windows PowerShell para crear
un certificado autofirmado.

Sintaxis
 PowerShell

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong

Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("
<NCRESTName>")

Ejemplo de uso

PowerShell

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong

Cryptographic Provider" -FriendlyName "MultiNodeNC" -DnsName
@("[Link]")

Nodo único

Puede usar el comando New-SelfSignedCertificate de Windows PowerShell para crear

un certificado autofirmado.

Sintaxis

PowerShell

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong

Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("
<NCFQDN>")

Ejemplo de uso

PowerShell

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong

Cryptographic Provider" -FriendlyName "SingleNodeNC" -DnsName
@("[Link]")

Creación de un certificado X.509 firmado por una entidad

de certificación
Para crear un certificado mediante una entidad de certificación, ya debe haber
implementado una infraestructura de clave pública (PKI) con Servicios de certificados de
Active Directory (AD CS).

７ Nota
 Puede usar entidades de certificación o herramientas de terceros, como openssl,
para crear un certificado para su uso con la Controladora de red, pero las
instrucciones de este tema son específicas para AD CS. Para información sobre
cómo usar una entidad de certificación o una herramienta de terceros, consulte la
documentación del software que esté usando.

La creación de un certificado con una entidad de certificación incluye los pasos

siguientes.

1. Usted o el administrador de dominio o seguridad de su organización configuran la

plantilla de certificado.
2. Usted o el administrador de la Controladora de red de la organización o el
administrador de SCVMM solicitan un nuevo certificado a la entidad de
certificación.

Requisitos de configuración de certificados

Mientras configura una plantilla de certificado en el paso siguiente, asegúrese de que la

plantilla que configure incluye los siguientes elementos necesarios.

1. El nombre del firmante del certificado debe ser el FQDN del host de Hyper-V.
2. El certificado debe colocarse en el almacén personal de la máquina local (My –
cert:\localmachine\my).
3. El certificado debe tener las directivas de aplicación de autenticación de servidor
(EKU: [Link].[Link].1) y autenticación de cliente (EKU: [Link].[Link].2).

７ Nota

Si el almacén de certificados personal (My – cert:\localmachine\my) del host de

Hyper-V tiene más de un certificado X.509 con el nombre del firmante (CN) como
nombre de dominio completo (FQDN) del host, asegúrese de que el certificado que
use SDN tenga una propiedad personalizada para el uso mejorado de clave con el
OID [Link].[Link].1.1.1. De lo contrario, es posible que la comunicación entre el
controlador de red y el host no funcione.

Para configurar la plantilla de certificado

７ Nota
 Antes de realizar este procedimiento, debe revisar los requisitos de certificado y las
plantillas de certificado disponibles en la consola Plantillas de certificado. Puede
modificar una plantilla existente o crear un duplicado de una plantilla existente y,
luego, modificar la copia de la plantilla. Se recomienda crear una copia de una
plantilla existente.

1. En el servidor donde está instalado AD CS, en Administrador del servidor, haga clic
en Herramientas y, luego, haga clic en Entidad de certificación. Se abre Microsoft
Management Console (MMC) de la entidad de certificación.
2. En MMC, haga doble clic en el nombre de la entidad de certificación, haga clic con
el botón derecho en Plantillas de certificado y, luego, haga clic en Administrar.
3. Se abre la consola Plantillas de certificado. Se mostrarán todas las plantillas de
certificado en el panel de detalles.
4. En el panel de detalles, haga clic en la plantilla que quiere duplicar.
5. Haga clic en el menú Acción y, luego, haga clic en Duplicar plantilla. Se abre el
cuadro de diálogo Propiedades de la plantilla.
6. En el cuadro de diálogo Propiedades de la plantilla, en la pestaña Nombre del
firmante, haga clic en Proporcionado por el solicitante. (Esta configuración es
necesaria para los certificados SSL de la Controladora de red).
7. En el cuadro de diálogo Propiedades de la plantilla, en la pestaña Control de
solicitudes, asegúrese de que la opción Permitir que se exporte la clave privada
esté seleccionada. Asegúrese también de que la firma y el propósito de cifrado
estén seleccionados.
8. En el cuadro de diálogo Propiedades de la plantilla, en la pestaña Extensiones,
seleccione Uso de claves y, luego, haga clic en Editar.
9. En Firma, asegúrese de que esté seleccionada la opción Firma digital.
10. En el cuadro de diálogo Propiedades de la plantilla, en la pestaña Extensiones,
seleccione Directivas de aplicación y, luego, haga clic en Editar.
11. En Directivas de aplicación, asegúrese de que se muestran las opciones
Autenticación de cliente y Autenticación de servidor.
12. Guarde la copia de la plantilla de certificado con un nombre único, como Plantilla
de Controladora de red.

Solicitud de un certificado a una entidad de certificación

Puede usar el complemento Certificados para solicitar certificados. Puede solicitar

cualquier tipo de certificado disponible y preconfigurado por el administrador de la
entidad de certificación que va a procesar la solicitud de certificado.

La pertenencia a grupos mínima necesaria para realizar este procedimiento es Usuarios

o Administradores locales.
 1. Abra el complemento Certificados de un equipo.
2. En el árbol de consola, haga clic en Certificados (equipo local). Seleccione el
almacén de certificados Personal.
3. En el menú Acción, seleccione **Todas las tareas y, luego, haga clic en **Solicitar
un nuevo certificado para iniciar el Asistente para la inscripción de certificados.
Haga clic en Next.
4. Seleccione la directiva de inscripción de certificados configurada por el
administrador y haga clic en Siguiente.
5. Seleccione la directiva de inscripción de Active Directory (basada en la plantilla de
CA que configuró en la sección anterior).
6. Expanda la sección Detalles y configure los siguientes elementos.
a. Asegúrese de que Uso de claves incluya Firma digital **y **Cifrado de claves.
b. Asegúrese de que Directivas de aplicación incluya Autenticación de servidor
([Link].[Link].1) y Autenticación de cliente ([Link].[Link].2).
7. Haga clic en Propiedades.
8. En la pestaña Firmante, en Nombre del firmante, en Tipo, seleccione Nombre
común. En Valor, especifique Punto de conexión REST de la Controladora de red.
9. Haga clic en Aplicar y en Aceptar.
10. Haga clic en Inscribir.

En MMC de certificados, haga clic en el almacén personal para ver el certificado que ha
inscrito de la entidad de certificación.

Exportación y copia del certificado en la

biblioteca de SCVMM
Después de crear un certificado autofirmado o firmado por una entidad de certificación,
debe exportarlo con la clave privada (en formato .pfx) y sin la clave privada (en formato
.cer de base-64) desde el complemento Certificados.

A continuación, debe copiar los dos archivos exportados en las carpetas

[Link] y [Link] que especificó en el momento en que importó la
plantilla de servicio de la Controladora de red.

1. Abra el complemento Certificados ([Link]) y busque el certificado en el

almacén de certificados Personal del equipo local.
2. Haga clic con el botón secundario en el certificado, haga clic en Todas las tareasy,
a continuación, haga clic en Exportar. Se abre el Asistente para exportar
certificados. Haga clic en Next.
3. Seleccione Sí, exporte la opción de clave privada y haga clic en Siguiente.
 4. Seleccione Intercambio de información personal: PKCS #12 (.PFX) y acepte el
valor predeterminado Incluir todos los certificados en la ruta de certificación (si
es posible).
5. Asigne los usuarios o grupos y una contraseña para el certificado que va a exportar
y haga clic en Siguiente.
6. En la página Archivo que se va a exportar, busque la ubicación en la que quiere
colocar el archivo exportado y asígnele un nombre.
7. Exporte del mismo modo el certificado en formato .CER. Nota: Para exportar al
formato .CER, desactive la opción Exportar la clave privada.
8. Copie el archivo .PFX en la carpeta [Link].
9. Copie el archivo .CER en la carpeta [Link].

Cuando haya terminado, actualice estas carpetas en la biblioteca de SCVMM y

asegúrese de que tiene copiados estos certificados. Continúe con la configuración y la
implementación de la plantilla de servicio de la Controladora de red.

Autenticación de servicios y dispositivos

Southbound
En la comunicación de la Controladora de red con hosts y dispositivos MUX de SLB se
usan certificados para la autenticación. La comunicación con los hosts se realiza a través
del protocolo OVSDB, mientras que la comunicación con los dispositivos MUX de SLB se
realiza a través del protocolo WCF.

Comunicación del host de Hyper-V con la Controladora

de red
Para la comunicación con los hosts de Hyper-V a través de OVSDB, la Controladora de
red debe presentar un certificado a las máquinas host. De forma predeterminada,
SCVMM selecciona el certificado SSL configurado en la Controladora de red y lo usa
para la comunicación Southbound con los hosts.

Esa es la razón por la que el certificado SSL debe tener configurada la EKU de
autenticación de cliente. Este certificado se configura en el recurso REST "Servidores"
(los hosts de Hyper-V se representan en la Controladora de red como un recurso de
servidor) y se pueden ver ejecutando el comando Get-NetworkControllerServer de
Windows PowerShell.

A continuación, se muestra un ejemplo parcial del recurso REST del servidor.

 "resourceId": "[Link]",
"properties": {
"connections": [
{
"managementAddresses": [
"[Link]"
],
"credential": {
"resourceRef": "/credentials/a738762f-f727-43b5-9c50-
cf82a70221fa"
},
"credentialType": "X509Certificate"
}
],

Para la autenticación mutua, el host de Hyper-V también debe tener un certificado para
comunicarse con la Controladora de red.

Puede inscribir el certificado desde una entidad de certificación (CA). Si no se encuentra

un certificado basado en una entidad de certificación en la máquina host, SCVMM crea
un certificado autofirmado y lo aprovisiona en dicha máquina.

Los certificación de la Controladora de red y del host de Hyper-V deben basarse en la

confianza mutua. El certificado raíz del certificado del host de Hyper-V debe estar
presente en el almacén de entidades de certificación raíz de confianza de la
Controladora de red para el equipo local y viceversa.

Cuando se usan certificados autofirmados, SCVMM garantiza que los certificados

necesarios están presentes en el almacén de entidades de certificación raíz de confianza
en el equipo local.

Si usa certificados basados en una entidad de certificación para los hosts de Hyper-V,
debe asegurarse de que el certificado raíz de la entidad de certificación esté presente en
el almacén de entidades de certificación raíz de confianza de la Controladora de red en
el equipo local.

Comunicación MUX de Software Load Balancer con la

Controladora de red
El multplexor (MUX) de Software Load Balancer y la Controladora de red se comunican a
través del protocolo WCF, usando certificados para la autenticación.

De forma predeterminada, SCVMM selecciona el certificado SSL configurado en la

Controladora de red y lo usa para la comunicación Southbound con los dispositivos
MUX. Este certificado se configura en el recurso REST
"NetworkControllerLoadBalancerMux" y se puede ver ejecutando el cmdlet Get-
NetworkControllerLoadBalancerMux de PowerShell.

Ejemplo de recurso REST de MUX (parcial):

"resourceId": "[Link]",
"properties": {
"connections": [
{
"managementAddresses": [
"[Link]"
],
"credential": {
"resourceRef": "/credentials/a738762f-f727-43b5-9c50-
cf82a70221fa"
},
"credentialType": "X509Certificate"
}
],

Para la autenticación mutua, también debe tener un certificado en los dispositivos MUX
de SLB. SCVMM configura automáticamente este certificado al implementar el
equilibrador de carga de software mediante SCVMM.

） Importante

En los nodos host y SLB, es fundamental que el almacén de certificados de

entidades de certificación raíz de confianza no incluya ningún certificado en el que
el emisor y el destinatario no sean la misma persona. Si esto ocurre, se produce un
error en la comunicación entre la Controladora de red y el dispositivo Southbound.

Los certificados de la Controladora de red y MUX de SLB deben basarse en la confianza

mutua (el certificado raíz del certificado MUX de SLB debe estar presente en el almacén
de entidades de certificación raíz de confianza de la máquina de la Controladora de red
y viceversa). Cuando se usan certificados autofirmados, SCVMM garantiza que los
certificados necesarios están presentes en el almacén de entidades de certificación raíz
de confianza en el equipo local.
Renovación de certificados de la
controladora de red antes de que
expiren
Artículo • 23/02/2023 • Tiempo de lectura: 6 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2; Windows Server 2022 y
Windows Server 2019

En este artículo se proporcionan instrucciones sobre cómo renovar o cambiar los

certificados de la controladora de red antes de que expiren.

） Importante

Si los certificados de la controladora de red ya han expirado, no use las

instrucciones de este artículo para renovarlos.

En la infraestructura de redes definidas por software (SDN), la controladora de red usa la

autenticación basada en certificados para proteger los canales de comunicación de
Northbound con clientes de administración, y las comunicaciones de Southbound con
dispositivos de red, como Software Load Balancer. Los certificados de la controladora de
red tienen con un período de validez establecido, después del cual se vuelven inválidos
y ya no se puede confiar en su uso. Debe renovarlos antes de que expiren.

Para obtener información general sobre la controladora de red, consulte ¿Qué es el

controlador de red?

Cuándo renovar o cambiar los certificados de la

controladora de red
Puede renovar o cambiar los certificados de la controladora de red cuando:

Los certificados están a punto de expirar. De hecho, puede renovar los certificados
de la controladora de red en cualquier momento antes de que expiren.

７ Nota

Si renueva los certificados existentes con la misma clave, tendrá todo listo y
no necesita hacer nada más.
 Quiere reemplazar un certificado autofirmado por un certificado firmado por una
entidad de certificación (CA).

７ Nota

Al cambiar los certificados, asegúrese de usar el mismo nombre de sujeto que

el certificado anterior.

Tipos de certificados de la controladora de red

En Azure Stack HCI, cada VM de la controladora de red usa dos tipos de certificados:

Certificado de REST. Un único certificado para la comunicación de Northbound con

clientes de REST (como Windows Admin Center) y la comunicación de Southbound
con hosts de Hyper-V y equilibradores de carga de software. Este mismo
certificado está presente en todas las VM de la controladora de red. Para renovar
los certificados de REST, consulte Renovación de certificados de REST.

Certificado de nodo de la controladora de red. Un certificado en cada VM de la

controladora de red para la autenticación entre nodos. Para renovar los
certificados de nodo de la controladora de red, consulte Renovación de los
certificados de nodo.

２ Advertencia

No deje que estos certificados expiren. Renuévelos antes de que expiren para evitar
cualquier problema de autenticación. Además, no quite ningún certificado que
haya expirado antes de renovarlos. Para averiguar la fecha de expiración de un
certificado, consulte Ver la expiración del certificado, a continuación.

Visualización de la expiración del certificado

Use el siguiente cmdlet en cada VM de la controladora de red para comprobar la fecha
de expiración de un certificado:

PowerShell

Get-ChildItem Cert:\LocalMachine\My | where{$_.Subject -eq "CN=<Certificate-

subject-name>"} | Select-Object NotAfter, Subject
 Para obtener la expiración de un certificado REST, reemplace "Certificate-subject-
name" por restIPAddress o RestName de la controladora de red. Puede encontrar
este valor en el cmdlet Get-NetworkController .

Para obtener la expiración de un certificado de nodo, reemplace "Certificate-

subject-name" por el nombre de dominio completo (FQDN) de la VM de la
controladora de red. Puede encontrar este valor en el cmdlet Get-
NetworkController .

Renovación de certificados de REST

Use el certificado de REST de la controladora de red para:

La comunicación de Northbound con clientes de REST

El cifrado de credenciales
La comunicación de Southbound con hosts y VM de software de Load Balancer

Al actualizar un certificado de REST, debe actualizar los clientes de administración y los

dispositivos de red para usar el nuevo certificado.

Para renovar el certificado de REST, complete los pasos siguientes:

1. Asegúrese de que el certificado en las VM de la controladora de red no haya

expirado antes de renovarlo. Consulte Visualización de la expiración del certificado.

７ Nota

Si el certificado ya ha expirado, no siga estos pasos.

2. Adquiera el nuevo certificado y colóquelo en el almacén personal del equipo local

(LocalMachine\My). Si es un certificado autofirmado, colóquelo en el almacén raíz
(LocalMachine\Root) de cada VM de la controladora de red. Para información
sobre cómo crear un certificado o emitirlo desde una entidad de certificación,
consulte Administración de certificados para redes definidas por software.

3. Asigne el nuevo certificado a una variable:

PowerShell

$cert= Get-ChildItem Cert:\LocalMachine\My | where{$_.Thumbprint -eq "

<thumbprint of the new certificate>"}
 4. Copie el certificado en todas las VM de la controladora de red.

5. Proporcione permisos de lectura y un permiso para NT Authority/Network Service

en el certificado:

PowerShell

$targetCertPrivKey = $[Link]
$privKeyCertFile = Get-Item -path
"$ENV:ProgramData\Microsoft\Crypto\RSA\MachineKeys\*" | where-object
{$_.Name -eq
$[Link]}
$privKeyAcl = Get-Acl $privKeyCertFile
$permission = "NT AUTHORITY\NETWORK SERVICE","Read","Allow"
$accessRule = new-object
[Link] $permission
$[Link]($accessRule)
Set-Acl $[Link] $privKeyAcl

6. (Solo para el certificado autofirmado) Copie la clave pública del certificado en

todos los hosts y VM de Software Load Balancer.

7. Modifique la configuración de la controladora de red para usar el nuevo

certificado.

Copia del certificado en todas las VM de la controladora

de red
Siga estos pasos para copiar un certificado en todas las VM de la controladora de red.

1. Asegúrese de adquirir el nuevo certificado y colóquelo en el almacén personal de

la máquina local (Mi – cert:\localmachine\my).

2. En la primera VM de la controladora de red, exporte el certificado a un archivo de

Intercambio de información personal (PFX).

PowerShell

$mypwd = ConvertTo-SecureString -String "<password>" -Force -

AsPlainText
Export-PfxCertificate -FilePath "C:\[Link]" -Password $mypwd -Cert
$cert
# Here, $cert is the new certificate

3. En otras VM de la controladora de red, importe el certificado y las claves privadas

desde un archivo PFX al almacén de destino:
 PowerShell

$mypwd = ConvertTo-SecureString -String "<password>" -Force -

AsPlainText
Import-PfxCertificate -FilePath C:\[Link] -CertStoreLocation
Cert:\LocalMachine\My -Password $mypwd
# Ensure that you copy the pfx file into the local machine before
importing the cert

Copia de la clave pública del certificado en todos los

hosts y VM de Software Load Balancer (Solo para el
certificado autofirmado)
Si usa un certificado autofirmado, colóquelo en el almacén raíz del equipo local
(LocalMachine\Root) según lo siguiente:

Cada VM de la controladora de red.

Cada máquina host de Azure Stack HCI y las VM de Software Load Balancer. Esto
garantiza que las entidades del mismo nivel confíen en el certificado.

Este es un comando de ejemplo para importar la clave pública del certificado que ya se
ha exportado:

PowerShell

Import-Certificate -FilePath "\\sa18fs\SU1_LibraryShare1\[Link]\" -

CertStoreLocation cert:\localMachine\Root

Modificación de la configuración de la controladora de

red para usar el nuevo certificado
Modifique la configuración del nodo, el clúster y la aplicación de la controladora de red
para usar el nuevo certificado.

Para la comunicación de Northbound

Para cambiar el certificado que usa la controladora de red para la comunicación de

Northbound, ejecute el siguiente comando en cualquiera de las VM de la controladora
de red:

PowerShell

Set-NetworkController -ServerCertificate \$cert

Para el cifrado de credenciales

Para cambiar el certificado que usa la controladora de red para el cifrado de

credenciales, ejecute el siguiente comando en cualquiera de las VM de la controladora
de red:

PowerShell

Set-NetworkControllerCluster -CredentialEncryptionCertificate $cert

Para la comunicación de Southbound

Para cambiar el certificado que usa la controladora de red para comunicarse con hosts y
equilibradores de carga de software, ejecute el siguiente comando:

PowerShell

$certCred = Get-NetworkControllerCredential -ConnectionUri <REST uri of

deployment> |where-object { $_.[Link] -eq "X509Certificate" }
$certCred[0].[Link] ="<Thumbprint of the new certificate>"

New-NetworkControllerCredential -ConnectionUri <REST uri of deployment> -

ResourceId $certCred[0].ResourceId -Properties $certCred[0].Properties -
Force

Renovación de certificados de nodo

Para renovar el certificado de nodo de la controladora de red, realice los pasos
siguientes en cada VM de la controladora de red:

1. Adquiera el nuevo certificado y colóquelo en el almacén personal del equipo local

(LocalMachine\My). Si es un certificado autofirmado, colóquelo en el almacén
(LocalMachine\Root) de cada VM de la controladora de red. Para obtener
información sobre cómo crear un certificado o emitirlo desde una entidad de
certificación, consulte Administración de certificados para redes definidas por
software.

2. Asigne el nuevo certificado a una variable:

PowerShell

$cert = Get-ChildItem Cert:\LocalMachine\My | where{$_.Thumbprint -eq "

<thumbprint of the new certificate>"}
3. Proporcione permisos de lectura y un permiso para NT Authority/Network Service
en el certificado:

PowerShell

$targetCertPrivKey = $[Link]
$privKeyCertFile = Get-Item -path
"$ENV:ProgramData\Microsoft\Crypto\RSA\MachineKeys\*" | where-object
{$_.Name -eq
$[Link]}
$privKeyAcl = Get-Acl $privKeyCertFile
$permission = "NT AUTHORITY\NETWORK SERVICE","Read","Allow"
$accessRule = new-object
[Link] $permission
$[Link]($accessRule)
Set-Acl $[Link] $privKeyAcl

4. Ejecute el siguiente comando para cambiar el certificado de nodo:

PowerShell

Set-NetworkControllerNode -Name "<Name of the Network Controller node>"

-NodeCertificate $cert
Kerberos con nombre de entidad de
seguridad de servicio (SPN)
Artículo • 23/01/2023 • Tiempo de lectura: 3 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2; Windows Server 2022,
Windows Server 2019

La Controladora de red admite varios métodos de autenticación para la comunicación

con clientes de administración. Puede usar la autenticación basada en Kerberos o la
autenticación basada en certificados X509. También tiene la opción de no usar ninguna
autenticación para las implementaciones de prueba.

System Center Virtual Machine Manager usa la autenticación basada en Kerberos. Si usa
la autenticación basada en Kerberos, debe configurar un nombre de entidad de
seguridad de servicio (SPN) para la Controladora de red en Active Directory. El SPN es
un identificador único de la instancia de servicio de la Controladora de red, que usa la
autenticación Kerberos para asociar una instancia de servicio a una cuenta de inicio de
sesión de servicio. Para más información, consulte Nombres de entidad de seguridad de
servicio.

Creación de nombres de entidad de seguridad

de servicio (SPN)
La Controladora de red configura automáticamente el SPN. Lo único que debe hacer
usted es proporcionar permisos para que las máquinas de la Controladora de red
registren y modifiquen el SPN.

1. En la máquina del controlador de dominio, abra Usuarios y equipos de Active

Directory.

2. Seleccione Ver > Avanzado.

3. En Equipos, busque una de las cuentas de máquina de la Controladora de red y,

luego, haga clic con el botón derecho y seleccione Propiedades.

4. Seleccione la ficha Seguridad y haga clic en Opciones avanzadas.

5. En la lista, si no se muestran todas las cuentas de máquina de la Controladora de

red o un grupo de seguridad que las tenga todas, haga clic en Agregar para
agregarlas.
 6. Para cada cuenta de máquina de la Controladora de red o un único grupo de
seguridad que contenga estas cuentas:

a. Seleccione la cuenta o grupo y haga clic en Editar.

b. En Permisos, seleccione Validate Write servicePrincipalName (Validar escritura

de servicePrincipalName).

d. Desplácese hacia abajo y, en Propiedades, seleccione:

Read servicePrincipalName

Write servicePrincipalName (Escribir servicePrincipalName)

e. Haga clic en Aceptar dos veces.

7. Repita los pasos del 3 al 6 para cada máquina de la Controladora de red.

8. Cierre Usuarios y equipos de Active Directory.

Error al proporcionar permisos para el registro

o la modificación de SPN
En una nueva implementación de Windows Server 2019, si eligió Kerberos para la
autenticación del cliente REST y no concede permiso para que los nodos de la
Controladora de red registren o modifiquen el SPN, se produce un error en las
operaciones REST en la Controladora de red, lo que impide administrar el SDN.

En el caso de una actualización de Windows Server 2016 a Windows Server 2019, si ha

elegido Kerberos para la autenticación del cliente REST, las operaciones REST no se
bloquean, lo que garantiza la transparencia de las implementaciones de producción
existentes.

Si SPN no está registrado, la autenticación del cliente REST usa NTLM, que es menos
segura. También obtiene un evento crítico en el canal de administración del canal de
eventos NetworkController-Framework que le pide que proporcione permisos para que
los nodos de la Controladora de red registren el SPN. Una vez que proporciona permiso,
la Controladora de red registra el SPN automáticamente y todas las operaciones de
cliente usan Kerberos.

 Sugerencia

Normalmente, puede configurar la Controladora de red para usar una dirección IP

o un nombre DNS para las operaciones basadas en REST. Sin embargo, al
configurar Kerberos, no puede usar una dirección IP para las consultas REST en la
Controladora de red. Por ejemplo, puede usar
<[Link] pero no <[Link] Los
nombres de entidad de seguridad de servicio no pueden funcionar si se usan
direcciones IP.

Si usaba la dirección IP para las operaciones REST junto con la autenticación

Kerberos en Windows Server 2016, la comunicación real habría sido a través de la
autenticación NTLM. En esta implementación, una vez que actualice a
Windows Server 2019, seguirá usando la autenticación basada en NTLM. Para pasar
a la autenticación basada en Kerberos, debe usar el nombre DNS de la
Controladora de red para las operaciones REST y proporcionar permiso para que
los nodos de la Controladora de red registren el SPN.
Configuración de grupos de seguridad
de red con PowerShell
Artículo • 23/01/2023 • Tiempo de lectura: 9 minutos

Se aplica a: Azure Stack HCI, versiones 22H2, 21H2 y 20H2; Windows Server 2022,
Windows Server 2019, Windows Server 2016

En este tema se proporcionan instrucciones para configurar grupos de seguridad de red

(NSG) para administrar el flujo de tráfico de datos mediante Datacenter Firewall para
redes definidas por software (SDN) en Azure Stack HCI mediante Windows PowerShell.
Para habilitar y configurar El firewall del centro de datos, cree grupos de seguridad de
red que se apliquen a una subred o a una interfaz de red. En los scripts de ejemplo de
este tema se usan los comandos de Windows PowerShell exportados del módulo
NetworkController. También puede usar Windows Admin Center para configurar y
administrar grupos de seguridad de red.

Configuración del firewall del centro de datos

para permitir todo el tráfico
Una vez que implemente SDN, debe probar la conectividad de red básica en el nuevo
entorno. Para ello, cree una regla para el firewall del centro de datos que permita todo
el tráfico de red, sin restricciones.

Use las entradas de la tabla siguiente para crear un conjunto de reglas que permitan
todo el tráfico de red entrante y saliente.

IP de IP de Protocolo Puerto de Puerto de Dirección Acción Priority

origen destino origen destino

* * All * * Entrada Allow 100

* * All * * Salida Allow 110

En este ejemplo, creará un grupo de seguridad de red con dos reglas:

1. AllowAll_Inbound : permite que todo el tráfico de red pase a la interfaz de red

donde está configurado este grupo de seguridad de red.
2. AllowAllOutbound: permite que todo el tráfico pase fuera de la interfaz de red.
Este grupo de seguridad de red, identificado por el identificador de recurso
"AllowAll-1" ya está listo para usarse en subredes virtuales e interfaces de red.
En primer lugar, conéctese a uno de los nodos del clúster. Para ello, abra una sesión de
PowerShell:

PowerShell

Enter-PSSession <server-name>

A continuación, ejecute el siguiente script para crear el grupo de seguridad de red:

PowerShell

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "*"
$[Link] = "100"
$[Link] = "Inbound"
$[Link] = "Enabled"
$aclrule1 = new-object [Link]
$[Link] = $ruleproperties
$[Link] = "AllowAll_Inbound"
$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "*"
$[Link] = "110"
$[Link] = "Outbound"
$[Link] = "Enabled"
$aclrule2 = new-object [Link]
$[Link] = $ruleproperties
$[Link] = "AllowAll_Outbound"
$acllistproperties = new-object
[Link]
$[Link] = @($aclrule1, $aclrule2)
New-NetworkControllerAccessControlList -ResourceId "AllowAll" -Properties
$acllistproperties -ConnectionUri <NC REST FQDN>

７ Nota

La referencia de comandos de Windows PowerShell para la Controladora de red se

encuentra en el tema Cmdlets de la Controladora de red.
Uso de grupos de seguridad de red para limitar
el tráfico en una subred
En este ejemplo, creará un grupo de seguridad de red que impide que las máquinas
virtuales (VM) dentro de la subred [Link]/24 se comuniquen entre sí. Este tipo de
grupo de seguridad de red es útil para limitar la capacidad de un atacante de distribuir
lateralmente dentro de la subred, a la vez que permite que las máquinas virtuales
reciban solicitudes desde fuera de la subred, así como para comunicarse con otros
servicios en otras subredes.

IP de origen IP de destino Protocolo Puerto Puerto Dirección Acción Priority

de de
origen destino

[Link] * All * * Entrada Allow 100

* [Link] All * * Salida Allow 101

[Link]/24 * All * * Entrada Block 102

* [Link]/24 All * * Salida Block 103

* * All * * Entrada Allow 104

* * All * * Salida Allow 105

El grupo de seguridad de red creado por el script de ejemplo siguiente, identificado por
la subred de identificador de recurso Subnet-192-168-0-0, ahora se puede aplicar a una
subred de red virtual que use la dirección de subred "[Link]/24". Cualquier interfaz
de red conectada a esa subred de red virtual obtiene automáticamente las reglas de
grupo de seguridad de red anteriores aplicadas.

A continuación se muestra un script de ejemplo para crear este grupo de seguridad de

red mediante la API REST de controladora de red:

PowerShell

import-module networkcontroller
$ncURI = "[Link]
$aclrules = @()

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "[Link]"
$[Link] = "*"
$[Link] = "100"
$[Link] = "Inbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "AllowRouter_Inbound"
$aclrules += $aclrule

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "[Link]"
$[Link] = "101"
$[Link] = "Outbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "AllowRouter_Outbound"
$aclrules += $aclrule

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Deny"
$[Link] = "[Link]/24"
$[Link] = "*"
$[Link] = "102"
$[Link] = "Inbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "DenySubnet_Inbound"
$aclrules += $aclrule

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Deny"
$[Link] = "*"
$[Link] = "[Link]/24"
$[Link] = "103"
$[Link] = "Outbound"
 $[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "DenySubnet_Outbound"

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "*"
$[Link] = "104"
$[Link] = "Inbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "AllowAll_Inbound"
$aclrules += $aclrule

$ruleproperties = new-object
[Link]
$[Link] = "All"
$[Link] = "0-65535"
$[Link] = "0-65535"
$[Link] = "Allow"
$[Link] = "*"
$[Link] = "*"
$[Link] = "105"
$[Link] = "Outbound"
$[Link] = "Enabled"

$aclrule = new-object [Link]

$[Link] = $ruleproperties
$[Link] = "AllowAll_Outbound"
$aclrules += $aclrule

$acllistproperties = new-object
[Link]
$[Link] = $aclrules

New-NetworkControllerAccessControlList -ResourceId "Subnet-192-168-0-0" -

Properties $acllistproperties -ConnectionUri $ncURI

Adición de un grupo de seguridad de red a una

interfaz de red
Una vez que haya creado un grupo de seguridad de red y lo haya asignado a una
subred virtual, es posible que desee invalidar ese grupo de seguridad de red
predeterminado en la subred virtual con un grupo de seguridad de red específico para
una interfaz de red individual. A partir de Windows Server 2019 Datacenter, puede
aplicar grupos de seguridad de red específicos directamente a interfaces de red
conectadas a redes lógicas SDN, además de redes virtuales sdN. Si tiene grupos de
seguridad de red establecidos en la subred virtual conectada a la interfaz de red, se
aplican ambos grupos de seguridad de red y se priorizan los grupos de seguridad de
red de la interfaz de red por encima de los grupos de seguridad de red de subred
virtual.

En este ejemplo, se muestra cómo agregar un grupo de seguridad de red a una red
virtual.

 Sugerencia

También es posible agregar un grupo de seguridad de red al mismo tiempo que se

crea la interfaz de red.

1. Obtenga o cree la interfaz de red a la que agregará el grupo de seguridad de red.

PowerShell

$nic = get-networkcontrollernetworkinterface -ConnectionUri $uri -

ResourceId "MyVM_Ethernet1"

2. Obtenga o cree el grupo de seguridad de red que agregará a la interfaz de red.

PowerShell

$acl = get-networkcontrolleraccesscontrollist -ConnectionUri $uri -

ResourceId "AllowAllACL"

3. Asigne el grupo de seguridad de red a la propiedad AccessControlList de la

interfaz de red.

PowerShell

$[Link][0].[Link] =
$acl

4. Agregue la interfaz de red en la Controladora de red.

 PowerShell

new-networkcontrollernetworkinterface -ConnectionUri $uri -Properties

$[Link] -ResourceId $[Link]

Eliminación de un grupo de seguridad de red

de una interfaz de red
En este ejemplo, se muestra cómo quitar un grupo de seguridad de red de una interfaz
de red. Al quitar un grupo de seguridad de red, se aplica el conjunto predeterminado de
reglas a la interfaz de red. El conjunto predeterminado de reglas permite todo el tráfico
saliente, pero bloquea el entrante. Si desea permitir todo el tráfico entrante, debe seguir
el ejemplo anterior para agregar un grupo de seguridad de red que permita todo el
tráfico entrante y saliente.

1. Obtenga la interfaz de red de la que quitará el grupo de seguridad de red.

PowerShell

$nic = get-networkcontrollernetworkinterface -ConnectionUri $uri -

ResourceId "MyVM_Ethernet1"

2. Asigne $null a la propiedad AccessControlList de ipConfiguration.

PowerShell

$[Link][0].[Link] =
$null

3. Agregue el objeto de la interfaz de red en la Controladora de red.

PowerShell

new-networkcontrollernetworkinterface -ConnectionUri $uri -Properties

$[Link] -ResourceId $[Link]

Auditoría de firewall
A partir de Windows Server 2019, la auditoría de firewall es una nueva funcionalidad del
firewall del centro de datos que registra cualquier flujo que procesan las reglas de
firewall de SDN. Se registran todos los grupos de seguridad de red que tienen
habilitado el registro. Los archivos de registro deben estar en una sintaxis coherente con
los registros de flujo de Azure Network Watcher. Estos registros se pueden usar para
realizar diagnósticos o archivar para su posterior análisis.

A continuación se incluye un script de ejemplo para habilitar la auditoría de firewall en

los servidores host. Actualice las variables del principio y ejecútelo en un clúster de
Azure Stack HCI con la Controladora de red implementada:

PowerShell

$logpath = "C:\test\log1"
$servers = @("sa18n22-2", "sa18n22-3", "sa18n22-4")
$uri = "[Link]

# Create log directories on the hosts

invoke-command -Computername $servers {
param(
$Path
)
mkdir $path -force
} -argumentlist $LogPath

# Set firewall auditing settings on Network Controller

$AuditProperties = new-object
[Link]
$[Link] = $logpath
set-networkcontrollerauditingsettingsconfiguration -connectionuri $uri -
properties $AuditProperties -force | out-null

# Enable logging on each server

$servers = get-networkcontrollerserver -connectionuri $uri
foreach ($s in $servers) {
$[Link] = @("Firewall")
new-networkcontrollerserver -connectionuri $uri -resourceid
$[Link] -properties $[Link] -force | out-null
}

Una vez habilitado, aparece un nuevo archivo en el directorio especificado de cada host
aproximadamente una vez por hora. Debe procesar periódicamente estos archivos y
quitarlos de los hosts. El archivo actual tiene una longitud igual a cero y se bloquea
hasta que se vacía en la marca de hora siguiente:

syntax

PS C:\test\log1> dir

Directory: C:\test\log1

Mode LastWriteTime Length Name

---- ------------- ------ ----
-a---- 7/19/2018 6:28 AM 17055
 SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]
-a---- 7/19/2018 7:28 AM 7880
SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]
-a---- 7/19/2018 8:28 AM 7867
SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]
-a---- 7/19/2018 9:28 AM 10949
SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]
-a---- 7/19/2018 9:28 AM 0
SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
[Link]

Estos archivos contienen una secuencia de eventos de flujo; por ejemplo:

syntax

{
"records": [
{
"properties":{
"Version":"1.0",
"flows":[
{
"flows":[
{
"flowTuples":
["1531963580,[Link],[Link],138,138,U,I,A"],
"portId":"9",
"portName":"7290436D-0422-498A-8EB8-
C6CF5115DACE"
}
],
"rule":"Allow_Inbound"
}
]
},
"operationName":"NetworkSecurityGroupFlowEvents",
"resourceId":"394f647d-2ed0-4c31-87c5-389b8c0c8132",
"time":"20180719:L012620622",
"category":"NetworkSecurityGroupFlowEvent",
"systemId":"d8b3b697-5355-40e2-84d2-1bf2f0e0dc4a"
},

Tenga en cuenta que el registro solo tiene lugar para las reglas que tienen el valor
Logging definido como Enabled; por ejemplo:

syntax
{
"Tags": null,
"ResourceRef": "/accessControlLists/AllowAll",
"InstanceId": "4a63e1a5-3264-4986-9a59-4e77a8b107fa",
"Etag": "W/\"1535a780-0fc8-4bba-a15a-093ecac9b88b\"",
"ResourceMetadata": null,
"ResourceId": "AllowAll",
"Properties": {
"ConfigurationState": null,
"ProvisioningState": "Succeeded",
"AclRules": [
{
"ResourceMetadata": null,
"ResourceRef":
"/accessControlLists/AllowAll/aclRules/AllowAll_Inbound",
"InstanceId": "ba8710a8-0f01-
422b-9038-d1f2390645d7",
"Etag": "W/\"1535a780-0fc8-
4bba-a15a-093ecac9b88b\"",
"ResourceId":
"AllowAll_Inbound",
"Properties": {
"Protocol":
"All",

"SourcePortRange": "0-65535",

"DestinationPortRange": "0-65535",
"Action":
"Allow",

"SourceAddressPrefix": "*",

"DestinationAddressPrefix": "*",
"Priority":
"101",

"Description": null,
"Type":
"Inbound",
"Logging":
"Enabled",

"ProvisioningState": "Succeeded"
}
},
{
"ResourceMetadata": null,
"ResourceRef":
"/accessControlLists/AllowAll/aclRules/AllowAll_Outbound",
"InstanceId": "068264c6-2186-
4dbc-bbe7-f504c6f47fa8",
"Etag": "W/\"1535a780-0fc8-
4bba-a15a-093ecac9b88b\"",
 "ResourceId":
"AllowAll_Outbound",
"Properties": {
"Protocol":
"All",

"SourcePortRange": "0-65535",

"DestinationPortRange": "0-65535",
"Action":
"Allow",

"SourceAddressPrefix": "*",

"DestinationAddressPrefix": "*",
"Priority":
"110",

"Description": null,
"Type":
"Outbound",
"Logging":
"Enabled",

"ProvisioningState": "Succeeded"
}
}
],
"IpConfigurations": [

],
"Subnets": [
{
"ResourceMetadata": null,
"ResourceRef":
"/virtualNetworks/10_0_1_0/subnets/Subnet1",
"InstanceId": "00000000-0000-
0000-0000-000000000000",
"Etag": null,
"ResourceId": null,
"Properties": null
}
]
}
}

Pasos siguientes
Para obtener información relacionada, consulte:

Introducción al firewall del centro de datos

Introducción a la controladora de red
SDN en Azure Stack HCI y Windows Server
Emparejamiento de redes virtuales de
Azure
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

El emparejamiento de redes virtuales permite conectar dos redes virtuales sin

problemas. Una vez emparejadas, para fines de conectividad, las redes virtuales
aparecen como una.

Las ventajas del uso del emparejamiento de redes virtuales son las siguientes:

El tráfico entre máquinas virtuales de las redes virtuales emparejadas se enruta a

través de la infraestructura troncal solo a través de direcciones IP privadas. La
comunicación entre las redes virtuales no requiere internet ni puertas de enlace
públicas.

Baja latencia, conexión de gran ancho de banda entre los recursos de redes
virtuales diferentes.

La capacidad de los recursos de una red virtual para comunicarse con los de otra
red virtual.

No hay tiempo de inactividad en los recursos de ninguna de las redes virtuales al

crear el emparejamiento.

Requisitos y restricciones
El emparejamiento de redes virtuales tiene algunos requisitos y restricciones:

Las redes virtuales emparejadas deben:

Tener espacios de direcciones IP no superpuestos

Ser administrado por la misma controladora de red

Una vez emparejada una red virtual con otra red virtual, no puede agregar ni
eliminar intervalos de direcciones en el espacio de direcciones.

 Sugerencia
 Si necesita agregar intervalos de direcciones:

1. Quite el emparejamiento.
2. Agregue el espacio de direcciones.
3. Vuelva a agregar el emparejamiento.

Dado que el emparejamiento de redes virtuales está entre dos redes virtuales, no
hay ninguna relación transitiva derivada entre emparejamientos. Por ejemplo, si
empareja virtualNetworkA con virtualNetworkB y virtualNetworkB con
virtualNetworkC, virtualNetworkA no se empareja con virtualNetworkC.

Conectividad
Después de emparejar redes virtuales, los recursos de cualquiera de las redes virtuales
pueden conectarse directamente con los recursos de la red virtual emparejada.

La latencia de red entre máquinas virtuales en redes virtuales emparejadas es la

misma que la latencia dentro de una sola red virtual.

El rendimiento de red se basa en el ancho de banda permitido para la máquina

virtual. No hay restricciones adicionales con respecto al ancho de banda en el
emparejamiento.

El tráfico entre máquinas virtuales de redes virtuales emparejadas se enruta

directamente a través de la infraestructura troncal, no a través de una puerta de
enlace o a través de la red pública de Internet.

Las máquinas virtuales de una red virtual pueden acceder al equilibrador de carga
interno de la red virtual emparejada.

Puede aplicar listas de control de acceso (ACL) en una red virtual para bloquear el
acceso a otras redes virtuales o subredes si lo desea. Si abre la conectividad completa
entre redes virtuales emparejadas (que es la opción predeterminada), puede aplicar ACL
a subredes o máquinas virtuales específicas para bloquear o denegar el acceso
específico. Para más información sobre las ACL, consulte Uso de listas de Access Control
(ACL) para administrar el tráfico de red del centro de datos Flow.

Encadenamiento de servicios
Puede configurar rutas definidas por el usuario que apunten a máquinas virtuales de
redes virtuales emparejadas como la dirección IP del próximo salto, para habilitar el
encadenamiento de servicios. El encadenamiento de servicios permite dirigir el tráfico
desde una red virtual a una aplicación virtual, en una red virtual emparejada, a través de
rutas definidas por el usuario.

Puede implementar redes de concentrador y radio, donde la red virtual del

concentrador puede hospedar componentes de infraestructura, como una aplicación
virtual de red. Todas las redes virtuales de radio se emparejan con la red virtual de
centro. El tráfico puede fluir a través de aplicaciones virtuales de red en la red virtual del
concentrador.

El emparejamiento de red virtual permite que el próximo salto de una ruta definida por
el usuario sea la dirección IP de una máquina virtual de la red virtual emparejada. Para
más información acerca de las rutas definidas por el usuario, consulte Uso de
aplicaciones virtuales de red en una red virtual.

Puertas de enlace y conectividad local

Cada red virtual, independientemente de si está emparejada con otra red virtual, todavía
puede tener su propia puerta de enlace para conectarse a una red local. Al emparejar
redes virtuales, también puede configurar la puerta de enlace en la red virtual
emparejada como un punto de tránsito a una red local. En este caso, la red virtual que
usa una puerta de enlace remota no puede tener su propia puerta de enlace. Una red
virtual solo puede tener una puerta de enlace que pueda ser una puerta de enlace local
o remota (en la red virtual emparejada).

Supervisión
Al emparejar dos redes virtuales, debe configurar un emparejamiento para cada red
virtual del emparejamiento.

Puede supervisar el estado de la conexión de emparejamiento, que puede encontrarse

en uno de los siguientes estados:

Iniciado: Se muestra al crear el emparejamiento de la primera red virtual a la

segunda.

Conectado: Se muestra después de crear el emparejamiento de la segunda red

virtual a la primera. El estado de emparejamiento para la primera red virtual
cambia de Iniciado a Conectado. Ambos pares de red virtual deben tener el estado
Conectado antes de establecer correctamente un emparejamiento de red virtual.

Desconectado: Se muestra si una red virtual se desconecta de otra red virtual.

[infografía de los estados]

Pasos siguientes
Configurar el emparejamiento de redes virtuales: en este procedimiento, se usa
Windows PowerShell para buscar la red lógica del proveedor de HNV para crear dos
redes virtuales, cada una con una subred. También se configura el emparejamiento entre
las dos redes virtuales.
Configuración del emparejamiento de
red virtual
Artículo • 21/12/2022 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En este procedimiento, se usa Windows PowerShell para crear dos redes virtuales, cada
una con una subred. A continuación, configure el emparejamiento entre las dos redes
virtuales para habilitar la conectividad entre ellas.

Paso 1. Crear la primera red virtual.

Paso 2. Crear la segunda red virtual.

Paso 3. Configuración del emparejamiento de la primera red virtual a la segunda

red virtual

Paso 4. Configuración del emparejamiento de la segunda red virtual a la primera

red virtual

） Importante

No olvide actualizar las propiedades de su entorno.

Paso 1. Crear la primera red virtual.

En este paso, usará Windows PowerShell la red lógica del proveedor de HNV para crear
la primera red virtual con una subred. El siguiente script de ejemplo crea la red virtual de
Contoso con una subred.

PowerShell

#Find the HNV Provider Logical Network

$logicalnetworks = Get-NetworkControllerLogicalNetwork -ConnectionUri $uri

foreach ($ln in $logicalnetworks) {
if ($[Link] -eq "True") {
$HNVProviderLogicalNetwork = $ln
}
}
 #Create the Virtual Subnet

$vsubnet = new-object [Link]

$[Link] = "Contoso"
$[Link] = new-object
[Link]
$[Link] = "[Link]/24"
$uri=”[Link]

#Create the Virtual Network

$vnetproperties = new-object
[Link]
$[Link] = new-object
[Link]
$[Link] = @("[Link]/24")
$[Link] = $HNVProviderLogicalNetwork
$[Link] = @($vsubnet)
New-NetworkControllerVirtualNetwork -ResourceId "Contoso_VNet1" -
ConnectionUri $uri -Properties $vnetproperties

Paso 2. Crear la segunda red virtual.

En este paso, creará una segunda red virtual con una subred. El siguiente script de
ejemplo crea la red virtual de Woodgrove con una subred.

PowerShell

#Create the Virtual Subnet

$vsubnet = new-object [Link]

$[Link] = "Woodgrove"
$[Link] = new-object
[Link]
$[Link] = "[Link]/24"
$uri=”[Link]

#Create the Virtual Network

$vnetproperties = new-object
[Link]
$[Link] = new-object
[Link]
$[Link] = @("[Link]/24")
$[Link] = $HNVProviderLogicalNetwork
$[Link] = @($vsubnet)
New-NetworkControllerVirtualNetwork -ResourceId "Woodgrove_VNet1" -
ConnectionUri $uri -Properties $vnetproperties
Paso 3. Configuración del emparejamiento de
la primera red virtual a la segunda red virtual
En este paso, configurará el emparejamiento entre la primera red virtual y la segunda
red virtual que creó en los dos pasos anteriores. El siguiente script de ejemplo establece
el emparejamiento de redes virtuales Contoso_vnet1a Woodgrove_vnet1.

PowerShell

$peeringProperties = New-Object
[Link]
$vnet2 = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId
"Woodgrove_VNet1"
$[Link] = $vnet2

#Indicate whether communication between the two virtual networks

$[Link] = $true

#Indicates whether forwarded traffic is allowed across the vnets

$[Link] = $true

#Indicates whether the peer virtual network can access this virtual networks
gateway
$[Link] = $false

#Indicates whether this virtual network uses peer virtual networks gateway
$[Link] =$false

New-NetworkControllerVirtualNetworkPeering -ConnectionUri $uri -

VirtualNetworkId “Contoso_vnet1” -ResourceId “ContosotoWoodgrove” -
Properties $peeringProperties

） Importante

Después de crear este emparejamiento, el estado de la red virtual muestra Iniciado.

Paso 4. Configuración del emparejamiento de

la segunda red virtual a la primera red virtual
En este paso, configurará el emparejamiento entre la segunda red virtual y la primera
red virtual que creó en los pasos 1 y 2 anteriores. El siguiente script de ejemplo
establece el emparejamiento de redes virtuales Woodgrove_vnet1a Contoso_vnet1.

PowerShell
 $peeringProperties = New-Object
[Link]
$vnet2=Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId
"Contoso_VNet1"
$[Link] = $vnet2

# Indicates whether communication between the two virtual networks is

allowed
$[Link] = $true

# Indicates whether forwarded traffic will be allowed across the vnets

$[Link] = $true

# Indicates whether the peer virtual network can access this virtual
network's gateway
$[Link] = $false

# Indicates whether this virtual network will use peer virtual network's
gateway
$[Link] =$false

New-NetworkControllerVirtualNetworkPeering -ConnectionUri $uri -

VirtualNetworkId “Woodgrove_vnet1” -ResourceId “WoodgrovetoContoso” -
Properties $peeringProperties

Después de crear este emparejamiento, el estado de emparejamiento de red virtual

muestra Conectado para ambos pares. Ahora, las máquinas virtuales de una red virtual
pueden comunicarse con máquinas virtuales de la red virtual emparejada.
Rendimiento de la puerta de enlace de
Windows Server 2019
Artículo • 18/01/2023 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Azure Stack HCI,
versiones 21H2 y 20H2

En Windows Server 2016, una de las preocupaciones del cliente era la incapacidad de la
puerta de enlace de SDN para cumplir los requisitos de rendimiento de las redes
modernas. El rendimiento de red de los túneles IPsec y GRE tenía limitaciones con el
rendimiento de conexión único para la conectividad de IPsec, que es de
aproximadamente 300 Mbps y para la conectividad GRE es de aproximadamente 2,5
Gbps.

Hemos mejorado significativamente en Windows Server 2019, con los números que se
elevan a 1,8 Gbps y 15 Gbps para conexiones IPsec y GRE, respectivamente. Todo esto,
con reducciones significativas en los ciclos de CPU/por byte, lo que proporciona un
rendimiento ultra-alto con mucho menos uso de CPU.

Habilitación del alto rendimiento con puertas

de enlace en Windows Server 2019
Para las conexiones GRE, una vez que implemente o actualice las compilaciones de
Windows Server 2019 en las máquinas virtuales de puerta de enlace, debería ver
automáticamente el rendimiento mejorado. No hay pasos manuales implicados.

En el caso de las conexiones IPsec, de forma predeterminada, al crear la conexión para

las redes virtuales, obtendrá la ruta de acceso de datos y los números de rendimiento de
Windows Server 2016. Para habilitar la ruta de acceso de datos de Windows Server 2019,
haga lo siguiente:

1. En una máquina virtual de puerta de enlace de SDN, vaya a Consola de servicios

([Link]).
2. Busque el servicio denominado Servicio de puerta de enlace de Azure y
establezca el tipo de inicio en Automático.
3. Reinicie la máquina virtual de puerta de enlace. Las conexiones activas de esta
puerta de enlace conmutan por error a una máquina virtual de puerta de enlace
redundante.
 4. Repita los pasos anteriores para el resto de las máquinas virtuales de la puerta de
enlace.

 Sugerencia

Para obtener los mejores resultados de rendimiento, asegúrese de que

cipherTransformationConstant y authenticationTransformConstant en la
configuración quickMode de la conexión IPsec usa el conjunto de cifrado
GCMAES256 .

Para obtener el máximo rendimiento, el hardware del host de puerta de enlace

debe admitir conjuntos de instrucciones de CPU AES-NI y PCLMULQDQ. Están
disponibles en cualquier Westmere (32nm) y versiones posteriores intel CPU,
excepto en los modelos en los que AES-NI se ha deshabilitado. Puede consultar la
documentación del proveedor de hardware para ver si la CPU admite conjuntos de
instrucciones de CPU AES-NI y PCLMULQDQ.

A continuación se muestra un ejemplo REST de conexión IPsec con algoritmos de

seguridad óptimos:

PowerShell

# NOTE: The virtual gateway must be created before creating the IPsec
connection. More details here.
# Create a new object for Tenant Network IPsec Connection
$nwConnectionProperties = New-Object
[Link]

# Update the common object properties

$[Link] = "IPSec"
$[Link] = 2000000
$[Link] = 2000000

# Update specific properties depending on the Connection Type

$[Link] = New-Object
[Link]
$[Link] = "PSK"
$[Link] = "111_aaa"

$[Link] = New-Object
[Link]
$[Link] =
"PFS2048"
$[Link]
ationConstant = "GCMAES256"
$[Link]
stant = "GCMAES256"
$[Link] =
 3600
$[Link] =
500
$[Link] =
2000

$[Link] = New-Object
[Link]
$[Link] =
"Group2"
$[Link] =
"SHA256"
$[Link] =
"AES256"
$[Link] =
28800
$[Link] =
2000

# L3 specific configuration (leave blank for IPSec)

$[Link] = @()
$[Link] = @()

# Update the IPv4 Routes that are reachable over the site-to-site VPN Tunnel
$[Link] = @()
$ipv4Route = New-Object [Link]
$[Link] = "<<On premise subnet that must be reachable
over the VPN tunnel. Ex: [Link]/24>>"
$[Link] = 10
$[Link] += $ipv4Route

# Tunnel Destination (Remote Endpoint) Address

$[Link] = "<<Public IP address of the
On-Premise VPN gateway. Ex: [Link]>>"

# Add the new Network Connection for the tenant. Note that the virtual
gateway must be created before creating the IPsec connection. $uri is the
REST URI of your deployment and must be in the form of “[Link] URI>”
New-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri $uri -
VirtualGatewayId $[Link] -ResourceId "Contoso_IPSecGW" -
Properties $nwConnectionProperties -Force

Resultados de pruebas
Hemos realizado pruebas de rendimiento exhaustivas para las puertas de enlace de SDN
en nuestros laboratorios de prueba. En las pruebas, hemos comparado el rendimiento
de red de puerta de enlace con Windows Server 2019 en escenarios de SDN y
escenarios que no son de SDN. Puede encontrar los resultados y los detalles de
configuración de pruebas capturados en el artículo de blog aquí .
Asignación de ancho de banda de
puerta de enlace
Artículo • 06/01/2023 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Azure Stack HCI, versiones
22H2, 21H2 y 20H2

En Windows Server 2016, el ancho de banda de túnel individual para IPsec, GRE y L3 era
una proporción de la capacidad total de la puerta de enlace. Por lo tanto, los clientes
proporcionarían la capacidad de puerta de enlace en función del ancho de banda TCP
estándar que espera que se salga de la máquina virtual de puerta de enlace.

Además, el ancho de banda máximo del túnel IPsec en la puerta de enlace estaba
limitado a (capacidad de puerta de enlace de 3/20)*proporcionada por el cliente. Por
ejemplo, si establece la capacidad de la puerta de enlace en 1000 Mbps, la capacidad
del túnel IPsec sería de 150 Mbps. Las relaciones equivalentes para los túneles GRE y L3
son 1/5 y 1/2, respectivamente.

Aunque esto funcionaba para la mayoría de las implementaciones, el modelo de

relación fija no era adecuado para entornos de alto rendimiento. Incluso cuando las
tasas de transferencia de datos eran altas (por ejemplo, más de 40 Gbps), el rendimiento
máximo de los túneles de puerta de enlace sdN se limitaba debido a factores internos.

En Windows Server 2019, para un tipo de túnel, se fija el rendimiento máximo. Incluso si
el host o la máquina virtual de puerta de enlace admite NIC con un rendimiento mucho
mayor, se fija el rendimiento máximo de túnel disponible. Otro problema que se
encarga de es el exceso de aprovisionamiento arbitrario de las puertas de enlace, lo que
sucede al proporcionar un número muy alto para la capacidad de la puerta de enlace.

El rendimiento máximo disponible para los distintos tipos de túnel son:

IPsec = 5 Gbps

GRE = 15 Gbps

L3 = 5 Gbps

７ Nota

De forma predeterminada, la asignación de ancho de banda de IPsec usa Windows

Server 2016 comportamiento descrito más adelante en este artículo. Para obtener
 el rendimiento máximo (5 Gbps), siga estos pasos en cada máquina virtual de
puerta de enlace:

1. Ejecute el siguiente comando para habilitar el servicio de puerta de enlace:

PowerShell

Set-Service gatewayservice -StartupType Automatic -Status Running

2. Reinicie la máquina virtual de puerta de enlace.

Cálculo de la capacidad de la puerta de enlace

Lo ideal es establecer la capacidad de rendimiento de la puerta de enlace en el
rendimiento disponible para la máquina virtual de puerta de enlace. Por lo tanto, por
ejemplo, si tiene una sola máquina virtual de puerta de enlace y el rendimiento de la
NIC del host subyacente es de 25 Gbps, el rendimiento de la puerta de enlace también
se puede establecer en 25 Gbps.

Si usa una puerta de enlace solo para conexiones IPsec, la capacidad fija máxima
disponible es de 5 Gbps. Por lo tanto, por ejemplo, si aprovisiona conexiones IPsec en la
puerta de enlace, solo puede aprovisionar un ancho de banda agregado (entrante y
saliente) como 5 Gbps.

Si usa la puerta de enlace para la conectividad IPsec y GRE, puede aprovisionar un

máximo de 5 Gbps de rendimiento de IPsec o un máximo de 15 Gbps de rendimiento
gre. Por lo tanto, por ejemplo, si aprovisiona 2 Gbps de rendimiento de IPsec, tiene 3
Gbps de rendimiento de IPsec para aprovisionar en la puerta de enlace o 9 Gbps de
rendimiento gre a la izquierda.

Para poner esto en términos más matemáticos:

Capacidad total de la puerta de enlace = 25 Gbps

Capacidad total de IPsec disponible = 5 Gbps (fija)

Capacidad total de GRE disponible = 15 Gbps (fija)

Relación de rendimiento de IPsec para esta puerta de enlace = 25/5 = 5 Gbps

Proporción de rendimiento de GRE para esta puerta de enlace = 25/15 = 5/3 Gbps

Por ejemplo, si asigna 2 Gbps de rendimiento de IPsec a un cliente:

Capacidad disponible restante en la puerta de enlace = Capacidad total de la puerta de
enlace: relación de rendimiento de IPsec*IPsec rendimiento asignado (capacidad usada)

25–5*2 = 15 Gbps

Rendimiento de IPsec restante que puede asignar en la puerta de enlace

5-2 = 3 Gbps

Rendimiento de GRE restante que puede asignar en la puerta de enlace = Capacidad

restante de la relación de rendimiento de puerta de enlace o GRE

15*3/5 = 9 Gbps

La relación de rendimiento varía en función de la capacidad total de la puerta de enlace.

Una cosa que debe tener en cuenta es que debe establecer la capacidad total en el
ancho de banda TCP disponible para la máquina virtual de puerta de enlace. Si tiene
varias máquinas virtuales hospedadas en la puerta de enlace, debe ajustar la capacidad
total de la puerta de enlace en consecuencia.

Además, si la capacidad de la puerta de enlace es menor que la capacidad total de túnel

disponible, la capacidad total del túnel disponible se establece en la capacidad de la
puerta de enlace. Por ejemplo, si establece la capacidad de puerta de enlace en 4 Gbps,
la capacidad total disponible para IPsec, L3 y GRE se establece en 4 Gbps, dejando la
relación de rendimiento de cada túnel a 1 Gbps.

comportamiento de Windows Server 2016

El algoritmo de cálculo de capacidad de la puerta de enlace para Windows Server 2016
permanece sin cambios. En Windows Server 2016, el ancho de banda máximo del túnel
IPsec estaba limitado a (capacidad de puerta de enlace de 3/20)*. Las relaciones
equivalentes para los túneles GRE y L3 eran 1/5 y 1/2, respectivamente.

Si va a actualizar de Windows Server 2016 a Windows Server 2019:

1. Túneles GRE y L3: La lógica de asignación de Windows Server 2019 surte efecto
una vez que los nodos de controladora de red se actualicen a Windows Server
2019

2. Túneles IPSec: La lógica de asignación de puerta de enlace de Windows Server

2016 continúa funcionando hasta que todas las puertas de enlace del grupo de
puertas de enlace se actualicen a Windows Server 2019. Para todas las puertas de
enlace del grupo de puertas de enlace, debe establecer el servicio de puerta de
enlace de Azure en Automático.
７ Nota

Es posible que después de actualizar a Windows Server 2019, una puerta de enlace
se sobreaprovisione (a medida que la lógica de asignación cambia de Windows
Server 2016 a Windows Server 2019). En este caso, las conexiones existentes en la
puerta de enlace siguen existiendo. El recurso REST de la puerta de enlace produce
una advertencia de que la puerta de enlace está aprovisionada por encima del
aprovisionamiento. En este caso, debe mover algunas conexiones a otra puerta de
enlace.
Solucionar problemas de SDN
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

Los temas de esta sección proporcionan información sobre cómo solucionar problemas
de las tecnologías de redes definidas por software (SDN) que se incluyen en Azure Stack
HCI, Windows Server 2019 y Windows Server 2016.

７ Nota

Para obtener documentación adicional sobre redes definidas por software, puede
usar las siguientes secciones de la biblioteca.

Tecnologías de SDN
Planear SDN
Implementar SDN
Administrar SDN
Seguridad para SDN

Esta sección contiene los temas siguientes.

Solución de problemas de la pila de redes definidas por software de

Windows Server
Entrada de blog Solución de problemas de SDN: Errores de comunicación UDP y
cambio del certificado de controladora de red
Entrada de blog Solución de problemas de certificados en redes definidas por
software (SDN)
Entrada de blog How to find the SDN gateway local address for BGP peering in
Windows Server 2016
Entrada de blog Solución de problemas de configuración de la configuración del
ancho de banda de VPN de PUERTA de enlace de RAS de SDN en Virtual Machine
Manager
Solución de problemas de la pila de
redes definidas por software de
Windows Server
Artículo • 21/12/2022 • Tiempo de lectura: 34 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Azure Stack HCI, versiones 21H2 y 20H2

En esta guía se examinan los escenarios comunes de errores y errores de redes definidas
por software (SDN) y se describe un flujo de trabajo de solución de problemas que usa
las herramientas de diagnóstico disponibles.

Para obtener más información sobre SDN, consulte Redes definidas por software.

Tipos de errores
La siguiente lista representa la clase de problemas que se ven con más frecuencia con
Virtualización de red de Hyper-V (HNVv1) en Windows Server 2012 R2 desde
implementaciones de producción en el mercado y coincide de muchas maneras con los
mismos tipos de problemas detectados en Windows Server 2016 HNVv2 con la nueva
pila de red definida por software (SDN).

La mayoría de los errores se pueden clasificar en un pequeño conjunto de clases:

Configuración no válida o no admitida Un usuario invoca la API NorthBound

incorrectamente o con una directiva no válida.

Error en la aplicación de directiva La directiva de controladora de red no se

entregó a un host de Hyper-V, retrasada o no actualizada en todos los hosts de
Hyper-V (por ejemplo, después de una migración en vivo).

Desfase de configuración o error de software Problemas de ruta de acceso de

datos que dan lugar a paquetes descartados.

Error externo relacionado con el hardware o los controladores de NIC o el tejido

de red subyacente Descargas de tareas de comportamiento erróneo (como VMQ)
o tejido de red subyacente mal configurado (por ejemplo, MTU)

Esta guía de solución de problemas examina cada una de estas categorías de

errores y recomienda procedimientos recomendados y herramientas de
 diagnóstico disponibles para identificar y corregir el error.

Herramientas de diagnóstico
Antes de analizar los flujos de trabajo de solución de problemas para cada uno de estos
tipos de errores, vamos a examinar las herramientas de diagnóstico disponibles.

Para usar las herramientas de diagnóstico de controladora de red (ruta de acceso de

control), primero debe instalar la característica de RSAT-NetworkController e importar el
NetworkControllerDiagnostics módulo:

PowerShell

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools

Import-Module NetworkControllerDiagnostics

Para usar las herramientas de diagnóstico de diagnóstico de HNV (ruta de acceso de

datos), debe importar el HNVDiagnostics módulo:

PowerShell

# Assumes RSAT-NetworkController feature has already been installed

Import-Module hnvdiagnostics

Diagnósticos de controladora de red

Estos cmdlets se documentan en TechNet en el tema cmdlet de diagnóstico de
controladora de red. Ayudan a identificar problemas con la coherencia de la directiva de
red en la ruta de acceso de control entre los nodos de controladora de red y entre la
controladora de red y los agentes de host nc que se ejecutan en los hosts de Hyper-V.

Los cmdlets Debug-ServiceFabricNodeStatus y Get-NetworkControllerReplica deben

ejecutarse desde una de las máquinas virtuales del nodo controladora de red. Todos los
demás cmdlets de diagnóstico de NC se pueden ejecutar desde cualquier host, que
tiene conectividad con la controladora de red y se encuentra en el grupo de seguridad
Administración de controladores de red (Kerberos) o tiene acceso al certificado X.509
para administrar la controladora de red.

Diagnósticos de host de Hyper-V

Estos cmdlets se documentan en TechNet en el tema del cmdlet de diagnóstico de
Virtualización de red de Hyper-V (HNV). Ayudan a identificar problemas en la ruta de
acceso de datos entre las máquinas virtuales de inquilino (Este/Oeste) y el tráfico de
entrada a través de una VIP de SLB (norte/sur).

Debug-VirtualMachineQueueOperation, Get-CustomerRoute, Get-PACAMapping, Get-

ProviderAddress, Get-VMNetworkAdapterPortId, Get-VMSwitchExternalPortId y Test-
EncapOverheadSettings son todas las pruebas locales que se pueden ejecutar desde
cualquier host de Hyper-V. Los otros cmdlets invocan pruebas de ruta de acceso de
datos a través de la controladora de red y, por tanto, necesitan acceso a la controladora
de red, como se ha descrito anteriormente.

GitHub
Microsoft/SDN GitHub Repo tiene muchos scripts y flujos de trabajo de ejemplo que
se basan en estos cmdlets de fábrica. En concreto, los scripts de diagnóstico se pueden
encontrar en la carpeta Diagnósticos . Ayúdenos a contribuir a estos scripts mediante
el envío de solicitudes de incorporación de cambios.

Solución de problemas de flujos de trabajo y

guías

[Hoster] Validación del estado del sistema

Hay un recurso incrustado denominado Estado de configuración en varios de los
recursos de controladora de red. El estado de configuración proporciona información
sobre el estado del sistema, incluida la coherencia entre la configuración de la
controladora de red y el estado real (en ejecución) en los hosts de Hyper-V.

Para comprobar el estado de configuración, ejecute lo siguiente desde cualquier host de

Hyper-V con conectividad a la controladora de red.

７ Nota

El valor del parámetro NetworkController debe ser el FQDN o la dirección IP en

función del nombre del firmante del certificado X.509 >creado para controladora
de red.

El parámetro Credential solo debe especificarse si la controladora de red usa la

autenticación Kerberos (típica en las implementaciones de VMM). La credencial
debe ser para un usuario que se encuentra en el grupo de seguridad de
administración de controladores de red.
 Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP>
[-Credential <PS Credential>]

# Healthy State Example - no status reported

$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController [Link]
-Credential $cred

Fetching ResourceType: accessControlLists

Fetching ResourceType: servers
Fetching ResourceType: virtualNetworks
Fetching ResourceType: networkInterfaces
Fetching ResourceType: virtualGateways
Fetching ResourceType: loadbalancerMuxes
Fetching ResourceType: Gateways

A continuación se muestra un mensaje de estado de configuración de ejemplo:

Fetching ResourceType: servers

----------------------------------------------------------------------------
-----------------------------
ResourcePath: [Link]
0056-4b10-8058-b8c04f395931
Status: Warning

Source: SoftwareLoadBalancerManager
Code: HostNotConnectedToController
Message: Host is not Connected.
----------------------------------------------------------------------------
------------------------------

７ Nota

Hay un error en el sistema en el que los recursos de interfaz de red para la NIC de
máquina virtual de tránsito de mux de SLB se encuentran en estado de error con el
error "Conmutador virtual: host no conectado al controlador". Este error se puede
omitir de forma segura si la configuración de IP del recurso NIC de máquina virtual
está establecida en una dirección IP del grupo de direcciones IP de la red lógica de
tránsito. Hay un segundo error en el sistema en el que los recursos de interfaz de
red de las NIC de máquina virtual del proveedor HNV de puerta de enlace se
encuentran en estado de error con el error "Virtual Switch - PortBlocked". Este error
también se puede omitir de forma segura si la configuración de IP en el recurso
NIC de máquina virtual está establecida en NULL (por diseño).
En la tabla siguiente se muestra la lista de códigos de error, mensajes y acciones de
seguimiento que se deben realizar en función del estado de configuración observado.

Código Mensaje Acción

Unknown Error desconocido

HostUnreachable No se puede acceder Comprobación de la

a la máquina host conectividad de red de
administración entre
controladora de red y host

PAIpAddressExhausted Direcciones IP de PA Aumento del tamaño del grupo

agotadas de direcciones IP de la subred
lógica del proveedor HNV

PAMacAddressExhausted Las direcciones Mac Aumento del intervalo de

de PA agotadas grupos de Mac

PAAddressConfigurationFailure No se pudieron Compruebe la conectividad de

rellenar las red de administración entre
direcciones PA en el controladora de red y host.
host

CertificateNotTrusted El certificado no es de Corrija los certificados usados

confianza para la comunicación con el
host.

CertificateNotAuthorized Certificado no Corrija los certificados usados

autorizado para la comunicación con el
host.

PolicyConfigurationFailureOnVfp Error al configurar Se trata de un error en tiempo

directivas de VFP de ejecución. No hay soluciones
alternativas definitivas. Recopilar
registros.

PolicyConfigurationFailure Error al insertar No hay acciones definitivas. Esto

directivas en los se debe a un error en el
hosts, debido a procesamiento de estado
errores de objetivo en los módulos de
comunicación u otros controladora de red. Recopilar
errores en registros.
NetworkController.
Código Mensaje Acción

HostNotConnectedToController El host aún no está El perfil de puerto no se aplica

conectado a la en el host o el host no es
controladora de red accesible desde la controladora
de red. Compruebe que la clave
del Registro HostID coincide con
el identificador de instancia del
recurso de servidor.

MultipleVfpEnabledSwitches Hay varios Elimine uno de los

conmutadores modificadores, ya que el agente
habilitados para VFp de host de controladora de red
en el host solo admite un vSwitch con la
extensión VFP habilitada.

PolicyConfigurationFailure No se pudieron Compruebe si se han

insertar directivas de implementado los certificados
red virtual para una adecuados (el nombre del
vmNic debido a firmante del certificado debe
errores de certificado coincidir con el FQDN del host).
o errores de Compruebe también la
conectividad conectividad de host con la
controladora de red.

PolicyConfigurationFailure No se pudieron Compruebe si se han

insertar directivas de implementado los certificados
vSwitch para una adecuados (el nombre del
vmNic debido a firmante del certificado debe
errores de certificado coincidir con el FQDN del host).
o errores de Compruebe también la
conectividad conectividad de host con la
controladora de red.

PolicyConfigurationFailure Failed to push Firewall Compruebe si se han

policies for a VmNic implementado los certificados
due to certificate adecuados (el nombre del
errors or connectivity firmante del certificado debe
errors (No se coincidir con el FQDN del host).
pudieron insertar Compruebe también la
directivas de firewall conectividad de host con la
para una VmNic controladora de red.
debido a errores de
certificado o errores
de conectividad)
Código Mensaje Acción

DistributedRouterConfigurationFailure No se pudo Error de pila TCPIP. Puede

configurar la requerir la limpieza de las VNIC
configuración del del host de recuperación ante
enrutador distribuido desastres y pa en el servidor en
en la vNic del host el que se notificó este error.

DhcpAddressAllocationFailure Error de asignación Compruebe si el atributo de

de direcciones DHCP dirección IP estática está
para una vmNic configurado en el recurso de
NIC.

CertificateNotTrusted No se pudo conectar Compruebe el código numérico

CertificateNotAuthorized a Mux debido a proporcionado en el código del
errores de red o mensaje de error: corresponde
certificado al código de error winsock. Los
errores de certificado son
granulares (por ejemplo, el
certificado no se puede
comprobar, el certificado no
está autorizado, etc.).

HostUnreachable MUX es incorrecto (el El par BGP en la máquina virtual

caso común es RRAS (máquina virtual BGP) o el
BGPRouter conmutador superior del
desconectado) bastidor (ToR) no es accesible o
no se puede emparejar
correctamente. Compruebe la
configuración de BGP en el
recurso de multiplexador de
software Load Balancer y el par
BGP (máquina virtual ToR o
RRAS).

HostNotConnectedToController El agente host de SLB Compruebe que el servicio

no está conectado agente host SLB se está
ejecutando; Consulte los
registros del agente host de SLB
(ejecución automática) por
motivos por los que, en caso de
que SLBM (NC) rechace el
certificado presentado por el
estado de ejecución del agente
host mostrará información
matizado.
 Código Mensaje Acción

PortBlocked El puerto VFP está Compruebe si hay otros errores,

bloqueado, debido a lo que puede provocar que las
la falta de directivas directivas no estén configuradas.
de red virtual o ACL.

Sobrecargado MuX del equilibrador Problema de rendimiento con

de carga está MUX
sobrecargado

RoutePublicationFailure El MUX del Compruebe si el MUX tiene

equilibrador de carga conectividad con los
no está conectado a enrutadores BGP y que el
un enrutador BGP emparejamiento BGP está
configurado correctamente.

VirtualServerUnreachable MuX del equilibrador Comprobación de la

de carga no está conectividad entre SLBM y MUX
conectado al
administrador de SLB

QosConfigurationFailure No se pudieron Compruebe si hay suficiente

configurar directivas ancho de banda disponible para
de QOS todas las máquinas virtuales si
se usa la reserva de QOS.

Comprobación de la conectividad de red entre la controladora de

red y el host de Hyper-V (servicio del agente de host nc)
Ejecute el siguiente comando netstat para validar que hay tres conexiones ESTABLISHED
entre el agente de host nc y los nodos de controladora de red y un socket LISTENING en
el host de Hyper-V.

ESCUCHANDO en el puerto TCP:6640 en el host de Hyper-V (servicio del agente de

host nc)
Dos conexiones establecidas desde la dirección IP del host de Hyper-V en el
puerto 6640 a la dirección IP del nodo NC en puertos efímeros (> 32000)
Una conexión establecida desde la dirección IP del host de Hyper-V en el puerto
efímero a la dirección IP de REST de la controladora de red en el puerto 6640

７ Nota

Solo puede haber dos conexiones establecidas en un host de Hyper-V si no hay

ninguna máquina virtual de inquilino implementada en ese host determinado.
 netstat -anp tcp |findstr 6640

# Successful output
TCP [Link]:6640 [Link]:0 LISTENING
TCP [Link]:6640 [Link]:50095 ESTABLISHED
TCP [Link]:6640 [Link]:62514 ESTABLISHED
TCP [Link]:50023 [Link]:6640 ESTABLISHED

Comprobación de servicios de agente de host

La controladora de red se comunica con dos servicios de agente de host en los hosts de
Hyper-V: agente de host de SLB y agente de host de NC. Es posible que uno o ambos
servicios no se ejecuten. Compruebe su estado y reinicie si no se están ejecutando.

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag

Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

Comprobación del estado de la controladora de red

Si no hay tres conexiones ESTABLISHED o si la controladora de red no responde,
compruebe que todos los nodos y módulos de servicio están en funcionamiento
mediante los siguientes cmdlets.

none

# Prints a DIFF state (status is automatically updated if state is changed)

of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

Los módulos de servicio de controladora de red son:

ControllerService
ApiService
SlbManagerService
ServiceInsertion
FirewallService
 VSwitchService
GatewayManager
FnmService
HelperService
UpdateService

Check that ReplicaStatus is **Ready** and HealthState is **Ok**.

In a production deployment is with a multi-node Network Controller, you can

also check which node each service is primary on and its individual replica
status.

```powershell
Get-NetworkControllerReplica

# Sample Output for the API service module

Replicas for service: ApiService

ReplicaRole : Primary
NodeName : [Link]
ReplicaStatus : Ready

Compruebe que el estado de la réplica está listo para cada servicio.

Compruebe los identificadores de host y los certificados

correspondientes entre la controladora de red y cada host de
Hyper-V.

En un host de Hyper-V, ejecute los siguientes comandos para comprobar que hostID
corresponde al identificador de instancia de un recurso de servidor en la controladora
de red.

PowerShell

Get-ItemProperty
"hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name
HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq

"162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags :
ResourceRef : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
 InstanceId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : [Link]
ResourceId : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties : [Link]

Remediación Si usa scripts SDNExpress o implementación manual, actualice la clave

HostId del Registro para que coincida con el identificador de instancia del recurso de
servidor. Reinicie el Agente host de controladora de red en el host de Hyper-V (servidor
físico) Si usa VMM, elimine el servidor de Hyper-V de VMM y quite la clave del Registro
HostId. A continuación, vuelva a agregar el servidor a través de VMM.

Compruebe que las huellas digitales de los certificados X.509 usados por el host de
Hyper-V (el nombre de host será el nombre del firmante del certificado) para la
comunicación (SouthBound) entre el host de Hyper-V (servicio agente de host nc) y los
nodos de controlador de red son los mismos. Compruebe también que el certificado
REST de la controladora de red tenga el nombre de sujeto CN=<FQDN o IP>.

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint Subject
---------- -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9 CN=SA18n30-
[Link]
...

dir cert:\\localmachine\root

Thumbprint Subject
---------- -------
30674C020268AA4E40FD6817BA6966531FB9ADA4 CN=[Link] **# NC REST IP
ADDRESS**

# On Network Controller Node VM

dir cert:\\localmachine\root

Thumbprint Subject
---------- -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9 CN=SA18n30-
[Link]
30674C020268AA4E40FD6817BA6966531FB9ADA4 CN=[Link] **# NC REST IP
ADDRESS**
...

También puede comprobar los siguientes parámetros de cada certificado para

asegurarse de que el nombre del firmante es el esperado (nombre de host o FQDN rest
de NC o IP), el certificado aún no ha expirado y que todas las entidades de certificación
de la cadena de certificados se incluyen en la entidad raíz de confianza.

Nombre del firmante

Fecha de expiración
Confianza de la entidad raíz

Remediación Si varios certificados tienen el mismo nombre de sujeto en el host de

Hyper-V, el Agente de host de controladora de red elegirá aleatoriamente uno para
presentarlo a la controladora de red. Esto puede no coincidir con la huella digital del
recurso de servidor conocido por la controladora de red. En este caso, elimine uno de
los certificados con el mismo nombre de sujeto en el host de Hyper-V y reinicie el
servicio agente de host de controladora de red. Si todavía no se puede establecer una
conexión, elimine el otro certificado con el mismo nombre de sujeto en el host de
Hyper-V y elimine el recurso de servidor correspondiente en VMM. A continuación,
vuelva a crear el recurso de servidor en VMM, que generará un nuevo certificado X.509
e lo instalará en el host de Hyper-V.

Comprobación del estado de configuración de SLB

El estado de configuración de SLB se puede determinar como parte de la salida al
cmdlet Debug-NetworkController. Este cmdlet también generará el conjunto actual de
recursos de controladora de red en archivos JSON, todas las configuraciones IP de cada
host de Hyper-V (servidor) y la directiva de red local de las tablas de base de datos del
Agente host.

Se recopilarán más seguimientos de forma predeterminada. Para no recopilar

seguimientos, agregue el parámetro -IncludeTraces:$false.

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS

Credential>] [-IncludeTraces:$false]

# Don't collect traces

$cred = Get-Credential
Debug-NetworkController -NetworkController [Link] -Credential $cred
-IncludeTraces:$false

Transcript started, output file is C:\\[Link]

Collecting Diagnostics data from NC Nodes

７ Nota
 La ubicación de salida predeterminada será el <directorio
working_directory>\NCDiagnostics\. El directorio de salida predeterminado se
puede cambiar mediante el -OutputDirectory parámetro .

La información de estado de configuración de SLB se puede encontrar en el archivo

[Link] de este directorio.

Este archivo JSON se puede dividir en las secciones siguientes:

Fabric
SlbmVips: en esta sección se muestra la dirección IP de la dirección VIP del
administrador de SLB, que usa la controladora de red para coordinar la
configuración y el estado entre los muxes de SLB y los agentes de host de SLB.
MuxState: en esta sección se mostrará un valor para cada mux de SLB
implementado, lo que proporciona el estado de la mux.
Configuración del enrutador: esta sección enumerará el número de sistema
autónomo (ASN) del enrutador ascendente (par BGP), la dirección IP de tránsito
y el identificador. También enumerará el ASN de los muxes de SLB y la dirección
IP de tránsito.
Información del host conectado: en esta sección se mostrará la dirección IP de
administración de todos los hosts de Hyper-V disponibles para ejecutar cargas
de trabajo con equilibrio de carga.
Intervalos vip: en esta sección se mostrarán los intervalos de grupos de
direcciones IP IP públicas y privadas. La VIP de SLBM se incluirá como una
dirección IP asignada de uno de estos intervalos.
Rutas mux: en esta sección se mostrará un valor para cada mux de SLB
implementado que contenga todos los anuncios de ruta para esa mux concreta.
Inquilino
VipConsolidatedState: en esta sección se enumerará el estado de conectividad
de cada VIP de inquilino, incluido el prefijo de ruta anunciado, el host de Hyper-
V y los puntos de conexión DIP.

７ Nota

El estado de SLB se puede determinar directamente mediante el script

DumpSlbRestState disponible en el repositorio de GitHub sdN de Microsoft .

Validación de puerta de enlace

Desde controladora de red:

 PowerShell

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

Desde la máquina virtual de puerta de enlace:

PowerShell

Ipconfig /allcompartments /all

Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

Desde la parte superior del conmutador de bastidor (ToR):

sh ip bgp summary (for 3rd party BGP Routers)

enrutador BGP de Windows

PowerShell

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Además de esto, a partir de los problemas que hemos visto hasta ahora (especialmente
en las implementaciones basadas en SDNExpress), la razón más común para que el
compartimiento de inquilinos no se configure en máquinas virtuales de GW parece ser
el hecho de que la capacidad de GW en FabricConfig.psd1 es menor en comparación
con lo que los usuarios intentan asignar a las conexiones de red (túneles S2S) en
TenantConfig.psd1. Esto se puede comprobar fácilmente comparando las salidas de los
siguientes comandos:

PowerShell

PS > (Get-NetworkControllerGatewayPool -ConnectionUri

$uri).[Link]
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri
$uri -VirtualGatewayId "TenantName").[Link]
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri
$uri -VirtualGatewayId "TenantName").property
[Hoster] Validar Data-Plane
Una vez implementada la controladora de red, se han creado las redes virtuales de
inquilino y las subredes, y las máquinas virtuales se han conectado a las subredes
virtuales, el host puede realizar pruebas de nivel de tejido adicionales para comprobar la
conectividad del inquilino.

Comprobación de la conectividad de red lógica del proveedor HNV

Una vez que la primera máquina virtual invitada que se ejecuta en un host de Hyper-V
se ha conectado a una red virtual de inquilino, la controladora de red asignará dos
direcciones IP del proveedor de HNV (direcciones IP PA) al host de Hyper-V. Estas
direcciones IP provendrán del grupo de direcciones IP del proveedor de HNV y serán
administradas por la controladora de red. Para averiguar cuáles son estas dos
direcciones IP de HNV

PowerShell

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : [Link]
MAC Address : 40-1D-D8-B7-1C-04
Subnet Mask : [Link]
Default Gateway : [Link]
VLAN : VLAN11

ProviderAddress : [Link]
MAC Address : 40-1D-D8-B7-1C-05
Subnet Mask : [Link]
Default Gateway : [Link]
VLAN : VLAN11

Estas direcciones IP del proveedor HNV (IP de PA) se asignan a adaptadores Ethernet
creados en un compartimiento de red TCPIP independiente y tienen un nombre de
adaptador de VLANX donde X es la VLAN asignada a la red lógica del proveedor de
HNV (transporte).

La conectividad entre dos hosts de Hyper-V mediante la red lógica del proveedor de
HNV se puede realizar mediante un ping con un parámetro de compartimiento
adicional (-c Y), donde Y es el compartimiento de red TCPIP en el que se crean los
PAhostVNIC. Este compartimiento se puede determinar ejecutando:
 C:\> ipconfig /allcompartments /all

<snip> ...
============================================================================
==
Network Information for *Compartment 3*
============================================================================
==
Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . :
fe80::5937:a365:d135:2899%39(Preferred)
IPv4 Address. . . . . . . . . . . : [Link](Preferred)
Subnet Mask . . . . . . . . . . . : [Link]
Default Gateway . . . . . . . . . : [Link]
NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . :
fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
IPv4 Address. . . . . . . . . . . : [Link](Preferred)
Subnet Mask . . . . . . . . . . . : [Link]
Default Gateway . . . . . . . . . : [Link]
NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*

<snip> ...

７ Nota

Los adaptadores de vNIC de host de PA no se usan en la ruta de acceso de datos y,

por tanto, no tienen una dirección IP asignada al adaptador "vEthernet
(PAhostVNic).

Por ejemplo, supongamos que los hosts 1 y 2 de Hyper-V tienen direcciones IP del
proveedor de HNV (PA):
 Host de Hyper-V Dirección IP de PA 1 Dirección IP de PA 2

Host 1 [Link] [Link]

Host 2 [Link] [Link]

podemos hacer ping entre los dos mediante el siguiente comando para comprobar la
conectividad de red lógica del proveedor de HNV.

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP

address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 [Link] -S [Link]

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP

address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 [Link] -S [Link]

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP

address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 [Link] -S [Link]

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP

address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 [Link] -S [Link]

Remediación Si el ping del proveedor de HNV no funciona, compruebe la conectividad

de red física, incluida la configuración de VLAN. Las NIC físicas de cada host de Hyper-V
deben estar en modo tronco sin ninguna VLAN específica asignada. La vNIC del host de
administración debe aislarse en la VLAN de la red lógica de administración.

PowerShell

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name : Ethernet 4
InterfaceDescription : <NIC> Ethernet Adapter
InterfaceIndex : 2
MacAddress : F4-52-14-55-BC-21
MediaType : 802.3
PhysicalMediaType : 802.3
InterfaceOperationalStatus : Up
AdminStatus : Up
LinkSpeed(Gbps) : 10
MediaConnectionState : Connected
ConnectorPresent : True
*VlanID : 0*
DriverInformation : Driver Date 2016-08-28 Version 5.25.12665.0
NDIS 6.60
 # VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set
VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode VlanList

------ -------------------- ---- --------
<snip> ...
Mgmt Access 7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-

VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID : 7
MultiTenantStack : Off
ParentAdapter : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate : True
CimSession : CimSession: .
ComputerName : SA18N30-2
IsDeleted : False

<snip> ...

Compruebe la compatibilidad de MTU y Jumbo Frame en la red

lógica del proveedor HNV.
Otro problema común en la red lógica del proveedor de HNV es que los puertos de red
físicos o la tarjeta Ethernet no tienen una MTU suficientemente grande configurada para
controlar la sobrecarga de la encapsulación de VXLAN (o NVGRE).

７ Nota

Algunas tarjetas y controladores Ethernet admiten la nueva palabra clave

*EncapOverhead que el Agente host de controladora de red establecerá
automáticamente en un valor de 160. A continuación, este valor se agregará al
valor de la palabra clave *JumboPacket cuya suma se usa como MTU anunciada.
Por ejemplo, *EncapOverhead = 160 y *JumboPacket = 1514 => MTU = 1674B
 # Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2

Physical Nic <NIC> Ethernet Adapter #2 can support SDN traffic.
Encapoverhead value set on the nic is 160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead
value set on the nic is 160

Para probar si la red lógica del proveedor de HNV admite o no el tamaño de MTU más
grande de un extremo a otro, use el cmdlet Test-LogicalNetworkSupportsJumboPacket :

PowerShell

# Get credentials for both source host and destination host (or use the same
credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-
V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -
DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -
DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: [Link] to Destination PA: [Link] with
Payload: 1632
pinging Source PA: [Link] to Destination PA: [Link] with
Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic <NIC> Ethernet Adapter #2 can support SDN traffic.
Encapoverhead value set on the nic is 160
Cannot send jumbo packets to the destination. Physical switch ports may not
be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic <NIC> Ethernet Adapter #2 can support SDN traffic.
Encapoverhead value set on the nic is 160
Cannot send jumbo packets to the destination. Physical switch ports may not
be configured to support jumbo packets.

Corrección

Ajuste el tamaño de MTU en los puertos de conmutador físico para que sean al
menos 1674B (incluido el encabezado Ethernet 14B y el finalizador)
Si la tarjeta NIC no admite la palabra clave EncapOverhead, ajuste la palabra clave
JumboPacket para que sea al menos 1674B.
Comprobación de la conectividad de NIC de máquina virtual de
inquilino

Cada NIC de máquina virtual asignada a una máquina virtual invitada tiene una
asignación de CA-PA entre la dirección de cliente privada (CA) y el espacio de dirección
del proveedor de HNV (PA). Estas asignaciones se conservan en las tablas del servidor
OVSDB en cada host de Hyper-V y se pueden encontrar ejecutando el siguiente cmdlet.

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address Virtual Subnet ID PA IP Address

------------- -------------- ----------------- -------------
[Link] 00-1D-D8-B7-1C-43 4115 [Link]
[Link] 00-1D-D8-B7-1C-43 4115 [Link]
[Link] 00-1D-D8-B7-1C-07 4114 [Link]
[Link] 40-1D-D8-B7-1C-06 4115 [Link]
[Link] 40-1D-D8-B7-1C-06 4114 [Link]
[Link] 00-1D-D8-B7-1C-05 4114 [Link]

７ Nota

Si las asignaciones de CA-PA que espera no son salidas para una máquina virtual de
inquilino determinada, compruebe los recursos de configuración de IP y NIC de
máquina virtual en controladora de red mediante el cmdlet Get-
NetworkControllerNetworkInterface . Además, compruebe las conexiones
establecidas entre el agente de host nc y los nodos de controladora de red.

Con esta información, ahora el hoster puede iniciar un ping de máquina virtual de
inquilino desde la controladora de red mediante el cmdlet Test-
VirtualNetworkConnection .

Escenarios de solución de problemas

específicos
En las secciones siguientes se proporcionan instrucciones para solucionar escenarios
específicos.

No hay conectividad de red entre dos máquinas virtuales

de inquilino
 1. [Inquilino] Asegúrese de que Windows Firewall en máquinas virtuales de inquilino
no bloquea el tráfico.
2. [Inquilino] Compruebe que las direcciones IP se han asignado a la máquina virtual
del inquilino mediante la ejecución de ipconfig.
3. [Hoster] Ejecute Test-VirtualNetworkConnection desde el host de Hyper-V para
validar la conectividad entre las dos máquinas virtuales de inquilino en cuestión.

７ Nota

El VSID hace referencia al identificador de subred virtual. En el caso de VXLAN, este

es el identificador de red VXLAN (VNI). Para encontrar este valor, ejecute el cmdlet
Get-PACAMapping .

Ejemplo

PowerShell

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force

$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

Cree CA-ping entre "Green Web VM 1" con senderCA IP de [Link] en el host
"[Link]" con mgmt IP de [Link] a listenerCA IP
de [Link] ambos conectados a la subred virtual (VSID) 4114.

PowerShell

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-

[Link] -MgmtIp [Link] -Creds $cred -VMName
"Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP
[Link] -SenderVSID 4114 -ListenerCAIP [Link] -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test

Starting trace session
Ping to [Link] succeeded from address [Link]
Rtt = 0 ms

CA Routing Information:

Local IP: [Link]

Local VSID: 4114
Remote IP: [Link]
Remote VSID: 4114
Distributed Router Local IP: [Link]
Distributed Router Local MAC: 40-1D-D8-B7-1C-06
Local CA MAC: 00-1D-D8-B7-1C-05
 Remote CA MAC: 00-1D-D8-B7-1C-07
Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

Local PA IP: [Link]

Remote PA IP: [Link]

<snip> ...

1. [Inquilino] Compruebe que no haya ninguna directiva de firewall distribuida

especificada en la subred virtual o en las interfaces de red de máquina virtual que
bloquearían el tráfico.

Consulte la API rest de controladora de red que se encuentra en el entorno de

demostración en sa18n30nc en el dominio de [Link].

$uri = "[Link]
Get-NetworkControllerAccessControlList -ConnectionUri $uri

Examine la configuración de IP y las subredes

virtuales que hacen referencia a esta ACL.
1. [Hoster] Ejecute Get-ProviderAddress en ambos hosts de Hyper-V que hospedan
las dos máquinas virtuales de inquilino en cuestión y, a continuación, ejecute Test-
LogicalNetworkConnection o ping -c <compartment> desde el host de Hyper-V para

validar la conectividad en la red lógica del proveedor de HNV.

2. [Hoster] Asegúrese de que la configuración de MTU es correcta en los hosts de
Hyper-V y en los dispositivos de conmutación de nivel 2 entre los hosts de Hyper-
V. Ejecute Test-EncapOverheadValue en todos los hosts de Hyper-V en cuestión.
Compruebe también que todos los conmutadores de nivel 2 entre tienen MTU
establecido en al menos 1674 bytes para tener en cuenta la sobrecarga máxima de
160 bytes.
3. [Hoster] Si las direcciones IP de PA no están presentes o se interrumpe la
conectividad de CA, compruebe que se ha recibido la directiva de red. Ejecute Get-
PACAMapping para ver si las reglas de encapsulación y las asignaciones de CA-PA
necesarias para crear redes virtuales superpuestas se establecen correctamente.
4. [Hoster] Compruebe que el agente host de controladora de red está conectado a
la controladora de red. Ejecute netstat -anp tcp |findstr 6640 para ver si
 5. [Hoster] Compruebe que el identificador de host de HKLM/ coincide con el
identificador de instancia de los recursos del servidor que hospedan las máquinas
virtuales del inquilino.
6. [Hoster] Compruebe que el id. de perfil de puerto coincide con el identificador de
instancia de las interfaces de red de máquina virtual de las máquinas virtuales del
inquilino.

Registro, seguimiento y diagnóstico avanzado

En las secciones siguientes se proporciona información sobre diagnósticos avanzados,
registro y seguimiento.

Registro centralizado de la controladora de red

La controladora de red puede recopilar automáticamente los registros del depurador y
almacenarlos en una ubicación centralizada. La recopilación de registros se puede
habilitar al implementar la controladora de red por primera vez o en cualquier momento
posterior. Los registros se recopilan de la controladora de red y los elementos de red
administrados por Controladora de red: máquinas host, equilibradores de carga de
software (SLB) y máquinas de puerta de enlace.

Estos registros incluyen registros de depuración para el clúster de Controladora de red,

la aplicación controladora de red, los registros de puerta de enlace, el SLB, las redes
virtuales y el firewall distribuido. Cada vez que se agrega un nuevo host, SLB o puerta de
enlace a la controladora de red, el registro se inicia en esas máquinas. De forma similar,
cuando se quita un host, SLB o puerta de enlace de la controladora de red, el registro se
detiene en esas máquinas.

Habilitar registro

El registro se habilita automáticamente al instalar el clúster de Controladora de red

mediante el cmdlet Install-NetworkControllerCluster . De forma predeterminada, los
registros se recopilan localmente en los nodos de controladora de red en
%systemdrive%\SDNDiagnostics. Se recomienda encarecidamente cambiar esta
ubicación para que sea un recurso compartido de archivos remoto (no local).

Los registros del clúster de Controladora de red se almacenan en

%programData%\Windows Fabric\log\Traces. Puede especificar una ubicación
centralizada para la recopilación de registros con el parámetro DiagnosticLogLocation
con la recomendación de que también sea un recurso compartido de archivos remoto.
Si desea restringir el acceso a esta ubicación, puede proporcionar las credenciales de
acceso con el parámetro LogLocationCredential . Si proporciona las credenciales para
acceder a la ubicación del registro, también debe proporcionar el parámetro
CredentialEncryptionCertificate , que se usa para cifrar las credenciales almacenadas
localmente en los nodos de controladora de red.

Con la configuración predeterminada, se recomienda tener al menos 75 GB de espacio

libre en la ubicación central y 25 GB en los nodos locales (si no se usa una ubicación
central) para un clúster de controladora de red de tres nodos.

Cambio de la configuración de registro

Puede cambiar la configuración de registro en cualquier momento mediante el Set-
NetworkControllerDiagnostic cmdlet . Se puede cambiar la siguiente configuración:

Ubicación de registro centralizada. Puede cambiar la ubicación para almacenar

todos los registros, con el DiagnosticLogLocation parámetro .
Credenciales para acceder a la ubicación del registro. Puede cambiar las
credenciales para acceder a la ubicación del registro, con el LogLocationCredential
parámetro .
Vaya al registro local. Si ha proporcionado una ubicación centralizada para
almacenar registros, puede volver al registro localmente en los nodos de
controladora de red con el UseLocalLogLocation parámetro (no se recomienda
debido a los requisitos de espacio en disco grandes).
Ámbito de registro. De forma predeterminada, se recopilan todos los registros.
Puede cambiar el ámbito para recopilar solo los registros del clúster de
Controladora de red.
Nivel de registro. El nivel de registro predeterminado es Informativo. Puede
cambiarlo a Error, Advertencia o Detallado.
Tiempo de envejecimiento del registro. Los registros se almacenan de forma
circular. De forma predeterminada, tiene tres días de datos de registro, tanto si usa
el registro local como el registro centralizado. Puede cambiar este límite de tiempo
con el parámetro LogTimeLimitInDays .
Tamaño de envejecimiento del registro. De forma predeterminada, tendrá un
máximo de 75 GB de datos de registro si usa el registro centralizado y 25 GB si usa
el registro local. Puede cambiar este límite con el parámetro LogSizeLimitInMBs .

Recopilación de registros y seguimientos

Las implementaciones de VMM usan el registro centralizado para la controladora de red
de forma predeterminada. La ubicación del recurso compartido de archivos para estos
registros se especifica al implementar la plantilla de servicio controladora de red.

Si no se ha especificado una ubicación de archivo, el registro local se usará en cada

nodo de controladora de red con los registros guardados en
C:\Windows\tracing\SDNDiagnostics. Estos registros se guardan con la siguiente
jerarquía:

CrashDumps
NCApplicationCrashDumps
NCApplicationLogs
PerfCounters
SDNDiagnostics
Traces

La controladora de red usa (Azure) Service Fabric. Service Fabric registros pueden ser
necesarios al solucionar ciertos problemas. Estos registros se pueden encontrar en cada
nodo de controladora de red en C:\ProgramData\Microsoft\Service Fabric.

Si un usuario ha ejecutado el cmdlet Debug-NetworkController , habrá más registros

disponibles en cada host de Hyper-V, que se ha especificado con un recurso de servidor
en la controladora de red. Estos registros (y seguimientos si están habilitados) se
mantienen en C:\NCDiagnostics

Diagnósticos de SLB

Errores de SLBM Fabric (acciones del proveedor de servicios de

hospedaje)
1. Compruebe que software Load Balancer Manager (SLBM) funciona y que las capas
de orquestación pueden comunicarse entre sí: SLBM -> SLB Mux y SLBM ->
Agentes host de SLB. Ejecute DumpSlbRestState desde cualquier nodo con
acceso al punto de conexión REST de controladora de red.
2. Valide los SDNSLBMPerfCounters en PerfMon en una de las máquinas virtuales del
nodo controladora de red (preferiblemente el nodo controladora de red principal:
Get-NetworkControllerReplica):
a. ¿El motor de Load Balancer (LB) está conectado a SLBM? (Configuraciones de
LBEngine de SLBM Total> 0)
b. ¿SLBM conoce al menos sus propios puntos de conexión? (Puntos de conexión
VIP Totales>= 2)
c. ¿Los hosts de Hyper-V (DIP) están conectados a SLBM? (Clientes HP conectados
== servidores numéricos)
 d. ¿Está conectado SLBM a muxes? (Muxes conectados == Muxes healthy on SLBM
(Muxes healthy on SLBM == ) Muxes notifican un estado correcto = # SLB Muxes
VM).
3. Asegúrese de que el enrutador BGP configurado está emparejando correctamente
con la MUX de SLB.
a. Si usa RRAS con acceso remoto (es decir, máquina virtual BGP):
i. Get-BgpPeer debe mostrar conectado
ii. Get-BgpRouteInformation debe mostrar al menos una ruta para la dirección
VIP de SLBM
b. Si usa el conmutador de la parte superior del bastidor (ToR) físico como punto
BGP, consulte la documentación.
i. Por ejemplo: # show bgp instance
4. Validación de los contadores SlbMuxPerfCounters y SLBMUX en PerfMon en la
máquina virtual de SLB Mux
5. Comprobación del estado de configuración y los intervalos de VIP en el recurso de
Software Load Balancer Manager
a. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://
FQDN o IP| convertto-json -depth 8 (compruebe los intervalos vip en grupos de
DIRECCIONES IP> y asegúrese de que SLBM self-VIP
(LoadBalanacerManagerIPAddress) y las VIP orientadas al inquilino están dentro
de estos intervalos<).
i. Get-NetworkControllerIpPool -NetworkId "<Id. de recurso> de red lógica de
VIP pública/privada" -subnetId "<Id. de recurso> de subred lógica de VIP
pública/privada" -ResourceId "<Id>. de recurso del grupo de DIRECCIONES
IP" -ConnectionUri $uri |convertto-json -depth 8
b. Debug-NetworkControllerConfigurationState:

Si se produce un error en alguna de las comprobaciones anteriores, el estado del SLB

del inquilino también estará en modo de error.

Remediación En función de la siguiente información de diagnóstico presentada, corrija

lo siguiente:

Asegúrese de que los multiplexores de SLB están conectados

Corrección de problemas de certificado
Corregir problemas de conectividad de la red
Asegúrese de que la información de emparejamiento de BGP esté configurada
correctamente.
Asegúrese de que el identificador de host del registro coincide con el identificador
de instancia del servidor en el recurso del servidor (apéndice de referencia para el
código de error HostNotConnected )
Recopilación de registros
Errores de inquilino de SLBM (acciones de inquilino y proveedor de
servicios de hospedaje)

1. [Hoster] Compruebe Debug-NetworkControllerConfigurationState para ver si algún

recurso de LoadBalancer está en estado de error. Intente mitigarlo siguiendo la
tabla de elementos de acción en el Apéndice.
a. Comprobación de que un punto de conexión vip está presente y anunciando
rutas
b. Compruebe cuántos puntos de conexión dip se han detectado para el punto de
conexión vip.
2. [Inquilino] Validar que los recursos de Load Balancer se especifican correctamente
a. Valide los puntos de conexión dip registrados en SLBM que hospedan máquinas
virtuales de inquilino, que corresponden a las configuraciones IP del grupo de
direcciones de back-end de LoadBalancer.
3. [Hoster] Si los puntos de conexión dip no se detectan ni se conectan:
a. Comprobación de Debug-NetworkControllerConfigurationState
i. Compruebe que el agente de host nc y SLB esté conectado correctamente al
coordinador de eventos de controlador de red mediante netstat -anp tcp
|findstr 6640)
b. Compruebe HostId en la clave de registro del servicio nchostagent (código de
error HostNotConnected de referencia en el apéndice) que coincida con el
identificador de instancia del recurso de servidor correspondiente ( Get-NCServer
|convertto-json -depth 8 )

c. Comprobación del identificador de perfil de puerto para el puerto de máquina

virtual coincide con el identificador de instancia del recurso de la NIC de la
máquina virtual correspondiente.
4. [Proveedor de hospedaje] Recopilación de registros

Seguimiento de mux de SLB

La información de los Load Balancer muxes de software también se puede determinar a

través de Visor de eventos.

1. Haga clic en "Mostrar registros analíticos y de depuración" en el menú ver de Visor

de eventos
2. Vaya a "Registros de aplicaciones y servicios" > de Microsoft > Windows >
seguimiento de SlbMuxDriver > en Visor de eventos
3. Haga clic con el botón derecho en él y seleccione "Habilitar registro".

７ Nota
 Se recomienda que solo tenga este registro habilitado durante un breve tiempo
mientras intenta reproducir un problema.

Seguimiento de VFP y vSwitch

Desde cualquier host de Hyper-V que hospede una máquina virtual invitada conectada
a una red virtual de inquilino, puede recopilar un seguimiento de VFP para determinar
dónde pueden estar los problemas.

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes

tracefile=[Link] report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\[Link] ov=yes
Red privada virtual (VPN)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows 10

Puerta de enlace de RAS como servidor VPN de

inquilino único
En Windows Server 2016, el rol de servidor de acceso remoto es una agrupación lógica
de las siguientes tecnologías de acceso a red relacionadas.

Servicio de acceso remoto (RAS)

Enrutamiento
Proxy de aplicación web

Estas tecnologías son los Servicios de rol del rol de servidor de acceso remoto.

Al instalar el rol de servidor de acceso remoto con el Asistente para agregar roles y
características o Windows PowerShell, puede instalar uno o varios de estos tres servicios
de rol.

Al instalar el servicio de rol DirectAccess y VPN (RAS), va a implementar la puerta de

enlace de servicio de acceso remoto (puerta de enlace ras). Puede implementar RAS
Gateway como un único servidor de red privada virtual (VPN) de puerta de enlace ras de
inquilino que proporciona muchas características avanzadas y funcionalidad mejorada.

７ Nota

También puede implementar la puerta de enlace ras como un servidor VPN

multiinquilino para su uso con redes definidas por software (SDN) o como servidor
de DirectAccess. Para obtener más información, vea Puerta de enlace ras, Redes
definidas por software (SDN) y DirectAccess.

Temas relacionados
Características y funcionalidades de VPN AlwaysOn: en este tema, obtendrá
información sobre las características y la funcionalidad de VPN AlwaysOn.
Configurar túneles de dispositivo VPN en Windows 10: VPN AlwaysOn le ofrece la
posibilidad de crear un perfil de VPN dedicado para el dispositivo o la máquina.
Las conexiones VPN AlwaysOn incluyen dos tipos de túneles: túnel de dispositivo y
túnel de usuario. El túnel de dispositivo se usa para escenarios de conectividad
previos al inicio de sesión y fines de administración de dispositivos. Los túneles de
usuario permiten a los usuarios acceder a los recursos de la organización
utilizando servidores VPN.

Implementación de VPN AlwaysOn para Windows Server 2016 y Windows 10:

proporciona instrucciones sobre la implementación del acceso remoto como
puerta de enlace DE RAS de VPN de inquilino único para conexiones VPN de punto
a sitio que permiten a los empleados remotos conectarse a la red de la
organización con conexiones VPN AlwaysOn. Se recomienda revisar las guías de
diseño e implementación de cada una de las tecnologías que se usan en esta
implementación.

Windows 10 Guía técnica de VPN: le guía por las decisiones que tomará para
Windows 10 clientes de la solución VPN empresarial y cómo configurar la
implementación. Puede encontrar referencias al proveedor de servicios de
configuración (CSP) VPNv2 y proporciona instrucciones de configuración de
administración de dispositivos móviles (MDM) mediante Microsoft Intune y la
plantilla de perfil de VPN para Windows 10.

Creación de perfiles de VPN en Configuration Manager: en este tema, aprenderá a

crear perfiles de VPN en Configuration Manager.

Configurar Windows 10 conexiones VPN AlwaysOn de cliente: en este tema se

describen las opciones y el esquema ProfileXML y cómo crear la VPN ProfileXML.
Después de configurar la infraestructura del servidor, debe configurar los equipos
cliente de Windows 10 para comunicarse con esa infraestructura con una conexión
VPN.

Opciones de perfil de VPN: en este tema se describen las opciones de perfil de

VPN en Windows 10 y aprenderá a configurar perfiles de VPN mediante Intune o
Configuration Manager. Puede configurar todas las opciones de VPN en Windows
10 mediante el nodo ProfileXML en el CSP de VPNv2.
Servicio de nombres Internet de
Windows (WINS)
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Windows Internet Name Service (WINS) es un servicio heredado de registro y resolución

de nombres de equipo que asigna nombres NetBIOS de equipo a direcciones IP.

Si aún no tiene WINS implementado en la red, no implemente WINS; en su lugar,

implemente el Sistema de nombres de dominio (DNS). DNS también proporciona
servicios de resolución y registro de nombres de equipo, e incluye muchas ventajas
adicionales sobre WINS, como la integración con Active Directory Domain Services.

Para obtener más información, vea Sistema de nombres de dominio (DNS)

Si ya ha implementado WINS en la red, se recomienda implementar DNS y, a

continuación, retirar WINS.
Servicio de hora de Windows (W32time)
Artículo • 21/12/2022 • Tiempo de lectura: 3 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012, Windows 10 o posterior, Azure
Stack HCI, versiones 21H2 y 20H2

El servicio de hora de Windows (W32Time) sincroniza la fecha y la hora de todos los

equipos que se ejecutan en Active Directory Domain Services (AD DS). La sincronización
de la hora es fundamental para el funcionamiento correcto de muchos servicios de
Windows y aplicaciones de línea de negocio (LOB). El servicio de hora de Windows usa
el Protocolo de tiempo de redes (NTP) para sincronizar los relojes de los equipos de una
red. NTP garantiza que se pueda asignar un valor de reloj, o una marca de tiempo,
preciso a las solicitudes de validación de red y de acceso a recursos.

En el tema del servicio de hora de Windows (W32Time), está disponible el siguiente

contenido:

Hora precisa para Windows Server 2016. La precisión de la sincronización de la

hora en Windows Server 2016 ha mejorado considerablemente, a la vez que se
mantiene totalmente la compatibilidad de NTP con versiones anteriores de
Windows. En condiciones de funcionamiento razonables, puede mantener una
precisión de 1 ms con respecto a utc o superior para los miembros del dominio
Windows Server 2016 y Windows 10 de actualización de aniversario.
Límite de compatibilidad para entornos de alta precisión. En este artículo se
describen los límites de compatibilidad del servicio de hora de Windows
(W32Time) en entornos que requieren una hora del sistema muy precisa y estable.
Configuración de sistemas de alta precisión. La sincronización de la hora en
Windows 10 y Windows Server 2016 se ha mejorado considerablemente. En
condiciones de funcionamiento razonables, los sistemas se pueden configurar para
mantener una precisión de 1 ms (milisegundos) o superior (con respecto a utc).
Windows tiempo de seguimiento. Las normas de muchos sectores exigen que los
sistemas puedan rastrearse según la hora UTC. Esto significa que se pueda dar fe
de la diferencia horaria de un sistema con respecto a UTC. Para habilitar escenarios
de cumplimiento normativo, Windows 10 y Server 2016 proporcionan nuevos
registros de eventos para proporcionar una imagen desde la perspectiva del
sistema operativo para comprender las acciones realizadas en el reloj del sistema.
Estos registros de eventos se generan continuamente para el servicio de hora de
Windows y se pueden examinar o archivar para su posterior análisis.
 Referencia técnica del servicio de hora de Windows. El servicio W32Time
proporciona sincronización del reloj de red para los equipos sin necesidad de una
extensa configuración. El servicio W32Time es esencial para el correcto
funcionamiento de la autenticación Kerberos, versión 5, y, por tanto, para la
autenticación basada en AD DS.
Funcionamiento del servicio de hora de Windows. Aunque el servicio de hora
de Windows no es una implementación exacta del Protocolo de tiempo de
redes (NTP), usa el conjunto de algoritmos complejo que se define en las
especificaciones de NTP para asegurarse de que los relojes de los equipos de
una red sean lo más precisos posible.
Configuración y herramientas del servicio de hora de Windows. La mayoría de
los equipos miembros de dominio tienen un tipo de cliente de hora de NT5DS,
lo que significa que sincronizan la hora desde la jerarquía de dominios. La única
excepción habitual a esto es el controlador de dominio que funciona como
maestro de operaciones del emulador del controlador de dominio principal
(PDC) del dominio raíz del bosque, que normalmente se configura para
sincronizar la hora con un origen de la hora externo.

Temas relacionados
Para obtener más información sobre la jerarquía de dominios y el sistema de
puntuación, vea la entrada de blog "¿Qué es Windows Time Service?".

El modelo de complementos del proveedor de hora de Windows está documentado en

TechNet.

Aquí se puede descargar un anexo al que se hace referencia en el artículo Hora exacta
para Windows 2016.

Para obtener una introducción rápida al servicio de hora de Windows, echa un vistazo a
este vídeo de información general .
Versión preliminar de Insider
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Compatibilidad con segundo intercalar

Se aplica a: Windows Server 2022, Windows Server 2019 y Windows 10, versión
1809, Azure Stack HCI, versiones 21H2 y 20H2

Un segundo intercalar es un ajuste ocasional de 1 segundo a la hora UTC. A medida que

la rotación de la tierra se ralentiza, la hora UTC (una escala de tiempo atómica) difiere
de la hora solar media o astronómica. Una vez que la hora UTC ha divergido un
máximo de 0,9 segundos, se inserta un segundo intercalar para mantener la hora UTC
sincronizada con la hora solar media.

Los segundos intercalares se han vuelto importantes para cumplir con los requisitos
normativos de precisión y rastreabilidad tanto en el Estados Unidos como en la Unión
Europea.

Para obtener más información, consulte:

Nuestro blog de anuncios

La guía de validación para desarrolladores

La guía de validación para profesionales de TI

Protocolo de tiempo de precisión

Se aplica a: Windows Server 2022, Windows Server 2019 y Windows 10,
versión 1809

Un nuevo proveedor de hora incluido en Windows Server 2019 y Windows 10

(versión 1809) te permite sincronizar la hora mediante el Protocolo de tiempo de
precisión (PTP). A medida que la hora se distribuye a través de una red, encuentra un
retraso (latencia) que, si no se tiene en cuenta, o si no es simétrico, hace que cada vez
sea más difícil comprender la marca de tiempo enviada desde el servidor de hora. PTP
permite que los dispositivos de red sumen la latencia introducida por cada dispositivo
de red a las mediciones de tiempo, con lo que se proporciona una muestra de hora
mucho más precisa para el cliente Windows.
Para obtener más información, consulte:

Nuestro blog de anuncios

La guía de validación para profesionales de TI

Marca de tiempo de software

Se aplica a: Windows Server 2022, Windows Server 2019 y Windows 10,
versión 1809

Al recibir un paquete de control de hora a través de la red desde un servidor de hora, la

pila de red del sistema operativo tiene que procesarlo antes de que se use en el servicio
de hora. Cada componente de la pila de red introduce una cantidad variable de latencia
que afecta a la precisión de la medición de la hora.

Para solucionar este problema, la marca de tiempo de software nos permite insertar la
marca de tiempo en paquetes antes y después de los "componentes de red de
Windows" que se muestran anteriormente para tener en cuenta el retraso en el sistema
operativo.

Para obtener más información, consulte:

Nuestro blog de anuncios

Guías de validación para desarrolladores y profesionales de TI

Hora precisa para Windows Server 2016
Artículo • 21/12/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012, Windows 10 o posterior, Azure
Stack HCI, versiones 21H2 y 20H2

El servicio Hora de Windows es un componente que usa un modelo de complemento

para los proveedores de sincronización de la hora de cliente y servidor. Hay dos
proveedores de clientes integrados en Windows y hay complementos de terceros
disponibles. Un proveedor usa NTP (RFC 1305) o MS-NTP para sincronizar la hora del
sistema local con un servidor de referencia compatible con NTP o MS-NTP. El otro
proveedor es para Hyper-V y sincroniza las máquinas virtuales (VM) con el host de
Hyper-V. Cuando existan varios proveedores, Windows elegirá el mejor mediante el
nivel de estrato en primer lugar, seguido de la demora de raíz, la dispersión de raíz y,
por último, la diferencia horaria.

７ Nota

Para obtener información general rápida del servicio Horario de Windows, eche un
vistazo a este vídeo de información general de alto nivel .

En este tema, hablaremos de... estos temas se refieren a la habilitación de la hora

precisa:

Mejoras
Medidas
Procedimientos recomendados

） Importante

Aquí puedes descargar el anexo al que se hace referencia en el artículo Hora

precisa para Windows 2016. En este documento se proporcionan más detalles
sobre nuestras metodologías para las pruebas y medidas.

７ Nota

El modelo de complementos del proveedor de hora de Windows está

documentado en TechNet.
Jerarquía de dominios
Las configuraciones Dominio e Independiente funcionan de manera diferente.

Los miembros del dominio usan un protocolo NTP seguro, que usa la
autenticación para garantizar la seguridad y la autenticidad de la referencia de la
hora. Los miembros del dominio se sincronizan con un reloj maestro determinado
por la jerarquía de dominios y un sistema de puntuación. En un dominio, hay una
capa jerárquica de estratos de tiempo, en la que cada controlador de dominio
apunta a un controlador de dominio principal con un estrato de tiempo más
preciso. La jerarquía se resuelve en el controlador de dominio principal o un
controlador de dominio del bosque raíz, o en un controlador de dominio con la
marca de dominio GTIMESERV, que indica un servidor horario adecuado para el
dominio. Consulta la sección Especificación de un servicio de hora local confiable
mediante GTIMESERV a continuación.

Las máquinas independientes están configuradas para usar [Link] de

forma predeterminada. El servidor DNS resuelve este nombre, que debe apuntar a
un recurso propiedad de Microsoft. Igual que en todas las referencias de hora
ubicadas remotamente, las interrupciones de red pueden impedir la sincronización.
Las cargas de tráfico de red y las rutas de acceso de red asimétricas pueden
reducir la precisión de la sincronización de la hora. Para una precisión de 1 ms, no
puedes depender de orígenes de hora remotos.

Como los invitados de Hyper-V van a tener al menos dos proveedores de hora de
Windows entre los que elegir, la hora del host y NTP, es posible que observes
comportamientos diferentes con la configuración Domino o Independiente cuando
ejecutes como invitado.

７ Nota

Para obtener más información sobre la jerarquía de dominios y el sistema de

puntuación, consulte la entrada de blog "¿Qué es Windows Time Service?".

７ Nota

El estrato es un concepto que se usa en los proveedores de NTP e Hyper-V, y su

valor indica la ubicación de los relojes en la jerarquía. El estrato 1 está reservado
para el reloj de nivel superior y el estrato 0 está reservado para el hardware que se
 supone preciso y que tiene poco o ningún retraso asociado. El estrato 2 se
comunica con los servidores del estrato 1, el estrato 3 con el estrato 2, etc. Aunque
un estrato inferior suele indicar un reloj más preciso, es posible encontrar
discrepancias. Además, W32time solo acepta la hora del estrato 15 o inferior. Para
ver el estrato de un cliente, usa w32tm /query /status.

Factores críticos para una hora precisa

En cada caso de hora precisa, hay tres factores críticos:

1. Reloj de origen sólido: el reloj de origen del dominio debe ser estable y preciso.
Suele significar que se debe instalar un dispositivo GPS o apuntar a un origen de
estrato 1, que tenga en cuenta el número 3. Una analogía: si tienes dos barcos en
el agua e intentas medir la altitud de uno en comparación con el otro, la precisión
es mejor si el barco de origen es muy estable y no se mueve. Lo mismo ocurre en
la hora y, si el reloj de origen no es estable, toda la cadena de relojes sincronizados
se ve afectada y aumenta en cada fase. También debe ser accesible porque las
interrupciones en la conexión interferirán en la sincronización de la hora. Y, por
último, debe ser seguro. Si la referencia de la hora no se mantiene correctamente u
la gestiona una entidad potencialmente malintencionada, podrías exponer tu
dominio a ataques basados en la hora.
2. Reloj de cliente estable: los relojes de cliente estables garantizan que se pueda
contener el desplazamiento natural del oscilador. NTP usa varias muestras de
distintos servidores NTP para condicionar y controlar el reloj de los equipos
locales. No aplica cambios de hora, sino que ralentiza o acelera el reloj local para
que se aproxime a la hora precisa rápidamente y mantenga la precisión entre las
solicitudes NTP. Sin embargo, si el oscilador del reloj del equipo cliente no es
estable, se pueden producir más fluctuaciones entre los ajustes y que los
algoritmos que Windows usa para acondicionar el reloj no funcionen
correctamente. En algunos casos, es posible que se necesiten actualizaciones del
firmware para conseguir la hora precisa.
3. Comunicación simétrica de NTP: es fundamental que la conexión para la
comunicación NTP sea simétrica. NTP usa cálculos para ajustar la hora en los que
se supone que la ruta de acceso de red es simétrica. Si la ruta de acceso del
paquete NTP que va al servidor tarda un tiempo diferente en devolverse, la
precisión se verá afectada. Por ejemplo, la ruta de acceso podría cambiar debido a
cambios en la topología de red, o a que los paquetes se enruten a través de
dispositivos que tienen diferentes velocidades de interfaz.
En el caso de dispositivos que funcionan con batería, tanto móviles como portátiles,
debes tener en cuenta diferentes estrategias. Según nuestra recomendación, mantener
la hora precisa requiere que el reloj se controle una vez por segundo, que se
correlaciona con la frecuencia de actualización del reloj. Esta configuración consumirá
más energía de la batería de lo esperado y puede interferir con los modos de ahorro de
energía disponibles en Windows para dichos dispositivos. Los dispositivos que
funcionan con batería también tienen algunos modos de energía que detienen la
ejecución de todas las aplicaciones, lo que interfiere con la capacidad de W32time para
controlar el reloj y mantener una hora precisa. Además, es posible que los relojes de los
dispositivos móviles no sean muy precisos para comenzar. Las condiciones ambientales
afectan a la precisión del reloj y un dispositivo móvil puede pasar de una condición
ambiental a otra, lo que puede interferir con la capacidad de mantener la precisión de la
hora. Por lo tanto, Microsoft no recomienda que configures los dispositivos portátiles
que funcionan con batería con una configuración de precisión alta.

¿Por qué es importante la hora?

Hay muchos motivos diferentes por los que podrías necesitar una hora precisa. El caso
típico de Windows es Kerberos, que requiere una precisión de 5 minutos entre el cliente
y el servidor. Sin embargo, hay muchas otras áreas que pueden verse afectadas por la
precisión de la hora, por ejemplo, las siguientes:

Regulaciones gubernamentales como:

50 ms de precisión para FINRA en EE. UU.
1 ms para ESMA (MiFID II) en la Unión Europea.
Algoritmos de criptografía
Sistemas distribuidos como Cluster/SQL/Exchange y Document DB
Marco de cadena de bloques para las transacciones de bitcoins
Registros distribuidos y análisis de amenazas
Replicación de AD
PCI (Payment Card Industry), actualmente una precisión de 1 segundo

Referencias adicionales
Mejoras en la precisión temporal para Windows Server 2016
Límite de compatibilidad de la hora de
alta precisión
Artículo • 21/12/2022 • Tiempo de lectura: 4 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016 y
Windows 10 versión 1607 o posterior, Azure Stack HCI, versiones 21H2 y 20H2

En este artículo se describen los límites de compatibilidad del servicio de hora de

Windows (W32Time) en entornos que requieren una hora del sistema muy precisa y
estable.

Compatibilidad de alta precisión para

Windows 8.1 y 2012 R2 (o anterior)
Las versiones anteriores de Windows (anteriores a Windows 10, 1607, o
Windows Server 2016, 1607) no pueden garantizar una hora muy precisa. El servicio de
hora de Windows en estos sistemas:

Proporcionaba la precisión de hora necesaria para satisfacer los requisitos de

autenticación de Kerberos, versión 5.

Proporcionaba una hora algo preciso para los clientes y servidores de Windows
unidos a un bosque común de Active Directory.

Los requisitos de precisión más estrictos estaban fuera de la especificación de diseño

del servicio de hora de Windows en estos sistemas operativos y no se admite.

Windows 10 y Windows Server 2016

La precisión de la hora en Windows 10 y Windows Server 2016 ha mejorado
considerablemente, a la vez que se mantiene totalmente la compatibilidad de NTP con
versiones anteriores de Windows. En las condiciones de funcionamiento adecuadas, los
sistemas que ejecutan Windows 10 o Windows Server 2016 y versiones más recientes
pueden proporcionar una precisión de 1 segundo, 50 ms (milisegundos) o 1 ms.

） Importante
 Orígenes de la hora muy precisos
La precisión en la hora que se obtiene en la topología depende en gran medida del
uso de un origen de la hora preciso y estable (estrato 1). Hay terceros proveedores
que venden hardware de origen de la hora NTP, compatible con Windows,
sumamente preciso, basado en Windows y no basado en Windows. Ponte en
contacto con tu proveedor para conocer la precisión de sus productos.

） Importante

Precisión de la hora
La precisión de la hora conlleva la distribución de un extremo a otro de la hora
precisa desde un origen de la hora de autoridad sumamente preciso hasta el
dispositivo final. Todo lo que introduce asimetría de red influirá negativamente en
la precisión, por ejemplo, los dispositivos físicos de red o una alta carga de CPU en
el sistema de destino.

Requisitos para la alta precisión

En el resto de este documento se describen los requisitos del entorno que deben
cumplirse para admitir los objetivos de alta precisión correspondientes.

Precisión del destino: 1 segundo (1 s)

Para lograr la precisión de 1 s para un equipo de destino específico en comparación con
un origen de la hora muy preciso:

El sistema de destino debe ejecutar Windows 10 o Windows Server 2016.

El sistema de destino debe sincronizar la hora desde una jerarquía NTP de

servidores de hora, que culmina en un origen de la hora NTP compatible con
Windows y muy preciso.

Todos los sistemas operativos Windows de la jerarquía NTP mencionados

anteriormente deben configurarse según se documentan en la documentación
Configuración de sistemas para alta precisión.

La latencia de red un sentido acumulativa entre el destino y el origen no debe

superar los 100 ms. El retraso acumulativo de la red se mide sumando los retrasos
unidireccionales individuales entre pares de nodos cliente-servidor NTP de la
 jerarquía a partir del destino y finalizando en el origen. Para más información,
consulta el documento de sincronización de la hora de alta precisión.

Precisión del destino: 50 milisegundos

Se aplican todos los requisitos descritos en la sección Precisión del destino: 1 segundo,
excepto en el caso de los controles más estrictos que se describen en esta sección.

Los otros requisitos para lograr una precisión de 50 ms para un sistema de destino
específico son:

El equipo de destino debe tener más de 5 ms de latencia de red entre su origen de

hora.

El sistema de destino no debe estar más allá del estrato 5 de un origen de la hora
muy preciso.

７ Nota

Ejecuta "w32tm /query /status" desde la línea de comandos para ver el

estrato.

El sistema de destino debe estar dentro de 6 saltos de red o menos desde el

origen de la hora muy preciso.

El uso promedio de CPU de un día en todos los estratos no debe superar el 90 %.

En el caso de los sistemas virtualizados, el uso promedio de CPU de un día del host
no debe superar el 90 %.

Precisión del destino: 1 milisegundo

Se aplican todos los requisitos descritos en las secciones Precisión del destino: 1
segundo y Precisión del destino: 50 milisegundos, excepto en el caso de los controles
más estrictos que se describen en esta sección.

Los otros requisitos para lograr una precisión de 1 ms para un sistema de destino
específico son:

El equipo de destino debe tener una latencia de red inferior a 0,1 ms entre su
origen de la hora.
El sistema de destino no debe estar más allá del estrato 5 de un origen de la hora
muy preciso.

７ Nota

Ejecuta "w32tm /query /status" desde la línea de comandos para ver el

estrato.

El sistema de destino debe estar dentro de 4 saltos de red o menos desde el

origen de la hora muy preciso.

El uso promedio de CPU de un día en cada estrato no debe superar el 80 %.

En el caso de los sistemas virtualizados, el uso promedio de CPU de un día del host
no debe superar el 80 %.
Configuración de sistemas para alta
precisión
Artículo • 21/12/2022 • Tiempo de lectura: 5 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016 y
Windows 10 versión 1607 o posterior, Azure Stack HCI, versiones 21H2 y 20H2

La sincronización de la hora en Windows 10 y Windows Server 2016 se ha mejorado

considerablemente. En condiciones de funcionamiento razonables, los sistemas se
pueden configurar para mantener una precisión de 1 ms (milisegundos) o mejor (con
respecto a la hora UTC).

La siguiente guía te ayudará a configurar los sistemas para lograr una alta precisión. En
este artículo se tratan los siguientes requisitos:

Sistemas operativos compatibles

Configuración del sistema

２ Advertencia

Objetivos de precisión de los sistemas operativos anteriores

Windows Server 2012 R2 y versiones anteriores no pueden cumplir los mismos
objetivos de alta precisión. Estos sistemas operativos no son compatibles con una
alta precisión.

En estas versiones, el servicio de hora de Windows cumplía los siguientes

requisitos:

Proporcionaba la precisión de hora necesaria para satisfacer los requisitos de

autenticación de Kerberos, versión 5.
Proporcionaba una hora algo preciso para los clientes y servidores de
Windows unidos a un bosque común de Active Directory.

Las mayores tolerancias en 2012 R2 y versiones anteriores están fuera de la

especificación de diseño del servicio de hora de Windows.

Configuración predeterminada de Windows 10

y Windows Server 2016
Si bien se admite la precisión de hasta 1 ms en Windows 10 o Windows Server 2016, la
mayoría de los clientes no requiere una hora sumamente precisa.

Por tanto, la configuración predeterminada está diseñada para cumplir con los mismos
requisitos que los sistemas operativos anteriores, es decir:

Proporcionar la precisión de hora necesaria para satisfacer los requisitos de

autenticación de Kerberos, versión 5.
Proporcionar una hora algo preciso para los clientes y servidores de Windows
unidos a un bosque común de Active Directory.

Procedimiento: Configuración de sistemas para

alta precisión

） Importante

Nota sobre la compatibilidad de los sistemas altamente precisos

La precisión de la hora conlleva la distribución de un extremo a otro de la hora
precisa desde el origen de la hora de autoridad hasta el dispositivo final. Todo lo
que agregue asimetría en las medidas a lo largo de este camino influirá
negativamente en la precisión y afectará a la precisión que puedan alcanzar los
dispositivos.

Por esta razón, hemos documentado el Límite de compatibilidad para configurar

el servicio de hora de Windows para entornos de alta precisión, que describe los
requisitos del entorno que también deben cumplirse para alcanzar objetivos de alta
precisión.

Requisitos del sistema operativo

Las configuraciones de alta precisión requieren Windows 10 o Windows Server 2016.
Todos los dispositivos Windows en la topología de hora deben cumplir este requisito,
incluidos los servidores de hora de Windows de estrato superior y, en escenarios
virtualizados, los hosts de Hyper-V que ejecutan las máquinas virtuales sujetas a
limitaciones temporales. Todos estos dispositivos deben ejecutar al menos Windows 10
o Windows Server 2016.

En la ilustración que se muestra a continuación, las máquinas virtuales que requieren

alta precisión ejecutan Windows 10 o Windows Server 2016. Del mismo modo, el host
de Hyper-V en el que residen las máquinas virtuales y el servidor de hora de Windows
de nivel superior también deben ejecutar Windows Server 2016.

 Sugerencia

Comprobación de la versión de Windows

Puede ejecutar el comando winver en un símbolo del sistema para verificar si la
versión del sistema operativo es 1607 (o posterior) y que la compilación del sistema
operativo es 14393 (o superior), como se muestra a continuación:
Configuración del sistema
Alcanzar destinos de alta precisión requiere la configuración del sistema. Hay varias
maneras de realizar esta configuración, entre otras, directamente en el registro o a
través de la directiva de grupo. Puede encontrar más información para cada una de
estas opciones en la referencia técnica del servicio de hora de Windows: herramientas
de servicio de hora de Windows.

Tipo de inicio del servicio de hora de Windows

El servicio de hora de Windows (W32Time) debe ejecutarse de manera continua. Para
ello, configure el tipo de inicio del servicio de hora de Windows en "Automático".

Latencia de red unidireccional acumulativa

La incertidumbre de medición y el "ruido" se incrementan a medida que aumenta la

latencia de red. Por tanto, es de vital importancia que la latencia de red esté dentro de
un límite razonable. Los requisitos específicos dependen de la precisión de destino y se
describen en el artículo Límite de compatibilidad para configurar el servicio de hora de
Windows para entornos de alta precisión.
Para calcular la latencia de red unidireccional acumulativa, agrega los retrasos
unidireccionales individuales entre pares de nodos cliente-servidor NTP en la topología
de hora, empezando por el destino y finalizando en el origen de la hora de estrato 1 de
alta precisión.

Por ejemplo: Considera la posibilidad de una jerarquía de sincronización de hora con un

origen muy preciso, dos servidores NTP intermedios (A y B), y la máquina de destino, en
ese orden. Para obtener la latencia de red acumulativa entre el destino y el origen, mide
el promedio de tiempo de ida y vuelta (RTT) de NTP individual entre:

El destino y el servidor de hora B

El servidor de hora B y el servidor de hora A
El servidor de hora A y el origen

Esta medición puede obtenerse mediante la herramienta de bandeja de entrada

[Link]. Para ello:

1. Haz el cálculo desde el destino y servidor de hora B.

w32tm /stripchart /computer:TimeServerB /rdtsc /samples:450 >

c:\temp\Target_TsB.csv

2. Haz el cálculo desde el servidor de hora B frente a (apuntando a) el servidor de

hora A.

w32tm /stripchart /computer:TimeServerA /rdtsc /samples:450 >

c:\temp\Target_TsA.csv

3. Haz el cálculo desde el servidor de hora A frente al origen.

4. Luego, agrega el promedio de RoundTripDelay medido en el paso anterior y divide

entre 2 para obtener el retraso de red acumulativo entre el destino y el origen.

Configuración del Registro

MinPollInterval
Configura el intervalo más pequeño en log2 segundos permitidos para el sondeo del
sistema.

Descripción Value

Ubicación de la clave HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config

 Descripción Value

Valor 6

Resultado El intervalo de sondeo mínimo es ahora de 64 segundos.

El comando siguiente indica a la hora de Windows que recoja la configuración

actualizada: w32tm /config /update

MaxPollInterval
Configura el intervalo más grande en log2 segundos permitidos para el sondeo del
sistema.

Descripción Value

Ubicación de la clave HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config

Valor 6

Resultado El intervalo de sondeo máximo es ahora de 64 segundos.

El comando siguiente indica a la hora de Windows que recoja la configuración

actualizada: w32tm /config /update

UpdateInterval
El número de tics del reloj entre los ajustes de corrección de fase.

Descripción Value

Ubicación de la HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config
clave

Valor 100

Resultado El número de tics del reloj entre los ajustes de corrección de fase es ahora de
100 tics.

El comando siguiente indica a la hora de Windows que recoja la configuración

actualizada: w32tm /config /update

SpecialPollInterval
Configura el intervalo de sondeo en segundos cuando la marca SpecialInterval 0x1 está
habilitada.

Descripción Value

Ubicación de la HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
clave

Valor 64

Resultado El intervalo de sondeo es ahora de 64 segundos.

El comando siguiente reinicia la hora de Windows para recoger la configuración

actualizada: net stop w32time && net start w32time

FrequencyCorrectRate

Descripción Value

Ubicación de la clave HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config

Valor 2
Hora de Windows para rastreabilidad
Artículo • 21/12/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016
versión 1709 o posterior, y Windows 10 versión 1703 o posterior, Azure Stack HCI,
versiones 21H2 y 20H2

Las normas de muchos sectores exigen que los sistemas puedan rastrearse según la
hora UTC. Esto significa que se pueda dar fe de la diferencia horaria de un sistema con
respecto a UTC. Para habilitar los escenarios de cumplimiento normativo, Windows 10
(versión 1703 o posterior) y Windows Server 2016 (versión 1709 o posterior)
proporcionan nuevos registros de eventos para dar una imagen desde la perspectiva del
sistema operativo con el objetivo de comprender las medidas adoptadas en el reloj del
sistema. Estos registros de eventos se generan continuamente para el servicio de hora
de Windows y se pueden examinar o archivar para su posterior análisis.

Estos nuevos eventos permiten responder a las siguientes preguntas:

¿Se modificó el reloj del sistema?

¿Se modificó la frecuencia del reloj?
¿Se modificó la configuración del servicio de hora de Windows?

Disponibilidad
Estas mejoras se incluyen en Windows 10, versión 1703 o posterior, y en
Windows Server 2016, versión 1709 o posterior.

Configuración
No se necesita ninguna configuración para usar esta característica. Estos registros de
eventos están habilitados de forma predeterminada y se pueden encontrar en el visor
de eventos, en el canal Applications and Services Log\Microsoft\Windows\Time-
Service\Operational.

Lista de registros de eventos

En la siguiente sección se describen los eventos registrados para su uso en escenarios
de rastreabilidad.
257

Este evento se registra cuando se inicia el servicio de hora de Windows (W32Time)

y registra información sobre la hora actual, el recuento de tics actual, la
configuración en tiempo de ejecución, los proveedores de hora y la velocidad de
reloj actual.

Descripción del evento Inicio del servicio

Detalles Tiene lugar en el inicio de W32time

Datos registrados Hora actual en UTC

Recuento de tics actual
Configuración de W32Time
Configuración del proveedor de hora
Frecuencia del reloj

Mecanismo de limitación Ninguna. Este evento se activa cada vez que se inicia el servicio.

Ejemplo:

W32time service has started at 2018-02-27T04:25:17.156Z (UTC), System

Tick Count 3132937.

Comando:

También se puede consultar esta información mediante los siguientes comandos.

Configuración del proveedor de hora y W32Time

[Link] /query /configuration

Frecuencia del reloj

[Link] /query /status /verbose

Referencia técnica del servicio de hora
de Windows
Artículo • 21/12/2022 • Tiempo de lectura: 6 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012, Windows 10 o posterior, Azure
Stack HCI, versiones 21H2 y 20H2

El servicio W32Time proporciona sincronización del reloj de red para los equipos sin
necesidad de una extensa configuración. El servicio W32Time es esencial para el
correcto funcionamiento de la autenticación Kerberos, versión 5, y, por tanto, para la
autenticación basada en AD DS. Cualquier aplicación que reconozca Kerberos, incluida
la mayoría de los servicios de seguridad, se basa en la sincronización de la hora entre los
equipos que participan en la solicitud de autenticación. Los controladores de dominio
de AD DS también deben tener los relojes sincronizados para asegurar que la
replicación de los datos sea precisa.

７ Nota

En Windows Server 2003 y Microsoft Windows 2000 Server, el servicio de directorio

se denomina Servicio de directorio de Active Directory. En Windows Server 2008 R2
y Windows Server 2008, el servicio de directorio se denomina Servicios de dominio
de Active Directory (AD DS). El resto de este tema hace referencia a AD DS, pero la
información también se puede aplicar a Active Directory Domain Services en
Windows Server 2016.

El servicio W32Time está implementado en una biblioteca de vínculos dinámicos

denominada [Link], que se instala de forma predeterminada en
%Systemroot%\System32. [Link] se desarrolló originalmente para que
Windows 2000 Server admitiera una especificación del protocolo de autenticación de
Kerberos versión 5 que requería la sincronización de los relojes de una red. A partir de
Windows Server 2003, [Link] proporcionaba mayor precisión en la sincronización
del reloj de red hasta el sistema operativo Windows Server 2000. Además, en
Windows Server 2003, [Link] admitía una variedad de dispositivos de hardware y
protocolos de hora de red mediante proveedores de hora.

Aunque originalmente se diseñó para proporcionar sincronización de reloj para la

autenticación de Kerberos, muchas aplicaciones actuales usan marcas de tiempo para
garantizar la coherencia transaccional, registrar la hora de eventos importantes y demás
información crítica sujeta a limitaciones temporales. Estas aplicaciones se benefician de
la sincronización de la hora entre los equipos que proporciona el servicio de hora de
Windows.

Importancia de los protocolos de hora

Los protocolos de hora se comunican entre dos equipos para intercambiar información
de hora y, luego, usan esa información para sincronizar sus relojes. Con el protocolo de
hora del servicio de hora de Windows, un cliente solicita información de hora a un
servidor y sincroniza su reloj en función de la información recibida.

El servicio de hora de Windows usa NTP para ayudar a sincronizar la hora a través de
una red. NTP es un protocolo de hora de Internet que incluye los algoritmos de
sincronización necesarios para sincronizar los relojes. NTP es un protocolo de hora más
preciso que el Protocolo simple de tiempo de redes (SNTP) que se usa en algunas
versiones de Windows; sin embargo, W32Time sigue admitiendo SNTP para habilitar la
compatibilidad con versiones anteriores con equipos que ejecutan servicios de hora
basados en SNTP, como Windows 2000.

Dónde encontrar la información relacionada

con la configuración del servicio de hora de
Windows
En esta guía no se analiza la configuración del servicio de hora de Windows. Hay varios
temas diferentes en Microsoft TechNet y en Microsoft Knowledge Base que sí explican
los procedimientos para configurar el servicio de hora de Windows. Si necesitas
información de configuración, los temas siguientes te ayudarán a ubicar la información
adecuada.

Para configurar el servicio de hora de Windows para el emulador del controlador

de dominio principal (PDC) raíz del bosque, consulta:

Configuración del servicio de hora de Windows en el emulador de PDC del

dominio raíz del bosque

Configuración de un origen de la hora para el bosque

En el artículo 816042 de Microsoft Knowledge Base, Cómo configurar un

servidor horario autoritativo en Windows Server, que describe los valores de
configuración de los equipos que ejecutan Windows Server 2008 R2, Windows
Server 2008, Windows Server 2003 y Windows Server 2003 R2.
Para configurar el servicio de hora de Windows en cualquier cliente o servidor
miembro del dominio, o incluso en controladores de dominio que no estén
configurados como el emulador de PDC de la raíz del bosque, consulta
Configuración de un equipo cliente para la sincronización automática de hora del
dominio.

２ Advertencia

Es posible que algunas aplicaciones requieran que sus equipos tengan

servicios de hora de alta precisión. En ese caso, puedes optar por configurar
un origen de hora manual, pero ten en cuenta que el servicio de la hora de
Windows no se diseñó para funcionar como origen de hora de alta precisión.
Asegúrate de conocer las limitaciones de compatibilidad para los entornos de
hora de alta precisión, como se describe en el artículo 939322 de Microsoft
Knowledge Base, Límite de compatibilidad para configurar el servicio de
hora de Windows para entornos de alta precisión.

Para configurar el servicio de hora de Windows en equipos cliente o servidor

basados en Windows que estén configurados como miembros del grupo de
trabajo en lugar de miembros del dominio, consulta Configuración de un origen
de la hora manual para un equipo cliente seleccionado.

Para configurar el servicio de hora de Windows en un equipo host que ejecuta un

entorno virtual, consulta el artículo 816042 de Microsoft Knowledge Base, Cómo
configurar un servidor horario autoritativo en Windows Server. Si trabajas con un
producto de virtualización que no es de Microsoft, asegúrate de consultar la
documentación del proveedor de ese producto.

Para configurar el servicio de hora de Windows en un controlador de dominio que

se ejecuta en una máquina virtual, se recomienda deshabilitar parcialmente la
sincronización de hora entre el sistema host y el sistema operativo invitado que
funciona como controlador de dominio. Esto permite que el controlador de
dominio invitado sincronice la hora de la jerarquía de dominios, pero evita que
tenga un sesgo horario si se restaura a partir de un estado guardado. Para obtener
más información, consulta el artículo 976924 de Microsoft Knowledge Base, Recibir
servicio de hora de Windows de los identificadores de sucesos 24, 29 y 38 en un
controlador de dominio virtualizado que se ejecuta en un servidor basado en
Windows Server 2008 con Hyper-V y Consideraciones de implementación para
controladores de dominio virtualizados.
 Para configurar el servicio de hora de Windows en un controlador de dominio que
funciona como emulador PDC raíz del bosque que también se ejecuta en un
equipo virtual, sigue las mismas instrucciones que para un equipo físico, tal como
se describe en Configuración del servicio de hora de Windows en el emulador de
PDC del dominio raíz del bosque.

Para configurar el servicio de hora de Windows en un servidor miembro que se

ejecuta como equipo virtual, usa la jerarquía de hora del dominio, tal y como se
describe en Configuración de un equipo cliente para la sincronización automática
de hora del dominio.

） Importante

Antes de Windows Server 2016, el servicio W32Time no estaba diseñado para

satisfacer las necesidades de las aplicaciones sujetas a limitaciones temporales. Sin
embargo, las actualizaciones de Windows Server 2016 ahora permiten implementar
una solución con una precisión de 1 ms en el dominio. Para obtener más
información, consulte Windows límite de tiempo preciso y soporte técnico de
Windows 2016para configurar el servicio de tiempo de Windows para entornos
de alta precisión para obtener más información.

Temas relacionados
Hora precisa para Windows Server 2016
Mejoras a la precisión temporal para Windows Server 2016
Funcionamiento del servicio Hora de Windows
Configuración y herramientas del servicio Hora de Windows
Support boundary to configure the Windows Time service for high-accuracy
environments (Límite del soporte técnico para configurar el servicio de hora de
Windows en entornos de alta precisión)
Funcionamiento del servicio Hora de
Windows
Artículo • 21/12/2022 • Tiempo de lectura: 28 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012, Windows 10 o posterior, Azure
Stack HCI, versiones 21H2 y 20H2

En esta sección

Arquitectura de servicio de hora de Windows

Protocolos de hora del servicio de hora de Windows

Procesos e interacciones del servicio de hora de Windows

Puertos de red usados por el servicio de hora de Windows

７ Nota

En este tema solo se explica cómo funciona el servicio de hora de Windows

(W32Time). Para obtener información sobre cómo configurar el servicio de hora de
Windows, consulta Configuración de sistemas para alta precisión.

７ Nota

En Windows Server 2003 y Microsoft Windows 2000 Server, el servicio de directorio

se denomina Servicio de directorio de Active Directory. En Windows Server 2008 y
versiones posteriores, el servicio de directorio se denomina Servicios de dominio de
Active Directory (AD DS). El resto de este tema hace referencia a AD DS, pero la
información también es aplicable a Active Directory.

Aunque el servicio de hora de Windows no es una implementación exacta del Protocolo

de tiempo de redes (NTP), usa el conjunto de algoritmos complejo que se define en las
especificaciones de NTP para asegurarse de que los relojes de los equipos de una red
sean lo más precisos posible. Idealmente, todos los relojes de los equipos de un
dominio de AD DS están sincronizados con la hora de un equipo autoritativo. Muchos
factores pueden afectar a la sincronización de la hora en una red. Los siguientes factores
suelen afectar a la precisión de la sincronización en AD DS:
 Las condiciones de la red

La precisión del reloj de hardware del equipo

La cantidad de recursos de CPU y de red a disposición del servicio de hora de

Windows

） Importante

Antes de Windows Server 2016, el servicio W32Time no estaba diseñado para

satisfacer las necesidades de las aplicaciones sujetas a limitaciones temporales. Sin
embargo, las actualizaciones de Windows Server 2016 ahora permiten implementar
una solución con una precisión de 1 ms en el dominio. Vea el límite de hora precisa
y soporte técnico de Windows 2016para configurar el servicio de hora de
Windows para entornos de alta precisión para obtener más información.

Los equipos que sincronizan su hora con menos frecuencia o que no están unidos a un
dominio están configurados de forma predeterminada para sincronizarse con
[Link]. Por lo tanto, no es posible garantizar la exactitud de la hora en los
equipos que tienen conexiones de red intermitentes o sin conexión.

Un bosque de AD DS tiene una jerarquía de sincronización de hora predeterminada. El

servicio de hora de Windows sincroniza la hora entre los equipos de la jerarquía, donde
los relojes de referencia más precisos se encuentran en la parte superior. Si se configura
más de un origen de hora en un equipo, la hora de Windows usa algoritmos NTP para
seleccionar el mejor origen de la hora entre los orígenes configurados en función de la
capacidad del equipo de sincronizarse con ese origen de hora. El servicio de hora de
Windows no admite la sincronización de red desde pares de difusión o del mismo nivel.
Para más información sobre estas características de NTP, consulta el documento
RFC 1305 en la base de datos RFC de IETF.

Cada equipo que ejecuta el servicio de hora de Windows usa el servicio para mantener
la hora más precisa. Los equipos que son miembros de un dominio funcionan como
clientes de hora de forma predeterminada; por lo tanto, en la mayoría de los casos no es
necesario configurar el servicio de hora de Windows. Sin embargo, el servicio de hora de
Windows se puede configurar para solicitar la hora desde un origen de la hora de
referencia designado, y también puede proporcionar la hora a clientes.

El grado de precisión de la hora de un equipo se denomina "estrato". El origen de la

hora más preciso en una red (por ejemplo, un reloj de hardware) ocupa el nivel de
estrato más bajo o el estrato uno. Este origen de la hora preciso se denomina "reloj de
referencia". Un servidor NTP que adquiere su hora directamente de un reloj de
referencia ocupa un estrato que es un nivel superior al del reloj de referencia. Los
recursos que adquieren la hora del servidor NTP están a dos pasos del reloj de
referencia y, por tanto, ocupan un estrato que es dos veces mayor que el origen de la
hora más preciso, y así sucesivamente. A medida que aumenta el número de estrato de
un equipo, la hora en el reloj del sistema puede ser menos precisa. Por lo tanto, el nivel
de estrato de cualquier equipo es un indicador de cuán sincronizado está ese equipo
con el origen de la hora más preciso.

Cuando el administrador de W32Time recibe ejemplos de hora, usa algoritmos

especiales en NTP para determinar cuál de los ejemplos de hora es el más adecuado
para su uso. El servicio de hora también usa otro conjunto de algoritmos para
determinar cuál de los orígenes de la hora configurados es el más preciso. Cuando el
servicio de hora ha determinado cuál muestra de hora es la mejor, en función de los
criterios anteriores, ajusta la frecuencia del reloj local para que pueda converger hacia la
hora correcta. Si la diferencia de hora entre el reloj local y la muestra de hora exacta
seleccionada (también denominado "sesgo horario") es demasiado grande para
corregirla ajustando la frecuencia del reloj local, el servicio de hora establece el reloj
local en la hora correcta. Este ajuste de la frecuencia del reloj o el cambio directo de la
hora del reloj se conocen como "sincronización de reloj".

Arquitectura de servicio de hora de Windows

El servicio de hora de Windows consta de los siguientes componentes:

Administrador de control de servicios

Administrador del servicio de hora de Windows

Sincronización de reloj

Proveedores de hora

En la ilustración siguiente se muestra la arquitectura del servicio de hora de Windows.

Arquitectura de servicio de hora de Windows

El administrador de control de servicios es responsable de iniciar y detener el servicio de
hora de Windows. El administrador del servicio de hora de Windows es responsable de
iniciar la acción de los proveedores de hora de NTP incluidos con el sistema operativo.
El administrador del servicio de hora de Windows controla todas las funciones del
servicio de hora de Windows y la fusión de todas las muestras de hora. Además de
proporcionar información sobre el estado actual del sistema, como el origen de la hora
actual o la última vez que se actualizó el reloj del sistema, el administrador del servicio
de hora de Windows también es responsable de crear eventos en el registro de eventos.

El proceso de sincronización de la hora conlleva los siguientes pasos:

Los proveedores de entrada solicitan y reciben las muestras de hora de los

orígenes de la hora NTP configurados.

Estos ejemplos de hora se pasan luego al administrador del servicio de hora de

Windows, que recopila todas las muestras y las pasa al subcomponente de
sincronización de reloj.

El subcomponente de sincronización de reloj aplica los algoritmos NTP, lo que da

como resultado la selección de la mejor muestra de hora.

El subcomponente de sincronización de reloj ajusta la hora del reloj del sistema a

la hora más precisa, ya sea ajustando la frecuencia del reloj o cambiando la hora
directamente.

Si se ha designado un equipo como servidor de hora, puede enviar la hora a cualquier

equipo que solicite la sincronización de la hora en cualquier momento de este proceso.

Protocolos de hora del servicio de hora de

Windows
Los protocolos de hora determinan el grado de sincronización de los relojes de dos
equipos. Un protocolo de hora es responsable de determinar la mejor información de
hora disponible y de hacer converger los relojes para asegurarse de que se mantenga
una hora uniforme en sistemas independientes.

El servicio de hora de Windows usa el Protocolo de tiempo de redes (NTP) para ayudar a
sincronizar la hora a través de una red. NTP es un protocolo de hora de Internet que
incluye los algoritmos de sincronización necesarios para sincronizar los relojes. NTP es
un protocolo de hora más preciso que el Protocolo simple de tiempo de redes (SNTP)
que se usa en algunas versiones de Windows; sin embargo, W32Time sigue admitiendo
SNTP para habilitar la compatibilidad con versiones anteriores con equipos que ejecutan
servicios de hora basados en SNTP, como Windows 2000.

Protocolo de tiempo de redes

El Protocolo de tiempo de redes (NTP) es el protocolo de sincronización de hora
predeterminado que usa el servicio de hora de Windows en el sistema operativo. NTP es
un protocolo de hora altamente escalable y tolerante a errores, y es el protocolo que se
usa con mayor frecuencia para sincronizar los relojes de los equipos mediante una
referencia de hora designada.

La sincronización de la hora de NTP tiene lugar durante un cierto período e implica la

transferencia de paquetes NTP a través de una red. Los paquetes NTP contienen marcas
de tiempo que incluyen una muestra de hora tanto del cliente como del servidor que
participan en la sincronización de la hora.

NTP se basa en un reloj de referencia para definir la hora más precisa que se va a usar, y
sincroniza todos los relojes de una red con ese reloj de referencia. NTP usa la hora
universal coordinada (UTC) como estándar universal para la hora actual. La hora UTC es
independiente de las zonas horarias y permite usar NTP en cualquier parte del mundo,
independientemente de la configuración de la zona horaria.

Algoritmos de NTP
NTP incluye dos algoritmos, un algoritmo de filtrado de relojes y un algoritmo de
selección de reloj, para ayudar al servicio de hora de Windows a determinar la mejor
muestra de hora. El algoritmo de filtrado de relojes está diseñado para examinar las
muestras de hora que se reciben de los orígenes de hora consultados y determinar las
mejores muestras de hora de cada origen. Luego, el algoritmo de selección de reloj
determina el servidor de hora más preciso de la red. A continuación, esta información se
pasa al algoritmo de sincronización de reloj, que usa la información recopilada para
corregir el reloj local del equipo, a la vez que compensa los errores debido a la latencia
de la red y a la inexactitud del reloj del equipo.

Los algoritmos de NTP son más precisos en condiciones de cargas de red y de servidor
de bajas a intermedias. Como con cualquier algoritmo que tiene en cuenta el tiempo de
tránsito por la red, los algoritmos de NTP podrían tener un bajo rendimiento en
condiciones de congestión extrema de la red. Para más información sobre los
algoritmos de NTP, consulta el documento RFC 1305 en la base de datos RFC de IETF.

Proveedor de hora de NTP

El servicio de hora de Windows es un paquete completo de sincronización de la hora

que puede admitir una variedad de dispositivos de hardware y protocolos de hora. Para
habilitar esta compatibilidad, el servicio usa proveedores de hora conectables. Un
proveedor de hora es responsable de obtener marcas de tiempo precisas (de la red o
del hardware) o de proporcionar dichas marcas de tiempo a otros equipos a través de la
red.

El proveedor de NTP es el proveedor de hora estándar incluido con el sistema operativo.

El proveedor de NTP sigue los estándares especificados por NTP, versión 3, para un
cliente y servidor, y puede interactuar con clientes y servidores SNTP para mantener la
compatibilidad con versiones anteriores de Windows 2000 y otros clientes SNTP. El
proveedor de NTP en el servicio de hora de Windows consta de las siguientes dos
partes:

Proveedor de salida NtpServer. Se trata de un servidor de hora que responde a las

solicitudes de hora de los clientes en la red.

Proveedor de entrada NtpClient. Se trata de un cliente de hora que obtiene

información de hora de otro origen, ya sea un dispositivo de hardware o un
servidor NTP, y puede devolver muestras de hora que son útiles para sincronizar el
reloj local.

Aunque las operaciones reales de estos dos proveedores están estrechamente

relacionadas, se muestran independientes ante el servicio de hora. A partir de
Windows 2000 Server, cuando un equipo Windows está conectado a una red, se
configura como cliente NTP. Además, los equipos que ejecutan el servicio de hora de
Windows solo intentan sincronizar la hora con un controlador de dominio o un origen
de hora especificado manualmente de manera predeterminada. Estos son los
proveedores de hora preferidos porque son orígenes de hora que están disponibles de
forma automática y son seguros.
Seguridad de NTP
Dentro de un bosque de AD DS, el servicio de hora de Windows se basa en las
características de seguridad estándar del dominio para aplicar la autenticación de los
datos de hora. La seguridad de los paquetes NTP que se envían entre un equipo
miembro del dominio y un controlador de dominio local que funciona como servidor de
hora se basa en la autenticación de clave compartida. El servicio de hora de Windows
usa la clave de sesión de Kerberos del equipo para crear firmas autenticadas en los
paquetes NTP que se envían a través de la red. Los paquetes NTP no se transmiten
dentro del canal seguro de Inicio de sesión de red. En su lugar, cuando un equipo
solicita la hora a un controlador de dominio en la jerarquía de dominios, el servicio de
hora de Windows requiere que se autentique la hora. Luego, el controlador de dominio
devuelve la información necesaria en forma de un valor de 64 bits que se ha autenticado
con la clave de sesión del servicio Inicio de sesión de red. Si el paquete NTP devuelto no
está firmado con la clave de sesión del equipo o tiene una firma incorrecta, se rechaza la
hora. Todos estos errores de autenticación se registran en el Registro de eventos. De
este modo, el servicio de hora de Windows proporciona seguridad para los datos de
NTP en un bosque de AD DS.

Por lo general, los clientes de hora de Windows obtienen automáticamente la hora

precisa para la sincronización desde controladores de dominio en el mismo dominio. En
un bosque, los controladores de dominio de un dominio secundario sincronizan la hora
con los controladores de dominio de sus dominios primarios. Cuando un servidor de
hora devuelve un paquete NTP autenticado a un cliente que solicita la hora, el paquete
se firma por medio de una clave de sesión de Kerberos definida por una cuenta de
confianza entre dominios. La cuenta de confianza entre dominios se crea cuando un
nuevo dominio de AD DS se une a un bosque, y el servicio Inicio de sesión de red
administra la clave de sesión. De este modo, el controlador de dominio que está
configurado como de confianza en el dominio raíz del bosque se convierte en el origen
de la hora autenticado para todos los controladores de dominio, tanto de los dominios
primarios como secundarios, e indirectamente en todos los equipos ubicados en el
árbol de dominios.

El servicio de hora de Windows se puede configurar para que funcione entre bosques,
pero es importante tener en cuenta que esta configuración no es segura. Por ejemplo,
un servidor NTP podría estar disponible en otro bosque. Sin embargo, dado que ese
equipo está en otro bosque, no hay ninguna clave de sesión de Kerberos con la cual
firmar y autenticar los paquetes NTP. Para obtener una sincronización de hora precisa
de un equipo en otro bosque, el cliente necesita acceso de red a ese equipo, y el
servicio de hora debe estar configurado para usar un origen de la hora específico
ubicado en el otro bosque. Si un cliente se configura manualmente para acceder a la
hora desde un servidor NTP fuera de su propia jerarquía de dominios, los paquetes NTP
enviados entre el cliente y el servidor de hora no se autentican y, por lo tanto, no son
seguros. Incluso con la implementación de confianzas de bosque, el servicio de hora de
Windows no es seguro entre bosques. Aunque el canal seguro de Inicio de sesión de red
es el mecanismo de autenticación para el servicio de hora de Windows, no se admite la
autenticación entre bosques.

Dispositivos de hardware admitidos por el servicio de hora de

Windows

Los relojes basados en hardware, como GPS o relojes de radio, suelen usarse como
dispositivos de reloj de referencia muy precisos. De manera predeterminada, el
proveedor de hora NTP del servicio de hora de Windows no admite la conexión directa
de un dispositivo de hardware a un equipo, aunque es posible crear un proveedor de
hora independiente basado en software que admita este tipo de conexión. Este tipo de
proveedor, junto con el servicio de hora de Windows, puede proporcionar una
referencia de hora estable y confiable.

Los dispositivos de hardware, como un reloj de cesio o un receptor del sistema de

posicionamiento global (GPS), proporcionan la hora actual precisa siguiendo un
estándar para obtener una definición precisa de la hora. Los relojes de cesio son
extremadamente estables y no se ven afectados por factores como la temperatura, la
presión ni la humedad, pero también son muy costosos. Un receptor de GPS funciona
de manera mucho más económica y también es un reloj de referencia preciso. Los
receptores de GPS obtienen la hora a partir de satélites que obtienen su hora a partir de
un reloj de cesio. Si no se usa un proveedor de hora independiente, los servidores de
hora de Windows pueden adquirir la hora mediante la conexión a un servidor NTP
externo, que se conecta a un dispositivo de hardware por medio de un teléfono o
Internet. Las organizaciones como el Observatorio Naval de Estados Unidos
proporcionan servidores NTP que están conectados a relojes de referencia
extremadamente confiables.

Muchos receptores de GPS y otros dispositivos de hora pueden funcionar como

servidores NTP en una red. Puedes configurar el bosque de AD DS para que sincronice
la hora a partir de estos dispositivos de hardware externos solo si también funcionan
como servidores NTP en la red. Para ello, configura el controlador de dominio que
funciona como emulador del controlador de dominio principal (PDC) en la raíz del
bosque para que se sincronice con el servidor NTP proporcionado por el dispositivo
GPS. Para ello, consulta Configuración del servicio de hora de Windows en el emulador
de PDC del dominio raíz del bosque.

Protocolo simple de tiempo de redes

El Protocolo simple de tiempo de redes (SNTP) es un protocolo de hora simplificado
diseñado para servidores y clientes que no requieren el grado de precisión que
proporciona NTP. SNTP, una versión más rudimentaria de NTP, es el protocolo de hora
principal que se usa en Windows 2000. Dado que los formatos de los paquetes de red
de SNTP y NTP son idénticos, los dos protocolos son interoperables. La principal
diferencia entre los dos es que SNTP no tiene los sistemas de administración de errores
y de filtrado complejo que proporciona NTP. Para más información sobre el Protocolo
simple de tiempo de redes, consulta el documento RFC 1769 en la base de datos RFC de
IETF.

Interoperabilidad de protocolos de hora

El servicio de hora de Windows puede funcionar en un entorno mixto de equipos que
ejecutan Windows 2000, Windows XP y Windows Server 2003, ya que el protocolo SNTP
usado en Windows 2000 es interoperable con el protocolo NTP en Windows XP y
Windows Server 2003.

El servicio de hora de Windows NT Server 4.0, llamado TimeServ, sincroniza la hora a

través de una red de Windows NT 4.0. TimeServ es una característica complementaria
disponible como parte del Kit de recursos de Microsoft Windows NT 4.0 y no proporciona
el grado de confiabilidad de la sincronización de la hora que requiere
Windows Server 2003.

El servicio de hora de Windows puede interoperar con equipos que ejecutan

Windows NT 4.0 porque pueden sincronizar la hora con equipos que ejecutan
Windows 2000 o Windows Server 2003; sin embargo, un equipo que ejecuta
Windows 2000 o Windows Server 2003 no detecta automáticamente los servidores de
hora de Windows NT 4.0. Por ejemplo, si el dominio está configurado para sincronizar la
hora mediante el método de sincronización basado en la jerarquía de dominios, y
quieres que los equipos de la jerarquía de dominios sincronicen la hora con un
controlador de dominio de Windows NT 4.0, tendrás que configurar esos equipos
manualmente para que se sincronicen con los controladores de dominio de
Windows NT 4.0.

Windows NT 4.0 usa un mecanismo más sencillo para la sincronización de la hora que el
que usa el servicio de hora de Windows. Por lo tanto, para garantizar una precisa
sincronización de la hora en la red, se recomienda actualizar los controladores de
dominio de Windows NT 4.0 a Windows 2000 o Windows Server 2003.
Procesos e interacciones del servicio de hora
de Windows
El servicio de hora de Windows está diseñado para sincronizar los relojes de los equipos
de una red. El proceso de sincronización de la hora de la red, también denominado
"convergencia de la hora", se produce a lo largo de una red a medida que cada equipo
accede a la hora a partir de un servidor de hora más preciso. La convergencia de la hora
implica un proceso por el cual un servidor autoritativo proporciona la hora actual a los
equipos cliente en forma de paquetes NTP. La información proporcionada en un
paquete indica si es necesario realizar un ajuste en la hora actual del reloj del equipo
para que esté sincronizado con el servidor más preciso.

Como parte del proceso de convergencia de la hora, los miembros del dominio intentan
sincronizar la hora con cualquier controlador de dominio ubicado en el mismo dominio.
Si el equipo es un controlador de dominio, intenta sincronizarse con un controlador de
dominio con mayor autoridad.

Los equipos que ejecutan Windows XP Home Edition o los equipos que no están unidos
a un dominio no intentan sincronizarse con la jerarquía de dominios, sino que están
configurados de forma predeterminada para obtener la hora de [Link].

Para establecer un equipo que ejecute Windows Server 2003 como autoritativo, el
equipo debe estar configurado para ser un origen de la hora confiable. De manera
predeterminada, el primer controlador de dominio que se instala en un dominio de
Windows Server 2003 se configura automáticamente para que sea un origen de la hora
confiable. Dado que se trata del equipo autoritativo para el dominio, debe configurarse
para que se sincronice con un origen de la hora externo, en lugar de hacerlo con la
jerarquía de dominios. También de manera predeterminada, todos los demás miembros
de dominio de Windows Server 2003 están configurados para sincronizarse con la
jerarquía de dominios.

Después de establecer una red de Windows Server 2003, puedes configurar el servicio
de hora de Windows para que use una de las siguientes opciones para la sincronización:

La sincronización basada en la jerarquía de dominios

Un origen de sincronización especificado manualmente

Todos los mecanismos de sincronización disponibles

Sin sincronización

Cada uno de estos tipos de sincronización se analiza en las siguientes secciones.

Sincronización basada en la jerarquía de dominios
La sincronización que se basa en una jerarquía de dominios usa la jerarquía de dominios
de AD DS para buscar un origen confiable con el que sincronizar la hora. En función de
la jerarquía de dominios, el servicio de hora de Windows determina la precisión de cada
servidor de hora. En un bosque de Windows Server 2003, el equipo que contiene el rol
principal de operaciones del emulador del controlador de dominio principal (PDC),
ubicado en el dominio raíz del bosque, contiene la posición del mejor origen de la hora,
a menos que se haya configurado otro origen de la hora confiable. En la ilustración
siguiente se muestra una ruta para la sincronización de la hora entre equipos en una
jerarquía de dominios.

Sincronización de hora en una jerarquía de AD DS

Configuración de origen de la hora de confianza

Un equipo configurado para ser un origen de la hora de confianza se identifica como la
raíz del servicio de hora. La raíz del servicio de hora es el servidor autoritativo para el
dominio y normalmente está configurado para recuperar la hora a partir de un servidor
NTP o dispositivo de hardware externos. Se puede configurar un servidor de hora como
origen de la hora de confianza para optimizar la manera en que la hora se transfiere a
través de la jerarquía de dominios. Si un controlador de dominio está configurado para
ser un origen de la hora de confianza, el servicio Inicio de sesión de red anuncia ese
controlador de dominio como origen de la hora de confianza cuando inicia sesión en la
red. Cuando otros controladores de dominio buscan un origen de la hora con el cual
sincronizarse, eligen primero un origen de confianza si hay alguno disponible.

Selección del origen de la hora

El proceso de selección del origen de la hora puede generar dos problemas en una red:

Ciclos de sincronización adicionales.

Mayor volumen de tráfico en la red.

Un ciclo en la red de sincronización se produce cuando la hora permanece constante

entre un grupo de controladores de dominio, y comparten la misma hora entre ellos de
manera continua sin necesidad de volver a sincronizar con otro origen de la hora de
confianza. El algoritmo de selección del origen de la hora del servicio de hora de
Windows está diseñado para protegerse frente a estos tipos de problemas.

Un equipo usa uno de los métodos siguientes para identificar un origen de la hora con
el cual sincronizarse:

Si el equipo no es miembro de un dominio, debe configurarse para que se

sincronice con un origen de la hora especificado.

Si el equipo es un servidor miembro o una estación de trabajo dentro de un

dominio, de manera predeterminada sigue la jerarquía de AD DS y sincroniza la
hora con un controlador de dominio en su dominio local que esté ejecutando
actualmente el servicio de hora de Windows.

Si el equipo es un controlador de dominio, hace hasta seis consultas para encontrar otro
controlador de dominio con el cual sincronizarse. Cada consulta está diseñada para
identificar un origen de la hora con determinados atributos, como un tipo de
controlador de dominio, una ubicación determinada y si es un origen de la hora de
confianza o no. El origen de la hora también debe cumplir las restricciones siguientes:
 Un origen la de hora de confianza solo puede sincronizarse con un controlador de
dominio en el dominio primario.

Un emulador de PDC se puede sincronizar con un origen de la hora de confianza

en su propio dominio o en cualquier controlador de dominio del dominio primario.

Si el controlador de dominio no se puede sincronizar con el tipo de controlador de

dominio que está consultando, no se hace la consulta. El controlador de dominio sabe
de qué tipo de equipo puede obtener la hora antes de hacer la consulta. Por ejemplo,
un emulador de PDC local no intenta consultar los números tres o seis porque un
controlador de dominio no intenta sincronizarse consigo mismo.

En la tabla siguiente se enumeran las consultas que hace un controlador de dominio

para buscar un origen de la hora y el orden en el que se hacen las consultas.

Consultas del controlador de dominio por orígenes de la hora

Número Controlador Ubicación Confiabilidad del origen de la hora

de de dominio
consulta

1 Controlador En el sitio Prefiere un origen de la hora de confianza, pero puede

de dominio sincronizarse con un origen de hora la que no sea de
primario confianza si es lo único que está disponible.

2 Controlador En el sitio Solo se sincroniza con un origen de la hora de confianza.

de dominio
local

3 Emulador de En el sitio No corresponde.

PDC local Un controlador de dominio no intenta sincronizarse
consigo mismo.

4 Controlador Fuera del Prefiere un origen de la hora de confianza, pero puede

de dominio sitio sincronizarse con un origen de hora la que no sea de
primario confianza si es lo único que está disponible.

5 Controlador Fuera del Solo se sincroniza con un origen de la hora de confianza.

de dominio sitio
local

6 Emulador de Fuera del No corresponde.

PDC local sitio Un controlador de dominio no intenta sincronizarse
consigo mismo.

Note
 Un equipo nunca se sincroniza consigo mismo. Si el equipo que intenta la
sincronización es el emulador de PDC local, no intenta las consultas 3 ni 6.

Cada consulta devuelve una lista de controladores de dominio que se pueden usar
como origen de la hora. Hora de Windows asigna a cada controlador de dominio que
recibe consultas una puntuación en función de la confiabilidad y la ubicación del
controlador de dominio. En la tabla siguiente se enumeran las puntuaciones asignadas
por Hora de Windows a cada tipo de controlador de dominio.

Determinación de la puntuación

Estado del controlador de dominio Puntuación

Controlador de dominio ubicado en el mismo sitio 8

Controlador de dominio marcado como origen de la hora de confianza 4

Controlador de dominio ubicado en el dominio primario 2

Controlador de dominio que es un emulador de PDC 1

Cuando el servicio de hora de Windows determina que ha identificado el controlador de

dominio con la mejor puntuación posible, no se hacen más consultas. Las puntuaciones
que asigna el servicio de hora son acumulativas; es decir, un emulador de PDC ubicado
en el mismo sitio recibe una puntuación de nueve.

Si la raíz del servicio de hora no está configurada para sincronizarse con un origen
externo, el reloj de hardware interno del equipo rige la hora.

Sincronización especificada manualmente

La sincronización especificada manualmente te permite designar un único homólogo o
una lista de homólogos de los que un equipo obtiene la hora. Si el equipo no es
miembro de un dominio, debe configurarse manualmente para que se sincronice con un
origen de la hora especificado. Un equipo que es miembro de un dominio está
configurado de manera predeterminada para sincronizarse a partir de la jerarquía de
dominios, la sincronización especificada manualmente es el método más útil para la raíz
del bosque del dominio o para los equipos que no están unidos a un dominio. La
especificación manual de un servidor NTP externo para sincronizar con el equipo
autoritativo del dominio proporciona una hora confiable. Sin embargo, la configuración
del equipo autoritativo para que tu dominio se sincronice con un reloj de hardware en
verdad es una mejor solución para proporcionar la hora más precisa y segura para tu
dominio.
Los orígenes de la hora especificados manualmente no se autentican a menos que se les
indique un proveedor de hora específico y, por tanto, son vulnerables a los atacantes.
Además, si un equipo se sincroniza con un origen especificado manualmente en lugar
de hacerlo con su controlador de dominio de autenticación, es posible que los dos
equipos no estén sincronizados, lo que provocaría un error en la autenticación de
Kerberos. Esto podría provocar errores en otras acciones que requieran la autenticación
de la red, como la impresión o el uso compartido de archivos. Si solo la raíz del bosque
está configurada para sincronizarse con un origen externo, todos los demás equipos del
bosque permanecen sincronizados entre sí, lo que dificulta los ataques de reinyección.

Todos los mecanismos de sincronización disponibles

La opción "todos los mecanismos de sincronización disponibles" es el método de
sincronización más valioso para los usuarios de una red. Este método permite la
sincronización con la jerarquía de dominios y también puede proporcionar un origen de
la hora alternativo si la jerarquía de dominios deja de estar disponible, según la
configuración. Si el cliente no puede sincronizar la hora con la jerarquía de dominios, el
origen de la hora recurre automáticamente al origen de la hora especificado por la
configuración de NtpServer. Es más probable que este método de sincronización
proporcione una hora precisa a los clientes.

Detención de la sincronización de la hora

Existen ciertas situaciones en las que querrás que un equipo deje de sincronizar la hora.
Por ejemplo, si un equipo intenta sincronizarse desde un origen de la hora en Internet o
desde otro sitio a través de una WAN por medio de una conexión de acceso telefónico,
puede suponer costosos cargos telefónicos. Cuando deshabilitas la sincronización en
ese equipo, se impides que el equipo intente acceder a un origen de la hora a través de
una conexión de acceso telefónico.

También puedes deshabilitar la sincronización para evitar la generación de errores en el

Registro de eventos. Cada vez que un equipo intenta sincronizarse con un origen de la
hora que no está disponible, genera un error en el Registro de eventos. Si un origen de
la hora se desconecta de la red para un mantenimiento programado y no tienes
intención de reconfigurar el cliente para que se sincronice a partir de otro origen,
puedes deshabilitar la sincronización en el cliente para evitar que intente la
sincronización mientras el servidor de hora no esté disponible.

Resulta útil deshabilitar la sincronización en el equipo designado como raíz de la red de

sincronización. Esto indica que el equipo raíz confía en su reloj local. Si la raíz de la
jerarquía de sincronización no está establecida en NoSync y, si no se puede sincronizar
con otro origen de la hora, los clientes no aceptan el paquete que envía este equipo
porque no es de confianza.

Los únicos servidores de hora en los que los clientes confían incluso si no se han
sincronizado con otro origen de la hora son los identificados por el cliente como
servidores de hora de confianza.

Deshabilitación del servicio de hora de Windows

El servicio de hora de Windows (W32Time) se puede deshabilitar por completo. Si
decides implementar un producto de sincronización de hora de un tercero que use NTP,
tienes que deshabilitar el servicio de hora de Windows. Esto se debe a que todos los
servidores NTP necesitan acceso al puerto 123 del Protocolo de datagramas de
usuario (UDP) y, siempre y cuando el servicio de hora de Windows se esté ejecutando en
el sistema operativo Windows Server 2003, el puerto 123 permanece reservado por Hora
de Windows.

Puertos de red usados por el servicio de hora

de Windows
El servicio de hora de Windows se comunica en una red para identificar los orígenes de
la hora de confianza, para obtener información de hora y proporcionar información de
hora a otros equipos. Establece esta comunicación tal y como se define en las RFC de
NTP y SNTP.

Asignaciones de puertos para el servicio de hora de Windows

Nombre de servicio UDP TCP

NTP 123 N/A

SNTP 123 N/A

Consulte también
Referencia técnica del servicio de hora de Windows Herramientas y configuración del
servicio de hora de Windows (W32Time)
Configuración y herramientas del
servicio de hora de Windows
Artículo • 21/12/2022 • Tiempo de lectura: 35 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012, Windows 10, Azure Stack HCI,
versiones 21H2 y 20H2

El servicio de hora de Windows (W32Time) sincroniza la fecha y la hora de todos los

equipos administrados por Active Directory Domain Services (AD DS). En este artículo se
tratan las distintas herramientas y configuraciones que se usan para administrar el
servicio de hora de Windows.

De manera predeterminada, un equipo que está unido a un dominio sincroniza la hora a

través de una jerarquía de dominios de orígenes de la hora. Sin embargo, si un equipo
se ha configurado manualmente para sincronizarse desde un origen de la hora
específico, quizás porque anteriormente no estaba unido a un dominio, puede volver a
configurar el equipo para que empiece a obtener la hora automáticamente desde la
jerarquía de dominios.

La mayoría de los equipos unidos a un dominio tienen un tipo de cliente de hora de

NT5DS, lo que significa que sincronizan la hora desde la jerarquía de dominios. Una
excepción a esto es el controlador de dominio, que funciona como maestro de
operaciones del emulador del controlador de dominio principal (PDC) del dominio raíz
del bosque. A su vez, el maestro de operaciones del emulador de PDC está configurado
para sincronizar la hora con un origen de hora externo.

Puede lograr una precisión de hasta un milisegundo en el dominio. Para obtener más
información, consulte Límite de compatibilidad de la hora de alta precisión y Hora
precisa para Windows Server 2016.

Ｕ Precaución

No use el comando Tiempo neto para configurar ni establecer la hora del reloj de
un equipo mientras se ejecuta el servicio de hora de Windows.

Además, en los equipos antiguos que ejecutan Windows XP o versiones anteriores,

el comando /querysntp de Tiempo neto muestra el nombre de un servidor de
Protocolo de tiempo de redes (NTP) con el que un equipo está configurado para
sincronizarse, pero ese servidor NTP solo se usa cuando el cliente de hora del
 equipo está configurado como NTP o AllSync. Este comando ha quedado en
desuso.

Puerto de red
El servicio de hora de Windows sigue la especificación del protocolo de hora de redes
(NTP), que requiere el uso del puerto UDP 123 para todas las sincronizaciones de hora.
Cada vez que el equipo sincroniza el reloj o proporciona la hora a otro equipo, tiene
lugar en el puerto UDP 123. Este puerto está reservado exclusivamente para el servicio
de hora de Windows.

７ Nota

Si tiene un equipo con varios adaptadores de red (también denominado

equipo de hosts múltiples), no puede habilitar el servicio de hora de Windows
en función del adaptador de red.
El cliente NTP de hora de Windows usa el puerto UDP 123 para las solicitudes
de sincronización de origen y destino. Al usar el filtrado de red, tenga en
cuenta el puerto de origen que se usa.

Uso de [Link]
Puede usar la herramienta de línea de comandos [Link] para configurar el servicio
de hora de Windows y diagnosticar los problemas de hora del equipo. [Link] es la
herramienta de línea de comandos preferida para configurar, supervisar y solucionar
problemas del servicio de hora de Windows. [Link] se incluye con Windows XP y
versiones posteriores, y con Windows Server 2003 y versiones posteriores.

Se requiere la pertenencia al Grupo Administradores local para ejecutar [Link]

localmente, mientras que se necesita la pertenencia al Grupo Admins. del dominio para
ejecutar [Link] de forma remota.

Ejecución de [Link]
1. En la barra de búsqueda de Windows, escriba cmd.
2. Haga clic con el botón derecho en Símbolo del sistema y, a continuación,
seleccione Ejecutar como administrador.
 3. En el símbolo del sistema, escriba w32tm seguido del parámetro correspondiente,
como se describe a continuación:

Parámetro Descripción

/? Muestra la ayuda de la línea de comandos de W32tm.

/register Registra el servicio de hora de Windows para que se ejecute

como servicio y agrega la información de configuración
predeterminada al Registro.

/unregister Anula el registro del servicio de hora de Windows y quita toda

su información de configuración del Registro.

/monitor [/domain:<domain Supervisa el servicio de hora de Windows.

name>] [/computers:<name>[, /domain: especifica el dominio que se va a supervisar. Si no se
<name>[,<name>...]] [/threads: proporciona ningún nombre de dominio o no se especifican las
<num>] opciones /domain ni /computers, se usa el dominio
predeterminado. Esta opción se puede usar más de una vez.

/computers: supervisa la lista de equipos especificada. Los

nombres de los equipos se separan con comas, no con
espacios. Si un nombre tiene el prefijo * , se trata como un
PDC. Esta opción se puede usar más de una vez.

/threads: especifica el número de equipos que se van a analizar

simultáneamente. El valor predeterminado es 3. El intervalo
permitido es de 1 a 50.

/ntte<Época de la hora NT> Convierte una hora del sistema Windows NT (medida en
intervalos de 10-7 segundos desde 0h 1 ene 1601) en un
formato legible.

/ntpte<Época de la hora NTP> Convierte una hora NTP (medida en intervalos de 2-32
segundos desde 0h 1 ene 1900) en un formato legible.
Parámetro Descripción

/resync [/computer: Indica a un equipo que debe volver a sincronizar el reloj lo

<computer>] [/nowait] antes posible y genera todas las estadísticas de error
[/discover] [/soft] acumuladas.
/computer:<equipo> : especifica el equipo que debe volver a
sincronizarse. Si no se especifica, se volverá a sincronizar el
equipo local.

/nowait: no espera a que se produzca la resincronización;

vuelve inmediatamente. De lo contrario, espere a que la
resincronización se complete antes de volver.

/rediscover: vuelve a detectar la configuración de red y los

orígenes de red; a continuación, resincroniza.

/soft: vuelve a realizar la sincronización con las estadísticas de

error existentes. Se usa con fines de compatibilidad.
Parámetro Descripción

/stripchart /computer:target> Muestra un gráfico de bandas del desplazamiento entre este

[/period:<<refresh>] equipo y otro.
[/dataonly] [/samples:<count>] /computer:<destino> : el equipo donde se medirá el
[/rdtsc] desplazamiento.

/period:<actualización> : Tiempo transcurrido entre muestras,

en segundos. El valor predeterminado es de 2 segundos.

/dataonly: solo muestra los datos, sin gráficos.

/samples:<count>: recopila muestras <de recuento> y, a

continuación, se detiene. Si no se especifica, las muestras se
recopilarán hasta que se presione Ctrl + C.

/rdtsc: para cada muestra, esta opción imprime valores

separados por comas, junto con los encabezados RdtscStart,
RdtscEnd, FileTime, RoundtripDelay y NtpOffset, en lugar del
gráfico de texto.

RdtscStart: valor RDTSC (contador de marca de hora de

lectura) recopilado justo antes de generar la solicitud
NTP.
RdtscEnd: valor de RDTSC recopilado justo después de la
recepción y el procesamiento de la respuesta NTP.
FileTime: valor de FILETIME local usado en la solicitud
NTP.
RoundtripDelay: tiempo transcurrido en segundos entre
la generación de la solicitud NTP y el procesamiento de
la respuesta NTP recibida, obtenido de los cálculos del
recorrido de ida y vuelta NTP.
NTPOffset: desfase de hora en segundos entre el equipo
local y el servidor NTP, obtenido de los cálculos de
desfase NTP.
Parámetro Descripción

/config [/computer:<target>] /computer:<target>: ajusta la configuración del <destino>. Si

[/update] [/manualpeerlist: no se especifica, el valor predeterminado es el equipo local.
<peers>] [/syncfromflags:
<source>] /update: notifica al servicio de hora de Windows que la
[/LocalClockDispersion: configuración ha cambiado y hace que los cambios surtan
<seconds>] [/reliable:(YES|NO)] efecto.
[/largephaseoffset:
/manualpeerlist:<peers>: establece la lista < de pares manual
<milliseconds>]**
en pares>, que es una lista delimitada por espacios de
direcciones DNS o IP. Al especificar varios elementos del
mismo nivel, esta opción debe ir entre comillas.

/syncfromflags:<origen> : establece los orígenes desde los

cuales debe sincronizarse el cliente NTP. <Fuente> debe ser
una lista separada por comas de estas palabras clave (no
distingue mayúsculas de minúsculas):

MANUAL: incluye elementos del mismo nivel de la lista

manual de elementos del mismo nivel.
DOMHIER: realiza la sincronización desde un controlador
de dominio (DC) en la jerarquía de dominios.

/LocalClockDispersion:<segundos> : configura la precisión del

reloj interno que W32Time adoptará cuando no pueda adquirir
la hora de sus orígenes configurados.

/reliable:(YES|NO): establezca si este equipo es un origen de

hora confiable. Esta configuración solo tiene sentido en
controladores de dominio.

YES: este equipo es un servicio de hora de confianza.

NO: este equipo no es un servicio de hora de confianza.

/largephaseoffset:<milisegundos>: establece la diferencia de

tiempo entre la hora local y la de red que W32Time
considerará un pico.

/tz Muestra la configuración actual de zona horaria.

/dumpreg [/subclave:<key>] Muestra los valores asociados a una clave del Registro
[/computer:<target>] determinada.
La clave predeterminada es
HKLM\System\CurrentControlSet\Services\W32Time (clave
raíz para el servicio de hora de Windows).

/subkey:<key>: muestra los valores asociados a la clave> de

subclave <de la clave predeterminada.

/computer:<destino> : consulta la configuración del Registro

para el equipo <destino>.
Parámetro Descripción

/query [/computer:<target>] Muestra la información del servicio de hora de Windows del

{/source | /configuration | equipo. Este parámetro primero estaba disponible para el
/peers | /status} [/verbose] cliente de hora de Windows de Windows Vista y
Windows Server 2008.
/computer:<target>: consulta la información de <destino>. Si
no se especifica, el valor predeterminado es el equipo local.

/source: muestra el origen de la hora.

/configuration: muestra la configuración del tiempo de

ejecución y la procedencia de la configuración. En el modo
detallado, se muestra también el valor sin definir o sin usar.

/peers: muestra una lista de elementos del mismo nivel y su

estado.

/status: muestra el estado del servicio de hora de Windows.

/verbose: establece el modo detallado para mostrar más

información.

/debug {/disable | {/enable /file: Habilita o deshabilita el registro privado del servicio de hora de
<Nombre> /size:/<bytes> Windows del equipo local. Este parámetro primero estaba
/entries:<value> [/truncate]}} disponible para el cliente de hora de Windows de
Windows Vista y Windows Server 2008.
/disable: deshabilita el registro privado.

/enable: habilita el registro privado.

file:<nombre> : especifica el nombre de archivo

absoluto.
size:<bytes> : especifica el tamaño máximo del registro
circular.
entries:<valor> : contiene una lista de marcas,
especificadas por número y separadas por comas, que
indican los tipos de información que se deben registrar.
Los valores válidos son de 0 a 300. Se admiten tanto un
intervalo de números como números individuales (por
ejemplo, 0-100,103,106). El valor 0-300 es para registrar
toda la información.

/truncate: trunca el archivo si existe.

Configuración del cliente para que use dos servidores de

hora
Para establecer un equipo cliente para que apunte a dos servidores horarios distintos,
uno denominado [Link] y otro [Link] , escriba el siguiente
comando en el símbolo del sistema y presiona ENTRAR:

cmd

w32tm /config /manualpeerlist:"[Link] [Link]"

/syncfromflags:manual /update

Configuración del cliente para que sincronice la hora

automáticamente desde un origen de dominio
Para configurar un equipo cliente que está sincronizando actualmente el tiempo
mediante un equipo especificado manualmente para sincronizar el tiempo
automáticamente desde la jerarquía de dominios de AD, ejecute lo siguiente:

cmd

w32tm /config /syncfromflags:domhier /update

net stop w32time

net start w32time

Comprobación de la configuración de la hora del cliente

Para comprobar la configuración del cliente desde un equipo cliente basado en
Windows que tiene el nombre de host contosoW1 , ejecuta el siguiente comando:

cmd

W32tm /query /computer:contosoW1 /configuration

La salida de este comando muestra una lista de parámetros de configuración de

W32time establecidos para el cliente.

） Importante

Windows Server 2016 ha mejorado los algoritmos de sincronización de hora para

cumplir con las especificaciones RFC. Por lo tanto, si quiere establecer el cliente de
hora local para que apunte a varios elementos del mismo nivel, se recomienda
preparar tres o más servidores de hora distintos.
 Si solo tiene dos servidores de tiempo, debe especificar la marca
Ntpserver UseAsFallbackOnly (0x2) para anular la prioridad de uno de ellos. Por
ejemplo, si desea priorizar [Link] sobre [Link] , ejecute
el siguiente comando:

cmd

w32tm /config /manualpeerlist:"[Link],0x8

[Link],0x2" /syncfromflags:manual /update

Además, puede ejecutar el siguiente comando y leer el valor de NtpServer en la salida:

cmd

reg query HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

Configuración del restablecimiento del reloj del equipo

Para que [Link] restablezca un reloj del equipo, primero comprueba el desfase
( CurrentTimeOffset , también conocido como Phase Offset ) entre la hora actual y la
hora del reloj del equipo para determinar si el desfase es menor que el valor
MaxAllowedPhaseOffset .

CurrentTimeOffset MaxAllowedPhaseOffset ≤ : ajuste el reloj del equipo

gradualmente mediante la velocidad del reloj.

CurrentTimeOffset > MaxAllowedPhaseOffset : establezca el reloj del equipo
inmediatamente.

Luego, para ajustar el reloj del equipo mediante la frecuencia del reloj, [Link]
calcula un valor de PhaseCorrection . Este algoritmo varía en función de la versión de
Windows:

Windows Server 2016 y versiones posteriores:

PhaseCorrection_raw = | CurrentTimeOffset | ÷ (16 × PhaseCorrectRate ×

pollIntervalInSeconds )
MaximumCorrection = | CurrentTimeOffset | ÷ ( UpdateInterval ÷ 100)

PhaseCorrection = min( PhaseCorrection_raw , MaximumCorrection )

Windows Server 2012 R2 y versiones anteriores:

Para obtener el SystemClockRate valor, puede usar el siguiente comando y convertirlo
de segundos a tics de reloj mediante la fórmula de (segundos × 1000 × 10 000):

PhaseCorrection = | CurrentTimeOffset | ÷ ( PhaseCorrectRate × UpdateInterval )

Todas las versiones de Windows usan la misma ecuación final para comprobar
PhaseCorrection :

PhaseCorrection SystemClockRate ≤ ÷ 2

７ Nota

Windows Server 2019 y Windows 10 1809 tienen la misma fórmula que

[Windows Server 2016 y versiones posteriores] descritas anteriormente
aplicando actualizaciones acumulativas de KB5006744 en adelante.

Estas ecuaciones usan PhaseCorrectRate , UpdateInterval ,

MaxAllowedPhaseOffset y SystemClockRate medidos en unidades de tics del

reloj. En sistemas Windows, 1 ms = 10 000 tics del reloj.

MaxAllowedPhaseOffset se puede configurar en el Registro. Sin embargo, el

parámetro del Registro se mide en segundos, en lugar de tics del reloj.

Para ver los valores SystemClockRate y pollIntervalInSeconds (medidos en

segundos), abra una ventana del símbolo del sistema y ejecute W32tm /query
/status /verbose . Este comando genera una salida similar a la siguiente.
 La salida presenta el intervalo de sondeo tanto en tics del reloj como en
segundos. Las ecuaciones usan el valor medido en segundos (el valor entre
paréntesis).
La salida presenta la frecuencia del reloj en segundos. Para ver el valor de
SystemClockRate en tics del reloj, use la fórmula siguiente:

( value in seconds ) × 1000 × 10 000

Por ejemplo, si SystemClockRate es 0,0156250 segundos, el valor que usa la

ecuación es de 156 250 tics del reloj. Para obtener descripciones completas de
los parámetros configurables y sus valores predeterminados, consulte
Entradas de configuración más adelante en este artículo.

En los siguientes ejemplos se muestra cómo aplicar estos cálculos para Windows Server
2012 R2 y versiones anteriores.

Ejemplo: Frecuencia del reloj del sistema desfasada en cuatro

minutos
La hora del reloj del equipo es 11:05 y la hora actual real es 11:09:

PhaseCorrectRate = 1

UpdateInterval = 30 000 tics del reloj

SystemClockRate = 156 000 tics del reloj

MaxAllowedPhaseOffset = 10 min = 600 segundos = 600 × 1000 × 10 000 = 6 000

000 000 tics de reloj

| CurrentTimeOffset | = 4 min = 4 × 60 × 1000 × 10 000 = 2 400 000 000 tics de reloj

¿Es CurrentTimeOffset ≤ MaxAllowedPhaseOffset ?

[Link] ≤ [Link]: TRUE

¿Y cumple con la ecuación siguiente?

(| CurrentTimeOffset | ÷ ( PhaseCorrectRate × UpdateInterval ) ≤ SystemClockRate ÷

2)
Es de 2400 000 000 / (30 000 × 1) ≤ 156 000 ÷ 2

80 000 ≤ 78 000: FALSE

Por lo tanto, [Link] retrasaría el reloj inmediatamente.

７ Nota

En este caso, si quiere retrasar el reloj lentamente, también tendrá que ajustar los
valores de PhaseCorrectRate o UpdateInterval en el Registro para asegurarse de
que el resultado de la ecuación sea TRUE.

Ejemplo: Frecuencia del reloj del sistema desfasada en tres minutos

La hora del reloj del equipo es 11:05 y la hora actual real es 11:08:

PhaseCorrectRate = 1

UpdateInterval = 30 000 tics del reloj

SystemClockRate = 156 000 tics del reloj

MaxAllowedPhaseOffset = 10 min = 600 segundos = 600 × 1000 × 10 000 = 6 000

000 000 tics de reloj

| CurrentTimeOffset | = 3 minutos = 3 × 60 × 1000 × 10 000 = 1 800 000 000 tics de

reloj

¿Es CurrentTimeOffset ≤ MaxAllowedPhaseOffset ?

[Link] ≤ [Link]: TRUE

¿Y cumple con la ecuación siguiente?

(| CurrentTimeOffset | ÷ ( PhaseCorrectRate × UpdateInterval ) ≤ SystemClockRate ÷

2)

(1800 000 000) ÷ (1 × 30 000) ≤ 156 000 ÷ 2

Es 60 000 ≤ 78 000: TRUE

En este caso, el reloj se retrasará lentamente.

Uso del Editor de directivas de grupo local

El servicio de hora de Windows almacena varias propiedades de configuración como
entradas del Registro. Puede usar objetos directiva de grupo (GPO) en el Editor de
directivas de grupo local para configurar la mayor parte de esta información. Por
ejemplo, puedes usar GPO para configurar un equipo para que sea NTPServer o
NTPClient, configurar el mecanismo de sincronización de la hora y configurar un equipo
para que sea un origen de hora confiable.

７ Nota

La configuración de la directiva de grupo del servicio de hora de Windows se

puede aplicar a los controladores de dominio de Windows Server 2003,
Windows Server 2003 R2, Windows Server 2008 y Windows Server 2008 R2, y se
puede aplicar a equipos que ejecutan Windows Server 2003, Windows Server
2003 R2, Windows Server 2008 y Windows Server 2008 R2.

Windows almacena la información de las directivas del servicio de hora de Windows en

el Editor de directivas de grupo local en Computer Configuration\Administrative
Templates\System\Windows Time Service . Almacena la información de configuración que

las directivas definen en el Registro de Windows, y luego usa esas entradas del Registro
para configurar las entradas del Registro específicas del servicio de hora de Windows.
Como resultado, los valores definidos por directiva de grupo sobrescriben cualquier
valor existente previamente en la sección del servicio de hora de Windows del Registro.
Algunas de las configuraciones de GPO preestablecidas difieren de las entradas del
Registro predeterminadas correspondientes del servicio de hora de Windows.

Por ejemplo, supongamos que editas la configuración de directiva en la directiva

Proveedores de hora\Configurar el cliente NTP de Windows. Windows carga esta
configuración en el área de directivas del Registro en la siguiente subclave:

HKLM\Software\Policies\Microsoft\W32time\TimeProviders\NtpClient

A continuación, Windows usa la configuración de directiva para configurar las entradas

del Registro del servicio de hora de Windows relacionadas en la siguiente subclave:

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NTPClient\
En la tabla siguiente se enumeran las directivas que se pueden configurar para el
servicio de hora de Windows y las subclaves del Registro a las que afectan esas
directivas.

７ Nota

Cuando se quita una configuración de directiva de grupo, Windows quita la

entrada correspondiente del área de directivas del Registro.

Directiva de grupo1 Ubicaciones del Registro2,3

Parámetros de configuración global W32Time

W32Time\Config
W32Time\Parameters

Proveedores de hora\Configurar el cliente NTP de Windows W32Time\TimeProviders\NtpClient

Proveedores de hora\Habilitar el cliente NTP de Windows W32Time\TimeProviders\NtpClient

Proveedores de hora\Habilitar el servidor NTP de Windows W32Time\TimeProviders\NtpServer

1
Category path: Computer Configuration\Administrative Templates\System\Windows Time
Service
2 Subclave: HKLM\SOFTWARE\Policies\Microsoft
3 Subclave: HKLM\SYSTEM\CurrentControlSet\Services

Referencia del Registro de Windows

２ Advertencia

Esta información se proporciona como referencia para su uso en la solución de

problemas y la validación. W32Time usa las claves del Registro de Windows para
almacenar información crítica. No cambie estos valores. El Editor del Registro o
Windows no validan las modificaciones del Registro antes de que se apliquen. Si el
Registro contiene valores no válidos, es posible que Windows experimente errores
irrecuperables.

El servicio de hora de Windows almacena información en el Registro en la ruta de

acceso HKLM\SYSTEM\CurrentControlSet\Services\W32Time, en las subclaves
siguientes:

\Config
 \Parameters
\TimeProviders\NtpClient
\TimeProviders\NtpServer

En las tablas siguientes, "Todas las versiones" hace referencia a Windows 7, Windows 8,
Windows 10, Windows Server 2008 y Windows Server 2008 R2, Windows Server 2012 y
Windows Server 2012 R2, Windows Server 2016 y Windows Server 2019.

７ Nota

Algunos de los parámetros del Registro se miden en ciclos de reloj y otros en

segundos. Para convertir la hora de ciclos de reloj a segundos, usa estos factores de
conversión:

1 minuto = 60 s
1 s = 1000 ms
1 ms = 10 000 tics del reloj en un sistema Windows, tal como se describe en
Propiedad [Link].

Por ejemplo, 5 minutos se convierte en 5 × 60 × 1000 × 10000 = 3000 000 000 tics
de reloj.

Entradas de configuración
Las entradas de la subclave Config se encuentran en
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config .

Entrada del Registro Versiones Descripción

Entrada del Registro Versiones Descripción

AnnounceFlags Todas las Controla si este equipo está marcado como un

versiones servidor de hora de confianza. Un equipo no
está marcado como confiable a menos que
también esté marcado como servidor horario.
0x00. No es un servidor horario.
0x01. Siempre es un servidor horario.
0x02. Servidor horario automático.
0x04. Siempre es un servidor horario de
confianza.
0x08. Servidor horario de confianza
automático.

El valor predeterminado para los miembros del

dominio es 10. El valor predeterminado para
los servidores y clientes independientes es 10.

ChainDisable Controla si el mecanismo de encadenamiento

está deshabilitado o no. Si el encadenamiento
está deshabilitado (establecido en 0), un
controlador de dominio de solo lectura
(RODC) se puede sincronizar con cualquier
controlador de dominio, pero los hosts que no
tengan su contraseña almacenada en caché en
RODC no podrán sincronizarse con RODC. Se
trata de un valor booleano y cuyo valor
predeterminado es 0.

ChainEntryTimeout Especifica la cantidad máxima de tiempo que

una entrada puede permanecer en la tabla de
encadenamiento antes de que se considere
que la entrada ha expirado. Las entradas
expiradas pueden quitarse cuando se procesa
la siguiente solicitud o respuesta. El valor
predeterminado es 16 (segundos).

ChainLoggingRate Controla la frecuencia con la que un evento

que indica el número de intentos de
encadenamiento correctos e incorrectos se
registra en el Registro del sistema en el Visor
de eventos. El valor predeterminado es 30
(minutos).
Entrada del Registro Versiones Descripción

ChainMaxEntries Controla el número máximo de entradas

permitidas en la tabla de encadenamiento. Si
la tabla de encadenamiento está llena y no se
puede quitar ninguna entrada expirada, se
descartan las solicitudes entrantes. El valor
predeterminado es 128 (entradas).

ChainMaxHostEntries Controla el número máximo de entradas que

se permiten en la tabla de encadenamiento de
un host determinado. El valor predeterminado
es 4 (entradas).

ClockAdjustmentAuditLimit Windows Especifica los ajustes del reloj local más

Server 2016 pequeños que se pueden registrar en el
versión registro de eventos del servicio W32time en el
1709 y equipo de destino. El valor predeterminado es
versiones 800 (partes por millón de PPM).
posteriores;
Windows
10 versión
1709 y
versiones
posteriores

ClockHoldoverPeriod Windows Indica el número máximo de segundos

Server 2016 durante los que un reloj del sistema puede
versión mantener nominalmente su precisión sin
1709 y sincronizarse con un origen de hora. Si este
versiones período de tiempo pasa sin que W32time
posteriores; obtenga nuevas muestras de ninguno de sus
Windows proveedores de entrada, W32time inicia una
10 versión nueva detección de orígenes de hora. Default:
1709 y 7 800 segundos.
versiones
posteriores

EventLogFlags Todas las Controla los eventos que registra el servicio de

versiones hora.
0x1. Salto de hora
0x2. Cambio de origen

El valor predeterminado en los miembros del

dominio es 2. El valor predeterminado en los
servidores y clientes independientes es 2.
Entrada del Registro Versiones Descripción

FrequencyCorrectRate Todas las Controla la velocidad a la que se corrige el

versiones reloj. Si este valor es demasiado pequeño, el
reloj es inestable y se sobrecorrige. Si el valor
es demasiado grande, el reloj tarda mucho
tiempo en sincronizarse. El valor
predeterminado en los miembros del dominio
es 4. El valor predeterminado en los servidores
y clientes independientes es 4.

Note
Cero no es un valor válido para la entrada del
Registro FrequencyCorrectRate. En equipos
con Windows Server 2003, Windows Server
2003 R2, Windows Server 2008 y Windows
Server 2008 R2, si el valor se establece en 0, el
servicio de hora de Windows lo cambia
automáticamente a 1.

HoldPeriod Todas las Controla el período de tiempo durante el que

versiones se deshabilita la detección de picos para que
el reloj local se sincronice rápidamente. Un
pico es una muestra de tiempo que indica que
el tiempo está fuera de un número de
segundos y se recibe después de que se hayan
devuelto muestras de buen tiempo de forma
coherente. El valor predeterminado en los
miembros del dominio es 5. El valor
predeterminado en los servidores y clientes
independientes es 5.

LargePhaseOffset Todas las Especifica que un desfase de hora mayor o

versiones igual que este valor en 10-7 segundos se
considera un pico. Una interrupción de la red,
como una gran cantidad de tráfico, puede
provocar un pico. Un pido se omitirá a menos
que se mantenga durante un largo período de
tiempo. El valor predeterminado en los
miembros del dominio es 50000000. El valor
predeterminado en los servidores y clientes
independientes es 50000000.
Entrada del Registro Versiones Descripción

LastClockRate Todas las W32Time la mantiene. Contiene datos

versiones reservados que se usan en el sistema
operativo Windows y los cambios que se
realicen en esta configuración pueden
producir resultados imprevisibles. El valor
predeterminado en los miembros del dominio
es 156250. El valor predeterminado en los
servidores y clientes independientes es
156250.

LocalClockDispersion Todas las Controla la dispersión (en segundos) que

versiones debes asumir cuando el único origen de hora
es el reloj CMOS integrado. El valor
predeterminado en los miembros del dominio
es 10. El valor predeterminado en los
servidores y clientes independientes es 10.

MaxAllowedPhaseOffset Todas las Especifica el desfase máximo (en segundos)

versiones que W32Time intenta ajustar el reloj del
equipo con la velocidad del reloj. Si el desfase
supera esta velocidad, W32Time establece el
reloj del equipo directamente. El valor
predeterminado para los miembros del
dominio es 300. El valor predeterminado para
los servidores y clientes independientes es 1.

MaxClockRate Todas las W32Time la mantiene. Contiene datos

versiones reservados que se usan en el sistema
operativo Windows y los cambios que se
realicen en esta configuración pueden
producir resultados imprevisibles. El valor
predeterminado para los miembros del
dominio es 155860. El valor predeterminado
para los servidores y clientes independientes
es 155860.
Entrada del Registro Versiones Descripción

MaxNegPhaseCorrection Todas las Especifica la corrección de tiempo negativa

versiones más grande, en segundos, que realiza el
servicio. Si el servicio determina que se
necesita un cambio mayor que este, registra
un evento en su lugar.
Note
El valor 0xFFFFFFFF es un caso especial. Este
valor significa que el servicio siempre corrige
la hora.

El valor predeterminado para los miembros del

dominio es 0xFFFFFFFF (hexadecimal). El valor
predeterminado para los controladores de
dominio es 172 800 (48 horas). El valor
predeterminado de los servidores y clientes
independientes es 54 000 (15 horas).

MaxPollInterval Todas las Especifica el intervalo más grande, en log2

versiones segundos, permitidos para el intervalo de
sondeo del sistema. Un sistema debe sondear
según el intervalo programado, un proveedor
puede rechazar la producción de muestras
cuando se le solicite hacerlo. El valor
predeterminado para los controladores de
dominio es 10. El valor predeterminado para
los miembros del dominio es 15. El valor
predeterminado para los servidores y clientes
independientes es 15.

MaxPosPhaseCorrection Todas las Especifica la corrección de tiempo positiva más

versiones grande en segundos que realiza el servicio. Si
el servicio determina que se necesita un
cambio mayor que este, registra un evento en
su lugar.
Note
El valor 0xFFFFFFFF es un caso especial. Este
valor significa que el servicio siempre corrige
la hora.

El valor predeterminado para los miembros del

dominio es 0xFFFFFFFF (hexadecimal). El valor
predeterminado para los controladores de
dominio es 172 800 (48 horas). El valor
predeterminado de los servidores y clientes
independientes es 54 000 (15 horas).
Entrada del Registro Versiones Descripción

MinClockRate Todas las W32Time la mantiene. Contiene datos

versiones reservados que se usan en el sistema
operativo Windows y los cambios que se
realicen en esta configuración pueden
producir resultados imprevisibles. El valor
predeterminado para los miembros del
dominio es 155860. El valor predeterminado
para los servidores y clientes independientes
es 155860.

MinPollInterval Todas las Especifica el intervalo más pequeño, en base

versiones logarítmica, 2 segundos, permitido para el
intervalo de sondeo del sistema. Un sistema
no solicita muestras con más frecuencia que
esta, un proveedor puede producir muestras
en ocasiones distintas del intervalo
programado. El valor predeterminado para los
controladores de dominio es 6. El valor
predeterminado para los miembros del
dominio es 10. El valor predeterminado para
los servidores y clientes independientes es 10.

PhaseCorrectRate Todas las Controla la velocidad a la que se corrige el

versiones error de fase. Si se especifica un valor
pequeño, se corrige el error de fase
rápidamente, pero es posible que el reloj se
vuelva inestable. Si el valor es demasiado
grande, se tarda más tiempo en corregir el
error de fase.
El valor predeterminado en los miembros del
dominio es 1. El valor predeterminado en los
servidores y clientes independientes es 7.

Note
Cero no es un valor válido para la entrada del
Registro PhaseCorrectRate. En equipos con
Windows Server 2003, Windows Server 2003
R2, Windows Server 2008 y Windows Server
2008 R2, si el valor está establecido en 0, el
servicio de hora de Windows lo cambia
automáticamente a 1.
Entrada del Registro Versiones Descripción

PollAdjustFactor Todas las Controla la decisión de aumentar o disminuir

versiones el intervalo de sondeo del sistema. Cuanto
mayor sea el valor, menor será la cantidad de
error que causará una reducción del intervalo
de sondeo. El valor predeterminado en los
miembros del dominio es 5. El valor
predeterminado en los servidores y clientes
independientes es 5.

RequireSecureTimeSyncRequests Windows 8 Controla si el controlador de dominio

y versiones responderá o no a las solicitudes de
posteriores sincronización de la hora que usan protocolos
de autenticación más antiguos. Si se habilita
(se establece en 1), el controlador de dominio
no responderá a las solicitudes que usen
dichos protocolos. Se trata de un valor
booleano y cuyo valor predeterminado es 0.

SpikeWatchPeriod Todas las Especifica la cantidad de tiempo que un

versiones desfase sospechoso debe persistir antes de
que se acepte como correcto (en segundos). El
valor predeterminado en los miembros del
dominio es 900. El valor predeterminado en
los servidores y clientes independientes es
900.

TimeJumpAuditOffset Todas las Entero sin signo que indica el umbral de

versiones auditoría de salto de hora, en segundos. Si el
servicio de hora ajusta el reloj local mediante
el ajuste directo del reloj, y la corrección de
tiempo es mayor que este valor, el servicio de
hora registra un evento de auditoría.
 Entrada del Registro Versiones Descripción

UpdateInterval Todas las Especifica el número de ciclos de reloj entre

versiones los ajustes de corrección de fase. El valor
predeterminado para los controladores de
dominio es 100. El valor predeterminado para
los miembros del dominio es 30 000. El valor
predeterminado para los servidores y clientes
independientes es 360 000.

Note
Cero no es un valor válido para la entrada del
Registro UpdateInterval. En equipos que
ejecutan Windows Server 2003,
Windows Server 2003 R2, Windows Server
2008 y Windows Server 2008 R2, si el valor se
establece en 0, el servicio de hora de Windows
lo cambia automáticamente a 1.

UtilizeSslTimeData Versiones El valor de 1 indica que W32Time usa varias

de marcas de tiempo de SSL para inicializar un
Windows reloj que es extremadamente impreciso.
posteriores
a Windows
10
compilación
1511

Entradas de parámetros
Las entradas de la subclave Parameters se encuentran en
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters .

Entrada del Registro Versiones Descripción

AllowNonstandardModeCombinations Todas las Indica que se permiten combinaciones de

versiones modos no estándar en la sincronización
entre elementos del mismo nivel. El valor
predeterminado para los miembros del
dominio es 1. El valor predeterminado para
los servidores y clientes independientes es
1.
Entrada del Registro Versiones Descripción

NtpServer Todas las Especifica una lista delimitada por espacios

versiones de los elementos del mismo nivel de los
que un equipo obtiene las marcas de
tiempo, que consta de uno o varios
nombres DNS o direcciones IP por línea.
Cada nombre DNS o dirección IP de la lista
debe ser único. Los equipos conectados a
un dominio deben sincronizarse con un
origen de hora más confiable, como el
reloj oficial de la hora de los EE. UU.
0x1 SpecialInterval
0x2 UseAsFallbackOnly
0x4 SymmetricActive: para obtener
más información sobre este modo,
vea Windows Time Server .
cliente de 0x8

No hay ningún valor predeterminado para

esta entrada del Registro en los miembros
del dominio. El valor predeterminado en
los servidores y clientes independientes es
[Link],0x1 .

ServiceDll Todas las W32Time la mantiene. Contiene datos

versiones reservados que se usan en el sistema
operativo Windows y los cambios que se
realicen en esta configuración pueden
producir resultados imprevisibles. La
ubicación predeterminada de este archivo
DLL en los miembros del dominio y en los
servidores y clientes independientes es
%windir%\System32\[Link].

ServiceMain Todas las W32Time la mantiene. Contiene datos

versiones reservados que se usan en el sistema
operativo Windows y los cambios que se
realicen en esta configuración pueden
producir resultados imprevisibles. El valor
predeterminado en los miembros del
dominio es SvchostEntry_W32Time. El
valor predeterminado en los servidores y
clientes independientes es
SvchostEntry_W32Time.
 Entrada del Registro Versiones Descripción

Type Todas las Indica desde qué elementos del mismo

versiones nivel se aceptará la sincronización:
NoSync. El servicio de hora no se
sincroniza con otros orígenes.
NTP. El servicio de hora se sincroniza
desde los servidores especificados
en la entrada del Registro NtpServer
Entrada del Registro.
NT5DS. El servicio de hora se
sincroniza desde la jerarquía de
dominios.
AllSync. El servicio de hora usa
todos los mecanismos de
sincronización disponibles.

El valor predeterminado en los miembros

del dominio es NT5DS. El valor
predeterminado en los servidores y
clientes independientes es NTP.

Entradas de NtpClient
Las entradas de la subclave NtpClient se encuentran en
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient .

Entrada del Registro Version Descripción

AllowNonstandardModeCombinations Todas las Indica que se permiten combinaciones de

versiones modos no estándar en la sincronización
entre elementos del mismo nivel. El valor
predeterminado para los miembros del
dominio es 1. El valor predeterminado para
los servidores y clientes independientes es
1.
Entrada del Registro Version Descripción

CompatibilityFlags Todas las Especifica los valores y las marcas de

versiones compatibilidad siguientes:
0x00000001: DispersionInvalid
0x00000002:
IgnoreFutureRefTimeStamp
0x80000000: AutodetectWin2K
0x40000000:
AutodetectWin2KStage2

El valor predeterminado para los miembros

del dominio es 0x80000000. El valor
predeterminado para los servidores y
clientes independientes es 0x80000000.

CrossSiteSyncFlags Todas las Determina si el servicio elige asociados de

versiones sincronización fuera del dominio del
equipo. Las opciones y los valores son:
0: None
1: PdcOnly
2: All

Este valor se omite si no se establece el

valor de NT5DS. El valor predeterminado
para los miembros del dominio es 2. El
valor predeterminado para los servidores y
clientes independientes es 2.

DllName Todas las Especifica la ubicación del archivo DLL para

versiones el proveedor de hora.
La ubicación predeterminada de este
archivo DLL en los miembros del dominio y
en los servidores y clientes independientes
es %windir%\System32\[Link].

Habilitado Todas las Indica si el proveedor NtpClient está

versiones habilitado en el servicio de hora actual.
1: Sí
0: No

El valor predeterminado en los miembros

del dominio es 1. El valor predeterminado
en los servidores y clientes independientes
es 1.
Entrada del Registro Version Descripción

EventLogFlags Todas las Especifica los eventos registrados por el

versiones servicio de hora de Windows.
0x1: cambios de disponibilidad
0x2 : asimetría de ejemplo grande (se
aplica solo a Windows Server 2003,
Windows Server 2003 R2, Windows
Server 2008 y Windows Server 2008
R2)

El valor predeterminado en los miembros

del dominio es 0x1. El valor predeterminado
en los servidores y clientes independientes
es 0x1.

InputProvider Todas las Indica si se debe habilitar NtpClient como

versiones InputProvider, que obtiene la información
de hora de NtpServer. NtpServer es un
servidor de hora que responde a las
solicitudes de hora del cliente en la red,
para lo cual devuelve muestras de hora que
son útiles para sincronizar el reloj local.
1: Sí
0: No

El valor predeterminado para los miembros

del dominio y los clientes independientes
es 1.

LargeSampleSkew Todas las Especifica el sesgo de muestras grande del

versiones registro, en segundos. Para cumplir con las
especificaciones de la Comisión de Valores
y Bolsa de EE. UU. (SEC), debe establecerse
en tres segundos. Los eventos se
registrarán para esta opción solo cuando
EventLogFlags se configure explícitamente
para el sesgo de muestra grande de 0x2. El
valor predeterminado en los miembros del
dominio es 3. El valor predeterminado en
los servidores y clientes independientes es
3.
Entrada del Registro Version Descripción

ResolvePeerBackOffMaxTimes Todas las Especifica el número máximo de veces que

versiones se debe duplicar el intervalo de espera
cuando se intenta buscar repetidamente un
elemento del mismo nivel para la
sincronización sin éxito. Un valor de cero
significa que el intervalo de espera siempre
es el mínimo. El valor predeterminado en
los miembros del dominio es 7. El valor
predeterminado en los servidores y clientes
independientes es 7.

ResolvePeerBackoffMinutes Todas las Especifica el intervalo inicial que hay que

versiones esperar, en minutos, antes de intentar
buscar un elemento del mismo nivel para la
sincronización. El valor predeterminado en
los miembros del dominio es 15. El valor
predeterminado en los servidores y clientes
independientes es 15.

SpecialPollInterval Todas las Especifica el intervalo de sondeo especial,

versiones en segundos, para los elementos del mismo
nivel manuales. Cuando se habilita la marca
SpecialInterval 0x1, W32Time usa este
intervalo de sondeo en lugar de un
intervalo de sondeo determinado por el
sistema operativo. El valor predeterminado
en los miembros del dominio es 3600. El
valor predeterminado en los servidores y
clientes independientes es 604 800.

Nuevo en la compilación 1703:

SpecialPollInterval se incluye en los valores
del Registro Config MinPollInterval y
MaxPollInterval.

SpecialPollTimeRemaining Todas las W32Time la mantiene. Contiene datos

versiones reservados que se usan en el sistema
operativo Windows. Especifica el tiempo, en
segundos, antes de que W32Time se vuelva
a sincronizar después de reiniciar el equipo.
Cualquier cambio en esta opción puede
provocar resultados imprevisibles. El valor
predeterminado en ambos miembros del
dominio y en los servidores y clientes
independientes se deja en blanco.
Entradas NtpServer
Las entradas de la subclave NtpServer se encuentran en
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer .

Entrada del Registro Versiones Descripción

AllowNonstandardModeCombinations Todas las Indica que se permiten combinaciones de

versiones modos no estándar en la sincronización
entre clientes y servidores. El valor
predeterminado para los miembros del
dominio es 1. El valor predeterminado para
los servidores y clientes independientes es
1.

DllName Todas las Especifica la ubicación del archivo DLL para

versiones el proveedor de hora. La ubicación
predeterminada de este archivo DLL en los
miembros del dominio y en los servidores y
clientes independientes es
%windir%\System32\[Link] .

habilitado Todas las Indica si el proveedor NtpServer está

versiones habilitado en el servicio de hora actual.
1: Sí
0: No

El valor predeterminado en los miembros

del dominio es 0. El valor predeterminado
en los servidores y clientes independientes
es 0.

InputProvider Todas las Indica si se debe habilitar NtpClient como

versiones InputProvider, que obtiene la información
de hora de NtpServer. NtpServer es un
servidor de hora que responde a las
solicitudes de hora del cliente en la red,
para lo cual devuelve muestras de hora que
son útiles para sincronizar el reloj local.
1: Sí
0: No = 0

Valor predeterminado para los miembros

del dominio y los clientes independientes: 0

Registro mejorado
Las siguientes entradas del Registro no forman parte de la configuración
predeterminada de W32Time, pero se pueden agregar al Registro para obtener mayores
funcionalidades de registro. La información registrada en el registro de eventos del
sistema se puede modificar cambiando los valores de la configuración EventLogFlags en
el Editor de objetos de directiva de grupo. De manera predeterminada, el servicio de
hora de Windows registra un evento cada vez que cambia a un nuevo origen de la hora.

Para habilitar el registro de W32Time, agrega las siguientes entradas de Registro :

Entrada Versiones Descripción

FileLogEntries Todas las Controla el número de entradas creadas en el archivo de registro de

versiones hora de Windows. El valor predeterminado es none, que no registra
ninguna actividad de Hora de Windows. Los valores válidos son de 0
a 300. Este valor no afecta a las entradas del registro de eventos que
crea normalmente Hora de Windows.

FileLogName Todas las Controla la ubicación y el nombre de archivo del registro de hora de
versiones Windows. El valor predeterminado está en blanco y no debe
cambiarse a menos que se modifique FileLogEntries. Un valor válido
es una ruta de acceso completa y un nombre de archivo que Hora
de Windows usará para crear el archivo de registro. Este valor no
afecta a las entradas del registro de eventos que crea normalmente
Hora de Windows.

FileLogSize Todas las Controla el comportamiento del registro circular de los archivos de
versiones registro de hora de Windows. Cuando se definen FileLogEntries y
FileLogName, define el tamaño, en bytes, que se permite que
alcance el archivo de registro antes de sobrescribir las entradas de
registro más antiguas con nuevas entradas. Usa un valor igual o
mayor que 1000000 para esta configuración. Este valor no afecta a
las entradas del registro de eventos que crea normalmente Hora de
Windows.

Configuración de objetos de directiva de grupo

La configuración de las directivas de grupo se encuentra en los GPO Valores de
configuración global y Configuración del cliente NTP de Windows.

Parámetros de configuración global

Estos son los valores globales de la directiva de grupo y los valores predeterminados
para el servicio de hora de Windows. Estos valores se encuentran en el GPO Valores de
configuración global en el Editor de directivas local.
 Configuración de directiva de grupo Valor predeterminado

AnnounceFlags 10

EventLogFlags 2

FrequencyCorrectRate 4

HoldPeriod 5

LargePhaseOffset 1 280 000

LocalClockDispersion 10

MaxAllowedPhaseOffset 300

MaxNegPhaseCorrection 54 000 (15 horas)

MaxPollInterval 15

MaxPosPhaseCorrection 54 000 (15 horas)

MinPollInterval 10

PhaseCorrectRate 7

PollAdjustFactor 5

SpikeWatchPeriod 90

UpdateInterval 100

Configuración del cliente NTP de Windows

Estos son los valores del cliente NTP de Windows y los valores predeterminados para el
servicio de hora de Windows. Estas opciones están contenidas en el GPO Configurar el
cliente NTP de Windows en el Editor de directivas de grupo local.

Configuración de directiva de grupo Valor predeterminado

NtpServer [Link] , 0x1

Tipo NT5DS : se usa para equipos unidos a un dominio

NTP : se usa para equipos no unidos a un dominio

CrossSiteSyncFlags 2

ResolvePeerBackoffMinutes 15

ResolvePeerBackoffMaxTimes 7
 Configuración de directiva de grupo Valor predeterminado

SpecialPollInterval 3,600

EventLogFlags 0

７ Nota

Si usa directiva de grupo para establecer el valor NtpServer como parte de la

directiva Configurar cliente NTP de Windows y aplicarlo a un miembro de dominio,
el servicio de hora de Windows no usará el valor del Registro NtpServer. Para ver la
configuración de NTP, abra un símbolo del sistema y ejecute w32tm /query
/configuration .

Información relacionada
Consulte RFC 1305 : protocolo de hora de red de Internet Engineering Task Force
(IETF).
Configuración de opciones de protocolo
seguro para WinHTTP
Artículo • 21/12/2022 • Tiempo de lectura: 2 minutos

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows 10, Windows 11

En esta guía paso a paso se muestra cómo usar la entrada del DefaultSecureProtocols
Registro para elegir qué protocolos para los servicios HTTP de Windows (WinHTTP).

La DefaultSecureProtocols entrada del Registro permite especificar qué protocolos SSL

se deben usar cuando se usa la WINHTTP_OPTION_SECURE_PROTOCOLS marca . La
configuración permite que las aplicaciones compiladas usen la marca predeterminada
WinHTTP para poder usar los protocolos TLS más recientes o evitar que SSL anterior se
base de forma nativa sin necesidad de actualizaciones en la aplicación.

Prerrequisitos
Calcule el valor de DefaultSecureProtocols con
WINHTTP_OPTION_SECURE_PROTOCOLS.

Confirme que su cuenta tiene derechos administrativos para el sistema.

Asegúrese de que PowerShell está instalado.

Configuración de DefaultSecureProtocols
Para agregar y establecer la entrada del Registro DefaultSecureProtocols:

x86

1. Abra un símbolo del sistema de PowerShell con privilegios elevados.

2. Para crear y establecer la clave del DefaultSecureProtocols Registro, ejecute el

siguiente comando (reemplace por {value} el DefaultSecureProtocols valor
seleccionado en el valor Calculado).

PowerShell
 Get-Item -Path
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\WinHttp" | New-ItemProperty -Name "DefaultSecureProtocols"
-Value "{value}"

3. Reinicie la máquina o reinicie los servicios que usen WinHTTP.

Pasos siguientes
Para configurar la entrada del DefaultSecureProtocols Registro para varias
máquinas, consulte Configurar un elemento de servicio.