Tasker: konektu la VPN antaŭ ol malfermi privatan URL-adreson
Tasker devus konekti kaj atendi antaŭ ol malfermi privatan URL-adreson: difinu pretecon, uzu la reg-interfacon de la kliento, kaj tenu ĉiam-an por malmola limo.
Malfermi privatan URL-adreson kaj esperi, ke la tunelo unue ekfunkcios, estas vetkuro, kaj kutime la retumilo venkas. Ŝparvojo, kiu reagas al jam ŝarĝiĝanta paĝo, maltrafis la DNS-serĉon kaj ofte la unuan konekton, kio estas ĝuste la parto, kiu bezonis la VPN-on. La laborfluo devas posedi la ordon anstataŭ observi ĝin. Tri kondiĉoj decidas, ĉu tiu laborfluo entute apartenas al Tasker.
Unu enirpunkto devus posedi la sinsekvon
Donu al la privata servo unu aprobitan enirpunkton, kaj lasu tiun enirpunkton plenumi la paŝojn laŭ ordo. Validigu la celon, elektu la celatan profilon, petu la konekton, atendu pretecan rezulton kun limo pri kiom longe vi atendos, kaj nur tiam malfermu la URL-adreson. Se iu paŝo malsukcesas, haltu kaj diru tion anstataŭ transiri al rekta malfermo.
Ĝuste tiun lastan kondiĉon homoj preterpasas. Laborfluo, kiu tamen malfermas la URL-adreson post tempolimo, estas pli malbona ol neniu aŭtomatigo, ĉar ĝi produktas peton, kiu aspektas kiel malsukcesinta VPN, kvankam ĝi neniam uzis unu.
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
La numerita listo supre estas la kontrakto, ne eksportita profilo. Ĉiu kliento realigas sian regsurfacon malsame, kaj iuj postulas kromaĵon, eksplicitan regpermeson aŭ unufojan konsenton de la uzanto, kiun neniu aŭtomatigo povas liveri.
Konektita ne samas kiel preta
Stato, kiu diras, ke la tunelo ekfunkciis pruvas, ke la kliento akceptis la peton. Ĝi ne pruvas, ke la solvilo nun redonas privatajn adresojn aŭ ke la celata servo estas atingebla. Tiuj estas apartaj rezultoj, kaj la breĉo inter ili estas la loko, kie ŝparvojo, kiu malfermas tro frue, malsukcesas silente. La kliento raportas sian propran staton, ne la staton de la vojo, kiun la URL-adreso uzos.
Difinu pretecon rilate al io, kion la laborfluo povas observi. Konekta stato de la kliento, solvita adreso el la atendata gamo aŭ atingeblo-sondo al la specifa servo ĉiuj funkcias, kondiĉe ke la sondo ne povas refali al la ordinara reta vojo. Sondo, kiu sukcesas tra la normala vojo, diras al vi nenion.
Limigu la atendon. Preteca kondiĉo sen tempolimo transformas difektitan profilon en ŝparvojon, kiu pendas, kaj uzantoj raportas tion kiel frostigitan telefonon, ne kiel VPN-problemon.
Kion Tasker povas fari kaj kion ne
Tasker liveras la gluon: ellasilon, ordigitan agonliston, kondiĉojn kaj URL-agon. Ĝia ago malfermi URL plenumas nur la malferman paŝon kaj nenion pli. La konekta paŝo devas veni de la VPN-kliento, per kromaĵo, intent aŭ malkaŝita servo, kiun la kliento dokumentas kaj permesas.
OpenVPN for Android, ekzemple, dokumentas fora-regadan interfacon konstruitan sur AIDL kaj intentoj. Tio estas kapablo de tiu kliento, ne permesilo por iu ajn tasko sur la aparato regi ĝin. Donu regadon nur al la apo, kiun vi celas, ĉar aŭtomatiga tavolo, kiu povas konekti kaj malkonekti tunelon, estas regsurfaco inda je protekto.
Se la instalita kliento ne montras iun subtenatan regan mekanismon, la honesta respondo estas, ke ĉi tiu laborfluo ne povas esti konstruita sur tiu kliento. Malnova paĝo pri komparo de trajtoj ne estas kapabla specifiko por la versio en la telefono.
Kiam la limo devas esti deviga
Aŭtomatigo estas komforto, kaj komforto ne povas devigi sekurecan limon. Se la postulo estas, ke kovritaj aplikoj neniam komunikas sen la VPN, uzu la ĉiam-an VPN kaj blokadan agordon de la platformo, aŭ la ekvivalentan administritan agordon. Retumila evento, kiu ekfunkcias post kiam navigado komenciĝis, ne povas anstataŭi tiun devigon, kiom ajn zorge la tasko estas ordigita.
Decidu, kiun vi konstruas. Ŝparvojo, kiu unue konektas kaj poste malfermas, estas utila kaj ĝi ne estas garantio. Administrita aparato kun blokado ŝaltita estas garantio kaj ĝi tute ne bezonas Tasker-sekvencon.
| Requirement | Mechanism |
|---|---|
| Open the page after the tunnel is ready | Ordered task with a bounded readiness wait |
| Never allow traffic outside the tunnel | Always-on VPN with blocking, or managed policy |
| Only some apps use the tunnel | Per-app VPN or work-profile scope |
| Different URL every time | Validate the input before opening it |
Testu tri rezultojn, ne unu
Rulu la laborfluon kontraŭ sukcesa konekto, intenca tempolimo kaj ordinara rekonekto post kiam la tunelo falas. La tempolima kazo estas tiu, kiu malkaŝas, ĉu la sinsekvo vere haltas, kaj la rekonekta kazo malkaŝas, ĉu preteco estas kontrolata aŭ nur supozata el antaŭa sukceso. Rulu la tempoliman kazon unue, ĉar laborfluo, kiu ignoras malsukceson, ne indas esti testata por sukceso.
Permesu nur celojn el la aprobita listo, kaj kontrolu ĉiun ligilon, kiu venas de ekstere, antaŭ ol malfermi ĝin. Tasko, kiu akceptas arbitrajn ligilojn, fariĝas maniero lanĉi neatenditajn skemojn, kaj privata administra paĝo atingita tiel estas pli malbona rezulto ol malsukcesinta ŝparvojo.
Skribu la profilon, la pretecan kondiĉon kaj la tempolimon apud la tasko. La sekva persono, kiu ŝanĝos la VPN-klienton, bezonos ĉiujn tri, kaj neniu el ili videblas de la ŝparvoja ikono.