Com construir una prova de WireGuard amb dos iguals que demostri un sol camí

Una prova de WireGuard que porta una ruta per defecte, un prefix LAN, DNS i una excepció de tallafocs no et pot dir quina d’aquestes peces s’ha trencat. Redueix-la a dos iguals, un parell d’adreces i un sol servei permès, i l’error no tindrà on amagar-se. La base avorrida és el diagnòstic. Construeix-la primer; triga quinze minuts i estalvia la tarda que d’altra manera passaries endevinant.

El que demostra la base és més estret del que la majoria de la gent espera. Demostra que dues identitats coincideixen, que l’UDP arriba al port d’escolta i que una destinació permesa porta una petició. El forwarding, el NAT, les rutes LAN i el DNS són funcions separades que s’afegeixen després, una a la vegada.

Claus, adreces i l’únic endpoint

Genera un parell de claus a cada sistema i mou entre ells només les meitats públiques. wg genkey | tee privatekey | wg pubkey > publickey és l’ordre documentada d’una sola línia, i deixa la clau privada en un fitxer que després pots protegir. Tria adreces de túnel d’un rang que no aparegui en cap altra configuració teva, com ara 10.99.0.1/24 i 10.99.0.2/24. Anota quina adreça pertany a quina màquina, perquè cada comprovació posterior depèn d’aquesta correspondència.

Les claus privades no viatgen mai. Si una prova necessita una clau copiada a l’altre costat, la prova ja ha anat malament. Quan els dos sistemes són darrere d’un NAT, almenys un necessita un port UDP abastable mentre l’altre porta un Endpoint que hi apunta, i l’adreça pública i el port pertanyen a les teves notes, no a les teves suposicions sobre el 51820.

Un reenviament de port que assigna un port extern diferent funciona bé sempre que l’Endpoint hi coincideixi. Les discrepàncies aquí produeixen silenci en lloc d’errors, i per això val la pena comprovar-les sobre paper abans de depurar sobre el cable.

Els camps que pertanyen a wg i els que no

El conjunt de camps bàsics és petit: PrivateKey i ListenPort sota Interface, PublicKey, AllowedIPs i Endpoint sota Peer. Address i DNS pertanyen a wg-quick i no a wg mateix, i aquesta distinció mossega en el moment que la mateixa configuració passa a una altra eina.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs porta dues feines alhora. Selecciona quines destinacions entren al túnel, i autoritza l’igual a utilitzar aquestes adreces d’origen a l’arribada. Per això l’entrada mirall de l’altre costat ha de nomenar exactament l’adreça del teu túnel; un /32 per a l’igual equivocat es llegeix com un problema d’encaminament i es comporta com un d’autorització. Inici ràpid de WireGuard mostra la mateixa forma de dos iguals amb la redacció canònica si vols comparar els noms dels camps.

Llegir l’handshake en lloc de la icona

Aixeca la interfície a través del que la posseeixi i després llegeix l’estat, no un llum d’estat. wg show imprimeix l’últim handshake de cada igual juntament amb els comptadors de bytes, i un handshake dels darrers minuts vol dir que les claus, l’endpoint i el camí UDP funcionen tots. Un comptador que només puja en una direcció és la seva pròpia resposta, i no és la mateixa fallada que un handshake que no passa mai.

Les dues fallades impliquen investigacions diferents. La manca total d’handshake apunta a una discrepància de claus, un Endpoint equivocat, UDP bloquejat o un tallafocs que descarta l’handshake mateix. Un handshake que té èxit mentre les dades no van enlloc apunta a AllowedIPs, un servei que no escolta a l’adreça del túnel o un tallafocs d’amfitrió que accepta el port per a la LAN però no per a la interfície del túnel. Són meitats diferents del sistema, i la base les separa abans que comencis a canviar regles.

Demostrar un servei permès i després el revers

Fes una petició a l’adreça de túnel de l’altre igual en un servei que ha de respondre, i tria alguna cosa millor que ping. Una resposta ICMP absent pot ser filtratge de l’amfitrió i no una fallada del túnel, així que un ping silenciós no demostra cap direcció. Una connexió TCP a un port que saps obert, o una petició que retorna dades, et dona una resposta que pots interpretar.

Executa la direcció inversa com una prova separada amb el seu propi resultat, perquè les dues direccions tenen entrades separades de tallafocs i AllowedIPs i poden fallar de manera independent. Si l’handshake funciona i la petició no, el problema és al camí de dades i no al túnel: AllowedIPs, el servei que escolta o un tallafocs de l’amfitrió. Arregla-ho abans d’afegir forwarding, NAT o DNS, o passaràs la tarda depurant una funció que mai no va ser la culpable.

Mantenir la base com a referència

Desa la topologia que funciona i la font del perfil en un lloc des d’on puguis restaurar-los, i mantén-los fora de qualsevol directori que se sincronitzi amb un servei públic. Després afegeix una funció a la vegada, repetint la petició original després de cadascuna: forwarding, NAT, una ruta LAN i només després DNS. Cada addició que trenca la prova ara és identificable, perquè res més no s’ha mogut.

Una base que només posa una icona verda no t’ha dit res sobre quina addició va causar la fallada següent. Mantén l’únic camí permès funcionant com a referència, i cada canvi posterior es mesura contra ell.