Reparar Check Point VPN: se perdió la conectividad con el servicio VPN
Perder la conectividad con el servicio VPN es un fallo local del cliente. Trabaje en orden: servicios, enlace del adaptador y luego una reparación MSI que conserva la configuración del sitio.
Conectar no hace nada y el cliente informa de que se ha perdido la conectividad con el servicio VPN. Esa frase habla del equipo que tiene delante: el servicio que hay detrás del túnel, el adaptador virtual sobre el que se asienta o la instalación que une ambos. Nada en ella señala a la puerta de enlace, así que volver a escribir la dirección del sitio o la cuenta no cambia nada. Léala como un fallo local y el espacio de búsqueda se reduce.
Lea el error como un fallo local
Los rechazos del lado del servidor suenan distinto: autenticación fallida, puerta de enlace inaccesible, certificado no válido. Perder la conexión con el servicio significa que el cliente no puede alcanzar su propio demonio, lo que deja fuera la puerta de enlace, las credenciales y las reglas del cortafuegos desde la primera hora. Copie la redacción exacta en sus notas antes de tocar nada, porque esa cadena es lo que separa un servicio muerto de un rechazo por política.
Después de eso solo quedan tres sospechosos: servicios, controladores y el instalador.
Inicie todos los servicios de Check Point, no solo uno
Abra services.msc y lea todas las entradas de Check Point, no solo la cuyo nombre aparece en el error. Una instalación de Endpoint Security VPN registra varias, y una sola entrada detenida o deshabilitada basta para impedir que el cliente se conecte. Inícielas todas, luego pase las que el cliente necesita de Manual a Automático, porque un servicio Manual que falla cuando se le pide reproduce el error exactamente.
La cadena de dependencias importa tanto como los propios servicios.
DHCP Client asigna su dirección al adaptador virtual y a su vez se apoya en tres componentes: Network Store Interface Service, el controlador NetIO legacy TDI y Ancillary Function Driver for Winsock. Detenga DHCP Client y el servicio VPN puede arrancar limpiamente mientras el adaptador sigue sin dirección. Las actualizaciones de características son el desencadenante recurrente, porque pueden devolver en silencio un servicio de terceros a Manual o Deshabilitado. Consulte el tipo de inicio después de una de esas actualizaciones en lugar de decidir que la instalación está dañada.
Get-Service -Name "Check*" | Format-Table -AutoSize Name, Status, StartType
Get-Service -Name Dhcp | Format-Table -AutoSize Name, Status, StartType
Compruebe el enlace del adaptador antes de reinstalar
Cuando los servicios funcionan y el mensaje persiste, mire el adaptador. Un adaptador puede estar presente y seguir roto, normalmente porque el controlador al que se enlaza no sobrevivió a una actualización. Desactivarlo y volver a activarlo es la prueba barata, y el Administrador de dispositivos necesita un ajuste cambiado antes de que el dispositivo siquiera sea visible.
set devmgr_show_nonpresent_devices=1
start devmgmt.msc
En Ver, elija Mostrar dispositivos ocultos, abra Adaptadores de red y localice el adaptador virtual de Check Point. Desactívelo y vuelva a activarlo, luego pruebe una conexión. Una insignia de advertencia, o ninguna entrada, significa que el controlador se ha ido y no que esté en pausa.
Repare la instalación en lugar de quitarla
En Programas y características, haga clic derecho en Check Point Endpoint Security VPN y elija Reparar. Esa única pasada vuelve a registrar el servicio y el adaptador y deja la configuración del sitio donde está. Instalar desde cero tras una desinstalación descarta esa configuración y normalmente cuesta un reinicio para nada.
Si Reparar se detiene a medias, el registro de instalación nombra el componente que se negó. Cuando termine, compruebe que tanto el servicio como el adaptador han vuelto antes de reconectar; un adaptador que aún lleva una insignia de advertencia significa que el paquete del controlador nunca se reinstaló y que Reparar por sí solo no puede arreglarlo.
Separe un problema de ruta de red de un problema del cliente
No todos los casos son locales. Una LAN corporativa que empuja el tráfico por un proxy que autentica puede impedir que el cliente alcance la puerta de enlace, mientras que el mismo portátil se conecta bien por un punto de acceso del teléfono. Si el punto de acceso funciona, el cliente está sano y el problema es de la ruta del proxy.
Un ajuste de BIOS que cambia los adaptadores de red automáticamente también puede cambiar el enlace bajo el cliente. Desactívelo solo donde el equipo exponga realmente la opción, ya que la mayoría de los portátiles no lo hacen.
Conecte y confirme que el adaptador del túnel recibió una dirección y que los servicios siguieron activos antes de cerrar el caso.
ipconfig /all
Get-Service -Name "Check*" | Format-Table -AutoSize Name, Status
Un túnel que aguanta un minuto y luego muere suele señalar al adaptador, o a un producto de seguridad que lo inspecciona, más que a la cuenta. Programe un reinicio tras una reparación de controlador o MSI, porque es lo que reconstruye el enlace, y anote los tipos de inicio sanos mientras todo funciona para que la próxima actualización tenga con qué comparar.