O segundo cliente VPN rompeu o primeiro: atope o recurso compartido

Onte o cliente orixinal funcionaba. Hoxe o recén chegado reclama unha conexión mentres o perfil antigo detense nunha etapa que antes superaba sen queixa. As credenciais raramente están implicadas, e a pasarela adoita ser inocente. O que cambiou é que dúas pilas VPN queren agora o mesmo recurso exclusivo, e a reparación depende de nomealo. Percorra as capas en lugar de reinstalar os dous.

Percorra as catro capas en orde

Un produto VPN necesita catro recursos que poden chocar: un servizo en segundo plano que a miúdo se nega a executarse dúas veces, un porto fixo, un adaptador virtual ou filtro de núcleo que ve o tráfico antes que a táboa de enrutamento, e o dereito a instalar rutas por diante da predeterminada. Saber cal cedeu converte un conflito vago nunha única pregunta cunha resposta comprobable.

Asigne o síntoma a unha capa antes de tocar nada. Un cliente que non arrinca apunta ao servizo; un que arrinca e nunca negocia apunta ao porto; un que se conecta mentres o outro perde toda a conectividade apunta ao filtro ou á ruta predeterminada. Anote esa asignación, porque aforra unha hora de reinstalar aplicacións coa esperanza de acertar.

Comece polo servizo que non se executa dúas veces

En Windows un cliente corporativo adoita ser máis que un túnel, porque instala un servizo, un controlador de filtro e ás veces un provedor de credenciais xunto co perfil. Anote que servizos se executan antes do cambio e de novo despois, e logo compare as dúas listas en lugar de reiniciar ata que algo funcione. Os servizos tamén poden excluírse entre si mediante dependencias, onde iniciar un detén outro, e o mesmo patrón aparece en macOS con tarefas launchd e un daemon compartido. Un cliente que arrinca e sae en segundos informa de propiedade, non de configuración.

Lea o estado do servizo e o seu rexistro antes de ler o perfil. Un servizo que arrincou e detivo dentro do mesmo minuto é o patrón que hai que buscar, e o seu propio rexistro de eventos nomea a dependencia que o desprazou. Un perfil non pode reparar un proceso que non se executa, e o tempo dedicado a editalo é tempo non dedicado ao conflito real.

Despois pregunte quen posúe o porto

A propiedade do porto é a evidencia máis clara que obterá, porque un fallo de enlace nomea o conflito directamente. Dúas implementacións IKE non poden responder ambas na mesma dirección local e porto UDP, e ningunha cantidade de reintentos o 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'

Calquera que sexa a liña que coincida coa súa plataforma, a resposta que quere é un proceso e o servizo que o creou. Se o oínte é o servizo IKE integrado, o segundo cliente é o intruso; se é un axente de provedor, o cliente integrado é o intruso. Decida cal pode arrincar ao iniciar sesión e desactive o inicio automático do outro en lugar de matalo en cada sesión.

O controlador de filtro está debaixo das súas rutas

Un controlador de filtro de rede intercepta o tráfico entre o adaptador e a pila de protocolos, así que pode reescribir ou bloquear paquetes diga o que diga a táboa de enrutamento. Así se ignora unha ruta que parece correcta, e por iso un ping exitoso pode convivir cun navegador que non carga nada.

Os compoñentes do provedor tamén se enlazan a conexións concretas. Un filtro herdado enlazado a un adaptador pode impedir que un perfil por demais correcto remate o seu handshake, e desenlazar ese compoñente das propiedades do adaptador é máis estreito e reversible que eliminar o produto por completo. Como o enlace é por conexión, compare os adaptadores en lugar de toda a pila.

Decida que produto posúe o arrinque e anóteo

A coexistencia só é realista cando os dous clientes ocupan capas distintas por deseño, como unha pila IPsec xunto a un proxy que só xestiona o tráfico de aplicacións. Onde ambos queren o mesmo porto, a mesma capa de filtro ou o dereito a publicar unha ruta predeterminada, seguirán alternándose e cada fallo parecerá unha avaría nova.

Escolla o propietario deliberadamente. As formas que sobreviven a un reinicio inclúen executar o segundo cliente dentro dunha máquina virtual, mantelo en hardware dedicado ou estandarizar nun só cliente que fale ambos protocolos. Desactivar o inicio automático e o servizo do perdedor é un cambio menor que reconstruír a táboa de enrutamento tras cada arrinque, e revértese cunha soa edición de configuración.