Come costruire un test WireGuard a due peer che dimostra un solo percorso

Un test WireGuard che trasporta una rotta predefinita, un prefisso LAN, DNS e un’eccezione del firewall non può dirti quale di questi si è rotto. Riducilo a due peer, una coppia di indirizzi e un solo servizio consentito, e il guasto non ha dove nascondersi. La base noiosa è la diagnosi. Costruiscila per prima; richiede quindici minuti e risparmia il pomeriggio che altrimenti passeresti a indovinare.

Ciò che la base dimostra è più stretto di quanto la maggior parte delle persone si aspetti. Dimostra che due identità concordano, che l’UDP raggiunge la porta in ascolto e che una destinazione consentita trasporta una richiesta. Il forwarding, il NAT, le rotte LAN e il DNS sono funzioni separate da aggiungere dopo, una alla volta.

Chiavi, indirizzi e l’unico endpoint

Genera una coppia di chiavi su ogni sistema e sposta tra loro solo le metà pubbliche. wg genkey | tee privatekey | wg pubkey > publickey è il comando documentato su una riga, e lascia la chiave privata in un file che poi puoi proteggere. Scegli indirizzi del tunnel da un intervallo che non compaia in nessun’altra configurazione che possiedi, come 10.99.0.1/24 e 10.99.0.2/24. Annota quale indirizzo appartiene a quale macchina, perché ogni controllo successivo dipende da quella mappatura.

Le chiavi private non viaggiano mai. Se un test ha bisogno che una venga copiata dall’altro lato, il test è già andato storto. Quando i due sistemi stanno dietro un NAT, almeno uno ha bisogno di una porta UDP raggiungibile mentre l’altro porta un Endpoint che punta lì, e l’indirizzo pubblico e la porta appartengono alle tue note, non alle tue supposizioni su 51820.

Un inoltro di porta che mappa una porta esterna diversa funziona bene finché l’Endpoint corrisponde. Le discrepanze qui producono silenzio invece di errori, ed è per questo che vale la pena verificarle sulla carta prima di fare debug sul cavo.

I campi che appartengono a wg e quelli che non vi appartengono

L’insieme dei campi fondamentali è piccolo: PrivateKey e ListenPort sotto Interface, PublicKey, AllowedIPs ed Endpoint sotto Peer. Address e DNS appartengono a wg-quick e non a wg stesso, e quella distinzione morde nel momento in cui la stessa configurazione passa a un altro strumento.

[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 due compiti insieme. Seleziona quali destinazioni entrano nel tunnel, e autorizza il peer a usare quegli indirizzi di origine all’arrivo. Per questo la voce speculare dall’altro lato deve nominare esattamente l’indirizzo del tuo tunnel; un /32 per il peer sbagliato si legge come un problema di routing e si comporta come un problema di autorizzazione. Il avvio rapido di WireGuard mostra la stessa forma a due peer con la formulazione canonica se vuoi confrontare i nomi dei campi.

Leggere l’handshake invece dell’icona

Alza l’interfaccia tramite ciò che la possiede, poi leggi lo stato invece di una spia. wg show stampa l’ultimo handshake per peer insieme ai contatori di byte, e un handshake negli ultimi minuti significa che chiavi, endpoint e percorso UDP funzionano tutti. Un contatore che sale solo in una direzione è la propria risposta, e non è lo stesso guasto di un handshake che non avviene mai.

I due guasti implicano indagini diverse. L’assenza totale di handshake punta a una discrepanza di chiavi, un Endpoint errato, UDP bloccato o un firewall che scarta l’handshake stesso. Un handshake che riesce mentre i dati non vanno da nessuna parte punta ad AllowedIPs, a un servizio che non ascolta sull’indirizzo del tunnel o a un firewall dell’host che accetta la porta per la LAN ma non per l’interfaccia del tunnel. Sono metà diverse del sistema, e la base le separa prima che tu inizi a cambiare regole.

Dimostrare un servizio consentito, poi il contrario

Fai una richiesta all’indirizzo del tunnel dell’altro peer su un servizio che deve rispondere, e scegli qualcosa di meglio di ping. Una risposta ICMP assente può essere filtraggio dell’host e non un guasto del tunnel, quindi un ping silenzioso non dimostra nessuna direzione. Una connessione TCP a una porta che sai aperta, o una richiesta che restituisce dati, ti dà una risposta che puoi interpretare.

Esegui la direzione inversa come test separato con il proprio risultato, perché le due direzioni hanno voci di firewall e AllowedIPs separate e possono fallire in modo indipendente. Se l’handshake funziona e la richiesta no, il problema è nel percorso dei dati e non nel tunnel: AllowedIPs, il servizio in ascolto o un firewall dell’host. Correggi questo prima di aggiungere forwarding, NAT o DNS, altrimenti passerai il pomeriggio a fare debug di una funzione che non era mai la colpevole.

Mantenere la base come riferimento

Salva la topologia funzionante e la fonte del profilo in un posto da cui puoi ripristinare, e tienile fuori da qualsiasi directory che si sincronizzi con un servizio pubblico. Poi aggiungi una funzione alla volta, ripetendo la richiesta originale dopo ciascuna: forwarding, NAT, una rotta LAN e solo dopo il DNS. Ogni aggiunta che rompe il test ora è identificabile, perché nient’altro si è mosso.

Una base che rende verde un’icona non ti ha detto nulla su quale aggiunta abbia causato il guasto successivo. Mantieni l’unico percorso consentito funzionante come riferimento, e ogni cambiamento successivo viene misurato su di esso.