Какой вариант сети выбрать для виртуалок под KVM в Интернете?

Ладно вам, умникам, лучше ответьте на более земной вопрос :))

Вот поставил я KVM в режиме NAT и поднял на нём под винду. Чтобы дать извне доступ по RDP, выдал парочку незамысловатых команд:

iptables -t nat -A PREROUTING --dst <адрес_kvm> -p tcp --dport 3389 -j DNAT --to-destination <адрес_винды>
iptables -I FORWARD 1 -i eth0 -o virbr0 -d <адрес_винды> -p tcp -m tcp --dport 3389 -j ACCEPT

Усё типа работает, но мне такое решение не наравится, и вот почему: - поскольку винда получает произвольный адрес по DHCP, не ровен час, этот адрес может сдуру поменяться, и пипец, доступ извне по RDP будет тупо утрачен.

Как быть? Отказаться от dhcp и тупо вбить статический?
Но фиг его знает - а вдруг линукс поменяет адреса внутренней подсети на что-то другое, хз, по каким значениям он их выдает, и опять доступ будет утрачен..
Как тут лучше сделать?

точно, я ведь не говорю фразами из мультиков

Уженирибёнак?

сам то понял что там написано?

Естественно, то. А вот тебе остался один квадратик, чтобы собрать линию на демагог-бинго.jpg

дада, почему?

БИНГО! Бинго! Би-инго! Динь-динь-динь динь-динь!
Сделал мою ночь просто.

ты серьезно считаешь bridge-utils нештатной утилитой?

define 「штатный」

kvm вообще поддерживает кучу всякой дряни которая никем не используется с 2006го года

[citation needed]

мы тогда много чего туда налопатили
мы

[id scan and gpg signature on commits needed]

и да, киддо, это скорее qemu а не kvm.

Продолжаем пукать в лужу?
http://www.linux-kvm.org/page/Networking#vde

http://www.cyberciti.biz/faq/rhel-linux-kvm-virtualization-bridged-networking...

Это не то, что я просил, но тоже вариант, если надо развести по локалкам. Только чую я потенциальный ворох, ну, может, не ворох — ворошочек проблем с натом между виртуальными машинами за br0 и за br1. iptables и мосты это часто кабздец.

это просто библиотека для управления, с ней удобнее.

Ваше мнение очень важно для нас. Пожалуйста, оставайтесь на линии и дождитесь ответа оператора.
Би-и… Би-и… Би-и…

ваш аргумент «нигде не используется» совершенно неумный, прекратите пожалуйста. оглядываться на кликадминов ънтрпрайза - последнее дело. все используют бридж только потому, что на каждом шагу в сети лежат руководства с ним. vde позволяет поднять полноценную виртуальную сетевую инфраструктуру, которую потом просто перетащить на физическое железо, в этом и суть виртуализацит. модное нынче и усиленно продвигаемое интеграторами решение «виртуалка под каждую задачу» убого и ненужно

немножко не в тему, но не помешает:

Други, кому не жалко выложите пожалуйста правила iptables host-а-машины сюда для запуска на вм всякого подозрительного и зондированного креэпа. Польза будет всем. Например как запретить виртуалке сканировать соседние хосты, сеть, хостовые сокеты да и вообще доступ к хостовой системе.

У меня есть такие правила:

#!/bin/bash

wlan0="wlp3s0"

# @see http://blog.bodhizazen.net/linux/bridge-wireless-cards/

for tapn in tap0 tap1 ; do
    echo "use $tapn"
    # Allow all outgoing traffic from the guest to the LAN or internet.
    iptables -A FORWARD -i $tapn -o $wlan0 -j ACCEPT

    # state replaced with conntrack
    # @see http://unix.stackexchange.com/questions/108169/what-is-the-difference-between-m-conntrack-ctstate-and-m-state-state
    # Allow only related / established connections from the LAN/internet to the guest
    # iptables -A FORWARD -i $wlan0 -o $tapn -m state --state RELATED,ESTABLISHED -j ACCEPT
    iptables -A FORWARD -i $wlan0 -o $tapn -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

    # As an example, allow connections to port 80 (Apache) to the guest.
    # iptables -A FORWARD -i $wlan0 -o $tapn -p tcp --dport 80 -j ACCEPT

    # Drop all other traffic
    iptables -A FORWARD -i $wlan0 -o $tapn -j DROP
    echo "done $tapn"
done

но почему-то не впечатляет, как он работает.

p.s. модеры: если имеет смысл перенесите эту ветку в отдельный трэд

поскольку винда получает произвольный адрес по DHCP, не ровен час, этот адрес может сдуру поменяться

В конфиге который я приводил не зря указаны как правила назначения IP «сдуру», так и привязанные к маку виртуалки.

Отказаться от dhcp и тупо вбить статический?

