[xanburzum]

A rede e as comunicações são críticas para que as organizações atendam ao desafio de competir no mercado global. Os funcionários precisam conectar-se à rede de qualquer lugar onde estejam e usando qualquer dispositivo. Parceiros, fornecedores e outros usuários fora da rede precisam interagir eficientemente com recursos-chave, e a segurança é mais importante do que nunca.

Este artigo é uma visão geral técnica dos aprimoramentos da rede e das comunicações no Windows Server "Longhorn" e no Windows Vista que abordam questões de conectividade, facilidade de uso, gerenciamento, confiabilidade e segurança. Com o Windows Server "Longhorn" e o Windows Vista, os administradores de TI têm opções mais variadas e flexíveis para gerenciar a infra-estrutura da rede, protegendo-a ao exigir que os computadores comprovem a integridade de seus sistemas, ao implantar conexões com e sem fio autenticadas por meio da Diretiva de Grupo ou de scripts e ao implantar cenários de tráfego protegido.

Protocolos e componentes centrais da rede
O Windows Server "Longhorn" e o Windows Vista incluem muitas alterações e aprimoramentos aos seguintes protocolos e componentes centrais da rede:

Next Generation TCP/IP Stack

Qualidade do Serviço

Aprimoramentos no Http.sys

Aprimoramentos no WinINet

Aprimoramentos no Windows Sockets

NDIS 6.0

Aprimoramentos no Windows Peer-to-Peer Networking

Aprimoramentos no Firewall do Windows

Aprimoramentos no IPsec

Next Generation TCP/IP Stack
O Windows Server "Longhorn" e o Windows Vista incluem uma nova implementação da pilha do protocolo TCP/IP conhecida como Next Generation TCP/IP Stack. A Next Generation TCP/IP Stack é um redesign completo da funcionalidade do TCP/IP para os protocolos IPv4 e IPv6 que atende às necessidades de conectividade e de desempenho dos vários ambientes e tecnologias de rede atuais.

Ajuste automático da janela de recebimento
O tamanho da janela de recebimento do TCP é a quantidade de bytes em um buffer de memória em um host de recebimento que é usada para armazenar dados de entrada em uma conexão TCP. Para determinar corretamente o valor do tamanho máximo da janela de recebimento para uma conexão com base nas condições atuais da rede, a Next Generation TCP/IP Stack oferece suporte ao Ajuste automático da janela de recebimento. O Ajuste automático da janela de recebimento determina continuamente o tamanho ideal da janela de recebimento em uma base por conexão, medindo o produto do atraso da largura de banda (a largura de banda multiplicada pela latência da conexão) e a taxa de recuperação do aplicativo, e ajusta automaticamente o tamanho máximo da janela de recebimento em uma base contínua.

Com uma taxa de transferência melhor entre os pontos TCP, a utilização da largura de banda da rede aumenta durante a transferência de dados. Se todos os aplicativos estiverem otimizados para receber dados TCP, a utilização global da rede poderá aumentar substancialmente, tornando a utilização da QoS (Qualidade do Serviço) mais importante para as redes que estão funcionando no limite de sua capacidade. Para obter mais informações, consulte "Qualidade do Serviço" neste documento.

Para obter mais informações sobre o Ajuste automático da janela de recebimento, consulte Melhorias de desempenho da Next Generation TCP/IP Stack.

TCP composto
Em conexões TCP com uma grande janela de recebimento e um amplo produto de atraso da largura de banda (a largura de banda de uma conexão multiplicada por seu atraso), o CTCP (TCP composto) na Next Generation TCP/IP Stack aumenta significativamente a quantidade de dados enviados simultaneamente, monitorando o produto do atraso da largura de banda, as variações do atraso e as perdas de pacotes. O CTCP também garante que seu comportamento não afete negativamente outras conexões TCP. Em testes executados internamente na Microsoft, tempos de backup de arquivos grandes foram reduzidos quase pela metade em uma conexão de 1 gigabyte por segundo com um tempo de ciclo de 50 milissegundos. Conexões com um produto de atraso da largura de banda maior podem ter um desempenho melhor ainda.

O Ajuste automático da janela de recebimento otimiza a taxa de transferência do lado do destinatário e o CTCP otimiza a taxa de transferência do lado do remetente. Trabalhando em conjunto, eles podem aumentar a utilização do link e produzir ganhos substanciais de desempenho para conexões com um alto produto de atraso da largura de banda.

A Next Generation TCP/IP Stack oferece suporte aos seguintes RFCs para otimizar a taxa de transferência em ambientes de alta perda:
RFC 2582: a modificação do NewReno para o Algoritmo de Recuperação Rápida do TCP

O algoritmo NewReno fornece uma taxa de transferência mais rápida alterando a maneira como um remetente pode aumentar sua taxa de envio quando vários segmentos em uma janela de dados são perdidos e o remetente recebe uma confirmação parcial (uma confirmação apenas de parte dos dados que foram recebidos com êxito).

RFC 2883: uma extensão à opção SACK (Confirmação seletiva) para TCP

O SACK, definido no RFC 2018, permite que um destinatário indique até quatro blocos não contíguos de dados recebidos. O RFC 2883 define um uso adicional dos campos na opção SACK TCP para confirmar pacotes duplicados. Isso permite que o destinatário do segmento TCP que contém a opção SACK determine quando retransmitiu um segmento desnecessariamente e ajusta seu comportamento para evitar retransmissões futuras. Quanto menos retransmissões forem enviadas, melhor será a taxa de transferência global.

RFC 3517: um algoritmo conservador de recuperação de perdas baseado em SACK (Confirmação seletiva) para TCP

A implementação do TCP/IP no Windows Server 2003 e no Windows® XP usa informações de SACK apenas para determinar quais segmentos TCP não chegaram ao destino. O RFC 3517 define um método de uso das informações de SACK para executar a recuperação de perdas quando confirmações duplicadas são recebidas, substituindo o algoritmo de recuperação rápida quando o SACK está habilitado em uma conexão. A Next Generation TCP/IP Stack controla as informações do SACK por conexão e monitora as confirmações de entrada e duplicadas para uma recuperação mais rápida quando vários segmentos não são recebidos no destino.

RFC 4138: Forward RTO-Recovery (F-RTO): um algoritmo para a detecção de tempos limite falsos de retransmissão com os protocolos TCP e SCTP.

Retransmissões falsas de segmentos TCP podem ocorrer quando há um aumento repentino e temporário no RTT. O algoritmo F-RTO evita a retransmissão falsa de segmentos TCP. O resultado do algoritmo F-RTO é que em ambientes que têm aumentos repentinos e temporários no RTT, como quando um cliente sem fio se move de um AP sem fio para outro, o F-RTO evita a retransmissão desnecessária de segmentos e retorna mais rapidamente para sua taxa de envio normal.

Para obter mais informações sobre esses aprimoramentos, consulte Melhorias de desempenho da Next Generation TCP/IP Stack.

Neighbor Unreachability Detection para IPv4
Neighbor Unreachability Detection é um recurso do IPv6 no qual um nó controla se um nó vizinho está acessível, proporcionando melhor detecção de erros e recuperação quando os nós se tornam indisponíveis repentinamente. A Next Generation TCP/IP Stack também oferece suporte ao Neighbor Unreachability Detection para tráfego IPv4 controlando o estado de acessibilidade de vizinhos IPv4 no cache de rotas do IPv4. O Neighbor Unreachability Detection para IPv4 determina a acessibilidade por meio de uma troca de mensagens unicast de solicitação ARP e de resposta ARP ou contando com protocolos da camada superior, como o TCP. Com o Neighbor Unreachability Detection para IPv4, as comunicações baseadas em IPv4 são beneficiadas determinando quando nós vizinhos, incluindo roteadores, não estão mais acessíveis e relatando a condição.

Para obter mais informações sobre o Neighbor Unreachability Detection para IPv4, consulte Melhorias de desempenho da Next Generation TCP/IP Stack.

Alterações na detecção de gateway inativo
A detecção de gateway inativo no TCP/IP para Windows Server 2003 e para Windows XP fornece uma função de failover, mas não uma função de failback na qual um gateway inativo é chamado novamente para determinar se ele se tornou disponível. A Next Generation TCP/IP Stack fornece failback para gateways inativos tentando enviar periodicamente tráfego TCP por meio do gateway inativo anteriormente detectado. Se o tráfego TCP enviado por meio do gateway inativo tiver êxito, a Next Generation TCP/IP Stack trocará o gateway padrão pelo gateway inativo detectado anteriormente. O suporte de failback para gateways padrão primários pode fornecer uma taxa de transferência mais rápida enviando tráfego pelo gateway padrão primário na sub-rede.

Alterações na detecção do roteador buraco negro PMTU
A descoberta de PMTU (Unidade de transmissão máxima de caminho), definida no RFC 1191, conta com o recebimento de mensagens do tipo "Destino Inacessível-Fragmentação Necessária" e "Não Fragmentar Conjunto" do protocolo ICMP de roteadores que contêm o MTU do próximo link. No entanto, em alguns casos, roteadores intermediários descartam pacotes que não podem ser fragmentados silenciosamente. Esses tipos de roteadores são conhecidos como roteadores buraco negro PMTU. Além disso, roteadores intermediários podem ignorar mensagens ICMP devido a regras de firewall configuradas. O resultado é que as conexões TCP podem esgotar o tempo limite e terminar porque os roteadores intermediários descartam silenciosamente grandes segmentos TCP, suas retransmissões e as mensagens de erro ICMP para descoberta de PMTU.

O roteador buraco negro PTMU detecta quando grandes segmentos TCP estão sendo retransmitidos e ajusta automaticamente o PMTU para a conexão, em vez de contar com o recebimento de mensagens do tipo "Destino Inacessível-Fragmentação Necessária" e "Não Fragmentar Conjunto". Com o TCP/IP no Windows Server 2003 e no Windows XP, a detecção do roteador buraco negro PMTU é desabilitada por padrão porque sua habilitação aumenta o número máximo de retransmissões executadas para um determinado segmento.

No entanto, com o aumento do uso de regras de firewall em roteadores para ignorar o tráfego ICMP, a Next Generation TCP/IP Stack habilita a detecção do roteador buraco negro PMTU por padrão para evitar que conexões TCP sejam encerradas. A detecção do roteador buraco negro PMTU é disparada em uma conexão TCP quando ela começa a retransmitir segmentos inteiros com o sinalizador de desfragmentação ativo. O TCP redefine o PTMU da conexão para 536 bytes e retransmite seus segmentos com o sinalizador de desfragmentação desmarcado. Isso mantém a conexão TCP, embora em um tamanho de PMTU provavelmente menor do que o que realmente existe para a conexão.

Compartimentos de roteamento
Para evitar o encaminhamento de tráfego indesejado entre interfaces para a rede virtual privada (VPN), o Terminal Sever e as configurações de logon multiusuário, a Next Generation TCP/IP Stack oferece suporte a compartimentos de roteamento. Um compartimento de roteamento é a combinação de um conjunto de interfaces com uma sessão de logon que possui suas próprias tabelas de roteamento de IP. Um computador pode ter vários compartimentos de roteamento isolados uns dos outros. Cada interface pode pertencer a apenas um único compartimento.

Por exemplo, quando um usuário inicia uma conexão VPN na Internet com a implementação de TCP/IP no Windows XP, o computador do usuário possui conectividade parcial com a Internet e com uma intranet particular manipulando entradas na tabela de roteamento IPv4. Em algumas situações, é possível que o tráfego da Internet seja encaminhado através da conexão VPN para a intranet particular. Para clientes VPN que oferecem suporte a compartimentos de roteamento, a Next Generation TCP/IP Stack isola a conectividade da Internet da conectividade da intranet particular com tabelas de roteamento de IP separadas.

