journalctl para los registros de VPN: ¿qué unidad posee la conexión?

Empiece por la unidad de systemd que realmente posee la conexión VPN, no por el comando de registro que recuerda. Un servicio de OpenVPN directo, una unidad de wg-quick y un perfil de NetworkManager colocan sus mensajes útiles en unidades distintas, y una consulta contra la equivocada produce un resultado vacío que parece silencio. Compare los tres propietarios habituales, acote la ventana y luego lea las etapas en orden.

Compare los tres propietarios habituales

Un servicio cliente de OpenVPN suele ser una unidad de instancia nombrada según el perfil, como [email protected]. Sus mensajes incluyen la ruta de la configuración, el análisis de las opciones, el apretón de manos TLS y la instalación de rutas que realiza el cliente.

Una unidad de wg-quick es más silenciosa por diseño. La configuración de la interfaz ocurre al arrancar, el apretón de manos lo gestiona el núcleo y las renovaciones rutinarias de claves no se registran de forma predeterminada, así que wg show suele ser más informativo que el registro. Esa diferencia importa cuando compara un protocolo que registra la negociación con uno que no lo hace.

NetworkManager posee los perfiles que ha creado, y sus mensajes viven bajo NetworkManager.service incluso cuando el complemento subyacente es un asistente de VPN. Consulte tanto el gestor como la unidad asistente cuando el perfil se administra de esa manera.

Acote la consulta a una unidad y una ventana

Consulte la unidad que identificó y limite el tiempo al intento que investiga. Un día suele bastar, y una ventana más corta es mejor cuando la máquina se reconecta a menudo.

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

Verifique el nombre instalado antes de confiar en la consulta. El empaquetado de la distribución renombra unidades, y un perfil que existe como archivo puede que nunca se haya habilitado como servicio. Si la unidad no existe, el registro vacío le habla del despliegue y no del túnel.

Lea la primera etapa fallida

Lea los eventos en el orden en que ocurren: búsqueda del punto final, transporte, identidad, autenticación, instalación de rutas y el fallo posterior de la aplicación. El primer fallo concreto es el que merece investigarse, porque todo lo que viene después es una consecuencia.

Un servicio que arranca correctamente no demuestra que todos los recursos necesarios sean accesibles. Un bucle de reconexión puede producir varias negociaciones separadas, así que guarde el nombre del perfil y la hora del intento junto a los eventos, y lea un intento en lugar de un flujo fusionado. Un solo intento es una secuencia con una causa, mientras que un flujo fusionado es un muro de líneas repetidas. Escriba el primer error en el ticket antes de seguir leyendo.

No mezcle un servicio fallido con un cliente manual

Si inició un cliente a mano después de que fallara el servicio, su salida va a otro sitio y su comportamiento puede diferir. Capture el resultado nuevo del mismo propietario y la misma solicitud tras una corrección admitida, para que la comparación muestre qué cambió en lugar de mezclar dos programas distintos.

No altere las marcas de tiempo originales para alinearlas con otro host. Anote la zona horaria y cualquier diferencia de reloj conocida por separado, porque una cronología que usted editó ya no es prueba.

Comparta un extracto, no una exportación

Las entradas del registro pueden contener nombres de usuario, direcciones de puntos finales, topología privada e información del entorno de scripts. Revise el extracto real y oculte lo que sea sensible en lugar de publicar una exportación completa sin restricciones. Cite las líneas que demuestran el fallo y resuma el resto. Un extracto breve y revisado es más fácil de aplicar que un archivo que nadie lee.

Envíe la ventana estrecha, el nombre de la unidad y la primera etapa fallida, y diga qué ha descartado ya. El manual de systemd journalctl documenta los selectores y las opciones de salida si necesita un formato que admita la versión de la distribución.