конечно

Но фиг его знает - а вдруг линукс поменяет адреса внутренней подсети на что-то другое, хз, по каким значениям он их выдает, и опять доступ будет утрачен

нет, он этого просто так не сделает

да, все понятно. пиши когда тебя отпустит, бедолага

ваш аргумент «нигде не используется» совершенно неумный, прекратите пожалуйста.

а что умнее?

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

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

vde позволяет поднять полноценную виртуальную сетевую инфраструктуру, которую потом просто перетащить на физическое железо, в этом и суть виртуализацит

предыдущий оратор так и не смог сказать что именно vde умеет такого «полноценного». буду рад узнать что то новое для себя

модное нынче и усиленно продвигаемое интеграторами решение «виртуалка под каждую задачу» убого и ненужно

это мнение основывается на опыте или бабка на скамейке нашептала?

Парни, посдкажите, плиз, как модифицировать этот код, чтобы доступ по RDP извне был не по стандартному 3389, а например, по 5555 ?

iptables -t nat -A PREROUTING --dst <адрес_хоста_kvm> -p tcp --dport 3389 -j DNAT --to-destination <адрес_виртуальной_винды>
iptables -I FORWARD 1 -i eth0 -o virbr0 -d <адрес_виртуальной_винды> -p tcp -m tcp --dport 3389 -j ACCEPT

Шо, никак? :))

iptables -t nat -A PREROUTING --dst <адрес_хоста_kvm> -p tcp --dport 5555 -j DNAT --to-destination <адрес_виртуальной_винды>:3389

Вроде такого?

Да, вроде такого, но оно не работает :(

Вроде нашел скрипт для перенаправления портов :

#!/bin/bash
EXT_IP="xxx.xxx.xxx.xxx" # Он всё равно чаще всего один и тот же.
INT_IP="xxx.xxx.xxx.xxx" # См. выше.
EXT_IF=eth0 # Внешний и внутренний интерфейсы.
INT_IF=eth1 # Для шлюза они вряд ли изменятся, поэтому можно прописать вручную.
FAKE_PORT=$1  # Вначале передаём скрипту "неправильный" порт на внешнем интерфейсе,
LAN_IP=$2     # затем - локальный адрес сервера
SRV_PORT=$3   # и в конце - реальный порт для подключения к серверу

# Здесь опять надо сделать проверку ввода данных, потому что операции всё ещё серьёзные.

iptables -t nat -A PREROUTING -d $EXT_IP -p tcp -m tcp --dport $FAKE_PORT -j DNAT --to-destination $LAN_IP:$SRV_PORT
iptables -t nat -A POSTROUTING -d $LAN_IP -p tcp -m tcp --dport $SRV_PORT -j SNAT --to-source $INT_IP
iptables -t nat -A OUTPUT -d $EXT_IP -p tcp -m tcp --dport $SRV_PORT -j DNAT --to-destination $LAN_IP
iptables -I FORWARD 1 -i $EXT_IF -o $INT_IF -d $LAN_IP -p tcp -m tcp --dport $SRV_PORT -j ACCEPT

но малость офигел от его сложности. Неужто нельзя попроще??

Итак, тов. чукча.

По быстродействию 1С: как уже выше написали двое товарищей - винда должна работать с virtio-диском, тогда производительность будет близка к нативной. С остальными типами вирт. дисков гостевая винда чудовищно тормозит. Только virtio.

По сети: если это твоя основная работа - забей на советы про всякие vde и др. хр. Строй нормальную виртуальную сеть. Вешай на интерфейс мост, в него втыкай виртуализованный же маршрутизатор (навроде vyos - чудесная вещь, кстати), и уже через рутер рули сеткой, фаером, натом, dhcp и прочим.

у libvirt есть post-up скрипты или как-то так. там можно прописать правила iptables.

За virtio спасибо, но уже использовал дефолтовый raw, и поменять уже ничего не могу, потому что хомячки уже начали работать :(

Что до vde, так я и не понял - что это? Но в любом случае всякие «втыкай мост, роутер и т.д.» не смогу использовать, т.к. это классический удаленный арендованный дедик, и максимум, что в него добавить из оборудования, т.к. это диски и память.

А вот по настройке iptables очень нужна ваша помощь.
Перегуглил десятки страниц с примерами, но они были очень сложны..
Потом нашел вроде самый подходящий и в то же время очень простой пример: http://digitalshock.ru/перенаправлление-порта-iptables/

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 25 -j DNAT --to XXX.XXX.XXX.XXX:2525
iptables -A POSTROUTING -t nat -p tcp -d XXX.XXX.XXX.XXX --dport 2525 -j SNAT --to-source YYY.YYY.YYY.YYY

но увы, он совершенно не заработал :(
ЧЯДНТ??

уже использовал дефолтовый raw

Это п****ц. Как хомячки закончат - добавляй ещё один дыск на шине virtio, ставь драйвер, выключай ВМ, меняй шину основного диска на virtio же и включай обратно.

всякие «втыкай мост, роутер и т.д.» не смогу использовать, т.к. это классический удаленный арендованный дедик, и максимум, что в него добавить из оборудования, т.к. это диски и память.

Ты чего???? Мост - это linux bridge, рутер - виртуалка. Никакого железа я тебе туда втыкать не предлагаю))

По «настройке iptables» - чётко опиши, как устроена сеть внутри хоста. Можешь даже схему нарисовать, с именами интерфейсов и адресами. Тгда, возможно, кто-нибудь и даст готовый рецепт (поскольку в сетях ты, очевидно, ни уха ни рыла).

nnw, спасибо тебе за ценные советы :)

