VLAN - с тегами и без

0

1

Доброго времени суток. Сразу попрошу ногами не пинать, в вопросе разбираюсь на теоретическом уровне, в первый раз с этим сталкиваюсь самостоятельно, но разобраться нужно. Если кто-нибудь кинется толковым руководством, объясняющим вопрос на пальцах, или разъяснит, «где я не прав», то буду очень признателен! Итак. Есть одна организация, у это организации есть сервер на CentOS. Сервер раздает интернет на несколько организаций, при этом маршрутизация и прочее реализовано на основе VLAN. Всего этих самых VLANов около десятка. Пытаюсь повторить это на виртуальной машине - поднять CentOS и настроить WAN в сторону провайдера (а точнее, физической локальной сети через «сетевой мост») через eth0 получилось без проблем, во внутренней сети виртуальной машины (VirtualBox) при указании адреса для eth1 машина из той же сети под Linux и Windows пингуют этот самый сервер на CentOS. Воодушевляюсь, делаю VLAN не без помощи этой http://xgu.ru/wiki/VLAN_в_Linux статьи - интерфейсы поднимаются, получают адреса. Однако теперь виртуальные машины не пингуют машину с CentOS и она не пингует их. Как я предполагаю, причина в том, что VLAN в Linux тегированный, а значит, трафик будет ходить только в том случае, если, например, на второй Linux-машине поднять VLAN и присвоить ему тот же ID, что и у машины под CentOS. Пока проверить не удалось, в качестве тестовой машины поставил slitaz, а у него соответствующего модуля ядра нет, нужно или пересобирать, или по-быстрому сделать еще одну виртуальную машину. Ок, но как в этом случае быть с Windows и как, черт подери, работает это все в «боевой» сети? Насколько я понимаю, каким-то образом есть возможность «снять» тег с VLAN и определить принадлежность на основе IP-адреса машины и источника пакета. Как это сделать? Прошу помочь, кто чем может.

Ссылка

←	Не могу запустить сайт

Вывод на dashboard только упавших хостов

→

а какой из вариантов сети выбрал в VBox? Nat, внутренняя, мост?

P.S. после получения на интерфейсе (vlanX или eth0.X к примеру) он уже не тегированнный.

P.P.S. обычно ставят мост между vlanX|eth0.X и виртуальной картой(tapY) для виртуальной ОС

Atlant ★★★★★
(25.11.2014 07:45:00 +00:00)
Последнее исправление: Atlant 25.11.2014 07:49:02 +00:00 (всего исправлений: 2)

Open vSwitch?

rubic ★
(25.11.2014 08:06:25 +00:00)

Пытаюсь повторить это на виртуальной машине

http://habrahabr.ru/post/242741/

af5 ★★★★★
(25.11.2014 08:07:14 +00:00)

Ссылка

router on the stick - решение дурацкое, не безопасное и не производительное.

Пытаюсь повторить это на виртуальной машине

«Ежи кололись и плакали»

каким-то образом есть возможность «снять» тег с VLAN

Тэг снимает или драйвер карты, или модуль ядра, отвечающий за обработку тэгированного трафика, потом пакет без тэга попадает в sub интерфейс. (eth0.0 к примеру)

и определить принадлежность на основе IP-адреса машины и источника пакета.

Принадлежность к VLAN ? На сколько я помню, в Linux нет возможности (в отличии от нормальных систем) присвоить одинаковый IP адрес разным интерфейсам. Так что, сети у вас уже поделены и без VLAN :)

robot12 ★★★★★
(25.11.2014 08:21:00 +00:00)

трафик будет ходить только в том случае, если, например, на второй Linux-машине поднять VLAN и присвоить ему тот же ID, что и у машины под CentOS

Верно.

как, черт подери, работает это все в «боевой» сети?

Обычно, теги снимаются коммутаторами, а конечные устройства ничего о VLAN'ах не знают.

Если реально нужно смоделировать поведение боевой сети, то пробуй, как и советовали, Open vSwitch.

post-factum ★★★★★
(25.11.2014 08:31:16 +00:00)

Ответ на: комментарий от Atlant 25.11.2014 07:45:00 +00:00

