Tasker: anslut VPN innan du öppnar en privat URL

Att öppna en privat URL och hoppas att tunneln kommer upp först är en kapplöpning, och webbläsaren vinner oftast. En genväg som reagerar på en sida som redan laddas har missat DNS-sökningen och ofta den första anslutningen, vilket är precis den del som behövde VPN:en. Arbetsflödet måste äga ordningen i stället för att observera den. Tre villkor avgör om det arbetsflödet alls hör hemma i Tasker.

En enda ingångspunkt bör äga sekvensen

Ge den privata tjänsten en enda godkänd ingångspunkt och låt den ingångspunkten utföra stegen i ordning. Validera målet, välj den avsedda profilen, begär anslutningen, vänta på ett beredskapsresultat med en gräns för hur länge du väntar, och öppna först då URL:en. Om något steg misslyckas, stanna och säg det i stället för att falla igenom till en direkt öppning.

Det är den sista klausulen folk hoppar över. Ett arbetsflöde som ändå öppnar URL:en vid timeout är sämre än ingen automatisering, eftersom det skapar en begäran som ser ut som en misslyckad VPN medan den aldrig använde någon.

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 numrerade listan ovan är kontraktet, inte en exporterad profil. Varje klient implementerar sin kontrollvy olika, och vissa kräver ett plugin, en uttrycklig kontrollbehörighet eller ett engångssamtycke från användaren som ingen automatisering kan leverera.

Ansluten är inte samma sak som redo

En status som säger att tunneln har startat bevisar att klienten accepterade begäran. Det bevisar inte att resolvern nu returnerar privata adresser eller att den avsedda tjänsten är nåbar. Det är separata resultat, och gapet mellan dem är där en genväg som öppnar för tidigt misslyckas tyst. Klienten rapporterar sitt eget tillstånd, inte tillståndet för den väg URL:en kommer att använda.

Definiera beredskap mot något som arbetsflödet kan observera. Ett anslutningstillstånd från klienten, en upplöst adress från det förväntade intervallet eller ett nåbarhetstest mot den specifika tjänsten fungerar alla, förutsatt att testet inte kan falla tillbaka på den vanliga nätverksvägen. Ett test som lyckas via den normala vägen säger dig ingenting.

Begränsa väntan. Ett beredskapsvillkor utan timeout gör en trasig profil till en genväg som hänger sig, och användare rapporterar det som telefonen som fryser, inte som ett VPN-problem.

Vad Tasker kan och inte kan

Tasker levererar limmet: en utlösare, en ordnad åtgärdslista, villkor och en URL-åtgärd. Dess åtgärd att öppna URL utför bara öppningssteget och ingenting annat. Anslutningssteget måste komma från VPN-klienten, via ett plugin, en intent eller en exponerad tjänst som klienten dokumenterar och tillåter.

OpenVPN for Android dokumenterar till exempel ett fjärrstyrningsgränssnitt byggt på AIDL och intents. Det är en förmåga hos den klienten, inte en licens för vilken uppgift som helst på enheten att styra den. Ge kontroll bara till appen du avser, eftersom ett automatiseringslager som kan ansluta och koppla från en tunnel är en kontrollvy som är värd att skydda.

Om den installerade klienten inte exponerar någon stödd kontrollmekanism är det ärliga svaret att detta arbetsflöde inte kan byggas på den klienten. En gammal funktionsjämförelsesida är inte en kapacitetsspecifikation för versionen på telefonen.

När gränsen måste vara obligatorisk

Automatisering är en bekvämlighet, och en bekvämlighet kan inte upprätthålla en säkerhetsgräns. Om kravet är att omfattade applikationer aldrig kommunicerar utan VPN:en, använd plattformens alltid på-VPN och blockering, eller motsvarande hanterade konfiguration. En webbläsarhändelse som utlöses efter att navigeringen har börjat kan inte ersätta den upprätthållningen, hur noggrant uppgiften än är ordnad.

Bestäm vilken du bygger. En genväg som ansluter först och sedan öppnar är användbar och det är ingen garanti. En hanterad enhet med blockering aktiverad är en garanti och den behöver ingen Tasker-sekvens alls.

Testa tre utfall, inte ett

Kör arbetsflödet mot en lyckad anslutning, en avsiktlig timeout och en vanlig återanslutning efter att tunneln faller. Timeoutfallet är det som avslöjar om sekvensen verkligen stoppar, och återanslutningsfallet avslöjar om beredskap kontrolleras eller bara antas från en tidigare framgång. Kör timeoutfallet först, eftersom ett arbetsflöde som ignorerar misslyckande inte är värt att testas för framgång.

Tillåt bara mål från den godkända listan, och kontrollera varje länk som kommer utifrån innan du öppnar den. En uppgift som accepterar godtyckliga länkar blir ett sätt att starta oväntade scheman, och en privat administrationssida som nås så är ett sämre utfall än en misslyckad genväg.

Skriv ned profilen, beredskapsvillkoret och timeouten bredvid uppgiften. Nästa person som ändrar VPN-klienten behöver alla tre, och ingen av dem syns från genvägsikonen.