Zamknąć czy rozłączyć: dwa różne wyniki VPN

Menu oferuje Rozłącz, okno ma przycisk zamykania, a menedżer zadań oferuje Zakończ zadanie. Każda z tych opcji wygląda jak sposób na zatrzymanie VPN i każda może pozostawić komputer w innym stanie. Jedna może zatrzymać tunel, zostawiając blokadę na miejscu, inna może wszystko posprzątać w ramach uporządkowanego wyjścia, a trzecia może tylko ukryć interfejs, podczas gdy komponent działający w tle nadal pracuje. Traktowanie ich jako synonimów to właśnie droga, którą test prywatności dochodzi do błędnego wniosku o tym, co się stało.

Dokumentacja klienta jest jedynym wiarygodnym miejscem, w którym można dowiedzieć się, co jest czym.

Cztery elementy sterowania, być może cztery zachowania

Rozłączenie zwykle rozbiera tunel, podczas gdy klient pozostaje w pamięci, co oznacza, że usługa, komponent w zasobniku systemowym lub reguła kill switcha mogą przetrwać kliknięcie. Wtedy wiele klientów nadal blokuje ruch, ponieważ ich polityka mówi, że urządzenie nie może wrócić do dostępu bezpośredniego, dopóki klient jest obecny. Takie zachowanie wygląda jak zepsuta sieć i jest celową ochroną.

Zamknięcie ma zakończyć aplikację, a dobrze zaprojektowany klient usuwa swoje reguły przy wyjściu. Niektóre rozwiązania zostawiają zamiast tego osobnego pomocnika, który egzekwuje politykę, i to jest wybór, a nie defekt. Zamknięcie okna to działanie interfejsu bez określonego wpływu na tunel, a Wstrzymanie, tam gdzie jest oferowane, to czwarte zachowanie z własnymi regułami.

Awaria po stronie serwera to zupełnie piąta droga i to z nią użytkownicy w praktyce spotykają się najczęściej.

Odczytaj stan przed i po każdej akcji

Zapisz listę procesów, stan usługi i reguły zapory przed akcją, a potem natychmiast powtórz zapis. Porównanie obu list pokazuje, co element sterowania naprawdę zrobił, bez polegania na opisie samego interfejsu.

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

Jeśli reguły znikają razem z procesem, należały do klienta. Jeśli reguły zostają, a proces zniknął, coś innego egzekwuje politykę, a znalezienie tego komponentu poprzedza każdą zmianę. Zapisz stan usługi w tym samym momencie, bo zatrzymany interfejs nic nie mówi o usłudze systemowej.

Ręczne rozłączenie to nie awaria

Rozłączenie przechodzi zamierzoną ścieżkę zamknięcia, a awaria ją pomija. Wyniki jednego nie przenoszą się więc na drugie, więc test, który użył pozycji menu, nie może wesprzeć twierdzenia o zachowaniu, gdy klient padnie.

Podobnie awaria nic nie mówi o zatwierdzonym czasowym wstrzymaniu. Trzymaj te trzy pytania osobno w planie testów i we wszystkim, co zostanie potem zapisane. Ścieżka zamknięcia wyjaśnia też, dlaczego czyste wyjście może usunąć reguły, które awaria zostawia. Ten sam przycisk, inny kod, inne dowody.

Wybierz stan niedostępności, którego naprawdę potrzebujesz

Jeśli ruch ma pozostać zablokowany za każdym razem, gdy tunel nie działa, zweryfikuj ten wymóg podczas konkretnej akcji, na której ci zależy, używając nieszkodliwego ruchu do znanego celu. Uwzględnij wyjątki aplikacji i wyjątki sieci lokalnej, bo egzekwowanie na całym urządzeniu jest często węższe, niż sugeruje nazwa. Następnie potwierdź, co dzieje się po ponownym uruchomieniu, bo wtedy zwykle pojawia się nieaktualny stan.

Jeśli celem jest zwykły dostęp bezpośredni, użyj udokumentowanego elementu sterowania zamiast zabijać procesy lub wyłączać całą zaporę. Nieaktualne reguły pozostawione przez przerwane wyjście to inny problem niż zamierzone zablokowanie i wymagają innego przywrócenia.

Zapisz, który komponent się zatrzymał: tunel, widoczna aplikacja czy warstwa egzekwująca politykę. To jedno zdanie zapobiega większości zamieszania, które tworzą te elementy sterowania.