а какой из вариантов сети выбрал в VBox? Nat, внутренняя, мост?

На машинах внутри сети (под Linux и под Windows) выбрана внутренняя сеть, на машине с CentOS две сетевые карты - одна смотрит мостом в локальную сеть, вторая - смотрит в ту же внутреннюю сеть.

P.S. после получения на интерфейсе (vlanX или eth0.X к примеру) он уже не тегированнный.

Вот где-то тут мне и непонятно... Получается, eth1.10 ждет «на той стороне» трафик с тем же ID, а остальной отбрасывает?

P.P.S. обычно ставят мост между vlanX|eth0.X и виртуальной картой(tapY) для виртуальной ОС

У меня сейчас три виртуалки (под б-гомерзкой виндой) - CentOS, Linux, Win 7. Как настроены карты - ответил в первом сообщении. Интересует VLAN именно во внутренней сети VirtualBox.

babich ★
(25.11.2014 10:00:43 +00:00) автор топика

Ссылка

Ответ на: комментарий от rubic 25.11.2014 08:06:25 +00:00

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

babich ★
(25.11.2014 10:02:56 +00:00) автор топика

Ссылка

Ответ на: комментарий от robot12 25.11.2014 08:21:00 +00:00

router on the stick - решение дурацкое, не безопасное и не производительное.

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

Пытаюсь повторить это на виртуальной машине
«Ежи кололись и плакали»

Т.е. если аналогичное поднять на реальном железе и, например, поставить коммутатор между конечными устройствами и сервером-маршрутизатором (как это сделоно в организации), все будет работать?

каким-то образом есть возможность «снять» тег с VLAN
Тэг снимает или драйвер карты, или модуль ядра, отвечающий за обработку тэгированного трафика, потом пакет без тэга попадает в sub интерфейс. (eth0.0 к примеру)

Вот ниже написали, что коммутатор снимает. В этом случае трафик будет распределяться по правилам для VLAN, определяя принадлежность к тому или иному VLAN (не заданному явно на конечном устройстве) на основе IP-адреса?

и определить принадлежность на основе IP-адреса машины и источника пакета.
Принадлежность к VLAN ? На сколько я помню, в Linux нет возможности (в отличии от нормальных систем) присвоить одинаковый IP адрес разным интерфейсам. Так что, сети у вас уже поделены и без VLAN :)

Имеется в виду по адресу на основе подсети, например, eth1.10 имеет адрес 192.168.10.1 и маску 255.255.255.0 - получается, если прилетел пакет от 192.168.10.55, то его обрабатываем по правилам для VLAN с ID 10. Я понимаю, что путанно объясняю, прошу прощения, но я с этим в первый раз столкнулся.

babich ★
(25.11.2014 10:13:08 +00:00) автор топика

Ссылка

Ответ на: комментарий от post-factum 25.11.2014 08:31:16 +00:00

Если реально нужно смоделировать поведение боевой сети, то пробуй, как и советовали, Open vSwitch.

А если поднять CentOS на реальном железе, настроить пару VLAN, поставить между «сервером» и конечными устройствами типа ноутбука свитч и попробовать пинговать - получится ли? В организации между клиентами и сервером стоит два коммутатора, судя по всему, какие-то более-менее управляемые, ибо имеют собственный IP-адрес. Внутрь пока еще не лазил, доступ на объект ограничен...

babich ★
(25.11.2014 10:15:16 +00:00) автор топика

Ответ на: комментарий от robot12 25.11.2014 08:21:00 +00:00

На сколько я помню, в Linux нет возможности (в отличии от нормальных
систем) присвоить одинаковый IP адрес разным интерфейсам.

1. Это не нормальные, а дебильные системы.
2. Linux - такой же. Тоже не проверяет нифига. ;-)

AS ★★★★★
(25.11.2014 10:18:33 +00:00)

Ссылка

Пытаюсь повторить это на виртуальной машине

Главный вопрос - зачем ?

и как, черт подери, работает это все в «боевой» сети ?

