O caso do problema no Identificador de Status de conexão de Rede (NCSI) do Windows quando conectado à rede Wireless
Autor: Eduardo Gaeta / Revisão Técnica: Daniel Mauser
Introdução:
Quando uma máquina Windows se conecta a uma rede, há duas tecnologias, de locais de rede (NLA) e Indicador de Status de conexão de rede (NCSI); que a máquina usa para identificar automaticamente a rede ele está se conectando, e se tem ou não tem acesso à Internet. Neste artigo iremos falar especificamente sobre Indicador de Status de conexão de rede (NCSI). Para maiores informações sobre o funcionamento de ambas as tecnologias verifique o blog - https://blogs.technet.com/b/networking/archive/2012/12/20/the-network-connection-status-icon.aspx
Problema:
Identificador de Status de conexão de Rede (NCSI) não funciona quando conectado à rede Wireless.
Quando conectamos à estação em uma rede Wireless, por alguma razão, a mesma não consegue validar o acesso à internet;
O erro acontece somente em redes Wirelees, para redes cabeadas o funcionamento é normal
Para validar o acesso à internet, a estação abre a seguinte página no Internet Explorer - https://www.msn.com/th-th/?ocid=wispr
Todas as vezes que a estação reconecta à rede Wireless, a validação ocorre , causando invoveniente para os usuários;
Enquanto a página não é aberta, a ícone da conexão Wireless fica com uma exclamação amarela (Sem acesso à internet).
Depois de aberta a página, a exclamação desaparece;Notamos que quando a estação esta conectada à rede cabeada, essa validação ocorre através do servidor proxy, e quando a rede utilizada é a Wireless, a validação é feita diretamente pelo firewall.
Nos traces de rede, podemos ver os seguintes comportamentos:
1. Cenário saudável – estação conectada à rede cabeada:
Query DNS para o NCSI:
39 17:18:44.8345014 0.0000000 <IP estação> <DNS Server> DNS www.msftncsi.com DNS:QueryId = 0xF59E, QUERY (Standard query), Query for www.msftncsi.com of type Host Addr on class Internet
Resposta da Query para o NCSI:
40 17:18:44.8378217 0.0033203 <DNS Server> <IP estação> DNS www.msftncsi.com DNS:QueryId = 0xF59E, QUERY (Standard query), Response - Success, 190.98.140.137, 190.98.140.123 ...
A estação tenta se conectar ao IP público do NCSI sem sucesso. Isso é esperado, visto que as conexões HTTP devem utilizar o proxy:
41 17:18:44.8383699 0.0005482 <IP estação> 190.98.140.137 TCP TCP:Flags=......S., SrcPort=61908, DstPort=HTTP(80), PayloadLen=0, Seq=3799356614, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192
170 17:18:47.8461813 3.0078114 <IP estação> 190.98.140.137 TCP TCP:[SynReTransmit #41]Flags=......S., SrcPort=61908, DstPort=HTTP(80), PayloadLen=0, Seq=3799356614, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192
414 17:18:53.8597024 3.6070138 <IP estação> 190.98.140.137 TCP TCP:[SynReTransmit #41]Flags=......S., SrcPort=61908, DstPort=HTTP(80), PayloadLen=0, Seq=3799356614, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192
Agora nós vemos que a estação tenta acessar o endereço utilizando o proxy:
345 17:18:50.2258807 2.3796994 <estação> proxy.contoso.local HTTP HTTP:Request, GET https://ipv6.msftncsi.com/ncsi.txt
346 17:18:50.2259196 0.0000389 <estação> proxy.contoso.local HTTP HTTP:Request, GET https://www.msftncsi.com/ncsi.txt
347 17:18:50.2310621 0.0051425 proxy.contoso.local <estação> HTTP HTTP:Response, HTTP/1.1, Status: Service unavailable, URL: https://ipv6.msftncsi.com/ncsi.txt
352 17:18:50.2526886 0.0216265 proxy.contoso.local <estação> HTTP HTTP:Response, HTTP/1.1, Status: Ok, URL: https://www.msftncsi.com/ncsi.txt
2. Cenário com problemas – estação conectada à rede Wireless:
Query DNS para o NCSI:
204 11:38:51 AM 11/16/2015 0.0000000 <IP estação> <DNS Server> DNS DNS:QueryId = 0x3C86, QUERY (Standard query), Query for www.msftncsi.com of type Host Addr on class Internet {DNS:53, UDP:52, IPv4:22}
Resposta da Query para o NCSI:
274 11:38:53 AM 11/16/2015 0.5774852 <DNS Server> <IP estação> DNS DNS:QueryId = 0x3C86, QUERY (Standard query), Response - Success, 190.98.146.25, 190.98.146.19 ... {DNS:53, UDP:52, IPv4:22}
A estação, conforme quando conectada à rede cabeada, envia o "HTTP GET" diretamente ao endereço público do NCSI - 190.98.146.25:
332 11:38:53 AM 11/16/2015 0.4822906 <IP estação> 190.98.146.25 HTTP HTTP:Request, GET /ncsi.txt {HTTP:153, TCP:118, IPv4:117}
Porém neste cenário ele recebe uma resposta:
397 11:38:55 AM 11/16/2015 1.4469217 190.98.146.25 <IP estação> HTTP HTTP:Response, HTTP/1.1, Status: Temporary Redirect, URL: /ncsi.txt {HTTP:153, TCP:118, IPv4:117}
Detalhes da Resposta:
Frame: Number = 397, Captured Frame Length = 305, MediaType = WiFi
+ WiFi: [Unencrypted QoS Data] F..R..P, (I) RSSI = -252 dBm, Rate = 24.0 Mbps
+ LLC: Unnumbered(U) Frame, Command Frame, SSAP = SNAP(Sub-Network Access Protocol), DSAP = SNAP(Sub-Network Access Protocol)
+ Snap: EtherType = Internet IP (IPv4), OrgCode = XEROX CORPORATION
+ Ipv4: Src = 190.98.146.25, Dest = <DNS Server>, Next Protocol = TCP, Packet ID = 42722, Total IP Length = 239
- Tcp: Flags=...AP..F, SrcPort=HTTP(80), DstPort=61451, PayloadLen=199, Seq=2181436018 - 2181436218, Ack=3442973846, Win=24862 (scale factor 0x5) = 795584
- Http: Response, HTTP/1.1, Status: Temporary Redirect, URL: /ncsi.txt
ProtocolVersion: HTTP/1.1
StatusCode: 307, Temporary Redirect
Reason: Temporary Redirect
Location: https://<IP do Checkpoint>/UserCheck/PortalMain?IID=804DF151-2279-2E5C-6133-AFECFF0CCE84&origUrl=aHR0cDovL3d3dy5tc2Z0bmNzaS5jb20vbmNzaS50eHQ
Connection: close
HeaderEnd: CRLF
6 segundos depois, a estação envia a requisição para o proxy conforme supostamente deveria acontecer, mas ja é tarde:
673 11:39:01 AM 11/16/2015 6.6398035 <estação> proxy.contoso.local HTTP HTTP:Request, GET https://www.msftncsi.com/ncsi.txt {HTTP:341, TCP:334, IPv4:242}
693 11:39:02 AM 11/16/2015 0.5544214 proxy.contoso.local <estação> HTTP HTTP:Response, HTTP/1.1, Status: Ok, URL: https://www.msftncsi.com/ncsi.txt {HTTP:341, TCP:334, IPv4:242}
701 11:39:02 AM 11/16/2015 0.0011508 <estação> proxy.contoso.local HTTP HTTP:Request, GET https://ipv6.msftncsi.com/ncsi.txt {HTTP:350, TCP:333, IPv4:242}
Causa Raiz do Problema:
O redirecionamento para a URL - https://<IP_do_Checkpoint>/UserCheck/PortalMain?IID=804DF151-2279-2E5C-6133-AFECFF0CCE84&origUrl=aHR0cDovL3d3dy5tc2Z0bmNzaS5jb20vbmNzaS50eHQ
Pesquisando na internet, identificamos que a URL mencionada acima esta relacionada à uma resposta do Firewall da Checkpoint
+++ How to customize and localize the UserCheck portal - https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk83700
Solução do Problema:
Garantir que o tráfego da estação seja bloqueado quando a mesma tentar acessar o endereço público do NCSI, ao invés de redirecionar o tráfego para à página do Firewall (UserCheck portal). Assim como acontece quando a estação esta conectada à rede cabeada.
Referência:
The Network Connection Status Icon
https://blogs.technet.com/b/networking/archive/2012/12/20/the-network-connection-status-icon.aspx