Нека ip rule преживее повторно поврзување со systemd-networkd

Додајте политичко правило со ip rule и тоа работи додека врската не исчезне; во тој момент едноставно го нема. Ништо не пропадна гласно: состојбата на јадрото се промени, а ниту еден сопственик на конфигурација не знаеше дека правилото треба да постои. Тоа е целата разлика меѓу правило што преживува и правило што не. На домаќин со systemd-networkd решението е да му дадете сопственик на правилото, наместо да ја повторувате командата по секое повторно поврзување.

Правилото постои само ако некој го поседува

Политиката за насочување на јадрото е состојба, а не конфигурација. Таа живее во системот што работи, и сѐ што го урнисува интерфејсот од кој зависи може да ја однесе со себе. Командата во школка ја менува таа состојба и не остава никаков запис за намерата.

Мрежните менаџери работат обратно: ја читаат конфигурацијата, ја применуваат и ја применуваат повторно кога настан на врската ја поништува претходната состојба. Правило декларирано во нивната конфигурација се создава повторно, додека правило додадено покрај нив е туѓ објект без сопственик.

Оваа разлика има име во networkd и вреди да се прочита пред да се овозможи нешто. Туѓите правила во поновите верзии се отстрануваат по стандард, што ги изненадува оние што очекуваа нивните рачни записи да останат.

Прочитајте ја верзијата пред да му верувате на поставување

Однесувањето на сопственоста се контролира со поставување во networkd.conf, а тоа поставување не постои во постари изданија на systemd. Проверете ја инсталираната верзија пред да дизајнирате околу неа, бидејќи постар домаќин се однесува поинаку од документацијата што ја читате.

Две вредности се важни. Едната одлучува дали правилата што не се декларирани во конфигурацијата на networkd се отстрануваат, а другата го прави истото за рутите. Двете се за сопственост, а не за содржината на политиката, и двете по стандард во тековните изданија избираат построго однесување. Нивното глобално исклучување го одржува живо секое туѓо правило, што е далеку поширока одлука отколку декларирање на една сакана VPN политика.

systemctl --version | head -1
networkctl --version | head -1
grep -R "ManageForeign" /etc/systemd/ /usr/lib/systemd/ 2>/dev/null

Тој grep ви кажува што е поставено локално и што е стандардот на добавувачот. Отсуството е исто така информација, бидејќи значи дека важи компајлираниот стандард. Запишете го стандардот во вашите белешки за следниот човек да не мора повторно да го открива.

Декларирајте го правилото и табелата кон која покажува

Правило во .network датотека именува табела, и тоа е сѐ што прави името. Тоа не ги создава рутите внатре во таа табела и не проверува дали имаат смисла. Декларирањето на правилото без рутите дава политика што го совпаѓа сообраќајот и потоа го отфрла.

Декларирајте ги рутите во истата датотека, со достапни следни скокови и точната табела. Задржете го приоритетот во декларираното правило за да слета таму каде што очекувате во подредената листа. Правило што доаѓа до погрешната табела порано од предвиденото менува повеќе сообраќај отколку услугата што сакавте да ја поправите. Читајте го фрагментот подолу како форма, а не како целосна датотека, бидејќи сопственоста на интерфејсот и остатокот од врската сѐ уште мора да бидат присутни.

[RoutingPolicyRule]
Family=ipv4
IPProtocol=tcp
SourcePort=443
Table=100
Priority=1000

[Route]
Destination=10.80.0.0/24
Gateway=10.80.0.1
Table=100

Потоа вчитајте повторно и читајте ја состојбата на јадрото, а не датотеката. Чисто анализирана конфигурација сепак може да создаде правило што не сте го намениле, и двата погледи се совпаѓаат само кога декларацијата била целосна.

Изберете еден сопственик за интерфејсот

Два менаџери на еден тунел создаваат судир што изгледа како грешка во двата. Увозот на постоечко wg-quick поставување во networkd е миграција, а не додаток, и работењето на двете го остава интерфејсот и неговите правила под два сопственика.

Направете ја миграцијата во еден потег: запрете ја старата единица, исклучете ја, декларирајте го интерфејсот и неговите рути во networkd, потоа вчитајте повторно. Проверете дали старата единица не може да се врати при подигнување. Преостаната единица што повторно се активира по рестарт ја препишува состојбата што штотуку ја деклариравте. Чувајте ја старата конфигурациска датотека додека новата не преживее повторно поврзување, потоа повлечете ја од употреба.

Сопственоста на ознаката заслужува исто внимание: ако правило се совпаѓа со ознака на огнен ѕид, нешто мора да ја постави таа ознака. Правило што упатува на ознака што никој не ја поставува е мртва конфигурација што изгледа намерна.

Вежбајте ги настаните од животниот циклус

Конфигурацијата вреди онолку колку што вреди нејзиното однесување низ настаните. Спуштите ја врската, подигнете ја, рестартирајте ја услугата и обновете ја адресата. По секое од нив прочитајте ја листата со правила и содржината на табелата.

sudo networkctl reload
ip rule show
ip route show table 100
sudo systemctl restart systemd-networkd

Посакуваниот резултат е истата политика со сопственик создадена повторно и застарена состојба повлечена, што е поиздржливо од повторно додавање на правило од школка по секое поврзување. Чувајте еден ред во записот за промени што ја именува датотеката што го поседува правилото и верзијата што го поддржува. Тогаш следниот инженер може да ја најде политиката без да пребарува историја на школка. Правило што никој не го поседува е правило што повторно ќе се загуби.