Что до virtio. Остановил виндовую виртуалку, сменил в настройках дисков IDE на Virtio, запустил ее снова, и она вроде нормально работает.
Я ничего не попутал? ;)

А нет, после запуска эта настройка снова скинулась на IDE :(

Йоу...

1. Добавляешь к вирт. машине жесткий диск с шиной virtio (хоть 8 mb, размер не важен);

2. перезагружаешь гостевую винду;

3. после загрузки винда находит новое оборудование, подсовываешь ей дрова (https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/virtio-win...);

4. выключаешь гостевую систему;

5. меняешь тип шины основного диска на virtio;

6. включаешь гостя;

7. радуешься

8 (опционально) удаляешь доп. диск, если мешает.

Вечно ты с опазданием :( Ждал тебя, ждал, не дождался, грохнул винду (занимает 1,7 ТБ) и ставлю ее заново.

Позже еще опишу конфигурацию сети, ок?

Да - пишут, что «Cache mode» нужно обязательно выставлять в «None»
Иначе

cache=none это означает, что отключено кэширование записи на диск. При включенном кэшировании записи вдвое увеличивается время обращения к диску виртуальной машины

Правильно пишут

В драйверном образе virtio-win-0.1-81.iso нет драйверов под 2008, выбираю ближайший - под «семерку» - правильно?

Еще не знаю, ускорилась ли работа программ и пользователей на VirtIO, но загрузка 2008-й стала ну очень нудной и долгой :(

Ты что-то делаешь не так. Всегда наоборот бывает - с IDE загрузка «очень нудная и долгая», а с virtio грузится раза в 2 быстрее, чем на «голом железе»

Скинь на pastebin вывод virtio dupmxml

(c) Я всегда всё делаю не так! :)
Шютка. Скорее всего, мне субъективно показалось, что медленнее, потому что ничем не измерял.
Так что отложим пока эти космические скоростя, и обсудим с твоей помощью сети.

Поскольку дедик сейчас хостер заблокировал по непонятным причинам, воспроизвожу по памяти:

KVM, как настоящий начинающий линуксоид, подымал с помощью Virtmanager, что ни говори, графика понятнее, чем комстрока.
При создании сети выбрал NAT, образовалась внутренняя сеть «default»
= 192.168.122.0/24.
Сразу обратил внимание, что внутренний DHCP сразу занял всю подсеть - от 192.168.122.2 до 192.168.122.254, не оставив хоть кусочек для статических адресов.
ifconfig выдает:
- eth0 - 77.77.77.77
- virbr1 = 92.168.122.2
- ну и lo.

И вот здесь обнаружил 1-ю непонятность - все Виндовс-виртуалки, которые устанавливал в этой подсети, прекрасно ходили в Интернет, обновлялись и т.п., но в упор не видели друг друга ни по пингу, ни по RDP - почему?





ifconfig выдает три интерфейса

Тишина какая-то в студии... Наверное, вопрос сложный.

Ладно, вот попроще: имею ли я право влезть в дефолтовый конфиг /etc/libvirt/qemu/networks/default.xml

<network>
  <name>default</name>
  <uuid>2f94e715-cf26-4072-9105-a7531fccd28b</uuid>
  <bridge name="virbr0" />
  <mac address='52:54:00:E:5C:71'/>
  <forward/>
  <ip address="192.168.122.1" netmask="255.255.255.0">
    <dhcp>
      <range start="192.168.122.2" end="192.168.122.254" />
    </dhcp>
  </ip>
</network>

и поправить строку

      <range start="192.168.122.2" end="192.168.122.254"

     <range start="192.168.122.2" end="192.168.122.99"

что именно vde умеет такого «полноценного»

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

Блин, я уже офигаю от этой раздачи адресов в KVM!
Оно никаким нормальным сетевым правилам не подчиняется, ипанутся можно!!

nbw, ты здесь? Вопросик есть :)