Suporte ao Network Diagnostics Framework
O Network Diagnostics Framework é uma arquitetura extensível que ajuda os usuários a recuperar e a solucionar problemas com conexões de rede. Para comunicação baseada em TCP/IP, o Network Diagnostics Framework fornece ao usuário uma série de opções para eliminar possíveis causas até que a causa raiz do problema seja identificada ou que todas as possibilidades sejam eliminadas. Os problemas específicos relacionados ao TCP/IP que podem ser diagnosticados pelo Network Diagnostics Framework são os seguintes:

Endereço IP incorreto

Gateway padrão (roteador) não disponível

Gateway padrão incorreto

Falha na resolução de nomes de NetBT (NetBIOS sobre TCP/IP)

Configurações de DNS incorretas

Porta local já está sendo usada

O serviço cliente DHCP não está em execução

Não existe ouvinte remoto

A mídia está desconectada

A porta local está bloqueada

Memória insuficiente

Suporte ao ESTATS
A Next Generation TCP/IP Stack oferece suporte ao rascunho da Internet "TCP Extended Statistics MIB" (draft-ietf-tsvwg-tcp-mib-extension-08.txt, em inglês) que define estatísticas estendidas de desempenho para TCP. Analisando o ESTATS em uma conexão, é possível determinar se o afunilamento do desempenho de uma conexão é o aplicativo de envio, o aplicativo de recebimento ou a rede. O ESTATS é desabilitado por padrão e pode ser habilitado por conexão. Com o ESTATS, ISVs (fornecedores independentes de software) podem criar aplicativos poderosos de diagnóstico e de análise da taxa de transferência da rede.

Novo modelo de filtragem de pacotes com a Windows Filtering Platform
A WFP (Windows Filtering Platform) é uma nova arquitetura na Next Generation TCP/IP Stack que fornece APIs para que ISVs de terceiros possam participar nas decisões de filtragem que ocorrem em várias camadas da pilha do protocolo TCP/IP e em todo o sistema operacional. A plataforma também integra e fornece suporte a recursos de firewall de ponta, como a comunicação autenticada e a configuração dinâmica de firewall baseada no uso dos aplicativos da API do Windows Sockets (diretiva baseada em aplicativo). Os ISVs podem criar firewalls, software antivírus, software de diagnóstico e outros tipos de aplicativos e serviços. O Firewall do Windows e o IPsec no Windows Server "Longhorn" e no Windows Vista usam a API WFP.

Para obter mais informações, consulte Windows Filtering Platform (em inglês).

Aprimoramentos no IPv6
A Next Generation TCP/IP Stack oferece suporte aos seguintes aprimoramentos no IPv6:

Pilha dupla de IP

A Next Generation TCP/IP Stack oferece suporte à arquitetura de camada dupla de IP, na qual as implementações de IPv4 e IPv6 compartilham camadas de transporte (que inclui TCP e UDP) e de delimitação de quadros comuns. A Next Generation TCP/IP Stack tem os protocolos IPv4 e IPv6 habilitados por padrão. Não é necessário instalar um componente separado para obter suporte ao IPv6.

Habilitado por padrão

No Windows Server "Longhorn" e no Windows Vista, o IPv6 é instalado e habilitado por padrão. É possível desabilitar o IPv6 para as conexões desmarcando a caixa de seleção ao lado do componente de IP versão 6 (TCP/IPv6) a partir das propriedades de uma conexão na pasta Connections and Adapters ou na Diretiva de Grupo. É possível definir as configurações de IPv6 por meio das propriedades do componente de IP versão 6 (TCP/IPv6) e por meio de comandos no contexto de netsh interface ipv6.

Configuração baseada na GUI

O Windows Server "Longhorn" e o Windows Vista agora permitem definir manualmente configurações de IPv6 por meio de um conjunto de caixas de diálogo na pasta Connections and Adapters, semelhante à forma como você pode definir manualmente as configurações de IPv4.

Aprimoramentos no Teredo

O Teredo é habilitado por padrão para computadores que executam o Windows Vista e para computadores membros do domínio. O Teredo pode funcionar se houver um cliente Teredo sob um ou mais NATs (conversores de endereços de rede) simétricos. Um NAT simétrico mapeia o mesmo endereço (privado) e número de porta internos para diferentes endereços (públicos) e portas externos, dependendo dos endereços de destino externos (para tráfego de saída). Esse novo comportamento permite que o Teredo funcione entre um conjunto maior de hosts conectados à Internet.

Suporte ao IPsec integrado

No Windows Server "Longhorn" e no Windows Vista, o suporte ao IPsec para tráfego IPv6 é o mesmo que para IPv4, incluindo suporte para o protocolo IKE e criptografia de dados. Os snap-ins Firewall do Windows com Segurança Avançada e Diretivas de Segurança IP agora oferecem suporte à configuração de diretivas IPsec para tráfego IPv6 da mesma maneira que para tráfego IPv4. Por exemplo, quando você configura um filtro IP como parte de uma lista de filtros IP no snap-in Diretivas de Segurança IP, é possível especificar endereços e prefixos de endereço IPv6 no Endereço IP ou Sub-Rede ao especificar um endereço IP específico de origem ou de destino.

MLDv2

O protocolo MLDv2 (Multicast Listener Discovery versão 2), especificado no RFC 3810, fornece suporte para tráfego multicast específico da origem. O MLDv2 é equivalente ao protocolo IGMPv3 (Group Management Protocol versão 3) para IPv4.

LLMNR

O protocolo LLMNR (Link-Local Multicast Name Resolution) permite que hosts IPv6 em uma única sub-rede sem um servidor DNS resolvam os nomes uns dos outros. Esse recurso é útil para redes domésticas com uma única sub-rede e redes sem fio ad hoc.

IPv6 sobre PPP

O cliente de acesso remoto interno agora oferece suporte ao IPv6 sobre o protocolo PPP (PPPv6) conforme definido no RFC 2472. O tráfego nativo IPv6 agora pode ser enviado por meio de conexões baseadas em PPP. Por exemplo, o suporte ao PPPv6 agora permite conexão com um provedor de serviços de Internet baseado em IPv6 por meio de conexões dial-up ou PPP sobre conexões baseadas em Ethernet (PPPoE) que podem ser usadas para acesso à Internet de banda larga.

Identificações aleatórias de interface para endereços IPv6

Para evitar verificações de endereços IPv6 com base nas identificações conhecidas de empresas de fabricantes de adaptadores de rede, o Windows Server "Longhorn" e o Windows Vista, por padrão, geram identificações aleatórias de interface para endereços IPv6 não temporários configurados automaticamente, incluindo endereços públicos e de links locais.

Suporte ao DHCPv6

O Windows Server "Longhorn" e o Windows Vista incluem um cliente DHCP com capacidade para DHCPv6 que executará a configuração automática de endereços com monitoração de estado com um servidor DHCPv6. O Windows Server "Longhorn" inclui um serviço de servidor DHCP com capacidade para DHCPv6.

Para obter mais informações sobre alterações no IPv6 no Windows Server "Longhorn" e no Windows Vista, consulte Alterações no IPv6 no Windows Vista e no Windows Server "Longhorn".

Qualidade do Serviço
No Windows Server 2003 e no Windows XP, a funcionalidade de QoS (Qualidade do Serviço) é disponibilizada para aplicativos por meio de APIs de QoS genérica (GQoS). Aplicativos que usavam as APIs de GQoS podiam acessar funções de entrega priorizada. No Windows Server "Longhorn" e no Windows Vista, existem novos recursos para gerenciar o tráfego da rede para empresas e residências.

QoS baseada em diretivas para redes corporativas
As diretivas de QoS no Windows Server "Longhorn" e no Windows Vista permitem que a equipe de TI priorize ou gerencie a taxa de envio de tráfego de rede de saída e podem ser confinadas para aplicativos específicos, endereços IP específicos de origem e de destino e portas TCP ou UDP de origem e de destino específicas. As configurações de diretivas de QoS fazem parte da Diretiva de Grupo Configuração do Usuário ou Configuração do Grupo e são definidas com o Editor de Objeto de Diretiva de Grupo e vinculadas aos recipientes do serviço de diretório do Active Directory® (domínios, sites e unidades organizacionais) com o Console de Gerenciamento de Diretiva de Grupo. As diretivas de QoS podem ser aplicadas a usuários ou computadores membros de um domínio, um site ou uma unidade organizacional.

Para gerenciar o uso da largura de banda, é possível configurar uma diretiva de QoS com uma taxa de otimização para o tráfego de saída. Por meio da otimização, uma diretiva de QoS limitará o tráfego de saída agregado da rede a uma taxa especificada. Para especificar a entrega priorizada, o tráfego é marcado com um valor de DSCP (Ponto de código de serviços diferenciados). Os roteadores na infra-estrutura da rede podem colocar pacotes marcados por DSCP em filas diferentes para uma entrega diferenciada. A marcação e a otimização do DSCP podem ser usadas em conjunto para gerenciar o tráfego de forma eficiente. Como a otimização e a marcação da prioridade ocorrem na camada da rede, os aplicativos não precisam ser modificados.

Para obter mais informações sobre a QoS baseada em diretivas, consulte Quality of Service in Windows Server "Longhorn" and Windows Vista (em inglês). Para obter informações sobre a arquitetura da QoS baseada em diretivas, consulte Policy-based QoS Architecture in Windows Server "Longhorn" and Windows Vista (em inglês).

qWave para redes domésticas
Como as redes domésticas estão cada vez mais sendo compartilhadas por aplicativos de dados e de AV (áudio/vídeo), uma solução de QoS é necessária para que o tráfego de AV dependente de tempo possa receber tratamento preferencial sobre o tráfego de dados. Além disso, as redes domésticas estão cada vez mais se tornando sem fio, o que introduz complicações adicionais para aplicativos que levam em conta a largura de banda e a latência. O Windows Vista oferece suporte ao qWave (Quality Windows Audio-Video Experience), uma coleção de módulos de software relacionados à QoS que lidam com desafios da rede introduzidos por aplicativos de AV e redes sem fio. O qWave está integrado na pilha da rede como parte do subsistema de QoS e funciona com várias tecnologias de prioridade de pacotes da camada de link da rede e de dados, para oferecer suporte a vários fluxos de AV (fluxos em tempo real que exigem a QoS) e fluxos de dados (fluxos de melhor esforço, como e-mail ou transferências de arquivos) simultaneamente por meio de uma rede doméstica, enquanto fornece uma experiência de usuário de alta qualidade.

A coleção de tecnologias do qWave detecta e monitora a largura de banda da rede local, descobre o recurso de QoS da rede doméstica e fornece controle de admissão distribuído para uma utilização uniforme e consistente da largura de banda da rede. Essas tecnologias habilitam técnicas avançadas de transmissão de AV para que os aplicativos possam adaptar-se dinamicamente à condições variáveis da rede.

Para obter mais informações sobre o qWave, consulte Quality Windows Audio-Video Experience - qWave (em inglês).

Aprimoramentos no Http.sys
O Http.sys, o driver do modo kernel que atende o tráfego do protocolo HTTP, foi aprimorado no Windows Server "Longhorn" e no Windows Vista com o seguinte:

HTTP Server API 2.0

Autenticação no servidor

Registro em log

Rastreamento ETW para eventos HTTP

Comandos Netsh

Contadores de desempenho

HTTP Server API 2.0
A HTTP Server API é um driver de protocolo HTTP no modo kernel com APIs no modo usuário disponíveis por meio do Httpapi.dll. As HTTP Server APIs permitem que um aplicativo de servidor registre URLs HTTP, receba solicitações e forneça respostas. As HTTP Server APIs incluem:

Recurso de ouvinte HTTP fácil de usar no Windows com aplicativos Windows .NET nativos e gerenciados.

