Always-on VPN czy kill switch: co właściwie włączyłeś?

Always-on i kill switch dzieli na tym samym ekranie ustawień zaledwie kilka wierszy, więc ludzie czytają je jako dwie nazwy jednej funkcji. Nie są nią. Always-on to polityka ponownego łączenia: uruchom tunel przy starcie, przywróć go po awarii lub zmianie sieci i próbuj dalej, dopóki się nie uda. Kill switch to polityka ruchu: wskazuje pakiety, które mimo wszystko mogą opuścić maszynę, gdy tunel jest wyłączony. Możesz włączyć pierwsze bez drugiego, a na większości platform domyślny wynik nadal wypuszcza ruch w tej luce.

Kontrola 1: czy blokada jest osobnym przełącznikiem?

W Androidzie 10 i nowszych zapisany profil VPN otwiera za ikoną zębatki dwa niezależne przełączniki: Always-on VPN i Block connections without VPN. Tylko drugi jest kill switchem. Przy samym always-on tunel rzeczywiście wraca po zerwaniu, a dowolna aplikacja w trakcie żądania może dotrzeć do sieci przez Wi-Fi lub dane komórkowe, zanim to nastąpi.

Urządzenia zarządzane zachowują ten sam podział w API polityk. setAlwaysOnVpnPackage() przyjmuje nazwę pakietu i flagę lockdownEnabled; administrator, który ustawi pakiet i zostawi flagę na false, zbudował trwały tunel, a nie zamknięte urządzenie. Sformułowania w konsoli rzadko pokazują tę różnicę.

Stan czytaj z urządzenia, nie z konsoli: adb shell settings get global always_on_vpn_app i adb shell settings get global always_on_vpn_lockdown. Jeśli pierwsze zwróci null, na poziomie platformy nie jest wymuszany żaden pakiet; jeśli drugie zwróci 0, platforma niczego nie blokuje. Przewodnik po VPN w Androidzie opisuje je jako odrębne możliwości, a nie jeden tryb.

Kontrola 2: która warstwa posiada blokadę?

Etykiety mieszkają w kliencie, a blokady zwykle w zaporze sieciowej, dlatego to samo słowo znaczy co innego na każdej platformie. Poniższe wiersze to te, które warto potwierdzić, zanim zaufasz któremukolwiek z nich.

Windows jest najjaśniejszym przykładem etykiety, która nie blokuje. Always On opisuje tam trwałość tunelu: tunel urządzenia do uwierzytelniania maszyny i tunel użytkownika dla zalogowanego konta, konfigurowane przez XML profilu lub Add-VpnConnection. Nic w tym profilu nie zatrzymuje pakietu wychodzącego, gdy tunelu brakuje, a filtrowanie wychodzące nie jest domyślnie włączone, więc laptop w Wi-Fi działa dalej, gdy VPN leży.

WireGuard dzieli się tak samo, ale według klienta. WireGuard for Windows ma opcję Block untunneled traffic dla każdego tunelu, która instaluje reguły filtra; narzędzia Linuksa nie mają odpowiednika. wg-quick dodaje trasę dla każdego wpisu AllowedIPs oraz regułę fwmark, a wg-quick down usuwa oba, więc fizyczna trasa domyślna przejmuje znowu, bez gubienia choćby jednego pakietu.

Na platformach Apple always-on przychodzi jako funkcja profilu zarządzania dla urządzeń nadzorowanych i wyraża się regułami on-demand, a nie polem wyboru. Pytanie, na które trzeba odpowiedzieć z payloadu, brzmi: czy nieudany tunel odmawia ruchu, czy tylko prosi o inne połączenie. Tytuł menu tego nie powie.

Kontrola 3: mierz lukę, nie ikonę

Cztery przejścia mają znaczenie i każde zawodzi inaczej: start, zanim ktokolwiek się zaloguje, uśpienie i wybudzenie, zmiana z Wi-Fi na dane komórkowe oraz awaria klienta, która zostawia interfejs tunelu w połowie skonfigurowany. Czyste ponowne połączenie na jednym z nich niczego nie dowodzi w kwestii pozostałych trzech.

Najtańszy test celowo zatrzymuje tunel i próbuje wyjść. Gdy tunel leży, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com zwracające 200 oznacza, że polityka jest fail-open; przekroczenie czasu lub odrzucone połączenie oznacza, że coś nadal blokuje. ip route get 1.1.1.1 wskazuje interfejs, który niósłby pakiet, co zwykle mówi więcej niż ikona w zasobniku, a systemctl status wg-quick@wg0 pokazuje, czy interfejs został czysto usunięty.

Uruchom tę samą kontrolę w drugim oknie, gdy sieć się zmienia, a nie tylko po jej uspokojeniu. Interwał między zerwaniem a ponowną próbą jest tym, co się liczy, a rozwiązywanie nazw to najszybszy sposób, by zauważyć, że ruch uciekł: jeśli lokalny resolver odpowiada, gdy tunel leży, blokada nie jest pełna.

Kontrola 4: ustal wyjątki, zanim zamkniesz wszystko

Dwa wyjątki są strukturalne. Klient musi dotrzeć do samego serwera VPN, więc zbiór reguł, który odrzuca wszystko, blokuje też ponowne połączenie, które przywróciłoby ochronę. Captive portal również nie jest osiągalny przez tunel, który nie jest podniesiony, więc zablokowane urządzenie w hotelowym Wi-Fi potrzebuje udokumentowanego sposobu otwarcia portalu, a nie doraźnego.

Minimalna postać: punkt końcowy dozwolony, reszta odrzucona:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Traktuj ten wiersz punktu końcowego jako zmienną, nie stałą. Dostawcy zmieniają adresy, a nieaktualny wyjątek jest zwykłą przyczyną tego, że działający kill switch staje się urządzeniem, które nie potrafi się ponownie połączyć. Lokalne drukarki, udziały NAS i usługi deweloperskie należą do tej samej zapisanej listy, inaczej odkrywa się je po jednym zgłoszeniu do pomocy technicznej.

Kontrola 5: zapisz, co naprawdę udowodniłeś

Prowadź tabelę z czterema kolumnami i wypełniaj ją testami: stan, oczekiwane zachowanie, zaobserwowane zachowanie, dowód. Wiersze to przejścia z kontroli 3 plus jedna świadoma awaria. Wiersz, którego nie wypełnisz wyjściem polecenia, jest wierszem, którego nie sprawdzono, a urządzenie, które przechodzi wiersz ponownego łączenia i zawodzi w wierszu startu, jest dość powszechne, by usprawiedliwić dodatkowe dziesięć minut.

Zanim uznasz to za skończone:

• Potwierdź, że ustawienie blokady jest osobne od ustawienia ponownego łączenia, i odczytaj jego wartość na urządzeniu.
• Wiedz, która warstwa wymusza blokadę - opcja klienta, polityka urządzenia czy zapora - i gdzie ta warstwa jest konfigurowana.
• Zachowaj jedno polecenie kontrolne, które dowodzi blokady, i uruchamiaj je podczas przejścia, a nie po nim.
• Zapisz listę wyjątków, wraz z punktem końcowym, i zaznacz, kto ją odświeża.
• Na zarządzanym sprzęcie nie ruszaj wymuszonej polityki; usunięcie blokady zmienia wymaganie zamiast naprawiać tunel.