Tasker: połącz VPN przed otwarciem prywatnego URL-a

Otwieranie prywatnego URL-a i liczenie na to, że tunel wstanie pierwszy, to wyścig, w którym zwykle wygrywa przeglądarka. Skrót, który reaguje na stronę już się ładującą, przegapił zapytanie DNS i często pierwsze połączenie, czyli dokładnie tę część, która potrzebowała VPN-a. Przepływ pracy musi posiadać kolejność, a nie ją obserwować. Trzy warunki decydują, czy ten przepływ w ogóle należy do Taskera.

Jeden punkt wejścia powinien posiadać sekwencję

Daj usłudze prywatnej jeden zatwierdzony punkt wejścia i pozwól temu punktowi wykonać kroki po kolei. Sprawdź miejsce docelowe, wybierz zamierzony profil, zażądaj połączenia, poczekaj na wynik gotowości z ograniczeniem, jak długo będziesz czekać, i dopiero wtedy otwórz URL. Jeśli którykolwiek krok zawiedzie, zatrzymaj się i powiedz to, zamiast przechodzić do bezpośredniego otwarcia.

Właśnie tę ostatnią klauzulę ludzie pomijają. Przepływ, który mimo upływu czasu i tak otwiera URL, jest gorszy niż brak automatyzacji, bo tworzy żądanie wyglądające na nieudany VPN, choć nigdy go nie użył.

1. validate destination against the approved list
2. select the intended VPN profile
3. request connection through the client's supported interface
4. wait for readiness, maximum 20 seconds
5. open the URL only if readiness succeeded
6. on timeout, stop and report

Powyższa numerowana lista to kontrakt, a nie wyeksportowany profil. Każdy klient implementuje swoją powierzchnię sterowania inaczej, a niektóre wymagają wtyczki, wyraźnego pozwolenia na sterowanie lub jednorazowej zgody użytkownika, której żadna automatyzacja nie dostarczy.

Połączony to nie to samo co gotowy

Status mówiący, że tunel został uruchomiony dowodzi, że klient przyjął żądanie. Nie dowodzi, że resolver zwraca teraz prywatne adresy ani że zamierzona usługa jest osiągalna. To osobne wyniki, a luka między nimi jest miejscem, w którym skrót otwierający zbyt wcześnie zawodzi po cichu. Klient zgłasza własny stan, a nie stan ścieżki, której użyje URL.

Zdefiniuj gotowość względem czegoś, co przepływ może obserwować. Stan połączenia od klienta, rozwiązany adres z oczekiwanego zakresu lub test osiągalności konkretnej usługi zadziałają, pod warunkiem że test nie może wrócić na zwykłą ścieżkę sieciową. Test, który udaje się przez normalną trasę, nie mówi ci nic.

Ogranicz oczekiwanie. Warunek gotowości bez limitu czasu zamienia zepsuty profil w skrót, który wisi, a użytkownicy zgłaszają to jako zamarzający telefon, nie jako problem z VPN-em.

Co Tasker może, a czego nie może

Tasker dostarcza klej: wyzwalacz, uporządkowaną listę akcji, warunki i akcję URL. Jego akcja otwarcia URL wykonuje tylko krok otwarcia i nic więcej. Krok połączenia musi pochodzić od klienta VPN, przez wtyczkę, intent lub udostępnioną usługę, którą klient dokumentuje i na którą pozwala.

OpenVPN for Android na przykład dokumentuje interfejs zdalnego sterowania zbudowany na AIDL i intentach. To możliwość tego klienta, a nie licencja dla dowolnego zadania w urządzeniu, by nim sterować. Przyznawaj sterowanie tylko aplikacji, którą masz na myśli, bo warstwa automatyzacji, która potrafi połączyć i rozłączyć tunel, jest powierzchnią sterowania wartą ochrony.

Jeśli zainstalowany klient nie udostępnia żadnego obsługiwanego mechanizmu sterowania, uczciwa odpowiedź brzmi: tego przepływu nie da się zbudować na tym kliencie. Stara strona porównania funkcji nie jest specyfikacją możliwości dla wersji w telefonie.

Kiedy granica musi być obowiązkowa

Automatyzacja to wygoda, a wygoda nie może wymusić granicy bezpieczeństwa. Jeśli wymogiem jest, by objęte aplikacje nigdy nie komunikowały się bez VPN-a, użyj ustawienia zawsze włączonego VPN i blokowania platformy albo równoważnej konfiguracji zarządzanej. Zdarzenie przeglądarki wywołane po rozpoczęciu nawigacji nie może zastąpić tego wymuszania, niezależnie od tego, jak starannie ułożone jest zadanie.

Zdecyduj, co budujesz. Skrót, który najpierw się łączy, a potem otwiera, jest użyteczny i nie jest gwarancją. Zarządzane urządzenie z włączonym blokowaniem jest gwarancją i nie potrzebuje żadnej sekwencji Taskera.

Przetestuj trzy wyniki, nie jeden

Uruchom przepływ wobec udanego połączenia, celowego przekroczenia czasu i zwykłego ponownego połączenia po upadku tunelu. Przypadek przekroczenia czasu ujawnia, czy sekwencja naprawdę się zatrzymuje, a przypadek ponownego połączenia ujawnia, czy gotowość jest sprawdzana, czy tylko zakładana z poprzedniego sukcesu. Uruchom najpierw przypadek przekroczenia czasu, bo przepływ ignorujący porażkę nie jest wart testowania pod kątem sukcesu.

Zezwalaj tylko na cele z zatwierdzonej listy i sprawdzaj każdy link przychodzący z zewnątrz, zanim go otworzysz. Zadanie, które przyjmuje dowolne linki, staje się sposobem uruchamiania nieoczekiwanych schematów, a prywatna strona administracyjna osiągnięta w ten sposób to gorszy wynik niż nieudany skrót.

Zapisz profil, warunek gotowości i limit czasu obok zadania. Następna osoba, która zmieni klienta VPN, będzie potrzebować wszystkich trzech, a żadnego z nich nie widać z ikony skrótu.