Handshake actiu, adreça perduda: tres estats de WireGuard
Un handshake recent demostra que el peer ha respost, no que la interfície conservi la seva adreça ni que el proper paquet surti per l'enllaç ascendent previst.
WireGuard pot tenir un handshake recent i cap adreça alhora, i aquest estat és coherent, no contradictori. El handshake és un esdeveniment del peer, l'adreça pertany a la interfície i la ruta decideix per quin enllaç ascendent surt un paquet. Tres capes, tres propietaris, i cadascuna pot fallar mentre les altres dues semblen sanes.
Llegir-les com un sol estat és el que converteix un diagnòstic de dos minuts en un matí sencer de reiniciar serveis.
El handshake és un esdeveniment del peer, no un esdeveniment d'adreçament
El handshake de WireGuard demostra que el peer configurat ha respost amb una clau vàlida i que les claus de sessió són actuals. No diu res sobre l'adreça local de la interfície, ni sobre si alguna ruta hi apunta. L'adreça l'assigna un assistent o un gestor de xarxa, mentre que la configuració del protocol només anomena peers i claus. Confondre les dues coses és com un handshake sa es llegeix com un túnel que funciona.
Per això wg show pot informar d'un handshake de fa segons en una interfície que no pot acceptar ni un paquet d'una aplicació.
Un gestor que recrea la interfície pot deixar caure l'adreça sense tocar la configuració del peer, i el següent handshake té èxit immediatament perquè les claus no han canviat mai. La línia del registre sobre un handshake correcte és exacta i irrelevant per a la fallada.
| 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 |
L'adreça de la interfície té el seu propi propietari
Una adreça al dispositiu de túnel pot venir de la línia Address d'un assistent, d'un client DHCP que s'executa a la interfície o d'un dimoni de gestió que la crea en connectar. Sigui quin sigui, aquell component posseeix l'adreça i la restaurarà o no segons la seva pròpia lògica. Llegir l'adreça sense anomenar-ne el propietari et deixa sense explicació de per què ha desaparegut.
Dos propietaris en una interfície és la fallada clàssica. Engegar un assistent i un gestor de xarxa d'escriptori sobre el mateix dispositiu produeix una cursa en què un elimina el que l'altre acaba de configurar, i el punt final continua responent durant tot el procés.
Tria un sol propietari i deixa que l'altra eina observi en lloc de gestionar. Val la pena anotar aquesta decisió, perquè el símptoma apareix setmanes després i sembla una pèrdua aleatòria d'adreça.
La ruta tria un enllaç ascendent, la interfície no
Una ruta interna que apunta a wg0 decideix que el trànsit entra al túnel. Una decisió separada envia els paquets externs xifrats cap al peer, i en un amfitrió amb diversos enllaços ascendents aquesta decisió ve de la taula d'encaminament i de les regles de política. Un roaming Wi-Fi pot canviar el camí extern sense tocar l'adreça interna.
Així, un túnel que funciona i un peer inabastable són estats compatibles, i també ho són un peer correcte i una ruta interna trencada. Les tres observacions s'han de prendre juntes, en el mateix moment, o la comparació no té sentit.
Compareu els tres estats en una sola passada
Tres ordres només de lectura responen les tres preguntes en l'ordre que aïlla la fallada més de pressa. Executeu-les sense canviar res entremig.
ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transferLa primera mostra si la interfície té cap adreça, i la segona mostra quin dispositiu faria servir ara una destinació concreta. La tercera informa de l'hora del darrer handshake i dels comptadors de bytes, i és l'única de les tres que descriu el peer i no l'amfitrió local.
Llegeix els comptadors i també la marca de temps. Un handshake que es refresca constantment mentre la transferència es queda plana vol dir que el peer respon però no hi passa res d'útil, cosa que apunta a l'encaminament o a una ACL i no a les claus. Una marca de temps que deixa d'avançar amb una adreça present apunta més amunt. Totes dues lectures surten de la mateixa línia de sortida, i cap no es veu si només comproves que existeixi un handshake.
Corregiu l'estat concret que està malament i després torneu a provar l'aplicació, no el túnel. Un handshake recent és evidència del peer, i l'evidència sobre el peer no és evidència que la propera petició del navegador trobarà una adreça, una ruta i un enllaç ascendent que funcioni. El manual de wg-quick diu explícitament quines d'aquestes coses munta l'assistent i quines pertanyen al protocol.