RasMan e RemoteAccess non sono lo stesso servizio
Uno gestisce le connessioni client, l’altro è un ruolo server di routing. Confrontate il primo errore del client che fallisce prima di abilitare una funzione di cui non ha mai avuto bisogno.
RasMan e RemoteAccess compaiono uno accanto all’altro in un elenco di servizi, entrambi menzionano l’accesso remoto, e svolgono lavori diversi. Uno gestisce le connessioni client, e l’altro è il ruolo server di routing e accesso remoto. Trattarli come intercambiabili è il modo in cui un portatile finisce con una funzione server abilitata per correggere un problema client. Un servizio può essere pertinente per nome e irrilevante per funzione, il che rende i nomi la prova meno utile del ticket.
Due nomi, due lavori diversi
RasMan è il gestore delle connessioni che si occupa dell’accesso remoto lato client, inclusa la rubrica telefonica e la meccanica di connessione usata dal client VPN integrato. RemoteAccess è il servizio Routing e accesso remoto, che fornisce routing, NAT e accesso remoto lato server su una macchina che agisce come router. La panoramica di RAS di Microsoft descrive quel modello client, e una workstation che compone un VPN ha bisogno solo del primo dei due. Installare o avviare il secondo non fa funzionare meglio il primo.
Un inventario di sola lettura non costa nulla e risponde alla prima domanda in pochi secondi. Eseguite entrambe le letture e tenete l’output accanto all’errore del client, perché un servizio assente e un servizio arrestato sono punti di partenza diversi.
Get-Service -Name RasMan,RemoteAccess -ErrorAction SilentlyContinue | Select-Object Name,Status,StartType
Get-VpnConnection | Select-Object Name,ConnectionStatus,ServerAddress
Un RasMan arrestato con tipo di avvio manuale è un servizio che il criterio ha disattivato, e questa è una questione di gestione, non una funzione mancante. Un RemoteAccess assente è lo stato normale di una workstation e non dice nulla del client. L’elenco delle connessioni conta perché mostra se Windows crede che esista un profilo prima che un servizio venga incolpato del guasto.
Da cosa dipende davvero il client
Identificate la dipendenza reale del client che fallisce e il suo primo errore, non l’ultimo. Un servizio arrestato dal criterio è una possibilità tra diverse. Due client che si contendono una rotta predefinita, DNS privato applicato all’adattatore sbagliato, un driver di filtro lasciato da un vecchio prodotto e criteri di sicurezza che non avrebbero mai dovuto coesistere producono ciascuno il proprio errore. Nessuno di essi viene riparato da una modalità di avvio. Quell’elenco è anche il motivo per cui una modalità di avvio è un cattivo primo passo, dato che una sola finestra può nascondere cinque cause diverse.
Il primo errore conta più dell’ultimo, perché tutto ciò che segue è una conseguenza. Catturatelo prima di fare modifiche, altrimenti la prova scompare con il sintomo.
Perché abilitare RRAS non ripara nulla qui
Attivare il ruolo di routing aggiunge un servizio, un insieme di configurazione del registro e, su alcune versioni, richieste sulla configurazione iniziale. Nulla di tutto ciò fornisce una dipendenza client, e su un portatile gestito può violare una baseline. Il post di un forum di una persona su un servizio che ha per caso riparato una macchina non è un criterio per abilitare funzioni di routing su tutta una flotta. Un cambiamento di servizio richiede che il ruolo e la documentazione di distribuzione siano d’accordo prima che qualcuno lo tocchi.
È il proprietario del sistema a conservare quella configurazione, non chi ha letto il thread per caso. La deriva della baseline su una flotta è costosa da annullare, e ogni ruolo abilitato è una cosa in più che il prossimo audit dovrà giustificare. Se il ruolo appartiene davvero alla macchina, quella decisione è di mesi precedente a questo ticket.
Confrontate con una macchina che funziona
Confrontate con una macchina funzionante che esegue le stesse versioni client e gli stessi profili previsti, invece di una con gli stessi nomi di scorciatoie del desktop. Due indicatori connessi non implicano un unico criterio di rete coerente, e verificare la coesistenza supportata fa parte del confronto. Annotate la versione del client, l’errore, i servizi presenti e le rotte in vigore su entrambe le macchine. Poi decidete se la differenza è un servizio, una rotta, un criterio o una versione.
Nomi simili sono un indizio su dove guardare, e questo è tutto il loro valore. Una diagnosi richiede un primo errore, una macchina di confronto e un registro anteriore al cambiamento.