TL; DR: хост может пропинговать гостевую виртуальную машину, подключенную через NAT, когда IP-адрес DHCP используется на гостевой, не может, когда используется статический ip. Помогите.

Поэтому я пытался настроить локальную сеть на основе NAT, с которой хост мог бы общаться, где каждая виртуальная машина имеет статический IP-адрес. Согласно документации VMware, к виртуальному коммутатору vmnet подключен адаптер хоста, который отображается как «vmnet #» (где # - номер адаптера) в выводе ifconfig хоста. Используя этот виртуальный интерфейс, хост может пинговать и связываться с гостевыми виртуальными машинами, подключенными к тому же виртуальному коммутатору vmnet #.

Сначала я создал новый виртуальный коммутатор vmnet10. Я настроил его на использование IP-адреса подсети 10.0.99.0/24 (NetMask: 255.255.255.0), устройства NAT с IP- 10.0.99.2 и DHCP-сервера (который, согласно документации VMware, находится на 10.0.99.254). Я не изменил автоматические настройки DHCP, поэтому диапазон 10.0.99.128 - 10.0.99.253 - это динамические IP-адреса DHCP, а 10.0.99.3 - 10.0.99.127 - это IP-адреса, которые я могу назначать статически. Вот где начинается проблема.

Когда гость виртуальной машины получает свой IP-адрес от сервера DHCP (10.0.99.128), к нему подключается хост-адаптер, а 10.0.99.1 может пропинговать 10.0.99.128 и наоборот. Однако, если я изменяю IP вручную через nmtui (генерируя следующий файл /etc/sysconfig/network-scripts/ifcfg-ens33 ), даже если виртуальный компьютер все еще может получить доступ к Интернету и пинговать другие виртуальные машины, хост не сможет достичь это и наоборот. В чем дело? Это из-за того, что я не запрашивал у DHCP-сервера статический IP-адрес?! Как это исправить?

Дамп конфигурации для систем, описанных выше, можно найти по этому адресу.

|источник

1 ответ1

1

РЕДАКТИРОВАТЬ: метод ниже может быть или не быть необходимым - однако, этот конкретный шаг является обязательным На гостевых интерфейсах необходимо создать статический маршрут, поскольку существующая таблица маршрутизации может быть неправильной. Моя изначально выглядела так:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.99.2       0.0.0.0         UG    100    0        0 ens33
10.0.99.2       0.0.0.0         255.255.255.255 UH    100    0        0 ens33
10.0.99.11      0.0.0.0         255.255.255.255 UH    100    0        0 ens33
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

Для этого необходимо создать файл /etc/sysconfig/network-scripts/route-ens33 (route- interface) с синтаксисом:

default 10.0.99.2 dev ens33
10.0.99.0/24 dev ens33

Где 10.0.99.2 - это IP-адрес шлюза (устройства VMware NAT), а 10.0.99.0/24 - подсеть, в которой существуют статические IP-адреса, т. Е. Подсеть LAN. После этого шага интерфейс должен быть перезапущен с помощью nmcli c d ens33; nmcli c u ens33 . Таблица маршрутизации ядра теперь должна выглядеть так:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.99.2       0.0.0.0         UG    100    0        0 ens33
10.0.99.0       0.0.0.0         255.255.255.0   U     100    0        0 ens33
...

Таким образом, оказывается, что мы должны назначить статический IP-адрес гостевым виртуальным машинам, даже если гости не работают с DHCP. Таким образом, dhcpd.conf для виртуального коммутатора должен иметь записи для каждого статического IP-адреса. Поскольку я использовал vmnet10 , я отредактировал файл /etc/vmware/vmnet10/dhcpd/dhcpd.conf и добавил:

...
####### VMNET DHCP Configuration. End of "DO NOT MODIFY SECTION" #######

####### VMNET Static IP Allocation Table by Somu                 #######
host vmInfra.somuVMnet.local {
    hardware ethernet 00:0C:29:79:8C:1F;
    fixed-address 10.0.99.99;
}

host vmPrime.somuVMnet.local {
    hardware ethernet 00:0C:29:3B:B9:1C;
    fixed-address 10.0.99.11;
}

host vmDeux.somuVMnet.local {
    hardware ethernet 00:0C:29:2A:E2:D3; 
    fixed-address 10.0.99.12;
}

Обратите внимание, что каждый MAC-адрес соответствует виртуальным NIC, назначенным для каждой виртуальной машины. Эти конфиги следует добавить после выключения виртуальных машин и выключения самой рабочей станции vmware.

Наконец, после того, как конфигурация была сохранена, так как служба dhcp работает на хост-компьютере, их необходимо перезапустить. Поскольку я не мог найти отдельную службу для каждой виртуальной машины, я просто перезапустил vmware.service на самом хосте. Обратите внимание, что я использую systemd так как я нахожусь на Fedora 27. Этот метод должен одинаково хорошо работать и в ОС System V, даже если команда будет другой. 

systemctl restart vmware; systemctl status -l vmware

Убедитесь, что служба активна, а затем включите гостя. Теперь, если вы настроили свою виртуальную машину на статический IP-адрес, она должна соответствовать IP- адресу, заданному вами в dhcpd.conf чтобы избежать конфликтов. Если вы используете автоматическую настройку на основе DHCP, это совсем не проблема, поскольку DHCP-сервер теперь назначит конкретный запрошенный вами IP-адрес на основе адреса MAC виртуального сетевого адаптера!

Я надеюсь, что этот ответ поможет кому-то, кто застрял в подобной ситуации, и сэкономит им бесчисленные часы поиска. Обратите внимание, что мне не нужно было выключать брандмауэр ни на хосте, ни на госте!

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .