Uruchamiaj zadania po VPN z dyspozytora, a nie z if-up

Skrypt, który musi się uruchomić po podniesieniu VPN, potrzebuje zdarzenia od komponentu, który posiada połączenie. Plik wrzucony do starego katalogu hooków sieciowych nie jest wywołaniem zwrotnym dla każdego VPN, który mogą utworzyć NetworkManager, pppd lub samodzielny proces OpenVPN. Każdy z tych właścicieli zgłasza inne zdarzenie w innym środowisku, więc właściciela trzeba zidentyfikować przed wyborem hooka. Inaczej skrypt jest poprawny i po prostu nigdy się nie uruchamia.

Dla VPN zarządzanego przez NetworkManager dyspozytor jest właściwym miejscem, a vpn-up właściwą akcją.

Używaj vpn-up, nie zdarzenia interfejsu

Dyspozytor rozróżnia up od vpn-up. Pierwszy zgłasza aktywowany interfejs; drugi zgłasza aktywowane połączenie VPN. Podniesienie Wi-Fi oznacza tylko, że istnieje łącze bazowe; tunel może jeszcze negocjować albo nigdy się nie uwierzytelnić.

Skrypt otrzymuje interfejs i akcję, a szczegóły połączenia przychodzą przez środowisko, w tym UUID profilu i interfejs IP VPN. Czytaj te zmienne, zamiast wnioskować tożsamość z nazw urządzeń.

Ogranicz dopasowanie do jednego połączenia

Dopasuj po UUID połączenia lub innej tożsamości podanej przez dyspozytora, a nie po prefiksie tun czy ppp0. Nazwy interfejsów nie są stabilne, jednocześnie może istnieć więcej niż jeden tunel, a dwa profile mogą mieć tę samą nazwę wyświetlaną. Dopasowanie prefiksu tun oznacza, że skrypt w końcu uruchomi się dla połączenia, którego nikt nie chciał dotykać. Może też uruchomić się dwa razy dla jednego profilu, gdy ponowne połączenie odbuduje urządzenie.

Uczyń zadanie idempotentnym. Wywołanie zwrotne, które przy każdym uruchomieniu dodaje trasę, w końcu zapełnia tabelę duplikatami, a to druga kopia psuje routing.

Wiedz, czego aktywacja nie dowodzi

vpn-pre-up działa, zanim NetworkManager zgłosi pełną aktywację VPN, a menedżer czeka na te skrypty. Używaj etapu blokującego tylko wtedy, gdy zadanie naprawdę tam należy, bo wolne sprawdzenie opóźnia aktywację, na którą czekają wszystkie inne komponenty.

Obecność tras nie dowodzi, że aplikacja nasłuchuje, że nazwa prywatna się rozwiązuje lub że istnieje sesja użytkownika. Sprawdzaj to osobno z ograniczonym limitem czasu i zgłaszaj, która warstwa zawiodła, zamiast powtarzać cały łańcuch.

Szanuj kontekst, w którym działa skrypt

Skrypty dyspozytora działają jako root, poza jakąkolwiek sesją użytkownika. Nie zakładaj, że dostępne są środowisko zalogowanego użytkownika, jego sesja graficzna lub odblokowany pęk kluczy. Nikt nie powinien odpowiadać na brak kontekstu pulpitu udostępnieniem każdego poświadczenia każdemu procesowi. Trzymaj pracę sesji użytkownika w usłudze użytkownika lub pomocniku sesji, któremu wywołanie zwrotne może wysłać sygnał bez podszywania się pod użytkownika.

Właściciel i uprawnienia skryptu też mają znaczenie. Plik uruchamiany jako root, który każdy użytkownik może podmienić, jest drogą do eskalacji uprawnień i stanowi ustalenie niezależne od tego, czy logika VPN jest poprawna.

Zaplanuj rozłączenie, które nigdy nie nastąpi

NetworkManager dokumentuje, że vpn-pre-down nie jest emitowane przy wymuszonych rozłączeniach, takich jak nieoczekiwane zakończenie lub utrata łączności. Dlatego sprzątanie zbudowane tylko wokół łagodnego pre-down jest z założenia niepełne. Każdy współdzielony stan, który skrypt zmienia, wymaga innego właściciela zdolnego go przywrócić po awarii, a ta ścieżka odzyskiwania musi być przetestowana, a nie założona.

Przetestuj hook przy zwykłym połączeniu, ponownym połączeniu, celowym rozłączeniu i wyciągniętym kablu. Zapisuj UUID, akcję i interfejs, który zadziałał, bez rejestrowania sekretów. Ten zapis jest jedynym wiarygodnym dowodem, że hook zadziałał dla zamierzonego połączenia, i to on czyni następną zmianę bezpieczną.