Os aplicativos podem usar a HTTP Server API para a coexistência e o compartilhamento de portas TCP com o IIS (Serviços de informações da internet) 6.0. Isso permite que portas TCP populares de tráfego da Web, como a 80 e a 443, sejam usadas por aplicativos baseados na HTTP Server API e no IIS 6.0 simultaneamente desde que eles estejam atendendo a partes diferentes do namespace da URL.

Uma pilha HTTP nativa para computadores executando um sistema operacional Windows compatível com o HTTP/1.1.

Novas APIs para configuração do servidor HTTP: Autenticação, Otimização de largura de banda, Registro em log, Limites de conexão, Estado do servidor, Respostas 503, Filas de solicitações, Cache de resposta e Ligação de certificado SSL. Para obter mais informações, consulte Using the HTTP Server Version 2.0 API (em inglês).

Autenticação no servidor
O Http.sys agora executa autenticação no servidor. Anteriormente, os aplicativos de servidor executavam sua própria autenticação. As vantagens do fornecimento da autenticação no servidor pelo Http.sys incluem o seguinte:

Os aplicativos de servidor podem ser executados sob contas com menos privilégios.

Os aplicativos de servidor podem ser executados sob contas diferentes, pois o Http.sys agora executa a autenticação SPN (Nome Principal do Serviço) em nome deles.

Handshakes de autenticação NTLM transparentes não provocam uma reinicialização do processo de handshake.

Registro em log
O Http.sys agora fornece o registro em log do W3C (World Wide Web Consortium) no qual um único arquivo de log armazena as entradas de todos os sites de um aplicativo de servidor, como o IIS. Dentro do arquivo de log centralizado, os campos de identificação encontram o site ao qual as entradas do log pertencem.

Rastreamento ETW para eventos HTTP
O ETW (Rastreamento de eventos do Windows) é um recurso do Windows que lhe permite obter informações sobre componentes e eventos, normalmente gravados em arquivos de log. Os arquivos de log do ETW facilitam muito a solução de problemas. O rastreamento também pode diagnosticar problemas de ponta a ponta, nos quais uma Identificação de Atividade indica o fluxo entre operações. O Http.sys oferece suporte ao rastreamento das seguintes categorias:

Solicitações e respostas HTTP

Transações de autenticação e SSL

Registro de eventos

Conexões e timers de conexão

Cache

Configuração de serviço ou de aplicativo; configuração ou exclusão de propriedades

Baseado na identificação da atividade, incluindo entre outros componentes habilitados para o ETW

Para cada categoria de rastreamento, o Http.sys oferece suporte a quatro níveis de informações: Erro, Aviso, Informativa e Detalhada. O rastreamento do Http.sys pode ser usado como uma ferramenta de solução de problemas avançada para obter informações sobre processos e sobre o comportamento do Http.sys.

Para iniciar uma sessão de rastreamento ETW para o Http.sys, execute os procedimentos a seguir:

Crie uma pasta para armazenar os arquivos de rastreamento. Nessa pasta, crie um arquivo denominado Httptrace.txt com o seguinte conteúdo:

"Microsoft-Windows-HttpService" 0xFFFF
Use o seguinte comando para iniciar o rastreamento:

logman start "http trace" -pf httptrace.txt -o httptrace.etl -ets
Execute as etapas ou os testes que precisam ser rastreados.

Para iniciar uma sessão de rastreamento ETW para o Http.sys, use o seguinte comando:

logman stop "http trace" -ets
Um arquivo de rastreamento Httptrace.etl deve aparecer na pasta agora. Esse arquivo pode ser convertido em formato XML, HTML ou em um arquivo CSV com a ferramenta Tracerpt.exe. Por exemplo, para converter o conteúdo do arquivo Httptrace.etl em um arquivo CSV, use o seguinte comando:

tracerpt httptrace.etl -y -o httptrace.csv
Em seguida, os arquivos CSV podem ser visualizados em um aplicativo de editor de texto ou planilha.

Comandos Netsh para Http.sys
Agora, é possível gerenciar definições da configuração e diagnósticos de controle para o Http.sys por meio de um conjunto de comandos no contexto netsh http. O Netsh é uma ferramenta de linha de comando usada por muitos outros serviços de rede do Windows, como o IPsec, Roteamento e Acesso Remoto. Com esse novo suporte, é possível executar o seguinte em um prompt de comando do Windows:

Configurar ligações de certificado SSL, reservas de URL, listas de escuta de IP ou tempos limites globais

Excluir ou liberar o cache HTTP ou os buffers de log

Exibir o serviço Http.sys ou o estado do cache

Contadores de desempenho para Http.sys
O Http.sys agora tem os seguintes contadores métricos de desempenho para ajudar na monitoração, no diagnóstico e no planejamento da capacidade dos servidores Web:

Contadores de serviço HTTP

Número de URIs no cache adicionadas desde a inicialização, excluídas desde a inicialização e número de liberações do cache

Acertos do cache/segundo e Erros do cache/segundo

Grupos de URLs do serviço HTTP

Taxa de envio de dados, taxa de recebimento de dados, bytes transferidos (enviados e recebidos)

Número máximo de conexões, taxa de tentativas de conexão, taxa de solicitações GET e HEAD e número total de solicitações

Filas de solicitação de serviço HTTP

Número de solicitações na fila, tempo das solicitações mais antigas na fila

Taxa de chegadas de solicitações na fila, taxa de rejeição, número total de solicitações rejeitadas, taxa de acertos do cache

Com esses novos contadores de desempenho, as métricas podem ser visualizadas por meio do snap-in Console de Diagnóstico ou obtidas por meio da API de contadores de desempenho.

Aprimoramentos no WinINet
Os aprimoramentos na API do WinINet no Windows Server "Longhorn" e no Windows Vista incluem o seguinte:

Suporte para literais IPv6 e identificações de escopo

Suporte para descompactação HTTP

Suporte para nomes de domínio internacionalizados

Suporte para Rastreamento ETW

Suporte para IPv6 nos scripts de descoberta automática de proxy da Web

Suporte para literais IPv6 e identificações de escopo
O WinINet agora oferece suporte ao RFC 2732 e ao uso de endereços literais IPv6 em URLs. Por exemplo, para conectar-se ao servidor Web no endereço IPv6 3ffe:ffff:100:2a5f::1, um usuário com um navegador da Web baseado no WinINet (como o Internet Explorer) pode digitar http://[3ffe:ffff:100:2a5f::1] como o endereço. Embora usuários normais possam não usar endereços literais IPv6, a habilidade de especificar o endereço IPv6 na URL é útil para os desenvolvedores de aplicativos, testadores de software e solucionadores de problemas da rede. O WinINet também oferece suporte à codificação da identificação do escopo do IPv6 (também conhecida como uma identificação de zona) como parte do endereço para permitir que os usuários especifiquem o escopo de destino IPv6. Para obter mais informações, consulte IP Version 6 Support (em inglês).

Suporte para descompactação HTTP
O WinINet agora inclui suporte interno para esquemas de codificação de conteúdo gzip e deflate. O processamento da descompactação no WinINet reduz problemas de compactação/descompactação entre navegadores da Web e servidores Web e fornece ganhos de desempenho por meio de tempos reduzidos de download das páginas da Web. Isso pode ser extremamente benéfico para os usuários que possuem uma conexão de largura de banda baixa, como usuários de Internet por dial-up. Para obter mais informações, consulte Content Encoding (em inglês).

Suporte para nomes de domínio internacionalizados
O WinINet agora é compatível com o padrão (RFC 3490) de IDN (Nomes de domínio internacionalizados) para nomes de host quando você usa as versões Unicode da API do WinINet. Esse novo suporte garante que os aplicativos funcionem corretamente com nomes de domínio que contêm caracteres não-ASCII sem exigir o suporte de IDN no aplicativo Web, a instalação de um plug-in de terceiros ou nós intermediários em um caminho de comunicação da rede. Para obter mais informações, consulte IDN Support in WinINet (em inglês).

Suporte para Rastreamento ETW
O WinINet agora oferece suporte ao Rastreamento ETW que permite que a assistência técnica de TI e os especialistas de suporte obtenham informações detalhadas sobre processos e eventos do WinINet para ajudar a determinar a origem de problemas com o protocolo ou o aplicativo. Com a inclusão de identificadores para todos os eventos do WinINet, você pode construir uma cadeia de rastreamentos ETW que alcançe toda a pilha da rede, usando os identificadores para associar rastreamentos de camadas adjacentes da rede. Para obter mais informações sobre o Rastreamento ETW, consulte Event Tracing (em inglês).

Suporte para IPv6 nos scripts de descoberta automática de proxy da Web
As funções auxiliares do script WPAD (Web Proxy Auto-Discovery) expostas pelo WinINet foram atualizadas para incluir suporte a endereços IPv6 e prefixos de sub-rede. Os scripts WPAD que usam as APIs Auxiliares de Proxy dnsResolve(), myIpAddress(), isInNet() e isResolvable() agora podem obter informações do IPv6 a partir do WinINet. Para obter mais informações, consulte WinHTTP AutoProxy Support (em inglês).

Aprimoramentos no WinHTTP
As atualizações da API do WinHTTP 5.1 no Windows Server "Longhorn" e no Windows Vista incluem o seguinte:

Suporte para carregamentos de dados superiores a 4 gigabytes

Suporte para codificação de transferência em partes

Suporte para recuperação da lista de emissores para autenticação de cliente baseada no Secure Sockets Layer

Suporte para solicitações de certificado opcional do cliente

Suporte para indicação de informações de conexão de quatro tuplas

Novos códigos de erro para autenticação de cliente SSL

Suporte ao IPv6 em scripts WPAD

Suporte para carregamentos de dados superiores a 4 gigabytes
O WinHTTP agora permite que aplicativos adicionem um cabeçalho “Content-Length” para especificar um comprimento de dados de até 264 bytes.

Suporte para codificação de transferência em partes
O WinHTTP agora permite que aplicativos executem a codificação de transferência "em partes" para seus dados e envie-os usando a API WinHttpWriteData(). O WinHTTP detecta a presença de um cabeçalho “Transfer-Encoding” e faz ajustes internos para garantir que a transferência seja compatível com a especificação HTTP 1.1.

Suporte para recuperação da lista de emissores para autenticação de cliente baseada no Secure Sockets Layer
O WinHTTP agora permite que o aplicativo recupere a lista de emissores associada a um pedido de autenticação do cliente. Uma lista de emissores especifica uma lista de autoridades de certificação que estão autorizadas pelo servidor a emitir certificados de cliente. Com esse novo suporte, um aplicativo WinHTTP pode determinar o certificado correto do cliente a ser usado para a autenticação do cliente.

Suporte para solicitações de certificado opcional do cliente
Alguns sites HTTP seguros solicitam um certificado de cliente, mas não o exigem. Se o cliente não tiver um certificado de cliente para responder à solicitação, o servidor poderá usar outros tipos de autenticação HTTP ou permitir acesso anônimo. Para oferecer suporte à interoperação com essas configurações de servidor, o WinHTTP agora permite que um aplicativo forneça um certificado de cliente NULL para indicar ao servidor que ele não tem um certificado de cliente para autenticação SSL.

Suporte para indicação de informações de conexão de quatro tuplas
Na conclusão de uma API WinHttpReceiveResponse(), o WinHTTP agora permite que um aplicativo consulte o "IP/port", a porta de origem e de destino associados à solicitação HTTP que resulta na resposta.

Novos códigos de erro para autenticação de cliente SSL
O WinHTTP agora inclui códigos de erro para os seguintes erros comuns na autenticação de cliente SSL:

O certificado de cliente não tem uma chave particular associada, o que é normalmente provocado pela importação de um certificado de cliente sem a chave particular.

