Ruli taskon kiam la VPN konektiĝas: evento, enketo aŭ legitimilo?
Ensaluta skripto ruliĝas antaŭ ol ekzistas la tunelo. Komparu retan eventan ekigilon, rimedan enketadon kaj konservitajn legitimilojn laŭ tio, kion ĉiu garantias.
Ensaluta skripto, kiu mapas diskon aŭ komencas sinkronigan taskon, ruliĝas antaŭ ol la tunelo havas adreson, do ĝi malsukcesas silente kaj la uzanto riparas ĝin permane ĉiun matenon. Vindozo ne ofertas al plej multaj klientoj po-VPNan konektan revokon, sed ĝi registras la retan ŝanĝon, kaj tiu registro povas komenci laboron en la ĝusta momento. La elekto staras inter reagi al tiu registro, enketi la rimedon kaj forigi la invitilon, kiu igis la malsukceson videbla.
Kompari la tri mekanismojn laŭ tio, kion ili garantias, superas ordigi ilin laŭ eleganto. Ĉiu malsukcesas malsame, kaj la malsukcesa reĝimo estas tio, kun kio vi poste vivas.
Kial ensaluto ekas tro frue
Ensaluto kaj lanĉo ruliĝas antaŭ ol la VPN-adaptilo ricevas sian adreson, do diskomapo, interna URL aŭ datumbaza konekto provita en tiu momento havas nek itineron nek solvilon. La peto malsukcesas, kaj la sesio restas en stato, kiun la uzanto devas ripari permane. Movi la saman skripton al la lanĉa dosierujo ŝanĝas nenion, ĉar la ordiga problemo vojaĝas kun ĝi. La ekigilo devas esti reta ŝanĝo, ne sesia evento.
Planita tasko ĉe ensaluto kun arbitra prokrasto aspektas kiel riparo kaj fakte estas konjekto. Ĝi funkcias sur rapida ligo kaj malsukcesas sur malrapida, kio estas la malplej utila speco de fidindeco.
Tri hokoj komparitaj
La mekanismoj diferencas laŭ tio, kion ili observas, kiom rapide ili reagas kaj kion ili faras pri rekonekto poste dum la tago. La tabelo komparas ilin laŭ tiuj tri punktoj, ne laŭ tio, kiom saĝe ĉiu sonas.
| Mechanism | Reacts to | Covers a mid-session reconnect | Typical failure |
|---|---|---|---|
| Network profile event | A network connect record | Yes, when the event repeats | Runs on the wrong network |
| Resource poll with backoff | The resource becoming reachable | Yes | Log noise and a wasted window |
| Stored credentials alone | Nothing; it removes a prompt | No | Still fires before the tunnel |
Legu la tabelon linion post linio. La eventa hoko estas la plej rapida kaj la plej brua, ĉar Vindozo registras ĉiun reton, inkluzive la Wi-Fi de la kafejo, do la ago devas kontroli la rimedon antaŭ ol fari ion ajn. La enketado estas pli malrapida kaj pli preciza, ĉar ĝi sukcesas ĝuste kiam la kunhavo aŭ la gastiganta nomo respondas, kaj ĝi bezonas neniun scion pri tio, kiu kliento estas instalita. Konservitaj legitimiloj tute ne estas konkurenca opcio: ili forigas la pasvortan invitilon, kio estas dua kaj sendependa kaŭzo, kial mapo ĉe ensaluto malsukcesas.
Elekti inter la du unuaj dependas de tio, ĉu ekzistas uzebla evento ĉe la kliento. Kie ĝi ekzistas, evento plus rimeda kontrolo estas la pli bona defaŭlto.
Konstruu la eventan ekigilon ĝuste
La registro troviĝas en la protokolo Microsoft-Windows-NetworkProfile/Operational, kaj ID 10001 markas reton, kiu ĵus konektiĝis. Kreu la taskon kun ekigilo Ĉe evento celanta tiun protokolon, tiun provizantan nomon kaj tiun identigilon. Ĉiu reto, al kiu la maŝino aliĝas, ekigos ĝin, do la ago bezonas gardan kondiĉon anstataŭ supozon, kaj ĝi devus ruliĝi nur dum la uzanto estas ensalutinta, se la laboro tuŝas mapitajn diskojn.
La garda kondiĉo devus testi tion, kion la tasko vere bezonas, kiel kunhavan vojon aŭ servan pordon, kaj silente eliri kiam ĝi neatingeblas. Testi la adaptilan nomon ne sufiĉas, ĉar kliento povas reuzi unu adaptilon tra pluraj profiloj. Silenta eliro tenas la protokolon legebla kaj malhelpas ŝtormon de ripetoj kontraŭ reto, kiu neniam servos la rimedon.
Testu, ke la tasko ruliĝas en la ĝusta momento
Pruvu la tempon, ne la agordon. La subaj komandoj montras la taskan difinon, la lastatempajn retprofilajn eventojn kaj ĉu la rimedo atingeblas el la konto, sub kiu la tasko ruliĝas. Rulu ilin post vera rekonekto, ne post permana starto.
schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoamiTaskhistoria ero, kiu ekzistas dum neniu reta evento kongruas, signifas, ke la ekigilo estas malĝusta, ne la ago. Se la eventoj aperas kaj la tasko ne, la tasko eble ruliĝas sub konto, kiu ne vidas la rimedon, kaj la kontoeligilo estas la indico. Rimeda kontrolo, kiu sukcesas dum la mapo ankoraŭ mankas, indikas sesian kuntekston, ne konekteblecon. Ĉiu el tiuj tri observoj kondukas vin al malsama riparo.
Skribu unu protokolan linion por ĉiu rulo kun la adreso, la rimeda rezulto kaj la fina rezulto. La sekva malsukceso tiam montros, ĉu la tasko ruliĝis frue, ruliĝis sur la malĝusta reto aŭ tute ne ruliĝis.