Рейтинг:-1

Командная строка KVM nat

флаг wf
t09

Как правильно настроить сеть NAT между KVM vm и хостом?

КВМ вм:

Брандмауэр не установлен

$ sudo arp-scan -r 5 -t 1000 --interface=eth0 --localnet

10.0.2.2 52:55:0a:00:02:02 локально администрируется
10.0.2.3 52:55:0a:00:02:03 локально администрируется

$ ip р

по умолчанию через 10.0.2.2 dev eth0 proto dhcp metric 100
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 100

ifconfig

eth0: инет 10.0.2.15 сетевая маска 255.255.255.0 широковещательная передача 10.0.2.255
      эфир 52:54:00:12:34:56
вот: инет 127.0.0.1 сетевая маска 255.0.0.0
      инет6 :: 1

Хозяин:

:~$ ip р

0.0.0.0/1 через 10.211.1.10 dev tun0 
по умолчанию через 192.168.1.1 dev wlan0 proto dhcp metric 600 
10.21xxxxxxxx dev tun0 ссылка на область ядра proto src 10.21xxxxx 
хххххххххх разработчик wlan0 
128.0.0.0/1 через 10.211.1.10 dev tun0 
192.168.1.0/24 dev wlan0 ссылка на прото-ядро src 192.168.1.172 метрика 600 
192.168.4.0/22 ​​dev eth0 proto kernel scope link src 192.168.4.8 метрика 100 

:~$ есликонфиг

 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
    инет 10.0.2.3 сетевая маска 255.0.0.0 широковещательный 10.255.255.255
    inet6 fe80::76c8:79b4:88d4:7f5c prefixlen 64 scopeid 0x20<ссылка>
    эфир ec:8e:b5:71:33:6e txqueuelen 1000 (Ethernet)
    Пакеты RX 1700 байт 194730 (190,1 КиБ)
    Ошибки RX 0 отброшено 0 переполнение 0 кадр 0
    Пакеты TX 2862 байта 246108 (240,3 КиБ)
    Ошибки передачи 0 отброшено 0 превышение пропускной способности 0 несущей 0 коллизий 0
    прерывание устройства 16 память 0xe1000000-e1020000  

 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
    инет 127.0.0.1 сетевая маска 255.0.0.0
    inet6 ::1 prefixlen 128 scopeid 0x10<хост>
    loop txqueuelen 1000 (локальная петля)
    Пакеты RX 13251 байт 7933624 (7,5 МБ)
    Ошибки RX 0 отброшено 0 переполнение 0 кадр 0
    Пакеты TX 13251 байт 7933624 (7,5 МБ)
    Ошибки передачи 0 отброшено 0 превышение пропускной способности 0 несущей 0 коллизий 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
    инет 10.211.1.69 сетевая маска 255.255.255.255 пункт назначения 10.211.1.70
    inet6 fe80::a920:941c:ffa8:5579 prefixlen 64 scopeid 0x20<ссылка>
    unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
    Пакеты RX 4348 байт 2242726 (2,1 МБ)
    Ошибки RX 0 отброшено 0 переполнение 0 кадр 0
    Пакеты TX 3823 байта 404190 (394,7 КиБ)
    Ошибки передачи 0 отброшено 0 превышение пропускной способности 0 несущей 0 коллизий 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
    инет 192.168.1.172 сетевая маска 255.255.255.0 широковещательная рассылка 192.168.1.255
    inet6 fe80::651b:5014:7929:9ba3 prefixlen 64 scopeid 0x20<ссылка>
    эфир d8:55:a3:d5:d1:30 txqueuelen 1000 (Ethernet)
    Пакеты RX 114455 байт 117950099 (112,4 МБ)
    Ошибки RX 0 отброшено 0 переполнение 0 кадр 0
    Пакеты TX 67169 байт 14855011 (14,1 МБ)
    Ошибки передачи 0 отброшено 0 превышение пропускной способности 0 несущей 0 коллизий 0 

~$ sudo arp-scan -r 5 -t 1000 --localnet

просто висит......

Хост не может пропинговать 10.0.2.2

Брандмауэр не включен

Пытался

