Ответы DHCP не доходят до виртуальных машин VMware через Wi-Fi

Ответы DHCP не доходят до виртуальных машин VMware через Wi-Fi, UniFi Network

eproxus

Guest

12.02.2018 15:41:00

После обновления моего CloudKey до версии 5.7.15 (Build: atag_5.7.15_10517) и прошивок всех устройств, мои виртуальные машины VMware Fusion больше не получают IP-адреса. До обновления они нормально получали адреса по DHCP. Все настроены в режиме мостового подключения (bridged mode), то есть должны выглядеть в сети как отдельные устройства. Сейчас у меня стоят следующие версии прошивок и ПО:

CloudKey 5.7.15 (Build: atag_5.7.15_10517)
UniFi Security Gateway 3P 4.4.18.5052168
UniFi Switch 8 POE-150W 3.9.21.8191
UniFi AP-AC-Pro 3.9.21.8191
Хост: macOS 10.13.3 и VMware Fusion Professional Version 10.1.1 (7520154)
Гость: Ubuntu 64-bit Server 17.10

Если я трассирую запросы DHCP с помощью tcpdump на виртуальной машине, хосте, AP и USG, то вижу, что запросы DHCP доходят до USG, там генерируется ответ, он возвращается к AP, но дальше до хоста уже не доходят, соответственно виртуальная машина тоже не получает ответ. Если хост подключить напрямую по Ethernet к свитчу, всё работает как надо. Никакие настройки DHCP или сети вручную после обновления не менялись.

Я приложил схему сети с информацией об устройствах и конфигурацию сети LAN, которую настроил.

Я совсем не понимаю, что дальше проверять… Вижу DHCP-ответы на AP, но они не доходят до хоста, и почему — не ясно. Может, кто-нибудь знает, поменялась ли в последней прошивке AP логика работы с DHCP? Или добавилась какая-то проверка, из-за которой ломаются виртуальные машины в режиме моста?

kmfurdm

Guest

04.09.2018 18:42:00

Не хочется снова поднимать этот вопрос, но я много искал решения и ничего не нашёл. Раньше я использовал некоторые виртуальные машины (Fusion) на проводном ethernet-компе, а теперь работаю с MacBook Pro, который время от времени использую по беспроводной сети дома. На работе, где стоит оборудование Cisco (Meraki), никаких проблем — машина нормально подключается по Wi-Fi, и виртуальная машина получает IP по DHCP в режиме мостового соединения. А дома это не работает — могу заставить виртуалки работать, только если вручную прописать IP, а DHCP вообще не хотят брать.

USG = 4.4.22.5086045
USW = 3.9.50.9295
AP AC Pro = 3.9.50.9295

mobeustech Guest	#3 22.03.2018 16:19:00 После переключения это не сработало. В итоге мне пришлось проделать то же самое и с точками доступа.

mobeustech Guest	#4 22.03.2018 16:19:00 Я перепробовал все версии вплоть до 3.7.35.6029, и только с этой всё заработало.

UI-Team

Guest

22.03.2018 16:16:00

Спасибо. Какие версии ты пробовал между ними? Давай пока сосредоточимся только на переключателе и проводном подключении, так как я подозреваю, что именно в них проблема, и исключение Wi-Fi сильно сузит количество переменных.

mobeustech Guest	#6 21.03.2018 21:34:00 Хорошо, мне пришлось понизить прошивку всех USW и UAP до версии 3.7.35.6029, чтобы виртуальные машины или Microsoft Virtual Bridges смогли получать DHCP. Это прошивка от 16 января 2017 года. Очень старенькая, если честно.

UI-Team

Guest

21.03.2018 20:40:00

Хорошо, это уже сужает круг. Дело точно не в контроллере, он не может вызвать такую проблему. Очень маловероятно, что это из-за USG. Ты знаешь, какую версию прошивки на коммутаторе стояла раньше? Если да, попробуй просто откатить прошивку коммутатора на ту версию. Если нет, то можно попробовать последнюю версию из серии 3.8.x — она обычно подходит.
https://community.ui.com/releases/54a46c6c-de51-4375-a773-48b217b316ae

mobeustech

Guest

21.03.2018 20:21:00

Я выяснил, что проблема не в точке доступа. Только что попробовал на другой машине с проводным подключением. Я создал мост между двумя Ethernet-подключениями, и мост не получал IP от DHCP. Скорее всего, дело либо в контроллере, либо в USG, либо в настройках свитча.

UI-Team

Guest

21.03.2018 20:04:00

Теперь я начинаю думать, что тут что-то другое. В последний раз, когда это случалось несколько месяцев назад, всё было, как я описывал выше. Здесь, похоже, задействовано больше людей, чем просто пара ненадёжных систем с той проблемой.

Мне интересно, не вызывает ли это какой-то баг в DHCP snooping на коммутаторе или что-то на AP. USG, скорее всего, не при чём.

Сначала бы я подключился по SSH к AP и посмотрел, какой DHCP-трафик там есть или чего нет. Запустить команду:
tcpdump -vnei eth0 port 67
Потом заставить гостя обновить аренду — что там будет показано?

eproxus

Guest

#10

21.03.2018 09:49:00

Это происходит только после обновления контроллера с версии 5.6 до 5.7, включая рекомендованную прошивку для всех устройств. В контроллере версии 5.6.30-10266 всё работает идеально (USG 4.4.18.5052168, Switch 8 PoE-150W 3.9.19.8123, AP-AC-Pro 3.9.19.8123).

mobeustech

Guest

#11

21.03.2018 00:10:00

Нет, это не была ad-hoc сеть. Всё работает нормально при подключении к оборудованию Cisco, Fortinet или Extreme. Какие команды и где их нужно запускать? В этой сети используются CloudKey, USG Pro, коммутатор Unifi 16POE SW, точки доступа Unifi AP Pro, Unifi Mesh AP Pro и Unifi Mesh AP.

UI-Team

Guest

#12

21.03.2018 00:01:00

Это может быть временная сеть или использование сети NAT VM, среди прочих возможных отличий. Проверьте MAC-адрес источника в запросе и MAC-адрес получателя в ответе: если это реальные MAC-адреса виртуальной машины, а не MAC-адреса Wi-Fi-адаптера, то вот в чем причина.

mobeustech Guest	#13 20.03.2018 23:54:00 Проблема в том, что когда я использую оборудование других производителей, она не возникает. Например, когда я подключаюсь к MacBook Pro через мобильный хотспот моего телефона, всё работает как надо.

UI-Team

Guest

#14

20.03.2018 23:48:00

В описанном сценарии гипервизор должен преобразовывать исходный MAC-адрес в MAC-адрес Wi-Fi сетевой карты хоста, потому что STA может использовать только этот один исходный MAC (все Wi-Fi так устроены по своей природе). В предыдущих случаях описанной проблемы все заканчивалось тем, что Fusion не выполнял это преобразование MAC.

mobeustech Guest	#15 20.03.2018 23:44:00 Не уверен, решился ли этот вопрос, но у меня та же самая проблема.

Читают тему (гостей: 1)