Rularea unei activități când VPN-ul se conectează: eveniment, interogare sau acreditare?
Un script de autentificare rulează înainte ca tunelul să existe. Comparați un declanșator de eveniment de rețea, o interogare a resursei și acreditările stocate după ce garantează fiecare.
Un script de autentificare care mapează un disc sau pornește o sarcină de sincronizare rulează înainte ca tunelul să aibă o adresă, așa că eșuează în tăcere, iar utilizatorul îl repară manual în fiecare dimineață. Windows nu oferă majorității clienților niciun apel invers la conectare pentru fiecare VPN, dar înregistrează schimbarea rețelei, iar acea înregistrare poate porni lucrul la momentul potrivit. Alegerea este între a reacționa la acea înregistrare, a interoga resursa și a elimina promptul care făcea vizibilă eroarea.
Compararea celor trei mecanisme după ce garantează este mai bună decât clasificarea lor după eleganță. Fiecare eșuează altfel, iar modul de eșec este ceea ce trăiești după aceea.
De ce autentificarea pornește prea devreme
Autentificarea și pornirea rulează înainte ca adaptorul VPN să-și primească adresa, așa că o mapare de disc, un URL intern sau o conexiune la baza de date încercate în acel moment nu au nici rută, nici resolver. Cererea eșuează, iar sesiunea rămâne într-o stare pe care utilizatorul trebuie să o repare manual. Mutarea aceluiași script în folderul de pornire nu schimbă nimic, pentru că problema de ordine călătorește cu el. Declanșatorul trebuie să fie o schimbare de rețea, nu un eveniment de sesiune.
O activitate programată la autentificare cu o întârziere arbitrară pare o soluție și este de fapt o presupunere. Funcționează pe o legătură rapidă și eșuează pe una lentă, ceea ce este cel mai puțin util tip de fiabilitate.
Trei cârlige comparate
Mecanismele diferă prin ce observă, cât de repede reacționează și ce fac la o reconectare mai târziu în cursul zilei. Tabelul le compară pe aceste trei puncte și nu pe cât de deștept sună fiecare.
| 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 |
Citiți tabelul rând cu rând. Cârligul de eveniment este cel mai rapid și cel mai zgomotos, deoarece Windows înregistrează fiecare rețea, inclusiv Wi-Fi-ul cafenelei, așa că acțiunea trebuie să verifice resursa înainte de a face ceva. Interogarea este mai lentă și mai precisă, pentru că reușește exact când răspunde partajarea sau numele de gazdă, și nu are nevoie să știe ce client este instalat. Acreditările stocate nu sunt deloc o opțiune concurentă: elimină promptul de parolă, care este un al doilea motiv independent pentru care o mapare la autentificare eșuează.
Alegerea între primele două depinde de existența unui eveniment utilizabil pe client. Acolo unde există, un eveniment plus o verificare a resursei este valoarea implicită mai bună.
Construiți corect declanșatorul de eveniment
Înregistrarea se află în jurnalul Microsoft-Windows-NetworkProfile/Operational, iar ID 10001 marchează o rețea care tocmai s-a conectat. Creați activitatea cu un declanșator La producerea unui eveniment îndreptat spre acel jurnal, acel nume de furnizor și acel identificator. Fiecare rețea la care se alătură mașina îl va declanșa, așa că acțiunea are nevoie de o clauză de protecție, nu de o presupunere, și ar trebui să ruleze doar cât timp utilizatorul este autentificat dacă lucrul atinge discuri mapate.
Clauza de protecție ar trebui să testeze ce are nevoie de fapt activitatea, cum ar fi o cale de partajare sau un port de serviciu, și să iasă în tăcere când nu este accesibilă. Testarea numelui adaptorului nu este suficientă, pentru că un client poate reutiliza un adaptor în mai multe profiluri. O ieșire în tăcere păstrează jurnalul lizibil și împiedică o furtună de reîncercări împotriva unei rețele care nu va servi niciodată resursa.
Testați că activitatea rulează la momentul potrivit
Dovediți momentul, nu configurația. Comenzile de mai jos arată definiția activității, evenimentele recente ale profilului de rețea și dacă resursa este accesibilă din contul sub care rulează activitatea. Rulați-le după o reconectare reală, nu după o pornire manuală.
schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoamiO intrare în istoricul activităților care există în timp ce niciun eveniment de rețea nu se potrivește înseamnă că declanșatorul este greșit, nu acțiunea. Dacă evenimentele apar, iar activitatea nu rulează, activitatea poate rula sub un cont care nu vede resursa, iar ieșirea contului este indiciul. O verificare a resursei care trece în timp ce maparea încă lipsește indică contextul sesiunii, nu conectivitatea. Fiecare dintre cele trei observații vă duce la o remediere diferită.
Scrieți o linie de jurnal pentru fiecare execuție cu adresa, rezultatul resursei și rezultatul final. Următoarea eroare va arăta atunci dacă activitatea a rulat devreme, a rulat pe rețeaua greșită sau nu a rulat deloc.