Eseguire un'attività quando la VPN si connette: evento, polling o credenziale?
Uno script di accesso viene eseguito prima che il tunnel esista. Confronta un trigger di evento di rete, un polling della risorsa e credenziali salvate in base a ciò che ciascuno garantisce.
Uno script di accesso che mappa un'unità o avvia un processo di sincronizzazione viene eseguito prima che il tunnel abbia un indirizzo, quindi fallisce in silenzio e l'utente lo ripara a mano ogni mattina. Windows non offre alla maggior parte dei client una richiamata di connessione per VPN, ma registra il cambio di rete, e quel record può avviare il lavoro al momento giusto. La scelta è tra reagire a quel record, interrogare la risorsa e rimuovere la richiesta che rendeva visibile l'errore.
Confrontare i tre meccanismi per ciò che garantiscono è meglio che classificarli per eleganza. Ognuno fallisce in modo diverso, e il modo di fallire è ciò con cui convivi dopo.
Perché l'accesso parte troppo presto
Accesso e avvio vengono eseguiti prima che la scheda VPN riceva il suo indirizzo, quindi una mappatura di unità, un URL interno o una connessione a database tentati in quel momento non hanno né rotta né resolver. La richiesta fallisce e la sessione resta in uno stato che l'utente deve riparare a mano. Spostare lo stesso script nella cartella di avvio non cambia nulla, perché il problema di ordine viaggia con esso. Il trigger deve essere un cambio di rete e non un evento di sessione.
Un'attività pianificata all'accesso con un ritardo arbitrario sembra una soluzione ed è in realtà una congettura. Funziona su un collegamento veloce e fallisce su uno lento, che è il tipo di affidabilità meno utile.
Tre ganci confrontati
I meccanismi differiscono in ciò che osservano, nella rapidità con cui reagiscono e in ciò che fanno per una riconnessione più tardi nella giornata. La tabella li confronta su questi tre punti e non su quanto ciascuno suoni intelligente.
| 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 |
Leggi la tabella riga per riga. Il gancio di evento è il più rapido e il più rumoroso, poiché Windows registra ogni rete, compreso il Wi-Fi del bar, quindi l'azione deve verificare la risorsa prima di fare qualsiasi cosa. Il polling è più lento e più preciso, perché riesce esattamente quando la condivisione o il nome host rispondono, e non ha bisogno di sapere quale client è installato. Le credenziali salvate non sono affatto un'opzione concorrente: rimuovono la richiesta della password, che è una seconda e indipendente ragione per cui una mappatura all'accesso fallisce.
Scegliere tra i primi due dipende dal fatto che esista un evento utilizzabile sul client. Dove esiste, un evento più un controllo della risorsa è il valore predefinito migliore.
Costruisci correttamente il trigger di evento
Il record si trova nel registro Microsoft-Windows-NetworkProfile/Operational, e l'ID 10001 contrassegna una rete appena connessa. Crea l'attività con un trigger In occasione di un evento rivolto a quel registro, a quel nome di provider e a quell'identificatore. Ogni rete a cui la macchina si unisce lo attiverà, quindi l'azione ha bisogno di una clausola di protezione e non di un'ipotesi, e dovrebbe essere eseguita solo mentre l'utente ha effettuato l'accesso se il lavoro tocca unità mappate.
La clausola di protezione dovrebbe verificare ciò di cui l'attività ha davvero bisogno, come un percorso di condivisione o una porta di servizio, e uscire in silenzio quando non è raggiungibile. Verificare il nome della scheda non basta, perché un client può riutilizzare una scheda su più profili. Un'uscita silenziosa mantiene leggibile il registro ed evita una tempesta di nuovi tentativi contro una rete che non servirà mai la risorsa.
Verifica che l'attività venga eseguita al momento giusto
Dimostra il momento, non la configurazione. I comandi seguenti mostrano la definizione dell'attività, gli eventi recenti del profilo di rete e se la risorsa è raggiungibile dall'account con cui viene eseguita l'attività. Eseguili dopo una vera riconnessione e non dopo un avvio manuale.
schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoami
Una voce nella cronologia delle attività che esiste mentre nessun evento di rete corrisponde significa che il trigger è sbagliato e non l'azione. Se gli eventi compaiono e l'attività no, l'attività potrebbe essere eseguita con un account che non vede la risorsa, e l'output dell'account è l'indizio. Un controllo della risorsa che passa mentre la mappatura manca ancora indica il contesto di sessione e non la connettività. Ognuna di queste tre osservazioni ti porta a una correzione diversa.
Scrivi una riga di registro per ogni esecuzione con l'indirizzo, il risultato della risorsa e l'esito. Il prossimo errore mostrerà allora se l'attività è partita presto, è partita sulla rete sbagliata o non è partita affatto.