У сервера, очевидно, мало сетевых карт. Всё собирается на коммутатор и тегированным портом с кучей VLAN попадает на сервер. На сервере сконфигурирована кучка VLAN-интерфейсов, кторые для системы выглядят, по факту, как обычные. Он между ними роутит. Всё. Если хочешь загнать всё в виртуалку, загоняй реальный eth туда, а внутри настраивай кучу VLAN точно так же.

AS ★★★★★
(25.11.2014 10:23:36 +00:00)

Ответ на: комментарий от babich 25.11.2014 10:15:16 +00:00

поставить между «сервером» и конечными устройствами типа ноутбука свитч и попробовать пинговать - получится ли?

Без настройки коммутаторов, конечно, не получится. Со стороны конечных устройств настраиваются access-порты (untagged), со стороны сервера — trunk (tagged).

post-factum ★★★★★
(25.11.2014 10:29:24 +00:00)

Прошу помочь, кто чем может.

Оставить все как есть :) Работает и ладно.

robot12 ★★★★★
(25.11.2014 10:56:51 +00:00)

Ответ на: комментарий от AS 25.11.2014 10:23:36 +00:00

Главный вопрос - зачем ?

Чтобы понять, как это работает. Может возникнуть необходимость добавить или убрать VLAN, изменить настройки ограничения по скорости (там это сделано через ipfw), задокументировать все это дело, чтобы, если я куда-нибудь денусь, это смог понять и обслуживать человек, который хотя бы отдаленно понимает, как оно должно быть.

У сервера, очевидно, мало сетевых карт. Всё собирается на коммутатор и тегированным портом с кучей VLAN попадает на сервер. На сервере сконфигурирована кучка VLAN-интерфейсов, кторые для системы выглядят, по факту, как обычные. Он между ними роутит. Всё. Если хочешь загнать всё в виртуалку, загоняй реальный eth туда, а внутри настраивай кучу VLAN точно так же.

Ну вот я как-то так и думал... Получается, из настроек на коммутаторе только один порт настроен как тегированный, к нему подключен сервер, а все остальные нетегированные? (собственно, это уже написано VLAN - с тегами и без (комментарий) здесь)

babich ★
(25.11.2014 11:30:07 +00:00) автор топика

Ответ на: комментарий от post-factum 25.11.2014 10:29:24 +00:00

Имеет ли значение марка коммутатора? Там, насколько мне смогли объяснить, стоит «какой-то D-Link и какой-то TP-Link», они, кстати, подключены через третью сетевую карту на сервер. Просто, судя по статье здесь http://xgu.ru/wiki/VLAN не все так просто и единого стандарта поведения нет.

babich ★
(25.11.2014 11:34:27 +00:00) автор топика

Ответ на: комментарий от robot12 25.11.2014 10:56:51 +00:00

Это само собой, но может возникнуть необходимость внести изменения, и тут хорошо бы знать, что куда и как.

babich ★
(25.11.2014 11:35:01 +00:00) автор топика

tl;dr.

У меня kvm+debian. На хосте я поднимаю подынтерфейсы с тегами и делаю бриджы с этими подынтерфейсами и их шару в ВМ. Всё работает - проблем не испытываю.

Если поддерживается IOMMU/VT-d, то можно сетевуху в ВМ пробросить и средствами ВМ рулить.

Deleted
(25.11.2014 11:35:20 +00:00)

Ссылка

Ответ на: комментарий от babich 25.11.2014 11:35:01 +00:00

Что куда и как ), так вот сначала составь карту сети с адресными пространствами и vlan, на каких участках у тебя L2 где L3, кто маршрутизатор, сколько и чего...

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

HarDX ★★
(25.11.2014 11:52:21 +00:00)

Ответ на: комментарий от babich 25.11.2014 11:34:27 +00:00

Имеет ли значение марка коммутатора?

Нет. 802.1q стандартизирован и поддерживается одинаково во всех современных железках. Имеет значение только наличие такой поддержки или её отсутствие в конкретной модели коммутатора. Обычно такие коммутаторы называют управляемыми уровня L2/L2+ или выше (хотя это неправильно, т.к. все коммутаторы по определению L2).

