Problema com o roteamento entre VMs do Hyper-V

Question

Temos algumas VMs em um servidor Windows 2008 (Hyper-V) e estamos tendo problemas com o roteamento entre elas.

A configuração é que o servidor Hyper-V executa o RRAS e mapeia os IPs em sua NIC para IPs internos (192.168.1.X) que as VMs usam. As VMs usam o servidor Hyper-V como seu gateway para o tráfego de saída. A razão para essa configuração é que nosso ISP atribui IPs por endereço MAC, caso contrário, as VMs não poderiam usar os IPs externos atribuídos ao servidor.

A questão é que as máquinas virtuais não podem falar umas com as outras usando o endereço IP externo. Por exemplo, se o Servidor A for 4.2.2.1 (IP externo) /192.168.1.1 (IP interno) e o Servidor B for 4.2.2.2 (IP externo) /192.168.1.2 (IP interno), você não poderá efetuar ping de 4.2.2.2 de 4.2 .2.1. Você PODE ping 192.168.1.1 de 192.168.1.2. Também temos um servidor C que é 4.2.3.1 (uma sub-rede diferente), e essa máquina não tem problema ao pingar o Servidor A ou o Servidor B. Então, essencialmente, a menos que as máquinas estejam em sub-redes separadas, elas não podem falar umas com as outras. / p>

O motivo pelo qual não usamos 192.168.1.X para nos comunicarmos é que, para essa finalidade específica, estamos configurando um servidor de monitoramento. Este servidor de monitoramento usará um FQDN (como servera.myservers.net) para tentar executar ping no Servidor B. Portanto, precisamos saber se há uma falha de DNS ou algo assim.

Uma coisa estranha é que, se você faz um tracert do Servidor A para o Servidor C, você obtém um tempo limite para as duas primeiras tentativas e, em seguida, uma conexão, mas não a vê passando por um gateway.

    

Answer 1

Acredito que a implementação do Microsoft NAT sofra de um artefato que muitas implementações de NAT fazem (Cisco PIXOS, Linux ipchains-- o precursor do iptables) em que o NAT ocorre somente no tráfego chegando no interface "pública". O Cisco-ISM para este comportamento é "hairpinning" (eu acho que porque o pacote faz um "hairpin turn" e sai através da interface que entrou).

Aqui está um problema analógico:

Um cliente tem um Cisco PIX na borda de sua rede fazendo NAT entre um endereço IP estático público e sua LAN. Eles têm um servidor HTTP na rede local 192.168.1.1 e seu IP público é 172.18.9.1. Uma solicitação de um navegador executado em um PC na LAN para " link " retorna "A página não pôde ser exibida" porque a implementação do PIX NAT não NAT o tráfego que chega na interface interna com limite de 172.18.9.1 a 192.168.1.1.

Aqui está uma questão de falha no servidor que também descreve o comportamento que estou falando (embora, novamente, não citando especificamente a implementação NAT da Microsoft): Não é possível conectar-se no servidor natted de um computador host na mesma rede local usando o endereço IP público

Acredito que você esteja vendo um comportamento semelhante com a implementação NAT da Microsoft, mas não tenho provas concretas (por exemplo, documentação da Microsoft). Eu não tenho recursos para criar uma máquina de teste, e a Microsoft não parece estar usando a palavra-chave "hairpin" em sua documentação para o positivo ou negativo.

(Eu realmente acho engraçado, nessa questão do Server Fault que eu mencionei acima, que as pessoas consideram a falta de hairpinning como "normal". Linux iptables lidaria com o que você está fazendo sem nenhum problema. Eu sempre considerei implementações de NAT que não conseguem lidar com esse hairpinning como sendo inferior.)