Windows Server Networking
Windows Server Networking
Documentação de rede
Cenários de rede com suporte do Windows Server
Novidades na rede
Diretrizes de rede principal para o Windows Server
Componentes da rede principal
Diretrizes complementares de rede principal
Implantar certificados de servidor para implantações com e sem fio do 802.1X
Visão geral da implantação de certificado do servidor
Planejamento da implantação de certificado do servidor
Implantação de certificados do servidor
Instalar o servidor Web WEB1
Criar um registro de alias (CNAME) em DNS para WEB1
Configurar WEB1 para distribuir CRLs (listas de certificados revogados)
Preparar o arquivo CAPolicy.inf
Instalar a autoridade de certificação
Configurar as extensões CPD e AIA em CA1
Copiar o certificado de Autoridade de Certificação e CRL para o diretório
virtual
Configurar o modelo de certificado do servidor
Configurar o registro automático de certificados do servidor
Atualizar política de grupo
Verificar registro de servidor de um certificado do servidor
Implantar acesso sem fio autenticado 802.1X baseado em senha
Visão geral da implantação de acesso sem fio
Processo da implantação de acesso sem fio
Planejamento da implantação de acesso sem fio
Implantação de acesso sem fio
Implantar o modo de cache hospedado do BranchCache
Visão geral da implantação do modo de cache hospedado do BranchCache
Planejamento da implantação do modo de cache hospedado do BranchCache
Implantação do modo de cache hospedado do BranchCache
Instalar o recurso BranchCache e configurar o servidor de cache hospedado
por ponto de conexão de serviço
Mover e redimensionar o cache hospedado (opcional)
Realizar hash prévio e pré-carregar conteúdo no servidor de cache hospedado
(opcional)
Configurar descoberta automática de cache hospedado cliente por ponto de
conexão de serviço
Recursos adicionais
BranchCache
Netsh BranchCache e comandos do Windows PowerShell
Guia de implantação do BranchCache
Escolher um design para o BranchCache
Implantar o BranchCache
Instalar e configurar servidores de conteúdo
Instalar servidores de conteúdo que usam o recurso BranchCache
Instalar servidores de conteúdo dos Serviços de Arquivo
Implantar servidores de cache hospedado (opcional)
Realizar o hash prévio e o pré-carregamento de conteúdo em servidores de
cache hospedado (opcionais)
Configurar BranchCache em computadores cliente
Usar política de grupo para configurar computadores cliente do membro do
domínio
Usar o Windows PowerShell para configurar computadores cliente do membro
que não sejam de domínio
Verificar configurações do computador cliente
DirectAccess
Sistema de nome de domínio (DNS)
Novidades no cliente DNS no Windows Server
Novidades no servidor DNS no Windows Server
Cliente DNS seguro via HTTPS (DoH)
DNS Anycast
Diretrizes de cenário de política DNS
Visão geral das políticas de DNS
Usar a política DNS para gerenciamento de tráfego de localização geográfica com
servidores primários
Usar a política DNS para gerenciamento de tráfego de localização geográfica com
implantações primárias e secundárias
Usar a política DNS para respostas DNS inteligentes com base na hora do dia
Respostas de DNS com base na hora do dia com o Servidor de aplicativos da
nuvem do Azure
Usar a política DNS para a implantação de DNS com partição de rede
Usar a política DNS para a DNS com partição de rede no Active Directory
Usar a política DNS para a aplicação de filtros em consultas DNS
Usar a política DNS para balanceamento de carga do aplicativo
Usar a política DNS para balanceamento de carga de aplicativo com
reconhecimento de localização geográfica
Solução de problemas de DNS
Solução de problemas de clientes DNS
Desabilitar o cache do DNS do lado do cliente em clientes DNS
Solução de problemas de servidores DNS
Protocolo DHCP
Novidades no DHCP
Opções de seleção de sub-rede DHCP
Eventos de registro em log de DHCP para registros de DNS
Implantar o DHCP usando o Windows PowerShell
Solucionar problemas do DHCP
Noções básicas do DHCP (protocolo DHCP)
Diretrizes gerais para solucionar problemas do DHCP
Como usar o endereçamento TCP/IP automático sem um servidor DHCP
Solucionar problemas no cliente DHCP
Solucionar problemas no servidor DHCP
Protocolo EAP (Extensible Authentication Protocol)
HPN (rede de alto desempenho)
Tecnologias de descarregamento e de otimização de rede
Recursos e tecnologias de SO (apenas software)
Recursos e tecnologias integrados a SH (software e hardware)
Tecnologias e recursos de HO (apenas hardware)
Propriedades avançadas de NIC
Insider Preview
RSC (União de Segmentos de Recebimento) no vSwitch
Diretrizes de configuração de NIC convergida
Configuração do adaptador de rede único
Configuração de adaptador de rede do datacenter
Configuração do comutador físico
Solução de problemas de NIC convergente
DCB (Data Center Bridging)
Instalar DCB
Gerenciar DCB
vRSS (Virtual Receive Side Scaling)
Planejar o uso de vRSS
Habilitar vRSS em um adaptador de rede virtual
Gerenciar vRSS
Perguntas frequentes sobre vRSS
Comandos do Windows PowerShell para RSS e vRSS
Resolver problemas de vRSS
API de serviço de HCN (rede de computação de host)
Cenários comuns de HCN
Identificadores de contexto de RPC para HCN
Esquemas de documento JSON de HCN
Exemplo de código gerado por C#
Exemplo de código gerado por Go
Comutador Virtual do Hyper-V
IPAM (Gerenciamento de Endereço IP)
Novidades no IPAM
Gerenciar IPAM
Gerenciamento de registro de recursos de DNS
Adicionar um registro de recursos de DNS
Excluir registros de recursos de DNS
Filtrar a exibição de registros de recursos de DNS
Exibir registros de recurso de DNS para um endereço IP específico
Gerenciamento de zonas DNS
Criar uma zona DNS
Editar uma zona DNS
Exibir registros de recurso de DNS para uma zona DNS
Exibir zonas DNS
Gerenciar recursos em várias florestas do Active Directory
Limpar dados de utilização
Controle de acesso baseado em função
Gerenciar controle de acesso baseado em função com o Gerenciador do
Servidor
Criar uma função de usuário para controle de acesso
Criar uma política de acesso
Definir escopo de acesso para uma zona DNS
Definir escopo de acesso para registros de recurso DNS
Exibir funções e permissões de função
Gerenciar controle de acesso baseado em função com o Windows PowerShell
Balanceamento de Carga de Rede
NPS (Servidor de Políticas de Rede)
Melhores práticas do NPS
Introdução ao NPS
Processamento de solicitações de conexão
Políticas de solicitação de conexão
Nomes de realm
Grupos de servidores RADIUS remotos
Políticas de rede
Permissão de acesso
Modelos NPS
Clientes RADIUS
Planejar o NPS
Planejar NPS como um servidor RADIUS
Planejar NPS como um proxy RADIUS
Implantar o NPS
Gerenciar NPS
Gerenciamento de Servidor de Políticas de Rede com Ferramentas de
Administração
Configurar políticas de solicitação de conexão
Configurar firewalls para tráfego RADIUS
Configurar políticas de rede
Configurar a contabilização do NPS
Configurar clientes RADIUS
Configurar grupos de servidores RADIUS remotos
Gerenciar certificados usados com NPS
Configurar modelos de certificado para requisitos de PEAP e EAP
Gerenciar NPSs
Configurar o NPS em um computador multihomed
Configurar informações da porta UDP do NPS
Desabilitar o encaminhamento de notificações do NAS
Exportar uma configuração do NPS para importar em outro servidor
Aumentar autenticações simultâneas processadas pelo NPS
Instalar o NPS
Balanceamento de carga do servidor proxy NPS
Registrar um NPS em um domínio do Active Directory
Cancelar o registro de um NPS de um domínio do Active Directory
Use expressões regulares no NPS
Verificar configuração depois das alterações do NPS
Coleta de dados do NPS
Gerenciar modelos do NPS
Shell de Rede (Netsh)
Sintaxe, contextos e formatação do comando netsh
Arquivo de lote de exemplo de Shell (Netsh) de rede
Comandos Netsh http
Comandos netsh interface portproxy
Comandos netsh mbn
Ajuste de desempenho do subsistema de rede
Como escolher um adaptador de rede
Configurar a ordem das interfaces de rede
Adaptadores de rede de ajuste de desempenho
Contadores de desempenho relacionados à rede
Ferramentas de desempenho para cargas de trabalho de rede
Agrupamento NIC
Gerenciamento e uso do endereço MAC de agrupamento NIC
Criar um agrupamento NIC em uma VM ou computador host
Como solucionar problemas de agrupamento NIC
Monitor de pacote (Pktmon)
Sintaxe e formatação do comando do Pktmon
Extensão de monitoramento de pacotes no Windows Admin Center
Extensão de diagnóstico de caminho de dados SDN no Windows Admin Center
Suporte do Monitor de Rede da Microsoft (Netmon)
Suporte do Wireshark (formato pcapng)
Política de QoS (qualidade de serviço)
Introdução à política de QoS
Como funciona a política de QoS
Arquitetura de política de QoS
Cenários de política de QoS
Gerenciar a política de QoS
Erros e eventos de política de QoS
Perguntas frequentes sobre a política de QoS
SDN (rede definida pelo software)
Visão geral da SDN no Windows Server
Tecnologias da SDN
Virtualização de rede Hyper-V
Visão geral da virtualização de rede Hyper-V
Detalhes técnicos da virtualização de rede Hyper-V
Novidades na virtualização de rede Hyper-V
iDNS (serviço DNS interno) para SDN
Controlador de rede
Alta disponibilidade do controlador de rede
Instalar a função de servidor do Controlador de Rede usando o Gerenciador do
Servidor
Etapas de pós-implantação para controlador de rede
Virtualização de função de rede
Visão geral do firewall do datacenter
Gateway de RAS para SDN
Arquitetura de implantação do Gateway de RAS
Alta disponibilidade do Gateway de RAS
SLB (balanceamento de carga do software) para SDN
SET (Agrupamento Incorporado de Comutador) para SDN
Rede de contêiner
Planejar SDN
Requisitos para instalação e preparação para implantação do controlador de rede
Implantar SDN
Implantar uma infraestrutura SDN
Implantar uma infraestrutura SDN usando scripts
Implantar tecnologias SDN usando o Windows PowerShell
Implantar controlador de rede usando o Windows PowerShell
Gerenciar SDN
Gerenciar redes virtuais de locatário
Noções básicas sobre o uso de redes virtuais e VLANs
Usar ACLs (listas de controle de acesso) para gerenciar o fluxo de tráfego de
rede do datacenter
Criar, excluir ou atualizar redes virtuais de locatário
Adicionar um gateway virtual a uma rede virtual de locatário
Conectar pontos de extremidade do contêiner a uma rede virtual do locatário
Configurar a criptografia para uma sub-rede virtual
Medição de saída em uma rede virtual
Gerenciar cargas de trabalho de locatário
Criar uma VM e conectar-se a uma rede virtual de locatário ou VLAN
Configurar a QoS para um adaptador de rede de VMs do locatário
Configurar ACLs de firewall do datacenter
Configurar o balanceador de carga de software para balanceamento de carga e
NAT (conversão de endereços de rede)
Usar solução de virtualização de rede em uma rede virtual
Clustering convidado em uma rede virtual
Atualizar, fazer backup e restaurar uma infraestrutura SDN
Segurança para SDN
Proteger o controlador de rede
Gerenciar certificados para SDN
Kerberos com SPN (nome da entidade de serviço)
Auditoria de firewall SDN
Emparelhamento de rede virtual
Configurar o emparelhamento de rede virtual
Desempenho de gateway do Windows Server 2019
Alocação de largura de banda de gateway
Solucionar problemas de SDN
Solucionar problemas de pilha de rede definida pelo software do Windows Server
Tecnologias do System Center para SDN
Microsoft Azure e SDN
Contatar a equipe de rede na nuvem e datacenter
VPN (rede virtual privada)
WINS (Serviço de Cadastramento na Internet do Windows)
Serviço de Tempo do Windows
Insider Preview – Serviço de Data/Hora do Windows no Windows Server 2019
Hora precisa do Windows Server 2016
Limite de suporte para hora de alta precisão
Como configurar sistemas de alta precisão
Horário do Windows para rastreamento
Referência técnica do serviço de data/hora do Windows
Como o Serviço de data/hora do Windows Funciona
Ferramentas e configurações do Serviço de data/hora do Windows
Cenários de rede com suporte do Windows Server
13/08/2021 • 5 minutes to read
aplica-se a: Windows server 2022, Windows server 2019, Windows ( canal semestral do servidor ) Windows
Server 2016
Este tópico fornece informações sobre os cenários com e sem suporte que você pode ou não executar com esta
versão do Windows Server 2016.
IMPORTANT
Para todos os cenários de produção, use os drivers de hardware mais recentes assinados do OEM do fabricante do
equipamento original ( ) ou do IHV do fornecedor de hardware independente ( ) .
NOTE
no Windows Server 2016, você pode usar o agrupamento NIC no Hyper-V, no entanto, em alguns casos, as filas de
máquina Virtual (VMQ) podem não ser habilitadas automaticamente nos adaptadores de rede subjacentes quando você
cria uma equipe NIC. se isso ocorrer, você poderá usar o seguinte comando Windows PowerShell para garantir que a
VMQ esteja habilitada nos adaptadores membros da equipe NIC:
Set-NetAdapterVmq -Name <NetworkAdapterName> -Enable
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
A seguir estão as tecnologias de rede novas ou aprimoradas Windows Server 2016. Upd Este tópico contém as
seções a seguir.
Novos recursos e tecnologias de rede
Novos recursos para tecnologias de rede adicionais
Dhcp
O DHCP é um padrão IETF (Internet Engineering Task Force) projetado para reduzir a carga administrativa e a
complexidade da configuração de hosts em uma rede baseada em TCP/IP, por exemplo, uma intranet privada.
Usando o serviço de servidor DHCP, o processo de configuração de TCP/IP em clientes DHCP é automático.
Para obter mais informações, consulte Novidades no DHCP.
DNS
DNS é um sistema usado em redes TCP/IP para nomear computadores e serviços de rede. A nomeação DNS
localiza computadores e serviços por meio de nomes simples. Quando um usuário insere um nome DNS em
um aplicativo, os serviços DNS podem resolvê-lo para outra informação associada a ele, como um endereço IP.
A seguir estão as informações sobre o cliente DNS e o servidor DNS.
Cliente DNS
A seguir estão as tecnologias de cliente DNS novas ou aprimoradas.
Associação de ser viço cliente DNS . No Windows 10, o serviço cliente DNS oferece suporte aprimorado
para computadores com mais de um interface de rede.
Para obter mais informações, consulte Novidades no cliente DNS no Windows Server 2016
Servidor DNS
A seguir estão as tecnologias de servidor DNS novas ou aprimoradas.
Políticas DNS . Você pode configurar políticas DNS para especificar como um servidor DNS responde às
consultas DNS. As respostas DNS podem ser baseadas no endereço IP do cliente (local), hora do dia e
vários outros parâmetros. As políticas dns permitem DNS com base em localização, gerenciamento de
tráfego, balanceamento de carga, DNS com dupla cabeça e outros cenários.
Supor te do Nano Ser ver para DNS baseado em arquivo. Você pode implantar o servidor DNS
Windows Server 2016 em uma imagem do Nano Server. Essa opção de implantação estará disponível
para você se você estiver usando o DNS baseado em arquivo. Ao executar o servidor DNS em uma
imagem do Nano Server, você pode executar seus servidores DNS com espaço reduzido, inicialização
rápida e a adoção de patch minimizada.
NOTE
Não há suporte para DNS integrado do Active Directory no Nano Server.
RRL (Limitação da Taxa de Resposta). Você pode habilitar a limitação da taxa de resposta em seus
servidores DNS. Ao fazer isso, você evita a possibilidade de sistemas mal-intencionados usando seus
servidores DNS para iniciar um ataque de negação de serviço em um cliente DNS.
Autenticação baseada em DNS de entidades nomeadas (DNS) . Você pode usar registros TLSA
(Autenticação de Segurança de Camada de Transporte) para fornecer informações aos clientes DNS que
informam de qual AC (autoridade de certificação) eles devem esperar um certificado para seu nome de
domínio. Isso impede ataques man-in-the-middle em que alguém pode corromper o cache DNS para
apontar para seu próprio site e fornecer um certificado emitido por uma AC diferente.
Supor te a registros desconhecidos. Você pode adicionar registros que não são explicitamente
suportados pelo servidor DNS Windows usando a funcionalidade de registro desconhecido.
Dicas raiz IPv6 . Você pode usar o suporte nativo de dicas raiz IPV6 para executar a resolução de nomes
da Internet usando os servidores raiz IPV6.
Supor te Windows PowerShell aprimorado. Novos Windows PowerShell cmdlets estão disponíveis
para o Servidor DNS.
Para obter mais informações, consulte Novidades no servidor DNS no Windows Server 2016
Túnel GRE
O Gateway ras agora dá suporte a túneis GRE (Encapsulamento de Roteamento Genérico) de alta
disponibilidade para conexões site a site e redundância M+N de gateways. GRE é um protocolo de túnel leve
que pode encapsular uma ampla variedade de protocolos de camada de rede em links de ponto a ponto virtuais
por meio de uma ligação entre redes de protocolo de Internet.
Para obter mais informações, consulte Túnel GRE no Windows Server 2016.
IPAM
IPAM fornece recursos administrativos e de monitoramento altamente personalizáveis para o endereço IP e a
infraestrutura DNS em uma rede da organização. Usando IPAM, você pode monitorar, auditar e gerenciar
servidores que executam o protocolo DHCP e o DNS (Sistema de Nomes de Domínio).
Gerenciamento de endereço IP aprimorado. IPAM recursos são aprimorados para cenários como
lidar com sub-redes IPv4 /32 e IPv6 /128 e localizar sub-redes e intervalos de endereço IP gratuitos em
um bloco de endereços IP.
Gerenciamento de ser viço DNS aprimorado. IPAM dá suporte ao registro de recursos DNS,
encaminhador condicional e gerenciamento de zona DNS para servidores DNS integrados ao Active
Directory e com suporte a arquivos ingressados no domínio.
Gerenciamento integrado de DNS, DHCP e endereço IP (DDI). Várias novas experiências e
operações integradas de gerenciamento do ciclo de vida estão habilitadas, como visualizar todos os
registros de recursos DNS que pertencem a um endereço IP, inventário automatizado de endereços IP
com base em registros de recursos DNS e gerenciamento de ciclo de vida de endereço IP para operações
DNS e DHCP.
Supor te a várias florestas do Active Director y . Você pode usar IPAM para gerenciar os servidores
DNS e DHCP de várias florestas do Active Directory quando houver uma relação de confiança de duas
vias entre a floresta em que o IPAM está instalado e cada uma das florestas remotas.
Windows PowerShell supor te para Controle de Acesso Baseado em Função . Você pode usar
Windows PowerShell para definir escopos de acesso em IPAM objetos.
Para obter mais informações, consulte Novidades no IPAM e Gerenciar IPAM.
Diretrizes de rede principal para o Windows Server
12/08/2021 • 3 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server, Windows Server 2016
Este tópico fornece uma visão geral das diretrizes de rede principal para Windows Server ® 2016 e contém as
seções a seguir.
Introdução à rede principal do Windows Server
Guia de rede principal para Windows Server
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este guia fornece instruções sobre como planejar e implantar os componentes principais necessários para uma
rede totalmente funcional e um novo domínio de Active Directory em uma nova floresta.
NOTE
este guia está disponível para download no formato Microsoft Word da galeria do TechNet. Para obter mais informações,
consulte Guia de rede de núcleo para Windows Server 2016.
Este guia de implantação fornece instruções para a implantação de uma rede principal com duas sub-redes
separadas por um roteador que tem o encaminhamento DHCP habilitado. No entanto, você pode implantar um
comutador de Camada 2, comutador de Camada 3 ou um hub, dependendo das suas necessidades e recursos.
Se você implantar um comutador, ele deverá ser capaz de encaminhar DHCP ou você deverá colocar um
servidor DHCP em cada sub-rede. Se você implantar um hub, estará implantando uma única sub-rede e não
precisará do encaminhamento DHCP ou de um segundo escopo no servidor DHCP.
C o n fi g u r a ç õ e s T C P / I P e st á t i c a s
Os servidores nesta implantação são configurados com endereços IPv4 estáticos. Os computadores cliente são
configurados por padrão para receber concessões de endereço IP do servidor DHCP.
C a t á l o g o g l o b a l d o s Se r v i ç o s d e D o m í n i o A c t i v e D i r e c t o r y e se r v i d o r D N S D C 1
O AD DS (Serviços de Domínio Active Directory) e o DNS (Sistema de Nomes de Domínio) são instalados neste
servidor, denominado DC1, que fornece os serviços de diretório e de resolução de nomes para todos os
computadores e dispositivos na rede.
Se r v i d o r D H C P D H C P 1
O servidor DHCP, denominado DHCP1, está configurado com um escopo que fornece concessões de endereços
IP para computadores na sub-rede local. O servidor DHCP pode também ser configurado com escopos
adicionais para fornecer concessões de endereços IP para computadores em outras sub-redes quando o
encaminhamento DHCP é configurado nos roteadores.
Co m pu t ado r es c l i en t e
Os computadores Windows sistemas operacionais cliente são configurados por padrão como clientes DHCP, que
obtém endereços IP e opções DHCP automaticamente do servidor DHCP.
NOTE
Para saber mais sobre como planejar sua implantação, confira também o Apêndice E – Folha de Preparação de
Planejamento de Rede Principal.
Planejando sub-redes
No sistema de redes dos protocolos TCP/IP, os roteadores são usados para interconectar o hardware e o
software usados em segmentos de rede física diferentes chamados sub-redes. Os roteadores também são
usados para encaminhar pacotes IP entre cada uma das sub-redes. Determine o layout físico da rede, incluindo
o número de roteadores e sub-redes que você precisa, antes de continuar com as instruções deste guia.
Além disso, para configurar os servidores na rede com endereços IP estáticos, determine o intervalo de
endereços IP que deseja usar para a sub-rede onde se encontram os servidores da rede principal. Neste guia, os
intervalos de endereços IP privados de 10.0.0.1 a 10.0.0.254 e 10.0.1.1 - 10.0.1.254 são usados como exemplos,
mas você pode usar qualquer intervalo de endereços IP privado que preferir.
IMPORTANT
Depois de selecionar os intervalos de endereços IP que deseja usar para cada sub-rede, verifique se você pode configurar
seus roteadores com o mesmo intervalo de endereços IP usado na sub-rede onde o roteador está instalado. Por exemplo,
se seu roteador estiver configurado por padrão com um endereço IP 192.168.1.1, mas você estiver instalando o roteador
em uma sub-rede com um intervalo de endereços IP de 10.0.0.0/24, deverá reconfigurar o roteador para usar um
endereço IP do intervalo de endereços IP 10.0.0.0/24.
Os seguintes intervalos de endereços IP privados reconhecidos são especificados pela RFC (Request for
Comments) da Internet 1918:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
Quando você usa os intervalos de endereços IP privados como especificado na RFC 1918, não pode se conectar
diretamente à Internet usando um endereço IP privado porque as solicitações desses endereços e para eles são
descartadas automaticamente pelos roteadores do ISP (provedor de serviço da Internet). Para adicionar
conectividade de Internet à rede principal mais tarde, contrate um ISP para obter um endereço IP público.
IMPORTANT
Ao usar endereços IP particulares, você deve usar algum tipo de servidor proxy ou NAT (conversão de endereços de rede)
para converter os intervalos de endereços IP privados na rede local para um endereço IP público que pode ser roteado na
Internet. A maioria dos roteadores fornecem os serviços NAT; portanto, selecionar um roteador compatível com NAT deve
ser bastante simples.
Endereço IP 10.0.0.2
NOTE
Se você planeja implantar mais de um servidor DNS, também pode planejar o endereço IP do Servidor DNS Alternativo.
IMPORTANT
Depois que o nível funcional de floresta é aumentado, os controladores de domínio que estão executando os sistemas
operacionais anteriores não podem ser introduzidos na floresta. Por exemplo, se você aumentar o nível funcional da
floresta para Windows Server 2016, os controladores de domínio que executam Windows Server 2012 R2 ou Windows
Server 2008 não poderão ser adicionados à floresta.
Escopo de Replicação de Zona do Active Directory Para todos os ser vidores DNS neste domínio
Página do assistente de Nome da Primeira Zona de Pesquisa Zona de pesquisa inversa do IPv4
Inversa
Depois do primeiro logon bem-sucedido com as credenciais de logon do domínio, as configurações de logon
persistem, a menos que o computador seja removido do domínio ou as configurações de logon sejam alteradas
manualmente.
Antes de você fazer logon no domínio:
Crie contas de usuários em Usuários e Computadores do Active Directory. Cada usuário deve ter uma
conta de usuário dos Serviços de Domínio Active Directory em Usuários e Computadores do Active
Directory. Para obter mais informações, consulte Criar uma conta de usuário em Usuários e
Computadores do Active Directory.
Verifique a configuração do endereço IP está correta. Para ingressar um computador no domínio, o
computador deve ter um endereço IP. Neste guia, os servidores são configurados com endereços IP
estáticos e os computadores cliente recebem concessões de endereços IP do servidor DHCP. Por esse
motivo, o servidor DHCP deve ser implantado antes que você adicione clientes ao domínio. Para obter
mais informações, consulte Implantando o DHCP1.
Ingresse o computador no domínio. Qualquer computador que fornece ou acessa recursos de rede deve
ser ingressado no domínio. Para obter mais informações, consulte Ingressando computadores servidores
no domínio e fazendo logon e Ingressando computadores cliente no domínio e fazendo logon.
Planejando a implantação do DHCP1
Estas são as principais etapas de planejamento antes de instalar a função de servidor DHCP no DHCP1.
Planejando os servidores DHCP e o encaminhamento DHCP
Como as mensagens DHCP são mensagens de difusão, elas não são encaminhadas entre as sub-redes por
roteadores. Se você tiver várias sub-redes e desejar fornecer o serviço DHCP em cada sub-rede, deverá fazer o
seguinte:
Instalar um servidor DHCP em cada sub-rede
Configurar roteadores para encaminhar as mensagens de difusão DHCP entre sub-redes e configurar
vários escopos no servidor DHCP, um escopo por sub-rede.
Na maioria dos casos, a configuração de roteadores para encaminhar mensagens de difusão DHCP é mais
econômica que a implantação de um servidor DHCP em cada segmento físico da rede.
Planejando intervalos de endereços IP
Cada sub-rede deve ter seu próprio intervalo de endereços IP exclusivo. Esses intervalos são representados em
um servidor DHCP com escopos.
Um escopo é um agrupamento administrativo de endereços IP para computadores em uma sub-rede que usa o
serviço DHCP. O administrador primeiro cria um escopo para cada sub-rede física e, em seguida, usa o escopo
para definir os parâmetros usados pelos clientes.
Um escopo tem as seguintes propriedades:
Um intervalo de endereços IP do qual incluir ou excluir endereços usados para ofertas de concessão de
serviço DHCP.
Uma máscara de sub-rede, que determina o prefixo de sub-rede para um determinado endereço IP.
Um nome de escopo atribuído quando é criado.
Valores de duração da concessão, que são atribuídos aos clientes DHCP que recebem endereços IP
alocados dinamicamente.
Qualquer opção de escopo DHCP configurada para atribuição a clientes DHCP, como endereço ID do
servidor DNS ou endereço IP do gateway do roteador/padrão.
As reservas são opcionalmente usadas para garantir que um cliente DHCP sempre receba o mesmo
endereço IP.
Antes de implantar os servidores, liste suas sub-redes e o intervalo de endereços IP que você deseja usar para
cada sub-rede.
Planejando máscaras de sub-rede
As IDs de rede e IDs de host são diferenciadas usando uma máscara de sub-rede. Cada máscara de sub-rede é
um número de 32 bits que usa grupos de bits consecutivos de todos (1) para identificar a ID da rede e todos os
zeros (0) para identificar as partes de ID do host de um endereço IP.
Por exemplo, a máscara de sub-rede normalmente usada com o endereço IP 131.107.16.200 é o seguinte
número binário de 32 bits:
Esse número de máscara de sub-rede são 16 bits de um seguidos de 16 bits de zero, indicando que as seções de
ID da rede e as seções de ID do host desse endereço IP têm 16 bits de comprimento. Normalmente, essa
máscara de sub-rede é exibida em notação decimal com ponto como 255.255.0.0.
A tabela a seguir exibe as máscaras de sub-rede para as classes de endereço de Internet.
Quando você cria um escopo no DHCP e insere o intervalo de endereços IP do escopo, o DHCP fornece esses
valores de máscara de sub-rede padrão. Normalmente, os valores de máscara de sub-rede padrão são
aceitáveis para a maioria das redes sem requisitos especiais e onde cada segmento de rede IP corresponde a
uma única rede física.
Em alguns casos, você pode usar máscaras de sub-rede personalizadas para implementar a criação de sub-
redes IP. Com a criação de sub-redes IP, você pode subdividir a parte padrão de ID de host de um endereço IP
para especificar sub-redes, que são subdivisões de ID de rede baseada na classe original.
Personalizando o comprimento da máscara de sub-rede, você pode reduzir o número de bits que são usados
para o ID de host real.
Para evitar a solução e o roteamento de problemas, verifique se todos os computadores TCP/IP em um
segmento de rede usam a mesma máscara de sub-rede e se cada computador ou dispositivo tem um endereço
IP exclusivo.
Planejando intervalos de exclusão
Quando você cria um escopo em um servidor DHCP, pode especificar um intervalo de endereços IP que inclui
todos os endereços IP que o servidor DHCP pode conceder aos clientes DHCP, como computadores e outros
dispositivos. Se você acessar e configurar manualmente alguns servidores e outros dispositivos com endereços
IP estáticos do mesmo intervalo de endereços IP usado pelo servidor DHCP, poderá criar acidentalmente um
conflito de endereços IP, onde você e o servidor DHCP atribuem o mesmo endereço IP a dispositivos diferentes.
Para resolver esse problema, você pode criar um intervalo de exclusão para o escopo DHCP. Um intervalo de
exclusão é um intervalo contíguo de endereços IP dentro do intervalo de endereços IP do escopo que o servidor
DHCP não tem permissão para usar. Se você criar um intervalo de exclusão, o servidor DHCP não atribuirá os
endereços nesse intervalo, permitindo que você atribua manualmente esses endereços sem criar um conflito de
endereços IP.
Você pode excluir endereços IP da distribuição pelo servidor DHCP, criando um intervalo de exclusão para cada
escopo. Use as exclusões para todos os dispositivos configurados com um endereço IP estático. Os endereços
excluídos devem incluir todos os endereços IP que você atribuiu manualmente a outros servidores, clientes não-
DHCP, estações de trabalho sem disco ou clientes de Roteamento, Acesso Remoto e PPP.
Recomendamos que você configure o intervalo de exclusão com endereços extras para acomodar o crescimento
futuro da rede. A tabela a seguir fornece um intervalo de exclusão de exemplo para um escopo com um
intervalo de endereços IP 10.0.0.1 a 10.0.0.254 e uma máscara de sub-rede de 255.255.255.0.
NOTE
Comandos equivalentes do Windows PowerShell são fornecidos para a maioria dos procedimentos neste guia. Antes
de executar esses cmdlets no Windows PowerShell, substitua os valores de exemplo pelos valores que são apropriados
para sua implantação de rede. Além disso, insira cada cmdlet em uma única linha no Windows PowerShell. Neste guia,
cmdlets individuais podem aparecer em várias linhas devido à formatação de restrições e à exibição do documento por
outro aplicativo ou navegador.
Os procedimentos deste guia não incluem instruções para os casos em que a caixa de diálogo Controle de Conta
de Usuário é aberta para solicitar sua permissão para continuar. Caso essa caixa de diálogo seja aberta durante a
execução dos procedimentos deste guia e em resposta às suas ações, clique em Continuar .
NOTE
Para executar este procedimento usando o Windows PowerShell, abra o PowerShell, digite os cmdlets a seguir em linhas
separadas e pressione ENTER. Você também deve substituir Nome_do_Computador pelo nome que deseja usar.
Rename-Computer Computername
Restart-Computer
1. No Gerenciador do Servidor, clique em Ser vidor Local . As Propriedades do computador são exibidas
no painel de detalhes.
2. Em Propriedades , em Nome do computador , clique no nome existente. A caixa de diálogo
Propriedades do Sistema será aberta. Clique em Alterar . A caixa de diálogo Alterações de
Nome/Domínio do Computador será aberta.
3. Na caixa de diálogo Alterações de Nome/Domínio do Computador , no Nome do computador ,
digite um novo nome para o computador. Por exemplo, se você deseja denominar o computador como
DC1, digite DC1 .
4. Clique em OK duas vezes e depois em Fechar . Se você deseja reiniciar o computador imediatamente
para concluir a alteração de nome, clique em Reiniciar Agora . Caso contrário, clique em Reiniciar Mais
Tarde .
NOTE
Para obter informações sobre como renomear computadores que estão executando outros sistemas operacionais da
Microsoft, consulte Apêndice A – Renomeando computadores.
NOTE
Para executar este procedimento usando o Windows PowerShell, abra o PowerShell, digite os cmdlets a seguir em linhas
separadas e pressione ENTER. Você também deve substituir os nomes de interface e os endereços IP neste exemplo pelos
valores que deseja usar para configurar o seu computador.
New-NetIPAddress -IPAddress 10.0.0.2 -InterfaceAlias "Ethernet" -DefaultGateway 10.0.0.1 -AddressFamily
IPv4 -PrefixLength 24
1. Na barra de tarefas, clique com o botão direito do mouse no ícone Rede e clique em Abrir a Central de
Rede e Compar tilhamento .
2. No Central de Rede e Compar tilhamento , clique em Alterar configurações do adaptador . A
pasta Conexões de Rede é aberta e exibe as conexões de rede disponíveis.
3. Em Conexões de Rede , clique com o botão direito do mouse na conexão que deseja configurar e clique
em Propriedades . A caixa de diálogo Propriedades da conexão de rede é aberta.
4. Na caixa de diálogo Propriedades da conexão de rede, em Esta conexão utiliza os seguintes itens ,
selecione Protocolo TCP/IPv4 (TCP/IP Versão 4) e clique em Propriedades . A caixa de diálogo
Propriedades do Protocolo TCP/IPv4 (TCP/IP Versão 4) será aberta.
5. Em Propriedades do Protocolo TCP/IPv4 (TCP/IP Versão 4) , na guia Geral , clique em Usar o
seguinte endereço IP . Em Endereço IP , digite o endereço IP que deseja usar.
6. Pressione Tab para colocar o cursor em Máscara de sub-rede . Um valor padrão para máscara de sub-
rede será inserido automaticamente. Aceite a máscara de sub-rede padrão ou digite a máscara de sub-
rede que deseja usar.
7. No Gateway padrão , digite o endereço IP do seu gateway padrão.
NOTE
Configure o Gateway padrão com o mesmo endereço IP usado na interface de LAN (rede de área local) do seu
roteador. Por exemplo, se você tiver um roteador que está conectado a uma WAN (rede de longa distância), como
a Internet, bem como a sua LAN, configure a interface de LAN com o mesmo endereço IP que você especificará
como o Gateway padrão . Em outro exemplo, se você tiver um roteador que está conectado a duas LANs, onde
a LAN A usa o intervalo de endereços 10.0.0.0/24 e a LAN B usa o intervalo de endereços 192.168.0.0/24,
configure a LAN A com um endereço de IP de roteador a partir desse intervalo de endereço, como 10.0.0.1. Além
disso, no escopo DHCP desse intervalo de endereços, configure o Gateway padrão com o endereço IP 10.0.0.1.
Para a LAN B, configure a interface do roteador da LAN B com um endereço desse intervalo de endereços, como
192.168.0.1, e configure o escopo da LAN B 192.168.0.0/24 com um valor de Gateway padrão de 192.168.0.1.
8. Em Ser vidor DNS preferencial , digite o endereço IP do seu servidor DNS. Se você planeja usar o
computador local como o servidor DNS preferencial, digite o endereço IP do computador local.
9. Em Ser vidor DNS alternativo , digite o endereço IP do seu servidor DNS alternativo, se houver. Se você
planeja usar o computador local como um servidor DNS alternativo, digite o endereço IP do computador
local.
10. Clique em OK e então clique em Fechar .
NOTE
Para obter informações sobre como configurar um endereço IP estático em computadores que executam outros sistemas
operacionais da Microsoft, consulte Apêndice B – Configurando endereços IP estáticos.
Implantando o DC1
Para implantar o DC1, que é o computador que executa o AD DS (Serviços de Domínio Active Directory) e o
DNS, conclua estas etapas na seguinte ordem:
Siga as etapas na seção Configurando todos os servidores.
Instalar o AD DS e o DNS para uma Nova Floresta
Criar uma Conta de Usuário em Usuários e Computadores do Active Directory
Atribuir a associação ao grupo
Configurar uma zona de pesquisa inversa de DNS
Privilégios administrativos
Se você estiver instalando uma rede pequena e for o único administrador da rede, recomendamos que crie uma
conta de usuário para si mesmo e adicione sua conta de usuário como um membro dos Administradores de
Empresa e Administradores do Domínio. Isso tornará mais fácil para você atuar como o administrador de todos
os recursos de rede. Também recomendamos que você faça logon com essa conta somente quando precisar
executar tarefas administrativas e crie uma conta de usuário separada para executar outras tarefas relacionadas.
Se você tem uma organização maior com vários administradores, consulte a documentação do AD DS para
determinar a melhor associação de grupo para os funcionários da organização.
Diferenças entre contas de usuário de domínio e contas de usuário no computador local
Uma das vantagens de uma infraestrutura baseada em domínio é que você não precisa criar contas de usuário
em cada computador no domínio. Isso é verdadeiro quando o computador é um computador cliente ou um
servidor.
Devido a isso, você não deve criar contas de usuário em cada computador no domínio. Crie todas as contas de
usuário em Usuários e Computadores do Active Directory e use os procedimentos anteriores para atribuir a
associação de grupo. Por padrão, todas as contas de usuário são membros do grupo Usuários do Domínio.
Todos os membros do grupo Usuários do Domínio podem fazer logon em qualquer computador cliente depois
que ele é associado ao domínio.
Você pode configurar contas de usuário para designar os dias e horários em que o usuário tem permissão para
fazer logon no computador. Você também pode designar que computadores cada usuário tem permissão para
usar. Para definir essas configurações, abra Usuários e Computadores do Active Directory, localize a conta de
usuário que deseja configurar e clique duas vezes na conta. Em Propriedades da conta de usuário, clique na
guia Conta e clique em Horário de Logon ou em Fazer Logon em .
Instalar o AD DS e o DNS para uma Nova Floresta
Você pode usar um dos procedimentos a seguir para instalar Active Directory Domain Services (AD DS) e DNS e
para criar um novo domínio em uma nova floresta.
O primeiro procedimento fornece instruções sobre como executar essas ações usando Windows PowerShell,
enquanto o segundo procedimento mostra como instalar AD DS e DNS usando Gerenciador do Servidor.
IMPORTANT
Depois de concluir a execução das etapas neste procedimento, o computador será reiniciado automaticamente.
NOTE
Para obter mais informações sobre esses Windows PowerShell, consulte os tópicos de referência a seguir.
Install-WindowsFeature
Install-ADDSForest
O mínimo necessário para executar este procedimento é ser membro do grupo Administradores .
Execute Windows PowerShell administrador, digite o seguinte comando e pressione ENTER:
Quando a instalação for concluída com êxito, a mensagem a seguir será exibida Windows PowerShell.
REIN IC IA L IZ A Ç Ã O
ÊXITO N EC ESSÁ RIA C Ó DIGO DE SA ÍDA RESULTA DO DO REC URSO
No Windows PowerShell, digite o seguinte comando, substituindo o texto corp.contoso.com pelo nome de
domínio e pressione ENTER:
Durante o processo de instalação e configuração, que é visível na parte superior da janela Windows
PowerShell, o prompt a seguir é exibido. Depois de aparecer, digite uma senha e pressione ENTER.
SafeModeAdministratorPassword:
Depois de digitar uma senha e pressionar ENTER, o prompt de confirmação a seguir será exibido. Digite a
mesma senha e pressione ENTER.
Confirme SafeModeAdministratorPassword:
Quando o prompt a seguir for exibido, digite a letra Y e pressione ENTER.
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"):
Se quiser, você poderá ler as mensagens de aviso exibidas durante a instalação normal e bem-sucedida
do AD DS DNS. Essas mensagens são normais e não são uma indicação de falha de instalação.
Após a instalação ser bem-sucedida, será exibida uma mensagem informando que você está prestes a ser
desconectado do computador para que o computador possa ser reiniciado. Se você clicar em Fechar ,
será imediatamente desconectado do computador e o computador será reiniciado. Se você não clicar em
Fechar , o computador será reiniciado após um período padrão.
Depois que o servidor for reiniciado, você poderá verificar a instalação bem-sucedida Active Directory
Domain Services e DNS. Abra Windows PowerShell, digite o comando a seguir e pressione ENTER.
Get-WindowsFeature
Os resultados desse comando são exibidos Windows PowerShell e devem ser semelhantes aos resultados na
imagem abaixo. Para tecnologias instaladas, os colchetes à esquerda do nome da tecnologia contêm o caractere
X e o valor de Estado de Instalação é Instalado.
Instalar AD DS e DNS usando Gerenciador do Ser vidor
1. No DC1, no Gerenciador do Ser vidor , clique em Gerenciar e em Adicionar Funções e Recursos . O
Assistente para Adicionar Funções e Recursos é aberto.
2. Em Antes de Começar , clique em Avançar .
NOTE
A página Antes de Começar do Assistente para Adicionar Funções e Recursos não é exibida quando você marca
a opção Ignorar esta página por padrão quando o Assistente para Funções e Recursos foi executado.
C r i a r u m a C o n t a d e U su á r i o e m U su á r i o s e C o m p u t a d o r e s d o A c t i v e D i r e c t o r y
Você pode usar este procedimento para criar uma nova conta de usuário de domínio no MMC (Console de
Gerenciamento Microsoft) Usuários e Computadores do Active Directory.
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.
NOTE
Para executar este procedimento usando o Windows PowerShell, abra o PowerShell, digite o cmdlet a seguir em uma linha
e pressione ENTER. Você também deve substituir o nome da conta de usuário neste exemplo pelo valor que você deseja
usar.
New-ADUser -SamAccountName User1 -AccountPassword (read-host "Set user password" -assecurestring) -name
"User1" -enabled $true -PasswordNeverExpires $true -ChangePasswordAtLogon $false
Depois de pressionar ENTER, digite a senha da conta de usuário. A conta é criada e, por padrão, é concedida a associação
ao grupo Usuários do Domínio.
Com o cmdlet a seguir, você pode atribuir membros de grupos adicionais à nova conta de usuário. O exemplo a seguir
adiciona User1 aos grupos Administradores do Domínio e Administradores de Empresa. Antes de executar esse comando,
altere o nome de conta de usuário, o nome do domínio e os grupos para atender às suas necessidades.
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"
P a ra c ri a r u ma c o n t a d e u s u á ri o
Você pode usar este procedimento para adicionar um usuário, computador ou grupo a um grupo no MMC
(Console de Gerenciamento Microsoft) Usuários e Computadores do Active Directory.
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.
A t ri b u i r a a s s o c i a ç ã o a o g ru p o
Você pode usar este procedimento para configurar uma zona de pesquisa inversa no DNS (Sistema de Nome de
Domínio).
O mínimo necessário para executar este procedimento é ser membro do grupo Adminis. do Domínio .
NOTE
Para organizações de médio e grande porte, é recomendável que você configure e use o grupo DNSAdmins em Active
Directory usuários e computadores. Para obter mais informações, consulte Recursos técnicos adicionais.
Para executar este procedimento usando o Windows PowerShell, abra o PowerShell, digite o cmdlet a seguir em uma
linha e pressione ENTER. Você também deve substituir os nomes da zona de pesquisa inversa DNS e do arquivo de
zona neste exemplo pelos valores que deseja usar. Verifique se você inverteu a ID de rede para o nome de zona
inversa. Por exemplo, se a ID de rede for 192.168.0, crie o nome da zona de pesquisa inversa 0.168.192.in-addr.
arpa .
Add-DnsServerPrimaryZone 0.0.10.in-addr.arpa -ZoneFile 0.0.10.in-addr.arpa.dns
P a ra c o n f i g u ra r u ma z o n a d e p e s q u i s a i n v e rs a d e DN S
NOTE
Para executar este procedimento usando o Windows PowerShell, abra o PowerShell, digite o cmdlet a seguir e pressione
ENTER. Você também deve substituir o nome do domínio pelo nome que deseja usar.
Add-Computer -DomainName corp.contoso.com
Quando você for solicitado a fazê-lo, digite o nome de usuário e a senha de uma conta que tenha permissão para
ingressar um computador no domínio. Para reiniciar o computador, digite o comando a seguir e pressione ENTER.
Restart-Computer
1. No Gerenciador do Servidor, clique em Ser vidor Local . No painel de detalhes, clique em Grupo de
Trabalho . A caixa de diálogo Propriedades do Sistema será aberta.
2. Na caixa de diálogo Propriedades do Sistema , clique em Alterar . A caixa de diálogo Alterações de
Nome/Domínio do Computador será aberta.
3. No Nome do Computador , em Membro de , clique em Domínio e digite o nome do domínio no qual
você deseja ingressar. Por exemplo, se o nome do domínio for corp.contoso.com, digite
corp.contoso.com .
4. Clique em OK . A caixa de diálogo Segurança do Windows será aberta.
5. Em Alterações de Nome/Domínio do Computador , em Nome de usuário , digite o nome de
usuário, digite a senha no campo Senha e clique em OK . A caixa de diálogo Alterações de
Nome/Domínio do Computador é aberta, dando as boas-vindas ao domínio. Clique em OK .
6. A caixa de diálogo Alterações de Nome/Domínio do Computador exibe uma mensagem indicando
que você deve reiniciar o computador para aplicar as alterações. Clique em OK .
7. Na caixa de diálogo Propriedades do Sistema , na guia Nome do Computador , clique em Fechar . A
caixa de diálogo Microsoft Windows é aberta e exibe uma mensagem, indicando novamente que você
deve reiniciar o computador para aplicar as alterações. Clique em Reiniciar Agora .
NOTE
Para obter informações sobre como unir computadores que estão executando outros sistemas operacionais da Microsoft
ao domínio, consulte o Apêndice C-unindo computadores ao domínio.
P a ra f a z e r l o g o n n o d o mí n i o u s a n d o c o mp u t a d o re s q u e e x e c u t a m o W i n d o w s Se rv e r 2016
NOTE
Para obter informações sobre como fazer logon no domínio usando computadores que executam outros sistemas
operacionais da Microsoft, consulte o Apêndice D – fazer logon no domínio.
Implantando o DHCP1
Antes de implantar este componente da rede principal, faça o seguinte:
Siga as etapas na seção Configurando todos os servidores.
Siga as etapas na seção Ingressando computadores servidores no domínio e fazendo logon.
Para implantar o DHCP1, que é o computador que executa a função de servidor do protocolo DHCP, conclua
estas etapas na seguinte ordem:
Instalar o protocolo DHCP
Criar e ativar um novo escopo do DHCP
NOTE
Para executar estes procedimentos usando o Windows PowerShell, abra o PowerShell, digite os cmdlets a seguir em linhas
separadas e pressione ENTER. Substitua o nome do escopo, os intervalos de endereços IP iniciais e finais, a máscara de
sub-rede e outros valores neste exemplo pelos valores que você deseja usar.
Install-WindowsFeature DHCP -IncludeManagementTools
Você pode usar este procedimento para instalar e configurar a função de Servidor DHCP usando o Assistente
para Adicionar Funções e Recursos.
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.
P a ra i n s t a l a r o DHC P
NOTE
A página Antes de Começar do Assistente para Adicionar Funções e Recursos não é exibida quando você marca
a opção Ignorar esta página por padrão quando o Assistente para Funções e Recursos foi executado.
Você pode usar este procedimento para criar um novo escopo do DHCP usando o MMC (Console de
Gerenciamento Microsoft) DHCP. Quando você conclui o procedimento, o escopo é ativado e o intervalo de
exclusão que você cria impede que o servidor DHCP conceda os endereços IP usados para configurar
estaticamente os servidores e outros dispositivos que exigem um endereço IP estático.
A associação em Administradores DHCP , ou equivalente, é o requisito mínimo para executar este
procedimento.
P a ra c ri a r e a t i v a r u m n o v o e s c o p o d o DHC P
IMPORTANT
Para criar novos escopos para sub-redes adicionais, repita o procedimento. Use um intervalo de endereços IP diferente
para cada sub-rede que você planeja implantar e verifique se o encaminhamento de mensagem DHCP está habilitado em
todos os roteadores que levam a outras sub-redes.
NOTE
Para executar este procedimento usando o Windows PowerShell, abra o PowerShell, digite o cmdlet a seguir e pressione
ENTER. Você também deve substituir o nome do domínio pelo nome que deseja usar.
Add-Computer -DomainName corp.contoso.com
Quando você for solicitado a fazê-lo, digite o nome de usuário e a senha de uma conta que tenha permissão para
ingressar um computador no domínio. Para reiniciar o computador, digite o comando a seguir e pressione ENTER.
Restart-Computer
P a r a i n g r e ssa r c o m p u t a d o r e s e x e c u t a n d o W i n d o w s 1 0 a o d o m í n i o
NOTE
Você pode implantar certificados de servidor e outros recursos adicionais por meio de Guias Complementares de Rede
Principal. Para obter mais informações, consulte Recursos técnicos adicionais.
A ilustração a seguir mostra a topologia Windows Server Core Network com NPS e servidores Web
adicionados.
As seções a seguir fornecem informações sobre como adicionar servidores NPS e Web a sua rede.
Implantando o NPS1
Implantando o WEB1
Implantando o NPS1
O servidor NPS (Servidor de Políticas de Rede) é instalado como uma etapa preparatória para a implantação de
outras tecnologias de acesso à rede, como servidores VPN (rede virtual privada), pontos de acesso sem fio e
comutadores de autenticação 802.1X.
O NPS (servidor de diretivas de rede) permite que você configure e gerencie centralmente as políticas de rede
com os seguintes recursos: serviço RADIUS (RADIUS) servidor e proxy RADIUS.
O NPS é um componente opcional de uma rede principal, mas você deve instalar o NPS quando qualquer uma
das seguintes opções é verdadeira:
você está planejando expandir sua rede para incluir servidores de acesso remoto que são compatíveis
com o protocolo RADIUS, como um computador executando Windows Server 2016, Windows Server
2012 R2, Windows Server 2012, Windows server 2008 R2 ou Windows server 2008 e serviço de
roteamento e acesso remoto, gateway de serviços de Terminal ou Área de Trabalho Remota gateway.
Você planeja implantar a autenticação 802.1 X para acesso com ou sem fio.
Antes de implantar esse serviço de função, você deve executar as etapas a seguir no computador que está
configurando como um NPS.
Siga as etapas na seção Configurando todos os servidores.
Siga as etapas na seção Ingressando computadores servidores no domínio e fazendo logon.
Para implantar o NPS1, que o computador está executando o serviço de função do NPS (Servidor de Políticas de
Rede) da função de servidor de Política de Rede e Serviços de Acesso, conclua esta etapa:
Planejando a implantação do NPS1
Instalar o NPS (Servidor de Políticas de Rede)
Registrar o NPS no domínio padrão
NOTE
Este guia fornece instruções para implantar o NPS em um servidor autônomo ou VM chamada NPS1. Outro modelo de
implantação recomendado é a instalação do NPS em um controlador de domínio. Se preferir instalar o NPS em um
controlador de domínio em vez de em um servidor autônomo, instale o NPS no DC1.
P l a n e j a n d o a i m p l a n t a ç ã o d o N P S1
Se você pretende implantar servidores de acesso à rede, como pontos de acesso sem fio ou servidores VPN,
depois de implantar a rede principal, recomendamos que implante o NPS.
Quando você usa o NPS como um servidor do serviço RADIUS, o NPS executa a autenticação e a autorização
para solicitações de conexão por meio de servidores de acesso à rede. O NPS também permite que você
configure e gerencie de forma centralizada as políticas de rede que determinam quem pode acessar a rede,
como eles podem acessar a rede e quando eles podem acessar a rede.
Estas são as principais etapas de planejamento antes de instalar o NPS.
Planeje o banco de dados de contas de usuário. Por padrão, se você ingressar o servidor que executa o
NPS em um domínio do Active Directory, o NPS executará a autenticação e a autorização usando o banco
de dados de contas de usuário do AD DS. Em alguns casos, como em grandes redes que usam o NPS
como um proxy RADIUS para encaminhar solicitações de conexão a outros servidores RADIUS, você
pode desejar instalar o NPS em um computador que não é membro do domínio.
Planeje a contabilização do RADIUS. O NPS permite que você registre em log os dados de contabilização
em um banco de dados SQL Server ou em um arquivo de texto no computador local. Se você deseja usar
o registro em log do SQL Server, planeje a instalação e a configuração de seu servidor que executa o SQL
Server.
I n st a l a r o N P S (Se r v i d o r d e P o l í t i c a s d e R e d e )
Você pode usar este procedimento para instalar o NPS (servidor de diretivas de rede) usando o assistente para
adicionar funções e recursos. O NPS é um serviço de função da função de servidor Serviços de Acesso e Política
de Rede.
NOTE
Por padrão, o NPS ouve o tráfego RADIUS nas portas 1812, 1813, 1645 e 1646 em todos os adaptadores de rede
instalados. se Windows Firewall com segurança avançada estiver habilitado quando você instalar o NPS, as exceções de
Firewall para essas portas serão criadas automaticamente durante o processo de instalação para o ( tráfego IPv6 e IPv4
do protocolo ip versão 6 ) . se os servidores de acesso à rede estiverem configurados para enviar tráfego RADIUS por
portas diferentes desses padrões, remova as exceções criadas em Windows Firewall com segurança avançada durante a
instalação do NPS e crie exceções para as portas que você usa para o tráfego RADIUS.
Credenciais administrativas
Para concluir este procedimento, você deve ser um membro do grupo Administradores de Domínio .
NOTE
Para executar este procedimento usando o Windows PowerShell, abra o PowerShell, digite o texto a seguir e pressione
ENTER.
Install-WindowsFeature NPAS -IncludeManagementTools
P a ra i n s t a l a r o N P S
NOTE
A página Antes de Começar do Assistente para Adicionar Funções e Recursos não é exibida quando você marca
a opção Ignorar esta página por padrão quando o Assistente para Funções e Recursos foi executado.
Você pode usar este procedimento para registrar um NPS no domínio em que o servidor é membro do
domínio.
NPSs deve ser registrado em Active Directory para que eles tenham permissão para ler as propriedades de
discagem de contas de usuário durante o processo de autorização. O registro de um NPS adiciona o servidor ao
grupo de Ser vidores RAS e ias em Active Directory.
Credenciais administrativas
Para concluir este procedimento, você deve ser um membro do grupo Administradores de Domínio .
NOTE
para executar esse procedimento usando comandos do shell de rede (Netsh) no Windows PowerShell, abra o PowerShell e
digite o seguinte e pressione ENTER.
netsh nps add registeredserver domain=corp.contoso.com server=NPS1.corp.contoso.com
P a ra re g i s t ra r u m N P S e m s e u d o mí n i o p a d rã o
NOTE
Para executar este procedimento usando o Windows PowerShell, abra o PowerShell, digite o texto a seguir e pressione
ENTER.
Install-WindowsFeature Web-Server -IncludeManagementTools
NOTE
A página Antes de Começar do Assistente para Adicionar Funções e Recursos não é exibida quando você marca
a opção Ignorar esta página por padrão quando o Assistente para Funções e Recursos foi executado.
3. Na página Selecionar tipo de instalação , clique em Avançar .
4. Na página selecionar ser vidor de destino , verifique se o computador local está selecionado e clique
em Avançar .
5. Na página selecionar funções de ser vidor , role para e selecione ser vidor Web (IIS) . A caixa de
diálogo Adicionar recursos necessários para o ser vidor Web (IIS) é aberta. Clique em Adicionar
Recursos e depois em Avançar .
6. Clique em Avançar até ter aceitado todas as configurações padrão do servidor Web e clique em
Instalar .
7. Confirme se todas as instalações tiveram êxito e clique em Fechar .
Apêndices A a E
as seções a seguir contêm informações de configuração adicionais para computadores que executam sistemas
operacionais diferentes de Windows Server 2016, Windows 10, Windows Server 2012 e Windows 8. Além
disso, uma planilha de preparação de rede é fornecida para ajudá-lo com sua implantação.
1. Apêndice A – Renomeando computadores
2. Apêndice B – Configurando endereços IP estáticos
3. Apêndice C – unindo computadores ao domínio
4. Apêndice D – fazer logon no domínio
5. Apêndice E – Folha de preparação do planejamento da Rede Principal
1. Clique em Iniciar , clique com botão direito do computador e clique em Propriedades . Será exibida a
caixa de diálogo Sistema .
2. Em Nome do computador, domínio e configurações de grupo de trabalho , clique em Alterar
configurações . A caixa de diálogo Propriedades do Sistema será aberta.
NOTE
em computadores que executam o Windows 7, antes que a caixa de diálogo propriedades do sistema seja
aberta, a caixa de diálogo controle de conta de usuário é aberta, solicitando permissão para continuar. Clique
em Continuar para prosseguir.
1. Clique em Iniciar , clique com botão direito do computador e clique em Propriedades . Será exibida a
caixa de diálogo Sistema .
2. Em Nome do computador, domínio e configurações de grupo de trabalho , clique em Alterar
configurações . A caixa de diálogo Propriedades do Sistema será aberta.
NOTE
em computadores que executam o Windows Vista, antes da caixa de diálogo propriedades do sistema ser
aberta, a caixa de diálogo controle de conta de usuário é aberta, solicitando permissão para continuar. Clique
em Continuar para prosseguir.
IMPORTANT
Para ingressar um computador em um domínio, faça logon no computador com a conta de Administrador local ou, se já
estiver conectado ao computador com uma conta de usuário que não tem credenciais administrativas do computador
local, forneça as credenciais para a conta de Administrador local durante o processo de ingressar o computador no
domínio. Além disso, você deve ter uma conta de usuário no domínio no qual deseja ingressar o computador. Durante o
processo de ingressar o computador no domínio, você será solicitado para inserir as credenciais de conta de domínio
(nome de usuário e senha).
NOTE
Em computadores que executam Windows 7, antes que a caixa de diálogo Propriedades do Sistema seja aberta, a
caixa de diálogo Controle de Conta de Usuário será aberta, solicitando permissão para continuar. Clique em
Continuar para prosseguir.
Endereço IP 10.0.0.2
Renomear o computador
IT EM DE C O N F IGURA Ç Ã O VA LO R DE EXEM P LO VA LO R
I t e n s d e c o n fi g u r a ç ã o d e i n st a l a ç ã o d o A D D S e d o D N S
Itens de configuração para o procedimento de implantação da Rede Principal do Windows Server Instalar o AD
DS e o DNS para uma Nova Floresta:
Instalando o DHCP
As tabelas nesta seção listam os itens de configuração de pré-instalação e de instalação do DHCP.
I t e n s d e c o n fi g u r a ç ã o d e p r é - i n st a l a ç ã o d o D H C P
Endereço IP 10.0.0.3
Renomear o computador
IT EM DE C O N F IGURA Ç Ã O VA LO R DE EXEM P LO VA LO R
I t e n s d e c o n fi g u r a ç ã o d e i n st a l a ç ã o d o D H C P
Comprimento 8
Duração da concessão -8
Dias -0
-0
Horas
minutos
As seguintes três tabelas listam os itens de configuração de pré-instalação descritos em Configurando todos os
servidores:
Configurar um endereço IP estático
Endereço IP 10.0.0.4
Renomear o computador
IT EM DE C O N F IGURA Ç Ã O VA LO R DE EXEM P LO VA LO R
I t e n s d e c o n fi g u r a ç ã o d e i n st a l a ç ã o d o Se r v i d o r d e P o l í t i c a s d e R e d e
Itens de configuração para os Windows implantação nps de rede do server core instalam o NPS (Servidor de
Políticas de Rede) e registram o NPS no domínio padrão.
Nenhum item de configuração adicional é necessário para instalar e registrar o NPS.
Diretrizes de complementar de rede principal
10/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
embora o guia de rede do Windows Server 2016 Core forneça instruções sobre como implantar uma nova
floresta do Active Directory ® com um novo domínio raiz e a infraestrutura de rede de suporte, os guias
complementares fornecem a capacidade de adicionar recursos à sua rede.
Cada guia complementar permite cumprir uma meta específica, após a implantação de sua rede principal. Em
alguns casos, existem vários guias complementarem que, quando implantados juntos e na ordem correta,
permitem realizar objetivos muito complexos de forma medida, econômica e razoável.
Se você implantou sua rede principal e seu domínio do Active Directory antes de encontrar o Guia da Rede
Principal, ainda pode usar os Guias Complementares para adicionar recursos à sua rede. Simplesmente use o
Guia da Rede Principal como uma lista de pré-requisitos e saiba que, para implantar recursos adicionais com os
Guias Complementares, a rede deve atender aos pré-requisitos que são fornecidos pelo Guia da Rede Principal.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este guia para implantar certificados de servidor em seus servidores de infraestrutura do NPS
(Servidor de Políticas de Rede e Acesso Remoto).
Este guia contém as seções a seguir.
Pré-requisitos para usar este guia
O que este guia não contém
Visões gerais da tecnologia
Visão geral da implantação de certificado do servidor
Planejamento de implantação de certificado do servidor
Implantação de certificado do servidor
Certificados do servidor digital
Este guia fornece instruções para usar Serviços de Certificados do Active Directory (AD CS) para registrar
automaticamente certificados em servidores de infraestrutura nps e acesso remoto. AD CS permite que você
crie uma PKI (infraestrutura de chave pública) e forneça criptografia de chave pública, certificados digitais e
funcionalidades de assinatura digital para sua organização.
Quando você usa certificados de servidor digital para autenticação entre computadores em sua rede, os
certificados fornecem:
1. Confidencialidade por meio da criptografia.
2. Integridade por meio de assinaturas digitais.
3. Autenticação associando chaves de certificado a contas de computador, usuário ou dispositivo em uma rede
de computador.
Tipos de servidores
Usando este guia, você pode implantar certificados de servidor nos seguintes tipos de servidores.
Servidores que executam o serviço de Acesso Remoto, que são servidores DirectAccess ou VPN (rede virtual
privada) padrão e que são membros do grupo de Servidores RAS e IAS.
Servidores que executam o serviço NPS (Servidor de Políticas de Rede) que são membros do grupo de
Ser vidores RAS e IAS.
Vantagens do registro automático de certificado
O registro automático de certificados de servidor, também chamado de registro automático, oferece as
seguintes vantagens.
A AC (autoridade de certificação) AD CS aplicativo registra automaticamente um certificado do servidor em
todos os seus servidores NPS e Acesso Remoto.
Todos os computadores no domínio recebem automaticamente seu certificado de autoridade de certificação,
que é instalado no armazenamento autoridades de certificação raiz confiáveis em cada computador membro
do domínio. Por isso, todos os computadores no domínio confiam nos certificados emitidos pela ac. Essa
confiança permite que os servidores de autenticação provem suas identidades entre si e se envolvam em
comunicações seguras.
Além de atualizar Política de Grupo, a reconfiguração manual de cada servidor não é necessária.
Cada certificado do servidor inclui a finalidade da Autenticação do Servidor e a finalidade da Autenticação do
Cliente em extensões de EKU (Uso Aprimorado de Chave).
Escalabilidade. Depois de implantar sua AC Enterprise raiz com este guia, você pode expandir sua PKI
(infraestrutura de chave pública) adicionando Enterprise AC subordinadas.
Capacidade de gerenciamento. Você pode gerenciar AD CS usando o console AD CS ou usando Windows
PowerShell e scripts.
Simplicidade. Especifique os servidores que registram certificados de servidor usando contas de grupo do
Active Directory e associação de grupo.
Quando você implanta certificados de servidor, os certificados são baseados em um modelo que você
configura com as instruções neste guia. Isso significa que você pode personalizar diferentes modelos de
certificado para tipos de servidor específicos ou pode usar o mesmo modelo para todos os certificados de
servidor que deseja emitir.
NOTE
O Windows Server 2016 De rede principal está disponível na biblioteca Windows Server 2016 técnica. Para obter
mais informações, consulte Guia de rede principal.
Você deve ler a seção de planejamento deste guia para garantir que esteja preparado para essa
implantação antes de executar a implantação.
Você deve executar as etapas neste guia na ordem em que elas são apresentadas. Não vá em frente e
implante sua AC sem executar as etapas que levam à implantação do servidor ou sua implantação
falhará.
Você deve estar preparado para implantar dois novos servidores em sua rede – um servidor no qual você
instalará o AD CS como uma AC raiz do Enterprise e um servidor no qual você instalará o Servidor Web
(IIS) para que sua AC possa publicar a CRL (lista de certificados revogados) no servidor Web.
NOTE
Você está preparado para atribuir um endereço IP estático aos servidores Web e AD CS que você implantar com este
guia, bem como nomear os computadores de acordo com as convenções de nomenur de sua organização. Além disso,
você deve unir os computadores ao seu domínio.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
NOTE
Na ilustração acima, vários servidores são representados: DC1, CA1, WEB1 e muitos servidores SDN. Este guia fornece
instruções para implantar e configurar o CA1 e o WEB1, e para configurar o DC1, que este guia pressupõe que você já
tenha instalado em sua rede. Se você ainda não tiver instalado seu domínio de Active Directory, poderá fazer isso usando
o Guia de rede principal para Windows Server 2016.
Para obter mais informações sobre cada item representado na ilustração acima, consulte o seguinte:
CA1
WEB1
DC1
NPS1
CA1 executando a função de servidor AD CS
nesse cenário, a autoridade de certificação raiz Enterprise (ca) também é uma ca emissora. A AC emite
certificados para computadores de servidor que têm as permissões de segurança corretas para registrar um
certificado. Os serviços de certificado Active Directory (AD CS) são instalados em CA1.
Para redes maiores ou em que as questões de segurança fornecem justificativa, você pode separar as funções da
CA raiz e da CA emissora e implantar CAs subordinadas que estão emitindo CAs.
nas implantações mais seguras, o Enterprise ac raiz é colocado offline e fisicamente protegido.
Arquivo de CAPolicy. inf
Antes de instalar o AD CS, você configura o arquivo CAPolicy. inf com configurações específicas para sua
implantação.
Cópia do modelo de certificado de Servidores RAS e ias
Ao implantar certificados de servidor, você faz uma cópia do modelo de certificado de Ser vidores RAS e ias e,
em seguida, configura o modelo de acordo com seus requisitos e as instruções neste guia.
Você utiliza uma cópia do modelo em vez do modelo original para que a configuração do modelo original seja
preservada para possível uso futuro. Você configura a cópia do modelo de Ser vidores RAS e ias para que a
autoridade de certificação possa criar certificados de servidor que ele emite para os grupos em Active Directory
usuários e computadores que você especificar.
Configuração de CA1 adicional
A CA publica uma CRL (lista de certificados revogados) que os computadores devem verificar para garantir que
os certificados apresentados a eles como prova de identidade sejam certificados válidos e não tenham sido
revogados. Você deve configurar sua autoridade de certificação com o local correto da CRL para que os
computadores saibam onde procurar a CRL durante o processo de autenticação.
WEB1 executando a função de servidor de serviços Web (IIS )
no computador que está executando a função de servidor do servidor Web (IIS), WEB1, você deve criar uma
pasta no Windows Explorer para uso como o local para a CRL e o AIA.
Diretório virtual para CRL e AIA
depois de criar uma pasta no Windows Explorer, você deve configurar a pasta como um diretório virtual no
gerenciador do Serviços de Informações da Internet (IIS), bem como configurar a lista de controle de acesso
para o diretório virtual para permitir que os computadores acessem o AIA e a CRL depois que eles forem
publicados lá.
DC1 executando as funções de servidor AD DS e DNS
DC1 é o controlador de domínio e o servidor DNS em sua rede.
Política de Grupo Diretiva de domínio padrão
Depois de configurar o modelo de certificado na autoridade de certificação, você pode configurar a política de
domínio padrão no Política de Grupo para que os certificados sejam registrados automaticamente nos
servidores NPS e RAS. O Política de Grupo está configurado em AD DS no servidor DC1.
Registro de recurso de alias DNS (CNAME)
Você deve criar um registro de recurso de alias (CNAME) para o servidor Web para garantir que outros
computadores possam encontrar o servidor, bem como o AIA e a CRL que estão armazenados no servidor. Além
disso, o uso de um registro de recurso CNAME de alias fornece flexibilidade para que você possa usar o servidor
Web para outras finalidades, como hospedar sites Web e FTP.
NPS1 executando o serviço de função do servidor de políticas de rede da diretiva de rede e da função de
servidor Serviços do Access
o NPS é instalado quando você executa as tarefas no guia de rede do Windows Server 2016 Core, portanto,
antes de executar as tarefas neste guia, você já deve ter um ou mais NPSs instalados em sua rede.
Política de Grupo aplicado e certificado registrado nos servidores
Depois de configurar o modelo de certificado e o registro automático, você pode atualizar Política de Grupo em
todos os servidores de destino. Neste momento, os servidores registram o certificado do servidor do CA1.
Visão geral do processo de implantação de certificado do servidor
NOTE
Os detalhes de como executar essas etapas são fornecidos na seção implantação de certificado do servidor.
NOTE
todos os computadores membros do domínio recebem automaticamente o certificado da autoridade de
certificação raiz Enterprise sem a configuração do registro automático. Esse certificado é diferente do certificado
do servidor que você configura e distribui usando o registro automático. O certificado da autoridade de
certificação é instalado automaticamente no repositório de certificados das autoridades de certificação raiz
confiáveis para todos os computadores membros do domínio para que eles confiem nos certificados emitidos por
essa autoridade de certificação.
11. Verifique se todos os servidores registraram um certificado de servidor válido.
Planejamento da implantação de certificado do
servidor
13/08/2021 • 6 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID=1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=https://pki.corp.contoso.com/pki/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=weeks
CRLPeriodUnits=1
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1
[BasicConstraintsExtension]
PathLength=0
Critical=Yes
IMPORTANT
Não é recomendável alterar qualquer outra configuração no arquivo CAPolicy. inf, a menos que você tenha um motivo
específico para fazer isso.
Por exemplo, se o seu servidor Web for denominado WEB1 e o registro CNAME do alias DNS para o servidor
Web for "PKI", seu domínio for corp.contoso.com e seu diretório virtual for chamado PKI, o local de CDP será:
https:\/\/1.800.gay:443\/http\/pki.corp.contoso.com\/pki\/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
Por exemplo, se o seu servidor Web for denominado WEB1 e o registro CNAME do alias DNS para o servidor
Web for "PKI", seu domínio for corp.contoso.com e seu diretório virtual for chamado PKI, o local AIA será:
https:\/\/1.800.gay:443\/http\/pki.corp.contoso.com\/pki\/<ServerDNSName>\_<CaName><CertificateName>.crt
NOTE
As três últimas seções de implantação deste guia, que permitem configurar o registro automático do certificado do
servidor, atualizar Política de Grupo em servidores e verificar se os servidores receberam um certificado de servidor válido
da CA-não exigem etapas de planejamento adicionais.
Implantação de certificados de servidor
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Siga estas etapas para instalar uma AC (autoridade de certificação) raiz corporativa e implantar certificados de
servidor para uso com PEAP e EAP.
IMPORTANT
Antes de instalar Serviços de Certificados do Active Directory, você deve nomear o computador, configurar o computador
com um endereço IP estático e ingressar o computador no domínio. Depois de instalar AD CS, não é possível alterar o
nome do computador ou a associação de domínio do computador, no entanto, você pode alterar o endereço IP, se
necessário. Para obter mais informações sobre como realizar essas tarefas, consulte o Guia de rede Windows Server ®
2016 Core.
NOTE
Os procedimentos deste guia não incluem instruções para os casos em que a caixa de diálogo Controle de Conta de
Usuário é aberta para solicitar sua permissão para continuar. Caso essa caixa de diálogo seja aberta durante a execução
dos procedimentos deste guia e em resposta às suas ações, clique em Continuar .
Instalar o servidor Web WEB1
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
A função servidor Web (IIS) no Windows Server 2016 fornece uma plataforma segura, fácil de gerenciar,
modular e extensível para hospedar sites, serviços e aplicativos de forma confiável. Com o IIS, você pode
compartilhar informações com usuários na Internet, em uma intranet ou em uma extranet. O IIS é uma
plataforma Web unificada que integra o IIS, ASP.NET, serviços FTP, PHP e Windows Communication Foundation
(WCF).
Quando você implanta certificados de servidor, seu servidor Web fornece um local em que você pode publicar a
CRL (lista de certificados revogados) para sua AC (autoridade de certificação). Após a publicação, a CRL fica
acessível a todos os computadores em sua rede para que eles possam usar essa lista durante o processo de
autenticação para verificar se os certificados apresentados por outros computadores não são revogados.
Se um certificado estiver na CRL como revogado, o esforço de autenticação falhará e seu computador será
protegido contra confiar em uma entidade que tenha um certificado que não seja mais válido.
Antes de instalar a função servidor Web (IIS), verifique se você configurou o nome do servidor e o endereço IP e
ingressou o computador no domínio.
NOTE
Para executar esse procedimento usando o Windows PowerShell, abra o PowerShell, digite o comando a seguir e pressione
ENTER. Install-WindowsFeature Web-Server -IncludeManagementTools
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para adicionar um ( registro de recurso CNAME ) de nome canônico de alias
para seu servidor Web a uma zona no DNS em seu controlador de domínio. Com os registros CNAME, você
pode usar mais de um nome para apontar para um único host, facilitando a realização de coisas como hospedar
um ( servidor FTP protocolo FTP ) e um servidor Web no mesmo computador.
Por isso, você é livre para usar o servidor Web para hospedar a CRL da lista de certificados revogados ( ) para
sua autoridade de certificação ( CA ) , bem como para executar serviços adicionais, como FTP ou servidor Web.
Ao executar esse procedimento, substitua o nome do alias e outras variáveis por valores que são apropriados
para sua implantação.
Para executar esse procedimento, você deve ser membro de Admins . do domínio.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para configurar o servidor Web WEB1 para distribuir CRLs.
Nas extensões da CA raiz, foi mencionado que a CRL da CA raiz estaria disponível via
https://pki.corp.contoso.com/pki . Atualmente, não há um diretório virtual PKI em WEB1, portanto, é necessário
criá-lo.
Para executar esse procedimento, você deve ser membro de Admins . do domínio.
NOTE
No procedimento abaixo, substitua o nome da conta de usuário, o nome do servidor Web, os nomes de pasta e os locais
e outros valores que são apropriados para sua implantação.
[Version] #section
Signature="$Windows NT$" #key=value
Versão
Identifica o arquivo como um arquivo .inf. A versão é a única seção necessária e deve estar no início do arquivo
CAPolicy.inf.
PolicyStatementExtension
Lista as políticas que foram definidas pela organização e se elas são opcionais ou obrigatórias. Várias políticas
são separadas por vírgulas. Os nomes têm significado no contexto de uma implantação específica ou em relação
a aplicativos personalizados que verificam a presença dessas políticas.
Para cada política definida, deve haver uma seção que defina as configurações para essa política específica. Para
cada política, você precisa fornecer um OID (identificador de objeto) definido pelo usuário e o texto que deseja
exibir como a instrução de política ou um ponteiro de URL para a instrução de política. A URL pode estar na
forma de uma URL HTTP, FTP ou LDAP.
Se você tiver um texto descritivo na instrução de política, as próximas três linhas do CAPolicy.inf terão a seguinte
aparência:
[InternalPolicy]
OID=1.1.1.1.1.1.1
Notice=”Legal policy statement text”
Se você for usar uma URL para hospedar a instrução de política de AC, as próximas três linhas serão como:
[InternalPolicy]
OID=1.1.1.1.1.1.2
URL=https://pki.wingtiptoys.com/policies/legalpolicy.asp
Além disso:
Há suporte para várias chaves de URL e Aviso.
Há suporte para chaves de AVISO e URL na mesma seção de política.
As URLs com espaços ou texto com espaços devem estar entre aspas. Isso é verdadeiro para a chave de
URL, independentemente da seção na qual ela aparece.
Um exemplo de vários avisos e URLs em uma seção de política seria como:
[InternalPolicy]
OID=1.1.1.1.1.1.1
URL=https://pki.wingtiptoys.com/policies/legalpolicy.asp
URL=ftp://ftp.wingtiptoys.com/pki/policies/legalpolicy.asp
Notice=”Legal policy statement text”
CRLDistributionPoint
Você pode especificar CDPs (Pontos de Distribuição de CRL) para um certificado de AC raiz no CAPolicy.inf.
Depois de instalar a AC, você pode configurar as URLs do CDP que a AC inclui em cada certificado emitido. O
certificado de AC raiz mostra as URLs especificadas nesta seção do arquivo CAPolicy.inf.
[CRLDistributionPoint]
URL=http://pki.wingtiptoys.com/cdp/WingtipToysRootCA.crl
IMPORTANT
Não dá suporte a URLs HTTPS.
As aspas devem cercar URLs com espaços.
Se nenhuma URLs for especificada , ou seja, se a seção [CRLDistributionPoint] existir no arquivo, mas
estiver vazia, a extensão do Ponto de Distribuição de CRL será omitida do certificado de AC raiz. Isso
geralmente é preferível ao configurar uma AC raiz. Windows não executa a verificação de revogação em
um certificado de AC raiz, portanto, a extensão CDP é supérflua em um certificado de AC raiz.
A AC pode publicar no ARQUIVO UNC, por exemplo, em um compartilhamento que representa a pasta
de um site em que um cliente recupera via HTTP.
Use esta seção somente se você estiver configurando uma AC raiz ou renovando o certificado de AC raiz.
A AC determina as extensões DE CDP subordinadas da AC.
AuthorityInformationAccess
Você pode especificar os pontos de acesso de informações de autoridade no CAPolicy.inf para o certificado de
autoridade de certificação raiz.
[AuthorityInformationAccess]
URL=http://pki.wingtiptoys.com/Public/myCA.crt
RenewalKeyLength define o tamanho da chave apenas para renovação. Isso só é usado quando um novo par
de chaves é gerado durante a renovação do certificado de AC. O tamanho da chave para o certificado de AC
inicial é definido quando a AC é instalada.
Ao renovar um certificado de AC com um novo par de chaves, o comprimento da chave pode ser aumentado ou
reduzido. Por exemplo, se você tiver definido um tamanho de chave de AC raiz de 4096 bytes ou superior e
descobrir que você tem aplicativos Java ou dispositivos de rede que só podem dar suporte a tamanhos de chave
de 2048 bytes. Se você aumentar ou diminuir o tamanho, deverá emitir todos os certificados emitidos por essa
AC.
RenewalValidityPeriod e RenewalValidityPeriodUnits estabelecem o tempo de vida do novo certificado de
AC raiz ao renovar o certificado de AC raiz antigo. Ela se aplica somente a uma AC raiz. O tempo de vida do
certificado de uma AC subordinada é determinado por seu superior. RenewalValidityPeriod pode ter os
seguintes valores: Horas, Dias, Semanas, Meses e Anos.
CRLPeriod e CRLPeriodUnits estabelecem o período de validade para a CRL base. CRLPeriod pode ter os
seguintes valores: Horas, Dias, Semanas, Meses e Anos.
CRLDeltaPeriod e CRLDeltaPeriodUnits estabelecem o período de validade da CRL delta. CRLDeltaPeriod
pode ter os seguintes valores: Horas, Dias, Semanas, Meses e Anos.
Cada uma dessas configurações pode ser configurada após a instalação da AC:
Lembre-se de Serviços de Certificados do Active Directory para que as alterações entre em vigor.
LoadDefaultTemplates só se aplica durante a instalação de uma AC Enterprise aplicativo. Essa configuração,
True ou False (ou 1 ou 0), determina se a AC está configurada com qualquer um dos modelos padrão.
Em uma instalação padrão da AC, um subconjunto dos modelos de certificado padrão é adicionado à pasta
Modelos de Certificado no snap-in autoridade de certificação. Isso significa que, assim que o serviço AD CS for
iniciado depois que a função tiver sido instalada, um usuário ou computador com permissões suficientes poderá
se registrar imediatamente para um certificado.
Talvez você não queira emitir nenhum certificado imediatamente após a instalação de uma AC, portanto, você
pode usar a configuração LoadDefaultTemplates para impedir que os modelos padrão são adicionados à AC
Enterprise. Se não houver modelos configurados na AC, ele não poderá emitir nenhum certificado.
AlternateSignatureAlgorithm configura a AC para dar suporte ao formato de assinatura PKCS 1 V2.1 para o
certificado de AC e solicitações # de certificado. Quando definido como 1 em uma AC raiz, o certificado de AC
incluirá o formato de assinatura PKCS # 1 V2.1. Quando definido em uma AC subordinada, a autoridade de
certificação subordinada criará uma solicitação de certificado que inclui o # formato de assinatura PKCS 1 v 2.1.
ForceUTF8 altera a codificação padrão de nomes diferenciados relativos (RDNS) em nomes diferenciados de
assunto e emissor para UTF-8. Somente os RDNs que dão suporte a UTF-8, como os que são definidos como
tipos de cadeia de caracteres de diretório por uma RFC, são afetados. Por exemplo, o RDN para o controlador de
domínio (DC) dá suporte à codificação como IA5 ou UTF-8, enquanto o RDN de país (C) dá suporte apenas à
codificação como uma cadeia de caracteres imprimível. Portanto, a diretiva ForceUTF8 afetará um RDN DC, mas
não afetará um RDN C.
EnableKeyCounting configura a autoridade de certificação para incrementar um contador sempre que a chave
de assinatura da autoridade de certificação é usada. Não habilite essa configuração a menos que você tenha um
HSM (módulo de segurança de hardware) e um CSP (provedor de serviços de criptografia) associado que
ofereça suporte à contagem de chaves. nem o CSP forte da microsoft nem o KSP (microsoft Software Key
Armazenamento Provider) oferece suporte à contagem de chaves.
[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID=1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=https://pki.corp.contoso.com/pki/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=weeks
CRLPeriodUnits=1
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1
[CRLDistributionPoint]
[AuthorityInformationAccess]
Cau t i on
Verifique se você salvou o CAPolicy.inf com a extensão inf. Se você não digitar .inf especificamente no
final do nome de arquivo e selecionar as opções conforme descrito, o arquivo será salvo como um
arquivo de texto e não será usado durante a instalação da AC.
9. Feche o Bloco de notas.
IMPORTANT
No arquivo CAPolicy. inf, você pode ver que há uma linha especificando a URL https://pki.corp.contoso.com/pki/cps.txt . A
seção Política Interna do CAPolicy.inf é mostrada apenas como um exemplo de como você poderia especificar o local de
uma CPS (declaração de prática de certificação). Neste guia, você não é instruído a criar a declaração de prática de
certificado (CPS).
Instalar a autoridade de certificação
13/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para instalar o Serviços de Certificados do Active Directory (AD CS) para que
você possa registrar um certificado do servidor em servidores que executam o NPS (Servidor de Políticas de
Rede), RRAS (Serviço de Roteamento e Acesso Remoto) ou ambos.
IMPORTANT
Antes de instalar Serviços de Certificados do Active Directory, você deve nomear o computador, configurar o
computador com um endereço IP estático e ingressar o computador no domínio. Para obter mais informações sobre
como realizar essas tarefas, consulte o Windows Server 2016 Core Network Guide.
Para executar este procedimento, o computador no qual você está instalando o AD CS deve estar associado a um
domínio no qual o AD DS (Serviços de Domínio Active Directory) esteja instalado.
A associação aos grupos Administradores de Empresa e Admins. do Domínio do domínio raiz é o mínimo
exigido para executar este procedimento.
NOTE
Para executar esse procedimento usando Windows PowerShell, abra Windows PowerShell digite o comando a seguir e
pressione ENTER.
Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
TIP
Se você quiser usar o Windows PowerShell para instalar Serviços de Certificados do Active Directory, consulte Install-
AdcsCertificationAuthority para cmdlets e parâmetros opcionais.
1. Faça logon como membro do grupo Administradores de Empresa e do grupo Admins. do Domínio do
domínio raiz.
2. No Gerenciador do Servidor, clique em Gerenciar e depois em Adicionar Funções e Recursos . O
Assistente para Adicionar Funções e Recursos é aberto.
3. Em Antes de Começar , clique em Avançar .
NOTE
A página Antes de Começar do Assistente para Adicionar Funções e Recursos não é exibida quando você marca
a opção Ignorar esta página por padrão quando o Assistente para Funções e Recursos foi executado.
4. Em Selecionar Tipo de Instalação , verifique se Instalação baseada em função ou recurso está
marcada e clique em Avançar .
5. Em Selecionar ser vidor de destino , verifique se Selecionar um ser vidor no pool de ser vidores
está marcada. Em Pool de Ser vidores , verifique se o computador local está selecionado. Clique em
Próximo .
6. Em Selecionar Funções de Ser vidor , em Funções , selecione Ser viços de Cer tificados do Active
Director y . Quando você for solicitado a adicionar os recursos necessários, clique em Adicionar
Recursos e, em seguida, clique em Próximo.
7. Em Selecionar recursos, clique em Próximo.
8. No Ser viços de Cer tificados do Active Director y , leia as informações fornecidas e clique em
Próximo.
9. Em Confirmar seleções de instalação , clique em Instalar . Não feche o assistente durante o processo
de instalação. Quando a instalação for concluída, clique em Configurar Ser viços de Cer tificados do
Active Director y no ser vidor de destino . O assistente AD CS configuração do aplicativo é aberto.
Leia as informações de credenciais e, se necessário, forneça as credenciais para uma conta que seja
membro do grupo Enterprise Administradores. Clique em Próximo .
10. Em Ser viços de Função, clique em Autoridade de Cer tificação e clique em Próximo.
11. Na página Tipo de Instalação, verifique se Enterprise CA está selecionada e clique em Próximo.
12. Na página Especificar o tipo da AC, verifique se a AC raiz está selecionada e clique em Próximo.
13. Na página Especificar o tipo da chave privada, verifique se a opção Criar uma nova chave privada
está selecionada e clique em Próximo.
14. Na página Criptografia para AC, mantenha as configurações padrão para CSP (RSA#Microsoft
Software Key Armazenamento Provider ) e algoritmo de hash (SHA2 ) e determine o melhor
comprimento de caracteres de chave para sua implantação. Comprimentos grandes de caracteres de
chave fornecem segurança ideal; No entanto, eles podem afetar o desempenho do servidor e podem não
ser compatíveis com aplicativos herdados. É recomendável que você mantenha a configuração padrão de
2048. Clique em Próximo .
15. Na página Nome da AC, mantenha o nome comum sugerido para a AC ou altere o nome de acordo com
suas necessidades. Verifique se você tem certeza de que o nome da AC é compatível com suas
convenções e finalidades de nomen por não poder alterar o nome da AC depois de instalar o AD CS.
Clique em Próximo .
16. Na página Período de Validade, em Especificar o período de validade , digite o número e selecione um
valor de tempo (Anos, Meses, Semanas ou Dias). A configuração padrão de cinco anos é recomendada.
Clique em Próximo .
17. Na página Banco de Dados da AC, em Especificar os locais do banco de dados , especifique o local
da pasta para o banco de dados de certificado e o log do banco de dados de certificado. Se você
especificar localizações diferentes do padrão, verifique se as pastas estão protegidas com ACLs (listas de
controle de acesso) que impedem que usuários ou computadores não autorizados acessem os arquivos
de log e o banco de dados da autoridade de certificação. Clique em Próximo .
18. Em Confirmação , clique em Configurar para aplicar suas seleções e clique em Fechar .
Configurar as extensões CDP e AIA em CA1
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para definir as configurações de CDP (Ponto de Distribuição da CRL) e AIA
(Acesso às Informações da Autoridade) na CA1.
Para executar esse procedimento, você deve ser um membro de Administradores de Domínio.
Para configurar as extensões CDP e AIA na CA1
1. No Gerenciador do Servidor, clique em Ferramentas e depois em Autoridade de Cer tificação .
2. Na árvore de console da Autoridade de Certificação, clique com o botão direito do mouse em corp-
CA1-CA e clique em Propriedades .
NOTE
O nome da ac é diferente se você não nomeou o computador CA1 e seu nome de domínio é diferente do deste
exemplo. O nome da AC está no formato domínio - CAComputerName-CA.
3. Clique na guia Extensões. Verifique se Selecionar extensão está definida como CDP (Ponto de
Distribuição de CRL) e, em Especificar locais dos quais os usuários podem obter uma CRL (lista de
certificados revogados), faça o seguinte:
a. Selecione a entrada
file://\\<ServerDNSName>\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl e clique em
Remover . Em Confirmar remoção, clique em Sim.
b. Selecione a entrada
http://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl e clique em
Remover . Em Confirmar remoção, clique em Sim.
c. Selecione a entrada que começa com o caminho
ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName> e clique em Remover . Em
Confirmar remoção, clique em Sim.
4. Em Especificar locais dos quais os usuários podem obter uma CRL (lista de cer tificados revogados),
clique em Adicionar . A caixa de diálogo Adicionar Local é aberta.
5. Em Adicionar Local , em Local , digite e clique em
http://pki.corp.contoso.com/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl OK. Isso retorna você
para a caixa de diálogo Propriedades da AC.
6. Na guia Extensões, marque as seguintes caixas de seleção:
Incluir em CRLs. Os clientes usam isso para encontrar os locais de CRL Delta
Incluir na extensão CDP de cer tificados emitidos
7. Em Especificar locais dos quais os usuários podem obter uma CRL (lista de cer tificados revogados),
clique em Adicionar . A caixa de diálogo Adicionar Local é aberta.
8. Em Adicionar Local , em Local , digite e clique em
file://\\pki.corp.contoso.com\pki\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl OK. Isso retorna você
para a caixa de diálogo Propriedades da AC.
9. Na guia Extensões, marque as seguintes caixas de seleção:
Publicar CRLs neste local
Publicar CRLs Delta nesse local
10. Alterar Selecione extensão para AIA (Acesso de Informações da Autoridade) e, em Especificar locais
dos quais os usuários podem obter uma CRL (lista de certificados revogados), faça o seguinte:
a. Selecione a entrada que começa com o caminho
ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services e clique em Remover . Em
Confirmar remoção, clique em Sim.
b. Selecione a entrada
http://<ServerDNSName>/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt e clique em
Remover . Em Confirmar remoção, clique em Sim.
c. Selecione a entrada
file://\\<ServerDNSName>\CertEnroll\<ServerDNSName><CaName><CertificateName>.crt e clique em
Remover . Em Confirmar remoção, clique em Sim.
11. Em Especificar locais dos quais os usuários podem obter o cer tificado para essa AC, clique em
Adicionar . A caixa de diálogo Adicionar Local é aberta.
12. Em Adicionar Local , em Local , digite e clique em
http://pki.corp.contoso.com/pki/<ServerDNSName>_<CaName><CertificateName>.crt OK. Isso retorna você
para a caixa de diálogo Propriedades da AC.
13. Na guia Extensões, selecione Incluir no AIA de cer tificados emitidos.
14. Quando for solicitado que você reinicie Serviços de Certificados do Active Directory, clique em Não .
Você reiniciará o serviço mais tarde.
Copiar o certificado de autoridade de certificação e
a CRL para o diretório virtual
11/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este procedimento para copiar a lista de certificados revogados e Enterprise certificado de
autoridade de certificação raiz de sua autoridade de certificado para um diretório virtual no servidor Web e
para garantir que o AD CS esteja configurado corretamente. Antes de executar os comandos a seguir, certifique-
se de substituir os nomes de diretório e servidor pelos que são apropriados para sua implantação.
Para executar este procedimento, você deve ser membro de Admins . do domínio.
Para copiar a lista de certificados revogados de CA1 para WEB1
1. no CA1, execute Windows PowerShell como administrador e, em seguida, publique a CRL com o seguinte
comando:
Digite certutil -crl e pressione ENTER.
Para copiar o certificado CA1 para o compartilhamento de arquivos no seu servidor Web, digite
copy C:\Windows\system32\certsrv\certenroll\*.crt \\WEB1\pki e pressione Enter.
TIP
Se o status de qualquer item não estiver OK , faça o seguinte:
Abra o compartilhamento no servidor Web para verificar se os arquivos de lista de revogação de certificado e
certificado foram copiados com êxito para o compartilhamento. Se eles não foram copiados com êxito para o
compartilhamento, modifique os comandos de cópia com a fonte de arquivo correta e o destino de compartilhamento
e execute os comandos novamente.
Verifique se você inseriu os locais corretos para CDP e AIA na guia extensões de CA. Verifique se não há espaços extras
ou outros caracteres nos locais que você forneceu.
Verifique se você copiou a CRL e o certificado de autoridade de certificação para o local correto no servidor Web e se o
local corresponde ao local fornecido para os locais de CDP e AIA na autoridade de certificação.
Verifique se você configurou corretamente as permissões para a pasta virtual na qual o certificado de autoridade de
certificação e a CRL estão armazenados.
Configurar o modelo de certificado do servidor
11/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para configurar o modelo de certificado que Active Directory ® serviços de
certificados (AD CS) usa como base para certificados de servidor registrados em servidores na sua rede.
Ao configurar esse modelo, você pode especificar os servidores por Active Directory grupo que deve receber
automaticamente um certificado de servidor do AD CS.
O procedimento a seguir inclui instruções para configurar o modelo para emitir certificados para todos os
seguintes tipos de servidor:
Servidores que executam o serviço de acesso remoto, incluindo servidores de gateway de RAS, que são
membros do grupo de Ser vidores RAS e ias .
Servidores que executam o serviço de servidor de diretivas de rede (NPS) que são membros do grupo de
Ser vidores RAS e ias .
A associação aos grupos Administradores de Empresa e Admins. do Domínio do domínio raiz é o mínimo
exigido para executar este procedimento.
Para configurar o modelo de certificado
1. Em CA1, em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em autoridade de
cer tificação . O MMC (console de gerenciamento Microsoft) da autoridade de certificação é aberto.
2. No MMC, clique duas vezes no nome da autoridade de certificação, clique com o botão direito do mouse
em modelos de cer tificado e clique em gerenciar .
3. O console modelos de certificado é aberto. Todos os modelos de certificado são exibidos no painel de
detalhes.
4. No painel de detalhes, clique no modelo de ser vidor RAS e ias .
5. Clique no menu ação e, em seguida, clique em duplicar modelo . A caixa de diálogo Propriedades do
modelo é aberta.
6. Clique na guia Segurança .
7. Na guia segurança , em nomes de grupo ou de usuário , clique em Ser vidores RAS e ias .
8. Em permissões para ser vidores RAS e ias , em permitir , verifique se o registro está selecionado e
marque a caixa de seleção registro automático . Clique em OK e feche o MMC modelos de certificado.
9. No MMC da autoridade de certificação, clique em modelos de cer tificado . No menu ação , aponte
para novo e clique em modelo de cer tificado a ser emitido . A caixa de diálogo Ativar Modelos de
Cer tificado é aberta.
10. Em habilitar modelos de cer tificado , clique no nome do modelo de certificado que você acabou de
configurar e, em seguida, clique em OK . Por exemplo, se você não alterou o nome do modelo de
certificado padrão, clique em cópia do ser vidor RAS e ias e, em seguida, clique em OK .
Configurar o registro automático do certificado
12/08/2021 • 3 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
NOTE
Antes de executar este procedimento, você deve configurar um modelo de certificado de servidor usando o snap-in
Console de Gerenciamento Microsoft para Modelos de Certificado em uma autoridade de certificação que execute AD CS.
A associação aos grupos Administradores de Empresa e Admins. do Domínio do domínio raiz é o mínimo exigido
para executar este procedimento.
IMPORTANT
Certifique-se de selecionar Editor de gerenciamento de política de grupo e não política de grupo
Gerenciamento . Se você selecionar política de grupo Gerenciamento , sua configuração usando essas
instruções falhará e um certificado do servidor não será registrado automaticamente em seu NPSs.
IMPORTANT
Certifique-se de selecionar Editor de gerenciamento de política de grupo e não política de grupo
Gerenciamento . Se você selecionar política de grupo Gerenciamento , sua configuração usando essas
instruções falhará e um certificado do servidor não será registrado automaticamente em seu NPSs.
Próximas etapas
Atualizar Política de Grupo
Atualizar Diretiva de Grupo
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para atualizar manualmente a Diretiva de Grupo no computador local.
Quando a Diretiva de Grupo é atualizada, se o registro automático de certificados estiver configurado e
funcionando corretamente, o computador local terá o registro automático de um certificado pela autoridade de
certificação (CA).
NOTE
A Diretiva de Grupo é atualizada automaticamente quando você reinicia ou um usuário faz logon em um computador
membro do domínio. Além disso, a Diretiva de Grupo é atualizada periodicamente. Por padrão, essa atualização periódica
é realizada a cada 90 minutos com uma diferença de horário aleatória de até 30 minutos.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para verificar se os servidores do servidor de diretivas de rede (NPS)
registraram um certificado de servidor da autoridade de certificação (CA).
NOTE
A associação no grupo Admins . do domínio é o mínimo necessário para concluir esses procedimentos.
IMPORTANT
Se o NPS não exibir um certificado de servidor válido e se ele fornecer a mensagem de que esse certificado não
pode ser encontrado no computador local, haverá duas razões possíveis para esse problema. É possível que
Política de Grupo não tenha sido atualizada corretamente, e o NPS não registrou um certificado da autoridade de
certificação. Nessa circunstância, reinicie o NPS. Quando o computador for reiniciado, Política de Grupo será
atualizado e você poderá executar esse procedimento novamente para verificar se o certificado do servidor está
registrado. Se a atualização Política de Grupo não resolver esse problema, o modelo de certificado, o registro
automático de certificado ou ambos não estão configurados corretamente. Para resolver esses problemas, comece
no início deste guia e execute todas as etapas novamente para garantir que as configurações fornecidas sejam
precisas.
NOTE
Como você não está concluindo o assistente, a política de rede de teste não é criada no NPS.
Implantar o - acesso sem fio autenticado 802.1 x
baseado em senha
11/08/2021 • 25 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
este é um guia complementar para o guia de rede do Windows Server ® 2016 Core. O guia de rede principal
fornece instruções para planejar e implantar os componentes necessários para uma rede totalmente funcional e
um novo Active Directory® domínio em uma nova floresta.
Este guia explica como criar uma rede principal fornecendo instruções sobre como implantar o Instituto de
engenheiros elétricos e eletrônicos do ( IEEE ) 802.1 x - acesso sem fio autenticado IEEE 802,11 usando
protocolo de autenticação extensível protegida – protocolo de autenticação de handshake de desafio da
Microsoft versão 2 ( PEAP - MS - CHAP v2 ) .
Como - o PEAP MS - CHAP v2 requer que os usuários forneçam - credenciais baseadas em senha em vez de um
certificado durante o processo de autenticação, normalmente é mais fácil e menos dispendioso implantar do
que EAP - TLS ou PEAP - TLS.
NOTE
Neste guia, o acesso sem fio autenticado IEEE 802.1 X com PEAP - MS - CHAP v2 é abreviado como "acesso sem fio" e
"acesso WiFi".
os administradores de rede e de sistema que implantam o sem fio autenticado devem seguir as instruções no
guia complementar de rede Windows Server 2016 Core, implantar cer tificados de ser vidor para
implantações 802.1 x com e sem fio . Este guia explica como implantar e usar o AD CS para registrar
automaticamente certificados de servidor em computadores que executam o NPS.
Este guia está disponível no local a seguir.
o guia complementar de rede do Windows Server 2016 Core implanta certificados de servidor para
implantações com e sem fio 802.1 x em formato HTML na biblioteca técnica.
CA Pública
Você pode comprar certificados de servidor de uma CA pública, como a VeriSign, que os computadores cliente
já confiam.
Um computador cliente confia em uma AC quando o certificado de autoridade de certificação é instalado no
repositório de certificados de autoridades de certificação raiz confiáveis. por padrão, os computadores que
executam o Windows têm vários certificados de ac pública instalados em seu repositório de certificados de
autoridades de certificação raiz confiáveis.
É recomendável que você examine os guias de design e implantação de cada uma das tecnologias usadas neste
cenário de implantação. Esses guias podem ajudar a determinar se o cenário de implantação fornece os serviços
e as configurações que você precisa para a rede de sua organização.
Requisitos
A seguir estão os requisitos para implantar uma infraestrutura de acesso sem fio usando o cenário
documentado neste guia:
Antes de implantar esse cenário, primeiro você deve adquirir pontos de - acesso sem fio compatíveis com
802.1 x para fornecer cobertura sem fio nos locais desejados no seu site. A seção de planejamento deste
guia ajuda a determinar os recursos aos quais seu APs deve dar suporte.
Active Directory Domain Services ( AD DS ) está instalado, assim como as outras tecnologias de rede
necessárias, de acordo com as instruções no guia de rede do Windows Server 2016 Core.
O AD CS é implantado e os certificados de servidor são registrados no NPSs. Esses certificados são
necessários quando você implanta o - método de - autenticação baseado em certificado do MS CHAP v2
de PEAP - que é usado neste guia.
Um membro da sua organização está familiarizado com os padrões IEEE 802,11 que são suportados por
seus APs sem fio e os adaptadores de rede sem fio instalados nos computadores cliente e dispositivos na
sua rede. Por exemplo, alguém em sua organização está familiarizado com tipos de frequência de rádio,
802,11 autenticação sem fio ( WPA2 ou WPA ) e codificações ( AES ou TKIP ) .
O que este guia não contém
A seguir estão alguns itens que este guia não fornece:
Diretrizes abrangentes para selecionar - pontos de acesso sem fio compatíveis com 802.1 x
Como existem muitas diferenças entre marcas e modelos de - APS sem fio compatíveis com 802.1 x, este guia
não fornece informações detalhadas sobre:
Determinar qual marca ou modelo de AP sem fio é mais adequada para suas necessidades.
A implantação física de APs sem fio em sua rede.
Configuração avançada de AP sem fio, como para VLANs de redes locais virtuais sem fio ( ) .
Instruções sobre como configurar - atributos específicos de fornecedor de AP sem fio no NPS.
Além disso, a terminologia e os nomes das configurações variam entre marcas e modelos de AP sem fio e
podem não corresponder aos nomes de configuração genérica que são usados neste guia. Para obter detalhes
de configuração de AP sem fio, você deve examinar a documentação do produto fornecida pelo fabricante de
seus APs sem fio.
Instruções para implantar certificados do NPS
Há duas alternativas para a implantação de certificados NPS. Este guia não fornece diretrizes abrangentes para
ajudá-lo a determinar qual alternativa atenderá melhor às suas necessidades. Em geral, no entanto, as opções
que você enfrenta são:
comprar certificados de uma CA pública, como a VeriSign, que já são confiáveis por - clientes baseados
em Windows. Essa opção geralmente é recomendada para redes menores.
Implantar uma PKI de infraestrutura de chave pública ( ) em sua rede usando o AD CS. Isso é
recomendado para a maioria das redes, e as instruções sobre como implantar certificados de servidor
com o AD CS estão disponíveis no guia de implantação mencionado anteriormente.
Políticas de rede do NPS e outras configurações de NPS
Exceto para as definições de configuração feitas quando você executa o assistente para Configurar 802.1 x ,
conforme documentado neste guia, este guia não fornece informações detalhadas para configurar
manualmente as condições do NPS, as restrições ou outras configurações de NPS.
DHCP
Este guia de implantação não fornece informações sobre como projetar ou implantar sub-redes DHCP para
LANs sem fio.
NOTE
você também pode usar computadores que executam o Windows Server 2016, o Windows Server 2012 R2 e o Windows
Server 2012 como clientes sem fio.
TA XA S DE T RA N SM ISSÃ O
PA DRÕ ES F REQ UÊN C IA S DE B IT S USO
802,11n \2.4 e 5,0 GHz ISM da Banda C - - e da 250 Mbps Dispositivos baseados no -
Banda S padrão IEEE 802.11n pré-
2007 foram disponibilizados
em agosto de 2007. Muitos
dispositivos de 802,11n são
compatíveis com
dispositivos 802.11a, b e g.
NOTE
Ao configurar políticas de rede sem fio, você deve selecionar WPA2 - Enterprise , WPA - Enterprise ou Abrir com
802.1X para obter acesso às configurações de EAP necessárias para implantações sem fio autenticadas 802.1X.
IMPORTANT
A WEP de Privacidade de Equivalência com Fio era o padrão de segurança sem fio ( ) original usado para criptografar o
tráfego de rede. Você não deve implantar o WEP em sua rede porque há - vulnerabilidades conhecidas nessa forma de
segurança desatualizada.
O PEAP de EAP protegido usa TLS para criar um canal criptografado entre um cliente PEAP de autenticação,
como um computador sem fio, e um autenticador PEAP, como um NPS ou outros servidores ( ) RADIUS. O PEAP
não especifica um método de autenticação, mas fornece segurança adicional para outros protocolos de
autenticação ( EAP, como eAP MS CHAP v2, que podem operar por meio do canal - criptografado TLS fornecido
pelo - ) PEAP. O PEAP é usado como um método de autenticação para acessar clientes que estão se conectando à
rede da sua organização por meio dos seguintes tipos de NASS de servidores de ( acesso à ) rede:
Pontos de acesso sem fio com capacidade para 802,1X -
Comutadores de autenticação com capacidade para 802.1X -
Computadores que Windows Server 2016 e o RAS do Serviço de Acesso Remoto configurados como
servidores VPN de rede virtual privada, servidores ( ) ( ) DirectAccess ou ambos
Computadores que executam Windows Server 2016 e Serviços de Área de Trabalho Remota
O PEAP MS CHAP v2 é mais fácil de implantar do que o TLS do EAP porque a autenticação de usuário é
executada usando o nome de usuário e a senha de credenciais baseadas em senha, em vez de certificados ou - -
cartões - - ( ) inteligentes. Somente NPS ou outros servidores RADIUS devem ter um certificado. O certificado
NPS é usado pelo NPS durante o processo de autenticação para provar sua identidade para clientes PEAP.
Este guia fornece instruções para configurar seus clientes sem fio e seus NPS s para usar o PEAP MS CHAP v2
para acesso ( ) - - autenticado 802.1X.
Servidor de Políticas de Rede
O NPS do Servidor de Políticas de Rede permite que você configure e gerencie centralmente políticas de rede
usando o servidor RADIUS do Serviço de Usuário discado na Autenticação Remota e o ( ) proxy - ( ) RADIUS. O
NPS é necessário quando você implanta o acesso sem fio 802.1X.
Quando você configura seus pontos de acesso sem fio 802.1X como clientes RADIUS no NPS, o NPS processa as
solicitações de conexão enviadas pelos APs. Durante o processamento da solicitação de conexão, o NPS executa
autenticação e autorização. A autenticação determina se o cliente apresentou credenciais válidas. Se o NPS
autenticar com êxito o cliente solicitante, o NPS determinará se o cliente está autorizado a fazer a conexão
solicitada e permitirá ou negará a conexão. Isso é explicado mais detalhadamente da seguinte forma:
Autenticação
A autenticação PEAP - MS - CHAP v2 bem-sucedida tem duas partes principais:
1. O cliente autentica o NPS. Durante essa fase de autenticação mútua, o NPS envia seu certificado do
servidor para o computador cliente para que o cliente possa verificar a identidade do NPS com o
certificado. Para autenticar com êxito o NPS, o computador cliente deve confiar na AC que emitiu o
certificado NPS. O cliente confia nessa AC quando o certificado da AC está presente no armazenamento
de certificados autoridades de certificação raiz confiáveis no computador cliente.
Se você implantar sua própria AC privada, o certificado de autoridade de certificação será instalado
automaticamente no armazenamento de certificados de Autoridades de Certificação Confiáveis para o
Usuário Atual e para o Computador Local quando Política de Grupo for atualizado no computador cliente
membro do domínio. Se você decidir implantar certificados de servidor de uma AC pública, verifique se o
certificado de autoridade de certificação pública já está no armazenamento de certificados autoridades
de certificação confiáveis.
2. O NPS autentica o usuário. Depois que o cliente autentica com êxito o NPS, o cliente envia as credenciais
baseadas em senha do usuário para o NPS, que verifica as credenciais do usuário no banco de dados de
contas de usuário no - Active Directory Domain Services ( AD DS ) .
Se as credenciais são válidas e a autenticação é bem-sucedida, o NPS inicia a fase de autorização do
processamento da solicitação de conexão. Se as credenciais não são válidas e a autenticação falha, o NPS envia
uma mensagem de Rejeição de Acesso e a solicitação de conexão é negada.
Autorização
O servidor que executa o NPS executa a autorização da seguinte forma:
1. O NPS verifica se há restrições na conta de usuário ou computador - discadas nas propriedades AD DS.
Cada conta de usuário e computador Usuários e Computadores do Active Directory inclui várias
propriedades, incluindo as encontradas na guia - Discar. Nessa guia, em Permissão de Acesso à Rede
, se o valor for Permitir acesso, o usuário ou o computador está autorizado a se conectar à rede. Se o
valor for Negar acesso , o usuário ou o computador não está autorizado a se conectar à rede. Se o valor
for Controlar o acesso por meio da Política de Rede NPS, o NPS avaliará as políticas de rede
configuradas para determinar se o usuário ou o computador está autorizado a se conectar à rede.
2. O NPS processa suas políticas de rede para encontrar uma política que corresponde à solicitação de
conexão. Se uma política de correspondência for encontrada, o NPS concederá ou negará a conexão com
base na configuração dessa política.
Se a autenticação e a autorização são bem-sucedidas e se a política de rede correspondente concede acesso, o
NPS concede acesso à rede e o usuário e o computador podem se conectar aos recursos de rede para os quais
eles têm permissões.
NOTE
Para implantar o acesso sem fio, você deve configurar políticas NPS. Este guia fornece instruções para usar o assistente
Configurar 802.1X no NPS para criar políticas NPS para acesso sem fio autenticado 802.1X.
Perfis de inicialização
Em redes sem fio autenticadas 802.1X, os clientes sem fio devem fornecer credenciais de segurança
autenticadas por um servidor RADIUS para se conectar - à rede. Para o Protocolo de Autenticação de Handshake
do EAP PEAP Protegido da Microsoft versão [ ] - 2 [ MS - CHAP v2 , as credenciais de ] segurança são um nome
de usuário e uma senha. Para TLS de Segurança de Camada de Transporte de EAP ou - [ ] TLS PEAP, as
credenciais de segurança são certificados, como certificados de usuário cliente e computador ou - cartões
inteligentes.
Ao se conectar a uma rede configurada para executar a autenticação PEAP - MS - CHAP v2, PEAP - TLS ou EAP
TLS, por padrão, os clientes sem fio do Windows também devem validar um certificado de computador enviado
pelo servidor - RADIUS. O certificado do computador enviado pelo servidor RADIUS para cada sessão de
autenticação é normalmente chamado de certificado do servidor.
Conforme mencionado anteriormente, você pode emitir o certificado do servidor de seus servidores RADIUS de
uma das duas maneiras: de uma AC comercial como ( VeriSign, Inc., ou de uma AC privada implantada em sua )
rede. Se o servidor RADIUS enviar um certificado de computador emitido por uma AC comercial que já tenha
um certificado raiz instalado no armazenamento de certificados de Autoridades de Certificação Confiáveis do
cliente, o cliente sem fio poderá validar o certificado do computador do servidor RADIUS, independentemente
de o cliente sem fio ter ingressado no domínio do Active Directory. Nesse caso, o cliente sem fio pode se
conectar à rede sem fio e, em seguida, você pode ingressar o computador no domínio.
NOTE
O comportamento que exige que o cliente valide o certificado do servidor pode ser desabilitado, mas desabilitar a
validação de certificado do servidor não é recomendado em ambientes de produção.
Perfis de inicialização sem fio são perfis temporários configurados de forma a permitir que os usuários cliente
sem fio se conectem à rede sem fio autenticada 802.1X antes que o computador seja ingressado no domínio e
ou antes que o usuário tenha feito logon com êxito no domínio usando um determinado computador sem fio - /
pela primeira vez. Esta seção resume qual problema é encontrado ao tentar ingressar um computador sem fio
no domínio ou para que um usuário use um computador sem fio ingressado no domínio pela primeira vez para
fazer logoff - no domínio.
Para implantações nas quais o usuário ou administrador de TI não pode conectar fisicamente um computador à
rede Ethernet com fio para ingressar o computador no domínio e o computador não tem o certificado de
AUTORIDADE de Certificação raiz de emissão necessário instalado em seu armazenamento de certificados
autoridades de certificação raiz confiáveis, você pode configurar clientes sem fio com um perfil de conexão sem
fio temporário, chamado perfil de inicialização, para se conectar à rede sem fio.
Um perfil de inicialização remove o requisito para validar o certificado do computador do servidor RADIUS. Essa
configuração temporária permite ao usuário sem fio ingressar o computador no domínio, momento em que as
Políticas ( IEEE 802.11 de Rede Sem Fio são aplicadas e o certificado de AC raiz apropriado é instalado
automaticamente no ) computador.
Quando Política de Grupo é aplicado, um ou mais perfis de conexão sem fio que impõem o requisito de
autenticação mútua são aplicados no computador; o perfil de inicialização não é mais necessário e é removido.
Depois de ingressar o computador no domínio e reiniciar o computador, o usuário pode usar uma conexão sem
fio para fazer logoff no domínio.
Para ter uma visão geral do processo de implantação de acesso sem fio usando essas tecnologias, consulte
Visão geral da implantação de acesso sem fio.
Visão geral da implantação de acesso sem fio
11/08/2021 • 5 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
A ilustração a seguir mostra os componentes necessários para implantar o acesso sem fio autenticado 802.1 X
com o PEAP - MS - CHAP v2.
TIP
Ao configurar uma nova política de rede sem fio, você tem a opção de alterar o nome e a descrição da política. Se você
alterar o nome da política, a alteração será refletida no painel de detalhes de editor de gerenciamento de política de
grupo e na barra de título da caixa de diálogo política de rede sem fio. Independentemente de como você renomear suas
políticas, a nova política sem fio do XP será sempre listada em Editor de Gerenciamento de Política de Grupo com o tipo
exibindo o XP . Outras políticas são listadas com o tipo mostrando o Vista e versões posteriores .
a diretiva de rede sem fio para Windows Vista e versões posteriores permite que você configure, priorize e
gerencie vários perfis sem fio. Um perfil sem fio é uma coleção de configurações de conectividade e segurança
que são usadas para se conectar a uma rede sem fio específica. Quando Política de Grupo é atualizado em seus
computadores cliente sem fio, os perfis que você cria na diretiva de rede sem fio são adicionados
automaticamente à configuração em seus computadores cliente sem fio aos quais a diretiva de rede sem fio se
aplica.
P e r m i t i n d o c o n e x õ e s c o m v á r i a s r e d e s se m fi o
Se você tiver clientes sem fio que são movidos entre locais físicos em sua organização, como entre um escritório
principal e uma filial, talvez você queira que os computadores se conectem a mais de uma rede sem fio. Nessa
situação, você pode configurar um perfil sem fio que contenha as configurações específicas de conectividade e
segurança para cada rede.
Por exemplo, suponha que sua empresa tenha uma rede sem fio para o escritório corporativo principal, com um
identificador de conjunto de serviços ( SSID ) WlanCorp.
Sua filial também tem uma rede sem fio à qual você também deseja se conectar. A filial tem o SSID configurado
como WlanBranch.
Nesse cenário, você pode configurar um perfil para cada rede, e computadores ou outros dispositivos que são
usados no escritório corporativo e na filial podem se conectar a qualquer uma das redes sem fio quando
estiverem fisicamente no alcance da área de cobertura de uma rede.
- R e d e s se m fi o d e m o d o m i st o
Como alternativa, suponha que sua rede tenha uma mistura de computadores sem fio e dispositivos que dão
suporte a diferentes padrões de segurança. talvez alguns computadores mais antigos tenham adaptadores sem
fio que só possam usar - Enterprise WPA, enquanto dispositivos mais novos podem usar o padrão WPA2
Enterprise mais forte - .
Você pode criar dois perfis diferentes que usam o mesmo SSID e configurações de segurança e conectividade
quase idênticas.
em um perfil, você pode definir a autenticação sem fio para WPA2 - Enterprise com AES e, no outro perfil, você
pode especificar o WPA - Enterprise com TKIP.
Isso é comumente conhecido como uma - implantação de modo misto e permite que computadores de
diferentes tipos e recursos sem fio compartilhem a mesma rede sem fio.
NPS do servidor de políticas de rede ()
O NPS permite que você crie e aplique políticas de acesso à rede para autenticação e autorização de solicitação
de conexão.
Ao usar o NPS como um servidor RADIUS, você configura os servidores de acesso à rede, como pontos de
acesso sem fio, como clientes RADIUS no NPS. Você também configura as políticas de rede que o NPS usa para
autenticar clientes de acesso e autorizar suas solicitações de conexão.
Computadores cliente sem fio
para o propósito deste guia, os computadores cliente sem fio são computadores e outros dispositivos
equipados com adaptadores de rede sem fio IEEE 802,11 e que estão executando Windows sistemas
operacionais de cliente ou servidor Windows.
Computadores de servidor como clientes sem fio
por padrão, a funcionalidade de 802,11 sem fio é desabilitada em computadores que executam o Windows
Server.
para habilitar a conectividade sem fio em computadores que executam sistemas operacionais de servidor, você
deve instalar e habilitar o recurso de serviço WLAN de LAN sem fio ( ) usando o Windows PowerShell ou o
assistente adicionar funções e recursos no Gerenciador do Servidor.
Quando você instala o recurso ser viço de L AN sem fio , o novo serviço configuração automática de
WL AN é instalado nos Ser viços . Quando a instalação for concluída, você deverá reiniciar o servidor.
depois que o servidor for reiniciado, você poderá acessar a configuração automática de WLAN ao clicar em
iniciar , Windows ferramentas administrativas e ser viços .
Após a instalação e a reinicialização do servidor, o serviço de configuração automática de WLAN está em um
estado parado com um tipo de inicialização automático . Para iniciar o serviço, clique duas vezes em
configuração automática de WL AN . Na guia geral , clique em Iniciar e em OK .
O serviço de configuração automática de WLAN enumera os adaptadores sem fio e gerencia as conexões sem
fio e os perfis sem fio que contêm configurações que são necessárias para configurar o servidor para se
conectar a uma rede sem fio.
Para obter uma visão geral da implantação de acesso sem fio, consulte processo de implantação de acesso sem
fio.
Processo da implantação de acesso sem fio
11/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
O processo usado para implantar o acesso sem fio ocorre nestes estágios:
Estágio 1 – Implantação de AP
Planeje, implante e configure seus APs para conectividade de cliente sem fio e para uso com NPS. Dependendo
de sua preferência e dependências de rede, você pode pré-definir as configurações em seus APs sem fio antes
de instalá-las em sua rede ou configurá-las remotamente após a - instalação.
NOTE
Por padrão, a configuração Permissão de Acesso à Rede nas propriedades discadas da conta de usuário é configurada
com a configuração Controlar o acesso por meio da Política de Rede NPS. A menos que você tenha motivos específicos
para alterar essa configuração, é recomendável manter o padrão. Isso permite controlar o acesso à rede por meio das
políticas de rede configuradas no NPS.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Antes de implantar o acesso sem fio, você deve planejar os seguintes itens:
Instalação de pontos de acesso sem fio ( APS ) em sua rede
Configuração e acesso de cliente sem fio
As seções a seguir fornecem detalhes sobre essas etapas de planejamento.
NOTE
Para implantar o WPA2, você deve usar adaptadores de rede sem fio e APs sem fio que também dão suporte a WPA2.
Caso contrário, use o WPA - Enterprise.
Além disso, para fornecer segurança aprimorada para a rede, os APs sem fio devem dar suporte às seguintes
opções de segurança:
Filtragem de DHCP. O AP sem fio deve filtrar as portas IP para evitar a transmissão de mensagens de
difusão DHCP nesses casos em que o cliente sem fio está configurado como um servidor DHCP. O AP
sem fio deve impedir que o cliente envie pacotes IP da porta UDP 68 para a rede.
Filtragem de DNS. O AP sem fio deve filtrar as portas IP para impedir que um cliente execute como um
servidor DNS. O AP sem fio deve impedir que o cliente envie pacotes IP da porta TCP ou UDP 53 para a
rede.
Isolamento de cliente Se o ponto de acesso sem fio fornece recursos de isolamento de cliente, você
deve habilitar o recurso para impedir possíveis ( explorações de falsificação ARP do protocolo de
resolução de endereço ) .
Identificar áreas de cobertura para usuários sem fio
Use desenhos arquitetônicos de cada andar para identificar as áreas em que você deseja fornecer cobertura sem
fio. Por exemplo, identifique os escritórios apropriados, as salas de conferências, lobbies, lanchonetes ou
Courtyards.
nos desenhos, indique quaisquer dispositivos que interfiram com os sinais sem fio, como equipamentos
médicos, câmeras de vídeo sem fio, telefones sem fio que operam no 2,4 a 2,5 GHz, o alcance do ISM Industrial,
científico e médico e ( ) Bluetooth - dispositivos habilitados.
No desenho, marque aspectos da construção que podem interferir com sinais sem fio; os objetos metálicos
usados na construção de um edifício podem afetar o sinal sem fio. Por exemplo, os objetos comuns a seguir
podem interferir na propagação de sinal: Elevadors, dutos de calefação e ar- - condicionado e suporte concreto
girders.
Consulte o fabricante do seu AP para obter informações sobre fontes que podem causar atenuação de
radiofrequência de AP sem fio. A maioria dos APs fornece software de teste que você pode usar para verificar a
intensidade do sinal, a taxa de erros e a taxa de transferência de dados.
Determinar onde instalar APs sem fio
Nos desenhos arquitetônicos, localize seus APs sem fio perto o suficiente para fornecer uma ampla cobertura
sem fio, mas muito distante que eles não interferem uns com os outros.
A distância necessária entre os APs depende do tipo de antena AP e PA, aspectos da construção que bloqueia
sinais sem fio e outras fontes de interferência. Você pode marcar lugares de ponto de acesso sem fio para que
cada AP sem fio não tenha mais de 300 pés de qualquer AP sem fio adjacente. Consulte a documentação do
fabricante do AP sem fio para obter as especificações e diretrizes de AP para posicionamento.
Instale temporariamente os APs sem fio nos locais especificados em seus desenhos arquitetônicos. Em seguida,
usando um laptop equipado com um adaptador sem fio 802,11 e o software de pesquisa de site que
normalmente é fornecido com adaptadores sem fio, determine a intensidade do sinal dentro de cada área de
cobertura.
Em áreas de cobertura em que a intensidade do sinal é baixa, posicione o AP para melhorar a intensidade do
sinal para a área de cobertura, instale APs sem fio adicionais para fornecer a cobertura necessária, realocar ou
remover fontes de interferência de sinal.
Atualize seus desenhos arquitetônicos para indicar o posicionamento final de todos os APs sem fio. Ter um
mapa de colocação de ponto de acesso preciso ajudará mais tarde durante operações de solução de problemas
ou quando você quiser atualizar ou substituir APs.
Planejar a configuração de cliente do AP sem fio e do NPS RADIUS
Você pode usar o NPS para configurar APs sem fio individualmente ou em grupos.
Se você estiver implantando uma rede sem fio grande que inclui muitos APs, será muito mais fácil configurar o
APs em grupos. Para adicionar os APs como grupos de clientes RADIUS no NPS, você deve configurar o APs
com essas propriedades.
Os APs sem fio são configurados com endereços IP do mesmo intervalo de endereços IP.
Os APs sem fio são todos configurados com o mesmo segredo compartilhado.
Planejar o uso da reconexão rápida de PEAP
Em uma infraestrutura 802.1 X, os pontos de acesso sem fio são configurados como clientes RADIUS para
servidores RADIUS. Quando o PEAP reconnect Fast é implantado, um cliente sem fio que faz roaming entre dois
ou mais pontos de acesso não precisa ser autenticado com cada nova associação.
A reconexão rápida do PEAP reduz o tempo de resposta para autenticação entre o cliente e o autenticador, pois a
solicitação de autenticação é encaminhada do novo ponto de acesso para o NPS que originalmente realizou a
autenticação e autorização para a solicitação de conexão do cliente.
Como o cliente PEAP e o NPS usam as propriedades de conexão TLS de segurança da camada de transporte em
cache ( ) ( , a coleção da qual é chamada de identificador TLS ) , o NPS pode determinar rapidamente que o
cliente está autorizado para uma reconexão.
IMPORTANT
Para que a reconexão rápida funcione corretamente, os APs devem ser configurados como clientes RADIUS do mesmo
NPS.
Se o NPS original ficar indisponível ou se o cliente mudar para um ponto de acesso configurado como um
cliente RADIUS para um servidor RADIUS diferente, a autenticação completa deverá ocorrer entre o cliente e o
novo autenticador.
Configuração de AP sem fio
A lista a seguir resume os itens normalmente configurados em - APS sem fio compatíveis com 802.1 x:
NOTE
Os nomes de item podem variar de acordo com a marca e o modelo e podem ser diferentes daqueles na lista a seguir.
Consulte a documentação do AP sem fio para obter - detalhes específicos de configuração.
Identificador do conjunto de ( ser viços SSID ) . Esse é o nome da rede sem fio, ( por exemplo,
ExampleWlan ) , e o nome que é anunciado para clientes sem fio. Para reduzir a confusão, o SSID que
você escolher anunciar não deve corresponder ao SSID que é transmitido por qualquer rede sem fio que
esteja dentro do intervalo de recepção da sua rede sem fio.
Em casos em que vários APs sem fio são implantados como parte da mesma rede sem fio, configure cada
AP sem fio com o mesmo SSID. Em casos em que vários APs sem fio são implantados como parte da
mesma rede sem fio, configure cada AP sem fio com o mesmo SSID.
Nos casos em que você tem a necessidade de implantar diferentes redes sem fio para atender às
necessidades de negócios específicas, o AP sem fio em uma rede deve transmitir um SSID diferente do
SSID de outras redes ( ) . Por exemplo, se precisar de uma rede sem fio separada para seus funcionários e
convidados, você poderá configurar seus APs sem fio para a rede de negócios com o SSID definido como
Broadcast ExampleWL AN . Para sua rede de convidados, você pode definir cada SSID de AP sem fio para
difundir GuestWL AN . Dessa forma, seus funcionários e convidados podem se conectar à rede
pretendida sem confusão desnecessária.
TIP
Alguns pontos de acesso sem fio têm a capacidade de difundir vários SSIDs para acomodar várias - implantações
de rede. Os pontos de acesso sem fio que podem difundir vários SSIDs podem reduzir os custos de implantação e
manutenção operacional.
IMPORTANT
Você deve posicionar o perfil com os padrões mais seguros mais altos na lista ordenada de perfis, pois a conexão de
computadores usa o primeiro perfil que eles são capazes de usar.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
NOTE
Os procedimentos deste guia não incluem instruções para os casos em que a caixa de diálogo Controle de Conta de
Usuário é aberta para solicitar sua permissão para continuar. Caso essa caixa de diálogo seja aberta durante a execução
dos procedimentos deste guia e em resposta às suas ações, clique em Continuar .
TIP
Registre o segredo compartilhado para cada AP sem fio e armazene-o em um local seguro, como um escritório seguro.
Você deve saber o segredo compartilhado para cada AP sem fio ao configurar clientes RADIUS no NPS.
Endereço IP do ser vidor RADIUS . Digite o endereço IP do servidor que executa o NPS.
Por ta ( s ) UDP . Por padrão, o NPS usa as portas UDP 1812 e 1645 para mensagens de autenticação e
portas UDP 1813 e 1646 para mensagens de contabilidade. É recomendável que você use essas mesmas
portas UDP em seus APs, mas se você tiver um motivo válido para usar portas diferentes, certifique-se
de não apenas configurar os APs com os novos números de porta, mas também reconfigurar todos os
seus NPSs para usar os mesmos números de porta que os APs. Se os APs e o NPSs não estiverem
configurados com as mesmas portas UDP, o NPS não poderá receber ou processar solicitações de
conexão do APs, e todas as tentativas de conexão sem fio na rede falharão.
VSAs . Alguns APs sem fio exigem - atributos específicos do fornecedor ( VSAs ) para fornecer
funcionalidade completa de AP sem fio. Os VSAs são adicionados à política de rede do NPS.
Filtragem de DHCP . Configure APs sem fio para impedir que clientes sem fio enviem pacotes IP da
porta UDP 68 para a rede, conforme documentado pelo fabricante do AP sem fio.
Filtragem de DNS . Configure os APs sem fio para impedir que clientes sem fio enviem pacotes IP da
porta TCP ou UDP 53 para a rede, conforme documentado pelo fabricante do AP sem fio.
1. Em Inserir os nomes de objeto a serem selecionados , digite o nome do usuário ou grupo que você
deseja adicionar e clique em OK .
2. Para atribuir a associação de grupo a outros usuários ou grupos, repita a etapa 1 deste procedimento.
Para adic ion ar u m c om pu t ador
NOTE
depois de ativar a versão Windows Vista e versões posteriores das políticas IEEE 802,11 da rede sem fio ( ) ou da
versão Windows XP , a opção versão será automaticamente removida da lista de opções quando você clicar com o
botão direito do mouse - em rede sem fio ( ) políticas IEEE 802,11 . Isso ocorre porque depois de selecionar uma
versão de política, a política é adicionada no painel de detalhes do GPME quando você seleciona o nó de políticas de
rede sem fio ( IEEE 802,11 ) . Esse estado permanece a menos que você exclua a política sem fio, quando a versão da
política sem fio retorna ao menu de clique com o botão direito do mouse em - ( ) políticas IEEE 802,11 de rede sem
fio no GPME. Além disso, as políticas sem fio são listadas apenas no painel detalhes do GPME quando o nó ( ) políticas
IEEE 802,11 de rede sem fio está selecionado.
4. A caixa de diálogo Propriedades da nova diretiva de rede sem fio é aberta. Em nome da política ,
digite um novo nome para a política ou mantenha o nome padrão. Clique em OK para salvar a política. A
política padrão é ativada e listada no painel de detalhes do GPME com o novo nome fornecido ou com o
nome padrão nova política de rede sem fio .
5. No painel de detalhes, clique duas vezes - em nova política de rede sem fio para abri-la.
Na próxima seção, você pode executar a configuração de política, a ordem de preferência de processamento de
política e as permissões de rede.
Configurar a nova política de rede sem fio
Você pode usar os procedimentos nesta seção para configurar a política de rede sem fio ( IEEE 802,11 ) . Essa
política permite que você defina configurações de segurança e autenticação, gerencie perfis sem fio e
especifique permissões para redes sem fio que não estão configuradas como redes preferenciais.
Configurar um perfil de conexão sem fio para PEAP - MS - CHAP v2
Definir a ordem de preferência para perfis de conexão sem fio
Definir permissões de rede
Configurar um perfil de conexão sem fio para PEAP - MS - CHAP v2
Este procedimento fornece as etapas necessárias para configurar um - - perfil sem fio PEAP MS CHAP v2.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
P a r a c o n fi g u r a r u m p e r fi l d e c o n e x ã o se m fi o p a r a P E A P - M S - C H A P v 2
1. No GPME, na caixa de diálogo Propriedades da rede sem fio para a política que você acabou de criar, na
guia geral e em Descrição , digite uma breve descrição para a política.
2. para especificar que a configuração automática de wlan é usada para definir as configurações do
adaptador de rede sem fio, verifique se usar Windows ser viço de configuração automática de
wlan para clientes está selecionado.
3. em Conexão às redes disponíveis na ordem dos perfis listados abaixo , clique em adicionar e
selecione infraestrutura . A caixa de diálogo Propriedades do novo perfil é aberta.
4. Na caixa de diálogo Propriedades do novo perfil , na guia conexão , no campo nome do perfil ,
digite um novo nome para o perfil. Por exemplo, digite perfil de WL AN example.com para Windows
10 .
5. Em nome da rede ( s ) ( SSID ) , digite o SSID que corresponde ao SSID configurado em seus APS sem
fio e clique em Adicionar .
Se sua implantação utiliza vários SSIDs e cada PA sem fio utiliza as mesmas configurações de segurança
sem fio, repita essa etapa para adicionar o SSID de cada PA sem fio ao qual você deseja que esse perfil
seja aplicado.
Se sua implantação utiliza vários SSIDs e as configurações de segurança para cada SSID não são
correspondentes, configure um perfil separado para cada grupo de SSIDs que usam as mesmas
configurações de segurança. por exemplo, se você tiver um grupo de aps sem fio configurado para usar
WPA2 - Enterprise e AES e outro grupo de aps sem fio para usar WPA - Enterprise e TKIP, configure um
perfil para cada grupo de aps sem fio.
6. Se o texto padrão NEWSSID estiver presente, selecione-o e clique em remover .
7. Se você implantou pontos de acesso sem fio configurados para suprimir o sinalizador de difusão,
selecione Conectar mesmo que não haja difusão na rede .
NOTE
Habilitar essa opção pode criar um risco de segurança, pois os clientes sem fio investigarão e tentarão conexões
com qualquer rede sem fio. Por padrão, essa configuração não está habilitada.
12. Em selecionar um método de autenticação de rede , selecione EAP ( PEAP ) protegido e clique
em Propriedades . A caixa de diálogo Propriedades EAP protegidas é aberta.
13. Em Propriedades EAP protegidas , confirme que Verifique se a identidade do ser vidor
Validando o cer tificado está selecionada.
14. Em autoridades de cer tificação raiz confiáveis , selecione a AC da autoridade de certificação raiz
confiável ( ) que emitiu o certificado do servidor para o NPS.
NOTE
Essa configuração limita as ACs raiz que os clientes confiam para as ACs selecionadas. Se nenhuma AC raiz
confiável for selecionada, os clientes confiarão em todas as CAs raiz listadas em seu repositório de certificados de
autoridades de certificação raiz confiáveis.
15. Na lista selecionar método de autenticação , selecione EAP de senha segura ( - MS - CHAP ) v2 .
16. Clique em Configurar . na caixa de diálogo propriedades EAP MSCHAPv2 , verifique se usar
automaticamente meu nome de logon do Windows e senha ( e ) domínio, se houver algum
selecionado, e clique em OK .
17. Para habilitar a reconexão rápida de PEAP, verifique se habilitar reconexão rápida está selecionado.
18. Para exigir TLV de cryptobinding de servidor em tentativas de conexão, selecione desconectar se o
ser vidor não apresentar TLV de cr yptobinding .
19. Para especificar que a identidade do usuário está mascarada na fase um da autenticação, selecione
Habilitar Privacidade de identidade e, na caixa de texto, digite um nome de identidade anônimo ou
deixe a caixa de texto em branco.
[! REGISTRA
A política do NPS para 802.1 X sem fio deve ser criada usando a política de solicitação de
conexão do NPS. Se a política de NPS for criada usando a política de rede do NPS, a
privacidade de identidade não funcionará.
A privacidade de identidade EAP é fornecida por determinados métodos EAP em que uma
identidade vazia ou anônima ( diferente da identidade real ) é enviada em resposta à solicitação de
identidade EAP. O PEAP envia a identidade duas vezes durante a autenticação. Na primeira fase, a
identidade é enviada em texto sem formatação e essa identidade é usada para fins de roteamento,
não para autenticação de cliente. A identidade real — usada para autenticação — é enviada
durante a segunda fase da autenticação, dentro do túnel seguro que é estabelecido na primeira
fase. Se a caixa de seleção Habilitar Privacidade de identidade estiver marcada, o nome de
usuário será substituído pela entrada especificada na caixa de texto. Por exemplo, suponha que
Habilitar Privacidade de identidade esteja selecionado e que o alias de privacidade de
identidade anônimo seja especificado na caixa de texto. Para um usuário com um alias de
identidade real [email protected] , a identidade enviada na primeira fase de autenticação será
alterada para [email protected] . A parte do Realm da identidade da 1ª fase não é
modificada, pois é usada para fins de roteamento.
20. Clique em OK para fechar a caixa de diálogo Propriedades EAP protegidas .
21. Clique em OK para fechar a guia segurança .
22. Se você quiser criar perfis adicionais, clique em Adicionar e repita as etapas anteriores, fazendo
diferentes escolhas para personalizar cada perfil para os clientes sem fio e a rede para a qual você deseja
aplicar o perfil. Quando terminar de adicionar perfis, clique em OK para fechar a caixa de diálogo
Propriedades da diretiva de rede sem fio.
Na próxima seção, você pode ordenar os perfis de política para garantir a segurança ideal.
Definir a ordem de preferência para perfis de conexão sem fio
Você pode usar este procedimento se tiver criado vários perfis sem fio em sua política de rede sem fio e desejar
solicitar os perfis para obter a eficácia e a segurança ideais.
Para garantir que os clientes sem fio se conectem com o nível mais alto de segurança que eles podem dar
suporte, coloque suas políticas mais restritivas na parte superior da lista.
Por exemplo, se você tiver dois perfis, um para clientes que dão suporte a WPA2 e outro para clientes que dão
suporte a WPA, coloque o perfil WPA2 mais alto na lista. Isso garante que os clientes que dão suporte a WPA2
usarão esse método para a conexão em vez do WPA menos seguro.
Este procedimento fornece as etapas para especificar a ordem na qual os perfis de conexão sem fio são usados
para conectar clientes sem fio membros do domínio a redes sem fio.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
P a r a d e fi n i r a o r d e m d e p r e fe r ê n c i a p a r a p e r fi s d e c o n e x ã o se m fi o
1. No GPME, na caixa de diálogo Propriedades da rede sem fio para a política que você acabou de
configurar, clique na guia geral .
2. na guia geral , em Conexão às redes disponíveis na ordem dos perfis listados abaixo , selecione
o perfil que você deseja mover na lista e clique no botão "seta para cima" ou no botão "seta para baixo"
para mover o perfil para o local desejado na lista.
3. Repita a etapa 2 para cada perfil que você deseja mover na lista.
4. Clique em OK para salvar todas as alterações.
Na seção a seguir, você pode definir permissões de rede para a política sem fio.
Definir permissões de rede
Você pode definir as configurações na guia permissões de rede para os membros do domínio aos quais ( as
diretivas IEEE 802,11 de rede sem fio ) se aplicam.
Você só pode aplicar as seguintes configurações para redes sem fio que não estão configuradas na guia geral
da página Propriedades da política de rede sem fio :
Permitir ou negar conexões a redes sem fio específicas que você especificar por tipo de rede e
identificador de conjunto de serviços ( SSID)
Permitir ou negar conexões a redes ad hoc
Permitir ou negar conexões a redes de infraestrutura
Permitir ou negar que os usuários exibam tipos de rede ( ad hoc ou infraestrutura ) à qual o acesso foi
negado
Permitir ou negar que os usuários criem um perfil que se aplica a todos os usuários
Os usuários só podem se conectar a redes permitidas usando perfis de Política de Grupo
A associação em Admins . do domínio, ou equivalente, é o mínimo necessário para concluir esses
procedimentos.
P a r a p e r m i t i r o u n e g a r c o n e x õ e s a r e d e s se m fi o e sp e c í fi c a s
1. No GPME, na caixa de diálogo Propriedades da rede sem fio, clique na guia permissões de rede .
2. Na guia permissões de rede , clique em Adicionar . A caixa de diálogo nova entrada de permissões
é aberta.
3. Na caixa de diálogo nova entrada de permissão , no campo nome da rede ( SSID ) , digite o SSID
da rede para o qual você deseja definir permissões.
4. Em tipo de rede , selecione infraestrutura ou ad hoc .
NOTE
Se você não tiver certeza se a rede de difusão é uma infraestrutura ou rede ad hoc, você pode configurar duas
entradas de permissão de rede, uma para cada tipo de rede.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Para registrar um NPS em seu domínio padrão
1. No seu NPS, em Gerenciador do ser vidor , clique em ferramentas e em ser vidor de políticas de
rede . O snap- - in do NPS é aberto.
2. Clique com o botão direito do mouse - em NPS ( local ) e clique em registrar ser vidor em Active
Director y . A caixa de diálogo Ser vidor de Políticas de Rede é aberta.
3. Em Ser vidor de Políticas de Rede , clique em OK e em OK novamente.
Configurar um AP sem fio como um cliente RADIUS NPS
Você pode usar este procedimento para configurar um AP, também conhecido como um servidor de acesso à
rede ( nas ), como um cliente RADIUS de autenticação remota - no serviço ( do usuário ) usando o snap-in do
NPS - .
IMPORTANT
Computadores cliente, como computadores portáteis sem fio e outros computadores que executam sistemas
operacionais cliente, não são clientes RADIUS. Os clientes RADIUS são servidores de acesso à rede — como pontos de
acesso sem fio, - switches compatíveis com 802.1 x, servidores VPN de rede privada virtual ( ) e servidores de dial - -up
— porque usam o protocolo RADIUS para se comunicar com servidores RADIUS, como o NPSs.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Para adicionar um servidor de acesso à rede como um cliente RADIUS no NPS
1. No seu NPS, em Gerenciador do ser vidor , clique em ferramentas e em ser vidor de políticas de
rede . O snap- - in do NPS é aberto.
2. No snap-in do NPS - , - clique duas vezes em clientes e ser vidores RADIUS . Clique com o botão
direito do mouse - em clientes RADIUS e clique em novo .
3. Em novo cliente RADIUS , verifique se a caixa de seleção habilitar este cliente RADIUS está
marcada.
4. Em novo cliente RADIUS , em nome amigável , digite um nome de exibição para o ponto de acesso
sem fio.
Por exemplo, se você quiser adicionar um AP de ponto de acesso sem fio ( ) chamado AP - 01, digite AP -
01.
5. Em endereço ( IP ou DNS ) , digite o endereço IP ou o FQDN do nome de domínio totalmente
qualificado ( ) para o nas.
Se você inserir o FQDN, para verificar se o nome está correto e é mapeado para um endereço IP válido,
clique em verificar e, em verificar endereço , no campo endereço , clique em resolver . Se o nome
FQDN for mapeado para um endereço IP válido, o endereço IP desse NAS será exibido automaticamente
no endereço IP . Se o FQDN não for resolvido para um endereço IP, você receberá uma mensagem
indicando que esse host não é conhecido. Se isso ocorrer, verifique se você tem o nome do AP correto e
se o AP está ligado e conectado à rede.
Clique em OK para fechar verificar endereço .
6. Em novo cliente RADIUS , em segredo compar tilhado , siga um destes procedimentos:
Para configurar manualmente um segredo compartilhado RADIUS, selecione manual e, em
segredo compar tilhado , digite a senha forte que também é inserida no nas. Digite novamente o
segredo compartilhado em confirmar segredo compar tilhado .
Para gerar automaticamente um segredo compartilhado, marque a caixa de seleção Gerar e clique
no botão Gerar. Salve o segredo compartilhado gerado e, em seguida, use esse valor para
configurar o NAS para que ele possa se comunicar com o NPS.
IMPORTANT
O segredo compartilhado RADIUS que você inscreva para suas AP virtuais no NPS deve corresponder
exatamente ao segredo compartilhado RADIUS configurado nas AP's sem fio reais. Se você usar a opção
NPS para gerar um segredo compartilhado RADIUS, deverá configurar a AP sem fio real correspondente
com o segredo compartilhado RADIUS gerado pelo NPS.
NOTE
Você pode executar o assistente Novas Conexões Seguras com Fio e Sem Fio do IEEE 802.1X sempre que precisar criar
novas políticas para acesso autenticado 802.1X.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Criar políticas para 802.1X sem fio autenticado usando um assistente
1. Abra o snap-in do - NPS. Se ainda não estiver selecionado, clique em NPS ( Local. ) Se você estiver
executando o snap-in do NPS MMC e quiser criar políticas em um - NPS remoto, selecione o servidor.
2. No Ponto de Par tida , em Configuração Padrão , selecione Servidor RADIUS para 802.1X Conexões
sem fio ou com fio. O texto e os links abaixo do texto mudam para refletir sua seleção.
3. Clique em Configurar 802.1X. O assistente Configurar 802.1X é aberto.
4. Na página do assistente Selecionar Tipo de Conexões 802.1X, em Tipo de conexões 802.1X , selecione
Conexões Sem Fio Seguras e, em Nome , digite um nome para sua política ou deixe o nome padrão
Conexões Sem Fio Seguras . Clique em Próximo .
5. Na página do assistente Especificar comutadores 802.1X, em clientes RADIUS, todas as opções
802.1X e os pontos de acesso sem fio que você adicionou como Clientes RADIUS no snap-in NPS - são
mostrados. Execute um destes procedimentos:
Para adicionar naSs servidores de acesso à rede adicionais, como APs sem fio, em clientes RADIUS,
clique em Adicionar e, em seguida, em Novo cliente RADIUS, insira as informações ( ) para: Nome
amigável, IP de endereço ou ( DNS ) e Segredo Compartilhado .
Para modificar as configurações de qualquer NAS, em clientes RADIUS, selecione o AP para o
qual você deseja modificar as configurações e clique em Editar . Modifique as configurações
conforme necessário.
Para remover um NAS da lista, em clientes RADIUS, selecione o NAS e clique em Remover .
WARNING
A remoção de um cliente RADIUS de dentro do assistente Configurar 802.1X exclui o cliente da
configuração do NPS. Todas as adições, modificações e exclusões feitas no assistente Configurar 802.1X
para clientes RADIUS são refletidas no snap-in NPS, no nó Clientes RADIUS em Clientes - NPS RADIUS e /
Ser vidores . Por exemplo, se você usar o assistente para remover uma opção 802.1X, a opção também
será removida do snap-in do - NPS.
TIP
Se você receber uma mensagem de erro indicando que um certificado não pode ser encontrado para uso com o
método de autenticação e tiver configurado o Serviços de Certificados do Active Directory para emitir certificados
automaticamente para servidores RAS e IAS em sua rede, primeiro verifique se você seguiu as etapas para
Registrar NPS no Active Directory Domain Services e, em seguida, use as seguintes etapas para atualizar o Política
de Grupo: Clique em Iniciar , clique em Windows System , clique em Executar e em Abrir , digite gpupdate e
pressione ENTER. Quando o comando retornar resultados indicando que o usuário e o computador Política de
Grupo foram atualizados com êxito, selecione Microsoft: EAP ( ) PEAP protegido novamente e clique em
Configurar .
Se, depois de atualizar o Política de Grupo você continuar recebendo a mensagem de erro indicando que um
certificado não pode ser encontrado para uso com o método de autenticação, o certificado não será exibido
porque ele não atenderá aos requisitos mínimos de certificado do servidor, conforme documentado no Guia
principal do Companion Network: Deploy Server Certificates for 802.1X Wiredand Wireless Deployments . Se isso
acontecer, você deverá descontinuar a configuração do NPS, revogar o certificado emitido para o NPS e, em
seguida, seguir as instruções para configurar um novo certificado usando o guia de implantação de ( ) certificados
do servidor.
Para permitir que os usuários percorrem o roam com seus computadores sem fio entre pontos de
acesso sem exigir que eles se autenticem novamente sempre que associarem a uma nova AP,
selecione Habilitar Reconexão Rápida.
Para especificar que a conexão de clientes sem fio encerrará o processo de autenticação de rede se
o servidor RADIUS não apresentar cryptobinding Type - - Length Value ( TLV ) , selecione
Desconectar Clientes sem Criptografia .
Para modificar as configurações de política para o tipo de EAP, em Tipos de EAP, clique em Editar ,
em Propriedades de EAP MSCHAPv2 , modifique as configurações conforme necessário e clique
em OK.
8. Clique em OK . A caixa de diálogo Editar Propriedades de EAP Protegidas é fechado, retornando você para
o assistente Configurar 802.1X. Clique em Próximo .
9. Em Especificar Grupos de Usuários , clique em Adicionar e digite o nome do grupo de segurança que
você configurou para seus clientes sem fio no Usuários e Computadores do Active Directory - snap-in.
Por exemplo, se você nomeou o grupo de segurança sem fio Grupo Sem Fio, digite Grupo Sem Fio .
Clique em Próximo .
10. Clique em Configurar para configurar atributos padrão RADIUS e atributos específicos do fornecedor
para a VLAN da LAN virtual conforme necessário e, conforme especificado pela documentação fornecida
pelo fornecedor de hardware de AP sem - ( ) fio. Clique em Próximo .
11. Revise os detalhes do resumo da configuração e clique em Concluir .
Suas políticas NPS agora são criadas e você pode passar para a junção de computadores sem fio ao domínio.
4. Distribua o novo computador sem fio para o usuário com o procedimento para "Fazer logoff no domínio
usando computadores que executam Windows 10".
Quando o usuário inicia o computador, Windows solicita que o usuário insira seu nome de conta de usuário de
domínio e senha. Como o Logom Único está habilitado, o computador usa as credenciais da conta de usuário do
domínio para estabelecer primeiro uma conexão com a rede sem fio e, em seguida, fazer logoff no domínio.
Faça logoff no domínio usando computadores que executam Windows 10
1. Faça logoff do computador ou o reinicie.
2. Pressione qualquer tecla no teclado ou clique na área de trabalho. A tela de logon aparece com um nome
de conta de usuário local exibido e um campo de entrada de senha abaixo do nome. Não faça logoff com
a conta de usuário local.
3. No canto inferior esquerdo da tela, clique em Outro Usuário. A tela Outro Usuário faz logoff com dois
campos, um para nome de usuário e outro para senha. Abaixo do campo senha está o texto Entrar em:
e, em seguida, o nome do domínio em que o computador está ingressado. Por exemplo, se o domínio for
example.com, o texto lerá Entrar em: EXEMPLO.
4. Em Nome de usuário, digite o nome de usuário do domínio.
5. Em Senha , digite sua senha do domínio e clique na seta ou pressione ENTER.
NOTE
Se a tela Outro Usuário não incluir o texto Entrar em: e seu nome de domínio, insira seu nome de usuário no formato
usuário do \ domínio. Por exemplo, para fazer logoff no domínio example.com com uma conta chamada Usuário - 01 ,
digite o exemplo De usuário \ - 01 .
Ingressar no domínio e fazer logon usando a configuração de perfil sem fio de inicialização por usuários
Com esse método, você conclui as etapas na seção Etapas gerais e, em seguida, fornece aos usuários membros
do domínio as instruções sobre como configurar manualmente um computador sem fio com um perfil sem fio
de - inicialização. O perfil sem fio de inicialização permite que o usuário estabeleça uma conexão sem fio e, em
seguida, insinue no domínio. Depois que o computador for ingressado no domínio e reiniciado, o usuário
poderá fazer logoff no domínio por meio de uma conexão sem fio.
Etapas gerais
1. Configure uma conta de administrador de computador local, Painel de Controle , para o usuário.
IMPORTANT
Para ingressar um computador em um domínio, o usuário deve estar conectado ao computador com a conta de
Administrador local. Como alternativa, o usuário deve fornecer as credenciais para a conta de Administrador local
durante o processo de ingressar o computador no domínio. Além disso, o usuário deve ter uma conta de usuário
no domínio ao qual o usuário deseja ingressar no computador. Durante o processo de ingressar o computador no
domínio, o usuário será solicitado a solicitar o nome de usuário e a senha das credenciais da conta ( de ) domínio.
2. Forneça aos usuários do domínio as instruções para configurar um perfil sem fio de inicialização,
conforme documentado no procedimento a seguir Para configurar um perfil sem fio de inicialização .
3. Além disso, forneça aos usuários o nome de usuário e a senha das credenciais do computador local e o
nome da conta de usuário do domínio e a senha do domínio no formato ( ) ( ) \ DomainName UserName,
bem como os procedimentos para "Ingressar o computador no domínio" e para "Fazer logon no
domínio", conforme documentado no Guia de Rede Principal do Windows Server 2016 .
Para configurar um perfil sem fio de inicialização
1. Use as credenciais fornecidas pelo administrador de rede ou profissionais de suporte de IT para fazer
logoff no computador com a conta de Administrador do computador local.
2. Clique - com o botão direito do mouse no ícone de rede na área de trabalho e clique em Abrir Central
de Rede e Compar tilhamento . A Central de Rede e Compar tilhamento será aberta. Em Alterar
as configurações de rede, clique em Configurar uma nova conexão ou rede . A caixa de diálogo
Configurar uma Conexão ou Rede é aberta.
3. Clique em Conectar-se manualmente a uma rede sem fio e clique em Próximo.
4. Em Conectar-se manualmente a uma rede sem fio , em Nome da rede , digite o nome SSID do AP.
5. Em Tipo de segurança, selecione a configuração fornecida pelo administrador.
6. Em Tipo de criptografia e Chave de Segurança, selecione ou digite as configurações fornecidas pelo
administrador.
7. Selecione Iniciar essa conexão automaticamente e clique em Próximo.
8. Em Adicionado com êxito o SSID de Rede, clique em Alterar configurações de conexão .
9. Clique em Alterar configurações de conexão . A caixa de diálogo Sua propriedade rede sem fio SSID
de rede é aberta.
10. Clique na guia Segurança e, em Escolher um método de autenticação de rede, selecione PEAP de
EAP ( protegido. )
11. Clique em Configurações . A página Propriedades peap de EAP ( ) protegida é aberta.
12. Na página Propriedades ( peap ) de EAP protegidas, verifique se Validar certificado do servidor não
está selecionado, clique em OK duas vezes e clique em Fechar .
13. Windows tenta se conectar à rede sem fio. As configurações do perfil sem fio de inicialização especificam
que você deve fornecer suas credenciais de domínio. Quando Windows solicitar um nome de conta e
senha, digite suas credenciais de conta de domínio da seguinte forma: Nome de Usuário do Nome de
Domínio , Senha de Domínio. \
P a r a i n g r e ssa r u m c o m p u t a d o r n o d o m í n i o
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012
o guia de rede Windows Server 2016 Core fornece instruções para planejar e implantar os componentes
principais necessários para uma rede totalmente funcional e um novo ® domínio de Active Directory em uma
nova floresta.
este guia explica como criar a rede principal fornecendo instruções para implantar o BranchCache no modo de
cache hospedado em uma ou mais filiais com um - controlador de domínio somente leitura em que os
computadores cliente estão executando o Windows ® 10, Windows 8.1 ou Windows 8 e ingressaram no
domínio.
IMPORTANT
não use este guia se você estiver planejando implantar ou já tiver implantado um servidor de cache hospedado do
BranchCache que esteja executando o Windows server 2008 R2. este guia fornece instruções para implantar o modo de
cache hospedado com um servidor de cache hospedado que está executando o Windows server ® 2016, Windows
Server 2012 R2 ou Windows Server 2012.
implante os servidores de conteúdo do BranchCache que estão executando Windows Server 2016,
Windows Server 2012 R2 ou Windows Server 2012 em seu escritório principal ou em uma data center
de nuvem. Para obter informações sobre como implantar servidores de conteúdo do BranchCache,
consulte recursos adicionais.
Estabeleça conexões WAN de rede de longa distância ( ) entre sua filial, seu escritório principal e, se
apropriado, seus recursos de nuvem, usando uma VPN de rede virtual privada ( , o ) DirectAccess ou
outro método de conexão.
Implante computadores cliente em sua filial que executam um dos sistemas operacionais a seguir, que
fornecem ao BranchCache suporte para Serviço de Transferência Inteligente em Segundo Plano (BITS),
protocolo HTTP e SMB (bloco de mensagens de servidor).
Windows 10 Enterprise
Windows 10 Education
Windows 8.1 Enterprise
O Windows 8 Enterprise
NOTE
Nos sistemas operacionais a seguir, o BranchCache não dá suporte à funcionalidade HTTP e SMB, mas dá suporte à
funcionalidade de BITS do BranchCache. - Windows 10 Pro, somente suporte a BITS - Windows 8.1 Pro, somente suporte
a BITS - Windows 8 Pro, somente suporte a BITS
IMPORTANT
se seus servidores de cache hospedados estiverem executando o Windows server 2008 r2, use o guia de implantação do
branchcache do Windows Server 2008 R2, em vez deste guia, para implantar o BranchCache no modo de cache
hospedado. aplique as configurações de Política de Grupo descritas nesse guia a todos os clientes do BranchCache que
estão executando versões do Windows de Windows 7 a Windows 10. computadores que executam o Windows Server
2008 R2 não podem ser configurados usando as etapas deste guia.
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012
Você pode usar este guia para implantar um servidor de cache hospedado do BranchCache em uma filial em
que os computadores são ingressados em um domínio. Você pode usar este tópico para obter uma visão geral
do processo de implantação do modo de cache hospedado do BranchCache.
Esta visão geral inclui a infraestrutura do BranchCache de que você precisa, bem como uma visão geral passo a
passo simples de implantação.
IMPORTANT
Embora essa implantação descreva os servidores de conteúdo em uma nuvem data center, você pode usar este guia para
implantar um servidor de cache hospedado do BranchCache, independentemente de onde você implanta seus servidores
de conteúdo – em seu escritório principal ou em um local de nuvem.
HCS1 na filial
Você deve configurar este computador como um servidor de cache hospedado. Se você optar por fazer o hash
de dados do servidor de conteúdo para poder pré-carregar o conteúdo em seus servidores de cache
hospedados, poderá importar pacotes de dados que contêm o conteúdo de seus servidores Web e de arquivos.
WEB1 na nuvem data center
WEB1 é um - servidor de conteúdo habilitado para BranchCache. Se você optar por prefazer o hash de dados do
servidor de conteúdo para poder pré-carregar o conteúdo em seus servidores de cache hospedados, você
poderá prearmazenar o conteúdo compartilhado em WEB1 e, em seguida, criar um pacote de dados que você
copia para o HCS1.
FILE1 na nuvem data center
FILE1 é um - servidor de conteúdo habilitado para BranchCache. Se você optar por prefazer o hash de dados do
servidor de conteúdo para poder pré-carregar o conteúdo em seus servidores de cache hospedados, você
poderá prefazer o hash do conteúdo compartilhado no ARQUIVO1 e, em seguida, criar um pacote de dados que
você copia para HCS1.
DC1 no escritório principal
DC1 é um controlador de domínio e você deve configurar a política de domínio padrão ou outra política mais
apropriada para sua implantação, com o BranchCache Política de Grupo configurações para habilitar a
descoberta automática de cache hospedado pelo ponto de conexão de serviço.
Quando os computadores cliente na ramificação tiverem Política de Grupo atualizados e essa configuração de
política for aplicada, ele automaticamente localiza e começa a usar o servidor de cache hospedado na filial.
Computadores cliente na filial
Você deve atualizar Política de Grupo em computadores cliente para aplicar novas configurações de Política de
Grupo do BranchCache e para permitir que os clientes localizem e usem o servidor de cache hospedado.
NOTE
Algumas das etapas a seguir são opcionais, como as etapas que demonstram como prehash e pré-carregamento de
conteúdo em servidores de cache hospedados. Quando você implanta o BranchCache no modo de cache hospedado, não
é necessário colocar o conteúdo de pré-hash em seus servidores de conteúdo da Web e de arquivo, criar um pacote de
dados e importar o pacote de dados para pré-carregar seus servidores de cache hospedados com o conteúdo. As etapas
são indicadas como opcionais nesta seção e na seção implantação do modo de cache hospedado do BranchCache para
que você possa ignorá-las se preferir.
1. no HCS1, use Windows PowerShell comandos para configurar o computador como um servidor de cache
hospedado e registrar um ponto de conexão de serviço no Active Directory.
2. (Opcional ) em HCS1, se os valores padrão do BranchCache não corresponderem aos seus objetivos de
implantação para o servidor e o cache hospedado, configure a quantidade de espaço em disco que você
deseja alocar para o cache hospedado. Configure também o local do disco que você prefere para o cache
hospedado.
3. ()Conteúdo de prehash opcional em servidores de conteúdo, criar pacotes de dados e pré-carregar
conteúdo no servidor de cache hospedado.
NOTE
O pré-hash e o pré-carregamento de conteúdo em seu servidor de cache hospedado são opcionais. no entanto,
se você optar por prehash e Preload, deverá executar todas as etapas abaixo aplicáveis à sua implantação. (Por
exemplo, se você não tiver servidores Web, não precisará executar qualquer uma das etapas relacionadas ao
prehash e ao pré-carregamento do conteúdo do servidor Web.)
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012
Você pode usar este tópico para planejar a implantação do BranchCache no modo de cache hospedado.
IMPORTANT
o servidor de cache hospedado deve estar executando Windows Server 2016, Windows Server 2012 R2 ou Windows
Server 2012.
Antes de implantar o servidor de cache hospedado, você deve planejar os seguintes itens:
Planejar a configuração básica do servidor
Planejar o acesso ao domínio
Planejar o local e o tamanho do cache hospedado
Planejar o compartilhamento no qual os pacotes do servidor de conteúdo devem ser copiados
Planejar a criação de pacotes de dados e de hash em servidores de conteúdo
NOTE
Neste guia, o servidor de cache hospedado é denominado HCS1, mas você deve usar um nome de servidor apropriado
para sua implantação.
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012
Você pode usar este tópico para obter links para tópicos de procedimentos detalhados que orientam você pelo
processo de implantação do modo de cache hospedado do BranchCache.
Siga estas etapas para implantar o modo de cache hospedado do BranchCache.
Instalar o recurso BranchCache e configurar o servidor de cache hospedado pelo ponto de conexão de
serviço
Mover e redimensionar o cache hospedado ()opcional
Pré-hash e pré-carregamento de conteúdo no servidor de cache hospedado ()opcional
Configurar descoberta automática de cache hospedado pelo cliente por ponto de conexão de serviço
NOTE
Os procedimentos deste guia não incluem instruções para os casos em que a caixa de diálogo Controle de Conta de
Usuário é aberta para solicitar sua permissão para continuar. Caso essa caixa de diálogo seja aberta durante a execução
dos procedimentos deste guia e em resposta às suas ações, clique em Continuar .
Para continuar com este guia, consulte instalar o recurso do BranchCache e configurar o servidor de cache
hospedado por ponto de conexão de serviço.
Instalar o recurso BranchCache e configurar o
servidor de cache hospedado por ponto de
conexão de serviço
10/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012
Você pode usar este procedimento para instalar o recurso do BranchCache em seu servidor de cache
hospedado, HCS1, e para configurar o servidor para registrar um SCP de ponto ( ) de conexão de serviço no
Active Directory Domain Services ( AD DS ) .
Quando você registra servidores de cache hospedados com um SCP no AD DS, o SCP permite que os
computadores cliente configurados corretamente para descobrir automaticamente os servidores de cache
hospedados consultando AD DS para o SCP. As instruções sobre como configurar computadores cliente para
executar essa ação são fornecidas posteriormente neste guia.
IMPORTANT
Antes de executar esse procedimento, você deve ingressar o computador no domínio e configurar o computador com um
endereço IP estático.
Install-WindowsFeature BranchCache
2. para configurar o computador como um servidor de cache hospedado após a instalação do recurso do
BranchCache e registrar um ponto de conexão de serviço no AD DS, digite o seguinte comando em
Windows PowerShell e pressione ENTER.
Enable-BCHostedServer -RegisterSCP
3. Para verificar a configuração do servidor de cache hospedado, digite o comando a seguir e pressione
ENTER.
Get-BCStatus
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012
Você pode usar este procedimento para mover o cache hospedado para a unidade e a pasta que preferir, e para
especificar a quantidade de espaço em disco que o servidor de cache hospedado pode usar para o cache
hospedado.
Esse procedimento é opcional. Se o local do cache padrão ( % windir% \ UserProfiles \ NetworkService \
AppData \ local \ PeerDistPub ) e Size – que é 5% do espaço total no disco rígido – são apropriados para sua
implantação, você não precisa alterá-los.
Você deve ser membro do grupo Administradores para executar esse procedimento.
Para mover e redimensionar o cache hospedado
1. abra Windows PowerShell com privilégios de administrador.
2. Digite o seguinte comando para mover o cache hospedado para outro local no computador local e
pressione ENTER.
IMPORTANT
Antes de executar o comando a seguir, substitua os valores de parâmetro, como – Path e – MoveTo, por valores
que são apropriados para sua implantação.
3. Digite o seguinte comando para redimensionar o cache hospedado – especificamente, o cache de dados -
no computador local. Pressione ENTER.
IMPORTANT
Antes de executar o comando a seguir, substitua os valores de parâmetro, como - percentual, por valores que são
apropriados para sua implantação.
Set-BCCache -Percentage 20
4. Para verificar a configuração do servidor de cache hospedado, digite o comando a seguir e pressione
ENTER.
Get-BCStatus
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012
Você pode usar os procedimentos nesta seção para pré-hash de conteúdo em seus servidores de conteúdo,
adicionar o conteúdo a pacotes de dados e, em seguida, pré-carregar o conteúdo em seus servidores de cache
hospedados.
Esses procedimentos são opcionais porque você não precisa pré-hash e pré-carregar conteúdo em seus
servidores de cache hospedados.
Se você não pré-carregar o conteúdo, os dados serão adicionados ao cache hospedado automaticamente à
medida que os clientes os baixarem pela conexão WAN.
IMPORTANT
Embora esses procedimentos sejam coletivamente opcionais, se você decidir pré-hash e pré-carregar conteúdo em seus
servidores de cache hospedados, a execução de ambos os procedimentos será necessária.
Criar pacotes de dados do servidor de conteúdo para conteúdo da Web e do arquivo (dados)
Importar pacotes de dados no servidor de cache hospedado (opcional)
Para continuar com este guia, consulte Create Content Server Data Packages for Web and File Content
(Optional).
Criar pacotes de dados do servidor de conteúdo
para conteúdo da Web e do arquivo (opcional)
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012
Você pode usar esse procedimento para pré-abrir o conteúdo na Web e em servidores de arquivos e, em
seguida, criar pacotes de dados para importar no servidor de cache hospedado.
Esse procedimento é opcional porque você não precisa pré-hash e pré-carregar conteúdo em seus servidores
de cache hospedados. Se você não pré-carregar o conteúdo, os dados serão adicionados ao cache hospedado
automaticamente à medida que os clientes os baixarem pela conexão WAN.
Este procedimento fornece instruções para pré-aplicação de conteúdo em servidores de arquivos e servidores
Web. Se você não tiver um desses tipos de servidores de conteúdo, não será preciso executar as instruções para
esse tipo de servidor de conteúdo.
IMPORTANT
Antes de executar este procedimento, você deve instalar e configurar o BranchCache em seus servidores de conteúdo.
Além disso, se você planeja alterar o segredo do servidor em um servidor de conteúdo, faça isso antes de pré-hash do
conteúdo – modificar o segredo do servidor invalida os - hashes gerados - anteriormente.
NOTE
O valor do parâmetro –Path é a pasta em que o conteúdo está localizado. Você deve substituir os valores de
exemplo nos comandos abaixo por um local de pasta válido no servidor de conteúdo que contém dados que você
deseja pré-manter e adicionar a um pacote.
Se o conteúdo que você deseja pré-hash estiver em um servidor de arquivos, digite o comando a
seguir e pressione ENTER.
Se o conteúdo que você deseja pré-hash estiver em um servidor Web, digite o comando a seguir e
pressione ENTER.
Publish-BCWebContent –Path D:\inetpub\wwwroot -StageData
4. Crie o pacote de dados executando o comando a seguir em cada um dos servidores de conteúdo.
Substitua o valor de exemplo D: temp para o parâmetro –Destination pelo local que você identificou ou
criou no ( \ início deste ) procedimento.
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012
Você pode usar esse procedimento para importar pacotes de dados e pré-carregar conteúdo em seus
servidores de cache hospedados.
Esse procedimento é opcional porque você não precisa pré-hash e pré-carregar conteúdo em seus servidores
de cache hospedados.
Se você não pré-carregar o conteúdo, os dados serão adicionados ao cache hospedado automaticamente à
medida que os clientes - os baixarem pela conexão WAN.
Você deve ser membro do grupo Administradores para executar esse procedimento.
3. Se você tiver mais de um servidor de cache hospedado no qual deseja pré-carregar conteúdo, execute
este procedimento em cada servidor de cache hospedado.
Para continuar com este guia, consulte Configure Client Automatic Hosted Cache Discovery by Service
Connection Point.
Configurar descoberta automática de cache
hospedado cliente por ponto de conexão de serviço
13/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012
com este procedimento, você pode usar Política de Grupo para habilitar e configurar o modo de cache
hospedado do branchcache em - computadores ingressados no domínio que executam os - sistemas
operacionais compatíveis Windows com o branchcache a seguir.
Windows 10 Enterprise
Windows 10 Education
Windows 8.1 Enterprise
O Windows 8 Enterprise
NOTE
para configurar computadores ingressados no domínio que executam o Windows server 2008 R2 ou Windows 7, consulte
o guia de implantação do BranchCachedo Windows Server 2008 R2.
NOTE
Por padrão, os computadores cliente armazenam em cache o conteúdo de servidores de arquivos se a latência de
rede de ida e volta for maior que 80 milissegundos.
12. Para configurar a quantidade de espaço em disco alocado em cada computador cliente para o cache do
BranchCache: no console do Editor de Gerenciamento de Política de Grupo, verifique se o BranchCache
ainda está selecionado e, no painel de detalhes, clique duas vezes - em definir percentual de espaço
em disco usado para o cache do computador cliente . A caixa de diálogo Definir a porcentagem
do espaço em disco usada pelo cache do computador cliente é aberta. Clique em Habilitado e,
em Opções , digite um valor numérico que represente a porcentagem de espaço no disco rígido usado
em cada computador cliente para o cache do BranchCache. Clique em OK .
13. Para especificar a idade padrão, em dias, para quais segmentos são válidos no cache de dados do
BranchCache em computadores cliente: no console do Editor de Gerenciamento de Política de Grupo,
verifique se o BranchCache ainda está selecionado e, no painel de detalhes, clique duas vezes em -
definir idade para segmentos no cache de dados . A caixa de diálogo definir idade para
segmentos na cache de dados é aberta. Clique em habilitado e, no painel de detalhes, digite o
número de dias que você preferir. Clique em OK .
14. Defina configurações adicionais de política de BranchCache para computadores cliente, conforme
apropriado para sua implantação.
15. Atualize Política de Grupo nos computadores cliente da filial executando o comando gpupdate/force ou
reinicializando os computadores cliente.
A implantação do modo de cache hospedado do BranchCache agora está concluída.
Para obter informações adicionais sobre as tecnologias deste guia, consulte recursos adicionais.
Recursos adicionais do BranchCache
10/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012
Para obter mais informações sobre as tecnologias discutidas neste guia, consulte os seguintes recursos:
BranchCache no Windows Server 2016
Instalar e configurar servidores de conteúdo
Shell de rede do BranchCache e comandos do Windows PowerShell
Política de Grupo visão geral do Windows Server 2012 R2
Windows Guia de implantação do BranchCache do Server 2008 R2
BranchCache
12/08/2021 • 34 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este tópico, que é direcionado a profissionais de TI (tecnologia da informação), fornece informações gerais sobre
o BranchCache, incluindo os modos, os recursos e as capacidades do BranchCache, bem como a funcionalidade
do BranchCache disponível em sistemas operacionais diferentes.
NOTE
Além deste tópico, a seguinte documentação do BranchCache está disponível.
Shell de rede do BranchCache e comandos do Windows PowerShell
Guia de Implantação do BranchCache
O que é BranchCache?
o BranchCache é uma tecnologia de otimização de largura de banda de WAN (rede de longa distância) incluída
em algumas edições dos sistemas operacionais Windows Server 2016 e Windows 10, bem como em algumas
edições do Windows Server 2012 r2, Windows 8.1, Windows Server 2012, Windows 8, Windows Server 2008
R2 e Windows 7. Para otimizar a largura de banda de WAN quando os usuários acessam conteúdo em
servidores remotos, o BranchCache busca o conteúdo dos servidores de conteúdo da matriz ou da nuvem
hospedada e o armazena em cache nas filiais, permitindo que os computadores cliente das filiais acessem o
conteúdo localmente e não pela WAN.
em filiais, o conteúdo é armazenado em servidores que estão configurados para hospedar o cache ou, quando
nenhum servidor está disponível na filial, em computadores cliente que executam Windows 10, Windows 8.1,
Windows 8 ou Windows 7. Depois que um computador cliente solicitar e receber o conteúdo da matriz e o
conteúdo for armazenado em cache na filial, outros computadores da mesma filial poderão obter o conteúdo
localmente em vez baixar o conteúdo do servidor de conteúdo pelo link WAN.
Quando solicitações subsequentes do mesmo conteúdo são realizadas pelos computadores clientes, são
baixadas do servidor informações sobre o conteúdo em vez do conteúdo propriamente dito. As informações de
conteúdo consistem em hashes calculados usando partes do conteúdo original. Elas são extremamente
pequenas quando comparadas ao conteúdo nos dados originais. Os computadores clientes usam as
informações de conteúdo para localizar o conteúdo de um cache na filial, esteja ela localizada em um
computador cliente ou servidor. Os computadores clientes e servidores também usam informações de conteúdo
para proteger conteúdo em cache, de modo que ele não possa ser acessado por usuários não autorizados.
O BranchCache aumenta a produtividade dos usuários finais, melhorando os tempos de resposta a consultas de
conteúdo para clientes e servidores em filiais. Além disso, ele também pode ajudar a aprimorar o desempenho
de rede por meio da redução do tráfego por links WAN.
Modos do BranchCache
O BranchCache tem dois modos de operação: o modo de cache distribuído e o modo de cache hospedado.
Quando você implanta o BranchCache no modo de cache distribuído, o cache de conteúdo na filial é distribuída
entre os computadores clientes.
Quando você implanta o BranchCache no modo de cache hospedado, o cache de conteúdo em uma filial é
hospedado em um ou mais servidores, que são chamados de servidores de cache hospedado.
NOTE
Você pode implantar o BranchCache usando os dois modos, mas apenas um deles pode ser usado por filial. Por exemplo,
se você tiver duas filiais, uma com um servidor e outra sem, será possível implantar o BranchCache no modo de cache
hospedado no escritório que possui o servidor e implantar a solução no modo de cache distribuído no escritório que tem
apenas computadores clientes.
Se você usa o BranchCache para cache SMB de arquivos e pastas, não desabilite Arquivos Offline. Se você
desabilitar Arquivos Offline, o cache SMB do BranchCache não funcionará corretamente.
NOTE
Somente o conteúdo de origem, ou seja, o conteúdo que os computadores cliente obtêm inicialmente de um servidor de
conteúdo habilitado para BranchCache, é acelerado pelo BranchCache. O conteúdo que os computadores clientes obtêm
diretamente de outras origens, como servidores Web na Internet ou Windows Update, não é armazenado em cache por
computadores clientes ou servidores de cache hospedado, nem compartilhado com outros computadores na filial. no
entanto, se você quiser acelerar o conteúdo do Windows Update, poderá instalar um servidor de aplicativos do Windows
Server Update Services (WSUS) em seu escritório principal ou na nuvem data center e configurá-lo como um servidor de
conteúdo do BranchCache.
Servidores Web
os servidores Web com suporte incluem computadores que executam o Windows Server 2016, Windows
Server 2012 R2, Windows Server 2012 ou Windows Server 2008 R2 que têm a função de servidor servidor
Web (IIS) instalada e que usam http (Hypertext Transfer Protocol) ou http Secure (HTTPS).
Além disso, o servidor Web deve ter o recurso BranchCache instalado.
Servidores de arquivos
os servidores de arquivos com suporte incluem computadores que executam o Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012 ou Windows Server 2008 R2 que têm a função de servidor
serviços de arquivos e o BranchCache para o serviço de função de arquivos de rede instalados.
Esses servidores de arquivos usam o protocolo SMB (Server Message Block) para trocar informações entre
computadores. Depois de concluir a instalação do servidor de arquivos, você também deve compartilhar pastas
e habilitar a geração de hash para pastas compartilhadas usando a Política de Grupo ou Política de Grupo Local
para habilitar o BranchCache.
Servidores de aplicativos
os servidores de aplicativos com suporte incluem computadores que executam o Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012 ou Windows Server 2008 R2 com o Serviço de Transferência
Inteligente em Segundo Plano (BITS) instalado e habilitado.
Além disso, o servidor de aplicativos deve ter o recurso BranchCache instalado. como exemplos de servidores
de aplicativos, você pode implantar o Microsoft Windows Server Update Services (WSUS) e Microsoft Endpoint
Configuration Manager servidores de ponto de distribuição de ramificação como servidores de conteúdo do
BranchCache.
BranchCache na nuvem
A nuvem tem um grande potencial de redução das despesas operacionais e obtenção de novos níveis de
dimensionamento. Porém, afastar as cargas de trabalho das pessoas que dependem delas podem aumentar os
custos de rede e prejudicar a produtividade. Os usuários esperam alto desempenho e não se preocupam onde
seus aplicativos e dados estão hospedados.
O BranchCache pode aprimorar o desempenho de aplicativos em rede e reduzir o consumo de largura de banda
com um cache compartilhado de dados. Ele aumenta a produtividade em filiais e matrizes, nas quais os
funcionários usam servidores implantados na nuvem.
Como o BranchCache não exige novo hardware nem mudanças na topologia de rede, ele é uma solução
excelente para melhorar as comunicações entre matrizes em nuvens privadas ou públicas.
NOTE
Como alguns proxies da Web não podem processar cabeçalhos de codificação de conteúdo não padrão, é recomendável
que você use o BranchCache com o protocolo HTTPS e não HTTP.
= = = = = = = para obter mais informações sobre as tecnologias de nuvem no Windows Server 2016, consulte
rede definida pelo Software (SDN).
NOTE
Na tabela a seguir, o acrônimo "so" significa sistema operacional.
VERSÕ ES DA S
SIST EM A O P ERA C IO N A L SO DE SERVIDO R DE SO DE SERVIDO R DE C A C H E IN F O RM A Ç Õ ES DE
C L IEN T E C O N T EÚDO H O SP EDA DO C O N T EÚDO
Quando você tem servidores de conteúdo e servidores de cache hospedados que executam Windows Server
2016, Windows Server 2012 R2 e Windows Server 2012, eles usam a versão de informações de conteúdo
apropriada com base no sistema operacional do cliente BranchCache que solicita informações.
Quando computadores que executam Windows Server 2012 e Windows 8 ou sistemas operacionais posteriores
solicitam conteúdo, o conteúdo e os servidores de cache hospedados usam informações de conteúdo V2;
Quando computadores que executam Windows Server 2008 R2 e Windows 7 solicitam conteúdo, o conteúdo e
os servidores de cache hospedados usam informações de conteúdo V1.
IMPORTANT
Quando você implanta o BranchCache no modo de cache distribuído, os clientes que utilizam versões de informações de
conteúdo diferentes não compartilham conteúdo uns com os outros. Por exemplo, um computador cliente executando
Windows 7 e um computador cliente executando Windows 10 que estão instalados na mesma filial não compartilham
conteúdo entre si.
IN STA L A R EST E EL EM EN TO DO
F UN C IO N A L IDA DE LO C A L N O C O M P UTA DO R B RA N C H C A C H E
Servidor de arquivos ( de conteúdo Matriz ou datacenter na nuvem Serviço de função BranchCache para
usando o protocolo SMB) Arquivos de Rede da função de
servidor Serviços de Arquivo
IN STA L A R EST E EL EM EN TO DO
F UN C IO N A L IDA DE LO C A L N O C O M P UTA DO R B RA N C H C A C H E
Para instalar o serviço de função ou o recurso, abra o Gerenciador do Servidor e selecione os computadores nos
quais deseja habilitar a funcionalidade BranchCache. No Gerenciador do Servidor, clique em Gerenciar e depois
em Adicionar Funções e Recursos . O assistente Adicionar Funções e Recursos será aberto. Conforme
executa o assistente, faça as seguintes seleções:
Na página do assistente Selecione o tipo de instalação , selecione Instalação Baseada em Função
ou Recursos .
Na página do assistente Selecione Funções de Servidor , se você estiver instalando um servidor de
arquivos habilitado para BranchCache, expanda Serviços de Arquivo e Armazenamento e Arquivo e
Ser viços iSCSI e selecione BranchCache para Arquivos de Rede . Para economizar espaço em disco,
você também pode selecionar o serviço de função Deduplication de Dados e, em seguida, continuar por
meio do assistente para instalação e conclusão. Se você não quiser instalar um servidor de arquivos
habilitado para BranchCache, não instale a função Arquivo e serviços Armazenamento com o serviço de
função BranchCache para Arquivos de Rede.
Na página do assistente Selecione recursos , se você estiver instalando um servidor de conteúdo que não
seja um servidor de arquivos ou estiver instalando um servidor de cache hospedado, selecione
BranchCache e, em seguida, continue por meio do assistente para instalação e conclusão. Se não quiser
instalar um servidor de conteúdo além do servidor de arquivos ou um servidor de cache hospedado, não
instale o recurso BranchCache.
NOTE
O BranchCache não está disponível por padrão nos sistemas operacionais Windows Server 2008 ou Windows Vista.
Nesses sistemas operacionais, no entanto, se você baixar e instalar a atualização Windows Management Framework, a
funcionalidade BranchCache estará disponível somente para o protocolo BITS (Serviço de Transferência Inteligente em
Segundo Plano). Para obter mais informações e para baixar Windows Management Framework, consulte Windows
Management Framework (Windows PowerShell 2.0, WinRM 2.0 e BITS 4.0) em https://go.microsoft.com/fwlink/?
LinkId=188677 .
Segurança do BranchCache
O BranchCache implementa uma abordagem segura por design, que trabalha de forma ininterrupta juntamente
com as arquiteturas de segurança de rede existentes, dispensando outros equipamentos ou configurações de
segurança adicionais complexas.
O BranchCache não é invasivo e não altera processo de autenticação ou autorização do Windows. Após a
implantação do BranchCache, a autenticação ainda é realizada usando credenciais de domínio, e o modo no qual
a organização com ACLs (listas de controle de acesso) funciona é inalterado. Além disso, outras configurações
continuam a funcionar do mesmo modo antes da implantação do BranchCache.
O modelo de segurança do BranchCache é baseado na criação de metadados, que assumem a forma de uma
série de hashes. Esses hashes também são chamados de informações de conteúdo.
Depois que as informações de conteúdo são criadas, elas são usadas em trocas de mensagens do BranchCache
no lugar dos dados reais e são trocadas usando os protocolos com suporte (HTTP, HTTPS e SMB).
Os dados em cache permanecem criptografados e não podem ser acessados por clientes sem permissão de
acesso a conteúdo da origem original. Os clientes devem ser autenticados e autorizados pela origem de
conteúdo original antes que possam recuperar metadados de conteúdo. Além disso, eles devem possuir
metadados de conteúdo para acessar o cache no escritório local.
Como o BranchCache gera as informações de conteúdo
Como as informações de conteúdo são criadas a partir de vários elementos, seu valor é sempre único. Esses
elementos são:
O conteúdo real (como páginas da Web ou arquivos compartilhados) do qual os hashes são derivados.
Parâmetros de configuração, como algoritmo de hash e tamanho do bloco. Para gerar informações de
conteúdo, o servidor divide o conteúdo em segmentos e os subdivide em blocos. O BranchCache usa
hashes criptográficos seguros para identificar e verificar cada bloco e segmento, com suporte ao
algoritmo de hash SHA256.
Um segredo do servidor. Todos os servidores de conteúdo devem ser configurados com um segredo do
servidor, que é um valor binário de comprimento arbitrário.
NOTE
O uso de um segredo do servidor garante que os computadores clientes não são capazes de gerar informações de
conteúdo por conta própria. Isso evita que usuários mal-intencionados usem ataques de força bruta com computadores
clientes habilitados pelo BranchCache para detectar alterações pequenas no conteúdo entre versões diferentes, em
situações em que o cliente tinha acesso a uma verão anterior, mas não tem acesso à versão atual.
A principal ameaça nesta camada é o risco para o segredo de segmento, mas o BranchCache criptografa os
blocos de dados de conteúdo para protegê-lo. O BranchCache faz isso usando a chave de criptografia derivada
do segredo do segmento de conteúdo no qual os blocos de conteúdo estão localizados.
Essa abordagem garante que uma entidade que não possua o segredo de segmento não possa descobrir o
conteúdo real em um bloco de dados. O segredo de segmento é tratado com o mesmo nível de segurança que o
segmento em texto não criptografado, pois o conhecimento do segredo de um determinado segmento permite
que uma entidade obtenha o segmento a partir de pares e o descriptografe. O conhecimento do segredo de
servidor não produz texto não criptografados, mas pode ser usado paras derivar certos tipos de dados do texto
codificado e possivelmente expor dados parcialmente conhecidos a um ataque de adivinhação pro força bruta.
Por isso, o segredo de servidor deve ser confidencial.
Processos do BranchCache: localizar conteúdo
Depois que as informações de conteúdo são recebidas pelo computador cliente, o cliente usa o ID do segmento
para localizar o conteúdo solicitado no cache local da filial, esteja ele distribuído entre computadores clientes ou
localizado em um servidor de cache hospedado.
Se o computador cliente estiver configurado para o modo de cache hospedado, ele será configurado com o
nome do computador do servidor de cache hospedado e entrará em contato com o servidor para recuperar o
conteúdo.
Porém, se o computador cliente estiver configurado para o modo de cache distribuído, o conteúdo poderá ser
armazenados entre vários caches em diversos computadores da filial. O computador cliente deve descobrir
onde o conteúdo está localizado antes de recuperá-lo.
Quando estão configurados para o modo de cache distribuído, os computadores clientes localizam conteúdo
usando um protocolo de descoberta baseado no protocolo WS-Discovery. Os clientes enviam mensagens de
sondagem multicast WS-Discovery para descobrir conteúdo em cache pela rede. Essas mensagens incluem o ID
do segmento, que permite que os clientes verifique se o conteúdo solicitado corresponde ao armazenado em
cache. Os clientes que recebem a mensagem de sondagem inicial respondem ao cliente da consulta com
mensagens de correspondência de sondagem unicast quando o ID do segmento corresponde ao conteúdo
armazenado em cache local.
Para que o processo WS-Discovery obtenha êxito, o cliente que realiza a descoberta deve ter as informações de
conteúdo corretas (fornecidas pelo servidor de conteúdo) para o conteúdo solicitado.
A ameaça principal aos dados durante a fase de solicitação de conteúdo é a divulgação das informações, pois o
acesso às informações de conteúdo implica em acesso autorizado ao conteúdo. Para eliminar esse risco, o
processo de descoberta não revela as informações de conteúdo, somente o ID do segmento, que não revela
nada sobre o segmento em texto não criptografado com o conteúdo.
Além disso, outro computador cliente executado por um usuário mal-intencionado na mesma sub-rede pode
ver o tráfego de descoberta do BranchCache para a origem de conteúdo original passando pelo roteador.
Se o conteúdo solicitado não for encontrado na filial, o cliente solicitará o conteúdo diretamente do servidor de
conteúdo pelo link WAN.
Depois que o conteúdo é recebido, ele é adicionado ao cache local, seja no computador cliente ou no servidor
de cache hospedado. Nesse caso, as informações de conteúdo evitam que um cliente ou servidor de cache
hospedado adicione ao cache local qualquer conteúdo que não corresponda aos hashes. O processo de
verificação do conteúdo por meio da correspondência de hashes garante que apenas o conteúdo válido seja
adicionado ao cache e a integridade do cache local seja protegida.
NOTE
Se os segmentos de conteúdo completos não existirem em um computador, o protocolo de recuperação recuperará e
constituirá o conteúdo a partir de uma combinação de origens: um conjunto de computadores clientes no modo de cache
distribuído, um servidor de cache hospedado e (se os caches da filial não contiverem o conteúdo completo) o servidor de
conteúdo original da matriz.
IMPORTANT
Os servidores de cache hospedados que estão executando Windows Server 2016, Windows Server 2012 R2 ou
Windows Server 2012 não exigem um certificado de servidor de cache hospedado e uma chave privada associada.
O computador cliente está configurado com o nome de computador do servidor de cache hospedado e o
número da porta TCP por meio da qual esse servidor está escutando o tráfego do BranchCache. O
certificado do servidor de cache hospedado está vinculado a essa porta. O nome de computador do
servidor de cache hospedado poderá ser um FQDN (nome de domínio totalmente qualificado) se o
servidor for um computador membro do domínio, ou um nome NetBIOS do computador se o servidor
não for membro do domínio.
O computador cliente escuta ativamente para detectar solicitações de blocos recebidas. A porta que ele
usa para isso é passada como parte das mensagens de oferta do cliente para o servidor de cache
hospedado. Isso permite que o servidor de cache hospedado use os protocolos do BranchCache para
conectar-se ao computador cliente e recuperar blocos de dados no segmento.
O servidor de cache hospedado começa a escutar para detectar solicitações HTTP recebidas quando é
iniciado.
Se o servidor de cache hospedado estiver configurado para exigir autenticação do computador cliente,
tanto o cliente quanto o servidor deverão dar suporte à autenticação HTTPS.
População de cache do modo de cache hospedado
O processo de adição de conteúdo ao cache do servidor de cache hospedado em uma filial começa quando o
cliente envia um INITIAL_OFFER_MESSAGE, que inclui a ID do segmento. A ID do segmento na solicitação
INITIAL_OFFER_MESSAGE é usada para recuperar o Hash de Dados do segmento correspondente, a lista de
hashes de bloco e o Segredo do Segmento do cache de blocos do servidor de cache hospedado. Se o servidor
de cache hospedado já tiver todas as informações de conteúdo de um segmento específico, a resposta a
INITIAL_OFFER_MESSAGE será OK, e nenhuma solicitação de download de blocos ocorrerá.
Se o servidor de cache hospedado não tiver todos os blocos de dados oferecidos associados aos hashes de
bloco no segmento, a resposta a INITIAL_OFFER_MESSAGE será INTERESTED. Em seguida, o cliente enviará
SEGMENT_INFO_MESSAGE, que descreve o segmento único oferecido. O servidor de cache hospedado
responde com uma mensagem de OK e inicia o download dos blocos ausentes do computador cliente que
realizou a oferta.
O hash de dados do segmento, a lista de hashes de bloco e o segredo de segmento são usados para garantir
que o conteúdo baixado não tenha sido violado nem alterado. Em seguida, os blocos baixados são adicionados
ao cache de bloco do servidor de cache hospedado.
Segurança de cache
Esta seção fornece informações sobre como o BranchCache protege dados em cache em computadores clientes
e servidores de cache hospedado.
Segurança do cache do computador cliente
A maior ameaça aos dados armazenados no BranchCache é a violação. Se um invasor puder violar o conteúdo e
as informações de conteúdo armazenadas em cache, ele poderá usá-los para tentar iniciar um ataque contra os
computadores que usam o BranchCache. Os invasores podem iniciar um ataque inserindo softwares mal-
intencionados no lugar de outros dados. O BranchCache elimina essa ameaça por meio da validação de todo o
conteúdo usando os hashes de bloco encontrados nas informações de conteúdo. Se um invasor tentar realizar
uma violação com esses dados, eles serão descartados e substituídos por dados válidos da origem original.
Uma ameaça secundária aos dados armazenados no BranchCache é a divulgação de informações. No modo de
cache distribuído, o cliente armazena em cache somente o conteúdo que solicitou por conta própria. Porém,
esses dados são armazenados como texto não criptografado e podem correr riscos. Para restringir o acesso ao
cache somente ao serviço BranchCache, o cache local é protegido pelas permissões do sistema de arquivos
especificadas em uma ACL.
Embora a ACL seja eficiente para evitar que usuários não autorizados acessem o cache, é possível que um
usuário com privilégios administrativos obtenha acesso ao cache por meio da alteração manual das permissões
especificadas na ACL. O BranchCache não oferece proteção contra o uso mal-intencionado de uma conta
administrativa.
Os dados armazenados no cache de conteúdo não são criptografados. Por isso, se o vazamento de dados for um
preocupação, use tecnologias como BitLocker ou EFS (Encrypting File System). O cache local usado pelo
BranchCache não aumenta o risco de divulgação de informações trazido por um computador na filial. O cache
contém apenas cópias dos arquivos que permanecem descriptografados em alguma parte do disco.
Criptografar todo o disco é particularmente importante em ambientes em que seja difícil garantir a segurança
física dos clientes. Por exemplo, a criptografia de todo o disco ajuda a proteger dados confidenciais em
computadores móveis que possam ser removidos do ambiente da filial.
Segurança do cache do servidor de cache hospedado
No modo de cache hospedado, a maior ameaça à segurança do servidor de cache hospedado é a divulgação de
informações. Em um ambiente de cache hospedado, o BranchCache comporta-se de modo semelhante ao modo
de cache distribuído, com a permissão do sistema de arquivos protegendo os dados em cache. A diferença é que
o servidor de cache hospedado armazena todo o conteúdo solicitado por qualquer computador habilitado por
BranchCache na filial, em vez de fazer isso apenas com os dados solicitados por um único cliente. As
consequências do acesso não autorizado a esse cache podem ser muito mais sérias, pois há muito mais dados
em risco.
Em um ambiente de cache hospedado em que o servidor de cache hospedado está executando o Windows
Server 2008 R2, o uso de tecnologias de criptografia como BitLocker ou EFS é aconselhável se qualquer um dos
clientes na filial puder acessar dados confidenciais pelo link wan. Também é necessário evitar o acesso físico ao
cache hospedado, pois a criptografia de disco funciona somente quando o computador está desligado no
momento em que o invasor obtém acesso físico. Se o computador estiver ligado ou no modo de suspensão, a
criptografia de disco oferecerá pouca proteção.
NOTE
Os servidores de cache hospedados que estão executando Windows Server 2016, Windows Server 2012 R2 ou Windows
Server 2012 criptografam todos os dados no cache por padrão, portanto, o uso de tecnologias de criptografia adicionais
não é necessário.
Mesmo que um cliente esteja configurado no modo de cache hospedado, ele ainda armazenará dados em cache
localmente. Por isso, convém tomar medidas para proteger o cache local (além do cache no servidor de cache
hospedado).
Shell de rede do BranchCache e comandos do
Windows PowerShell
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
no Windows Server, você pode configurar e gerenciar o BranchCache usando os comandos de Windows
PowerShell ou de Shell de rede (Netsh) para BranchCache.
Nas futuras versões do Windows, a Microsoft poderá remover a funcionalidade do netsh para BranchCache. a
Microsoft recomenda a transição para Windows PowerShell se você usar o netsh no momento para configurar e
gerenciar o BranchCache e outras tecnologias de rede.
As referências dos comandos do Windows PowerShell e do netsh estão nos seguintes locais. embora as duas
referências de comando tenham sido publicadas para sistemas operacionais anteriores a Windows Server 2016,
essas referências são precisas para esse sistema operacional.
Comandos do netsh para BranchCache no Windows Server 2008 R2
Cmdlets de BranchCache no Windows PowerShell
TIP
Para exibir uma lista de comandos do Windows PowerShell para BranchCache no prompt do Windows PowerShell, digite
Get-Command -Module BranchCache no prompt do Windows PowerShell e pressione ENTER.
Guia de Implantação do BranchCache
13/08/2021 • 6 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este guia para aprender a implantar o BranchCache no Windows Server 2016.
Além deste tópico, este guia contém as seções a seguir.
Escolhendo um design do BranchCache
Implantar o BranchCache
NOTE
se você estiver implantando o BranchCache em sistemas operacionais diferentes de Windows Server 2016, os recursos de
documentação a seguir estarão disponíveis.
para obter informações sobre o BranchCache em Windows 8, Windows 8.1, Windows Server 2012 e Windows Server
2012 R2, consulte visão geral do branchcache.
para obter informações sobre o branchcache no Windows 7 e Windows Server 2008 r2, consulte BranchCache para
Windows Server 2008 r2.
Escolher um design para o BranchCache
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para saber mais sobre os modos de BranchCache e para selecionar os melhores
modos para sua implantação.
Você pode usar este guia para implantar o BranchCache nos modos e combinações de modo a seguir.
Todas as filiais são configuradas para o modo de cache distribuído.
Todas as filiais são configuradas para o modo de cache hospedado e têm um servidor de cache
hospedado no site.
Algumas filiais estão configuradas para o modo de cache distribuído e algumas filiais têm um servidor de
cache hospedado no site e são configuradas para o modo de cache hospedado.
A ilustração a seguir descreve uma instalação de modo duplo, com uma filial configurada para o modo de cache
distribuído e uma filial configurada para o modo de cache hospedado.
Antes de implantar o BranchCache, selecione o modo que você prefere para cada filial em sua organização.
Implantar o BranchCache
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
As seções a seguir fornecem informações sobre como implantar o BranchCache em modos de cache
distribuídos e hospedados.
Instalar e configurar servidores de conteúdo
Implantar servidores de cache hospedados (aplicativos)
Pré-hashiing e preloading content on Hosted Cache Servers (opcional)
Configurar computadores cliente BranchCache
NOTE
Os procedimentos deste guia não incluem instruções para os casos em que a caixa de diálogo Controle de Conta de
Usuário é aberta para solicitar sua permissão para continuar. Caso essa caixa de diálogo seja aberta durante a execução
dos procedimentos deste guia e em resposta às suas ações, clique em Continuar .
Instalar e configurar servidores de conteúdo
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Ao implantar o BranchCache no modo de cache distribuído ou no modo de cache hospedado, você deve
implantar um ou mais servidores de conteúdo em seu escritório principal ou na nuvem. Os servidores de
conteúdo que são servidores Web ou servidores de aplicativos usam o recurso BranchCache. Os servidores de
conteúdo que são servidores de arquivos usam o BranchCache para o serviço de função de arquivos de rede da
função de servidor de serviços de arquivo no Windows Server 2016.
Consulte os tópicos a seguir para implantar servidores de conteúdo.
Instalar servidores de conteúdo que usam o recurso BranchCache
Instalar servidores de conteúdo dos serviços de arquivo
Instalar servidores de conteúdo que usam o recurso
BranchCache
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Para implantar servidores de conteúdo que são servidores Web HTTPS (Secure Hypertext Transfer Protocol),
servidores Web HTTP (Protocolo de Transferência de Hipertexto) e servidores de aplicativos baseados em BITS
(Serviço de Transferência Inteligente em Segundo Plano), como servidores do sistema de sites de distribuição
do branch do Windows Server Update Services (WSUS) e do branch do Microsoft Endpoint Configuration
Manager, você deve instalar o recurso BranchCache, iniciar o serviço BranchCache e (somente para servidores
WSUS) executar etapas de configuração adicionais.
Consulte os tópicos a seguir para implantar servidores de conteúdo.
Instalar o recurso BranchCache
Configurar Windows Server Update Services (servidores de conteúdo) WSUS
Instalar o recurso BranchCache
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para instalar o recurso BranchCache e iniciar o serviço BranchCache em um
computador que executa o Windows Server ® 2016, Windows Server 2012 R2 ou Windows Server 2012.
A associação a Administradores ou equivalente é o requisito mínimo para a execução deste procedimento.
Antes de executar este procedimento, é recomendável instalar e configurar seu aplicativo baseado em BITS ou
servidor Web.
NOTE
Para executar esse procedimento usando Windows PowerShell, execute Windows PowerShell como Administrador, digite
os comandos a seguir no prompt Windows PowerShell e pressione ENTER.
Install-WindowsFeature BranchCache
Restart-Computer
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Depois de instalar o recurso BranchCache e iniciar o serviço BranchCache, é necessário configurar os servidores
do WSUS para armazenar arquivos de atualização no computador local.
Ao configurar servidores do WSUS para armazenar arquivos de atualização no computador local, os metadados
de atualização e os arquivos de atualização são baixados e armazenados diretamente no servidor do WSUS. Isso
garante que os computadores cliente BranchCache recebam os arquivos de atualização dos produtos da
Microsoft do servidor do WSUS e não diretamente do site do Microsoft Update.
Para obter mais informações sobre a sincronização do WSUS, consulte Configurando sincronizações de
atualização
Instalar servidores de conteúdo dos Serviços de
Arquivo
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Para implantar servidores de conteúdo que executam a função de servidor de Serviços de Arquivo, instale o
BranchCache para o serviço de função de arquivos de rede da função de servidor de Serviços de Arquivo. Além
disso, você deve habilitar o BranchCache em compartilhamentos de arquivos de acordo com suas necessidades.
Durante a configuração do servidor de conteúdo, você pode permitir a publicação do BranchCache de conteúdo
para todos os compartilhamentos de arquivos ou pode selecionar um subconjunto de compartilhamentos de
arquivos para publicar.
NOTE
Quando você implanta um servidor de arquivos habilitado para BranchCache ou um servidor Web como um servidor de
conteúdo, as informações de conteúdo agora são calculadas offline, bem antes de um cliente do BranchCache solicitar um
arquivo. Por causa dessa melhoria, você não precisa configurar a publicação de hash para servidores de conteúdo, como
fez na versão anterior do BranchCache.
Essa geração automática de hash fornece um desempenho mais rápido e mais economia de largura de banda, pois as
informações de conteúdo estão prontas para o primeiro cliente que solicita o conteúdo, e os cálculos já foram realizados.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para instalar a função de servidor de serviços de arquivo e o BranchCache
para o serviço de função de arquivos de rede em um computador que executa o Windows Server 2016.
A associação a Administradores ou equivalente é o requisito mínimo para a execução deste procedimento.
NOTE
para executar esse procedimento usando Windows PowerShell, execute Windows PowerShell como administrador, digite
os seguintes comandos no prompt de Windows PowerShell e pressione ENTER.
Install-WindowsFeature FS-BranchCache -IncludeManagementTools
Restart-Computer
Para instalar o serviço de função eliminação de duplicação de dados, digite o comando a seguir e pressione ENTER.
Install-WindowsFeature FS-Data-Deduplication -IncludeManagementTools
Para instalar os Serviços de Arquivo e o BranchCache para o serviço de função de arquivos de rede
1. No Gerenciador do Servidor, clique em Gerenciar e depois em Adicionar Funções e Recursos . O
Assistente para Adicionar Funções e Recursos é aberto. Em Antes de Começar , clique em Avançar .
2. Em Selecionar tipo de instalação , verifique se a instalação baseada em função ou em recurso está
selecionada e clique em Avançar .
3. Em selecionar ser vidor de destino , verifique se o servidor correto está selecionado e clique em
Avançar .
4. em selecionar funções de ser vidor , em funções , observe que a função arquivo e ser viços de
Armazenamento já está instalada; Clique na seta à esquerda do nome da função para expandir a
seleção de serviços de função e, em seguida, clique na seta à esquerda de ser viços de arquivo e iSCSI .
5. Marque as caixas de seleção do ser vidor de arquivos e do BranchCache para arquivos de rede .
TIP
É recomendável que você também marque a caixa de seleção para eliminação de duplicação de dados .
Clique em Próximo .
6. Em selecionar recursos , clique em Avançar .
7. Em confirmar seleções de instalação , examine suas seleções e clique em instalar . O painel
progresso da instalação é exibido durante a instalação. Quando a instalação for concluída, clique em
fechar .
Configurar um servidor de arquivos existente como
um servidor de conteúdo
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para instalar o BranchCache para o serviço de função de arquivos de rede
da função de servidor de serviços de arquivo em um computador que executa o Windows Server 2016.
IMPORTANT
Se a função de servidor de Serviços de Arquivo ainda não estiver instalada, não execute este procedimento. Em vez disso,
consulte instalar um novo servidor de arquivos como um servidor de conteúdo.
NOTE
para executar esse procedimento usando Windows PowerShell, execute Windows PowerShell como administrador, digite
os seguintes comandos no prompt de Windows PowerShell e pressione ENTER.
Install-WindowsFeature FS-BranchCache -IncludeManagementTools
Para instalar o serviço de função eliminação de duplicação de dados, digite o comando a seguir e pressione ENTER.
Install-WindowsFeature FS-Data-Deduplication -IncludeManagementTools
TIP
Se você ainda não tiver feito isso, é recomendável marcar também a caixa de seleção para eliminação de
duplicação de dados .
Clique em Próximo .
6. Em selecionar recursos , clique em Avançar .
7. Em confirmar seleções de instalação , examine suas seleções e clique em instalar . O painel
progresso da instalação é exibido durante a instalação. Quando a instalação for concluída, clique em
fechar .
Habilitar publicação de hash para servidores de
arquivos
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
NOTE
Se você tiver vários servidores de arquivos e quiser habilitar a publicação de hash por compartilhamento, em vez de
habilitar a publicação de hash para todos os compartilhamentos, você poderá usar as instruções no tópico habilitar a
publicação de hash para servidores de arquivos não membro do domínio.
Habilitar publicação de hash para servidores de
arquivos do membro que não sejam de domínio
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para configurar a publicação de hash para o BranchCache usando o Política
de Grupo de computador local em um servidor de arquivos que está executando o Windows Server 2016 com o
serviço de função BranchCache para Arquivos de Rede da função de servidor de Serviços de Arquivos
instalada.
Este procedimento se destina ao uso em um servidor de arquivos que não é membro do domínio. Se você
executar este procedimento em um servidor de arquivos membro do domínio e também configurar o
BranchCache usando a Diretiva de Grupo do domínio, as configurações da Diretiva de Grupo do domínio
substituirão as configurações da Diretiva de Grupo local.
A associação a Administradores ou equivalente é o requisito mínimo para a execução deste procedimento.
NOTE
Se você tiver um ou mais servidores de arquivos membro do domínio, poderá adicioná-los a uma UO (unidade
organizacional) nos Serviços de Domínio Active Directory e então usar a Diretiva de Grupo para configurar publicação de
hash para todos os servidores de arquivos de uma vez, em vez de configurar cada servidor de arquivos individualmente.
Para obter mais informações, consulte Habilitar publicação de hash para servidores de arquivos de membro de domínio.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Quando estiver usando Active Directory Domain Services (AD DS), você poderá usar o Política de Grupo de
domínio para habilitar a publicação de hash do BranchCache para vários servidores de arquivos. Para fazer isso,
você deve criar uma UO (unidade organizacional), adicionar servidores de arquivos à UO, criar uma publicação
de hash do BranchCache Política de Grupo objeto (GPO) e, em seguida, configurar o GPO.
Consulte os tópicos a seguir para habilitar a publicação de hash para vários servidores de arquivos.
Criar a unidade organizacional de servidores de arquivos BranchCache
Mover servidores de arquivos para a unidade organizacional de servidores de arquivos BranchCache
Criar o Objeto de Política de Grupo de publicação de hash BranchCache
Configurar o Objeto de Política de Grupo de publicação de hash BranchCache
Criar a unidade organizacional de servidores de
arquivos BranchCache
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para criar uma UO (unidade organizacional) no AD DS (Serviços de Domínio
Active Directory) para servidores de arquivos BranchCache.
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.
Para criar a unidade organizacional de servidores de arquivos BranchCache
1. Em um computador em que o AD DS está instalado, em Gerenciador do Servidor, clique em
ferramentas e, em seguida, clique em Active Director y usuários e computadores . O console de
Usuários e Computadores do Active Directory é aberto.
2. No console de Usuários e Computadores do Active Directory, clique com o botão direito do mouse no
domínio ao qual você deseja adicionar uma UO. Por exemplo, se o domínio for denominado
exemplo.com, clique com o botão direito do mouse em exemplo.com . Aponte para Novo e clique em
Unidade Organizacional . A caixa de diálogo novo objeto – unidade organizacional é aberta.
3. Na caixa de diálogo novo objeto – unidade organizacional , em nome , digite um nome para a nova
UO. Por exemplo, se desejar denominar a UO de Servidores de arquivos BranchCache, digite Ser vidores
de arquivos BranchCache e clique em OK .
Mover servidores de arquivos para a unidade
organizacional de servidores de arquivos
BranchCache
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para adicionar servidores de arquivos BranchCache a uma UO (unidade
organizacional) no AD DS (Serviços de Domínio Active Directory).
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.
NOTE
Você deve criar uma UO de servidores de arquivos BranchCache no console de Usuários e Computadores do Active
Directory antes de adicionar contas de computador à UO com este procedimento. Para obter mais informações, consulte
criar a unidade organizacional de servidores de arquivos do BranchCache.
Para mover servidores de arquivos para a unidade organizacional de servidores de arquivos BranchCache
1. Em um computador em que o AD DS está instalado, em Gerenciador do Servidor, clique em
ferramentas e, em seguida, clique em Active Director y usuários e computadores . O console de
Usuários e Computadores do Active Directory é aberto.
2. No console de Usuários e Computadores do Active Directory, localize a conta de computador de um
servidor de arquivos BranchCache, clique para selecionar a conta e arraste e solte a conta de computador
na UO de servidores de arquivos BranchCache que você criou. Por exemplo, se você criou anteriormente
uma UO denominada ser vidores de arquivos do BranchCache , arraste e solte a conta de
computador na UO servidores de arquivos do BranchCache .
3. Repita a etapa anterior para cada servidor de arquivos BranchCache no domínio que você deseja mover
para a UO.
Criar o Objeto de Política de Grupo de publicação
de hash BranchCache
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para criar a publicação de hash BranchCache Política de Grupo Objeto (GPO).
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.
NOTE
Antes de executar este procedimento, crie a unidade organizacional de servidores de arquivos BranchCache e mova os
servidores de arquivos para a UO. Para obter mais informações, consulte Habilitar publicação de hash para servidores de
arquivos de membro de domínio.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para configurar a publicação de hash do BranchCache Política de Grupo
objeto (GPO) para que todos os servidores de arquivos que você adicionou à sua UO tenham a mesma
configuração de política de publicação de hash aplicada a eles.
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.
NOTE
Antes de executar esse procedimento, você deve criar a unidade organizacional de servidores de arquivos do
BranchCache, mover os servidores de arquivos para a UO e criar o GPO de publicação de hash do BranchCache. Para
obter mais informações, consulte habilitar a publicação de hash para servidores de arquivos do membro do domínio.
NOTE
Na maioria dos casos, é necessário salvar o console MMC e atualizar a exibição para exibir as alterações de configuração
feitas.
Habilitar BranchCache em um compartilhamento de
arquivos (opcional)
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para habilitar o BranchCache em um compartilhamento de arquivos.
IMPORTANT
Você não precisará executar este procedimento se definir a configuração de publicação de hash com o valor Permitir
publicação de hash para todas as pastas compar tilhadas.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para instalar e configurar servidores de cache hospedados do BranchCache
localizados em filiais em que você deseja implantar o modo de cache hospedado do BranchCache. com o
BranchCache no Windows Server 2016, você pode implantar vários servidores de cache hospedados em uma
filial.
IMPORTANT
Essa etapa é opcional porque o modo de cache distribuído não requer um computador de servidor de cache hospedado
em filiais. Se você não estiver planejando implantar o modo de cache hospedado em qualquer filial, não será necessário
implantar um servidor de cache hospedado e não precisará executar as etapas neste procedimento.
Você deve ser membro de Administradores ou equivalente para executar este procedimento.
Para instalar e configurar um servidor de cache hospedado
1. no computador que você deseja configurar como um servidor de cache hospedado, execute o comando a
seguir em um Windows PowerShell prompt para instalar o recurso do BranchCache.
Install-WindowsFeature BranchCache -IncludeManagementTools
2. Configure o computador como um servidor de cache hospedado usando um dos seguintes comandos:
para configurar um computador não ingressado no domínio como um servidor de cache
hospedado, digite o seguinte comando no prompt de Windows PowerShell e pressione ENTER.
Enable-BCHostedServer
3. para verificar a configuração correta do servidor de cache hospedado, digite o seguinte comando no
prompt de Windows PowerShell e pressione ENTER.
Get-BCStatus
NOTE
Depois de executar esse comando, na seção HostedCacheSer verConfiguration , o valor de
HostedCacheSer verIsEnabled será true . Se você tiver configurado um servidor de cache hospedado associado
ao domínio para registrar um SCP (ponto de conexão de serviço) em Active Directory, o valor de
HostedCacheScpRegistrationEnabled será true .
Realizar o hash prévio e o pré-carregamento de
conteúdo em servidores de cache hospedado
(opcionais)
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para forçar a criação de informações de conteúdo – também chamadas de
hashes-em servidores Web e de arquivos habilitados para BranchCache. Você também pode reunir os dados em
arquivos e servidores Web em pacotes que podem ser transferidos para servidores de cache hospedados
remotos. Isso fornece a capacidade de pré-carregar conteúdo em servidores de cache hospedados remotos para
que os dados estejam disponíveis para o primeiro acesso para cliente.
Você deve ser membro de Administradores ou equivalente para executar este procedimento.
Para colocar o conteúdo de pré -hash e pré -carregar o conteúdo em servidores de cache hospedados
1. Faça logon no arquivo ou servidor Web que contém os dados que você deseja pré-carregar e identifique
as pastas e os arquivos que você deseja carregar em um ou mais servidores de cache hospedados
remotamente.
2. execute Windows PowerShell como administrador. Para cada pasta e arquivo, execute o
Publish-BCFileContent comando ou o Publish-BCWebContent comando, dependendo do tipo de servidor
de conteúdo, para disparar a geração de hash e para adicionar dados a um pacote de dados.
3. Depois que todos os dados tiverem sido adicionados ao pacote de dados, exporte-os usando o
Export-BCCachePackage comando para produzir um arquivo de pacote de dados.
4. Mova o arquivo de pacote de dados para os servidores de cache hospedado remoto usando sua opção
de tecnologia de transferência de arquivo. FTP, SMB, HTTP, DVD e discos rígidos portáteis são
Transportações viáveis.
5. Importe o arquivo de pacote de dados nos servidores de cache hospedados remotos usando o
Import-BCCachePackage comando.
Configurar BranchCache em computadores cliente
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar os tópicos a seguir para configurar computadores cliente membros do domínio e não membros
do domínio como clientes de cache distribuído branchCache ou modo de cache hospedado.
Usar Política de Grupo para configurar computadores cliente membro do domínio
Usar Windows PowerShell para configurar computadores cliente que não são membros do domínio
Configurar regras de firewall para membros que não são do domínio para permitir o tráfego do
BranchCache
Verificar o computador cliente Configurações
Usar Política de Grupo para configurar
computadores cliente membro do domínio
07/08/2021 • 5 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Nesta seção, você criará um objeto Política de Grupo para todos os computadores em sua organização,
configurará computadores cliente membro do domínio com o modo de cache distribuído ou o modo de cache
hospedado e configurará o Firewall do Windows com Segurança Avançada para permitir o tráfego do
BranchCache.
Esta seção contém os procedimentos a seguir.
1. Para criar um objeto Política de Grupo e configurar os modos BranchCache
2. Para configurar o firewall Windows com regras de tráfego de entrada de segurança avançada
3. Para configurar o firewall Windows com regras avançadas de tráfego de saída de segurança
TIP
No procedimento a seguir, você é instruído a criar um objeto Política de Grupo na Política de Domínio Padrão, no entanto,
você pode criar o objeto em uma UO (unidade organizacional) ou outro contêiner apropriado para sua implantação.
Você deve ser um membro de Administradores de Domínio ou equivalente para executar esses
procedimentos.
NOTE
Quando você habilita as configurações de política Definir Cache Distribuído do BranchCache e Habilitar
Descoberta Automática de Cache Hospedado por Ponto de Conexão de Serviço, os computadores cliente operam
no modo de cache distribuído branchCache, a menos que encontrem um servidor de cache hospedado na filial,
em que ponto eles operam no modo de cache hospedado.
12. Use os procedimentos a seguir para definir as configurações de firewall em computadores cliente usando
Política de Grupo.
IMPORTANT
Selecione Permitir a conexão para que o cliente BranchCache possa receber o tráfego nesta porta.
8. Para criar uma exceção do firewall do WS-Discovery, clique novamente com o botão direito do mouse em
Regras de Entrada e clique em Nova Regra . O Assistente para Nova Regra de Entrada é aberto.
9. Em Tipo de Regra, clique em Predefinido, expanda a lista de opções e clique em BranchCache –
Descoberta de Pares (Usa WSD). Clique em Próximo .
10. Em Regras Predefinidas , clique em Avançar .
11. Em Ação , verifique se Permitir a conexão está selecionado e clique em Concluir .
IMPORTANT
Selecione Permitir a conexão para que o cliente BranchCache possa receber o tráfego nesta porta.
IMPORTANT
Selecione Permitir a conexão para que o cliente BranchCache possa enviar o tráfego nesta porta.
5. Para criar uma exceção do firewall do WS-Discovery, clique novamente com o botão direito do mouse em
Regras de Saída e clique em Nova Regra . O Assistente para Nova Regra de Saída é aberto.
6. Em Tipo de Regra, clique em Predefinido, expanda a lista de opções e clique em BranchCache –
Descoberta de Pares (Usa WSD). Clique em Próximo .
7. Em Regras Predefinidas , clique em Avançar .
8. Em Ação , verifique se Permitir a conexão está selecionado e clique em Concluir .
IMPORTANT
Selecione Permitir a conexão para que o cliente BranchCache possa enviar o tráfego nesta porta.
usar Windows PowerShell para configurar
computadores cliente que não são membros do
domínio
07/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para configurar manualmente um computador cliente do BranchCache para
o modo de cache distribuído ou o modo de cache hospedado.
NOTE
Se você configurou computadores cliente BranchCache usando a Diretiva de Grupo, as configurações da Diretiva de
Grupo substituirão qualquer configuração manual de computadores cliente aos quais as diretivas foram aplicadas.
Para configurar o computador cliente para o modo de cache hospedado do BranchCache, digite o
comando a seguir e pressione ENTER.
Enable-BCHostedClient
TIP
Se você quiser especificar os servidores de cache hospedados disponíveis, use o -ServerNames
parâmetro com uma lista separada por vírgulas de seus servidores de cache hospedados como o valor do
parâmetro. Por exemplo, se você tiver dois servidores de cache hospedados chamados HCS1 e HCS2,
configure o computador cliente para o modo de cache hospedado com o comando a seguir.
Enable-BCHostedClient -ServerNames HCS1,HCS2
Configurar regras de firewall para membros não
associados a domínio para permitir tráfego
BranchCache
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar as informações neste tópico para configurar produtos de firewall de terceiros e configurar um
computador cliente manualmente com regras de firewall que permitam a execução do BranchCache no modo
de cache distribuído.
NOTE
Se você configurou computadores cliente BranchCache usando a Diretiva de Grupo, as configurações da Diretiva de
Grupo substituirão qualquer configuração manual de computadores cliente aos quais as diretivas foram aplicadas.
Se você implantou o BranchCache com DirectAccess, pode usar as configurações deste tópico para configurar regras
de IPsec para permitir o tráfego de BranchCache.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para verificar se o computador cliente está configurado corretamente para
BranchCache.
NOTE
Este procedimento inclui etapas para atualizar manualmente Política de Grupo e para reiniciar o serviço do BranchCache.
Não será necessário executar essas ações se você reinicializar o computador, pois eles ocorrerão automaticamente nessa
circunstância.
Você deve ser membro de Administradores ou equivalente para executar este procedimento.
Para verificar as configurações do computador cliente do BranchCache
1. para atualizar Política de Grupo no computador cliente cuja configuração do BranchCache você deseja
verificar, execute Windows PowerShell como administrador, digite o comando a seguir e pressione
ENTER.
gpupdate /force
2. Para computadores cliente configurados no modo de cache hospedado e são configurados para
descobrir automaticamente servidores de cache hospedados pelo ponto de conexão de serviço, execute
os seguintes comandos para parar e reiniciar o serviço do BranchCache.
net stop peerdistsvc
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para obter uma breve visão geral do DirectAccess, incluindo os sistemas
operacionais de servidor e cliente que dão suporte ao DirectAccess e links para a documentação adicional do
DirectAccess para Windows Server 2016.
NOTE
Além deste tópico, a seguinte documentação do DirectAccess está disponível.
caminhos de implantação do directaccess no servidor Windows
Pré-requisitos para implantação do DirectAccess
Configurações do DirectAccess sem suporte
Guias de laboratório de teste do DirectAccess
Problemas conhecidos do DirectAccess
Planejamento de capacidade do DirectAccess
Ingresso no domínio offline do DirectAccess
Como solucionar problemas do DirectAccess
Implantar um único servidor DirectAccess usando o assistente de Introdução
Implantar um único servidor do DirectAccess com configurações avançadas
Adicionar o DirectAccess a uma implantação de acesso remoto existente (VPN)
O DirectAccess permite a conectividade para usuários remotos para recursos de rede da organização sem a
necessidade de conexões de VPN (rede virtual privada) tradicionais. Com as conexões do DirectAccess, os
computadores cliente remotos são sempre conectados à sua organização – não há necessidade de que os
usuários remotos iniciem e parem conexões, como é necessário com conexões VPN. Além disso, os
administradores de ti podem gerenciar computadores cliente do DirectAccess sempre que estiverem em
execução e conectados à Internet.
IMPORTANT
Não tente implantar o acesso remoto em uma VM de máquina ( virtual ) no Microsoft Azure. não há suporte para o uso
do acesso remoto no Microsoft Azure. você não pode usar o acesso remoto em uma VM do Azure para implantar VPN,
directaccess ou qualquer outro recurso de acesso remoto no Windows Server 2016 ou em versões anteriores do
Windows Server. para obter mais informações, consulte suporte de software de servidor da Microsoft para máquinas
virtuais Microsoft Azure.
O DirectAccess fornece suporte apenas para clientes ingressados no domínio que incluem suporte ao sistema
operacional para o DirectAccess.
Os sistemas operacionais de servidor a seguir dão suporte ao DirectAccess.
você pode implantar todas as versões do Windows Server 2016 como um cliente directaccess ou um
servidor directaccess.
você pode implantar todas as versões do Windows Server 2012 R2 como um cliente directaccess ou um
servidor directaccess.
você pode implantar todas as versões do Windows Server 2012 como um cliente directaccess ou um
servidor directaccess.
você pode implantar todas as versões do Windows Server 2008 R2 como um cliente directaccess ou um
servidor directaccess.
Os sistemas operacionais cliente a seguir dão suporte ao DirectAccess.
Windows 10 Enterprise
Windows 10 Enterprise 2015 Branch de Manutenção em Longo Prazo (LTSB)
Windows 8 e 8,1 Enterprise
Windows 7 Ultimate
Windows 7 Enterprise
Sistema de nome de domínio (DNS)
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
O DNS (sistema de nomes de domínio) é um dos pacotes padrão do setor de protocolos que compõem TCP/IP
e, juntos, o cliente DNS e o servidor DNS fornecem serviços de resolução de nomes de nome de computador
para os computadores e usuários.
NOTE
Além deste tópico, o conteúdo DNS a seguir está disponível.
O que há de novo no cliente DNS
O que há de novo no servidor DNS
Guia de cenário de política DNS
vídeo: Windows Server 2016: gerenciamento de DNS em IPAM
no Windows Server 2016, o DNS é uma função de servidor que você pode instalar usando Gerenciador do
Servidor ou Windows PowerShell comandos. Se você estiver instalando um novo Active Directory floresta e
domínio, o DNS será instalado automaticamente com Active Directory como o servidor de catálogo global para
a floresta e o domínio.
Active Directory Domain Services (AD DS) usa o DNS como seu mecanismo de localização do controlador de
domínio. Quando qualquer uma das principais operações de Active Directory é executada, como autenticação,
atualização ou pesquisa, os computadores usam o DNS para localizar Active Directory controladores de
domínio. Além disso, os controladores de domínio usam o DNS para localizar um ao outro.
o serviço cliente DNS está incluído em todas as versões de cliente e servidor do sistema operacional Windows e
está sendo executado por padrão na instalação do sistema operacional. Quando você configura uma conexão de
rede TCP/IP com o endereço IP de um servidor DNS, o cliente DNS consulta o servidor DNS para descobrir
controladores de domínio e para resolver nomes de computador para endereços IP. Por exemplo, quando um
usuário de rede com uma conta de usuário Active Directory faz logon em um domínio Active Directory, o
serviço cliente DNS consulta o servidor DNS para localizar um controlador de domínio para o domínio de
Active Directory. Quando o servidor DNS responde à consulta e fornece o endereço IP do controlador de
domínio para o cliente, o cliente entra em contato com o controlador de domínio e o processo de autenticação
pode começar.
o Windows Server 2016 servidor dns e os serviços cliente dns usam o protocolo dns que está incluído no
pacote de protocolo TCP/IP. O DNS faz parte da camada de aplicativo do modelo de referência TCP/IP, conforme
mostrado na ilustração a seguir.
Novidades no cliente DNS no Windows Server 2016
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este tópico descreve a funcionalidade do cliente DNS (Sistema de Nomes de Domínio) que é nova ou alterada
no Windows 10 e Windows Server 2016 e versões posteriores desses sistemas operacionais.
NOTE
Alterações no serviço cliente DNS no Windows 10 também estão presentes em computadores que executam Windows
Server 2016 e versões posteriores.
Referências adicionais
Novidades do servidor DNS no Windows Server 2016
o que há de novo no servidor DNS no Windows
server
13/08/2021 • 9 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este tópico descreve a funcionalidade de servidor DNS (sistema de nomes de domínio) que é nova ou alterada
no Windows Server 2016.
no Windows Server 2016, o servidor DNS oferece suporte aprimorado nas seguintes áreas.
Limitação de taxa de resposta (RRL) Novo Você pode habilitar a limitação da taxa
de resposta em seus servidores DNS.
Ao fazer isso, você evita a possibilidade
de sistemas mal-intencionados que
usam seus servidores DNS para iniciar
um ataque de negação de serviço em
um cliente DNS.
Suporte a registro desconhecido Novo você pode adicionar registros que não
são explicitamente suportados pelo
servidor DNS Windows usando a
funcionalidade de registro
desconhecida.
F UN C IO N A L IDA DE N O VO O U M EL H O RA DO DESC RIÇ Ã O
Políticas de DNS
Você pode usar a política DNS para gerenciamento de tráfego baseado em Geo-Location, respostas de DNS
inteligente com base na hora do dia, para gerenciar um único servidor DNS configurado para implantação de
divisão - Brain, aplicação de filtros em consultas DNS e muito mais. Os itens a seguir fornecem mais detalhes
sobre esses recursos.
Balanceamento de carga do aplicativo. Quando você implantou várias instâncias de um aplicativo
em locais diferentes, você pode usar a política DNS para balancear a carga de tráfego entre as diferentes
instâncias de aplicativo, alocando dinamicamente a carga de tráfego para o aplicativo.
-Gerenciamento de tráfego baseado na localização geográfica. Você pode usar a política DNS
para permitir que servidores DNS primários e secundários respondam a consultas de cliente DNS com
base na localização geográfica do cliente e do recurso ao qual o cliente está tentando se conectar,
fornecendo ao cliente o endereço IP do recurso mais próximo.
DNS de divisão de cérebro. Com - o DNS de divisão Brain, os registros DNS são divididos em escopos
de zona diferentes no mesmo servidor DNS, e os clientes DNS recebem uma resposta com base no fato
de os clientes serem clientes internos ou externos. Você pode configurar o - DNS de divisão de cérebro
para Active Directory zonas integradas ou para zonas em servidores DNS autônomos.
Aplica. Você pode configurar a política DNS para criar filtros de consulta baseados em critérios
fornecidos por você. Os filtros de consulta na política DNS permitem configurar o servidor DNS para
responder de uma maneira personalizada com base na consulta DNS e no cliente DNS que envia a
consulta DNS.
Análises forenses. Você pode usar a política DNS para redirecionar clientes DNS mal-intencionados
para um - endereço IP não existente em vez de direcioná-los para o computador que estão tentando
acessar.
Hora do redirecionamento com base no dia. Você pode usar a política DNS para distribuir o tráfego
de aplicativos em diferentes instâncias distribuídas geograficamente de um aplicativo usando políticas de
DNS com base na hora do dia.
Você também pode usar políticas de DNS para Active Directory zonas DNS integradas.
Para obter mais informações, consulte o Guia de cenários de política de DNS.
Suporte ao SUNDANÊS
Você pode usar o tipo de suporte ( do sundanês RFC 6394 e 6698 ) para especificar para seus clientes DNS qual
AC eles devem esperar que os certificados sejam emitidos para os nomes de domínios hospedados no seu
servidor DNS. Isso impede uma forma de ataque man-in-the-Middle, em que alguém é capaz de corromper um
cache DNS e apontar um nome DNS para seu próprio endereço IP.
Por exemplo, imagine que você hospede um site seguro que usa SSL em www.contoso.com usando um
certificado de uma autoridade bem conhecida chamada CA1. Alguém ainda poderá obter um certificado para
www.contoso.com de uma autoridade de certificação diferente, e não tão conhecida, denominada CA2. Em
seguida, a entidade que hospeda o site da www.contoso.com falsa pode ser capaz de corromper o cache DNS de
um cliente ou servidor para apontar www.contoto.com para seu site falso. O usuário final receberá um
certificado de CA2 e poderá simplesmente refirmá-lo e conectar-se ao site falso. Com o SUNDANÊS, o cliente
fará uma solicitação ao servidor DNS para contoso.com solicitando o registro TLSA e aprenderia que o
certificado para www.contoso.com foi emitido por CA1. Se for apresentado um certificado de outra CA, a
conexão será anulada.
Referências adicionais
O que há de novo no cliente DNS
Cliente DNS seguro via HTTPS (DoH)
12/08/2021 • 4 minutes to read
A partir do Windows Server 2022, o cliente DNS dá suporte a DNS sobre HTTPS (DoH). Quando o DoH está
habilitado, as consultas DNS entre o cliente DNS do Windows Server e o servidor DNS passam por uma
conexão HTTPS segura em vez de em texto sem-texto. Ao passar a consulta DNS em uma conexão criptografada,
ela é protegida contra interceptação por terceiros nãotrudos.
4. Na tela Rede, role para baixo até as configurações de DNS e selecione o botão Editar.
5. Na tela Editar configurações de DNS, selecione Manual na lista de configurações de IP automáticas ou
manuais. Essa configuração permite que você configure os servidores DNS preferenciais e DNS
alternativos. Se os endereços desses servidores estão presentes na lista de servidores DoH conhecidos, o
menu suspenso Criptografia DNS preferencial será habilitada. Você pode escolher entre as seguintes
configurações para definir a criptografia DNS preferencial:
Somente criptografado (DNS sobre HTTPS) . Quando essa configuração for escolhida, todo o
tráfego de consulta DNS passará por HTTPS. Essa configuração fornece a melhor proteção para o
tráfego de consulta DNS. No entanto, isso também significa que a resolução dns não ocorrerá se o
servidor DNS de destino não puder dar suporte a consultas DoH.
Criptografado preferencial, não criptografado permitido. Quando essa configuração for
escolhida, o cliente DNS tentará usar o DoH e, em seguida, retornará para consultas DNS não
criptografadas, se isso não for possível. Essa configuração fornece a melhor compatibilidade para
servidores DNS compatíveis com DoH, mas você não receberá nenhuma notificação se as
consultas DNS são alternados de DoH para texto sem-texto.
Somente não criptografado. Todo o tráfego de consulta DNS para o servidor DNS especificado
não é criptografado. Essa configuração define o cliente DNS para usar consultas DNS de texto
sem-texto simples tradicionais.
Não habilita a opção Exigir DoH para computadores ingressados no domínio, pois Active Directory Domain
Services depende muito do DNS porque o serviço servidor DNS do servidor Windows não dá suporte a
consultas DoH. Se você precisar que o tráfego de consulta DNS Active Directory Domain Services rede seja
criptografado, considere implementar regras de segurança de conexão baseadas em IPsec para proteger esse
tráfego. Confira Proteger conexões IPsec de ponta a ponta usando IKEv2 para obter mais informações.
Cloudflare 1.1.1.1
1.0.0.1
2606:4700:4700::1111
2606:4700:4700::1001
Google 8.8.8.8
8.8.4.4
2001:4860:4860::8888
2001:4860:4860::8844
Quad 9 9.9.9.9
149.112.112.112
2620:fe::fe
2620:fe::fe:9
Aplica-se a: Windows Server 2022, Windows Server 2016 e Windows Server 2019
O que é Anycast?
Anycast é uma tecnologia que fornece vários caminhos de roteamento para um grupo de pontos de
extremidade que são atribuídos a cada um deles o mesmo endereço IP. Cada dispositivo no grupo anuncia o
mesmo endereço em uma rede e os protocolos de roteamento são usados para escolher qual é o melhor
destino.
O Anycast permite dimensionar um serviço sem estado, como DNS ou HTTP, colocando vários nós atrás do
mesmo endereço IP e usando o roteamento ecmp (caminho múltiplo) de custo igual para direcionar o tráfego
entre esses nós. Anycast é diferente do unicast, no qual cada ponto de extremidade tem seu próprio endereço IP
separado.
2. DC001
3. DC002
Diagrama de resumo
Figura 2: Configuração do laboratório para demonstração nativa do DNS Anycast do BGP
NOTE
Se o ping falhar, verifique também se não há regras de firewall bloqueando ICMP.
3. No client1 e client2, use nslookup ou dig para consultar o registro TXT. Exemplos de ambos são
mostrados abaixo.
PS C: > dig server.zone.tst TXT +short
PS C: > nslookup -type=txt server.zone.tst 51.51.51.51
Um cliente exibirá "DC001" e o outro cliente exibirá "DC002" verificando se o Anycast está funcionando
corretamente. Você também pode consultar no servidor de gateway.
4. Em seguida, desabilite o adaptador Ethernet em DC001.
PS C: > (Get-NetAdapter). Nome
Loopback
Ethernet 2
PS C: > Disable-NetAdapter "Ethernet 2"
Confirmar
Tem certeza de que deseja executar essa ação?
Disable-NetAdapter 'Ethernet 2'
[Y] Sim [A] Sim para Todos [N] Não [L] Não para Todos [S] Suspender [?] Ajuda (o padrão é "Y"):
PS C: > (Get-NetAdapter). Status
Up
Desabilitado
5. Confirme se os clientes DNS que estavam recebendo respostas anteriormente do DC001 mudaram para
DC002.
PS C: > nslookup -type=txt server.zone.tst 51.51.51.51
Servidor: Não Conhecido
Endereço: 51.51.51.51
server.zone.tst text =
"DC001"
PS C: > nslookup -type=txt server.zone.tst 51.51.51.51
Servidor: Não Conhecido
Endereço: 51.51.51.51
server.zone.tst text =
"DC002"
6. Confirme se a sessão BGP está ino mesmo no DC001 usando Get-BgpStatistics no servidor de gateway.
7. Habilita o adaptador Ethernet no DC001 novamente e confirme se a sessão BGP foi restaurada e os
clientes receberão respostas DNS do DC001 novamente.
NOTE
Se um balanceador de carga não for usado, um cliente individual usará o mesmo servidor DNS de back-end se ele estiver
disponível. Isso cria um caminho BGP consistente para o cliente. Para obter mais informações, consulte a seção 4.4.3 de
RFC4786: Caminhos de custo igual.
Perguntas frequentes
P: O DNS Anycast é uma boa solução a ser usada em um ambiente DNS local?
R: O DNS Anycast funciona perfeitamente com um serviço DNS local. No entanto, Anycast não é necessário para
que o serviço DNS seja dimensionado.
P: Qual é o impacto da implementação do DNS Anycast em um ambiente com um grande número (por
exemplo, >50) de controladores de domínio?
R: Não há nenhum impacto direto na funcionalidade. Se um balanceador de carga for usado, nenhuma
configuração adicional em controladores de domínio será necessária.
P: Há suporte para uma configuração de DNS Anycast pelo serviço de atendimento ao cliente da Microsoft?
R: Se você usar um balanceador de carga não Microsoft para encaminhar consultas DNS, a Microsoft dará
suporte a problemas relacionados ao serviço servidor DNS. Consulte o fornecedor do balanceador de carga
para problemas relacionados ao encaminhamento de DNS.
P: Qual é a melhor prática para o DNS Anycast com um número grande (por exemplo, >50) de controladores de
domínio?
R: A melhor prática é usar um balanceador de carga em cada localização geográfica. Os balanceadores de carga
normalmente são fornecidos por um fornecedor externo.
P: O DNS anycast e DNS do Azure têm funcionalidade semelhante?
R: DNS do Azure usa Anycast. Para usar o Anycast com DNS do Azure, configure o balanceador de carga para
encaminhar solicitações para o DNS do Azure servidor.
Guia de cenários de política de DNS
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este guia destina-se ao uso pelo DNS, pela rede e pelos administradores de sistemas.
A Política dns é um novo recurso para DNS no Windows Server ® 2016. Você pode usar este guia para
aprender a usar a política DNS para controlar como um servidor DNS processa consultas de resolução de
nomes com base em diferentes parâmetros que você define nas políticas.
Este guia contém informações de visão geral da política DNS, bem como cenários de política DNS específicos
que fornecem instruções sobre como configurar o comportamento do servidor DNS para atingir suas metas,
incluindo o gerenciamento de tráfego baseado em localização geográfica para servidores DNS primários e
secundários, alta disponibilidade de aplicativos, DNS de divisão e muito mais.
Este guia contém as seções a seguir.
Visão geral das políticas dns
Usar política de DNS para gerenciamento de tráfego baseado em localização geográfica com servidores
primários
Usar política de DNS para gerenciamento de tráfego baseado em localização geográfica com implantações
primárias e secundárias
Usar a política de DNS para respostas de DNS inteligente com base na hora do dia
Respostas DNS com base na hora do dia com um Servidor de Aplicativos de Nuvem do Azure
Usar a política DNS para Split-Brain de DNS
Usar a política dns para Split-Brain DNS no Active Directory
Usar a política DNS para aplicar filtros em consultas DNS
Usar a Política de DNS para balanceamento de carga de aplicativo
Usar a Política de DNS para balanceamento de aplicativo com reconhecimento de localização geográfica
Visão geral das políticas de DNS
13/08/2021 • 12 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para saber mais sobre a política DNS, que é nova no Windows Server 2016. Você
pode usar a política DNS para gerenciamento de tráfego baseado em Geo-Location, respostas de DNS
inteligente com base na hora do dia, para gerenciar um único servidor DNS configurado para implantação de
divisão - Brain, aplicação de filtros em consultas DNS e muito mais. Os itens a seguir fornecem mais detalhes
sobre esses recursos.
Balanceamento de carga do aplicativo. Quando você implantou várias instâncias de um aplicativo
em locais diferentes, você pode usar a política DNS para balancear a carga de tráfego entre as diferentes
instâncias de aplicativo, alocando dinamicamente a carga de tráfego para o aplicativo.
-Gerenciamento de tráfego baseado na localização geográfica. Você pode usar a política DNS
para permitir que servidores DNS primários e secundários respondam a consultas de cliente DNS com
base na localização geográfica do cliente e do recurso ao qual o cliente está tentando se conectar,
fornecendo ao cliente o endereço IP do recurso mais próximo.
DNS de divisão de cérebro. Com - o DNS de divisão Brain, os registros DNS são divididos em escopos
de zona diferentes no mesmo servidor DNS, e os clientes DNS recebem uma resposta com base no fato
de os clientes serem clientes internos ou externos. Você pode configurar o - DNS de divisão de cérebro
para Active Directory zonas integradas ou para zonas em servidores DNS autônomos.
Aplica. Você pode configurar a política DNS para criar filtros de consulta baseados em critérios
fornecidos por você. Os filtros de consulta na política DNS permitem configurar o servidor DNS para
responder de uma maneira personalizada com base na consulta DNS e no cliente DNS que envia a
consulta DNS.
Análises forenses. Você pode usar a política DNS para redirecionar clientes DNS mal-intencionados
para um - endereço IP não existente em vez de direcioná-los para o computador que estão tentando
acessar.
Hora do redirecionamento com base no dia. Você pode usar a política DNS para distribuir o tráfego
de aplicativos em diferentes instâncias distribuídas geograficamente de um aplicativo usando políticas de
DNS com base na hora do dia.
Novos conceitos
Para criar políticas para dar suporte aos cenários listados acima, é necessário ser capaz de identificar grupos de
registros em uma zona, grupos de clientes em uma rede, entre outros elementos. Esses elementos são
representados pelos seguintes novos objetos DNS:
Sub-rede do cliente: um objeto de sub-rede de cliente representa uma sub-rede IPv4 ou IPv6 da qual
as consultas são enviadas a um servidor DNS. Você pode criar sub-redes para definir posteriormente as
políticas a serem aplicadas com base em qual sub-rede as solicitações vêm. Por exemplo, em um cenário
de DNS de divisão Brain, a solicitação de resolução para um nome como www.Microsoft.com pode ser
respondida com um endereço IP interno para clientes de sub-redes internas e um endereço IP diferente
para clientes em sub-redes externas.
Escopo da recursão: os escopos de recursão são instâncias exclusivas de um grupo de configurações
que controlam a recursão em um servidor DNS. Um escopo de recursão contém uma lista de
encaminhadores e especifica se a recursão está habilitada. Um servidor DNS pode ter muitos escopos de
recursão. As políticas de recursão do servidor DNS permitem que você escolha um escopo de recursão
para um conjunto de consultas. Se o servidor DNS não for autoritativo para determinadas consultas, as
políticas de recursão do servidor DNS permitirão que você controle como resolver essas consultas. Você
pode especificar quais encaminhadores devem ser usados e se a recursão deve ser usada.
Escopos de zona: uma zona DNS pode ter vários escopos de zona, com cada escopo de zona contendo
seu próprio conjunto de registros DNS. O mesmo registro pode estar presente em vários escopos, com
endereços IP diferentes. Além disso, as transferências de zona são feitas no nível de escopo da zona. Isso
significa que os registros de um escopo de zona em uma zona primária serão transferidos para o mesmo
escopo de zona em uma zona secundária.
Tipos de política
As políticas de DNS são divididas por nível e tipo. Você pode usar as políticas de resolução de consulta para
definir como as consultas são processadas e as políticas de transferência de zona para definir como as
transferências de zona ocorrem. Você pode aplicar cada tipo de política no nível do servidor ou no nível da zona.
Políticas de resolução de consulta
Você pode usar políticas de resolução de consulta DNS para especificar como as consultas de resolução de
entrada são tratadas por um servidor DNS. Cada política de resolução de consulta DNS contém os seguintes
elementos:
Ação Ação a ser executada pelo servidor -Permitir (padrão para nível de zona)
DNS -Deny (padrão no nível do servidor)
-Ignorar
Escopo Lista de escopos de zona e valores -Lista de escopos de zona (por nome)
ponderados por escopo. Valores e pesos
ponderados são usados para
distribuição de balanceamento de
carga. Por exemplo, se essa lista incluir
Datacenter1 com peso de 3 e
datacenter2 com um peso de 5, o
servidor responderá com um registro
de datacentre1 três vezes em oito
solicitações
NOTE
As políticas de nível de servidor só podem ter os valores negar ou ignorar como uma ação.
Sub-rede do cliente Nome de uma sub-rede de cliente - EQ, Espanha, França -resolve para
predefinida. Usado para verificar a sub- verdadeiro se a sub-rede for
rede da qual a consulta foi enviada. identificada como Espanha ou França
- Ne, Canadá, México -resolve para
verdadeiro se a sub-rede do cliente for
qualquer sub-rede diferente do
Canadá e do México
FQDN FQDN do registro na consulta, com a - EQ, www. contoso. com -resolve
possibilidade de usar um curinga para verdadeiro somente se a consulta
estiver tentando resolver o FQDN do
www.contoso.com
- EQ, * . contoso.com, * .
Woodgrove.com -resolve para
verdadeiro se a consulta for para
qualquer registro que termina em *
contoso.com *ou Woodgrove.com
Tipo de consulta Tipo de registro que está sendo - EQ, txt, SRV -resolve para
consultado (A, SRV, TXT) verdadeiro se a consulta estiver
solicitando um registro txt ou SRV
- EQ, MX -resolve para verdadeiro se
a consulta estiver solicitando um
registro MX
NOME DESC RIÇ Ã O VA LO RES DE EXEM P LO
Usando a tabela acima como ponto de partida, a tabela a seguir pode ser usada para definir um critério que é
usado para fazer a correspondência de consultas de qualquer tipo de registro, mas SRV registros no domínio
contoso.com provenientes de um cliente na sub-rede 10.0.0.0/24 via TCP entre 8 e 10 PM por meio da interface
10.0.0.3:
NOME VA LO R
Você pode criar várias políticas de resolução de consulta do mesmo nível, desde que elas tenham um valor
diferente para a ordem de processamento. Quando várias políticas estão disponíveis, o servidor DNS processa
as consultas de entrada da seguinte maneira:
Políticas de recursão
As políticas de recursão são um tipo especial de políticas de nível de servidor. As políticas de recursão
controlam como o servidor DNS executa a recursão para uma consulta. As políticas de recursão se aplicam
somente quando o processamento de consultas atinge o caminho de recursão Você pode escolher um valor de
negar ou ignorar para recursão para um conjunto de consultas. Como alternativa, você pode escolher um
conjunto de encaminhadores para um conjunto de consultas.
Você pode usar políticas de recursão para implementar uma configuração de DNS de divisão-cérebro. Nessa
configuração, o servidor DNS executa a recursão para um conjunto de clientes para uma consulta, enquanto o
servidor DNS não executa recursão para outros clientes para essa consulta.
As políticas de recursão contêm os mesmos elementos que uma política de resolução de consulta DNS regular
contém, juntamente com os elementos na tabela abaixo:
Aplicar na recursão Especifica que essa política só deve ser usada para recursão.
NOTE
As políticas de recursão só podem ser criadas no nível do servidor.
NOTE
As políticas de transferência de zona só podem usar DENY ou IGNORE como ações.
Você pode usar a política de transferência de zona de nível de servidor abaixo para negar uma transferência de
zona para o domínio contoso.com de uma determinada sub-rede:
Você pode criar várias políticas de transferência de zona do mesmo nível, desde que elas tenham um valor
diferente para a ordem de processamento. Quando várias políticas estão disponíveis, o servidor DNS processa
as consultas de entrada da seguinte maneira:
Gerenciando políticas DNS
Você pode criar e gerenciar políticas DNS usando o PowerShell. Os exemplos a seguir passam por diferentes
cenários de exemplo que você pode configurar por meio de políticas de DNS:
Gerenciamento de tráfego
Você pode direcionar o tráfego com base em um FQDN para servidores diferentes, dependendo do local do
cliente DNS. O exemplo a seguir mostra como criar políticas de gerenciamento de tráfego para direcionar os
clientes de uma determinada sub-rede para um datacenter da América do Norte e de outra sub-rede para um
datacenter Europeu.
As duas primeiras linhas do script criam objetos de sub-rede de cliente para América do Norte e Europa. As
duas linhas depois dessa criam um escopo de zona dentro do domínio contoso.com, uma para cada região. As
duas linhas depois dessa criam um registro em cada zona que associa ww.contoso.com a um endereço IP
diferente, um para a Europa, outro para América do Norte. Por fim, as últimas linhas do script criam duas
políticas de resolução de consulta DNS, uma para ser aplicada à sub-rede América do Norte, outra para a sub-
rede da Europa.
Bloquear consultas para um domínio
Você pode usar uma política de resolução de consulta DNS para bloquear consultas a um domínio. O exemplo a
seguir bloqueia todas as consultas para treyresearch.net:
A primeira linha no script cria um objeto de sub-rede chamado AllowedSubnet com o bloqueio de IP
172.21.33.0/24. A segunda linha cria uma política de transferência de zona para permitir transferências de zona
para qualquer servidor DNS na sub-rede criada anteriormente.
Criar uma política de transferência de zona no nível da zona
Você também pode criar políticas de transferência de zona no nível da zona. O exemplo a seguir ignora
qualquer solicitação de transferência de zona para contoso.com provenientes de uma interface de servidor que
tenha um endereço IP de 10.0.0.33:
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para saber como configurar a política DNS para permitir que servidores DNS
primários respondam a consultas de cliente DNS com base na localização geográfica do cliente e do recurso ao
qual o cliente está tentando se conectar, fornecendo ao cliente o endereço IP do recurso mais próximo.
IMPORTANT
Este cenário ilustra como implantar a política DNS para o gerenciamento de tráfego baseado na localização geográfica
quando você estiver usando somente servidores DNS primários. Você também pode realizar o gerenciamento de tráfego
baseado na localização geográfica quando tiver servidores DNS primários e secundários. Se você tiver uma implantação
primária-secundária, primeiro conclua as etapas neste tópico e, em seguida, conclua as etapas que são fornecidas no
tópico usar política DNS para gerenciamento de tráfego baseado em Geo-Location com implantações de Primary-
Secondary.
Com as novas políticas de DNS, você pode criar uma política DNS que permite que o servidor DNS responda a
uma consulta de cliente solicitando o endereço IP de um servidor Web. As instâncias do servidor Web podem
estar localizadas em data centers diferentes em locais físicos diferentes. O DNS pode avaliar os locais do cliente
e do servidor Web e, em seguida, responder à solicitação do cliente, fornecendo ao cliente um endereço IP do
servidor Web para um servidor Web localizado fisicamente mais próximo do cliente.
Você pode usar os seguintes parâmetros de política DNS para controlar as respostas do servidor DNS para
consultas de clientes DNS.
Sub-rede do cliente . Nome de uma sub-rede de cliente predefinida. Usado para verificar a sub-rede da
qual a consulta foi enviada.
Protocolo de transpor te . Protocolo de transporte usado na consulta. As entradas possíveis são UDP e
TCP .
Protocolo de Internet . Protocolo de rede usado na consulta. As entradas possíveis são IPv4 e IPv6 .
Endereço IP da interface do ser vidor . Endereço IP da interface de rede do servidor DNS que recebeu a
solicitação DNS.
FQDN . O FQDN (nome de domínio totalmente qualificado) do registro na consulta, com a possibilidade de
usar um curinga.
Tipo de consulta . Tipo de registro que está sendo consultado (A, SRV, TXT, etc.).
Hora do dia . Hora do dia em que a consulta é recebida.
Você pode combinar os critérios a seguir com um operador lógico (e/ou) para formular expressões de política.
Quando essas expressões correspondem, espera-se que as políticas executem uma das ações a seguir.
Ignorar . O servidor DNS descarta a consulta silenciosamente.
Negar . O servidor DNS responde a consulta com uma resposta de falha.
Permitir . O servidor DNS responde de volta com a resposta gerenciada de tráfego.
Exemplo de gerenciamento de tráfego baseado na localização
geográfica
Veja a seguir um exemplo de como você pode usar a política DNS para obter o redirecionamento de tráfego
com base no local físico do cliente que executa uma consulta DNS.
Este exemplo usa duas empresas fictícias: serviços de nuvem da Contoso, que fornecem soluções de
Hospedagem de domínio e Web; e os serviços do Woodgrove Food, que fornecem serviços de entrega de
alimentos em várias cidades em todo o mundo e que tem um site chamado woodgrove.com.
Os serviços de nuvem da Contoso têm dois data centers, um nos EUA e outro na Europa. O datacenter Europeu
hospeda um portal de pedidos de alimentos para woodgrove.com.
Para garantir que os clientes do woodgrove.com tenham uma experiência responsiva de seu site, o Woodgrove
quer clientes europeus direcionados para o datacenter Europeu e os clientes norte-americanos direcionados
para o datacenter dos EUA. Os clientes localizados em outro lugar do mundo podem ser direcionados para um
dos datacenters.
A ilustração a seguir descreve esse cenário.
NOTE
As políticas de DNS utilizam o IP do remetente no pacote UDP/TCP que contém a consulta DNS. Se a consulta atingir o
servidor primário por meio de vários saltos resolvedor/LDNS, a política considerará apenas o IP do último resolvedor do
qual o servidor DNS recebe a consulta.
NOTE
Você deve executar essas etapas no servidor DNS que é autoritativo para a zona que deseja configurar. A associação em
DNSAdmins , ou equivalente, é necessária para executar os procedimentos a seguir.
IMPORTANT
as seções a seguir incluem exemplo Windows PowerShell comandos que contêm valores de exemplo para muitos
parâmetros. Certifique-se de substituir os valores de exemplo nesses comandos por valores apropriados para sua
implantação antes de executar esses comandos.
NOTE
Por padrão, um escopo de zona existe nas zonas DNS. Esse escopo de zona tem o mesmo nome que a zona e as
operações de DNS herdadas funcionam nesse escopo.
você pode usar os seguintes comandos de Windows PowerShell para criar escopos de zona.
neste exemplo, você também deve usar os comandos de Windows PowerShell a seguir para adicionar registros
ao escopo de zona padrão para garantir que o restante do mundo ainda possa acessar o servidor web
woodgrove.com de qualquer um dos dois data centers.
O parâmetro ZoneScope não é incluído quando você adiciona um registro no escopo padrão. Isso é o mesmo
que adicionar registros a uma zona DNS padrão.
Para obter mais informações, consulte Add-DnsServerResourceRecord.
Criar as políticas
Depois de criar as sub-redes, as partições (escopos de zona) e adicionar registros, você deve criar políticas que
conectam as sub-redes e as partições, de modo que quando uma consulta vier de uma origem em uma das sub-
redes de cliente DNS, a resposta de consulta será retornada do escopo correto da zona. Nenhuma política é
necessária para mapear o escopo de zona padrão.
você pode usar os seguintes comandos de Windows PowerShell para criar uma política DNS que vincula as sub-
redes do cliente DNS e os escopos de zona.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para saber como criar uma política DNS para o gerenciamento de tráfego baseado
em localização geográfica quando sua implantação de DNS inclui servidores DNS primários e secundários.
O cenário anterior, Usar política DNS para gerenciamento de tráfego baseado em Geo-Locationcom servidores
primários, forneceu instruções para configurar a política DNS para o gerenciamento de tráfego baseado em
localização geográfica em um servidor DNS primário. Na infraestrutura de Internet, no entanto, os servidores
DNS são amplamente implantados em um modelo primário-secundário, em que a cópia que pode ser gravada
de uma zona é armazenada em servidores primários selecionados e seguros, e as cópias somente leitura da
zona são mantidas em vários servidores secundários.
Os servidores secundários usam os protocolos de transferência de zona AXFR (Transferência Autoritativa) e IXFR
(Transferência Incremental de Zona) para solicitar e receber atualizações de zona que incluem novas alterações
nas zonas nos servidores DNS primários.
NOTE
Para obter mais informações sobre o AXFR, consulte a IETF (Internet Engineering Task Force) Request for Comments 5936.
Para obter mais informações sobre o IXFR, consulte a Solicitação de IETF (Internet Engineering Task Force) para
Comentários 1995.
NOTE
As instruções neste tópico para copiar sub-redes de cliente DNS, escopos de zona e políticas DNS de servidores primários
DNS para servidores secundários DNS são para sua configuração e validação de DNS iniciais. No futuro, talvez você queira
alterar as configurações de sub-redes, escopos de zona e políticas do cliente DNS no servidor primário. Nessa
circunstância, você pode criar scripts de automação para manter os servidores secundários sincronizados com o servidor
primário.
Para configurar a política DNS para respostas de consulta baseadas em localização geográfica primária
secundária, você deve executar as etapas a seguir.
Criar as zonas secundárias
Configurar o Configurações zona na zona primária
Copiar as sub-redes do cliente DNS
Criar os escopos de zona no servidor secundário
Configurar política DNS
As seções a seguir fornecem instruções de configuração detalhadas.
IMPORTANT
As seções a seguir incluem Windows PowerShell comandos que contêm valores de exemplo para muitos parâmetros.
Substitua os valores de exemplo nesses comandos por valores apropriados para sua implantação antes de executar esses
comandos.
A associação em DnsAdmins ou equivalente é necessária para executar os procedimentos a seguir.
NOTE
No comando de exemplo a seguir, o parâmetro -Notify especifica que o servidor primário enviará notificações sobre
atualizações para a lista de seleção de secundários.
NOTE
Nesses comandos de exemplo, o parâmetro -ErrorAction Ignore está incluído, porque existe um escopo de zona
padrão em cada zona. O escopo de zona padrão não pode ser criado ou excluído. O pipelining resultará em uma tentativa
de criar esse escopo e falhará. Como alternativa, você pode criar os escopos de zona não padrão em duas zonas
secundárias.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para aprender a distribuir o tráfego de aplicativo entre diferentes instâncias
distribuídas geograficamente de um aplicativo usando políticas DNS baseadas na hora do dia.
Esse cenário é útil em situações em que você deseja direcionar o tráfego em um fuso horário para servidores de
aplicativos alternativos, como servidores Web, localizados em outro fuso horário. Isso permite balancear a carga
do tráfego entre instâncias de aplicativo durante períodos de pico quando os servidores primários estão
sobrecarregados com o tráfego.
Exemplo de respostas DNS inteligentes com base na hora do dia
Veja a seguir um exemplo de como você pode usar a política DNS para equilibrar o tráfego do aplicativo com
base na hora do dia.
Este exemplo usa uma empresa fictícia, a Contoso Gift Services, que fornece soluções de presentes online em
todo o mundo por meio de seu site, contosogiftservices.com.
O contosogiftservices.com Web está hospedado em dois datacenters, um em Seattle (América do Norte) e outro
em Dublin (Europa). Os servidores DNS são configurados para enviar respostas com conhecimento de
localização geográfica usando a política dns. Com um aumento recente nos negócios, contosogiftservices.com
tem um número maior de visitantes todos os dias e alguns dos clientes relataram problemas de disponibilidade
do serviço.
O Contoso Gift Services executa uma análise de site e descobre que todas as tardes entre 18h e 21h no horário
local, há um aumento no tráfego para os servidores Web. Os servidores Web não podem ser dimensionados
para lidar com o aumento do tráfego nesses horários de pico, resultando em negação de serviço aos clientes. A
mesma sobrecarga de tráfego de horário de pico ocorre nos datacenters europeu e americano. Em outros
momentos do dia, os servidores lidam com volumes de tráfego que estão bem abaixo de sua capacidade
máxima.
Para garantir que contosogiftservices.com clientes recebam uma experiência responsiva do site, a Contoso Gift
Services deseja redirecionar algum tráfego de Dublin para os servidores de aplicativos de Seattle entre 18h e
21h em Dublin; e eles querem redirecionar algum tráfego de Seattle para os servidores de aplicativos de Dublin
entre 18h e 21h em Seattle.
A ilustração a seguir ilustra esse cenário.
Como as respostas DNS inteligentes com base na hora do dia funcionam
Quando o servidor DNS é configurado com a política DNS de hora do dia, entre 18h e 21h em cada localização
geográfica, o servidor DNS faz o seguinte.
Responde às quatro primeiras consultas que ele recebe com o endereço IP do servidor Web no datacenter
local.
Responde à quinta consulta que recebe com o endereço IP do servidor Web no datacenter remoto.
Esse comportamento baseado em políticas descarrega 20% da carga de tráfego do servidor Web local para o
servidor Web remoto, endossando a tensão no servidor de aplicativos local e melhorando o desempenho do
site para os clientes.
Fora do horário de pico, os servidores DNS executam o gerenciamento de tráfego baseado em localizações
geográficas normais. Além disso, os clientes DNS que enviam consultas de locais diferentes América do Norte
ou Europa, o servidor DNS balanceia o tráfego entre os datacenters de Seattle e Dublin.
Quando várias políticas DNS são configuradas no DNS, elas são um conjunto ordenado de regras e são
processadas pelo DNS da prioridade mais alta para a prioridade mais baixa. O DNS usa a primeira política que
corresponde às circunstâncias, incluindo a hora do dia. Por esse motivo, políticas mais específicas devem ter
prioridade mais alta. Se você criar políticas de hora do dia e der a elas alta prioridade na lista de políticas, o DNS
processa e usa essas políticas primeiro se elas corresponderem aos parâmetros da consulta do cliente DNS e
aos critérios definidos na política. Se eles não corresponderem, o DNS move para baixo a lista de políticas para
processar as políticas padrão até encontrar uma combinação.
Para obter mais informações sobre tipos e critérios de política, consulte Visão geral das políticas DNS.
Como configurar a política DNS para respostas DNS inteligentes com base na hora do dia
Para configurar a política DNS para respostas de consulta baseadas no balanceamento de carga do aplicativo de
hora do dia, você deve executar as etapas a seguir.
Criar as sub-redes do cliente DNS
Criar os escopos de zona
Adicionar registros aos escopos de zona
Criar as políticas DNS
NOTE
Você deve executar essas etapas no servidor DNS autoritativo para a zona que você deseja configurar. A associação em
DnsAdmins ou equivalente é necessária para executar os procedimentos a seguir.
IMPORTANT
As seções a seguir incluem Windows PowerShell comandos que contêm valores de exemplo para muitos parâmetros.
Substitua os valores de exemplo nesses comandos por valores apropriados para sua implantação antes de executar esses
comandos.
NOTE
Por padrão, existe um escopo de zona nas zonas DNS. Esse escopo de zona tem o mesmo nome que a zona e as
operações dns herddas funcionam nesse escopo.
Você pode usar os comandos Windows PowerShell a seguir para criar escopos de zona.
O parâmetro ZoneScope não é incluído quando você adiciona um registro no escopo padrão. Isso é o mesmo
que adicionar registros a uma zona DNS padrão.
Para obter mais informações, consulte Add-DnsServerResourceRecord.
Criar as políticas DNS
Depois de criar as sub-redes, as partições (escopos de zona) e adicionar registros, você deve criar políticas que
conectam as sub-redes e partições, de modo que, quando uma consulta vem de uma origem em uma das sub-
redes do cliente DNS, a resposta da consulta é retornada do escopo correto da zona. Nenhuma política é
necessária para mapear o escopo de zona padrão.
Depois de configurar essas políticas dns, o comportamento do servidor DNS é o seguinte:
1. Os clientes DNS europeus recebem o endereço IP do servidor Web no datacenter de Dublin em sua resposta
de consulta DNS.
2. Os clientes DNS americanos recebem o endereço IP do servidor Web no datacenter de Seattle em sua
resposta de consulta DNS.
3. Entre 18h e 21h em Dublin, 20% das consultas de clientes europeus recebem o endereço IP do servidor Web
no datacenter de Seattle em sua resposta de consulta DNS.
4. Entre 18h e 21h em Seattle, 20% das consultas dos clientes americanos recebem o endereço IP do servidor
Web no datacenter de Dublin em sua resposta de consulta DNS.
5. Metade das consultas do restante do mundo recebe o endereço IP do datacenter de Seattle e a outra metade
recebe o endereço IP do datacenter de Dublin.
Você pode usar os comandos Windows PowerShell a seguir para criar uma política DNS que vincula as sub-
redes do cliente DNS e os escopos de zona.
NOTE
Neste exemplo, o servidor DNS está no fuso horário GMT, portanto, os períodos de hora de pico devem ser expressos no
horário GMT equivalente.
Add-DnsServerQueryResolutionPolicy -Name "America6To9Policy" -Action ALLOW -ClientSubnet "eq,AmericaSubnet"
-ZoneScope "SeattleZoneScope,4;DublinZoneScope,1" -TimeOfDay "EQ,01:00-04:00" -ZoneName
"contosogiftservices.com" -ProcessingOrder 1
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para aprender a distribuir o tráfego de aplicativo entre diferentes instâncias
distribuídas geograficamente de um aplicativo usando políticas DNS baseadas na hora do dia.
Esse cenário é útil em situações em que você deseja direcionar o tráfego em um fuso horário para servidores de
aplicativos alternativos, como servidores Web hospedados no Microsoft Azure, localizados em outro fuso
horário. Isso permite balancear a carga do tráfego entre instâncias de aplicativo durante períodos de pico
quando os servidores primários estão sobrecarregados com o tráfego.
NOTE
Para saber como usar a política DNS para respostas DNS inteligentes sem usar o Azure, consulte Usar a política dns para
respostas DNS inteligentes com base na hora do dia.
Os servidores DNS são configurados com escopos de zona e políticas DNS para que, entre 17h e 21h todos os
dias, 30% das consultas sejam enviadas para a instância do servidor Web em execução no Azure.
A ilustração a seguir ilustra esse cenário.
NOTE
Você deve executar essas etapas no servidor DNS autoritativo para a zona que você deseja configurar. A associação em
DnsAdmins, ou equivalente, é necessária para executar os procedimentos a seguir.
IMPORTANT
As seções a seguir incluem Windows PowerShell comandos que contêm valores de exemplo para muitos parâmetros.
Substitua os valores de exemplo nesses comandos por valores apropriados para sua implantação antes de executar esses
comandos.
NOTE
Por padrão, existe um escopo de zona nas zonas DNS. Esse escopo de zona tem o mesmo nome que a zona e as
operações dns herddas funcionam nesse escopo.
Você pode usar o comando de exemplo a seguir para criar um escopo de zona para hospedar os registros do
Azure.
Essa expressão configura o servidor DNS com uma combinação ZoneScope e peso que instrui o servidor DNS a
enviar o endereço IP do servidor Web de Seattle por cento do tempo, ao enviar o endereço IP do servidor Web
do Azure 30% do tempo.
Você pode criar milhares de políticas DNS de acordo com seus requisitos de gerenciamento de tráfego e todas
as novas políticas são aplicadas dinamicamente – sem reiniciar o servidor DNS – em consultas de entrada.
Usar a política DNS para a implantação de DNS de
divisão - Brain
13/08/2021 • 9 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para aprender a configurar a política dns no Windows Server ® 2016 para
implantações de dns de divisão-brain, em que há duas versões de uma única zona-uma para os usuários
internos na intranet da sua organização e outra para os usuários externos, que normalmente são usuários na
Internet.
NOTE
Para obter informações sobre como usar a política DNS para a implantação de DNS de divisão - Brain com Active
Directory zonas DNS integrado, consulte usar a política dns para Split-Brain DNS no Active Directory.
Anteriormente, esse cenário exigia que os administradores de DNS mantenham dois servidores DNS diferentes,
cada um fornecendo serviços a cada conjunto de usuários, interno e externo. Se apenas alguns registros dentro
da zona tiverem sido reduzidos - ou se ambas as instâncias da zona (internas e externas) tiverem sido delegadas
para o mesmo domínio pai, isso se tornaria um enigma de gerenciamento.
Outro cenário de configuração para implantação de divisão-Brain é o controle de recursão seletiva para a
resolução de nomes DNS. em algumas circunstâncias, espera-se que os servidores DNS Enterprise executem a
resolução recursiva pela Internet para os usuários internos, enquanto eles também devem atuar como
servidores de nome autoritativo para usuários externos e bloquear a recursão para eles.
Este tópico inclui as seções a seguir.
Exemplo de implantação de Split-Brain de DNS
Exemplo de controle de recursão seletiva de DNS
NOTE
Por padrão, um escopo de zona existe nas zonas DNS. Esse escopo de zona tem o mesmo nome que a zona e as
operações de DNS herdadas funcionam nesse escopo. Esse escopo de zona padrão hospedará a versão externa do
www.career.contoso.com.
Você pode usar o seguinte comando de exemplo para particionar o escopo de zona contoso.com para criar um
escopo de zona interno. O escopo da zona interna será usado para manter a versão interna do
www.career.contoso.com.
Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "internal"
NOTE
Este exemplo usa a interface de servidor como os critérios para diferenciar entre os clientes internos e externos. Outro
método para diferenciar entre clientes externos e internos é usar sub-redes de cliente como um critério. Se você puder
identificar as sub-redes às quais os clientes internos pertencem, você pode configurar a política DNS para diferenciar com
base na sub-rede do cliente. Para obter informações sobre como configurar o gerenciamento de tráfego usando critérios
de sub-rede do cliente, consulte usar a política DNS para o gerenciamento de tráfego baseado em Geo-Location com
servidores primários.
Quando o servidor DNS recebe uma consulta na interface privada, a resposta de consulta DNS é retornada do
escopo da zona interna.
NOTE
Nenhuma política é necessária para mapear o escopo de zona padrão.
No comando de exemplo a seguir, 10.0.0.56 é o endereço IP na interface de rede privada, conforme mostrado na
ilustração anterior.
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW -ServerInterface "eq,10.0.0.56"
-ZoneScope "internal,1" -ZoneName contoso.com
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para aproveitar as funcionalidades de gerenciamento de tráfego de políticas DNS
para implantações duplas com - zonas DNS integradas do Active Directory Windows Server 2016.
No Windows Server 2016, o suporte a políticas DNS é estendido para zonas DNS integradas do Active
Directory. A integração do Active Directory fornece recursos de alta disponibilidade de - vários mestres para o
servidor DNS.
Anteriormente, esse cenário exigia que os administradores de DNS mantenham dois servidores DNS diferentes,
cada um fornecendo serviços para cada conjunto de usuários, internos e externos. Se apenas alguns registros
dentro da zona foram divididos ou ambas as instâncias da zona (internas e externas) foram delegadas para o
mesmo domínio pai, isso se tornou um conflito de - gerenciamento.
NOTE
As implantações de DNS são divididas quando há duas versões de uma única zona, uma versão para usuários internos
na intranet da organização e uma versão para usuários externos – que normalmente são usuários na - Internet.
O tópico Usar a Política dns para Split-Brain de DNS explica como você pode usar políticas DNS e escopos de zona para
implantar um sistema DNS de dupla encefálica em um único Windows Server 2016 - DNS.
Para obter mais informações, consulte os tópicos Windows PowerShell referência a seguir.
Get-DnsServerQueryResolutionPolicy
Add-DnsServerQueryResolutionPolicy
Como configurar a política DNS para dividir - o DNS do Brain no
Active Directory
Para configurar a implantação de Split-Brain DNS usando a Política de DNS, você deve usar as seções a seguir,
que fornecem instruções de configuração detalhadas.
Adicionar a zona integrada do Active Directory
Você pode usar o comando de exemplo a seguir para adicionar a zona contoso.com do Active Directory ao
servidor DNS.
NOTE
Este exemplo usa a interface do servidor do parâmetro -ServerInterface no comando de exemplo abaixo como os critérios
para diferenciar ( entre os clientes internos e ) externos. Outro método para diferenciar entre clientes externos e internos é
usar sub-redes de cliente como critérios. Se você puder identificar as sub-redes às quais os clientes internos pertencem,
poderá configurar a política DNS para diferenciar com base na sub-rede do cliente. Para obter informações sobre como
configurar o gerenciamento de tráfego usando critérios de sub-rede do cliente, consulte Usar política DNS para
gerenciamento de tráfego baseado em Geo-Location com servidores primários.
Depois de configurar políticas, quando uma consulta DNS é recebida na interface pública, a resposta é retornada
do escopo externo da zona.
NOTE
Nenhuma política é necessária para mapear o escopo da zona interna padrão.
NOTE
208.84.0.53 é o endereço IP no interface de rede pública.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para aprender a configurar a política DNS no Windows Server ® 2016 para criar
filtros de consulta baseados em critérios fornecidos por você.
Os filtros de consulta na política DNS permitem configurar o servidor DNS para responder de uma maneira
personalizada com base na consulta DNS e no cliente DNS que envia a consulta DNS.
Por exemplo, você pode configurar a política DNS com a lista de blocos de filtro de consulta que bloqueia
consultas DNS de domínios mal-intencionados conhecidos, o que impede que o DNS responda a consultas
desses domínios. Como nenhuma resposta é enviada do servidor DNS, a consulta DNS do membro do domínio
mal-intencionado atinge o tempo limite.
Outro exemplo é criar uma lista de permissões de filtro de consulta que permita que apenas um conjunto
específico de clientes resolva determinados nomes.
Tipo de consulta Tipo de registro que está sendo consultado ( , SRV, txt, etc. ) .
Os exemplos a seguir mostram como criar filtros para a política DNS que bloqueiam ou permitem consultas de
resolução de nomes DNS.
NOTE
os comandos de exemplo neste tópico usam o comando Windows PowerShell Add-DnsSer verQuer yResolutionPolicy .
Para obter mais informações, consulte Add-DnsServerQueryResolutionPolicy.
NOTE
Quando você configura o parâmetro Action com o valor ignore , o servidor DNS é configurado para descartar consultas
sem nenhuma resposta. Isso faz com que o cliente DNS no domínio mal-intencionado expire.
Você pode criar milhares de políticas de DNS de acordo com seus requisitos de gerenciamento de tráfego e
todas as novas políticas são aplicadas dinamicamente, sem reiniciar o servidor DNS-em consultas de entrada.
Usar a Política de DNS para balanceamento de
carga de aplicativo
12/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para saber como configurar a política DNS para executar o balanceamento de carga
do aplicativo.
As versões anteriores do Windows DNS do servidor só forneceam balanceamento de carga usando round robin
respostas; mas com DNS no Windows Server 2016, você pode configurar a política DNS para balanceamento de
carga do aplicativo.
Quando você tiver implantado várias instâncias de um aplicativo, poderá usar a política dns para equilibrar a
carga de tráfego entre as diferentes instâncias de aplicativo, alocando dinamicamente a carga de tráfego para o
aplicativo.
NOTE
Por padrão, existe um escopo de zona nas zonas DNS. Esse escopo de zona tem o mesmo nome que a zona e as
operações dns herddas funcionam nesse escopo.
Você pode usar os comandos Windows PowerShell a seguir para criar escopos de zona.
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "SeattleZoneScope"
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "DallasZoneScope"
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "ChicagoZoneScope"
NOTE
No comando de exemplo abaixo, a expressão –ZoneScope "SeattleZoneScope,2; ChicagoZoneScope,1; DallasZoneScope,1"
configura o servidor DNS com uma matriz que inclui a combinação de parâmetros <ZoneScope> , <weight> .
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para saber como configurar a política DNS para balancear a carga de um aplicativo
com reconhecimento de localização geográfica.
O tópico anterior neste guia, Usar Política DNSpara Balanceamento de Carga de Aplicativo, usa um exemplo de
uma empresa fictícia – Contoso Gift Services – que fornece serviços de presentes online e que tem um site
chamado contosogiftservices.com. O Contoso Gift Services balanceia a carga de seu aplicativo Web online entre
servidores em datacenters da América do Norte localizados em Seattle, WA, Chicago, IL e Dallas, TX.
NOTE
É recomendável que você se familiarize com o tópico Usar Política DNS para Balanceamento de Carga de Aplicativo antes
de executar as instruções neste cenário.
Este tópico usa a mesma infraestrutura fictícia de rede e empresa como base para uma nova implantação de
exemplo que inclui reconhecimento de localização geográfica.
Neste exemplo, os Serviços de Presentes da Contoso estão expandindo com êxito sua presença em todo o
mundo.
Semelhante ao América do Norte, a empresa agora tem servidores Web hospedados em datacenters europeus.
Os administradores dns dos Serviços de Presentes da Contoso querem configurar o balanceamento de carga do
aplicativo para datacenters europeus de maneira semelhante à implementação da política DNS no Estados
Unidos, com o tráfego de aplicativos distribuído entre servidores Web localizados em Dublin, Irlanda, Amsterdã,
Amsterdã e em outro lugar.
Os administradores de DNS também querem que todas as consultas de outros locais do mundo distribuídas
igualmente entre todos os seus datacenters.
Nas próximas seções, você pode aprender a atingir metas semelhantes às dos Administradores dns da Contoso
em sua própria rede.
NOTE
Por padrão, existe um escopo de zona nas zonas DNS. Esse escopo de zona tem o mesmo nome que a zona e as
operações dns herddas funcionam nesse escopo.
O cenário anterior no balanceamento de carga do aplicativo demonstra como configurar três escopos de zona
para datacenters América do Norte.
Com os comandos abaixo, você pode criar mais dois escopos de zona, um para os datacenters Dublin e
Amsterdã.
Você pode adicionar esses escopos de zona sem nenhuma alteração aos três escopos América do Norte zona
existentes na mesma zona. Além disso, depois de criar esses escopos de zona, você não precisa reiniciar o
servidor DNS.
Você pode usar os comandos Windows PowerShell a seguir para criar escopos de zona.
Problemas de resolução de nome de domínio podem ser divididos em problemas do lado do cliente e do
servidor. Em geral, você deve começar com a solução de problemas do lado do cliente, a menos que determine
durante a fase de scoping que o problema está definitivamente ocorrendo no lado do servidor.
Solução de problemas de clientes DNS
Solução de problemas de servidores DNS
Coleta de dados
Recomendamos que você colete dados simultaneamente nos lados do cliente e do servidor quando o problema
ocorrer. No entanto, dependendo do problema real, você pode iniciar sua coleção em um único conjunto de
dados no cliente DNS ou no servidor DNS.
Para coletar um Windows de rede de um cliente afetado e seu servidor DNS configurado, siga estas etapas:
1. Iniciar capturas de rede no cliente e no servidor:
ipconfig /flushdns
3. Reproduza o problema.
4. Parar e salvar rastreamentos:
5. Salve os Nettrace.cab de cada computador. Essas informações serão úteis quando você entrar em contato
com Suporte da Microsoft.
Solução de problemas de clientes DNS
12/08/2021 • 2 minutes to read
Verificar a configuração de IP
1. Abra uma janela do Prompt de Comando como administrador no computador cliente.
2. Execute o comando a seguir:
ipconfig /all
3. Verifique se o cliente tem um endereço IP válido, uma máscara de sub-rede e um gateway padrão para a
rede à qual ele está anexado e sendo usado.
4. Verifique os servidores DNS listados na saída e verifique se os endereços IP listados estão corretos.
5. Verifique o sufixo DNS específico da conexão na saída e verifique se ele está correto.
Se o cliente não tiver uma configuração TCP/IP válida, use um dos seguintes métodos:
Para clientes configurados dinamicamente, use o comando para forçar manualmente o cliente a renovar
sua configuração de endereço ipconfig /renew IP com o servidor DHCP.
Para clientes configurados estaticamente, modifique as propriedades TCP/IP do cliente para usar
definições de configuração válidas ou conclua sua configuração de DNS para a rede.
ping 10.0.0.1
Se nenhum servidor DNS configurado responder a um ping direto de seu endereço IP, isso indicará que a
origem do problema é mais provável conectividade de rede entre o cliente e os servidores DNS. Se esse for o
caso, siga as etapas básicas de solução de problemas de rede TCP/IP para corrigir o problema. Tenha em mente
que o tráfego ICMP deve ser permitido por meio do firewall para que o comando ping funcione.
Testes de consulta DNS
Se o cliente DNS puder fazer ping no computador do servidor DNS, tente usar os comandos a seguir para testar
se o servidor nslookup pode responder a clientes DNS. Como nslookup não usa o cache DNS do cliente, a
resolução de nomes usará o servidor DNS configurado do cliente.
Testar um cliente
nslookup <client>
Por exemplo, se o computador cliente for chamado client1 , execute este comando:
nslookup client1
Se uma resposta bem-sucedida não for retornada, tente executar o seguinte comando:
nslookup client1.corp.contoso.com.
NOTE
Você deve incluir o período à parte final ao executar esse teste.
Se Windows encontrar o FQDN com êxito, mas não for possível encontrar o nome curto, verifique a
configuração do Sufixo DNS na guia DNS da guia TCP/IP avançado Configurações da NIC. Para obter mais
informações, consulte Configuring DNS Resolution.
Testar o servidor DNS
Por exemplo, se o servidor DNS for chamado DC1, execute este comando:
nslookup dc1
Se os testes anteriores foram bem-sucedidos, esse teste também deve ser bem-sucedido. Se esse teste não for
bem-sucedido, verifique a conectividade com o servidor DNS.
Testar o registro com falha
nslookup app1.corp.contoso.com
Por exemplo:
nslookup bing.com
Se todos os quatro testes foram bem-sucedidos, execute ipconfig /displaydns e verifique a saída do nome que
falhou. Se você vir "Nome não existe" com o nome com falha, uma resposta negativa foi retornada de um
servidor DNS e foi armazenada em cache no cliente.
Para resolver o problema, limpe o cache executando ipconfig /flushdns .
Próxima etapa
Se a resolução de nomes ainda estiver falhando, vá para a seção Solução de problemas de servidores DNS.
Desabilitar o cache do DNS do lado do cliente em
clientes DNS
13/08/2021 • 3 minutes to read
Windows contém um cache DNS do lado do cliente. O recurso de cache DNS do lado do cliente pode gerar uma
falsa impressão de que o balanceamento de carga do DNS "round robin" não está ocorrendo do servidor DNS
para o computador Windows cliente. Quando você usa o comando ping para pesquisar o mesmo nome de
domínio de registro A, o cliente pode usar o mesmo endereço IP.
Para desabilitar o cache DNS permanentemente Windows, use a ferramenta Controlador de Serviço ou a
ferramenta Serviços para definir o tipo de inicialização do serviço Cliente DNS como Desabilitado. Observe
que o nome do serviço Windows cliente DNS também pode aparecer como "Dnscache".
NOTE
Se o cache do resolvedor de DNS for desativado, o desempenho geral do computador cliente diminuirá e o tráfego de
rede para consultas DNS aumentará.
O serviço cliente DNS otimiza o desempenho da resolução de nomes DNS, armazenar nomes resolvidos
anteriormente na memória. Se o serviço cliente DNS estiver desligado, o computador ainda poderá resolver
nomes DNS usando os servidores DNS da rede.
Quando o Windows resolvedor recebe uma resposta, seja positiva ou negativa, a uma consulta, ele adiciona
essa resposta ao cache e, assim, cria um registro de recurso DNS. O resolvedor sempre verifica o cache antes de
consultar qualquer servidor DNS. Se um registro de recurso DNS estiver no cache, o resolvedor usará o registro
do cache em vez de consultar um servidor. Esse comportamento agiliza consultas e diminui o tráfego de rede
para consultas DNS.
Você pode usar a ferramenta ipconfig para exibir e liberar o cache do resolvedor de DNS. Para exibir o cache do
resolvedor de DNS, execute o seguinte comando em um prompt de comando:
ipconfig /displaydns
Esse comando exibe o conteúdo do cache do resolvedor dns, incluindo os registros de recursos DNS pré-
carregados do arquivo Hosts e quaisquer nomes consultados recentemente que foram resolvidos pelo sistema.
Após algum tempo, o resolvedor descarta o registro do cache. O período de tempo é especificado pelo valor
TTL (Vida Vida) associado ao registro de recurso DNS. Você também pode liberar o cache manualmente.
Depois de liberar o cache, o computador deverá consultar servidores DNS novamente para quaisquer registros
de recurso DNS que foram resolvidos anteriormente pelo computador. Para excluir as entradas no cache do
resolvedor dns, execute ipconfig /flushdns em um prompt de comando.
O período de tempo para o qual uma resposta positiva ou negativa é armazenada em cache depende dos
valores de entradas na seguinte chave do Registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser vices\DNSCache\Parameters
O TTL para respostas positivas é o menor dos seguintes valores:
O número de segundos especificado na resposta de consulta que o resolvedor recebeu
O valor da configuração do Registro MaxCacheTtl.
NOTE
O TTL padrão para respostas positivas é de 86.400 segundos (1 dia).
O TTL para respostas negativas é o número de segundos especificado na configuração do Registro
MaxNegativeCacheTtl.
O TTL padrão para respostas negativas é de 5 segundos; antes da Windows 10, versão 1703, o padrão era 900
segundos (15 minutos). Se você não quiser que respostas negativas sejam armazenadas em cache, defina a
configuração do Registro MaxNegativeCacheTtl como 0.
Verificar a configuração de IP
1. Execute ipconfig /all em um prompt de comando e verifique o endereço IP, a máscara de sub-rede e o
gateway padrão.
2. Verifique se o servidor DNS é autoritativo para o nome que está sendo procurado. Em caso afirmativo,
consulte Verificando se há problemas com dados autoritativos.
3. Execute o comando a seguir:
Por exemplo:
Se você receber uma resposta de falha ou tempo-out, consulte Verificando problemas de recursão.
4. Liberar o cache do resolvedor. Para fazer isso, execute o seguinte comando em uma janela administrativa
do Prompt de Comando:
dnscmd /clearcache
Clear-DnsServerCache
5. Repita a etapa 3.
Se o problema ocorrer quando o serviço estiver em execução, o servidor poderá não estar escutando no
endereço IP que você usou na consulta nslookup. Na guia Interfaces da página de propriedades do servidor no
console DNS, os administradores podem restringir um servidor DNS para escutar somente em endereços
selecionados. Se o servidor DNS tiver sido configurado para limitar o serviço a uma lista específica de seus
endereços IP configurados, é possível que o endereço IP usado para contatar o servidor DNS não está na lista.
Você pode tentar um endereço IP diferente na lista ou adicionar o endereço IP à lista.
Em casos raros, o servidor DNS pode ter uma configuração avançada de segurança ou firewall. Se o servidor
estiver localizado em outra rede acessível somente por meio de um host intermediário (como um roteador de
filtragem de pacotes ou servidor proxy), o servidor DNS poderá usar uma porta não padrão para escutar e
receber solicitações do cliente. Por padrão, nslookup envia consultas para servidores DNS na porta UDP 53.
Portanto, se o servidor DNS usar qualquer outra porta, as consultas nslookup falharão. Se você acha que esse
pode ser o problema, verifique se um filtro intermediário é usado intencionalmente para bloquear o tráfego em
portas DNS conhecidas. Se não estiver, tente modificar os filtros de pacote ou as regras de porta no firewall para
permitir o tráfego na porta UDP/TCP 53.
NOTE
Você pode determinar qual servidor é o servidor primário examinando as propriedades da zona secundária no
console DNS.
nslookup
server <IP address of server being examined>
set q=NS
Se o resolvedor retornar o endereço IP de um servidor raiz, você provavelmente terá uma delegação
interrompida entre o servidor raiz e o nome ou o endereço IP que está tentando resolver. Siga o
procedimento Testar uma delegação interrompida para determinar onde você tem uma delegação
interrompida.
Se o resolvedor retornar uma resposta "Solicitação ao servidor com tempo de vida", verifique se as dicas
raiz apontam para servidores raiz em funcionamento. Para fazer isso, use o procedimento Para exibir as
dicas raiz atuais. Se as dicas raiz apontarem para servidores raiz em funcionamento, você poderá ter um
problema de rede ou o servidor poderá usar uma configuração avançada de firewall que impede que o
resolvedor consulte o servidor, conforme descrito na seção Verificar problemas do servidor DNS.
Também é possível que o padrão de tempo-máximo recursivo seja muito curto.
Testar uma delegação interrompida
Inicie os testes no procedimento a seguir consultando um servidor raiz válido. O teste leva você por um
processo de consulta de todos os servidores DNS da raiz até o servidor que você está testando para uma
delegação interrompida.
1. No prompt de comando no servidor que você está testando, insira o seguinte:
nslookup
server <server IP address>
set norecursion
set querytype= <resource record type>
<FQDN>
NOTE
Tipo de registro de recurso é o tipo de registro de recurso que você estava consultando em sua consulta original,
e FQDN é o FQDN para o qual você estava consultando (encerrado por um período).
2. Se a resposta incluir uma lista de registros de recursos "NS" e "A" para servidores delegados, repita a
etapa 1 para cada servidor e use o endereço IP dos registros de recurso "A" como o endereço IP do
servidor.
Se a resposta não contém um registro de recurso "NS", você tem uma delegação interrompida.
Se a resposta contiver registros de recurso "NS", mas nenhum registro de recurso "A", insira
definir recursão e consulte individualmente os registros de recursos "A" de servidores listados
nos registros "NS". Se você não encontrar pelo menos um endereço IP válido de um registro de
recurso "A" para cada registro de recurso NS em uma zona, terá uma delegação interrompida.
3. Se você determinar que tem uma delegação interrompida, corrija-a adicionando ou atualizando um
registro de recurso "A" na zona pai usando um endereço IP válido para um servidor DNS correto para a
zona delegada.
Para exibir as dicas raiz atuais
1. Inicie o console DNS.
2. Adicione ou conecte-se ao servidor DNS que falhou em uma consulta recursiva.
3. Clique com o botão direito do mouse no servidor e selecione Propriedades .
4. Clique em Dicas Raiz.
Verifique se há conectividade básica com os servidores raiz.
Se as dicas raiz pareceram estar configuradas corretamente, verifique se o servidor DNS usado em uma
resolução de nomes com falha pode fazer ping nos servidores raiz por endereço IP.
Se os servidores raiz não responderem ao ping por endereço IP, os endereços IP dos servidores raiz
poderão ter sido alterados. No entanto, é incomum ver uma reconfiguração de servidores raiz.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para uma breve visão geral do DHCP Windows Server 2016.
NOTE
Além deste tópico, a documentação do DHCP a seguir está disponível.
Novidades no DHCP
Implantar o DHCP usando Windows PowerShell
O protocolo DHCP é um protocolo de cliente/servidor que fornece automaticamente um host ip (protocolo IP)
com seu endereço IP e outras informações de configuração relacionadas, como a máscara de sub-rede e o
gateway padrão. As RFCs 2131 e 2132 definem o DHCP como um padrão de IETF (Força-Tarefa de Engenharia
da Internet) com base no protocolo BOOTP, um protocolo com o qual o DHCP compartilha muitos detalhes de
implementação. O DHCP permite que os hosts obtenham informações de configuração TCP/IP necessárias de
um servidor DHCP.
Windows Server 2016 inclui o Servidor DHCP, que é uma função de servidor de rede opcional que você pode
implantar em sua rede para concessão de endereços IP e outras informações para clientes DHCP. Todos
Windows sistemas operacionais cliente baseados em Windows incluem o cliente DHCP como parte do TCP/IP e
o cliente DHCP está habilitado por padrão.
Benefícios do DHCP
O DHCP oferece os seguintes benefícios.
Configuração de endereço IP confiável. O DHCP minimiza os erros de configuração causados pela
configuração manual de endereço IP, como erros tipográficos ou conflitos de endereço causados pela
atribuição de um endereço IP a mais de um computador ao mesmo tempo.
Administração de rede reduzida. O DHCP inclui os seguintes recursos para reduzir a administração
de rede:
Configuração TCP/IP centralizada e automatizada.
A capacidade de definir configurações de TCP/IP de um local central.
A capacidade de atribuir um intervalo completo de valores de configuração TCP/IP adicionais por
meio de opções DHCP.
O tratamento eficiente de alterações de endereço IP para clientes que devem ser atualizados com
frequência, como aqueles para dispositivos portáteis que se movem para locais diferentes em uma
rede sem fio.
O encaminhamento de mensagens DHCP iniciais usando um agente de retransmissão DHCP, que
elimina a necessidade de um servidor DHCP em cada sub-rede.
Novidades no DHCP
13/08/2021 • 3 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este tópico descreve a funcionalidade DHCP (Dynamic Host Configuration Protocol) que é nova ou alterada no
Windows Server 2016.
O DHCP é um padrão IETF (Internet Engineering Task Force) projetado para reduzir a carga administrativa e a
complexidade da configuração de hosts em uma rede baseada em TCP/IP, como uma - intranet privada. Usando
o serviço de servidor DHCP, o processo de configuração de TCP/IP em clientes DHCP é automático.
As seções a seguir fornecem informações sobre novos recursos e alterações na funcionalidade do DHCP.
Em uma implantação NAP, um servidor DHCP executando um sistema operacional que dá suporte a NAP pode
funcionar como um ponto de imposição NAP para o método de imposição de NAP DHCP. Para obter mais
informações sobre o DHCP no NAP, consulte Checklist: Implementing a DHCP Enforcement Design.
No Windows Server 2016, os servidores DHCP não impõem políticas NAP e os escopos DHCP não podem ser
habilitados - para NAP. Os computadores cliente DHCP que também são clientes NAP enviam uma instrução de
soH de saúde com a ( ) solicitação DHCP. Se o servidor DHCP estiver executando Windows Server 2016, essas
solicitações serão processadas como se nenhum SoH estivesse presente. O servidor DHCP concede uma
concessão DHCP normal ao cliente.
Se os servidores que estão executando o Windows Server 2016 são proxies RADIUS que encaminham
solicitações de autenticação para um NPS do Servidor de Política de Rede que dá suporte a NAP, esses clientes
NAP são avaliados pelo NPS como não compatíveis com NAP e o processamento ( ) NAP - falha.
Referências adicionais
Protocolo DHCP
Opções de seleção de sub-rede DHCP
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para obter informações sobre as novas opções de seleção de sub-rede DHCP.
O DHCP agora dá suporte à opção 82 ( sub-opção 5 ) . Você pode usar essas opções para permitir que clientes
de proxy DHCP e agentes de retransmissão solicitem um endereço IP para uma sub-rede específica e de um
escopo e intervalo de endereços IP específicos. Para obter mais detalhes, consulte Opção 82 Sub Option 5 :
RFC 3527 Link Selection sub-option for the Relay Agent Information Option for DHCPv4.
Se você estiver usando um agente de retransmissão DHCP configurado com a opção DHCP 82, sub-opção 5, o
agente de retransmissão poderá solicitar uma concessão de endereço IP para clientes DHCP de um intervalo de
endereços IP específico.
NOTE
Todos os endereços IP do agente de retransmissão (GIADDR) devem fazer parte de um intervalo de endereços IP de
escopo DHCP ativo. Qualquer GIADDR fora dos intervalos de endereços IP do escopo DHCP é considerado uma
retransmissão não Windows servidor DHCP não reconhecerá solicitações de cliente DHCP desses agentes de
retransmissão.
Um escopo especial pode ser criado para "autorizar" agentes de retransmissão. Crie um escopo com o GIADDR (ou vários
se os GIADDR são endereços IP sequenciais), exclua os endereços GIADDR da distribuição e, em seguida, ative o escopo.
Isso autorizará os agentes de retransmissão, impedindo que os endereços GIADDR seja atribuídos.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Os logs de eventos do servidor DHCP agora fornecem informações detalhadas sobre falhas de registro dns.
NOTE
Em muitos casos, o motivo para falhas de registro de registro DNS por servidores DHCP é que uma Zona de Lookup
Inversa dns está configurada incorretamente ou não está - configurada.
Os novos eventos DHCP a seguir ajudam você a identificar facilmente quando os registros DNS estão falhando
devido a uma Zona de Lookup Inversa de DNS configurada - inadvertida ou ausente.
ID EVEN TO VA LO R
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
este guia fornece instruções sobre como usar Windows PowerShell para implantar um servidor dhcp do
protocolo de configuração de Host dinâmico do protocolo Internet (IP) versão 4 ( ) que atribui automaticamente
endereços IP e opções dhcp a clientes dhcp IPv4 que estão conectados a uma ou mais sub-redes em sua rede.
NOTE
para baixar este documento no formato do Word na galeria do TechNet, consulte implantar o DHCP usando o Windows
PowerShell em Windows Server 2016.
O uso de servidores DHCP para atribuir endereços IP economiza em sobrecarga administrativa porque você não
precisa configurar manualmente as configurações de TCP/IP V4 para cada adaptador de rede em cada
computador na rede. Com DHCP, a configuração de TCP/IP V4 é executada automaticamente quando um
computador ou outro cliente DHCP está conectado à sua rede.
Você pode implantar o servidor DHCP em um grupo de trabalho como um servidor autônomo ou como parte
de um domínio de Active Directory.
Este guia contém as seções a seguir.
Visão geral da implantação de DHCP
Visões gerais de tecnologia
Planejar a implantação do DHCP
Usando este guia em um laboratório de teste
Implantar o DHCP
Verificar a funcionalidade do servidor
Windows PowerShell Comandos para DHCP
lista de comandos Windows PowerShell neste guia
Esse número de máscara de sub-rede são 16 bits de um seguidos de 16 bits de zero, indicando que as seções de
ID da rede e as seções de ID do host desse endereço IP têm 16 bits de comprimento. Normalmente, essa
máscara de sub-rede é exibida em notação decimal com ponto como 255.255.0.0.
A tabela a seguir exibe as máscaras de sub-rede para as classes de endereço de Internet.
Quando você cria um escopo no DHCP e insere o intervalo de endereços IP do escopo, o DHCP fornece esses
valores de máscara de sub-rede padrão. Normalmente, os valores de máscara de sub-rede padrão são
aceitáveis para a maioria das redes sem requisitos especiais e onde cada segmento de rede IP corresponde a
uma única rede física.
Em alguns casos, você pode usar máscaras de sub-rede personalizadas para implementar a criação de sub-
redes IP. Com a criação de sub-redes IP, você pode subdividir a parte padrão de ID de host de um endereço IP
para especificar sub-redes, que são subdivisões de ID de rede baseada na classe original.
Personalizando o comprimento da máscara de sub-rede, você pode reduzir o número de bits que são usados
para o ID de host real.
Para evitar a solução e o roteamento de problemas, verifique se todos os computadores TCP/IP em um
segmento de rede usam a mesma máscara de sub-rede e se cada computador ou dispositivo tem um endereço
IP exclusivo.
Planejando intervalos de exclusão
Quando você cria um escopo em um servidor DHCP, pode especificar um intervalo de endereços IP que inclui
todos os endereços IP que o servidor DHCP pode conceder aos clientes DHCP, como computadores e outros
dispositivos. Se você acessar e configurar manualmente alguns servidores e outros dispositivos com endereços
IP estáticos do mesmo intervalo de endereços IP usado pelo servidor DHCP, poderá criar acidentalmente um
conflito de endereços IP, onde você e o servidor DHCP atribuem o mesmo endereço IP a dispositivos diferentes.
Para resolver esse problema, você pode criar um intervalo de exclusão para o escopo DHCP. Um intervalo de
exclusão é um intervalo contíguo de endereços IP dentro do intervalo de endereços IP do escopo que o servidor
DHCP não tem permissão para usar. Se você criar um intervalo de exclusão, o servidor DHCP não atribuirá os
endereços nesse intervalo, permitindo que você atribua manualmente esses endereços sem criar um conflito de
endereços IP.
Você pode excluir endereços IP da distribuição pelo servidor DHCP, criando um intervalo de exclusão para cada
escopo. Use as exclusões para todos os dispositivos configurados com um endereço IP estático. Os endereços
excluídos devem incluir todos os endereços IP que você atribuiu manualmente a outros servidores, clientes não-
DHCP, estações de trabalho sem disco ou clientes de Roteamento, Acesso Remoto e PPP.
Recomendamos que você configure o intervalo de exclusão com endereços extras para acomodar o crescimento
futuro da rede. A tabela a seguir fornece um intervalo de exclusão de exemplo para um escopo com um
intervalo de endereços IP 10.0.0.1 a 10.0.0.254 e uma máscara de sub-rede de 255.255.255.0.
NOTE
Se você não quiser implantar o DHCP em um laboratório de teste, poderá pular para a seção Implantar DHCP.
Os requisitos para seu laboratório diferem dependendo se você está usando servidores físicos ou VMs de
máquinas virtuais e se você está usando um domínio do Active Directory ou implantando um servidor ( ) DHCP
autônomo.
Você pode usar as informações a seguir para determinar os recursos mínimos necessários para testar a
implantação do DHCP usando este guia.
Requisitos do laboratório de teste com VMs
Para implantar o DHCP em um laboratório de teste com VMs, você precisa dos recursos a seguir.
Para implantação de domínio ou implantação autônoma, você precisa de um servidor configurado como um -
host hyper-V.
Implantação de domínio
Essa implantação requer um servidor físico, um comu switch virtual, dois servidores virtuais e um cliente
virtual:
No servidor físico, no Gerenciador do Hyper-V, crie os itens a seguir.
1. Um comu switch virtual interno. Não crie um comutadores vir tuais externos, pois se o host Hyper V
estiver em uma sub-rede que inclui um servidor DHCP, suas VMs de teste receberão um endereço IP do
servidor - DHCP. Além disso, o servidor DHCP de teste que você implanta pode atribuir endereços IP a outros
computadores na sub-rede em que o host Hyper - V está instalado.
2. Uma VM em execução Windows Server 2016 configurada como um controlador de domínio com Active
Directory Domain Services que está conectado ao com switch virtual interno que você criou. Para
corresponder a este guia, esse servidor deve ter um endereço IP configurado estaticamente de 10.0.0.2. Para
obter informações sobre como AD DS, consulte a seção Implantando DC1 no Guia de rede Windows
Server 2016 Core.
3. Uma VM em execução Windows Server 2016 que você configurará como um servidor DHCP usando este
guia e que está conectada ao comu switch virtual interno que você criou.
4. Uma VM executando um sistema operacional cliente Windows que está conectado ao comutório virtual
interno que você criou e que você usará para verificar se o servidor DHCP está alocando dinamicamente
endereços IP e opções DHCP para clientes DHCP.
Implantação autônoma do ser vidor DHCP
Essa implantação requer um servidor físico, um comu switch virtual, um servidor virtual e um cliente virtual:
No servidor físico, no Gerenciador do Hyper-V, crie os itens a seguir.
1. Um comu switch virtual interno. Não crie um comutadores vir tuais externos, pois se o host Hyper V
estiver em uma sub-rede que inclui um servidor DHCP, suas VMs de teste receberão um endereço IP do
servidor - DHCP. Além disso, o servidor DHCP de teste que você implanta pode atribuir endereços IP a outros
computadores na sub-rede em que o host Hyper - V está instalado.
2. Uma VM em execução Windows Server 2016 que você configurará como um servidor DHCP usando este
guia e que está conectada ao comu switch virtual interno que você criou.
3. Uma VM executando um sistema operacional cliente Windows que está conectado ao comutório virtual
interno que você criou e que você usará para verificar se o servidor DHCP está alocando dinamicamente
endereços IP e opções DHCP para clientes DHCP.
Requisitos do laboratório de teste com servidores físicos
Para implantar o DHCP em um laboratório de teste com servidores físicos, você precisa dos recursos a seguir.
Implantação de domínio
Essa implantação requer um hub ou uma opção, dois servidores físicos e um cliente físico:
1. Um hub Ethernet ou uma opção para a qual você pode conectar os computadores físicos com cabos Ethernet
2. Um computador físico executando Windows Server 2016 configurado como um controlador de domínio
com Active Directory Domain Services. Para corresponder a este guia, esse servidor deve ter um endereço IP
configurado estaticamente de 10.0.0.2. Para obter informações sobre como AD DS, consulte a seção
Implantando DC1 no Guia de rede Windows Server 2016 Core.
3. Um computador físico executando Windows Server 2016 que você configurará como um servidor DHCP
usando este guia.
4. Um computador físico executando um Windows operacional cliente que você usará para verificar se o
servidor DHCP está alocando dinamicamente endereços IP e opções DHCP para clientes DHCP.
NOTE
Se você não tiver máquinas de teste suficientes para essa implantação, poderá usar um computador de teste para AD DS
e DHCP– no entanto, essa configuração não é recomendada para um ambiente de produção.
Implantar o DHCP
Esta seção fornece exemplos Windows PowerShell comandos que você pode usar para implantar o DHCP em
um servidor. Antes de executar esses comandos de exemplo em seu servidor, você deve modificar os comandos
para corresponder à rede e ao ambiente.
Por exemplo, antes de executar os comandos, você deve substituir os valores de exemplo nos comandos para os
seguintes itens:
Nomes de computadores
Intervalo de endereços IP para cada escopo que você deseja configurar (1 escopo por sub-rede)
Máscara de sub-rede para cada intervalo de endereços IP que você deseja configurar
Nome do escopo para cada escopo
Intervalo de exclusão para cada escopo
Valores de opção DHCP, como gateway padrão, nome de domínio e servidores DNS ou WINS
Nomes de interface
IMPORTANT
Examine e modifique todos os comandos para seu ambiente antes de executar o comando.
Para obter mais informações sobre esses comandos, consulte os tópicos a seguir.
New-NetIPAddress
Set-DnsClientServerAddress
Renomear o computador
Você pode usar os comandos a seguir para renomear e reiniciar o computador.
Para obter mais informações sobre esses comandos, consulte os tópicos a seguir.
Rename-Computer
Restart-Computer
Ingressar o computador no domínio ( Opcional)
Se você estiver instalando o servidor DHCP em um ambiente de domínio do Active Directory, deverá ingressar o
computador no domínio. Abra Windows PowerShell com privilégios de Administrador e execute o comando a
seguir depois de substituir o domínio NetBios name CORP por um valor apropriado para seu ambiente.
Add-Computer CORP
Quando solicitado, digite as credenciais de uma conta de usuário de domínio que tenha permissão para
ingressar um computador no domínio.
Restart-Computer
Para obter mais informações sobre esse comando, consulte o tópico a seguir.
Install-WindowsFeature
Criar grupos de segurança DHCP
Para criar grupos de segurança, você deve executar um comando netsh do Shell de Rede no Windows
PowerShell e reiniciar o serviço DHCP para que os novos grupos se tornem ( ) ativos.
Quando você executar o comando netsh a seguir no servidor DHCP, os grupos de segurança Administradores
DHCP e Usuários DHCP serão criados em Usuários e Grupos Locais no servidor DHCP.
Restart-Service dhcpserver
Para obter mais informações sobre esses comandos, consulte os tópicos a seguir.
Shell de Rede (Netsh)
Restart-Service
Autorizar o servidor DHCP no Active Directory ( Opcional)
Se você estiver instalando o DHCP em um ambiente de domínio, deverá executar as etapas a seguir para
autorizar o servidor DHCP a operar no domínio.
NOTE
Servidores DHCP não autorizados instalados em domínios do Active Directory não podem funcionar corretamente e não
arrendam endereços IP para clientes DHCP. A desabilitação automática de servidores DHCP não autorizados é um recurso
de segurança que impede que servidores DHCP não autorizados atribuam endereços IP incorretos a clientes em sua rede.
Você pode usar o comando a seguir para adicionar o servidor DHCP à lista de servidores DHCP autorizados no
Active Directory.
NOTE
Se você não tiver um ambiente de domínio, não execute este comando.
Para verificar se o servidor DHCP está autorizado no Active Directory, você pode usar o comando a seguir.
Get-DhcpServerInDC
IPAddress DnsName
--------- -------
10.0.0.3 DHCP1.corp.contoso.com
Para obter mais informações sobre esses comandos, consulte os tópicos a seguir.
Add-DhcpServerInDC
Get-DhcpServerInDC
Notificar Gerenciador do Servidor que a - configuração do DHCP pós-instalação está concluída ( Opcional)
Depois de concluir as tarefas pós-instalação, como criar grupos de segurança e autorizar o servidor DHCP no
Active Directory, o Gerenciador do Servidor ainda poderá exibir um alerta na interface do usuário informando
que as etapas de pós-instalação devem ser concluídas usando o assistente de Configuração de Pós-Instalação
do - - DHCP.
Você pode impedir que essa mensagem desnecessária e imprecisa apareça no Gerenciador do Servidor
configurando a seguinte chave do Registro usando esse comando - Windows PowerShell segurança.
Para obter mais informações sobre esse comando, consulte o tópico a seguir.
Set-ItemProperty
Definir definições de configuração de atualização dinâmica de DNS no nível do servidor ( Opcional)
Se você quiser que o servidor DHCP execute atualizações dinâmicas de DNS para computadores cliente DHCP,
execute o comando a seguir para definir essa configuração. Essa é uma configuração de nível de servidor, não
uma configuração de nível de escopo, portanto, ela afetará todos os escopos que você configurar no servidor.
Este comando de exemplo também configura o servidor DHCP para excluir registros de recursos DNS para
clientes quando o cliente expira menos.
Você pode usar o comando a seguir para configurar as credenciais que o servidor DHCP usa para registrar ou
não registrar registros de cliente em um servidor DNS. Este exemplo salva uma credencial em um servidor
DHCP. O primeiro comando usa Get-Credential para criar um objeto PSCredential e, em seguida, armazena o
objeto na variável $Credential dados. O comando solicita o nome de usuário e a senha, portanto, certifique-se
de fornecer credenciais para uma conta que tenha permissão para atualizar registros de recursos em seu
servidor DNS.
$Credential = Get-Credential
Set-DhcpServerDnsCredential -Credential $Credential -ComputerName "DHCP1.corp.contoso.com"
Para obter mais informações sobre esses comandos, consulte os tópicos a seguir.
Set-DhcpServerv4DnsSetting
Set-DhcpServerDnsCredential
Configurar o escopo Corpnet
Após a conclusão da instalação do DHCP, você pode usar os comandos a seguir para configurar e ativar o
escopo Corpnet, criar um intervalo de exclusão para o escopo e configurar o gateway padrão de opções DHCP, o
endereço IP do servidor DNS e o nome de domínio DNS.
Para obter mais informações sobre esses comandos, consulte os tópicos a seguir.
Add-DhcpServerv4Scope
Add-DhcpServerv4ExclusionRange
Set-DhcpServerv4OptionValue
Configurar o escopo Corpnet2 ( opcional)
Se você tiver uma segunda sub-rede conectada à primeira sub-rede com um roteador em que o
encaminhamento DHCP está habilitado, poderá usar os comandos a seguir para adicionar um segundo escopo,
chamado Corpnet2 para este exemplo. Este exemplo também configura um intervalo de exclusão e o endereço
IP para o gateway padrão, o endereço IP do roteador na ( sub-rede ) da sub-rede Corpnet2.
Se você tiver sub-redes adicionais que são ativas por esse servidor DHCP, poderá repetir esses comandos,
usando valores diferentes para todos os parâmetros de comando, para adicionar escopos para cada sub-rede.
IMPORTANT
Verifique se todos os roteadores entre os clientes DHCP e o servidor DHCP estão configurados para encaminhamento de
mensagens DHCP. Consulte a documentação do roteador para obter informações sobre como configurar o
encaminhamento DHCP.
Módulo DhcpServer
a referência a seguir fornece descrições de comando e sintaxe para todos os comandos de Windows PowerShell
de servidor DHCP para o Windows Server 2012 R2. O tópico lista os comandos em ordem alfabética com base
no verbo no início dos comandos, como Get ou set .
NOTE
você pode usar os comandos do Windows Server 2012 R2 no Windows Server 2016.
Add-Computer CORP
Restart-Computer
$Credential = Get-Credential
Set-DhcpServerDnsCredential -Credential $Credential -ComputerName "DHCP1.corp.contoso.com"
Para qualquer dispositivo (como um computador ou telefone) ser capaz de operar em uma rede, ele deve ser
atribuído a um endereço IP. Você pode atribuir um endereço IP manual ou automaticamente. A atribuição
automática é tratada pelo serviço DHCP (Microsoft ou servidor de terceiros).
Neste artigo, discutiremos as etapas gerais de solução de problemas para o cliente e o servidor DHCP do
Microsoft IPv4.
Mais informações
O procedimento para atribuição de endereço IPv4 geralmente envolve três componentes principais:
Um dispositivo cliente DHCP que precisa obter um endereço IP
Um serviço DHCP que fornece endereços IP para o cliente com base em configurações específicas
Um auxiliar/IP de agente de retransmissão DHCP para enviar solicitações de difusão DHCP a um
segmento de rede diferente
Uma comunicação de cliente para servidor DHCP consiste em três tipos de interação entre os dois pares:
Dora com base em difusão (descoberta, oferta, solicitação, confirmação). O processo é composto
pelas seguintes etapas:
O cliente DHCP envia uma solicitação de difusão de descoberta de DHCP para todos os servidores
DHCP disponíveis no intervalo.
Uma resposta de difusão de oferta DHCP é recebida do servidor DHCP, oferecendo uma concessão
de endereço IP disponível.
A solicitação de difusão de cliente DHCP solicita a concessão de endereço IP oferecido e a
confirmação de difusão DHCP no final.
Se o cliente DHCP e o servidor estiverem localizados em diferentes segmentos de rede lógica, um
agente de retransmissão DHCP atuará em um encaminhador, enviando os pacotes de difusão
DHCP para frente e para trás entre os pares.
Solicitações de renovação de DHCP unicast : elas são enviadas diretamente ao servidor DHCP do
cliente DHCP para renovar a atribuição de endereço ip após 50% do tempo de concessão do endereço IP.
Reassociar solicitações de difusão DHCP : elas são feitas em qualquer servidor DHCP dentro do
intervalo do cliente. Eles são enviados após 87,5% da duração da concessão do endereço IP porque isso
indica que a solicitação unicast direcionada não funcionou. Para o processo DORA, esse processo envolve
uma comunicação de agente de retransmissão DHCP.
Se um cliente DHCP da Microsoft não receber um endereço DHCP IPv4 válido, provavelmente o cliente será
configurado para usar um endereço APIPA. Para obter mais informações, consulte o seguinte artigo da base de
dados de conhecimento: 220874 como usar o endereçamento TCP/IP automático sem um servidor DHCP
Toda a comunicação é feita nas portas UDP 67 e 68. Para obter mais informações, consulte o seguinte artigo da
base de dados de conhecimento: Noções básicas de 169289 DHCP (protocolo de configuração de host
dinâmico).
Noções básicas do DHCP (Dynamic Host
Configuration Protocol)
10/08/2021 • 15 minutes to read
O protocolo DHCP é um protocolo padrão definido pelo RFC 1541 (que é superado pelo RFC 2131) que permite
que um servidor distribua dinamicamente informações de endereçamento IP e configuração para clientes.
Normalmente, o servidor DHCP fornece ao cliente pelo menos essas informações básicas:
Endereço IP
Máscara de Sub-rede
Gateway Padrão Outras informações também podem ser fornecidas, como endereços de servidor DNS
(Serviço de Nome de Domínio Windows) e endereços de servidor WINS (Serviço de Nome de Internet).
O administrador do sistema configura o servidor DHCP com as opções que são analisados para o cliente.
Mais informações
Os seguintes produtos da Microsoft fornecem a funcionalidade do cliente DHCP:
Windows NT Versões do servidor 3.5, 3.51 e 4.0
Windows NT Estação de trabalho versões 3.5, 3.51 e 4.0
Windows 95
Microsoft Network Client versão 3.0 para MS-DOS
Microsoft LAN Manager Client versão 2.2c para MS-DOS
Microsoft TCP/IP-32 para Windows para Grupos de Trabalho versões 3.11, 3.11a e 3.11b
Clientes DHCP diferentes são suportados por diferentes opções que podem receber do servidor DHCP.
Os seguintes sistemas operacionais do servidor Microsoft fornecem a funcionalidade do servidor DHCP:
Windows NT Versão do servidor 3.5
Windows NT Versão do servidor 3.51
Windows NT Versão do servidor 4.0
Quando um cliente é inicializado pela primeira vez depois de configurado para receber informações de DHCP,
ele inicia uma conversa com o servidor.
Veja abaixo uma tabela de resumo da conversa entre o cliente e o servidor, que é seguida por uma descrição no
nível do pacote do processo:
DHCPOFFER
O servidor DHCP responde enviando um pacote DHCPOFFER. Na seção IP do trecho de captura abaixo, o
endereço de origem agora é o endereço IP do servidor DHCP e o Endereço de destino é o endereço de difusão
255.255.255.255.255. A seção DHCP identifica o pacote como uma Oferta. O campo LTDADDR é preenchido
com o endereço IP que o servidor está oferecendo ao cliente. Observe que o campo LTDDR ainda contém o
endereço físico do cliente solicitante. Além disso, vemos na seção Campo de Opção DHCP as várias opções que
estão sendo enviadas pelo servidor junto com o endereço IP. Nesse caso, o servidor está enviando a Máscara de
Sub-rede, o Gateway Padrão (Roteador), o Tempo de Concessão, o endereço do servidor WINS (Serviço de
Nome NetBIOS) e o Tipo de Nó NetBIOS.
Dhcprequest
O cliente responde ao DHCPOFFER enviando um DHCPREQUEST. Na seção IP da captura abaixo, o endereço de
origem do cliente ainda é 0.0.0.0 e o Destino do pacote ainda é 255.255.255.255.255. O cliente retém 0.0.0.0
porque o cliente não recebeu a verificação do servidor de que não há problema em começar a usar o endereço
oferecido. O Destino ainda é transmitido, porque mais de um servidor DHCP pode ter respondido e estar
mantendo uma reserva para uma Oferta feita ao cliente. Isso permite que esses outros servidores DHCP saibam
que podem liberar seus endereços oferecidos e devolvê-los aos pools disponíveis. A seção DHCP identifica o
pacote como uma Solicitação e verifica o endereço oferecido usando o campo DHCP: Endereço Solicitado. O
campo DHCP: Identificador de Servidor mostra o endereço IP do servidor DHCP que oferece a concessão.
Dhcpack
O servidor DHCP responde ao DHCPREQUEST com um DHCPACK, concluindo assim o ciclo de inicialização. O
endereço de origem é o endereço IP do servidor DHCP e o Endereço de destino ainda é 255.255.255.255. O
campo LTDADDR contém o endereço do cliente e os campos DEDDD e DHCP: Identificador do Cliente são o
endereço físico da placa de rede no cliente solicitante. A seção Opção DHCP identifica o pacote como um 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 = 157.54.48.151
IP: Destination Address = 255.255.255.255
IP: Data: Number of data bytes remaining = 308 (0x0134)
Se o cliente tiver anteriormente um endereço IP atribuído a DHCP e ele for reiniciado, o cliente solicitará
especificamente o endereço IP arrendado anteriormente em um pacote DHCPREQUEST especial. O endereço de
origem é 0.0.0.0 e o Destino é o endereço de difusão 255.255.255.255. Os clientes da Microsoft preencherão o
DHCP Campo de Opção DHCP: Endereço Solicitado com o endereço atribuído anteriormente. Os clientes
estritamente compatíveis com RFC preencherão o campo CIADDR com o endereço solicitado. O servidor DHCP
da Microsoft aceitará qualquer um deles.
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 = 0.0.0.0
IP: Destination Address = 255.255.255.255
IP: Data: Number of data bytes remaining = 308 (0x0134)
Neste ponto, o servidor pode ou não responder. O comportamento do Windows NT servidor DHCP depende da
versão do sistema operacional que está sendo usada, bem como de outros fatores, como a supercopiação. Se o
servidor determinar que o cliente ainda pode usar o endereço, ele permanecerá silencioso ou ACK o
DHCPREQUEST. Se o servidor determinar que o cliente não pode ter o endereço, ele enviará um 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 = 157.54.48.151
IP: Destination Address = 255.255.255.255
IP: Data: Number of data bytes remaining = 308 (0x0134)
Em seguida, o cliente iniciará o processo de descoberta, mas o pacote DHCPDISCOVER ainda tentará a
concessão do mesmo endereço. Em muitas instâncias, o cliente tth obterá o mesmo endereço, mas talvez não.
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 = 0.0.0.0
IP: Destination Address = 255.255.255.255
IP: Data: Number of data bytes remaining = 308 (0x0134)
As informações de DHCP obtidas pelo cliente de um servidor DHCP terão um tempo de concessão associado a
ele. O tempo de concessão define por quanto tempo o cliente pode usar as informações atribuídas ao DHCP.
Quando a concessão atingir determinados marcos, o cliente tentará renovar suas informações de DHCP.
Para exibir informações de IP em um Windows ou Windows para workgroups, use o utilitário IPCONFIG. Se o
cliente for Windows 95, use WINIPCFG.
Referências
Para obter mais informações sobre o DHCP, consulte RFC1541 e RFC2131. RfCs podem ser obtidos por meio da
Internet em vários sites, por exemplo: http://www.rfc-editor.org/ e http://www.tech-nic.qc.ca/
Diretrizes gerais para solucionar problemas do
DHCP
12/08/2021 • 2 minutes to read
Antes de começar a solucionar problemas, verifique os itens a seguir. Eles podem ajudá-lo a encontrar a causa
raiz do problema.
Lista de verificação
Quando começou o problema?
Há mensagens de erro?
O servidor DHCP estava funcionando anteriormente ou nunca funcionou? Se funcionou anteriormente,
algo mudou antes do problema começar. Por exemplo, uma atualização foi instalada? Foi feita uma
alteração na infraestrutura?
O problema é persistente ou intermitente? Se for intermitente, quando ela ocorreu pela última vez?
As falhas de concessão de endereço estão ocorrendo para todos os clientes ou apenas para clientes
específicos, como uma sub-rede de escopo único?
Há clientes na mesma sub-rede de rede que o servidor DHCP?
Se os clientes residiem na mesma sub-rede de rede, eles podem obter endereços IP?
Se os clientes não estão na mesma sub-rede de rede, os roteadores ou comutadores VLAN estão
configurados corretamente para ter agentes de retransmissão DHCP (também conhecidos como
Auxiliares de IP)?
O servidor DHCP é autônomo ou está configurado para alta disponibilidade, como escopo dividido ou
failover de DHCP?
Verifique os dispositivos intermediários em busca de recursos como VRRP/HSRP, Inspeção dinâmica de
ARP ou assegamento DHCP que são conhecidos por causar problemas.
Como usar o endereçamento TCP/IP automático
sem um servidor DHCP
10/08/2021 • 5 minutes to read
Este artigo descreve como usar o endereçamento do protocolo TCP/IP (protocolo de controle de transmissão)
automático sem que um servidor DHCP esteja presente na rede. As versões do sistema operacional listadas na
seção "aplica-se a" deste artigo têm um recurso chamado APIPA (endereçamento IP privado automático). com
esse recurso, um computador Windows pode atribuir a si mesmo um endereço IP (Internet Protocol) caso um
servidor DHCP não esteja disponível ou não exista na rede. Esse recurso torna a configuração e o suporte a uma
pequena rede local (LAN) que executa TCP/IP com menos dificuldade.
Mais informações
IMPORTANT
Siga as etapas nesta seção com cuidado. Problemas sérios podem ocorrer se você modificar o Registro incorretamente.
Antes de modificá-lo, faça backup do Registro para a restauração em caso de problemas.
um computador baseado em Windows configurado para usar o DHCP pode automaticamente atribuir a si
próprio um endereço IP (Internet Protocol) se um servidor DHCP não estiver disponível. Por exemplo, isso pode
ocorrer em uma rede sem um servidor DHCP, ou em uma rede se um servidor DHCP estiver temporariamente
inativo para manutenção.
A IANA (Internet Assigned Numbers Authority) reservou o 169.254.0.0-169.254.255.255 para o endereçamento
IP privado automático. Como resultado, o APIPA fornece um endereço que está garantido para não entrar em
conflito com endereços roteáveis.
Depois que o adaptador de rede tiver sido atribuído um endereço IP, o computador poderá usar TCP/IP para se
comunicar com qualquer outro computador que esteja conectado à mesma LAN e que também esteja
configurado para APIPA ou que tenha o endereço IP definido manualmente como 169.254. x. y (em que x. y é o
intervalo de endereços do cliente) com uma máscara de sub-rede de 255.255.0.0. Observe que o computador
não pode se comunicar com computadores em outras sub-redes ou com computadores que não usam o
endereçamento IP privado automático. O endereçamento IP privado automático é habilitado por padrão.
Talvez você queira desabilitá-lo em qualquer um dos seguintes casos:
Sua rede usa roteadores.
Sua rede está conectada à Internet sem um servidor NAT ou de proxy.
A menos que você tenha desabilitado mensagens relacionadas ao DHCP, as mensagens DHCP fornecem
notificações quando você altera entre o endereçamento DHCP e o endereçamento IP privado automático. Se o
sistema de mensagens DHCP for desabilitado acidentalmente, você poderá ativar as mensagens DHCP
novamente alterando o valor do valor PopupFlag na seguinte chave do registro de 00 para 01:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP
Observe que você deve reiniciar o computador para que a alteração entre em vigor. você também pode
determinar se o computador está usando o APIPA usando a ferramenta Winipcfg no Windows Millennium
edition, Windows 98 ou Windows 98 Second edition:
Clique em Iniciar, executar, digite "winipcfg" (sem as aspas) e, em seguida, clique em OK. Clique em mais
informações. Se a caixa endereço de configuração automática de IP contiver um endereço IP dentro do intervalo
169.254. x. x, o endereçamento IP privado automático será habilitado. Se a caixa de endereço IP existir, o
endereçamento IP privado automático não estará habilitado no momento. para Windows 2000, Windows XP ou
Windows Server 2003, você pode determinar se o computador está usando o APIPA usando o comando IPconfig
em um prompt de comando:
Clique em Iniciar, executar, digite "cmd" (sem as aspas) e clique em OK para abrir uma janela de linha de
comando do MS-DOS. Digite "ipconfig/all" (sem as aspas) e, em seguida, pressione a tecla ENTER. Se a linha '
autoconfiguração habilitada ' disser "Sim" e o ' endereço IP de configuração automática ' for 169.254. x. y (em
que x. y é o identificador exclusivo do cliente), o computador estará usando APIPA. Se a linha ' autoconfiguração
habilitada ' disser "não", o computador não está usando APIPA no momento. Você pode desabilitar o
endereçamento IP privado automático usando qualquer um dos métodos a seguir.
Você pode configurar as informações de TCP/IP manualmente, o que desabilita completamente o DHCP. Você
pode desabilitar o endereçamento IP privado automático (mas não o DHCP) editando o registro. você pode fazer
isso adicionando a entrada de registro DWORD "IPAutoconfigurationEnabled" com um valor de 0x0 para a
seguinte chave do registro para Windows Millennium edition, Windows98 ou Windows 98 Second edition:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP
para Windows 2000, Windows XP e Windows Server 2003, o APIPA pode ser desabilitado adicionando a entrada
de registro DWORD "IPAutoconfigurationEnabled" com um valor de 0x0 para a seguinte chave do registro:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<Adapter GUID>
NOTE
A subchave do GUID do adaptador é um GUID (identificador global exclusivo) para o adaptador de LAN do
computador.
Este artigo discute como solucionar problemas que ocorrem em clientes DHCP.
Logs de eventos
Examine os logs de eventos de administrador/eventos do cliente microsoft-Windows-dhcp/operacional e
microsoft-Windows-dhcp. Todos os eventos relacionados ao serviço de cliente DHCP são enviados a esses logs
de eventos. os eventos do cliente Microsoft-Windows-DHCP estão localizados no Visualizador de Eventos em
Logs de aplicativos e ser viços .
O comando do PowerShell "Get-netadapter-IncludeHidden" fornece as informações necessárias para interpretar
os eventos listados nos logs. Por exemplo, ID de interface, endereço MAC e assim por diante.
Coleta de dados
Recomendamos que você colete dados simultaneamente no cliente DHCP e no lado do servidor quando o
problema ocorrer. No entanto, dependendo do problema real, você também pode iniciar sua investigação
usando um único conjunto de dados no cliente DHCP ou no servidor DHCP.
Para coletar dados do servidor e do cliente afetado, use o Wireshark. Comece a coletar ao mesmo tempo no
cliente DHCP e nos computadores do servidor DHCP.
Execute os seguintes comandos no cliente que está enfrentando o problema:
ipconfig /release
ipconfig /renew
Em seguida, interrompa o Wireshark no cliente e no servidor. Verifique os rastreamentos gerados. Eles devem,
pelo menos, dizer em qual estágio a comunicação será interrompida.
Solucionar problemas no servidor DHCP
12/08/2021 • 3 minutes to read
Este artigo discute como solucionar problemas que ocorrem no servidor DHCP.
Logs de eventos
Verifique os logs de eventos do sistema e do serviço servidor DHCP (Logs de aplicativos e serviços >
Microsoft > Windows > DHCP-Ser ver ) para problemas relatados relacionados ao problema observado.
Dependendo do tipo de problema, um evento é registrado em um dos seguintes canais de evento: Eventos
operacionais do servidor DHCPEventos administrativos do servidor DHCP Eventos do sistema do servidor
DHCPEventos de notificação de filtro do servidor DHCPEventos de auditoria do servidor DHCP
Coleta de dados
Log do Servidor DHCP
Os logs de depuração do serviço servidor DHCP fornecem mais informações sobre a atribuição de concessão de
endereço IP e as atualizações dinâmicas de DNS que são feitas pelo servidor DHCP. Por padrão, esses logs estão
localizados em %windir% \ System32 \ Dhcp. Para obter mais informações, consulte Analisar arquivos de log do
servidor DHCP.
Rastreamento de rede
Um rastreamento de rede correlacionado pode indicar o que o servidor DHCP estava fazendo no momento em
que o evento foi registrado. Para criar esse rastreamento, siga estas etapas:
1. Vá para GitHube baixe o arquivo tss _tools.zip.
2. Copie o arquivotools.zip Tss e expanda-o para um local no disco local, como para _ a pasta ferramentas \
C:.
3. Execute o seguinte comando das ferramentas C: \ em uma janela de prompt de comando com elevados:
NOTE
Neste comando, substitua e pela ID do evento e o canal de evento no que você se <Stop:Evt:> <Other:>
concentrará em sua sessão de rastreamento. O Tss.cmd ReadMeHelp.docx arquivos contidos no arquivo
Tsstools.zip fornecem mais informações sobre todas as _ _ _ configurações disponíveis.
4. Depois que o evento é disparado, a ferramenta cria uma pasta chamada C: \ MS _ DATA. Essa pasta
conterá alguns arquivos de saída úteis que fornecem informações gerais sobre a configuração de rede e
domínio do computador. O arquivo mais interessante nessa pasta é %Computername% _ date _ time _
packetcapture _ InternetClient _ dbg.etl. Usando o Monitor de Rede, você pode carregar o arquivo e
definir o filtro de exibição no protocolo "DHCP ou DNS" para examinar o que está acontecendo nos
bastidores.
EAP (protocolo de autenticação extensível) para
acesso à rede
07/08/2021 • 27 minutes to read
aplica-se a: Windows server 2022, Windows server 2019, Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012, Windows 10, Windows 8.1
O EAP (protocolo de autenticação extensível) é uma estrutura arquitetônica que fornece extensibilidade para
métodos de autenticação para tecnologias de acesso à rede protegidas comumente usadas, como o acesso sem
fio baseado em IEEE 802.1 X, o acesso com fio baseado em IEEE 802.1 X e conexões de protocolo PPP (PPP),
como VPN (rede virtual privada). O EAP não é um método de autenticação como o MS-CHAP v2, mas sim uma
estrutura no cliente de acesso e no servidor de autenticação que permite aos fornecedores de rede desenvolver
e instalar facilmente novos métodos de autenticação conhecidos como métodos EAP.
Métodos de autenticação
Este tópico contém informações específicas sobre configuração dos seguintes métodos de autenticação em EAP.
Observe que os métodos de autenticação EAP usados em métodos EAP encapsulados são comumente
conhecidos como métodos internos ou tipos de EAP .
EAP protegido (PEAP)
Esta seção contém informações de configuração para os dois métodos EAP internos padrão fornecidos
com o PEAP.
Protocolo EAP-TLS (Transport Layer Security)
Aparecendo como car tão inteligente ou outras propriedades de cer tificado no sistema
operacional, o EAP-TLS pode ser implantado como um método interno para PEAP ou como um
método EAP autônomo. Quando é configurado como método de autenticação interno, as
definições de configuração do EAP-TLS são idênticas às definições usadas para implantar o EAP-
TLS como método externo, com a diferença de que ele é configurado para operar no PEAP. Para
obter detalhes de configuração, consulte cartão inteligente ou outros itens de configuração de
propriedades de certificado.
MS-CHAP v2 (EAP-Microsoft Challenge Handshake Authentication Protocol versão 2)
EAP-MS-CHAP v2 de senha segura é um tipo de EAP que pode ser usado com o PEAP para
autenticação de rede baseada em senha. O EAP-MsCHAP V2 também pode ser usado como um
método autônomo para VPN, mas somente como um método interno de PEAP para sem fio.
Protocolo EAP-TTLS (Tunneled Transpor t Layer Security)
EAP-SIM (Subscriber Identity Module), EAP- AKA (Authentication and Key Agreement), e
EAP-AKA' (AKA Prime)
Permite a autenticação usando cartões SIM e é implementado quando um cliente adquire um plano de
serviço de banda larga sem fio de uma operadora de rede móvel. Como parte do plano, o cliente
normalmente recebe um perfil móvel que é pré-configurado para autenticação SIM.
Este tópico fornece informações sobre o seguinte:
Definições de configuração de EAP-SIM
Definições de configuração de EAP-AKA e EAP-AKA
IMPORTANT
A implantação do mesmo tipo de método de autenticação para PEAP e EAP cria uma vulnerabilidade de segurança.
Quando você implantar PEAP e EAP (que não é protegido), não use o mesmo tipo de autenticação. Por exemplo, se você
implantar o PEAP-TLS, não implante também o EAP-TLS.
NOTE
Não especifique um certificado de autoridade de certificação raiz confiável que ainda não esteja listado nos repositórios de
certificados Autoridades de Cer tificação Raiz Confiáveis dos computadores clientes para o Usuário Atual e
Computador Local. Se você designar um certificado que não esteja instalado nos computadores cliente, a autenticação
falhará.
NOTE
Se você designar um certificado que não esteja instalado nos computadores cliente, a autenticação falhará.
Selecionar EKUs
Você pode selecionar um EKU na lista fornecida ou adicionar um novo.
IT EM DETA L H ES
Insira o nome de EKU Fornece um local para digitar o nome do EKU personalizado.
Insira o OID EKU Fornece um local para digitar o OID do EKU. Somente
números, separadores e “.” são permitidos. É permitido inserir
curingas. Nesse caso, todos os OIDs filhos na hierarquia são
permitidos. Por exemplo, se você informar 1.3.6.1.4.1.311.*,
serão permitidos 1.3.6.1.4.1.311.42 e 1.3.6.1.4.1.311.42.2.1
NOTE
Se você designar um certificado que não esteja instalado nos computadores cliente, a autenticação falhará.
NOTE
A lista de listas listadas selecionar um método EAP para autenticação enumerará todos os métodos de EAP
instalados no servidor, exceto os métodos PEAP e FAST tunnel. Os tipos EAP são listados na ordem em que são
descobertos pelo computador.
Configurar
Abre a caixa de diálogo de propriedades do tipo EAP especificado. Para obter detalhes sobre os tipos de EAP
padrão, consulte Itens de configuração de propriedades de cartão inteligente ou outros itens de configuração de
propriedades de certificado ou Senha segura (EAP-MSCHAP v2)itens de configuração de propriedades .
Definições de configuração do EAP-SIM
O EAP-SIM é usado na distribuição de chaves de sessão e autenticação para sistemas GSM (Global System for
Mobile Communications). EAP-SIM é definido em RFC 4186.
A tabela a seguir lista as definições de configuração do EAP-SIM.
IT EM DESC RIÇ Ã O
Usar chaves de Criptografia for tes Se selecionada, especifica que o perfil usa criptografia forte.
Não revelar a identidade real no ser vidor quando a Quando habilitada, força o cliente a falhar na autenticação
identidade do pseudônimo estiver disponível quando as solicitações do servidor por identidade
permanente no cliente têm uma identidade de pseudônimo.
As identidades de pseudônimos são usadas na privacidade
de identidades, de modo que o identidade real ou
permanente de um usuário não seja revelada durante a
autenticação.
Habilitar uso de realms Fornece um local para digitação do nome do realm. Se esse
campo for deixado em branco com Habilitar uso de realms
selecionado, o realm será derivado da IMSI (Identidade do
Assinante Móvel Internacional) usando o realm 3gpp.org,
conforme descrito no padrão Project 3GPP (3GPP) 23.003
V6.8.0.
IT EM DESC RIÇ Ã O
Não revelar a identidade real no ser vidor quando a Quando habilitada, força o cliente a falhar na autenticação
identidade do pseudônimo estiver disponível quando as solicitações do servidor por identidade
permanente no cliente têm uma identidade de pseudônimo.
As identidades de pseudônimos são usadas na privacidade
de identidades, de modo que o identidade real ou
permanente de um usuário não seja revelada durante a
autenticação.
Habilitar uso de realms Fornece um local para digitação do nome do realm. Se esse
campo for deixado em branco com Habilitar uso de realms
selecionado, o realm será derivado da IMSI (Identidade do
Assinante Móvel Internacional) usando o realm 3gpp.org,
conforme descrito no padrão Project 3GPP (3GPP) 23.003
V6.8.0.
IT EM DESC RIÇ Ã O
Não revelar a identidade real no ser vidor quando a Quando habilitada, força o cliente a falhar na autenticação
identidade do pseudônimo estiver disponível quando as solicitações do servidor por identidade
permanente no cliente têm uma identidade de pseudônimo.
As identidades de pseudônimos são usadas na privacidade
de identidades, de modo que o identidade real ou
permanente de um usuário não seja revelada durante a
autenticação.
Habilitar uso de realms Fornece um local para digitação do nome do realm. Se esse
campo for deixado em branco com Habilitar uso de realms
selecionado, o realm será derivado da IMSI (Identidade do
Assinante Móvel Internacional) usando o realm 3gpp.org,
conforme descrito no padrão Project 3GPP (3GPP) 23.003
V6.8.0.
Ignorar incompatibilidade de nome de rede O cliente compara o nome da rede conhecido com o nome
enviado pelo servidor RADIUS durante a autenticação. Se
houver incompatibilidade, ela será ignorada se essa opção
estiver selecionada. Se não estiver selecionada, haverá falha
de autenticação.
Habilitar Reautenticação Rápida Especifica que a reautenticação rápida está habilitada. Esse
recurso é útil quando a autenticação SIM é realizada com
frequência. As chaves de criptografia derivadas da
autenticação completa são reutilizadas. Como resultado, o
algoritmo SIM não precisa ser executado em cada tentativa
de autenticação, e o número de operações de rede
resultantes das tentativas frequentes de autenticação é
reduzido.
Recursos adicionais
Para obter informações adicionais sobre configurações sem fio autenticadas no Política de Grupo, consulte
Gerenciando a nova rede sem fio (IEEE 802.11) Políticas Configurações
Para obter informações adicionais sobre configurações com fio autenticadas no Política de Grupo, consulte
Gerenciando a nova rede com fio (IEEE 802.3) políticas Configurações
Para obter informações sobre configurações avançadas para acesso com fio autenticado e acesso sem fio
autenticado, consulte Advanced Security Settings for Wired and Wireless Network Policies.
Rede de alto desempenho (HPN)
07/08/2021 • 2 minutes to read
aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019
Redes de alto desempenho (HPNs) desempenham uma função em requisitos de processamento de dados em
tempo real. Por exemplo, atividades como a replicação do datacenter, a recuperação de desastres do datacenter
e a computação distribuída de alto desempenho exigem alta transferência de dados de volume e baixa latência
de rede. HPNs com recursos de conexão dinâmica tornam os recursos de rede de alto desempenho mais
acessíveis e gerenciáveis. Para saber mais, confira requisitos de rede do host para Azure Stack HCI.
Os tópicos de rede de alto desempenho incluem:
Insider Preview
Tecnologias de descarregamento e de otimização de rede
Recursos e tecnologias de SO (apenas software)
Recursos e tecnologias integrados a SH (software e hardware)
Tecnologias e recursos de HO (apenas hardware)
Propriedades avançadas de NIC
RSC no vSwitch
Tecnologias de descarregamento e otimização de
rede
07/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019
Neste tópico, apresentamos uma visão geral dos diferentes recursos de descarregaamento e otimização de rede
disponíveis no Windows Server 2016 e discutiremos como eles ajudam a tornar a rede mais eficiente. Essas
tecnologias incluem recursos e tecnologias so (somente software), recursos e tecnologias integrados de SH
(Software e Hardware) e tecnologias e recursos e tecnologias somente hardware (HO). Para saber mais, confira
Requisitos de rede de host para Azure Stack HCI.
As três categorias de recursos de rede disponíveis no Windows Server 2016 são:
1. Tecnologias e recursos somente de software (SO): esses recursos são implementados como parte do
sistema operacional e são independentes das NIC(s) subjacentes. Às vezes, esses recursos exigirão algum
ajuste da NIC para uma operação ideal. Exemplos disso incluem recursos do Hyper-V, como vmQoS, ACLs
e recursos que não são do Hyper-V, como o NIC Teaming.
2. Recursos e tecnologias integradosde SOFTWARE e Hardware (SH) : esses recursos têm componentes de
software e hardware. O software está intimamente vinculado aos recursos de hardware necessários para
que o recurso funcione. Exemplos disso incluem VMMQ, VMQ, Descarregado de Soma de Verificação IPv4
do lado de envio e RSS.
3. Tecnologias e recursos de HO (Hardware Only): essas acelerações de hardware melhoram o desempenho
de rede em conjunto com o software, mas não fazem parte de nenhum recurso de software. Exemplos
disso incluem Moderação de interrupção, Flow controle e descarregamento de verificação IPv4 do lado
do recebimento.
4. Propriedades avançadas da NIC:você pode gerenciar NICs e todos os recursos por meio Windows
PowerShell usando o cmdlet NetAdapter. Você também pode gerenciar NICs e todos os recursos usando
Painel de Controle (ncpa.cpl).
TIP
Os recursos e tecnologias do SO estão disponíveis em todas as arquiteturas de hardware, independentemente da
velocidade da NIC ou dos recursos de NIC.
Os recursos sh e HO estão disponíveis somente quando o adaptador de rede dá suporte aos recursos ou
tecnologias.
Somente software (SO) recursos e tecnologias
12/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019
Somente recursos de software são implementados como parte do sistema operacional e são independentes das
NIC(s) subjacentes. Às vezes, esses recursos exigem algum ajuste da NIC para uma operação ideal. Exemplos
disso incluem recursos do Hyper-V, como vmQoS (Virtual Machine Quality of Service), ACLs (Listas de Controle
de Acesso) e recursos não Hyper-V, como o NIC Teaming. Para saber mais, confira Requisitos de rede de host
para Azure Stack HCI.
ACLs estendidas
As ACLs estendidas do Com switch virtual hyper-V permitem que você configure as ACLs de Porta Estendida do
Com switch virtual do Hyper-V para fornecer proteção de firewall e impor políticas de segurança para as VMs
de locatário em datacenters. Como as ACLs de porta estão configuradas no Comutar Virtual do Hyper-V em vez
de dentro das VMs, o administrador pode gerenciar políticas de segurança para todos os locatários em um
ambiente multitenatário.
Você pode gerenciar ACLs estendidas do comutadores hyper-V por meio dos cmdlets Add-
VMNetworkAdapterExtendedAcl e Remove-VMNetworkAdapterExtendedAcl do PowerShell.
TIP
Esse recurso se aplica à pilha HNVv1. Para ACLs na pilha SDN, consulte ACLs do SDN de Rede Definida pelo Software
abaixo.
Para obter mais informações sobre listas de controle de acesso de porta estendida nesta biblioteca, consulte
Criar políticas de segurança com listas de controle de acesso de porta estendida.
Agrupamento NIC
O NIC Teaming, também chamado de vínculo NIC, é a agregação de várias portas NIC em uma entidade que o
host percebe como uma única porta NIC. O NIC Teaming protege contra a falha de uma única porta NIC (ou o
cabo conectado a ela). Ele também agrega o tráfego de rede para uma produtividade mais rápida. Para obter
mais detalhes, consulte NIC Teaming.
Com Windows Server 2016 você tem duas maneiras de fazer o teaming:
1. Windows Server 2012 de equipe
2. Windows Server 2016 Set (Switch Embedded Teaming)
RSC no vSwitch
O RSC (Receive Segment Coalescing) no vSwitch é um recurso que aceita pacotes que fazem parte do mesmo
fluxo e chegam entre interrupções de rede e os une em um único pacote antes de fornená-los ao sistema
operacional. O com switch virtual no Windows Server 2019 tem esse recurso. Para obter mais detalhes sobre
esse recurso, consulte Receive Segment Coalescing in the vSwitch.
aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019
Esses recursos têm componentes de software e hardware. O software está intimamente ligado a recursos de
hardware que são necessários para que o recurso funcione. Exemplos desses incluem VMMQ, VMQ,
descarregamento de soma de verificação do IPv4 do lado do envio e RSS. Para saber mais, confira requisitos de
rede do host para Azure Stack HCI.
TIP
Os recursos SH e HO estarão disponíveis se a NIC instalada der suporte a ele. As descrições de recurso a seguir abordarão
como saber se a NIC dá suporte ao recurso.
NIC convergida
A NIC convergida é uma tecnologia que permite que as NICs virtuais no host Hyper-V exponham serviços
RDMA para hospedar processos. Windows Server 2016 não requer mais NICs separadas para RDMA. O recurso
NIC convergida permite que as NICs virtuais na partição de host (vNICs) exponham RDMA à partição de host e
compartilhem a largura de banda das NICs entre o tráfego RDMA e a VM e outro tráfego TCP/UDP de uma
maneira justa e gerenciável.
Você pode gerenciar a operação de NIC convergida por meio do VMM ou Windows PowerShell. Os cmdlets do
PowerShell são os mesmos cmdlets usados para RDMA (veja abaixo).
Para usar a capacidade de NIC convergida:
1. Certifique-se de definir o host para DCB.
2. Certifique-se de habilitar o RDMA na NIC ou, no caso de uma equipe definida, as NICs estão associadas à
opção do Hyper-V.
3. Certifique-se de habilitar o RDMA no vNICs designado para RDMA no host.
Para obter mais detalhes sobre o RDMA e o conjunto, consulte acesso remoto direto à memória (RDMA) e
alternância inserida de equipe (Set).
v2 NVGRE (HNVv2 NVGRE) em Windows Server 2016 e System Center Virtual Machine
Manager, a Microsoft fornece uma solução de virtualização
de rede de ponta a ponta que inclui Gateway de RAS,
balanceamento de carga de Software, controlador de rede e
muito mais. Para obter mais informações, consulte visão
geral da virtualização de rede Hyper-V no Windows Server
2016.
v2 VxL AN (HNVv2 VxL AN) no Windows Server 2016, faz parte da extensão SDN, que
você gerencia por meio do controlador de rede.
IMPORTANT
O descarregamento de Chimney TCP é uma tecnologia preterida. Recomendamos que você não use o descarregamento
de Chimney TCP, pois a Microsoft pode parar de dar suporte a ele no futuro.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019
Essas acelerações de hardware melhoram o desempenho de rede em conjunto com o software, mas não fazem
parte de nenhum recurso de software. Exemplos disso incluem Moderação de interrupção, Flow controle e
descarregamento de verificação IPv4 do lado do recebimento. Para saber mais, confira Requisitos de rede de
host para Azure Stack HCI.
TIP
Os recursos SH e HO estarão disponíveis se a NIC instalada for compatível com ele. As descrições do recurso abaixo
abrangem como saber se a NIC dá suporte ao recurso.
Quadros jumbo
Frames Dols é um recurso de rede e NIC que permite que um aplicativo envie quadros muito maiores do que os
1500 bytes padrão. Normalmente, o limite em quadros de frames do Frames é de cerca de 9.000 bytes, mas
pode ser menor.
Não houve nenhuma alteração no suporte ao quadro de quadros no Windows Server 2012 R2.
No Windows Server 2016 há um novo descarregado: MTU_for_HNV. Esse novo descarregamento funciona com
as configurações de Frame do York para garantir que o tráfego encapsulado não requer segmentação entre o
host e o computação adjacente. Esse novo recurso da pilha SDN faz com que a NIC calcule automaticamente
qual MTU anunciar e qual MTU usar na transmissão. Esses valores para MTU serão diferentes se qualquer
descarregado de HNV estiver em uso. (Na tabela de compatibilidade de recursos, Tabela 1, MTU_for_HNV teria
as mesmas interações que os descarregados HNVv2, pois está diretamente relacionado às descarregadas
HNVv2.)
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019
Você pode gerenciar NICs e todos os recursos por meio Windows PowerShell usando o cmdlet NetAdapter. Você
também pode gerenciar NICs e todos os recursos usando Painel de Controle (ncpa.cpl). Para saber mais, confira
Requisitos de rede de host para Azure Stack HCI.
1. No Windows PowerShell , execute o Get NetAdapterAdvancedProperty cmdlet em relação a duas
diferentes make/model de NICs.
No passado, filas de máquina virtual e várias filas de máquinas virtuais permitiam uma taxa de transferência
muito maior para VMs individuais, pois as taxas de transferência de rede atingiram primeiro a marca de 10 GbE
e além. Infelizmente, o planejamento, a base, o ajuste e o monitoramento necessários para o sucesso se
tornaram uma grande tarefa; geralmente mais do que o administrador de IT pretendia gastar.
Windows O Server 2019 aprimora essas otimizações, difundindo e ajustando dinamicamente o processamento
de cargas de trabalho de rede conforme necessário. Windows O Servidor 2019 garante a eficiência máxima e
remove a carga de configuração para os administradores de IT. Para saber mais, confira Requisitos de rede de
host para Azure Stack HCI.
Para obter mais informações, consulte:
Blog do comunicado
Guia de validação para a equipe de PRO
O RSC (Receive Segment Coalescing) no vSwitch é um aprimoramento que une vários segmentos TCP em um
segmento maior antes de os dados atravessarem o vSwitch. O segmento grande melhora o desempenho de
rede para cargas de trabalho virtuais.
Anteriormente, esse era um descarregado implementado pela NIC. Infelizmente, isso foi desabilitado no
momento em que você anexou o adaptador a um com switch virtual. A RSC no vSwitch no Windows Server
2019 e Atualização de outubro de 2018 para o Windows 10 remove essa limitação.
Por padrão, a RSC no vSwitch é habilitada em comutadores virtuais externos.
Para obter mais informações, consulte:
Blog do comunicado
Guia de validação para a equipe de PRO
RSC no vSwitch
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019
IMPORTANT
Importante: a RSC no vSwitch pode ser habilitada e desabilitada em tempo real sem afetar as conexões existentes.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
NIC de placa de interface de rede convergida ( ) permite expor RDMA por meio de uma - vNIC NIC virtual de
partição de host ( ) para que os serviços de partição de host possam acessar o RDMA de acesso remoto direto à
memória ( ) nas mesmas NICs que os convidados do Hyper-V estão usando para tráfego TCP/IP.
Antes do recurso NIC convergido, os serviços de partição de host de gerenciamento ( ) que desejavam usar o
RDMA eram necessários para usar NICs compatíveis com RDMA dedicados - , mesmo que a largura de banda
estivesse disponível nas NICs que estavam associadas ao comutador virtual Hyper-V.
Com a NIC convergida, as duas cargas de trabalho ( gerenciam os usuários de tráfego de RDMA e convidado )
podem compartilhar as mesmas NICs físicas, permitindo que você instale menos NICs em seus servidores.
quando você implanta a NIC convergida com Windows Server 2016 hosts hyper-v e comutadores virtuais do
hyper-v, o vNICs nos hosts hyper-v expõe serviços RDMA para hospedar processos usando RDMA em qualquer
- tecnologia RDMA baseada em Ethernet.
NOTE
Para usar a tecnologia NIC convergida, os adaptadores de rede certificados em seus servidores devem dar suporte a
RDMA.
Este guia fornece dois conjuntos de instruções, um para implantações em que os servidores têm um único
adaptador de rede instalado, que é uma implantação básica da NIC convergida; e outro conjunto de instruções
em que os servidores têm dois ou mais adaptadores de rede instalados, que é uma implantação de NIC
convergida em uma ( equipe do conjunto de agrupamentos integrado de comutador ) de - adaptadores de rede
habilitado para RDMA.
Pré-requisitos
Veja a seguir os pré-requisitos para as implantações básica e de datacenter da NIC convergida.
NOTE
para os exemplos fornecidos, usamos um adaptador Ethernet Mellanox ConnectX-3 Pro 40 Gbps, mas você pode usar
qualquer um dos adaptadores de rede compatíveis com o Windows Server certified RDMA - que dão suporte a esse
recurso. para obter mais informações sobre adaptadores de rede compatíveis, consulte os cartões de LANdo tópico do
catálogo do Windows Server.
Tópicos relacionados
Configuração de NIC convergida com um único adaptador de rede
Configuração NIC agrupada NIC convergida
Configuração de comutador físico para NIC convergida
Solucionando problemas de configurações de NIC convergida
Configuração de NIC convergida com um único
adaptador de rede
13/08/2021 • 12 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Neste tópico, fornecemos as instruções para configurar a NIC convergida com uma única NIC em seu host
Hyper-V.
A configuração de exemplo neste tópico descreve dois hosts Hyper-V, Host A do Hyper-V e Host Hyper-V B.
Ambos os hosts têm uma única pNIC (NIC física) instalada e as NICs são conectadas a um comutador físico ( ToR
) de rack. Além disso, os hosts estão localizados na mesma sub-rede, que é 192.168.1.x/24.
Get-NetAdapter
Resultados:
IN T ERFA C EDES
NOME C RIP T IO N SE_ÍN DIC E STAT US M A C A DDRESS L IN K SP EED
Get-NetAdapter M1 | fl *
Resultados:
MacAddress : 7C-FE-90-93-8F-A1
Status : Up
LinkSpeed: 40 Gbps
MediaType: 802.3
PhysicalMediaType: 802.3
AdminStatus : Up
MediaConnectionState : Connected
DriverInformation: Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60
DriverFileName : mlx4eth63.sys
NdisVersion : 6.60
ifOperStatus : Up
ifAlias : M1
InterfaceAlias : M1
ifIndex : 4
ifDesc : Mellanox ConnectX-3 Pro Ethernet Adapter
ifName : ethernet_32773
DriverVersion: 5.25.12665.0
LinkLayerAddress : 7C-FE-90-93-8F-A1
Caption :
Description :
ElementName :
InstanceID : {39B58B4C-8833-4ED2-A2FD-E105E7146D43}
CommunicationStatus :
DetailedStatus :
HealthState :
InstallDate :
Name : M1
OperatingStatus :
OperationalStatus:
PrimaryStatus:
StatusDescriptions :
AvailableRequestedStates :
EnabledDefault : 2
EnabledState : 5
OtherEnabledState:
RequestedState : 12
TimeOfLastStateChange:
TransitioningToState : 12
AdditionalAvailability :
Availability :
CreationClassName: MSFT_NetAdapter
TIP
Se você tiver certeza de que os hosts podem se comunicar entre si, ignore esta etapa.
Test-NetConnection 192.168.1.5
Resultados:
PA RÂ M ET RO VA LO R
ComputerName 192.168.1.5
RemoteAddress 192.168.1.5
AliasdeInterface M1
SourceAddress 192.168.1.3
PingSucceeded True
Em alguns casos, talvez seja necessário desabilitar Windows Firewall com Segurança Avançada para executar
esse teste com êxito. Se você desabilitar o firewall, tenha em mente a segurança e verifique se a configuração
atende aos requisitos de segurança da sua organização.
2. Desabilite todos os perfis de firewall.
Test-NetConnection 192.168.1.5
Resultados:
PA RÂ M ET RO VA LO R
ComputerName 192.168.1.5
RemoteAddress 192.168.1.5
AliasdeInterface Test-40G-1
SourceAddress 192.168.1.3
PingSucceeded Falso
NOTE
Consulte a documentação da opção ToR para obter instruções sobre como configurar o modo Tronco na opção .
A imagem a seguir mostra dois hosts Hyper-V, cada um com um adaptador de rede física e cada um
configurado para se comunicar na VLAN 101.
IMPORTANT
Execute isso nos servidores locais e de destino. Se o servidor de destino não estiver configurado com a mesma ID de
VLAN que o servidor local, os dois não poderão se comunicar.
IMPORTANT
Não execute esse comando se você estiver conectado ao host remotamente por meio dessa interface, pois isso
resulta na perda de acesso ao host.
Resultados:
Resultados:
IN T ERFA C EDES
NOME C RIP T IO N SE_ÍN DIC E STAT US M A C A DDRESS L IN K SP EED
IMPORTANT
Pode levar vários segundos para o dispositivo reiniciar e ficar disponível na rede.
4. Verifique a conectividade.
Se a conectividade falhar, inspecione a configuração do switch VLAN ou a participação de destino na
mesma VLAN.
Test-NetConnection 192.168.1.5
Install-WindowsFeature Data-Center-Bridging
Da
PA RÂ M ET RO VA LO R
Nome SMB
NetworkProfile Tudo
Precedência 127
JobObject
NetDirectPort 445
Prioridadevalue 3
3. para implantações de RoCE, ative o controle de prioridade Flow para o tráfego SMB, o que não é
necessário para o iWarp.
Enable-NetQosFlowControl -priority 3
Get-NetQosFlowControl
Da
0 Falso Global
1 Falso Global
2 Falso Global
3 True Global
4 Falso Global
5 Falso Global
6 Falso Global
7 Falso Global
Da
Nome : M1 habilitado : verdadeiro
Técnicas
PA RÂ M ET RO H A RDWA RE C URREN T
OperationalTrafficClasses:
1 ETS 30% 3
OperationalFlowControl:
Prioridade 3 habilitada
OperationalClassifications:
Padrão 0
NetDirect 445 3
Da
L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S
Get-NetQosTrafficClass
Da
L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S
Get-NetAdapterRdma
Da
Da
M2 14 {192.168.1.5}
NOTE
Se o tráfego RDMA falhar, para o caso RoCE especificamente, consulte a configuração do comutador ToR para
configurações apropriadas de PFC/ETS que devem corresponder às configurações do host. Consulte a seção QoS
neste documento para obter os valores de referência.
Da
Get-NetAdapter | ft -AutoSize
Da
IN T ERFA C EDES
NOME C RIP T IO N SE_ÍN DIC E STAT US M A C A DDRESS L IN K SP EED
Resultados:
4. Teste a conexão.
Test-NetConnection 192.168.1.5
Resultados:
ComputerName : 192.168.1.5
RemoteAddress : 192.168.1.5
InterfaceAlias : vEthernet (CORP-External-Switch)
SourceAddress : 192.168.1.3
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
Resultados:
VM N ET W O RK A DA P T ERN A
VM N A M E ME M O DE VL A N L IST
Test-NetConnection 192.168.1.5
Resultados:
ComputerName : 192.168.1.5
RemoteAddress : 192.168.1.5
InterfaceAlias : vEthernet (VMSTEST)
SourceAddress : 192.168.1.3
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
Resultados:
Nome: VMSTEST IeeePriorityTag: On
2. Exibir as informações de RDMA do adaptador de rede.
Get-NetAdapterRdma
Resultados:
Get-NetAdapter
Resultados:
IN T ERFA C EDES
NOME C RIP T IO N SE_ÍN DIC E STAT US M A C A DDRESS L IN K SP EED
Resultados:
NOTE
Se o parâmetro Enabled tiver o valor True , isso significa que o RDMA está habilitado.
A linha final nesta saída, "Teste de tráfego RDMA BEM-sucedido: o tráfego RDMA foi enviado para 192.168.1.5",
mostra que você configurou com êxito a NIC convergida em seu adaptador.
Tópicos relacionados
Configuração de NIC em NIC convergida
Configuração do com switch físico para NIC convergida
Solução de problemas de configurações de NIC convergida
NIC convergida em uma configuração de NIC em
equipe (datacenter)
12/08/2021 • 24 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Neste tópico, fornecemos instruções para implantar a NIC convergida em uma configuração de NIC com Switch
Embedded Teaming ( SET ) .
A configuração de exemplo neste tópico descreve dois hosts Hyper-V, Host Hyper-V 1 e Host Hyper-V 2.
Ambos os hosts têm dois adaptadores de rede. Em cada host, um adaptador é conectado à sub-rede
192.168.1.x/24 e um adaptador está conectado à sub-rede 192.168.2.x/24.
Resultados:
IN T ERFA C EDES
NOME C RIP T IO N SE_ÍN DIC E STAT US M A C A DDRESS L IN K SP EED
Resultados:
PA RÂ M ET RO VA LO R
IPAddress 192.168.1.3
Interfaceindex 11
AliasdeInterface Test-40G-1
Addressfamily IPv4
Tipo Unicast
PrefixLength 24
Resultados:
IN T ERFA C EDES
NOME C RIP T IO N SE_ÍN DIC E STAT US M A C A DDRESS L IN K SP EED
Resultados:
PA RÂ M ET RO VA LO R
IPAddress 192.168.2.3
Interfaceindex 13
AliasdeInterface TEST-40G-2
Addressfamily IPv4
Tipo Unicast
PA RÂ M ET RO VA LO R
PrefixLength 24
5. Verifique se outros pNICs de membro set ou equipe NIC têm um endereço IP válido.
Use uma sub-rede separada, ( xxx.xxx.2 .xxx versus xxx.xxx. 1 .xxx ) , para facilitar o envio desse adaptador
para o destino. Caso contrário, se você localizar ambos os pNICs na mesma sub-rede, o Windows
balancear a carga da pilha TCP/IP entre as interfaces e a validação simples se tornará mais complicado.
Test-NetConnection 192.168.1.5
Resultados:
PA RÂ M ET RO VA LO R
ComputerName 192.168.1.5
RemoteAddress 192.168.1.5
AliasdeInterface Test-40G-1
SourceAddress 192.168.1.3
PingSucceeded Falso
Em alguns casos, talvez seja necessário desabilitar Windows Firewall com Segurança Avançada para
executar esse teste com êxito. Se você desabilitar o firewall, tenha em mente a segurança e verifique se a
configuração atende aos requisitos de segurança da sua organização.
2. Desabilite todos os perfis de firewall.
Test-NetConnection 192.168.1.5
Resultados:
PA RÂ M ET RO VA LO R
ComputerName 192.168.1.5
PA RÂ M ET RO VA LO R
RemoteAddress 192.168.1.5
AliasdeInterface Test-40G-1
SourceAddress 192.168.1.3
PingSucceeded Falso
4. Verifique a conectividade para NICs adicionais. Repita as etapas anteriores para todos os pNICs
subsequentes incluídos na NIC ou no conjunto de equipe.
Test-NetConnection 192.168.2.5
Da
PA RÂ M ET RO VA LO R
ComputerName 192.168.2.5
RemoteAddress 192.168.2.5
AliasdeInterface Teste-40G-2
SourceAddress 192.168.2.3
PingSucceeded Falso
NOTE
Consulte a documentação do comutador ToR para obter instruções sobre como configurar o modo de tronco no
comutador.
A imagem a seguir mostra dois hosts Hyper-V com dois adaptadores de rede cada um com VLAN 101 e VLAN
102 configurados nas propriedades do adaptador de rede.
TIP
De acordo com os padrões de rede IEEE do Instituto de engenheiros elétricos e eletrônicos ( ) , as propriedades de QoS de
qualidade de serviço ( ) na NIC física agem no cabeçalho 802.1 p que é inserido no ( cabeçalho VLAN 802.1 q ) quando
você configura a ID de VLAN.
Da
Da
IN T ERFA C EDES
NOME C RIP T IO N IF IN DEX STAT US M A C A DDRESS L IN K SP EED
Da
Da
IN T ERFA C EDES
NOME C RIP T IO N IF IN DEX STAT US M A C A DDRESS L IN K SP EED
IMPORTANT
Pode levar vários segundos para o dispositivo reiniciar e ficar disponível na rede.
Test-NetConnection 192.168.1.5
Da
PA RÂ M ET RO VA LO R
ComputerName 192.168.1.5
RemoteAddress 192.168.1.5
AliasdeInterface Test-40G-1
SourceAddress 192.168.1.5
PA RÂ M ET RO VA LO R
PingSucceeded True
Test-NetConnection 192.168.2.5
Da
PA RÂ M ET RO VA LO R
ComputerName 192.168.2.5
RemoteAddress 192.168.2.5
AliasdeInterface Teste-40G-2
SourceAddress 192.168.2.3
PingSucceeded True
IMPORTANT
Não é incomum para um Test-NetConnection ou a falha de ping ocorrer imediatamente após a execução de
Restar t-netadapter . Portanto, aguarde até que o adaptador de rede seja inicializado completamente e tente
novamente.
Se as conexões de VLAN 101 funcionarem, mas as conexões de VLAN 102 não, o problema pode ser que a opção
precisa ser configurada para permitir o tráfego de porta na VLAN desejada. Você pode verificar isso Configurando
temporariamente os adaptadores com falha para a VLAN 101 e repetindo o teste de conectividade.
A imagem a seguir mostra os hosts do Hyper-V após configurar com êxito as VLANs.
Etapa 4. Configurar a qualidade do serviço ( QoS)
NOTE
Você deve executar todas as seguintes etapas de configuração de DCB e QoS em todos os hosts que se destinam a se
comunicar entre si.
Install-WindowsFeature Data-Center-Bridging
Da
REIN IC IA L IZ A Ç Ã O
ÊXITO N EC ESSÁ RIA C Ó DIGO DE SA ÍDA RESULTA DO DO REC URSO
Da
PA RÂ M ET RO VA LO R
Nome SMB
NetworkProfile Tudo
Precedência 127
JobObject
NetDirectPort 445
Prioridadevalue 3
Da
PA RÂ M ET RO VA LO R
Nome DEFAULT
NetworkProfile Tudo
Precedência 127
Modelo Padrão
JobObject
Prioridadevalue 0
4. ative o controle de prioridade Flow para o tráfego SMB, o que não é necessário para iWarp.
Enable-NetQosFlowControl -priority 3
Get-NetQosFlowControl
Da
0 Falso Global
1 Falso Global
2 Falso Global
3 True Global
4 Falso Global
P RIO RIDA DE H A B IL ITA DA P O L ÍT IC A DE IF IN DEX IFA L IA S
5 Falso Global
6 Falso Global
7 Falso Global
Impor tante Se os resultados não corresponderem a esses resultados porque itens diferentes de 3
têm um valor habilitado de true, você deve desabilitar FlowControl para essas classes.
Em configurações mais complexas, as outras classes de tráfego podem exigir controle de fluxo, no
entanto, esses cenários estão fora do escopo deste guia.
Name: TEST-40G-1
Enabled: True
Recursos :
PA RÂ M ET RO H A RDWA RE C URREN T
OperationalTrafficClasses :
0 Rigoroso 0-7
OperationalFlowControl :
Prioridade 3 habilitada
OperationalClassifications :
Padrão 0
NetDirect 445 3
6. Habilite a QoS para a segunda NIC, Test-40G-2.
Name: TEST-40G-2
Enabled: True
Recursos :
PA RÂ M ET RO H A RDWA RE C URREN T
OperationalTrafficClasses :
0 Rigoroso 0-7
OperationalFlowControl :
Prioridade 3 habilitada
OperationalClassifications :
Padrão 0
NetDirect 445 3
Da
L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S
Get-NetQosTrafficClass | ft -AutoSize
Da
L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S
TIP
Você pode omitir os valores "IP1" e "IP2".
Da
L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S
Da
L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S
Get-NetQosTrafficClass | ft -AutoSize
Da
L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S
Da
AllowFlowControlUnderDebugger
-----------------------------
1
Get-NetAdapterRdma | ft -AutoSize
Da
Da
A L IA SDEIN T ERFA C E IN T ERFA C EIN DEX IP V4A DDRESS
TEST-40G-1 14 192.168.1.3
TESTE-40G-2 13 {192.168.2.3}
Da
NOTE
Se o tráfego RDMA falhar, para o caso RoCE especificamente, consulte a configuração do comutador ToR para
configurações apropriadas de PFC/ETS que devem corresponder às configurações do host. Consulte a seção QoS
neste documento para obter os valores de referência.
6. Execute o Test-Rdma.ps1 script do PowerShell para passar o valor ifIndex para o script, junto com o
endereço IP do segundo adaptador remoto na mesma VLAN.
Neste exemplo, o script passa o valor ifIndex de 13 no endereço IP do adaptador de rede remoto
192.168.2.5.
C:\TEST\Test-RDMA.PS1 -IfIndex 13 -IsRoCE $true -RemoteIpAddress 192.168.2.5 -PathToDiskspd
C:\TEST\Diskspd-v2.0.17\amd64fre\
Da
Disso
Name: VMSTEST
Id: ad9bb542-dda2-4450-a00e-f96d44bdfbec
NetAdapterInterfaceDescription: {Mellanox ConnectX-3 Pro Ethernet Adapter, Mellanox ConnectX-3 Pro
Ethernet Adapter #2}
TeamingMode: SwitchIndependent
LoadBalancingAlgorithm: Dynamic
Get-NetAdapter
Da
IN T ERFA C EDES
NOME C RIP T IO N IF IN DEX STAT US M A C A DDRESS L IN K SP EED
Get-VMNetworkAdapter -ManagementOS
Da
Test-NetConnection 192.168.1.5
Da
ComputerName : 192.168.1.5
RemoteAddress : 192.168.1.5
InterfaceAlias : vEthernet (CORP-External-Switch)
SourceAddress : 10.199.48.170
PingSucceeded : False
PingReplyDetails (RTT) : 0 ms
2. Defina a ID da VLAN.
Da
Test-NetConnection 192.168.1.5
Da
ComputerName : 192.168.1.5
RemoteAddress : 192.168.1.5
InterfaceAlias : vEthernet (VMSTEST)
SourceAddress : 192.168.1.3
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
Impor tante Se os resultados não forem semelhantes aos resultados de exemplo e o ping falhar com
a mensagem "aviso: ping para 192.168.1.5 falhou--status: DestinationHostUnreachable", confirme se
o "vEthernet (VMSTEST)" tem o endereço IP adequado.
IPAddress : 192.168.1.3
InterfaceIndex: 37
InterfaceAlias: vEthernet (VMSTEST)
AddressFamily : IPv4
Type : Unicast
PrefixLength : 24
PrefixOrigin : Manual
SuffixOrigin : Manual
AddressState : Tentative
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : ActiveStore
Da
Get-NetAdapter
Da
IN T ERFA C EDES
NOME C RIP T IO N IF IN DEX STAT US M A C A DDRESS L IN K SP EED
Da
Nome: IeeePriorityTag de gerenciamento: ativado
2. Crie dois vNICs de host para RDMA e conecte-os ao VMSTEST vSwitch.
Get-VMNetworkAdapter -ManagementOS
Da
Da
IPAddress : 192.168.2.111
InterfaceIndex: 40
InterfaceAlias: vEthernet (SMB1)
AddressFamily : IPv4
Type : Unicast
PrefixLength : 24
PrefixOrigin : Manual
SuffixOrigin : Manual
AddressState : Invalid
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : PersistentStore
Test-NetConnection 192.168.2.5
Da
ComputerName : 192.168.2.5
RemoteAddress : 192.168.2.5
InterfaceAlias : vEthernet (SMB1)
SourceAddress : 192.168.2.111
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
Da
IPAddress : 192.168.2.222
InterfaceIndex: 44
InterfaceAlias: vEthernet (SMB2)
AddressFamily : IPv4
Type : Unicast
PrefixLength : 24
PrefixOrigin : Manual
SuffixOrigin : Manual
AddressState : Invalid
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : PersistentStore
Get-VMNetworkAdapterVlan -ManagementOS
Da
6. Inspecione o mapeamento de SMB1 e SMB2 para as NICs físicas subjacentes na equipe do conjunto de
vSwitch.
A associação do host vNIC a NICs físicas é aleatória e está sujeita a rebalanceamento durante a criação e
a destruição. Nessa circunstância, você pode usar um mecanismo indireto para verificar a associação
atual. Os endereços MAC de SMB1 e SMB2 são associados ao membro da equipe NIC TEST-40G-2. Isso
não é ideal porque Test-40G-1 não tem um host SMB vNIC associado e não permitirá a utilização de
tráfego RDMA pelo link até que um host SMB vNIC seja mapeado para ele.
Get-NetAdapterVPort (Preferred)
Get-NetAdapterVmqQueue
Da
Get-VMNetworkAdapter -ManagementOS
Da
9. Mapeie o SMB1 e o SMB2 para separar membros da equipe NIC física e para exibir os resultados de suas
ações.
IMPORTANT
Verifique se você concluiu esta etapa antes de continuar ou se a sua implementação falha.
Da
NetAdapterName : Test-40G-1
NetAdapterDeviceId : {BAA9A00F-A844-4740-AA93-6BD838F8CFBA}
ParentAdapter : VMInternalNetworkAdapter, Name = 'SMB1'
IsTemplate : False
CimSession : CimSession: .
ComputerName : 27-3145G0803
IsDeleted : False
NetAdapterName : Test-40G-2
NetAdapterDeviceId : {B7AB5BB3-8ACB-444B-8B7E-BC882935EBC8}
ParentAdapter : VMInternalNetworkAdapter, Name = 'SMB2'
IsTemplate : False
CimSession : CimSession: .
ComputerName : 27-3145G0803
IsDeleted : False
Get-NetAdapterVmqQueue
Da
Name QueueID MacAddressVlanID Processor VmFriendlyName
---- ------- ---------------- --------- --------------
TEST-40G-1 1 E4-1D-2D-07-40-71 1010:17
TEST-40G-1 2 00-15-5D-30-AA-00 1020:17
TEST-40G-2 1 00-15-5D-30-AA-01 1020:17
11. Teste a conexão do sistema remoto porque o host vNICs reside na mesma sub-rede e tem a mesma ID de
VLAN ( 102 ) .
Test-NetConnection 192.168.2.111
Da
ComputerName : 192.168.2.111
RemoteAddress : 192.168.2.111
InterfaceAlias : Test-40G-2
SourceAddress : 192.168.2.5
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
Test-NetConnection 192.168.2.222
Da
ComputerName : 192.168.2.222
RemoteAddress : 192.168.2.222
InterfaceAlias : Test-40G-2
SourceAddress : 192.168.2.5
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
Da
Name: SMB1
SwitchName : VMSTEST
IeeePriorityTag : On
Status : {Ok}
Name: SMB2
SwitchName : VMSTEST
IeeePriorityTag : On
Status : {Ok}
Da
Name InterfaceDescription Enabled
---- -------------------- -------
vEthernet (SMB2) Hyper-V Virtual Ethernet Adapter #4 False
vEthernet (SMB1) Hyper-V Virtual Ethernet Adapter #3 False
vEthernet (MGT) Hyper-V Virtual Ethernet Adapter #2 False
Da
TIP
Talvez seja necessário desabilitar o firewall neste sistema. Consulte sua política de malha para obter detalhes.
Da
Get-NetAdapter
Da
Name InterfaceDescriptionifIndex Status MacAddress LinkSpeed
---- --------------------------- ------ ---------- ---------
Test-40G-2Mellanox ConnectX-3 Pro Ethernet A...#3 3 Up E4-1D-2D-07-43-D140 Gbps
Get-NetAdapterRdma
Da
Da
Da
VERBOSE: Diskspd.exe found at C:\TEST\Diskspd-v2.0.17\amd64fre\diskspd.exe
VERBOSE: The adapter Test-40G-2 is a physical adapter
VERBOSE: Underlying adapter is RoCE. Checking if QoS/DCB/PFC is configured on each physical
adapter(s)
VERBOSE: QoS/DCB/PFC configuration is correct.
VERBOSE: RDMA configuration is correct.
VERBOSE: Checking if remote IP address, 192.168.2.222, is reachable.
VERBOSE: Remote IP 192.168.2.222 is reachable.
VERBOSE: Disabling RDMA on adapters that are not part of this test. RDMA will be enabled on them
later.
VERBOSE: Testing RDMA traffic now for. Traffic will be sent in a parallel job. Job details:
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 0 RDMA bytes sent per second
VERBOSE: 485137693 RDMA bytes written per second
VERBOSE: 35200268 RDMA bytes sent per second
VERBOSE: 939044611 RDMA bytes written per second
VERBOSE: 34880901 RDMA bytes sent per second
VERBOSE: Enabling RDMA on adapters that are not part of this test. RDMA was disabled on them prior to
sending RDMA traffic.
VERBOSE: RDMA traffic test SUCCESSFUL: RDMA traffic was sent to 192.168.2.222
Get-NetAdapter | ft –AutoSize
Da
Da
VERBOSE: Diskspd.exe found at C:\TEST\Diskspd-v2.0.17\amd64fre\diskspd.exe
VERBOSE: The adapter vEthernet (SMB1) is a virtual adapter
VERBOSE: Retrieving vSwitch bound to the virtual adapter
VERBOSE: Found vSwitch: VMSTEST
VERBOSE: Found the following physical adapter(s) bound to vSwitch: TEST-40G-1, TEST-40G-2
VERBOSE: Underlying adapter is RoCE. Checking if QoS/DCB/PFC is configured on each physical
adapter(s)
VERBOSE: QoS/DCB/PFC configuration is correct.
VERBOSE: RDMA configuration is correct.
VERBOSE: Checking if remote IP address, 192.168.2.5, is reachable.
VERBOSE: Remote IP 192.168.2.5 is reachable.
VERBOSE: Disabling RDMA on adapters that are not part of this test. RDMA will be enabled on them
later.
VERBOSE: Testing RDMA traffic now for. Traffic will be sent in a parallel job. Job details:
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 0 RDMA bytes sent per second
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 15250197 RDMA bytes sent per second
VERBOSE: 896320913 RDMA bytes written per second
VERBOSE: 33947559 RDMA bytes sent per second
VERBOSE: 912160540 RDMA bytes written per second
VERBOSE: 34091930 RDMA bytes sent per second
VERBOSE: Enabling RDMA on adapters that are not part of this test. RDMA was disabled on them prior to
sending RDMA traffic.
VERBOSE: RDMA traffic test SUCCESSFUL: RDMA traffic was sent to 192.168.2.5
Da
A linha final nesta saída, "teste de tráfego RDMA com êxito: o tráfego RDMA foi enviado para 192.168.2.5",
mostra que você configurou com êxito a NIC convergida no adaptador.
Tópicos relacionados
Configuração de NIC convergida com um único adaptador de rede
Configuração de comutador físico para NIC convergida
Solucionando problemas de configurações de NIC convergida
Configuração do com switch físico para NIC
convergida
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
IMPORTANT
Verifique se a VLAN e a política sem soltar estão definidas para a prioridade sobre a qual o SMB está configurado.
Específico da porta
Tópicos relacionados
Configuração de NIC convergida com um único adaptador de rede
Configuração de NIC em NIC convergida
Solução de problemas de configurações de NIC convergida
Solucionando problemas de configurações de NIC
convergida
13/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar o script a seguir para verificar se a configuração de RDMA está correta no host Hyper-V.
Baixar Test-Rdma.ps1de script
você também pode usar os seguintes comandos de Windows PowerShell para solucionar problemas e verificar
a configuração de suas NICs convergidas.
Get-NetAdapterRdma
para verificar a configuração de RDMA do adaptador de rede, execute o seguinte comando Windows PowerShell
no servidor Hyper-V.
Get-NetAdapterRdma | fl *
Você pode usar os seguintes resultados esperados e inesperados para identificar e resolver problemas depois
de executar esse comando no host do Hyper-V.
Get-NetAdapterRdma resultados esperados
O host vNIC e a NIC física mostram recursos RDMA diferentes de zero.
Get-NetAdapterRdma resultados inesperados
Execute as etapas a seguir se você receber resultados inesperados ao executar o comando Get-
NetAdapterRdma .
1. Verifique se os drivers de barramento Mlnx e miniporta Mlnx são mais recentes. Para o Mellanox, use
pelo menos a remoção de 42.
2. Verifique se a miniporta Mlnx e os drivers de barramento correspondem verificando a versão do driver
por meio de Gerenciador de Dispositivos. O driver de barramento pode ser encontrado em dispositivos
do sistema. o nome deve começar com Mellanox Conexão-X 3 PRO VPI, conforme ilustrado na seguinte
captura de tela das propriedades do adaptador de rede.
3. Verifique se a RDMA (rede direta) está habilitada na NIC física e no host vNIC.
4. Verifique se o vSwitch foi criado no adaptador físico correto verificando seus recursos de RDMA.
5. Verifique o log do sistema do visualizador e filtre por origem "Hyper-V-VmSwitch".
Get-SmbClientNetworkInterface
Get-NetAdapterQos
você pode exibir a qualidade do adaptador de rede da configuração de QoS do serviço ( ) executando o seguinte
comando Windows PowerShell.
Get-NetAdapterQos
Get-SmbMultiChannelConnection
você pode usar o comando Windows PowerShell a seguir para verificar se o endereço IP do nó remoto é -
compatível com RDMA.
Get-SmbMultiChannelConnection
Get-SmbClientNetworkInterface
Contadores Perfmon
Você pode examinar os contadores no monitor de desempenho para verificar a atividade RDMA de sua
configuração.
Tópicos relacionados
Configuração de NIC convergida com um único adaptador de rede
Configuração NIC agrupada NIC convergida
Configuração de comutador físico para NIC convergida
DCB (Data Center Bridging)
13/08/2021 • 6 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para obter informações introdutórios sobre Data Center Bridging ( DCB ) .
O DCB é um conjunto de padrões IEEE do Institute of Electrical and Electronics Engineers que habilitam malhas
convergida no data center, em que armazenamento, rede de dados, IPC de comunicação entre processos de
cluster e tráfego de gerenciamento compartilham a mesma infraestrutura de rede ( ) - ( ) Ethernet.
NOTE
Além deste tópico, a documentação do DCB a seguir está disponível
Instalar o DCB Windows Server 2016 ou Windows 10
Gerenciar Data Center Bridging (DCB)
O DCB fornece alocação de largura de banda baseada em hardware para um tipo específico de tráfego de rede e
aprimora a confiabilidade do transporte Ethernet com o uso do controle de fluxo - - baseado em prioridade.
A alocação de largura de banda baseada em hardware é essencial se o tráfego ignora o sistema operacional e é
descarregado para um adaptador de rede convergido, que pode dar suporte ao iSCSI da Interface do Sistema de
Computador Pequeno da Internet, RDMA de Acesso Remoto Direto à Memória via Ethernet ou - Fiber Channel
sobre Ethernet ( ) ( ) ( FCoE ) .
O controle de fluxo baseado em prioridade será essencial se o protocolo de camada superior, como Fiber
Channel, assumir um transporte subjacente - sem perda.
NOTE
Antes de usar qualquer versão RDMA sobre Ethernet RoCE convergida ( ) do RDMA, você deve habilitar o DCB. Embora
não seja necessário para redes iWARP de Protocolo RDMA de Área Larga da Internet, o teste determinou que todas as
tecnologias RDMA baseadas em Ethernet funcionam melhor ( ) com o - DCB. Por isso, você deve considerar o uso de DCB
para implantações de RDMA iWARP. Para obter mais informações, consulte Remote Direct Memory Access (RDMA) e
Switch Embedded Teaming (SET).
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para aprender a instalar o DCB no Windows Server 2016 ou Windows 10.
NOTE
Depois de executar a primeira etapa neste procedimento, a página antes de começar do assistente para adicionar
funções e recursos não será exibida se você tiver selecionado anteriormente ignorar esta página por padrão quando
o assistente para adicionar funções e recursos for executado. Se a página antes de começar não for exibida, pule da
etapa 1 para a etapa 3.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
este tópico fornece instruções sobre como usar comandos de Windows PowerShell para configurar a ponte do
data Center ( DCB ) em um - adaptador de rede compatível com DCB que está instalado em um computador que
está executando o Windows Server 2016 ou Windows 10.
Configurações do DCB
antes da Windows Server 2016, todas as configurações de DCB foram aplicadas universalmente a todos os
adaptadores de rede que suportavam DCB.
no Windows Server 2016, você pode aplicar configurações de DCB ao repositório de política Global ou ao
repositório de política individual ( s ) . Quando as políticas individuais são aplicadas, elas substituem todas as
configurações de política global.
As configurações de classe de tráfego, PFC e atribuição de prioridade de aplicativo no nível do sistema não são
aplicadas em adaptadores de rede até que você faça o seguinte.
1. Transforme o bit de DCBX disposto em false
2. Habilite o DCB nos adaptadores de rede. consulte habilitar e exibir DCB Configurações em adaptadores
de rede.
NOTE
Se você quiser configurar o DCB de um comutador por meio de DCBX, consulte configurações de DCBX.
O bit DCBX disposto é descrito na especificação DCB. Se o bit disposto em um dispositivo for definido como
true, o dispositivo estará disposto a aceitar configurações de um dispositivo remoto por meio do DCBX. Se o bit
disposto em um dispositivo for definido como false, o dispositivo rejeitará todas as tentativas de configuração
de dispositivos remotos e impedirá apenas as configurações locais.
se DCB não estiver instalado em Windows Server 2016 o valor do bit disposto é irrelevante no que diz respeito
ao sistema operacional, pois o sistema operacional não tem configurações locais aplicáveis a adaptadores de
rede. Após a instalação do DCB, o valor padrão do bit disposto é true. Esse design permite que os adaptadores
de rede mantenham quaisquer configurações que possam ter recebido de seus colegas remotos.
Se um adaptador de rede não oferecer suporte a DCBX, ele nunca receberá configurações de um dispositivo
remoto. Ele recebe configurações do sistema operacional, mas somente depois que o bit DCBX disposto é
definido como false.
NOTE
DCB Windows PowerShell nomes de comando incluem "QoS" em vez de "DCB" na cadeia de caracteres de nome. isso
ocorre porque o QoS e o DCB são integrados no Windows Server 2016 para fornecer uma experiência de gerenciamento
de QoS direta.
Confirm
Are you sure you want to perform this action?
Set-NetQosDcbxSetting -Willing $false
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
Para exibir o estado da configuração de bit dedisposta, você pode usar o seguinte comando:
Get-NetQosDcbxSetting
Get-NetQosTrafficClass
Get-NetQosTrafficClass
Depois de criar uma classe de tráfego, você pode alterar suas configurações de forma independente. As
configurações que podem ser alteradas incluem:
1. Alocação de largura de banda (-BandwidthPercentage)
2. TSA (-Algorithm)
3. Mapeamento de prioridade (-Priority)
Remover uma classe de tráfego
Você pode usar o comando Remove-NetQosTrafficClass para excluir uma classe de tráfego.
IMPORTANT
Não é possível remover a classe de tráfego padrão.
Remove-NetQosTrafficClass -Name SMB
Get-NetQosTrafficClass
Depois de remover uma classe de tráfego, o valor de 802.1 p mapeado para essa classe de tráfego é remapeado
para a classe de tráfego padrão. Qualquer largura de banda reservada para uma classe de tráfego é retornada
para a alocação de classe de tráfego padrão quando a classe de tráfego é removida.
PS C:\> Get-NetQosTrafficClass
O comando anterior cria uma nova política para SMB. – O SMB é um filtro de caixa de entrada que corresponde
à porta TCP 445 (reservada para SMB). Se um pacote for enviado para a porta TCP 445, ele será marcado pelo
sistema operacional com o valor de 4 do 802.1 p antes que o pacote seja passado para um driver de miniporta
de rede.
Além de – SMB, outros filtros padrão incluem – iSCSI (correspondência da porta TCP 3260),-NFS
(correspondência da porta TCP 2049),-LiveMigration (correspondência da porta TCP 6600),-FCOE (Matching
EtherType 0x8906) e – NetworkDirect.
NetworkDirect é uma camada abstrata que criamos sobre qualquer implementação de RDMA em um adaptador
de rede. – NetworkDirect deve ser seguido por uma porta direta da rede.
Além dos filtros padrão, você pode classificar o tráfego pelo nome do executável do aplicativo (como no
primeiro exemplo abaixo) ou por endereço IP, porta ou protocolo (como mostrado no segundo exemplo):
Por nome do executável
Name : background
Owner : Group Policy (Machine)
NetworkProfile : All
Precedence : 127
AppPathName : C:\Program files (x86)\backup.exe
JobObject :
PriorityValue : 1
Name : background
Owner : Group Policy (Machine)
NetworkProfile : All
Precedence : 127
AppPathName : C:\Program files (x86)\backup.exe
JobObject :
PriorityValue : 1
Confirm
Are you sure you want to perform this action?
Remove-NetQosPolicy -Name "Network Management" -Store GPO:localhost
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y
PS C:\> Enable-NetAdapterQos M1
PS C:\> Get-NetAdapterQos
Name : M1
Enabled : True
Capabilities : Hardware Current
-------- -------
MacSecBypass : NotSupported NotSupported
DcbxSupport : None None
NumTCs(Max/ETS/PFC) : 8/8/8 8/8/8
PS C:\> Disable-NetAdapterQos M1
PS C:\> Get-NetAdapterQos M1
Name : M1
Enabled : False
Capabilities : Hardware Current
-------- -------
MacSecBypass : NotSupported NotSupported
DcbxSupport : None None
NumTCs(Max/ETS/PFC) : 8/8/8 0/0/0
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Neste tópico, você aprenderá sobre o VRSS (Virtual Receive Side Scaling) e como configurar um adaptador de
rede virtual para balancear a carga do tráfego de rede de entrada em vários núcleos de processador lógico em
uma VM. Você também pode usar o vRSS para configurar vários núcleos físicos para uma vNIC da placa de
interface de rede virtual ( do ) host.
Essa configuração permite que a carga de um adaptador de rede virtual seja distribuída entre vários
processadores virtuais em uma VM de máquina virtual, permitindo que a VM processe mais tráfego de rede
mais rapidamente do que pode com um único processador ( ) lógico.
TIP
Você pode usar o vRSS em VMs em hosts hyper-V que têm vários processadores, um único processador de vários núcleos
ou mais de um vários processadores principais instalados e configurados para uso - de VM.
O vRSS é compatível com todas as outras - tecnologias de rede do Hyper-V. O vRSS depende Fila de Máquina
Virtual VMQ no host Hyper V e RSS na VM ou na ( ) - vNIC do host.
Por padrão, Windows Server habilita o vRSS, mas você pode desabilitá-lo em uma VM usando Windows
PowerShell. Para obter mais informações, consulte Gerenciar comandos vRSS e Windows PowerShell para RSS e
vRSS.
Requisitos de hardware
A seguir estão os requisitos de hardware para vRSS.
Os adaptadores de rede física devem dar suporte Fila de Máquina Virtual ( VMQ ) . Se a VMQ estiver
desabilitada ou não tiver suporte, o vRSS será desabilitado para o host Hyper V e todas as - VMs
configuradas no host.
Os adaptadores de rede devem ter uma velocidade de link de 10 Gbps ou mais.
Os - hosts hyper-V devem ser configurados com vários processadores ou pelo menos um processador de
vários - núcleos para usar o vRSS.
As ( VMs de máquinas ) virtuais devem ser configuradas para usar dois ou mais processadores lógicos.
Tópicos relacionados
Planejar o uso do vRSS
Habilitar o vRSS em um adaptador de rede virtual
Gerenciar vRSS
Perguntas frequentes sobre vRSS
Windows PowerShell Comandos para RSS e vRSS
Planejar o uso do vRSS
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
No Windows Server 2016, o vRSS está habilitado por padrão, no entanto, você deve preparar seu ambiente
para permitir que o vRSS funcione corretamente em uma VM de máquina virtual ou em um adaptador virtual
host ( ) ( vNIC ) . No Windows Server 2012 R2, o vRSS foi desabilitado por padrão.
Ao planejar e preparar o uso do vRSS, verifique se:
O adaptador de rede física é compatível com Fila de Máquina Virtual VMQ e tem uma velocidade ( ) de link
de 10 Gbps ou mais.
A VMQ está habilitada na NIC física e na porta do Com switch virtual do Hyper - V
Não há nenhuma SR IOV de - virtualização de saída de entrada de raiz ( - única ) configurada para a VM.
O Teaming da NIC está configurado corretamente.
A VM tem vários ( LPs de processadores ) lógicos.
NOTE
O vRSS também é habilitado por padrão para quaisquer vNICs de host que têm o RSS habilitado.
A seguir estão informações adicionais que você precisa para concluir essas etapas de preparação.
1. Capacidade do adaptador de rede. Verifique se o adaptador de rede é compatível com Fila de
Máquina Virtual VMQ e tem uma velocidade ( ) de link de 10 Gbps ou mais. Se a velocidade do link for
menor que 10 Gbps, o Comutadores Virtuais do Hyper-V desabilitará a VMQ por padrão, mesmo que ele
ainda mostre a VMQ como habilitada nos resultados do comando - Windows PowerShell Get-
NetAdapterVmq . Um método que você pode usar para verificar se a VMQ está habilitada ou
desabilitada é usar o comando Get-NetAdapterVmqQueue . Se a VMQ estiver desabilitada, os
resultados desse comando mostrarão que não há QueueID atribuído à VM ou adaptador de rede virtual
do host.
2. Habilitar VMQ . Verifique se a VMQ está ativada no computador host. O vRSS não funcionará se o host
não tiver suporte para VMQ. Você pode verificar se a VMQ está habilitada executando Get-VMSwitch e
encontrando o adaptador que o com switch virtual está usando. Em seguida, execute Get-
NetAdapterVmq e assegure-se de que o adaptador é exibido nos resultados e que possui a VMQ
habilitada.
3. Ausência de SR - IOV . Verifique se um driver VF de VF de Função Virtual de Sr IOV de Virtualização de
Saída de Entrada Única não está anexado ao interface de - rede da ( - ) ( ) VM. Você pode verificar isso
usando o comando Get-NetAdapterSriov. Se um driver VF for carregado, o RSS usará as
configurações de dimensionamento desse driver em vez das configuradas pelo vRSS. Se o driver VF não
for suportado pelo RSS, o vRSS será desabilitado.
4. Configuração de NIC Teaming . Se você estiver usando o NIC Teaming, é importante que você
configure corretamente a VMQ para trabalhar com as configurações de NIC Teaming. Para obter
informações detalhadas sobre a implantação e o gerenciamento do NIC Teaming, consulte NIC Teaming.
5. Número de LPs . Verifique se a VM tem mais de um LP de processador ( ) lógico. O vRSS depende do
RSS na VM ou no host Hyper-V para balancear a carga do tráfego recebido para vários LPs para
processamento paralelo. Você pode observar quantos LPs sua VM tem executando o comando Windows
PowerShell Get-VMProcessor no host. Depois de executar o comando, você pode observar a entrada
da coluna Contagem para o número de LPs.
A vNIC do host sempre tem acesso a todos os processadores físicos; para configurar a vNIC do host para usar
um número específico de processadores, use as configurações -BaseProcessorNumber e -MaxProcessors
ao executar o comando Set-NetAdapterRss Windows PowerShell.
Habilitar o vRSS em um adaptador de rede virtual
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
O ( VRSS virtual RSS ) requer Fila de Máquina Virtual suporte à ( VMQ ) do adaptador físico. Se a VMQ estiver
desabilitada ou não tiver suporte, o dimensionamento virtual do lado do recebimento será desabilitado.
Para obter mais informações, consulte Planejar o uso do vRSS.
NOTE
A primeira etapa neste procedimento é específica para VMs que estão executando Windows 10 ou Windows Server 2016.
Se sua VM estiver executando um sistema operacional diferente, você poderá abrir o Gerenciador de Dispositivos primeiro
abrindo o Painel de Controle, em seguida, localizando e abrindo Gerenciador de Dispositivos.
NOTE
Na guia Avançado, alguns adaptadores de rede também exibem o número de filas RSS com suporte pelo adaptador.
Windows PowerShell
Use o procedimento a seguir para habilitar o vRSS usando Windows PowerShell.
1. Na máquina virtual, abra Windows PowerShell .
2. Digite o comando a seguir, garantindo que você substitua o valor AdapterName para o parâmetro -
Name pelo nome do adaptador de rede que você deseja configurar e pressione ENTER.
TIP
Como alternativa, você pode usar o comando a seguir para habilitar o vRSS.
Para obter mais informações, consulte Windows PowerShell comandos para RSS e vRSS.
Gerenciar vRSS
12/08/2021 • 2 minutes to read
neste tópico, você usa os comandos de Windows PowerShell para gerenciar o vRSS em VMs de máquinas
virtuais ( ) e em - hosts Hyper V.
NOTE
para obter mais informações sobre os comandos mencionados neste tópico, consulte Windows PowerShell comandos
para RSS e vRSS.
Get-NetAdapterVmq
Set-NetAdapterVmq
Get-VMNetworkAdapter <vm-name> | fl
Get-VMNetworkAdapter -ManagementOS | fl
IMPORTANT
Em algumas condições de limitação de recursos, uma - porta de comutador virtual Hyper-V pode não ser capaz de
habilitar esse recurso. Essa é uma condição temporária e o recurso pode estar disponível em um momento subsequente.
Se VrssEnabled for true , o recurso será habilitado para essa porta do - comutador virtual do Hyper-V, ou seja, para essa
VM ou vNIC.
Get-NetAdapterRSS
Set-NetAdapterRss
NOTE
Definir o perfil dentro da VM não afeta o agendamento do trabalho. O Hyper - V faz todas as decisões de agendamento e
ignora o perfil dentro da VM.
Desabilitar vRSS
Você pode desabilitar o vRSS para desabilitar qualquer uma das configurações mencionadas anteriormente.
Desabilite a VMQ para a NIC física ou para a VM.
Cau t i on
Desabilitar a VMQ na NIC física afeta seriamente a capacidade de seu host Hyper- - V de lidar com os
pacotes de entrada.
Desabilite o vRSS para uma VM na - porta do comutador virtual Hyper-v no host Hyper- - v.
Desabilite o vRSS para um host vNIC na - porta do comutador virtual Hyper-v no host Hyper- - v.
Disable-NetAdapterRSS *
Windows PowerShell Comandos para RSS e vRSS
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
neste tópico, você aprenderá a localizar rapidamente informações de referência técnica sobre Windows
PowerShell comandos para receber o rss de escala lateral e o rss ( ) virtual ( vRSS ) .
Use os comandos RSS a seguir para configurar o RSS em um computador físico com vários processadores ou
vários núcleos. Você pode usar os mesmos comandos para configurar o vRSS em uma VM de máquina virtual (
) que esteja executando um sistema operacional com suporte. Para obter mais informações, consulte cmdlets do
adaptador de rede em Windows PowerShell.
Configurar a VMQ
o vRSS requer que a VMQ esteja habilitada e configurada. você pode usar os seguintes comandos de Windows
PowerShell para gerenciar as configurações de VMQ.
Desabilitar-NetAdapterVmq
Habilitar-NetAdapterVmq
Get-NetAdapterVmq
Set-NetAdapterVmq
IMPORTANT
Habilitar o RSS em uma VM ou em um host vNIC é um pré-requisito para habilitar e usar o vRSS.
Desabilitar-NetAdapterRss
Habilitar-NetAdapterRss
Get-NetAdapterRss
Set-NetAdapterRss
Get-VMNetworkAdapter <vm-name> | fl
Habilitado o recurso:
Set-VMNetworkAdapter <vm-name> -VrssEnabled [$True|$False]
Get-VMNetworkAdapter -ManagementOS | fl
no Windows Server 2019, o vRSS pode atualizar os processadores lógicos usados para processar o tráfego de
rede dinamicamente. Os dispositivos com drivers com suporte têm esse modo de agendamento habilitado por
padrão.
Determine o modo de agendamento atual em um sistema ou modifique o modo de agendamento de uma VM.
Exibir as configurações atuais:
para determinar o modo de agendamento atual ou para modificar o modo de agendamento de um host vNIC,
use os seguintes comandos de Windows PowerShell:
Exibir as configurações atuais:
Se você tiver concluído todas as etapas de preparação e ainda não vir o tráfego de balanceamento de carga
vRSS para a VM LPs, haverá possíveis problemas diferentes.
1. Antes de executar as etapas de preparação, o vRSS foi desabilitado-e agora deve ser habilitado. Você
pode executar set-VMNetworkAdapter para habilitar o vRSS para a VM.
2. O RSS foi desabilitado na VM ou no host vNIC. o Windows Server 2016 habilita RSS por padrão; Alguém
pode tê-lo desabilitado.
Habilitado = verdadeiro
Exibir as configurações atuais:
Execute o seguinte cmdlet do PowerShell na VM ( para vrss em uma VM ) ou no host ( para o vrss vNIC
do host ) .
Get-NetAdapterRss
Habilite o recurso:
Para alterar o valor de false para true, execute o seguinte cmdlet do PowerShell.
Enable-NetAdapterRss *
para garantir que o RSS não seja desabilitado globalmente. E habilitá-lo se necessário. Essa configuração
não é coberta por *-NetAdapterRSS.
3. Se você achar que o VMMQ não está habilitado depois de configurar o vRSS, verifique as seguintes
configurações em cada adaptador anexado ao comutador virtual:
VmmqEnabled = false
VmmqEnabledRequested = true
Exibir as configurações atuais:
Habilite o recurso:
4. (Windows Server 2019) Não é possível habilitar VMMQ (VmmqEnabled = false) ao definir
VrssQueueSchedulingMode como dinâmico . O VrssQueueSchedulingMode não é alterado para
dinâmico quando VMMQ está habilitado.
O VrssQueueSchedulingMode de dinâmico requer suporte de driver quando o VMMQ está
habilitado. VMMQ é um descarregamento do posicionamento de pacotes em processadores lógicos e,
como tal, requer suporte de driver para aproveitar o algoritmo dinâmico. Instale o driver e o firmware do
fornecedor da NIC que dá suporte a VMMQ dinâmicos.
API de serviço HCN (rede de computação de host)
para VMs e contêineres
13/08/2021 • 6 minutes to read
A API de serviço HCN (rede de computação de host) é uma API Win32 voltada para o público que fornece
acesso em nível de plataforma para gerenciar redes virtuais, pontos de extremidade de rede virtual e políticas
associadas. juntos, isso fornece conectividade e segurança para VMs (máquinas virtuais) e contêineres em
execução em um host Windows.
Os desenvolvedores usam a API de serviço HCN para gerenciar a rede para VMs e contêineres em seus fluxos
de trabalho de aplicativo. A API HCN foi projetada para fornecer a melhor experiência para os desenvolvedores.
Os usuários finais não interagem diretamente com essas APIs.
TIP
A API do serviço HCN tem suporte em tarefas em segundo plano e em janelas que não são de primeiro plano.
TIP
As anotações [NewIn ("2.0") fazem parte do suporte de controle de versão para as definições de esquema. A partir desta
definição interna, geramos as especificações de OpenAPI para o 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",
"type": "object",
"properties": {
"NextHop": {
"type": "string"
},
"DestinationPrefix": {
"type": "string"
},
"Metric": {
"type": "integer",
"format": "uint16"
}
}
}
}
}
Você pode usar ferramentas, como o Swagger, para gerar representações específicas de idioma da linguagem
de programação de esquema usada por um cliente. O Swagger dá suporte a uma variedade de linguagens,
como C#, go, JavaScript e Python.
exemplo de código C# gerado para o nível superior IPAM & objeto de sub-rede.
exemplo de código Go gerado para o nível superior IPAM & objeto de sub-rede. Go é usado pelo Docker
e kubernetes, que são dois dos consumidores das APIs de serviço de rede de computação do host. O Go
tem suporte interno para empacotamento de tipos Go de e para documentos JSON.
além da geração de código e da validação, você pode usar ferramentas para simplificar o trabalho com
documentos JSON, ou seja, Visual Studio Code.
Objetos de nível superior definidos no HCN. Arquivo schemas. Mars
Conforme mencionado acima, você pode encontrar o esquema do documento para documentos usados pelas
APIs HCN em um conjunto de arquivos. Mars em: onecore/VM/DV/net/HNS/Schema/Mars/esquema
Os objetos de nível superior são:
HostComputeNetwork
HostComputeEndpoint
HostComputeNamespace
HostComputeLoadBalancer
class HostComputeNetwork : HCN.Schema.Common.Base
{
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.NetworkMode Type;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.NetworkPolicy Policies[];
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.MacPool MacPool;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.DNS Dns;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.Ipam Ipams[];
};
class HostComputeEndpoint : HCN.Schema.Common.Base
{
[NewIn("2.0"),OmitEmpty] string HostComputeNetwork;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.Endpoint.EndpointPolicy Policies[];
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.Endpoint.IpConfig IpConfigurations[];
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.DNS Dns;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.Route Routes[];
[NewIn("2.0"),OmitEmpty] string MacAddress;
};
class HostComputeNamespace : HCN.Schema.Common.Base
{
[NewIn("2.0"),OmitEmpty] uint32 NamespaceId;
[NewIn("2.0"),OmitEmpty] Guid NamespaceGuid;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Namespace.NamespaceType Type;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Namespace.NamespaceResource Resources[];
};
class HostComputeLoadBalancer : HCN.Schema.Common.Base
{
[NewIn("2.0"), OmitEmpty] string HostComputeEndpoints[];
[NewIn("2.0"), OmitEmpty] string VirtualIPs[];
[NewIn("2.0"), OmitEmpty] HCN.Schema.Network.Endpoint.Policy.PortMappingPolicy PortMappings[];
[NewIn("2.0"), OmitEmpty] HCN.Schema.LoadBalancer.LoadBalancerPolicy Policies[];
};
Próximas etapas
Saiba mais sobre os cenários comuns de HCN.
Saiba mais sobre os identificadores de contexto RPC para HCN.
Saiba mais sobre os esquemas de documento JSON HCN.
Cenários comuns
11/08/2021 • 10 minutes to read
Cenário: HCN
Criar um HCN
Este exemplo mostra como usar a API do Serviço de Rede de Computação de Host para criar uma Rede de
Computação de Host no host que pode ser usada para conectar NICS Virtuais a Máquinas Virtuais ou
Contêineres.
Excluir um HCN
Este exemplo mostra como usar a API do Serviço de Rede de Computação do Host para Abrir & Excluir uma
Rede de Computação de Host
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);
}
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(hcnnetwork.get(), query.c_str(), &properties, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
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(hcnendpoint.get(), ModifySettingAddPortJson.c_str(), &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
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);
}
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);
}
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);
}
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,
"ResourceType" : 0,
"Settings" : {
"EndpointId" : "87fdcf16-d210-426e-959d-2a1d4f41d6d1"
}
}
)";
hr = HcnModifyLoadBalancer(handle.get(), ModifySettingAddEndpointJson.c_str(), &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
hr = HcnCloseLoadBalancer(handle.get());
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
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);
}
Consultar propriedades do balanceador de carga
Este exemplo mostra como usar a API de Serviço de Rede de Computação do Host para consultar as
propriedades do LoadBalancer de Rede de Computação do Host.
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(handle.get(), query.c_str(), &properties, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
Próximas etapas
Saiba mais sobre os alças de contexto RPC para HCN.
Saiba mais sobre os esquemas de documento JSON do HCN.
Identificadores de contexto de RPC para HCN
11/08/2021 • 12 minutes to read
HCN_Network
Uma rede HCN é uma entidade que é usada para representar uma rede de computação de host e seus recursos
e políticas de sistema associados. Por exemplo, uma rede HCN normalmente consistirá em um conjunto de
metadados (por exemplo, ID, nome, tipo), um comutador virtual, um adaptador de rede virtual do host (que atua
como um gateway padrão para a rede), uma instância de NAT (se exigido pelo tipo de rede), um conjunto de
pools de sub-rede e de MAC e qualquer política de toda a rede a ser aplicada (
As entidades de rede HCN são representadas usando HCN_NETWORK identificadores de contexto RPC.
HCN_Endpoint
Um ponto de extremidade HCN é uma entidade que é usada para representar um ponto de extremidade de IP
em uma rede HCN e seus recursos e políticas de sistema associados. Por exemplo, um ponto de extremidade
HCN geralmente consiste em um conjunto de metadados (por exemplo, ID, nome, ID de rede pai), sua
identidade de rede (por exemplo, endereço IP, endereço MAC) e quaisquer políticas específicas de ponto de
extremidade a serem aplicadas (por exemplo, ACLs, rotas). As entidades de ponto de extremidade HCN são
representadas usando HCN_ENDPOINT identificadores de contexto RPC.
HCN_Namespace
Um namespace HCN é uma entidade que é usada para representar um namespace de rede de computação do
host. Os namespaces permitem que você tenha ambientes de rede isolados em um único host, em que cada
namespace tem suas próprias interfaces de rede e tabela de roteamento, separados de outros namespaces.
As entidades de namespace HCN são representadas usando HCN_NAMESPACE identificadores de contexto RPC.
HCN_LoadBalancer
Um HCN Balancer é uma entidade que é usada para representar uma rede de computação do host balanceador
de carga. Os Load balancers permitem que você tenha pontos de extremidade de rede de computação de host
com balanceamento de carga. As entidades do balanceador HCN são representadas usando
HCN_LOADBALANCER identificadores de contexto RPC.
/// 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 documento JSON de HCN
07/08/2021 • 2 minutes to read
Esquema HCN
// 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>
} ],
},
}
/*
* HCN API
*
* No description provided (generated by Swagger Codegen https://github.com/swagger-api/swagger-codegen)
*
* OpenAPI spec version: 2.1
*
* Generated by: https://github.com/swagger-api/swagger-codegen.git
*/
using System;
using System.Linq;
using System.IO;
using System.Text;
using System.Text.RegularExpressions;
using System.Collections;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Runtime.Serialization;
using Newtonsoft.Json;
using Newtonsoft.Json.Converters;
using System.ComponentModel.DataAnnotations;
using SwaggerDateConverter = IO.Swagger.Client.SwaggerDateConverter;
namespace IO.Swagger.Model
{
/// <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>
/// </summary>
/// <param name="Type"> Type : dhcp.</param>
/// <param name="Subnets">Subnets.</param>
public Ipam(TypeEnum? Type = default(TypeEnum?), List<Subnet> Subnets = default(List<Subnet>))
{
this.Type = Type;
this.Subnets = 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();
sb.Append("class Ipam {\n");
sb.Append(" Type: ").Append(Type).Append("\n");
sb.Append(" Subnets: ").Append(Subnets).Append("\n");
sb.Append("}\n");
return sb.ToString();
}
/// <summary>
/// Returns the JSON string presentation of the object
/// </summary>
/// <returns>JSON string presentation of the object</returns>
public string ToJson()
{
return JsonConvert.SerializeObject(this, Formatting.Indented);
}
/// <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 this.Equals(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
(
this.Type == input.Type ||
(this.Type != null &&
this.Type.Equals(input.Type))
) &&
(
this.Subnets == input.Subnets ||
this.Subnets != null &&
this.Subnets.SequenceEqual(input.Subnets)
);
}
/// <summary>
/// Gets the hash code
/// </summary>
/// <returns>Hash code</returns>
public override int GetHashCode()
{
unchecked // Overflow is fine, just wrap
{
int hashCode = 41;
if (this.Type != null)
hashCode = hashCode * 59 + this.Type.GetHashCode();
if (this.Subnets != null)
hashCode = hashCode * 59 + this.Subnets.GetHashCode();
return hashCode;
}
}
/// <summary>
/// To validate all properties of the instance
/// </summary>
/// <param name="validationContext">Validation context</param>
/// <returns>Validation Result</returns>
IEnumerable<System.ComponentModel.DataAnnotations.ValidationResult>
IValidatableObject.Validate(ValidationContext validationContext)
{
yield break;
}
}
}
/*
* HCN API
*
* No description provided (generated by Swagger Codegen https://github.com/swagger-api/swagger-codegen)
*
* OpenAPI spec version: 2.1
*
* Generated by: https://github.com/swagger-api/swagger-codegen.git
*/
using System;
using System.Linq;
using System.IO;
using System.Text;
using System.Text.RegularExpressions;
using System.Collections;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Runtime.Serialization;
using Newtonsoft.Json;
using Newtonsoft.Json.Converters;
using System.ComponentModel.DataAnnotations;
using SwaggerDateConverter = IO.Swagger.Client.SwaggerDateConverter;
namespace IO.Swagger.Model
{
/// <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>))
{
this.ID = ID;
this.IpAddressPrefix = IpAddressPrefix;
this.Policies = Policies;
this.Routes = 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();
sb.Append("class Subnet {\n");
sb.Append(" ID: ").Append(ID).Append("\n");
sb.Append(" IpAddressPrefix: ").Append(IpAddressPrefix).Append("\n");
sb.Append(" Policies: ").Append(Policies).Append("\n");
sb.Append(" Routes: ").Append(Routes).Append("\n");
sb.Append("}\n");
return sb.ToString();
}
/// <summary>
/// Returns the JSON string presentation of the object
/// </summary>
/// <returns>JSON string presentation of the object</returns>
public string ToJson()
{
return JsonConvert.SerializeObject(this, Formatting.Indented);
}
/// <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 this.Equals(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
(
this.ID == input.ID ||
(this.ID != null &&
this.ID.Equals(input.ID))
) &&
(
this.IpAddressPrefix == input.IpAddressPrefix ||
(this.IpAddressPrefix != null &&
(this.IpAddressPrefix != null &&
this.IpAddressPrefix.Equals(input.IpAddressPrefix))
) &&
(
this.Policies == input.Policies ||
this.Policies != null &&
this.Policies.SequenceEqual(input.Policies)
) &&
(
this.Routes == input.Routes ||
this.Routes != null &&
this.Routes.SequenceEqual(input.Routes)
);
}
/// <summary>
/// Gets the hash code
/// </summary>
/// <returns>Hash code</returns>
public override int GetHashCode()
{
unchecked // Overflow is fine, just wrap
{
int hashCode = 41;
if (this.ID != null)
hashCode = hashCode * 59 + this.ID.GetHashCode();
if (this.IpAddressPrefix != null)
hashCode = hashCode * 59 + this.IpAddressPrefix.GetHashCode();
if (this.Policies != null)
hashCode = hashCode * 59 + this.Policies.GetHashCode();
if (this.Routes != null)
hashCode = hashCode * 59 + this.Routes.GetHashCode();
return hashCode;
}
}
/// <summary>
/// To validate all properties of the instance
/// </summary>
/// <param name="validationContext">Validation context</param>
/// <returns>Validation Result</returns>
IEnumerable<System.ComponentModel.DataAnnotations.ValidationResult>
IValidatableObject.Validate(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}$",
RegexOptions.CultureInvariant);
if (false == regexID.Match(this.ID).Success)
{
yield return new System.ComponentModel.DataAnnotations.ValidationResult("Invalid value for
ID, must match a pattern of " + regexID, new [] { "ID" });
}
yield break;
}
}
}
Exemplo de código gerado por Go
12/08/2021 • 2 minutes to read
/*
* HCN API
*
* No description provided (generated by Swagger Codegen https://github.com/swagger-api/swagger-codegen)
*
* API version: 2.1
* Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
*/
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 https://github.com/swagger-api/swagger-codegen)
*
* API version: 2.1
* Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
*/
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"`
}
Comutador Virtual Hyper-V
13/08/2021 • 5 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este tópico fornece uma visão geral do Comutadores Virtuais do Hyper-V, que fornece a capacidade de conectar
VMs de máquinas virtuais a redes externas ao ( ) host hyper-V, incluindo a intranet da sua organização e a -
Internet.
Você também pode se conectar a redes virtuais no servidor que está executando o Hyper V ao implantar o -
SDN de Rede Definida pelo Software ( ) .
NOTE
Além deste tópico, a documentação do Com switch virtual do Hyper-V a seguir está disponível.
Gerenciar o comutador virtual do Hyper-V
Acesso Remoto Direto à Memória (RDMA) e Agrupamento incorporado de comutador (SET)
Cmdlets de equipe do comutador de rede no Windows PowerShell
Novidades no VMM 2016
Configurar a malha de rede do VMM
Fórum do Hyper-V
Hyper-V: a extensão do comutador virtual WFP deve ser habilitada se for exigida pelas extensões de terceiros
Para obter mais informações sobre outras tecnologias de rede, consulte Rede no Windows Server 2016.
O Com switch virtual hyper-V é um comando de rede Ethernet de camada 2 baseado em software que está
disponível no Gerenciador do Hyper V quando você instala a função de - - servidor - Hyper-V.
O Comutr Virtual hyper-V inclui funcionalidades gerenciadas e extensíveis de forma programática para conectar
VMs a redes virtuais e à rede física. Além disso, o Comutador Virtual Hyper-V fornece imposição de política para
níveis de segurança, de isolamento e de serviço.
NOTE
O Comutador Virtual Hyper-V dá suporte apenas a Ethernet e não dá suporte a quaisquer outras tecnologias de LAN
(rede local) com fio, como Infiniband e Fibre Channel.
O Com switch virtual do Hyper-V inclui recursos de isolamento de locatário, formatação de tráfego, proteção
contra máquinas virtuais mal-intencionadas e solução de problemas simplificada.
Com suporte interno para drivers de filtro NDIS da Especificação de Interface de Dispositivo de Rede e drivers
de saída WFP da Plataforma de Filtragem do Windows, o Comutamento Virtual hyper-V permite que isVs
independentes de fornecedores de software criem ( ) ( ) ( ) plug-ins extensíveis, chamados extensões de
comutadores virtuais, que podem fornecer recursos avançados de rede e segurança. As Extensões de
Comutador Virtual que podem ser adicionadas ao Comutador Virtual Hyper-V são listadas no recurso
Gerenciador de Comutador Virtual do Gerenciador Hyper-V.
Na ilustração a seguir, uma VM tem uma NIC virtual que está conectada ao Com switch virtual do Hyper-V por
meio de uma porta switch.
Os recursos do Com switch virtual do Hyper-V fornecem mais opções para impor isolamento de locatário,
modelar e controlar o tráfego de rede e empregar medidas de proteção contra VMs mal-intencionadas.
NOTE
No Windows Server 2016, uma VM com uma NIC virtual exibe com precisão a produtividade máxima para a NIC virtual.
Para exibir a velocidade de NIC virtual em Conexões de Rede , clique com o botão direito do mouse no ícone de NIC
virtual desejado e clique em Status . A caixa de diálogo Status da NIC virtual é aberta. Em Conexão , o valor de
Velocidade corresponde à velocidade da NIC física instalada no servidor.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
NOTE
Além deste tópico, o conteúdo IPAM conteúdo está disponível.
Novidades no IPAM
Gerenciar IPAM
Gerenciamento de Endereço IP (IPAM) cmdlets de servidor no Windows PowerShell
Vídeo: Windows Server 2016: gerenciamento de DNS no IPAM
Novidades no IPAM
13/08/2021 • 6 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este tópico descreve a funcionalidade Gerenciamento de Endereço IP (IPAM) que é nova ou alterada no
Windows Server 2016.
IPAM fornece recursos administrativos e de monitoramento altamente personalizáveis para o endereço IP e a
infraestrutura DNS em uma rede CSP (provedor de serviços de nuvem) ou Enterprise nuvem. Você pode
monitorar, auditar e gerenciar servidores que executam o protocolo DHCP e o DNS (Sistema de Nomes de
Domínio) usando IPAM.
Suporte a várias florestas do Active Novo Você pode usar IPAM para gerenciar
Directory os servidores DNS e DHCP de várias
florestas do Active Directory quando
houver uma relação de confiança de
duas vias entre a floresta em que o
IPAM está instalado e cada uma das
florestas remotas.
REC URSO / F UN C IO N A L IDA DE N O VO O U M EL H O RA DO DESC RIÇ Ã O
Windows PowerShell suporte para Novo Você pode usar Windows PowerShell
controle de acesso baseado em função para definir escopos de acesso em
IPAM objetos.
NOTE
Para a IPAM Windows PowerShell de comando, consulte cmdlets Gerenciamento de Endereço IP (IPAM) server no
Windows PowerShell.
NOTE
Na verdade, essa função não aloca as sub-redes, apenas relata sua disponibilidade. No entanto, a saída do cmdlet pode
ser canal para o comando Add-IpamSubnet para criar a sub-rede.
NOTE
Na verdade, essa função não aloca os intervalos, apenas relata sua disponibilidade. No entanto, a saída do cmdlet pode
ser canal para o comando Add-IpamRange para criar o intervalo.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este guia fornece informações de administração e solução de problemas para o recurso Gerenciamento de
Endereço IP (IPAM) no Windows Server 2016.
No Windows Server 2016, o IPAM dá suporte ao registro de recursos DNS, ao encaminhador condicional e ao
gerenciamento de zona DNS para servidores DNS integrados ao Active Directory ingressados no domínio e
com suporte a arquivos. Além disso, o IPAM dá suporte ao controle de acesso baseado em função e a todas as
funcionalidades em versões anteriores da tecnologia.
Este guia inclui as seguintes seções:
Gerenciamento de registros de recursos DNS
Gerenciamento de zona DNS
Gerenciar recursos em várias florestas do Active Directory
Limpar dados de utilização
Controle de acesso baseado em função
Consulte Também
Gerenciamento de Endereço IP (IPAM)
Gerenciamento de registro de recursos de DNS
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este tópico fornece informações sobre como gerenciar registros de recursos DNS usando IPAM.
NOTE
Além deste tópico, os tópicos de gerenciamento de registro de recursos DNS a seguir estão disponíveis nesta seção.
Adicionar um registro de recurso DNS
Excluir registros de recursos DNS
Filtrar a exibição de registros de recursos DNS
Exibir registros de recursos DNS para um endereço IP específico
Os dados DNS coletados incluem informações de zona DNS e registro de recurso. Você pode configurar o IPAM
para coletar informações de zona de seu servidor DNS preferencial. IPAM coleta as zonas do Active Directory e
baseadas em arquivo.
NOTE
IPAM coleta dados exclusivamente de servidores DNS da Microsoft ingressados no domínio. Não há suporte para
servidores DNS de terceiros e servidores não ingressados no domínio IPAM.
Veja a seguir uma lista de tipos de registro de recurso DNS coletados por IPAM.
Banco de dados AFS
Endereço do ATM
CNAME
DHCID
Dname
Hospedar A ou AAAA
Informações do host
Isdn
MX
Servidores de Nome
Ponteiro (PTR)
Pessoa responsável
Roteá-lo
Local do Serviço
SOA
SRV
Texto
Serviços conhecidos
WINS
WINS-R
X.25
No Windows Server 2016, o IPAM fornece integração entre o inventário de endereços IP, zonas DNS e registros
de recursos DNS:
Você pode usar o IPAM para criar automaticamente um inventário de endereços IP de registros de
recursos DNS.
Você pode criar manualmente um inventário de endereços IP de registros de recursos dns A e AAAA.
Você pode exibir registros de recursos DNS para uma zona DNS específica e filtrar os registros com base
no tipo, endereço IP, dados de registro de recurso e outras opções de filtragem.
IPAM cria automaticamente um mapeamento entre intervalos de endereços IP e Zonas de Look up
Inversa do DNS.
IPAM cria endereços IP para os registros PTR que estão presentes na zona de busca inversa e que estão
incluídos nesse intervalo de endereços IP. Você também pode modificar manualmente esse mapeamento,
se necessário.
IPAM permite executar as seguintes operações em registros de recursos do console IPAM.
Criar registros de recursos DNS
Editar registros de recursos DNS
Excluir registros de recurso DNS
Criar registros de recursos associados
IPAM registra automaticamente todas as alterações de configuração de DNS feitas usando o console IPAM dns.
Consulte Também
Gerenciar IPAM
Adicionar um registro de recursos de DNS
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para adicionar um ou mais novos registros de recursos DNS usando o console IPAM
cliente.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para adicionar um registro de recurso DNS
1. No Gerenciador do Servidor, clique em IPAM . O IPAM do cliente é exibido.
2. No painel de navegação, em MONITORAR E GERENCIAR , clique em Zonas DNS . O painel de
navegação se divide em um painel de navegação superior e em um painel de navegação inferior.
3. No painel de navegação inferior, clique em For ward Lookup . Todas as IPAM de pesquisa de
encaminhamento de DNS gerenciadas pelo DNS são exibidas nos resultados da pesquisa do painel de
exibição. Clique com o botão direito do mouse na zona em que você deseja adicionar um registro de
recurso e clique em Adicionar registro de recurso DNS .
6. A lista de tipos de registro de recurso é exibida. Clique no tipo de registro de recurso que você deseja
adicionar.
7. Em Novo Registro de Recurso, em Nome , digite um nome de registro de recurso. Em Endereço IP ,
digite um endereço IP e selecione as propriedades de registro de recurso apropriadas para sua
implantação. Clique em Adicionar Registro de Recurso .
8. Se você não quiser criar registros de recursos adicionais, clique em OK. Se você quiser criar registros de
recursos adicionais, clique em Novo .
9. A caixa de diálogo expande para revelar Novo Registro de Recurso. Clique em Tipo de registro de
recurso . A lista de tipos de registro de recurso é exibida. Clique no tipo de registro de recurso que você
deseja adicionar.
10. Em Novo Registro de Recurso, em Nome , digite um nome de registro de recurso. Em Endereço IP ,
digite um endereço IP e selecione as propriedades de registro de recurso apropriadas para sua
implantação. Clique em Adicionar Registro de Recurso .
11. Se você quiser adicionar mais registros de recursos, repita o processo para criar registros. Quando
terminar de criar novos registros de recurso, clique em Aplicar .
12. A caixa de diálogo Adicionar Registro de Recurso exibe um resumo de registros de recursos enquanto
IPAM os registros de recurso no servidor DNS especificado. Quando os registros são criados com êxito, o
Status do registro é Êxito.
13. Clique em OK .
Consulte Também
Gerenciamento de registros de recursos DNS Gerenciar IPAM
Excluir registros de recursos de DNS
11/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para excluir um ou mais registros de recursos DNS usando o console do cliente do
IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para excluir registros de recursos de DNS
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, em monitorar e gerenciar , clique em zonas DNS . O painel de navegação
divide-se em um painel de navegação superior e em um painel de navegação inferior.
3. Clique para expandir a pesquisa direta e o domínio no qual os registros de zona e de recursos que você
deseja excluir estão localizados. Clique na zona e, no painel de exibição, clique em exibição atual . Clique
em registros de recursos .
4. No painel de exibição, localize e selecione os registros de recursos que você deseja excluir.
5. Clique com o botão direito do mouse nos registros selecionados e clique em Excluir registro de
recurso DNS .
6. A caixa de diálogo Excluir registro de recurso DNS é aberta. Verifique se o servidor DNS correto está
selecionado. Se não estiver, clique em ser vidor DNS e selecione o servidor do qual você deseja excluir
os registros de recursos. Clique em OK . IPAM exclui os registros de recursos do servidor DNS.
Consulte Também
Gerenciamento de registros de recursos de DNS Gerenciar IPAM
Filtrar a exibição de registros de recursos de DNS
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para filtrar a exibição de registros de recursos DNS no console IPAM cliente.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para filtrar a exibição de registros de recursos DNS
1. No Gerenciador do Servidor, clique em IPAM . O IPAM do cliente é exibido.
2. No painel de navegação, em MONITORAR E GERENCIAR , clique em Zonas DNS . O painel de
navegação se divide em um painel de navegação superior e em um painel de navegação inferior.
3. No painel de navegação inferior, clique em For ward Lookup . Todas as IPAM de pesquisa de
encaminhamento de DNS gerenciadas pelo DNS são exibidas nos resultados da pesquisa do painel de
exibição.
4. Clique na zona cujos registros você deseja exibir e filtrar.
5. No painel de exibição, clique em Exibição atual e, em seguida, clique em Registros de Recursos . Os
registros de recurso para a zona são mostrados no painel de exibição.
6. No painel de exibição, clique em Adicionar critérios.
7. Selecione um critério na lista lista listada. Por exemplo, se você quiser exibir um tipo de registro
específico, clique em Tipo de Registro .
8. Clique em Adicionar .
9. O Tipo de Registro é adicionado como um parâmetro de pesquisa. Insira texto para o tipo de registro
que você deseja encontrar. Por exemplo, se você quiser exibir apenas registros SRV, digite SRV .
10. Pressione ENTER. Os registros de recursos DNS são filtrados de acordo com os critérios e a frase de
pesquisa que você especificou.
Consulte Também
Gerenciamento de registros de recursos DNS Gerenciar IPAM
Exibir registros de recurso de DNS para um
endereço IP específico
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para exibir os registros de recursos de DNS que estão associados ao endereço IP que
você escolher.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para exibir registros de recursos para um endereço IP
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, em espaço de endereço IP , clique em inventário de endereço IP . No painel
de navegação inferior, clique em IPv4 ou IPv6 . O inventário de endereço IP aparece na exibição de
pesquisa do painel de exibição. Localize e selecione o endereço IP cujos registros de recursos DNS você
deseja exibir.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
este tópico fornece informações sobre como gerenciar zonas DNS usando o console do cliente do IPAM.
NOTE
além deste tópico, os tópicos de IPAM de gerenciamento de zona DNS a seguir estão disponíveis nesta seção.
Criar uma zona DNS
Editar uma zona DNS
Exibir registros de recurso DNS para uma zona DNS
Exibir Zonas DNS
ao implantar IPAM no Windows Server 2016, você pode usar IPAM para gerenciar as zonas DNS.
no console do IPAM, você pode exibir os registros de recurso dns para uma zona DNS específica e filtrar os
registros com base no tipo, endereço IP, dados de registro de recurso e outras opções de filtragem. Além disso,
você pode editar os registros de recursos de DNS para zonas específicas
Consulte Também
Gerenciar IPAM
Criar uma zona DNS
11/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para criar uma zona DNS usando o console do cliente do IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para criar uma zona DNS
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, em monitorar e gerenciar , clique em ser vidores DNS e DHCP . No painel
de exibição, clique em tipo de ser vidor e, em seguida, clique em DNS . todos os servidores DNS
gerenciados pelo IPAM são listados nos resultados da pesquisa.
3. Localize o servidor no qual você deseja adicionar uma zona e clique com o botão direito do mouse no
servidor. Clique em criar zona DNS .
4. A caixa de diálogo criar zona DNS é aberta. Em Propriedades gerais , selecione uma categoria de
zona, um tipo de zona e insira um nome em nome da zona . Selecione também os valores apropriados
para sua implantação em Propriedades avançadas e clique em OK .
Consulte Também
Gerenciamento de zona DNS Gerenciar IPAM
Editar uma zona DNS
07/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para editar uma zona DNS no console do cliente do IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para editar uma zona DNS
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, em monitorar e gerenciar , clique em zonas DNS . O painel de navegação
divide-se em um painel de navegação superior e em um painel de navegação inferior.
3. No painel de navegação inferior, faça uma das seguintes seleções:
Pesquisa direta
Pesquisa inversa de IPv4
Pesquisa inversa de IPv6
4. Por exemplo, selecione pesquisa inversa de IPv4.
5. No painel de exibição, clique com o botão direito do mouse na zona que você deseja editar e clique em
Editar zona DNS .
6. A caixa de diálogo Editar zona DNS é aberta com a página geral selecionada. Se necessário, edite as
propriedades de zona geral: ser vidor DNS , categoria de zona e tipo de zona e, em seguida, clique
em aplicar ou, se as edições estiverem concluídas, OK .
7. Na caixa de diálogo Editar zona DNS , clique em avançado . A página Propriedades avançadas de
zona é aberta. Se necessário, edite as propriedades que você deseja alterar e, em seguida, clique em
aplicar ou, se suas edições estiverem concluídas, OK .
8. Se necessário, selecione os nomes de página de propriedades de zona adicionais (servidores de nomes,
SOA, transferências de zona), faça suas edições e clique em aplicar ou em OK . Para revisar todas as
edições de zona, clique em Resumo e em OK .
Consulte Também
Gerenciamento de zona DNS Gerenciar IPAM
Exibir registros de recurso de DNS para uma zona
DNS
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para exibir registros de recursos de dns para uma zona dns no console do cliente do
IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para exibir registros de recursos de DNS para uma zona
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, em monitorar e gerenciar , clique em zonas DNS . O painel de navegação
divide-se em um painel de navegação superior e em um painel de navegação inferior.
3. No painel de navegação inferior, clique em pesquisa direta e, em seguida, expanda a lista domínio e
zona para localizar e selecionar a zona que você deseja exibir. Por exemplo, se você tiver uma zona
chamada Dublin, clique em Dublin .
4. No painel de exibição, a exibição padrão é dos servidores DNS da zona. Para alterar a exibição, clique em
modo de exibição atual e em registros de recursos .
5. Os registros de recursos de DNS para a zona são exibidos. Para filtrar os registros, digite o texto que você
deseja localizar no filtro .
6. Para filtrar os registros de recursos por tipo de registro, escopo de acesso ou outros critérios, clique em
Adicionar critérios e faça seleções na lista critérios e clique em Adicionar .
Consulte Também
Gerenciamento de zona DNS Gerenciar IPAM
Exibir zonas DNS
11/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para exibir as zonas DNS no console do cliente do IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
para exibir as zonas DNS no console do cliente do IPAM
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, em monitorar e gerenciar , clique em zonas DNS . O painel de navegação
divide-se em um painel de navegação superior e em um painel de navegação inferior.
3. No painel de navegação inferior, faça uma das seguintes seleções:
Pesquisa direta
Pesquisa inversa de IPv4
Pesquisa inversa de IPv6
Encaminhador condicional
Consulte Também
Gerenciamento de zona DNS Gerenciar IPAM
Gerenciar recursos em várias florestas do Active
Directory
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para aprender a usar o IPAM para gerenciar controladores de domínio, servidores
DHCP e servidores DNS em várias florestas de Active Directory.
para usar IPAM para gerenciar recursos em florestas de Active Directory remotas, cada floresta que você deseja
gerenciar deve ter uma relação de confiança bidirecional com a floresta onde IPAM está instalado.
Para iniciar o processo de descoberta para diferentes Active Directory florestas, abra Gerenciador do Servidor e
clique em IPAM. no console do cliente do IPAM, clique em configurar descober ta de ser vidor e em obter
florestas . Isso inicia uma tarefa em segundo plano que descobre florestas confiáveis e seus domínios. Após a
conclusão do processo de descoberta, clique em Configurar descober ta de ser vidor , que abre a caixa de
diálogo a seguir.
NOTE
para o - provisionamento baseado em Política de Grupo para um cenário de Active Directory entre florestas, certifique-se
de executar o cmdlet Windows PowerShell a seguir no servidor IPAM e não nos controladores de domínio confiantes. por
exemplo, se o seu servidor de IPAM estiver ingressado na floresta corp.contoso.com e a floresta confiante for
fabrikam.com, você poderá executar o seguinte cmdlet Windows PowerShell no servidor IPAM no corp.contoso.com para -
o provisionamento baseado em Política de Grupo na floresta fabrikam.com. Para executar esse cmdlet, você deve ser
membro do grupo Admins. do domínio na floresta fabrikam.com.
Na caixa de diálogo Configurar descober ta de ser vidor , clique em selecionar a floresta e escolha a
floresta que você deseja gerenciar com IPAM. Selecione também os domínios que você deseja gerenciar e clique
em Adicionar .
Em selecionar as funções de ser vidor para descobrir , para cada domínio que você deseja gerenciar,
especifique o tipo de servidores a serem descobertos. As opções são controlador de domínio , ser vidor
DHCP e ser vidor DNS .
Por padrão, os controladores de domínio, servidores DHCP e servidores DNS são descobertos. portanto, se você
não quiser descobrir um desses tipos de servidores, certifique-se de desmarcar a caixa de seleção dessa opção.
na ilustração de exemplo acima, o servidor de IPAM é instalado na floresta contoso.com e o domínio raiz da
floresta fabrikam.com é adicionado para gerenciamento de IPAM. as funções de servidor selecionadas permitem
que IPAM descubra e gerencie controladores de domínio, servidores DHCP e servidores DNS no domínio raiz
fabrikam.com e no domínio raiz contoso.com.
Depois de especificar florestas, domínios e funções de servidor, clique em OK . IPAM executa a descoberta e,
quando a descoberta é concluída, você pode gerenciar recursos na floresta local e remota.
Limpar dados de utilização
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para saber como excluir dados de utilização do banco de IPAM.
você deve ser membro de IPAM administradores , o grupo administradores do computador local ou
equivalente, para executar esse procedimento.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este tópico fornece informações sobre como usar o controle de acesso baseado em função no IPAM.
NOTE
além deste tópico, a seguinte documentação de controle de acesso do IPAM está disponível nesta seção.
Gerenciar controle de acesso baseado em função com o Gerenciador do Servidor
Gerenciar controle de acesso baseado em função com o Windows PowerShell
O controle de acesso baseado em função permite que você especifique privilégios de acesso em vários níveis,
incluindo o servidor DNS, a zona DNS e os níveis de registro de recurso DNS. Usando o controle de acesso
baseado em função, você pode especificar quem tem controle granular sobre as operações para criar, editar e
excluir diferentes tipos de registros de recursos de DNS.
Você pode configurar o controle de acesso para que os usuários sejam restritos às permissões a seguir.
Os usuários podem editar somente registros de recursos DNS específicos
Os usuários podem editar registros de recursos de DNS de um tipo específico, como PTR ou MX
Os usuários podem editar registros de recursos de DNS para zonas específicas
Consulte Também
Gerenciar o controle de acesso baseado em função com o Gerenciador do servidor Gerenciar o controle de
acesso baseado em função com o Windows PowerShell Gerenciar IPAM
Gerenciar controle de acesso baseado em função
com o Gerenciador do Servidor
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar os tópicos a seguir para gerenciar o controle de acesso baseado em função usando Gerenciador
do Servidor, que tem uma interface gráfica do usuário.
Criar uma função de usuário para controle de acesso
Criar uma política de acesso
Definir escopo de acesso para uma zona DNS
Definir escopo de acesso para registros de recursos DNS
Exibir funções e permissões de função
Como alternativa, você pode usar o Windows PowerShell para gerenciar IPAM controle de acesso baseado em
função. Para obter mais informações, consulte Gerenciar o controle de acesso baseado em função com Windows
PowerShell.
Consulte Também
Gerenciar IPAM
Criar uma função de usuário para controle de
acesso
07/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para criar uma nova função de usuário de controle de acesso no console do cliente
do IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
NOTE
Depois de criar uma função, você pode criar uma política de acesso para atribuir a função a um usuário ou grupo de
Active Directory específico. Para obter mais informações, consulte criar uma política de acesso.
3. Clique com o botão direito do mouse em funções e clique em Adicionar função de usuário .
4. A caixa de diálogo Adicionar ou Editar função é aberta. Em nome , digite um nome para a função que
torna a função de função clara. Por exemplo, se você quiser criar uma função que permita que os
administradores gerenciem registros de recurso SRV DNS, você pode nomear a função IPAMSr v . Se
necessário, role para baixo em operações para localizar o tipo de operações que você deseja definir para
a função. Para este exemplo, role para baixo até as operações de gerenciamento de registro de
recurso de DNS .
Consulte Também
Controle de acesso baseado em função Gerenciar IPAM
Criar uma política de acesso
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para criar uma política de acesso no console do cliente do IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
NOTE
Você pode criar uma política de acesso para um usuário específico ou para um grupo de usuários no Active Directory. ao
criar uma política de acesso, você deve selecionar uma função de IPAM interna ou uma função personalizada que você
criou. Para obter mais informações sobre as funções personalizadas, consulte criar uma função de usuário para o controle
de acesso.
5. A caixa de diálogo locais é aberta. Navegue até o local que contém a conta de usuário, selecione o local e
clique em OK . A caixa de diálogo locais é fechada.
6. Na caixa de diálogo Selecionar usuário ou grupo , em digite o nome do objeto a ser
selecionado , digite o nome da conta de usuário para a qual você deseja criar uma política de acesso.
Clique em OK .
7. em adicionar política de acesso , no usuário Configurações , o alias de usuário agora contém a
conta de usuário à qual a política se aplica. em Configurações de acesso , clique em novo .
Consulte Também
Controle de acesso baseado em função Gerenciar IPAM
Definir escopo de acesso para uma zona DNS
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para definir o escopo de acesso para uma zona DNS usando o console IPAM cliente.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para definir o escopo de acesso para uma zona DNS
1. No Gerenciador do Servidor, clique em IPAM . O IPAM do cliente é exibido.
2. No painel de navegação, clique em Zonas DNS. No painel de exibição, clique com o botão direito do
mouse na zona DNS para a qual você deseja alterar o escopo de acesso. Em seguida, clique em Definir
Escopo de Acesso .
3. A caixa de diálogo Definir Escopo de Acesso é aberta. Se necessário para sua implantação, clique
para desmarcar Herdar escopo de acesso do pai. Em Selecionar o escopo de acesso, selecione um
item e clique em OK.
4. No painel IPAM de exibição do console do cliente, verifique se o escopo de acesso para a zona foi
alterado.
Consulte Também
Controle de acesso baseado em função Gerenciar IPAM
Definir escopo de acesso para registros de recurso
DNS
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para definir o escopo de acesso para registros de recursos DNS usando o console do
cliente do IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para definir o escopo de acesso para registros de recursos de DNS
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, clique em zonas DNS . No painel de navegação inferior, expanda pesquisa
direta e navegue até e selecione a zona que contém os registros de recursos cujo escopo de acesso você
deseja alterar.
3. No painel de exibição, localize e selecione os registros de recursos cujo escopo de acesso você deseja
alterar.
4. Clique com o botão direito do mouse nos registros de recursos DNS selecionados e clique em definir
escopo de acesso .
5. A caixa de diálogo definir escopo de acesso é aberta. Se necessário para sua implantação, clique para
anular a seleção de herdar o escopo de acesso do pai . Em selecionar o escopo de acesso ,
selecione um item e clique em OK .
Consulte Também
Controle de acesso baseado em função Gerenciar IPAM
Exibir funções e permissões de função
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para exibir as funções de usuário do Controle de Acesso no console IPAM cliente.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para exibir funções de Controle de Acesso
1. No Gerenciador do Servidor, clique em IPAM . O IPAM do cliente é exibido.
2. No painel de navegação, clique em CONTROLE DE ACESSO.
3. No painel de navegação inferior, clique em Funções . No painel de exibição, as funções são listadas.
4. Selecione a função cujas permissões você deseja exibir. No painel de detalhes inferior, as operações
permitidas para a função são exibidas.
Consulte Também
Controle de acesso baseado em função Gerenciar IPAM
Gerenciar controle de acesso baseado em função
com o Windows PowerShell
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para aprender a usar o IPAM gerenciar o controle de acesso baseado em função com
Windows PowerShell.
NOTE
Para a IPAM Windows PowerShell de comando, consulte os cmdlets IpamServer no Windows PowerShell.
Os novos Windows PowerShell IPAM novos comandos fornecem a capacidade de recuperar e alterar os escopos
de acesso de objetos DNS e DHCP. A tabela a seguir ilustra o comando correto a ser usado para cada IPAM
objeto.
ZoneName : dublin.contoso.com
ZoneType : Forward
AccessScopePath : \Global\Dublin
IsSigned : False
DynamicUpdateStatus : None
ScavengeStaleRecords : False
SYNTAX
Set-IpamAccessScope [-IpamRange] -InputObject <ciminstance[]> [-AccessScopePath <string>] [-
IsInheritedAccessScope] [-PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf]
[-Confirm] [<CommonParameters>]
No exemplo a seguir, o escopo de acesso da zona DNS dublin.contoso.com é alterado de Dublin para
Europa.
PS C:\Users\Administrator.CONTOSO> Get-IpamDnsZone -ZoneType Forward -ZoneName dublin.contoso.com
ZoneName : dublin.contoso.com
ZoneType : Forward
AccessScopePath : \Global\Dublin
IsSigned : False
DynamicUpdateStatus : None
ScavengeStaleRecords : False
ZoneName : dublin.contoso.com
ZoneType : Forward
AccessScopePath : \Global\Europe
IsSigned : False
DynamicUpdateStatus : None
ScavengeStaleRecords : False
Network Load Balancing
12/08/2021 • 8 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Neste tópico, fornecemos uma visão geral do recurso NLB de balanceamento de carga de rede ( ) no Windows
Server 2016. Você pode usar o NLB para gerenciar dois ou mais servidores como um único cluster virtual. O
NLB aprimora a disponibilidade e a escalabilidade de aplicativos de servidor de Internet, como aqueles usados
em Web, FTP, firewall, proxy, VPN de rede privada virtual ( ) e outros servidores de missão - crítica.
NOTE
a Windows Server 2016 inclui um novo Software inspirado pelo Azure Load Balancer ( SLB ) como um componente da
infraestrutura de SDN de rede definida pelo Software ( ) . Use SLB em vez de NLB se você estiver usando o SDN, usando
cargas de trabalho não Windows, precisar de NAT de conversão de endereços de rede ( ) de saída ou necessidade de
balanceamento de carga de camada 3 ( L3 ) ou não baseado em TCP. você pode continuar a usar o NLB com Windows
Server 2016 para implantações não SDN. Para obter mais informações sobre SLB, consulte balanceamento de carga de
software (SLB) para Sdn.
O recurso NLB de balanceamento de carga de rede ( ) distribui o tráfego entre vários servidores usando o /
protocolo de rede IP TCP. Ao combinar dois ou mais computadores que estão executando aplicativos em um
único cluster virtual, o NLB fornece confiabilidade e desempenho para servidores Web e outros - servidores de
missão crítica.
Os servidores em um cluster NLB se chamam hosts, e cada host executa uma cópia separada dos aplicativos de
servidor. O NLB distribui as solicitações de entrada dos clientes pelos hosts do cluster. É possível configurar a
carga que será tratada por cada host. Você também pode adicionar hosts dinamicamente ao cluster para tratar
aumentos de carga. Além disso, o NLB pode direcionar todo o tráfego para um único host designado, chamado
de host padrão.
O NLB permite que todos os computadores no cluster sejam abordados pelo mesmo conjunto de endereços IP, e
mantém um conjunto de endereços IP exclusivos e dedicados para cada host. Para aplicativos com
balanceamento de carga - , quando um host falha ou fica offline, a carga é redistribuída automaticamente entre
os computadores que ainda estão operando. Quando estiver pronto, o computador offline poderá reintegrar-se
ao cluster de forma transparente e retomar sua parcela da carga de trabalho, o que permite que os outros
computadores do cluster lidem com menos tráfego.
Aplicações práticas
o NLB é útil para garantir que aplicativos sem estado, como servidores web que executam Serviços de
Informações da Internet ( IIS ) , estejam disponíveis com tempo de inatividade mínimo e que sejam escalonáveis
( adicionando mais servidores à medida que a carga aumenta ) . As seções a seguir descrevem como o NLB
suporta alta disponibilidade, escalabilidade e gerenciamento dos servidores em cluster que executam esses
aplicativos.
Alta disponibilidade
Um sistema altamente disponível oferece, de forma confiável, um nível aceitável de serviço com tempo de
inatividade mínimo. Para fornecer alta disponibilidade, o NLB inclui - recursos internos que podem
automaticamente:
Detectar um host de cluster que falha ou fica offline, e depois recuperar.
Equilibrar a carga da rede quando hosts são adicionados ou removidos.
Recuperar e redistribuir carga de trabalho no prazo de dez segundos.
Escalabilidade
Escalabilidade é a medida que determina como um computador, serviço ou aplicativo pode atender melhor às
necessidades crescentes de desempenho. No caso de clusters NLB , a escalabilidade é a capacidade de adicionar
paulatinamente um ou mais sistemas a um cluster existente quando a carga total sobre o cluster excede seus
recursos. Para dar suporte à escalabilidade, o NLB pode fazer o seguinte:
Equilibre solicitações de carga no cluster NLB para serviços IP individuais de TCP / .
Dar suporte para até 32 computadores em um único cluster.
Equilibre várias solicitações ( de carga de servidor do mesmo cliente ou de vários clientes em ) vários
hosts no cluster.
Adicionar hosts ao cluster do NLB à medida que a carga aumenta, sem fazer o cluster falhar.
Remover os hosts do cluster quando a carga diminui.
Permitir alto desempenho e baixa sobrecarga através de implementação com pipelining integral. O
pipelining permite que as solicitações sejam enviadas ao cluster NLB sem aguardar resposta da
solicitação enviada anteriormente.
Capacidade de gerenciamento
Para dar suporte à escalabilidade, o NLB pode fazer o seguinte:
Gerencie e configure vários clusters NLB e os hosts de cluster de um único computador usando o
Gerenciador NLB ou os cmdlets NLB (balanceamento de carga de rede) no Windows PowerShell.
Especificar o comportamento do balanceamento de carga para uma única porta ou para um grupo de
portas IP usando regras de gerenciamento de portas.
Definir regras de porta diferentes para cada site. Se você usar o mesmo conjunto de - servidores com
balanceamento de carga para vários aplicativos ou sites, as regras de porta serão baseadas no endereço
IP virtual de destino ( usando clusters virtuais ) .
Encaminhe todas as solicitações de cliente para um único host usando regras de host único opcionais - .
O NLB roteia solicitações de clientes para um host específico que esteja executando aplicativos
específicos.
Bloquear o acesso indesejado à rede para determinadas portas IP.
Habilite o suporte IGMP do protocolo de gerenciamento de grupo da Internet ( ) nos hosts do cluster
para controlar a saturação da porta do comutador ( em que os pacotes de rede de entrada são enviados
para todas as portas no comutador ) ao operar no modo multicast.
Iniciar, parar e controlar as ações NLB remotamente usando comandos do Windows PowerShell ou
scripts.
Exibir o log de eventos do Windows para verificar eventos do NLB. O NLB registra todas as ações e
alterações de cluster no log de eventos.
Funcionalidade importante
o NLB é instalado como um componente de driver de rede do Windows Server padrão. Suas operações são
transparentes para a / pilha de rede IP TCP. A figura a seguir mostra a relação entre o NLB e outros componentes
de software em uma configuração típica.
NOTE
Quando você implanta VMs como clusters virtuais, o NLB não exige que os servidores sejam de hospedagem múltipla
para ter vários endereços IP virtuais.
Permite que o NLB seja vinculado a vários adaptadores de rede, o que permite configurar vários clusters
independentes em cada host. O suporte a vários adaptadores de rede difere dos clusters virtuais, pois os
clusters virtuais permitem configurar vários clusters em um único adaptador de rede.
Não requer modificações de aplicativos de servidor para que eles possam ser executados em um cluster
NLB.
Pode ser configurado para adicionar automaticamente um host ao cluster se esse host de cluster falhar e
voltar ao modo online posteriormente. O host adicionado pode começar a manipular os pedidos de
novos servidores clientes.
Permite que você coloque computadores offline para manutenção preventiva sem perturbar as
operações de cluster nos outros hosts.
Requisitos de hardware
A seguir estão os requisitos de hardware para executar um cluster NLB.
Todos os hosts do cluster devem residir na mesma sub-rede.
Não há restrição ao número de adaptadores de rede em cada host, e hosts diferentes podem ter um
número diferente de adaptadores.
Dentro de cada cluster, todos os adaptadores de rede devem ser multicast ou unicast. O NLB não dá
suporte a ambientes mistos unicast e multicast em um único cluster.
Se você usar o modo unicast, o adaptador de rede que é usado para - manipular - o cliente para o tráfego
de cluster deve dar suporte à alteração do seu endereço MAC de controle de acesso à mídia ( ) .
Requisitos de software
A seguir estão os requisitos de software para executar um cluster NLB.
Somente TCP / IP pode ser usado no adaptador para o qual o NLB está habilitado em cada host. Não
adicione nenhum outro protocolo ( , por exemplo, IPX ) a esse adaptador.
Os endereços IP dos servidores no cluster devem ser estáticos.
NOTE
O NLB não dá suporte ao DHCP do protocolo de configuração de host dinâmico ( ) . O NLB desabilita o DHCP em cada
interface que ele configura.
Informações de instalação
você pode instalar o NLB usando Gerenciador do Servidor ou os comandos Windows PowerShell para NLB.
Opcionalmente, você pode instalar as Ferramentas de Balanceamento de Carga de Rede para gerenciar um
cluster NLB local ou remoto. as ferramentas incluem o gerenciador de balanceamento de carga de rede e os
comandos de Windows PowerShell do NLB.
Instalação com o Gerenciador do Servidor
No Gerenciador do Servidor, você pode usar o assistente para adicionar funções e recursos para adicionar o
recurso de balanceamento de carga de rede . Quando você concluir o assistente, o NLB será instalado e não
será necessário reiniciar o computador.
Instalação com o Windows PowerShell
para instalar o NLB usando Windows PowerShell, execute o comando a seguir em um prompt de Windows
PowerShell elevado no computador em que você deseja instalar o NLB.
Recursos adicionais
A tabela a seguir fornece links para informações adicionais sobre o recurso NLB.
Aplica-se a: Windows Server 2022, Windows Server 2016 e Windows Server 2019
Você pode usar este tópico para uma visão geral do Servidor de Políticas de Rede no Windows Server 2016 e
Windows Server 2019. O NPS é instalado quando você instala o recurso NPAS (Network Policy e Serviços do
Access) no Windows Server 2016 Server 2019.
NOTE
Além deste tópico, a documentação do NPS a seguir está disponível.
Práticas recomendadas do Servidor de Políticas de Rede
Introdução ao Servidor de Políticas de Rede
Planejar Servidor de Políticas de Rede
Implantar o Servidor de Políticas de Rede
Gerenciar o Servidor de Políticas de Rede
Cmdlets do NPS (Servidor de Políticas de Rede) Windows PowerShell para Windows Server 2016 e Windows 10
Cmdlets do NPS (Servidor de Políticas de Rede) Windows PowerShell para Windows Server 2012 R2 e Windows 8.1
Cmdlets NPS no Windows PowerShell para Windows Server 2012 e Windows 8
O Servidor de Políticas de Rede (NPS) permite que você crie e aplique políticas de acesso de rede em toda a
organização para autenticação e autorização de solicitações de conexão.
Você também pode configurar o NPS como um proxy radius (Remote Authentication Dial-In User Service) para
encaminhar solicitações de conexão para um NPS remoto ou outro servidor RADIUS para que você possa
balancear a carga de solicitações de conexão e encaminhá-las para o domínio correto para autenticação e
autorização.
O NPS permite configurar e gerenciar centralmente a autenticação, a autorização e a contabilidade de acesso à
rede com os seguintes recursos:
Ser vidor RADIUS . O NPS executa autenticação centralizada, autorização e contabilização de comutadores
sem fio, autenticação, discagem de acesso remoto e conexões VPN (rede virtual privada). Ao usar o NPS
como servidor RADIUS, você configura servidores de acesso à rede (como pontos de acesso sem fio e
servidores VPN) como clientes RADIUS no NPS. Você também configura as políticas de rede que o NPS usa
para autorizar solicitações de conexão. Você pode configurar a contabilização RADIUS para que o NPS
registre as informações de contabilização em arquivos de log no disco rígido local ou em um banco de dados
do Microsoft SQL Server. Para obter mais informações, consulte Servidor RADIUS.
Proxy RADIUS . Ao usar o NPS como um proxy RADIUS, você configura políticas de solicitação de conexão
que dizem ao NPS quais solicitações de conexão encaminhar para outros servidores RADIUS e para quais
servidores RADIUS você deseja encaminhar solicitações de conexão. Também é possível configurar o NPS
para que encaminhe dados contábeis a serem registrados por um ou mais computadores de um grupo de
servidores RADIUS remotos. Para configurar o NPS como um servidor proxy RADIUS, consulte os tópicos a
seguir. Para obter mais informações, consulte Proxy RADIUS.
Configurar políticas de solicitação de conexão
Contabilidade RADIUS . Você pode configurar o NPS para registrar eventos em um arquivo de log local ou
em uma instância local ou remota do Microsoft SQL Server. Para obter mais informações, consulte Registro
em log do NPS.
IMPORTANT
NAP da Proteção de Acesso à Rede, HRA da Autoridade de Registro de Saúde e Protocolo de Autorização de Credencial do
Host foram preterido no Windows Server 2012 R2 e não estão disponíveis ( ) no ( ) ( ) Windows Server 2016. Se você tiver
uma implantação NAP usando sistemas operacionais anteriores Windows Server 2016, não poderá migrar sua
implantação NAP para Windows Server 2016.
Você pode configurar o NPS com qualquer combinação desses recursos. Por exemplo, você pode configurar um
NPS como um servidor RADIUS para conexões VPN e também como um proxy RADIUS para encaminhar
algumas solicitações de conexão a membros de um grupo de servidores RADIUS remoto para autenticação e
autorização em outro domínio.
NOTE
O recurso política de rede e Serviços do Access WIndows não está disponível em sistemas instalados com uma opção de
instalação Server Core.
As seções a seguir fornecem informações mais detalhadas sobre o NPS como um servidor RADIUS e um proxy.
NOTE
Para obter informações sobre como implantar o NPS como um servidor RADIUS, consulte Deploy Network Policy Server.
O NPS permite o uso de um conjunto heterogêneo de rede sem fio, comutador, acesso remoto ou equipamento
VPN. Você pode usar o NPS com o serviço de Acesso Remoto, que está disponível no Windows Server 2016.
O NPS usa um Active Directory Domain Services AD DS ou o banco de dados de contas de usuário SAM
(Gerenciador de Contas de Segurança) local para autenticar credenciais de usuário para ( ) tentativas de
conexão. Quando um servidor que executa o NPS é membro de um domínio AD DS, o NPS usa o serviço de
diretório como seu banco de dados de conta de usuário e faz parte de uma solução de logon único. O mesmo
conjunto de credenciais é usado para autenticação e autorização de acesso de controle de acesso de rede a uma
rede e para fazer logoff em um ( ) AD DS domínio.
NOTE
O NPS usa as propriedades discadas da conta de usuário e das políticas de rede para autorizar uma conexão.
IsPs de provedores de serviços de Internet e organizações que mantêm o acesso à rede têm o maior desafio de
gerenciar todos os tipos de acesso à rede de um único ponto de administração, independentemente do tipo de
equipamento de acesso ( ) à rede usado. O padrão RADIUS dá suporte a essa funcionalidade em ambientes
homogêneos e heterogêneos. RADIUS é um protocolo cliente-servidor que permite que o equipamento de
acesso à rede (usado como clientes RADIUS) envie solicitações de autenticação e contabilidade para um
servidor RADIUS.
Um servidor RADIUS tem acesso às informações da conta de usuário e pode verificar as credenciais de
autenticação de acesso à rede. Se as credenciais do usuário são autenticadas e a tentativa de conexão é
autorizada, o servidor RADIUS autoriza o acesso do usuário com base nas condições especificadas e, em
seguida, registra a conexão de acesso à rede em um log de contabilidade. O uso do RADIUS permite que os
dados de autenticação, autorização e contabilidade do usuário de acesso à rede sejam coletados e mantidos em
um local central, em vez de em cada servidor de acesso.
Usando o NPS como um servidor RADIUS
Você pode usar o NPS como um servidor RADIUS quando:
Você está usando um domínio AD DS ou o banco de dados de contas de usuário SAM local como seu banco
de dados de conta de usuário para clientes de acesso.
Você está usando o Acesso Remoto em vários servidores discados, servidores VPN ou roteadores discados
por demanda e deseja centralizar a configuração de políticas de rede e registro em log de conexão e
contabilidade.
Você está terceirizando seu acesso discado, VPN ou sem fio a um provedor de serviços. Os servidores de
acesso usam RADIUS para autenticar e autorizar conexões feitas por membros de sua organização.
Você deseja centralizar a autenticação, a autorização e a contabilidade de um conjunto heterogêneo de
servidores de acesso.
A ilustração a seguir mostra o NPS como um servidor RADIUS para uma variedade de clientes de acesso.
Proxy RADIUS
Como um proxy RADIUS, o NPS encaminha mensagens de autenticação e contabilidade para NPS e outros
servidores RADIUS. Você pode usar o NPS como um proxy RADIUS para fornecer o roteamento de mensagens
RADIUS entre clientes RADIUS também chamados de servidores de acesso à rede e servidores RADIUS que
executam autenticação de usuário, autorização e contabilização para a tentativa ( ) de conexão.
Quando usado como um proxy RADIUS, o NPS é um ponto central de troca ou roteamento por meio do qual o
acesso RADIUS e as mensagens de contabilidade fluem. O NPS registra informações em um log de
contabilidade sobre as mensagens encaminhadas.
Usando NPS como um proxy RADIUS
Você pode usar o NPS como um proxy RADIUS quando:
Você é um provedor de serviços que oferece serviços terceirizados de acesso à rede discada, VPN ou sem fio
para vários clientes. Seus NASs enviam solicitações de conexão para o proxy RADIUS do NPS. Com base na
parte do realm do nome de usuário na solicitação de conexão, o proxy NPS RADIUS encaminha a solicitação
de conexão para um servidor RADIUS que é mantido pelo cliente e pode autenticar e autorizar a tentativa de
conexão.
Você deseja fornecer autenticação e autorização para contas de usuário que não são membros do domínio
no qual o NPS é um membro ou outro domínio que tenha uma relação de confiança de duas vias com o
domínio no qual o NPS é membro. Isso inclui contas em domínios não confiáveis, domínios confiáveis e
outras florestas. Em vez de configurar seus servidores de acesso para enviar suas solicitações de conexão
para um servidor NPS RADIUS, você pode configurá-los para enviar suas solicitações de conexão para um
proxy NPS RADIUS. O proxy NPS RADIUS usa a parte do nome de realm do nome de usuário e encaminha a
solicitação para um NPS no domínio ou floresta correto. As tentativas de conexão para contas de usuário em
um domínio ou floresta podem ser autenticadas para NASs em outro domínio ou floresta.
Você deseja executar a autenticação e a autorização usando um banco de dados que não é um banco de
dados Windows conta. Nesse caso, as solicitações de conexão que corresponderem a um nome de realm
especificado são encaminhadas para um servidor RADIUS, que tem acesso a um banco de dados diferente de
contas de usuário e dados de autorização. Exemplos de outros bancos de dados de usuário incluem o NDS
(Novell Directory Services) e linguagem SQL (SQL) .
Você deseja processar um grande número de solicitações de conexão. Nesse caso, em vez de configurar seus
clientes RADIUS para tentar equilibrar suas solicitações de conexão e contabilidade em vários servidores
RADIUS, você pode configurá-los para enviar suas solicitações de conexão e contabilidade para um proxy
NPS RADIUS. O proxy RADIUS NPS balanceia dinamicamente a carga de solicitações de conexão e
contabilidade em vários servidores RADIUS e aumenta o processamento de grandes números de clientes
RADIUS e autenticações por segundo.
Você deseja fornecer autenticação RADIUS e autorização para provedores de serviços terceirizados e
minimizar a configuração de firewall da intranet. Um firewall de intranet está entre a rede de perímetro (a
rede entre a intranet e a Internet) e a intranet. Ao colocar um NPS em sua rede de perímetro, o firewall entre
a rede de perímetro e a intranet deve permitir que o tráfego flua entre o NPS e vários controladores de
domínio. Ao substituir o NPS por um proxy NPS, o firewall deve permitir que apenas o tráfego RADIUS flua
entre o proxy NPS e um ou vários NPSs na intranet.
A ilustração a seguir mostra o NPS como um proxy RADIUS entre clientes RADIUS e servidores RADIUS.
Com o NPS, as organizações também podem terceirizar a infraestrutura de acesso remoto para um provedor de
serviços, mantendo o controle sobre autenticação, autorização e contabilidade do usuário.
As configurações do NPS podem ser criadas para os seguintes cenários:
Acesso sem fio
Acesso remoto de rede virtual privada (VPN) ou dial-up da organização
Dial-up ou acesso sem fio terceirizado
Acesso à Internet
Acesso autenticado a recursos de extranet para parceiros de negócios
Configuração
Para configurar o NPS como um servidor RADIUS, você pode usar a configuração padrão ou a configuração
avançada no console do NPS ou no Gerenciador do Servidor. Para configurar o NPS como um proxy RADIUS,
você deve usar a configuração avançada.
Configuração padrão
Com a configuração padrão, os assistentes são fornecidos para ajudá-lo a configurar o NPS para os seguintes
cenários:
Servidor RADIUS para conexões dial-up ou VPN
Servidor RADIUS para conexões 802.1X com ou sem fio
Para configurar o NPS usando um assistente, abra o console do NPS, selecione um dos cenários anteriores e
clique no link que abre o assistente.
Configuração avançada
Ao usar a configuração avançada, você configura manualmente o NPS como um servidor RADIUS ou proxy
RADIUS.
Para configurar o NPS usando a configuração avançada, abra o console do NPS e clique na seta ao lado de
Configuração avançada para expandir esta seção.
Os seguintes itens de configuração avançada são fornecidos.
Configurar servidor RADIUS
Para configurar o NPS como um servidor RADIUS, você deve configurar clientes RADIUS, a política de rede e a
contabilização RADIUS.
Para obter instruções sobre como fazer essas configurações, consulte os tópicos a seguir.
Configurar clientes RADIUS
Configurar políticas de rede
Configurar a contabilização do Servidor de Políticas de Rede
Configurar proxy RADIUS
Para configurar o NPS como um proxy RADIUS, você deve configurar clientes RADIUS, grupos de servidores
remotos RADIUS e políticas de solicitação de conexão.
Para obter instruções sobre como fazer essas configurações, consulte os tópicos a seguir.
Configurar clientes RADIUS
Configurar grupos de servidores RADIUS remotos
Configurar políticas de solicitação de conexão
Log do NPS
O log do NPS também é chamado de contabilidade RADIUS. Configure o log do NPS para seus requisitos se o
NPS for usado como um servidor RADIUS, proxy ou qualquer combinação dessas configurações.
Para configurar o log do NPS, você deve configurar os eventos que deseja que sejam registrados e exibidos com
Visualizador de Eventos e, em seguida, determinar quais outras informações deseja registrar em log. além disso,
você deve decidir se deseja registrar em log as informações de autenticação e estatísticas de usuário em
arquivos de log de texto armazenados no computador local ou em um banco de dados SQL Server no
computador local ou em um computador remoto.
Para obter mais informações, consulte Configure Network Policy Server Accounting.
Práticas recomendadas do Servidor de Políticas de
Rede
13/08/2021 • 8 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para saber mais sobre as práticas recomendadas para implantar e gerenciar o NPS
do Servidor de Políticas ( de ) Rede.
As seções a seguir fornecem práticas recomendadas para diferentes aspectos da implantação do NPS.
Contabilidade
A seguir estão as práticas recomendadas para registro em log do NPS.
Há dois tipos de contabilidade ou registro em log no NPS:
Log de eventos para NPS. Você pode usar o log de eventos para registrar eventos NPS nos logs de
eventos do sistema e de segurança. Isso é usado principalmente para auditar e solucionar problemas de
tentativas de conexão.
Registro em log de solicitações de contabilidade e autenticação de usuário. Você pode registrar
solicitações de autenticação e contabilidade de usuário para registrar arquivos no formato de texto ou no
formato de banco de dados ou fazer logoff em um procedimento armazenado em um banco de dados
SQL Server 2000. O log de solicitações é usado principalmente para fins de análise de conexão e
cobrança e também é útil como uma ferramenta de investigação de segurança, fornecendo um método
de acompanhamento da atividade de um invasor.
Para fazer o uso mais eficaz do registro em log do NPS:
Abile o registro ( em log inicialmente para registros de ) autenticação e contabilidade. Modifique essas
seleções depois de determinar o que é apropriado para seu ambiente.
Verifique se o log de eventos está configurado com uma capacidade suficiente para manter os logs.
Faça o back-up de todos os arquivos de log regularmente porque eles não podem ser recriados quando
estão danificados ou excluídos.
Use o atributo classe RADIUS para acompanhar o uso e simplificar a identificação de qual departamento
ou usuário cobrar pelo uso. Embora o atributo Class gerado automaticamente seja exclusivo para cada
solicitação, registros duplicados podem existir em casos em que a resposta ao servidor de acesso é
perdida e a solicitação é reposta. Talvez seja necessário excluir solicitações duplicadas de seus logs para
acompanhar com precisão o uso.
Se os servidores de acesso à rede e servidores proxy RADIUS enviarem periodicamente mensagens de
solicitação de conexão fictícia ao NPS para verificar se o NPS está online, use a configuração de registro
ping de nome de usuário. Essa configuração define o NPS para rejeitar automaticamente essas
solicitações de conexão falsas sem processá-las. Além disso, o NPS não registra transações que envolvem
o nome de usuário fictício em nenhum arquivo de log, o que facilita a interpretação do log de eventos.
Desabilite o encaminhamento de notificação do NAS. Você pode desabilitar o encaminhamento de
mensagens de início e parada de NASs (servidores de acesso à rede) para membros de um grupo de
servidores RADIUS remoto configurado no NPS. Para obter mais informações, consulte Desabilitar o
encaminhamento de notificação nas.
Para obter mais informações, consulte Configure Network Policy Server Accounting.
Para fornecer failover e redundância com SQL Server registro em log, coloque dois computadores
executando SQL Server em sub-redes diferentes. Use o assistente SQL Server Criar Publicação para
configurar a replicação de banco de dados entre os dois servidores. Para obter mais informações, consulte
SQL Server documentação técnica e Replicação do SQL Server.
Autenticação
A seguir estão as práticas recomendadas para autenticação.
Use métodos de autenticação baseados em certificado, como PROTOCOLO PEAP de Autenticação Extensível
Protegido e EAP de Protocolo de Autenticação ( ) Extensível ( para ) autenticação forte. Não use métodos de
autenticação somente senha porque eles são vulneráveis a uma variedade de ataques e não são seguros.
Para autenticação sem fio segura, é recomendável usar o PEAP - MS CHAP v2, pois o NPS prova sua
identidade para clientes sem fio usando um certificado do servidor, enquanto os usuários provam sua
identidade com seu nome de usuário e - senha. Para obter mais informações sobre como usar o NPS em sua
implantação sem fio, consulte Deploy Password-Based 802.1X Authenticated Wireless Access.
Implante sua própria AC de autoridade de certificação com os Serviços de Certificados do Active Directory
AD CS quando você usar métodos de autenticação fortes baseados em certificado, como PEAP e EAP, que
exigem o uso de um certificado de servidor ( ) em ® ( ) NPSs. Você também pode usar sua AC para
registrar certificados de computador e certificados de usuário. Para obter mais informações sobre como
implantar certificados de servidor em nps e servidores de acesso remoto, consulte Deploy Server
Certificates for 802.1X Wired and Wireless Deployments.
IMPORTANT
O NPS (Servidor de Políticas de Rede) não dá suporte ao uso dos caracteres ASCII estendidos em senhas.
Sugestões de instalação
A seguir estão as práticas recomendadas para instalar o NPS.
Antes de instalar o NPS, instale e teste cada um dos servidores de acesso à rede usando métodos de
autenticação local antes de configurá-los como clientes RADIUS no NPS.
Depois de instalar e configurar o NPS, salve a configuração usando o comando Windows PowerShell
Export-NpsConfiguration. Salve a configuração do NPS com esse comando sempre que reconfigurar o
NPS.
Cau t i on
O arquivo de configuração NPS exportado contém segredos compartilhados não criptografados para
clientes RADIUS e membros de grupos de servidores RADIUS remotos. Por isso, certifique-se de salvar o
arquivo em um local seguro.
O processo de exportação não inclui configurações de registro em log Microsoft SQL Server no arquivo
exportado. Se você importar o arquivo exportado para outro NPS, deverá configurar manualmente SQL
Server Log no novo servidor.
Problemas de segurança
A seguir estão as práticas recomendadas para reduzir problemas de segurança.
Quando você estiver administrando um NPS remotamente, não envie dados confidenciais ou confidenciais (por
exemplo, segredos compartilhados ou senhas) pela rede em texto não criptografado. Há dois métodos
recomendados para administração remota de NPSs:
Use Serviços de Área de Trabalho Remota para acessar o NPS. Quando você usa Serviços de Área de
Trabalho Remota, os dados não são enviados entre o cliente e o servidor. Somente a interface do usuário
do servidor (por exemplo, a área de trabalho do sistema operacional e a imagem do console NPS) é
enviada ao cliente do Serviços de Área de Trabalho Remota, que é chamado Conexão de Área de Trabalho
Remota no Windows ® 10. O cliente envia a entrada do teclado e do mouse, que é processada
localmente pelo servidor que Serviços de Área de Trabalho Remota habilitado. Quando Serviços de Área
de Trabalho Remota usuários fazem logon, eles podem exibir apenas suas sessões de cliente individuais,
que são gerenciadas pelo servidor e são independentes umas das outras. Além disso, Conexão de Área
de Trabalho Remota fornece criptografia de 128 bits entre cliente e servidor.
Use o protocolo IPsec para criptografar dados confidenciais. Você pode usar o IPsec para criptografar a
comunicação entre o NPS e o computador cliente remoto que você está usando para administrar o NPS.
Para administrar o servidor remotamente, você pode instalar o Ferramentas de Administração de
Servidor Remoto para Windows 10 no computador cliente. Após a instalação, use o Console de
Gerenciamento Microsoft (MMC) para adicionar o snap-in nps ao console.
IMPORTANT
Você pode instalar Ferramentas de Administração de Servidor Remoto para Windows 10 somente na versão completa do
Windows 10 Professional ou Windows 10 Enterprise.
Para obter mais informações sobre o NPS, consulte Servidor de Políticas de Rede (NPS).
Introdução ao Servidor de Políticas de Rede
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar os tópicos desta seção para saber mais sobre recursos e funcionalidades do servidor de
diretivas de rede.
NOTE
Para obter a documentação adicional do servidor de políticas de rede, você pode usar as seções de biblioteca a seguir.
Planejar Servidor de Políticas de Rede
Implantar o Servidor de Políticas de Rede
Gerenciar o Servidor de Políticas de Rede
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para saber mais sobre o processamento de solicitação de conexão no servidor de
políticas de rede no Windows Server 2016.
NOTE
Além deste tópico, a documentação de processamento de solicitação de conexão a seguir está disponível.
Políticas de solicitação de conexão
Nomes de territórios
Grupos de servidores RADIUS remotos
Você pode usar o processamento de solicitação de conexão para especificar onde a autenticação de solicitações
de conexão é executada-no computador local ou em um servidor RADIUS remoto que é membro de um grupo
de servidores RADIUS remoto.
Se desejar que o servidor local que está executando o NPS (servidor de diretivas de rede) execute a autenticação
para solicitações de conexão, você poderá usar a política de solicitação de conexão padrão sem configuração
adicional. Com base na política padrão, o NPS autentica usuários e computadores que têm uma conta no
domínio local e em domínios confiáveis.
Se você quiser encaminhar as solicitações de conexão para um NPS remoto ou outro servidor RADIUS, crie um
grupo de servidores remotos RADIUS e configure uma política de solicitação de conexão que encaminhe
solicitações para esse grupo de servidores remotos RADIUS. Com essa configuração, o NPS pode encaminhar
solicitações de autenticação para qualquer servidor RADIUS, e os usuários com contas em domínios não
confiáveis podem ser autenticados.
A ilustração a seguir mostra o caminho de uma mensagem de Access-Request de um servidor de acesso à rede
para um proxy RADIUS e, em seguida, para um servidor RADIUS em um grupo de servidores RADIUS remoto.
No proxy RADIUS, o servidor de acesso à rede é configurado como um cliente RADIUS; e, em cada servidor
RADIUS, o proxy RADIUS é configurado como um cliente RADIUS.
NOTE
Os servidores de acesso à rede que você usa com o NPS podem ser dispositivos de gateway em conformidade com o
protocolo RADIUS, como pontos de acesso sem fio 802.1 X e comutadores de autenticação, servidores que executam
acesso remoto que são configurados como servidores VPN ou dial-up ou outros dispositivos compatíveis com RADIUS.
Se você quiser que o NPS processe algumas solicitações de autenticação localmente ao encaminhar outras
solicitações para um grupo de servidores RADIUS remotos, configure mais de uma política de solicitação de
conexão.
Para configurar uma política de solicitação de conexão que especifica qual NPS ou grupo de servidores RADIUS
processa solicitações de autenticação, consulte políticas de solicitação de conexão.
Para especificar o NPS ou outros servidores RADIUS aos quais as solicitações de autenticação são
encaminhadas, consulte grupos de servidores remotos RADIUS.
NOTE
O servidor de acesso também envia Accounting-Request mensagens durante o tempo em que a conexão é estabelecida,
quando a conexão do cliente de acesso é fechada e quando o servidor de acesso é iniciado e interrompido.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para aprender a usar as políticas de solicitação de conexão do NPS para configurar o
NPS como um servidor RADIUS, um proxy RADIUS ou ambos.
NOTE
Além deste tópico, a documentação da política de solicitação de conexão a seguir está disponível.
Configurar políticas de solicitação de conexão
Configurar grupos de servidores RADIUS remotos
As políticas de solicitação de conexão são conjuntos de condições e configurações que permitem que os
administradores de rede designem quais servidores do serviço RADIUS (RADIUS) executam a autenticação e a
autorização de solicitações de conexão que o servidor que executa o NPS (servidor de diretivas de rede) recebe
de clientes RADIUS. As políticas de solicitação de conexão podem ser configuradas para designar quais
servidores RADIUS são usados para contabilização RADIUS.
Você pode criar políticas de solicitação de conexão para que algumas mensagens de solicitação RADIUS
enviadas de clientes RADIUS sejam processadas localmente (o NPS é usado como um servidor RADIUS) e
outros tipos de mensagens são encaminhados para outro servidor RADIUS (o NPS é usado como um proxy
RADIUS).
Com as políticas de solicitação de conexão, você pode usar o NPS como um servidor RADIUS ou um proxy
RADIUS, com base em fatores como o seguinte:
A hora do dia e o dia da semana
O nome do Realm na solicitação de conexão
O tipo de conexão que está sendo solicitada
O endereço IP do cliente RADIUS
As mensagens de Access-Request RADIUS serão processadas ou encaminhadas pelo NPS somente se as
configurações da mensagem de entrada corresponderem a pelo menos uma das políticas de solicitação de
conexão configuradas no NPS.
Se as configurações de política forem correspondentes e a política exigir que o NPS processe a mensagem, o
NPS atuará como um servidor RADIUS, Autenticando e autorizando a solicitação de conexão. Se as
configurações de política forem correspondentes e a política exigir que o NPS encaminhe a mensagem, o NPS
atuará como um proxy RADIUS e encaminhará a solicitação de conexão a um servidor RADIUS remoto para
processamento.
Se as configurações de uma mensagem de Access-Request RADIUS de entrada não corresponderem a pelo
menos uma das políticas de solicitação de conexão, uma mensagem de Access-Reject será enviada ao cliente
RADIUS e o usuário ou computador que está tentando se conectar à rede terá o acesso negado.
Exemplos de configuração
Os exemplos de configuração a seguir demonstram como você pode usar as políticas de solicitação de conexão.
NPS como um servidor RADIUS
A política de solicitação de conexão padrão é a única política configurada. Neste exemplo, o NPS é configurado
como um servidor RADIUS e todas as solicitações de conexão são processadas pelo NPS local. O NPS pode
autenticar e autorizar usuários cujas contas estejam no domínio do domínio NPS e em domínios confiáveis.
NPS como um proxy RADIUS
A política de solicitação de conexão padrão é excluída e duas novas políticas de solicitação de conexão são
criadas para encaminhar solicitações para dois domínios diferentes. Neste exemplo, o NPS está configurado
como um proxy RADIUS. O NPS não processa nenhuma solicitação de conexão no servidor local. Em vez disso,
ele encaminha as solicitações de conexão para o NPS ou outros servidores RADIUS configurados como
membros de grupos de servidores RADIUS remotos.
NPS como servidor RADIUS e proxy RADIUS
Além da política de solicitação de conexão padrão, é criada uma nova política de solicitação de conexão que
encaminha as solicitações de conexão para um NPS ou outro servidor RADIUS em um domínio não confiável.
Neste exemplo, a política de proxy aparece primeiro na lista ordenada de políticas. Se a solicitação de conexão
corresponder à política de proxy, a solicitação de conexão será encaminhada para o servidor RADIUS no grupo
de servidores remotos RADIUS. Se a solicitação de conexão não corresponder à política de proxy, mas
corresponder à política de solicitação de conexão padrão, o NPS processará a solicitação de conexão no servidor
local. Se a solicitação de conexão não corresponder a nenhuma política, ela será descartada.
NPS como servidor RADIUS com servidores de contabilidade remoto
Neste exemplo, o NPS local não está configurado para executar a contabilidade e a política de solicitação de
conexão padrão é revisada para que as mensagens de contabilização RADIUS sejam encaminhadas para um
NPS ou outro servidor RADIUS em um grupo de servidores remotos RADIUS. Embora as mensagens de
contabilização sejam encaminhadas, as mensagens de autenticação e autorização não são encaminhadas, e o
NPS local executa essas funções para o domínio local e todos os domínios confiáveis.
NPS com RADIUS remoto para Windows mapeamento de usuário
neste exemplo, o NPS atua como um servidor radius e como um proxy radius para cada solicitação de conexão
individual encaminhando a solicitação de autenticação para um servidor RADIUS remoto ao usar uma conta de
usuário Windows local para autorização. essa configuração é implementada configurando o RADIUS remoto
para Windows atributo de mapeamento de usuário como uma condição da política de solicitação de conexão.
(Além disso, uma conta de usuário deve ser criada localmente que tenha o mesmo nome que a conta de usuário
remoto na qual a autenticação é executada pelo servidor RADIUS remoto.)
IMPORTANT
Se você configurar um método de autenticação na diretiva de solicitação de conexão que seja menos segura do que o
método de autenticação configurado na diretiva de rede, o método de autenticação mais seguro que você configurar na
política de rede será substituído. Por exemplo, se você tiver uma política de rede que exija o uso de autenticação extensível
protegida Protocol-Microsoft protocolo de autenticação de handshake de desafio versão 2 ( PEAP-MS-CHAP v2 ) , que é
um método de autenticação baseado em senha para sem fio seguro e também configurar uma política de solicitação de
conexão para permitir acesso não autenticado, o resultado é que nenhum cliente é solicitado a autenticar usando PEAP-
MS Neste exemplo, todos os clientes que se conectam à sua rede recebem acesso não autenticado.
Contabilidade
Ao usar essa configuração, você pode configurar a política de solicitação de conexão para encaminhar
informações de estatísticas para um NPS ou outro servidor RADIUS em um grupo de servidores remotos
RADIUS para que o grupo de servidores remotos RADIUS execute a contabilidade.
NOTE
Se você tiver vários servidores RADIUS e quiser informações de estatísticas para todos os servidores armazenados em um
banco de dados de contabilidade RADIUS central, poderá usar a configuração contabilidade de política de solicitação de
conexão em uma política em cada servidor RADIUS para encaminhar dados contábeis de todos os servidores para um
NPS ou outro servidor RADIUS designado como um servidor de contabilidade.
NOTE
Se você estiver usando o protocolo de autenticação MS-CHAP v2, não poderá manipular o atributo de nome de usuário
se a política de solicitação de conexão for usada para encaminhar a mensagem RADIUS. A única exceção ocorre quando
uma barra invertida ( ) caractere é usada e a manipulação só afeta as informações à esquerda dela. Um caractere de barra
invertida normalmente é usado para indicar um nome de domínio (as informações à esquerda do caractere de barra
invertida) e um nome de conta de usuário dentro do domínio (as informações à direita do caractere de barra invertida).
Nesse caso, somente as regras de manipulação de atributos que modificam ou substituem o nome de domínio são
permitidas.
Para obter exemplos de como manipular o nome de realm no atributo de nome de usuário, consulte a seção
"exemplos de manipulação do nome de realm no atributo de nome de usuário" no tópico usar expressões
regulares no NPS.
Encaminhando a solicitação
Você pode definir as seguintes opções de solicitação de encaminhamento que são usadas para mensagens de
Access-Request RADIUS:
Autenticar solicitações neste ser vidor . Usando essa configuração, o NPS usa um domínio do
Windows NT 4,0, Active Directory ou o banco de dados de contas de usuário do SAM (Gerenciador de
contas de segurança) local para autenticar a solicitação de conexão. Essa configuração também especifica
que a diretiva de rede correspondente configurada no NPS, juntamente com as propriedades de
discagem da conta de usuário, são usadas pelo NPS para autorizar a solicitação de conexão. Nesse caso, o
NPS é configurado para executar como um servidor RADIUS.
Encaminhe solicitações para o seguinte grupo de ser vidores remotos RADIUS . Ao usar essa
configuração, o NPS encaminha as solicitações de conexão para o grupo de servidores remotos RADIUS
que você especificar. Se o NPS receber uma mensagem de Access-Accept válida que corresponde à
mensagem de Access-Request, a tentativa de conexão será considerada autenticada e autorizada. Nesse
caso, o NPS atua como um proxy RADIUS.
Aceite usuários sem validar credenciais . Ao usar essa configuração, o NPS não verifica a identidade
do usuário que está tentando se conectar à rede e o NPS não tenta verificar se o usuário ou o
computador tem o direito de se conectar à rede. Quando o NPS é configurado para permitir o acesso não
autenticado e recebe uma solicitação de conexão, o NPS envia imediatamente uma mensagem de Access-
Accept para o cliente RADIUS, e o usuário ou computador recebe acesso à rede. Essa configuração é
usada para alguns tipos de encapsulamento compulsório em que o cliente de acesso é encapsulado antes
de as credenciais do usuário serem autenticadas.
NOTE
Essa opção de autenticação não pode ser usada quando o protocolo de autenticação do cliente de acesso é MS-CHAP v2
ou EAP-TLS (autenticação extensível Protocol-Transport segurança de camada), ambos fornecendo autenticação mútua.
Na autenticação mútua, o cliente de acesso comprova que se trata de um cliente de acesso válido para o servidor de
autenticação (o NPS), e o servidor de autenticação comprova que é um servidor de autenticação válido para o cliente de
acesso. Quando essa opção de autenticação é usada, a mensagem de Access-Accept é retornada. No entanto, o servidor
de autenticação não fornece validação para o cliente de acesso e a autenticação mútua falha.
Para obter exemplos de como usar expressões regulares para criar regras de roteamento que encaminham
mensagens RADIUS com um nome de realm especificado para um grupo de servidores RADIUS remotos,
consulte a seção "exemplo de encaminhamento de mensagens RADIUS por um servidor proxy" no tópico usar
expressões regulares no NPS.
Avançado
Você pode definir propriedades avançadas para especificar a série de atributos RADIUS que são:
Adicionado à mensagem de resposta RADIUS quando o NPS está sendo usado como um servidor de
autenticação ou contabilização RADIUS. Quando há atributos especificados em uma diretiva de rede e na
política de solicitação de conexão, os atributos que são enviados na mensagem de resposta RADIUS são a
combinação dos dois conjuntos de atributos.
Adicionado à mensagem RADIUS quando o NPS está sendo usado como um proxy de autenticação ou
estatísticas RADIUS. Se o atributo já existir na mensagem que é encaminhada, ele será substituído pelo valor
do atributo especificado na política de solicitação de conexão.
Além disso, alguns atributos que estão disponíveis para configuração na guia configurações de diretiva de
solicitação de conexão na categoria avançado fornecem funcionalidade especializada. Por exemplo, você pode
configurar o atributo RADIUS remoto para mapeamento de usuário do Windows quando desejar dividir
a autenticação e a autorização de uma solicitação de conexão entre dois bancos de dados de contas de usuário.
O atributo RADIUS remoto para o mapeamento de usuários do Windows especifica que a autorização
do Windows ocorre para usuários que são autenticados por um servidor RADIUS remoto. Em outras palavras,
um servidor RADIUS remoto executa a autenticação em uma conta de usuário em um banco de dados de contas
de usuário remoto, mas o NPS local autoriza a solicitação de conexão com uma conta de usuário em um banco
de dados de contas de usuário local. Isso é útil quando você deseja permitir que os visitantes acessem sua rede.
Por exemplo, os visitantes de organizações parceiras podem ser autenticados por seu próprio servidor RADIUS
da organização parceira e, em seguida, usam uma conta de usuário do Windows em sua organização para
acessar uma rede local de convidado (LAN) em sua rede.
Outros atributos que fornecem funcionalidade especializada são:
MS-Quarantine-IPFilter e MS-Quarantine-Session-Timeout . Esses atributos são usados quando você
implanta o NAQC (controle de quarentena de acesso à rede) com a implantação de VPN de roteamento e
acesso remoto.
Passpor t-User-Mapping-UPN-sufixo . Esse atributo permite que você autentique solicitações de conexão
com as credenciais da conta de usuário do Windows Live™ ID.
Tunnel-Tag . Esse atributo designa o número de ID de VLAN para o qual a conexão deve ser atribuída pelo
NAS quando você implanta redes locais virtuais (VLANs).
Política de solicitação de conexão padrão
Uma política de solicitação de conexão padrão é criada quando você instala o NPS. Esta política tem a
configuração a seguir.
A autenticação não está configurada.
A contabilidade não está configurada para encaminhar informações de contabilidade para um grupo de
servidores RADIUS remotos.
O atributo não está configurado com regras de manipulação de atributos que encaminham solicitações de
conexão para grupos de servidores remotos RADIUS.
A solicitação de encaminhamento é configurada para que as solicitações de conexão sejam autenticadas e
autorizadas no NPS local.
Atributos avançados não estão configurados.
A política de solicitação de conexão padrão usa o NPS como um servidor RADIUS. Para configurar um servidor
que executa o NPS para atuar como um proxy RADIUS, você também deve configurar um grupo de servidores
remotos RADIUS. Você pode criar um novo grupo de servidores remotos RADIUS enquanto estiver criando uma
nova política de solicitação de conexão usando o assistente de nova política de solicitação de conexão. Você
pode excluir a política de solicitação de conexão padrão ou verificar se a política de solicitação de conexão
padrão é a última política processada pelo NPS, colocando-a por último na lista ordenada de políticas.
NOTE
se o NPS e o serviço de acesso remoto estiverem instalados no mesmo computador e o serviço de acesso remoto estiver
configurado para Windows autenticação e contabilização, é possível que as solicitações de autenticação e contabilização
de acesso remoto sejam encaminhadas para um servidor RADIUS. Isso pode ocorrer quando as solicitações de
autenticação e contabilização de acesso remoto correspondem a uma política de solicitação de conexão configurada para
encaminhá-las a um grupo de servidores remotos RADIUS.
Nomes de realm
13/08/2021 • 6 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para obter uma visão geral do uso de nomes de territórios no processamento de
solicitação de conexão do servidor de políticas de rede.
O User-Name atributo RADIUS é uma cadeia de caracteres que normalmente contém um local de conta de
usuário e um nome de conta de usuário. o local da conta de usuário também é chamado de realm ou nome
realm, e é sinônimo do conceito de domínio, incluindo domínios DNS, domínios de® Active Directory e
domínios Windows NT 4,0. Por exemplo, se uma conta de usuário estiver localizada no banco de dados de
contas de usuário para um domínio chamado example.com, example.com será o nome do realm.
Em outro exemplo, se o atributo RADIUS User-Name contiver o nome de usuário [email protected] , user1
será o nome da conta de usuário e example.com será o nome do realm. Os nomes de realm podem ser
apresentados no nome de usuário como um prefixo ou como um sufixo:
Example\user1 . Neste exemplo, o exemplo de nome de realm é um prefixo; e também é o nome de um
domínio de AD DS do Active Directory Domain ® Services ( ) .
[email protected] . Neste exemplo, o nome do Realm example.com é um sufixo; e é um nome de
domínio DNS ou o nome de um domínio AD DS.
Você pode usar nomes de território configurados em políticas de solicitação de conexão ao criar e implantar sua
infraestrutura RADIUS para garantir que as solicitações de conexão sejam roteadas de clientes RADIUS, também
chamadas de servidores de acesso à rede, para servidores RADIUS que podem autenticar e autorizar a
solicitação de conexão.
Quando o NPS é configurado como um servidor RADIUS com a política de solicitação de conexão padrão, o
NPS processa as solicitações de conexão para o domínio no qual o NPS é membro e para domínios confiáveis.
Para configurar o NPS para atuar como um proxy RADIUS e encaminhar solicitações de conexão para domínios
não confiáveis, você deve criar uma nova política de solicitação de conexão. Na nova política de solicitação de
conexão, você deve configurar o atributo de nome de usuário com o nome de realm que será contido no
atributo de User-Name de solicitações de conexão que você deseja encaminhar. Você também deve configurar a
política de solicitação de conexão com um grupo de servidores RADIUS remoto. A política de solicitação de
conexão permite que o NPS Calcule quais solicitações de conexão encaminhar para o grupo de servidores
remotos RADIUS com base na parte de realm do atributo User-Name.
Cau t i on
A edição incorreta do Registro pode danificar seriamente o sistema. Antes de alterar o Registro, faça backup de
todos os dados importantes do computador.
Alguns servidores de acesso à rede que não são da Microsoft excluem ou modificam o nome de domínio
conforme especificado pelo usuário. Como resultado, a solicitação de acesso à rede é autenticada no domínio
padrão, que pode não ser o domínio da conta do usuário. Para resolver esse problema, configure os servidores
RADIUS para alterar o nome de usuário para o formato correto com o nome de domínio preciso.
Grupos de servidores RADIUS remotos
11/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Ao configurar o NPS (servidor de diretivas de rede) como um proxy de serviço RADIUS (RADIUS), você usa o
NPS para encaminhar solicitações de conexão a servidores RADIUS que são capazes de processar as solicitações
de conexão, pois podem executar autenticação e autorização no domínio em que a conta de usuário ou
computador está localizada. Por exemplo, se você quiser encaminhar solicitações de conexão para um ou mais
servidores RADIUS em domínios não confiáveis, poderá configurar o NPS como um proxy RADIUS para
encaminhar as solicitações para os servidores remotos RADIUS no domínio não confiável.
NOTE
os grupos de servidores RADIUS remotos não estão relacionados a grupos de Windows e separados deles.
Para configurar o NPS como um proxy RADIUS, você deve criar uma política de solicitação de conexão que
contenha todas as informações necessárias para que o NPS avalie quais mensagens devem ser encaminhadas e
para onde enviar as mensagens.
Quando você configura um grupo de servidores remotos RADIUS no NPS e configura uma política de
solicitação de conexão com o grupo, você está designando o local onde o NPS é para encaminhar solicitações de
conexão.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para obter uma visão geral das políticas de rede no NPS.
NOTE
Além deste tópico, a seguinte documentação de política de rede está disponível.
Permissão de acesso
Configurar políticas de rede
As políticas de rede são conjuntos de condições, restrições e configurações que permitem designar quem está
autorizado a se conectar à rede e as circunstâncias sob as quais eles podem ou não se conectar.
No processamento das solicitações de conexão como um servidor RADIUS, o NPS executa a autenticação e a
autorização da solicitação de conexão. Durante o processo de autenticação, o NPS verifica a identidade do
usuário ou computador que está se conectando à rede. Durante o processo de autorização, o NPS determina se
o usuário ou o computador tem permissão para acessar a rede.
Para fazer essas determinações, o NPS usa políticas de rede que são configuradas no console do NPS. O NPS
também examina as propriedades de discagem da conta de usuário no Active Directory ® Domain Services (
AD DS ) para executar a autorização.
NOTE
Se desejar que o NPS avalie uma política de rede ao executar a autorização para solicitações de conexão, você deverá
configurar a configuração de estado da política marcando a caixa de seleção política habilitada.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
A permissão de acesso é configurada na guia Visão geral de cada política de rede no NPS (Servidor de Políticas
de Rede).
Essa configuração permite que você configure a política para conceder ou negar acesso aos usuários se as
condições e restrições da política de rede corresponderem à solicitação de conexão.
As configurações de permissão de acesso têm o seguinte efeito:
Conceda acesso a . O acesso será concedido se a solicitação de conexão corresponde às condições e
restrições configuradas na política.
Negar acesso . O acesso será negado se a solicitação de conexão corresponde às condições e restrições
configuradas na política.
A permissão de acesso também é concedida ou negada com base na configuração das propriedades discadas de
cada conta de usuário.
NOTE
As contas de usuário e suas propriedades, como propriedades discadas, são configuradas no snap-in usuários e grupos
locais do Usuários e Computadores do Active Directory Console de Gerenciamento Microsoft MMC, dependendo se você
tiver o ( Active Directory Domain Services ) ® (AD DS) instalado.
A configuração de Permissão de Acesso à Rede da conta de usuário , que está configurada nas propriedades
discadas de contas de usuário, substitui a configuração de permissão de acesso à política de rede. Quando a
permissão de acesso à rede em uma conta de usuário é definida como a opção Controlar o acesso por meio da
Política de Rede NPS, a configuração de permissão de acesso à política de rede determina se o usuário tem
acesso concedido ou negado.
NOTE
No Windows Server 2016, o valor padrão de Permissão de Acesso à Rede AD DS propriedades discadas da conta de
usuário é Controlar o acesso por meio da Política de Rede NPS.
Quando o NPS avalia as solicitações de conexão em relação às políticas de rede configuradas, ele executa as
seguintes ações:
Se as condições da primeira política não corresponderem, o NPS avaliará a próxima política e continuará
esse processo até que uma combinação seja encontrada ou todas as políticas tenham sido avaliadas quanto
a uma combinação.
Se as condições e restrições de uma política corresponderem, o NPS concederá ou negará acesso,
dependendo do valor da configuração de Permissão de Acesso na política.
Se as condições de uma política corresponderem, mas as restrições na política não corresponderem, o NPS
rejeitará a solicitação de conexão.
Se as condições de todas as políticas não corresponderem, o NPS rejeitará a solicitação de conexão.
Ignorar propriedades discadas da conta de usuário
Você pode configurar a política de rede NPS para ignorar as propriedades discadas de contas de usuário
selecionando ou des marcando a caixa de seleção Ignorar propriedades discadas da conta de usuário na guia
Visão geral de uma política de rede.
Normalmente, quando o NPS executa a autorização de uma solicitação de conexão, ele verifica as propriedades
discadas da conta de usuário, em que o valor da configuração de permissão de acesso à rede pode afetar se o
usuário está autorizado a se conectar à rede. Quando você configura o NPS para ignorar as propriedades
discadas de contas de usuário durante a autorização, as configurações de política de rede determinam se o
usuário recebe acesso à rede.
As propriedades discadas de contas de usuário contêm o seguinte:
Permissão de acesso à rede
Caller-ID
Opções de retorno de chamada
Endereço IP estático
Rotas estáticas
Para dar suporte a vários tipos de conexões para as quais o NPS fornece autenticação e autorização, pode ser
necessário desabilitar o processamento de propriedades discadas da conta de usuário. Isso pode ser feito para
dar suporte a cenários em que propriedades discadas específicas não são necessárias.
Por exemplo, as propriedades caller-ID, retorno de chamada, endereço IP estático e rotas estáticas são projetadas
para um cliente que está discando em um NAS do servidor de acesso à rede, não para clientes que estão se
conectando a pontos de acesso sem ( ) fio. Um ponto de acesso sem fio que recebe essas configurações em uma
mensagem RADIUS do NPS pode não ser capaz de processá-las, o que pode fazer com que o cliente sem fio seja
desconectado.
Quando o NPS fornece autenticação e autorização para usuários que estão discando e acessando a rede da sua
organização por meio de pontos de acesso sem fio, você deve configurar as propriedades discadas para dar
suporte a conexões discadas definindo propriedades discadas ou conexões sem fio, não definindo propriedades
( ) ( ) discadas.
Você pode usar o NPS para habilitar o processamento de propriedades discadas para a conta de usuário em
alguns cenários, como discagem e para desabilitar o processamento de propriedades discadas em outros
cenários, como sem fio ( ) ( 802.1X e comutamento de autenticação ) .
Você também pode usar Ignorar propriedades discadas da conta de usuário para gerenciar o controle de
acesso à rede por meio de grupos e a configuração de permissão de acesso na política de rede. Quando você
marca a caixa de seleção Ignorar propriedades discadas da conta de usuário, a permissão de acesso à
rede na conta de usuário é ignorada.
A única desvantagem dessa configuração é que você não pode usar as propriedades de discagem de conta de
usuário adicionais de caller-ID, retorno de chamada, endereço IP estático e rotas estáticas.
Para obter mais informações sobre o NPS, consulte Servidor de Políticas de Rede (NPS).
Modelos NPS
10/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
(Os modelos NPS do servidor ) de políticas de rede permitem que você crie elementos de configuração, como
serviço RADIUS ( ) clientes RADIUS ou segredos compartilhados, que você pode reutilizar no NPS local e
exportar para uso em outros NPSs.
Os modelos de NPS são projetados para reduzir a quantidade de tempo e o custo necessário para configurar o
NPS em um ou mais servidores. Os seguintes tipos de modelo de NPS estão disponíveis para configuração no
gerenciamento de modelos:
Segredos compartilhados
Clientes RADIUS
Servidores RADIUS remotos
Filtros de IP
Grupos de servidores de atualizações
Configurar um modelo é diferente de configurar diretamente o NPS. A criação de um modelo não afeta a
funcionalidade do NPS. Somente quando você seleciona o modelo no local apropriado no console do NPS, o
modelo afeta a funcionalidade do NPS.
Por exemplo, se você configurar um cliente RADIUS no console do NPS em clientes e servidores RADIUS, você
alterou a configuração do NPS e fez uma etapa na configuração do NPS para se comunicar com um dos seus
servidores de acesso à rede ( nas ) . (A próxima etapa seria configurar o NAS para se comunicar com o NPS. )
No entanto, se você configurar um novo modelo de clientes RADIUS no console do NPS em Gerenciamento
de modelos , em vez de criar um novo cliente RADIUS em clientes e ser vidores RADIUS , você criou um
modelo, mas ainda não alterou a funcionalidade do NPS. Para alterar a funcionalidade do NPS, você deve
selecionar o modelo do local correto no console do NPS.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Um nas do servidor de acesso à rede ( ) é um dispositivo que fornece algum nível de acesso a uma rede maior.
Um NAS que usa uma infraestrutura RADIUS também é um cliente RADIUS, enviando solicitações de conexão e
mensagens de contabilização para um servidor RADIUS para autenticação, autorização e contabilidade.
NOTE
Computadores cliente, como computadores laptop e outros computadores que executam sistemas operacionais cliente,
não são clientes RADIUS. Os clientes RADIUS são servidores de acesso à rede, como pontos de acesso sem fio,
comutadores de autenticação 802.1 X, servidores VPN de rede privada virtual ( ) e servidores dial-up, pois usam o
protocolo RADIUS para se comunicar com servidores RADIUS, como servidores NPS de servidor de políticas de rede ( ) .
Para implantar o NPS como um servidor RADIUS ou um proxy RADIUS, você deve configurar clientes RADIUS
no NPS.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
Planejar Servidor de Políticas de Rede
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este tópico fornece links para informações sobre como planejar implantações de NPS e proxy.
NOTE
Para obter documentação adicional do Servidor de Políticas de Rede, você pode usar as seções de biblioteca a seguir.
Introdução ao Servidor de Políticas de Rede
Implantar o Servidor de Políticas de Rede
Gerenciar o Servidor de Políticas de Rede
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Quando você implanta o NPS do servidor de políticas de rede ( ) como um servidor serviço RADIUS (RADIUS), o
NPS executa autenticação, autorização e contabilização de solicitações de conexão para o domínio local e para
domínios que confiam no domínio local. Você pode usar essas diretrizes de planejamento para simplificar a
implantação do RADIUS.
Essas diretrizes de planejamento não incluem circunstâncias nas quais você deseja implantar o NPS como um
proxy RADIUS. Quando você implanta o NPS como um proxy RADIUS, o NPS encaminha as solicitações de
conexão para um servidor que executa o NPS ou outros servidores RADIUS em domínios remotos, domínios
não confiáveis ou ambos.
Antes de implantar o NPS como um servidor RADIUS em sua rede, use as diretrizes a seguir para planejar sua
implantação.
Planejar a configuração do NPS.
Planejar clientes RADIUS.
Planeje o uso de métodos de autenticação.
Planejar políticas de rede.
Planejar a contabilidade do NPS.
IMPORTANT
Clientes de acesso, como computadores cliente, não são clientes RADIUS. Somente os servidores de acesso à rede e os
servidores proxy que dão suporte ao protocolo RADIUS são clientes RADIUS.
Além disso, os pontos de acesso sem fio e os comutadores devem ser compatíveis com a autenticação 802.1 X.
Se você quiser implantar o protocolo ( EAP ) ou ( PEAP ) , os pontos de acesso e os comutadores de autenticação
extensíveis devem oferecer suporte ao uso do EAP.
Para testar a interoperabilidade básica para conexões PPP para pontos de acesso sem fio, configure o ponto de
acesso e o cliente de acesso para usar o protocolo de autenticação de senha (PAP). Use protocolos de
autenticação adicionais baseados em PPP, como o PEAP, até que você tenha testado aqueles que pretende usar
para acesso à rede.
Principais etapas
Durante o planejamento para clientes RADIUS, você pode usar as etapas a seguir.
Documente os atributos específicos do fornecedor (VSAs) que você deve configurar no NPS. Se os
servidores de acesso à rede exigirem VSAs, registre as informações de VSA para uso posterior ao
configurar as políticas de rede no NPS.
Documente os endereços IP de clientes RADIUS e seu NPS para simplificar a configuração de todos os
dispositivos. Ao implantar seus clientes RADIUS, você deve configurá-los para usar o protocolo RADIUS,
com o endereço IP do NPS inserido como o servidor de autenticação. E, ao configurar o NPS para se
comunicar com seus clientes RADIUS, você deve inserir os endereços IP do cliente RADIUS no snap-in do
NPS.
Crie segredos compartilhados para configuração nos clientes RADIUS e no snap-in do NPS. Você deve
configurar clientes RADIUS com um segredo compartilhado, ou senha, que também será inserido no
snap-in do NPS ao configurar clientes RADIUS no NPS.
Planejar o uso de métodos de autenticação
O NPS dá suporte a métodos de autenticação baseados em senha e em certificado. No entanto, nem todos os
servidores de acesso à rede oferecem suporte aos mesmos métodos de autenticação. Em alguns casos, talvez
você queira implantar um método de autenticação diferente com base no tipo de acesso à rede.
Por exemplo, você pode desejar implantar o acesso sem fio e VPN para sua organização, mas usar um método
de autenticação diferente para cada tipo de acesso: EAP-TLS para conexões VPN, devido à segurança forte que o
EAP com segurança de camada de transporte (EAP-TLS) fornece e PEAP-MS-CHAP v2 para conexões sem fio
802.1 X.
O PEAP com o protocolo de autenticação de handshake de desafio da Microsoft versão 2 (PEAP-MS-CHAP v2)
fornece um recurso chamado reconexão rápida que é projetado especificamente para uso com computadores
portáteis e outros dispositivos sem fio. A reconexão rápida permite que os clientes sem fio se movam entre
pontos de acesso sem fio na mesma rede sem serem autenticados sempre que eles se associam a um novo
ponto de acesso. Isso fornece uma experiência melhor para usuários sem fio e permite que eles se movam entre
pontos de acesso sem precisar digitar novamente suas credenciais. Devido à reconexão rápida e à segurança
fornecida pelo PEAP-MS-CHAP v2, o PEAP-MS-CHAP v2 é uma opção lógica como um método de autenticação
para conexões sem fio.
Para conexões VPN, o EAP-TLS é um método de autenticação baseado em certificado que fornece segurança
forte que protege o tráfego de rede mesmo quando ele é transmitido pela Internet de computadores
domésticos ou móveis para os servidores VPN da sua organização.
Métodos de autenticação baseados em certificado
Os métodos de autenticação baseados em certificado têm a vantagem de fornecer forte segurança; e eles têm a
desvantagem de serem mais difíceis de implantar do que os métodos de autenticação baseados em senha.
O PEAP-MS-CHAP v2 e o EAP-TLS são métodos de autenticação baseados em certificado, mas há muitas
diferenças entre eles e a maneira como eles são implantados.
EAP-TLS
O EAP-TLS usa certificados para autenticação de cliente e de servidor e requer que você implante uma
infraestrutura de chave pública (PKI) em sua organização. A implantação de uma PKI pode ser complexa e
requer uma fase de planejamento que seja independente do planejamento para o uso do NPS como um
servidor RADIUS.
Com o EAP-TLS, o NPS registra um certificado de servidor de uma AC de autoridade de certificação ( ) e o
certificado é salvo no computador local no repositório de certificados. Durante o processo de autenticação, a
autenticação do servidor ocorre quando o NPS envia seu certificado de servidor ao cliente de acesso para
provar sua identidade para o cliente de acesso. O cliente de acesso examina várias propriedades de certificado
para determinar se o certificado é válido e é apropriado para uso durante a autenticação do servidor. Se o
certificado do servidor atender aos requisitos mínimos de certificado do servidor e for emitido por uma AC que
o cliente de acesso confia, o NPS será autenticado com êxito pelo cliente.
Da mesma forma, a autenticação de cliente ocorre durante o processo de autenticação quando o cliente envia
seu certificado de cliente para o NPS para provar sua identidade para o NPS. O NPS examina o certificado e, se
o certificado do cliente atender aos requisitos mínimos de certificado do cliente e for emitido por uma
autoridade de certificação que o NPS confia, o cliente de acesso será autenticado com êxito pelo NPS.
Embora seja necessário que o certificado do servidor seja armazenado no repositório de certificados no NPS, o
cliente ou o certificado do usuário podem ser armazenados no repositório de certificados no cliente ou em um
cartão inteligente.
Para que esse processo de autenticação seja bem sucedido, é necessário que todos os computadores tenham o
certificado de autoridade de certificação de sua organização no repositório de certificados das autoridades
confiáveis para o computador local e o usuário atual.
PEAP-MS -CHAP v2
O PEAP-MS-CHAP v2 usa um certificado para autenticação de servidor e credenciais baseadas em senha para
autenticação de usuário. Como os certificados são usados apenas para autenticação de servidor, não é
necessário implantar uma PKI para usar o PEAP-MS-CHAP v2. Ao implantar o PEAP-MS-CHAP v2, você pode
obter um certificado de servidor para o NPS de uma das duas maneiras a seguir:
Você pode instalar Active Directory serviços de certificados (AD CS) e, em seguida, registrar certificados
automaticamente no NPSs. Se você usar esse método, também deverá registrar o certificado de
autoridade de certificação nos computadores cliente que se conectam à sua rede para que eles confiem
no certificado emitido para o NPS.
Você pode comprar um certificado de servidor de uma CA pública, como a VeriSign. Se você usar esse
método, certifique-se de selecionar uma autoridade de certificação que já seja confiável em
computadores cliente. Para determinar se os computadores cliente confiam em uma autoridade de
certificação, abra o snap-in do MMC (console de gerenciamento Microsoft) de certificados em um
computador cliente e, em seguida, exiba o repositório de autoridades de certificação raiz confiáveis para
o computador local e para o usuário atual. Se houver um certificado da autoridade de certificação nesses
repositórios de certificados, o computador cliente confiará na autoridade de certificação e, portanto,
confiará em qualquer certificado emitido pela autoridade de certificação.
Durante o processo de autenticação com PEAP-MS-CHAP v2, a autenticação do servidor ocorre quando o NPS
envia seu certificado do servidor para o computador cliente. O cliente de acesso examina várias propriedades de
certificado para determinar se o certificado é válido e é apropriado para uso durante a autenticação do servidor.
Se o certificado do servidor atender aos requisitos mínimos de certificado do servidor e for emitido por uma AC
que o cliente de acesso confia, o NPS será autenticado com êxito pelo cliente.
A autenticação de usuário ocorre quando um usuário tenta se conectar à rede digita credenciais baseadas em
senha e tenta fazer logon. O NPS recebe as credenciais e executa a autenticação e a autorização. Se o usuário for
autenticado e autorizado com êxito e se o computador cliente tiver autenticado com êxito o NPS, a solicitação de
conexão será concedida.
Principais etapas
Durante o planejamento para o uso de métodos de autenticação, você pode usar as etapas a seguir.
Identifique os tipos de acesso à rede que você planeja oferecer, como sem fio, VPN, comutador com
capacidade 802.1 X e acesso dial-up.
Determine o método de autenticação ou os métodos que você deseja usar para cada tipo de acesso. É
recomendável que você use os métodos de autenticação baseados em certificado que fornecem
segurança forte; no entanto, talvez não seja prático implantar uma PKI, para que outros métodos de
autenticação possam fornecer um equilíbrio melhor do que você precisa para sua rede.
Se você estiver implantando o EAP-TLS, planeje sua implantação de PKI. Isso inclui o planejamento dos
modelos de certificado que você usará para certificados de servidor e certificados de computador cliente.
Ele também inclui determinar como registrar certificados em computadores membros do domínio e não
membros do domínio e determinar se você deseja usar cartões inteligentes.
Se você estiver implantando PEAP-MS-CHAP v2, determine se deseja instalar o AD CS para emitir
certificados de servidor para seus NPSs ou se deseja comprar certificados de servidor de uma AC
pública, como VeriSign.
Planejar políticas de rede
As políticas de rede são usadas pelo NPS para determinar se as solicitações de conexão recebidas de clientes
RADIUS estão autorizadas. O NPS também usa as propriedades discadas da conta de usuário para fazer uma
determinação de autorização.
Como as políticas de rede são processadas na ordem em que aparecem no snap-in nps, planeje colocar suas
políticas mais restritivas primeiro na lista de políticas. Para cada solicitação de conexão, o NPS tenta
corresponder as condições da política com as propriedades da solicitação de conexão. O NPS examina cada
política de rede na ordem até encontrar uma combinação. Se ele não encontrar uma combinação, a solicitação
de conexão será rejeitada.
Etapas principais
Durante o planejamento de políticas de rede, você pode usar as etapas a seguir.
Determine a ordem de processamento do NPS preferencial das políticas de rede, da mais restritiva à
menos restritiva.
Determine o estado da política. O estado da política pode ter o valor de habilitado ou desabilitado. Se a
política estiver habilitada, o NPS avaliará a política durante a execução da autorização. Se a política não
estiver habilitada, ela não será avaliada.
Determine o tipo de política. Você deve determinar se a política foi projetada para conceder acesso
quando as condições da política são corresponderes pela solicitação de conexão ou se a política foi
projetada para negar acesso quando as condições da política são corresponderem pela solicitação de
conexão. Por exemplo, se você quiser negar explicitamente o acesso sem fio aos membros de um grupo
Windows, poderá criar uma política de rede que especifique o grupo, o método de conexão sem fio e que
tenha uma configuração de tipo de política negar acesso.
Determine se você deseja que o NPS ignore as propriedades discadas de contas de usuário que são
membros do grupo no qual a política se baseia. Quando essa configuração não está habilitada, as
propriedades discadas das contas de usuário substituem as configurações configuradas nas políticas de
rede. Por exemplo, se uma política de rede estiver configurada que concede acesso a um usuário, mas as
propriedades discadas da conta de usuário para esse usuário estão definidas para negar o acesso, o
usuário terá o acesso negado. Mas se você habilitar a configuração de tipo de política Ignorar
propriedades discadas da conta de usuário, o mesmo usuário terá acesso à rede.
Determine se a política usa a configuração de origem da política. Essa configuração permite que você
especifique facilmente uma origem para todas as solicitações de acesso. As fontes possíveis são um
Gateway de Serviços de Terminal (Gateway de TS), um servidor de acesso remoto (VPN ou discagem),
um servidor DHCP, um ponto de acesso sem fio e um servidor da Autoridade de Registro de Saúde.
Como alternativa, você pode especificar uma fonte específica do fornecedor.
Determine as condições que devem ser corresponder para que a política de rede seja aplicada.
Determine as configurações aplicadas se as condições da política de rede corresponderem à solicitação
de conexão.
Determine se você deseja usar, modificar ou excluir as políticas de rede padrão.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Quando você implanta o NPS (Servidor de Políticas de Rede) como um proxy RADIUS do Remote Authentication
Dial-In User Service, o NPS recebe solicitações de conexão de clientes RADIUS, como servidores de acesso à
rede ou outros ( proxies RADIUS, e, em seguida, encaminha essas solicitações de conexão para servidores que
executam NPS ou outros ) servidores RADIUS. Você pode usar essas diretrizes de planejamento para simplificar
sua implantação radius.
Essas diretrizes de planejamento não incluem circunstâncias nas quais você deseja implantar o NPS como um
servidor RADIUS. Quando você implanta o NPS como um servidor RADIUS, o NPS executa autenticação,
autorização e contabilização para solicitações de conexão para o domínio local e para domínios que confiam no
domínio local.
Antes de implantar o NPS como um proxy RADIUS em sua rede, use as diretrizes a seguir para planejar sua
implantação.
Planejar a configuração do NPS.
Planejar clientes RADIUS.
Planejar grupos de servidores RADIUS remotos.
Planejar regras de manipulação de atributo para encaminhamento de mensagens.
Planejar políticas de solicitação de conexão.
Planejar a contabilidade do NPS.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para obter informações sobre como implantar o servidor de políticas de rede.
NOTE
Para obter a documentação adicional do servidor de políticas de rede, você pode usar as seções de biblioteca a seguir.
Introdução ao Servidor de Políticas de Rede
Planejar Servidor de Políticas de Rede
Gerenciar o Servidor de Políticas de Rede
o guia de rede do Windows Server 2016 Core inclui uma seção sobre como planejar e instalar o nps do servidor
de políticas de rede ( ) , e as tecnologias apresentadas no guia servem como pré-requisitos para implantar o
NPS em um domínio de Active Directory. para obter mais informações, consulte a seção "implantar NPS1" no
guia de rededo Windows Server 2016 Core.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar os tópicos desta seção para gerenciar o servidor de políticas de rede.
NOTE
Para obter a documentação adicional do servidor de políticas de rede, você pode usar as seções de biblioteca a seguir.
Introdução ao Servidor de Políticas de Rede
Planejar Servidor de Políticas de Rede
Implantar o Servidor de Políticas de Rede
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para saber mais sobre as ferramentas que podem ser usadas para gerenciar seus
NPSs.
Depois de instalar o NPS, você pode administrar NPSs:
Localmente, usando o snap-in nps Console de Gerenciamento Microsoft MMC, o console NPS estático em
Ferramentas Administrativas, Windows PowerShell comandos ou os comandos Netsh do Shell de Rede para
( ) ( ) NPS.
Em um NPS remoto, usando o snap-in do NPS MMC, os comandos Netsh para NPS, os comandos Windows
PowerShell para NPS ou Conexão de Área de Trabalho Remota.
Em uma estação de trabalho remota, usando Conexão de Área de Trabalho Remota em combinação com
outras ferramentas, como o NPS MMC ou Windows PowerShell.
NOTE
No Windows Server 2016, você pode gerenciar o NPS local usando o console do NPS. Para gerenciar NPSs remotos e
locais, você deve usar o snap-in do NPS - MMC.
As seções a seguir fornecem instruções sobre como gerenciar seus NPSs locais e remotos.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para criar e configurar políticas de solicitação de conexão que designam se o NPS
local processa solicitações de conexão ou as encaminha para o servidor RADIUS remoto para processamento.
As políticas de solicitação de conexão são conjuntos de condições e configurações que permitem que os
administradores de rede designem quais servidores Remote Authentication Dial-In User Service (RADIUS)
executam a autenticação e a autorização de solicitações de conexão que o servidor que executa o NPS do
Servidor de Políticas de Rede recebe de clientes ( ) RADIUS.
A política de solicitação de conexão padrão usa NPS como um servidor RADIUS e processa todas as solicitações
de autenticação localmente.
Para configurar um servidor que executa o NPS para atuar como um proxy RADIUS e encaminhar solicitações
de conexão para outros servidores NPS ou RADIUS, você deve configurar um grupo de servidores RADIUS
remoto, além de adicionar uma nova política de solicitação de conexão que especifica condições e configurações
que as solicitações de conexão devem corresponder.
Você pode criar um novo grupo de servidores RADIUS remoto enquanto cria uma nova política de solicitação de
conexão com o Assistente para Nova Política de Solicitação de Conexão.
Se você não quiser que o NPS atue como um servidor RADIUS e processe solicitações de conexão localmente,
exclua a política de solicitação de conexão padrão.
Se você quiser que o NPS atue como um servidor RADIUS, processando solicitações de conexão localmente e
como um proxy RADIUS, encaminhando algumas solicitações de conexão para um grupo de servidores RADIUS
remoto, adicione uma nova política usando o procedimento a seguir e verifique se a política de solicitação de
conexão padrão é a última política processada colocando-a por último na lista de políticas.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Os firewalls podem ser configurados para permitir ou bloquear tipos de tráfego IP de e para o computador ou
dispositivo no qual o firewall está sendo executado. Se os firewalls não estiverem configurados corretamente
para permitir o tráfego RADIUS entre clientes RADIUS, proxies RADIUS e servidores RADIUS, a autenticação de
acesso à rede poderá falhar, impedindo que os usuários acessem recursos de rede.
Talvez seja necessário configurar dois tipos de firewalls para permitir o tráfego RADIUS:
Windows Defender Firewall com segurança avançada no servidor local que executa o servidor de diretivas
de rede (NPS).
Firewalls em execução em outros computadores ou dispositivos de hardware.
Outros firewalls
Na configuração mais comum, o firewall está conectado à Internet e o NPS é um recurso de intranet que está
conectado à rede de perímetro.
Para acessar o controlador de domínio na intranet, o NPS pode ter:
Uma interface na rede de perímetro e uma interface na intranet (o roteamento de IP não está habilitado).
Uma única interface na rede de perímetro. Nessa configuração, o NPS se comunica com os controladores de
domínio por meio de outro firewall que conecta a rede de perímetro à intranet.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para configurar políticas de rede no NPS.
NOTE
Computadores cliente, como computadores laptop e outros computadores que executam sistemas operacionais cliente,
não são clientes RADIUS. Os clientes RADIUS são servidores de acesso à rede — como pontos de acesso sem fio,
comutadores de autenticação 802.1 X, servidores VPN de rede privada virtual ( ) e servidores dial-up — porque esses
dispositivos usam o protocolo RADIUS para se comunicar com servidores RADIUS, como NPSs.
Este procedimento explica como abrir o novo assistente de conexões de rede virtual privada ou dial-up no NPS.
Depois de executar o assistente, as seguintes políticas são criadas:
Uma política de solicitação de conexão
Uma política de rede
Você pode executar o novo assistente de conexões de rede virtual privada ou dial-up toda vez que precisar criar
novas políticas para servidores de conexão discada e servidores VPN.
A execução do novo assistente de conexões de rede virtual privada ou dial-up não é a única etapa necessária
para implantar servidores VPN ou discadas como clientes RADIUS para o NPS. Os dois métodos de acesso à
rede exigem que você implante componentes de hardware e software adicionais.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Para criar políticas para dial-up ou VPN com um assistente
1. Abra o console do NPS. Se ainda não estiver selecionado, clique em NPS ( local ) . Se você quiser criar
políticas em um NPS remoto, selecione o servidor.
2. Em introdução e configuração padrão , selecione ser vidor RADIUS para conexões dial-up ou
VPN . O texto e os links sob o texto são alterados para refletir sua seleção.
3. Clique em Configurar VPN ou dial-up com um assistente . O novo assistente para conexão discada
ou rede virtual privada é aberto.
4. Siga as instruções no Assistente para concluir a criação de suas novas políticas.
Criar políticas de rede para 802.1 X com ou sem fio com um assistente
Você pode usar este procedimento para criar a política de solicitação de conexão e a política de rede que são
necessárias para implantar comutadores de autenticação 802.1 X ou pontos de acesso sem fio 802.1 X como
clientes RADIUS (serviço RADIUS) para o servidor RADIUS NPS.
Este procedimento explica como iniciar o novo assistente de conexões sem fio e com fio IEEE 802.1 X seguro no
NPS.
Depois de executar o assistente, as seguintes políticas são criadas:
Uma política de solicitação de conexão
Uma política de rede
Você pode executar o novo assistente de conexões com fio e sem fio IEEE 802.1 X seguras toda vez que precisar
criar novas políticas para acesso 802.1 X.
A execução do novo assistente de conexões com e sem fio IEEE 802.1 X seguro não é a única etapa necessária
para implantar comutadores de autenticação 802.1 X e pontos de acesso sem fio como clientes RADIUS para o
NPS. Os dois métodos de acesso à rede exigem que você implante componentes de hardware e software
adicionais.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Para criar políticas para 802.1 X com ou sem fio com um assistente
1. No NPS, em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em ser vidor de
políticas de rede . O console do NPS é aberto.
2. Se ainda não estiver selecionado, clique em NPS ( local ) . Se você quiser criar políticas em um NPS
remoto, selecione o servidor.
3. Em introdução e configuração padrão , selecione ser vidor RADIUS para conexões 802.1 x sem
fio ou com fio . O texto e os links sob o texto são alterados para refletir sua seleção.
4. Clique em Configurar 802.1 x usando um assistente . O novo assistente de conexões com e sem fio
IEEE 802.1 X seguro é aberto.
5. Siga as instruções no Assistente para concluir a criação de suas novas políticas.
NOTE
O NPS formatará os dados de contabilidade como um documento XML que ele envia para o report_event armazenado no
banco de dados SQL Server que você designa no NPS. Para SQL Server registro em log funcione corretamente, você deve
ter um procedimento armazenado chamado repor t_event no banco de dados SQL Server que possa receber e analisar
os documentos XML do NPS.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Para configurar o SQL Server registro em log no NPS
1. Abra o console nps ou o snap-in Console de Gerenciamento Microsoft NPS (MMC).
2. Na árvore de console, clique em Contabilidade .
3. No painel de detalhes, em Propriedades SQL Server registro em log, clique em Alterar SQL Ser ver
propriedades de log. A caixa de SQL Ser ver propriedades de registro em log é aberta.
4. Em Registrar as seguintes informações, selecione as informações que você deseja registrar:
Para registrar todas as solicitações de contabilidade, clique em Solicitações de contabilidade .
Para registrar solicitações de autenticação, clique em Solicitações de autenticação .
Para registrar o status de contabilidade periódico, clique em Status de contabilidade periódica .
Para registrar o status periódico, como solicitações de contabilidade provisórios, clique em Status
periódico.
5. Para configurar o número de sessões simultâneas permitidas entre o servidor que executa o NPS e o SQL
Server, digite um número em Número máximo de sessões simultâneas.
6. Para configurar a fonte SQL Server dados, no log SQL Ser ver, clique em Configurar . A caixa de diálogo
Propriedades do Link de Dados é aberta. Na guia Conexão, especifique o seguinte:
Para especificar o nome do servidor no qual o banco de dados está armazenado, digite ou selecione
um nome em Selecionar ou insira um nome de ser vidor .
Para especificar o método de autenticação com o qual fazer logoff no servidor, clique em Usar
Windows NT segurança integrada. Ou clique em Usar um nome de usuário e senha específicos
e digite credenciais em Nome de usuário e Senha .
Para permitir uma senha em branco, clique em Senha em branco.
Para armazenar a senha, clique em Permitir salvar senha.
Para especificar a qual banco de dados se conectar no computador que executa SQL Server, clique em
Selecionar o banco de dados no servidor e selecione um nome de banco de dados na lista.
7. Para testar a conexão entre NPS e SQL Server, clique em Testar Conexão . Clique em OK para fechar
Propriedades do Link de Dados .
8. Em Ação de falha de registro em log, selecione Habilitar registro em log do arquivo de texto para failover
se quiser que o NPS continue com o registro em log do arquivo de texto se SQL Server registro em log
falhar.
9. Em Ação de falha de registro em log , selecione Se o registro em log falhar, descarte as solicitações de
conexão se você quiser que o NPS pare o processamento Access-Request mensagens quando os arquivos de
log estão completos ou não disponíveis por algum motivo. Se você quiser que o NPS continue processando
solicitações de conexão se o registro em log falhar, não marque essa caixa de seleção.
a edição incorreta do Registro pode danificar gravemente o sistema. Antes de alterar o Registro, faça backup de
todos os dados importantes do computador.
Para adicionar o nome de usuário ping ao Registro
O nome de usuário ping pode ser adicionado à seguinte chave do Registro como um valor de cadeia de
caracteres por um membro do grupo Administradores local:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IAS\Parameters
TIP
Para indicar mais de um nome de usuário para um valor de nome de usuário ping, insira um padrão de nome, como
um nome DNS, incluindo caracteres curinga, em Dados .
Configurar clientes RADIUS
13/08/2021 • 6 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para configurar servidores de acesso à rede como clientes RADIUS no NPS.
Ao adicionar um novo servidor VPN do servidor de acesso à rede ( , ponto de acesso sem fio, comutador de
autenticação ou servidor dial-up ) à sua rede, você deve adicionar o servidor como um cliente RADIUS no NPS
e, em seguida, configurar o cliente RADIUS para se comunicar com o NPS.
IMPORTANT
Os computadores e dispositivos cliente, como computadores laptop, tablets, telefones e outros computadores que
executam sistemas operacionais cliente, não são clientes RADIUS. Os clientes RADIUS são servidores de acesso à rede,
como pontos de acesso sem fio, comutadores compatíveis com 802.1 X, servidores de rede virtual privada (VPN) e
servidores dial-up, porque eles usam o protocolo RADIUS para se comunicar com servidores RADIUS, como servidores
NPS de servidor de políticas de rede ( ) .
Essa etapa também é necessária quando o NPS é membro de um grupo de servidores RADIUS remotos
configurado em um proxy NPS. Nessa circunstância, além de executar as etapas nesta tarefa no proxy NPS, você
deve fazer o seguinte:
No proxy NPS, configure um grupo de servidores RADIUS remoto que contenha o NPS.
No NPS remoto, configure o proxy NPS como um cliente RADIUS.
Para executar os procedimentos deste tópico, você deve ter pelo menos um servidor VPN do servidor de acesso
à rede ( , ponto de acesso sem fio, comutador de autenticação ou servidor de conexão discada ) ou proxy do
NPS fisicamente instalado em sua rede.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para configurar grupos de servidores remotos RADIUS quando desejar configurar o
NPS para atuar como um servidor proxy e encaminhar solicitações de conexão para outros NPSs para
processamento.
NOTE
Você também pode configurar um novo grupo de servidores remotos RADIUS durante o processo de criação de uma
nova política de solicitação de conexão.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Para adicionar um grupo de servidores RADIUS remotos
1. Em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em ser vidor de políticas de
rede para abrir o console do NPS.
2. Na árvore de console, clique duas vezes em clientes e ser vidores RADIUS , clique com o botão direito do
mouse em grupos de ser vidores RADIUS remotos e clique em novo .
3. A caixa de diálogo novo grupo de ser vidores remotos RADIUS é aberta. Em nome do grupo , digite
um nome para o grupo de servidores remotos RADIUS.
4. Em ser vidores RADIUS , clique em Adicionar . A caixa de diálogo adicionar ser vidores RADIUS é
aberta. Digite o endereço IP do servidor RADIUS que você deseja adicionar ao grupo ou digite o FQDN do
nome de domínio totalmente qualificado ( ) do servidor RADIUS e, em seguida, clique em verificar .
5. Em adicionar ser vidores RADIUS , clique na guia Autenticação/Contabilização . Em segredo
compar tilhado e confirmar segredo compar tilhado , digite o segredo compartilhado. Você deve usar o
mesmo segredo compartilhado ao configurar o computador local como um cliente RADIUS no servidor
RADIUS remoto.
6. Se você não estiver usando o protocolo EAP para autenticação, clique em solicitar deve conter o atributo
autenticador de mensagem . O EAP usa o atributo Message-Authenticator por padrão.
7. Verifique se os números de porta de autenticação e contabilização estão corretos para sua implantação.
8. Se você usar um segredo compartilhado diferente para contabilidade, em contabilidade , desmarque a caixa
de seleção usar o mesmo segredo compar tilhado para autenticação e contabilização e, em seguida,
digite o segredo compartilhado de contabilidade em segredo compar tilhado e confirme segredo
compar tilhado .
9. Se você não quiser encaminhar mensagens de início e parada do servidor de acesso à rede para o servidor
RADIUS remoto, desmarque a caixa de seleção encaminhar notificações do ser vidor de acesso à rede
para este ser vidor .
Para obter mais informações sobre como gerenciar o NPS, consulte gerenciar o servidor de políticas de rede.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
Gerenciar certificados usados com NPS
12/08/2021 • 7 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
IMPORTANT
Esse procedimento deve ser executado em um NPS, não em um computador cliente.
IMPORTANT
Esse procedimento deve ser executado em um NPS, não em um computador cliente.
Para configurar o tempo de expiração do identificador TLS em NPSs
1. Em um NPS, abra o editor do registro.
2. Navegue até a chave do registro HKEY _ local _
MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL
3. No menu Editar , clique em novo e em chave .
4. Digite Ser verCacheTime e pressione Enter.
5. Clique com o botão direito do mouse em Ser verCacheTime , clique em novo e em valor DWORD (32
bits) .
6. Digite o período de tempo, em milissegundos, que você deseja que o NPSs armazene em cache o
identificador TLS de um computador cliente após a primeira tentativa de autenticação bem-sucedida pelo
cliente.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Todos os certificados que são usados para autenticação de acesso à rede com - segurança de camada de
transporte ( EAP TLS, segurança de protocolo de autenticação - ) extensível protegidas - ( PEAP - TLS ) e PEAP -
Microsoft Challenge Handshake Authentication Protocol versão 2 ( MS - CHAP v2 ) devem atender aos
requisitos para certificados X. 509 e trabalhar para conexões que usam SSL/TLS (camada de soquete
seguro/segurança em nível de transporte). Os certificados de cliente e de servidor têm requisitos adicionais.
IMPORTANT
Este tópico fornece instruções para configurar modelos de certificado. Para usar essas instruções, é necessário que você
tenha implantado sua própria PKI de infraestrutura de chave pública ( ) com Active Directory serviços de certificados ( AD
CS ) .
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
NOTE
Para obter documentação adicional do Servidor de Políticas de Rede, você pode usar as seções de biblioteca a seguir.
Introdução ao Servidor de Políticas de Rede
Implantar o Servidor de Políticas de Rede
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para configurar um NPS com vários adaptadores de rede.
Ao usar vários adaptadores de rede em um servidor que executa o NPS (servidor de diretivas de rede), você
pode configurar o seguinte:
Os adaptadores de rede que fazem e não enviam e recebem serviço RADIUS ( ) tráfego RADIUS.
Em uma base de adaptador por rede, se o NPS monitora o tráfego RADIUS no protocolo IP versão 4 ( IPv4 ) ,
IPv6 ou IPv4 e IPv6.
Os números de porta UDP sobre os quais o tráfego RADIUS é enviado e recebido por protocolo ( IPv4 ou
IPv6 ) , por adaptador de rede.
Por padrão, o NPS escuta o tráfego RADIUS nas portas 1812, 1813, 1645 e 1646 para IPv6 e IPv4 para todos os
adaptadores de rede instalados. Como o NPS usa automaticamente todos os adaptadores de rede para o
tráfego RADIUS, você só precisa especificar os adaptadores de rede que deseja que o NPS use para o tráfego
RADIUS quando desejar impedir que o NPS utilize um adaptador de rede específico.
NOTE
Se você desinstalar o IPv4 ou IPv6 em um adaptador de rede, o NPS não monitorará o tráfego RADIUS para o protocolo
desinstalado.
Em um NPS com vários adaptadores de rede instalados, talvez você queira configurar o NPS para enviar e
receber o tráfego RADIUS somente nos adaptadores que você especificar.
Por exemplo, um adaptador de rede instalado no NPS pode levar a um segmento de rede que não contém
clientes RADIUS, enquanto um segundo adaptador de rede fornece ao NPS um caminho de rede para seus
clientes RADIUS configurados. Nesse cenário, é importante direcionar o NPS a usar o segundo adaptador de
rede para todo o tráfego RADIUS.
Em outro exemplo, se o NPS tiver três adaptadores de rede instalados, mas você quiser que o NPS use dois dos
adaptadores para o tráfego RADIUS, você poderá configurar informações de porta somente para os dois
adaptadores. Ao excluir a configuração de porta para o terceiro adaptador, você impede que o NPS use o
adaptador para o tráfego RADIUS.
IMPORTANT
Se você não usar os números de porta RADIUS padrão, deverá configurar exceções no firewall para o computador local
para permitir o tráfego RADIUS nas novas portas. Para obter mais informações, consulte Configurar firewalls para tráfego
RADIUS.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar o procedimento a seguir para configurar as portas que o servidor de diretivas de rede (NPS) usa
para serviço RADIUS ( ) tráfego de estatísticas e autenticação RADIUS.
Por padrão, o NPS escuta o tráfego RADIUS nas portas 1812, 1813, 1645 e 1646 para o protocolo IP versão 6 (
IPv6 ) e IPv4 para todos os adaptadores de rede instalados.
NOTE
Se você desinstalar o IPv4 ou IPv6 em um adaptador de rede, o NPS não monitorará o tráfego RADIUS para o protocolo
desinstalado.
Os valores de porta de 1812 para autenticação e 1813 para contabilidade são portas RADIUS padrão definidas
pelo Internet Engineering Task Force ( IETF ) nas RFCs 2865 e 2866. No entanto, por padrão, muitos servidores
de acesso usam as portas 1645 para solicitações de autenticação e 1646 para solicitações de contabilização.
Não importa quais números de porta você decidir usar, verifique se o NPS e o servidor de acesso estão
configurados para usar os mesmos.
FUNDAMENTAL Se você não usar os números de porta RADIUS padrão, deverá configurar exceções no
firewall para o computador local para permitir o tráfego RADIUS nas novas portas. Para obter mais
informações, consulte Configurar firewalls para tráfego RADIUS.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este procedimento para desabilitar o encaminhamento de mensagens de início e de parada de
servidores de acesso à rede (NASs) para membros de um grupo de servidores RADIUS remoto configurado no
NPS.
Quando você tiver grupos de servidores RADIUS remotos configurados e, em políticas de solicitação de
conexão NPS, desmarque a caixa de seleção encaminhar solicitações de contabilidade para este grupo
de ser vidores remotos RADIUS , esses grupos ainda serão enviados nas mensagens de notificação de início
e parada do nas.
Isso cria tráfego de rede desnecessário. Para eliminar esse tráfego, desabilite o encaminhamento de notificação
do NAS para servidores individuais em cada grupo de servidores RADIUS remotos.
Para concluir este procedimento, é preciso ser um membro do grupo Administradores .
Para desabilitar o encaminhamento de notificação do NAS
1. No Gerenciador do Servidor, clique em Ferramentas e, em seguida, clique em Ser vidor de Políticas
de Rede . O console do NPS é aberto.
2. No console do NPS, clique duas vezes em clientes e ser vidores RADIUS , clique em grupos de
ser vidores RADIUS remotos e clique duas vezes no grupo de servidores remotos RADIUS que você
deseja configurar. A caixa de diálogo Propriedades do grupo de servidores remotos RADIUS é aberta.
3. Clique duas vezes no membro do grupo que você deseja configurar e, em seguida, clique na guia
Autenticação/Contabilização .
4. Em contabilidade , desmarque a caixa de seleção encaminhar o ser vidor de acesso à rede iniciar e
parar notificações neste ser vidor e clique em OK .
5. Repita as etapas 3 e 4 para todos os membros do grupo que você deseja configurar.
Para obter mais informações sobre como gerenciar o NPS, consulte gerenciar o servidor de políticas de rede.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
Exportar uma configuração do NPS para
importação em outro servidor
07/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode exportar toda a configuração do NPS – incluindo clientes e servidores RADIUS, política de rede,
política de solicitação de conexão, registro e configuração de log – de um NPS para importação em outro NPS.
Use uma das seguintes ferramentas para exportar a configuração do NPS:
No Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012, você pode usar o Netsh ou
usar Windows PowerShell.
No Windows Server 2008 R2 e Windows Server 2008, use Netsh.
IMPORTANT
Não use esse procedimento se o banco de dados NPS de origem tiver um número de versão maior do que o número de
versão do banco de dados NPS de destino. Você pode exibir o número de versão do banco de dados NPS na exibição do
comando netsh nps show config.
Como as configurações do NPS não são criptografadas no arquivo XML exportado, enviá-lo por uma rede pode
representar um risco de segurança, portanto, tome precauções ao mover o arquivo XML do servidor de origem
para os servidores de destino. Por exemplo, adicione o arquivo a um arquivo morto criptografado protegido por
senha antes de mover o arquivo. Além disso, armazene o arquivo em um local seguro para impedir que
usuários mal-intencionados o acessem.
NOTE
Se SQL Server log estiver configurado no NPS de origem, SQL Server configurações de log não serão exportadas para o
arquivo XML. Depois de importar o arquivo em outro NPS, você deve configurar manualmente SQL Server log.
A tabela a seguir lista parâmetros para o cmdlet Expor t-NpsConfiguration no Windows PowerShell.
Parâmetros em negrito são necessários.
PA RÂ M ET RO DESC RIÇ Ã O
Credenciais administrativas
Para concluir este procedimento, é preciso ser um membro do grupo Administradores.
Exemplo de exportação
No exemplo a seguir, a configuração do NPS é exportada para um arquivo XML localizado na unidade local. Para
executar esse comando, execute Windows PowerShell como Administrador no NPS de origem, digite o
comando a seguir e pressione Enter.
Exemplo de importação
O comando a seguir importa as configurações do arquivo chamado C:\Npsconfig.xml para NPS. Para executar
esse comando, execute Windows PowerShell como Administrador no NPS de destino, digite o comando a seguir
e pressione Enter.
NOTE
Ao usar o comando netsh nps expor t, você precisa fornecer o parâmetro de comando expor tPSK com o valor YES.
Esse parâmetro e valor explicitamente afirmam que você entende que está exportando a configuração do NPS e que o
arquivo XML exportado contém segredos compartilhados não criptografados para clientes RADIUS e membros de grupos
de servidores RADIUS remotos.
Credenciais administrativas
Para concluir este procedimento, é preciso ser um membro do grupo Administradores.
Para copiar uma configuração do NPS para outro NPS usando comandos Netsh
1. No NPS de origem, abra Prompt de Comando , digite netsh e pressione Enter.
2. No prompt netsh, digite nps e pressione Enter.
3. No prompt netsh nps, digite export filename= "path\file.xml" expor tPSK=YES , em que path é o local
da pasta em que você deseja salvar o arquivo de configuração NPS e o arquivo é o nome do arquivo XML
que você deseja salvar. Pressione Enter.
Isso armazena as definições de configuração (incluindo as configurações do Registro) em um arquivo
XML. O caminho pode ser relativo ou absoluto ou pode ser um caminho UNC (Convenção universal de
nomenização). Depois de pressionar Enter, uma mensagem será exibida indicando se a exportação para o
arquivo foi bem-sucedida.
4. Copie o arquivo que você criou para o NPS de destino.
5. Em um prompt de comando no NPS de destino, digite netsh nps impor t filename= "path\file.xml" e
pressione Enter. Uma mensagem é exibida indicando se a importação do arquivo XML foi bem-sucedida.
Referências adicionais
Shell de Rede (Netsh)
Aumentar autenticações simultâneas processadas
pelo NPS
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para obter instruções sobre como configurar autenticações simultâneas do Servidor
de Políticas de Rede.
Se você instalou o NPS do Servidor de Políticas de Rede em um computador diferente de um controlador de
domínio e o NPS está recebendo um grande número de solicitações de autenticação por segundo, você pode
melhorar o desempenho do NPS aumentando o número de autenticações simultâneas permitidas entre o NPS e
o controlador ( ) de domínio.
Para fazer isso, você deve editar a seguinte chave do Registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Se você atribuir um valor a MaxConcurrentApi muito alto, o NPS poderá colocar uma carga excessiva no
controlador de domínio.
Para obter mais informações sobre como gerenciar o NPS, consulte Manage Network Policy Server.
Para obter mais informações sobre o NPS, consulte Servidor de Políticas de Rede (NPS).
Instalar o NPS (Servidor de Políticas de Rede)
13/08/2021 • 2 minutes to read
você pode usar este tópico para instalar o servidor de diretivas de rede (NPS) usando o Windows PowerShell ou
o assistente para adicionar funções e recursos. O NPS é um serviço de função da função de servidor Serviços de
Acesso e Política de Rede.
NOTE
Por padrão, o NPS ouve o tráfego RADIUS nas portas 1812, 1813, 1645 e 1646 em todos os adaptadores de rede
instalados. se Windows Firewall com segurança avançada estiver habilitado quando você instalar o NPS, as exceções de
Firewall para essas portas serão criadas automaticamente durante o processo de instalação para o ( tráfego IPv6 e IPv4
do protocolo ip versão 6 ) . se os servidores de acesso à rede estiverem configurados para enviar tráfego RADIUS por
portas diferentes desses padrões, remova as exceções criadas em Windows Firewall com segurança avançada durante a
instalação do NPS e crie exceções para as portas que você usa para o tráfego RADIUS.
Credenciais administrativas
Para concluir este procedimento, você deve ser um membro do grupo Administradores de Domínio .
NOTE
A página Antes de Começar do Assistente para Adicionar Funções e Recursos não é exibida quando você marca
a opção Ignorar esta página por padrão quando o Assistente para Funções e Recursos foi executado.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Remote Authentication Dial-In User Service (RADIUS), que são servidores de acesso à rede, como servidores
vpn (rede virtual privada) e pontos de acesso sem fio, criam solicitações de conexão e as enviam para servidores
RADIUS, como NPS. Em alguns casos, um NPS pode receber muitas solicitações de conexão ao mesmo tempo,
resultando em desempenho degradado ou sobrecarga. Quando um NPS está sobrecarregado, é uma boa ideia
adicionar mais NPSs à sua rede e configurar o balanceamento de carga. Quando você distribui solicitações de
conexão de entrada de maneira equilibrada entre vários NPSs para evitar a sobrecarga de um ou mais NPSs, ele
é chamado de balanceamento de carga.
O balanceamento de carga é particularmente útil para:
Organizações que usam a Autenticação Extensível Protocol-Transport ( EAP-TLS ou TLS de Protocolo de
Autenticação Extensível Protegido ) ( PEAP ) -TLS para autenticação. Como esses métodos de autenticação
usam certificados para autenticação de servidor e para autenticação de computador cliente ou usuário, a
carga em proxies e servidores RADIUS é mais pesada do que quando métodos de autenticação baseados em
senha são usados.
Organizações que precisam manter a disponibilidade contínua do serviço.
ISPs de provedores de serviços ( de Internet ) que terceirizam o acesso à VPN para outras organizações. Os
serviços VPN terceirizados podem gerar um grande volume de tráfego de autenticação.
Há dois métodos que você pode usar para equilibrar a carga de solicitações de conexão enviadas ao NPSs:
Configure seus servidores de acesso à rede para enviar solicitações de conexão para vários servidores
RADIUS. Por exemplo, se você tiver 20 pontos de acesso sem fio e dois servidores RADIUS, configure cada
ponto de acesso para enviar solicitações de conexão para ambos os servidores RADIUS. Você pode balancear
a carga e fornecer failover em cada servidor de acesso à rede configurando o servidor de acesso para enviar
solicitações de conexão a vários servidores RADIUS em uma ordem de prioridade especificada. Esse método
de balanceamento de carga geralmente é melhor para organizações pequenas que não implantam um
grande número de clientes RADIUS.
Use o NPS configurado como um proxy RADIUS para balancear a carga de solicitações de conexão entre
vários NPSs ou outros servidores RADIUS. Por exemplo, se você tiver 100 pontos de acesso sem fio, um
proxy NPS e três servidores RADIUS, poderá configurar os pontos de acesso para enviar todo o tráfego para
o proxy NPS. No proxy NPS, configure o balanceamento de carga para que o proxy distribua de maneira
equilibrada as solicitações de conexão entre os três servidores RADIUS. Esse método de balanceamento de
carga é melhor para organizações médias e grandes que têm muitos clientes e servidores RADIUS.
Em muitos casos, a melhor abordagem para balanceamento de carga é configurar clientes RADIUS para enviar
solicitações de conexão para dois servidores proxy NPS e, em seguida, configurar os proxies NPS para balancear
a carga entre servidores RADIUS. Essa abordagem fornece failover e balanceamento de carga para proxies NPS
e servidores RADIUS.
NOTE
As etapas a seguir pressuem que você já implantou e configurou servidores RADIUS.
Para configurar o NPS para atuar como um servidor proxy e encaminhar solicitações de conexão de clientes
RADIUS para servidores RADIUS remotos, você deve tomar as seguintes ações:
1. Implante seus servidores VPN de clientes RADIUS, servidores discados, servidores de Gateway de
Serviços de Terminal, comutadores de autenticação 802.1X e pontos de acesso sem fio ( 802.1X e
configure-os para enviar solicitações de conexão para seus servidores ) proxy NPS.
2. No proxy NPS, configure os servidores de acesso à rede como clientes RADIUS. Para obter mais
informações, consulte Configurar clientes RADIUS.
3. No proxy NPS, crie um ou mais grupos de servidores RADIUS remotos. Durante esse processo, adicione
servidores RADIUS aos grupos de servidores RADIUS remotos. Para obter mais informações, consulte
Configurar grupos de servidores RADIUS remotos.
4. No proxy NPS, para cada servidor RADIUS que você adicionar a um grupo de servidores RADIUS remoto,
clique na guia Balanceamento de Carga do servidor RADIUS e, em seguida, configure As configurações
Prioridade, Peso e Avançado .
5. No proxy NPS, configure políticas de solicitação de conexão para encaminhar solicitações de autenticação
e contabilidade para grupos de servidores RADIUS remotos. Você deve criar uma política de solicitação
de conexão por grupo de servidores RADIUS remoto. Para obter mais informações, consulte Configurar
políticas de solicitação de conexão.
Registrar um NPS em um domínio do Active
Directory
07/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
você pode usar este tópico para registrar um servidor que executa o servidor de diretivas de rede no Windows
Server 2016 no domínio padrão do NPS ou em outro domínio.
NOTE
No comando anterior, Domain é o nome de domínio DNS do domínio em que você deseja registrar o NPS e Server é o
nome do computador NPS.
Cancelar o registro de um NPS de um domínio do
Active Directory
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
No processo de gerenciamento da implantação do NPS, você pode achar útil mover um NPS para outro
domínio, substituir um NPS ou para retirar um NPS.
Ao mover ou descompactar um NPS, você pode fazer o registro do NPS nos domínios do Active Directory em
que o NPS tem permissão para ler as propriedades das contas de usuário no Active Directory.
A associação a Administradores ou equivalente é o requisito mínimo para a execução destes procedimentos.
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016
Este tópico explica o uso de expressões regulares para correspondência de padrões no NPS no Windows Server.
Você pode usar essa sintaxe para especificar as condições de atributos de política de rede e realms RADIUS.
x | y Corresponde a x ou y.
{n} Corresponde exatamente n vezes ( n é /o{2}/ does not match the "o" in
um inteiro não negativo - ) . "Bob," but matches the first two
instances of the letter o in
"foooood."
C A RA C T ERE DESC RIÇ Ã O EXEM P LO
{n,} Corresponde a pelo menos n vezes ( n /o{2,}/ does not match the "o"
é um inteiro não negativo - ) . in "Bob" but matches all of the
instances of the letter o in
"foooood." /o{1,}/ is equivalent
to /o+/.
\r Corresponde a um caractere de
retorno de carro.
\t Corresponde a um caractere de
tabulação.
\v Corresponde a um caractere de
tabulação vertical.
C A RA C T ERE DESC RIÇ Ã O EXEM P LO
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para verificar a configuração do NPS após uma alteração de nome ou endereço IP
para o servidor.
Este documento explica como encontrar informações do usuário coletadas pelo NPS (Servidor de Políticas de
Rede) caso você gostaria de removê-los.
NOTE
Se você estiver interessado em exibir ou excluir dados pessoais, examine as diretrizes da Microsoft no site Solicitações de
entidades de dados do Windows para o RGPD. Se você estiver procurando informações gerais sobre o RGPD, confira a
seção RGPD do Portal de Confiança do Serviço.
A Política de Rede e Serviços do Access de log de eventos são consideradas duplicativas para os dados de
contabilidade e não precisam ser coletadas.
Se os dados de contabilidade não estão habilitados, os registros das tentativas de autenticação NPS de um
usuário podem ser obtidos da Política de Rede e Serviços do Access log de eventos pesquisando o <username> .
Gerenciar modelos do NPS
12/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar ( modelos NPS do servidor ) de políticas de rede para criar elementos de configuração, como
serviço RADIUS ( ) clientes RADIUS ou segredos compartilhados, que você pode reutilizar no NPS local e
exportar para uso em outros NPSs.
O gerenciamento de modelos fornece um nó no console do NPS, no qual você pode criar, modificar, excluir,
duplicar e exibir o uso de modelos de NPS. Os modelos de NPS são projetados para reduzir a quantidade de
tempo e o custo necessário para configurar o NPS em um ou mais servidores.
Os seguintes tipos de modelo de NPS estão disponíveis para configuração no gerenciamento de modelos.
Segredos compar tilhados . Esse tipo de modelo possibilita que você especifique um segredo
compartilhado que pode ser reutilizado (selecionando o modelo no local apropriado no console do NPS)
ao configurar clientes e servidores RADIUS.
Clientes RADIUS . Esse tipo de modelo possibilita que você defina as configurações do cliente RADIUS
que podem ser reutilizadas selecionando o modelo no local apropriado no console do NPS.
Ser vidores RADIUS remotos . Esse modelo possibilita que você defina as configurações do servidor
RADIUS remoto que você pode reutilizar selecionando o modelo no local apropriado no console do NPS.
Filtros de IP . Esse modelo possibilita que você crie filtros IPv6 (protocolo IP versão 4) e protocolo IP
versão 6 ( ) que podem ser reutilizados ( , selecionando o modelo no local apropriado no console do NPS
) quando você configura as políticas de rede.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
O Netsh (Shell de Rede) é um utilitário de linha de comando que permite configurar e exibir o status de vários
componentes e funções de servidor de comunicações de rede depois que são instalados nos computadores que
executam o Windows Server.
Algumas tecnologias de clientes, como o cliente (DHCP) e o BranchCache, também fornecem comandos netsh
que permitem configurar computadores cliente que executam o Windows 10.
Na maioria dos casos, os comandos netsh fornecem a mesma funcionalidade disponível quando você usa o
snap-in do MMC (Console de Gerenciamento Microsoft) para cada função de servidor de rede ou recurso de
rede. Por exemplo, você pode configurar o NPS (Servidor de Políticas de Rede) usando o snap-in do MMC do
NPS ou os comandos netsh no contexto do netsh nps .
Além disso, há comandos netsh para tecnologias de rede, como IPv6, ponte de rede e RPC (Chamada de
Procedimento Remoto), que não estão disponíveis no Windows Server como um snap-in do MMC.
IMPORTANT
Recomendamos usar o Windows PowerShell para gerenciar as tecnologias de rede no Windows Server e Windows 10 em
vez de no Shell de Rede. No entanto, o Shell de Rede é incluído para oferecer compatibilidade com seus scripts e há
suporte para o uso dele.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Você pode usar este tópico para aprender a inserir contextos e subcontextos netsh, a entender a formatação da
sintaxe e do comando netsh e a executar comandos netsh em computadores locais e remotos.
O Netsh é um utilitário de script de linha de comando que permite exibir ou modificar a configuração de rede de
um computador em execução no momento. Os comandos netsh podem ser executados digitando comandos no
prompt netsh e podem ser usados em arquivos ou scripts em lotes. Os computadores remotos e o computador
local podem ser configurados usando comandos netsh.
O Netsh também fornece um recurso de script com o qual você pode executar um grupo de comandos no
modo em lote para um computador especificado. Com o Netsh, você pode salvar um script de configuração em
um arquivo de texto para fins de arquivamento ou para ajudar você a configurar outros computadores.
Contextos netsh
O netsh interage com outros componentes do sistema operacional usando arquivos (DLL) da biblioteca de
vínculo-dinâmico.
Cada DLL auxiliar do netsh fornece um amplo conjunto de recursos chamado de contexto, que é um grupo de
comandos específicos a uma função de servidor de rede ou recurso. Esses contextos ampliam a funcionalidade
do netsh fornecendo suporte de configuração e monitoramento para um ou mais serviços, utilitários ou
protocolos. Por exemplo, Dhcpmon.dll fornece o netsh com o contexto e o conjunto de comandos necessários
para configurar e gerenciar servidores DHCP.
Obter uma lista de contextos
Você pode obter uma lista de contextos netsh abrindo o prompt de comando ou o Windows PowerShell em um
computador que executa Windows Server 2016 ou Windows 10. Digite o comando netsh e pressione ENTER.
Digite /? e pressione ENTER.
Veja a seguir um exemplo de saída desses comandos em um computador que executa o Windows Server 2016
Datacenter.
PS C:\Windows\system32> netsh
netsh>/?
To view help for a command, type the command, followed by a space, and then type ?.
Subcontextos
Os contextos netsh podem conter comandos e contextos adicionais, chamados subcontextos. Por exemplo,
dentro do contexto de roteiros, você pode alterar para os subcontextos IP e IPv6.
Para exibir uma lista de comandos e subcontextos que você pode usar em um contexto, no prompt do netsh,
digite o nome do contexto e digite /? ou help . Por exemplo, para exibir uma lista de subcontextos e comandos
que podem ser usados no contexto de roteiros, no prompt do netsh (ou seja, netsh> ), digite um dos seguintes:
routing /?
routing help
Para executar tarefas em outro contexto sem alterar o contexto atual, digite o caminho de contexto do comando
que você deseja usar no prompt do netsh. Por exemplo, para adicionar uma interface denominada "Conexão de
Área Local" no contexto IGMP sem primeiro alterar para o contexto IGMP, no prompt do netsh, digite:
routing ip igmp add interface "Local Area Connection" star tupquer yinter val=21
Legenda de formatação
Você pode usar a legenda de formatação para interpretar e usar a sintaxe de comando netsh correta quando
você executa o comando no prompt do netsh ou em um arquivo ou script em lotes.
O texto em itálico é a informação que você deve fornecer enquanto digita o comando. Por exemplo, se um
comando tiver um parâmetro denominado -UserName, você deverá digitar o nome de usuário real.
O texto em negrito é a informação que você deve digitar exatamente conforme mostrado enquanto você
digita o comando.
O texto seguido por um reticências (...) é um parâmetro que pode ser repetido várias vezes em uma linha de
comando.
O texto entre colchetes [ ] é um item opcional.
O texto entre chaves { } com opções separadas por um pipe fornece um conjunto de opções do qual você
deve selecionar apenas uma, como {enable|disable} .
O texto formatado com a fonte Courier é a saída do código ou do programa.
-a
Opcional. Especifica que você é levado de volta ao prompt do netsh depois de executar AliasFile.
AliasFile
Opcional. Especifica o nome do arquivo de texto que contém um ou mais comandos netsh .
-c
Opcional. Especifica que você deseja que o comando seja executado em um computador remoto.
IMPORTANT
Quando você usa alguns comandos netsh remotamente ou outro computador com o parâmetro netsh –r , o serviço do
Registro Remoto deve ser executado no computador remoto. Se não estiver em execução, o Windows exibirá uma
mensagem de erro "Caminho de Rede não encontrado".
RemoteComputer
Opcional. Especifica que você deseja executar o comando netsh em uma conta de usuário.
DomainName\\
Opcional. Especifica o domínio em que a conta de usuário está localizada. O padrão será o domínio local se
DomainName\ não estiver especificado.
UserName
Opcional. Especifica que você deseja fornecer uma senha para a conta de usuário.
Password
Opcional. Especifica a senha da conta de usuário que você especificou com -u UserName.
NetshCommand
Opcional. Sai do netsh depois de executar o script que você designa com ScriptFile.
ScriptFile
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Use este tópico para aprender a criar um arquivo em lotes que executa várias tarefas usando o Netsh no
Windows Server. Este exemplo de arquivo em lotes usa o contexto netsh wins .
rem 1. Connect to (WINS-A), and add the dynamic name MY\_RECORD \[04h\] to the (WINS-A) database.
netsh wins server 192.168.125.30 add name Name=MY\_RECORD EndChar=04 IP={192.168.0.205}
rem 2. Connect to (WINS-A), and set (WINS-B) as a push/pull replication partner of (WINS-A).
netsh wins server 192.168.125.30 add partner Server=192.168.0.189 Type=2
rem 3. Connect to (WINS-B), and set (WINS-A) as a push/pull replication partner of (WINS-B).
netsh wins server 192.168.0.189 add partner Server=192.168.125.30 Type=2
rem 5. Connect to (WINS-B), and check that the record MY_RECORD [04h] was replicated successfully.
netsh wins server 192.168.0.189 show name Name=MY_RECORD EndChar=04
Referências adicionais
Shell de Rede (Netsh)
Comandos Netsh http
13/08/2021 • 8 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
TIP
Se você estiver usando o Windows PowerShell em um computador que executa Windows Server ou Windows 10, insira
netsh e pressione Enter. No prompt netsh, digite http e pressione Enter para obter o prompt netsh http.
netsh http>
add iplisten
Adiciona um novo endereço IP à lista de escuta de IP, excluindo o número da porta.
Sintaxe
Parâmetros
Exemplos
A seguir, estão quatro exemplos do comando add iplisten .
add iplisten ipaddress=fe80::1
add iplisten ipaddress=1.1.1.1
add iplisten ipaddress=0.0.0.0
add iplisten ipaddress=::
add sslcert
Adiciona uma nova associação de certificado do servidor SSL e as políticas de certificado de cliente
correspondentes a um endereço IP e uma porta.
Sintaxe
Parâmetros
Exemplos
A seguir, está um exemplo do comando add sslcer t .
add sslcert ipport=1.1.1.1:443 certhash=0102030405060708090A0B0C0D0E0F1011121314 appid=
{00112233-4455-6677-8899- AABBCCDDEEFF}
add timeout
Adiciona um tempo limite global ao serviço.
Sintaxe
add timeout [ timeouttype= ] IdleConnectionTimeout | HeaderWaitTimeout [ value=] U-Short
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O
Exemplos
A seguir, estão dois exemplos do comando add timeout .
add timeout timeouttype=idleconnectiontimeout value=120
add timeout timeouttype=headerwaittimeout value=0x40
add urlacl
Adiciona uma entrada de reserva de URL (Uniform Resource Locator). Esse comando reserva a URL para contas
e usuários não administradores. A DACL pode ser especificada usando um nome de conta do NT com os
parâmetros listen e delegate ou usando uma cadeia de caracteres SDDL.
Sintaxe
add urlacl [ url= ] URL [ [user=] User [ [ listen= ] yes | no [ delegate= ] yes | no ] | [ sddl= ] SDDL ]
Parâmetros
Exemplos
A seguir, estão quatro exemplos do comando add urlacl .
add urlacl url=https://+:80/MyUri user=DOMAIN\ user
add urlacl url=https://www.contoso.com:80/MyUri user=DOMAIN\user listen=yes
add urlacl url=https://www.contoso.com:80/MyUri user=DOMAIN\user delegate=no
add urlacl url=https://+:80/MyUri sddl=...
delete cache
Exclui todas as entradas ou uma entrada especificada do cache do URI do kernel do serviço HTTP.
Sintaxe
Parâmetros
Exemplos
A seguir, estão dois exemplos do comando delete cache .
delete cache url=https://www.contoso.com:80/myresource/ recursive=yes
delete cache
delete iplisten
Exclui um endereço IP da lista de escuta de IP. A lista de escuta de IP é usada para definir o escopo da lista de
endereços aos quais o serviço HTTP associa-se.
Sintaxe
Parâmetros
Exemplos
A seguir, estão quatro exemplos do comando delete iplisten .
delete iplisten ipaddress=fe80::1
delete iplisten ipaddress=1.1.1.1
delete iplisten ipaddress=0.0.0.0
delete iplisten ipaddress=::
delete sslcert
Excluir as associações de certificado do servidor SSL e as políticas de certificado de cliente correspondentes a
um endereço IP e uma porta.
Sintaxe
Parâmetros
Exemplos
A seguir, estão três exemplos do comando delete sslcer t .
delete sslcert ipport=1.1.1.1:443
delete sslcert ipport=0.0.0.0:443
delete sslcert ipport=[::]:443
delete timeout
Exclui um tempo limite global e faz com que o serviço reverta para os valores padrão.
Sintaxe
delete timeout [ timeouttype= ] idleconnectiontimeout | headerwaittimeout
Parâmetros
Exemplos
A seguir, estão dois exemplos do comando delete timeout .
delete timeout timeouttype=idleconnectiontimeout
delete timeout timeouttype=headerwaittimeout
delete urlacl
Exclui as reservas de URL.
Sintaxe
Parâmetros
Exemplos
A seguir, estão dois exemplos do comando delete urlacl .
delete urlacl url=https://+:80/MyUri
delete urlacl url=https://www.contoso.com:80/MyUri
flush logbuffer
Libera os buffers internos para os arquivos de log.
Sintaxe
flush logbuffer
show cachestate
Lista os recursos de URI armazenados em cache e suas propriedades associadas. Este comando lista todos os
recursos e propriedades associadas em cache no cache de resposta HTTP ou exibe um único recurso e as
propriedades associadas a ele.
Sintaxe
Parâmetros
Exemplos
Veja abaixo dois exemplos do comando show cachestate :
show cachestate url=https://www.contoso.com:80/myresource
show cachestate
show iplisten
Exibe todos os endereços IP na lista de escuta de IP. A lista de escuta de IP é usada para definir o escopo da lista
de endereços aos quais o serviço HTTP associa-se. "0.0.0.0" significa qualquer endereço IPv4 e "::" significa
qualquer endereço IPv6.
Sintaxe
show iplisten
show servicestate
Exibe um instantâneo do serviço HTTP.
Sintaxe
Parâmetros
show sslcert
Exibe associações de certificado do servidor de protocolo SSL e as políticas de certificado de cliente
correspondentes a um endereço IP e uma porta.
Sintaxe
Parâmetros
Exemplos
A seguir, estão cinco exemplos do comando show sslcer t .
show sslcert ipport=[fe80::1]:443
show sslcert ipport=1.1.1.1:443
show sslcert ipport=0.0.0.0:443
show sslcert ipport=[::]:443
show sslcert
show timeout
Exibe, em segundos, os valores de tempo limite do serviço HTTP.
Sintaxe
show timeout
show urlacl
Exibe DACLs (listas de controle de acesso discricional) para a URL reservada especificada ou todas as URLs
reservadas.
Sintaxe
show urlacl [ [url= ] URL]
Parâmetros
Exemplos
A seguir, estão três exemplos do comando show urlacl .
show urlacl url=https://+:80/MyUri
show urlacl url=https://www.contoso.com:80/MyUri
show urlacl
Comandos netsh interface portproxy
12/08/2021 • 10 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Use os comandos netsh interface por tproxy para funcionar como proxies entre as redes e aplicativos IPv4 e
IPv6. Você pode usar esses comandos para estabelecer o serviço de proxy das seguintes maneiras:
Mensagens de computador e aplicativo configuradas para IPv4 enviadas para outros computadores e
aplicativos configurados para IPv4.
Mensagens de computador e aplicativo configuradas para IPv4 enviadas para computadores e aplicativos
configurados para IPv6.
Mensagens de computador e aplicativo configuradas para IPv6 enviadas para computadores e aplicativos
configurados para IPv4.
Mensagens de computador e aplicativo configuradas para IPv6 enviadas para outros computadores e
aplicativos configurados para IPv6.
Ao gravar arquivos ou scripts em lotes usando esses comandos, cada comando deve começar com netsh
interface por tproxy . Por exemplo, ao usar o comando delete v4tov6 para especificar que o servidor
portproxy exclua uma porta e um endereço IPv4 da lista de endereços IPv4 para os quais o servidor escuta, o
script ou o arquivo em lotes deverá usar a seguinte sintaxe:
netsh interface portproxy delete v4tov6 listenport= {Integer | ServiceName} [[listenaddress=] {IPv4Address|
HostName}] [[protocol=]tcp]
add v4tov4
O servidor portproxy escuta mensagens enviadas a uma porta e um endereço IPv4 específicos. Ele mapeia uma
porta e um endereço IPv4 para enviar as mensagens recebidas após estabelecer uma conexão TCP separada.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O
add v4tov6
O servidor portproxy escuta mensagens enviadas a uma porta e um endereço IPv4 específicos e mapeia uma
porta e um endereço IPv6 para enviar as mensagens recebidas após estabelecer uma conexão TCP separada.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O
PA RÂ M ET RO DESC RIÇ Ã O
add v6tov4
O servidor portproxy escuta mensagens enviadas a uma porta e um endereço IPv6 específicos e mapeia uma
porta e um endereço IPv4 para os quais enviar as mensagens recebidas após estabelecer uma conexão TCP
separada.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O
delete v4tov4
O servidor portproxy exclui um endereço IPv4 da lista de portas e endereços IPv4 para os quais o servidor
escuta.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O
delete v6tov4
O servidor portproxy exclui uma porta e um endereço IPv6 da lista de endereços IPv6 para os quais o servidor
escuta.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O
delete v6tov6
O servidor portproxy exclui um endereço IPv6 da lista de endereços IPv6 para os quais o servidor escuta.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O
reset
Redefine o estado de configuração do IPv6.
Sintaxe
reset
set v4tov4
Modifica os valores de parâmetro de uma entrada existente no servidor portproxy criado com o comando add
v4tov4 ou adiciona uma nova entrada à lista que mapeia os pares porta/endereço.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O
set v4tov6
Modifica os valores de parâmetro de uma entrada existente no servidor portproxy criado com o comando add
v4tov6 ou adiciona uma nova entrada à lista que mapeia os pares porta/endereço.
Sintaxe
set v4tov6 listenport= {Integer | ServiceName} [[connectaddress=] {IPv6Address | HostName} [[connectport=]
{Integer | ServiceName}] [[listenaddress=] {IPv4Address | HostName} [[protocol=]tcp]
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O
set v6tov4
Modifica os valores de parâmetro de uma entrada existente no servidor portproxy criado com o comando add
v6tov4 ou adiciona uma nova entrada à lista que mapeia os pares porta/endereço.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O
set v6tov6
Modifica os valores de parâmetro de uma entrada existente no servidor portproxy criado com o comando add
v6tov6 ou adiciona uma nova entrada à lista que mapeia os pares porta/endereço.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O
exibir tudo
Exibe todos os parâmetros portproxy, incluindo pares porta/endereço para v4tov4, v4tov6, v6tov4 e v6tov6.
Sintaxe
show all
show v4tov4
Exibe os parâmetros v4tov4 portproxy.
Sintaxe
show v4tov4
show v4tov6
Exibe os parâmetros v4tov6 portproxy.
Sintaxe
show v4tov6
show v6tov4
Exibe os parâmetros v6tov4 portproxy.
Sintaxe
show v6tov4
show v6tov6
Exibe os parâmetros v6tov6 portproxy.
Sintaxe
show v6tov6
Comandos netsh mbn
13/08/2021 • 13 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Use o netsh mbn para consultar e definir configurações e parâmetros de banda larga móvel.
TIP
Você pode obter ajuda sobre o comando netsh mbn usando
netsh mbn /?
adicionar
Adiciona uma entrada de configuração a uma tabela.
Os comandos netsh mbn add disponíveis são:
dmprofile
profile
dmprofile
Adiciona um perfil de Configuração DM ao Armazenamento de Dados de Perfil.
Sintaxe
Parâmetros
Exemplo
perfil
Adiciona um perfil de rede ao Armazenamento de Dados do Perfil.
Sintaxe
Parâmetros
Exemplo
connect
Conecta-se a uma rede de Banda Larga Móvel.
Sintaxe
Parâmetros
Exemplos
excluir
Exclui uma entrada de configuração de uma tabela.
Os comandos netsh mbn delete disponíveis são:
dmprofile
profile
dmprofile
Exclui um perfil de Configuração DM do Armazenamento de Dados de Perfil.
Sintaxe
Parâmetros
Exemplo
Parâmetros
Exemplo
diagnose
Executa o diagnóstico para problemas básicos de celular.
Sintaxe
diagnose [interface=]<string>
Parâmetros
Exemplo
diagnose interface="Cellular"
desconectar
Desconecta-se de uma rede de Banda Larga Móvel.
Sintaxe
disconnect [interface=]<string>
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO
Exemplo
disconnect interface="Cellular"
dump
Exibe um script de configuração.
Cria um script que contém a configuração atual. Se for salvo em um arquivo, esse script poderá ser usado para
restaurar as definições de configuração alteradas.
Sintaxe
dump
ajuda
Exibe uma lista de comandos.
Sintaxe
help
set
Define as informações de configuração.
Os comandos netsh mbn set disponíveis são:
acstate
dataenablement
dataroamcontrol
enterpriseapnparams
highestconncategory
powerstate
profileparameter
slotmapping
tracing
acstate
Define o estado de conexão automática de dados de Banda Larga Móvel para a interface fornecida.
Sintaxe
Exemplo
dataenablement
Ativa ou desativa os dados de Banda Larga Móvel para o conjunto de perfis e a interface especificados.
Sintaxe
Parâmetros
Exemplo
dataroamcontrol
Define o estado do controle de roaming de Dados de Banda Larga Móvel para o conjunto de perfis e a interface
especificados.
Sintaxe
set dataroamcontrol [interface=]<string> [profileset=]internet|mms|all [state=]none|partner|all
Parâmetros
Exemplo
enterpriseapnparams
Define os parâmetros enterpriseAPN de dados de Banda Larga Móvel para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
highestconncategory
Define a categoria de conexão mais alta de dados de Banda Larga Móvel para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
powerstate
Ativa ou desativa o rádio de Banda Larga Móvel para a interface fornecida.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO
Exemplo
profileparameter
Definir parâmetros em um Perfil de Rede de Banda Larga Móvel.
Sintaxe
Parâmetros
Comentários
Pelo menos um parâmetro entre o nome da interface e o custo deve ser especificado.
Exemplo
slotmapping
Define o mapeamento de slot de modem de Banda Larga Móvel para a interface fornecida.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO
Exemplo
tracing
Habilitar ou desabilitar o rastreamento.
Sintaxe
Parâmetros
Exemplo
show
Exibe informações de rede de banda larga móvel.
Os comandos netsh mbn show disponíveis são:
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
Mostra o estado de conexão automática de dados de Banda Larga Móvel para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
capability
Mostra as informações de capacidade da interface para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
show capability interface="Cellular"
connection
Mostra as informações de conexão atuais para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
dataenablement
Mostra o estado de habilitação de dados de Banda Larga Móvel para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
dataroamcontrol
Mostra o estado de controle de roaming de dados de Banda Larga Móvel para a interface fornecida.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO
Exemplo
dmprofiles
Mostra uma lista de perfis de Configuração de DM configurados no sistema.
Sintaxe
Parâmetros
Comentários
Mostra os dados do perfil ou lista os perfis no sistema.
Se o nome do perfil for fornecido, o conteúdo do perfil será exibido. Caso contrário, os perfis serão listados para
a interface.
Se o nome da interface for fornecido, somente o perfil especificado na interface fornecida será listado. Caso
contrário, o primeiro perfil correspondente será exibido.
Exemplo
enterpriseapnparams
Mostra os parâmetros enterpriseAPN de dados de Banda Larga Móvel para a interface fornecida.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO
Exemplo
highestconncategory
Mostra a categoria de conexão mais alta de Dados de Banda Larga Móvel para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
homeprovider
Mostra as informações do provedor de residencial para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
interfaces
Mostra uma lista de interfaces de Banda Larga Móvel no sistema. Não há parâmetros para esse comando.
Sintaxe
show interfaces
netlteattachinfo
Mostra as informações de anexação LTE de rede de Banda Larga Móvel para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
pin
Mostra as informações de marcador para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
pinlist
Mostra as informações de lista de marcadores para a interface fornecida.
Sintaxe
Parâmetros
PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO
Exemplo
preferredproviders
Mostra a lista de provedores preferenciais para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
profiles
Mostra uma lista de perfis configurados no sistema.
Sintaxe
Parâmetros
Comentários
Se o nome do perfil for fornecido, o conteúdo do perfil será exibido. Caso contrário, os perfis serão listados para
a interface.
Se o nome da interface for fornecido, somente o perfil especificado na interface fornecida será listado. Caso
contrário, o primeiro perfil correspondente será exibido.
Se a finalidade for fornecida, somente os perfis com o GUID de finalidade correspondente serão exibidos. Caso
contrário, os perfis não serão filtrados por finalidade. A cadeia de caracteres pode ser um GUID com chaves ou
uma das seguintes cadeias de caracteres: internet, supl, mms, ims ou allhost.
Exemplo
profilestate
Mostra o estado de um perfil de Banda Larga Móvel para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
provisionedcontexts
Mostra as informações de contextos provisionadas para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
show provisionedcontexts interface="Cellular"
purpose
Mostra os GUIDs do grupo de finalidade que podem ser usados para filtrar perfis no dispositivo. Não há
parâmetros para esse comando.
Sintaxe
show purpose
radio
Mostra as informações de estado de rádio para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
readyinfo
Mostra as informações prontas para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
signal
Mostra as informações de sinal para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
slotmapping
Mostra o mapeamento de slot de modem de Banda Larga Móvel para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
slotstatus
Mostra o status do slot de modem de Banda Larga Móvel para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
show slotstatus interface="Cellular"
smsconfig
Mostra as informações de configuração do SMS para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
tracing
Mostra se o rastreamento de Banda Larga Móvel está habilitado ou desabilitado.
Sintaxe
show tracing
visibleproviders
Mostra a lista de provedores visíveis para a interface fornecida.
Sintaxe
Parâmetros
Exemplo
test
Executa testes para uma área de recurso específica enquanto coleta logs.
Sintaxe
Parâmetros
M A RC A VA LO R O P C IO N A L?
Comentários
As áreas de recursos compatíveis são:
conectividade
potência
radio
esim
sms
dssa
lte
bringup
Alguns testes exigem que parâmetros adicionais sejam fornecidos no campo param . Os parâmetros necessários
para os recursos estão listados abaixo.
connectivity : AccessString, UserName (se aplicável), Senha (se aplicável)
radio : AccessString, UserName (se aplicável), Senha (se aplicável)
esim : ActivationCode
bringup : AccessString, UserName (se aplicável), Senha (se aplicável)
Exemplos
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Você pode usar este tópico para uma visão geral do subsistema de rede e links para outros tópicos neste guia.
NOTE
Além deste tópico, as seções a seguir deste guia fornecem recomendações de ajuste de desempenho para dispositivos de
rede e a pilha de rede.
Escolhendo um adaptador de rede
Configurar a ordem das interfaces de rede
Adaptadores de rede de ajuste de desempenho
Contadores de desempenho relacionados à rede
Ferramentas de desempenho para cargas de trabalho de rede
O ajuste de desempenho do subsistema de rede, especialmente para cargas de trabalho com uso intensivo de
rede, pode envolver cada camada da arquitetura de rede, que também é chamada de pilha de rede. Essas
camadas são amplamente divididas nas seções a seguir.
1. Interface de rede . Essa é a camada mais baixa na pilha de rede e contém o driver de rede que se
comunica diretamente com o adaptador de rede.
2. NDIS (Especificação de Interface do Driver de Rede). O NDIS expõe interfaces para o driver abaixo
dele e para as camadas acima dele, como a Pilha de Protocolos.
3. Pilha de protocolos . A pilha de protocolo implementa protocolos como TCP/IP e UDP/IP. Essas camadas
expõem a interface da camada de transporte para camadas acima delas.
4. Drivers de sistema . Normalmente, esses são clientes que usam uma interface TDX (transport data
extension) ou WSK (Winsock Kernel) para expor interfaces a aplicativos de modo de usuário. A interface
WSK foi introduzida no Windows Server 2008 e Windows Vista e é exposta ® por AFD.sys. A interface
melhora o desempenho eliminando a alternação entre o modo de usuário e o modo kernel.
5. Aplicativos de modo de usuário . Normalmente, são soluções da Microsoft ou aplicativos
personalizados.
A tabela a seguir fornece uma ilustração vertical das camadas da pilha de rede, incluindo exemplos de itens que
são executados em cada camada.
Escolhendo um adaptador de rede
13/08/2021 • 11 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Você pode usar este tópico para aprender alguns dos recursos dos adaptadores de rede que podem afetar suas
opções de compra.
Aplicativos com uso intensivo de rede exigem Adaptadores de rede de alto desempenho. Esta seção explora
algumas considerações sobre como escolher adaptadores de rede, bem como definir configurações de
adaptador de rede diferentes para obter o melhor desempenho de rede.
TIP
Você pode definir as configurações do adaptador de rede usando Windows PowerShell. Para obter mais informações,
consulte cmdlets do adaptador de rede em Windows PowerShell.
Recursos de descarga
O descarregamento de tarefas da CPU da unidade de processamento central ( ) para o adaptador de rede pode
reduzir o uso da CPU no servidor, o que melhora o desempenho geral do sistema.
A pilha de rede nos produtos da Microsoft pode descarregar uma ou mais tarefas em um adaptador de rede se
você selecionar um adaptador de rede que tenha os recursos de descarregamento apropriados. A tabela a
seguir fornece uma breve visão geral de diferentes recursos de descarregamento que estão disponíveis no
Windows Server 2016.
Cálculo da soma de verificação para TCP A pilha de rede pode descarregar o cálculo e a validação das
somas de verificação TCP do protocolo de controle de
transmissão ( ) nos caminhos de código de envio e
recebimento. Ele também pode descarregar o cálculo e a
validação de somas de verificação de IPv4 e IPv6 em
caminhos de código de envio e recebimento.
Cálculo da soma de verificação para UDP A pilha de rede pode descarregar o cálculo e a validação de
somas de verificação UDP do protocolo de datagrama de
usuário ( ) em caminhos de código de envio e recebimento.
Cálculo da soma de verificação para IPv4 A pilha de rede pode descarregar o cálculo e a validação de
somas de verificação de IPv4 em caminhos de código de
envio e recebimento.
Cálculo da soma de verificação para IPv6 A pilha de rede pode descarregar o cálculo e a validação de
somas de verificação do IPv6 em caminhos de código de
envio e recebimento.
T IP O DE DESC A RREGA M EN TO DESC RIÇ Ã O
RSS de escala lateral de recebimento () O RSS é uma tecnologia de driver de rede que permite a
distribuição eficiente de processamento de recebimento de
rede em várias CPUs em sistemas multiprocessadores. Mais
detalhes sobre o RSS são fornecidos posteriormente neste
tópico.
União de segmento de recebimento ( RSC) O RSC é a capacidade de agrupar pacotes para minimizar o
processamento de cabeçalho necessário para que o host seja
executado. Um máximo de 64 KB de carga recebida pode ser
agrupado em um único pacote maior para processamento.
Mais detalhes sobre o RSC são fornecidos posteriormente
neste tópico.
NOTE
Para obter uma referência de comando detalhada para cada cmdlet, incluindo sintaxe e parâmetros, você pode clicar nos
links a seguir. além disso, você pode passar o nome do cmdlet para Get-Help no prompt de Windows PowerShell para
obter detalhes sobre cada comando.
Disable-NetAdapterRss. Esse comando desabilita o RSS no adaptador de rede que você especificar.
Enable-NetAdapterRss. Esse comando habilita o RSS no adaptador de rede que você especificar.
Get-NetAdapterRss. Esse comando recupera as propriedades de RSS do adaptador de rede que você
especificar.
Set-NetAdapterRss. Esse comando define as propriedades de RSS no adaptador de rede que você
especificar.
Perfis de RSS
Você pode usar o parâmetro – Profile do cmdlet Set-NetAdapterRss para especificar quais processadores
lógicos são atribuídos a qual adaptador de rede. Os valores disponíveis para esse parâmetro são:
Mais próximo . Os números de processador lógicos próximos ao processador RSS base do adaptador de
rede são preferenciais. Com esse perfil, o sistema operacional pode reequilibrar os processadores lógicos
dinamicamente com base na carga.
ClosestStatic . Os números de processador lógico próximo ao processador RSS de base do adaptador de
rede são preferenciais. Com esse perfil, o sistema operacional não reequilibra dinamicamente os
processadores lógicos com base na carga.
Numa . Os números de processador lógicos geralmente são selecionados em diferentes nós NUMA para
distribuir a carga. Com esse perfil, o sistema operacional pode reequilibrar os processadores lógicos
dinamicamente com base na carga.
NUMAStatic . Esse é o perfil padrão . Os números de processador lógicos geralmente são selecionados
em diferentes nós NUMA para distribuir a carga. Com esse perfil, o sistema operacional não reequilibrará
os processadores lógicos dinamicamente com base na carga.
Conser vador . O RSS usa o menor número possível de processadores para sustentar a carga. Essa opção
ajuda a reduzir o número de interrupções.
dependendo do cenário e das características de carga de trabalho, você também pode usar outros parâmetros
do cmdlet Set-NetAdapterRss Windows PowerShell para especificar o seguinte:
Em uma base de adaptador por rede, quantos processadores lógicos podem ser usados para RSS.
O deslocamento inicial para o intervalo de processadores lógicos.
O nó do qual o adaptador de rede aloca memória.
A seguir estão os parâmetros set-NetAdapterRss adicionais que você pode usar para configurar o RSS:
NOTE
Na sintaxe de exemplo para cada parâmetro abaixo, o nome do adaptador de rede Ethernet é usado como um valor de
exemplo para o parâmetro – Name do comando set-NetAdapterRss . Ao executar o cmdlet, verifique se o nome do
adaptador de rede que você usa é apropriado para seu ambiente.
* MaxProcessors : define o número máximo de processadores RSS a serem usados. Isso garante que o
tráfego do aplicativo esteja associado a um número máximo de processadores em uma determinada
interface. Exemplo de sintaxe:
Set-NetAdapterRss –Name "Ethernet" –MaxProcessors <value>
* NumaNode : o nó numa para o qual cada adaptador de rede pode alocar memória. Isso pode estar
dentro de um grupo k ou de diferentes grupos k. Exemplo de sintaxe:
Set-NetAdapterRss –Name "Ethernet" –NumaNodeID <value>
Para obter mais informações, clique no link a seguir para baixar a rede escalonável: eliminando o afunilamento
de processamento de recebimento, apresentando o RSS no formato Word.
Noções básicas sobre o desempenho do RSS
O ajuste do RSS requer a compreensão da configuração e da lógica de balanceamento de carga. para verificar se
as configurações de RSS entraram em vigor, você pode examinar a saída ao executar o cmdlet Get-
NetAdapterRss Windows PowerShell. Veja a seguir um exemplo de saída desse 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
Além dos parâmetros de eco que foram definidos, o aspecto principal da saída é a saída da tabela de indireção.
A tabela de indireção exibe os buckets de tabela de hash que são usados para distribuir o tráfego de entrada.
Neste exemplo, a notação n:c designa o par de índice K-Group: CPU de numa que é usado para direcionar o
tráfego de entrada. Vemos exatamente duas entradas exclusivas (0:0 e 0:4), que representam k-Group 0/CPU0 e
k-Group 0/CPU 4, respectivamente.
Há apenas um grupo k para este sistema (k-Group 0) e uma entrada de tabela de indireção n (em que n <=
128). Como o número de filas de recebimento está definido como 2, somente 2 processadores (0:0, 0:4) são
escolhidos, embora os processadores máximos estejam definidos como 8. Na verdade, a tabela de indireção
está aplicando hash ao tráfego de entrada para usar apenas 2 CPUs dos 8 que estão disponíveis.
Para utilizar totalmente as CPUs, o número de filas de recebimento RSS deve ser igual ou maior que os
processadores máximos. No exemplo anterior, a fila de recebimento deve ser definida como 8 ou superior.
Agrupamento NIC e RSS
O RSS pode ser habilitado em um adaptador de rede que está agrupado com outra placa de interface de rede
usando o agrupamento NIC. Nesse cenário, somente o adaptador de rede física subjacente pode ser
configurado para usar o RSS. Um usuário não pode definir os cmdlets RSS no adaptador de rede agrupado.
União de segmento de recebimento (RSC )
A União de segmento ( de recebimento RSC ) ajuda o desempenho, reduzindo o número de cabeçalhos IP que
são processados para uma determinada quantidade de dados recebidos. Ele deve ser usado para ajudar a
dimensionar o desempenho de dados recebidos agrupando ( ou unindo ) os pacotes menores em unidades
maiores.
Essa abordagem pode afetar a latência com os benefícios vistos principalmente nos ganhos da produtividade. O
RSC é recomendado para aumentar a taxa de transferência para cargas de trabalho pesadas recebidas.
Considere a implantação de adaptadores de rede que dão suporte a RSC.
Nesses adaptadores de rede, verifique se o RSC está nessa ( configuração padrão ) , a menos que você tenha
cargas de trabalho específicas, ( por exemplo, baixa latência, rede de baixa taxa de transferência ) que mostre os
benefícios do RSC sendo desativado.
Compreendendo o diagnóstico de RSC
você pode diagnosticar o RSC usando os cmdlets de Windows PowerShell Get-NetAdapterRsc e get-
NetAdapterStatistics .
A seguir, há um exemplo de saída quando você executa o cmdlet Get-NetAdapterRsc.
PS C:\Users\Administrator> Get-NetAdapterRsc
O cmdlet Get mostra se o RSC está habilitado na interface e se o TCP permite que o RSC esteja em um estado
operacional. O motivo da falha fornece detalhes sobre a falha ao habilitar o RSC nessa interface.
No cenário anterior, o IPv4 RSC tem suporte e está operacional na interface. Para entender as falhas de
diagnóstico, é possível ver os bytes ou as exceções Unidas causadas. Isso fornece uma indicação dos problemas
de União.
A seguir, há um exemplo de saída quando você executa o cmdlet Get-NetAdapterStatistics.
CoalescedBytes : 0
CoalescedPackets : 0
CoalescingEvents : 0
CoalescingExceptions : 0
RSC e virtualização
Somente há suporte para RSC no host físico quando o adaptador de rede do host não está associado ao
comutador virtual do Hyper-V. O RSC é desabilitado pelo sistema operacional quando o host está associado ao
comutador virtual do Hyper-V. Além disso, as máquinas virtuais não têm o benefício de RSC porque os
adaptadores de rede virtual não dão suporte a RSC.
O RSC pode ser habilitado para uma máquina virtual quando o Sr-IOV de virtualização de entrada/saída de raiz
única ( ) estiver habilitado. Nesse caso, as funções virtuais dão suporte ao recurso RSC; Portanto, as máquinas
virtuais também recebem o benefício do RSC.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
em Windows Server 2016 e Windows 10, você pode usar a métrica de interface para configurar a ordem das
interfaces de rede.
isso é diferente de em versões anteriores do Windows e Windows Server, que permitia que você configure a
ordem de associação dos adaptadores de rede usando a interface do usuário ou os comandos
INetCfgComponentBindings:: MoveBefore e INetCfgComponentBindings:: MoveAfter . esses dois
métodos para ordenar interfaces de rede não estão disponíveis em Windows Server 2016 e Windows 10.
Em vez disso, você pode usar o novo método para definir a ordem enumerada dos adaptadores de rede
configurando a métrica de interface de cada adaptador. você pode configurar a métrica de interface usando o
comando Set-NetIPInterface Windows PowerShell.
Quando as rotas de tráfego de rede são escolhidas e você configurou o parâmetro InterfaceMetric do
comando set-NetIPInterface , a métrica geral usada para determinar a preferência de interface é a soma da
métrica de rota e a métrica da interface. Normalmente, a métrica de interface dá preferência a uma interface
específica, como usar com fio se ambos com e sem fio estiverem disponíveis.
o exemplo de comando a seguir Windows PowerShell mostra o uso desse parâmetro.
A ordem na qual os adaptadores aparecem em uma lista é determinada pela métrica da interface IPv4 ou IPv6.
Para obter mais informações, consulte função GetAdaptersAddresses.
Para obter links para todos os tópicos deste guia, consulte ajuste de desempenho do subsistema de rede.
Adaptadores de rede para ajuste do desempenho
13/08/2021 • 16 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Use as informações neste tópico para ajustar os adaptadores de rede de desempenho para computadores que
executam o Windows Server 2016 e versões posteriores. Se os adaptadores de rede fornecerem opções de
ajuste, você poderá usar essas opções para otimizar a taxa de transferência de rede e o uso de recursos.
As configurações de ajuste corretas para seus adaptadores de rede dependem das seguintes variáveis:
O adaptador de rede e seu conjunto de recursos
O tipo de carga de trabalho que o servidor executa
Os recursos de hardware e software do servidor
Seus objetivos de desempenho para o servidor
As seções a seguir descrevem algumas de suas opções de ajuste de desempenho.
IMPORTANT
Não use os recursos de descarregamento Descarregamento de tarefa IPSec ou descarregamento de Chimney TCP .
essas tecnologias são preteridas no Windows Server 2016 e podem afetar negativamente o desempenho do servidor e da
rede. Além disso, essas tecnologias podem não ter suporte da Microsoft no futuro.
Por exemplo, considere um adaptador de rede que tenha recursos de hardware limitados. Nesse caso, habilitar
os recursos de descarregamento de segmentação pode reduzir a taxa de transferência máxima sustentável do
adaptador. No entanto, se a taxa de transferência reduzida for aceitável, você deverá seguir um habilitar os
recursos de descarga de segmentação.
NOTE
Alguns adaptadores de rede exigem que você habilite recursos de descarregamento independentemente para os
caminhos de envio e recebimento.
NOTE
Se um adaptador de rede não expõe a configuração manual de recursos, ele configura dinamicamente os recursos ou os
recursos são definidos com um valor fixo que não pode ser alterado.
NOTE
Essa configuração não funcionará corretamente se o BIOS do sistema tiver sido definido para desabilitar o controle
do sistema operacional do gerenciamento de energia.
Habilitar descarregamentos estáticos. Por exemplo, habilite as somas de verificação de UDP, somas de
verificação de TCP e configurações de descarga grande (LSO).
Se o tráfego for de vários fluxos, como ao receber o tráfego de multicast de alto volume, habilite o RSS.
Desabilite a configuração Moderação de interrupção dos drivers da placa de rede que requerem a
menor latência possível. Lembre-se de que essa configuração pode usar mais tempo de CPU e representa
uma compensação.
Manipule as interrupções do adaptador de rede e DPCs em um processador de núcleo que compartilha
cache de CPU com o núcleo que está sendo usado pelo programa (thread de usuário) que está lidando
com o pacote. O ajuste na afinidade da CPU pode ser usado para direcionar um processo para
determinados processadores lógicos em conjunto com a configuração de RSS com essa finalidade. O uso
do mesmo núcleo para interrupção, DPC e thread de modo de usuário revela piora no desempenho na
medida em que a carga aumenta, porque o ISR, DPC e thread disputam o uso do núcleo.
NOTE
O sistema operacional não pode controlar SMIs porque o processador lógico está sendo executado em um modo de
manutenção especial, o que impede a intervenção do sistema operacional.
Ajuste de desempenho TCP
Você pode usar os seguintes itens para ajustar o desempenho de TCP.
Ajuste automática da janela de recepção TCP
no Windows Vista, Windows Server 2008 e versões posteriores do Windows, a pilha de rede Windows usa um
recurso chamado nível de ajuste da janela de recepção tcp para negociar o tamanho da janela de recepção tcp.
Esse recurso pode negociar um tamanho de janela de recebimento definido para cada comunicação TCP durante
o handshake TCP.
em versões anteriores do Windows, a pilha de rede Windows usava uma janela de recepção de tamanho fixo
(65.535 bytes) que limitou a taxa de transferência potencial geral para conexões. A taxa de transferência
atingível total de conexões TCP pode limitar os cenários de uso da rede. A janela de recepção TCP habilita esses
cenários para usar totalmente a rede.
Para uma janela de recepção TCP que tem um tamanho específico, você pode usar a equação a seguir para
calcular a taxa de transferência total de uma única conexão.
Taxa de transferência atingível total em bytes = Tamanho da janela de recepção TCP em bytes * (1/ latência
de conexão em segundos)
Por exemplo, para uma conexão que tem uma latência de 10 ms, a taxa de transferência atingível total é de
apenas 51 Mbps. Esse valor é razoável para uma grande infraestrutura de rede corporativa. No entanto, usando
a AutoAjuste para ajustar a janela de recebimento, a conexão pode atingir a taxa de linha completa de uma
conexão de 1 Gbps.
Alguns aplicativos definem o tamanho da janela de recepção TCP. Se o aplicativo não definir o tamanho da
janela de recebimento, a velocidade do link determinará o tamanho da seguinte maneira:
Menos de 1 megabit por segundo (Mbps): 8 quilobytes (KB)
1 Mbps a 100 Mbps: 17 KB
100 Mbps a 10 gigabits por segundo (Gbps): 64 KB
10 Gbps ou mais rápido: 128 KB
Por exemplo, em um computador que tem um adaptador de rede de 1 Gbps instalado, o tamanho da janela
deve ser 64 KB.
Esse recurso também faz uso completo de outros recursos para melhorar o desempenho da rede. Esses
recursos incluem o restante das opções de TCP que são definidas no RFC 1323. usando esses recursos,
computadores baseados em Windows podem negociar tamanhos de janela de recepção TCP menores, mas são
dimensionados em um valor definido, dependendo da configuração. Esse comportamento é mais fácil de lidar
com dispositivos de rede.
NOTE
Você pode enfrentar um problema em que o dispositivo de rede não está em conformidade com a opção de
dimensionamento de janela TCP , conforme definido no RFC 1323 e, portanto, não dá suporte ao fator de escala.
Nesses casos, consulte essa KB 934430, a conectividade de rede falha quando você tenta usar o Windows Vista atrás de
um dispositivo de firewall ou entre em contato com a equipe de suporte do fornecedor do dispositivo de rede.
NOTE
Para obter informações detalhadas sobre os níveis de ajuste automático disponíveis, consulte Níveis de ajuste automático.
NOTE
No comando anterior, representa <Value> o novo valor para o nível de ajuste automático.
Para obter mais informações sobre esse comando, consulte Comandos Netsh para o Protocolo de Controle de
Transmissão de Interface.
Para usar o PowerShell para revisar ou modificar o nível de ajuste automático
Para revisar as configurações atuais, abra uma janela do PowerShell e execute o cmdlet a seguir.
NOTE
No comando anterior, representa <Value> o novo valor para o nível de ajuste automático.
Para obter mais informações sobre esses cmdlets, consulte os seguintes artigos:
Get-NetTCPSetting
Set-NetTCPSetting
Níveis de ajuste automático
Você pode definir o ajuste automático da janela de recebimento para qualquer um dos cinco níveis. O nível
padrão é Normal. A tabela a seguir descreve os níveis.
Se você usar um aplicativo para capturar pacotes de rede, o aplicativo deverá relatar dados semelhantes aos
seguintes para diferentes configurações de nível de ajuste automático de janela.
Nível de ajuste automático: Normal (estado padrão)
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 = 192.169.0.5, Dest = 192.169.0.4, 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:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Ser vices\Tcpip\Parameters
NOTE
Um filtro WFP mal escrito pode diminuir significativamente o desempenho de rede de um servidor. Para obter mais
informações, consulte Portando Packet-Processing drivers e aplicativos para WFP no Windows Centro de
Desenvolvimento.
Para ver links para todos os tópicos neste guia, consulte Ajuste de desempenho do subsistema de rede.
Contadores de desempenho relacionados à rede
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Este tópico lista os contadores que são relevantes para gerenciar o desempenho de rede e contém as seções a
seguir.
Utilização de recursos
Possíveis problemas de rede
Desempenho de União lateral de recebimento (RSC)
Utilização de recursos
Os contadores de desempenho a seguir são relevantes para a utilização de recursos de rede.
IPv4, IPv6
Datagramas recebidos/s
Datagramas enviados/s
TCPv4, TCPv6
Segmentos recebidos/s
Segmentos Enviados/s
Segmentos retransmitidos/s
Interface de rede (*), adaptador de rede ( * )
Bytes Recebidos/s
Bytes Enviados/s
Pacotes recebidos/s
Pacotes enviados/s
Tamanho da Fila de Saída
Esse contador é o comprimento da fila de pacotes de saída ( em pacotes ) . Se isso for maior do
que 2, ocorrerão atrasos. Você deve encontrar o afunilamento e eliminá-lo se puder. Como o NDIS
enfileira as solicitações, esse comprimento deve ser sempre 0.
Informações do processador
% Tempo do Processador
Interrupções/s
DPCs enfileirados/s
Esse contador é uma taxa média na qual as DPCs foram adicionadas à fila de DPC do processador
lógico. Cada processador lógico tem sua própria fila de DPC. Esse contador mede a taxa na qual as
DPCs são adicionadas à fila, não o número de DPCs na fila. Ele exibe a diferença entre os valores
que foram observados nos dois últimos exemplos, divididos pela duração do intervalo de
amostragem.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para saber mais sobre as ferramentas de desempenho.
Este tópico contém seções sobre o cliente para a ferramenta de tráfego de servidor e o tamanho da janela
TCP/IP.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
neste tópico, fornecemos uma visão geral do agrupamento NIC (placa de Interface de rede) no Windows Server.
O agrupamento NIC permite que você agrupe entre um e 32 adaptadores de rede Ethernet físicos em um ou
mais adaptadores de rede virtual baseados em software. Esses adaptadores de rede virtual oferecem
desempenho rápido e tolerância a falhas no caso de uma falha do adaptador de rede.
IMPORTANT
Você deve instalar adaptadores de rede de membros da equipe NIC no mesmo computador host físico.
TIP
Uma equipe NIC que contém apenas um adaptador de rede não pode fornecer balanceamento de carga e failover. No
entanto, com um adaptador de rede, você pode usar agrupamento NIC para separação de tráfego de rede quando você
também estiver usando redes locais virtuais (VLANs).
Quando você configura adaptadores de rede em uma equipe NIC, eles se conectam à solução de agrupamento
NIC Common Core, que apresenta um ou mais adaptadores virtuais (também chamados de NICs de equipe
[tNICs] ou interfaces de equipe) ao sistema operacional.
como Windows Server 2016 dá suporte a até 32 interfaces de equipe por equipe, há uma variedade de
algoritmos que distribuem o tráfego de saída (carga) entre as NICs. A ilustração a seguir descreve uma equipe
NIC com vários tNICs.
Além disso, você pode conectar suas NICs agrupadas ao mesmo comutador ou a diferentes opções. Se você
conectar NICs a diferentes comutadores, ambos os comutadores deverão estar na mesma sub-rede.
Disponibilidade
O agrupamento NIC está disponível em todas as versões do Windows Server 2016. Você pode usar uma
variedade de ferramentas para gerenciar o agrupamento NIC de computadores que executam um sistema
operacional cliente, como:
Cmdlets do Windows PowerShell
Área de Trabalho Remota
Ferramentas de Administração de Servidor Remoto
IMPORTANT
Não coloque as NICs virtuais do Hyper-V expostas na vNICs (partição de host) em uma equipe. Não há suporte
para o agrupamento de vNICs dentro da partição de host em nenhuma configuração. Tentativas de vNICs de
equipe podem causar uma perda completa de comunicação se ocorrerem falhas de rede.
Compatibilidade
o agrupamento NIC é compatível com todas as tecnologias de rede no Windows Server 2016 com as seguintes
exceções.
Sr-IOV (vir tualização de e/s de raiz única) . Para SR-IOV, os dados são entregues diretamente à NIC
sem passá-los por meio da pilha de rede (no sistema operacional do host, no caso de virtualização).
Portanto, não é possível que a equipe NIC Inspecione ou Redirecione os dados para outro caminho na
equipe.
QoS (qualidade de ser viço) do host nativo . Quando você define políticas de QoS em um sistema
nativo ou de host, e essas políticas chamam limitações de largura de banda mínima, a taxa de
transferência geral para uma equipe NIC é menor do que seria sem as políticas de largura de banda em
vigor.
Chimney TCP . Não há suporte para TCP Chimney com agrupamento NIC porque o Chimney TCP
descarrega toda a pilha de rede diretamente para a NIC.
autenticação 802.1 x . Você não deve usar a autenticação 802.1 X com agrupamento NIC, pois algumas
opções não permitem a configuração da autenticação 802.1 X e do agrupamento NIC na mesma porta.
Para saber mais sobre como usar o agrupamento NIC em máquinas virtuais (VMs) executadas em um host
Hyper-V, confira criar uma nova equipe NIC em um computador host ou VM.
Migração dinâmica
O agrupamento NIC em VMs não afeta Migração ao Vivo. As mesmas regras existem para Migração ao Vivo se
está ou não Configurando o agrupamento NIC na VM.
Cada VM pode ter uma VF (função virtual) de uma ou ambas NICs SR-IOV e, no caso de uma desconexão NIC,
failover do VF primário para o adaptador de backup (VF). Como alternativa, a VM pode ter uma VF de uma NIC
e uma vmNIC não VF conectada a outro com switch virtual. Se a NIC associada à VF for desconectada, o tráfego
poderá fazer failover para a outra opção sem perda de conectividade.
Como o failover entre NICs em uma VM pode resultar no tráfego enviado com o endereço MAC da outra
vmNIC, cada porta do Com switch virtual do Hyper-V associada a uma VM usando o NIC Teaming deve ser
definida para permitir o teaming.
Tópicos relacionados
Uso e gerenciamento de endereços MAC de NIC Teaming:quando você configura uma equipe NIC com o
modo independente do comutamento e o hash de endereço ou a distribuição dinâmica de carga, a
equipe usa o endereço MAC (controle de acesso à mídia) do membro principal da Equipe de NIC no
tráfego de saída. O membro principal da Equipe NIC é um adaptador de rede selecionado pelo sistema
operacional do conjunto inicial de membros da equipe.
Configurações de NIC Teaming: neste tópico, apresentamos uma visão geral das propriedades da Equipe
de NIC, como modos de balanceamento de carga e de equipe. Também lhe damos detalhes sobre a
configuração do adaptador Em espera e a propriedade de interface da equipe primária. Se você tiver pelo
menos dois adaptadores de rede em uma Equipe NIC, não será necessário designar um adaptador em
espera para tolerância a falhas.
Criar uma nova Equipe NIC em um computador host ou VM:neste tópico, você cria uma nova Equipe de
NIC em um computador host ou em uma VM (máquina virtual) Hyper-V em execução Windows Server
2016.
Solução de problemas de equipe NIC:neste tópico, discutiremos maneiras de solucionar problemas de
NIC Teaming, como hardware, com switch físico e desabilitando ou habilitando adaptadores de rede
usando Windows PowerShell.
Gerenciamento e uso do endereço MAC de
agrupamento NIC
12/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Quando você configura uma Equipe NIC com o modo independente do comutamento e o hash de endereço ou
a distribuição dinâmica de carga, a equipe usa o endereço MAC (controle de acesso de mídia) do membro
principal da Equipe de NIC no tráfego de saída. O membro principal da Equipe de NIC é um adaptador de rede
que o sistema operacional seleciona no conjunto inicial de membros da equipe. É o primeiro membro da equipe
a ser associado à equipe depois que você a cria ou depois que o computador host é reiniciado. Como o membro
da equipe principal pode mudar de maneira não determinística em cada inicialização, ação de NIC
desabilitar/habilitar ou outras atividades de reconfiguração, o membro da equipe principal pode mudar e o
endereço MAC da equipe pode variar.
Na maioria das situações, isso não causa problemas, mas há alguns casos em que podem surgir problemas.
Se o membro da equipe principal for removido da equipe e colocado em operação, poderá haver um conflito de
endereço MAC. Para resolver esse conflito, desabilite e habilita a interface de equipe. O processo de
desabilitação e habilitação da interface de equipe faz com que a interface selecione um novo endereço MAC dos
membros restantes da equipe e elimina o conflito de endereço MAC.
Você pode definir o endereço MAC da equipe de NIC para um endereço MAC específico definindo-o na interface
da equipe primária, assim como você pode fazer ao configurar o endereço MAC de qualquer NIC física.
Tópicos relacionados
NIC Teaming: neste tópico, apresentamos uma visão geral do NIC (Network Interface Card) Teaming in
Windows Server 2016. O NIC Teaming permite agrupar entre um e 32 adaptadores de rede Ethernet
físicos em um ou mais adaptadores de rede virtual baseados em software. Esses adaptadores de rede
virtual fornecem desempenho rápido e tolerância a falhas em caso de falha do adaptador de rede.
Configurações de NIC Teaming: neste tópico, apresentamos uma visão geral das propriedades da Equipe
de NIC, como modos de balanceamento de carga e de equipe. Também lhe damos detalhes sobre a
configuração do adaptador Em espera e a propriedade de interface da equipe primária. Se você tiver pelo
menos dois adaptadores de rede em uma Equipe NIC, não será necessário designar um adaptador em
espera para tolerância a falhas.
Criar uma nova Equipe NIC em um computador host ou VM:neste tópico, você cria uma nova Equipe de
NIC em um computador host ou em uma VM (máquina virtual) Hyper-V em execução Windows Server
2016.
Solução de problemas de equipe NIC:neste tópico, discutiremos maneiras de solucionar problemas de
NIC Teaming, como hardware, com switch físico e desabilitando ou habilitando adaptadores de rede
usando Windows PowerShell.
Criar uma nova equipe NIC em um computador
host ou VM
12/08/2021 • 9 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Neste tópico, você criará uma nova Equipe de NIC em um computador host ou em uma VM (máquina virtual)
hyper-V em execução Windows Server 2016.
TIP
Você também pode habilitar o NIC Teaming com um Windows PowerShell comando:
3. Em Adaptadores e Interfaces , selecione um ou mais adaptadores de rede que você deseja adicionar a
uma equipe de NIC.
4. Clique em TAREFAS e clique em Adicionar à Nova Equipe.
A caixa de diálogo Nova equipe é aberta e exibe adaptadores de rede e membros da equipe.
5. Em Nome da equipe , digite um nome para a nova Equipe NIC e clique em Propriedades adicionais .
6. Em Propriedades adicionais, selecione valores para:
Modo de equipe . As opções para o modo de Equipe são Alternar Independente e Mudar
Dependente. O modo Dependente do Comutamento inclui o Teaming Estático e o LACP
(Protocolo de Controle de Agregação de Vínculo).
Alternar Independente. Com o modo Switch Independent, a opção ou as opções para as
quais os membros da Equipe NIC estão conectados não estão cientes da presença da
equipe de NIC e não determinam como distribuir o tráfego de rede para membros da
Equipe NIC – em vez disso, a equipe NIC distribui o tráfego de rede de entrada entre os
membros da Equipe NIC.
Alternar Dependente. Com os modos dependentes de switch, o comutador ao qual os
membros da equipe NIC estão conectados determina como distribuir o tráfego de rede de
entrada entre os membros da equipe NIC. A opção tem uma independência completa para
determinar como distribuir o tráfego de rede entre os membros da equipe da NIC.
M O DE DESC RIÇ Ã O
7. Se você quiser configurar o nome da interface da equipe primária ou atribuir um número de VLAN à
Equipe NIC, clique no link à direita da interface da equipe primária .
A caixa de diálogo Nova interface de equipe é aberta.
Tópicos relacionados
NIC Teaming: neste tópico, apresentamos uma visão geral do NIC (Network Interface Card) Teaming in
Windows Server 2016. O NIC Teaming permite agrupar entre um e 32 adaptadores de rede Ethernet
físicos em um ou mais adaptadores de rede virtual baseados em software. Esses adaptadores de rede
virtual oferecem desempenho rápido e tolerância a falhas no caso de uma falha do adaptador de rede.
Uso e gerenciamento de endereços MAC de NIC Teaming:quando você configura uma equipe NIC com o
modo independente do comutamento e o hash de endereço ou a distribuição dinâmica de carga, a
equipe usa o endereço MAC (controle de acesso à mídia) do membro principal da Equipe de NIC no
tráfego de saída. O membro principal da Equipe NIC é um adaptador de rede selecionado pelo sistema
operacional do conjunto inicial de membros da equipe.
Configurações de NIC Teaming: neste tópico, apresentamos uma visão geral das propriedades da Equipe
de NIC, como modos de balanceamento de carga e de equipe. Também lhe damos detalhes sobre a
configuração do adaptador Em espera e a propriedade de interface da equipe primária. Se você tiver pelo
menos dois adaptadores de rede em uma Equipe NIC, não será necessário designar um adaptador em
espera para tolerância a falhas.
Solução de problemas de equipe NIC:neste tópico, discutiremos maneiras de solucionar problemas de
NIC Teaming, como hardware, com switch físico e desabilitando ou habilitando adaptadores de rede
usando Windows PowerShell.
Solucionar problemas de agrupamento NIC
07/08/2021 • 3 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Neste tópico, discutiremos maneiras de solucionar problemas de agrupamento NIC, como valores de hardware
e comutador físico. Quando as implementações de hardware de protocolos padrão não estão em conformidade
com as especificações, o desempenho de agrupamento NIC pode ser afetado. Além disso, dependendo da
configuração, o agrupamento NIC pode enviar pacotes do mesmo endereço IP com vários endereços MAC que
podem viajar recursos de segurança no comutador físico.
Disable-NetAdapter *
Enable-NetAdapter *
Tópicos relacionados
Agrupamento NIC: neste tópico, fornecemos uma visão geral do agrupamento NIC (placa de interface de
rede) no Windows Server 2016. O agrupamento NIC permite que você agrupe entre um e 32
adaptadores de rede Ethernet físicos em um ou mais adaptadores de rede virtual baseados em software.
Esses adaptadores de rede virtual fornecem desempenho rápido e tolerância a falhas se um adaptador de
rede falhar.
Uso e gerenciamento de endereço MAC de agrupamento NIC: quando você configura uma equipe NIC
com o modo independente de comutador e o hash ou a distribuição de carga dinâmica, a equipe usa o
endereço MAC (controle de acesso à mídia) do membro da equipe NIC primário no tráfego de saída. O
membro da equipe NIC primário é um adaptador de rede que o sistema operacional seleciona do
conjunto inicial de membros da equipe.
Configurações de agrupamento NIC: neste tópico, fornecemos uma visão geral das propriedades da
equipe NIC, como os modos de agrupamento e balanceamento de carga. Também fornecemos detalhes
sobre a configuração do adaptador em espera e a propriedade da interface da equipe principal. Se você
tiver pelo menos dois adaptadores de rede em uma equipe NIC, não será necessário designar um
adaptador em espera para tolerância a falhas.
Pktmon do monitor de pacotes ()
13/08/2021 • 5 minutes to read
aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows servidor 2019, Windows 10,
Hub de Azure Stack, Azure
O monitor de pacotes (Pktmon) é uma ferramenta de diagnóstico de rede entre componentes para Windows.
Ele pode ser usado para captura de pacotes, detecção de pacotes drop, filtragem de pacotes e contagem. A
ferramenta é especialmente útil em cenários de virtualização, como rede de contêineres e SDN, pois fornece
visibilidade dentro da pilha de rede. ele está disponível na caixa por meio do comando pktmon.exe e por meio
de extensões do centro de administração do Windows.
Visão geral
Qualquer computador que se comunique pela rede tem pelo menos um adaptador de rede. Todos os
componentes entre esse adaptador e um aplicativo formam uma pilha de rede: um conjunto de componentes
de rede que processam e movem o tráfego de rede. Em cenários tradicionais, a pilha de rede é pequena e todos
os roteamentos e comutadores de pacotes ocorrem em dispositivos externos.
No entanto, com o advento da virtualização de rede, o tamanho da pilha de rede foi multiplicado. Essa pilha de
rede estendida agora inclui componentes como o comutador virtual que lida com o processamento e a
alternância de pacotes. Esse ambiente flexível permite uma maior utilização de recursos e isolamento de
segurança, mas também deixa mais espaço para erros de configuração que podem ser difíceis de diagnosticar. O
monitor de pacotes fornece a visibilidade aprimorada na pilha de rede que geralmente é necessária para
identificar esses erros.
O monitor de pacotes intercepta os pacotes em vários locais em toda a pilha de rede, expondo a rota do pacote.
Se um pacote foi descartado por um componente com suporte na pilha de rede, o monitor de pacotes relatará
esse descarte de pacotes. Isso permite que os usuários diferenciem entre um componente que é o destino
pretendido para um pacote e um componente que está interferindo com um pacote. Além disso, o monitor de
pacotes relatará os motivos de remoção; por exemplo, incompatibilidade de MTU ou VLAN filtrada, etc. Esses
motivos de eliminação fornecem a causa raiz do problema sem a necessidade de esgotar todas as
possibilidades. O monitor de pacotes também fornece contadores de pacotes para cada ponto de intercepção,
permitindo um exame de fluxo de pacotes de alto nível sem a necessidade de análise de log demorada.
Práticas Recomendadas
Use essas práticas recomendadas para simplificar a análise de rede.
Verifique a ajuda da linha de comando para obter argumentos e funcionalidades (por exemplo, pktmon Start
help).
Configure os filtros de pacote correspondentes ao seu cenário (pktmon filtro de adição).
Verifique os contadores de pacotes durante o experimento de exibição de alto nível (contadores de pktmon).
Examine o log para ver a análise detalhada (formato pktmon pktmon. ETL).
Funcionalidade
O monitor de pacotes oferece a seguinte funcionalidade:
Monitoramento e contagem de pacotes em vários locais ao longo da pilha de rede
Detecção de pacotes Drop em vários locais de pilha
Filtragem de pacotes em tempo de execução flexível com suporte para encapsulamento
Suporte a log e rastreamento geral (eventos ETW e WPP)
Análise de log TXT com base na análise de pacote TcpDump
Vários modos de log: em tempo real, alto volume na memória, vários arquivos, circular
Suporte a tipos de mídia Ethernet, Wi-Fi e móvel de banda larga
Suporte ao formato PCAPNG
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Server 2019, Windows 10,
Azure Stack Hub, Azure
O Monitor de Pacotes (Pktmon) é uma ferramenta de diagnóstico de rede entre componentes in-box para
Windows. Ele pode ser usado para captura de pacotes, detecção de soltar pacotes, filtragem e contagem de
pacotes. A ferramenta é especialmente útil em cenários de virtualização, como rede de contêiner e SDN, pois
fornece visibilidade dentro da pilha de rede. O Monitor de Pacotes está disponível na caixa por meio do
comando pktmon.exe no Windows 10 e Windows Server 2019 (versão 1809 e posterior). Você pode usar este
tópico para saber como entender a sintaxe pktmon, a formatação de comando e a saída. Para ver uma lista
completa de comandos, consulte sintaxe pktmon.
Início rápido
Use as seguintes etapas para começar a usar cenários genéricos:
1. Identifique o tipo de pacotes necessários para a captura, como endereços IP específicos, portas ou
protocolos associados ao pacote.
2. Verifique a sintaxe para aplicar filtros de captura e aplique os filtros para os pacotes identificados na
etapa anterior.
4. Reproduza o problema que está sendo diagnosticada. Contadores de consulta para confirmar a presença
do tráfego esperado e obter uma exibição de alto nível de como o tráfego fluia no computador.
Consulte Analisar a saída do Monitor de Pacotes para obter instruções sobre como analisar a saída txt.
Capturar filtros
É altamente recomendável aplicar filtros antes de iniciar qualquer captura de pacote, pois a solução de
problemas de conectividade com um destino específico é mais fácil quando você se concentra em um único
fluxo de pacotes. Capturar todo o tráfego de rede pode tornar a saída muito barulhento para analisar. Para que
um pacote seja relatado, ele deve corresponder a todas as condições especificadas em pelo menos um filtro. Há
suporte para até 32 filtros ao mesmo tempo.
Por exemplo, o conjunto de filtros a seguir capturará qualquer tráfego ICMP de ou para o endereço IP 10.0.0.10,
bem como qualquer tráfego na porta 53.
Funcionalidade de filtragem
O Monitor de Pacotes dá suporte à filtragem por endereços MAC, endereços IP, portas, EtherType,
protocolo de transporte e ID de VLAN.
O Monitor de Pacotes não distinguirá entre a origem ou o destino quando se trata de endereço MAC,
endereço IP ou filtros de porta.
Para filtrar ainda mais os pacotes TCP, uma lista opcional de sinalizadores TCP para corresponder pode
ser fornecida. Os sinalizadores com suporte são FIN, SYN, RST, PSH, ACK, LTDA, ECE e CWR.
Por exemplo, o filtro a seguir capturará todos os pacotes SYN enviados ou recebidos pelo endereço IP
10.0.0.10:
O Monitor de Pacotes pode aplicar um filtro a pacotes internos encapsulados, além do pacote externo, se o
sinalizador [-e] tiver sido adicionado a qualquer filtro. Os métodos de encapsulamento com suporte são
VXLAN, GRE, NVGRE e IP em IP. A porta VXLAN personalizada é opcional e o padrão é 4789.
Para obter mais informações, consulte sintaxe de filtro pktmon.
O comando a seguir capturará apenas os pacotes descartados que passam pelos componentes 4 e 5 e os
registrará em log:
NOTE
*Use os hiperlinks acima para saber como analisar e analisar logs do Monitor de Pacotes no Wireshark e Monitor de
Rede .
Para correlacionar todos os instantâneos dos mesmos pacotes, monitore os valores PktGroupId e PktNumber
(realçadas em amarelo); todos os instantâneos do mesmo pacote devem ter esses dois valores em comum. O
valor aparência (realçada em azul) atua como um contador para cada instantâneo subsequente do mesmo
pacote. Por exemplo, o primeiro instantâneo do pacote (em que o pacote apareceu pela primeira vez na pilha de
rede) tem o valor 1 para aparência, o próximo instantâneo tem o valor 2 e assim por diante.
Cada instantâneo de pacote tem uma ID de componente (sublinhada na imagem acima) que denota o
componente associado ao instantâneo. Para resolver o nome do componente e os parâmetros, pesquise essa ID
de componente na lista de componentes na parte inferior do arquivo de log. Uma parte da tabela componentes
é mostrada na imagem abaixo realçando "Componente 1" em amarelo (esse era o componente em que o último
instantâneo acima foi capturado). Componentes com duas bordas relatarão dois instantâneos em cada borda
(como os instantâneos com a Aparência 3 e a Aparência 4, por exemplo, na imagem acima).
Na parte inferior de cada arquivo de log, a lista de filtros é apresentada conforme mostrado na imagem abaixo
(realçada em azul). Cada filtro exibe os parâmetros especificados (PROTOCOLO ICMP no exemplo abaixo) e
zeros para o restante dos parâmetros.
Para pacotes descartados, a palavra "soltar" aparece antes de qualquer uma das linhas que representam o
instantâneo em que o pacote foi descartado. Cada pacote descartado também fornece um valor dropReason.
Esse parâmetro dropReason fornece uma breve descrição do motivo para soltar o pacote; por exemplo,
incompatibilidade de MTU, VLAN filtrada, etc.
Contadores de pacotes
Os contadores de monitor de pacotes fornecem uma exibição de alto nível do tráfego de rede em toda a pilha
de rede sem a necessidade de analisar um log, o que pode ser um processo caro. Examine os padrões de tráfego
consultando contadores de pacotes com contadores pktmon depois de iniciar a captura do monitor de
pacotes. Redefina os contadores para zero usando pktmon Reset ou pare de monitorar todos juntos usando
pktmon Stop .
Os contadores são organizados por pilhas de associação com adaptadores de rede na parte superior e
protocolos na parte inferior.
TX/RX: os contadores são separados em duas colunas para as direções enviar (TX) e receber (RX).
Bordas: os componentes relatam a propagação de pacotes quando um pacote está ultrapassando o limite do
componente (borda). Cada componente pode ter uma ou mais bordas. Os drivers de miniporta normalmente
têm borda superior única, os protocolos têm borda inferior única e os drivers de filtro têm bordas superiores
e inferiores.
Quedas: os contadores de remoção de pacotes estão sendo relatados na mesma tabela.
No exemplo a seguir, uma nova captura foi iniciada, então o comando pktmon Counters foi usado para
consultar os contadores antes da interrupção da captura. Os contadores mostram um único pacote que o torna
fora da pilha de rede, começando da camada de protocolo até o adaptador de rede física e sua resposta volta na
outra direção. Se o ping ou a resposta estava ausente, é fácil detectá-lo por meio dos contadores.
No exemplo a seguir, os descartes são relatados na coluna "Counter". Recupere a última razão de descarte para
cada componente solicitando dados de contadores no formato JSON usando contadores pktmon--JSON ou
analise o log de saída para obter informações mais detalhadas.
Conforme mostrado nesses exemplos, os contadores podem fornecer muitas informações por meio de um
diagrama que pode ser analisado apenas com uma aparência rápida.
Para obter mais informações, consulte sintaxe de contadores de pktmon.
NOTE
As IDs não são persistentes e podem ser alteradas entre as reinicializações e as reinicializações do driver do monitor de
pacotes.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Server 2019, Windows 10,
Azure Stack Hub, Azure
A extensão monitoramento de pacotes permite que você opere e consuma o Monitor de Pacotes por meio
Windows Admin Center. A extensão ajuda você a diagnosticar sua rede capturando e exibindo o tráfego de rede
por meio da pilha de rede em um log fácil de seguir e manipular.
Antes de começar
Para usar a ferramenta, o servidor de destino precisa estar executando Windows Server 2019 versão 1903
(19H1) e superior.
Instalar o Windows Admin Center.
Adicione um servidor ao Windows Admin Center:
1. Clique em + Adicionar em Todas as Conexões .
2. Escolha adicionar uma Conexão de Servidor.
3. Digite o nome do servidor e, se solicitado, as credenciais a usar.
4. Clique em Enviar para concluir.
O servidor será adicionado à sua lista de conexões na página Visão geral.
Introdução
Para acessar a ferramenta, navegue até o servidor que você criou na etapa anterior e vá para a extensão
"Monitoramento de pacotes".
Aplicação de filtros
É altamente recomendável aplicar filtros antes de iniciar qualquer captura de pacote, pois a solução de
problemas de conectividade com um destino específico é mais fácil ao se concentrar em um único fluxo de
pacotes. Por outro lado, capturar todo o tráfego de rede pode tornar a saída muito barulhento para analisar. Da
mesma forma, a extensão orienta você para o painel de filtros primeiro antes de iniciar a captura. Você pode
ignorar esta etapa clicando em Próximo para iniciar a captura sem filtros. O painel filtros orienta você a
adicionar filtros em três etapas.
1. Filtragem por componentes de pilha de rede
Se você quiser capturar o tráfego que passa apenas por componentes específicos, a primeira etapa do
painel filtros mostrará o layout da pilha de rede para que você possa selecionar os componentes pelos
qual filtrar. Esse também é um ótimo lugar para analisar e entender o layout da pilha de rede do
computador.
Posteriormente, um resumo de todas as condições de filtro selecionadas é exibido para revisão. Você
poderá recuperar essa exibição depois de iniciar a captura por meio do botão Condições de Captura.
Log de captura
Os resultados são exibidos em uma tabela que mostra os principais parâmetros dos pacotes capturados:
Timestamp, Sources IP Address, Source Port, Destination IP Address, Destination Port, Ethertype, Protocol, TCP
Flags, whether the packet was dropped, and the drop reason.
O timestamp para cada um desses pacotes também é um hiperlink que redireciona você para uma página
diferente, na qual você pode encontrar mais informações sobre o pacote selecionado. Consulte a seção
Página de Detalhes abaixo.
Todos os pacotes descartados têm um valor "True" na guia Descartado, um motivo para soltar e são exibidos
em texto vermelho para facilitar a localização.
Todas as guias podem ser ordenadas em ordem crescente e decrescente.
Você pode pesquisar um valor em qualquer coluna no log usando a barra de pesquisa.
Você pode reiniciar a captura com os mesmos filtros escolhidos usando o botão Reiniciar.
Página de detalhes
Esta página apresenta um instantâneo do pacote conforme ele flui por cada componente da pilha de rede local.
Essa exibição mostra o caminho do fluxo de pacotes e permite que você investigue como os pacotes mudam
conforme eles são processados por cada componente que passam.
Os instantâneos de pacote são agrupados por cada pilha de adaptador/comporte; Ou seja, instantâneos de
pacote capturados por um adaptador/com switch, seus drivers de filtro e seus drivers de protocolo serão
agrupados sob o nome do adaptador/opção. Isso facilitará o acompanhamento do fluxo do pacote de um
adaptador para o outro.
Quando um instantâneo é selecionado, mais detalhes sobre esse instantâneo específico são mostrados,
incluindo os headers de pacotes brutos.
Todos os pacotes descartados têm um valor "True" na guia Descartado, um motivo para soltar e são exibidos
em texto vermelho para facilitar a localização.
Exibir filtros
Os filtros de exibição permitem filtrar o log depois de capturar os pacotes. Para cada filtro, você pode especificar
parâmetros de pacote como Endereços MAC, Endereços IP, Portas, Ethertype e Protocolo de Transporte. Ao
contrário dos filtros de captura:
Os filtros de exibição podem distinguir entre a origem e o destino de Endereços IP, Endereços MAC e Portas.
Os filtros de exibição podem ser excluídos e editados após a aplicação para alterar a exibição do log.
Os filtros de exibição são invertidos nos logs salvos.
Salvar recurso
O botão Salvar permite salvar o log no computador local, no computador remoto ou em ambos. Os filtros de
exibição serão invertidos no log salvo.
Se o log for salvo no computador local, você poderá salvá-lo em vários formatos:
Formato ETL que pode ser analisado usando Monitor de Rede da Microsoft. Observação: verifique esta
página para obter mais informações.
Formato de texto que pode ser analisado usando qualquer editor de texto como TextAnalysisTool.NET.
Formato Pcapng que pode ser analisado usando ferramentas como Wireshark.
A maioria dos metadados do Monitor de Pacotes será perdida durante essa conversão. Confira esta
página para obter mais informações.
Abrir recurso
O recurso aberto permitirá que você reabra qualquer um dos cinco últimos logs salvos para analisar por meio
da ferramenta.
Extensão de diagnóstico de caminho de dados SDN
no Windows Admin Center
13/08/2021 • 5 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Server 2019, Windows 10,
Azure Stack Hub, Azure
O Diagnóstico de Caminho de Dados SDN é uma ferramenta dentro da extensão de monitoramento SDN do
Centro de Administração do Windows que automatiza capturas de pacotes baseadas no Monitor de Pacotes de
acordo com vários cenários de SDN e apresenta a saída em uma única exibição que é fácil de seguir e manipular.
Antes de começar
Para usar a ferramenta, o servidor de destino precisa estar executando Windows Server 2019 versão 1903
(19H1) e superior.
Instalar o Windows Admin Center.
Adicione um cluster ao Windows Admin Center:
1. Clique em + Adicionar em Todas as Conexões .
2. Escolha adicionar uma conexão Hyper-Converged cluster.
3. Digite o nome do cluster e, se solicitado, as credenciais a usar.
4. Marque Configurar o Controlador de Rede para continuar.
5. Insira o URI do Controlador de Rede e clique em Validar .
6. Clique em Adicionar para concluir.
O cluster será adicionado à lista de conexões. Clique nele para iniciar o Painel.
Introdução
Para acessar a ferramenta, navegue até o cluster que você criou na etapa anterior e, em seguida, para a extensão
"Monitoramento de SDN" e, em seguida, para a guia "Diagnóstico de Caminho de Dados".
Selecionando cenários
A primeira página lista todos os cenários de SDN classificados como cenários de carga de trabalho e cenários de
infraestrutura, conforme mostrado na imagem abaixo. Para começar, selecione o cenário de SDN que precisa ser
diagnosticada.
Parâmetros de cenário
Depois de escolher o cenário, preencha uma lista de parâmetros obrigatórios e opcionais para iniciar a captura.
Esses parâmetros básicos apontarão a ferramenta para a conexão que precisa ser diagnosticada. Em seguida, a
ferramenta usará esses parâmetros para que as consultas executem uma captura bem-sucedida, sem nenhuma
intervenção do usuário para descobrir o fluxo de pacotes esperado, os máquinas envolvidas no cenário, sua
localização no cluster ou os filtros de captura a aplicar em cada computador. Os parâmetros obrigatórios
permitem que a captura seja executado e os parâmetros opcionais ajudam a filtrar algum ruído.
Log de captura
Depois de iniciar a captura, a extensão mostrará uma lista dos máquinas em que a captura está iniciando. Você
poderá ser solicitado a entrar nesses máquinas se suas credenciais não foram salvas. Você pode começar
reproduzindo o ping ou o problema que está tentando diagnosticar capturando os pacotes relativos. Depois que
os pacotes são capturados, a extensão mostrará marcas ao lado dos máquinas em que os pacotes foram
capturados.
Depois de interromper a captura, os logs de todos os máquinas serão mostrados em uma única página, dividida
pelo título do computador. Cada título incluirá o nome do computador, sua função no cenário e seu host no caso
de VMs (máquinas virtuais).
Os resultados são exibidos em uma tabela que mostra os principais parâmetros dos pacotes capturados:
Timestamp, Sources IP Address, Source Port, Destination IP Address, Destination Port, Ethertype, Protocol, TCP
Flags, whether the packet was dropped, and the drop reason.
O timestamp para cada um desses pacotes também é um hiperlink que redireciona você para uma página
diferente, na qual você pode encontrar mais informações sobre o pacote selecionado. Consulte a seção
Página de Detalhes abaixo.
Todos os pacotes descartados têm um valor "True" na guia Descartado, um motivo para soltar e são exibidos
em texto vermelho para facilitar a localização.
Todas as guias podem ser ordenadas em ordem crescente e decrescente.
Você pode pesquisar um valor em qualquer coluna no log usando a barra de pesquisa.
Você pode reiniciar a captura com os mesmos filtros escolhidos usando o botão Reiniciar.
Página de detalhes
As informações nesta página são particularmente valiosas se você tiver problemas de propagação de pacotes
incorretos ou problemas de configuração incorreta, pois você pode investigar o fluxo do pacote por meio de
cada componente da pilha de rede. Para cada salto de pacote, há detalhes que incluem os parâmetros de pacote,
bem como os detalhes brutos do pacote.
Os saltos são agrupados com base nos componentes envolvidos. Cada adaptador e os drivers sobre ele são
agrupados pelo nome do adaptador. Isso facilita o controle do pacote em um alto nível por meio desses
títulos de grupo.
Todos os pacotes descartados também serão exibidos em texto vermelho para facilitar a localização.
Selecione um salto para exibir mais detalhes. Em cenários de encapsulamento e NAT (Conversão de Endereços
de Rede), esse recurso permite que você veja o pacote mudando conforme ele passa pela pilha de rede e verifica
se há problemas de configuração incompatibilidade.
Salvar
O botão Salvar permite que você salve o log em seu computador local para análise posterior por meio de outras
ferramentas. Os filtros de exibição serão invertidos no log salvo. Os logs podem ser salvos em vários formatos:
Formato ETL que pode ser analisado usando Monitor de Rede da Microsoft. Observação: verifique esta
página para obter mais informações.
Formato de texto que pode ser analisado usando qualquer editor de texto como TextAnalysisTool.NET.
Formato Pcapng que pode ser analisado usando ferramentas como Wireshark.
A maioria dos metadados do Monitor de Pacotes será perdida durante essa conversão. Observação:
verifique esta página para obter mais informações.
Suporte a Pktmon para Monitor de Rede da
Microsoft (Netmon)
07/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Server 2019, Windows 10,
Azure Stack Hub, Azure
O Monitor de Pacotes (Pktmon) gera logs no formato ETL. Esses logs podem ser analisados usando Monitor de
Rede da Microsoft (Netmon) usando analisadores especiais. Este tópico explica como analisar arquivos ETL
gerados pelo Monitor de Pacotes no Netmon.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Server 2019, Windows 10,
Azure Stack Hub, Azure
O Monitor de Pacotes (Pktmon) pode converter logs no formato pcapng. Esses logs podem ser analisados
usando Wireshark (ou qualquer analisador pcapng); no entanto, algumas das informações críticas podem estar
ausentes nos arquivos pcapng. Este tópico explica a saída esperada e como tirar proveito dela.
-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.
Filtragem de saída
Todas as informações sobre os relatórios de rebaixamento de pacotes e o fluxo de pacotes pela pilha de rede
serão perdidas na saída pcapng. Portanto, o conteúdo do log deve ser cuidadosamente pré-filtrado para essa
conversão. Por exemplo:
O formato Pcapng não faz distinção entre um pacote de fluxo e um pacote descartado. Para separar todos os
pacotes na captura de pacotes descartados, gere dois arquivos pcapng; um que contém todos os pacotes
("pktmon pcapng log.etl --out log-capture.etl ") e outro que contém apenas pacotes descartados
("pktmon pcapng log.etl --drop-only --out log-drop.etl "). Dessa forma, você poderá analisar os
pacotes descartados em um log separado.
O formato Pcapng não distingue entre diferentes componentes de rede em que um pacote foi capturado.
Para esses cenários multicamadas, especifique a ID de componente desejada na saída pcapng "pktmon
pcapng log.etl --component-id 5 ". Repita esse comando para cada conjunto de IDs de componente em
que você está interessado.
Qualidade da ( política de QoS de serviço )
13/08/2021 • 7 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar a Política de QoS como um ponto central de gerenciamento de largura de banda de rede em
toda sua infraestrutura do Active Directory por meio da criação de perfis de QoS, cujas configurações são
distribuídas com a Política de Grupo.
NOTE
Além deste tópico, a documentação de política de QoS a seguir está disponível.
Introdução com a política de QoS
Gerenciar política de QoS
Perguntas frequentes sobre a política de QoS
As políticas de QoS são aplicadas a uma sessão de logon de usuário ou a um computador como parte de um
GPO de Política de Grupo objeto ( ) que você vinculou a um contêiner de Active Directory, como um domínio,
site ou UO da unidade organizacional ( ) .
O gerenciamento de tráfego de QoS ocorre abaixo da camada de aplicativo, o que significa que os aplicativos
existentes não precisam ser modificados para se beneficiarem das vantagens fornecidas pelas políticas de QoS.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar os tópicos a seguir para começar com a qualidade da ( política de QoS de serviço ) .
Como funciona a política de QoS
Arquitetura de política de QoS
Cenários de política de QoS
Para o primeiro tópico deste guia, consulte política de QoS (qualidade de serviço).
Como funciona a política de QoS
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para saber mais sobre a arquitetura da Política de QoS.
A figura a seguir mostra a arquitetura da QoS baseada em políticas.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para analisar cenários hipotéticos que demonstram como, quando e por que usar a
Política de QoS.
Os dois cenários neste tópico são:
1. Priorizar o tráfego de rede para um aplicativo de linha de negócios
2. Priorizar o tráfego de rede para um aplicativo de servidor HTTP
NOTE
Algumas seções deste tópico contêm etapas gerais que você pode executar para executar as ações descritas. Para obter
instruções mais detalhadas sobre como gerenciar a política de QoS, consulte Gerenciar política de QoS.
NOTE
Para obter mais informações sobre o DSCP, consulte a seção Definir prioridade de QoS por meio de um ponto de
código Serviços Diferenciados no tópico Política de QoS (Qualidadede Serviço).
Além dos valores DSCP, as políticas de QoS podem especificar uma taxa de aceleração. A limitação tem o efeito
de limitar todo o tráfego de saída que corresponde à Política de QoS a uma taxa de envio específica.
Configuração de política de QoS
Com três metas separadas para realizar, o administrador de IT decide criar três políticas de QoS diferentes.
Política de QoS para servidores de aplicativos LOB
O primeiro aplicativo crítico para o qual o departamento de IT cria uma Política de QoS é um aplicativo ERP de
planejamento de recursos de toda - - a Enterprise ( ) empresa. O aplicativo ERP é hospedado em vários
computadores que estão executando Windows Server 2016. No Active Directory Domain Services, esses
computadores são membros de uma UO de unidade da organização que foi criada para servidores de
aplicativos LOB de linha ( ) de ( ) negócios. O componente do lado do cliente para o aplicativo ERP é instalado
em computadores que estão executando Windows 10 - e Windows 8.1.
No Política de Grupo, um administrador de IT seleciona o GPO Política de Grupo objeto ao qual a ( ) política de
QoS será aplicada. Usando o assistente de política de QoS, o administrador de IT cria uma política de QoS
chamada "Política lob do servidor" que especifica um valor DSCP de alta prioridade de 44 para todos os
aplicativos, qualquer endereço IP, TCP e UDP e número da - porta.
A política de QoS é aplicada somente aos servidores LOB vinculando o GPO à UO que contém apenas esses
servidores, por meio da ferramenta Console de Gerenciamento de Política de Grupo ( ) GPMC. Essa política de
LOB do servidor inicial aplica o valor DSCP de alta - prioridade sempre que o computador envia o tráfego de
rede. Essa política de QoS pode ser editada posteriormente na ferramenta Editor de Objeto de Política de Grupo
para incluir os números de porta do aplicativo ERP, que limita a política a ser aplicada somente quando o
número da porta especificado ( ) é usado.
Política de QoS para o grupo financeiro
Embora muitos grupos dentro da empresa acessem o aplicativo ERP, o grupo financeiro depende desse
aplicativo ao lidar com clientes, e o grupo requer um desempenho consistentemente alto do aplicativo.
Para garantir que o grupo financeiro possa dar suporte a seus clientes, a política de QoS deve classificar o
tráfego desses usuários como de alta prioridade. No entanto, a política não deve ser aplicada quando os
membros do grupo financeiro usam aplicativos diferentes do aplicativo ERP.
Por isso, o departamento de IT define uma segunda política de QoS chamada "Política lob do cliente" na
ferramenta Editor de Objeto de Política de Grupo que aplica um valor DSCP de 60 quando o grupo de usuários
financeiros executa o aplicativo ERP.
Política de QoS para um aplicativo de backup
Um aplicativo de backup separado está em execução em todos os computadores. Para garantir que o tráfego do
aplicativo de backup não use todos os recursos de rede disponíveis, o departamento de IT cria uma política de
dados de backup. Essa política de backup especifica um valor DSCP de 1 com base no nome executável do
aplicativo de backup, que é backup.exe .
Um terceiro GPO é criado e implantado para todos os computadores cliente no domínio. Sempre que o
aplicativo de backup envia dados, o valor DSCP de baixa prioridade é aplicado, mesmo se ele se origina de
computadores no departamento financeiro.
NOTE
O tráfego de rede sem uma Política de QoS envia com um valor DSCP de 0.
Políticas de cenário
A tabela a seguir resume as políticas de QoS para esse cenário.
A P L IC A DO À S
TA XA DE UN IDA DES DA
N O M E DE P O L ÍT IC A VA LO R DSC P A C EL ERA Ç Ã O O RGA N IZ A Ç Ã O DESC RIÇ Ã O
NOTE
Os valores DSCP são representados na forma decimal.
Com as políticas de QoS definidas e aplicadas usando Política de Grupo, o tráfego de rede de saída recebe o
valor DSCP especificado pela política. Os roteadores fornecem tratamento diferencial com base nesses valores
DSCP usando a fila. Para esse departamento de IT, os roteadores são configurados com quatro filas: alta
prioridade, prioridade intermediária, melhor esforço e baixa prioridade.
Quando o tráfego chega ao roteador com valores DSCP de "Política lob do servidor" e "política lob do cliente",
os dados são colocados em filas de alta prioridade. O tráfego com um valor DSCP de 0 recebe um nível de
serviço de melhor esforço. Pacotes com um valor DSCP de 1 (do aplicativo de backup) recebem tratamento de
baixa prioridade.
Pré -requisitos para priorizar um aplicativo de linha de negócios
Para concluir essa tarefa, certifique-se de atender aos seguintes requisitos:
Os computadores envolvidos estão executando sistemas operacionais compatíveis - com QoS.
Os computadores envolvidos são membros de um domínio Active Directory Domain Services AD DS
para que possam ser ( ) configurados usando Política de Grupo.
As redes TCP/IP são configuradas com roteadores configurados para o DSCP ( RFC 2474. ) Para obter
mais informações, consulte RFC 2474.
Os requisitos de credenciais administrativas são atendidos.
Credenciais administrativas
Para concluir essa tarefa, você deve ser capaz de criar e implantar Política de Grupo Objetos.
Configurando o ambiente de teste para priorizar um aplicativo de linha de negócios
Para configurar o ambiente de teste, conclua as tarefas a seguir.
Crie um AD DS domínio com clientes e usuários agrupados em unidades da organização. Para obter
instruções sobre como implantar AD DS, consulte o Guia de rede principal.
Configure os roteadores para enfil de forma diferencial com base em valores DSCP. Por exemplo, o valor
DSCP 44 entra em uma fila "Platinum" e todos os outros são ponderados com fila justa.
NOTE
Você pode exibir valores DSCP usando capturas de rede com ferramentas como Monitor de Rede. Depois de executar uma
captura de rede, você pode observar o campo TOS nos dados capturados.
Etapas para priorizar um aplicativo de linha de negócios
Para priorizar um aplicativo de linha de negócios, conclua as seguintes tarefas:
1. Crie e vincule um GPO Política de Grupo objeto ( com uma política de ) QoS.
2. Configure os roteadores para tratar diferencialmente um aplicativo de linha de negócios (usando en fila)
com base nos valores DSCP selecionados. Os procedimentos dessa tarefa variam dependendo do tipo de
roteadores que você tem.
NOTE
Você não pode usar políticas de QoS baseadas em URL para priorizar o tráfego de rede para computadores que executam
sistemas operacionais Windows que foram lançados antes do Windows 7 e Windows Server 2008 R2.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar este tópico para saber mais sobre como usar o assistente de política de QoS para criar, editar ou
excluir uma política de QoS.
NOTE
Além deste tópico, a documentação de gerenciamento de política de QoS a seguir está disponível.
Eventos e erros da política de QoS
em sistemas operacionais Windows, a política de QoS combina a funcionalidade de QoS baseada em padrões
com a capacidade de gerenciamento de Política de Grupo. A configuração dessa combinação torna o aplicativo
fácil de políticas de QoS para Política de Grupo objetos. o Windows inclui um assistente de política de QoS para
ajudá-lo a realizar as tarefas a seguir.
Criar uma política de QoS
Exibir, editar ou excluir uma política de QoS
NOTE
por padrão, Windows tráfego tem um valor DSCP de 0.
O número de filas e seu comportamento de priorização devem ser planejados como parte da estratégia de QoS
de sua organização. Por exemplo, sua organização pode optar por ter cinco filas: tráfego sensível à latência,
tráfego de controle, tráfego crítico para os negócios, tráfego de melhor esforço e tráfego de transferência de
dados em massa.
Acelerando o tráfego
Juntamente com valores DSCP, a limitação é outro controle de chave para gerenciar a largura de banda da rede.
Conforme mencionado anteriormente, você pode usar a configuração especificar taxa de restrição para
configurar uma política de QoS com uma taxa de limitação específica para o tráfego de saída. Usando a
limitação, uma política de QoS limita o tráfego de rede de saída para uma taxa de limitação especificada. A
aceleração e a marcação de DSCP podem ser usadas juntas para gerenciar o tráfego de maneira eficiente.
NOTE
Por padrão, a caixa de seleção Especificar Taxa de Aceleração não está marcada.
Para criar uma política de QoS, edite as configurações de um objeto de Política de Grupo (GPO) de dentro da
ferramenta Console de Gerenciamento de Política de Grupo (GPMC). Em seguida, o GPMC abre a Editor de
Objeto de Política de Grupo.
Os nomes das políticas de QoS devem ser exclusivos. Como as políticas são aplicadas a servidores e usuários
finais depende de onde a política de QoS é armazenada no Editor de Objeto de Política de Grupo:
uma política de QoS na configuração do computador \ Windows Configurações política \QoS se aplica a
computadores, independentemente do usuário que estiver conectado no momento. Normalmente, você
usa políticas de QoS baseadas no computador em servidores.
uma política de QoS na configuração do usuário \ Windows Configurações política \QoS se aplica aos
usuários depois que eles tiverem feito logon, independentemente de em qual computador eles fizeram
logon.
Para criar uma nova política de QoS com o assistente de política de QoS
No Editor de Objeto de Política de Grupo, clique com o botão direito do mouse em um dos nós da política
de QoS e clique em criar uma nova política .
Página 1 do assistente -perfil de política
Na primeira página do assistente de política de QoS, você pode especificar um nome de política e configurar
como o QoS controla o tráfego de rede de saída.
Para configurar a página Perfil da Política do Assistente de QoS Baseado em Política
1. Em Nome da política , digite um nome para a política de QoS. O nome deve identificar a política de
forma exclusiva.
2. Opcionalmente, use especificar valor DSCP para habilitar a marcação DSCP e, em seguida, configure
um valor DSCP entre 0 e 63.
3. Como opção, use Especificar Taxa de Aceleração para habilitar a aceleração de tráfego e configurar a
taxa de aceleração. O valor da taxa de limitação deve ser maior que 1 e você pode especificar unidades de
kilobytes por segundo, ( kbps ) ou megabytes por segundo ( Mbps ) .
4. Clique em Próximo .
Página 2 do assistente -nome do aplicativo
Na segunda página do assistente de política de QoS, você pode aplicar a política a todos os aplicativos, a um
aplicativo específico, conforme identificado pelo nome do executável, para um caminho e nome de aplicativo, ou
para os aplicativos de servidor HTTP que lidam com solicitações de uma URL específica.
Todos os aplicativos especifica que as configurações de gerenciamento de tráfego na primeira página
do assistente de política de QoS se aplicam a todos os aplicativos.
Somente aplicativos com esse nome executável especificam que as configurações de
gerenciamento de tráfego na primeira página do assistente de política de QoS são para um aplicativo
específico. O nome do arquivo executável deve terminar com a extensão de nome de arquivo .exe.
Somente aplicativos de ser vidor http respondendo a solicitações para esta URL especifica que
as configurações de gerenciamento de tráfego na primeira página do assistente de política de QoS se
aplicam apenas a determinados aplicativos de servidor http.
Como opção, você pode inserir o caminho do aplicativo. Para especial um caminho de aplicativo, inclua o
caminho com o nome do aplicativo. O caminho pode incluir variáveis de ambiente. Por exemplo,
%ProgramFiles%\Caminho do Meu Aplicativo\MeuAplicativo.exe ou c:\arquivos de programas\caminho do meu
aplicativo\meuaplicativo.exe.
NOTE
O caminho do aplicativo não pode incluir um caminho que resolva um link simbólico.
Se você selecionar ambos apenas para o endereço IP de origem a seguir e apenas para o endereço IP
de destino a seguir , os endereços ou prefixos de endereço deverão ser baseados em IPv4 ou IPv6.
Se você especificou a URL para aplicativos de servidor HTTP na página anterior do assistente, observará que o
endereço IP de origem da política de QoS nesta página do assistente está esmaecido.
Isso é verdadeiro porque o endereço IP de origem é o endereço do servidor HTTP e não é configurável aqui. Por
outro lado, você ainda pode personalizar a política especificando o endereço IP de destino. Isso possibilita que
você crie políticas diferentes para clientes diferentes usando os mesmos aplicativos de servidor HTTP.
Para configurar a página endereços IP do assistente de política de QoS
1. Nesta política de QoS aplica-se a (origem), selecione qualquer endereço IP de origem ou apenas
para o endereço de origem IP a seguir .
2. Se você selecionou apenas o endereço de origem IP a seguir , especifique um endereço ou prefixo
IPv4 ou IPv6.
3. Nesta política de QoS aplica-se a (destino), selecione qualquer endereço de destino ou apenas
para o endereço IP de destino a seguir.
4. Se você selecionou apenas para o endereço IP de destino a seguir , especifique um endereço IPv4
ou IPv6 ou prefixo que corresponda ao tipo de endereço ou prefixo especificado para o endereço de
origem.
5. Clique em Próximo .
Página 4 do assistente -protocolos e portas
Na quarta página do assistente de política de QoS, você pode especificar os tipos de tráfego e as portas que são
controladas pelas configurações na primeira página do assistente. É possível especificar:
Tráfego TCP, tráfego UDP ou os dois
Todas as portas de origem, um intervalo de portas de origem ou uma porta de origem específica
Todas as portas de destino, um intervalo de portas de destino ou uma porta de destino específica
Para configurar a página protocolos e portas do assistente de política de QoS
1. Em Selecionar o protocolo ao qual esta política de QoS se aplica , selecione TCP , UDP ou TCP e
UDP .
2. Em Especifique o número da por ta de origem , selecione De qualquer por ta de origem ou Deste
número de por ta de origem .
3. Se você selecionou a par tir desse número de por ta de origem , digite um número de porta entre 1 e
65535.
Opcionalmente, você pode especificar um intervalo de portas, no formato "baixo:alto", onde baixo e alto
representam os limites inferiores e limites superiores do intervalo de portas, inclusive. Baixo e alto
devem ser um número entre 1 e 65535. Não são permitidos espaços entre o caractere de dois pontos (:)
e os números.
4. Em Especifique o número da por ta de destino , selecione Para qualquer por ta de destino ou
Para este número de por ta de destino .
5. Se você selecionou Para este número de por ta de destino na etapa anterior, digite um número de
porta entre 1 e 65535.
Para concluir a criação da nova política de QoS, clique em concluir na página protocolos e por tas do
assistente de política de QoS. Quando concluído, a nova política de QoS é listada no painel de detalhes do Editor
de Objeto de Política de Grupo.
Para aplicar as configurações de política de QoS a usuários ou computadores, vincule o GPO no qual as políticas
de QoS estão localizadas em um contêiner Active Directory Domain Services, como um domínio, um site ou
uma UO (unidade organizacional).
Exibir, editar ou excluir uma política de QoS
As páginas do assistente de política de QoS descritas anteriormente correspondem às páginas de propriedades
que são exibidas quando você exibe ou edita as propriedades de uma política.
Para exibir as propriedades de uma política de QoS
Clique com o botão direito do mouse no nome da política no painel de detalhes da Editor de Objeto de
Política de Grupo e clique em Propriedades .
O Editor de Objeto de Política de Grupo exibe a página Propriedades com as seguintes guias:
Perfil da Política
Nome do Aplicativo
Endereços IP
Protocolos e portas
Para editar uma política de QoS
Clique com o botão direito do mouse no nome da política no painel de detalhes da Editor de Objeto de
Política de Grupo e clique em Editar política existente .
O Editor de Objeto de Política de Grupo exibe a caixa de diálogo Editar uma política de QoS existente
.
Para excluir uma política de QoS
Clique com o botão direito do mouse no nome da política no painel de detalhes da Editor de Objeto de
Política de Grupo e clique em excluir política .
Relatórios GPMC de política de QoS
Depois de ter aplicado uma série de políticas de QoS em sua organização, pode ser útil ou necessário examinar
periodicamente como as políticas são aplicadas. Um resumo das políticas de QoS para um usuário ou
computador específico pode ser exibido usando os relatórios do GPMC.
Para executar o assistente de resultados de Política de Grupo para um relatório de políticas de QoS
No GPMC, clique com o botão direito do mouse no nó política de grupo resultados e selecione a opção
de menu para Assistente de política de grupo de resultados.
depois que os resultados da Política de Grupo forem gerados, clique na guia Configurações . na guia
Configurações , as políticas de QoS podem ser encontradas nos nós "configuração do computador \ Windows
Configurações política \QoS" e "configuração do usuário \ Windows Configurações política \QoS".
na guia Configurações , as políticas de qos são listadas por seus nomes de política de qos com o valor DSCP, a
taxa de aceleração, as condições de política e o GPO vencedor listado na mesma linha.
A exibição de resultados de Política de Grupo identifica exclusivamente o GPO vencedor. Quando vários GPOs
têm políticas de QoS com o mesmo nome de política de QoS, o GPO com a maior precedência de GPO é
aplicado. Esse é o GPO vencedor. As políticas de QoS conflitantes (identificadas pelo nome da política) que estão
anexadas a um GPO de prioridade mais baixa não são aplicadas. Observe que as prioridades de GPO definem
quais políticas de QoS são implantadas no site, no domínio ou na UO, conforme apropriado. Após a
implantação, em um nível de usuário ou computador, as regras de precedência de política de QoS determinam
qual tráfego é permitido e bloqueado.
O valor DSCP da política de QoS, a taxa de limitação e as condições de política também são visíveis em Editor de
Objeto de Política de Grupo (GPOE)
Configurações avançadas para roaming e usuários remotos
Com a política de QoS, o objetivo é gerenciar o tráfego na rede de uma empresa. Em cenários móveis, os
usuários podem estar enviando tráfego para dentro ou para fora da rede corporativa. como as políticas de qos
não são relevantes enquanto estão longe da rede da empresa, as políticas de qos são habilitadas somente em
interfaces de rede que estão conectadas à empresa para Windows 8, Windows 7 ou Windows Vista.
Por exemplo, um usuário pode conectar seu computador portátil à rede da sua empresa por meio da VPN (rede
virtual privada) de uma cafeteria. Para VPN, a interface de rede física (como sem fio) não terá políticas de QoS
aplicadas. No entanto, a interface VPN terá políticas de QoS aplicadas porque se conecta à empresa. Se o
usuário mais tarde inserir outra rede da empresa que não tenha uma relação de confiança AD DS, as políticas de
QoS não serão habilitadas.
Observe que esses cenários móveis não se aplicam às cargas de trabalho do servidor. Por exemplo, um servidor
com vários adaptadores de rede pode se sentar na borda da rede de uma empresa. O departamento de ti pode
optar por ter políticas de QoS para limitar o tráfego que egresso a empresa; no entanto, esse adaptador de rede
que envia esse tráfego de saída não necessariamente se conecta de volta à rede corporativa. Por esse motivo, as
políticas de QoS sempre são habilitadas em todas as interfaces de rede de um computador que executa o
Windows Server 2012.
NOTE
A habilitação seletiva só se aplica a políticas de QoS e não às configurações de QoS avançadas discutidas a seguir neste
documento.
NOTE
os Configurações de QoS avançados são configurações de Política de Grupo no nível do computador.
0 64 KB
1 256 KB
2 1 MB
3 16 MB
O tamanho real da janela pode ser um valor igual ou menor que o máximo, dependendo das condições da rede.
P a ra d e f i n i r a j a n e l a d o l a d o d e re c e b i me n t o TC P
A Wi-Fi Alliance estabeleceu uma certificação para WMM de multimídia sem fio ( ) que define quatro categorias
( de acesso WMM_AC ) para priorizar o tráfego de rede transmitido em uma - rede sem fio Wi-Fi. As categorias
de acesso incluem para a ( prioridade mais alta para a mais baixa ) : voz, vídeo, melhor esforço e plano de fundo;
respectivamente abreviados como vo, vi, ser e BK. A especificação WMM define quais valores de DSCP
correspondem a cada uma das quatro categorias de acesso:
Você pode criar políticas de QoS que usam esses valores de DSCP para garantir que computadores portáteis
com - ™ de Certificação Wi-Fi para adaptadores sem fio WMM recebam tratamento priorizado quando
associados a Wi - Fi CERTIFIED para pontos de acesso do WMM.
Regras de precedência de política de QoS
Semelhante às prioridades do GPO, as políticas de QoS têm regras de precedência para resolver conflitos
quando várias políticas de QoS se aplicam a um conjunto específico de tráfego. Para o tráfego TCP ou UDP de
saída, somente uma política de QoS pode ser aplicada por vez, o que significa que as políticas de QoS não têm
um efeito cumulativo, como o local em que as taxas de limitação seriam somadas.
Em geral, a política de QoS com as condições mais correspondentes vence. Quando várias políticas de QoS se
aplicam, as regras se enquadram em três categorias: nível de usuário versus nível de computador; aplicativo
versus a rede quintuple; e entre a rede quintuple.
Por quintuple de rede, queremos dizer o endereço IP de origem, o endereço IP de destino, a porta de origem, a
porta de destino e o protocolo ( TCP/UDP ) .
A política de QoS de nível de usuário tem precedência sobre a política de QoS no nível do
computador
Essa regra facilita muito o gerenciamento de GPOs de QoS pelos administradores de rede, especialmente para
políticas baseadas em grupo de usuários. Por exemplo, se o administrador de rede quiser definir uma política de
QoS para um grupo de usuários, ele poderá apenas criar e distribuir um GPO para esse grupo. Eles não
precisam se preocupar com quais computadores esses usuários estão conectados e se esses computadores
terão políticas de QoS em conflito definidas, porque, se houver um conflito, a política de nível de usuário
sempre terá precedência.
NOTE
Uma política de QoS de nível de usuário só é aplicável ao tráfego gerado por esse usuário. Outros usuários de um
computador específico e o próprio computador não estarão sujeitos a nenhuma política de QoS definida para esse
usuário.
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Mensagens informativas
A seguir está uma lista de mensagens informativas da Política de QoS.
AT RIB UTO VA LO R
MessageId 16500
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_MACHINE_POLICY_REFRESH_NO_CHAN
GE
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16501
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_MACHINE_POLICY_REFRESH_WITH_CH
ANGE
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16502
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_USER_POLICY_REFRESH_NO_CHANGE
Idioma Inglês
AT RIB UTO VA LO R
AT RIB UTO VA LO R
MessageId 16503
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_USER_POLICY_REFRESH_WITH_CHANGE
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16504
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_NOT_CONFIGURED
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16505
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_OFF
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16506
AT RIB UTO VA LO R
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_HIGHLY_RESTRICTE
D
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16507
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_RESTRICTED
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16508
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_NORMAL
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16509
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_APP_MARKING_NOT_CONFIGURED
Idioma Inglês
AT RIB UTO VA LO R
AT RIB UTO VA LO R
MessageId 16510
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_APP_MARKING_IGNORED
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16511
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_APP_MARKING_ALLOWED
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16512
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_LOCAL_SETTING_DONT_USE_NLA
Idioma Inglês
Mensagens de aviso
A seguir está uma lista de mensagens de aviso da Política de QoS.
AT RIB UTO VA LO R
MessageId 16600
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_TEST_1
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16601
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_TEST_2
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16602
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_VERSION
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16603
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_USER_POLICY_VERSION
Idioma Inglês
MessageId 16604
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_PROFILE_NOT_
SPECIFIED
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16605
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_USER_POLICY_PROFILE_NOT_SPEC
IFIED
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16606
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_QUOTA_EXCEE
DED
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16607
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_USER_POLICY_QUOTA_EXCEEDED
AT RIB UTO VA LO R
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16608
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_CONFLICT
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16609
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_USER_POLICY_CONFLICT
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16610
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_NO_FULLPATH
_APPNAME
Idioma Inglês
MessageId 16611
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_USER_POLICY_NO_FULLPATH_APP
NAME
Idioma Inglês
Mensagens de erro
A seguir está uma lista de mensagens de erro de política de QoS.
AT RIB UTO VA LO R
MessageId 16700
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_MACHINE_POLICY_REFERESH
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16701
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_USER_POLICY_REFERESH
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16702
Gravidade Erro
AT RIB UTO VA LO R
SymbolicName EVENT_EQOS_ERROR_OPENING_MACHINE_POLICY_ROOT_
KEY
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16703
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_OPENING_USER_POLICY_ROOT_KEY
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16704
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_MACHINE_POLICY_KEYNAME_TOO_L
ONG
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16705
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_USER_POLICY_KEYNAME_TOO_LONG
Idioma Inglês
MessageId 16706
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_MACHINE_POLICY_KEYNAME_SIZE_ZE
RO
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16707
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_USER_POLICY_KEYNAME_SIZE_ZERO
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16708
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_OPENING_MACHINE_POLICY_SUBKEY
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16709
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_OPENING_USER_POLICY_SUBKEY
AT RIB UTO VA LO R
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16710
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_PROCESSING_MACHINE_POLICY_FIEL
D
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16711
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_PROCESSING_USER_POLICY_FIELD
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16712
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_SETTING_TCP_AUTOTUNING
Idioma Inglês
AT RIB UTO VA LO R
MessageId 16713
AT RIB UTO VA LO R
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_SETTING_APP_MARKING
Idioma Inglês
Para o próximo tópico deste guia, consulte perguntas frequentes sobre a política de QoS.
Para o primeiro tópico deste guia, consulte política de QoS (qualidade de serviço).
SDN na visão geral do Windows Server
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
A Rede Definida pelo Software (SDN) fornece um método para configurar e gerenciar centralmente dispositivos
de rede física e virtual, como roteadores, comutadores e gateways no seu data center. Você pode usar seus
dispositivos compatíveis com SDN existentes para obter uma integração mais profunda entre a rede virtual e a
rede física. Elementos de rede virtual, como o Com switch virtual do Hyper-V, a Virtualização de Rede Hyper-V e
o Gateway ras, foram projetados para serem elementos integrais da infraestrutura do SDN.
NOTE
Hosts Hyper-V e VMs (máquinas virtuais) que executam servidores de infraestrutura SDN, como os nós controlador de
rede e balanceamento de carga de software, devem ter o Windows Server 2019 ou 2016 Datacenter Edition instalado.
Hosts Hyper-V que contêm apenas VMs de carga de trabalho de locatário conectadas a redes controladas por SDN
podem usar Windows Server 2019 ou 2016 Standard Edition.
O SDN é possível porque os planos de rede não estão mais vinculados aos próprios dispositivos de rede. No
entanto, outras entidades, como o software de gerenciamento de datacenter, como System Center 2016 usam
planos de rede. O SDN permite que você gerencie sua rede de datacenter dinamicamente, fornecendo uma
maneira automatizada e centralizada de atender aos requisitos de seus aplicativos e cargas de trabalho.
Você pode usar o SDN para:
Criar, proteger e conectar sua rede dinamicamente para atender às necessidades em evolução de seus
aplicativos
Acelerar a implantação de suas cargas de trabalho de maneira sem interrupções
Conter vulnerabilidades de segurança da distribuição pela rede
Definir e controlar políticas que controlam redes físicas e virtuais
Implementar políticas de rede consistentemente em escala
O SDN permite que você realize tudo isso, reduzindo também os custos gerais de infraestrutura.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
os tópicos nesta seção fornecem uma visão geral e informações técnicas sobre as tecnologias de rede definidas
pelo Software que estão incluídas no Windows Server.
Controlador de rede
O controlador de rede fornece um ponto de automação centralizado e programável para gerenciar, configurar,
monitorar e solucionar problemas de infraestrutura de rede física e virtual em seu datacenter. Com o
controlador de rede, você pode automatizar a configuração da infraestrutura de rede em vez de executar a
configuração manual de dispositivos e serviços de rede.
O controlador de rede é um servidor altamente disponível e escalonável e fornece duas interfaces de
programação de aplicativo (APIs):
1. API Southbound – permite que o controlador de rede se comunique com a rede.
2. API Nor thbound – permite que você se comunique com o controlador de rede.
você pode usar Windows PowerShell, a API REST (representational State Transfer) ou um aplicativo de
gerenciamento para gerenciar a seguinte infraestrutura de rede física e virtual:
VMs e comutadores virtuais do Hyper-V
Comutadores de rede física
Roteadores de rede física
Software de firewall
Gateways de VPN, incluindo gateways de multilocatários RAS (serviço de acesso remoto)
Balanceadores de Carga
System Center
Implante e gerencie a infraestrutura de SDN com o VMM (gerenciamento de máquinas virtuais) e Operations
Manager. Com o VMM, você provisiona e gerencia os recursos necessários para criar e implantar máquinas
virtuais e serviços em nuvens privadas. Com o Operations Manager, você monitora serviços, dispositivos e
operações em toda a empresa para identificar problemas para ação imediata.
Virtualização de Rede Hyper-V
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
introduzido em Windows Server 2012, a virtualização de rede do Hyper-V (HNV) permite a virtualização de
redes de clientes sobre uma infraestrutura de rede física compartilhada. com as alterações mínimas necessárias
na malha de rede física, o HNV dá aos provedores de serviços a agilidade para implantar e migrar cargas de
trabalho de locatário em qualquer lugar nas três nuvens: a nuvem do provedor de serviços, a nuvem privada ou
a nuvem pública Microsoft Azure.
Para obter mais informações, consulte estes tópicos:
Visão geral da virtualização de rede Hyper-V no Windows Server 2016
O que há de novo na virtualização de rede Hyper-V no Windows Server 2016
Você sabia que o Microsoft Azure fornece uma funcionalidade semelhante na nuvem? Saiba mais sobre
Soluções de Virtualização do Microsoft Azure.
Criar uma solução de virtualização híbrida no Microsoft Azure:
- Conexão uma rede local para o Azure por meio de VPN site a site e estender Active Directory para um
controlador de domínio de VM IaaS no Azure|
Visão geral da Virtualização de Rede Hyper-V no
Windows Server
12/08/2021 • 13 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
No Windows Server e Virtual Machine Manager, a Microsoft fornece uma solução de virtualização de rede de
ponta a ponta. Há cinco componentes principais que compõem a solução de virtualização de rede da Microsoft:
Windows Azure Pack para Windows Ser ver fornece um portal voltado para locatários para criar
redes virtuais e um portal administrativo para gerenciar redes virtuais.
Vir tual Machine Manager (VMM) fornece gerenciamento centralizado da malha de rede.
O Controlador de Rede da Microsoft fornece um ponto de automação centralizado e programável
para gerenciar, configurar, monitorar e solucionar problemas de infraestrutura de rede virtual e física em
seu datacenter.
A Vir tualização de Rede Hyper-V oferece a infraestrutura necessária para virtualizar o tráfego da
rede.
Os gateways de Vir tualização de Rede Hyper-V fornecem conexões entre redes virtuais e físicas.
Este tópico apresenta conceitos e explica os principais benefícios e funcionalidades da Virtualização de Rede
Hyper-V (uma parte da solução geral de virtualização de rede) no Windows Server 2016. Ele explica como a
virtualização de rede beneficia as nuvens privadas para consolidação de carga de trabalho corporativa e os
provedores de serviço de nuvem pública de IaaS (Infraestrutura como Serviço).
Para obter mais detalhes técnicos sobre a virtualização de rede Windows Server 2016, consulte Detalhes
técnicos de virtualização de rede hyper-V no Windows Server 2016.
Você quis dizer
Visão geral da Virtualização de Rede Hyper-V ( Windows Server 2012 R2 )
Visão geral do Hyper-V
Visão geral do Comutador Virtual do Hyper-V
Descrição do recurso
A Virtualização de Rede Hyper-V fornece "redes virtuais" (chamadas de rede VM) para máquinas virtuais
semelhantes a como a virtualização de servidor (hipervisor) fornece "máquinas virtuais" para o sistema
operacional. A virtualização de rede separa redes virtuais da infraestrutura de rede física e remove as restrições
da atribuição de endereços IP hierárquicos e de VLAN do provisionamento de máquinas virtuais. Essa
flexibilidade facilita a migração de clientes para nuvens IaaS e torna mais eficiente o gerenciamento da
infraestrutura pelos hosters e administradores do datacenter, mantendo ainda o isolamento multilocatário, os
requisitos de segurança e o suporte à sobreposição de endereços IP de máquinas virtuais.
Os clientes desejam estender diretamente seus datacenters para a nuvem. Atualmente, existem desafios técnicos
para a criação dessas arquiteturas de nuvem híbridas integradas. Um dos maiores obstáculos que os clientes
enfrentam é a reutilação de suas topologias de rede existentes (sub-redes, endereços IP, serviços de rede e assim
por diante) na nuvem e ponte entre seus recursos locais e seus recursos de nuvem. A Virtualização de Rede
Hyper-V oferece o conceito de uma Rede VM independente da rede física subjacente. Com esse conceito de
Rede VM, composta de uma ou mais Sub-redes Virtuais, a localização física exata da rede física das máquinas
virtuais ligadas a uma rede virtual é separada da topologia da rede virtual. Como resultado, os clientes podem
mover facilmente suas sub-redes virtuais para a nuvem preservando seus endereços IP e sua topologia
existente na nuvem, de forma que os serviços existentes continuam funcionando independentemente da
localização física das sub-redes. Ou seja, a Virtualização de Rede Hyper-V permite uma nuvem híbrida integrada.
Além da nuvem híbrida, muitas organizações estão consolidando seus datacenters e criando nuvens privadas
para obter internamente o benefício das arquiteturas em nuvem em termos de eficiência e escalabilidade. A
Virtualização de Rede Hyper-V permite maior flexibilidade e eficiência para nuvens privadas, desacoplando a
topologia de rede de uma unidade de negócios (tornando-a virtual) da topologia de rede física real. Assim, as
unidades de negócios podem facilmente compartilhar uma nuvem privada interna, ao mesmo tempo em que
ficam isoladas umas das outras e continuam a manter as topologias de rede existentes. A equipe de operações
do datacenter tem flexibilidade para implantar e mover dinamicamente cargas de trabalho em qualquer lugar
do datacenter sem interrupções do servidor, fornecendo eficiências operacionais melhores e, no geral, um
datacenter mais eficiente.
Para proprietários de carga de trabalho, o principal benefício é que agora eles podem mover suas "topologias"
de carga de trabalho para a nuvem sem alterar seus endereços IP ou reescrevê-los. Por exemplo, o aplicativo
LOB típico de três camadas é composto de uma camada de front-end, uma camada de lógica de negócios e uma
camada de banco de dados. Por meio da política, a Virtualização de Rede Hyper-V permite que o cliente
carregue todas as partes das três camadas na nuvem, mantendo a topologia de roteamento e os endereços IP
dos serviços (ou seja, os endereços IP da máquina virtual), sem a necessidade de alterar os aplicativos.
Para proprietários de infraestrutura, a flexibilidade adicional no posicionamento de máquinas virtuais torna
possível mover cargas de trabalho em qualquer lugar dos datacenters sem alterar o as máquinas virtuais ou
reconfigurar as redes. Por exemplo, a Virtualização de Rede Hyper-V permite a migração ao vivo entre sub-
redes, de forma que uma máquina virtual pode migrar ao vivo em qualquer lugar do datacenter sem uma
interrupção do serviço. Anteriormente, a migração ao vivo era limitada à mesma sub-rede, restringindo os
locais onde as máquinas virtuais podiam ficar localizadas. A migração ao vivo entre sub-redes permite que os
administradores consolidem cargas de trabalho com base em requisitos de recursos dinâmicos, eficiência de
energia e também possam acomodar a manutenção da infraestrutura sem interromper o tempo de atividade da
carga de trabalho do cliente.
Aplicações práticas
Com o sucesso dos datacenters virtualizados, as organizações de TI e os provedores de hospedagem
(provedores que fornecem aluguéis de servidores físicos ou colocação) começaram a oferecer infraestruturas
virtualizadas mais flexíveis que facilitam a oferta de instâncias de servidor por demanda a seus clientes. Essa
nova classe de serviços é chamada de IaaS (Infraestrutura como Serviço). Windows Server 2016 fornece todos
os recursos de plataforma necessários para permitir que os clientes empresariais criem nuvens privadas e
transiram para um modelo operacional de TI como serviço. Windows Server 2016 também permite que os
hosters criem nuvens públicas e ofereçam soluções de IaaS para seus clientes. Quando combinada com Virtual
Machine Manager e Windows Azure Pack para gerenciar a política de Virtualização de Rede Hyper-V, a Microsoft
fornece uma solução de nuvem poderosa.
Windows Server 2016 A Virtualização de Rede Hyper-V fornece virtualização de rede controlada por software
baseada em políticas que reduz a sobrecarga de gerenciamento enfrentada pelas empresas ao expandir nuvens
IaaS dedicadas e fornece aos hosters de nuvem melhor flexibilidade e escalabilidade para gerenciar máquinas
virtuais para obter maior utilização de recursos.
Um cenário IaaS que tem máquinas virtuais de diferentes divisões organizacionais (nuvem dedicada) ou
diferentes clientes (nuvem hospedada) exige um isolamento seguro. A solução atual, VLANs (redes locais
virtuais), pode apresentar desvantagens significativas nesse cenário.
VL ANs
Atualmente, as VLANs são o mecanismo que a maioria das organizações usa para dar suporte à reutilização de
espaço de endereço e ao isolamento de locatário. Uma VLAN usa a marcação explícita (VLAN ID) nos cabeçalhos
de quadros Ethernet e depende dos comutadores Ethernet para impor o isolamento e restringir o tráfego aos
nós da rede com a mesma ID da VLAN. As principais desvantagens das VLANs são as descritas a seguir:
Risco aumentado de uma interrupção inadvertida devido à trabalhosa reconfiguração de comutadores de
produção sempre que máquinas virtuais ou os limites de isolamento se movem no datacenter dinâmico.
Escalabilidade limitada porque existe um máximo de 4094 VLANS e os comutadores típicos não dão
suporte a mais de 1000 IDs de VLAN.
Limitadas a uma única sub-rede de IPs, o que restringe o número de nós em uma única VLAN e o
posicionamento de máquinas virtuais com base em localizações físicas. Embora as VLANs possam ser
expandidas entre sites, a VLAN inteira deve estar na mesma sub-rede.
Atribuição de endereço IP
Além das desvantagens apresentadas pelas VLANs, a atribuição de endereço IP da máquina virtual apresenta
problemas, que incluem:
As localizações físicas na infraestrutura de rede do datacenter determinam os endereços IP das máquinas
virtuais. Como resultado, a mudança para a nuvem normalmente exige a alteração dos endereços IP das
cargas de trabalho de serviços.
As políticas são associadas a endereços IP, como regras de firewall, descoberta de recursos e serviços de
diretório etc. A alteração de endereços IP exige a atualização de todas as políticas associadas.
A implantação de máquinas virtuais e o isolamento do tráfego dependem da topologia.
Quando os administradores de rede do datacenter planejam o layout físico do datacenter, devem tomar
decisões sobre onde as sub-redes serão posicionadas e roteadas fisicamente. Essas decisões se baseiam na
tecnologia de IP e Ethernet, que afeta os possíveis endereços IP permitidos para máquinas virtuais em execução
em um determinado servidor ou um blade conectado a um rack específico no datacenter. Quando uma máquina
virtual é provisionada e posicionada no datacenter, ela deve estar de acordo com essas opções e restrições
referentes ao endereço IP. Portanto, normalmente, os administradores do datacenter atribuem endereços IP
novos às máquinas virtuais.
O problema desse requisito é que, além de ser um endereço, há informações semânticas associadas a um
endereço IP. Por exemplo, uma sub-rede pode conter determinados serviços ou estar em uma localização física
distinta. É comum que regras de firewall, políticas de controle de acesso e associações de segurança IPsec
estejam associados a endereços IP. A alteração dos endereços IP exige que os proprietários das máquinas
virtuais ajustem todas as políticas baseadas no endereço IP original. Essa sobrecarga com a renumeração é tão
grande que muitas empresas optam por implantar somente serviços novos na nuvem, abandonando os
aplicativos herdados.
A Virtualização de Rede Hyper-V separa as redes virtuais das máquinas virtuais do cliente da infraestrutura de
rede física. Como resultado, as máquinas virtuais do cliente podem manter seus endereços IP originais, e os
administradores do datacenter podem provisionar as máquinas virtuais do cliente em qualquer lugar do
datacenter sem precisar reconfigurar endereços IP físicos ou IDs da VLAN. A próxima seção resume as principais
funcionalidades.
Funcionalidade importante
Veja a seguir uma lista das principais funcionalidades, benefícios e funcionalidades da Virtualização de Rede
Hyper-V Windows Server 2016:
Habilita o posicionamento flexível da carga de trabalho – Isolamento de rede e rea utilização
de endereço IP sem VL ANs
A Virtualização de Rede Hyper-V dissocia as redes virtuais do cliente da infraestrutura de rede física dos
hosters, fornecendo liberdade para posicionamentos de carga de trabalho dentro dos datacenters. O
posicionamento da carga de trabalho de máquinas virtuais não é mais limitado pelos requisitos de
atribuição de endereços IP ou isolamento da VLAN da rede física, pois é imposto com hosts Hyper-V
baseados em políticas de virtualização multilocatário definidas pelo software.
Agora as máquinas virtuais de diferentes clientes com endereços IP sobrepostos podem ser implantadas
no mesmo servidor host, sem exigir a trabalhosa configuração da VLAN ou violar a hierarquia de
endereços IP. Isso pode agilizar a migração de cargas de trabalho do cliente em provedores de
hospedagem IaaS compartilhados, permitindo que os clientes migrem essas cargas de trabalho sem
modificações, inclusive deixando os endereços IP das máquinas virtuais inalterados. Para o provedor de
hospedagem, o suporte a numerosos clientes que desejam estender seus espaços de endereços de rede
existentes para o datacenter IaaS compartilhado é um exercício complexo de configuração e manutenção
de VLANs isoladas para cada cliente, a fim de garantir a coexistência de espaços de endereços
possivelmente sobrepostos. Com a Virtualização de Rede Hyper-V, o suporte a endereços sobrepostos é
facilitado e exige menos reconfiguração da rede pelo provedor de hospedagem.
Além disso, a manutenção e as atualizações da infraestrutura física podem ser feitas sem causar um
tempo de inatividade das cargas de trabalho do cliente. Com a Virtualização de Rede Hyper-V, as
máquinas virtuais em um determinado host, rack, sub-rede, VLAN ou em todo o cluster podem ser
migradas sem exigir a alteração do endereço IP físico ou uma reconfiguração de grande porte.
Habilita migrações mais fáceis de cargas de trabalho para uma nuvem IaaS compar tilhada
Com a Virtualização de Rede Hyper-V, as configurações de endereços IP e máquinas virtuais permanecem
inalteradas. Isso permite que as organizações de TI migrem mais facilmente as cargas de trabalho de seus
datacenters para um provedor de hospedagem IaaS compartilhado, com reconfiguração mínima da
carga de trabalho ou das ferramentas e políticas de sua infraestrutura. Nos casos em que há
conectividade entre dois datacenters, os administradores de TI podem continuar a usar suas ferramentas
sem precisar reconfigurá-las.
Habilita a migração ao vivo entre sub-redes
A migração ao vivo de cargas de trabalho de máquina virtual tradicionalmente tem sido limitada à
mesma sub-rede IP ou VLAN porque a passagem de sub-redes exigia que o sistema operacional
convidado da máquina virtual alterava seu endereço IP. Essa alteração de endereço interrompe a
comunicação existente e os serviços em execução na máquina virtual. Com a Virtualização de Rede
Hyper-V, as cargas de trabalho podem ser migradas ao vivo de servidores que executam o Windows
Server 2016 em uma sub-rede para servidores que executam Windows Server 2016 em uma sub-rede
diferente sem alterar os endereços IP da carga de trabalho. A Virtualização de Rede Hyper-V garante que
as alterações de localização das máquinas virtuais devido à migração ao vivo sejam atualizadas e
sincronizadas entre os hosts que têm comunicação contínua com as máquinas virtuais migradas.
Habilita o gerenciamento mais fácil da administração de rede e de ser vidores separados
O posicionamento da carga de trabalho do servidor é simplificado porque a migração e o
posicionamento de cargas de trabalho são independentes das configurações da rede física subjacente. Os
administradores de servidores podem se concentrar no gerenciamento de serviços e servidores, e os
administradores de rede podem se concentrar no gerenciamento geral do tráfego e da infraestrutura de
rede. Assim, os administradores de servidores do datacenter podem implantar e migrar máquinas
virtuais sem precisar alterar os endereços IP das máquinas virtuais. As sobrecarga é reduzida porque a
Virtualização de Rede Hyper-V permite que o posicionamento de máquinas virtuais ocorra de maneira
independente da topologia de rede, reduzindo a necessidade de os administradores de rede se
envolverem com os posicionamentos que podem alterar os limites do isolamento.
Simplifica a rede e melhora a utilização de recursos de ser vidor/rede
A rigidez das VLANs e a dependência do posicionamento de máquinas virtuais em uma infraestrutura de
rede física resulta no superprovisionamento e na subutilização. Com a quebra dessa dependência, a
maior flexibilidade do posicionamento da carga de trabalho de máquinas virtuais pode simplificar o
gerenciamento de rede e melhorar a utilização de recurso de servidor e de rede. Observe que a
Virtualização de Rede Hyper-V dá suporte a VLANs no contexto do datacenter físico. Por exemplo, um
datacenter pode requerer que todo o tráfego da Virtualização de Rede Hyper-V esteja em uma VLAN
específica.
É compatível com a infraestrutura existente e a tecnologia emergente
A virtualização de rede Hyper-V pode ser implantada no datacenter atual, ainda que seja compatível com
as tecnologias de "rede plana" do datacenter emergente.
por exemplo, HNV em Windows Server 2016 dá suporte ao formato de encapsulamento VXLAN e ao
OVSDB (Open vSwitch Database Management Protocol) como a Interface SouthBound (SBI).
Fornece interoperabilidade e prontidão do ecossistema
A Virtualização de Rede Hyper-V dá suporte a várias configurações de comunicação com recursos
existentes, como conectividade entre locais, SAN (rede de área de armazenamento), acesso a recursos
não virtualizados etc. A Microsoft tem o compromisso de trabalhar com parceiros de ecossistema para
dar suporte e aperfeiçoar a experiência da Virtualização de Rede Hyper-V em termos de desempenho,
escalabilidade e gerenciabilidade.
Configuração baseada em política
as políticas de virtualização de rede no Windows Server 2016 são configuradas através do controlador
de rede da Microsoft. o controlador de rede tem uma API northbound RESTful e Windows PowerShell
interface para configurar a política. Para obter mais informações sobre o controlador de rede da
Microsoft, consulte controlador de rede.
Requisitos de software
a virtualização de rede Hyper-v usando o controlador de rede da Microsoft requer Windows Server 2016 e a
função Hyper-v.
Confira também
para saber mais sobre a virtualização de rede Hyper-V no Windows Server 2016 consulte os links a seguir:
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
A virtualização de servidores permite que várias instâncias do servidor sejam executadas simultaneamente em
um único host físico, mas as instâncias do servidor são isoladas umas das outras. Cada máquina virtual opera
essencialmente como se fosse o único servidor em execução no computador físico.
A virtualização de rede fornece um recurso semelhante, no qual várias redes virtuais (potencialmente com
endereços IP sobrepostos) são executadas na mesma infraestrutura de rede física e cada rede virtual funciona
como se fosse a única rede virtual em execução na infraestrutura de rede compartilhada. A figure 1 exibe essa
relação.
IMPORTANT
Este tópico se concentra no HNVv2.
Rede virtual
Cada rede virtual consiste em uma ou mais sub-redes virtuais. Uma rede virtual forma um limite de
isolamento em que as máquinas virtuais em uma rede virtual só podem se comunicar entre si.
Tradicionalmente, esse isolamento foi imposto usando VLANs com um intervalo de endereços IP
segregado e uma marca 802.1 q ou ID de VLAN. Mas com HNV, o isolamento é imposto usando o
encapsulamento NVGRE ou VXLAN para criar redes de sobreposição com a possibilidade de
sobreposição de sub-redes IP entre clientes ou locatários.
Cada rede virtual tem uma RDID (ID de domínio de roteamento) exclusiva no host. Este RDID
basicamente mapeia para uma ID de recurso para identificar o recurso REST de rede virtual no
controlador de rede. O recurso REST da rede virtual é referenciado usando um namespace Uniform
Resource Identifier (URI) com a ID de recurso acrescentada.
Sub-redes virtuais
Uma sub-rede virtual implementa a semântica de sub-rede IP de Camada 3 das máquinas virtuais na
mesma sub-rede virtual. A sub-rede virtual forma um domínio de difusão (semelhante a uma VLAN) e o
isolamento é imposto usando o campo TNI (ID de rede de locatário NVGRE) ou VNI (identificador de rede
VXLAN).
Cada sub-rede virtual pertence a uma única rede virtual (RDID) e recebe uma VSID (ID de sub-rede
virtual) exclusiva usando a chave TNI ou VNI no cabeçalho de pacote encapsulado. O VSID deve ser
exclusivo dentro do datacenter e está no intervalo de 4096 a 2 ^ 24-2.
Uma vantagem importante da rede virtual e do domínio de roteamento é que ele permite que os clientes
Tragam suas próprias topologias de rede (por exemplo, sub-redes IP) para a nuvem. A Figura 2 mostra um
exemplo onde a Contoso Corp tem duas redes separadas, Rede P&D e Rede de Vendas. Como essas redes têm
diferentes IDs de domínio de roteamento, elas não podem interagir entre si. Ou seja, a contoso R&D net é
isolada da Contoso Sales net, embora ambas sejam de propriedade da Contoso Corp. a contoso R&D net
contém três sub-redes virtuais. Observe que a RDID e a VSID são exclusivas dentro de um datacenter.
Figura 2: Redes de cliente e sub-redes virtuais
Encaminhamento da camada 2
Na Figura 2, as máquinas virtuais no VSID 5001 podem ter seus pacotes encaminhados para máquinas virtuais
que também estão no VSID 5001 por meio do comutador do Hyper-V. Os pacotes de entrada de uma máquina
virtual no VSID 5001 são enviados para um VPort específico no comutador do Hyper-V. As regras de entrada
(por exemplo, encap) e mapeamentos (por exemplo, cabeçalho de encapsulamento) são aplicadas pelo
comutador do Hyper-V para esses pacotes. Os pacotes são encaminhados para um VPort diferente na opção do
Hyper-V (se a máquina virtual de destino estiver anexada ao mesmo host) ou em um comutador Hyper-V
diferente em um host diferente (se a máquina virtual de destino estiver localizada em um host diferente).
Roteamento de camada 3
Da mesma forma, as máquinas virtuais no VSID 5001 podem ter seus pacotes roteados para máquinas virtuais
no VSID 5002 ou VSID 5003 pelo roteador distribuído HNV que está presente em cada VSwitch do host Hyper-
V. Ao entregar o pacote para o comutador do Hyper-V, o HNV atualiza o VSID do pacote de entrada para o VSID
da máquina virtual de destino. Isso ocorrerá somente se as duas VSIDs estiverem na mesma RDID. Portanto, os
adaptadores de rede virtual com RDID1 não podem enviar pacotes para adaptadores de rede virtual com RDID2
sem atravessar um gateway.
NOTE
Na descrição do fluxo de pacotes acima, o termo "máquina virtual" realmente significa o adaptador de rede virtual na
máquina virtual. O caso comum é quando uma máquina virtual tem apenas um único adaptador de rede virtual. Nesse
caso, as palavras "máquina virtual" e "adaptador de rede virtual" podem significar a mesma coisa de forma conceitual.
Cada sub-rede virtual define uma sub-rede IP de Camada 3 e um limite de domínio de difusão de Camada 2
(L2) de maneira semelhante a uma VLAN. Quando uma máquina virtual transmite um pacote, o HNV usa a UR
(replicação unicast) para fazer uma cópia do pacote original e substituir o IP de destino e o MAC pelos
endereços de cada VM que estão no mesmo VSID.
NOTE
quando Windows Server 2016 são fornecidos, difusões e multicast de sub-rede serão implementados usando a replicação
unicast. Não há suporte para roteamento multicast entre sub-redes e IGMP.
Além de ser um domínio de difusão, a VSID fornece isolamento. Um adaptador de rede virtual no HNV é
conectado a uma porta de comutador do Hyper-V que terá regras de ACL aplicadas diretamente à porta
(recurso de virtualNetworkInterface REST) ou à sub-rede virtual (VSID) da qual ela faz parte.
A porta do comutador do Hyper-V deve ter uma regra ACL aplicada. Essa ACL pode ser permitir todos, negar
tudo ou ser mais específica para permitir apenas certos tipos de tráfego com base em correspondência de 5
tuplas (IP de origem, IP de destino, porta de origem, porta de destino, protocolo) correspondente.
NOTE
Extensões de comutador Hyper-V não funcionarão com HNVv2 na nova pilha de SDN (rede definida pelo software). O
HNVv2 é implementado usando a extensão de comutador VFP (plataforma de filtragem virtual) do Azure que não pode
ser usada em conjunto com qualquer outra extensão de comutador de terceiros.
NOTE
O agente de host, agindo como o servidor OVSDB, usa uma variante do esquema VTEP para armazenar mapeamentos
CA-PA, tabela MAC e assim por diante.
Se um endereço MAC estiver disponível, o agente de host injetará uma resposta ARP e a enviará de volta para a
máquina virtual. Depois que a pilha de rede da máquina virtual tiver todas as informações de cabeçalho L2
necessárias, o quadro será enviado para a porta Hyper-V correspondente na opção V-. Internamente, o
comutador do Hyper-V testa esse quadro em relação às regras de correspondência de N-tupla atribuídas à
porta V e aplica determinadas transformações ao quadro com base nessas regras. O mais importante é que um
conjunto de transformações de encapsulamento é aplicado para construir o cabeçalho de encapsulamento
usando NVGRE ou VXLAN, dependendo da política definida no controlador de rede. Com base na política
programada pelo agente do host, um mapeamento de CA-PA é usado para determinar o endereço IP do host
Hyper-V onde reside a máquina virtual de destino. A opção Hyper-V garante que as regras de roteamento e as
marcas de VLAN corretas sejam aplicadas ao pacote externo para que ele atinja o endereço PA remoto.
Se uma máquina virtual conectada a uma rede virtual HNV deseja criar uma conexão com uma máquina virtual
em uma sub-rede virtual diferente (VSID), o pacote precisa ser roteado de acordo. O HNV pressupõe uma
topologia em estrela em que há apenas um endereço IP no espaço da autoridade de certificação usado como o
próximo salto para alcançar todos os prefixos de IP (ou seja, uma rota/gateway padrão). Atualmente, isso impõe
uma limitação a uma única rota padrão e não há suporte para rotas não padrão.
Roteamento Entre Sub-redes Virtuais
Em uma rede física, uma sub-rede IP é um domínio de camada 2 (L2) em que os computadores (virtuais e
físicos) podem se comunicar diretamente entre si. O domínio L2 é um domínio de difusão em que as entradas
ARP (IP: mapa de endereços MAC) são aprendidas por meio de solicitações ARP que são transmitidas em todas
as interfaces e as respostas ARP são enviadas de volta para o host solicitante. O computador usa as informações
de MAC aprendidas da resposta ARP para construir completamente o quadro L2, incluindo cabeçalhos Ethernet.
No entanto, se um endereço IP estiver em uma sub-rede L3 diferente, a solicitação ARP não cruzará esse limite
L3. Em vez disso, uma interface de roteador L3 (próximo salto ou gateway padrão) com um endereço IP na sub-
rede de origem deve responder a essas solicitações ARP com seu próprio endereço MAC.
na rede Windows padrão, um administrador pode criar rotas estáticas e atribuí-las a uma interface de rede.
Além disso, um "gateway padrão" geralmente é configurado para ser o endereço IP de próximo salto em uma
interface em que os pacotes destinados à rota padrão (0.0.0.0/0) são enviados. Os pacotes serão enviados para
esse gateway padrão se não existirem rotas específicas. Normalmente, esse é o roteador da rede física. O HNV
usa um roteador interno que faz parte de cada host e tem uma interface em cada VSID para criar um roteador
distribuído para as redes virtuais.
Como o HNV pressupõe uma topologia em estrela, o roteador distribuído HNV atua como um gateway padrão
único para todo o tráfego que está indo entre sub-redes virtuais que fazem parte da mesma rede VSID. O
endereço usado como padrão do gateway padrão é o endereço IP mais baixo no VSID e é atribuído ao roteador
distribuído HNV. Esse roteador distribuído permite uma maneira muito eficiente para todo o tráfego dentro de
uma rede VSID ser roteado adequadamente porque cada host pode rotear diretamente o tráfego para o host
apropriado sem precisar de um intermediário. Isso é particularmente verdadeiro quando duas máquinas
virtuais na mesma Rede VM, mas em diferentes Sub-redes Virtuais estão no mesmo host físico. Como você verá
mais adiante nesta seção, o pacote nunca terá que sair do host físico.
Roteamento entre sub-redes PA
Ao contrário do HNVv1 que alocou um endereço IP PA para cada sub-rede virtual (VSID), o HNVv2 agora usa
um endereço IP PA por membro da equipe NIC de Switch-Embedded (conjunto). A implantação padrão assume
uma equipe de duas NICs e atribui dois endereços IP PA por host. Um único host tem IPs PA atribuídos da
mesma sub-rede lógica do PA (provedor) na mesma VLAN. Duas VMs de locatário na mesma sub-rede virtual
podem realmente estar localizadas em dois hosts diferentes que estão conectados a duas sub-redes lógicas de
provedor diferentes. O HNV construirá os cabeçalhos IP externos para o pacote encapsulado com base no
mapeamento CA-PA. No entanto, ele depende da pilha de TCP/IP do host para ARP para o gateway PA padrão e
cria os cabeçalhos de Ethernet externos com base na resposta ARP. Normalmente, essa resposta ARP vem da
interface SVI no comutador físico ou do roteador L3 onde o host está conectado. O HNV, portanto, depende do
roteador L3 para rotear os pacotes encapsulados entre sub-redes lógicas/VLANs do provedor.
Roteamento Fora de uma Rede Virtual
A maioria das implantações de cliente exigirá a comunicação do ambiente de HNV com recursos que não fazem
parte do ambiente de HNV. São necessários gateways de Virtualização de Rede para permitir a comunicação
entre os dois ambientes. As infraestruturas que exigem um gateway HNV incluem nuvem privada e nuvem
híbrida. Basicamente, os gateways de HNV são necessários para o roteamento de camada 3 entre redes internas
e externas (incluindo NAT) ou entre diferentes sites e/ou nuvens (privadas ou públicas) que usam um túnel de
VPN IPSec ou GRE.
Os gateways podem ser fornecidos em diferentes fatores forma físicos. eles podem ser criados em Windows
Server 2016, incorporados a um TOR (Top of Rack) switch atuando como um Gateway VXLAN, acessado por
meio de um VIP (IP Virtual) anunciado por um balanceador de carga, colocado em outros dispositivos de rede
existentes ou pode ser um novo dispositivo de rede autônomo.
para obter mais informações sobre Windows opções de gateway ras, consulte gateway de ras.
Encapsulamento de Pacote
Cada adaptador de rede virtual da HNV está associado a dois endereços IP:
Endereço do cliente (CA) o endereço IP atribuído pelo cliente, com base em sua infraestrutura de
intranet. Esse endereço permite que o cliente troque o tráfego de rede com a máquina virtual como se ela
não tivesse sido movida para uma nuvem pública ou privada. O CA é visível para a máquina virtual e está
acessível para o cliente.
Endereço do provedor (PA) o endereço IP atribuído pelo provedor de hospedagem ou os
administradores do datacenter com base em sua infraestrutura de rede física. O PA é exibido nos pacotes
da rede que são trocados com o servidor Hyper-V que hospeda a máquina virtual. O PA está visível na
rede física, mas não para a máquina virtual.
Os CAs mantêm a topologia de rede do cliente, que é virtualizada e separada dos endereços e da topologia de
rede física real subjacente, conforme implementado pelos PAs. O diagrama a seguir mostra a relação conceitual
entre os CAs de máquinas virtuais e os PAs da infraestrutura de rede resultantes da virtualização da rede.
Resumo
Os datacenters baseados em nuvem podem oferecer diversos benefícios, como escalabilidade aprimorada e
melhor utilização de recursos. Para aproveitar esses possíveis benefícios, é necessária uma tecnologia que
basicamente trate dos problemas de escalabilidade multilocatário em um ambiente dinâmico. A HNV foi
projetada para lidar com essas questões e também para aprimorar a eficiência operacional do datacenter,
separando a topologia da rede virtual para a topologia da rede física. Com base em um padrão existente, a HNV
é executado no datacenter de hoje e opera com sua infraestrutura VXLAN existente. Os clientes com HNV agora
podem consolidar seus datacenters em uma nuvem privada ou estender seus datacenters perfeitamente para o
ambiente de um provedor de servidores de hospedagem com uma nuvem híbrida.
Confira também
Para saber mais sobre o HNVv2, confira os seguintes links:
T IP O DE C O N T EÚDO REF ERÊN C IA S
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Este tópico descreve a funcionalidade de HNV (virtualização de rede) do Hyper-V que é nova ou alterada no
Windows Server 2016.
Atualizações no HNV
O HNV oferece suporte aprimorado nas seguintes áreas:
NOTE
Para obter mais informações sobre OVSDB, consulte RFC 7047.
A opção Hyper-V dá suporte a regras de fluxo com e sem estado com base na ' ação de correspondência '
simples no mecanismo de fluxo da Microsoft.
Referências adicionais
Visão Geral da Virtualização de Rede Hyper-V
Detalhes técnicos da Virtualização de Rede Hyper-V
Rede definida pelo software
Serviço DNS interno (iDNS) para SDN
07/08/2021 • 7 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Se você trabalhar para um CSP do Provedor de Serviços de Nuvem ou um Enterprise que está planejando
implantar o SDN de Rede Definida pelo Software no servidor Windows, poderá fornecer serviços DNS para suas
cargas de trabalho de locatário hospedadas usando o iDNS dns interno, que é integrado ao ( ) ( ) ( ) SDN.
As VMs e aplicativos de máquinas virtuais hospedadas exigem que o DNS se comunique em suas próprias
redes e com ( ) recursos externos na Internet. Com o iDNS, você pode fornecer aos locatários serviços de
resolução de nomes DNS para seu espaço de nome local isolado e para recursos da Internet.
Como o serviço iDNS não está acessível de Redes Virtuais de locatário, além do proxy iDNS, o servidor não está
vulnerável a atividades mal-intencionadas em redes de locatário.
Principais recursos
A seguir estão os principais recursos para iDNS.
Fornece serviços de resolução de nomes DNS compartilhados para cargas de trabalho de locatário
Serviço DNS autoritativo para resolução de nomes e registro DNS dentro do espaço de nome do locatário
Serviço DNS recursivo para resolução de nomes de Internet de VMs de locatário.
Se desejar, você pode configurar a hospedagem simultânea de nomes de malha e locatário
Uma solução DNS econômica – os locatários não precisam implantar sua própria infraestrutura dns
Alta disponibilidade com a integração do Active Directory, que é necessária.
Além desses recursos, se você estiver preocupado em manter seus servidores DNS integrados do AD abertos na
Internet, poderá implantar servidores iDNS atrás de outro resolvedor recursivo na rede de perímetro.
Como o iDNS é um servidor centralizado para todas as consultas DNS, um CSP ou Enterprise também pode
implementar firewalls DNS de locatário, aplicar filtros, detectar atividades mal-intencionadas e auditar
transações em um local central
Infraestrutura do iDNS
A infraestrutura iDNS inclui servidores iDNS e proxy iDNS.
Servidores iDNS
O iDNS inclui um conjunto de servidores DNS que hospedam dados específicos do locatário, como registros de
recursos DNS da VM.
Os servidores iDNS são os servidores autoritativos para suas zonas DNS internas e também atuam como
resolvedores de nomes públicos quando as VMs de locatário tentam se conectar a recursos externos.
Todos os nomes de host para VMs em Redes Virtuais são armazenados como Registros de Recursos DNS na
mesma zona. Por exemplo, se você implantar o iDNS para uma zona chamada contoso.local, os Registros de
Recursos DNS para as VMs nessa rede serão armazenados na zona contoso.local.
Os FQDNs de Nomes de Domínio Totalmente Qualificados da VM do Locatário consistem no nome do
computador e na cadeia de caracteres do sufixo DNS para a Rede ( ) Virtual, no formato GUID. Por exemplo, se
você tiver uma VM de locatário chamada TENANT1 que está na Rede Virtual contoso,local, o FQDN da VM será
TENANT1. vn-guid.contoso.local, em que vn-guid é a cadeia de caracteres de sufixo DNS para a Rede Virtual.
NOTE
Se você for um administrador de malha, poderá usar sua infraestrutura CSP ou dns Enterprise como servidores iDNS em
vez de implantar novos servidores DNS especificamente para uso como servidores iDNS. Independentemente de você
implantar novos servidores para iDNS ou usar sua infraestrutura existente, o iDNS depende do Active Directory para
fornecer alta disponibilidade. Portanto, os servidores iDNS devem ser integrados ao Active Directory.
Proxy iDNS
O proxy iDNS é um Windows que é executado em cada host e que encaminha o tráfego DNS da Rede Virtual do
locatário para o servidor iDNS.
A ilustração a seguir ilustra os caminhos de tráfego DNS de Redes Virtuais do locatário por meio do proxy iDNS
para o servidor iDNS e a Internet.
NOTE
Se você tiver implantado o SDN usando scripts, não precisará executar nenhuma dessas etapas. As etapas são fornecidas
apenas para fins de informações e solução de problemas.
Url: https://<url>/networking/v1/iDnsServer/configuration
Method: PUT
{
"properties": {
"connections": [
{
"managementAddresses": [
"10.0.0.9"
],
"credential": {
"resourceRef": "/credentials/iDnsServer-Credentials"
},
"credentialType": "usernamePassword"
}
],
"zone": "contoso.local"
}
}
NOTE
Este é um trecho da seção Configuration ConfigureIDns no SDNExpress.ps1. Para obter mais informações, consulte
Implantar uma infraestrutura de rede definida pelo software usando scripts.
NOTE
Este é um trecho da seção Configuração ConfigureIDnsProxy no SDNExpress.ps1. Para obter mais informações,
consulte Implantar uma infraestrutura de rede definida pelo software usando scripts.
NOTE
Essas informações estão incluídas na seção Configuration AttachToVir tualNetwork no SDNExpressTenant.ps1. Para
obter mais informações, consulte Implantar uma infraestrutura de rede definida pelo software usando scripts.
Alta disponibilidade do controlador de rede
12/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Você pode usar este tópico para saber mais sobre a configuração de alta disponibilidade e escalabilidade do
Controlador de Rede para o ( SDN de Rede Definida pelo ) Software.
Ao implantar o SDN em seu datacenter, você pode usar o Controlador de Rede para implantar, monitorar e
gerenciar centralmente muitos elementos de rede, incluindo Gateways RAS, Balanceadores de Carga de
Software, políticas de rede virtual para comunicação de locatário, políticas de Firewall do Datacenter, QoS de
Qualidade de Serviço para ( políticas de SDN, políticas de rede híbrida e muito ) mais.
Como o Controlador de Rede é a base do gerenciamento de SDN, é essencial que as implantações do
Controlador de Rede forneçam alta disponibilidade e a capacidade de escalar ou rebanhar facilmente os nós do
Controlador de Rede com suas necessidades de datacenter.
Embora seja possível implantar o Controlador de Rede como um único cluster de computador, para alta
disponibilidade e failover, você deve implantar o Controlador de Rede em um cluster de vários computador com,
no mínimo, três máquinas.
NOTE
Você pode implantar o Controlador de Rede em computadores servidores ou em VMs de máquinas virtuais que estão ( )
executando Windows Server 2016 Datacenter Edition. Se você implantar o Controlador de Rede em VMs, as VMs deverão
estar em execução em hosts Hyper-V que também estão executando o Datacenter Edition. O Controlador de Rede não
está disponível no Windows Server 2016 Standard Edition.
NOTE
Para obter informações sobre Service Fabric no Azure, consulte Visão geral do Azure Service Fabric.
Quando você implanta o Controlador de Rede em vários máquinas, o Controlador de Rede é executado como
um único Service Fabric aplicativo em um cluster Service Fabric rede. Você pode formar um Service Fabric
cluster conectando um conjunto de instâncias do sistema operacional.
O aplicativo Controlador de Rede é composto por vários serviços de Service Fabric com estado. Cada serviço é
responsável por uma função de rede, como gerenciamento de rede física, gerenciamento de rede virtual,
gerenciamento de firewall ou gerenciamento de gateway.
Cada Service Fabric tem uma réplica primária e duas réplicas secundárias. A réplica de serviço primário
processa solicitações, enquanto as duas réplicas de serviço secundário fornecem alta disponibilidade em
circunstâncias em que a réplica primária está desabilitada ou não disponível por algum motivo.
A ilustração a seguir ilustra um cluster de Service Fabric controlador de rede com cinco máquinas. Quatro
serviços são distribuídos entre os cinco máquinas: Serviço de Firewall, Serviço de Gateway, Serviço de
Balanceamento de Carga de Software SLB e serviço ( ) ( VNET de rede ) virtual. Cada um dos quatro serviços
inclui uma réplica de serviço primária e duas réplicas de serviço secundário.
NOTE
No Windows Server 2016, não há suporte para a adição de serviços de terceiros ao Controlador de Rede.
Service Fabric modularidade usa esquemas de modelo de serviço para maximizar a facilidade de
desenvolvimento, implantação e manutenção de um aplicativo.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Este tópico fornece instruções sobre como instalar a função de servidor do controlador de rede usando
Gerenciador do Servidor.
IMPORTANT
Não implante a função de servidor do controlador de rede em hosts físicos. Para implantar o controlador de rede, você
deve instalar a função de servidor do controlador de rede em uma VM de máquina virtual do Hyper-V ( ) instalada em
um host do Hyper-v. depois de instalar o controlador de rede em VMs em três - hosts hyper-v diferentes, você deve
habilitar os - hosts hyper-v para o SDN de rede definido pelo Software ( ) adicionando os hosts ao controlador de rede
usando o comando Windows PowerShell New-NetworkControllerSer ver . Ao fazer isso, você está permitindo que o
software SDN Load Balancer funcione. Para obter mais informações, consulte New-NetworkControllerServer.
depois de instalar o controlador de rede, você deve usar os comandos Windows PowerShell para configuração
adicional do controlador de rede. Para obter mais informações, consulte implantar o controlador de rede usando
Windows PowerShell.
Para instalar o controlador de rede
1. No Gerenciador do Servidor, clique em Gerenciar e depois em Adicionar Funções e Recursos . O
assistente Adicionar funções e recursos é aberto. Clique em Próximo .
2. Em Selecionar tipo de instalação , mantenha a configuração padrão e clique em Avançar .
3. Em selecionar ser vidor de destino , escolha o servidor no qual você deseja instalar o controlador de
rede e clique em Avançar .
4. Em selecionar funções de ser vidor , em funções , clique em controlador de rede .
5. A caixa de diálogo Adicionar recursos necessários para o controlador de rede é aberta. Clique em
Adicionar Recursos .
Consulte Também
Controlador de rede
Etapas de pós-implantação para Controlador de
Rede
11/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Ao instalar o Controlador de Rede, você pode escolher implantações Kerberos ou não Kerberos.
Para - implantações não Kerberos, você deve configurar certificados.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Você pode usar este tópico para saber mais sobre a virtualização de função de rede, que permite implantar
dispositivos de rede virtual, como o Firewall do datacenter, o gateway de RAS multilocatário e o multiplexador
SLB de balanceamento de carga de software ( ) ( MUX ) .
NOTE
Além deste tópico, a documentação de virtualização de função de rede a seguir está disponível.
Visão geral do firewall do datacenter
Gateway de RAS para SDN
SLB (balanceamento de carga do software) para SDN
Nos data centers definidos pelo software de hoje, as funções de rede que estão sendo executadas por
dispositivos de hardware (como balanceadores de carga, firewalls, roteadores, comutadores etc.) são cada vez
mais virtualizadas como dispositivos virtuais. Essa "virtualização da função de rede" é uma progressão natural
de virtualização do servidor e de virtualização de rede. Os dispositivos virtuais estão surgindo rapidamente e
criando um mercado totalmente novo. Eles continuam gerando interesse e conquistam impulso nas plataformas
de virtualização e nos serviços de nuvem.
a Microsoft incluiu um gateway autônomo como um dispositivo virtual a partir do Windows Server 2012 R2.
Para obter mais informações, consulte Gateway do Windows Server. agora, com Windows Server 2016 a
Microsoft continua a expandir e investir no mercado de virtualização de funções de rede.
A plataforma da Microsoft foi projetada para ser uma ótima plataforma para criar e implantar dispositivos
virtuais. Veja por quê:
A Microsoft fornece as principais funções de rede virtualizadas com Windows Server 2016.
Você pode implantar um dispositivo virtual do fornecedor de sua escolha.
Você pode implantar, configurar e gerenciar seus dispositivos virtuais com o controlador de rede da
Microsoft que vem com Windows Server 2016. Para obter mais informações sobre o controlador de rede,
consulte controlador de rede.
O Hyper-V pode hospedar os principais sistemas operacionais convidados de que você precisa.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Você pode usar este tópico para saber mais sobre a implantação do CSP (provedor de serviços de nuvem) do
gateway de RAS, incluindo pools de gateway de RAS, refletores de rota e implantação de vários gateways para
locatários individuais.
As seções a seguir fornecem breves visões gerais de alguns dos novos recursos do gateway de RAS para que
você possa entender como usar esses recursos no design de sua implantação de gateway.
Além disso, um exemplo de implantação é fornecido, incluindo informações sobre o processo de adição de
novos locatários, sincronização de rotas e roteamento do plano de dados, failover do refletor de gateway e rota
e muito mais.
Este tópico inclui as seções a seguir.
Usando novos recursos do gateway de RAS para projetar sua implantação
Exemplo de implantação
Adicionar novos locatários e espaço de CA (endereço do cliente) emparelhamento EBGP
Sincronização de rotas e roteamento do plano de dados
Como o controlador de rede responde ao gateway RAS e ao failover de refletor de rota
Vantagens de usar novos recursos de gateway de RAS
Exemplo de implantação
A ilustração a seguir fornece um exemplo com emparelhamento eBGP em conexões VPN site a site configuradas
entre dois locatários, contoso e Woodgrove, e o datacenter CSP da Fabrikam.
Neste exemplo, a contoso requer largura de banda de gateway adicional, levando à decisão de design de
infraestrutura de gateway para encerrar o site contoso los Angeles em GW3 em vez de GW2. Por isso, as
conexões VPN da Contoso de sites diferentes terminam no datacenter do CSP em dois gateways diferentes.
Ambos os gateways, GW2 e GW3, foram os primeiros gateways de RAS configurados pelo controlador de rede
quando o CSP adicionou os locatários contoso e Woodgrove à sua infraestrutura. Por isso, esses dois gateways
são configurados como refletores de rota para esses clientes (ou locatários) correspondentes. GW2 é o refletor
de rota da Contoso e GW3 é o refletor de rota do Woodgrove, além de ser o ponto de término do gateway de
RAS do CSP para a conexão VPN com o site de HQ de los da Contoso Angeles.
NOTE
Um gateway RAS pode rotear o tráfego de rede virtual e física para até 100 locatários diferentes, dependendo dos
requisitos de largura de banda de cada locatário.
Como os refletores de rota, o GW2 envia rotas de espaço de CA da Contoso para o controlador de rede e GW3
envia rotas de espaço da AC do Woodgrove para o controlador de rede.
O controlador de rede envia políticas de virtualização de rede Hyper-V para as redes virtuais contoso e
Woodgrove, bem como políticas de RAS para os gateways RAS e políticas de balanceamento de carga para os
multiplexadores (MUXes) configurados como um pool de balanceamento de carga de software.
NOTE
Depois que o controlador de rede tiver configurado um gateway RAS e um refletor de rota para o
locatário, sempre que o mesmo locatário exigir uma nova conexão VPN site a site, o controlador de rede
verificará a capacidade disponível nessa VM do gateway RAS. Se o gateway original puder atender à
capacidade necessária, a nova conexão de rede também será configurada na mesma VM de gateway de
RAS. Se a VM do gateway de RAS não puder lidar com capacidade adicional, o controlador de rede
selecionará uma nova VM de gateway RAS disponível e configurará a nova conexão nela. Essa nova VM de
gateway de RAS associada ao locatário se torna o cliente de refletor de rota do refletor de rota de gateway
RAS de locatário original.
como os pools de Gateway de RAS estão protegidos pelos balanceadores de carga de Software (SLBs), os
endereços VPN site a site dos locatários usam um único endereço ip público, chamado de VIP (endereço ip
virtual), que é convertido pelo SLBs em um endereço ip interno de datacenter, chamado de DIP (endereço
ip dinâmico), para um Gateway RAS que roteia Enterprise o tráfego para o locatário esse mapeamento de
endereço IP público para privado por SLB garante que os túneis VPN site a site sejam corretamente
estabelecidos entre os sites Enterprise e os gateways RAS de CSP e os refletores de rota.
Para obter mais informações sobre SLB, VIPs e DIPs, consulte balanceamento de carga de Software () SLB
para Sdn.
5. depois que o túnel VPN site a site entre o site do Enterprise e o Gateway de RAS do datacenter do CSP for
estabelecido para o novo locatário, as rotas estáticas associadas aos túneis serão automaticamente
provisionadas nos lados Enterprise e CSP do túnel.
6. com o roteamento de BGP de espaço da CA, o emparelhamento eBGP entre os sites Enterprise e o
refletor de rota de Gateway RAS do CSP também é estabelecido.
NOTE
Quando um gateway de RAS não é um refletor de rota para a infraestrutura BGP de um locatário, ele é um cliente de
refletor de rota na infraestrutura BGP do locatário.
O controlador de rede seleciona uma VM de gateway de RAS em espera disponível e provisiona a nova
VM de gateway de RAS com a configuração da VM de gateway de RAS com falha.
O controlador de rede atualiza a configuração de SLB correspondente para garantir que os túneis de VPN
site a site de sites de locatário para o gateway de RAS com falha sejam estabelecidos corretamente com o
novo gateway de RAS.
O controlador de rede configura o cliente de refletor de rota BGP no novo gateway.
O controlador de rede configura o novo cliente de refletor de rota BGP de gateway de RAS como ativo. o
Gateway de RAS inicia imediatamente o emparelhamento com o refletor de rota do locatário para
compartilhar informações de roteamento e habilitar o emparelhamento eBGP para o site de Enterprise
correspondente.
Falha de VM para um refletor de rota BGP de gateway de RAS
O controlador de rede executa as seguintes ações quando um refletor de rota BGP de gateway RAS falha.
O controlador de rede seleciona uma VM de gateway de RAS em espera disponível e provisiona a nova
VM de gateway de RAS com a configuração da VM de gateway de RAS com falha.
O controlador de rede configura o refletor de rota na nova VM de gateway de RAS e atribui a nova VM o
mesmo endereço IP que foi usado pela VM com falha, fornecendo, assim, a integridade da rota, apesar da
falha da VM.
O controlador de rede atualiza a configuração de SLB correspondente para garantir que os túneis de VPN
site a site de sites de locatário para o gateway de RAS com falha sejam estabelecidos corretamente com o
novo gateway de RAS.
O controlador de rede configura a nova VM de refletor de rota BGP de gateway de RAS como ativa.
O refletor de rota fica imediatamente ativo. o túnel VPN site a site para a Enterprise é estabelecido e o
refletor de rota usa o emparelhamento eBGP e as rotas de troca com os roteadores de site Enterprise.
Após a seleção de rota de BGP, o refletor de rota BGP de gateway de RAS atualiza os clientes de refletor
de rota de locatário no datacenter e sincroniza as rotas com o controlador de rede, disponibilizando o
caminho de dados de ponta a ponta para o tráfego de locatário.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Você pode usar este tópico para saber mais sobre configurações de alta disponibilidade para o SDN (Gateway
Multilotador ras para rede definida pelo software).
Este tópico inclui as seções a seguir.
Visão geral do Gateway ras
Visão geral dos pools de gateway
Visão geral da implantação do Gateway ras
Integração do Gateway ras com o controlador de rede
NOTE
As conexões L3 e GRE ignoram o SLB e se conectam diretamente ao Gateway ras designado. Essas conexões exigem que
o roteador de ponto de extremidade remoto (ou outro dispositivo de terceiros) deve ser configurado corretamente para
se conectar ao Gateway ras.
Se o roteamento BGP estiver habilitado para a conexão, o peering BGP será iniciado pelo Gateway de RAS e as
rotas serão trocadas entre gateways de nuvem e locais. As rotas aprendidas pelo BGP (ou que são rotas
configuradas estaticamente se o BGP não for usado) são enviadas ao Controlador de Rede. Em seguida, o
Controlador de Rede ressuvia as rotas para os hosts Hyper-V nos quais as VMs de locatário estão instaladas.
Neste ponto, o tráfego de locatário pode ser roteado para o site local correto. O Controlador de Rede também
cria políticas associadas de Virtualização de Rede Hyper-V que especificam locais de gateway e as rebabece para
os hosts Hyper-V.
Alta disponibilidade para IKEv2 S2S
Um Gateway ras em um pool consiste em conexões e no par BGP de locatários diferentes. Cada pool tem
gateways ativos 'M' e gateways em espera 'N'.
O Controlador de Rede lida com a falha de gateways da seguinte maneira.
O Controlador de Rede pinga constantemente os gateways em todos os pools e pode detectar um
gateway com falha ou falha. O Controlador de Rede pode detectar os seguintes tipos de falhas de
Gateway RAS.
Falha na VM do Gateway ras
Falha do host Hyper-V no qual o Gateway ras está em execução
Falha de serviço do Gateway de RAS
O Controlador de Rede armazena a configuração de todos os gateways ativos implantados. A
configuração consiste em configurações de conexão e configurações de roteamento.
Quando um gateway falha, ele afeta as conexões de locatário no gateway, bem como as conexões de
locatário localizadas em outros gateways, mas cujo RR reside no gateway com falha. O tempo de in
queda das últimas conexões é menor que o primeiro. Quando o Controlador de Rede detecta um
gateway com falha, ele executa as tarefas a seguir.
Remove as rotas das conexões impactadas dos hosts de computação.
Remove as políticas de Virtualização de Rede Hyper-V nesses hosts.
Seleciona um gateway em espera, converte-o em um gateway ativo e configura o gateway.
Altera os mapeamentos NAT no pool SLB para apontar conexões para o novo gateway.
Simultaneamente, à medida que a configuração é exibida no novo gateway ativo, as conexões S2S IKEv2
e o emparelhamento via protocolo BGP são restabelecidas. As conexões e o emparelhamento via
protocolo BGP podem ser iniciados pelo gateway de nuvem ou pelo gateway local. Os gateways
atualizam suas rotas e as enviam para o controlador de rede. Depois que o controlador de rede aprende
as novas rotas descobertas pelos gateways, o controlador de rede envia as rotas e as políticas de
virtualização de rede do Hyper-V associadas aos hosts do Hyper-V onde residem as VMs dos locatários
afetados pela falha. Essa atividade do controlador de rede é semelhante à circunstância de uma nova
configuração de conexão, mas só ocorre em uma escala maior.
Alta disponibilidade para GRE
O processo de resposta de failover do gateway de RAS por controlador de rede-incluindo detecção de falha,
copiar a configuração de conexão e roteamento para o gateway em espera, o failover do roteamento de
BGP/estático das conexões afetadas (incluindo a retirada e o redirecionamento de rotas em hosts de
computação e reemparelhamento de BGP) e a reconfiguração de políticas de virtualização de rede do Hyper-V
em hosts de computação-é a mesma para gateways e conexões GRE. No entanto, a redefinição de conexões GRE
acontece de modo diferente, e a solução de alta disponibilidade para o GRE tem alguns requisitos adicionais.
No momento da implantação do gateway, cada VM de gateway de RAS recebe um endereço IP dinâmico (DIP).
Além disso, cada VM de gateway também recebe um endereço IP virtual (VIP) para alta disponibilidade do GRE.
VIPs são atribuídos somente a gateways em pools que podem aceitar conexões GRE e não a pools não-GRE. Os
VIPs atribuídos são anunciados para a parte superior dos comutadores de rack (TOR) usando o BGP, que anuncia
ainda mais os VIPs para a rede física de nuvem. Isso torna os gateways acessíveis a partir de roteadores
remotos ou dispositivos de terceiros em que a outra extremidade da conexão GRE reside. Esse emparelhamento
via protocolo BGP é diferente do emparelhamento via protocolo BGP no nível de locatário para a troca de rotas
de locatário.
No momento do provisionamento de conexão GRE, o controlador de rede seleciona um gateway, configura um
ponto de extremidade GRE no gateway selecionado e retorna o endereço VIP do gateway atribuído. Esse VIP é
então configurado como o endereço do túnel GRE de destino no roteador remoto.
Quando um gateway falha, o controlador de rede copia o endereço VIP do gateway com falha e outros dados de
configuração para o gateway em espera. Quando o gateway em espera se torna ativo, ele anuncia o VIP para
seu comutador TOR e ainda mais na rede física. Roteadores remotos continuam conectando túneis GRE ao
mesmo VIP e a infraestrutura de roteamento garante que os pacotes sejam roteados para o novo gateway ativo.
Alta disponibilidade para gateways de encaminhamento L3
Um gateway de encaminhamento L3 de virtualização de rede Hyper-V é uma ponte entre a infraestrutura física
no datacenter e a infraestrutura virtualizada na nuvem de virtualização de rede Hyper-V. Em um gateway de
encaminhamento L3 multilocatário, cada locatário usa sua própria rede lógica marcada por VLAN para
conectividade com a rede física do locatário.
Quando um novo locatário cria um novo gateway L3, o gateway do controlador de rede Service Manager
seleciona uma VM de gateway disponível e configura uma nova interface de locatário com um endereço IP de
espaço de CA (endereço de cliente) altamente disponível (da rede lógica marcada pela VLAN do locatário). O
endereço IP é usado como o endereço IP do par no gateway remoto (rede física) e é o próximo salto para
alcançar a rede de virtualização de rede do Hyper-V do locatário.
Ao contrário das conexões de rede IPsec ou GRE, a opção TOR não aprenderá dinamicamente a rede marcada de
VLAN do locatário. O roteamento para a rede marcada por VLAN do locatário precisa ser configurado no
comutador TOR e todos os comutadores intermediários e roteadores entre a infraestrutura física e o gateway
para garantir a conectividade de ponta a ponta. A seguir está um exemplo de configuração de rede virtual do
CSP, conforme ilustrado na ilustração a seguir.
Veja a seguir exemplos de configurações de gateway de locatário, conforme ilustrado na ilustração a seguir.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
O Switch Embedded Teaming (SET) é uma solução alternativa de NIC Teaming que você pode usar em
ambientes que incluem o Hyper-V e a pilha SDN (Rede Definida pelo Software) no Windows Server 2019 e
2016. SET integra algumas funcionalidades de NIC Teaming no Com switch virtual do Hyper-V.
SET permite agrupar entre um e oito adaptadores de rede Ethernet físicos em um ou mais adaptadores de rede
virtual baseados em software. Esses adaptadores de rede virtual oferecem desempenho rápido e tolerância a
falhas no caso de uma falha do adaptador de rede.
Para obter mais informações, consulte Remote Direct Memory Access (RDMA) e Switch Embedded Teaming
(SET).
Visão geral de rede de contêineres
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Neste tópico, damos uma visão geral da pilha de rede para contêineres Windows e incluímos links para
diretrizes adicionais sobre como criar, configurar e gerenciar redes de contêiner.
Windows Contêineres de servidor são um método leve de virtualização do sistema operacional que separa
aplicativos ou serviços de outros serviços que são executados no mesmo host de contêiner. Windows
contêineres funcionam da mesma forma que as máquinas virtuais. Quando habilitado, cada contêiner tem uma
exibição separada do sistema operacional, dos processos, do sistema de arquivos, do registro e dos endereços IP,
que você pode conectar a redes virtuais.
Um Windows contêiner compartilha um kernel com o host do contêiner e todos os contêineres em execução no
host. Devido ao espaço de kernel compartilhado, esses contêineres exigem a mesma versão e configuração de
kernel. Os contêineres fornecem isolamento do aplicativo por meio da tecnologia de isolamento de processo e
namespace.
IMPORTANT
Windows contêineres não fornecem um limite de segurança agressivo e não devem ser usados para isolar código não
falso.
Com Windows contêineres, você pode implantar um host Hyper-V, em que você cria uma ou mais máquinas
virtuais nos hosts de VM. Dentro dos hosts de VM, os contêineres são criados e o acesso à rede é feito por meio
de um com switch virtual em execução dentro da máquina virtual. Você pode usar imagens reutilizáveis
armazenadas em um repositório para implantar o sistema operacional e os serviços em contêineres. Cada
contêiner tem um adaptador de rede virtual que se conecta a um com switch virtual, encaminhando o tráfego
de entrada e saída. Você pode anexar pontos de extremidade de contêiner a uma rede de host local (como NAT),
à rede física ou à rede virtual de sobreposição criada por meio da pilha SDN.
Para impor o isolamento entre contêineres no mesmo host, você cria um compartimento de rede para cada
Windows Server e contêiner do Hyper-V. Contêineres do Windows Server usam uma vNIC do host para se
conectar ao comutador virtual. Os contêineres do Hyper-V usam uma NIC de VM sintética (não exposta à VM do
utilitário) para se conectar ao comutador virtual.
Tópicos relacionados
Windows rede de contêineres:saiba como criar e gerenciar redes de contêiner para implantações de não
sobreposição/SDN.
Conexão de contêiner parauma rede virtual de locatário: saiba como criar e gerenciar redes de contêiner
para sobrepor redes virtuais com SDN.
Implantar uma infraestrutura de rede definida pelo
software
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Tópicos relacionados
SDN (rede definida pelo software)
Tecnologias SDN
Planejar SDN
Gerenciar SDN
Segurança para SDN
Solucionar problemas de SDN
Implantar uma infraestrutura de rede definida pelo
software usando scripts
11/08/2021 • 9 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Neste tópico, você implanta uma infraestrutura de SDN (Rede Definida pelo Software) da Microsoft usando
scripts. A infraestrutura inclui um controlador de rede (HA) altamente disponível, um SLB (Software Load
Balancer de HA)/MUX, redes virtuais e ACLs (Listas de Controle de Acesso) associadas. Além disso, outro script
implanta uma carga de trabalho de locatário para validar sua infraestrutura de SDN.
Se quiser que suas cargas de trabalho de locatário se comuniquem fora de suas redes virtuais, você poderá
configurar regras NAT SLB, túneis de Gateway Site a Site ou Encaminhamento de Camada 3 para roteamento
entre cargas de trabalho virtuais e físicas.
Você também pode implantar uma infraestrutura SDN usando Virtual Machine Manager (VMM). Para obter
mais informações, consulte Configurar uma infraestrutura de SDN (Rede Definida pelo Software) na malha do
VMM.
Pré-implantação
IMPORTANT
Antes de começar a implantação, você deve planejar e configurar os hosts e a infraestrutura da rede física. Para obter mais
informações, confira Planejar a infraestrutura de rede definida por software.
Todos os hosts Hyper-V devem ter Windows Server 2019 ou 2016 instalados.
Etapas de implantação
Comece configurando o comutamento virtual Hyper-V e a atribuição de endereço IP do host Hyper-V
(servidores físicos). Qualquer tipo de armazenamento compatível com o Hyper-V, compartilhado ou local pode
ser usado.
Instalar a rede de host
1. Instale os drivers de rede mais recentes disponíveis para seu hardware NIC.
2. Instale a função Hyper-V em todos os hosts (para obter mais informações, consulte Get started with
Hyper-V on Windows Server 2016.
TIP
Você poderá ignorar as etapas 4 e 5 se tiver NICs de gerenciamento separadas.
4. Consulte o tópico de planejamento ( Planejar uma infraestrutura de rede definida pelo software ) e
trabalhe com o administrador de rede para obteraID da VLAN de Gerenciamento. Anexe a vNIC de
Gerenciamento do Com switch virtual recém-criado à VLAN de Gerenciamento. Esta etapa poderá ser
omitida se seu ambiente não usar marcas de VLAN.
6. [Opcional] Implantar uma máquina virtual para hospedar Active Directory Domain Services (Instalar
Active Directory Domain Services (nível 100) e um servidor DNS.
a. Conexão máquina virtual do Servidor DNS/Active Directory para a VLAN de Gerenciamento:
NOTE
O controlador de rede dá suporte a certificados Kerberos e X.509 para autenticação. Este guia usa ambos os
mecanismos de autenticação para finalidades diferentes (embora apenas um seja necessário).
7. Insinue todos os hosts hyper-V ao domínio. Verifique se a entrada do servidor DNS para o adaptador de
rede que tem um endereço IP atribuído à rede de gerenciamento aponta para um servidor DNS que pode
resolver o nome de domínio.
a. Clique com o botão direito do mouse em Iniciar , clique em Sistema e em Alterar Configurações . b.
Clique em Alterar . c. Clique em Domínio e especifique o nome de domínio. """" d. Clique em OK . e.
Digite o nome de usuário e as credenciais de senha quando solicitado. f. Reinicie o servidor.
Validação
Use as etapas a seguir para validar se a rede de host está configurada corretamente.
1. Verifique se a opção VM foi criada com êxito:
NOTE
Relevante somente se o tráfego de Gerenciamento e Locatário compartilhar a mesma NIC.
Get-VMNetworkAdapterIsolation -ManagementOS
3. Valide todos os hosts Hyper-V e recursos de gerenciamento externos, por exemplo, servidores DNS.
Verifique se eles estão acessíveis por meio de ping usando seu endereço IP de gerenciamento e/ou FQDN
(nome de domínio totalmente qualificado).
4. Execute o comando a seguir no host de implantação e especifique o FQDN de cada host Hyper-V para
garantir que as credenciais Kerberos usadas fornece acesso a todos os servidores.
NOTE
O computador de implantação designado deve estar executando Windows Server 2016 ou posterior.
3. Expanda o arquivo zip e copie a pasta SDNExpress para a pasta do computador de C:\ implantação.
4. Compartilhe a C:\SDNExpress pasta como "SDNExpress " com permissão para Todos ler/gravar .
5. Navegue até a pasta C:\SDNExpress .
Você verá as seguintes pastas:
Validação
Supondo que o script do SDN Express foi concluído sem relatar erros, você pode executar a etapa a seguir para
garantir que os recursos de malha foram implantados corretamente e estão disponíveis para implantação de
locatário.
Use Ferramentas de Diagnóstico para garantir que não haja erros em nenhum recurso de malha no controlador
de rede.
Implantar uma carga de trabalho de locatário de exemplo com o balanceador de carga de software
Agora que os recursos de malha foram implantados, você pode validar sua implantação de SDN de ponta a
ponta implantando uma carga de trabalho de locatário de exemplo. Essa carga de trabalho de locatário consiste
em duas sub-redes virtuais (camada da Web e camada de banco de dados) protegidas por meio de regras de
ACL (Lista de Controle de Acesso) usando o firewall distribuído SDN. A sub-rede virtual da camada da Web é
acessível por meio do SLB/MUX usando um endereço IP Virtual (VIP). O script implanta automaticamente duas
máquinas virtuais da camada da Web e uma máquina virtual da camada de banco de dados e as conecta às
sub-redes virtuais.
1. Personalize o arquivo SDNExpress\scripts\TenantConfig.psd1 alterando as marcas<< Substituir >> por
valores específicos (por exemplo: nome da imagem VHD, nome REST do controlador de rede, nome do
vSwitch etc., conforme definido anteriormente no arquivo FabricConfig.psd1)
2. Execute o script. Por exemplo:
3. Para desfazer a configuração, execute o mesmo script com o parâmetro undo. Por exemplo:
SDNExpress\scripts\SDNExpressTenant.ps1 -Undo -ConfigurationDataFile TenantConfig.psd1 -Verbose
Validação
Para validar se a implantação do locatário foi bem-sucedida, faça o seguinte:
1. Faça logon na máquina virtual da camada de banco de dados e tente efetuar ping no endereço IP de uma
das máquinas virtuais da camada da Web (verifique se Windows Firewall está desligado em máquinas
virtuais da camada da Web).
2. Verifique se há erros nos recursos de locatário do controlador de rede. Execute o seguinte em qualquer
host Hyper-V com conectividade de Camada 3 com o controlador de rede:
3. Para verificar se o balanceador de carga está sendo executado corretamente, execute o seguinte em
qualquer host Hyper-V:
TIP
Pesquise VIPIP a variável TenantConfig.psd1.
Execute isso várias vezes para ver a opção do balanceador de carga entre os DIPs disponíveis. Você
também pode observar esse comportamento usando um navegador da Web. Navegue até
<VIP IP address>/unique.htm . Feche o navegador, abra uma nova instância e navegue novamente. Você
verá a página azul e a página verde alternativa, exceto quando o navegador armazenar em cache a
página antes que o cache esnoque.
Implantar tecnologias de rede definidas pelo
software usando o Windows PowerShell
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Você pode usar os tópicos desta seção para implantar tecnologias de SDN individuais usando o Windows
PowerShell.
Esta seção contém o tópico a seguir:
Implantar controlador de rede usando o Windows PowerShell
Implantar o controlador de rede usando o Windows
PowerShell
10/08/2021 • 15 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
este tópico fornece instruções sobre como usar Windows PowerShell para implantar o controlador de rede em
uma ou mais máquinas virtuais (VMs) que estão executando o Windows Server 2019 ou 2016.
IMPORTANT
Não implante a função de servidor do controlador de rede em hosts físicos. Para implantar o controlador de rede, você
deve instalar a função de servidor do controlador de rede em uma VM de máquina virtual do Hyper-V ( ) instalada em
um host do Hyper-v. depois de instalar o controlador de rede em VMs em três - hosts hyper-v diferentes, você deve
habilitar os - hosts hyper-v para o SDN de rede definido pelo Software ( ) adicionando os hosts ao controlador de rede
usando o comando Windows PowerShell New-NetworkControllerSer ver . Ao fazer isso, você está permitindo que o
software SDN Load Balancer funcione. Para obter mais informações, consulte New-NetworkControllerServer.
IMPORTANT
Não implante a função de servidor do controlador de rede em hosts físicos. Para implantar o controlador de rede, você
deve instalar a função de servidor do controlador de rede em uma VM de máquina virtual do Hyper-V ( ) instalada em
um host do Hyper-v. Depois de instalar o controlador de rede em VMs em três - hosts Hyper-v diferentes, você deve
habilitar os - hosts Hyper-v para o Sdn de rede definido pelo software ( ) adicionando os hosts ao controlador de rede. Ao
fazer isso, você está permitindo que o software SDN Load Balancer funcione.
para instalar o controlador de rede usando Windows PowerShell, digite os comandos a seguir em um prompt
de Windows PowerShell e pressione ENTER.
Install-WindowsFeature -Name NetworkController -IncludeManagementTools
A instalação do controlador de rede requer que você reinicie o computador. Para fazer isso, digite o comando a
seguir e pressione ENTER.
Restart-Computer
NOTE
você pode executar os procedimentos nas seções a seguir diretamente na VM em que você instalou o controlador de
rede ou pode usar o Ferramentas de Administração de Servidor Remoto para Windows Server 2016 para executar os
procedimentos de um computador remoto que esteja executando Windows Server 2016 ou Windows 10. Além disso, a
associação em Administradores , ou equivalente, é o requisito mínimo necessário para executar esse procedimento. Se o
computador ou a VM na qual você instalou o controlador de rede estiver ingressado em um domínio, sua conta de
usuário deverá ser membro de usuários de domínio .
Você pode criar um cluster de controlador de rede criando um objeto de nó e, em seguida, configurando o
cluster.
Criar um objeto de nó
Você precisa criar um objeto de nó para cada VM que seja membro do cluster do controlador de rede.
para criar um objeto de nó, digite o seguinte comando no prompt de comando Windows PowerShell e
pressione ENTER. Certifique-se de adicionar valores para cada parâmetro que são apropriados para sua
implantação.
PA RÂ M ET RO DESC RIÇ Ã O
Configurar o cluster
para configurar o cluster, digite o seguinte comando no prompt de comando Windows PowerShell e pressione
ENTER. Certifique-se de adicionar valores para cada parâmetro que são apropriados para sua implantação.
PA RÂ M ET RO DESC RIÇ Ã O
PA RÂ M ET RO DESC RIÇ Ã O
PA RÂ M ET RO DESC RIÇ Ã O
$cred=New-Object Microsoft.Windows.Networkcontroller.credentialproperties
$cred.type="usernamepassword"
$cred.username="admin"
$cred.value="abcd"
3. Para recuperar a credencial que você adicionou ao Controlador de Rede, digite o comando a seguir e
pressione ENTER. Certifique-se de adicionar valores para cada parâmetro apropriado para sua
implantação.
4. Revise a saída do comando, que deve ser semelhante à saída de exemplo a seguir.
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 : Microsoft.Windows.NetworkController.CredentialProperties
NOTE
Ao executar o comando Get-NetworkControllerCredential, você pode atribuir a saída do comando a uma
variável usando o operador dot para listar as propriedades das credenciais. Por exemplo, $cred. Propriedades.
TA REFA C O M A N DO SIN TA XE
NOTE
Windows PowerShell comandos para o Controlador de Rede estão na Biblioteca do TechNet em Cmdlets do Controlador
de Rede.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Você pode usar os tópicos desta seção para gerenciar a rede definida pelo software, incluindo cargas de
trabalho de locatário e redes virtuais.
NOTE
Para obter uma documentação adicional de rede definida pelo software, você pode usar as seções de biblioteca a seguir.
Tecnologias de SDN
Planejar SDN
Implantar SDN
Segurança para SDN
Solucionar problemas de SDN
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Você pode usar os tópicos nesta seção para gerenciar Redes Virtuais de Virtualização de Rede Hyper-V do
Locatário depois de implantar a Rede Definida pelo Software usando o tópico Implantar uma infraestrutura de
rede definida pelo software usando scripts.
Esta seção contém os seguintes tópicos.
Noções básicas sobre o uso de redes virtuais e VLANs
Usar ACLs (listas de controle de acesso) para gerenciar o tráfego de rede do datacenter Flow
Criar, excluir ou atualizar redes virtuais de locatário
Adicionar um gateway virtual a uma rede virtual de locatário
Conectar pontos de extremidade do contêiner a uma rede virtual do locatário
Entender o uso de redes virtuais e VLANs
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Neste tópico, você aprenderá sobre redes virtuais de virtualização de rede Hyper-V e como elas diferem das
VLANs (redes locais virtuais). Com a virtualização de rede hyper-V, você cria redes virtuais de sobreposição,
também chamadas de redes virtuais.
A SDN (Rede Definida pelo Software) no Windows Server 2016 baseia-se na política de programação para
sobrepor redes virtuais em um Comutamento Virtual do Hyper-V. Você pode criar redes virtuais de
sobreposição, também chamadas de Redes Virtuais, com a Virtualização de Rede Hyper-V.
Quando você implanta a Virtualização de Rede Hyper-V, as redes de sobreposição são criadas encapsulando o
quadro Ethernet de Camada 2 da máquina virtual de locatário original com um header de sobreposição ( ou
túnel – (por exemplo, VXLAN ou NVGRE) e os headers IP de Camada 3 e Ethernet de Camada 2 da rede de
subposição (ou física). As redes virtuais de sobreposição são identificadas por um VNI (Identificador de Rede
Virtual) de 24 bits para manter o isolamento de tráfego de locatário e permitir endereços IP sobrepostos. A VNI
é composta por uma VSID (ID de sub-rede virtual), ID de comutamento lógico e ID de túnel.
Além disso, cada locatário recebe um domínio de roteamento (semelhante ao roteamento e encaminhamento
virtual – VRF) para que vários prefixos de sub-rede virtuais (cada um representado por uma VNI) possam ser
roteados diretamente entre si. Não há suporte para o roteamento entre locatários (ou domínio de roteamento
cruzado) sem passar por um gateway.
A rede física na qual o tráfego encapsulado de cada locatário é encapsulado é representada por uma rede lógica
chamada rede lógica do provedor. Essa rede lógica do provedor consiste em uma ou mais sub-redes, cada uma
representada por um Prefixo IP e, opcionalmente, uma marca VLAN 802.1q.
Você pode criar redes lógicas e sub-redes adicionais para fins de infraestrutura para transportar o tráfego de
gerenciamento, o tráfego de armazenamento, o tráfego de migração ao vivo etc.
O Microsoft SDN não dá suporte ao isolamento de redes de locatário usando VLANs. O isolamento de locatário
é realizado exclusivamente usando o encapsulamento e redes virtuais de sobreposição de Virtualização de Rede
Hyper-V.
Criar, excluir ou atualizar redes virtuais do locatário
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Neste tópico, você aprenderá a criar, excluir e atualizar redes virtuais de virtualização de rede Hyper-V depois de
implantar o SDN (rede definida pelo software). A virtualização de rede Hyper-V ajuda você a isolar redes de
locatários para que cada rede de locatários seja uma entidade separada. Cada entidade não tem nenhuma
possibilidade de conexão cruzada, a menos que você configure cargas de trabalho de acesso público.
N O M E DO LO C ATÁ RIO ID DE SUB - REDE VIRT UA L P REF IXO DE SUB - REDE VIRT UA L
o script de exemplo a seguir usa Windows PowerShell comandos exportados do módulo NetworkController
para criar a rede virtual da Contoso e uma sub-rede:
import-module networkcontroller
$URI = "https://ncrest.contoso.local"
$vnet.properties.AddressSpace.AddressPrefixes += "24.30.2.0/24"
$vnet.properties.Subnets += $vsubnet
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Saiba como usar Windows PowerShell e scripts para fornecer conectividade site a site para as redes virtuais do
locatário. Neste tópico, você adiciona gateways virtuais de locatário a instâncias do gateway RAS que são
membros de pools de gateways, usando o Controlador de Rede. O gateway ras dá suporte a até cem locatários,
dependendo da largura de banda usada por cada locatário. O Controlador de Rede determina automaticamente
o melhor Gateway RAS a ser usado quando você implanta um novo gateway virtual para seus locatários.
Cada gateway virtual corresponde a um locatário específico e consiste em uma ou mais conexões de rede
(túneis VPN site a site) e, opcionalmente, Border Gateway Protocol (BGP). Quando você fornece conectividade
site a site, seus clientes podem conectar sua rede virtual de locatário a uma rede externa, como uma rede
corporativa de locatário, uma rede de provedor de serviços ou a Internet.
Ao implantar um Gateway Vir tual de Locatário, você tem as seguintes opções de configuração:
VPN (rede virtual privada) site a site do IPSec Configuração do roteador BGP
GRE (Encapsulamento de Roteamento Genérico) Configuração de par BGP
Encaminhamento de camada 3 Configuração de políticas de roteamento BGP
Os Windows PowerShell exemplo de scripts e comandos neste tópico demonstram como implantar um gateway
virtual de locatário em um Gateway ras com cada uma dessas opções.
IMPORTANT
Antes de executar qualquer um dos comandos Windows PowerShell e scripts fornecidos, você deve alterar todos os
valores de variáveis para que os valores sejam apropriados para sua implantação.
$uri = "https://ncrest.contoso.com"
2. Verifique se a sub-rede usada para rotear pacotes fora da rede virtual do locatário existe no Controlador
de Rede. Você também recupera a sub-rede virtual usada para roteamento entre o gateway de locatário e
a rede virtual.
$uri = "https://ncrest.contoso.com"
3. Crie um novo objeto para o gateway virtual de locatário e, em seguida, atualize a referência do pool de
gateway. Você também especifica a sub-rede virtual usada para roteamento entre o gateway e a rede
virtual. Depois de especificar a sub-rede virtual, atualize o restante das propriedades do objeto do
gateway virtual e adicione o novo gateway virtual para o locatário.
# Specify the Virtual Subnet that is to be used for routing between the gateway and Virtual Network
$VirtualGWProperties.GatewaySubnets = @()
$VirtualGWProperties.GatewaySubnets += $RoutingSubnet
4. Crie uma conexão VPN site a site com encaminhamento IPsec, GRE ou Camada 3 (L3).
TIP
Opcionalmente, você pode combinar todas as etapas anteriores e configurar um gateway virtual de locatário com
todas as três opções de conexão. Para obter mais detalhes, consulte Configurar um gateway com todos os três
tipos de conexão (IPsec, GRE, L3) e BGP.
$nwConnectionProperties.IpSecConfiguration.QuickMode = New-Object
Microsoft.Windows.NetworkController.QuickMode
$nwConnectionProperties.IpSecConfiguration.QuickMode.PerfectForwardSecrecy = "PFS2048"
$nwConnectionProperties.IpSecConfiguration.QuickMode.AuthenticationTransformationConstant =
"SHA256128"
$nwConnectionProperties.IpSecConfiguration.QuickMode.CipherTransformationConstant = "DES3"
$nwConnectionProperties.IpSecConfiguration.QuickMode.SALifeTimeSeconds = 1233
$nwConnectionProperties.IpSecConfiguration.QuickMode.IdleDisconnectSeconds = 500
$nwConnectionProperties.IpSecConfiguration.QuickMode.SALifeTimeKiloBytes = 2000
$nwConnectionProperties.IpSecConfiguration.MainMode = New-Object
Microsoft.Windows.NetworkController.MainMode
$nwConnectionProperties.IpSecConfiguration.MainMode.DiffieHellmanGroup = "Group2"
$nwConnectionProperties.IpSecConfiguration.MainMode.IntegrityAlgorithm = "SHA256"
$nwConnectionProperties.IpSecConfiguration.MainMode.EncryptionAlgorithm = "AES256"
$nwConnectionProperties.IpSecConfiguration.MainMode.SALifeTimeSeconds = 1234
$nwConnectionProperties.IpSecConfiguration.MainMode.SALifeTimeKiloBytes = 2000
# Update the IPv4 Routes that are reachable over the site-to-site VPN Tunnel
$nwConnectionProperties.Routes = @()
$ipv4Route = New-Object Microsoft.Windows.NetworkController.RouteInfo
$ipv4Route.DestinationPrefix = "14.1.10.1/32"
$ipv4Route.metric = 10
$nwConnectionProperties.Routes += $ipv4Route
# Update the IPv4 Routes that are reachable over the site-to-site VPN Tunnel
$nwConnectionProperties.Routes = @()
$ipv4Route = New-Object Microsoft.Windows.NetworkController.RouteInfo
$ipv4Route.DestinationPrefix = "14.2.20.1/32"
$ipv4Route.metric = 10
$nwConnectionProperties.Routes += $ipv4Route
# Create a new object for the Logical Network to be used for L3 Forwarding
$lnProperties = New-Object Microsoft.Windows.NetworkController.LogicalNetworkProperties
$lnProperties.NetworkVirtualizationEnabled = $false
$lnProperties.Subnets = @()
# Create a new object for the Logical Subnet to be used for L3 Forwarding and update
properties
$logicalsubnet = New-Object Microsoft.Windows.NetworkController.LogicalSubnet
$logicalsubnet.ResourceId = "Contoso_L3_Subnet"
$logicalsubnet.Properties = New-Object
Microsoft.Windows.NetworkController.LogicalSubnetProperties
$logicalsubnet.Properties.VlanID = 1001
$logicalsubnet.Properties.AddressPrefix = "10.127.134.0/25"
$logicalsubnet.Properties.DefaultGateways = "10.127.134.1"
$lnProperties.Subnets += $logicalsubnet
$nwConnectionProperties.IPAddresses = @()
$localIPAddress = New-Object Microsoft.Windows.NetworkController.CidrIPAddress
$localIPAddress.IPAddress = "10.127.134.55"
$localIPAddress.PrefixLength = 25
$nwConnectionProperties.IPAddresses += $localIPAddress
$nwConnectionProperties.PeerIPAddresses = @("10.127.134.65")
# Update the IPv4 Routes that are reachable over the site-to-site VPN Tunnel
$nwConnectionProperties.Routes = @()
$ipv4Route = New-Object Microsoft.Windows.NetworkController.RouteInfo
$ipv4Route.DestinationPrefix = "14.2.20.1/32"
$ipv4Route.metric = 10
$nwConnectionProperties.Routes += $ipv4Route
b. Adicione um Par de BGP para esse locatário, correspondente à Conexão de Rede VPN site a site
adicionada acima.
# Create a new object for Tenant BGP Peer
$bgpPeerProperties = New-Object Microsoft.Windows.NetworkController.VGwBgpPeerProperties
# Specify the Virtual Subnet that is to be used for routing between GW and VNET
$VirtualGWProperties.GatewaySubnets = @()
$VirtualGWProperties.GatewaySubnets += $RoutingSubnet
$ipSecConnection.Properties.IpSecConfiguration = New-Object
Microsoft.Windows.NetworkController.IpSecConfiguration
$ipSecConnection.Properties.IpSecConfiguration.AuthenticationMethod = "PSK"
$ipSecConnection.Properties.IpSecConfiguration.SharedSecret = "P@ssw0rd"
$ipSecConnection.Properties.IpSecConfiguration.QuickMode = New-Object
Microsoft.Windows.NetworkController.QuickMode
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.PerfectForwardSecrecy = "PFS2048"
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.AuthenticationTransformationConstant = "SHA256128"
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.CipherTransformationConstant = "DES3"
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.SALifeTimeSeconds = 1233
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.IdleDisconnectSeconds = 500
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.SALifeTimeKiloBytes = 2000
$ipSecConnection.Properties.IpSecConfiguration.MainMode = New-Object
Microsoft.Windows.NetworkController.MainMode
$ipSecConnection.Properties.IpSecConfiguration.MainMode.DiffieHellmanGroup = "Group2"
$ipSecConnection.Properties.IpSecConfiguration.MainMode.IntegrityAlgorithm = "SHA256"
$ipSecConnection.Properties.IpSecConfiguration.MainMode.EncryptionAlgorithm = "AES256"
$ipSecConnection.Properties.IpSecConfiguration.MainMode.SALifeTimeSeconds = 1234
$ipSecConnection.Properties.IpSecConfiguration.MainMode.SALifeTimeKiloBytes = 2000
$ipSecConnection.Properties.IPAddresses = @()
$ipSecConnection.Properties.PeerIPAddresses = @()
$ipSecConnection.Properties.Routes = @()
$ipSecConnection.Properties.DestinationIPAddress = "10.127.134.121"
$greConnection.Properties.IPAddresses = @()
$greConnection.Properties.PeerIPAddresses = @()
$greConnection.Properties.Routes = @()
$greConnection.Properties.DestinationIPAddress = "10.127.134.122"
$l3Connection.Properties.IPAddresses = @()
$localIPAddress = New-Object Microsoft.Windows.NetworkController.CidrIPAddress
$localIPAddress.IPAddress = "10.127.134.55"
$localIPAddress.PrefixLength = 25
$l3Connection.Properties.IPAddresses += $localIPAddress
$l3Connection.Properties.PeerIPAddresses = @("10.127.134.65")
$l3Connection.Properties.Routes = @()
$ipv4Route = New-Object Microsoft.Windows.NetworkController.RouteInfo
$ipv4Route.DestinationPrefix = "14.2.20.1/32"
$ipv4Route.metric = 10
$ipv4Route.metric = 10
$l3Connection.Properties.Routes += $ipv4Route
$bgpRouter.Properties.ExtAsNumber = "0.64512"
$bgpRouter.Properties.RouterId = "192.168.0.2"
$bgpRouter.Properties.RouterIP = @("192.168.0.2")
$bgpRouter.Properties.BgpPeers = @()
$bgpRouter.Properties.BgpPeers += $bgpPeer_IPSec
$bgpRouter.Properties.BgpPeers += $bgpPeer_Gre
$bgpRouter.Properties.BgpPeers += $bgpPeer_L3
$VirtualGWProperties.BgpRouters += $bgpRouter
Navegue até a estrutura da variável para acessar a propriedade necessária e defini-la como o
valor de atualizações
$nwConnection.properties.IpSecConfiguration.SharedSecret = "C0mplexP@ssW0rd"
Remover um gateway
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Neste tópico, mostraremos como conectar pontos de extremidade do contêiner a uma rede virtual de locatário
existente criada por meio de SDN. use o driver de rede l2bridge (e, opcionalmente, l2tunnel) disponível com o
plug-in Windows libnetwork para o docker para criar uma rede de contêiner na VM de locatário.
No tópico drivers de rede do contêiner , discutimos que os vários drivers de rede estão disponíveis por meio do
Docker no Windows. Para SDN, use os drivers l2bridge e l2tunnel . Para ambos os drivers, cada ponto de
extremidade do contêiner está na mesma sub-rede virtual que a máquina virtual do host do contêiner
(locatário).
O serviço de rede de host (HNS), por meio do plug-in de nuvem privada, atribui dinamicamente os endereços IP
para pontos de extremidade de contêiner. Os pontos de extremidade do contêiner têm endereços IP exclusivos,
mas compartilham o mesmo endereço MAC da máquina virtual do host do contêiner (locatário) devido à
conversão de endereço da camada 2.
A política de rede (ACLs, encapsulamento e QoS) para esses pontos de extremidade de contêiner são impostas
no host físico do Hyper-V conforme recebido pelo controlador de rede e definido em sistemas de
gerenciamento de camada superior.
As diferenças entre os drivers l2bridge e l2tunnel são:
L 2B RIDGE L 2T UN N EL
Pontos de extremidade do contêiner que residem em: Todo o tráfego de rede entre dois pontos de extremidade de
A mesma máquina virtual do host do contêiner e na contêiner é encaminhado para o host do Hyper-V físico,
mesma sub-rede têm todo o tráfego de rede ponte independentemente do host ou da sub-rede. A política de
dentro do comutador virtual do Hyper-V. rede se aplica a tráfego de rede entre sub-redes e entre
VMs de host de contêiner diferentes ou em sub- hosts.
redes diferentes têm seu tráfego encaminhado para o
host do Hyper-V físico.
A política de rede não é imposta, pois o tráfego de rede
entre os contêineres no mesmo host e na mesma sub-rede
não flui para o host físico. A política de rede aplica-se
somente ao tráfego de rede do contêiner entre hosts ou
entre sub-redes.
NOTE
Esses modos de rede não funcionam para conectar pontos de extremidade de contêiner do Windows a uma rede virtual
de locatário na nuvem pública do Azure.
Pré-requisitos
Uma infraestrutura de SDN implantada com o controlador de rede.
Uma rede virtual de locatário foi criada.
uma máquina virtual de locatário implantada com o recurso de contêiner Windows habilitado, docker
instalado e recurso do Hyper-V habilitado. O recurso Hyper-V é necessário para instalar vários binários
para redes l2bridge e l2tunnel.
NOTE
A virtualização aninhada e a exposição de extensões de virtualização não são necessárias, a menos que usem contêineres
Hyper-V.
Fluxo de trabalho
1. Adicione várias configurações de IP a um recurso de NIC de VM existente por meio do controlador de rede
(host Hyper-V) 2. Habilite o proxy de rede no host para alocar endereços IP de CA para pontos de extremidade
de contêiner (host Hyper-V) 3. Instale o plug-in de nuvem privada para atribuir endereços IP de autoridade de
certificação aos pontos de extremidade do contêiner (VM do host do contêiner) 4. Criar uma rede l2bridge ou
l2tunnel usando o Docker (VM do host do contêiner)
NOTE
Não há suporte para várias configurações de IP em recursos de NIC de VM criados por meio de System Center Virtual
Machine Manager. É recomendável para esses tipos de implantações que você cria o recurso NIC da VM fora da banda
usando o PowerShell do controlador de rede.
# 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"
$resourceid = "IP_192_168_1_1"
if ($i -eq 10)
{
$resourceid += "10"
$ipstr = "192.168.1.110"
}
else
{
$resourceid += "0$i"
$ipstr = "192.168.1.10$i"
}
$newipconfig.ResourceId = $resourceid
$props.PrivateIPAddress = $ipstr
$props.PrivateIPAllocationMethod = "Static"
$props.Subnet = new-object Microsoft.Windows.NetworkController.Subnet
$props.Subnet.ResourceRef = $vmsubnet.ResourceRef
$props.AccessControlList = new-object Microsoft.Windows.NetworkController.AccessControlList
$props.AccessControlList.ResourceRef = $allowallacl.ResourceRef
$newipconfig.Properties = $props
$vmnic.Properties.IpConfigurations += $newipconfig
}
PS C:\> ConfigureMCNP.ps1
PS C:\> InstallPrivateCloudPlugin.ps1
NOTE
A atribuição de IP estático não tem suporte com redes de contêiner l2bridge ou l2tunnel quando usadas com a pilha do
Microsoft Sdn.
Mais informações
Para obter mais detalhes sobre como implantar uma infraestrutura de SDN, consulte implantar uma
infraestrutura de rede definida pelo software.
Configurar a criptografia para uma sub-rede virtual
13/08/2021 • 5 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
A criptografia de rede virtual permite a criptografia do tráfego de rede virtual entre VMs que se comunicam
entre si em sub-redes marcadas como 'Criptografia Habilitada'. Ela também utiliza o DTLS (Datagrama do
protocolo TLS) na sub-rede virtual para criptografar os pacotes. O DTLS protege contra interceptações,
falsificação e adulteração por qualquer pessoa com acesso à rede física.
A criptografia de rede virtual requer:
Certificados de criptografia instalados em cada um dos hosts Hyper-V habilitados para SDN.
Um objeto de credencial no Controlador de Rede que referencia a impressão digital desse certificado.
A configuração em cada uma das Redes Virtuais contém sub-redes que exigem criptografia.
Depois de habilitar a criptografia em uma sub-rede, todo o tráfego de rede dentro dessa sub-rede será
criptografado automaticamente, além de qualquer criptografia no nível do aplicativo que também possa ocorrer.
O tráfego que cruza entre sub-redes, mesmo que marcado como criptografado, é enviado descriptografado
automaticamente. Qualquer tráfego que cruze o limite da rede virtual também é enviado descriptografado.
NOTE
Ao se comunicar com outra VM na mesma sub-rede, esteja ela conectada ou conectada posteriormente, o tráfego é
criptografado automaticamente.
TIP
Se você tiver que restringir os aplicativos a se comunicarem apenas na sub-rede criptografada, poderá usar ACLs (Listas
de Controle de Acesso) somente para permitir a comunicação dentro da sub-rede atual. Para obter mais informações,
consulte Usar ACLs (listasde controle de acesso) para gerenciar o tráfego de rede do datacenter Flow .
#Generate Key
$key = new-object -com "X509Enrollment.CX509PrivateKey.1"
$key.ProviderName = $cryptographicProviderName
$key.KeySpec = 1 #X509KeySpec.XCN_AT_KEYEXCHANGE
$key.Length = $privateKeyLength
$key.MachineContext = 1
$key.ExportPolicy = 0x2 #X509PrivateKeyExportFlags.XCN_NCRYPT_ALLOW_EXPORT_FLAG
$key.Create()
#Configure Eku
$serverauthoid = new-object -com "X509Enrollment.CObjectId.1"
$serverauthoid.InitializeFromValue($sslServerOidString)
$clientauthoid = new-object -com "X509Enrollment.CObjectId.1"
$clientauthoid.InitializeFromValue($sslClientOidString)
$ekuoids = new-object -com "X509Enrollment.CObjectIds.1"
$ekuoids.add($serverauthoid)
$ekuoids.add($clientauthoid)
$ekuext = new-object -com "X509Enrollment.CX509ExtensionEnhancedKeyUsage.1"
$ekuext.InitializeEncode($ekuoids)
#Request Certificate
$cert = new-object -com "X509Enrollment.CX509CertificateRequestCertificate.1"
Thumbprint Subject
---------- -------
84857CBBE7A1C851A80AE22391EB2C39BF820CE7 CN=MyNetwork
5EFF2CE51EACA82408572A56AE1A9BCC7E0843C6 CN=EncryptedVirtualNetworks
$subjectName = "EncryptedVirtualNetworks"
$cert = Get-ChildItem cert:\localmachine\my | ? {$_.Subject -eq "CN=$subjectName"}
[System.io.file]::WriteAllBytes("c:\$subjectName.pfx", $cert.Export("PFX", "secret"))
Export-Certificate -Type CERT -FilePath "c:\$subjectName.cer" -cert $cert
Directory: C:\
$server = "Server01"
$subjectname = "EncryptedVirtualNetworks"
copy c:\$SubjectName.* \\$server\c$
invoke-command -computername $server -ArgumentList $subjectname,"secret" {
param (
[string] $SubjectName,
[string] $Secret
)
$certFullPath = "c:\$SubjectName.cer"
$certFullPath = "c:\$SubjectName.pfx"
$certificate = new-object System.Security.Cryptography.X509Certificates.X509Certificate2
$certificate.import($certFullPath, $Secret, "MachineKeySet,PersistKeySet")
PSParentPath: Microsoft.PowerShell.Security\Certificate::localmachine\my
Thumbprint Subject
---------- -------
5EFF2CE51EACA82408572A56AE1A9BCC7E0843C6 CN=EncryptedVirtualNetworks
PSParentPath: Microsoft.PowerShell.Security\Certificate::localmachine\root
Thumbprint Subject
---------- -------
5EFF2CE51EACA82408572A56AE1A9BCC7E0843C6 CN=EncryptedVirtualNetworks
$uri = "https://nc.contoso.com"
TIP
Você pode reutilizar essa credencial para cada rede virtual criptografada ou pode implantar e usar um certificado exclusivo
para cada locatário.
$vnet.properties.EncryptionCredential = $certcred
# Replace the Subnets index with the value corresponding to the subnet you want encrypted.
# Repeat for each subnet where encryption is needed
$vnet.properties.Subnets[0].properties.EncryptionEnabled = $true
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
Um aspecto fundamental da monetização de rede de nuvem é poder cobrar pela utilização da largura de banda
da rede. Os dados de saída são cobrados com base na quantidade total de dados que sai do data center pela
Internet em um determinado ciclo de cobrança.
Egress medição para tráfego de rede SDN no Windows Server 2019 permite a capacidade de oferecer
medidores de uso para transferências de dados de saída. O tráfego de rede que sai de cada rede virtual, mas
permanece dentro do data center pode ser rastreado separadamente para que possa ser excluído dos cálculos
de cobrança. Pacotes associados a endereços IP de destino que não estão incluídos em um dos intervalos de
endereços não cobrados são rastreados como transferências de dados de saída cobradas.
import-module NetworkController
$uri = "https://sdn.contoso.com"
AddressSpace : Microsoft.Windows.NetworkController.AddressSpace
DhcpOptions :
UnbilledAddressRanges :
ConfigurationState :
ProvisioningState : Succeeded
Subnets : {21e71701-9f59-4ee5-b798-2a9d8c2762f0, 5f4758ef-9f96-40ca-a389-35c414e996cc,
29fe67b8-6f7b-486c-973b-8b9b987ec8b3}
VirtualNetworkPeerings :
EncryptionCredential :
LogicalNetwork : Microsoft.Windows.NetworkController.LogicalNetwork
TIP
Se você adicionar várias sub-redes IP, use uma vírgula entre cada uma das sub-redes IP. Não inclua espaços antes
ou depois da vírgula.
Confirm
Performing the operation 'New-NetworkControllerVirtualNetwork' on entities of type
'Microsoft.Windows.NetworkController.VirtualNetwork' via
'https://sdn.contoso.com/networking/v3/virtualNetworks/VNet1'. 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 : Microsoft.Windows.NetworkController.VirtualNetworkProperties
AddressSpace : Microsoft.Windows.NetworkController.AddressSpace
DhcpOptions :
UnbilledAddressRanges : 10.10.2.0/24,192.168.2.0/24
ConfigurationState :
ProvisioningState : Succeeded
Subnets : {21e71701-9f59-4ee5-b798-2a9d8c2762f0, 5f4758ef-9f96-40ca-a389-35c414e996cc,
29fe67b8-6f7b-486c-973b-8b9b987ec8b3}
VirtualNetworkPeerings :
EncryptionCredential :
LogicalNetwork : Microsoft.Windows.NetworkController.LogicalNetwork
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Este tópico contém links para a documentação que permite gerenciar cargas de trabalho de locatário
adicionando VMs (máquinas virtuais) de locatário, usando soluções de virtualização de rede, configurando o
balanceamento de carga de software e muito mais.
Esta seção inclui os seguintes tópicos.
criar uma VM e Conexão a uma rede Virtual de locatário ou VLAN
Configurar qualidade de serviço (QoS) para um adaptador de rede de VM do locatário
Configurar as listas de controle de acesso (ACLs) do firewall do datacenter
Configurar o Load Balancer de software para balanceamento de carga e NAT (conversão de endereços de
rede)
Usar dispositivos de rede virtual em uma rede virtual
Clustering de convidado em uma rede virtual
Criar uma máquina virtual e se conectar a uma rede
virtual de locatário ou VLAN
13/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Neste tópico, você cria uma VM de locatário e a conecta a uma rede virtual que você criou com a virtualização
de rede Hyper-V ou a uma rede de área local virtual (VLAN). você pode usar Windows PowerShell cmdlets do
controlador de rede para se conectar a uma rede virtual ou NetworkControllerRESTWrappers para se conectar a
uma VLAN.
Use os processos descritos neste tópico para implantar dispositivos virtuais. Com algumas etapas adicionais,
você pode configurar dispositivos para processar ou inspecionar pacotes de dados que fluem de ou para outras
VMs na rede virtual.
as seções neste tópico incluem o exemplo Windows PowerShell comandos que contêm valores de exemplo para
muitos parâmetros. Certifique-se de substituir os valores de exemplo nesses comandos por valores apropriados
para sua implantação antes de executar esses comandos.
Pré-requisitos
1. Adaptadores de rede VM criados com endereços MAC estáticos para o tempo de vida da VM.
Se o endereço MAC for alterado durante o tempo de vida da VM, o controlador de rede não poderá
configurar a política necessária para o adaptador de rede. Não configurar a política para a rede impede
que o adaptador de rede processe o tráfego de rede e toda a comunicação com a rede falhe.
2. Se a VM exigir acesso à rede na inicialização, não inicie a VM até depois de definir a ID da interface na
porta do adaptador de rede da VM. Se você iniciar a VM antes de definir a ID da interface e a interface de
rede não existir, a VM não poderá se comunicar na rede no controlador de rede e todas as políticas
aplicadas.
3. Se você precisar de ACLs personalizadas para esse adaptador de rede, crie a ACL agora usando as
instruções no tópico usar ACLs (listas de controle de acesso) para gerenciar o tráfego de rede do
datacenter Flow
Verifique se você já criou uma rede virtual antes de usar este comando de exemplo. Para obter mais
informações, consulte criar, excluir ou atualizar redes virtuais de locatário.
2. Obtenha a rede virtual que contém a sub-rede à qual você deseja conectar o adaptador de rede.
TIP
Nesta etapa, você usa a ACL personalizada.
$vmnicproperties.DnsSettings = new-object
Microsoft.Windows.NetworkController.NetworkInterfaceDnsSettings
$vmnicproperties.DnsSettings.DnsServers = @("24.30.1.11", "24.30.1.12")
$vmnicproperties.IpConfigurations = @($ipconfiguration)
New-NetworkControllerNetworkInterface –ResourceID "MyVM_Ethernet1" –Properties $vmnicproperties –
ConnectionUri $uri
NOTE
Você deve executar esses comandos no host do Hyper-V onde a VM está instalada.
#Do not change the hardcoded IDs in this section, because they are fixed values and must not change.
$FeatureId = "9940cd46-8b06-43bb-b9d5-93d50381fd56"
$Feature.SettingData.ProfileId = "{$($nic.InstanceId)}"
$Feature.SettingData.NetCfgInstanceId = "{56785678-a0e5-4a26-bc9b-c0cba27311a3}"
$Feature.SettingData.CdnLabelString = "TestCdn"
$Feature.SettingData.CdnLabelId = 1111
$Feature.SettingData.ProfileName = "Testprofile"
$Feature.SettingData.VendorId = "{1FA41B39-B444-4E43-B35A-E1F7985FD548}"
$Feature.SettingData.VendorName = "NetworkController"
$Feature.SettingData.ProfileData = 1
6. Inicie a VM.
Você criou uma VM com êxito, conectou a VM a uma rede virtual de locatário e iniciou a VM para que ela possa
processar cargas de trabalho de locatário.
$vmnicproperties.DnsSettings = new-object
Microsoft.Windows.NetworkController.NetworkInterfaceDnsSettings
$vmnicproperties.DnsSettings.DnsServers = $logicalnet.Properties.Subnets[0].DNSServers
$vmnicproperties.IpConfigurations = @($ipconfiguration)
$vnic = New-NetworkControllerNetworkInterface –ResourceID "MyVM_Ethernet1" –Properties
$vmnicproperties –ConnectionUri $uri
$vnic.InstanceId
#The hardcoded Ids in this section are fixed values and must not change.
$FeatureId = "9940cd46-8b06-43bb-b9d5-93d50381fd56"
$Feature.SettingData.ProfileId = "{$InstanceId}"
$Feature.SettingData.NetCfgInstanceId = "{56785678-a0e5-4a26-bc9b-c0cba27311a3}"
$Feature.SettingData.CdnLabelString = "TestCdn"
$Feature.SettingData.CdnLabelId = 1111
$Feature.SettingData.ProfileName = "Testprofile"
$Feature.SettingData.VendorId = "{1FA41B39-B444-4E43-B35A-E1F7985FD548}"
$Feature.SettingData.VendorName = "NetworkController"
$Feature.SettingData.ProfileData = 1
5. Inicie a VM.
Get-VM -Name "MyVM" | Start-VM
Você criou uma VM com êxito, conectou a VM a uma VLAN e iniciou a VM para que ela possa processar cargas
de trabalho de locatário.
Configurar a QoS (qualidade de serviço) para um
adaptador de rede de VM
20/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Você pode configurar a qualidade de serviço (rede definida pelo software) (QoS) para um adaptador de rede de
máquina virtual (VM) para limitar a largura de banda em uma interface virtual a fim de impedir que uma VM de
tráfego intenso contenha outro tráfego de rede VM. Você também pode configurar o QoS de SDN para reservar
uma quantidade específica de largura de banda para uma VM a fim de garantir que a VM possa enviar tráfego
independentemente de outro tráfego na rede. Isso pode ser aplicado às VMs conectadas às redes de VLAN
tradicionais, bem como às VMs conectadas a redes de sobreposição de SDN.
Você também pode configurar o descarregamento de QoS para impor regras de QoS no adaptador de rede
física em vez de no comutador virtual, resultando em menor utilização da CPU e imposição aprimorada. o
descarregamento de QoS é um recurso opcional encontrado em NICs certificadas do Windows server 2022 que
alcançaram o Windows servidor Software-Defined data Center (SDDC) Premium qualificação adicional (AQ).
Para obter mais informações, consulte selecionar um adaptador de rede.
$vswitchConfig=[Microsoft.Windows.NetworkController.VirtualSwitchManagerProperties]::new()
$qos=[Microsoft.Windows.NetworkController.VirtualSwitchQosSettings]::new()
$qos.EnableSoftwareReservations=$true
$vswitchConfig.QosSettings =$qos
Set-NetworkControllerVirtualSwitchConfiguration -ConnectionUri $uri -Properties $vswitchConfig
Em seguida, configure a taxa de transferência máxima de entrada e de saída permitida na interface de rede:
$NwInterface.Properties.PortSettings.QosSettings=
[Microsoft.Windows.NetworkController.VirtualNetworkInterfaceQosSettings]::new()
$NwInterface.Properties.PortSettings.QosSettings.InboundMaximumMbps ="1000"
New-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId $NwInterface.ResourceId -Properties
$NwInterface.Properties
NOTE
Essa opção só está disponível para Azure Stack assinantes do HCI.
IMPORTANT
Você deve garantir que o QosOffload esteja habilitado em cada NIC física da equipe em todos os hosts. Sem isso, a
regra de QoS será imposta por meio do comutador virtual e resultará em menor eficiência.
Use os seguintes cmdlets para verificar se os adaptadores dão suporte QosOffload e, em seguida, modifique as
propriedades do adaptador:
Get-NetAdapterAdvancedProperty -Name <physical NIC Name> -RegistryKeyword *QosOffload
Enable QosOffload for your adapters:
Set-NetAdapterAdvancedProperty -Name <physical NIC Name> -RegistryKeyword *QosOffload -RegistryValue 1
$vswitchConfig=[Microsoft.Windows.NetworkController.VirtualSwitchManagerProperties]::new()
$qos=[Microsoft.Windows.NetworkController.VirtualSwitchQosSettings]::new()
$qos.EnableHardwareLimits=$true
$vswitchConfig.QosSettings =$qos
Set-NetworkControllerVirtualSwitchConfiguration -ConnectionUri $uri -Properties $vswitchConfig
Em seguida, configure a taxa de transferência máxima de saída permitida na interface de rede. O exemplo a
seguir cria uma regra de QoS limitando o tráfego de saída de uma interface de VM para 1 Gbps.
IMPORTANT
O descarregamento de QoS dá suporte apenas a OutboundMaximumMbps . Você não pode usar
OutboundReser vedValue ou InboundMaximumMbps com descarregamento de QoS.
$NwInterface.Properties.PortSettings.QosSettings=
[Microsoft.Windows.NetworkController.VirtualNetworkInterfaceQosSettings]::new()
$NwInterface.Properties.PortSettings.QosSettings. EnableHardwareLimits=$true
$NwInterface.Properties.PortSettings.QosSettings.OutboundMaximumMbps ="1000"
New-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId $NwInterface.ResourceId -Properties
$NwInterface.Properties
NOTE
Durante a migração ao vivo, é possível que uma VM passe para um host que não dá suporte ao descarregamento de
QoS. Nesse cenário, a migração ao vivo terá sucesso, mas a QoS fará fallback para o QoS de SDN.
Configurar o balanceador de carga de software
para balanceamento de carga e Conversão de
endereços de rede (NAT)
12/08/2021 • 7 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Você pode usar este tópico para aprender a usar o SLB do balanceador de carga de software de rede definido
pelo software ( Sdn ) ( ) para fornecer ( NAT ) de conversão de endereços de rede de saída, NAT de entrada ou
balanceamento de carga entre várias instâncias de um aplicativo.
import-module NetworkController
$URI = "https://sdn.contoso.com"
$LBResourceId = "LB2"
$VIPIP = "10.127.134.5"
$VIPLogicalNetwork = get-networkcontrollerlogicalnetwork -ConnectionUri $uri -resourceid "PublicVIP"
-PassInnerException
$FrontEndIPConfig = new-object
Microsoft.Windows.NetworkController.LoadBalancerFrontendIpConfiguration
$FrontEndIPConfig.ResourceId = "FE1"
$FrontEndIPConfig.ResourceRef =
"/loadBalancers/$LBResourceId/frontendIPConfigurations/$($FrontEndIPConfig.ResourceId)"
$FrontEndIPConfig.Properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerFrontendIpConfigurationProperties
$FrontEndIPConfig.Properties.Subnet = new-object Microsoft.Windows.NetworkController.Subnet
$FrontEndIPConfig.Properties.Subnet.ResourceRef =
$VIPLogicalNetwork.Properties.Subnets[0].ResourceRef
$FrontEndIPConfig.Properties.PrivateIPAddress = $VIPIP
$FrontEndIPConfig.Properties.PrivateIPAllocationMethod = "Static"
$LoadBalancerProperties.FrontEndIPConfigurations += $FrontEndIPConfig
3. Aloque um pool de endereços de back-end, que contém os DIPs (IPs dinâmicos) que compõem os
membros do conjunto de VMs com balanceamento de carga.
$BackEndAddressPool.Properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerBackendAddressPoolProperties
$LoadBalancerProperties.backendAddressPools += $BackEndAddressPool
4. Defina uma investigação de integridade que o balanceador de carga usa para determinar o estado de
integridade dos membros do pool de back-end.
Neste exemplo, você define uma investigação HTTP que consulta o RequestPath de "/health.htm". A
consulta é executada a cada 5 segundos, conforme especificado pela propriedade IntervalInSeconds.
A investigação de integridade deve receber um código de resposta HTTP 200 para 11 consultas
consecutivas para que a investigação considere o IP de back-end a ser íntegro. Se o IP de back-end não
estiver íntegro, ele não receberá o tráfego do balanceador de carga.
IMPORTANT
Não bloqueie o tráfego de ou para o primeiro IP na sub-rede para quaisquer ACLs (listas de controle de acesso)
que você aplicar ao IP de back-end porque esse é o ponto de origem para as investigações.
$LoadBalancerProperties.Probes += $Probe
5. Defina uma regra de balanceamento de carga para enviar o tráfego que chega ao IP de front-end para o
IP de back-end. Neste exemplo, o pool de back-end recebe o tráfego TCP para a porta 80.
Use o exemplo a seguir para definir uma regra de balanceamento de carga:
$LoadBalancerProperties.loadbalancingRules += $Rule
7. Siga o exemplo a seguir para adicionar as interfaces de rede a esse pool de back-ends.
$LBResourceId = "OutboundNATMMembers"
$VIPIP = "10.127.134.6"
$FrontEndIPConfig = new-object
Microsoft.Windows.NetworkController.LoadBalancerFrontendIpConfiguration
$FrontEndIPConfig.ResourceId = "FE1"
$FrontEndIPConfig.ResourceRef =
"/loadBalancers/$LBResourceId/frontendIPConfigurations/$($FrontEndIPConfig.ResourceId)"
$FrontEndIPConfig.Properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerFrontendIpConfigurationProperties
$FrontEndIPConfig.Properties.Subnet = new-object Microsoft.Windows.NetworkController.Subnet
$FrontEndIPConfig.Properties.Subnet.ResourceRef =
$VIPLogicalNetwork.Properties.Subnets[0].ResourceRef
$FrontEndIPConfig.Properties.PrivateIPAddress = $VIPIP
$FrontEndIPConfig.Properties.PrivateIPAllocationMethod = "Static"
$LoadBalancerProperties.FrontEndIPConfigurations += $FrontEndIPConfig
$LoadBalancerProperties.backendAddressPools += $BackEndAddressPool
$OutboundNAT.properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerOutboundNatRuleProperties
$OutboundNAT.properties.frontendipconfigurations += $FrontEndIPConfig
$OutboundNAT.properties.backendaddresspool = $BackEndAddressPool
$OutboundNAT.properties.protocol = "ALL"
$LoadBalancerProperties.OutboundNatRules += $OutboundNAT
4. Siga o exemplo a seguir para adicionar as interfaces de rede às quais você deseja fornecer acesso à
Internet.
$lbresourceid = "LB2"
$lb = get-networkcontrollerloadbalancer -connectionuri $uri -resourceID $LBResourceId -
PassInnerException
NOTE
Esse processo não exige que você crie um objeto de balanceador de carga. A atribuição do PublicIPAddress à interface de
rede é suficiente para que o software Load Balancer execute sua configuração.
Counters : {}
ConfigurationState :
IpAddress : 10.127.134.2
PublicIPAddressVersion : IPv4
PublicIPAllocationMethod : Dynamic
IdleTimeoutInMinutes : 4
DnsSettings :
ProvisioningState : Succeeded
IpConfiguration :
PreviousIpConfiguration :
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Neste tópico, você aprenderá a implantar dispositivos de rede virtual em redes virtuais de locatário. Você pode
adicionar soluções de virtualização de rede a redes que executam funções de espelhamento de porta e
roteamento definidas pelo usuário.
TIP
Se você quiser adicionar mais rotas, repita essa etapa para cada rota que você deseja definir.
Assim que você aplicar a tabela de roteamento à rede virtual, o tráfego será encaminhado para o dispositivo
virtual. Você deve configurar a tabela de roteamento no dispositivo virtual para encaminhar o tráfego de uma
maneira apropriada para o seu ambiente.
3. Crie um objeto iminsertproperties para conter as regras de espelhamento de porta e o elemento que
representa a interface de destino.
$portmirror = [Microsoft.Windows.NetworkController.ServiceInsertionProperties]::new()
$portMirror.Priority = 1
4. Crie um objeto serviceinsertionrules para conter as regras que devem ser correspondidas para que o
tráfego seja enviado para o dispositivo.
As regras definidas abaixo correspondem a todo o tráfego, tanto de entrada quanto de saída, que
representa um espelho tradicional. Você pode ajustar essas regras se estiver interessado em espelhar
uma porta específica ou origem/destinos específicos.
$portmirror.ServiceInsertionRules =
[Microsoft.Windows.NetworkController.ServiceInsertionRule[]]::new(1)
$portmirror.ServiceInsertionRules[0] =
[Microsoft.Windows.NetworkController.ServiceInsertionRule]::new()
$portmirror.ServiceInsertionRules[0].ResourceId = "Rule1"
$portmirror.ServiceInsertionRules[0].Properties =
[Microsoft.Windows.NetworkController.ServiceInsertionRuleProperties]::new()
$portmirror.ServiceInsertionElements[0] =
[Microsoft.Windows.NetworkController.ServiceInsertionElement]::new()
$portmirror.ServiceInsertionElements[0].ResourceId = "Element1"
$portmirror.ServiceInsertionElements[0].Properties =
[Microsoft.Windows.NetworkController.ServiceInsertionElementProperties]::new()
$srcNic.Properties.IpConfigurations[0].Properties.ServiceInsertion = $portMirror
$srcNic = New-NetworkControllerNetworkInterface -ConnectionUri $uri -Properties $srcNic.Properties -
ResourceId $srcNic.ResourceId
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
As máquinas virtuais conectadas a uma rede virtual só têm permissão para usar os endereços IP que o
Controlador de Rede atribuiu para se comunicar na rede. As tecnologias de clustering que exigem um endereço
IP flutuante, como o Clustering de Failover da Microsoft, exigem algumas etapas adicionais para funcionar
corretamente.
O método para tornar o IP flutuante acessível é usar um VIP de IP virtual Load Balancer ( ) ( ) SLB. O balanceador
de carga de software deve ser configurado com uma investigação de saúde em uma porta nesse IP para que o
SLB direciona o tráfego para o computador que atualmente tem esse IP.
$VIP = "192.168.2.100"
$subnet = "Subnet2"
$VirtualNetwork = "MyNetwork"
$ResourceId = "MyNetwork_InternalVIP"
5. Adicione uma investigação para detectar em qual nó de cluster o endereço flutuante está ativo no
momento.
NOTE
A consulta de investigação no endereço permanente da VM na porta definida abaixo. A porta só deve responder
no nó ativo.
$lbprobe.ResourceId = "Probe1"
$lbprobe.resourceRef = "/loadBalancers/$ResourceId/Probes/$($lbprobe.resourceId)"
$lbprobe.properties.protocol = "TCP"
$lbprobe.properties.port = "59999"
$lbprobe.properties.IntervalInSeconds = 5
$lbprobe.properties.NumberOfProbes = 11
$lbrule.properties.frontendipconfigurations += $FrontEnd
$lbrule.properties.backendaddresspool = $BackEnd
$lbrule.properties.protocol = "TCP"
$lbrule.properties.frontendPort = $lbrule.properties.backendPort = 1433
$lbrule.properties.IdleTimeoutInMinutes = 4
$lbrule.properties.EnableFloatingIP = $true
$lbrule.properties.Probe = $lbprobe
# Cluster Node 2
Depois de criar o balanceador de carga e adicionar as interfaces de rede ao pool de back-end, você estará
pronto para configurar o cluster.
9. (Opcional) Se você estiver usando um Cluster de Failover da Microsoft, continue com o próximo exemplo.
$ClusterName = "MyCluster"
Add-ClusterNode $nodes[1]
O cluster está ativo. O tráfego que vai para o VIP na porta especificada é direcionado para o nó ativo.
Atualizar, fazer backup e restaurar a infraestrutura
SDN
11/08/2021 • 8 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Neste tópico, você aprenderá a atualizar, fazer backup e restaurar uma infraestrutura de SDN.
IMPORTANT
se você usar System Center gerenciador Virtual, deverá atualizá-lo com os pacotes cumulativos de atualizações mais
recentes.
ao atualizar cada componente, você pode usar qualquer um dos métodos padrão para instalar Windows
atualizações. No entanto, para garantir o tempo de inatividade mínimo para cargas de trabalho e a integridade
do banco de dados do controlador de rede, siga estas etapas:
1. Atualize os consoles de gerenciamento.
Instale as atualizações em cada um dos computadores em que você usa o módulo do PowerShell do
controlador de rede. Incluindo em qualquer lugar que você tenha a função RSAT-NetworkController
instalada por si só. Excluindo as VMs do controlador de rede propriamente ditas; Você os atualiza na
próxima etapa.
2. Na primeira VM do controlador de rede, instale todas as atualizações e reinicie o.
3. Antes de prosseguir para a próxima VM do controlador de rede, use o get-networkcontrollernode cmdlet
para verificar o status do nó que você atualizou e reiniciou.
4. Durante o ciclo de reinicialização, aguarde até que o nó do controlador de rede fique inativo e volte
novamente.
Após a reinicialização da VM, pode levar vários minutos antes de retornar ao status de backup . Para
obter um exemplo da saída, consulte
5. Instale atualizações em cada VM MUX do SLB, uma de cada vez, para garantir a disponibilidade contínua
da infraestrutura do balanceador de carga.
6. Atualize os hosts e gateways RAS do Hyper-V, começando com os hosts que contêm os gateways RAS
que estão no modo de espera .
As VMs de gateway de RAS não podem ser migradas ao vivo sem perder as conexões de locatário.
Durante o ciclo de atualização, você deve ter cuidado para minimizar o número de vezes que o failover de
conexões de locatário para um novo gateway de RAS. Ao coordenar a atualização de hosts e gateways de
RAS, cada locatário falha ao longo de uma vez, no máximo.
a. Evacuar o host de VMs que são capazes de migração dinâmica.
As VMs de gateway de RAS devem permanecer no host.
b. Instale atualizações em cada VM de gateway neste host.
c. Se a atualização exigir que a VM de gateway seja reinicializada, reinicialize a VM.
d. Instale atualizações no host que contém a VM de gateway que acabou de ser atualizada.
e. Reinicialize o host se exigido pelas atualizações.
f. Repita para cada host adicional que contém um gateway em espera.
Se nenhum gateway em espera permanecer, siga estas mesmas etapas para todos os hosts restantes.
Exemplo: Use o cmdlet Get-networkcontrollernode
Neste exemplo, você vê a saída para a get-networkcontrollernode execução do cmdlet de dentro de uma das
VMs do controlador de rede.
O status dos nós que você vê na saída de exemplo é:
NCNode1.contoso.com = down
NCNode2.contoso.com = up
NCNode3.contoso.com = up
IMPORTANT
Você deve aguardar vários minutos até que o status do nó seja alterado para ativo antes de atualizar qualquer nó
adicional, um de cada vez.
Depois de atualizar todos os nós do controlador de rede, o controlador de rede atualiza os microserviços em
execução no cluster do controlador de rede dentro de uma hora.
TIP
Você pode disparar uma atualização imediata usando o update-networkcontroller cmdlet.
PS C:\> get-networkcontrollernode
Name : NCNode1.contoso.com
Server : NCNode1.Contoso.com
FaultDomain : fd:/NCNode1.Contoso.com
RestInterface : Ethernet
NodeCertificate :
Status : Down
Name : NCNode2.Contoso.com
Server : NCNode2.contoso.com
FaultDomain : fd:/ NCNode2.Contoso.com
RestInterface : Ethernet
NodeCertificate :
Status : Up
Name : NCNode3.Contoso.com
Server : NCNode3.Contoso.com
FaultDomain : fd:/ NCNode3.Contoso.com
RestInterface : Ethernet
NodeCertificate :
Status : Up
IMPORTANT
Execute este cmdlet quando não houver mais atualizações a serem instaladas.
PS C:\> update-networkcontroller
NetworkControllerClusterVersion NetworkControllerVersion
------------------------------- ------------------------
10.1.1 10.1.15
IMPORTANT
Não reinicie o serviço do SCVMM até que o backup do controlador de rede seja concluído.
$URI = "https://NC.contoso.com"
$Credential = Get-Credential
$ShareUserResourceId = "BackupUser"
# Create backup
],
"ProvisioningState": "Succeeded",
"Credential": {
"Tags": null,
"ResourceRef": "/credentials/BackupUser",
"InstanceId": "00000000-0000-0000-0000-000000000000",
"Etag": null,
"ResourceMetadata": null,
"ResourceId": null,
"Properties": null
}
}
}
IMPORTANT
As etapas variam dependendo do número de componentes restaurados.
stop-service slbhostagent
stop-service nchostagent
4. Interrompa as VMs do gateway de RAS.
5. Interrompa as VMs MUX SLB.
6. Restaure o controlador de rede com o new-networkcontrollerrestore cmdlet.
7. Verifique o ProvisioningState de restauração para saber quando a restauração foi concluída com êxito.
8. Se estiver usando o SCVMM, restaure o banco de dados do SCVMM usando o backup que foi criado ao
mesmo tempo que o backup do controlador de rede.
9. Se você quiser restaurar VMs de carga de trabalho do backup, faça isso agora.
10. Verifique a integridade do sistema com o cmdlet Debug-networkcontrollerconfigurationstate.
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController "https://NC.contoso.com" -Credential $cred
$URI = "https://NC.contoso.com"
$Credential = Get-Credential
$ShareUserResourceId = "BackupUser"
$ShareCredential = Get-NetworkControllerCredential -ConnectionURI $URI -Credential $Credential | Where
{$_.ResourceId -eq $ShareUserResourceId }
para obter informações sobre as mensagens de estado de configuração que podem aparecer, consulte
solucionar problemas da pilha de rede definida pelo Software Windows Server 2016.
Segurança para SDN
11/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Você pode usar os tópicos nesta seção para saber mais sobre segurança no SDN de Rede Definida pelo Software
().
NOTE
Para obter documentação adicional de Rede Definida pelo Software, você pode usar as seguintes seções de biblioteca:
Tecnologias SDN
Planejar SDN
Implantar SDN
Gerenciar SDN
Solucionar problemas de SDN
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Neste tópico, você aprenderá a configurar a segurança para toda a comunicação entre o controlador de rede e
outros softwares e dispositivos.
Os caminhos de comunicação que você pode proteger incluem a comunicação Northbound no plano de
gerenciamento, a comunicação de cluster entre ( VMs ) de máquinas virtuais de controlador de rede em um
cluster e a comunicação Southbound no plano de dados.
1. Comunicação Nor thbound . o controlador de rede se comunica no plano de gerenciamento com -
software de gerenciamento compatível com SDN, como Windows PowerShell e System Center Virtual
Machine Manager ( SCVMM ) . Essas ferramentas de gerenciamento fornecem a capacidade de definir a
diretiva de rede e criar um estado de meta para a rede, no qual você pode comparar a configuração de
rede real para colocar a configuração real em paridade com o estado da meta.
2. Comunicação de cluster do controlador de rede . Quando você configura três ou mais VMs como
nós de cluster do controlador de rede, esses nós se comunicam entre si. Essa comunicação pode estar
relacionada à sincronização e à replicação de dados entre nós ou comunicação específica entre os
serviços do controlador de rede.
3. Comunicação Southbound . O controlador de rede se comunica no plano de dados com a
infraestrutura de SDN e outros dispositivos, como balanceadores de carga de software, gateways e
máquinas de host. Você pode usar o controlador de rede para configurar e gerenciar esses dispositivos
Southbound para que eles mantenham o estado da meta que você configurou para a rede.
Comunicação Northbound
O controlador de rede dá suporte à autenticação, autorização e criptografia para comunicação northbound. As
seções a seguir fornecem informações sobre como definir essas configurações de segurança.
Autenticação
Ao configurar a autenticação para a comunicação Northbound do controlador de rede, você permite que nós de
cluster do controlador de rede e clientes de gerenciamento verifiquem a identidade do dispositivo com o qual
estão se comunicando.
O controlador de rede dá suporte aos três modos de autenticação a seguir entre os clientes de gerenciamento e
os nós do controlador de rede.
NOTE
se você estiver implantando o controlador de rede com o System Center Virtual Machine Manager, somente o modo
Kerberos terá suporte.
1. Kerberos . Use a autenticação Kerberos ao unir o cliente de gerenciamento e todos os nós de cluster do
controlador de rede a um domínio Active Directory. O domínio de Active Directory deve ter contas de
domínio usadas para autenticação.
2. X509 . Use o X509 para - autenticação baseada em certificado para clientes de gerenciamento que não
ingressaram em um domínio Active Directory. Você deve registrar certificados para todos os nós de
cluster do controlador de rede e clientes de gerenciamento. Além disso, todos os nós e clientes de
gerenciamento devem confiar nos certificados dos outros.
3. None . Use nenhum para fins de teste em um ambiente de teste e, portanto, não é recomendado para uso
em um ambiente de produção. Quando você escolhe esse modo, não há nenhuma autenticação
executada entre nós e clientes de gerenciamento.
você pode configurar o modo de autenticação para comunicação Northbound usando o comando Windows
PowerShell Install-NetworkController com o parâmetro clientauthentication válido .
Autorização
Ao configurar a autorização para a comunicação Northbound do controlador de rede, você permite que nós de
cluster do controlador de rede e clientes de gerenciamento verifiquem se o dispositivo com o qual estão se
comunicando é confiável e tem permissão para participar da comunicação.
Use os métodos de autorização a seguir para cada um dos modos de autenticação com suporte do controlador
de rede.
1. Kerberos . Ao usar o método de autenticação Kerberos, você define os usuários e computadores
autorizados a se comunicar com o controlador de rede criando um grupo de segurança no Active
Directory e, em seguida, adicionando os usuários e computadores autorizados ao grupo. você pode
configurar o controlador de rede para usar o grupo de segurança para autorização usando o parâmetro
ClientSecurityGroup do comando Install-NetworkController Windows PowerShell. Depois de instalar
o controlador de rede, você pode alterar o grupo de segurança usando o comando set-
NetworkController com o parâmetro -ClientSecurityGroup. Se estiver usando o SCVMM, você deverá
fornecer o grupo de segurança como um parâmetro durante a implantação.
2. X509 . Quando você estiver usando o método de autenticação X509, o controlador de rede só aceita
solicitações de clientes de gerenciamento cujas impressões digitais de certificado são conhecidas pelo
controlador de rede. você pode configurar essas impressões digitais usando o parâmetro
ClientCertificateThumbprint do comando Install-NetworkController Windows PowerShell. Você pode
adicionar outras impressões digitais do cliente a qualquer momento usando o comando set-
NetworkController .
3. None . Quando você escolhe esse modo, não há nenhuma autenticação executada entre nós e clientes de
gerenciamento. Use nenhum para fins de teste em um ambiente de teste e, portanto, não é recomendado
para uso em um ambiente de produção.
Criptografia
A comunicação Northbound usa protocolo SSL ( SSL ) para criar um canal criptografado entre os clientes de
gerenciamento e os nós do controlador de rede. A criptografia SSL para comunicação Northbound inclui os
seguintes requisitos:
Todos os nós do controlador de rede devem ter um certificado idêntico que inclua a autenticação do
servidor e as finalidades de autenticação do cliente nas extensões EKU do uso avançado de chave ( ) .
O URI usado pelos clientes de gerenciamento para se comunicar com o controlador de rede deve ser o
nome da entidade do certificado. O nome da entidade do certificado deve conter o nome de domínio
totalmente qualificado (FQDN) ou o endereço IP do ponto de extremidade REST do controlador de rede.
se os nós do controlador de rede estiverem em sub-redes diferentes, o nome da entidade de seus
certificados deverá ser o mesmo que o valor usado para o parâmetro rest no comando Install-
NetworkController Windows PowerShell.
Todos os clientes de gerenciamento devem confiar no certificado SSL.
Registro e configuração de certificado SSL
Você deve registrar manualmente o certificado SSL em nós do controlador de rede.
depois que o certificado for registrado, você poderá configurar o controlador de rede para usar o certificado
com o parâmetro -Ser verCer tificate do comando Install-NetworkController Windows PowerShell. Se você
já tiver instalado o controlador de rede, poderá atualizar a configuração a qualquer momento usando o
comando set-NetworkController .
NOTE
Se você estiver usando o SCVMM, deverá adicionar o certificado como um recurso de biblioteca. Para obter mais
informações, consulte configurar um controlador de rede Sdn na malha do VMM.
NOTE
Se você implantar o controlador de rede usando o SCVMM, somente o modo Kerberos terá suporte.
1. Kerberos . Você pode usar a autenticação Kerberos quando todos os nós de cluster do controlador de
rede são ingressados em um domínio Active Directory, com contas de domínio usadas para autenticação.
2. X509 . O X509 é uma - autenticação baseada em certificado. Você pode usar a autenticação X509 quando
os nós de cluster do controlador de rede não tiverem ingressado em um domínio Active Directory. Para
usar o X509, você deve registrar certificados em todos os nós de cluster do controlador de rede e todos
os nós devem confiar nos certificados. Além disso, o nome da entidade do certificado registrado em cada
nó deve ser o mesmo que o nome DNS do nó.
3. None . Quando você escolhe esse modo, não há nenhuma autenticação executada entre nós do
controlador de rede. Esse modo é fornecido apenas para fins de teste e não é recomendado para uso em
um ambiente de produção.
Autorização
Ao configurar a autorização para comunicação de cluster do controlador de rede, você permite que os nós de
cluster do controlador de rede verifiquem se os nós com os quais estão se comunicando são confiáveis e têm
permissão para participar da comunicação.
Para cada um dos modos de autenticação com suporte do controlador de rede, os métodos de autorização a
seguir são usados.
1. Kerberos . Os nós do controlador de rede aceitam solicitações de comunicação somente de outras contas
de computador do controlador de rede. você pode configurar essas contas ao implantar o controlador de
rede usando o parâmetro Name do comando New-NetworkControllerNodeObject Windows PowerShell.
2. X509 . Os nós do controlador de rede aceitam solicitações de comunicação somente de outras contas de
computador do controlador de rede. você pode configurar essas contas ao implantar o controlador de
rede usando o parâmetro Name do comando New-NetworkControllerNodeObject Windows PowerShell.
3. None . Quando você escolhe esse modo, não há nenhuma autorização executada entre nós do
controlador de rede. Esse modo é fornecido apenas para fins de teste e não é recomendado para uso em
um ambiente de produção.
Criptografia
A comunicação entre nós do controlador de rede é criptografada usando a criptografia do nível de transporte
do WCF. Essa forma de criptografia é usada quando os métodos de autenticação e autorização são certificados
Kerberos ou X509. Para obter mais informações, consulte estes tópicos.
Como: proteger um serviço com credenciais do Windows
Como: proteger um serviço com certificados X. 509.
Comunicação Southbound
O Controlador de Rede interage com diferentes tipos de dispositivos para comunicação de southbound. Essas
interações usam protocolos diferentes. Por isso, há requisitos diferentes para autenticação, autorização e
criptografia, dependendo do tipo de dispositivo e protocolo usado pelo Controlador de Rede para se comunicar
com o dispositivo.
A tabela a seguir fornece informações sobre a interação do Controlador de Rede com diferentes dispositivos de
southbound.
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Você pode usar este tópico para aprender a gerenciar certificados para comunicações de Northbound e
Southbound do Controlador de Rede ao implantar o SDN de Rede Definida pelo Software no datacenter do (
Windows Server 2019 ou 2016 e estiver usando o SCVMM do System Center Virtual Machine Manager como
seu ) cliente de gerenciamento do ( ) SDN.
NOTE
Para obter informações de visão geral sobre o Controlador de Rede, consulte Controlador de rede.
Se você não estiver usando o Kerberos para proteger a comunicação do Controlador de Rede, poderá usar
certificados X.509 para autenticação, autorização e criptografia.
O SDN no Windows Server 2019 e 2016 Datacenter dá suporte a - ( certificados X.509 autoatendados e
assinados pela AC da Autoridade de ) Certificação. Este tópico fornece instruções passo a passo para criar esses
certificados e aplicação deles para proteger os canais de comunicação de Northbound do Controlador de Rede
com clientes de gerenciamento e comunicações de southbound com dispositivos de rede, como o Software
Load Balancer ( ) SLB. . Ao usar a autenticação baseada em certificado, você deve registrar um certificado em
nós do Controlador de Rede que - é usado das seguintes maneiras.
1. Criptografando a comunicação de northbound com protocolo SSL SSL entre nós do Controlador de Rede e
clientes de gerenciamento, como ( ) System Center Virtual Machine Manager.
2. Autenticação entre nós do Controlador de Rede e dispositivos e serviços de southbound, como hosts Hyper-
V e SLBs de Balanceadores de Carga ( de Software ) .
NOTE
Ao usar o SCVMM para implantar o Controlador de Rede, você deve especificar o certificado X.509 usado para
criptografar as comunicações de northbound durante a configuração do Modelo de Serviço do Controlador de Rede.
Exemplo de uso
Nó único
Você pode usar o comando New-SelfSignedCertificate Windows PowerShell criar um certificado - autoatendido.
Sintaxe
Exemplo de uso
NOTE
Você pode usar CAs ou ferramentas de terceiros, como openssl, para criar um certificado para uso com o Controlador de
Rede, no entanto, as instruções neste tópico são específicas para AD CS. Para saber como usar uma AC ou ferramenta de
terceiros, confira a documentação do software que você está usando.
NOTE
Se o personal My – cert:\localmachine\my certificate store no host Hyper V tiver mais de um certificado X.509 com CN
(Nome da Assunto) como o FQDN do nome de domínio totalmente qualificado do host, verifique se o certificado que será
usado pelo SDN tem uma propriedade adicional personalizada uso de chave aprimorada com o ( ) - ( ) OID
1.3.6.1.4.1.311.95.1.1.1. Caso contrário, a comunicação entre o controlador de rede e o host pode não funcionar.
NOTE
Antes de executar este procedimento, você deve revisar os requisitos de certificado e os modelos de certificado
disponíveis no console modelos de certificado. Você pode modificar um modelo existente ou criar uma duplicata de um
modelo existente e, em seguida, modificar sua cópia do modelo. É recomendável criar uma cópia de um modelo existente.
"resourceId": "host31.fabrikam.com",
"properties": {
"connections": [
{
"managementAddresses": [
"host31.fabrikam.com"
],
"credential": {
"resourceRef": "/credentials/a738762f-f727-43b5-9c50-cf82a70221fa"
},
"credentialType": "X509Certificate"
}
],
Para autenticação mútua, o host Hyper-V também deve ter um certificado para se comunicar com o Controlador
de Rede.
Você pode registrar o certificado de uma AC de Autoridade de ( Certificação ) . Se um certificado baseado em
AC não for encontrado no computador host, o SCVMM criará um certificado auto-assinado e o provisiona no
computador host.
O Controlador de Rede e os certificados de host hyper-V devem ser confiáveis entre si. O certificado raiz do
certificado do host Hyper-V deve estar presente no armazenamento autoridades de certificação raiz confiáveis
do controlador de rede para o computador local e vice-versa.
Quando você está usando certificados auto assinados, o SCVMM garante que os certificados necessários estão
presentes no armazenamento autoridades de certificação raiz confiáveis para - o computador local.
Se você estiver usando certificados baseados em AC para os hosts Hyper-V, precisará garantir que o certificado
raiz da AC está presente no armazenamento autoridades de certificação raiz confiáveis do controlador de rede
para o computador local.
Comunicação de Load Balancer MUX com o controlador de rede
O software Load Balancer Multiplexor MUX e o Controlador de Rede se comunicam por meio do ( ) protocolo
WCF, usando certificados para autenticação.
Por padrão, o SCVMM escolhe o certificado SSL configurado no Controlador de Rede e o usa para comunicação
de southbound com os dispositivos Mux. Esse certificado é configurado no recurso REST
"NetworkControllerLoadBalancerMux" e pode ser exibido executando o cmdlet do PowerShell Get-
NetworkControllerLoadBalancerMux.
Exemplo de recurso REST de MUX ( ) parcial:
"resourceId": "slbmux1.fabrikam.com",
"properties": {
"connections": [
{
"managementAddresses": [
"slbmux1.fabrikam.com"
],
"credential": {
"resourceRef": "/credentials/a738762f-f727-43b5-9c50-cf82a70221fa"
},
"credentialType": "X509Certificate"
}
],
Para autenticação mútua, você também deve ter um certificado nos dispositivos SLB MUX. Esse certificado é
configurado automaticamente pelo SCVMM quando você implanta o balanceador de carga de software usando
o SCVMM.
IMPORTANT
Nos nós de host e SLB, é essencial que o armazenamento de certificados autoridades de certificação confiáveis não inclua
nenhum certificado em que "Emitido para" não seja o mesmo que "Emitido por". Se isso ocorrer, a comunicação entre o
Controlador de Rede e o dispositivo de southbound falhará.
O Controlador de Rede e os certificados SLB MUX devem ser confiáveis entre si. O certificado raiz do certificado
SLB MUX deve estar presente no armazenamento de Autoridades de Certificação Raiz Confiáveis do
computador controlador de rede e ( vice-versa. ) Quando você está usando certificados auto assinados, o
SCVMM garante que os certificados necessários estão presentes no no armazenamento autoridades de
certificação raiz confiáveis para o - computador local.
Kerberos com o nome da entidade de serviço (SPN)
13/08/2021 • 3 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019
O Controlador de Rede dá suporte a vários métodos de autenticação para comunicação com clientes de
gerenciamento. Você pode usar a autenticação baseada em Kerberos, autenticação baseada em certificado X509.
Você também tem a opção de não usar nenhuma autenticação para implantações de teste.
System Center Virtual Machine Manager usa a autenticação baseada em Kerberos. Se você estiver usando a
autenticação baseada em Kerberos, deverá configurar um SPN (Nome da Entidade de Serviço) para o
Controlador de Rede no Active Directory. O SPN é um identificador exclusivo para a instância de serviço do
Controlador de Rede, que é usado pela autenticação Kerberos para associar uma instância de serviço a uma
conta de logon de serviço. Para obter mais detalhes, consulte Nomes de entidade de serviço.
TIP
Normalmente, você pode configurar o Controlador de Rede para usar um endereço IP ou um nome DNS para operações
baseadas em REST. No entanto, ao configurar o Kerberos, você não pode usar um endereço IP para consultas REST no
Controlador de Rede. Por exemplo, você pode usar <https://networkcontroller.consotso.com> , mas não pode usar
<https://192.34.21.3> . Os Nomes de Entidade de Serviço não poderão funcionar se os endereços IP são usados.
Se você estivesse usando o endereço IP para operações REST junto com a autenticação Kerberos no Windows Server
2016, a comunicação real teria sido por meio da autenticação NTLM. Nessa implantação, depois de atualizar para o
Windows Server 2019, você continuará a usar a autenticação baseada em NTLM. Para mover para a autenticação baseada
em Kerberos, você deve usar o nome DNS do Controlador de Rede para operações REST e fornecer permissão para que os
nós do Controlador de Rede registrem o SPN.
Emparelhamento de rede virtual
13/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
O emparelhamento de rede virtual permite que você conecte duas redes virtuais diretamente. Uma vez
emparelhadas, para fins de conectividade, as redes virtuais aparecem como uma.
Os benefícios do uso do emparelhamento de rede virtual incluem:
O tráfego entre as máquinas virtuais nas redes virtuais emparelhadas é roteado por meio da
infraestrutura de backbone somente por meio de endereços IP privados . A comunicação entre as redes
virtuais não requer Internet ou gateways públicos.
Baixa latência, conexão com largura de banda alta entre os recursos em redes virtuais diferentes.
A capacidade de recursos em uma rede virtual para se comunicar com recursos em uma rede virtual
diferente.
Nenhum tempo de inatividade para recursos em nenhuma rede virtual ao criar o emparelhamento.
Requisitos e restrições
O emparelhamento de rede virtual tem alguns requisitos e restrições:
As redes virtuais emparelhadas devem:
Ter espaços de endereço IP não sobrepostos
Ser gerenciado pelo mesmo controlador de rede
Depois de emparelhar uma rede virtual com outra rede virtual, você não poderá adicionar ou excluir
intervalos de endereços no espaço de endereço.
TIP
Se você precisar adicionar intervalos de endereços:
1. Remova o emparelhamento.
2. Adicione o espaço de endereço.
3. Adicione o emparelhamento novamente.
Como o emparelhamento de rede virtual está entre duas redes virtuais, não há nenhuma relação
transitiva derivada entre emparelhamentos. Por exemplo, se você emparelhar virtualNetworkA com
virtualNetworkB e virtualNetworkB com virtualNetworkC, o virtualNetworkA não será emparelhado com
virtualNetworkC.
Conectividade
Depois de emparelhar as redes virtuais, os recursos em qualquer rede virtual podem se conectar diretamente
com os recursos na rede virtual emparelhada.
A latência de rede entre as máquinas virtuais nas redes virtuais emparelhadas é igual à latência em uma
única rede virtual.
A taxa de transferência de rede é baseada na largura de banda permitida para a máquina virtual. Não
existe restrição adicional quanto à largura de banda no emparelhamento.
O tráfego entre máquinas virtuais em redes virtuais emparelhadas é roteado diretamente por meio da
infraestrutura de backbone, não por meio de um gateway ou pela Internet pública.
As máquinas virtuais em uma rede virtual podem acessar o balanceador de carga interno na rede virtual
emparelhada.
Você pode aplicar listas de controle de acesso (ACLs) em qualquer rede virtual para bloquear o acesso a outras
redes virtuais ou sub-redes, se desejado. Se você abrir a conectividade completa entre redes virtuais
emparelhadas (que é a opção padrão), poderá aplicar ACLs a sub-redes ou máquinas virtuais específicas para
bloquear ou negar acesso específico. Para saber mais sobre ACLs, confira usar ACLs (listas de controle de
acesso) para gerenciar o tráfego de rede do datacenter Flow.
Encadeamento de serviços
Você pode configurar rotas definidas pelo usuário que apontem para máquinas virtuais em redes virtuais
emparelhadas como o endereço IP do próximo salto, para habilitar o encadeamento de serviços. O
encadeamento de serviços permite direcionar o tráfego de uma rede virtual para uma solução de virtualização,
em uma rede virtual emparelhada, por meio de rotas definidas pelo usuário.
Você pode implantar redes Hub e spoke, em que a rede virtual do Hub pode hospedar componentes de
infraestrutura, como uma solução de virtualização de rede. Todas as redes virtuais spoke emparelhadas com a
rede virtual do Hub. O tráfego pode fluir por meio de dispositivos de rede virtual na rede virtual do Hub.
O emparelhamento de rede virtual permite que o próximo salto em uma rota definida pelo usuário seja o
endereço IP de uma máquina virtual na rede virtual emparelhada. Para saber mais sobre as rotas definidas pelo
usuário, confira usar dispositivos de rede virtual em uma rede virtual.
Monitoramento
Ao emparelhar duas redes virtuais, você deve configurar um emparelhamento para cada rede virtual no
emparelhamento.
Você pode monitorar o status da conexão de emparelhamento, que pode estar em um dos seguintes Estados:
Iniciado em: Mostrado quando você cria o emparelhamento da primeira rede virtual para a segunda
rede virtual.
Conectado: Mostrado depois de criar o emparelhamento da segunda rede virtual para a primeira rede
virtual. O estado de emparelhamento da primeira rede virtual muda de Iniciado para Conectado. Ambos
os pares de rede virtual devem ter o estado conectado antes de estabelecer um emparelhamento de rede
virtual com êxito.
Desconectado: Mostrado se uma rede virtual se desconectar de outra rede virtual.
[infográfico dos Estados]
Próximas etapas
configurar o emparelhamento de rede virtual: neste procedimento, você usa Windows PowerShell para localizar
a rede lógica do provedor HNV para criar duas redes virtuais, cada uma com uma sub-rede. Você também
configura o emparelhamento entre as duas redes virtuais.
Configure emparelhamento de rede virtual
12/08/2021 • 3 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
neste procedimento, você usa Windows PowerShell para criar duas redes virtuais, cada uma com uma sub-rede.
Em seguida, você configura o emparelhamento entre as duas redes virtuais para habilitar a conectividade entre
elas.
Etapa 1. Criar a primeira rede virtual
Etapa 2. Criar a segunda rede virtual
Etapa 3. Configurar o emparelhamento da primeira rede virtual para a segunda rede virtual
Etapa 4. Configurar o emparelhamento da segunda rede virtual para a primeira rede virtual
IMPORTANT
Lembre-se de atualizar as propriedades do seu ambiente.
#Indicates whether the peer virtual network can access this virtual networks gateway
$peeringProperties.allowGatewayTransit = $false
#Indicates whether this virtual network uses peer virtual networks gateway
$peeringProperties.useRemoteGateways =$false
IMPORTANT
Depois de criar esse emparelhamento, o status da vnet mostrará iniciado .
# Indicates whether the peer virtual network can access this virtual network's gateway
$peeringProperties.allowGatewayTransit = $false
# Indicates whether this virtual network will use peer virtual network's gateway
$peeringProperties.useRemoteGateways =$false
Depois de criar esse emparelhamento, o status de emparelhamento vnet mostra conectado para ambos os
pares. Agora, as máquinas virtuais em uma rede virtual podem se comunicar com máquinas virtuais na rede
virtual emparelhada.
Windows Desempenho do gateway do servidor
2019
13/08/2021 • 3 minutes to read
aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019
em Windows Server 2016, uma das preocupações dos clientes foi a incapacidade do gateway de SDN de
atender aos requisitos de taxa de transferência das redes modernas. A taxa de transferência de rede de túneis
IPsec e GRE teve limitações com a taxa de transferência de conexão única para a conectividade IPsec de cerca de
300 Mbps e para a conectividade do GRE sendo cerca de 2,5 Gbps.
melhoramos significativamente no Windows Server 2019, com os números de soaring a 1,8 gbps e 15 gbps
para conexões IPsec e GRE, respectivamente. Tudo isso, com reduções significativas nos ciclos de CPU/por byte,
fornecendo, assim, uma taxa de transferência de alto desempenho com muito menos utilização da CPU.
TIP
Para obter os melhores resultados de desempenho, verifique se cipherTransformationConstant e
authenticationTransformConstant nas configurações do modo rápido da conexão IPsec usam o GCMAES256 Cipher
Suite.
Para obter o máximo de desempenho, o hardware do host do gateway deve dar suporte a conjuntos de instruções de
CPU AES-NI e PCLMULQDQ. Eles estão disponíveis em qualquer Westmere (32nm) e na CPU da Intel posterior, exceto
nos modelos em que o AES-NI foi desabilitado. Você pode examinar a documentação do fornecedor de hardware para ver
se a CPU dá suporte a conjuntos de instruções de CPU AES-NI e PCLMULQDQ.
Abaixo está um exemplo REST de conexão IPsec com algoritmos de segurança ideais:
# 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 Microsoft.Windows.NetworkController.NetworkConnectionProperties
$nwConnectionProperties.IpSecConfiguration.QuickMode = New-Object
Microsoft.Windows.NetworkController.QuickMode
$nwConnectionProperties.IpSecConfiguration.QuickMode.PerfectForwardSecrecy = "PFS2048"
$nwConnectionProperties.IpSecConfiguration.QuickMode.AuthenticationTransformationConstant = "GCMAES256"
$nwConnectionProperties.IpSecConfiguration.QuickMode.CipherTransformationConstant = "GCMAES256"
$nwConnectionProperties.IpSecConfiguration.QuickMode.SALifeTimeSeconds = 3600
$nwConnectionProperties.IpSecConfiguration.QuickMode.IdleDisconnectSeconds = 500
$nwConnectionProperties.IpSecConfiguration.QuickMode.SALifeTimeKiloBytes = 2000
$nwConnectionProperties.IpSecConfiguration.MainMode = New-Object
Microsoft.Windows.NetworkController.MainMode
$nwConnectionProperties.IpSecConfiguration.MainMode.DiffieHellmanGroup = "Group2"
$nwConnectionProperties.IpSecConfiguration.MainMode.IntegrityAlgorithm = "SHA256"
$nwConnectionProperties.IpSecConfiguration.MainMode.EncryptionAlgorithm = "AES256"
$nwConnectionProperties.IpSecConfiguration.MainMode.SALifeTimeSeconds = 28800
$nwConnectionProperties.IpSecConfiguration.MainMode.SALifeTimeKiloBytes = 2000
# Update the IPv4 Routes that are reachable over the site-to-site VPN Tunnel
$nwConnectionProperties.Routes = @()
$ipv4Route = New-Object Microsoft.Windows.NetworkController.RouteInfo
$ipv4Route.DestinationPrefix = "<<On premise subnet that must be reachable over the VPN tunnel. Ex:
10.0.0.0/24>>"
$ipv4Route.metric = 10
$nwConnectionProperties.Routes += $ipv4Route
# 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
“https://<REST URI>”
New-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId
$virtualGW.ResourceId -ResourceId "Contoso_IPSecGW" -Properties $nwConnectionProperties -Force
Testando resultados
Fizemos testes de desempenho extensivos para os gateways de SDN em nossos laboratórios de teste. nos
testes, comparamos o desempenho de rede do gateway com o Windows Server 2019 em cenários de sdn e
cenários que não são SDN. Você pode encontrar os resultados e os detalhes de configuração de teste
capturados no artigo do blog aqui.
Alocação de largura de banda de gateway
12/08/2021 • 4 minutes to read
aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019
no Windows Server 2016, a largura de banda de túnel individual para IPsec, GRE e L3 era uma proporção da
capacidade total do gateway. Portanto, os clientes forneceriam a capacidade do gateway com base na largura de
banda TCP padrão, esperando isso fora da VM do gateway.
Além disso, a largura de banda máxima do túnel IPsec no gateway era limitada à * capacidade do gateway
(3/20) fornecida pelo cliente. Portanto, por exemplo, se você definir a capacidade do gateway como 100 Mbps, a
capacidade do túnel IPsec será de 150 Mbps. As taxas equivalentes para túneis GRE e L3 são 1/5 e 1/2,
respectivamente.
Embora isso tenha trabalhado para a maioria das implantações, o modelo de taxa fixa não era apropriado para
ambientes de alta taxa de transferência. Mesmo quando as taxas de transferência de dados eram altas (digamos,
mais de 40 Gbps), a taxa de transferência máxima de túneis de gateway de SDN é limitada devido a fatores
internos.
no Windows Server 2019, para um tipo de túnel, a taxa de transferência máxima é fixa:
IPsec = 5 Gbps
GRE = 15 Gbps
L3 = 5 Gbps
Portanto, mesmo que o host/VM do gateway dê suporte a NICs com uma taxa de transferência muito maior, a
taxa de transferência máxima do túnel disponível será corrigida. Outro problema que isso cuida é que o excesso
de provisionamento de gateways é arbitrariamente, o que acontece ao fornecer um número muito alto para a
capacidade do gateway.
NOTE
é possível que, após a atualização para o Windows Server 2019, um gateway se torne excessivamente provisionado (já
que a lógica de alocação muda de Windows Server 2016 para Windows Server 2019). Nesse caso, as conexões existentes
no gateway continuam a existir. O recurso REST para o gateway gera um aviso de que o gateway está excessivamente
provisionado. Nesse caso, você deve mover algumas conexões para outro gateway.
Solucionar problemas de SDN
12/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Os tópicos nesta seção fornecem informações sobre como solucionar problemas das tecnologias de SDN (Rede
Definida pelo Software) incluídas no Azure Stack HCI, no Windows Server 2019 e no Windows Server 2016.
NOTE
Para obter documentação adicional de Rede Definida pelo Software, você pode usar as seções de biblioteca a seguir.
Tecnologias SDN
Planejar SDN
Implantar SDN
Gerenciar SDN
Segurança para SDN
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Este guia examina os cenários comuns de falha e erros de SDN (Rede Definida pelo Software) e descreve um
fluxo de trabalho de solução de problemas que usa as ferramentas de diagnóstico disponíveis.
Para obter mais informações sobre o SDN, consulte Rede definida pelo software.
Tipos de erro
A lista a seguir representa a classe de problemas mais frequentemente vistos com a Virtualização de Rede
Hyper-V (HNVv1) no Windows Server 2012 R2 de implantações de produção no mercado e coincide de várias
maneiras com os mesmos tipos de problemas vistos no Windows Server 2016 HNVv2 com a nova pilha de
SDN (Rede Definida pelo Software).
A maioria dos erros pode ser classificada em um pequeno conjunto de classes:
Configuração inválida ou sem supor te Um usuário invoca a API NorthBound incorretamente ou
com uma política inválida.
Erro no aplicativo de política A política do Controlador de Rede não foi entregue a um Host Hyper-V,
atrasada ou não atualizada em todos os hosts Hyper-V (por exemplo, após um Migração ao Vivo).
Desa drift de configuração ou bug de software Problemas de caminho de dados resultando em
pacotes descartados.
Erro externo relacionado ao hardware/drivers NIC ou à malha de rede de subposição
Descarregamento de tarefa de comportamento indefatório (como VMQ) ou malha de rede de subposição
configurada inde forma (como MTU)
Este guia de solução de problemas examina cada uma dessas categorias de erro e recomenda as
melhores práticas e ferramentas de diagnóstico disponíveis para identificar e corrigir o erro.
Ferramentas de diagnóstico
Antes de discutir os fluxos de trabalho de solução de problemas para cada um desses tipos de erros, vamos
examinar as ferramentas de diagnóstico disponíveis.
Para usar as ferramentas de diagnóstico do Controlador de Rede (caminho de controle), você deve primeiro
instalar o recurso RSAT-NetworkController e importar o NetworkControllerDiagnostics módulo:
Para usar as ferramentas de diagnóstico de Diagnóstico HNV (caminho de dados), você deve importar o
HNVDiagnostics módulo:
# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics
NOTE
O valor do parâmetro NetworkController deve ser o FQDN ou o endereço IP com base no nome da assunto do
certificado X.509 >criado para o Controlador de Rede.
O parâmetro Credential só precisará ser especificado se o controlador de rede estiver usando a autenticação Kerberos
(típica em implantações do VMM). A credencial deve ser para um usuário que está no Grupo de Segurança de
Gerenciamento do Controlador de Rede.
Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]
Source: SoftwareLoadBalancerManager
Code: HostNotConnectedToController
Message: Host is not Connected.
----------------------------------------------------------------------------------------------------------
NOTE
Há um bug no sistema em que os recursos de Interface de Rede para a NIC de VM de Trânsito do SLB Mux estão em um
estado de falha com o erro "Comutdor Virtual – Host Não Conectado ao Controlador". Esse erro poderá ser ignorado
com segurança se a configuração de IP no recurso NIC da VM estiver definida como um Endereço IP do Pool de IP da
Rede Lógica de Trânsito. Há um segundo bug no sistema em que os recursos de Interface de Rede para as NICs de VM do
Provedor de HNV do Gateway estão em um estado de falha com o erro "Comu switch virtual – PortBlocked". Esse erro
também poderá ser ignorado com segurança se a configuração de IP no recurso NIC da VM estiver definida como nula
(por design).
A tabela a seguir mostra a lista de códigos de erro, mensagens e ações de acompanhamento a tomar com base
no estado de configuração observado.
PolicyConfigurationFailure Falha ao efetuar o emissão de políticas Nenhuma ação definida. Isso ocorre
para os hosts, devido a falhas de devido à falha no processamento do
comunicação ou outros erros no estado de meta nos módulos do
NetworkController. Controlador de Rede. Coletar logs.
HostNotConnectedToController O host ainda não está conectado ao O Perfil de Porta não é aplicado no
Controlador de Rede host ou o host não está acessível pelo
Controlador de Rede. Validar se a
chave do Registro HostID corresponde
à ID da Instância do recurso do
servidor
MultipleVfpEnabledSwitches Há vários Comutadores habilitados Exclua uma das opções, pois o Agente
para VFp no host de Host do Controlador de Rede dá
suporte apenas a um vSwitch com a
extensão VFP habilitada
HostUnreachable O MUX não está 100%(o caso comum O par BGP no comutador RRAS
é O BGPRouter desconectado) (máquina virtual BGP) ou ToR (topo do
rack) está inacessível ou não é possível
fazer o peer com êxito. Verifique as
configurações de BGP no recurso Load
Balancer multiplexador de software e
no par BGP (máquina virtual ToR ou
RRAS)
HostNotConnectedToController O agente host SLB não está conectado Verifique se o serviço agente de host
SLB está em execução; Consulte logs
do agente host SLB (execução
automática) por motivos, caso o NC
(SLBM) tenha rejeitado o certificado
apresentado pelo estado de execução
do agente host mostrará informações
nuances
PortBlocked A porta VFP está bloqueada devido à Verifique se há outros erros, o que
falta de políticas de VNET/ACL pode fazer com que as políticas não
sejam configuradas.
Verificar a conectividade de rede entre o controlador de rede e o Host Hyper-V (serviço agente host NC)
Execute o comando netstat abaixo para validar se há três conexões ESTABLISHED entre o Agente de Host NC e
os nós do Controlador de Rede e um soquete LISTENING no Host Hyper-V
ESCUTAndo na porta TCP:6640 no Host Hyper-V (Serviço de Agente de Host NC)
Duas conexões estabelecidas do IP do host Hyper-V na porta 6640 para o IP do nó NC em portas efêmeras
(> 32000)
Uma conexão estabelecida do IP do host Hyper-V na porta efêmera para o IP REST do controlador de rede na
porta 6640
NOTE
Pode haver apenas duas conexões estabelecidas em um host Hyper-V se não houver máquinas virtuais de locatário
implantadas nesse host específico.
# Successful output
TCP 0.0.0.0:6640 0.0.0.0:0 LISTENING
TCP 10.127.132.153:6640 10.127.132.213:50095 ESTABLISHED
TCP 10.127.132.153:6640 10.127.132.214:62514 ESTABLISHED
TCP 10.127.132.153:50023 10.127.132.211:6640 ESTABLISHED
Get-Service SlbHostAgent
Get-Service NcHostAgent
# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module
replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>
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
ReplicaRole : Primary
NodeName : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready
HostId : **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 : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties : Microsoft.Windows.NetworkController.ServerProperties
Correção Se estiver usando scripts SDNExpress ou implantação manual, atualize a chave HostId no Registro
para corresponder à ID da Instância do recurso do servidor. Reinicie o Agente de Host do Controlador de Rede
no host Hyper-V (servidor físico) Se estiver usando o VMM, exclua o Servidor Hyper-V do VMM e remova a
chave do Registro HostId. Em seguida, adicione o servidor por meio do VMM.
Verifique se as impressões digitais dos certificados X.509 usados pelo host Hyper-V (o nome do host será o
Nome da Assunto do certificado) para a comunicação (SouthBound) entre os nós host Hyper-V (serviço agente
host NC) e controlador de rede. Verifique também se o certificado REST do Controlador de Rede tem o nome da
assunto CN= .
# On Hyper-V Host
dir cert:\\localmachine\my
Thumbprint Subject
---------- -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9 CN=SA18n30-4.sa18.nttest.microsoft.com
...
dir cert:\\localmachine\root
Thumbprint Subject
---------- -------
30674C020268AA4E40FD6817BA6966531FB9ADA4 CN=10.127.132.211 **# NC REST IP ADDRESS**
Thumbprint Subject
---------- -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9 CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4 CN=10.127.132.211 **# NC REST IP ADDRESS**
...
Você também pode verificar os seguintes parâmetros de cada certificado para verificar se o nome da entidade é
o esperado (hostname ou FQDN REST nc ou IP), o certificado ainda não expirou e se todas as autoridades de
certificação na cadeia de certificados estão incluídas na autoridade raiz confiável.
Nome do assunto
Data de Validade
Confiável por autoridade raiz
Correção Se vários certificados têm o mesmo nome de assunto no host Hyper-V, o Agente de Host do
Controlador de Rede escolherá aleatoriamente um para apresentar ao Controlador de Rede. Isso pode não
corresponder à impressão digital do recurso de servidor conhecido pelo Controlador de Rede. Nesse caso,
exclua um dos certificados com o mesmo nome de assunto no host Hyper-V e reinicie o serviço Agente de Host
do Controlador de Rede. Se uma conexão ainda não puder ser feita, exclua o outro certificado com o mesmo
nome de assunto no Host Hyper-V e exclua o recurso de servidor correspondente no VMM. Em seguida, recrie o
recurso de servidor no VMM, que gerará um novo certificado X.509 e o instalará no host Hyper-V.
Verificar o estado de configuração do SLB
O Estado de Configuração do SLB pode ser determinado como parte da saída para o cmdlet Debug-
NetworkController. Esse cmdlet também apresentará o conjunto atual de recursos do Controlador de Rede em
arquivos JSON, todas as configurações de IP de cada host hyper-V (servidor) e política de rede local das tabelas
de banco de dados do Agente host.
Mais rastreamentos serão coletados por padrão. Para não coletar rastreamentos, adicione o parâmetro -
IncludeTraces:$false.
NOTE
O estado SLB pode ser verificado diretamente usando o script DumpSlbRestState disponível no repositório de GitHub
microsoft SDN.
Validação de gateway
Do Controlador de Rede:
Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface
Da VM do Gateway:
Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation
Além disso, dos problemas que vimos até agora (especialmente em implantações baseadas em SDNExpress), o
motivo mais comum para o Compartimento de Locatário não ser configurado em VMs GW parece ser o fato de
que a Capacidade gw no FabricConfig.psd1 é menor em comparação com o que as pessoas tentam atribuir às
Conexões de Rede (Túneis S2S) no TenantConfig.psd1. Isso pode ser verificado facilmente comparando as saídas
dos seguintes comandos:
PS > Get-ProviderAddress
# Sample Output
ProviderAddress : 10.10.182.66
MAC Address : 40-1D-D8-B7-1C-04
Subnet Mask : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN : VLAN11
ProviderAddress : 10.10.182.67
MAC Address : 40-1D-D8-B7-1C-05
Subnet Mask : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN : VLAN11
Esses endereços IP do provedor de HNV (PA IPs) são atribuídos a adaptadores de Ethernet criados em um
compartimento de rede TCPIP separado e têm um nome de adaptador de VLANX em que X é a VLAN atribuída
à rede lógica do provedor de HNV (transporte).
A conectividade entre dois hosts Hyper-V usando a rede lógica do provedor HNV pode ser feita por um ping
com um parâmetro de compartimento adicional (-c Y) em que Y é o compartimento de rede TCPIP no qual o
PAhostVNICs é criado. Esse compartimento pode ser determinado executando:
C:\> ipconfig /allcompartments /all
<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...
NOTE
Os adaptadores de host vNIC do PA não são usados no caminho de dados e, portanto, não têm um IP atribuído ao
adaptador "vEthernet (PAhostVNic)".
Por exemplo, suponha que os hosts Hyper-V 1 e 2 tenham endereços IP de provedor de HNV (PA) de:
Podemos executar ping entre os dois usando o comando a seguir para verificar a conectividade de rede lógica
do provedor 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 10.10.182.66 -S 10.10.182.64
# 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 10.10.182.67 -S 10.10.182.64
# 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 10.10.182.66 -S 10.10.182.65
# 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 10.10.182.67 -S 10.10.182.65
Correção Se o ping do provedor HNV não funcionar, verifique a conectividade da rede física, incluindo a
configuração de VLAN. As NICs físicas em cada host Hyper-V devem estar no modo de tronco sem uma VLAN
específica atribuída. O host de gerenciamento vNIC deve ser isolado para a VLAN da rede lógica de
gerenciamento.
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>
# 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> ...
Verificar o MTU e o suporte a quadros Jumbo na rede lógica do provedor de HNV
Outro problema comum na rede lógica do provedor de HNV é que as portas de rede física e/ou a placa Ethernet
não têm uma MTU grande o suficiente configurada para lidar com a sobrecarga do encapsulamento VXLAN (ou
NVGRE).
NOTE
Alguns drivers e placas Ethernet dão suporte à nova palavra-chave * EncapOverhead, que será automaticamente definida
pelo agente de host do controlador de rede para um valor de 160. Esse valor será então adicionado ao valor da palavra-
chave * JumboPacket cujo somatório é usado como a MTU anunciada. por exemplo, * EncapOverhead = 160 e *
JumboPacket = 1514 => MTU = 1674B
# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings
Para testar se a rede lógica do provedor de HNV dá suporte ao tamanho de MTU maior de ponta a ponta, use o
cmdlet Test-LogicalNetworkSupportsJumboPacket :
# 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: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 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.
Remediação
Ajuste o tamanho de MTU nas portas do comutador físico para que seja pelo menos 1674B (incluindo o
cabeçalho e o trailer de Ethernet 14B)
Se a placa NIC não oferecer suporte à palavra-chave EncapOverhead, ajuste a palavra-chave JumboPacket
para ter pelo menos 1674B
Verificar conectividade NIC de VM de locatário
Cada NIC de VM atribuída a uma VM convidada tem um mapeamento de CA-PA entre o endereço do cliente
privado (CA) e o espaço de endereço do provedor HNV (PA). Esses mapeamentos são mantidos nas tabelas do
servidor OVSDB em cada host do Hyper-V e podem ser encontrados executando o cmdlet a seguir.
# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping
NOTE
Se os mapeamentos de CA-PA esperados não forem impressos para uma determinada VM de locatário, verifique os
recursos de configuração de IP e NIC de VM no controlador de rede usando o cmdlet Get-
NetworkControllerNetworkInterface . Além disso, verifique as conexões estabelecidas entre o agente do host NC e os nós
do controlador de rede.
Com essas informações, um ping de VM de locatário agora pode ser iniciado pelo hoster do controlador de rede
usando o cmdlet Test-VirtualNetworkConnection .
NOTE
O VSID refere-se à ID de sub-rede virtual. No caso de VXLAN, esse é o VNI (identificador de rede VXLAN). Você pode
encontrar esse valor executando o cmdlet Get-PACAMapping .
Exemplo
Criar CA-ping entre "VM verde da Web 1" com SenderCA IP de 192.168.1.4 no host "sa18n30-
2.sa18.nttest.microsoft.com" com IP de gerenciamento de 10.127.132.153 para ListenerCA IP de 192.168.1.5
ambos anexados à sub-rede virtual (VSID) 4114.
Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp
10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP
192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1
CA Routing Information:
PA Routing Information:
<snip> ...
1. Vários Verifique se não há políticas de firewall distribuídas especificadas na sub-rede virtual ou nas interfaces
de rede de VM que bloquearam o tráfego.
Consulte a API REST do controlador de rede encontrada no ambiente de demonstração em sa18n30nc no
domínio sa18.nttest.microsoft.com.
$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
System Center inclui as seguintes tecnologias para uso com a SDN (Rede Definida pelo Software):
System Center Operations Manager
System Center Virtual Machine Manager
Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016
Microsoft Azure é a plataforma de nuvem da Microsoft: uma coleção crescente de serviços integrados –
computação, armazenamento, dados, rede e aplicativo – que ajudam você a se mover mais rapidamente, fazer
mais e economizar dinheiro.
A abordagem da Microsoft à SDN (Rede Definida pelo Software) inclui projetar, criar e operar redes de
datacenter de escala global para serviços como Microsoft Azure. Microsoft Azure datacenters globais executam
dezenas de milhares de alterações de rede todos os dias, o que é possível apenas devido ao SDN.
O Microsoft Azure é executado na mesma plataforma do Windows Server e do Hyper-V que está incluída no
Windows Server. Windows O servidor e System Center incluem melhorias e práticas recomendadas com base
na experiência da Microsoft em operar redes de datacenter de escala global como Microsoft Azure para que
você possa implantar as mesmas tecnologias para flexibilidade, automação e controle ao usar tecnologias SDN.
Para obter mais informações, consulte O que é Microsoft Azure?.
Entrar em contato com a equipe de rede na nuvem
e Datacenter
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
As soluções ( SDN ) de Rede Definida pelo Software e Rede de Contêiner da Microsoft são criadas pela Equipe
de Rede de Nuvem e Datacenter. Use esta página para entrar em contato com a equipe – para fazer perguntas,
fornecer comentários, relatar bugs ou fazer solicitações de recursos.
Há muitas vias para entrar em contato com as equipes da Microsoft e, embora façamos nosso melhor na equipe
do SDN para seguir todas as vias usadas por nossa comunidade, aqui está uma lista de fóruns que tendem a ser
os mais ativos. Esses são os principais recursos para nossos usuários e, como tal, eles são as vias que
observamos mais próximos.
Twitter
Recentemente, lançamos nossa presença no Twitter como @Microsoft_SDN . Sinta-se à vontade para usar nosso
alça do Twitter para fazer perguntas, fornecer comentários ou fazer solicitações de recurso/documentação.
Além de um local em que você possa entrar em contato com perguntas/comentários/solicitações, considere
o Twitter o local para obter seu "feed" em tudo o que o SDN e a rede de contêineres do Windows
relacionados – o Twitter é o primeiro lugar em que postaremos notícias, anunciaremos novos recursos e
apontaremos a comunidade para todos os nossos blogs e recursos mais recentes.
GitHub é o melhor lugar para entrar em contato conosco sobre tópicos que envolvem mais detalhes do que
os tipos de coisas que você pode ajustar facilmente em um Tweet. Precisa de ajuda com a implantação do
SDN? Não tem certeza de como nossos recursos podem atender às necessidades exclusivas da sua
organização? Está sendo mantido por um possível bug? Todos os bons motivos para entrar em contato
conosco enviando um GitHub problema.
Microsoft Docs
Nossa documentação de Rede de Contêineres pode ser encontrada Microsoft Docs (docs.microsoft.com), que
tem a funcionalidade de comentário. Para sair ou responder a um comentário Microsoft Docs basta entrar, role
para baixo até a parte inferior da página Microsoft Docs que você deseja referenciar e, em seguida, faça e envie
seu comentário para lá.
Microsoft Docs é o novo site de documentação unificada da Microsoft. Embora a maioria da documentação
do SDN da nossa equipe permaneça no TechNet, nossa documentação de Rede de Contêineres agora está
Microsoft Docs.
Em geral, se você tiver um tópico no Microsoft Docs que a spark uma pergunta ou deixar você desejar mais,
basta deixar um comentário nessa página para compartilhar seus comentários com a equipe da Microsoft
que pode ajudar.
Container-Specific fóruns
Sinta-se à vontade para usar qualquer caminho nesta página para fornecer comentários relacionados a
contêineres e rede de contêineres. No entanto, se você estiver procurando os fóruns principais da Microsoft
para a comunidade de contêineres especificamente, consulte o seguinte:
Voz do usuário – melhor para solicitações de recursos
Github (repo de virtualização) – melhor para buscar a solução de problemas de ajuda e relatar bugs
Não está vendo o fórum para você?
Sempre que possível, incentivamos o uso de nossos fóruns públicos para que a comunidade mais ampla possa
se beneficiar do acesso às perguntas e comentários que vêm em nosso caminho. No entanto, também
reconhecemos que há situações em que o email é simplesmente a maneira preferencial de entrar em contato
conosco. Se você estiver em uma dessas situações, envie um email para e teremos o prazer de
[email protected] saber de você.
VPN (rede virtual privada)
11/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016 e Windows 10
NOTE
Você também pode implantar o gateway RAS como um servidor VPN multilocatário para uso com o SDN (rede definida
pelo software) ou como um servidor DirectAccess. Para obter mais informações, consulte Gateway de Ras, rede definida
por software (SDN)e DirectAccess.
Tópicos relacionados
Always on recursos e funcionalidades de VPN: neste tópico, você aprende sobre os recursos e a
funcionalidade de Always on VPN.
configurar túneis de dispositivo vpn no Windows 10: Always On VPN oferece a capacidade de criar um
perfil VPN dedicado para o dispositivo ou computador. Always On conexões VPN incluem dois tipos de
túneis: túnel de dispositivo e túnel de usuário. O túnel de dispositivo é usado para cenários de
conectividade pré-login e para fins de gerenciamento de dispositivos. O túnel do usuário permite que os
usuários acessem recursos da organização por meio de servidores VPN.
Always On implantação de VPN para Windows Server 2016 e Windows 10: fornece instruções sobre
como implantar o acesso remoto como um Gateway de RAS vpn de locatário único para conexões vpn
ponto a site que permitem que seus funcionários remotos se conectem à rede da sua organização com
conexões vpn Always On. É recomendável revisar os guias de design e implantação para cada uma das
tecnologias usadas nesta implantação.
guia técnico de VPN Windows 10: orienta você pelas decisões que você fará para Windows 10 clientes
em sua solução de VPN corporativa e como configurar sua implantação. você pode encontrar referências
ao provedor de serviços de configuração do VPNv2 (CSP) e fornece instruções de configuração de MDM
(gerenciamento de dispositivo móvel) usando Microsoft Intune e o modelo de perfil VPN para Windows
10.
Como criar perfis VPN no Configuration Manager: neste tópico, você aprende a criar perfis vpn no
Configuration Manager.
configurar Windows 10 cliente Always On conexões VPN: este tópico descreve as opções e o esquema do
ProfileXML e como criar a VPN ProfileXML. depois de configurar a infraestrutura do servidor, você deve
configurar o Windows 10 computadores cliente para se comunicar com essa infraestrutura com uma
conexão VPN.
opções de perfil vpn: este tópico descreve as configurações de perfil vpn no Windows 10 e saiba como
configurar perfis vpn usando o Intune ou o Configuration Manager. você pode definir todas as
configurações de VPN no Windows 10 usando o nó ProfileXML no CSP VPNv2.
Serviço de Cadastramento na Internet do Windows
(WINS)
13/08/2021 • 2 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
O serviço WINS é um serviço herdado de registro e resolução de nomes de computadores que mapeia nomes
NetBIOS de computadores para endereços IP.
Se você ainda não tiver o WINS implantado em sua rede, não implante o WINS-em vez disso, implante o DNS
do sistema de nome de domínio ( ) . O DNS também fornece serviços de registro e resolução de nome de
computador e inclui muitos benefícios adicionais sobre o WINS, como a integração com o Active Directory
Domain Services.
Para obter mais informações, consulte DNS (sistema de nomes de domínio)
Se você já tiver implantado o WINS em sua rede, é recomendável implantar o DNS e, em seguida, encerrar o
WINS.
Serviço de Horário do Windows (W32Time)
11/08/2021 • 3 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012
R2, Windows Server 2012 e Windows 10 ou posterior
Um segundo bissexto é um ajuste ocasional de 1 segundo para UTC. À medida que a rotação da Terra
desacelera, o UTC (escala de tempo atômica) diverge da hora solar ou do tempo astronômico. Depois que o UTC
tiver divergido em pelo menos 0,9 segundos, um segundo bissexto será inserido para manter o UTC em
sincronia com o tempo solar médio.
Os segundos intercalares se tornaram importantes para atender aos requisitos regulatórios de precisão e
rastreabilidade nos Estados Unidos e na União Europeia.
Para obter mais informações, consulte:
Nosso blog de comunicado
Guia de Validação para Desenvolvedores
Guia de Validação para Profissionais de TI
Um novo provedor de horário incluído no Windows Server 2019 e no Windows 10 (versão 1809) permite que
você sincronize a hora usando o protocolo PTP. Conforme o tempo é distribuído em uma rede, ocorre atraso
(latência) que, se não for contabilizado ou não for simétrico, dificultará cada vez mais o entendimento do
carimbo de data/hora enviado do servidor de horário. O PTP permite que os dispositivos de rede adicionem a
latência introduzida por cada dispositivo de rede nas medições de tempo, fornecendo, assim, um tempo bem
mais preciso ao cliente Windows.
Para obter mais informações, consulte:
Nosso blog de comunicado
Guia de Validação para Profissionais de TI
Ao receber um pacote de tempo pela rede de um servidor de horário, ele deve ser processado pela pilha de rede
do sistema operacional antes de ser consumido no serviço de horário. Cada componente na pilha de rede
introduz uma quantidade variável de latência que afeta a precisão da medição de tempo.
Para resolver esse problema, o carimbo de data/hora do software nos permite carimbar pacotes com data/hora
antes e depois dos "Componentes de Rede do Windows" mostrados acima para considerar o atraso no sistema
operacional.
Para obter mais informações, consulte:
Nosso blog de comunicado
Guias de validação para desenvolvedores e profissionais de TI
Hora precisa no Windows Server 2016
13/08/2021 • 6 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012
R2, Windows Server 2012 e Windows 10 ou posterior
O Serviço de Horário do Windows é um componente que usa um modelo de plug-in para provedores de
sincronização de hora do cliente e do servidor. Há dois provedores de cliente internos no Windows e há plug-ins
de terceiros disponíveis. Um provedor usa o NTP (RFC 1305) ou o MS-NTP para sincronizar a hora do sistema
local com um servidor de referência em conformidade com o NTP e/ou o MS-NTP. O outro provedor destina-se
ao Hyper-V e sincroniza as VMs (máquinas virtuais) com o host do Hyper-V. Quando houver vários provedores,
o Windows escolherá o melhor provedor usando o nível de camada primeiro, seguido pelo atraso de raiz,
dispersão de raiz e, por fim, a diferença de horário.
NOTE
Para obter uma visão geral rápida do Serviço de Horário do Windows, assista a este vídeo de visão geral de alto nível.
Neste tópico, abordaremos... estes tópicos conforme estão relacionados com a habilitação da hora precisa:
Aprimoramentos
Medidas
Práticas recomendadas
IMPORTANT
Um adendo referenciado pelo artigo Hora precisa do Windows 2016 pode ser baixado aqui. Esse documento fornece mais
detalhes sobre nossas metodologias de teste e medição.
NOTE
O modelo de plug-in do provedor de horário do Windows está documentado no TechNet.
Hierarquia de domínio
As configurações autônomas e de domínio funcionam de maneira diferente.
Os membros do domínio usam um protocolo NTP seguro, que usa a autenticação para garantir a
segurança e a autenticidade da referência de tempo. Os membros do domínio são sincronizados com um
relógio mestre determinado pela hierarquia de domínio e um sistema de pontuação. Em um domínio, há
uma camada hierárquica de camadas de tempo, na qual cada controlador de domínio aponta para um
controlador de domínio pai com uma camada de tempo mais precisa. A hierarquia é resolvida como o
controlador de domínio primário ou um controlador de domínio na floresta raiz ou um controlador de
domínio com o sinalizador de domínio do GTIMESERV, o que indica um Servidor de Horário Certo para o
domínio. Confira a seção [Especificar um serviço de hora confiável local usando o GTIMESERV] abaixo.
Os computadores autônomos são configurados para usar o time.windows.com por padrão. Esse nome é
resolvido pelo servidor DNS, que deverá apontar para um recurso pertencente à Microsoft. Como todas
as referências de tempo localizadas remotamente, as interrupções de rede podem impedir a
sincronização. As cargas de tráfego de rede e os caminhos de rede assimétrica poderão reduzir a precisão
da sincronização de hora. Para uma precisão de 1 ms, você não pode depender de fontes de horário
remotas.
Como os convidados do Hyper-V terão, pelo menos, dois provedores de tempo do Windows à escolha, a hora
do host e o NTP, você poderá ver comportamentos diferentes com Domínio ou Autônomo na execução como
convidado.
NOTE
Para obter mais informações sobre a hierarquia de domínio e o sistema de pontuação, confira "O que é o Serviço de
Tempo do Windows?" .
NOTE
A camada é um conceito usado nos provedores NTP e Hyper-V; o valor delas indica a localização dos relógios na
hierarquia. A camada 1 é reservada para o relógio de nível mais alto e a camada 0 é reservada para o hardware
considerado preciso e que tenha pouco ou nenhum atraso associado a ele. A camada 2 se comunica com os servidores da
camada 1, a camada 3 com a camada 2 e assim por diante. Embora uma camada mais baixa geralmente indique um
relógio mais preciso, é possível encontrar discrepâncias. Além disso, o W32Time aceita apenas a hora da camada 15 ou
abaixo. Para ver a camada de um cliente, use w32tm /query /status.
Referências adicionais
Aprimoramentos de precisão de tempo para o Windows Server 2016
Limite de suporte para a hora de alta precisão
13/08/2021 • 4 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016 e Windows 10 versão
1607 ou posterior
Este artigo descreve os limites de suporte para o Serviço de Horário do Windows (W32Time) em ambientes que
exigem que a hora do sistema seja altamente precisa e estável.
IMPORTANT
Fontes de tempo altamente precisas
A precisão de tempo resultante em sua topologia é altamente dependente do uso de uma fonte de horário precisa e de
raiz estável (estrato 1). Há hardware de fonte de horário NTP altamente preciso baseado em Windows, não baseado em
Windows e compatível com o Windows vendido por fornecedores terceiros. Entre em contato com seu fornecedor com
relação à precisão dos produtos dele.
IMPORTANT
Precisão do tempo
A precisão do tempo envolve a distribuição de ponta a ponta de tempo preciso de uma fonte de horário autoritativo
altamente preciso para o dispositivo final. Qualquer coisa que introduz a assimetria de rede influenciará negativamente a
precisão, por exemplo, dispositivos de rede física ou alta carga de CPU no sistema de destino.
NOTE
Execute "w32tm /query /status" na linha de comando para ver o estrato.
O sistema de destino deve estar dentro de 6 ou menos saltos de rede da fonte de horário altamente
precisa
A utilização média de CPU de um dia em todos os estratos não deve exceder 90%
Para sistemas virtualizados, a utilização média de um dia da CPU do host não deve exceder 90%
Precisão de destino: 1 milissegundo
Todos os requisitos descritos nas seções Precisão de destino: 1 segundo e Precisão de destino: 50
milissegundos se aplicam, exceto em situações em que controles mais estritos forem descritos nesta seção.
Os requisitos adicionais para obter precisão de 1 ms para um sistema de destino específico são:
O computador de destino deve ter latência de rede melhor que 0,1 ms entre a fonte de horário
O sistema de destino não deve ser maior do que o estrato 5 com base em uma fonte de horário
altamente precisa
NOTE
Execute 'w32tm /query /status' na linha de comando para ver o estrato
O sistema de destino deve estar dentro de 4 ou menos saltos de rede da fonte de horário altamente
precisa
A utilização média de CPU de um dia em cada estrato não deve exceder 80%
Para sistemas virtualizados, a utilização média de um dia da CPU do host não deve exceder 80%
Configurar sistemas para oferecer alta precisão
13/08/2021 • 5 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016 e Windows 10 versão
1607 ou posterior
WARNING
Metas de precisão anteriores dos sistemas operacionais
O Windows Server 2012 R2 e versões inferiores não podem atender aos mesmos objetivos de alta precisão. Esses
sistemas operacionais não têm suporte para alta precisão.
Nessas versões, o Serviço de Horário do Windows atendeu aos seguintes requisitos:
Forneceu a precisão de tempo necessária para atender aos requisitos de autenticação do Kerberos versão 5.
Forneceu um tempo menos preciso para clientes e servidores Windows ingressados em uma floresta do Active
Directory comum.
Tolerâncias maiores no 2012 R2 e abaixo estão fora da especificação de design do Serviço de Horário do Windows.
Configuração do sistema
Atingir destinos de alta precisão requer a configuração do sistema. Há várias maneiras de executar essa
configuração, incluindo diretamente no Registro ou por meio da política de grupo. Mais informações para cada
uma dessas configurações podem ser encontradas na Referência Técnica do Serviço de Hora do Windows –
Ferramentas do Serviço de Hora do Windows.
Tipo de Inicialização do Serviço de Horário do Windows
O Serviço de Horário do Windows (W32Time) deve ser executado continuamente. Para fazer isso, configure o
tipo de inicialização do Serviço de Horário do Windows como início “Automático”.
Configurações do Registro
MinPollInterval
Configura o menor intervalo em log2 segundos permitido para sondagem do sistema.
DESC RIÇ Ã O VA LO R
Configuração 6
MaxPollInterval
Configura o maior intervalo em log2 segundos permitido para sondagem do sistema.
DESC RIÇ Ã O VA LO R
Configuração 6
DESC RIÇ Ã O VA LO R
UpdateInterval
O número de tiques de relógio entre os ajustes de correção de fase.
DESC RIÇ Ã O VA LO R
Configuração 100
SpecialPollInterval
Configura o intervalo de sondagem em segundos quando o sinalizador SpecialInterval 0x1 está habilitado.
DESC RIÇ Ã O VA LO R
Configuração 64
FrequencyCorrectRate
DESC RIÇ Ã O VA LO R
Configuração 2
Horário do Windows para rastreabilidade
10/08/2021 • 6 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016 versão 1709 ou posterior
e Windows 10 versão 1703 ou posterior
As regulamentações em muitos setores exigem que os sistemas sejam rastreáveis para o UTC. Isso significa que
a diferença de um sistema pode ser atestada com respeito ao UTC. Para habilitar cenários de conformidade
regulatória, o Windows 10 (versão 1703 ou posterior) e o Windows Server 2016 (versão 1709 ou posterior)
fornecem novos logs de eventos para oferecer uma visão da perspectiva do Sistema Operacional a fim de criar
uma compreensão das ações executadas no relógio do sistema. Esses logs de evento são gerados
continuamente para o Serviço de Horário do Windows e podem ser examinados ou arquivados para análise
posterior.
Esses novos eventos permitem que as seguintes perguntas sejam respondidas:
O relógio do sistema foi alterado
A frequência do relógio foi modificada
A configuração do Serviço de Horário do Windows foi modificada
Disponibilidade
Esses aprimoramentos estão incluídos no Windows 10 versão 1703 ou posterior e no Windows Server 2016
versão 1709 ou posterior.
Configuração
Nenhuma configuração é necessária para usar este recurso. Esses logs de eventos são habilitados por padrão e
podem ser encontrados no visualizador de eventos no canal Applications and Ser vices
Log\Microsoft\Windows\Time-Ser vice\Operational .
Esse evento é registrado em log quando o Serviço de Horário do Windows (W32Time) é iniciado e registra
informações em log sobre a hora atual, a contagem atual de tiques, a configuração do runtime, os provedores
de horário e a taxa atual do relógio.
DESC RIÇ Ã O DO EVEN TO IN ÍC IO DO SERVIÇ O
Exemplo:
W32time service has started at 2018-02-27T04:25:17.156Z (UTC), System Tick Count 3132937.
Comando:
Essas informações também podem ser consultadas usando os comandos a seguir
Configuração do W32Time e do Provedor de Tempo
Taxa do relógio
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012
R2, Windows Server 2012 e Windows 10 ou posterior
O serviço W32Time fornece sincronização de relógio de rede para computadores sem a necessidade de
configuração extensiva. O serviço W32Time é essencial para a operação bem-sucedida da autenticação do
Kerberos V5 e, portanto, para a autenticação baseada em AD DS. Qualquer aplicativo com reconhecimento de
Kerberos, incluindo a maioria dos serviços de segurança, depende da sincronização de tempo entre os
computadores que participam da solicitação de autenticação. Os controladores de domínio do AD DS também
devem ter relógios sincronizados para ajudar a garantir uma replicação de dados precisa.
NOTE
No Windows Server 2003 e no Microsoft Windows 2000 Server, o serviço de diretório é denominado serviço de diretório
Active Directory. No Windows Server 2008 R2 e no Windows Server 2008, o serviço de diretório é denominado AD DS
(Active Directory Domain Services). O restante deste tópico se refere ao AD DS, mas as informações também se aplicam
ao Active Directory Domain Services no Windows Server 2016.
O serviço W32Time é implementado em uma biblioteca de vínculo dinâmico chamada W32Time.dll, instalada
por padrão no %Systemroot%\System32 . O W32Time.dll foi originalmente desenvolvido para o Windows
2000 Server dar suporte a uma especificação pelo protocolo de autenticação Kerberos V5 que exigia que os
relógios estivessem em uma rede para serem sincronizados. Do Windows Server 2003 em diante, o
W32Time.dll fornecia maior precisão na sincronização do relógio de rede no sistema operacional Windows
Server 2000. Além disso, no Windows Server 2003, o W32Time.dll dava suporte a uma variedade de
dispositivos de hardware e protocolos de horário de rede usando provedores de horário.
Embora originalmente criado para fornecer sincronização de relógio para a autenticação do Kerberos, muitos
aplicativos atuais usam carimbos de data/hora para garantir a consistência transacional, registrar o temo de
importantes eventos e outras informações críticas para os negócios e sensíveis ao tempo. Esses aplicativos se
beneficiam da sincronização de tempo entre computadores fornecidos pelo Serviço de Horário do Windows.
WARNING
Alguns aplicativos podem exigir que os computadores deles tenham serviços de tempo de alta precisão. Se esse
for o caso, você poderá optar por configurar uma fonte de horário manual, mas saiba que o Serviço de Horário do
Windows não foi criado para funcionar como uma fonte de horário altamente precisa. Verifique se você conhece as
limitações de suporte para ambientes de tempo de alta precisão conforme descrito no artigo 939322 da Base de
Dados de Conhecimento Microsoft, Limite de suporte para configurar o Serviço de Horário do Windows para
ambientes de alta precisão.
IMPORTANT
Antes do Windows Server 2016, o serviço W32Time não era criado para atender a necessidades de aplicativos sensíveis
ao tempo. Contudo, agora as atualizações do Windows Server 2016 permitem que você implemente uma solução para
ter precisão de 1 ms em seu domínio. Para obter mais informações sobre isso, confira Tempo Preciso do Windows 2016 e
Limite de suporte para configurar o Serviço de Horário do Windows para ambientes de alta precisão para obter mais
informações.
Tópicos relacionados
Hora precisa do Windows 2016
Aprimoramentos de precisão de tempo para o Windows Server 2016
Como o serviço de Horário do Windows funciona
Ferramentas e configurações do Serviço de Tempo do Windows
Limite de suporte para configurar o Serviço de Horário do Windows para ambientes de alta precisão
Artigo 902229 da Base de Dados de Conhecimento Microsoft
Como funciona o serviço Horário do Windows
13/08/2021 • 27 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012
R2, Windows Server 2012 e Windows 10 ou posterior
Nesta seção
Arquitetura do Serviço de Horário do Windows
Protocolos de tempo do Serviço de Horário do Windows
Processos e interações do Serviço de Horário do Windows
Portas de rede usadas pelo Serviço de Horário do Windows
NOTE
Este tópico explica como funciona o Serviço de Horário do Windows (W32Time). Para obter informações de como
configurar o Serviço de Horário do Windows, confira Configuração de sistemas para alta precisão.
NOTE
No Windows Server 2003 e no Microsoft Windows 2000 Server, o serviço de diretório é denominado serviço de diretório
Active Directory. No Windows Server 2008 e versões posteriores, o serviço de diretório é chamado de AD DS (Active
Directory Domain Services). O restante deste tópico refere-se ao AD DS, mas as informações também são aplicáveis para
o Active Directory.
Embora o Serviço de Horário do Windows não seja uma implementação exata do protocolo NTP, ele usa o
complexo conjunto de algoritmos definido nas especificações do NTP para verificar se os relógios em
computadores em toda a rede são os mais precisos possíveis. O ideal é que todos os relógios dos computadores
de um domínio do AD DS sejam sincronizados com a hora de um computador oficial. Muitos fatores podem
afetar a sincronização de horário em uma rede. Os seguintes fatores geralmente afetam a precisão da
sincronização no AD DS:
Condições da rede
A precisão do relógio do hardware do computador
A quantidade de recursos de CPU e de rede disponíveis para o Serviço de Horário do Windows
IMPORTANT
Antes do Windows Server 2016, o serviço W32Time não era criado para atender a necessidades de aplicativos sensíveis
ao tempo. Contudo, agora as atualizações do Windows Server 2016 permitem que você implemente uma solução para
ter precisão de 1 ms em seu domínio. Confira Tempo Preciso do Windows 2016 e Limite de suporte para configurar o
Serviço de Horário do Windows para ambientes de alta precisão para obter mais informações.
Os computadores que sincronizam o horário com menos frequência ou que não são associados a um domínio,
são configurados para sincronizar com o time.windows.com por padrão. Portanto, é impossível garantir a
precisão do tempo em computadores que têm conexões de rede intermitentes ou que não têm conexão.
Uma floresta do AD DS tem uma hierarquia de sincronização de tempo predeterminada. O Serviço de Horário
do Windows sincroniza o tempo entre computadores da hierarquia, com os relógios de referência mais precisos
na parte superior. Se mais de uma fonte de horário estiver configurada em um computador, o Horário do
Windows usará algoritmos NTP para selecionar a melhor fonte de horário dentre as fontes configuradas com
base na capacidade do computador de sincronizar com essa fonte de horário. O Serviço de Horário do Windows
não é compatível com a sincronização de rede de pares de difusão ou difusão seletiva. Para obter mais
informações sobre esses recursos de NTP, confira RFC 1305 no banco de dados RFC da IETF.
Todos os computadores que executam o Serviço de Horário do Windows usam o serviço para manter o tempo
mais preciso. Os computadores que são membros de um domínio atuam como um cliente de tempo por
padrão, portanto, na maioria dos casos, não é necessário configurar o Serviço de Horário do Windows. No
entanto, o Serviço de Horário do Windows pode ser configurado para solicitar a hora de uma fonte de horário
de referência designada e também pode fornecer o horário aos clientes.
O grau de precisão da hora de um computador é chamado de estrato. A fonte de horário mais precisa em uma
rede (como um relógio de hardware) ocupa o nível mais baixo de estrato ou estrato um. Essa fonte de horário
precisa é chamada de relógio de referência. Um servidor NTP que adquire o horário diretamente de um relógio
de referência ocupa um estrato que é um nível acima do relógio de referência. Os recursos que adquirem o
tempo do servidor NTP são dois níveis acima do relógio de referência e, portanto, ocupam um estrato maior do
que a fonte de horário mais precisa e assim por diante. À medida que o número de estrato de um computador
aumenta, o tempo no relógio do sistema pode se tornar menos preciso. Portanto, o nível de estrato de qualquer
computador é um indicador de quão próximo ele está sincronizado com a fonte de horário mais precisa.
Quando o Gerenciador do W32Time recebe amostras de tempo, ele usa algoritmos especiais do protocolo NTP
para determinar qual das amostras de tempo é a mais apropriada para uso. O serviço de horário também usa
outro conjunto de algoritmos para determinar qual das fontes de horário configuradas é a mais precisa. Quando
o serviço de horário tiver determinado qual amostra de tempo é a melhor, com base nos critérios acima, ele
ajustará a velocidade do relógio local para permitir que ela convirja em direção ao horário correto. Se a
diferença de tempo entre o relógio local e a amostra de hora precisa selecionada (também chamada de
distorção de tempo) for muito grande para ser corrigida ajustando a velocidade do relógio local, o serviço de
horário definirá o relógio local com a hora correta. Esse ajuste da velocidade do relógio ou alteração direta do
horário do relógio é conhecida como disciplina do relógio.
C O N T RO L A DO R DE C O N F IA B IL IDA DE DA
N ÚM ERO DA C O N SULTA DO M ÍN IO LO C A L F O N T E DE H O RÁ RIO
Obser vação
Um computador nunca sincroniza com ele mesmo. Se o computador que está tentando sincronizar for o
emulador de PDC local, ele não tentará as consultas 3 ou 6.
Cada consulta retorna uma lista de controladores de domínio que podem ser usados como uma fonte de
horário. O Horário do Windows atribui a cada controlador de domínio uma pontuação que é consultada com
base na confiabilidade e na localização do controlador de domínio. A tabela a seguir lista as pontuações
atribuídas pelo Horário do Windows a cada tipo de controlador de domínio.
Determinação da Pontuação
STAT US DO C O N T RO L A DO R DE DO M ÍN IO P O N T UA Ç Ã O
Quando o Serviço de Horário do Windows determina que identificou o controlador de domínio com a melhor
pontuação possível, ele para de fazer consultas. As pontuações atribuídas pelo serviço de horário são
cumulativas, o que significa que um emulador de PDC localizado no mesmo site recebe uma pontuação igual a
nove.
Se a raiz do serviço de horário não estiver configurada para sincronizar com uma fonte externa, o relógio de
hardware interno do computador controlará o tempo.
Sincronização especificada manualmente
A sincronização especificada manualmente permite designar um par ou uma lista de pares dos quais um
computador obtém o tempo. Se o computador não é membro de um domínio, ele deve ser configurado
manualmente para sincronizar com uma fonte de horário especificada. Um computador que é membro de um
domínio é configurado por padrão para sincronizar na hierarquia de domínio; a sincronização especificada
manualmente é mais útil para a raiz de floresta do domínio ou para computadores que não fazem parte de um
domínio. A especificação manual de um servidor NTP externo para sincronizar com o computador oficial do seu
domínio fornece um tempo confiável. No entanto, configurar o computador oficial do seu domínio para
sincronizar com um relógio de hardware é, na verdade, uma solução melhor para fornecer o tempo mais
preciso e seguro para o seu domínio.
As fontes de horários especificadas manualmente não são autenticadas, a menos que um provedor de horário
específico seja gravado para elas e, portanto, seja vulnerável a invasores. Além disso, se um computador
sincronizar com uma fonte especificada manualmente em vez de seu controlador de domínio de autenticação,
os dois computadores poderão ficar fora de sincronização, causando a falha da autenticação Kerberos. Isso pode
causar falha em outras ações que exigem autenticação de rede, como impressão ou compartilhamento de
arquivos. Se apenas a raiz da floresta estiver configurada para sincronizar com uma fonte externa, todos os
outros computadores da floresta permanecerão sincronizados entre si, dificultando os ataques de repetição.
Todos os mecanismos de sincronização disponíveis
A opção "todos os mecanismos de sincronização disponíveis" é o método de sincronização mais valioso para
usuários em uma rede. Esse método permite a sincronização com a hierarquia do domínio e também pode
fornecer uma fonte de horário alternativa, caso a hierarquia do domínio não esteja disponível, dependendo da
configuração. Se o cliente não puder sincronizar a hora com a hierarquia do domínio, a fonte de horário
automaticamente voltará para a fonte de horário especificada pela configuração NtpSer ver . Esse método de
sincronização tem maior probabilidade de fornecer um tempo preciso para os clientes.
Parando a sincronização de tempo
Há algumas situações em que você desejará impedir que um computador sincronize seu tempo. Por exemplo, se
um computador tentar sincronizar usando uma fonte de horário da Internet ou outro site por meio de uma
WAN de uma conexão discada, isso poderá gerar altos encargos de telefone. Ao desabilitar a sincronização
nesse computador, você impedirá que o computador tente acessar uma fonte de horário por meio de uma
conexão discada.
Você também pode desabilitar a sincronização para evitar a geração de erros no log de eventos. Cada vez que
um computador tenta sincronizar com uma fonte de horário que não está disponível, ele gera um erro no Log
de Eventos. Se uma fonte de horário for retirada da rede para manutenção agendada e você não pretender
reconfigurar o cliente para sincronizar com outra fonte, você poderá desabilitar a sincronização no cliente para
impedi-lo de tentar a sincronização enquanto o servidor de horário não estiver disponível.
É útil desabilitar a sincronização no computador designado como a raiz da rede de sincronização. Isso indica que
o computador raiz confia em seu relógio local. Se a raiz da hierarquia de sincronização não estiver definida
como NoSync e se não for possível sincronizar com outra fonte de horário, os clientes não aceitarão o pacote
enviado por esse computador, pois seu tempo não é confiável.
Os únicos servidores de tempo que são confiáveis para os clientes, mesmo que não tenham sido sincronizados
com outra fonte de horário, são aqueles identificados pelo cliente como servidores de horário confiáveis.
Desabilitando o Serviço de Horário do Windows
O Serviço de Horário do Windows (W32Time) pode ser completamente desabilitado. Se você optar por
implementar um produto de sincronização de tempo de terceiros que usa o NTP, será necessário desabilitar o
Serviço de Horário do Windows. Isso ocorre porque todos os servidores NTP precisam de acesso à porta 123
do protocolo UDP e, enquanto o Serviço de Horário do Windows estiver em execução no sistema operacional
Windows Server 2003, a porta 123 permanecerá reservada pelo Horário do Windows.
Portas de rede usadas pelo Serviço de Horário do Windows
O Serviço de Horário do Windows se comunica em uma rede para identificar fontes de horário confiáveis, obter
informações de tempo e fornecer informações de tempo a outros computadores. Ele executa essa comunicação
conforme definido pelas RFCs de NTP e SNTP.
Atribuições de por ta para o Ser viço de Horário do Windows
N O M E DO SERVIÇ O UDP TC P
Consulte Também
Referência técnica do Serviço de Horário do Windows Ferramentas e configurações do Serviço de Horário do
Windows Artigo 902229 da Base de Dados de Conhecimento Microsoft
Ferramentas e configurações do Serviço de Tempo
do Windows
18/08/2021 • 32 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012
R2, Windows Server 2012 e Windows 10
O Serviço de Hora do Windows (W32Time) sincroniza a data e a hora de todos os computadores gerenciados
pelo AD DS (Active Directory Domain Services). Este artigo aborda as diferentes ferramentas e configurações
usadas para gerenciar o Serviço de Hora do Windows.
Por padrão, um computador ingressado em um domínio sincroniza a hora por meio de uma hierarquia de
domínio de fontes de hora. No entanto, se um computador tiver sido configurado manualmente para
sincronizar de uma fonte de hora específica, talvez por não estar ingressado em um domínio anteriormente,
você poderá reconfigurá-lo para começar a obter a hora automaticamente da hierarquia de domínio.
A maioria dos computadores conectados ao domínio tem o tipo de cliente de hora NT5DS, o que significa que
sincronizam a hora com base na hierarquia de domínio. Uma exceção é o controlador de domínio, que funciona
como o mestre de operações do emulador PDC (controlador de domínio primário) do domínio da floresta raiz.
O mestre de operações do emulador PDC, por sua vez, geralmente é configurado para sincronizar a hora com
uma fonte de hora externa.
Você pode alcançar uma precisão de hora de um milissegundo em seu domínio. Para saber mais, confira Limite
de suporte para hora de alta precisão e Hora precisa para o Windows Server 2016.
Cau t i on
Não use o comando Net time para configurar nem definir a hora do relógio de um computador quando o
Serviço de Hora do Windows estiver em execução.
Além disso, em computadores mais antigos que executam o Windows XP ou anterior, o comando Net time
/quer ysntp exibe o nome de um servidor de protocolo NTP com o qual o computador está configurado para
sincronizar, mas esse servidor NTP é usado somente quando o cliente de hora do computador está configurado
como NTP ou AllSync. Esse comando foi preterido.
Porta de rede
O Serviço de Hora do Windows segue a especificação do protocolo NTP, que requer o uso da porta UDP 123
para toda a sincronização de hora. Sempre que o computador sincronizar o relógio ou fornecer a hora a outro
computador, isso ocorrerá por meio da porta UDP 123. Essa porta é reservada exclusivamente pelo Serviço de
Hora do Windows.
NOTE
Se você tem um computador com vários adaptadores de rede (ou multihomed), não poderá habilitar o Serviço de Hora
do Windows com base no adaptador de rede.
Usando W32tm.exe
Use a ferramenta de linha de comando W32tm.exe para definir as configurações do Serviço de Hora do
Windows e diagnosticar problemas com a hora do computador. O W32tm.exe é a ferramenta de linha de
comando preferencial para configurar, monitorar e solucionar problemas do Serviço de Hora do Windows. O
W32tm.exe é incluído no Windows XP e posteriores e no Windows Server 2003 e posteriores.
A associação ao grupo Administradores local é necessária para executar o W32tm.exe localmente, enquanto
a associação ao grupo Administradores de Domínio é necessária para executar o W32tm.exe remotamente.
Executar o W32tm.exe
1. Na barra de pesquisa do Windows, insira cmd .
2. Clique com o botão direito do mouse em Prompt de Comando e selecione Executar como
administrador .
3. No prompt de comando, digite w32tm seguido pelo parâmetro aplicável, conforme descrito abaixo:
PA RÂ M ET RO DESC RIÇ Ã O
/ntte <NT time epoch> Converte uma hora do sistema do Windows NT (medida em
intervalos de 10-7 segundos começando à 0h de 1º de
janeiro de 1601) em um formato legível.
/ntpte <NTP time epoch> Converte uma hora do NTP (medida em intervalos de 2-32
segundos começando à 0h de 1º de janeiro de 1900) em um
formato legível.
PA RÂ M ET RO DESC RIÇ Ã O
/resync [/computer:<computer>] [/nowait] [/rediscover] Informa a um computador que ele deve ressincronizar seu
[/soft] relógio assim que possível, descartando todas as estatísticas
de erro acumuladas.
/computer :< computer > : especifica o computador
que deve ser ressincronizado. Se não for especificado, o
computador local será ressincronizado.
/nowait : não aguardar a ressincronização; retornar
imediatamente. Caso contrário, aguardar a
ressincronização ser concluída antes de retornar.
/rediscover : detecta novamente a configuração de
rede, redescobre as fontes de rede e ressincroniza.
/soft : faz a ressincronização usando as estatísticas de
erro existentes. É usado para fins de compatibilidade.
/stripchar t /computer:<target> [/period:<refresh>] Exibe um gráfico de faixas da diferença entre este e outro
[/dataonly] [/samples:<count>] [/rdtsc] computador.
/computer :< target > : o computador em relação ao
qual a diferença será medida.
/period:< refresh > : o tempo entre amostras, em
segundos. O padrão é 2 segundos.
/dataonly : exibe somente os dados, sem gráficos.
/samples:< count > : coleta amostras <count> e, em
seguida, interrompe o processo. Se não for especificado,
os exemplos serão coletados até que CTRL+C seja
pressionado.
/config [/computer:<target>] [/update] [/manualpeerlist: /computer :< target > : ajusta a configuração de <target>.
<peers>] [/syncfromflags:<source>] [/LocalClockDispersion: Se não for especificada, o padrão será o computador local.
<seconds>] [/reliable:(YES|NO)] [/largephaseoffset: /update : notifica o Serviço de Hora do Windows de que
<milliseconds>]** a configuração foi alterada, fazendo com que as
alterações entrem em vigor.
/manualpeerlist:< peers > : define a lista de pares
manual como <peers>, que é uma lista delimitada por
espaços de DNS e/ou endereços IP. Ao especificar vários
pares, essa opção deve ser colocada entre aspas.
/syncfromflags:< source > : define de quais fontes o
cliente NTP deve fazer a sincronização. <source> deve
ser uma lista separada por vírgula dessas palavras-chave
(não diferencia maiúsculas de minúsculas):
MANUAL : inclui pares da lista de pares manuais.
DOMHIER: faz a sincronização de um DC
(controlador de domínio) na hierarquia de domínio.
/LocalClockDispersion:< seconds > : configura a precisão
do relógio interno que o W32Time presumirá quando não
puder adquirir a hora das fontes configuradas.
/reliable:(YES|NO) : define se este computador é uma
fonte de hora confiável. Essa configuração só é
significativa em controladores de domínio.
SIM : este computador é um serviço de hora
confiável.
NÃO : este computador não é um serviço de hora
confiável.
/largephaseoffset:< milliseconds > : define a diferença de
hora entre a hora local e a da rede que o W32Time vai
considerar um pico.
/debug {/disable | {/enable /file:<name> /size:/<bytes> habilita ou desabilita o log privado do Serviço de Hora do
/entries:<value> [/truncate]}} Windows do computador local. Esse parâmetro foi
disponibilizado pela primeira vez no cliente de Hora do
Windows no Windows Vista e no Windows Server 2008.
/disable : desabilita o log privado.
/enable : habilita o log privado.
file:< name > : especifica o nome de arquivo
absoluto.
size:< bytes > : especifica o tamanho máximo para o
log circular.
entries:< value > : contém uma lista de
sinalizadores, especificados por número e separados
por vírgulas, que especificam os tipos de informações
que devem ser registradas em log. Os valores válidos
são de 0 a 300. Uma variedade de números é válida,
além de números únicos, como 0-100.103.106. O
valor 0-300 é para registrar em log todas as
informações.
/truncate : trunca o arquivo, se ele existir.
O resultado desse comando exibe uma lista de parâmetros de configuração de W32time que são definidos para
o cliente.
IMPORTANT
O Windows Server 2016 aprimorou os algoritmos de sincronização de tempo para se alinhar com as especificações de
RFC. Portanto, se você quiser definir o cliente de hora local para apontar para vários pares, é altamente recomendável
preparar três ou mais servidores de hora diferentes.
Se você tiver apenas dois servidores de hora, deverá especificar o sinalizador (0x2) Ntpser ver UseAsFallbackOnly para
retirar a prioridade de um deles. Por exemplo, se quiser priorizar ntpserver.contoso.com com relação a
clock.adatum.com , execute o comando a seguir.
Além disso, você pode executar o seguinte comando e ler o valor de NtpServer na saída:
Em seguida, para ajustar o relógio do computador usando a taxa do relógio, W32tm.exe calcula um valor
PhaseCorrection . Esse algoritmo varia dependendo da versão do Windows:
Todas as versões do Windows usam a mesma equação final para verificar PhaseCorrection :
PhaseCorrection ≤ SystemClockRate ÷2
NOTE
Essas equações usam PhaseCorrectRate , UpdateInterval , MaxAllowedPhaseOffset e SystemClockRate
medidos em unidades de tiques de relógio. Em sistemas Windows, 1 ms = 10.000 tiques de relógio.
MaxAllowedPhaseOffset é configurável no Registro. No entanto, o parâmetro de Registro é medido em
segundos, em vez de tiques de relógio.
Para ver os valores SystemClockRate e pollIntervalInSeconds (medidos em segundos), abra uma janela do
Prompt de comando e, em seguida, execute W32tm /query /status /verbose . Esse comando produz uma saída
semelhante ao descrito a seguir.
A saída apresenta o intervalo de sondagem em tiques do relógio e em segundos. As equações usam o valor
medido em segundos (o valor entre parênteses).
A saída apresenta a taxa do relógio em segundos. Para ver o valor SystemClockRate em tiques do relógio, use a
seguinte fórmula:
Por exemplo, se SystemClockRate for 0,0156250 segundos, o valor usado pela equação será de 156.250 tiques
do relógio. Para obter descrições completas dos parâmetros configuráveis e os valores padrão deles, confira
Entradas de configuração mais adiante neste artigo.
Os exemplos a seguir mostram como aplicar esses cálculos para o Windows Server 2012 R2 e versões
anteriores.
Exemplo: taxa do relógio do sistema deslocada em quatro minutos
A hora do relógio do computador é 11h05 e a hora atual real é 11h09:
PhaseCorrectRate =1
UpdateInterval = 30.000 tiques do relógio
SystemClockRate = 156.000 tiques do relógio
MaxAllowedPhaseOffset = 10 min = 600 segundos = 600 × 1.000 × 10.000 = 6.000.000.000 de tiques do
relógio
| CurrentTimeOffset | = 4 min = 4 × 60 × 1.000 × 10.000 = 2.400.000.000 de tiques do relógio
É CurrentTimeOffset ≤ MaxAllowedPhaseOffset ?
NOTE
Nesse caso, se você quiser atrasar o relógio lentamente, também precisará ajustar os valores de PhaseCorrectRate ou
UpdateInterval no Registro para garantir que o resultado da equação seja TRUE.
PhaseCorrectRate =1
UpdateInterval = 30.000 tiques do relógio
SystemClockRate = 156.000 tiques do relógio
MaxAllowedPhaseOffset = 10 min = 600 segundos = 600 × 1.000 × 10.000 = 6.000.000.000 de tiques do
relógio
| CurrentTimeOffset | = 3 min = 3 × 60 × 1.000 × 10.000 = 1.800.000.000 de tiques do relógio
É CurrentTimeOffset ≤ MaxAllowedPhaseOffset ?
NOTE
As configurações da Política de Grupo do Serviço de Hora do Windows podem ser aplicadas nos controladores de
domínio do Windows Server 2003, do Windows Server 2003 R2, do Windows Server 2008 e do Windows Server 2008 R2
e podem ser aplicadas a computadores que executam o Windows Server 2003, o Windows Server 2003 R2, o Windows
Server 2008 e o Windows Server 2008 R2.
O Windows armazena as informações de política de Serviço de Hora do Windows no Editor de Política de Grupo
Local em Computer Configuration\Administrative Templates\System\Windows Time Service . Ele armazena as
informações de configuração que as políticas definem no Registro do Windows e usa essas entradas do Registro
para configurar as entradas do Registro específicas para o Serviço de Hora do Windows. Como resultado, os
valores definidos pela Política de Grupo substituem os valores pré-existentes na seção do Serviço de Hora do
Windows do Registro. Algumas das configurações predefinidas do GPO são diferentes das entradas do Registro
do Serviço de Hora do Windows padrão correspondentes.
Por exemplo, suponha que você edite as configurações de política na política Provedores de
Hora\Configurar o Cliente NTP do Windows . O Windows carrega essas configurações na área de política
do Registro na seguinte subchave:
HKLM\Software\Policies\Microsoft\W32time\TimeProviders\NtpClient
Em seguida, o Windows usa as configurações de política para definir as entradas do Registro do Serviço de Hora
do Windows relacionadas na seguinte subchave:
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Time Providers\NTPClient\\
A tabela a seguir lista as políticas que podem ser configuradas para o Serviço de Hora do Windows e as
subchaves do Registro que essas políticas afetam.
NOTE
Quando você remove uma configuração de Política de Grupo, o Windows remove a entrada correspondente da área de
política do Registro.
P O L ÍT IC A DE GRUP O 1 LO C A L IZ A Ç Õ ES DO REGIST RO 2, 3
NOTE
Alguns dos parâmetros do Registro são medidos em tiques do relógio e outros são medidos em segundos. Para converter
a hora de tiques do relógio em segundos, use estes fatores de conversão:
1 minuto = 60 s
1 s = 1000 ms
1 ms = 10.000 tiques do relógio em um sistema Windows, conforme descrito na Propriedade DateTime.Ticks.
Por exemplo, 5 minutos passam a ser 5 × 60 × 1.000 × 10.000 = 3.000.000.000 tiques do relógio.
Entradas de configuração
As entradas de subchave Config estão localizadas em HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config .
ClockHoldoverPeriod Windows Server 2016 versão 1709 e Indica o número máximo de segundos
versões posteriores; Windows 10 que um relógio do sistema pode
versão 1709 e versões posteriores manter nominalmente a precisão sem
sincronizar com uma fonte de hora. Se
esse período passar sem o W32time
obter novas amostras de um dos
provedores de entrada, o W32time
iniciará uma redescoberta de fontes de
hora. Default: 7.800 segundos.
Entradas de parâmetros
As entradas de subchave Parameters estão localizadas em
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters .
EN T RA DA DE REGIST RO VERSÕ ES DESC RIÇ Ã O
Entradas de NtpClient
As entradas de subchave NtpClient estão localizadas em
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
Entradas de NtpServer
As entradas de subchave NtpClient estão localizadas em
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer .
AnnounceFlags 10
EventLogFlags 2
FrequencyCorrectRate 4
HoldPeriod 5
LargePhaseOffset 1.280.000
LocalClockDispersion 10
MaxAllowedPhaseOffset 300
MaxPollInterval 15
MinPollInterval 10
PhaseCorrectRate 7
PollAdjustFactor 5
C O N F IGURA Ç Ã O DA P O L ÍT IC A DE GRUP O VA LO R PA DRÃ O
SpikeWatchPeriod 90
UpdateInterval 100
CrossSiteSyncFlags 2
ResolvePeerBackoffMinutes 15
ResolvePeerBackoffMaxTimes 7
SpecialPollInterval 3.600
EventLogFlags 0
Informações relacionadas
Confira RFC 1305 – Protocolo NTP da IETF (Internet Engineering Task Force).