O thread do aplicativo que chama WinHttpSendRequest() ou WinHttpReceiveResponse() não tem o privilégio de acessar a chave particular associada ao certificado de cliente fornecido. Verifique se a ACL (lista de controle de acesso) da chave particular permite que o aplicativo a acesse.

Suporte ao IPv6 em scripts WPAD
As funções auxiliares do script WPAD expostas pelo WinHTTP foram atualizadas para incluir suporte a endereços IPv6 e prefixos de sub-rede. Os scripts WPAD que usam as APIs Auxiliares de Proxy dnsResolve(), myIpAddress(), isInNet() e isResolvable() agora podem obter informações do IPv6 a partir do WinHTTP. Para obter mais informações, consulte WinHTTP AutoProxy Support (em inglês).

Para obter informações sobre os aprimoramentos do WinHTTP no Windows Server "Longhorn" e no Windows Vista, consulte What's New in Windows Longhorn e SSL in WinHTTP (em inglês).

Aprimoramentos no Windows Sockets
O suporte ao Windows Sockets (Winsock) foi atualizado com o seguinte:

Novas APIs do Winsock

Rastreamento ETW para eventos do Winsock

Aprimoramentos no Provedor de Serviço em Camadas

Módulo Network Diagnostics Framework do Winsock

Nova API do Sockets em modo kernel

Novas APIs do Winsock
O Windows Server "Longhorn" e o Windows Vista incluem as seguintes novas APIs do Winsock:

WSAConnectByName() Cria uma conexão com o destino especificado, quando o nome do host de destino é especificado. O WSAConnectByName() usa todos os endereços de destino retornados pela resolução de nomes, todos os endereços locais e tenta conexões usando pares de endereços com maior probabilidade de êxito. Um algoritmo de emparelhamento ideal fornecido pelo transporte determina a ordem dos pares de endereços. O WSAConnectByName() garante que uma conexão será estabelecida (se possível), no menor período de tempo.

WSAConnectByList() Cria uma conexão com o destino especificado, quando uma lista de endereços IP de destino é fornecida. O WSAConnectByList usa uma lista de M endereços e de N endereços do computador local e tenta estabelecer a conexão usando até M x N combinações de endereços antes que a conexão falhe.

Rastreamento ETW para eventos do Winsock
Os eventos do Winsock a seguir são alguns dos eventos que podem ser rastreados com o rastreamento ETW:

Criação de soquete

Ligação

Conexão

Aceitação

Envio

Recebimento

Indicações de anulação

É possível habilitar o rastreamento ETW para eventos do Winsock usando o seguinte:

Snap-in Visualizar Eventos

Ferramentas Logman.exe e Tracerpt.exe

Para habilitar o Rastreamento ETW para eventos do Winsock usando o snap-in Visualizar Eventos, execute os procedimentos a seguir:

Execute a ferramenta Visualizar Eventos na pasta Ferramentas Administrativas.

Na árvore do snap-in Visualizar Eventos, abra Application Logs e, em seguida, Microsoft-Windows-Winsock-AFD.

Clique no item Winsock/AFD.

No painel Action, clique em Log Properties.

Na caixa de diálogo Log Properties, clique em Enable Logging e clique em OK.

Para exibir os eventos, no painel Action, clique em Refresh. Para desabilitar o registro em log, desmarque a caixa de seleção Enable Logging na caixa de diálogo Log Properties do item Winsock/AFD.

Pode ser necessário aumentar o tamanho do log dependendo de quantos eventos você deseja exibir.

Para habilitar o Rastreamento ETW para eventos do Winsock usando a ferramenta Logman.exe, use os seguintes comandos:

logman create trace afdlog –o LogFileLocation
logman update afdlog –p “Microsoft-Windows-Winsock-AFD”
logman start afdlog
Um arquivo de log binário será gravado no LogFileLocation. Para converter o arquivo binário gravado pela ferramenta Logman.exe em texto legível, use a ferramenta Tracerpt.exe. Por exemplo, use o seguinte comando:

tracerpt.exe c:\afdlog.etl –o afdlog.txt
Para parar o registro em log, use o seguinte comando:

logman stop afdlog
Aprimoramentos no Provedor de serviço em camadas
O suporte ao LSP (Provedor de serviço em camadas) do Winsock no Windows Server "Longhorn" e no Windows Vista foi aprimorado da seguinte forma:

A instalação e a remoção de LSPs são registradas no log de eventos do sistema para ajudar a determinar quais aplicativos estão instalando LSPs e para solucionar problemas de falhas de instalações de LSP. Para exibir os eventos registrados em uma janela do console, use o comando netsh winsock audit trail.

Há uma nova API de instalação (WSCInstallProviderAndChains) que os fornecedores de software podem usar para instalar um LSP no catálogo do Winsock. A instalação manual de um LSP pode ser feita usando uma série de funções do Winsock, mas se feita de maneira inapropriada, poderá deixar o catálogo LSP do Winsock em um estado inconsistente. O uso dessa nova API pode economizar centenas de linhas de código para um fornecedor que desenvolve um LSP.

Existem novos recursos para categorizar LSPs e remover a maioria dos LSPs do caminho de processamento para serviços críticos do sistema. Esses novos recursos fornecem mais estabilidade ao Windows, protegendo serviços críticos do sistema contra LSPs desenvolvidos de maneira inapropriada.

Existe um módulo de diagnóstico específico do Winsock para o Network Diagnostics Framework que permitirá que os usuários reparem o catálogo do Winsock de maneira seletiva removendo apenas os LSPs que estão provocando problemas.

Nova API do Sockets em modo kernel
A arquitetura de rede do Windows Server "Longhorn" e do Windows Vista inclui uma nova interface chamada WSK (Winsock Kernel), uma substituição final para a TDI (Interface do driver de transporte). O WSK facilita o desenvolvimento de transportes (drivers de protocolo) para os fornecedores de software no Windows. O WSK inclui uma nova API do Sockets em modo kernel. Para obter mais informações, consulte Windows Sockets in Kernel (em inglês).

NDIS 6.0
O Windows Server "Longhorn" e o Windows Vista incluem o NDIS (Especificação da interface do driver de rede) 6.0. O NDIS especifica uma interface padrão entre drivers de rede no modo kernel e o sistema operacional. O NDIS também especifica uma interface padrão entre drivers de rede sobreposta, abstraindo os drivers de nível inferior que gerenciam o hardware de drivers de nível superior, como transportes de rede. Para obter mais informações sobre o NDIS 6.0, consulte NDIS - Network Driver Interface Specification (em inglês).

O NDIS 6.0 inclui os seguintes recursos:

Novo suporte a descarregamento

Suporte a drivers de filtro simples

Receive-Side Scaling

Novo suporte a descarregamento
O NDIS 6.0 inclui o novo suporte a seguir para o descarregamento de funções de processamento de tráfego da rede para adaptadores de rede:

Descarregamento de tráfego IPv6 O NDIS 5.1 no Windows Server 2003 e no Windows XP já oferece suporte ao descarregamento do processamento de tráfego IPv4. O NDIS 6.0 agora oferece suporte ao descarregamento do processamento de tráfego IPv6.

O descarregamento da soma de verificação oferece suporte ao IPv6 O descarregamento de cálculos de soma de verificação do tráfego IPv6 agora tem suporte.

Giant Send Offload O NDIS 5.1 agora oferece suporte ao LSO (Large Segment Offload) que descarrega a segmentação de dados TCP para blocos de dados de até 64 KB. O GSO (Giant Send Offload) no NDIS 6.0 pode descarregar a segmentação de dados TCP para blocos de dados maiores do que 64 KB.

Suporte a drivers de filtro simples
No NDIS 6.0, drivers de filtros intermediários foram substituídos por drivers LWF (de filtro simples), que são uma combinação de um driver intermediário de NDIS e um driver de miniporta. Os drivers LWF têm as seguintes vantagens:

Não há mais necessidade de escrever um protocolo e uma miniporta separados. Todas essas funções estão contidas em um único driver.

Os drivers LWF podem ser adicionados ou removidos da pilha sem interromper as conexões existentes.

Desempenho aprimorado.

O modo Ignorar permite que o driver LWF examine apenas caminhos de controle e de dados selecionados.

Um exemplo de um driver de filtro intermediário que foi convertido em um driver LWF é o Pacer.sys, anteriormente conhecido como Psched.sys. Ele tem a mesma funcionalidade, mas se beneficia dos aprimoramentos de desempenho disponíveis com o NDIS 6.0. Para obter mais informações, incluindo exemplos, consulte o Windows Driver Kit (em inglês).

Receive-Side Scaling
Na arquitetura para computadores multiprocessador que executam o Windows Server 2003 ou o Windows XP, um adaptador de rede está associado a um único processador. O processador único deve tratar de todo o tráfego recebido pelo adaptador da rede, quer existam outros processadores disponíveis ou não. O resultado dessa arquitetura para servidores de alto volume, como servidores Web voltados para a Internet ou servidores de arquivos empresariais, é que a quantidade de tráfego de entrada e o número de conexões que podem ser atendidas pelo processador associado ao adaptador da rede são limitados. Se o processador associado ao adaptador da rede não puder tratar do tráfego de entrada com rapidez suficiente, o adaptador da rede descartará o tráfego, resultando em retransmissões e desempenho reduzidos.

No Windows Server "Longhorn" e no Windows Vista, um adaptador de rede não está associado a um único processador. Em vez disso, o processamento do tráfego de entrada é distribuído entre os processadores no computador. Esse novo recurso, conhecido como RSS (Receive-Side Scaling), permite que muito mais tráfego seja recebido por um adaptador de rede em um servidor de alto volume. Um computador multiprocessador agora pode lidar com mais tráfego de entrada sem precisar adicionar servidores, resultando em custos mais baixos. Para tirar proveito desse recurso, você deve instalar adaptadores de rede compatíveis com o RSS que podem tirar proveito da nova arquitetura no Windows Server "Longhorn" e no Windows Vista. Os adaptadores de rede compatíveis com RSS são disponibilizados por muitos fornecedores de adaptador de rede.

Para obter mais informações, consulte Scalable Networking with RSS (em inglês).

Aprimoramentos no Windows Peer-to-Peer Networking
O Windows Peer-to-Peer Networking, originalmente lançado no Advanced Networking Pack para Windows XP, é uma plataforma e API do sistema operacional no Windows Vista que permite o desenvolvimento de aplicativos P2P (ponto a ponto). O Windows Vista inclui os seguintes aprimoramentos no Windows Peer-to-Peer Networking:

API nova e fácil de usar As APIs para acesso a recursos do Windows Peer-to-Peer Networking, como resolução de nomes, criação de grupos e segurança, foram bastante simplificadas no Windows Vista, facilitando a criação de aplicativos P2P para Windows.

Nova versão do PNRP O Windows Vista inclui uma nova versão do PNRP que é mais escalável e usa menos largura de banda da rede. Para o PNRP v2 no Windows Vista, os aplicativos do Windows Peer-to-Peer Networking podem acessar funções de publicação e de resolução de nomes por meio de uma API PNRP simplificada. Para proporcionar uma resolução de nomes PNRP simplificada no Windows Vista, os nomes PNRP agora estão integrados à função getaddrinfo() do Windows Sockets. Para usar o PNRP para solucionar um nome para um endereço IPv6, os aplicativos podem usar a função getaddrinfo() para solucionar o FDQN (Nome de domínio totalmente qualificado) nome.prnp.net, no qual nome é o nome do ponto de mesmo nível que está sendo solucionado. O domínio pnrp.net é um domínio reservado no Windows Vista para a resolução de nomes PNRP. O protocolo PNRP v2 é incompatível com o protocolo PNRP usado por computadores que executam o Windows XP. A Microsoft está investigando o desenvolvimento e o lançamento de uma atualização dos componentes do Windows Peer-to-Peer Networking no Windows XP para oferecer suporte ao PNRP v2.

