Un par que deixa de pasar tráfico non perde por iso a súa chave, e un handshake novo non demostra que alguén renovase o permiso para usala. Os temporizadores de WireGuard manteñen as chaves frescas e os paquetes en movemento; non modelan un usuario que pecha a sesión tras un número fixo de minutos. Aquí confúndense tres preguntas, e cada unha ten probas distintas. A distinción decide que ferramenta se usa.

Tres preguntas, unha saída de orde

Os operadores preguntan se un par é alcanzable, se estivo activo e se aínda está permitido. A primeira é estado de protocolo, a segunda son contadores de tráfico e a terceira é autorización. Só as dúas primeiras poden lerse dunha interface de WireGuard, e empréganse habitualmente para responder ás tres.

QuestionEvidence it needsWhat does not answer it
Is the peer reachable now?A recent handshake and a working return pathAn interface that exists
Has it been active?Transfer counters moving over timeA handshake timestamp alone
Is access still granted?The configuration or controller that authorizes itAny protocol timer

Lea as filas como tres investigacións separadas. As dúas primeiras son baratas e poden responderse cos contadores da propia interface. A terceira necesita a configuración que concede o acceso, e esa vive noutro ficheiro ou noutro sistema. Escoller a fila equivocada é pedirlle a un temporizador de protocolo que faga o traballo dunha política.

Que gobernan realmente os temporizadores

O protocolo define constantes para o reintento do handshake, a rotación de chaves de transporte e o rexeitamento de paquetes protexidos por unha chave antiga. Responden ao tráfico e ao estado, non a un calendario nin a unha política que diga que unha persoa pode estar conectada ata as 17:00. Por iso un par inactivo pode parecer inactivo durante horas e seguir autorizado.

PersistentKeepalive adoita confundirse co tempo de espera que falta. Envía paquetes baleiros autenticados para manter viva unha asignación NAT, e poñelo a cero detén eses paquetes sen revogar nada.

Lea o estado en execución por par, usando a chave pública en lugar do comentario:

wg show wg0 latest-handshakes
wg show wg0 transfer

Un handshake recente di que se completou un handshake. Non di que o servizo privado detrás do túnel sexa alcanzable, e unha marca de tempo antiga pode pertencer a un par que simplemente cala.

Por que un par inactivo non é un par desconectado

WireGuard non ten un obxecto de sesión cun inicio e un final. Un par é unha chave pública con enderezos permitidos, e o handshake que protexe o seu tráfico substitúese cando é necesario sen ningún inicio de sesión visible para o usuario. Tratar a ausencia de tráfico recente como unha desconexión inverte o modelo.

Se a queixa real é que unha conexión falla despois de estar inactiva, a causa adoita estar noutro sitio: unha asignación NAT caducada, un dispositivo que durmiu ou un firewall que perdeu o estado. Probe enviando tráfico desde o outro lado e comezando un fluxo novo, e compare que cambia.

Pon o prazo onde vive a autorización

Se o acceso debe rematar a unha hora concreta, o prazo pertence ao que concede o acceso. Un controlador que emite configuracións de pares pode esixir unha aprobación renovada antes de entregar unha nova, e iso é unha propiedade do controlador e non un parámetro oculto na interface.

Para os pares xestionados a man, a eliminación ten que chegar a dous sitios: a interface en execución e a configuración gardada. Eliminar o par só en tempo de execución desfaino un reinicio ou un bucle de reconciliación, que restaura a identidade que vostede cría caducada:

sudo wg set wg0 peer <public-key> remove
sudo wg-quick save wg0

Despois probe o límite e non a etiqueta. Confirme que o par se rexeita após o prazo, que a ruta de renovación funciona e que o estado sobrevive a unha recarga do xestor. A idade dun handshake é un sinal operativo útil, e non é un rexistro de acceso.

Artigos relacionados