Proxmox не получается добавить мост

Можете создать OVS Bridge в него подключить хост и виртуалку, на хосте разрешить форвард и занатить трафик.У виртуалки шлюзом будет ip адрес который вы назначили для хоста в этом бридже.

Покажите конфиги моста, конфиги сети виртуалок. Все виртуалки хотите через один IP пустить или купили пачку IP ?

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

iface lo inet6 loopback

auto enp4s0
iface enp4s0 inet static
        address  <ip сетевой карты>
        netmask  255.255.255.224
        gateway  <шлюз сетевой карты>
        up route add -net x.x.x.x netmask 255.255.255.224 gw <шлюз сетевой карты> dev enp4s0


iface enp4s0 inet6 static
        address  <адрес>
        netmask  64
        gateway  <шлюз>

auto vmbr0
iface vmbr0 inet static
        address  192.168.1.100
        netmask  255.255.255.0
        bridge-ports enp4s0

Виртуалка пока в процессе установки системы. В мастере настройки прописал ей ip 192.168.1.110, шлюз 192.168.1.100. Из консоли гипервизора пингуется и мост и виртуалка, но мастер пытается что-то скачать из удаленного репозитория и видимо не может попасть в инет, поэтому ругается на настройки сети.

Разрешить форвард - это вот так?

sysctl -w net.ipv4.ip_forward=1

1) Удалите auto enp4s0 inet и inet6 со всем содержимым, зачем вам сеть на физической карте при настройке моста?

2) Добавьте шлюз для моста, prox всё делает именно через мост.

Должно получиться примерно так:

auto lo
iface lo inet loopback

iface lo inet6 loopback

auto vmbr0
   iface vmbr0 inet static
    bridge_ports enp4s0
    address 192.168.1.100
    netmask 255.255.255.0
    gateway 192.168.1.1
    broadcast 192.168.1.255

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o enp4s0 -j MASQUERADE но вам нужно сделать отдельный vmbr1 и через него пускать виртуалки

Где реальный ip он просто потеряет хост систему с вашим конфигом

И ещё, мосту можно вообще не задавать конфиг сети, vmbr1 в примере ниже (боевой конфиг кстати):

auto lo
iface lo inet loopback

iface eno1 inet manual

iface enp1s0f0 inet manual

iface enp1s0f1 inet manual

iface enp1s0f2 inet manual

iface enp1s0f3 inet manual

auto vmbr0
iface vmbr0 inet static
	address  192.168.0.2
	netmask  255.255.255.0
	gateway  192.168.0.1
	bridge-ports enp1s0f0 enp1s0f1 enp1s0f2 enp1s0f3
	bridge-stp off
	bridge-fd 0
#4x1Gbit LAN

auto vmbr1
iface vmbr1 inet manual
	bridge-ports eno1
	bridge-stp off
	bridge-fd 0
#no IP for hypervisor WAN

Хост система замечательно управляется по ip моста, у меня несколько серверов так настроены - никаких проблем.

Спасибо всем огромное за помощь.Сегодня буду пробовать варианты раздачи инета виртуалкам:)

1) Удалите auto enp4s0 inet и inet6 со всем содержимым, зачем вам сеть на физической карте при настройке моста?

А как тогда все в инет ходить будут, если эти настройки удалить?

Так через мост же, примерно так (как у вас в шапке):

auto lo
iface lo inet loopback

iface enp4s0 inet manual

auto vmbr0
       iface vmbr0 inet static
        bridge_ports enp4s0
        address  <ip сетевой карты>
        netmask  255.255.255.224
        gateway  <шлюз сетевой карты>
        broadcast 192.168.1.255
        up route add -net x.x.x.x netmask 255.255.255.224 gw <шлюз> dev vmbr0

Т.е. я на мосте настраиваю выход в инет все уже через него ходят, в том числе и гипервизор?

Т.е. я на мосте настраиваю выход в инет все уже через него ходят, в том числе и гипервизор?

ну да, если задача гипервизор сделать шлюзом.

ну да, если задача гипервизор сделать шлюзом.

Пока стоит именно такая задача. Потом скорее всего добавится еще один сервер с proxmox и будет задача как все это объединить в одну сеть:)

auto lo iface lo inet loopback

iface enp4s0 inet manual