Pessoas ao meu Redor Um novo recurso do Windows Peer-to-Peer Networking para Windows Vista que permite que os usuários descubram dinamicamente outros usuários na sub-rede local, seus aplicativos compatíveis com o recurso Pessoas ao meu Redor e convidem facilmente outros usuários para uma atividade de colaboração. O convite e sua aceitação iniciam um aplicativo no computador do usuário convidado e os dois aplicativos podem começar a participar de uma atividade de colaboração, como bate-papo, compartilhamento de fotos ou jogos.

Aplicativo de reunião baseado em P2P O Windows Vista inclui um novo aplicativo de reunião ad hoc baseado em P2P que usa a funcionalidade do Windows Peer-to-Peer Networking.

Firewall do Windows
O novo Firewall do Windows no Windows Server "Longhorn" e no Windows Vista conta com os seguintes aprimoramentos no Firewall do Windows atual no Windows XP com Service Pack 2 e no Windows Server 2003 com Service Pack 1:

Oferece suporte para tráfego de entrada e de saída

Um administrador de rede pode configurar o novo Firewall do Windows com um conjunto de exceções para bloquear todo o tráfego enviado para portas específicas, como as conhecidas portas usadas por programas antivírus, ou para endereços específicos que contêm conteúdo confidencial ou indesejado.

Novo snap-in do MMC (Console de Gerenciamento Microsoft) Firewall do Windows com Segurança Avançada para a configuração da GUI (interface gráfica do usuário)

O novo snap-in Firewall do Windows com Segurança Avançada fornece assistentes para configurar exceções e regras de segurança. Para a configuração de linha de comando das configurações avançadas do novo Firewall do Windows, você pode usar comandos no contexto netsh advfirewall.

As configurações de filtragem de firewall e proteção de IPsec são integradas

Ao usar o snap-in Firewall do Windows com Segurança Avançada, é possível configurar a filtragem do firewall e as regras de tráfego protegido.

Configuração avançada de exceções

Exceções de filtragem de firewall podem ser configuradas para endereços IP de origem e destino, número de IP, portas de protocolos TCP e UDP de origem e de destino, todas as portas ou várias portas TCP ou UDP, tipos específicos de interfaces, tráfego de ICMP e de ICMP para IPv6 (ICMPv6) por Tipo e Código e também para serviços.

Para obter mais informações sobre esses aprimoramentos, consulte O Novo Firewall do Windows no Windows Vista e do Windows Server "Longhorn".

Aprimoramentos no IPsec
O Windows Server "Longhorn" e o Windows Vista incluem os seguintes aprimoramentos para o protocolo IPsec:

Configuração integrada de firewall e IPsec

Configuração simplificada da diretiva IPsec

Proteção de IPsec de cliente para controlador de domínio

Suporte aprimorado ao balanceamento de carga e servidor de cluster

Autenticação IPsec aprimorada

Novo suporte à criptografia

Integração com a Proteção de Acesso a Rede

Opções adicionais de configuração para comunicação protegida

Suporte integrado a IPv4 e IPv6

Eventos estendidos e contadores do monitor de desempenho

Suporte ao Network Diagnostics Framework

Configuração integrada de firewall e IPsec
No Windows Server 2003 e no Windows XP, o Firewall do Windows e o IPsec eram componentes e serviços que precisavam ser configurados separadamente. Embora o objetivo do Firewall do Windows fosse bloquear ou permitir tráfego de entrada, o IPsec também podia ser configurado para bloquear ou permitir tráfego de entrada. Como o comportamento de bloqueio e permissão de tráfego de entrada podia ser configurado por meio de dois serviços diferentes e separados, era possível ter configurações duplicadas e contraditórias. Além disso, o Firewall do Windows e o IPsec suportavam diferentes opções de configuração para especificar o tráfego de entrada permitido. Por exemplo, o Firewall do Windows permitia exceções (permitia tráfego de entrada) especificando o nome do aplicativo, mas o IPsec não. O IPsec permitia exceções baseado em um número de protocolo IP e o Firewall do Windows não.

No Windows Server "Longhorn" e no Windows Vista, o Firewall do Windows e o IPsec foram combinados em uma única ferramenta configurável com o novo snap-in Firewall do Windows com Segurança Avançada, que agora controla as responsabilidades do firewall tradicional (bloqueando e permitindo tráfego de entrada e de saída) e protegendo o tráfego com o IPsec. Além disso, os comandos no contexto netsh advfirewall podem ser usados para a configuração da linha de comando do comportamento do firewall e do IPsec. A integração do Firewall do Windows com o IPsec fornece aos computadores que executam o Windows Server "Longhorn" ou o Windows Vista um firewall de autenticação.

Configuração simplificada da diretiva IPsec
No Windows Server 2003 e no Windows XP, a configuração da diretiva IPsec em muitos cenários, como no isolamento de servidores e de domínio, consiste em um conjunto de regras para proteger a maior parte do tráfego na rede e outro conjunto de regras para exceções de tráfego protegido. As exceções são necessárias para a comunicação não protegida com servidores de infra-estrutura de rede, como servidores DHCP e DNS e controladores de domínio. Quando um computador está sendo iniciado, ele deve ser capaz de obter um endereço IP, de usar o DNS para localizar um controlador de domínio e, em seguida, fazer logon em seu domínio antes de poder começar a usar a autenticação Kerberos para autenticar-se como um ponto IPsec. Outras exceções são necessárias para a comunicação com nós da rede que não são compatíveis com IPsec. Em alguns casos, há dezenas ou centenas de exceções, o que dificulta a implantação da proteção de IPsec em uma rede privada e a manutenção dela ao longo do tempo.

O IPsec no Windows Server "Longhorn" e no Windows Vista fornece um comportamento opcional ao negociar a proteção de IPsec. Se habilitado, ao iniciar a comunicação com outro nó da rede, um nó IPsec que executa o Windows Server "Longhorn" ou o Windows Vista tentará comunicar-se de modo transparente e negociar a comunicação protegida em paralelo. Se o ponto IPsec de início não receber uma resposta à tentativa de negociação inicial, a comunicação continuará transparentemente. Se o ponto IPsec de início receber uma resposta, a comunicação em modo transparente será paralisada até que a negociação possa ser concluída.

Com esse comportamento opcional e a configuração recomendada para exigir proteção para comunicações de entrada iniciadas e solicitar proteção para comunicações de saída iniciadas, o nó de início descobre se o nó com o qual está se comunicando pode usar IPsec e se comporta da maneira apropriada, simplificando significativamente a configuração da diretiva IPsec. Por exemplo, o nó de início não precisa de um conjunto de filtros IPsec predefinidos para tratar das exceções do conjunto de hosts que não devem ou não podem proteger o tráfego de rede com o IPsec. O nó de início tenta estabelecer a comunicação protegida e a não protegida em paralelo e, se a comunicação protegida não for possível, a comunicação não protegida será usada.

Esse novo comportamento de negociação também melhora o desempenho de conexões não protegidas com hosts. Um nó IPsec que executa o Windows Server 2003 ou o Windows XP e que está configurado para solicitar comunicações protegidas, mas permite comunicações não protegidas — um comportamento conhecido como fallback para comunicação sem criptografia — enviaria as mensagens de negociação e, em seguida, esperaria por uma resposta. O nó de início aguardaria por três segundos antes de fazer o fallback para comunicação sem criptografia e tentar comunicações não protegidas. Com o Windows Server "Longhorn" e o Windows Vista, não há mais um atraso de três segundos ao fazer o fallback para comunicação sem criptografia, porque as comunicações de modo transparente já estão em andamento enquanto o nó de início está aguardando uma resposta.

Proteção de IPsec de cliente para controlador de domínio
No Windows Server 2003 e no Windows XP, a recomendação atual da Microsoft é não usar a proteção de IPsec para proteger o tráfego entre controladores de domínio e computadores membro (no entanto, a Microsoft recomenda proteger o tráfego entre controladores de domínio). Isso porque a configuração da diretiva IPsec pode se tornar muito complexa devido aos diferentes tipos de tráfego enviado entre membros de domínio e controladores de domínio. Além disso, existe um problema de inicialização de ingresso no domínio. Se o controlador de domínio exigir tráfego protegido por IPsec de computadores que devem fornecer credenciais baseadas no domínio para autenticação, um computador que não seja um membro do domínio não poderá entrar em contato com um controlador de domínio para ingressar no domínio.

O Windows Server "Longhorn" e o Windows Vista oferecem suporte à proteção de tráfego entre os membros do domínio e controladores de domínio nos seguintes modos de implantação:

Devido ao novo comportamento de negociação, não é mais necessário configurar isenções para controladores de domínio, o que simplifica a diretiva IPsec e a implantação da proteção de IPsec em um domínio.

É possível configurar a diretiva IPsec no domínio para solicitar tráfego protegido, mas sem que isso seja uma exigência.

Controladores de domínio protegerão a maior parte do tráfego com membros do domínio, mas permitirão ingressos de texto não criptografado no domínio e outros tipos de tráfego.

É possível configurar a diretiva IPsec para exigir tráfego protegido para controladores de domínio.

Quando um computador que executa o Windows Longhorn "Server" ou o Windows Vista tenta ingressar no domínio, o nome do usuário e a senha de uma conta de usuário do domínio são solicitados. O IPsec com o controlador de domínio é negociado com as credenciais do usuário do NTLM v2 (NT/LAN Manager versão 2) do Windows para ingressar em um domínio protegido. Esse novo comportamento está disponível apenas para computadores membros do domínio que executam o Windows Vista ou o Windows Server "Longhorn" e para controladores de domínio que executam o Windows Server "Longhorn."

Suporte aprimorado ao balanceamento de carga e servidor de cluster
O IPsec no Windows Server 2003 oferece suporte ao balanceamento de carga e a servidores de cluster. No entanto, os tempos de failover para restabelecer a conectividade IPsec com um endereço IP virtual de cluster são os seguintes:

Normalmente, de 3 a 6 segundos para mudanças administrativas de recursos agrupados em cluster.

Até dois minutos quando um nó do cluster se torna indisponível repentinamente ou quando ocorre outra perda repentina de conectividade. O tempo limite de dois minutos inclui um minuto para que o tempo ocioso do IPsec expire e um minuto para renegociar as associações de segurança. Esse tempo ocioso prolongado pode fazer com que ocorram falhas em conexões TCP ativas com o cluster.

No Windows Server “Longhorn” e no Windows Vista, o tempo limite de uma falha no nó do cluster é substancialmente reduzido. O IPsec no Windows Server “Longhorn” e no Windows Vista está mais fortemente integrado com a Next Generation TCP/IP Stack. Em vez de contar com os tempos limites de ociosidade do IPsec para detectar uma falha do nó do cluster, o IPsec no Windows Server “Longhorn” e no Windows Vista monitora conexões TCP para associações de segurança estabelecidas. Se a conexão TCP de uma associação de segurança estabelecida começar a retransmitir segmentos, o IPsec renegociará as associações de segurança. O resultado é que o failover para um novo nó de cluster ocorre rapidamente, normalmente em tempo para evitar que ocorram falhas no aplicativo.

Autenticação IPsec aprimorada
O IPsec no Windows Server 2003 e no Windows XP oferece suporte ao protocolo IKE e a três métodos de autenticação durante negociações no modo principal: Kerberos (para membros de domínio do Active Directory), certificados digitais e chave pré-compartilhada. Para todos esses métodos de autenticação, o processo de autenticação valida a identidade e a confiabilidade de um computador, em vez do usuário do computador. O IKE tenta uma única autenticação usando um único método de autenticação.

