Напишу я, пожалуй, об одной очень очевидной вещи (которая, тем не менее, очевидна не всем).
Напишу я про то, как linux-машине жить в условиях двух вланов. Ну и заодно мы научимся заставлять машинку отвечать на пакеты, пришедшие на определенный интерфейс (логический) с этого же интерфейса.
У нас есть 3 примера:
1) просто подключить машину к двум VLANам
2) обеспечить возможность держать на машине виртуальные машины из двух VLANов
3) создадим виртуальную машину с 2мя VLANами.
У нас есть:
1) vlan с номером 100, подсеть 192.168.0.1/24
2) транк с vlan’ом 101, подсеть 192.168.1.1/24
Что нужно сделать написано выше. Сетевая карта одна, само собой.
Не забудьте поставить пакет vlan
Запустим машину с 2мя VLANами:
Пишем примерно следующее в /etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 87.250.235.62
auto eth0.101
iface eth0.101 inet static
address 192.168.1.2
netmask 255.255.255.0
post-up ip ro add default via 192.168.1.1 dev eth0.101 src 192.168.1.2 table 17 mtu 1450 advmss 1410
post-up ip ru add from 192.168.1.2 lookup 17 priority 17
pre-down ip ru del from 192.168.1.2 lookup 17 priority 17
pre-down ip ro del default via 192.168.1.1 dev eth0 src 192.168.1.2 table 17 mtu 1450 advmss 1410
Здесь стоит обратить внимание на несколько моментов.
Название интерфейса eth0.101. Debian и Ubuntu автоматически распознает такие имена интерфейсов и производит все нужные действия в системе при старте такого интерфейса.
В post-up второго интерфейса мы указываем, что пакеты, отправляемые от ip адреса 192.168.1.2 должны отправляться через шлюз 192.168.1.1 с интерфейса eth0.101. В pre-down мы удаляем эти правила, соответственно. MTU и advmss стоит выставить подходящие для вашей сети.
Для интерфейса eth0.101 мы не указываем gateway.
Собственно, всё. Используя этот простенький пример мы можем создавать сколько угодно VLANов в нашей сети между linux-машинами (при условии, что ваши коммутаторы это поддерживают). И используя этот же пример (а точнее его часть с pre-up, pre-down) — мы можем указывать, через какой интерфейс отправлять исходящий трафик для определенного IP.
Теперь поговорим о том, как создавать виртуалки в разных VLANах на одной машине.
В этом случае /etc/network/interfaces будет выглядеть примерно так:
auto br0
iface br0 inet static
address 192.168.0.2
netmask 255.255.255.0
bridge_ports eth0
bridge_stp off
post-up /sbin/ip route replace default via 192.168.0.1 mtu 1450 advmss 1410
auto br0.101
iface br0.101 inet manual
bridge_ports eth0.101
bridge_stp off
pre-up modprobe 8021q
И для работы этой схемы нужно выполнить команду:
root@host:~# ebtables -t broute -A BROUTING -i eth0 -p 802_1Q -j DROP
(только не спрашивайте откуда это и что это =) спасибо Бегемоту за решение проблемы).
Теперь мы можем цеплять виртуалки к br0 или br0.101. Им ничего не нужно знать о вланах.
Сложность появляется тогда, когда нам понадобится виртуалка с интерфейсами сразу в двух VLANах. Тут есть несколько моментов. Во-первых, само собой, мы цепляем 2 сетевых карты виртуалки к разным бриджам. Во-вторых, внутри виртуалки мы создаем не eth0 и eth0.101, а eth0 и eth1.
Для lxctl это выглядит так (файл /var/lib/lxc/container-name/config):
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.mtu = 1500
lxc.network.hwaddr = F0:26:cb:de:02:01
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0.101
lxc.network.name = eth1
lxc.network.mtu = 1500
lxc.network.hwaddr = F0:26:cb:de:02:32
Проверьте, чтобы маки были разные.
Для kvm это будет выглядеть примерно так (/etc/libvirtd/qemu/vmname.conf):
<interface type='bridge'>
<mac address='52:54:00:4e:da:1e'/>
<source bridge='br0'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<interface type='bridge'>
<mac address='52:54:00:4e:da:12'/>
<source bridge='br0.101'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</interface>
Тут стоит обратить внимание на то, чтобы slot= и мак адреса были разными. Ну или проще создайте через virt-manager.
Вот. Теперь у нас в виртуалке есть 2 интерфейса, каждый из них смотрит в разный vlan.
/etc/network/interfaces в виртуалке будет выглядеть так:
auto eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
gateway 87.250.235.62
auto eth1
iface eth1 inet static
address 192.168.1.3
netmask 255.255.255.0
post-up ip ro add default via 192.168.1.1 dev eth1 src 192.168.1.3 table 17 mtu 1450 advmss 1410
post-up ip ru add from 192.168.1.3 lookup 17 priority 17
pre-down ip ru del from 192.168.1.3 lookup 17 priority 17
pre-down ip ro del default via 192.168.1.1 dev eth1 src 192.168.1.2 table 17 mtu 1450 advmss 1410
Если пакет придет на eth1 — то и ответит на него машинка с eth1. По умолчанию пакеты будут отправляться с eth0. Изменить это для отдельных подсетей можно с помощью того же ip ro в post-up.
Вот. Как-то так.
В общем то мораль здесь простая — нужно быть просто внимательным)
Эм… Я один не проникся статьей?
Собственно, маршрутизация описана, ну ок, допустим — а vlan’ы то где?)
Да и финт с маршрутизацией я тоже не понял — что вам даёт кроме выставления приоритета? Ну и могу из настроек предположить, что подсеть 192.168.1.0/24, у вас тоже недоступна напрямую и ходите вы в неё через шлюз 1.1, что тоже странно.
Поясните, пожалуйста, ваши мысли)
vlanы в названиях интерфейсов. Много кто крутит настройки vlan’ов лапками — в дебиане этого не нужно.
А маршрутизация такая просто для примера. Не суть важно, какие там подсети.
И основной смысл всё же в том, чтобы под этим хозяйством виртуалки завести. Например, проблему с ebtables решить с наскока не удалось (да и никто внутрь них даже не думал смотреть изначально).
Эм… Я всё же не догоняю, а кто сказал eth0 помечать пакеты 100 vid’ом или вы забыли .100? Кстати можно ли так стыковать — eth0:1.101?
И заодно можно prooflink какой-то на доку, сам я как-то не нашёл… Казалось бы тут(http://www.debian.org/doc/manuals/debian-reference/ch05.en.html) должно быть, но нет.
А, вот нашёл, пока ответ писал) — http://wiki.debian.org/NetworkConfiguration#Howto_use_vlan_.28dot1q.2C_802.1q.2C_trunk.29_.28Etch.2C_Lenny.29
100й в данном случае — native, его маркать не нужно.
eth0.101:1 должно работать, если ничего не поменялось.
Можно маркать и native vlan, но это лишняя нагрузка только. Всё от security-задач зависит, впрочем.
Чтобы покрасить и native — нужно будет заводить eth0 без конфига и к нему уже заводить сверху eth0.100.
Эм, не понял зачем и eth0 и eth0.100? Или типа eth0.100 не примет нетегированный трафик?
eth0 затем, чтобы железная карточка заработала гарантированно. Иначе на старте могут быть спецэффекты в виде неподнимающихся теггированных интерфейсов.
В первоначальной настройке /etc/network/interfaces Откуда взялся eth1 ?
Вроде поправил, спасибо.