Windows Server - Redirecionando Solicitações para IP Público para Localhost

Question

Eu tenho um cliente que tem uma caixa do Windows Server 2008 executando dois conjuntos diferentes de scripts.

Um conjunto de scripts hospeda vários sites em vários domínios diferentes. O outro conjunto de scripts é usado para gerar relatórios e outras informações com base nas URLs do primeiro conjunto.

O segundo conjunto de scripts (para relatórios) gera os relatórios com base no URL. No entanto, os relatórios interrompem (não funcionam) a menos que as URLs sejam inseridas manualmente no arquivo HOSTS do servidor e vinculadas a 127.0.0.1 . Caso contrário, parece que as solicitações estão indo para o endereço IP externo, que pode estar ficando preso na DMZ / firewall.  Atualizar o arquivo HOSTS é complicado para o cliente.

Minha sugestão, além de editar regras na DMZ, é atualizar a Tabela de Roteamento do Windows, para que todas as solicitações destinadas ao endereço IP público sejam redirecionadas automaticamente para 127.0.0.1 .

Eu sou louco e / ou isso é uma sugestão estúpida? Isso pode ser feito com o comando route add ? Se sim, exatamente como?

    

Answer 1

it seems that the requests are going to the external IP address, which may be getting stuck at the DMZ / firewall.

[...]

My suggestion, aside from editing rules in the DMZ, is to update the Windows Routing Table, so that any requests destined for the public IP address automatically get rerouted to 127.0.0.1.

A regra da administração do sistema profissional é fazer com que os sistemas padrão funcionem de maneira padrão. É inesperado para o seu servidor não conseguir resolver seu próprio nome e / ou acessar o endereço IP da própria interface. Eu não sei sua topologia, no entanto, e poderia haver hairpin NAT em jogo ou algum tipo de SNAT / DNAT acima do servidor. Seja qual for a razão, pelo menos trabalhe para discernir a causa de tudo e se é um ambiente orientado por padrões.

No entanto, afastando-se da teoria e em questões práticas, você precisa levar traços do tráfego até os picos e vales de impulsos elétricos no fio, se necessário, tudo para descobrir por que esse servidor pode converse com o endereço da própria interface. Mascarar o fedor com entradas de arquivos HOSTS e rotas loucas na tabela de roteamento voltará para torturá-lo mais tarde.

A resposta para o problema não pode ser dada porque os fatos necessários não são dados, mas a metodologia seria:

• Ouça em cada interface envolvida na comunicação (servidor, switch, firewall, etc.)
• Verifique cada salto de rede para aplicativos e serviços que possam interferir no tráfego
• Isso inclui várias camadas em cada host. Só porque o firewall do seu host não está matando a conversa, não significa que o IIS não esteja tankando assim que os pacotes passem da pilha TCP / IP.
• Em um host Windows, o Monitor de rede é a melhor análise pontuada de pacotes playmate.

Am I crazy, and/or is this a stupid suggestion?

Nenhum comentário. =)

Can this be accomplished with the route add command? If so, exactly how?

Da perspectiva de "Qual é a maneira menos produtiva de realizar essa tarefa que é, ao mesmo tempo, mais provável que me faça querer cometer seppuku com um spork", sim, isso poderia ser feito. Quanto a "exatamente como", eu não vou contar para você, caso contrário, eu te bati no spork.