O Windows Server "Longhorn" e o Windows Vista oferecem suporte aos seguintes recursos para autenticação IPsec:

Habilidade de exigir que os pontos IPsec sejam autenticados com um certificado de integridade

Um servidor de certificado de integridade emite um certificado de integridade quando um cliente de Proteção de Acesso a Rede comprova que seu estado de integridade é compatível com a diretiva de integridade atual. Para obter mais informações sobre a plataforma de Proteção de Acesso a Rede, consulte "Proteção de Acesso a Rede" neste artigo.

Habilidade para especificar a autenticação baseada no usuário ou na integridade durante o modo estendido

O IPsec no Windows Server "Longhorn" e no Windows Vista define um novo modo de negociação conhecido como modo estendido. No modo estendido, o IPsec no Windows Server "Longhorn" e no Windows Vista pode executar um nível adicional de autenticação. As credenciais usadas durante a autenticação no modo estendido podem ser baseadas no seguinte:

Credenciais do Kerberos da conta do usuário conectado

Credenciais do NTLM v2 da conta do usuário conectado

Um certificado de usuário

Um certificado de integridade do computador

A autenticação em modo estendido pode ser feita com ou sem a autenticação em modo principal. Por exemplo, você pode usar a autenticação em modo principal e as credenciais do Kerberos para autenticar o computador e, em seguida, a autenticação em modo estendido e um certificado de integridade para validar o estado de integridade do computador.

Vários métodos de autenticação são tentados

No Windows Server 2003 e no Windows XP, é possível selecionar vários métodos de autenticação em uma ordem preferencial para a autenticação IPsec em modo principal. No entanto, apenas um método de autenticação é usado para autenticação. Se o processo de autenticação para o método de autenticação negociado falhar, o modo principal falhará e a proteção de IPsec não poderá ser executada. Quando você seleciona vários métodos de autenticação em computadores que executam o Windows Server "Longhorn" ou o Windows Vista, o IPsec fará várias tentativas de autenticação como um esforço para executar a autenticação mútua. Por exemplo, se você especificar que deseja fazer a autenticação usando o Kerberos e certificados de computador com uma autoridade de certificação específica (nessa ordem), o ponto IPsec poderá não ter êxito na autenticação do Kerberos e, em seguida, tentar fazer a autenticação de certificado.

Novo suporte à criptografia
Em resposta a requisitos de segurança governamentais e a tendências do mercado de segurança para oferecer suporte mais amplo à criptografia, o Windows Server “Longhorn” e o Windows Vista oferecem suporte a algoritmos adicionais de derivação de chaves e criptografia.

O Windows Server "Longhorn" e o Windows Vista dão suporte aos seguintes algoritmos adicionais para negociar o material de chave mestra derivado durante a negociação em modo principal:

Diffie-Hellman (DH) Grupo 19, que é um algoritmo de curva elíptica que usa um grupo de curva aleatória de 256 bits (identificador NIST P-256)

DH Grupo 20, que é um algoritmo de curva elíptica que usa um grupo de curva aleatória de 384 bits (identificador NIST P-384)

Esses métodos são mais fortes do que os algoritmos Diffie-Hellman (DH)-768, DH-1024 e DH-2048 com suporte no Windows Server 2003 e no Windows XP com Service Pack 2 e incluídos no Windows Server "Longhorn" e Windows Vista. Para obter mais informações sobre esses algoritmos, consulte o rascunho da Internet intitulado “ECP Groups For IKE and IKEv2” (em inglês). Esses novos algoritmos DH não podem ser usados para a negociação em modo principal com um computador que esteja executando o Windows Server 2003, o Windows XP ou o Windows 2000.

Além do DES (padrão de criptografia de dados) e do 3DES (DES triplo), o Windows Server "Longhorn" e o Windows Vista oferecem suporte aos seguintes algoritmos adicionais para criptografia de dados:

AES (padrão avançado de criptografia) com CBC (encadeamento de bloco codificado) e uma chave de 128 bits (AES 128)

AES com CBC e uma chave de 192 bits (AES 192)

AES com CBC e uma chave de 256 bits (AES 256)

Esses novos algoritmos de criptografia não podem ser usados para uma associação de segurança com um computador que esteja executando o Windows Server 2003, o Windows XP ou o Windows 2000.

Integração com a Proteção de Acesso a Rede
Com a nova Proteção de Acesso a Rede, é possível exigir que nós IPsec se autentiquem durante a negociação em modo estendido com um certificado de integridade, certificando que o nó IPsec atende aos requisitos de integridade do sistema atual. Um servidor de certificado de integridade emite um certificado de integridade depois que o status da integridade de um ponto IPsec foi avaliado por um NPS (Servidor de Diretivas de Rede). Para obter mais informações, consulte “Proteção de Acesso a Rede” neste artigo.

Opções adicionais de configuração para comunicação protegida
Quando a diretiva IPsec é configurada com o novo snap-in Firewal do Windows com Segurança Avançada, é possível configurar a comunicação protegida com as novas configurações a seguir:

Por nome de aplicativo Isso simplifica significativamente a configuração do tráfego protegido, porque as portas usadas pelo aplicativo não precisam ser configuradas manualmente.

Todas ou várias portas Agora, é possível especificar todas as portas ou várias portas TCP ou UDP em uma lista delimitada por vírgula, simplificando a configuração.

Para todos os endereços em um intervalo numérico Agora, é possível especificar um intervalo de endereços IP usando um intervalo numérico, como 10.1.17.23 a 10.1.17.219.

Para todos os endereços na sub-rede local Um conjunto de endereços predefinidos que são mapeados dinamicamente para o conjunto de endereços definido por seu endereço IPv4 e pela máscara de sub-rede, ou por seu prefixo de sub-rede local IPv6.

Para todos os adaptadores sem fio É possível proteger o tráfego com base no tipo da interface, que agora inclui acesso sem fio além da LAN e do acesso remoto.

Por conta de usuário ou computador do Active Directory É possível especificar a lista de computadores ou usar contas ou grupos que estejam autorizados a iniciar a comunicação protegida. Por exemplo, isso permite especificar que o tráfego para servidores específicos com dados confidenciais seja protegido e possa originar-se apenas de contas de usuário específicas que façam parte de determinados grupos de segurança do Active Directory.

Por valor de tipo ou código de ICMP ou ICMPv6 É possível especificar mensagens ICMP ou ICMPv6 definindo os valores dos campos Type e Code de mensagens ICMP ou ICMPv6.

Para serviços É possível especificar que a exceção se aplica a qualquer processo, apenas a serviços ou a um serviço específico pelo nome do serviço. Você pode ainda digitar o nome abreviado do serviço.

Suporte integrado a IPv4 e IPv6
O suporte a IPsec para o tráfego IPv6 no Windows XP e no Windows Server 2003 é limitado. Não existe suporte para IKE ou criptografia de dados. As diretivas de segurança IPsec, associações de segurança e chaves devem ser configuradas por meio de arquivos de texto e ativadas por meio de uma ferramenta de linha de comando, o IPsec6.exe.

No Windows Server "Longhorn" e no Windows Vista, o suporte a IPsec para tráfego IPv6 é o mesmo que para IPv4, incluindo o suporte a IKE e criptografia de dados. As configurações de diretivas para tráfego IPv4 e IPv6 são configuradas da mesma maneira, usando os snap-ins Firewall do Windows com Segurança Avançada ou Diretivas de Segurança IP.

Eventos estendidos e contadores do monitor de desempenho
O Windows Server "Longhorn" e o Windows Vista incluem 15 novos eventos específicos de auditoria do IPsec, e o texto de 25 eventos existentes foi atualizado com informações mais úteis. Esses aprimoramentos ajudarão a solucionar problemas de falhas em negociações do IPsec, sem que seja necessário habilitar o recurso avançado de registro em log Oakley.

O Windows Server "Longhorn" e o Windows Vista também incluem contadores de desempenho IPsec para ajudar a identificar problemas de desempenho e de rede com tráfego IPsec protegido.

Suporte ao Network Diagnostics Framework
O Network Diagnostics Framework é uma arquitetura extensível que ajuda os usuários a recuperar e a solucionar problemas com conexões de rede. Para uma falha na negociação do IPsec, o Network Diagnostics Framework fornecerá um prompt ao usuário com uma opção para identificar e corrigir o problema. Em seguida, o suporte do IPsec ao Network Diagnostics Framework tenta descobrir a origem da conexão com falha e corrige o problema automaticamente ou, dependendo das considerações de segurança, solicita ao usuário a alteração apropriada na configuração.

Conexões sem fio e com fio baseadas no 802.1X
O Windows Server "Longhorn" e o Windows Vista incluem muitos aprimoramentos para oferecer suporte a redes sem fio IEEE 802.11 e redes que usam comutadores de autenticação.

Alterações e aprimoramentos na conexão sem fio IEEE 802.11
O Windows Server "Longhorn" e o Windows Vista incluem as seguintes alterações e aprimoramentos na conexão sem fio IEEE 802.11:

Arquitetura Wi-Fi nativa

Aprimoramentos na interface do usuário para conexões sem fio

Aprimoramentos na Diretiva de Grupo sem fio

Alterações na Configuração Automática sem Fio

Suporte a WPA2

Logon único

Integração com a Proteção de Acesso a Rede ao usar a autenticação 802.1X

Infra-estrutura de EAPHost

Diagnósticos da conexão sem fio 802.11

Suporte à linha de comando para definir configurações sem fio

Reconhecimento de locais de rede e perfis de rede

Aprimoramentos na Next Generation TCP/IP Stack para ambientes sem fio

Arquitetura Wi-Fi nativa
No Windows Server 2003 e no Windows XP, a infra-estrutura do software que oferece suporte a conexões sem fio foi construída para emular uma conexão Ethernet e pode ser estendida apenas oferecendo suporte adicional a tipos EAP para autenticação IEEE 802.1X. No Windows Server "Longhorn" e no Windows Vista, a infra-estrutura de software para conexões sem fio 802.11, denominada Arquitetura Wi-Fi nativa, foi reprojetada para oferecer o seguinte:

O IEEE 802.11 agora é representado dentro do Windows como um tipo de mídia separada do IEEE 802.3. Isso permite mais flexibilidade a IHVs para oferecer suporte a recursos avançados de redes IEEE 802.11, como um tamanho de quadro maior do que o Ethernet.

Novos componentes na Arquitetura Wi-Fi nativa executam autenticação, autorização e gerenciamento de conexões 802.11, reduzindo a carga nos IHVs para incorporar essas funções em seus drivers de adaptador de rede sem fio. Isso torna o desenvolvimento de drivers de adaptadores de rede sem fio muito mais fácil. No Windows Server "Longhorn" e no Windows Vista, os IHVs devem desenvolver um driver de miniporta NDIS 6.0 menor que expõe uma interface 802.11 nativa em sua borda superior.

A Arquitetura Wi-Fi nativa oferece suporte a APIs para permitir que ISVs e IHVs possam estender o cliente sem fio interno para serviços sem fio adicionais e recursos personalizados. Componentes extensíveis escritos por ISVs e IHVs também podem fornecer caixas de diálogo e assistentes de configuração personalizados.

Aprimoramentos na interface do usuário para conexões sem fio
A interface do usuário da configuração sem fio foi aprimorada com o seguinte:

Interface do usuário extensível para conexão sem fio Conforme descrito na seção “Arquitetura Wi-Fi nativa” deste artigo, as caixas de diálogo ou os assistentes de configuração sem fio podem ser escritos e adicionados ao cliente sem fio interno do Windows, permitindo a configuração de recursos sem fio personalizados por ISVs e IHVs.

