LINUX.ORG.RU
решено ФорумAdmin

Гостевая виртуальная машина с Debian не получает IP-адрес по DHCP. В чём может быть загвоздка?

 , , ,


0

1

Здравствуйте, господа. На ПК с Windows 7 установлена VMWare Workstation 14.1.2. Создана виртуалка и установлен на неё Debian 8 («Jessie»). Хост с виндой подключается к Интернет по Wi-Fi. Для виртуалки выбран тип подключения к сети - VMnet0 (мост), где указан используемый Wi-Fi-адаптер.

Скриншот 1
Скриншот 2
Скриншот 3

Как заставить гостевой Debian подключаться к сети по DHCP в режиме моста? Самое интересное, что если выбрать тип подключения VMnet1 (Только для узла) или VMnet8 (NAT), то система благополучно подключается к сети.


Ответ на: комментарий от Riniko

Не установлено у меня Ъ, но есть логи dhclient. Содержимое /var/log/dhclient.log

Jul 11 15:55:47 vmware dhclient: Internet Systems Consortium DHCP Client 4.3.1
Jul 11 15:55:47 vmware dhclient: Copyright 2004-2014 Internet Systems Consortium.
Jul 11 15:55:47 vmware dhclient: All rights reserved.
Jul 11 15:55:47 vmware dhclient: For info, please visit https://www.isc.org/software/dhcp/
Jul 11 15:55:47 vmware dhclient: 
Jul 11 15:55:47 vmware dhclient: Listening on LPF/eth0/00:0c:29:a8:cc:67
Jul 11 15:55:47 vmware dhclient: Sending on   LPF/eth0/00:0c:29:a8:cc:67
Jul 11 15:55:47 vmware dhclient: Sending on   Socket/fallback
Jul 11 15:55:47 vmware dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Jul 11 15:55:47 vmware dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Jul 11 15:55:47 vmware dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
Jul 11 15:55:47 vmware dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 21
Jul 11 15:55:47 vmware dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
Jul 11 15:55:47 vmware dhclient: No DHCPOFFERS received.
Jul 11 15:55:47 vmware dhclient: No working leases in persistent database - sleeping.

Sferg ()
Ответ на: комментарий от Sferg

Jul 11 15:55:47 vmware dhclient: No DHCPOFFERS received.

Ну тебе намекают, что никто никаких адресов не предлагал.

Иди на dhcp сервер и смотри -

1. Доходят ли до него реквесты
2. Отсылает ли он ответ (и какой)

zgen ★★★★★ ()
Ответ на: комментарий от zgen

Дык если в свойствах сетевого адаптера у виртуалки сменить тип подключения с VMnet0 (мост) на VMnet1 (Только для узла) или VMnet8 (NAT), то Debian получает-таки свой адрес у DHCP и всё благополучно подключается.

Дело в том, что мне не нужен ни узел, ни NAT. Нужен мост.

Sferg ()
Ответ на: комментарий от Sferg

в тех случаях клиент получает ответ от dhcp сервера самого хоста внутри вирт сегмента хост машины. в случае бриджа запрос уходит наружу и ответ должен быть получен от внешнего dhcp сервера. нужно проверить, уходит ли запрос за пределы хост машины и видны ли запросы на внешнем dhcp сервере от мака вирт машины.

anonymous ()
Ответ на: комментарий от Sferg

Тогда не удалось поумничать. У длинков часто бывает, что адрес выдают 2-3 клиентам, а дальше уже не выдают.

Deleted ()

У меня с виртуалками были такие проблемы, виной тому оказывался плохой клиент dhcp. Проблему решал самопальной сборкой свежего клиента и подменой бинаря.

Deleted ()
Ответ на: комментарий от anonymous

Логи с внешнего DHCP-сервера /var/log/dhcpd.log:

Jul 11 17:20:06 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (vmware) via br0
Jul 11 17:20:07 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (vmware) via br0
Jul 11 17:20:11 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (vmware) via br0
Jul 11 17:20:11 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (vmware) via br0
Jul 11 17:20:24 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (vmware) via br0
Jul 11 17:20:24 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (vmware) via br0
Jul 11 17:20:32 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (vmware) via br0
Jul 11 17:20:32 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (vmware) via br0
Jul 11 17:20:42 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (vmware) via br0
Jul 11 17:20:42 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (vmware) via br0
Jul 11 17:20:57 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (vmware) via br0
Jul 11 17:20:57 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (vmware) via br0

MAC с виртуальной машины в логах засветился, но подключения не состоялось.

Sferg ()
Ответ на: комментарий от Sferg

Прописал в /etc/network/interfaces следующее:

auto eth0
iface eth0 inet static
address 192.168.0.13
netmask 255.255.0.0
broadcast 192.168.255.255
gateway 192.168.0.1
dns-nameservers 77.88.8.2 77.88.8.88

Успешно подключилось. Непонятно, почему по DHCP не желает.

