El segundo cliente VPN rompió el primero: encuentre el recurso compartido

Ayer el cliente original funcionaba. Hoy el recién llegado reclama una conexión mientras el perfil antiguo se detiene en una etapa que antes superaba sin queja. Las credenciales rara vez están implicadas, y la puerta de enlace suele ser inocente. Lo que ha cambiado es que dos pilas VPN ahora quieren el mismo recurso exclusivo, y la reparación depende de nombrarlo. Recorra las capas en lugar de reinstalar ambos.

Recorra las cuatro capas en orden

Un producto VPN necesita cuatro recursos que pueden chocar: un servicio en segundo plano que a menudo se niega a ejecutarse dos veces, un puerto fijo, un adaptador virtual o filtro de núcleo que ve el tráfico antes que la tabla de enrutamiento, y el derecho a instalar rutas por delante de la predeterminada. Saber cuál cedió convierte un conflicto vago en una sola pregunta con una respuesta comprobable.

Asigne el síntoma a una capa antes de tocar nada. Un cliente que no arranca apunta al servicio; uno que arranca y nunca negocia apunta al puerto; uno que se conecta mientras el otro pierde toda la conectividad apunta al filtro o a la ruta predeterminada. Anote esa asignación, porque ahorra una hora de reinstalar aplicaciones con la esperanza de acertar.

Empiece por el servicio que no se ejecuta dos veces

En Windows un cliente corporativo suele ser más que un túnel, porque instala un servicio, un controlador de filtro y a veces un proveedor de credenciales junto con el perfil. Anote qué servicios se ejecutan antes del cambio y de nuevo después, y luego compare las dos listas en lugar de reiniciar hasta que algo funcione. Los servicios también pueden excluirse entre sí mediante dependencias, donde iniciar uno detiene otro, y el mismo patrón aparece en macOS con tareas launchd y un demonio compartido. Un cliente que arranca y sale en segundos informa de propiedad, no de configuración.

Lea el estado del servicio y su registro antes de leer el perfil. Un servicio que arrancó y se detuvo dentro del mismo minuto es el patrón que debe buscar, y su propio registro de eventos nombra la dependencia que lo desplazó. Un perfil no puede reparar un proceso que no se ejecuta, y el tiempo dedicado a editarlo es tiempo no dedicado al conflicto real.

Después pregunte quién posee el puerto

La propiedad del puerto es la evidencia más clara que obtendrá, porque un fallo de enlace nombra el conflicto directamente. Dos implementaciones IKE no pueden responder ambas en la misma dirección local y puerto UDP, y ninguna cantidad de reintentos lo cambia.

Get-NetUDPEndpoint -LocalPort 500,4500 | Select-Object LocalAddress,LocalPort,OwningProcess
netstat -ano | findstr :500
sudo lsof -nP -iUDP:500
ss -lunp | grep -E ':500|:4500'

Cualquiera que sea la línea que coincida con su plataforma, la respuesta que busca es un proceso y el servicio que lo creó. Si el oyente es el servicio IKE integrado, el segundo cliente es el intruso; si es un agente de proveedor, el cliente integrado lo es. Decida cuál puede arrancar al iniciar sesión y desactive el inicio automático del otro en lugar de matarlo en cada sesión.

El controlador de filtro está debajo de sus rutas

Un controlador de filtro de red intercepta el tráfico entre el adaptador y la pila de protocolos, así que puede reescribir o bloquear paquetes sin importar lo que diga la tabla de enrutamiento. Así se ignora una ruta que parece correcta, y por eso un ping exitoso puede convivir con un navegador que no carga nada.

Los componentes del proveedor también se enlazan a conexiones concretas. Un filtro heredado enlazado a un adaptador puede impedir que un perfil por lo demás correcto termine su handshake, y desenlazar ese componente de las propiedades del adaptador es más acotado y reversible que eliminar el producto por completo. Como el enlace es por conexión, compare los adaptadores en lugar de toda la pila.

Decida qué producto posee el arranque y anótelo

La coexistencia solo es realista cuando los dos clientes ocupan capas distintas por diseño, como una pila IPsec junto a un proxy que solo gestiona el tráfico de aplicaciones. Donde ambos quieren el mismo puerto, la misma capa de filtro o el derecho a publicar una ruta predeterminada, seguirán alternándose y cada fallo parecerá una avería nueva.

Elija al propietario deliberadamente. Las formas que sobreviven a un reinicio incluyen ejecutar el segundo cliente dentro de una máquina virtual, mantenerlo en hardware dedicado o estandarizar en un solo cliente que hable ambos protocolos. Desactivar el inicio automático y el servicio del perdedor es un cambio menor que reconstruir la tabla de enrutamiento tras cada arranque, y se revierte con una sola edición de configuración.