Специфическая архитектура сети

[BabiyPetr]

Приветствую ребята.

 

Делаем частное облако на базе OpenNebula , под это дело была приобретена Cisco Nexus 9000 C9372PX, отдельное человеческое спасибо всем кто помог перепрошить ее и поднять аплинки))

 

Суть такова сейчас на этот свитч захидит два линка по 10Г от дата центра, линки агрегированы lacp , весь этот трафик идет в Vlan1 

 

Создано еще два Vlan один для приватной сети между виртуалками а второй для синхронизации хранилища

 

В целом Cisco сейчас работает в L2 режиме, но вот хочется использовать весь потенциал этого свитча и высвободить белые IP которых не так то и много спрятав все за NAT , но только вот таким хитрым способом, что если на виртуалке прописан белый IP то она должна быть доступна без NAT , если не прописан, то в интернет она ходить может через NAT. Высвободить хочется преимущественно ip для нод и IPMI пронатив это все по портам (PAT)

 

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

[uxcr]

Непонятно, что мешает-то. В одном влане хотите использовать серые и белые адреса, что ли?

[BabiyPetr]

Just now, uxcr said:

Непонятно, что мешает-то. В одном влане хотите использовать серые и белые адреса, что ли?

Совершенно верно, то есть на ноде мост на мосту висит серый ip , она в сеть ходит через NAT , на виртуалках которые к этому мосту подключены можно использовать и серые и белые адреса

 

 

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