$ sudo ip route добавить по умолчанию через 10.0.2.0
$ sudo ip route добавить по умолчанию через 10.0.2.2
$ sudo ip route добавить по умолчанию через 10.0.2.0/24

Может ли NAT работать без вирша?

Можно ли исправить NAT только из командной строки?

Обновлять:

$ sudo ip link добавить мост типа natbr0
$ sudo ip link set dev natbr0 up
$ sudo ip link set dev eth0 up
$ sudo ip link set dev eth0 master natbr0

это работает для соединения подчиненного eth0 с kvm - vm может пинговать другие компьютеры в сети. но не ответ хозяина @Tom Yan в сочетании с archlinux-Network_bridge созданные выше команды, которые могут пинговать другие сетевые IP-адреса

Поэтому я попытался изменить рабочее мостовое соединение, чтобы позволить хосту и kvm общаться.

Цель: host$ ping kvm

$ sudo ip link добавить мост типа natbr0
$ sudo ip link set dev natbr0 up
$ sudo ip a add 10.0.2.1/24 dev natbr0
$ sudo kvm -m 3G -hdb /dev/sde -nic мост, br=natbr0
kvm$ sudo ip link добавить мост типа natbr0
kvm$ sudo ip добавить 10.0.2.2
kvm$ sudo ip link set dev natbr0 up
kvm может пинговать себя 

$ пинг 10.0.2.2

PING 10.0.2.2 (10.0.2.2) 56 (84) байт данных
64 байта из 10.0.2.2: icmp_seq=1 ttl=64 время=0,027 мс

но kvm$ping 10.0.2.1

Хост назначения недоступен

хост $ пинг 10.0.2.2

(просто висит)

Предпочитайте командную строку для проверки устойчивости голых костей процесса/системы по сравнению с множеством сценариев, которые могут представлять большую уязвимость к сбоям. - работает командная строка или нет, а ошибки легче отслеживаются, изолируются и воспроизводятся. В зависимости от варианта Linux некоторые сценарии/части сценариев (например, те, которые включены в предлагаемые альтернативные решения xml) могут работать или не работать. Если соединение с kvm можно воспроизвести на любой разновидности Linux, выполнив приведенные выше команды... тогда кажется возможным, что kvm NAT также можно выполнить с помощью команд cli - просто чтобы прояснить смысл этого поста, шаги cli для NAT kvm будут более стандартизированы, поэтому предпочтительнее.

как правило, ответ @NikitaKipriyanov был правильным путем, это был ответ, но для команды требовалась настройка

$ sudo kvm -m 3G -hdb /dev/sde -net nic -net user,hostfwd=tcp::1810-:22

с помощью команды tweak vm может обмениваться данными с Интернетом, как по умолчанию, а также связываться с хостом через ssh. спасибо @NikitaKipriyanov и @cnst за настройку https://stackoverflow.com/a/54120040

Пользователю нужно будет использовать ssh, используя порт 1810, используя адрес локального хоста.

$ ssh p@localhost -p 1810

