LIFE_OF_NETWORK_ENGINEER Telegram 152
Задача: на виртульной машине с 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%. Попробую разобраться как он работает.

#Задача
Please open Telegram to view this post
VIEW IN TELEGRAM
👍25🔥123🫡21



tgoop.com/life_of_network_engineer/152
Create:
Last Update:

Задача: на виртульной машине с 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%. Попробую разобраться как он работает.

#Задача

BY Будни сетевика


Share with your friend now:
tgoop.com/life_of_network_engineer/152

View MORE
Open in Telegram


Telegram News

Date: |

Hui said the messages, which included urging the disruption of airport operations, were attempts to incite followers to make use of poisonous, corrosive or flammable substances to vandalize police vehicles, and also called on others to make weapons to harm police. In 2018, Telegram’s audience reached 200 million people, with 500,000 new users joining the messenger every day. It was launched for iOS on 14 August 2013 and Android on 20 October 2013. It’s easy to create a Telegram channel via desktop app or mobile app (for Android and iOS): A vandalised bank during the 2019 protest. File photo: May James/HKFP. According to media reports, the privacy watchdog was considering “blacklisting” some online platforms that have repeatedly posted doxxing information, with sources saying most messages were shared on Telegram.
from us


Telegram Будни сетевика
FROM American