Прямое соединение двух пространств имен с помощью устройств veth, какой префикс сети следует использовать?

TL;DR

Linux добавляет неявные маршруты при добавлении адресов. Когда адрес равен /32, добавление неявного маршрута невозможно. Затем вам нужно вручную добавить маршрут к другим IP-адресам (s ). Когда предполагается маршрутизация только к одному месту назначения (LAN или IP, но когда он симметричен, часто используется только IP-адрес партнера ), это можно сократить с помощью параметраip addresspeer, чтобы добавить маршрут в тот же выстрел. Таким образом, вместо двух команд ifconfigиспользуйте эту (с более новыми командами ip), и ping будет работать :

ip -n net1 link set veth1 up
ip -n net2 link set veth2 up
ip -n net1 address add 10.0.15.1 peer 10.0.15.2 dev veth1
ip -n net2 address add 10.0.15.2 peer 10.0.15.1 dev veth2

Длинный ответ:

Сначала несколько замечаний:

• Ваша проблема связана не с сетевыми пространствами имен, а с маршрутизацией, а также с особенностями Linux. В любом случае, сетевые пространства имен очень удобны для создания макета всей установки.
• В Linux следует отказаться от использования команды ifconfig(, а также команд route, brctlи т. д. )в пользу набора команд, предоставляемыхiproute2.. API ifconfig(ioctl )был наполовину заброшен в Linux, чтобы использовать вместо него netlink API, поэтому некоторые новые функции могут быть доступны только с помощью команды типа ip....
• Достаточно недавние инструменты iproute2 имеют для большинства своих подкоманд -параметр -netnsв качестве ярлыка при использовании пространств имен:ip -netns net1 FOOэквивалентен ip netns exec net1 ip FOO. Я буду использовать этот ярлык, когда это возможно ниже.Многие команды имеют сокращенные версии (, например:ip addrили даже ip aвместо ip address), а некоторые ключевые слова параметров могут быть опущены. Я не буду использовать здесь сокращения (, за исключением -nвместо-netns).

Linux неявно добавляет маршрут, когда задан адрес с сетевой маской. Когда сетевая маска равна /32, маршрут не может быть добавлен таким образом (или на самом деле все еще :есть локальный маршрут области действия, но он скрыт в локальном таблице маршрутизации (ip -n net1 route show table local), а не в основной таблице маршрутизации. Этого добавления можно избежать при использовании ip address addс флагом noprefixrouteдля некоторых установок, где неявный маршрут не нужен. Обратите внимание, что ifconfigтакже добавляет несколько настроек по умолчанию, например, по умолчанию (все биты узла устанавливают вариант )широковещательный адрес. Они должны быть явно заданы при использовании ip address.

Вот несколько примеров, которые помогут понять, что происходит.

Прямо перед добавлением адресов запуститеip monitorв одном из пространств имен, в отдельном терминале. Он отобразит любое из множества возможных сетевых изменений в сетевом пространстве имен, а затем запустит первое добавление адреса(ip netns exec net1 ifconfig veth1 10.0.15.1/24 up). Вот что обычно можно получить:

# ip -4 -n net1 monitor route
local 10.0.15.1 dev veth1 table local proto kernel scope host src 10.0.15.1 
broadcast 10.255.255.255 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 
10.0.0.0/8 dev veth1 proto kernel scope link src 10.0.15.1 linkdown 
broadcast 10.0.0.0 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 
Deleted 10.0.0.0/8 dev veth1 proto kernel scope link src 10.0.15.1 linkdown 
Deleted broadcast 10.255.255.255 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 
Deleted broadcast 10.0.0.0 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 
Deleted local 10.0.15.1 dev veth1 table local proto kernel scope host src 10.0.15.1 
local 10.0.15.1 dev veth1 table local proto kernel scope host src 10.0.15.1 
broadcast 10.0.15.255 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 
10.0.15.0/24 dev veth1 proto kernel scope link src 10.0.15.1 linkdown 
broadcast 10.0.15.0 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown

Здесь видно, чтоifconfigработает неэффективно :сначала добавляет маршрут /8, затем удаляет его и ставит запрошенный маршрут /24. Вероятно, это пережиток прошлого, который так и не был исправлен. Здесь было бы эквивалентноip -n net1 link set veth1 up; ip -n net1 address add 10.0.15.1/24 broadcast + dev veth1:

local 10.0.15.1 dev veth1 table local proto kernel scope host src 10.0.15.1 
broadcast 10.0.15.255 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 
10.0.15.0/24 dev veth1 proto kernel scope link src 10.0.15.1 linkdown 
broadcast 10.0.15.0 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 

А что, если вам не нужен /24? Вы можете установить /32 IP-адреса и добавить маршрут самостоятельно, например (. В то же время я переписываю (n, возможно, )более короткую версию всей настройки):

ip netns add net1
ip netns add net2
ip -n net1 link set lo up
ip -n net2 link set lo up
ip -n net1 link add name veth1 type veth peer netns net2 name veth2

Настройка интерфейсов (может быть выполнена до или после, это не изменит окончательный результат, как только он будет установлен):

ip -n net1 link set veth1 up
ip -n net2 link set veth2 up

Адреса:

ip -n net1 address add 10.0.15.1/32 dev veth1
ip -n net2 address add 10.0.15.2/32 dev veth2

Здесь ip -4 -n net1 monitor routeпоказал бы толькоlocal 10.0.15.1 dev veth1 table local proto kernel scope host src 10.0.15.1:только скрытый локальный маршрут.

Маршруты:

ip -n net1 route add 10.0.15.2/32 dev veth1
ip -n net2 route add 10.0.15.1/32 dev veth2

Два значения адреса могут быть совершенно не связаны. Вы также можете использовать 192.0.2.1 и 198.51.100.2. Некоторые хостинг-провайдеры используют этот механизм для предоставления дополнительных «отказоустойчивых IP-адресов». На самом деле для этого конкретного случая есть ярлык, когда снова маршрут будет добавлен по адресу за один раз, если будет предоставлена ​​​​соответствующая информация. Так что вместо 4-х предыдущих команд достаточно этой:

ip -n net1 address add 10.0.15.1 peer 10.0.15.2 dev veth1
ip -n net2 address add 10.0.15.2 peer 10.0.15.1 dev veth2

Обратите внимание, что во всех случаях это по-прежнему интерфейсы Ethernet, а не точки -— -, поэтому на канальном уровне все равно будут выполняться запросы ARP для поиска другого IP-адреса.

Заключительное замечание :Если вы собираетесь использовать более двух сетевых пространств имен вместе, вам, вероятно, следует вернуться к использованию маски сети LAN, и вам, скорее всего, потребуется создать интерфейс моста (, который вы можете поместить в него. исходное пространство имен в одном из вновь созданных пространств имен, но я советую вам поместить его в собственное зарезервированное пространство имен, чтобы избежать непредвиденных взаимодействий ). Затем для каждой пары интерфейсов veth одна сторона должна быть помещена в сетевое пространство имен моста и подчинена мосту (, например:ip -n mybridgens link set vethp1 master bridge0).