флаг in
Информация от `ip r` и `ip a` с информацией о том, какой сетевой адаптер принадлежит вашему KVM, а также, возможно, командная строка вашей машины kvm, должна помочь вам в решении вашей проблемы. `-nic user,model=virtio` дает вам пользовательский режим NAT Если то, что вы хотите, на самом деле является nat от хоста к вашей сети, то: `iptables -t nat -A POSTROUTING -s $vmnet -j MASQUERADE` даст вам NAT
Nikita Kipriyanov avatar
флаг za
Отвечает ли это на ваш вопрос? [переадресация порта хоста с помощью qemu через libvirt в сети пользовательского режима] (https://serverfault.com/questions/890520/host-port-forward-with-qemu-through-libvirt-in-user-mode-networking)
t09 avatar
флаг wf
t09
@NiKiZe: _iptables -t .... MASQUERADE_ выводит: неверный аргумент `MASQUERADE'. И _iptables -t nat -A POSTROUTING -o Brii -j MASQUERADE_ принимается хостом, но kvm по-прежнему не может пинговать хост или интернет
Nikita Kipriyanov avatar
флаг za
Обратите внимание, мост не имеет ничего общего с NAT и маршрутизацией. Не путайте их. Если вы хотите мост, удалите «NAT» и «ip route» и друзей везде, вы не собираетесь это использовать. Ваша виртуальная машина появится рядом с вашим хостом в какой-то сети (это может быть сеть, частная для хоста и виртуальной машины, но это уже другая история). С другой стороны, если вы собираетесь использовать NAT в пользовательском режиме, вам, конечно, вообще не нужен мост (поскольку он разработан, чтобы в первую очередь избавиться от необходимости использовать мост).
Nikita Kipriyanov avatar
флаг za
Другой ответ (от @TomYan) - это *другая история*, о которой я упоминал. Он предлагает вам пойти таким путем, т.е. е. от использования пользовательского режима NAT вы используете NAT в хост-ОС. Это работающий подход, но он, безусловно, *сложнее* и *громоздче*, чем просто правильное написание параметров командной строки.
t09 avatar
флаг wf
t09
@Nikita Киприянов - я проводил тесты на kvm, чтобы увидеть, может ли он NAT, как Virt-Manager, без раздувания и больших требований virt-manager к ресурсам. Я изучу применение libvirt в cli для решения этой проблемы и опубликую результаты в случае успеха.
Рейтинг:1
флаг za

Общая идея NAT заключается в том, что вы не вижу переведенные адреса. У вас нет путей к ним. Они не существуют для вас. Вы видите только те адреса, на которые они переведены.

Случай с QEMU ничем не отличается.В этом случае ваш хост находится «снаружи», ваша виртуальная машина находится «внутри», поэтому к виртуальной машине никогда не будет доступа по адресу, которому она назначена. У вас есть адрес виртуальной машины 10.0.2.2/24, но когда она достигает Интернета, ее пакеты транслируются на 192.168.1.172. процессом QEMU, поэтому хост считает эти пакеты созданными процессом QEMU и обрабатывает их как любые другие пакеты, скажем, от локально запущенного веб-браузера или чего-то подобного.

Как получить доступ к виртуальной машине с хоста? Когда у нас есть NAT, для доступа к хостам, скрытым за ним, мы устанавливаем ДНКТ правила. И опять же, случай QEMU ничем не отличается, вы должны установить в нем некоторые правила, а затем вы можете общаться с виртуальной машиной с хоста (или с других хостов, если хотите), отправляя пакеты на выбранные порты хозяин адрес.

Согласно документация QEMU, чтобы установить правила DNAT в NAT пользовательского режима, вы используете hostfwd пункт. Введем в его командную строку следующее:

    -netdev пользователь, id=usernet0,hostfwd=tcp::11111-:22 \
    -устройство virtio-net-pci,netdev=usernet0,mac=08:00:27:92:B0:51

Затем tcp-порт 11111 будет занят qemu-система-x86_64 процесс на моей машине, и если вы подключитесь к локальный хост порт 11111, подключение будет осуществляться к порту 22 ВМ.

Общая форма hostfwd=hostip:hostport-guestip:guestport, но если опустить хостип, это будет локальный хост, и если вы опустите гостевой совет, это будет первый "нешлюзовый" адрес внутри гостевой сети.

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

t09 avatar
флаг wf
t09
спасибо, ответ имеет смысл - я все еще делаю что-то не так. `$ sudo kvm -m 3G -hdb /dev/sde netdev user,id=usernet0,hostfwd=tcp::11111-:22` Вывод: `qemu-system-x86_64: netdev: не удалось открыть 'netdev': такого нет файл или каталог` Я прочитал ссылку на документацию QEMU - какие-либо учебные пособия объясняют это шаг за шагом, я могу следовать?
t09 avatar
флаг wf
t09
`$ sudo kvm -m 3G -hdb /dev/sde netdev user,id=usernet0,hostfwd=tcp::11111-:22 устройство virtio-net-pci,netdev=usernet0,mac=08:00:27:92: B0:51` Тот же вывод: `qemu-system-x86_64: netdev: не удалось открыть 'netdev': нет такого файла или каталога`
Michael Hampton avatar
флаг cz
@ t09 Просто исправьте опечатку; вы забыли `-` в `-netdev user,...`
Tom Yan avatar
флаг in
На самом деле `(S)NAT` (в смысле, не относящемся к qemu) не мешает виртуальной машине получить доступ к хосту. Скорее, он «маскирует» трафик от виртуальной машины так, чтобы он выглядел так, как будто он исходит от хоста виртуальной машины к сетевым хостам в той же локальной сети, что и эта (например, ее шлюз по умолчанию). Технически это даже не препятствует тому, чтобы трафик от этих хостов достигал виртуальной машины (но только то, что ответный трафик от виртуальной машины не будет казаться ответом на них).
Tom Yan avatar
флаг in
Что на самом деле «изолирует» виртуальную машину, так это, насколько мне известно, тот факт, что `-netdev user` представляет собой сетевой стек пользовательского пространства внутри самого qemu: https://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29, который почему вы не увидите ничего нового в `ip l` на хосте. Просто многие пользователи просто используют это для настройки «NAT-подхода» (потому что это значение по умолчанию), так что это становится синонимом NAT в контексте qemu. Правда в том, что вы можете использовать мост без физического подчиненного устройства и полагаться на переадресацию IP для подключения к Интернету на виртуальных машинах.
Nikita Kipriyanov avatar
флаг za
@ t09 `-netdev` должен быть с тире, правда. Это параметр командной строки QEMU.
t09 avatar
флаг wf
t09
обычно это был ответ, но требовалось настроить команду $ sudo kvm -m 3G -hdb /dev/sde -net nic -net user,hostfwd=tcp::1810-:22
Рейтинг:0
флаг in

Вы можете использовать мост, не привязывая к нему какие-либо физические интерфейсы Ethernet на узле виртуальной машины.

Скажем, мы придерживаемся выбора подсети 10.0.2.0/24 (что НЕ обязательно):

# ip l добавить мост типа natbr0
# ip a add 10.0.2.1/24 dev natbr0

Затем создайте следующий файл:

$ echo 'разрешить natbr0' | тройник судо /etc/qemu/bridge.conf 
разрешить natbr0

Затем запустите qemu, например, -nic мост,br=natbr0 или же -netdev bridge,br=natbr0,id=nb0 -device virtio-net,netdev=nb0, который будет кран вашу виртуальную машину к мосту динамическим образом (т. кран интерфейс будет удален после выключения виртуальной машины).

Вам также необходимо настроить статический IP-адрес на виртуальной машине:

# ip a add 10.0.2.2/24 dev ens3
# ip r добавить по умолчанию через 10.0.2.1

Если вы также не настроили DHCP-сервер (например, с dnsmasq) на хосте. Не забудьте также настроить DNS-сервер для использования внутри виртуальной машины.

Обратите внимание, что виртуальные машины, использующие один и тот же мост, могут взаимодействовать друг с другом, если только вы не заблокируете такое взаимодействие каким-либо образом (например, с помощью ebtables).

По умолчанию маршрут (и DNS-сервер для использования) необходимы только в том случае, если вы хотите, чтобы виртуальная машина могла достичь «снаружи». Если вам нужно только, чтобы он мог общаться с хостом виртуальной машины, вы должны пропустить вторую команду и можете прекратить чтение. (Ну, читайте P.S.)


Вероятно, было бы лучше настроить, например. dnsmasq на хосте в качестве переадресатора DNS, если вы не хотите использовать определенный «общедоступный» DNS-сервер в виртуальной машине, хотя и используете DNAT для пересылки DNS-запросов, например. 192.168.1.1 должны работать для основных.

Затем вам нужно включить переадресацию IP:

# sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

Если вы хотите избежать переадресации IP-адресов с/на определенный сетевой интерфейс (например тун0) из соображений безопасности вам необходимо настроить брандмауэр. Например:

# iptables -A ВПЕРЕД -i tun0 -j УДАЛИТЬ
# iptables -A ВПЕРЕД -o tun0 -j УДАЛИТЬ

Поскольку у вас есть (VPN) туннельные маршруты, которые практически переопределяют По умолчанию маршрут, трафик от виртуальной машины к Интернету также будет идти в туннель (если вы не добавили примеры правил выше). Если вы хотите, чтобы трафик пошел, например. через ваш маршрутизатор, вам понадобится политика маршрутизации. Например:

# ip ru add iif natbr0 таблица поиска 123
# ip r add 192.168.1.1 dev wlan0 table 123 # возможно необязательно
# ip r добавить по умолчанию через 192.168.1.1 таблица 123

Вы также можете запретить своим виртуальным машинам доступ к хостам вашей локальной сети:

# iptables -A FORWARD -i natbr0 -d 192.168.1.0/24 -j DROP

Делайте исключения (обратите внимание на ), если вы собираетесь перенаправлять DNS-запросы на свой маршрутизатор:

# iptables -I FORWARD -i natbr0 -d 192.168.1.1 -p tcp --dport 53 -j ПРИНЯТЬ
# iptables -I FORWARD -i natbr0 -d 192.168.1.1 -p udp --dport 53 -j ПРИНЯТЬ

Наконец, настройте iptables для динамического выполнения SNAT (в соответствии с исходящим интерфейсом) для вашей подсети виртуальной машины:

# iptables -t nat -A POSTROUTING -s 10.0.2.0/24 -j MASQUERADE

Обратите внимание, что это НЕ предназначено и не будет препятствовать тому, чтобы определенный трафик извне (ваши физические хосты LAN или Интернет; хост виртуальной машины не в счет) мог достичь ваших виртуальных машин. Это просто прерывает связь как побочный эффект, когда исходный адрес отвечающего трафика от виртуальных машин изменяется до его пересылки.Для правильной изоляции вам потребуются (дополнительные) соответствующие правила в ВПЕРЕД цепь. Если у вас есть такая необходимость, подумайте о том, чтобы установить там «с сохранением состояния».

Кроме того, вы можете перенаправить DNS-запросы к хосту с виртуальных машин на ваш маршрутизатор:

iptables -t nat -A PREROUTING -d 10.0.2.1 -p udp --dport 53 -j DNAT --к месту назначения 192.168.1.1
iptables -t nat -A PREROUTING -d 10.0.2.1 -p tcp --dport 53 -j DNAT --к месту назначения 192.168.1.1

Который более или менее позволит вам использовать 10.0.2.1 в качестве DNS-сервера в виртуальной машине.


P.S. Все манипуляции выше (кроме создания/записи в /etc/qemu/bridge.conf) нестабильны, т. е. они исчезнут после перезагрузки (если только ваш дистрибутив не сделает что-нибудь глупое). Я не собираюсь углубляться в то, как вы можете сделать их постоянными, поскольку существуют разные способы/подходы, и они могут зависеть от дистрибутива.

t09 avatar
флаг wf
t09
пришлось создать каталог /etc/qemu/.... Не уверен, что правильно запускаю виртуальную машину. Пробовал `sudo kvm -m 3G -hdb /dev/sde -netdev bridge,br=natbr0,id=nb0 -device virtio-net,netdev=nb0` и `$ sudo kvm -m 3G -hdb /dev/sde -nic bridge,br=natbr0,id=usernet0` и `$ sudo kvm -m 3G -hdb /dev/sde -nic bridge,br=natbr0,id=usernet0` vm запущен
t09 avatar
флаг wf
t09
на vm: `$ip a ...3: natbr0: ... состояние НЕИЗВЕСТНАЯ группа по умолчанию qlen 1000` _ifconfig_ `natbr0: inet 10.0.2.2 сетевая маска 255.255.255.0 широковещательная 0.0.0.0` _$sudo ip r добавить по умолчанию через 10.0.2.1/24_ `Ошибка: ожидается любой допустимый адрес, а не "10.0.2.1/24`
Tom Yan avatar
флаг in
@ t09 Это была опечатка. `/24` не следует использовать в этой команде.
Tom Yan avatar
флаг in
@ t09 Была еще одна опечатка: вместо команды «ip a add 10.0.2.2/24» должно быть что-то вроде «dev ens3». (Проверьте внутри виртуальной машины с помощью `ip l`, чтобы узнать имя используемого интерфейса. Убедитесь, что вы знаете, что *весь командный блок*, состоящий из команды, должен выполняться *на виртуальной машине*.)

Ответить или комментировать

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