Por qué una VPN puede parecer conectada cuando nada funciona

Su cliente informa conectado mientras la interfaz está levantada y el navegador agota el tiempo, y ninguna de esas tres afirmaciones es falsa. Conectado describe una capa que no tiene nada que ver con la página que solicitó. Decidir qué capa informa requiere una solicitud nueva y un vistazo al contador que demostraría que el tráfico se movió. Un reinicio tira esa evidencia y reconstruye las condiciones que intentaba observar.

Tres cosas diferentes llamadas conectado

Abajo del todo, conectado puede significar que un proceso de cliente se ejecuta y mantiene un socket hacia un par. Por encima, puede significar que existe una interfaz con una dirección, que un dispositivo persistente o una rutina de recuperación pueden crear sin sesión viva detrás. En el nivel de control, puede significar que se negoció una asociación, lo que no dice nada sobre si un solo paquete ha cruzado por debajo. Cada una sobrevive a fallos a los que las otras no sobreviven, y un cliente suele mostrar la más fuerte que puede reclamar.

Un icono verde y un túnel muerto son, por tanto, compatibles y no contradictorios; informan de objetos distintos. Esa es toda la razón por la que este fallo se diagnostica mal una y otra vez como un error del cliente.

Envíe una solicitud inocua a un destino que realmente necesite antes de tocar el demonio, y mantenga el bloque de tráfico directo requerido en su sitio mientras trabaja. Un reinicio borra el orden de los eventos y luego los recrea lo bastante cerca para ocultar la causa, y por eso el mismo ticket vuelve una semana después sin nada nuevo. Una solicitud, una lectura del contador y el desencadenante que produjo el fallo son la evidencia mínima.

Qué contador demuestra que los paquetes se movieron

En IPsec la asociación IKE y la asociación CHILD son objetos separados, y solo el child lleva los contadores que responden a esta pregunta. Liste el child, observe si los paquetes aumentan en ambas direcciones y compárelo con lo que la aplicación intenta hacer. Una asociación instalada a cero es un hallazgo distinto de una que aumenta mientras la aplicación sigue fallando; la primera significa que el tráfico no se selecciona, la segunda que se mueve y que el fallo está más adelante. Lea los contadores dos veces, con unos segundos de diferencia, porque una sola muestra no puede mostrar una tendencia.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Los contadores a cero apuntan a la selección: el enrutamiento, la política, un espacio de nombres del que salió el paquete o una interfaz a la que el cliente nunca se vinculó. Los contadores crecientes apuntan lejos del túnel, así que continúe con el reenvío en el extremo lejano, la resolución de nombres, el camino de vuelta y el servicio de destino, en ese orden. Un protocolo sin objeto child separado expone la misma evidencia en sus propios términos, así que use lo que informa sobre el estado del par y el recuento de paquetes en lugar de tomar prestado el vocabulario de IPsec. La forma de la lectura importa más que la herramienta que la produjo.

Dónde se sitúa el fallo después de que los contadores se muevan

Una puerta de enlace que responde en su propia dirección de gestión demuestra que la puerta funciona, no que algo detrás sirva su solicitud, así que pruebe el lado lejano y no la caja del medio. La resolución de nombres oculta los fallos mejor que nada, porque un resolutor al que no se puede llegar por el túnel agota el tiempo igual que una conexión muerta. Dos consultas separan esos casos, y ambas son baratas. Pregunte primero al resolutor que empuja el túnel y luego pregunte a un resolutor público por el mismo nombre.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Un nombre que se resuelve por el resolutor público pero no por el del túnel significa que la ruta DNS está rota, mientras que un nombre que se resuelve por ambos y aún agota el tiempo en el navegador apunta al camino de vuelta o al servicio. Si el ping por dirección tiene éxito y la aplicación sigue negándose, la red entregó la solicitud y el servicio la rechazó, lo que es una etapa mucho más tardía.

Registre el desencadenante y luego cambie una cosa

Registre qué precedió al fallo: un periodo de inactividad, un cambio de red, una renovación de clave, un portátil reanudado o un sistema restaurado. Producen mecanismos distintos, y normalmente solo el sistema restaurado se repara solo, que es justo el caso que no le enseña nada. Un reinicio elimina el orden de los eventos y luego recrea condiciones lo bastante cercanas para ocultar la causa. Escriba el desencadenante mientras aún es reproducible.

Después haga una corrección respaldada y repita la solicitud original junto con el desencadenante que produjo el fallo. La inactividad es el desencadenante más fácil de reproducir, así que es la confirmación más rápida de que la corrección abordó el mecanismo y no el síntoma.

Lo que quiere informar es la prueba de que el tráfico que pretendía enviar llegó al servicio al que pretendía llegar. Un icono que se pone verde, una página en caché que carga y un contador que se mueve demuestran todos menos que una solicitud completada contra el destino previsto. Mantenga juntos la solicitud, la lectura del contador y el desencadenante, para que la siguiente persona pueda distinguir una corrección de una coincidencia.