Регистрация Войти
Рейтинг:1
avatar Server

Почему трафик направляется между разными veth-устройствами?

флаг ua
kriomant

У меня проблема: существует непредвиденный путь маршрутизации между виртуальными сетевыми устройствами.

Давайте создадим две независимые пары устройств veth-peer:

$ sudo ip link add veth0 type veth имя однорангового узла peer0
$ sudo ip link add veth1 type veth имя однорангового узла peer1

Назначьте адреса устройствам peerX:

$ sudo IP-адрес добавить ab:: dev peer0
$ sudo ip addr добавить cd:: dev peer1

Настройте все устройства:

$ sudo ip link set dev veth0 up
$ sudo ip link set dev veth1 up
$ sudo ip link set dev peer1 up
$ sudo ip link set dev peer0 up

Проверить устройства:

$ ip а
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    ссылка/петля 00:00:00:00:00:00 брд 00:00:00:00:00:00
    инет 127.0.0.1/8 область хоста lo
       valid_lft навсегда
    inet6 :: 1/128 узел области видимости
       valid_lft навсегда
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel состояние UP группа по умолчанию qlen 1000
    ссылка/эфир 02:82:b2:df:b0:58 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 область глобальная динамическая enp0s3
       valid_lft 84429 сек. selected_lft 84 429 сек.
    inet6 fe80::82:b2ff:fedf:b058/64 ссылка на область действия
       valid_lft навсегда
3: peer0@veth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    ссылка/эфир 6e:8d:c0:7c:02:9c brd ff:ff:ff:ff:ff:ff
    inet6 ab::/128 глобальная область видимости
       valid_lft навсегда
    ссылка на область inet6 fe80::6c8d:c0ff:fe7c:29c/64
       valid_lft навсегда
4: veth0@peer0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    ссылка/эфир 4e:43:26:75:10:11 брд ff:ff:ff:ff:ff:ff
    ссылка на область inet6 fe80::4c43:26ff:fe75:1011/64
       valid_lft навсегда
5: peer1@veth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    ссылка/эфир ea:8c:82:e6:2e:a9 brd ff:ff:ff:ff:ff:ff
    inet6 cd::/128 глобальная область видимости
       valid_lft навсегда
    ссылка на область inet6 fe80::e88c:82ff:fee6:2ea9/64
       valid_lft навсегда
6: veth1@peer1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    ссылка/эфир da:5a:68:b1:e8:43 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::d85a:68ff:feb1:e843/64 ссылка на область действия
       valid_lft навсегда

и маршруты:

$ ip р
по умолчанию через 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 метрика 100
10.0.2.0/24 dev enp0s3 ссылка на область действия ядра proto src 10.0.2.15
10.0.2.2 dev enp0s3 proto dhcp scope link src 10.0.2.15 метрика 100

Теперь слушайте peer0 на UDP-порту 2000:

$ nc -u -6 -l аб:: 2000

И отправить пакет через peer1:

$ echo -n abc nc -u -6 -s cd::ab::2000

И слушаю нк отпечатки азбука! Но Почему? пир0 и одноранговый узел1 никак не связаны. Если я правильно понял, слушаю нк должен привязываться к пир0 и отправка нк должен привязываться к одноранговый узел1.

28
0 + 0
Рейтинг:1
A.B avatar Server
флаг cl
A.B

peer0 и peer1 никак не связаны.

Все они являются интерфейсами, принадлежащими системе, поэтому они подключены к системе. Маршрутизация происходит в системе.Система будет обмениваться данными между принадлежащими ей адресами напрямую, без маршрутизации пакетов вовне, т.е. без пересылки пакетов через интерфейсы veth, а с использованием своего loopback-интерфейса (Дев Ло ниже):

# ip маршрут от cd:: до ab::
local ab:: from cd:: dev lo table local proto kernel src ab:: metric 0 pref medium

Кроме того, здесь это не очень помогает, но при отображении маршрутов без какого-либо значения IPv6, чтобы намекнуть на IPv6, -6 должен быть задан, иначе по умолчанию используется IPv4.

# ip -6 маршрут
ab:: dev peer0 proto kernel metric 256 pref medium
cd:: dev peer1 proto kernel metric 256 pref medium
fe80::/64 dev peer1 proto kernel metric 256 pref средний
fe80::/64 dev veth1 proto kernel metric 256 pref средний
fe80::/64 dev peer0 proto kernel metric 256 pref средний
fe80::/64 dev veth0 протоядерная метрика 256 pref средний
# ip -6 маршрут показать таблицу локальный
local :: 1 dev lo proto kernel metric 0 pref medium
local fe80::4c43:26ff:fe75:1011 dev veth0 метрика протоядра 0 pref средний
local fe80::6c8d:c0ff:fe7c:29c dev peer0 proto kernel metric 0 pref medium
local fe80::d85a:68ff:feb1:e843 dev veth1 метрика протоядра 0 pref средний
local fe80::e88c:82ff:fee6:2ea9 dev peer1 proto kernel metric 0 pref medium
многоадресная рассылка ff00::/8 dev veth1 proto kernel metric 256 pref medium
многоадресная рассылка ff00::/8 dev peer1 proto kernel metric 256 pref medium
многоадресная рассылка ff00::/8 dev veth0 proto kernel metric 256 pref medium
многоадресная рассылка ff00::/8 dev peer0 proto kernel metric 256 pref medium
0 + 0
флаг ua
kriomant
Благодарить. Значит, чтобы их изолировать, мне нужно использовать отдельные сетевые пространства имен?
0
Ответить
A.B avatar
флаг cl
A.B
Я не знаю точно, что вы собираетесь делать и почему есть две пары veth-интерфейсов, а не одна пара, но да, основное использование veth-интерфейсов — это сетевые пространства имен (в том же пространстве имен есть и другие менее распространенные варианты использования, когда также с помощью моста).
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.