auto vmbr0 iface vmbr0 inet static bridge_ports enp4s0 address <ip сетевой карты> netmask 255.255.255.224 gateway <шлюз сетевой карты> broadcast 192.168.1.255 up route add -net x.x.x.x netmask 255.255.255.224 gw <шлюз> dev vmbr0

При такой конфигурации какие ip назначать виртуалкам? После перезагрузки у меня из конфига пропадает строчка

broadcast 192.168.1.255

Я вот понять не могу. Вы не могли на кроликах разобраться. Поставит виртуалку на лок комп проверить поиграться и потом все это МАСТЫРИТЬ на удаленке. Или теперь так модно устроится на работу, где дали не посильную задачу, но я ее решаю на раз сказал начальнику ajijohn. А тут типа чтот не срослось, но есть люди LOR которые помогут и скажут, что и к чему, причем за бесплатно, а я ajijohn за это и бабосы к томуже получу. Зачем мне что-то учить хоть просто ip-routing понимать не хочу и не знаю.
ajijohn Дата регистрации: 19.10.2018 12:37:38
Я прошу меня не сильно пинать, т.к. накипело, можно все протестить на лок машине, и читать, читать, читать документацию, ну и поиском пользоваться. Все выдохнул.

1) Создаешь интерфейс Linux Bridge 2) Переносишь IP, маску и все прочее из первого интерфейса (enp2s0) в новый интерфейс (vmbr0) 3) В интерфейсе vmbr0 в поле «Bridge ports» указываешь имя первого интерфейса (enp2s0)

Сохраняешь, перезапускаешь сеть/сервер

пропадает строчка
broadcast 192.168.1.255

У вас же маска *.224 и 255 похоже за пределами, вот и пропадает.

Виртуалкам ip в зависимости от сетей. Мож у вас пул белых ip снаружи, локалка ограничена и т.д. и т.п.

https://pve.proxmox.com/wiki/Network_Configuration

Я вот понять не могу. Вы не могли на кроликах разобраться. Поставит виртуалку на лок комп проверить поиграться и потом все это МАСТЫРИТЬ на удаленке. Или теперь так модно устроится на работу, где дали не посильную задачу, но я ее решаю на раз сказал начальнику ajijohn. А тут типа чтот не срослось, но есть люди LOR которые помогут и скажут, что и к чему, причем за бесплатно, а я ajijohn за это и бабосы к томуже получу. Зачем мне что-то учить хоть просто ip-routing понимать не хочу и не знаю. ajijohn Дата регистрации: 19.10.2018 12:37:38 Я прошу меня не сильно пинать, т.к. накипело, можно все протестить на лок машине, и читать, читать, читать документацию, ну и поиском пользоваться. Все выдохнул.

Да что ж вы так нервничаете. На работу я уже давно устроился и занимаюсь исключительно программированием. Настройка proxmox имеет просто академический интерес. Ну вот интересно мне стало как это работает. Мануалом и поиском пользоваться я умею, уж поверьте.

Дата регистрации... Я про этот сайт только сегодня утром узнал, когда после долгой ночи наступил момент отчаяния:))))

1) Создаешь интерфейс Linux Bridge 2) Переносишь IP, маску и все прочее из первого интерфейса (enp2s0) в новый интерфейс (vmbr0) 3) В интерфейсе vmbr0 в поле «Bridge ports» указываешь имя первого интерфейса (enp2s0)

Сохраняешь, перезапускаешь сеть/сервер

да я так и делаю, но виртуалки не видят сеть.

У вас же маска *.224 и 255 похоже за пределами, вот и пропадает.

Виртуалкам ip в зависимости от сетей. Мож у вас пул белых ip снаружи, локалка ограничена и т.д. и т.п.

Ресурсы ограничены одним выделенным сервером и двумя белыми ip :)

Виртуалкам во вкладке «оборудование» сетевые карты дали на основе vmbr?

Вывод

ifconfig -a

выделенным сервером и двумя белыми ip

Один фиг я бы гипервизиру сеть настроил только локальную (vmbr0), сетевуху смотрящую наружу оставил бы без настроек ip (только vmbr1), а уже виртуалки делал с белыми ip (дал им по 2 сетевухи на основе vmbr0 и vmbr1), шлюзами, натами, пробросами и прочими плюшками. Боевой пример выше приводил.

А почему в случае ТС не сделать как описано тут ?

Это какой то завогр

