Kvm хост не пингует виртуалку

Обновлено: 04.07.2024

24 фев 2020, 15:46

Есть виртуальная машина (ВМ) с Win7. Основная машина - KDE Neon 5.18. ВМ реализована через KVM + libvirt + virt-manager. Сейчас в ВМ интернет работает через NAT, хост и ВМ пингуются. Я хочу понять, как правильно сделать соединение с работающей локалкой, но без доступа в ВМ интернета? Текущая:
KDE Neon 5.22
Предыдущая:
Linux Mint 19.1 Cinnamon
Железо:
Intel Core i3-6100 CPU @ 3.7 ГГц x2, 16Гб ОЗУ

Настройка сети между хостом и ВМ без интернета для KVM

24 фев 2020, 16:51

Kurum , в вм шлюз и днс убери и не будет тебе тырнета.

Настройка сети между хостом и ВМ без интернета для KVM

24 фев 2020, 19:23

Так локалка перестаёт работать, пинга с хостом нет.
IP-адрес и маску прописывал вручную (какие ВМ получала автоматически), ну а шлюз и днс пустые.

=====
Вообще, я хочу сделать данную настройку на хосте, а не внутри ВМ.

Текущая:
KDE Neon 5.22
Предыдущая:
Linux Mint 19.1 Cinnamon
Железо:
Intel Core i3-6100 CPU @ 3.7 ГГц x2, 16Гб ОЗУ

Настройка сети между хостом и ВМ без интернета для KVM

24 фев 2020, 19:36

Kurum , ну без прокси или iptables чисто на хосте хз как. а так можешь выбрать мост, а не нат - получишь сквозную адресацию на вм и очистка шлюза и днс будет работать как положено

Настройка сети между хостом и ВМ без интернета для KVM

24 фев 2020, 20:13

Я хочу понять, как правильно сделать соединение с работающей локалкой, но без доступа в ВМ интернета? Проще всего из правильных решений - создать отдельную сеть в настройках virt-manager. При создании выбрать режим сети Isolated. Если у виртуальной машины будет подключение к этой сети - общаться она будет только с хостом и другими VM подключеными к этой же сети.

Настройка сети между хостом и ВМ без интернета для KVM

24 фев 2020, 20:16

В virt-manager в списке сетевых интерфесов нет моста. Там:
1. NAT
2. Устройство хоста - сетевая карта 1
3. Устройство хоста - сетевая карта 2
4. Общее устройство.
Т.е. мост надо ручками создавать. Проблема ещё в том, что я не нашёл нормального мануала, как это вообще делается. Проще всего из правильных решений - создать отдельную сеть в настройках virt-manager. При создании выбрать режим сети Isolated. Если у виртуальной машины будет подключение к этой сети - общаться она будет только с хостом и другими VM подключеными к этой же сети. Да, я как-раз ищу правильное решение. Можете посоветовать литературу, где описано, как сделать то, что Вы предлагаете? Текущая:
KDE Neon 5.22
Предыдущая:
Linux Mint 19.1 Cinnamon
Железо:
Intel Core i3-6100 CPU @ 3.7 ГГц x2, 16Гб ОЗУ

Настройка сети между хостом и ВМ без интернета для KVM

24 фев 2020, 20:21

Настройка сети между хостом и ВМ без интернета для KVM

24 фев 2020, 20:23

Да там не надо никакой литературы. Просто через GUI мышекликами, с окна где список всех VM, для русской локали:
Правка -> Свойства подключения -> Виртуальные Сети -> (внизу слева) кнопка "+", всплывающая подсказка "создание виртуальной сети".

Настройка сети между хостом и ВМ без интернета для KVM

25 фев 2020, 07:06

enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.3.102 netmask 255.255.255.0 broadcast 192.168.3.255
inet6 fe80::c26f:3036:ec5a:a5df prefixlen 64 scopeid 0x20<link>
ether 00:1e:58:af:89:70 txqueuelen 1000 (Ethernet)
RX packets 10111 bytes 10982804 (10.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8303 bytes 1267555 (1.2 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

virbr1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.123.1 netmask 255.255.255.0 broadcast 192.168.123.255
ether 52:54:00:83:d4:f2 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

В результате сеть в ВМ не работает вообще. Явообще не понимаю, как она может работать, когда с маской 255.255.255.0 и IP 192.168.123.1 в обычной сети нельзя выйти на IP 192.168.3.102.
Первую ссылку я находил, но понятной для меня она не является. Создаётся код, что он делает каждая строчка - не ясно. А вот вторая ссылку - уже интересно, если через virt-manager не получится, то буду эту статью разбирать.

Настройка сети между хостом и ВМ без интернета для KVM

25 фев 2020, 13:29

У хоста теперь две сетевых карты и два адреса. Один 192.168.3.102 - это для обычной сети, он и раньше был. Второй 192.168.123.1 - это для изолированной локалки виртуальных машин. Если надо из этой локалки обратится к хосту - стучаться нужно именно на 192.168.123.1, адрес 192.168.3.102 просто так не доступен оттуда. Если надо сделать частичное нарушение изоляции и иметь доступ к каким-то машинами сети 192.168.3.0/255 из изолированной сети 192.168.123.0/255 - это уже через iptables надо форвардинг или NAT настраивать на хосте. Но тут уже проще использовать вариант сети с NAT который был раньше, и изоляцией там разумеется не пахнет.

P.S. Было бы проще что-то советовать, если бы задача была описана полностью. Возможно, она просто решается опять не с того бока. Чего именно нужно достичь отрезая машину с Win7 от интернета? Чтобы с нее нельзя было в интернет выйти вообще? Или чтобы на нее из интернета доступа не было (от атакующих "из вне")? А для локальной сети 192.168.3.0/255 - должны машины из нее видеть эту VM? И должна ли VM ходить в сеть 192.168.3.0/255?

Настройка сети между хостом и ВМ без интернета для KVM

25 фев 2020, 20:06

. имеется в виду что виртуальная машина подключенная к изолированной сети вообще никакой IP ардес не получает, и не может пинговать (и соответственно обращаться) к 192.168.123.1 - то где-то что-то не сработало в virt-manager. Пингую с ВМ: ping 192.168.123.1 - > получаю генеральный отказ, сбой передачи
Пингую с хоста: : ping 192.168.123.2 - > узел назначения недоступен.
Может мне нужно сделать вывод каких-то настроек?
Я хочу полностью заблокировать все соединения из ВМ в интернет (дабы никакие пакеты не могли выскочить - для выполнения этой задачи самой винде я не доверяю), но мне нужна сеть с хостом для чтения/записи данных. Собственно всё. Текущая:
KDE Neon 5.22
Предыдущая:
Linux Mint 19.1 Cinnamon
Железо:
Intel Core i3-6100 CPU @ 3.7 ГГц x2, 16Гб ОЗУ

Настройка сети между хостом и ВМ без интернета для KVM

25 фев 2020, 20:36

Я хочу полностью заблокировать все соединения из ВМ в интернет (дабы никакие пакеты не могли выскочить - для выполнения этой задачи самой винде я не доверяю), но мне нужна сеть с хостом для чтения/записи данных. Собственно всё.

Это должно было работать сразу. Обращения к 192.168.123.1 должны быть доступны из VM сразу после запуска изолированной сети.

Покажите вывод команд ip a , ip r и sudo iptables -L у хоста, и ipconfig /all и route print -4 у VM (там же сейчас винда? Если нет - то вывод тех же команд как у хоста).

Настройка сети между хостом и ВМ без интернета для KVM

25 фев 2020, 22:55

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: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether xxx brd ff:ff:ff:ff:ff:ff
inet 192.168.3.102/24 brd 192.168.3.255 scope global dynamic noprefixroute enp4s0
valid_lft 6779sec preferred_lft 6779sec
inet6 fe80::c26f:3036:ec5a:a5df/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: enp5s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether xxx brd ff:ff:ff:ff:ff:ff
4: virbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether xxx brd ff:ff:ff:ff:ff:ff
inet 192.168.123.1/24 brd 192.168.123.255 scope global virbr1
valid_lft forever preferred_lft forever
5: virbr1-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr1 state DOWN group default qlen 1000
link/ether xxx brd ff:ff:ff:ff:ff:ff
6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether xxx brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
7: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
link/ether xxx brd ff:ff:ff:ff:ff:ff
8: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master virbr1 state UNKNOWN group default qlen 1000
link/ether xxx brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe70:fe94/64 scope link
valid_lft forever preferred_lft forever default via 192.168.3.1 dev enp4s0 proto dhcp metric 100
169.254.0.0/16 dev enp4s0 scope link metric 1000
192.168.3.0/24 dev enp4s0 proto kernel scope link src 192.168.3.102 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
192.168.123.0/24 dev virbr1 proto kernel scope link src 192.168.123.1

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 ctstate RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
ACCEPT udp -- anywhere anywhere udp dpt:bootpc

Я перевожу виртуальную машину kvm со старого хоста (как аппаратного, так и операционного) на новый.

Для работы в сети virt-manager предложил мне новую опцию: macvtap . Это выглядело хорошей альтернативой настройке моста на eth0.

Так что теперь гость загружается просто отлично, получает IP-адрес от моего локального сетевого DHCP-сервера, может выйти в Интернет. Гость также видит другие машины в локальной сети, я могу ssh их и т. Д.

Вот route -n команда с хоста:

(тот же вывод от гостя).

Я мог бы, вероятно, настроить новый интерфейс tun / tap, предназначенный для связи между хостом и гостем, но это выглядит немного излишним. Есть ли способ заставить хозяина и гостя общаться?

Macvtap не является допустимой заменой мостов. Если вы хотите переключение, а не мостовое соединение, посмотрите на openvswitch.

Я задал этот вопрос на IRC, и кажется, что Macvtap

вводит гостевой трафик в сетевой стек, слишком низкий для этого

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

virt-manager прямо говорит, что при настройке macvtap не работает связь между хостом и гостевой сетью. Я просто добавил второй интерфейс на основе nat, настроил его в гостевой системе и использовал его для связи с моим хостом.

Решение состоит в том, чтобы настроить интерфейс macvlan на гипервизоре с тем же IP-адресом, что и реальный аппаратный интерфейс (очень важно), и настроить маршрутизацию на хосте для его использования. В Qemu / KVM используйте интерфейс macvtap на аппаратном интерфейсе как обычно.

Для моей конфигурации (сеть 192.168.1.0/24, аппаратный интерфейс p10p1 и шлюз 192.168.1.1) это дает (на гипервизоре):

Как уже упоминалось в предыдущих ответах, решение этой проблемы заключается в добавлении сетевого адаптера macvlan на хост. Тем не менее, я чувствовал, что ручная переподключение маршрутов к адаптеру macvlan было довольно хакерским, тем более что я хотел, чтобы поддержка IPv6 и ручная настройка маршрутов могли стать проблемой при изменении префикса. Итак, вот моя конфигурация, которая оставляет ядро под контролем таблицы маршрутизации:

_{(Конкретная конфигурация здесь специфична для Debian и Upstart, но основные шаги должны работать на любом GNU / Linux.)}

Создание адаптера macvlan при загрузке

Сначала вам нужно выбрать MAC-адрес для вашего адаптера. Вы можете использовать случайный, но я предлагаю вам вручную создать адаптер macvlan и использовать его MAC. Таким образом, MAC обязуется любые соглашения, которые могут быть там.

Рекомендуется установить фиксированный MAC-адрес, поскольку в противном случае, например, DHCP-сервер не сможет распознать ваш компьютер после перезагрузки и назначить ему тот же IP-адрес, что и раньше.

Итак, создайте адаптер и найдите MAC:

Выделенное шестнадцатеричное число - ваш MAC-адрес.

Теперь вы создаете сценарий инициализации - который должен быть запущен до инициализации сети - для создания адаптера macvlan при каждом запуске. Команда для этого:

Пример сценария инициализации Upstart для этой цели:

Просто вставьте это, например /etc/init/macvlan.conf .

Настройка конфигурации сети

В /etc/network/interfaces настройте физический сетевой адаптер на ручной (но оставьте его автоматическим) и перенесите его предыдущую конфигурацию (обычно DHCP или статический IP-адрес) на ваш адаптер macvlan. Например:

Отключение IPv6 для физического адаптера

Наконец, вы не хотите, чтобы физический адаптер получал IP-адрес. Для IPv4 установка адаптера на ручной режим не позволяет ему получить адрес. Однако я не нашел конфигурацию, которая мешает ядру получить / назначить IPv6-адрес для / адаптеру. Когда это происходит, он также добавляет маршруты для них, что может вызвать проблемы. Таким образом, лучший способ - отключить IPv6 для физического адаптера. Вы можете сделать это, добавив строку

чтобы /etc/sysctl.conf , создав файл /etc/sysctl.d/ с этой строкой, или добавив

на ваш сценарий инициализации.

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

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

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

VMware Technology Network
:
Global
:
Russian
:
Russian Discussions
:
Не пингуется виртуальная машина

BorisGun

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Здравствуйте, моя проблема заключается в том что если тип сети поставить "мостовой" или NAT то виртуальная машина не пингуется с хостовой машины. Таким образом хотелось бы узнать как наладить локальную сеть между хостовой и вирт. машиной. Так же хотелось спросить можно ли наладить сеть таким образом чтобы хостовая машина получала интернет траффик через виртуальную.

mazday

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

В таком случае покажите вывод ipconfig /all в хостовой ОС и в виртуалке. А до кучи можно еще и результаты route print

mazday

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

После этого уже можно будет конкретно спрашивать, если что-то не получается.

По поводу "наладить сеть таким образом чтобы хостовая машина получала интернет траффик через виртуальную", вы хотите в виртуаке поднять проксик/роутер с которого раздавать интернет остальным машинам в сети?

BorisGun

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Статью почитал и даже не знаю что я сделал не так. Често говоря очень плохо разбираюсь в этом. Мне в данный момент просто нужна локальная сеть связывающая физ. и вирт. машины, с доспутом вирт. машины в интренет. Поэтому я включил NAT, но я не могу пропинговать вирт. машину с физической, я даже не представляю что я мог сделать не так.

А на счёт второго вопроса, да так. Мне нужно чтобы, не знаю как обьяснить, но если бы я делал команду tracert чтобы пакеты шли через вирт. машины в интернет и наоборот.

mazday

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

. я даже не представляю что я мог сделать не так.

. Мне нужно чтобы, не знаю как обьяснить.

Получается проблема не в средствах VMware, а в понимании основ сетей. а форум не профильный получается.

Но попробую помочь.

Что у вас за инет? как вы планировали его в виртуалку "прокинуть"?

Как на хостовой машине настроена сеть? (DHCP или статика?)

Мне видится такая схема (тут можеть быть много "но" и "если" которые зависят от вашей ситуации).

Я не могу пинговать шлюз с виртуальной машины Kali-Linux, в то время как я могу пинговать его с хоста и Win7 на виртуальную машину!

конфигурация:

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

что я сделал до сих пор?

Я заменил гостевой IP-адрес Kali-linux на гостевой IP-адрес Win7 (и наоборот). Ну, ничего не изменилось!

я попробовал другие операционные системы в качестве гостя. Для Ubuntu и Backtrack я не могу пинговать шлюз тоже, но для Win7 и Win XP это нормально.

Я бегу Wireshark на моем Хосте и контролировать трафик. Ну, я могу видеть Пакеты запроса ICMP как для гостей Linux, так и для гостей windows, но ответ от шлюза предназначен только для гостей Windows.

неустойчивое решение:

в прошлом, когда я сталкивался с этой проблемой, манипулируя таблицу маршрутов на виртуальной машине Linux была решена проблема (50%-50%), но теперь он не работает больше!

параметры:

выиграть 7 гостей (на Компания VMware):

гость Kali Linux (на VMware):

кто-нибудь знает, в чем причина этой проблемы?

ваша таблица маршрутизации верна, на самом деле она идентична моей.

но вы заявляете:

Я запускаю Wireshark на своем Хосте и контролирую трафик. Ну, я вижу пакеты запросов ICMP как для гостей Linux, так и для гостей windows, но ответ от Gateway предназначен только для гостей Windows.

это означает, что шлюз по-разному реагирует на два ping-пакета. Лучший способ продолжить состоит в том, чтобы перехватить оба пакета и сравнить их. Так как вы работаете wireshark, слушайте на исходящем интерфейсе Хоста, ограничьте свой перехват к icmp протокол и по назначению 10.0.60.0 , ping один раз только с host1 nd host2, сохраните 2 пакета в файл, изучите, что между ними отличается.

разница между двумя пакетами является то, что вызывает другое поведение шлюза. если, в конце концов, единственная разница IP-адрес источника, то это означает, что есть проблема с вашим Кали Ip адрес. Если это статический адрес, убедитесь, что он находится вне диапазона DHCP. В противном случае можно попытаться перезапустить шлюз, хост и виртуальные машины для обеспечения выпуска аренды DHCP в случае конфликта с ранее назначенными адресами.

Я имел почти идентичную проблему (Гугл привел меня сюда), но в моем случае проблема была в конфигурации ВМ, как-то изменился от Мостовой (присваивается собственный ник) в НАТу, значит ВМ все думал, что это был IP-адрес, выделенный с помощью VMware виртуальный мост, несмотря на меня имеющий модифицированных /и т. д./сети/интерфейсов и перезапустить сетевую службу.

оглядываясь назад, я не могу думать, как сетевые настройки могут измениться в VMWare, поэтому я более склонен думать об этом это была моя ошибка, но я мог бы поклясться, что я установил VM на "мост" перед запуском Kali VMDK.

Читайте также: