не дает одновременно

Кто то писал выше что там надо какой то параметр включить

Потому что опыт, чувак. Когда хотят ИП на ВМ, то все заканчивается секурити группами ALL-ALL и бедой

а тебя опытом попросили поделиться?)

Не помню

+

не дает одновременно

бэкенд ovs ? где исполняются l3-агенты нейтрона? чем деплоил openstack ?

у тебя может сложиться так, что bridge ovs только на нетворк нодах, где нет compute, тогда vlan будет скедулиться на нетворк ноды\вроутер, но на инстансы (compute) - нет

на вопросы ответить не готов, мопед не мой второе более менее понятно, посмотрю. спасибо

удачи)

Обращайся

Добрый день, подскажите куда копать пожалуйста есть vlan провайдера подключенный напрямую к свитчу openstack external network, нужно белые ip из подсети этого vlan повесить на router и instance интерфейс одновременно на router получается, а на instance нет... такая схема вообще реальна?

главное с ИБ согласовать такое

есть какие то риски для владельца openstack? или только для клиента владельца виртуалок который хочет выставить их в мир?

виртуалкой вполне может быть какой нибуть vngfw

главное с ИБ согласовать такое

и все равно получить по жопе

у нас почти все хосты имеют WAN порт без SNAT/DNAT

есть какие то риски для владельца openstack? или только для клиента владельца виртуалок который хочет выставить их в мир?

теоретический риск - если выключить секьюрити группы на портах ВМ, которые подключены к provider network - изнутри ОС ВМ можно будит прописать себе "чужой" ip и случится конфликт ip адресов.

Кто как управляет выдачей IP-адресов для ВМ? Кладете их в cloud-init, или используете DHCP. Кто-нибудь генерирует cloud-init автоматом?

и все равно получить по жопе

угу, и 2х факторка не спасет

теоретический риск - если выключить секьюрити группы на портах ВМ, которые подключены к provider network - изнутри ОС ВМ можно будит прописать себе "чужой" ip и случится конфликт ip адресов.

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

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

как решите = так и будет

)

а по поводу "проблемой внутри проекта" - зависит от ваших устоявшихся ЗО

ок тогда какой бест практикс, поделитесь опытом плиз

зависит от того что вы делаете )

вот эти клиенты - у вас их больше одного планируется?

вланов с паблик ип тоже больше одного?

да сильно больше одного

от одного инстанса - эти все в одном проекте до крупных пулов

ИБ у каждого клиента разные? клиенты готовы сами отвечать за своё сетевое ИБ или они думают что ВЫ им ИБ предоставляете?

да по договору все на них

ну тогда каждому клиенту отдельный проект с отдельным vlan с паблик сеткой и пусть творят что хотят. За деньги = да

теоретический риск - если выключить секьюрити группы на портах ВМ, которые подключены к provider network - изнутри ОС ВМ можно будит прописать себе "чужой" ip и случится конфликт ip адресов.

тогда в добавок к этому - на аппаратных коммутаторах должна быть защите per vlan, stp/штормы/e.t.c

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

тогда в добавок к этому - на аппаратных коммутаторах должна быть защите per vlan, stp/штормы/e.t.c

это уже частично учтено, покопаем еще

l2 дерьмо из гостевой ОС не будет попадать в провайдерский vlan. FW будет на уровень выше. Можно сетевую архитектуру "красивую блэт" реализовать

сори опыта нет вообще, могу путатся с терминологией

Тогда может нанять сетевика ?

с FIP некоторые сервисы будут работать по другому у клиентов. Например Астериск нужно будет дополнительно настраивать для работы за NAT

и все равно получить по жопе

Люди хотят Аэрофлот 2.0

Тогда может нанять сетевика ?

именно с сетевой терминологией более менее норм, там была речь о терминологии опенстака

Добрый день, подскажите куда копать пожалуйста есть vlan провайдера подключенный напрямую к свитчу openstack external network, нужно белые ip из подсети этого vlan повесить на router и instance интерфейс одновременно на router получается, а на instance нет... такая схема вообще реальна?

А зачем усложнять топологию? Не понимать

Люди хотят Аэрофлот 2.0

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

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

Ничем. У тебя там нат работает

Ты от провайдера просто подаешь всю сетку. А на стороне опенстака можешь сказать какой пул из этой сетки использовать

ну про 3 уровень выше написали аргумент уже

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

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