Виртуалкам во вкладке «оборудование» сетевые карты дали на основе vmbr?

Вывод

ifconfig -a

из консоли виртуалки в студию.

Вот как-то так:

enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether c8:60:00:54:b7:7b  txqueuelen 1000  (Ethernet)
        RX packets 44605  bytes 8547136 (8.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 23500  bytes 11037541 (10.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 6390  bytes 2495392 (2.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6390  bytes 2495392 (2.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap100i0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
        ether 92:4d:71:ad:8d:34  txqueuelen 1000  (Ethernet)
        RX packets 31488  bytes 1347764 (1.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2173  bytes 388803 (379.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap100i1: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
        ether ea:48:ba:eb:82:11  txqueuelen 1000  (Ethernet)
        RX packets 313  bytes 31166 (30.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 180 (180.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vmbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 5.9.x.x  netmask 255.255.255.255  broadcast 5.9.x.x
        inet6 fe80::ca60:ff:fe54:b77b  prefixlen 64  scopeid 0x20<link>
        ether c8:60:00:54:b7:7b  txqueuelen 1000  (Ethernet)
        RX packets 20307  bytes 3895436 (3.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12648  bytes 6373371 (6.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vmbr1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.254  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::acc6:54ff:fe1d:db0c  prefixlen 64  scopeid 0x20<link>
        ether ae:c6:54:1d:db:0c  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 46  bytes 2124 (2.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

А почему в случае ТС не сделать как описано тут ?

Это я еще просто не успел попробовать, но уже скоро.

Вот есть подобный вопрос и в этом сообщении почти ответ примените только к себе.

На гипервизоре не настраиваю шлюз по ряду причин:

- если ломанут виртуалку, то гипервизор есть шанс, что не успеют или не смогут

- виртуалку проще и быстрее бекапить и восстанавливать

- дебиан в режиме шлюза+нат+dhcp+dns+vpn это всего ~500-600 мегов места и ~256 оперативы

- ядро проксмокса несколько кастрировано, 4g мопед из коробки не завёлся у меня, а в deb9.5 как часы

Это прям что слёту вспомнил ))

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

Буду знать.

Консоли виртуалки, а не гипервозора ;)

На гипервизоре не настраиваю шлюз по ряду причин:
- если ломанут виртуалку, то гипервизор есть шанс, что не успеют или не смогут

Очень сомнительный профит. Если вы допускаете взлом шлюза. То во-первых это значит что ваша сеть за шлюзом, уже скомпрометирована. «Добрый» какер", врядли сразу после взлома пришлет вам сообщение «я вас взломал, срочно решайте проблему». Т.е. от момента самого взлома до момента когда обнаружили может пройти оооочень много времени. Во-вторых, что на правильно настроенном шлюзе ломать? Хорошо, предположим нашлась убер уязвимость в ssh который у вас открыт для всех, но тогда один фиг и хост и гостя поломают. Или убер уязвимость в ведре, но результат будет тот же, сломают все. На моей практике за 20 лет было два взлома шлюза и оба случая из-за личного раздолбайства. В-третьих добавлять оверхэда в виде виртуалки, зачем? В-четвертых дополнительная точка отказа.

- ядро проксмокса несколько кастрировано, 4g мопед из коробки не завёлся у меня, а в deb9.5 как часы

Ничего не мешало установить dep и на него накатить прокс

И отдельно

- виртуалку проще и быстрее бекапить и восстанавливать

Давайте рассмотрим по какой причине может сдохнуть совсем виртуалка?
1. Шаловливые ручки
Если предполагаете такое, то может для вас вариант и верный.
2. Хардверная проблема хоста
Ничем не спасет, один фиг разворачивать из бэкапов.

1 - шлюз обычно смотрит в инет под белым ip это уже уязвимость

2 - вот, находят уязвимость в ядре например, а ядро на гипервизоре обновляется платно, т.е. не обновляется. А в виртуалке всегда свежак из стабов.

3 - 1% оверхеда не проблема, ресурсов навалом.

4 - в моём случае дополнительная точка отказоустойчивости.

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

1 - шлюз обычно смотрит в инет под белым ip это уже уязвимость

В чем?

2 - вот, находят уязвимость в ядре например, а ядро на гипервизоре обновляется платно, т.е. не обновляется. А в виртуалке всегда свежак из стабов.

Напомните мне случай когда из-за ведра, именно просто уязвимостей в ведре в сетевой системе что-то сломали?

4 - в моём случае дополнительная точка отказоустойчивости.

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

Перед запуском в продакшн 2 месяца тестов, поэтому шаловливых рук нет.

А хардверная это было - интеловый ссд с ОС прокса наработал 1% и сдох. Нет худа без добра: 4 на 5 прокс как раз обновился ))

Перед запуском в продакшн 2 месяца тестов, поэтому шаловливых рук нет.

Вы пишите:

- если ломанут виртуалку
- виртуалку проще и быстрее бекапить и восстанавливать

Где правда? «Шаловливые ручки» не только в момент запуска, но и в процессе работы могут появиться. И повторюсь, вы заранее закладываете вариант что «ваш шлюз поломают». Мне кажется вы что-то делаете не так.

1 обычный ддос

2 вот только недавно (с год назад) Тровальд заплатку ядра внедрил для дыр виртуализации интеловых ппроцов

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

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

Поломают или поломается (харварно например) это всё стимулирует делат бекапы как минимум.

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

После этого шлюзы строю на компах/серверах.

Все оказалось намного проще, чем я думал:) Добавил бридж vmbr0 с настройками физической карты. Добавил vmbr1 вообще без ip и прочего.

На виртуалке поднял pfsense. Один адаптер - vmbr0, второй - vmbr1.

Напомню, что у меня 2 белых ip.

Насколько я понял, Hetzner выдает свои ip серверам через DHCP сервер по MAC адресам. Поэтому для сетевой карты виртуалки(vmbr0) нужно было просто прописать MAC второго ip адреса, который указан в лк Hetzner.

При запуске, pfsense сразу получил правильный белый ip. Для остальных виртуалок сетевой картой указываю vmbr1 и pfsense выдает им ip внутренней сети. Инет на виртуалках работает. Вобщем, все как мне и нужно было:)

Спасибо всем, кто пытался помочь в этом непростом, для меня, деле:)

1 обычный ддос

Чем, вот чем? вас спасет виртуалка? «wtf» так и хочется сказать. Это не же взлом, «вашу машу».

2 вот только недавно (с год назад) Тровальд заплатку ядра внедрил для дыр виртуализации интеловых ппроцов

И? Вы внимательно читали в чем проблема? И когда? И какая? Или так «мимокрокодил» ?

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

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

1 например, если шлюз это будет хост, то есть вероятность 100% нагрузки проца при злом ддосе, встанут все виртуалки. В варианте виртуалка-шлюз только с одним ядром хостпроца ляжет виртуалка, всё остальное продолжает работать

2 кратко это вероятность ломануть хост из ввиртуалки

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

Поломают или поломается (харварно например) это всё стимулирует делат бекапы как минимум.

Вы это называете «стимуляцией» ? «Ёж птица гордая пока не пнешь, не полетит» или по другому «не делаем бэкапы - уже делаем бэкапы - проверяем бэкапы».

Вами любимые роутеры глухо закрытые на вход мне высаживали раз в неделю стабильно.

Ну у меня нет «Вами любимые роутеры»

Даже хардварный фаервол дэлинка высадили.

Очень смешно. Что значит «хардверный» ? Для примера тут (сильно ранее) приводил тот же нэтгир у которого v6 во все поля открыты на локалку.

например, если шлюз это будет хост, то есть вероятность 100% нагрузки проца при злом ддосе, встанут все виртуалки.

Вы о чем? Куда ddos идет, по вашему мнению? Вы явно не понимаете что это такое. Один фиг «труба одна».

«Ёж птица гордая пока не пнешь, не полетит»

)))

Что значит «хардверный» ?

Производитель своё устройство называет фаерволом.

Куда ddos идет, по вашему мнению?

Полагаю, что основной удар по ядру виртуалки. Неужели и ядро хоста тоже будет атаковано? Как заполнится очередь в виртуалке, начнётся переполнение хоста?

Полагаю, что основной удар по ядру виртуалки.

«основной удар» по вашему каналу. Бывают варианты локального уменьшения нагрузки при ddos, в соседней теме тут обсуждается, но это не всегда спасает. У самого есть «истории успеха» решенные локально, но в большинстве своем без прова тут не обойтись, у них «труба шире».

«основной удар» по вашему каналу

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