После смены роутера не работает пинг из гостевой машины к хост-машине

[Petya V4sechkin]

Команды (nbtstat -n) и (ipconfig /all)
Единственное различие, которое бросается в глаза, - порядок сетевых интерфейсов. Как поменять:
Network Protocol Bindings in Windows 10 (https://talhaqamar.com/2019/03/02/network-protocol-bindings-in-windows-10/)

Ну или роутер блокирует широковещательные (broadcast) пакеты. Что естественно, раз хост и гостевая в разных подсетях.

[CyraxZ]

...
Насколько я понимаю, "name resolve order" - это только для WINS-сервера:
7.3.3 Setting Up Samba as a WINS Server
You can set up Samba as a WINS server by setting two global options in the configuration file, as shown below:
[global]
wins support = yes
name resolve order = wins lmhosts hosts bcast
Но на всякий случай проверил: в файле "/etc/samba/smb/conf" в секции "global" добавил строку:
name resolve order = wins lmhosts hosts bcast - не помогло.

Добавил две строки:
wins support = yes
name resolve order = wins lmhosts hosts bcast
Тоже не помогло.


Ну или роутер блокирует широковещательные (broadcast) пакеты. Что естественно, раз хост и гостевая в разных подсетях.
Поднял приоритет у "VirtualBox Host-Only Network" над "Ethernet" - в итоге в (ipconfig /all) "Адаптер Ethernet VirtualBox Host-Only Network" оказался впереди (как и со старым роутером):

PS C:\Windows\system32> Get-NetIPInterface
ifIndex InterfaceAlias AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp ConnectionState PolicyStore
------- -------------- ------------- ------------ --------------- ---- --------------- -----------
5 VirtualBox Host-Only Network IPv6 1500 25 Enabled Connected ActiveStore
15 Ethernet IPv6 1500 25 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
5 VirtualBox Host-Only Network IPv4 1500 25 Disabled Connected ActiveStore
15 Ethernet IPv4 1500 25 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected ActiveStore

PS C:\Windows\system32> Set-NetIPInterface -InterfaceIndex 15 -InterfaceMetric 35
PS C:\Windows\system32> Get-NetIPInterface

ifIndex InterfaceAlias AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp ConnectionState PolicyStore
------- -------------- ------------- ------------ --------------- ---- --------------- -----------
5 VirtualBox Host-Only Network IPv6 1500 25 Enabled Connected ActiveStore
15 Ethernet IPv6 1500 35 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
5 VirtualBox Host-Only Network IPv4 1500 25 Disabled Connected ActiveStore
15 Ethernet IPv4 1500 35 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected ActiveStore

PS C:\Windows\system32> ipconfig /all

Настройка протокола IP для Windows

Имя компьютера . . . . . . . . . : vicreal
Основной DNS-суффикс . . . . . . :
Тип узла. . . . . . . . . . . . . : Гибридный
IP-маршрутизация включена . . . . : Нет
WINS-прокси включен . . . . . . . : Нет
Порядок просмотра суффиксов DNS . : mчеКw

Адаптер Ethernet VirtualBox Host-Only Network:

DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : VirtualBox Host-Only Ethernet Adapter
Физический адрес. . . . . . . . . : 0A-00-27-00-00-05
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
Локальный IPv6-адрес канала . . . : fe80::86e:9823:1da7:6f62%5(Основной)
IPv4-адрес. . . . . . . . . . . . : 192.168.56.1(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . :
IAID DHCPv6 . . . . . . . . . . . : 185204775
DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-2C-BB-1D-5C-F4-B5-20-3E-8F-F2
DNS-серверы. . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBios через TCP/IP. . . . . . . . : Включен

Адаптер Ethernet Ethernet:

DNS-суффикс подключения . . . . . : mчеКw
Описание. . . . . . . . . . . . . : Realtek PCIe 2.5GbE Family Controller
Физический адрес. . . . . . . . . : F4-B5-20-3E-8F-F2
DHCP включен. . . . . . . . . . . : Да
Автонастройка включена. . . . . . : Да
Локальный IPv6-адрес канала . . . : fe80::c93:bef8:f91:5a51%15(Основной)
IPv4-адрес. . . . . . . . . . . . : 192.168.0.64(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Аренда получена. . . . . . . . . . : 18 января 2024 г. 19:21:04
Срок аренды истекает. . . . . . . . . . : 19 января 2024 г. 19:21:03
Основной шлюз. . . . . . . . . : 192.168.0.1
DHCP-сервер. . . . . . . . . . . : 192.168.0.1
IAID DHCPv6 . . . . . . . . . . . : 116700448
DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-2C-BB-1D-5C-F4-B5-20-3E-8F-F2
DNS-серверы. . . . . . . . . . . : 192.168.0.1
NetBios через TCP/IP. . . . . . . . : Включен
Перезагрузил виртуальную машину, перезагрузил хост-машину. Результат тот же - имя HOSTCOMPNAME гостевая машина не видит:
ping -nq -c3 \\HOSTCOMPNAME -- Debian 11: "ping: \HOSTCOMPNAME: Системная ошибка" (в логи samba ничего не пишется)
ping -nq -c3 \\HOSTCOMPNAME -- Debian 8: "ping: unknown host \HOSTCOMPNAME" (в логи samba ничего не пишется)
ping -nq -c3 192.168.0.64 -- OK
ping -nq -c3 192.168.56.1 -- OK


Ну или роутер блокирует широковещательные (broadcast) пакеты. Что естественно, раз хост и гостевая в разных подсетях.
Проверил настройки нового роутера - нет ничего связанного с широковещательными пакетами (broadcast).

[dmitryst]

нет ничего связанного с широковещательными пакетами (broadcast). »
при использовании НАТ и не будет ;) Широковещательный трафик не уходит через НАТ. Коллеги, поправьте, если это не так.

[Petya V4sechkin]

dmitryst, вообще непонятно, если бы был NAT, на Debian IP-адрес должен быть в подсети 192.168.56.0/24, а не:
внутренний IP-адрес гостевой машины (10.0.2.15

[CyraxZ]

dmitryst, вообще непонятно, если бы был NAT, на Debian IP-адрес должен быть в подсети 192.168.56.0/24, а не: ... 10.0.2.15
10.0.2.15 - это IP-адрес гостевой машины (Debian) в локальной сети 10.0.2.0/24
10.0.2.2 - это IP-адрес хост-машины (Windows 10) в локальной сети 10.0.2.0/24

[Petya V4sechkin]

10.0.2.2 - это IP-адрес Windows 10 в локальной сети 10.0.2.0/24
Но мы не видели этот адрес в ранее выложенных ipconfig /all.

[CyraxZ]

Но мы не видели этот адрес в ранее выложенных ipconfig /all.
Это локальные сети на уровне виртуальных машин. Их нужно смотреть из виртуальных (гостевых) машин.
Debian 8:
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:b2:95:32 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:feb2:9532/64 scope link
valid_lft forever preferred_lft forever

Debian 11:
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:26:e7:26 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
valid_lft 84714sec preferred_lft 84714sec
inet6 fe80::a00:27ff:fe26:e726/64 scope link
valid_lft forever preferred_lft forever

[Petya V4sechkin]

CyraxZ, значит, я заблуждался, считая VirtualBox Host-Only Network внутренним интерфейсом виртуального NAT.

Но ведь в VirtualBox шару можно сделать и через Настройки -> Общие папки? Так доступ был бы напрямую, а не через роутер.

добавил строку:
name resolve order = wins lmhosts hosts bcast - не помогло
Если не настраивали WINS, то без разницы (раньше-то работало).
По умолчанию же примерно так:
name resolve order = lmhosts host wins bcast
Странно только, что lmhosts не сработал.

Добавил в "/etc/hosts" строку "192.168.0.64 HOSTCOMPNAME".
Итог:
ping -nq -c3 \\HOSTCOMPNAME -- ошибка
ping -nq -c3 \HOSTCOMPNAME -- OK
ping -nq -c3 HOSTCOMPNAME -- OK
mount -t cifs ... '\\HOSTCOMPNAME\...' ... -- OK
Ну раз шара монтируется и доступ к ней есть, то и проблема как бы решена?

inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
А на Debian шлюз не задан? Ну типа 10.0.2.2, или я опять чего-то не понимаю?

[CyraxZ]

Но ведь в VirtualBox шару можно сделать и через Настройки -> Общие папки? Так доступ был бы напрямую, а не через роутер.
Родная файловая система VirtualBox (vboxfs) работает очень медленно. Сетевая файловая система cifs работает намного быстрее (в разы или даже на порядок).

По умолчанию же примерно так:
> name resolve order = lmhosts host wins bcast
Странно только, что lmhosts не сработал.
Так ведь настройка "name resolve order" - это же для WINS-сервера, а у меня виртуальная машина (Debian) - не WINS-сервер.
Может, в Windows 10 (WINS-сервер) нужно с порядком разрешения имён поколдовать ?

Добавил в "/etc/hosts" строку "192.168.0.64 HOSTCOMPNAME".
Итог:
ping -nq -c3 \\HOSTCOMPNAME -- ошибка
ping -nq -c3 \HOSTCOMPNAME -- OK
ping -nq -c3 HOSTCOMPNAME -- OK
mount -t cifs ... '\\HOSTCOMPNAME\...' ... -- OK
Ну раз шара монтируется и доступ к ней есть, то и проблема как бы решена?
Не совсем. Использование вместо имени HOSTCOMPNAME IP-адреса Ethernet-контроллера хост-машины на практике приведёт к тому, что при запуске виртуальной машины на другой хост-машине, либо при подключении смартфона в качестве USB-роутера или Wi-Fi-роутера (при проблемах с интернетом у провайдера) пинг и монтирование сетевой файловой системы работать не будут. А в случае использования имени HOSTCOMPNAME - будут (если удастся решить сабжевую проблему).

> inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
А на Debian шлюз не задан? Ну типа 10.0.2.2 ?
После установки Debian никаких настроек сети не выполнялось. Но шлюз по умолчанию задан да, именно такой (и в Debian 8, и в Debian 11):
ip r sh
default via 10.0.2.2 dev enp0s3
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15

[Petya V4sechkin]

строку "192.168.0.64 HOSTCOMPNAME"
А с 192.168.56.1 что, не работает? Он-то никуда не денется.
192.168.56.1 HOSTCOMPNAME

Так ведь настройка "name resolve order" - это же для WINS-сервера
Это задаёт порядок разрешения имён NetBIOS, а WINS - один из вариантов (необязательный).

[CyraxZ]

А с 192.168.56.1 что, не работает? Он-то никуда не денется.
192.168.56.1 HOSTCOMPNAME
Изначально я остановился на 192.168.0.64, т.к. со старым роутером HOSTCOMPNAME резолвился именно в этот адрес.
Но с точки зрения обеспечения работоспособности виртуальной машины в разном Интернет-окружении - да, лучше указать адрес виртуального контроллера 192.168.56.1. Если он действительно не будет меняться в тех или иных условиях.

> Так ведь настройка "name resolve order" - это же для WINS-сервера
Это задаёт порядок разрешения имён NetBIOS, а WINS - один из вариантов (необязательный).
Вообще-то да, Debian в данном случае выступает в качестве WINS-сервера, т.к. резолвит имена NetBIOS (с помощью Samba).


По умолчанию же примерно так: name resolve order = lmhosts host wins bcast
Странно только, что lmhosts не сработал.
Я создавал его в "/etc/samba/smb/conf" (этого файла там не было). Возможно, опция "name resolve order" ищет его в другом месте. Либо причина в том, что я проверял этот файл в Debian 11, а в нём попытка пинга через имя HOSTCOMPNAME завершается не сообщением "unknown host \HOSTCOMPNAME" (как в Debian 8), а ошибкой "\HOSTCOMPNAME: Системная ошибка" - возможно, при такой ошибке переход к следующему варианту разрешения имени не осуществляется (wins lmhosts hosts bcast). Либо при выполнении ping Samba не задействован вообще (я проверял только ping, вроде).

В любом случае вопрос с lmhosts больше не актуален, т.к. IP-адрес я прописал непосредственно в скрипте, выполняющем монтирование сетевой файловой системы - чтобы не "распылять" логику решения сабжевой проблемы на два места (host/lmhost и скрипт монтирования сетевой файловой системы).

[Petya V4sechkin]

Вообще-то да, Debian в данном случае выступает в качестве WINS-сервера, т.к. резолвит имена NetBIOS (с помощью Samba)
Если вы не настраивали WINS-сервер, то никто в этом качестве не выступает, а строчка wins в параметре игнорируется.

Изначально надо было задуматься, а почему со старым роутером работало? Если WINS отсутствует, broadcast не ходит в другие подсети, в hosts и lmhosts ничего не было, то что остаётся? DNS - в настройках старого роутера можете поискать, где вручную сопоставляли HOSTCOMPNAME.

[CyraxZ]

Если вы не настраивали WINS-сервер, то никто в этом качестве не выступает, а строчка wins в параметре игнорируется.
7.3.3 Setting Up Samba as a WINS Server
You can set up Samba as a WINS server by setting two global options in the configuration file, as shown below:
[global]
wins support = yes
name resolve order = wins lmhosts hosts bcast

Если для настройки Samba в качестве WINS-сервера достаточно двух строчек в "/etc/samba/smb/conf":
wins support = yes
name resolve order = wins lmhosts hosts bcast
то в момент проверки lmhosts с именем HOSTCOMPNAME Samba у меня работал в качестве WINS-сервера и lmhosts должен был подхватываться:
Я создавал его в "/etc/samba/smb/conf" (этого файла там не было). Возможно, опция "name resolve order" ищет его в другом месте. Либо причина в том, что я проверял этот файл в Debian 11, а в нём попытка пинга через имя HOSTCOMPNAME завершается не сообщением "unknown host \HOSTCOMPNAME" (как в Debian 8), а ошибкой "\HOSTCOMPNAME: Системная ошибка" - возможно, при такой ошибке переход к следующему варианту разрешения имени не осуществляется (wins lmhosts hosts bcast). Либо при выполнении ping Samba не задействован вообще (я проверял только ping, вроде).
Если для настройки Samba в качестве WINS-сервера двух строчек в "/etc/samba/smb/conf" недостаточно, то Samba у меня в качестве WINS-сервера не работал, параметр "name resolve order" не работал и "lmhosts" поэтому не подхватывался.


DNS - в настройках старого роутера можете поискать, где вручную сопоставляли HOSTCOMPNAME.
В настройках старого роутера HOSTCOMPNAME не прописывался. На старом ПК (http://forum.oszone.net/thread-354400.html) с совсем другим именем компьютера на том же старом роутере всё работало (с другим именем компьютера в команде пинга и в команде монтирования сетевой файловой системы).

Изначально надо было задуматься, а почему со старым роутером работало? Если WINS отсутствует, broadcast не ходит в другие подсети, в hosts и lmhosts ничего не было, то что остаётся?
WINS работал. Только не через "name resolve order" в "/etc/samba/smb/conf", а через winbind + добавление "wins" параметру "hosts" в "/etc/nsswitch.conf":
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: files systemd
group: files systemd
shadow: files
gshadow: files

hosts: files dns wins
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

[Petya V4sechkin]

CyraxZ, ради интереса можно посмотреть, как со старым и новым роутером происходит разрешение имени из Debian:
nmblookup HOSTCOMPNAME
nmblookup --name-resolve=bcast HOSTCOMPNAME
nmblookup --name-resolve=wins HOSTCOMPNAME
nmblookup --name-resolve=host HOSTCOMPNAME
nmblookup --name-resolve=lmhosts HOSTCOMPNAME
и трассировку (traceroute или типа того: действительно ли VirtualBox пускает маршрут из виртуалки до хоста через роутер).

В настройках старого роутера HOSTCOMPNAME не прописывался. На старом ПК с совсем другим именем компьютера на том же старом роутере всё работало
Вероятно, DIR-300 использует свой же DHCP Client List как локальный источник для DNS.