Aplikacja nie może działać, gdy VPN jest włączony: co to wymusza

Kill switche i reguły zakazu nakładania się wskazują w przeciwne strony, co wyjaśnia, dlaczego zwykłe ustawienia VPN nigdy nie wyrażają tej drugiej. Kill switch reaguje na tunel, który upadł, a to wymaganie reaguje na tunel, który jest aktywny, i trzyma aplikację poza obrazem. Jedna decyzja projektowa rozstrzyga większość: czy aplikacja jest zatrzymywana, blokowana przed uruchomieniem, czy tylko pozbawiana dostępu do sieci. Wybierz tę warstwę, zanim sięgniesz po regułę firewalla albo pętlę zabijającą procesy, bo reguła egzekwowana przez obserwację przecieka okno przy każdym uruchomieniu.

Mit: kill switch powstrzymuje programy przed uruchomieniem

Kill switche to kontrola ruchu i są tego uczciwe: przepuszczają lub odrzucają pakiety według stanu tunelu. Żaden z nich nie odmawia uruchomienia programu i żaden nie sprawdza, który plik wykonywalny otworzył gniazdo. Skrót na pulpicie, zaplanowane zadanie i pomocnik w tle docierają do sieci bez przechodzenia przez cokolwiek, co zna nazwę aplikacji. Odległość między tymi dwoma mechanizmami to miejsce, w którym mieszka większość zamieszania.

Układ, który naprawdę decyduje, czy program może się uruchomić, to kontrola aplikacji. W Windows oznacza to AppLocker lub WDAC, a w zarządzanym macOS listę dozwolonych wymuszaną przez profil urządzenia. Oba są niezależne od tunelu, dlatego oba wymagania łączy się w jednym zgłoszeniu, a potem żadne nie jest spełnione.

Nazwij tryb, zanim nazwiesz narzędzie

Zapisz regułę jako maszynę stanów z trzema stanami: zwykłe użycie, sesja pracy z VPN i wyjście. Zabronione nakładanie się należy do stanu środkowego, a nie do oprogramowania klienta.

Kto zmienia stan, ma trzy działania w kolejności: zakończyć pracę aplikacji, zażądać jej normalnego zamknięcia i potwierdzić, że instancja zniknęła, zanim tunel się podniesie. Kolejność ma znaczenie także na drugim końcu, bo VPN, który najpierw się łączy, a potem zatrzymuje program, już dopuścił nakładanie się. Jeśli wymaganie obejmuje nawiązanie połączenia, czekanie na wskaźnik połączenia jest zbyt późne.

Co naprawdę robi konflikt dwukierunkowy

Dla dwóch usług naprawdę zarządzanych przez systemd Conflicts= jest symetryczne: uruchomienie jednej zatrzymuje drugą. Dokumentacja jednostek opisuje to zachowanie i osobno wymaga jawnej kolejności, gdy jedna musi dokończyć zatrzymywanie, zanim druga się zacznie. Bez tych wpisów kolejności zatrzymanie i start ścigają się, a wynik zależy od czasu.

To nie jest lista blokad. Podłącz zależność odwrotnie, a uruchomienie aplikacji zatrzyma zamiast tego VPN, co jest awarią, którą warto podejrzewać, gdy tunel sam się rozłącza w przewidywalnym momencie. Aplikacja desktopowa nie jest jednostką systemd, a połączenie NetworkManager też nią nie jest, więc ten wzorzec działa tylko dla usług, które sam opakowujesz.

Testuj przejścia, nie tylko pierwszy start

Cztery przejścia decydują, czy wymaganie się utrzymuje: wejście w sesję z działającą aplikacją, ponowne jej uruchomienie w połowie sesji, nieudany start VPN i celowe rozłączenie. Przetestuj każde i zachowaj wynik obok plików jednostek. Poniższe polecenia odczytują obecną relację, a następnie ćwiczą najważniejsze przejście.

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

Trzecie polecenie powinno pozostawić aplikację nieaktywną, a czwarte powinno wymienić tylko połączenie tunelu, gdy sesja trwa. Inny wynik oznacza, że przejście w ogóle nie jest egzekwowane.

Ponowne uruchomienie w trakcie sesji to przypadek, który obnaża projekt oparty na opakowaniu, bo skrót uruchomiony z pulpitu nigdy nie konsultuje skryptu startowego. Jeśli to obejście ma znaczenie, egzekwowanie należy do kontroli aplikacji, a nie do klienta VPN. Udokumentuj też koniec sesji i przedkładaj świadome wznowienie nad ponowne otwieranie każdego procesu zatrzymanego przy wejściu. Zapisz wynik każdego przejścia w tej samej notatce, która przechowuje pliki jednostek.