Prefisso host di WireGuard: perché un indirizzo funziona e gli altri no

Il tunnel è attivo, l’handshake avviene ogni due minuti, ed esattamente un indirizzo dall’altra parte risponde. I ping all’indirizzo del tunnel del peer funzionano; nulla dietro di esso funziona. Qualcuno legge la configurazione dell’interfaccia, vede un prefisso host e conclude che la maschera è sbagliata. Allargarla a un /24 sistema il ping per un po’ e poi rompe qualcos’altro. Il prefisso non è mai stato il problema, e la rotta che mancava non è quella che la maschera controlla.

Cosa crea davvero il prefisso dell’interfaccia

Su Linux, assegnare un indirizzo a un’interfaccia crea una rotta connessa per quel prefisso. Se assegni un prefisso host, la rotta connessa copre un solo indirizzo. Se assegni un /24, ne copre 256, e ciascuno di essi viene ora considerato raggiungibile su quel collegamento.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Un prefisso host è una scelta del tutto normale per un tunnel punto a punto, perché c’è esattamente un peer dall’altra parte. Il terzo comando è quello che risponde alla domanda dell’utente: dice quale interfaccia il kernel userebbe per quella destinazione, e non mostrerà nulla di utile se nessuna rotta corrisponde.

È tutta la spiegazione del sintomo. Un indirizzo risponde perché esiste una rotta connessa per esso, o perché la lista consentita del peer per caso lo include. Tutto il resto non ha rotta e viene scartato prima che WireGuard sia coinvolto. Il tunnel è sano per tutto il tempo, ed è per questo che il contatore degli handshake continua a sembrare rassicurante.

AllowedIPs sono due regole con un solo nome

La lista consentita per peer di WireGuard svolge due compiti insieme, e la sintassi di configurazione li fa sembrare uno. In ingresso, autorizza quali indirizzi di origine un peer può presentare. In uscita, seleziona a quale peer viene inviato un pacchetto, trovando la corrispondenza più specifica.

Nessuno dei due compiti è routing. Il kernel deve comunque decidere che un pacchetto appartiene all’interfaccia del tunnel prima che WireGuard lo guardi, e quella decisione viene dalla tabella di routing. Una voce di peer con una lista consentita ampia non installa una rotta da sola.

Per questo una configurazione può sembrare completa e comportarsi in modo asimmetrico. Il client invia verso l’altro estremo perché esiste una rotta, e le risposte non arrivano mai perché la lista consentita dell’altro estremo non autorizza l’origine del client, o perché l’altro estremo non ha un percorso di ritorno. Entrambe le direzioni sono decisioni separate con modalità di errore separate. Annotare quale stai provando è metà della diagnosi.

Da dove viene la rotta

Se usi wg-quick, le rotte vengono generate per te dalla lista consentita di ogni peer, a meno che tu non abbia impostato Table = off e ti sia preso il controllo da solo. È il comportamento documentato dallo strumento, ed è il motivo per cui una configurazione senza direttive di rotta esplicite funziona comunque.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Confronta la lista consentita con le rotte effettivamente presenti. Un peer che consente un’intera sottorete ma ha prodotto solo una rotta host significa che l’helper non è mai stato eseguito, oppure che gestisci l’interfaccia direttamente con wg e ip, e in quel caso nulla genera rotte per te.

Quando la gestisci a mano, la rotta è una riga e la sua forma è esplicita: la destinazione attraverso l’interfaccia, senza gateway perché il collegamento è punto a punto. Aggiungerla non è un espediente per un prefisso sbagliato; è la metà mancante di un progetto che ha scelto di occuparsi del routing da sé.

Allargare il prefisso non aggiunge la voce del peer

La soluzione tentatrice è cambiare l’indirizzo in un /24 così che la rotta connessa copra la LAN del server. Sembra funzionare, e il motivo per cui sembra funzionare è che la rotta connessa ora corrisponde, non che WireGuard abbia imparato qualcosa di nuovo.

Quello che hai anche fatto è rivendicare l’intero intervallo come direttamente raggiungibile su quel collegamento, inclusi indirizzi che appartengono ad altri peer o a una LAN che in realtà sta dietro al server. Il traffico verso quegli indirizzi ora entra nel tunnel, e se ne esce dall’altra parte dipende dal routing e dalle liste consentite del server stesso.

Il lato crittografico non è influenzato in nessun caso. WireGuard ha ancora bisogno di una voce nella lista consentita che copra la destinazione per scegliere un peer, e l’altro estremo ha ancora bisogno di una voce che copra la tua origine per accettarla. Un prefisso di interfaccia più ampio non può fornire nessuna delle due.

Conferma entrambe le direzioni prima di cambiare qualcosa

Lavora i due estremi separatamente e annota ciò che dice ciascuno. Sul client la rotta e la voce del peer; sul server l’immagine speculare più il suo percorso di ritorno:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

La cattura è ciò che risolve le discussioni sulla direzione. Se i pacchetti in uscita compaiono sull’interfaccia del tunnel e il server non registra nulla, l’estremo remoto li sta rifiutando, di solito perché la tua origine è fuori dalla sua lista consentita. Se non compare nulla del tutto, la rotta manca o punta altrove.

Poi sistema l’estremo più stretto. Una voce nella lista consentita lato server per l’indirizzo del tuo client e una voce lato client per la sottorete di destinazione è la forma normale, e lascia in pace il prefisso dell’interfaccia. Allarga il prefisso solo se il piano degli indirizzi vuole davvero una sottorete condivisa su quel collegamento, e fallo come cambio di piano invece che come passo di debug.