Redes sem fio ocultas podem ser marcadas Uma rede sem fio oculta não anuncia seu nome de rede, também conhecido como seu SSID (identificador do conjunto de serviços). Um ponto de acesso sem fio de uma rede sem fio oculta pode ser configurado para não enviar ou para enviar quadros de beacon com um SSID configurado como NULL. Essa prática é conhecida como uso de SSIDs de não-difusão. No Windows Server 2003 e no Windows XP, você não podia marcar uma rede sem fio preferencial como oculta, o que algumas vezes gerava um comportamento confuso ao estabelecer uma conexão automática com redes sem fio, sendo que algumas estavam ocultas e outras não. No Windows Server “Longhorn” e no Windows Vista, é possível indicar que uma rede sem fio preferencial está oculta configurando-a como uma rede de não-difusão.

É exibido um prompt para o usuário antes de se conectar a uma rede sem fio não segura Devido aos riscos associados à comunicação em redes sem fio não protegidas, o Windows Server “Longhorn” e o Windows Vista agora exibem um prompt para o usuário ao estabelecer uma conexão com uma rede sem fio não segura e permitem que o usuário confirme a tentativa de conexão.

O assistente de configuração adota como padrão a segurança mais alta com suporte no adaptador de rede sem fio O Assistente de Configuração de Rede Sem Fio no Windows Server “Longhorn” e no Windows Vista recupera os recursos de segurança do adaptador de rede sem fio e recomenda o uso da segurança mais forte com suporte do adaptador de rede sem fio. Por exemplo, se um adaptador de rede sem fio oferecer suporte ao WEP (Wired Equivalent Privacy) e ao WPA (Wi-Fi Protected Access), o Assistente de Configuração de Rede Sem Fio assumirá como padrão as configurações de WPA.

Aprimoramentos na Diretiva de Grupo sem fio
No Windows Server "Longhorn" e no Windows Vista, as configurações da Diretiva de Grupo sem fio, localizadas no nó Configuração do Computador/Configurações do Windows/Configurações de Segurança no snap-in Diretiva de Grupo, incluem os seguintes aprimoramentos:

Opções de autenticação WPA2 O Windows XP com a atualização do WPA2 (Wi-Fi Protected Access 2)/WPS IE (Wireless Provisioning Services Information Element) para Windows XP com Service Pack 2 oferece suporte às configurações de autenticação WPA2: WPA2 (para WPA2 Enterprise) e WPA2-PSK (para WPA2 Personal). No entanto, as Diretivas de Rede sem fio (IEEE 802.11) no Windows Server 2003 com Service Pack 1 não oferecem suporte à configuração centralizada de opções de autenticação WPA2. As configurações da Diretiva de Grupo sem fio no Windows Server “Longhorn” permitem a configuração de opções de autenticação WPA2. A Microsoft está estudando o suporte a opções de autenticação WPA2 em configurações de Diretiva de Grupo sem fio em uma atualização futura do Windows Server 2003.

Listas de nomes de redes sem fio autorizadas e negadas O cliente sem fio do Windows Server 2003 e do Windows XP solicitará ao usuário para estabelecer conexão a redes sem fio detectadas se nenhuma das redes sem fio preferenciais for localizada ou se nenhuma das conexões a redes sem fio preferenciais detectadas forem bem-sucedidas. Os computadores cliente sem fio que executam o Windows Server 2003 ou o Windows XP não puderam ser configurados para solicitar ao usuário para conectar-se apenas a redes sem fio específicas ou para nunca solicitar ao usuário para conectar-se a redes sem fio específicas. As configurações da Diretiva de Grupo sem fio no Windows Server "Longhorn" e no Windows Vista permitem configurar listas de nomes de redes sem fio autorizados e negados. Com uma lista de permissões, é possível especificar o conjunto de redes sem fio por nome (SSID) para os quais o cliente sem fio do Windows Server "Longhorn" ou do Windows Vista têm permissão para estabelecer uma conexão. Isso é útil para administradores de rede que querem que um computador laptop da organização seja conectado a um conjunto específico de redes sem fio, que pode incluir a rede sem fio da organização e provedores de serviços de Internet. Com uma lista de negações, é possível especificar o conjunto de redes sem fio, para as quais o cliente sem fio não tem permissão para se conectar, por nome. Isso é útil para evitar que computadores laptop gerenciados se conectem a outras redes sem fio que estejam dentro do alcance da rede sem fio da organização (como quando uma organização ocupa um andar de um edifício e há outras redes sem fio de outras organizações nos andares vizinhos) ou para evitar que computadores laptop gerenciados se conectem a outras redes sem fio não protegidas.

Configurações adicionais de redes sem fio preferenciais As configurações da Diretiva de Grupo sem fio no Windows Server “Longhorn” permitem as definições a seguir para redes sem fio preferenciais:

Configurações de roaming rápido O roaming rápido é um recurso avançado de redes sem fio WPA2 que permite que clientes sem fio passem mais rapidamente de um AP sem fio para outro usando a pré-autenticação e o cache PMK. Na atualização do WPA2 (Wi-Fi Protected Access 2)/WPS IE (Wireless Provisioning Services Information Element) para Windows XP com Service Pack 2, é possível controlar o comportamento da pré-autenticação e do cache PMK por meio de configurações do Registro. Com o Windows Server “Longhorn”, é possível configurar esse comportamento pelas configurações da Diretiva de Grupo sem fio.

Redes sem fio ocultas Conforme descrito na seção “Aprimoramentos na interface do usuário para conexões sem fio” deste artigo, é possível configurar localmente as redes sem fio preferenciais como redes sem fio ocultas. Com o Windows Server “Longhorn”, agora é possível configurar redes sem fio preferenciais nas configurações da Diretiva de Grupo como redes ocultas.

Conexão automática ou manual Com o Windows XP Service Pack 2, o Windows Server 2003 Service Pack 1, o Windows Server “Longhorn” e o Windows Vista, é possível configurar uma rede sem fio preferencial para conexão automática (padrão) ou manual na guia Conexão das propriedades da rede sem fio preferencial. Com as configurações da Diretiva de Grupo sem fio no Windows Server “Longhorn”, agora é possível configurar redes sem fio preferenciais para conexão automática ou manual.

Alterações na Configuração Automática sem Fio
A Configuração Automática sem Fio é um serviço que seleciona dinamicamente a rede sem fio à qual o computador será conectado automaticamente, baseado nas suas preferências ou nas configurações padrão. Isso inclui a seleção automática e a conexão a uma rede sem fio mais preferencial quando ela se torna disponível. O Windows Server "Longhorn" e o Windows Vista incluem as seguintes alterações na Configuração Automática sem Fio:

Alteração no comportamento quando não há redes sem fio preferenciais disponíveis No Windows XP e no Windows Server 2003, se uma rede sem fio preferencial não puder ser conectada e a rede sem fio estiver configurada para evitar a conexão automática a redes sem fio que não estão na lista de preferências (padrão), a Configuração Automática sem Fio criará um nome de rede sem fio aleatório e colocará o adaptador da rede sem fio em modo de infra-estrutura. Depois disso, o adaptador sem fio não será conectado a nenhuma rede sem fio, mas continuará a procurar por redes sem fio preferenciais a cada 60 segundos. No Windows Server "Longhorn" e no Windows Vista, a Configuração Automática sem Fio estaciona o adaptador de rede sem fio enquanto continua a procurar periodicamente por redes preferenciais, evitando uma conexão sem fio com uma rede sem fio que corresponda ao nome da rede sem fio aleatória.

Novo suporte para redes sem fio ocultas No Windows XP e no Windows Server 2003, a Configuração Automática sem Fio tenta fazer a correspondência entre as redes sem fio preferenciais configuradas e as redes sem fio que estão difundindo seu nome de rede. Se nenhuma das redes disponíveis corresponder a uma rede sem fio preferencial, a Configuração Automática sem Fio enviará solicitações de sondagem para determinar se as redes preferenciais na lista ordenada estão ocultas. O resultado desse comportamento é que as redes de difusão serão conectadas antes das redes ocultas, mesmo que uma rede oculta esteja mais alta na lista de preferências do que uma rede de difusão. Outro resultado é que um cliente sem fio com o Windows XP ou o Windows Server 2003 anuncia sua lista de redes sem fio preferenciais ao enviar solicitações de sondagem.

No Windows Server "Longhorn" e no Windows Vista, é possível configurar redes sem fio como difusão (o nome da rede sem fio é incluído nos quadros de beacon enviados pelo AP sem fio) ou não-difusão (o nome da rede sem fio é oculto porque o AP sem fio não envia um quadro de beacon ou os quadros de beacon contêm um nome de rede configurado como NULL). Quando as redes ocultas são colocadas na lista de redes sem fio preferenciais, a ordem de tentativas de conexão a redes sem fio preferenciais é mantida e um cliente sem fio do Windows Server "Longhorn" ou do Windows Vista não anuncia mais sua lista de redes sem fio preferenciais.

Suporte a WPA2
O Windows Server "Longhorn" e o Windows Vista incluem suporte interno para configurar opções de autenticação WPA2 com o perfil padrão (redes sem fio preferenciais configuradas localmente) e o perfil do domínio com configurações da Diretiva de Grupo. O WPA2 é uma certificação de produto disponível por meio da Wi-Fi Alliance que certifica equipamentos sem fio como compatíveis com o padrão IEEE 802.11i. O WPA2 no Windows Server "Longhorn" e no Windows Vista oferece suporte aos modos de operação Enterprise (autenticação IEEE 802.1X) e Personal (autenticação de chave pré-compartilhada).

O Windows Server "Longhorn" e o Windows Vista também incluem suporte a WPA2 para uma rede sem fio em modo ad hoc (uma rede sem fio entre clientes sem fio que não usa um ponto de acesso sem fio).

Logon único
A implantação de tecnologias sem fio seguras promoveu o uso da autenticação de redes de Camada 2, como o 802.1X, para garantir que apenas um usuário ou dispositivo apropriado tenha permissão na rede protegida e que seus dados sejam protegidos no nível de transmissão de rádio. O recurso Logon Único do Windows Server "Longhorn" e do Windows Vista executa a autenticação 802.1X no momento apropriado com base na configuração de segurança da rede, enquanto integra-se de maneira simples e transparente com a experiência de logon do usuário do Windows.

Os administradores da rede podem usar as configurações da Diretiva de Grupo ou os novos comandos netsh wireless para configurar perfis de Logon Único em computadores cliente sem fio. Após a configuração de um perfil de Logon Único, a autenticação 802.1X terá precedência sobre o logon do computador ao domínio e os usuários serão solicitados a fornecer credenciais apenas se necessário. Esse recurso garante que a conexão sem fio tenha precedência sobre o logon no domínio do computador, o que possibilita cenários que exigem a conectividade de rede antes do logon do usuário, como no caso de atualizações da Diretiva de Grupo, execução de scripts de logon e ingresso no domínio do cliente sem fio.

Integração com a Proteção de Acesso a Rede ao usar a autenticação 802.1X
As conexões dinâmicas WPA2-Enterprise, WPA-Enterprise e WEP que usam autenticação 802.1X podem usar a plataforma de Proteção de Acesso a Rede para evitar que clientes sem fio que não são compatíveis com os requisitos de integridade do sistema obtenham acesso ilimitado a uma rede privada. Para obter mais informações sobre a plataforma de Proteção de Acesso a Rede, consulte "NAP (Proteção de acesso a rede)" neste artigo.

Infra-estrutura de EAPHost
Para um desenvolvimento mais fácil de métodos de autenticação do protocolo EAP para conexões de rede sem fio autenticadas por IEEE 802.1X, o Windows Server "Longhorn" e o Windows Vista oferecem suporte à nova infra-estrutura de EAPHost. Para obter mais informações, consulte "Arquitetura EAPHost" neste artigo.