стоит «какой-то D-Link и какой-то TP-Link», они, кстати, подключены через третью сетевую карту на сервер

Сложно представить, какую топологию там сварганили с таким подходом.

post-factum ★★★★★
(25.11.2014 12:17:20 +00:00)

Ответ на: комментарий от babich 25.11.2014 11:30:07 +00:00

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

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

AS ★★★★★
(25.11.2014 12:52:31 +00:00)

Ответ на: комментарий от post-factum 25.11.2014 12:17:20 +00:00

L2+

L2+ - это L2-коммутатор, умеющий что-то делать на третьем уровне. IP ACL, статическая маршрутизация примитивная и т.п. 802.1q под «+» не попадает нигде. В смысле, если плюса нет, это не заначит, что нет VLAN.

AS ★★★★★
(25.11.2014 12:57:47 +00:00)

Ответ на: комментарий от post-factum 25.11.2014 12:17:20 +00:00

Скорее всего D-Link или TP-Link (если железка простая) смотрит к провайдеру, с него вероятно мост в Centos (хотя скорее всего D-Link и TP-Link как L3 (там или pppoe или обычная статика или dhcp до провайдера) - а на сервак с Centos уже инет локальным адресом в 3 сетевку)

Сама Centos скорее всего маршрутизит с 3 сетевки в интерфейсы с VLAN, на которые уже навешаны правила по скоростям и т.п... транком tagged vlan идут в маршрутизаторы L2 и дальше к клиентам простой untagged...

Думаю как то так, хотя это вопрос к топикпастеру ) ему лучше знать...

HarDX ★★
(25.11.2014 12:59:31 +00:00)

Ответ на: комментарий от HarDX 25.11.2014 11:52:21 +00:00

Схема тут http://s50.radikal.ru/i130/1411/04/776aa384da27.png Просьба не судить строго, всего лишь третий опыт в Dia.

babich ★
(25.11.2014 13:06:52 +00:00) автор топика

Ответ на: комментарий от AS 25.11.2014 12:57:47 +00:00

Надеюсь, это было и так понятно.

post-factum ★★★★★
(25.11.2014 13:07:14 +00:00)

Ссылка

Ответ на: комментарий от AS 25.11.2014 12:52:31 +00:00

Там eth0 (не-VLAN интерфейс) без адреса. Получается, что варианта с нетегированным трафиком нет? Или есть какой-то VLAN по-умолчанию, native вроде или как-то так? Если явно не задан, есть или нет?

babich ★
(25.11.2014 13:08:12 +00:00) автор топика

Ответ на: комментарий от babich 25.11.2014 13:06:52 +00:00

eth2 — WAN, eth0 — транк с кучей вланов, на eth1 — просто себе отдельная подсетка (типа административная). От eth0 шнурок идёт, видимо, к тем длинкам-тплинкам, на которых уже настроены порты-транки и порты доступа.

post-factum ★★★★★
(25.11.2014 13:10:26 +00:00)

Ответ на: комментарий от HarDX 25.11.2014 12:59:31 +00:00

Схему приложил, почти так, как вы сказали, только провайдер подключен напрямую в сервер статикой. На сервере наворочена маршрутизация через iptables и «правила по скоростям» (кажется, это называется шейпер) через ipfw. По схеме сети человек, который был на объекте, сказал «похоже», но ясности как-то не добавилось.

babich ★
(25.11.2014 13:10:29 +00:00) автор топика

Ответ на: комментарий от babich 25.11.2014 13:08:12 +00:00

Выходит, нет.

post-factum ★★★★★
(25.11.2014 13:10:55 +00:00)

Ссылка

Ответ на: комментарий от post-factum 25.11.2014 13:10:26 +00:00

Да, именно так. На eth1 подсетка самого предприятия, на VLANах eth0 висят арендаторы.

babich ★
(25.11.2014 13:11:25 +00:00) автор топика

В общем, спасибо всем участникам, вроде бы разобрались, как оно было. Дальше буду копать сам.

babich ★
(25.11.2014 13:12:07 +00:00) автор топика

Ссылка

Ответ на: комментарий от babich 25.11.2014 13:11:25 +00:00

