Tasker: koble til VPN før du åpner en privat URL

Å åpne en privat URL og håpe at tunnelen kommer opp først er et kappløp, og nettleseren vinner som regel. En snarvei som reagerer på en side som allerede lastes, har mistet DNS-oppslaget og ofte den første forbindelsen, som nettopp er den delen som trengte VPN-en. Arbeidsflyten må eie rekkefølgen i stedet for å observere den. Tre betingelser avgjør om den arbeidsflyten i det hele tatt hører hjemme i Tasker.

Ett inngangspunkt bør eie sekvensen

Gi den private tjenesten ett godkjent inngangspunkt, og la det inngangspunktet utføre trinnene i rekkefølge. Valider målet, velg den tiltenkte profilen, be om forbindelsen, vent på et beredskapsresultat med en grense for hvor lenge du vil vente, og åpne først da URL-en. Hvis et trinn feiler, stopp og si det i stedet for å falle gjennom til en direkte åpning.

Det er den siste klausulen folk hopper over. En arbeidsflyt som likevel åpner URL-en ved tidsavbrudd, er verre enn ingen automatisering, fordi den lager en forespørsel som ser ut som en mislykket VPN mens den aldri brukte noen.

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

Den nummererte listen ovenfor er kontrakten, ikke en eksportert profil. Hver klient implementerer kontrollflaten sin ulikt, og noen krever en plugin, en uttrykkelig kontrolltillatelse eller et engangssamtykke fra brukeren som ingen automatisering kan levere.

Tilkoblet er ikke det samme som klar

En status som sier at tunnelen er startet beviser at klienten godtok forespørselen. Det beviser ikke at oppløseren nå returnerer private adresser, eller at den tiltenkte tjenesten er nåbar. Det er separate resultater, og gapet mellom dem er der en snarvei som åpner for tidlig, feiler stille. Klienten rapporterer sin egen tilstand, ikke tilstanden til veien URL-en vil bruke.

Definer beredskap mot noe arbeidsflyten kan observere. En tilkoblingstilstand fra klienten, en oppløst adresse fra det forventede området eller en nåbarhetstest mot den konkrete tjenesten fungerer alle, forutsatt at testen ikke kan falle tilbake til den vanlige nettverksveien. En test som lykkes via den normale ruten, forteller deg ingenting.

Begrens ventingen. En beredskapsbetingelse uten tidsavbrudd gjør en ødelagt profil til en snarvei som henger, og brukere rapporterer det som telefonen som fryser, ikke som et VPN-problem.

Hva Tasker kan og ikke kan

Tasker leverer limet: en utløser, en ordnet handlingsliste, betingelser og en URL-handling. Dens handling for å åpne URL utfører bare åpningstrinnet og ingenting annet. Tilkoblingstrinnet må komme fra VPN-klienten, via en plugin, en intent eller en eksponert tjeneste som klienten dokumenterer og tillater.

OpenVPN for Android dokumenterer for eksempel et fjernkontrollgrensesnitt bygget på AIDL og intents. Det er en egenskap ved den klienten, ikke en lisens for enhver oppgave på enheten til å styre den. Gi kontroll bare til appen du har til hensikt, fordi et automatiseringslag som kan koble til og fra en tunnel, er en kontrollflate som er verdt å beskytte.

Hvis den installerte klienten ikke eksponerer noen støttet kontrollmekanisme, er det ærlige svaret at denne arbeidsflyten ikke kan bygges på den klienten. En gammel funksjonssammenligningsside er ikke en kapasitetsspesifikasjon for versjonen på telefonen.

Når grensen må være obligatorisk

Automatisering er en bekvemmelighet, og en bekvemmelighet kan ikke håndheve en sikkerhetsgrense. Hvis kravet er at dekkede applikasjoner aldri kommuniserer uten VPN-en, bruk plattformens alltid på-VPN og blokkering, eller den tilsvarende administrerte konfigurasjonen. En nettleserhendelse som utløses etter at navigeringen har begynt, kan ikke erstatte den håndhevelsen, uansett hvor nøye oppgaven er ordnet.

Bestem hvilken du bygger. En snarvei som kobler til først og deretter åpner, er nyttig, og den er ikke en garanti. En administrert enhet med blokkering aktivert er en garanti, og den trenger ikke en Tasker-sekvens i det hele tatt.

Test tre utfall, ikke ett

Kjør arbeidsflyten mot en vellykket tilkobling, et bevisst tidsavbrudd og en vanlig gjenoppkobling etter at tunnelen faller. Tidsavbruddsfallet er det som avslører om sekvensen virkelig stopper, og gjenoppkoblingsfallet avslører om beredskap sjekkes eller bare antas fra en tidligere suksess. Kjør tidsavbruddsfallet først, fordi en arbeidsflyt som ignorerer feil, ikke er verdt å teste for suksess.

Tillat bare mål fra den godkjente listen, og kontroller enhver lenke som kommer utenfra før du åpner den. En oppgave som godtar vilkårlige lenker, blir en måte å starte uventede skjemaer, og en privat administrasjonsside som nås slik, er et verre utfall enn en mislykket snarvei.

Skriv ned profilen, beredskapsbetingelsen og tidsavbruddet ved siden av oppgaven. Den neste personen som endrer VPN-klienten, trenger alle tre, og ingen av dem er synlige fra snarveiikonet.