[zhenya`]

А нат кто будет делать?

[BabiyPetr]

11 minutes ago, zhenya` said:

А нат кто будет делать?

Тут сложно сказать , NAT то не панацея. По сути ведь можно разрулить все и маршрутизацией, а для доступа к приватным сетям снаружи поднять IPSEC VPN вроди же можно такое на цисках? вчера находил какие то древние статьи на эту тему, но более и менее актуальное касается IPSEC типа точка - точка

VPN был бы удобнее чем NAT для доступа к инфраструктурным нодам ну а исходящий трафик наверное можно и без NAT разрулить

Вопрос только как правильно сделать... OpenNebula поддерживает Open Switch и VXLAN  может это как то можно применить для достижения цели..

[zhenya`]

Тут вопрос в том, что у вас свитч. Никакие ipsec он не сделает. Н9к умеет только статический нат 1 в 1. И он не даст сэкономить адреса.

[lugoblin]

Не совсем понятна топология L3.

У вас весь L3 в датацентре? (до которого, как вы сказали, 2x 10G в LACP)

В том числе и аплинк с "белыми" адресами?

Или ваш аплинк это и есть белая сеть, а весь "серый" L3 предполагается рутить локально?

 

В любом случае, независимо от контекста:

 

- В одном и том-же сегменте (VLAN) можно использовать серые и белые адреса. Дадим хосту серый адрес и пропшишем серый шлюз, будет ходить в Интернет через NAT. Дадим белый адрес и пропишем белый шлюз, будет ходить напрямую. Это работает, но слишком велик соблазн развести там грязь. Особенно, если несколько людей этим рулит и принимает решения. Рекомендую разнести по разным VLAN-ам публичную сеть с белыми адресами, и приватную с серыми.

 

- Функцию NAT, как и вообще коммутацию L3, не стоит отдавать на откуп устройству в роли "свич доступа", потому что это превратит его в монолитный god-box с огромным риском наслоений всяких legacy, над которум вы очень быстро потеряете контроль. На первых порах, функцию L3 можно сделать на виртуалке x86 с чем угодно, от Линукса общего назначения со скриптом nftables, до аплаянсов FotriGate, Wyatta или Mikrotik. По мере надобности, когда захлёбываться начнёт, либо рулить станет слишком неудобно, заменить на специальную железку или интегрировать функцию в вашу платформу виртуализации по моде Software Defined Network. Из этого правила есть много ислючений, их можно обсудить, но это отклонит нас от темы.

 

- Адреса для нод, IPMI и т.д., однозначно надо спрятать за NAT, независимо от избытка или недостатка белых адресов. Кроме того, их следует закрыть файерволом (который != NAT), запретить бесконтрольно шлятся в инет и подключаться к ним откуда попало.

 

- Мотивация "использовать весь потенциал этого свитча" несколько порочна, т.к. можно легко и незаметно перешагнуть грань, за которой использование некого ресурса будет нецелесообразно. Используйте то что требуется когда это уместно, и не печальтесь за простаивающий потенциал.

 

Рекомендую расписать требования к сети, например в форме списка use-cases, и нарисовать топологию (L2 и L3 отдельно) в соответствии с требованиями. Пoказать на "поругать" дружественному специалисту. Потом внедрять.

Например:

- Вычислительной ноде требуется физический порт для MGMT, с приватным адресом и серьёзными ограничениями по связности. Решаем выделением порта на MGMT свиче, с конфигурацией untagged в специальном VLAN-е.

- Вычислительной ноде требуется 2-4 физическийх портов для связности общего назначения с остальной сетью, с поддержкой агрегации. Решаем выделением портов с ЛАЦП на Access свиче, в mode trunk, с доступом в VLAN отданную под MGMT для руления гипервизором.

- Виртуальной машине с обратным прокси требуется прямой доступ в Инет и в приватную сеть A. Решаем выделением этой машине двух VIF, одной в VLAN-е с белыми адресами, другой в VLAN-е где живёт сеть A.

 

[BabiyPetr]

Quote

У вас весь L3 в датацентре? (до которого, как вы сказали, 2x 10G в LACP)

Порты аплинков включены в L2 (mode access)

 

Quote

Или ваш аплинк это и есть белая сеть, а весь "серый" L3 предполагается рутить локально?

Совершенно верно

 

Quote

Рекомендую разнести по разным VLAN-ам публичную сеть с белыми адресами, и приватную с серыми.

Сейчас так и сделано

Vlan 1 - в него приходит от аплинка наш /23 блок
Vlan 5 - 10.10.0.0/24 - это сеть комуникации гипервизора (10Г)
Vlan 10 - 10.0.0.0/24 - это сеть синхронизации DRBD хранилища, от каждой ноды в этот влан по два 10Г порта входит и я их объединил при помощи lacp (L2) что бы обеспечить канал в 20Г на ноду для синхронизации массива (планировался ceph , но из-за того что все железки в одной стойке пока отказались от него)

И по сути меня эта схема устраивает, есдинственное чего не хватает это что бы из сети 10.10.0.0/24 (влан 5) можно было выходить в интернет

 

Quote

Адреса для нод, IPMI и т.д., однозначно надо спрятать за NAT, независимо от избытка или недостатка белых адресов. Кроме того, их следует закрыть файерволом (который != NAT), запретить бесконтрольно шлятся в инет и подключаться к ним откуда попало.

Вот это да, мне очень хочется это сделать, сейчас IPMI подключен через каталист свитч и в принципе нет проблем переключить линк на него в 5 влан что бы использовать там 10.10.0.0/24 сетку. Вопрос в том как лучше доступ к этой сети снаружи сделать? Понятно что я могу в принципе поднять ВПН в самом облаке и через него получать доуступ в эту приватную сеть, в принципе то вероятность того что все ноды облака умрут одновременно и исчезнет этот впн доступ достаточно минимальны.

Что касается нод, то тут у меня вероятно явный недостаток знаний, допустим мостовой интерфейс vmbr0 на котором сейчас висит публичный адрес и который воткнут в влан 1 , я переведу во влан 5 где живет сетка 10.10.0.0/24  , но как тогда трафик пришедший на влан 1 (где живет наш блок /23) доберется до виртуалок которые включены через мост во влан 5 ?

Если этот мост оставлять в первом влане то как на нем применить приватные адреса?

[lugoblin]

14 hours ago, BabiyPetr said:

Quote

Или ваш аплинк это и есть белая сеть, а весь "серый" L3 предполагается рутить локально?

Совершенно верно

Тогда почему бы вам не набросать схему вашей сети L3, как вы её видите? По ней станет понятно, какие элементы и с какими функциями вам понадобятся. После этого можно будет думать, из каких ресурсов что организовать, и как связать на L2. Будет что сравнивать со списком требований.

 

Чтобы из сети 10.10.0.0/24 (влан 5) можно было выходить в интернет, понадобится роутер (коммутатор пакетов на уровне 3 модели OSI) с функцией NAT. Как я уже писал, это не обязательно отдельное физическое устройство.

 

Чтобы из Интернета можно было всем этим делом рулить, в том числе и IPMI, не создавая рекурсивной зависимости, инфраструкту контроля можно выннести на отдельные устройства.

 

Если у вас в распоряжении 2x 10G линка в Интернет, провайдер сотрудничает для поддержки агрегации LACP и есть белая сеть /23, я предположу вы работаете с неким разумным бюджетом. Возможно, имеет смысл направить часть него на оплату консультаций. Если вам интересно самому разобраться, ищите консультацию в формате менторства. В том что вы описали, есть много осмысленных мест, а так-же много очевидных косяков, в которые можно ткнуть пальцем и рекомендовать конкретные улучшения, но структуры вашему поекту таким образом дать не получится.

 

[VolanD666]

Роутер поставьте перед нексусом и НАТите свои серые в Интернет. Еще я бы служебные и дата SVI разнес бы по разным VRF.

[BabiyPetr]

Спасибо всем за советы, не стал мучать нексус маршрутизацией, переложил ее на VirtualRouter от OpenNebula , на всех нодах настроил VPN доступ во внутреннюю сеть, все IP для IPMI перенес в серую сеть, а IP нод прикрыл фаерволом.

[lugoblin]

9 hours ago, BabiyPetr said:

не стал мучать нексус маршрутизацией, переложил ее на VirtualRouter от OpenNebula

Нормально. Теперь аккуратнее в OpenNebul-е удалённо ковыряйтесь, чтоб ненароком доступ не потерять.