При использовании VMWare Fusion: поиск DNS в гостевой системе Windows 7 добавляет локальный домен

Question

Вот что я печатаю:

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

Раньше это не вызывало никаких проблем и, возможно, раньше оно не добавляло localdomain ... но теперь это вызывает проблемы для приложений, которые не добавляют '.' при поиске доменного имени.

Я вижу проблему в командной строке ssh в cygwin.

И чтобы быть уверенным ... на хосте (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
> 

Я использую VMWare Fusion 7.1.2, Mac OS/X 10.10.4, Windows 7 SP1 со всеми важными обновлениями, а также последние версии cygwin и ssh (из пакета cygwin с версией: OpenSSH_6.9p1, OpenSSL 1.0.2d 9 июля 2015 г. ).

ssh - не единственная программа, у которой есть проблемы, но мне нужно ее использовать.

Есть идеи, почему это происходит?

Ох ... и если я вручную установлю DNS-сервер в Windows на тот, который используется в Mac OS/X (192.168.2.1 в моем примере), то все работает нормально.

Answer 1

Чтобы добавить к ответу Скотта, из того, что я понимаю, различие в режиме NAT/Shared VMWare изолирует гостя, делая его более безопасным, виртуальная машина не имеет своего собственного IP-адреса во внешней сети. Вместо этого на вашем Mac установлена отдельная частная сеть с именем localadmin ...

В мостовой сети виртуальная машина выглядит как дополнительный компьютер в той же физической сети Ethernet, что и ваш Mac, что делает ее менее защищенной. См VMWare KB статьи о типах сетей.

Тест режима 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

>

Тест мостового режима:

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

Answer 2

Да, это вызывает проблемы с SSH (и расширением git). Проблема заключается в том, что сетевой адаптер виртуальной машины настроен в режиме NAT (также показывается как « Поделиться с моим Mac»), а в режиме NAT VMWare пытается форсировать IPv6, но каким-то образом не поддерживает IPv6 должным образом. Вы можете переключиться в режим моста или заставить SSH использовать IPv4.

Переключен в режим моста

ПРИМЕЧАНИЕ. Это может снизить безопасность вашей виртуальной машины, поскольку теперь она будет напрямую подключена к сети и не будет иметь защиты через хост-компьютер. Переведите сеть в режим моста , выбрав в меню « Виртуальная машина»> «Сетевой адаптер»> «Мост через мост» (Autodetect), и буду работать.

Заставить SSH использовать IPv4

Добавьте следующую строку в /etc/ssh/ssh_config (или c:\Program Files\Git\etc\ssh\ssh_config при использовании git для окон):

AddressFamily inet

Answer 3

Я отключил ipv6 на Windows, и он, кажется, работает.

Я использовал инструкции на https://support.microsoft.com/en-us/kb/929852

To disable certain IPv6 components, follow these steps:
Click Start, type regedit in the Start Search box, and then click regedit.exe in the Programs list.
In the User Account Control dialog box, click Continue.
In Registry Editor, locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
Double-click DisabledComponents to change the DisabledComponents entry. 

Note If the DisabledComponents entry is unavailable, you must create it. To do this, follow these steps:
In the Edit menu, point to New, and then click DWORD (32-bit) Value.
Type DisabledComponents, and then press Enter.
Double-click DisabledComponents.
Type any of the following values in the Value data field to configure the IPv6 protocol to the intended state, and then click OK:
Type 0 to re-enable all IPv6 components (Windows default setting).
Type 0xff to disable all IPv6 components except the IPv6 loopback interface. This value also configures Windows to prefer using IPv4 over IPv6 by changing entries in the prefix policy table. For more information, see Source and destination address selection.
Type 0x20 to prefer IPv4 over IPv6 by changing entries in the prefix policy table.
Type 0x10 to disable IPv6 on all nontunnel interfaces (both LAN and Point-to-Point Protocol [PPP] interfaces).
Type 0x01 to disable IPv6 on all tunnel interfaces. These include Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), 6to4, and Teredo.
Type 0x11 to disable all IPv6 interfaces except for the IPv6 loopback interface.