Задача: на виртульной машине с Ubuntu 24 изолировать два сетевых интерфейса между собой.

Мы боролись с ассиметрией в виртуальной среде NSX-T, где distributed firewall к ней совсем нетерпим, необходимо было разнести маршруты 0/0 и 10/8 по разным интерфейсам, при это было важно, чтобы они не были в одной таблице маршрутизации.

И когда сетевик слышит, что нужно что-то «изолировать» - он идет натягивать VRF. По официальной документации netplan поддерживает VRF - то, что надо, берем.

Адаптируем под себя:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0: # -> vrf-mgmt
      addresses:
        - 10.10.8.101/23
      routes:
        - to: 10.0.0.0/8
          via: 10.10.8.1
      routing-policy:
        - from: 10.10.8.101/23
    eth1: # -> main
      addresses:
        - 10.11.8.3/29
      gateway4: 10.11.8.1
  vrfs:
    vrf-mgmt:
      table: 101
      interfaces: [eth0]

Интерфейсы разнесены по VRF, всё выглядит корректно:

# ip route
default via 10.11.8.1 dev eth1 proto static
10.11.8.0/29 dev eth1 proto kernel scope link src 10.11.8.3

# ip route show vrf vrf-mgmt
10.0.0.0/8 via 10.10.8.1 dev eth0 proto static
10.10.8.0/23 dev eth0 proto kernel scope link src 10.10.8.101

Проверяем доступ извне до IP-адреса внутри VRF - ping работает! А для сетевика полученный ICMP-ответ - это как документ с печатью, подтверждающий наличие доступа. Проверяем SSH, получаем «connection refused», перезагружаем VM(на всякий), доступа нет, интересно. Отключаем iptables(в любой непонятной ситуации), но и это не помогает. Любые дальнейшие эксперименты показывают, что и другие сервисы, привязанные к IP-адресу eth0 (который внутри VRF) также недоступны 🤷

Я не знал, что все сервисы работают в контексте VRF по умолчанию, т.е. процессы используют таблицу маршрутизации по умолчанию и имеют доступ к прослушиваемым IP-адресам только в этом дефолтном VRF, если не указано иное.

Если для ping внутри VRF мы можем использовать опцию -I, которая указывает src-интерфейс внутри VRF и ping начинает работать, то сервису SSH необходимо явно указать - используй контекст vrf-mgmt! Это будет касаться и других сервисов, которые должны работать с IP-адресами внутри VRF.

Решение для SSH: в systemd для юнита sshd изменить ExecStart с указанием использования VRF. Пока идет отладка изменим сразу /lib/systemd/system/ssh.service. (Напрямую лучше не изменять системные файлы, потому что любое обновление перезатрет изменения, нужно использовать override)

Было
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS

Стало
ExecStart=/bin/ip vrf exec vrf-mgmt /usr/sbin/sshd -D $SSHD_OPTS

Команда ip vrf exec запускает процесс sshd в контексте vrf-mgmt.

После изменения файла службы нужно перезагрузить конфигурацию systemd и службу SSH, чтобы изменения вступили в силу:

systemctl daemon-reload
systemctl restart ssh

Проверяем SSH извне на IP внутри VRF - доступ есть!

Если цель вынести только управление VM в отдельный VRF, то в принципе, на этом можно остановиться. Но в нашем случае были и другие сервисы, которым нужен доступ к VRF.

Идем дальше.

Есть решение, в котором все сервисы будут работать со всеми VRF в системе - L3 Master Device, известный как l3mdev:

Official reference
Enables child sockets to inherit the L3 master device index. Enabling this option allows a “global” listen socket to work across L3 master domains (e.g.,VRFs) with connected sockets derived from the listen socket to be bound to the L3 domain in which the packets originated. Only valid when the kernel was compiled with CONFIG_NET_L3_MASTER_DEV

Проверим наличие модуля CONFIG_NET_L3_MASTER_DEV в конфигурационном файле ядра:

grep CONFIG_NET_L3_MASTER_DEV /boot/config-$(uname -r)

Если видим CONFIG_NET_L3_MASTER_DEV=y, значит модуль встроен в ядро.

Включаем для tcp/udp:

sysctl -w net.ipv4.tcp_l3mdev_accept=1
sysctl -w net.ipv4.udp_l3mdev_accept=1

Проверяем, убеждаемся что все сервисы начинают работать внутри VRF. Успех 😮‍💨

По документации, l3mdev ухудшает производительность на 2-3%. Попробую разобраться как он работает.

#Задача