Spraw, by reguła ip przetrwała ponowne połączenie z systemd-networkd

Dodaj regułę polityki poleceniem ip rule; działa ona do chwili zniknięcia łącza, a wtedy po prostu jej nie ma. Nic nie zawiodło głośno: stan jądra się zmienił, a żaden właściciel konfiguracji nie wiedział, że reguła powinna istnieć. To cała różnica między regułą, która przetrwa, a taką, która nie. Na hoście z systemd-networkd rozwiązaniem jest danie regule właściciela, a nie ponowne uruchamianie polecenia po każdym połączeniu.

Reguła istnieje tylko wtedy, gdy ktoś ją posiada

Polityka routingu jądra to stan, a nie konfiguracja. Żyje w działającym systemie, a wszystko, co zrywa interfejs, od którego zależy, może ją zabrać ze sobą. Polecenie w powłoce zmienia ten stan i nie zostawia żadnego zapisu intencji.

Menedżery sieci działają odwrotnie: czytają konfigurację, stosują ją i stosują ponownie, gdy zdarzenie łącza unieważni poprzedni stan. Reguła zadeklarowana w ich konfiguracji jest odtwarzana, natomiast reguła dodana obok nich jest obcym obiektem bez właściciela.

To rozróżnienie ma nazwę w networkd i warto je przeczytać, zanim cokolwiek włączysz. Obce reguły są domyślnie usuwane w nowszych wersjach, co zaskakuje tych, którzy oczekiwali, że ich ręczne wpisy zostaną.

Przeczytaj wersję, zanim zaufasz ustawieniu

Zachowanie własności jest kontrolowane przez ustawienie w networkd.conf, a tego ustawienia nie ma w starszych wydaniach systemd. Sprawdź zainstalowaną wersję, zanim zaprojektujesz wokół tego, ponieważ starszy host zachowuje się inaczej niż dokumentacja, którą czytasz.

Znaczenie mają dwie wartości. Jedna decyduje, czy usuwane są reguły niezadeklarowane w konfiguracji networkd, a druga robi to samo dla tras. Obie dotyczą własności, a nie treści polityki, i obie domyślnie wybierają surowsze zachowanie w bieżących wydaniach. Wyłączenie ich globalnie utrzymuje przy życiu każdą obcą regułę, co jest znacznie szerszą decyzją niż zadeklarowanie jednej pożądanej polityki VPN.

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

Ten grep mówi ci, co jest ustawione lokalnie i jaka jest domyślna wartość dostawcy. Brak też jest informacją, bo oznacza, że obowiązuje wartość skompilowana. Zapisz ją w notatkach, żeby następna osoba nie musiała jej odkrywać ponownie.

Zadeklaruj regułę i tabelę, na którą wskazuje

Reguła w pliku .network nazywa tabelę i to wszystko, co robi nazwa. Nie tworzy tras w tej tabeli i nie sprawdza, czy mają sens. Zadeklarowanie reguły bez tras daje politykę, która dopasowuje ruch, a potem go odrzuca.

Zadeklaruj trasy w tym samym pliku, z osiągalnymi następnymi skokami i właściwą tabelą. Zachowaj priorytet w zadeklarowanej regule, żeby trafiła tam, gdzie się spodziewasz, w uporządkowanej liście. Reguła, która dociera do niewłaściwej tabeli wcześniej niż zamierzono, zmienia więcej ruchu niż usługa, którą chciałeś naprawić. Czytaj poniższy fragment jako kształt, a nie jako pełny plik, bo własność interfejsu i reszta połączenia nadal muszą być obecne.

[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

Potem przeładuj i odczytaj stan jądra, a nie plik. Konfiguracja, która została czysto przeanalizowana, wciąż może dać regułę, której nie zamierzałeś, a oba widoki zgadzają się tylko wtedy, gdy deklaracja była kompletna.

Wybierz jednego właściciela interfejsu

Dwaj menedżerowie na jednym tunelu wywołują spór, który w obu wygląda jak błąd. Zaimportowanie istniejącej konfiguracji wg-quick do networkd to migracja, a nie dodatek, a uruchamianie obu zostawia interfejs i jego reguły pod dwoma właścicielami.

Wykonaj migrację za jednym razem: zatrzymaj starą jednostkę, wyłącz ją, zadeklaruj interfejs i jego trasy w networkd, a potem przeładuj. Sprawdź, że stara jednostka nie może wrócić przy starcie. Pozostała jednostka, która po restarcie znów się aktywuje, nadpisuje stan, który właśnie zadeklarowałeś. Zachowaj stary plik konfiguracji, aż nowy przetrwa ponowne połączenie, a potem go wycofaj.

Własność znacznika zasługuje na taką samą troskę: jeśli reguła pasuje do znacznika zapory, coś musi ten znacznik ustawiać. Reguła odwołująca się do znacznika, którego nikt nie ustawia, to martwa konfiguracja, która wygląda na zamierzoną.

Przećwicz zdarzenia cyklu życia

Konfiguracja jest warta tyle, ile jej zachowanie w obliczu zdarzeń. Zdejmij łącze, podnieś je, zrestartuj usługę i odśwież adres. Po każdym z nich odczytaj listę reguł i zawartość tabeli.

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

Zamierzonym wynikiem jest ta sama posiadana polityka odtworzona i przestarzały stan wycofany, co jest trwalsze niż ponowne dodawanie reguły powłoki po każdym połączeniu. Zachowaj jedną linię w rejestrze zmian, która nazywa plik posiadający regułę i wersję, która ją obsługuje. Wtedy następny inżynier znajdzie politykę bez przeszukiwania historii powłoki. Reguła, której nikt nie posiada, to reguła, która znowu zostanie utracona.