Handshake activo, dirección perdida: tres estados de WireGuard
Un handshake recente demostra que o par respondeu, non que a interface conserve o seu enderezo nin que o seguinte paquete tome a ligazón ascendente prevista.
WireGuard pode ter un handshake recente e ningún enderezo á vez, e ese estado é coherente, non contraditorio. O handshake é un evento do par, o enderezo pertence á interface e a ruta decide por que ligazón ascendente sae un paquete. Tres capas, tres donos, e cada unha pode fallar mentres as outras dúas parecen san.
Lelos como un só estado é o que converte un diagnóstico de dous minutos nunha tarde enteira de reiniciar servizos.
O handshake é un evento do par, non un evento de direccionamento
O handshake de WireGuard demostra que o par configurado respondeu cunha clave válida e que as claves de sesión están ao día. Non di nada sobre o enderezo local na interface, nin sobre se algunha ruta apunta alí. O enderezo asígnao un axudante ou un xestor de rede, mentres que a configuración do protocolo só nomea pares e claves. Confundir ambas as cousas é como un handshake san se le como un túnel que funciona.
Por iso wg show pode informar dun handshake de hai segundos nunha interface que non pode aceptar nin un paquete dunha aplicación.
Un xestor que recrea a interface pode perder o enderezo sen tocar a configuración do par, e o seguinte handshake ten éxito de inmediato porque as claves nunca cambiaron. A liña do rexistro sobre un handshake correcto é exacta e irrelevante para o fallo.
| Observation | Which layer it belongs to | Wrong conclusion it invites |
|---|---|---|
| Handshake a few seconds old | Peer and keys | The tunnel is usable for application traffic |
Address present on wg0 | Interface configuration | Traffic actually egresses through it |
Route points at wg0 | Forwarding table | The outer packet uses the intended uplink |
O enderezo da interface ten o seu propio dono
Un enderezo no dispositivo de túnel pode vir da liña Address dun axudante, dun cliente DHCP que se executa na interface ou dun demo de xestión que o crea ao conectar. Sexa cal sexa, ese compoñente posúe o enderezo e restaurarao ou non segundo a súa propia lóxica. Ler o enderezo sen nomear o seu dono déixache sen explicación de por que desapareceu.
Dous donos nunha interface é o fallo clásico. Arrancar un axudante e un xestor de rede de escritorio sobre o mesmo dispositivo produce unha carreira na que un elimina o que o outro acaba de configurar, e o extremo segue respondendo todo o tempo.
Escolle un só dono e deixa que a outra ferramenta observe en lugar de xestionar. Esa decisión merece anotarse, porque o síntoma aparece semanas despois e parece unha perda aleatoria de enderezo.
A ruta escolle unha ligazón ascendente, a interface non
Unha ruta interna que apunta a wg0 decide que o tráfico entra no túnel. Unha decisión aparte envía os paquetes externos cifrados cara ao par, e nun equipo con varias ligazóns ascendentes esa decisión vén da táboa de reenvío e das regras de política. Un roaming Wi-Fi pode cambiar o camiño externo sen tocar o enderezo interno.
Así, un túnel que funciona e un par inalcanzable son estados compatibles, e tamén o son un par correcto e unha ruta interna rota. As tres observacións deben tomarse xuntas, no mesmo momento, ou a comparación non ten sentido.
Compare os tres estados nunha soa pasada
Tres comandos de só lectura responden as tres preguntas na orde que illa o fallo máis rápido. Execúteos sen cambiar nada entre eles.
ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transferO primeiro mostra se a interface ten algunha dirección, e o segundo mostra que dispositivo usaría agora un destino concreto. O terceiro informa da hora do último handshake e dos contadores de bytes, e é o único dos tres que describe o par e non o equipo local.
Lea os contadores ademais da marca de tempo. Un handshake que se refresca continuamente mentres a transferencia segue plana significa que o par responde pero non pasa nada útil, o que apunta ao encamiñamento ou a unha ACL e non ás claves. Unha marca de tempo que deixa de avanzar cun enderezo presente apunta máis arriba. Ambas as lecturas saen da mesma liña de saída, e ningunha se ve se só comproba que exista un handshake.
Corrixa o estado concreto que está mal e logo volva probar a aplicación, non o túnel. Un handshake recente é evidencia do par, e a evidencia sobre o par non é evidencia de que a próxima petición do seu navegador atope un enderezo, unha ruta e unha ligazón ascendente que funcione. O manual de wg-quick di explicitamente cales desas cousas monta o axudante e cales pertencen ao protocolo.