systemd-networkd

Сьо­го­дні я вам роз­ка­жу коро­тку казо­чку про systemd-networkd.

TL;DR: усе пра­цює, але є нюан­си, осо­бли­во в скла­дних кон­фі­гу­ра­ці­ях, тому кра­ще поки вико­ри­сто­ву­ва­ти дистри­бу­тив­ні кон­фі­гу­рял­ки мере­жі.

Кон­фіг для зви­чай­но­го під­клю­че­н­ня до про­вай­де­ра, звер­ху яко­го під­ні­ма­ти­ме­ться IPv6-тунель (enp2s0.network):

[Match]
Name=enp2s0
 
[Network]
DNS=127.0.0.1
IPForward=yes
Tunnel=netassist
 
[Address]
Address=a.b.c.d/24
 
[Route]
Gateway=e.f.g.h

Кон­фіг туне­ля (по-поряд­ку netassist.netdev і netassist.network):

[Match]
 
[NetDev]
Name=netassist
Kind=sit
MTUBytes=1480
 
[Tunnel]
Local=a.b.c.d
Remote=i.j.k.l
TTL=255
[Match]
Name=netassist
 
[Network]
Address=2a01:dead:beef::2
Gateway=2a01:dead:beef::1

Для Wi-Fi+hostapd я вико­ри­сто­вую такий же самий кон­фіг, що і для ISP, але ще дода­тко­во ство­рюю сер­віс, який вистав­ляє поту­жність точки досту­пу після заван­та­же­н­ня hostapd (After=hostapd.service).

VLAN'и кон­фі­гу­ру­ю­ться також дово­лі про­сто (по-поряд­ку enp3s0.10.netdev і enp3s0.10.network):

[Match]
 
[NetDev]
Name=enp3s0.10
Kind=vlan
 
[VLAN]
Id=10
[Match]
Name=enp3s0.10
 
[Network]
IPForward=yes
Address=10.10.10.1/24
Address=2a01:dead:beef:10::1/64

Зауваж­те, що якщо потрі­бно роби­ти SNAT/маскарадинг чи щось інше, що потре­бує фор­вар­дін­га паке­тів на інтер­фей­сі, обов’язково потрі­бно вка­зу­ва­ти IPForward=yes, іна­кше ніякий sysctl вам не допо­мо­же.

Ще я роблю так, щоб на гіпер­ві­зо­рі був під­ня­тий міст, у який під­клю­ча­ю­ться вір­ту­ал­ки. Для поча­тку кон­фіг моста (по-поряд­ку bridge-vms.netdev і bridge-vms.network):

[NetDev]
Name=bridge-vms
Kind=bridge
[Match]
Name=bridge-vms
 
[Network]
IPForward=yes
Address=169.254.0.1/16

Отут, як бачи­те, дуже тупо. systemd-networkd вва­жає, що інтер­фейс пере­бу­ває у ста­ні degraded, якщо на ньо­му не наві­ше­но IP-адре­су. Мені вона на інтер­фей­сі мосту не потрі­бно (див. ниж­че), тому я вішаю що-небудь сіре, у цьо­му випад­ку це IP з діа­па­зо­ну авто­кон­фі­гу­ра­ції IPv4.

Також, для досту­пу до брі­джо­ва­них вір­ту­а­лок я вико­ри­сто­вую VETH із гіпер­ві­зо­ра (щоб не було про­блем зі змі­ною MAC-адре­си брі­джа). Для цьо­го в systemd-networkd потрі­бно ство­ри­ти аж три фай­ли: host.netdev, host-bp.network і host.network. Їх пода­но ниж­че також по-поряд­ку.

[NetDev]
Name=host
Kind=veth
 
[Peer]
Name=host-bp
[Match]
Name=host-bp
 
[Network]
Bridge=bridge-vms
[Match]
Name=host
 
[Network]
IPForward=yes
Address=10.10.11.1/24
Address=2a01:dead:beef:11::1/64

Таким чином, одним кін­цем пара диви­ться у брідж, іншим — у хост, і через цей інтер­фейс можна роби­ти мар­шру­ти­за­цію. Див­но, що в netctl я не зна­йшов поки що нічо­го схо­жо­го (як і для CentOS'і, мабуть, дове­де­ться писа­ти якийсь модуль само­му).

Окрім під­во­дно­го камі­н­ня із вми­ка­н­ням фор­вар­дін­га і дегра­до­ва­них брі­джів є ще поки що не вилі­ку­ва­на про­бле­ма з тим, що мере­же­ві інтер­фей­си час­тко­во під­ні­ма­ю­ться після служб, яким вони потрі­бні. При цьо­му, в netctl тако­го непо­доб­ства нема. Сюди ж від­но­си­ться і про­бле­ма з бін­дін­гом nginx'а на IPv6-адре­су, про яку я вже писав рані­ше. А в іншо­му інстру­мен­та­рій дуже зру­чний, і свої зада­чі після дове­де­н­ня до при­стой­но­го вигля­ду, спо­ді­ва­ю­ся, буде вико­ну­ва­ти добре.

Мітки: , ,

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

*

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.