Sferg ()
Ответ на: комментарий от Sferg

Непонятно в этой ситуации ещё и то, что все остальные устройства благополучно подключаются по DHCP, а конкретно эта виртуалка не хочет - если только по статичному IP.

Sferg ()
Ответ на: комментарий от Sferg

В этом роутере может какие-то логи полезные есть ?
Или можно tcpdump запустить.

Deleted ()

Яннп. Ты хочешь на одну сетевку дважды получить адрес по dhcp? Это crazy skillz или особая магия? Посмотри макадрес в госте и макадрес на хосте, сравни, подумай.

Anoxemian ★★★★★ ()
Ответ на: комментарий от Sferg
Jul 11 17:20:06 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (vmware) via br0
Jul 11 17:20:07 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (vmware) via br0

У тебя и на внешнем сервере какой-то мост настроен? И откуда он знает что этот мак - это vmware? Что-то не так, не сходится с описанием. Но вангую что оффер приходит на хост у которого все хорошо.

Anoxemian ★★★★★ ()
Ответ на: комментарий от anonymous

Вангую, что твой WiFi адаптер не умеет в неразборчивый режим.

Что-то на физическом уровне, однозначно.

Anoxemian ★★★★★ ()
Ответ на: комментарий от Anoxemian

Да, на сетевом шлюзе мост настроен. Этот мак в настройках VMWare прописан.

Скриншот

Вероятно, при попытке подключения себя идентифицирует. На виртуалке в Debian у меня в качестве hostname указано vmware.

Sferg ()
Последнее исправление: Sferg (всего исправлений: 1)
Ответ на: комментарий от Sferg

Повторю: шлюз откуда знает, что этот мак - vmware? Или это имя хоста? Т.е. оффер идет к хосту, посмотри трафик с гостя, доходят ли офера.

Anoxemian ★★★★★ ()
Ответ на: комментарий от Anoxemian

Сменил на госте содержимое /etc/hostname на testing. Вывод лога /var/log/dhcpd.log на сетевом шлюзе:

Jul 12 00:21:44 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 00:21:45 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 00:21:51 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 00:21:51 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 00:22:00 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 00:22:00 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 00:22:19 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 00:22:19 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 00:22:40 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 00:22:40 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (testing) via br0 

Похоже, что в скобках это действительно hostname.

Sferg ()
Последнее исправление: Sferg (всего исправлений: 3)
Ответ на: комментарий от Anoxemian

Нет, ничего не приходит. Как следствие, подключения не происходит. Синхронизировал логи гостевой системы и внешнего DHCP-сервера на сетевом шлюзе.

Логи гостя:

Jul 12 11:16:55 testing dhclient: Listening on LPF/eth0/00:0c:29:a8:cc:67
Jul 12 11:16:55 testing dhclient: Sending on   LPF/eth0/00:0c:29:a8:cc:67
Jul 12 11:16:55 testing dhclient: Sending on   Socket/fallback
Jul 12 11:16:55 testing dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
Jul 12 11:16:55 testing dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
Jul 12 11:16:55 testing dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Jul 12 11:16:55 testing dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 19
Jul 12 11:16:55 testing dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
Jul 12 11:16:55 testing dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
Jul 12 11:16:55 testing dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Jul 12 11:16:55 testing dhclient: No DHCPOFFERS received.
Jul 12 11:16:55 testing dhclient: No working leases in persistent database - sleeping.

Логи внешнего DHCP-сервера:

Jul 12 11:15:54 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:15:55 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:15:57 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:15:57 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:16:00 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:16:00 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:16:07 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:16:07 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:16:26 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:16:26 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:16:39 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:16:39 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:16:47 atom dhcpd: DHCPDISCOVER from 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:16:47 atom dhcpd: DHCPOFFER on 192.168.0.32 to 00:0c:29:a8:cc:67 (testing) via br0
Jul 12 11:17:07 atom dhcpd: DHCPREQUEST for 192.168.0.104 from **:**:**:**:**:** (ASUS-i7) via br0
Jul 12 11:17:07 atom dhcpd: DHCPACK on 192.168.0.104 to **:**:**:**:**:** (ASUS-i7) via br0
Jul 12 11:19:09 atom dhcpd: DHCPINFORM from 192.168.0.104 via br0: not authoritative for subnet 192.168.0.0
Jul 12 11:19:12 atom dhcpd: DHCPINFORM from 192.168.0.104 via br0: not authoritative for subnet 192.168.0.0

Sferg ()
Ответ на: комментарий от Anoxemian

Интереса ради попробовал подключить другой WiFi-адаптер (USB). С ним гостевая система успешно подключается по DHCP. Странно, что основной WiFi-адаптер не подключается, а какой-то USB-свисток от D-Link справился.

Sferg ()
Ответ на: комментарий от Sferg

В общем, проблема была в драйверах на этот самый WiFi-адаптер. Поставил старую версию - и всё заработало исправно.

Sferg ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.