Всё предприятие в одной канальной подсети? Много компов?

post-factum ★★★★★
(25.11.2014 13:12:24 +00:00)

Ответ на: комментарий от babich 25.11.2014 13:10:29 +00:00

eth2 не понятно для чего, eth1 не нужен, можно было обойтись одним транковым eth0 при желании, раз уж с dlink идет транком... хотя я не совсем понимаю зачем... D-Link куда то еще что раздает или что это за железка, не совсем понимаю зачем транк на него, т.е. зачем нужны ваши внутренние сети по сути на D-Link?

HarDX ★★
(25.11.2014 13:15:06 +00:00)

Ответ на: комментарий от babich 25.11.2014 13:08:12 +00:00

Там eth0 (не-VLAN интерфейс) без адреса. Получается,
что варианта с нетегированным трафиком нет ?

Видимо да. Хотя, само по себе, его наличие там зависит от коммутатора. Так-то eth0 может оказаться в каком-нибудь бридже, и этот трафик может куда-то и улететь.

Или есть какой-то VLAN по-умолчанию, native вроде или как-то
так ? Если явно не задан, есть или нет ?

Завист от производителя и от настроек. Но чаще он есть, и это VLAN 1.

AS ★★★★★
(25.11.2014 13:25:45 +00:00)

Ссылка

Ответ на: комментарий от post-factum 25.11.2014 13:12:24 +00:00

Нет, порядка тридцати. Вполне умещаются.

babich ★
(25.11.2014 13:34:35 +00:00) автор топика

Ссылка

Ответ на: комментарий от HarDX 25.11.2014 13:15:06 +00:00

eth2 это провайдер. eth1 - «внутренняя сеть» предприятия. Зачем поделено - хз. eth0 - для VLANов. D-Link (судя по файлам настроек сервера) как раз таки тэгирует и растэгирует пакеты, раздает интернет по предприятию и арендаторам. На сервере с CentOS происходит маршрутизация трафика и ограничение потоков для каждой подсети. Как-то так.

babich ★
(25.11.2014 13:37:14 +00:00) автор топика

Ответ на: комментарий от babich 25.11.2014 13:37:14 +00:00

А ну тады понятно (я думал у вас провайдер через D-Link (модем или роутер какой), D-Link и TP-Link L2 у вас тупа, провайдер с eth2, только можно было eth1 исключить и засунуть в eth0 так же транком...

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

HarDX ★★
(25.11.2014 13:48:33 +00:00)

Ссылка

Ответ на: комментарий от babich 25.11.2014 13:37:14 +00:00

Я обычно что типа того рисую http://s52.radikal.ru/i135/1411/76/eb687174f9f5.png в draw.io и в рамочку, тогда более менее любому сотруднику понятно становиться хотя бы куды что воткнуто )

Хотя схема не по стандартам каюся...

HarDX ★★
(25.11.2014 14:03:28 +00:00)

Ответ на: комментарий от HarDX 25.11.2014 14:03:28 +00:00

в draw.io

То же самое можно в LibreOffice Draw нарисовать, почему веб-сервис?

af5 ★★★★★
(26.11.2014 03:54:48 +00:00)

Ответ на: комментарий от af5 26.11.2014 03:54:48 +00:00

Из коробки куча объектов Cisco и т.п., плюс синхрит в гуглодоку... + совместно можно работать... + не надо ставить LibreOffice )

HarDX ★★
(26.11.2014 06:03:01 +00:00)

Ответ на: комментарий от HarDX 26.11.2014 06:03:01 +00:00

Что за дистрибутив у тебя без LO?

af5 ★★★★★
(26.11.2014 06:46:26 +00:00)

Ответ на: комментарий от af5 26.11.2014 06:46:26 +00:00

LO монстроподобное просто не использую ) он загибается на больших и сложных doc (docx) файлах, в основном WPS Office он жует все от MS, + google doc в последнее время все больше использую.

odf и т.п. не аргумент для меня т.к. по работе (включая зарубежные компании - doc или pdf) и т.п. никто его не использует.

HarDX ★★
(26.11.2014 07:12:28 +00:00)