внешние, продажа виртуалок - грубо говоря

о других частях я скромно умолчу

)

внешние, продажа виртуалок - грубо говоря

как вы будете мониторить IP конфликты ?

выше уже писал что это проблема клиента внутри проекта

внешние, продажа виртуалок - грубо говоря

Облако-то каких объёмов хотите ?

И какого плана архитектура у сети ?

небольших 1000 ядер

Хм...цель масштабирования через какой промежуток времени ?

провайдер -- свитч -- опенстек

веб морда отдельно...

Leaf spine ?

нет цели

выше уже писал что это проблема клиента внутри проекта

у вас же разные клиенты. И проблема быстро станет вашей. Но, вам виднее\

Leaf spine ?

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

у вас же разные клиенты. И проблема быстро станет вашей. Но, вам виднее\

ну так разные клиенты в разных проектах/вланах

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

вам провайдер согласовал растягивание десятков влан с колизиями на явно больше чем 20 гиперов?

4 ноды

нет цели

Хм... Мне кажется что вам проще взять cloudstack для такого облака и вашего подхода к сети. Опенстак больше про сложные топологии сети с более интересными приватными сетями

работаем с тем что уже есть

Хм...в таком случае вам нужно разрабатывать четкую архитектуру сети: что как и куда вы будете распределять/как будете группировать. Какие адреса/подсети у вас для каких задач. Отдельно делать изолированную сетку управления с firewall, либо локальным управлением через/в офисе. Отдельно делать сетку хранения(если не локальное). Здесь сложно сказать как реализовать сеть под ваши задачи, чтоб не возникало конфликтов адресов и всех вытекающих после+разбирать vlan все

так и планируется служебные подсети/вланы уже разбиты свитч для сети хранения/внутренних сетей между нодами отдельный - не пересекается с тем в который зашел провайдер сейчас дошло до подключения "клиентов" к интернету

а тебя опытом попросили поделиться?)

А тебя попросили меня спросить чем меня попросили поделиться?

так и планируется служебные подсети/вланы уже разбиты свитч для сети хранения/внутренних сетей между нодами отдельный - не пересекается с тем в который зашел провайдер сейчас дошло до подключения "клиентов" к интернету

Делай тогда сразу правильно. А то потом залупа прилетит

Делай тогда сразу правильно. А то потом залупа прилетит

правильно это только FIP и хрен кому прямую подсеть от провайдера? даже если у клиента своя подсеть делаем из не FIP и отдаем так?

правильно это только FIP и хрен кому прямую подсеть от провайдера? даже если у клиента своя подсеть делаем из не FIP и отдаем так?

Охохо. Смотри, можно сделать сильно по разному. Но если ты будешь отдавать адреса внешки сразу на вм, то надо точно знать что у тебя есть защита от ддос и внешний фв. Правильно написали - рисуй архитектуру.

Люди хотят Аэрофлот 2.0

ну то есть когда без порт секьюрити подают белые ip на vm.. это уже не Аэрофлот, это Киевстар. Их так и попячили

https://infohub.delltechnologies.com/en-us/l/architecture-guide-ready-architecture-for-red-hat-openstack-platform-version-16-1-flex-2/solution-with-25gbe-100gbe-networking-overview/

https://infohub.delltechnologies.com/en-us/l/architecture-guide-ready-architecture-for-red-hat-openstack-platform-version-16-1-flex-2/solution-with-25gbe-100gbe-networking-overview/

Дай угадаю, в данной топологии используются carrier ноды?

теоретический риск - если выключить секьюрити группы на портах ВМ, которые подключены к provider network - изнутри ОС ВМ можно будит прописать себе "чужой" ip и случится конфликт ip адресов.

А разве это в секуритигруппах? Оно же вроде в allowed_address_pairs определялось, не?

l2 дерьмо из гостевой ОС не будет попадать в провайдерский vlan. FW будет на уровень выше. Можно сетевую архитектуру "красивую блэт" реализовать

А еще можно от души получить секса с протоколами которые анонсят хостовый IP. Например iSCSI, SIP, FTP и прочие.

А еще можно от души получить секса с протоколами которые анонсят хостовый IP. Например iSCSI, SIP, FTP и прочие.

а если эта vm гейтвей то на ней можно малварь покласть

если получить доступ

А еще можно хрустальный хер сломать и руки порезать.

А еще можно хрустальный хер сломать и руки порезать.

Нужно!