Ao usar o VMWare Fusion: a pesquisa de DNS no convidado do Windows 7 acrescenta domínio local


1

Aqui está o que eu digito:

C:\Users>nslookup
Default Server:  UnKnown
Address:  172.16.128.2

> google.com
Server:  UnKnown
Address:  172.16.128.2

Name:    google.com.localdomain
Addresses:  74.125.226.14
          74.125.226.14

> google.com.
Server:  UnKnown
Address:  172.16.128.2

Non-authoritative answer:
Name:    google.com
Addresses:  2607:f8b0:4006:806::1005
          74.125.226.1
          74.125.226.6
          74.125.226.2
          74.125.226.4
          74.125.226.5
          74.125.226.9
          74.125.226.8
          74.125.226.7
          74.125.226.3
          74.125.226.0
          74.125.226.14

Isso costumava não causar problemas e talvez não acrescentasse domínio local ... mas agora causa problemas para aplicativos que não anexam um '.' ao fazer a pesquisa de nome de domínio.

Eu vejo o problema na linha de comando ssh no cygwin.

E para ter certeza ... no host (Mac OS / X):

jzwolak@laptop:~$ nslookup
> google.com
Server:     192.168.2.1
Address:    192.168.2.1#53

Non-authoritative answer:
Name:   google.com
Address: 74.125.226.14
Name:   google.com
Address: 74.125.226.1
Name:   google.com
Address: 74.125.226.6
Name:   google.com
Address: 74.125.226.2
Name:   google.com
Address: 74.125.226.4
Name:   google.com
Address: 74.125.226.5
Name:   google.com
Address: 74.125.226.9
Name:   google.com
Address: 74.125.226.8
Name:   google.com
Address: 74.125.226.7
Name:   google.com
Address: 74.125.226.3
Name:   google.com
Address: 74.125.226.0
> 

Estou executando o VMWare Fusion 7.1.2, Mac OS / X 10.10.4, Windows 7 SP1 com todas as atualizações importantes e as últimas cygwin e ssh (do pacote cygwin com a versão: OpenSSH_6.9p1, OpenSSL 1.0.2d 9 de julho de 2015 )

O ssh não é o único programa que tem problemas, mas é o que eu preciso usar.

Alguma idéia de por que isso está acontecendo?

Ah ... e se eu definir manualmente o servidor DNS no Windows como o usado no Mac OS / X (192.168.2.1 no meu exemplo), tudo funcionará bem.


Esse problema também ocorre com o VMWare Fusion 8? Alguém sabe?
Jason

Vejo que o VMWare Fusion 8 Pro tem suporte explícito para redes NAT ipv6. Mas não sei se o problema está resolvido.
Jason

Respostas:


1

Para acrescentar à resposta de Scott, pelo que entendi a diferença está no modo NAT / Compartilhado, o VMWare isola o hóspede, tornando-o mais seguro, a máquina virtual não possui seu próprio endereço IP na rede externa. Em vez disso, uma rede privada separada chamada localadmin é configurada no seu Mac ...

Com a rede em ponte, a máquina virtual aparece como um computador adicional na mesma rede Ethernet física do seu Mac, tornando-a menos segura. Consulte o artigo do VMWare KB sobre os tipos de rede.

Teste do modo NAT :

C:\Windows\System32>nslookup
Default Server:  UnKnown
Address:  172.16.65.2

> google.com
Server:  UnKnown
Address:  172.16.65.2

Name:    google.com.localdomain
Addresses:  216.58.192.46
          216.58.192.46

>

Teste do modo de ponte :

C:\Windows\System32>nslookup
Default Server:  google-public-dns-a.google
Address:  8.8.8.8

> google.com
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    google.com
Addresses:  2607:f8b0:4010:800::1004
          216.58.192.46

Finalmente, eu posso usar o git no Cygwin no Windows em execução no VMWare! Obrigado!
Leremjs 23/12/2015

0

Sim, isso causa problemas com o SSH (e por extensão git). O problema é que o adaptador de rede da máquina virtual está configurado no modo NAT (também mostrado como Compartilhar com meu Mac ) e no modo NAT o VMWare está tentando forçar o IPv6, mas não oferece suporte adequado ao IPv6. Você pode alternar para o modo ponte ou forçar o SSH a usar o IPv4.

Comutado para o modo Bridge

NOTA: Isso pode reduzir a segurança da sua VM, uma vez que ela estará diretamente conectada à rede agora e não terá proteção através da máquina host. Altere a rede para o modo Ponte selecionando o menu Máquina Virtual> Adaptador de Rede> Ponte (Detecção Automática) e vai funcionar.

Forçar o SSH a usar o IPv4

Adicione a seguinte linha a /etc/ssh/ssh_config(ou c:\Program Files\Git\etc\ssh\ssh_configao usar o git para windows):

AddressFamily inet

0

Desativei o ipv6 no Windows e parece funcionar.

Usei as instruções em https://support.microsoft.com/en-us/kb/929852

Para desabilitar certos componentes IPv6, siga estas etapas:
Clique em Iniciar, digite regedit na caixa Iniciar Pesquisa e clique em regedit.exe na lista Programas.
Na caixa de diálogo Controle de Conta de Usuário, clique em Continuar.
No Editor do Registro, localize e clique na seguinte subchave do Registro:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip6 \ Parameters \
Clique duas vezes em DisabledComponents para alterar a entrada DisabledComponents. 

Nota Se a entrada DisabledComponents estiver indisponível, você deverá criá-la. Para fazer isso, execute as seguintes etapas:
No menu Editar, aponte para Novo e clique em Valor DWORD (32 bits).
Digite DisabledComponents e, em seguida, pressione Enter.
Clique duas vezes em DisabledComponents.
Digite um dos seguintes valores no campo Dados do valor para configurar o protocolo IPv6 para o estado pretendido e clique em OK:
Digite 0 para reativar todos os componentes IPv6 (configuração padrão do Windows).
Digite 0xff para desativar todos os componentes do IPv6, exceto a interface de loopback do IPv6. Esse valor também configura o Windows para preferir o uso do IPv4 sobre o IPv6, alterando as entradas na tabela de políticas de prefixo. Para mais informações, consulte Seleção de endereço de origem e destino.
Digite 0x20 para preferir IPv4 sobre IPv6, alterando as entradas na tabela de políticas de prefixo.
Digite 0x10 para desativar o IPv6 em todas as interfaces não-túneis (interfaces LAN e Protocolo Ponto a Ponto [PPP]).
Digite 0x01 para desativar o IPv6 em todas as interfaces de túnel. Isso inclui o ISATAP, 6to4 e Teredo.
Digite 0x11 para desativar todas as interfaces IPv6, exceto a interface de loopback IPv6.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.