Мне нужно реализовать службу прозрачной локальной сети на основе VLAN в Linux. Это означает, что мне нужно взять настроенную VLAN и переслать ее прямо на указанный порт (все широковещательные / многоадресные и одноадресные пакеты).
Тривиальным решением будет определение моста 1 к 1 между интерфейсом VLAN и указанным портом. Обратной стороной этого решения является то, что я узнал обо всех MAC-адресах в этом туннеле. Я работаю на встроенном устройстве с ограниченной таблицей Mac и хочу избежать загрязнения таблицы Mac устройствами из сетей, которые я подключаю.
Я пытался найти способ использовать ebtables для этой задачи, но похоже, что -o параметры ebtables полезны только в цепочке FORWARD, которая возникает после обучения Mac. Цепочка BROUTING - это та, которая мне нужна, но похоже, что с этого момента я не могу заставить пакет выйти на конкретный интерфейс.
Итак, ebtables, похоже, тупиковый. Есть другие варианты? В идеальном мире я бы предпочел иметь службу TLS на основе любого ключа, и не только VLAN, но и VLAN пока подойдут.
Спасибо, Илья.
ОБНОВИТЬ: Добавлено решение, все еще использующее мост. Это возможно, для случая VLAN в любом случае использовать мост Linux для его возможностей фильтрации VLAN и полностью отключить обучение MAC. tc ниже может быть полезен для его общего способа сопоставления селекторов (вероятно, было бы проще использовать tc с адекватным соответствием для чего-то еще, кроме VLAN в качестве селектора, чем использование моста без кода для его обработки).
Есть возможность отключить изучение MAC-адресов. Это сделано с bridge link команда. Затем мост можно настроить для фильтрации VLAN (используя также bridge vlan): ему не нужен MAC-адрес, вся его пересылка будет выполняться на основе настроенных настроек VLAN.
учиться или учиться вне
Определяет, будет ли данный порт узнавать MAC-адреса из полученного трафика или нет. Если обучение отключено, мост в конечном итоге затопит любой трафик, для которого у него нет записи FDB. По умолчанию этот флаг установлен.
learning_sync включено или learning_sync выключено
Определяет, будет ли данный порт синхронизировать MAC-адреса, полученные на порте устройства, с мостом FDB.
Так, например, давайте посмотрим на систему с интерфейсом eth0 в качестве магистрали с помеченными фреймами, а eth1 eth2 eth3 соответственно. для vlan с идентификаторами 10, 20 и 30 без тегов. Это будет сделано с помощью:
ip link add name br0 type bridge vlan_filtering 1
#remove implicit bridge's self port br0 from any interaction.
# Might have to not be done if using an IP on the bridge
# but more configuration might then be needed anyway.
bridge vlan del vid 1 dev br0 self
bridge link set dev br0 learning off learning_sync off self
for $nic in eth0 eth1 eth2 eth3; do
ip link set dev $nic master br0
bridge link set dev $nic learning off learning_sync off
bridge vlan del vid 1 dev $nic
done
ip link set br0 up
bridge vlan add 10 dev eth0
bridge vlan add 20 dev eth0
bridge vlan add 30 dev eth0
bridge vlan add vid 10 pvid 10 untagged dev eth1
bridge vlan add vid 20 pvid 20 untagged dev eth2
bridge vlan add vid 30 pvid 30 untagged dev eth3
Чтобы проверить, как ведет себя эта другая установка, просто замените следующие строки в сценарии установки в конце (которые используют tc метод, описанный в следующей части ответа):
ip netns exec fakebridge tc qdisc add dev trunk0 ingress
for vlan in 10 20 30; do
ip netns exec fakebridge tc qdisc add dev vlan$vlan ingress
ip netns exec fakebridge tc filter add dev vlan$vlan parent ffff: matchall action vlan push id $vlan action mirred egress redirect dev trunk0
ip netns exec fakebridge tc filter add dev trunk0 parent ffff: basic match "meta(vlan mask 0xfff eq $vlan)" action vlan pop action mirred egress redirect dev vlan$vlan
done
вместо этого (это больше не не настоящие мост но все равно ...):
ip -n fakebridge link add name br0 type bridge vlan_filtering 1
ip netns exec fakebridge bridge vlan del vid 1 dev br0 self #remove implicit bridge's self port br0 from any interaction
ip -n fakebridge link set dev trunk0 master br0
ip netns exec fakebridge bridge vlan del vid 1 dev trunk0
ip netns exec fakebridge bridge link set dev trunk0 learning off learning_sync off
for vlan in 10 20 30; do
ip -n fakebridge link set dev vlan$vlan master br0
ip netns exec fakebridge bridge link set dev vlan$vlan learning off learning_sync off
ip netns exec fakebridge bridge vlan add vid $vlan dev trunk0
ip netns exec fakebridge bridge vlan del vid 1 dev vlan$vlan
ip netns exec fakebridge bridge vlan add vid $vlan pvid $vlan untagged dev vlan$vlan
done
ip -n fakebridge link set br0 up
Также можно вообще не использовать мост и работать с идентификатором VLAN для операций, используя ...
tc может управлять VLAN напрямую, используя tc vlan:
ОПИСАНИЕ
Действие vlan позволяет выполнять инкапсуляцию или декапсуляцию 802.1Q в пакете, что отражается в режимах работы POP, PUSH и MODIFY. Режим POP прост, так как не требуется никакой дополнительной информации, чтобы просто отбросить инкапсуляцию внешней VLAN. Для режимов PUSH и MODIFY требуется как минимум VLANID, и они позволяют дополнительно выбрать VLANPROTO для использования.
Наряду с другими tc функции:
u32 match u32 0 0 на старых ядрах) для безусловного соответствия пакетам,и обычная сантехника (есть qdisc, прикреплять фильтр с участием действие), можно перемещать пакеты с одного интерфейса на другой при инкапсуляции или декапсуляции идентификатора VLAN 802.1Q. Система не будет передавать и маршрутизировать эти пакеты. Системе не придется запоминать MAC-адрес или манипулировать IP-адресом, ее осведомленность о пакетах и протоколах будет ограничена тем, что делается с tc.
Обратите внимание, что это доказательство концепции. Конечно, реальной системе все равно придется общаться с использованием IP-адреса, чтобы не мешать этим настройкам. Правильная реализация этого для производства, вероятно, вызовет непредвиденные дополнительные трудности, учитывая, что tc это сложный инструмент. Также могут быть другие лучшие способы, доступные с tc обращаться с вещами в более общем плане (думать о tc flow использовать идентификатор VLAN в качестве ключа для сопоставления с идентификатором класса, который можно использовать в более общем смысле, или, возможно, можно использовать что-то еще в качестве ключа помимо VLAN, если есть способ инкапирования / декапирования.).
Так, например, давайте посмотрим на систему с интерфейсом eth0 в качестве магистрали с помеченными фреймами, а eth1 eth2 eth3 соответственно. для vlan с идентификаторами 10, 20 и 30 без тегов. Разрешить помеченной стороне взаимодействовать с правильной немаркированной стороной, а обратное будет сделано с помощью:
tc qdisc add dev eth0 handle ffff: ingress
tc qdisc add dev eth1 handle ffff: ingress
tc qdisc add dev eth2 handle ffff: ingress
tc qdisc add dev eth3 handle ffff: ingress
tc filter add dev eth0 parent ffff: basic match "meta(vlan mask 0xfff eq 10)" action vlan pop action mirred egress redirect dev eth1
tc filter add dev eth0 parent ffff: basic match "meta(vlan mask 0xfff eq 20)" action vlan pop action mirred egress redirect dev eth2
tc filter add dev eth0 parent ffff: basic match "meta(vlan mask 0xfff eq 30)" action vlan pop action mirred egress redirect dev eth3
tc filter add dev eth1 parent ffff: matchall action vlan push id 10 action mirred egress redirect dev eth0
tc filter add dev eth2 parent ffff: matchall action vlan push id 20 action mirred egress redirect dev eth0
tc filter add dev eth3 parent ffff: matchall action vlan push id 30 action mirred egress redirect dev eth0
Может показаться логичным, что фактические интерфейсы должны быть переведены в неразборчивый режим для фактического перенаправления трафика, но в ядре 5.0.x и в этом не было необходимости. veth интерфейсы во время тестирования в любом случае.
Я провел несколько экспериментов по реализации фальшивого моста с одним тегированным интерфейсом магистрали и несколькими нетегированными интерфейсами vlan с использованием сетевых пространств имен. Каждый «хост» имеет собственное пространство имен и связан с другими хостами с помощью сетевых элементов, которые сами реализованы с помощью Другой сетевые пространства имен, которые включают мост. Фактическая система, имитирующая то, что может делать ваше встроенное устройство, будет называться Fakebridge, поскольку он может выглядеть как мост с поддержкой VLAN.
tagged untagged _______
.|host10b|
+-------+ . =======
+------+ | |....vlan10....|host10|
| |.......trunk......|fake | ======
|router|..................| |....vlan20....|host20|
| | (vlans 10+20+30) |bridge | ======
+------+ | |....vlan30....|host30|
+-------+ ------
Итак, 1 + 1 + 4 = 6 хостов, 1 + 3 = 4 сети, всего 10 пространств имен.
После запуска приведенного ниже скрипта (от имени пользователя root) можно тестировать и наблюдать с помощью таких команд, как:
term1:
ip netns exec fakebridge tcpdump -l -n -s0 -e -p -i trunk0
term2:
ip netns exec host10 ping -c1 198.51.100.20
Давая например:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on trunk0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:27:56.036743 c2:e8:f4:79:28:96 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Request who-has 192.0.2.110 tell 192.0.2.10, length 28
00:27:56.036777 16:51:fa:18:21:b0 > c2:e8:f4:79:28:96, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Reply 192.0.2.110 is-at 16:51:fa:18:21:b0, length 28
00:27:56.036794 c2:e8:f4:79:28:96 > 16:51:fa:18:21:b0, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4, 192.0.2.10 > 198.51.100.20: ICMP echo request, id 13483, seq 1, length 64
00:27:56.036807 16:51:fa:18:21:b0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 198.51.100.20 tell 198.51.100.120, length 28
00:27:56.036832 b6:1d:bc:33:87:98 > 16:51:fa:18:21:b0, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Reply 198.51.100.20 is-at b6:1d:bc:33:87:98, length 28
00:27:56.036841 16:51:fa:18:21:b0 > b6:1d:bc:33:87:98, ethertype 802.1Q (0x8100), length 102: vlan 20, p 0, ethertype IPv4, 192.0.2.10 > 198.51.100.20: ICMP echo request, id 13483, seq 1, length 64
00:27:56.036860 b6:1d:bc:33:87:98 > 16:51:fa:18:21:b0, ethertype 802.1Q (0x8100), length 102: vlan 20, p 0, ethertype IPv4, 198.51.100.20 > 192.0.2.10: ICMP echo reply, id 13483, seq 1, length 64
00:27:56.036867 16:51:fa:18:21:b0 > c2:e8:f4:79:28:96, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4, 198.51.100.20 > 192.0.2.10: ICMP echo reply, id 13483, seq 1, length 64
00:28:01.043203 16:51:fa:18:21:b0 > c2:e8:f4:79:28:96, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Request who-has 192.0.2.10 tell 192.0.2.110, length 28
00:28:01.043246 b6:1d:bc:33:87:98 > 16:51:fa:18:21:b0, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 198.51.100.120 tell 198.51.100.20, length 28
00:28:01.043287 c2:e8:f4:79:28:96 > 16:51:fa:18:21:b0, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Reply 192.0.2.10 is-at c2:e8:f4:79:28:96, length 28
00:28:01.043284 16:51:fa:18:21:b0 > b6:1d:bc:33:87:98, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Reply 198.51.100.120 is-at 16:51:fa:18:21:b0, length 28
Сценарий установки для запуска от имени пользователя root. Он создает различные сетевые пространства имен, используя ip netns, заполняет необходимые сетевые ссылки (мосты и veth), настраивает tc фильтры на Fakebridgeи, наконец, настройте IP-адреса различных хостов, чтобы можно было экспериментировать. Fakebridge остается без IP или моста. Нет таблицы MAC-адресов, которую можно было бы заполнить: ip neigh или bridge fdb не будет показывать ничего, связанного с трафиком, поскольку нет ни ARP без IP, ни MAC без моста.
#!/bin/sh
if ip netns id | grep -qv '^ *$' ; then
printf 'ERROR: leave netns "%s" first\n' $(ip netns id) >&2
exit 1
fi
hosts='router fakebridge host10 host10b host20 host30'
nets='trunk vlan10 vlan20 vlan30'
for ns in $hosts $nets; do
ip netns del $ns 2>/dev/null || :
ip netns add $ns
ip netns exec $ns sysctl -q -w net.ipv6.conf.default.disable_ipv6=1
ip netns exec $ns sysctl -q -w net.ipv4.icmp_echo_ignore_broadcasts=0
done
for ns in $hosts; do
ip -n $ns link set lo up
done
bmac=1
for ns in $nets; do
ip -n $ns link add bridge0 address 02:00:00:00:00:$(printf '%02d' $bmac) type bridge
ip -n $ns link set bridge0 up
bmac=$(($bmac+1))
done
link_ns () {
ip -n $1 link add name "$3" type veth peer netns $2 name "$4"
ip -n $1 link set dev "$3" up
ip -n $2 link set dev "$4" up
if printf '%s\n' "$nets" | grep -q -w "$1"; then
ip -n "$1" link set dev "$3" master bridge0
fi
if printf '%s\n' "$nets" | grep -q -w "$2"; then
ip -n "$2" link set dev "$4" master bridge0
fi
}
link_ns trunk fakebridge fakebridge trunk0
link_ns vlan10 fakebridge fakebridge vlan10
link_ns vlan20 fakebridge fakebridge vlan20
link_ns vlan30 fakebridge fakebridge vlan30
link_ns trunk router router trunk0
link_ns vlan10 host10 host10 eth0
link_ns vlan10 host10b host10b eth0
link_ns vlan20 host20 host20 eth0
link_ns vlan30 host30 host30 eth0
ip netns exec fakebridge tc qdisc add dev trunk0 ingress
for vlan in 10 20 30; do
ip netns exec fakebridge tc qdisc add dev vlan$vlan ingress
ip netns exec fakebridge tc filter add dev vlan$vlan parent ffff: matchall action vlan push id $vlan action mirred egress redirect dev trunk0
ip netns exec fakebridge tc filter add dev trunk0 parent ffff: basic match "meta(vlan mask 0xfff eq $vlan)" action vlan pop action mirred egress redirect dev vlan$vlan
done
for vlan in 10 20 30; do
ip -n router link add link trunk0 name trunk.$vlan type vlan id $vlan
ip -n router link set dev trunk.$vlan up
ip netns exec router sysctl -q -w net.ipv4.conf.trunk/$vlan.forwarding=1
done
ip -n router address add 192.0.2.110/24 dev trunk.10
ip -n router address add 198.51.100.120/24 dev trunk.20
ip -n router address add 203.0.113.130/24 dev trunk.30
ip -n host10 address add 192.0.2.10/24 dev eth0
ip -n host10b address add 192.0.2.11/24 dev eth0
ip -n host20 address add 198.51.100.20/24 dev eth0
ip -n host30 address add 203.0.113.30/24 dev eth0
ip -n host10 route add default via 192.0.2.110
ip -n host10b route add default via 192.0.2.110
ip -n host20 route add default via 198.51.100.120
ip -n host30 route add default via 203.0.113.130