Novo método de autenticação EAP padrão
No Windows Server 2003 e no Windows XP, o método de autenticação EAP padrão para conexões sem fio autenticadas por 802.1X é o EAP-TLS. Embora seja a forma mais segura de autenticação que usa autenticação mútua com certificados digitais, o EAP-TLS requer uma PKI (infra-estrutura de chave pública) para distribuir, revogar e renovar certificados de usuário e de computador.

Em muitos casos, as organizações querem utilizar a infra-estrutura de autenticação baseada em nome de conta e senha já existente no Active Directory. Portanto, no Windows Server "Longhorn" e no Windows Vista, o método de autenticação padrão EAP para conexões sem fio autenticadas por 802.1X foi alterado para o protocolo PEAP-MS-CHAP v2. O PEAP-MS-CHAP v2 é um método de autenticação 802.1X baseado em senha para conexões sem fio que exigem apenas que certificados de computador sejam instalados em servidores RADIUS (Remote Authentication Dial-In User Service). Para obter mais informações sobre PEAP-MS-CHAP v2, consulte PEAP with MS-CHAP Version 2 for Secure Password-based Wireless Access (em inglês).

Suporte a diagnóstico para conexões sem fio
A solução de problemas de conexões sem fio que apresentam falhas, embora aprimorada no Windows XP Service Pack 2 e no Windows Server 2003 Service Pack 1, ainda pode ser difícil. No Windows Server "Longhorn" e no Windows Vista, a solução de problemas de conexões sem fio é feita muito mais facilmente por meio dos seguintes recursos:

As conexões sem fio oferecem suporte ao novo Network Diagnostics Framework O Network Diagnostics Framework é uma arquitetura extensível que ajuda os usuários a recuperar e solucionar problemas de conexões de rede. Quando ocorre uma falha na conexão sem fio, o Network Diagnostics Framework envia um prompt ao usuário com uma opção para identificar e corrigir o problema. Em seguida, o suporte sem fio ao Network Diagnostics Framework tenta descobrir a origem da conexão com falha e corrige o problema automaticamente ou, dependendo das considerações de segurança, solicita que o usuário faça a alteração apropriada na configuração.

Novas informações armazenadas no log de eventos do Windows Quando ocorre uma falha na tentativa de conexão sem fio, os componentes sem fio do Windows Server "Longhorn" e do Windows Vista registram informações detalhadas sobre a tentativa de conexão no log de eventos do Windows. Esses registros de eventos podem ser usados por profissionais de suporte de uma organização para executar uma solução de problemas adicional quando o diagnóstico da conexão sem fio não puder resolver o problema ou quando ele puder resolver o problema, mas não puder corrigi-lo por meio da alteração das configurações do cliente sem fio. As informações no log de eventos do Windows podem reduzir o tempo necessário para resolver problemas de suporte da conexão sem fio. Adicionalmente, essas entradas do log de eventos podem ser coletadas automaticamente pelo administrador da rede com o Microsoft Operations Manager ou com outros tipos de ferramentas de gerenciamento central e analisadas para obter tendências e alterações de design na infra-estrutura da conexão sem fio.

As informações podem ser enviadas para a Microsoft para análise e aprimoramentos Os usuários que enfrentam problemas com a conexão sem fio também serão solicitados a enviar as informações de conexão à Microsoft para análise por meio da infra-estrutura WER (Relatórios de erros do Windows). Além disso, diagnósticos bem-sucedidos podem ser enviados à Microsoft pela infra-estrutura de SQM (Avaliação da qualidade do software), também conhecida como Programa de Aperfeiçoamento da Experiência do Usuário no Windows XP. Nos dois casos, apenas informações de diagnóstico da rede sem fio são enviadas (nenhuma informação pessoal sobre o computador ou o usuário). A Microsoft usará essas informações para identificar as principais causas de falhas nas conexões sem fio, identificar problemas de conexões sem fio e suas causas e tomar as medidas apropriadas para aperfeiçoar o software cliente sem fio no Windows ou trabalhará com fornecedores de conexão sem fio para ajudar a aperfeiçoar os produtos de hardware sem fio.

Interface de linha de comando para a definição de configurações sem fio
O Windows Server 2003 ou o Windows XP não tem uma interface de linha de comando que permita definir as configurações de rede sem fio que estão disponíveis a partir das caixas de diálogo de conexão sem fio na pasta Conexões de Rede ou por meio das configurações de Diretiva de Grupo de rede sem fio (IEEE 802.11). A configuração por meio da linha de comando da conexão sem fio pode ajudar a implantar redes sem fio nas seguintes situações:

Suporte de scripts automatizados para configurações sem fio sem o uso da Diretiva de Grupo As configurações da Diretiva de Grupo da rede sem fio (IEEE 802.11) aplicam-se apenas a um domínio do Active Directory. Para um ambiente sem o Active Directory ou uma infra-estrutura de Diretiva de Grupo, um script que automatiza a configuração de conexões sem fio pode ser executado manual ou automaticamente, como parte do script de logon.

Inicialização de um cliente sem fio na rede sem fio da organização protegida Um computador cliente sem fio que não é membro do domínio não pode estabelecer conexão com a rede sem fio protegida da organização. Além disso, um computador não pode ingressar no domínio até que tenha se conectado com êxito à rede sem fio protegida. Um script de linha de comando fornece um método para a conexão com a rede sem fio protegida da organização para ingressar no domínio.

No Windows Server "Longhorn" e no Windows Vista, é possível usar comandos Netsh no contexto netsh wireless para fazer o seguinte:

Definir todas as configurações do cliente sem fio em um perfil nomeado, incluindo configurações gerais (os tipos de rede sem fio a serem acessadas), configurações 802.11 (SSID, tipo de autenticação, tipo de criptografia de dados) e configurações de autenticação 802.1X (tipos EAP e suas configurações).

Especificar a lista de nomes de redes sem fio permitidas e negadas.

Especificar a ordem das redes sem fio preferenciais.

Exibir a configuração de um cliente sem fio.

Remover a configuração sem fio de um cliente sem fio.

Migrar definições da configuração sem fio entre clientes sem fio.

Reconhecimento de locais de rede e perfis de rede
Muitos aplicativos não reconhecem redes, resultando em confusão do cliente e sobrecarga para o desenvolvedor. Por exemplo, um aplicativo não pode ajustar automaticamente seu comportamento com base na rede e nas condições da conexão atual. Os usuários podem precisar redefinir as configurações do aplicativo de acordo com a rede à qual eles estão conectados (a rede privada da empresa, a rede doméstica do usuário, a Internet). Para remover a carga de configuração, os desenvolvedores de aplicativos podem usar as próprias APIs de nível inferior do Windows, construções de dados e até mesmo a sondagem da rede para determinar a rede atual e ajustar o comportamento do aplicativo de maneira apropriada.

Para fornecer uma infra-estrutura de sistema operacional a fim de permitir que desenvolvedores de aplicativos reconfigurem o comportamento do aplicativo com base na rede atualmente conectada, o serviço NLA (Reconhecimento de locais de rede) no Windows Server "Longhorn" e no Windows Vista agrega informações de rede disponíveis para o Windows em nome dos aplicativos e permite que eles se adaptem de maneira fácil e eficiente a esses ambientes em constante mudança. O NLA faz isso fornecendo aos aplicativos uma API unificada que permite que eles obtenham informações atualizadas da rede e notificações de alteração do local.

Para obter mais informações, consulte How to Write a Network-Aware Application e Longhorn Network Location Awareness Service (em inglês).

Aprimoramentos na Next Generation TCP/IP Stack para ambientes sem fio
Conforme descrito na seção "Aprimoramentos em ambientes com perda alta" deste artigo, a Next Generation TCP/IP Stack inclui suporte a novos algoritmos TCP que otimizam a taxa de transferência recuperando-se de perdas de um único ou de vários pacotes e detectando retransmissões falsas, o que melhora o desempenho em ambientes de rede sem fio.

Aprimoramentos na conectividade com fio baseada no IEEE 802.1X
No Windows Server 2003 e no Windows XP, é oferecido suporte limitado para a implantação de configurações de autenticação 802.1X para conexões com fio a um comutador de autenticação. O Windows Server "Longhorn" e o Windows Vista incluem o seguinte para obter uma implantação mais fácil de conexões com fio autenticadas por 802.1X:

Suporte à Diretiva de Grupo para configurações 802.1X com fio

Interface de linha de comando para definir configurações 802.1X com fio

Integração com a Proteção de Acesso a Rede ao usar a autenticação 802.1X

Infra-estrutura de EAPHost

Alteração no estado do serviço 802.1X

Logon único

Suporte à Diretiva de Grupo para configurações 802.1X com fio
Para ambientes que usam o Active Directory e a Diretiva de Grupo, o Windows Server "Longhorn" e o Windows Vista incluem suporte à Diretiva de Grupo para configurações da autenticação 802.1X para conexões com fio em Configuração do Computador/Configurações do Windows/Configurações de Segurança/Wired Network (IEEE 802.3) Policies.

Interface de linha de comando para definir configurações 802.1X com fio
Para ambientes que não usam o Active Directory ou a Diretiva de Grupo ou para cenários de inicialização, o Windows Server "Longhorn" e o Windows Vista também oferecem suporte a uma interface de linha de comando para definir configurações de autenticação 802.1X para conexões com fio. Usando comandos no contexto netsh wired, é possível fazer o seguinte:

Definir todas as configurações de cliente com fio em um perfil nomeado, incluindo configurações de autenticação 802.1X (tipos EAP e suas configurações)

Exibir a configuração de um cliente com fio

Remover a configuração com fio de um cliente com fio

Migrar definições da configuração com fio entre clientes com fio

Integração com a Proteção de Acesso a Rede ao usar a autenticação 802.1X
As conexões com fio autenticadas pelo IEEE 802.1X podem usar a plataforma de Proteção de Acesso a Rede para evitar que clientes com fio que não são compatíveis com os requisitos de integridade do sistema obtenham acesso ilimitado a uma rede privada. Para obter mais informações sobre a plataforma de Proteção de Acesso a Rede, consulte "NAP (Proteção de acesso a rede)" neste artigo.

Infra-estrutura de EAPHost
Para um desenvolvimento mais fácil de métodos de autenticação do protocolo EAP para conexões de rede com fio autenticadas por IEEE 802.1X, o Windows Server "Longhorn" e o Windows Vista oferecem suporte à nova infra-estrutura de EAPHost. Para obter mais informações, consulte "Arquitetura EAPHost" neste artigo.

Alteração no estado do serviço 802.1X
No Windows XP e no Windows Server 2003, o serviço 802.1X era habilitado por padrão, mas era colocado em um modo passivo de escuta. No Windows Vista, o serviço 802.1X é desabilitado por padrão, mas quando é habilitado, funciona em modo ativo.

Logon único
A implantação de comutadores de autenticação promoveu o uso da autenticação de redes de Camada 2, como o 802.1X, para garantir que apenas um usuário ou dispositivo apropriado tenha permissão para trocar quadros com o comutador. O recurso Logon Único do Windows Server "Longhorn" e do Windows Vista executa a autenticação 802.1X no momento apropriado com base na configuração de segurança da rede, enquanto integra-se de maneira simples e transparente com a experiência de logon do usuário do Windows.

Os administradores da rede podem usar as configurações da Diretiva de Grupo ou os novos comandos netsh wireless para configurar perfis de Logon Único em computadores cliente com fio. Após a configuração de um perfil de Logon Único, a autenticação 802.1X terá precedência sobre o logon do computador ao domínio e os usuários serão solicitados a fornecer credenciais apenas se necessário. Esse recurso garante que a conexão com fio tenha precedência sobre o logon no domínio do computador, o que possibilita cenários que exigem a conectividade de rede antes do logon do usuário, como no caso de atualizações da Diretiva de Grupo, execução de scripts de logon e ingresso no domínio do cliente com fio.