A solicitação de aplicativo roteamento em um convidado hyper-v pára intermitentemente

Question

Breve descrição:

Estou com um problema estranho ao configurar o ARR em um convidado do hyper-v.

Eu posso carregar meus sites DotNetNuke / ASPx normalmente, mas depois de algum tempo de inatividade, as páginas não são mais carregadas.

Ele só volta ao trabalho depois que eu visito um site IIS padrão e pressiono Ctrl + F5. Isso é até deixar o navegador ocioso novamente.

Abaixo, descrevo o cenário e a descrição completa:

O cenário:

(Nota: Eu desabilitei as regras e configurei uma regra "pega-tudo", depois de passar dias tentando descobrir o problema com as configurações de produção. É simplificado para este cenário, mas o problema é o mesmo.)

• Eu tenho um d-link DSL-2750B, que é o encaminhamento de porta 80s para um servidor proxy reverso (Windows 2012 Std VM);

• Este servidor proxy reverso tem ARR habilitado e uma regra de Regravação de URL configurada para redirecionar todas as chamadas para um Servidor Web (reencaminhamento para seu Farm), usando uma "regra de captura geral" (*), apenas para teste fins;

• No servidor da Web, que também é uma VM, eu tenho três sites DotNetNuke e um site padrão do IIS, com apenas html padrão;

• Todos esses sites não possuem autenticação do Windows. Todos aceitam anônimos.

Descrição longa:

A configuração acima funciona. Para fazer o teste strong, estou acessando as páginas da empresa usando meu computador de casa, via LogmeIn:

• Eu abro o meu navegador "doméstico" e navego para todos os sites (os 3 dnn sites e o site padrão do IIS). Tudo ok.

• Agora deixo o Web Broser ocioso ou simplesmente continuo trabalhando por minutos aleatórios.

• De repente, quando tento atualizar ou navegar pelos sites, as páginas não são carregadas e o Navegador da Web continua exibindo o "ícone de progresso" (no Firefox, o círculo verde em execução, logo após o cinza ).

• Ele é mantido por um longo tempo até que a mensagem "Conexão reiniciada" seja exibida.

• Não importa quantos cliques no botão "atualizar", ele continua mostrando o círculo verde. Além disso, fechar o navegador e abrir nova instância não ajuda. Eventualmente, após alguns minutos, os sites retornam ao trabalho.

• Agora a parte estranha : se eu navegar no site IIS padrão e pressionar Ctrl + F5, posso navegar normalmente para sites DNN!

• Todos navegam bem, até que ele eventualmente fique preso novamente, depois de alguns minutos.

Alguém passou por este problema?

Mais informações:

• no mesmo tempo em que o Web Broser "doméstico" está travado, um navegador da Web "corporativo" (observe, na mesma rede) funciona normalmente, apontando para o servidor ARR usando a modificação HOSTS).

• se eu encaminhar o firewall direto para o servidor da Web (VM), tudo parece estar funcionando bem.

• parece que há um tempo reservado para trabalhar e um tempo reservado para não trabalhar. É intermitente.

• o único truque que encontrei para contornar esse problema é carregar um site padrão do IIS no Navegador da Web.

Answer 1

Ok. Depois de mais um dia de testes e agora envolvendo um amigo, encontramos o bandido: o roteador.

Acabamos de substituir o roteador por um antigo e bom D-Link DI-624 que nós tínhamos como sobressalente e tudo está funcionando bem agora.

Aqui, os passos que temos para encontrar o ponto problemático:

• primeiro, desenhamos em um documento toda a infraestrutura que a solicitação vai do cliente para o servidor da web

• então, começamos os testes de eliminação. Verifique os problemas, do final ao início. Primeiro, teste novamente a solicitação andando em toda a infraestrutura

• depois, movemos um site para cada servidor e testamos cada um deles:

  • de "VM Web Server" para "VM ARR Server" e teste-o local e remotamente
  • de "VM ARR Server" para "Hyper-v Host Server" e teste-o local e remotamente

• para cada movimento do Web Site, apontamos o firewall para o ARR e diretamente para o servidor da Web

Com esses testes, poderíamos eliminar que os erros não pudessem estar no sistema operacional, nos hyper-v guests, nem no ARR / Rewrite, nem mesmo em nossas placas de rede ou rede ou cabos.

Então, quando estávamos fazendo os testes, arriscamos nosso desenho quando chegamos ao último elo da cadeia: o roteador.

É isso!