Estou executando o Windows Server 2008 R2, temos um aplicativo que conecta (vincula) a um IP público no servidor para 127.0.0.1:8334 [conecta-se a um serviço que atende em 0.0.0.0:8334]
No Windows 2003, não houve problema com isso. Podemos nos conectar usando o TCP de 1.2.3.4 [p.ex.] para 127.0.0.1:8334 bem.
No Windows 2008, descobrimos que as conexões TCP do ip público, por exemplo, 1.2.3.4 a 127.0.0.1:8334 falham, mesmo. mas o serviço aceita conexões de 127.0.0.1 a 127.0.0.1:8334 e 127.0.0.1 a 1.2.3.4:8334.
Tentei desativar o firewall do Windows, configurando seu registro, etc. (nenhuma entrada de registro útil apareceu), sem sucesso. Isso é um problema com a nova pilha de rede?
edições
1.2.3.4 está tentando se conectar ao host local [127.0.0.1] na mesma máquina
O arquivo hosts é o arquivo host padrão do Windows 2008.
Informação de verificação de loopback, interessante. Tentei ... não funcionou. Verificado para verificar se a ID fez tudo corretamente - eu tenho.
Estou querendo saber se existe uma solução usando NAT ou alguma outra maneira de encaminhar portas - se eu encaminhar 127.0.0.1:port para 1.2.3.4:port, isso funcionaria? Dado que o aplicativo escuta em 0.0.0.0:port, ele pegaria conexões em 1.2.3.4:port
O arquivo HOSTS contém localhost 127.0.0.1 - no entanto, o arquivo hosts é usado apenas em pesquisas de nome de host. Nesse caso, nosso aplicativo não procuraria nenhum nome de host, pois o endereço IP 127.0.0.1 é codificado nele (em vez de hostname do host local). Então o arquivo HOSTS não entraria em jogo aqui.
Como para portas acima de 1024 [acho que você se refere ao problema MaxUserPort talvez?] Eu testei isso tentando uma conexão simples à porta 445 - funciona a partir de 127.0.0.1, não funciona quando eu conecto a partir do IP 1.2.3.4 de origem. 445 é um serviço padrão do Windows, então deve funcionar!
Atualmente não está executando NAT ou RRAS na máquina ... queria saber se havia uma maneira de fazer o reencaminhamento - Imagino que não funcionará, já que a pilha TCP / IP rejeitará o pacote antes que ele atinja a interface de loopback. -rota.
Impressão do roteamento que eu tinha verificado - parece bem, os IPs públicos roteados primeiro, depois, finalmente, a máscara de rede 127.0.0.0 255.255.255.0 e a máscara de rede 127.0.0.1 255.255.255.255 para loopback.
Editar Parece que encontrei a resposta quanto à razão do problema. Eu usei eventvwr.msc, habilitado log Winsock, desliguei outros serviços, apenas tentei este teste de conexão. Recebi um erro que, em hexadecimal, mapeou para STATUS_INVALID_ADDRESS_COMPONENT quando pesquisei no Google.
Isso me levou a: link
O que confirmou que esta é uma alteração por design no WFP para o Vista / 7 / Server 2008 [plataforma de filtragem de janelas].
[Veja a resposta de Anupama Vasanth]
Parece que eu vou ter que ir pelo caminho difícil e reescrever o código [difícil, porque isso significa lidar com os gerentes!]
Obrigado por me ajudar a localizar / confirmar o problema!
Não se esqueça, no Windows 2008, o firewall está ativado por padrão. Isso potencialmente pode bloquear qualquer & todo o tráfego, mesmo na interface de loopback. Além disso, se você ligar para 0.0.0.0, estará aceitando conexões em TODAS as interfaces. O firewall ainda bloquearia isso. Você pode tentar desligar o firewall durante o teste ... e ligá-lo novamente. Eu não tive nenhum problema de conexão com vários programas que desenvolvi em 127.0.0.1.
Tente conectar-se ao 127.0.0.2 no Vista / win2k8 e acima - parece engraçado, mas funciona. Teve resultados positivos com isso no passado
Tenho certeza de que ele está conectado com o recurso de segurança de verificação de loopback, embora não seja possível detalhar em detalhes como ele é implementado, apenas como superá-lo:
E para "APLICA-SE AO" Windows 2008, consulte o link
Bem, o que exatamente está no seu arquivo HOSTS? Eu não tenho o W2008. Você quer dizer que não há "127.0.0.1 localhost" lá?
Eu também li em algum lugar que a configuração padrão do W2008 não permite se comunicar com portas maiores que 1024.
Você pode enviar comentários sobre o MS Windows Server 2008 diretamente para a equipe do MS por meio de
e eles responderão
Se você tentou desativar a "verificação de loopback" por meio do método de edição do registro, então é necessário reinicializar. Outro - não.
NAT dentro da máquina? 127.0.0.1 não é encaminhado ou encaminhado, creio que sim, é interno, você pode desligar a placa de rede, o seu 1.2.3.4 desaparecerá, mas 127.0.0.1 continuará a estar lá.
Qual é a saída de sua (impressão de rota Executar - > cmd - >)?
Há mais um momento, eu estava pensando, embora eu não saiba como montar isso.
127.0.0.1 é localhost (interface), é um nome de rótulo único e considerado local. 1.2.3.4 é um nome sem rótulo único.
Possíveis problemas com isso é que esse nome pode ter sido considerado externo
Você pode tentar separadamente:
Desativando (se estiver ativado e ativando se estiver desativado) IPv6 no adaptador de rede?
Colocando algum nome de rótulo único para 1.2.3.4 no arquivo HOSTS?
O que é a descrição do evento correspondente, EventID, etc. em eventvwr.msc por falha na comunicação de 1.2.3.4 a 127.0.0.1:8334?
"445 is a standard Windows service"
É para SMB-direct over TCP / IP? para compartilhamento de arquivos? CIFS?
Não tão confiável ... Ele está sendo constantemente invadido por hotfixes MS. Leia:
("O NetBIOS navegando pelas sub-redes pode falhar após a atualização para o Windows Server 2008") - link
Então,
"we have the same issue as described earlier with Vista SP2 machines trying to reach a Windows Server 2008 SP1 or SP2 file share. The file sharing service is protected by Windows Firewall with advanced security using a predefined rule for file sharing (SMB) reguesting a secure connection"