journalctl para os rexistros de VPN: que unidade posúe a conexión?

Comece pola unidade de systemd que realmente posúe a conexión VPN, non polo comando de rexistro que recorda. Un servizo OpenVPN directo, unha unidade wg-quick e un perfil de NetworkManager colocan as súas mensaxes útiles en unidades distintas, e unha consulta contra a equivocada produce un resultado baleiro que parece silencio. Compare os tres propietarios habituais, restrinxa a xanela e logo lea as etapas en orde.

Compare os tres propietarios habituais

Un servizo cliente de OpenVPN adoita ser unha unidade de instancia nomeada segundo o perfil, como [email protected]. As súas mensaxes inclúen a ruta da configuración, a análise das opcións, o aperto de mans TLS e a instalación de rutas que realiza o cliente.

Unha unidade wg-quick é máis silenciosa por deseño. A configuración da interface ocorre no arranque, o aperto de mans xestiónao o núcleo e as renovacións rutineiras de claves non se rexistran por defecto, así que wg show adoita ser máis informativo ca o rexistro. Esa diferenza importa cando compara un protocolo que rexistra a negociación cun que non o fai.

NetworkManager posúe os perfís que creou, e as súas mensaxes viven baixo NetworkManager.service mesmo cando o complemento subxacente é un asistente de VPN. Consulte tanto o xestor como a unidade asistente cando o perfil se xestiona desa maneira.

Restrinxa a consulta a unha unidade e unha xanela

Consulte a unidade que identificou e limite o tempo ao intento que investiga. Un día adoita abondar, e unha xanela máis curta é mellor cando a máquina se reconecta a miúdo.

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

Verifique o nome instalado antes de confiar na consulta. O empaquetado da distribución renomea unidades, e un perfil que existe como ficheiro pode que nunca se habilitase como servizo. Se a unidade non existe, o rexistro baleiro fálalle do despregamento e non do túnel.

Lea a primeira etapa fallida

Lea os acontecementos na orde en que ocorren: procura do punto final, transporte, identidade, autenticación, instalación de rutas e o fallo posterior da aplicación. O primeiro fallo concreto é o que merece investigarse, porque todo o que vén despois é unha consecuencia.

Un servizo que arranca correctamente non demostra que todos os recursos necesarios sexan accesibles. Un bucle de reconexión pode producir varias negociacións separadas, así que garde o nome do perfil e a hora do intento xunto aos acontecementos, e lea un intento en lugar dun fluxo fusionado. Un só intento é unha secuencia cunha causa, mentres que un fluxo fusionado é un muro de liñas repetidas. Escriba o primeiro erro no ticket antes de seguir lendo.

Non mesture un servizo fallido cun cliente manual

Se iniciou un cliente a man despois de que fallase o servizo, a súa saída vai a outro sitio e o seu comportamento pode diferir. Capture o resultado novo do mesmo propietario e a mesma solicitude tras unha corrección admitida, para que a comparación mostre que cambiou en lugar de mesturar dous programas distintos.

Non altere as marcas de tempo orixinais para aliñalas con outro host. Anote a zona horaria e calquera diferenza de reloxo coñecida por separado, porque unha cronoloxía que vostede editou xa non é proba.

Comparta un extracto, non unha exportación

As entradas do rexistro poden conter nomes de usuario, enderezos de puntos finais, topoloxía privada e información da contorna de scripts. Revise o extracto real e oculte o que sexa sensible en lugar de publicar unha exportación completa sen restricións. Cite as liñas que demostran o fallo e resuma o resto. Un extracto breve e revisado é máis doado de aplicar ca un ficheiro que ninguén le.

Envíe a xanela estreita, o nome da unidade e a primeira etapa fallida, e diga que xa descartou. O manual de systemd journalctl documenta os selectores e as opcións de saída se necesita un formato que admita a versión da distribución.