Riparare Check Point VPN: la connettività con il servizio VPN è persa
La perdita di connettività con il servizio VPN è un guasto locale del client. Procedere in ordine: servizi, binding dell’adattatore e poi una riparazione MSI che conserva la configurazione del sito.
Connetti non fa nulla e il client segnala che la connettività con il servizio VPN è persa. Quella frase riguarda la macchina davanti a voi: il servizio dietro il tunnel, l’adattatore virtuale su cui poggia o l’installazione che lega i due. Nulla in essa accusa il gateway, quindi riscrivere l’indirizzo del sito o l’account non cambia nulla. Leggetela come un guasto locale e lo spazio di ricerca si restringe.
Leggere l’errore come un guasto locale
I rifiuti lato server suonano diversi: autenticazione fallita, gateway irraggiungibile, certificato non valido. Perdere la connessione al servizio significa che il client non riesce a raggiungere il proprio demone, il che esclude gateway, credenziali e regole del firewall fin dalla prima ora. Copiate la dicitura esatta nelle vostre note prima di toccare qualsiasi cosa, perché è quella stringa a separare un servizio morto da un rifiuto di policy.
Dopodiché restano solo tre sospetti: servizi, driver e programma di installazione.
Avviate ogni servizio Check Point, non solo uno
Aprite services.msc e leggete ogni voce Check Point, non solo quella il cui nome compare nell’errore. Un’installazione di Endpoint Security VPN ne registra diverse, e una sola voce arrestata o disabilitata basta a impedire al client di connettersi. Avviateli tutti, poi portate quelli da cui dipende il client da Manuale ad Automatico, perché un servizio Manuale che fallisce su richiesta riproduce l’errore esattamente.
La catena delle dipendenze conta quanto i servizi stessi.
DHCP Client assegna l’indirizzo all’adattatore virtuale e a sua volta poggia su tre componenti: Network Store Interface Service, il driver NetIO legacy TDI e Ancillary Function Driver for Winsock. Arrestate DHCP Client e il servizio VPN può avviarsi pulito mentre l’adattatore è ancora senza indirizzo. Gli aggiornamenti delle funzionalità sono l’innesco ricorrente, perché possono riportare in silenzio un servizio di terze parti su Manuale o Disabilitato. Dopo uno di questi aggiornamenti interrogate il tipo di avvio invece di concludere che l’installazione sia corrotta.
Get-Service -Name "Check*" | Format-Table -AutoSize Name, Status, StartType
Get-Service -Name Dhcp | Format-Table -AutoSize Name, Status, StartType
Controllate il binding dell’adattatore prima di reinstallare
Quando i servizi sono in esecuzione e il messaggio persiste, guardate l’adattatore. Un adattatore può essere presente e comunque guasto, di solito perché il driver a cui si lega non è sopravvissuto a un aggiornamento. Disabilitarlo e riabilitarlo è il test economico, e il Gestione periferiche richiede che un’impostazione venga cambiata prima che il dispositivo sia persino visibile.
set devmgr_show_nonpresent_devices=1
start devmgmt.msc
In View scegliete Show hidden devices, aprite Network adapters e individuate l’adattatore virtuale Check Point. Disattivatelo e riattivatelo, poi provate una connessione. Un badge di avviso, o nessuna voce, significa che il driver è sparito e non che sia in pausa.
Riparate l’installazione invece di rimuoverla
In Programs and Features fate clic con il tasto destro su Check Point Endpoint Security VPN e scegliete Repair. Quella singola passata registra di nuovo sia il servizio sia l’adattatore e lascia la configurazione del sito dov’è. Installare da zero dopo una disinstallazione scarta quella configurazione e di solito costa un riavvio per nulla.
Se Repair si ferma a metà, il log di installazione nomina il componente che ha rifiutato. Al termine, verificate che sia il servizio sia l’adattatore siano tornati prima di riconnettervi; un adattatore che porta ancora un badge di avviso significa che il pacchetto del driver non è mai stato reinstallato, e Repair da solo non può rimediare.
Separa un problema di percorso di rete da un problema del client
Non ogni caso è locale. Una LAN aziendale che spinge il traffico attraverso un proxy che autentica può impedire al client di raggiungere il gateway, mentre lo stesso portatile si connette bene tramite un hotspot del telefono. Se l’hotspot funziona, il client è sano e il problema è del percorso del proxy.
Un’impostazione del BIOS che commuta automaticamente gli adattatori di rete può anche sostituire il collegamento sotto il client. Disabilitatela solo dove la macchina espone davvero l’opzione, perché la maggior parte dei portatili non lo fa.
Connettetevi e confermate che l’adattatore del tunnel abbia ottenuto un indirizzo e che i servizi siano rimasti attivi prima di chiudere il caso.
ipconfig /all
Get-Service -Name "Check*" | Format-Table -AutoSize Name, Status
Un tunnel che resiste un minuto e poi muore di solito accusa l’adattatore, o un prodotto di sicurezza che lo ispeziona, più che l’account. Pianificate un riavvio dopo una riparazione di driver o MSI, perché è ciò che ricostruisce il binding, e annotate i tipi di avvio sani mentre tutto funziona, così il prossimo aggiornamento ha con cosa confrontarsi.