WireGuard AllowedIPs: la rotta che NetworkManager non ha mai aggiunto

Il contatore delle strette di mano si aggiorna, l’interfaccia conserva il suo indirizzo e un ping verso l’altro lato non arriva da nessuna parte. Questa combinazione confonde, perché una stretta di mano funzionante sembra la prova che il tunnel è pronto. Non lo è: un tunnel può essere completamente negoziato e non avere comunque alcuna rotta che vi indirizzi il traffico, e sono due compiti separati svolti da due pezzi di stato separati. La correzione dipende interamente da quale dei due manca, quindi il primo passo è scoprirlo.

wg-quick fa entrambe le cose senza che glielo si chieda. Il supporto WireGuard integrato in NetworkManager installa anch’esso le rotte dei peer per impostazione predefinita, il che restringe i sospetti a un’opzione disattivata, a un’altra tabella di routing o a una configurazione importata tramite qualcos’altro.

Confermate il tunnel prima di inseguire la rotta

wg show stampa l’interfaccia, il peer, l’endpoint e l’età dell’ultima stretta di mano, e ip addr show conferma che l’indirizzo è presente. Una stretta di mano recente significa che le chiavi, l’endpoint e il percorso UDP funzionano. Tutto ciò che è rotto sta a valle: routing, filtraggio o risoluzione dei nomi.

Poi chiedete al kernel cosa farebbe con una destinazione reale invece che ipotetica: ip route get 10.42.7.9. La risposta nomina l’interfaccia in uscita e l’indirizzo di origine che il pacchetto porterebbe. Quando nomina l’adattatore fisico, il pacchetto non entra mai nel tunnel, per quanto sana sembri la stretta di mano.

AllowedIPs è un filtro e un elenco di rotte

I prefissi in AllowedIPs svolgono due compiti. Scelgono quale peer trasporta una destinazione in uscita e convalidano l’indirizzo di origine dei pacchetti in entrata, che è il confine del routing a chiave crittografica. In wg-quick guidano anche l’installazione automatica delle rotte, e proprio questo comportamento aggiuntivo è il motivo per cui la stessa configurazione funziona da un terminale e non da un client desktop.

Nel caso dietro questo articolo, il profilo è stato importato tramite un plugin di terze parti anziché tramite il supporto integrato, e l’interfaccia è salita senza la rotta del prefisso. Elencare la tabella lo mostra subito: ip route show contiene solo la rotta connessa dell’indirizzo dell’interfaccia, e nulla per l’intervallo remoto.

Chiedete se le rotte dei peer sono attive

Leggete l’impostazione prima di modificare qualcosa: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Quando peer-routes mostra no, la riparazione supportata è nmcli connection modify work-wg wireguard.peer-routes yes, seguita da una riconnessione. Aggiungere invece una rotta statica funziona fino alla successiva attivazione e poi sparisce in silenzio. Quella sparizione è l’indizio: una rotta che torna come un mistero ogni mattina non è installata dal profilo.

Se l’opzione è già attiva, verificate se il prefisso vive in un’altra tabella con ip route show table all | grep 10. Una rotta in una tabella che non è quella principale non manca, è semplicemente invisibile a una ricerca che consulta solo la tabella principale. Correggete il routing delle politiche invece di impilare sopra una voce duplicata.

Aggiungete il prefisso alla connessione, non al sistema in esecuzione

Nell’editor delle connessioni, la pagina WireGuard contiene il peer e i suoi AllowedIPs, e la pagina IPv4 contiene rotte aggiuntive. Una rotta aggiunta lì sopravvive alle riconnessioni perché appartiene al profilo. Sulla riga di comando l’equivalente è aggiungere una rotta alla connessione nella forma con gateway vuoto, poi abbassare e rialzare la connessione perché la modifica venga applicata.

Scegliete il prefisso più stretto che copra gli host che vi servono. Copiare l’esempio /8 del fornitore può inghiottire intervalli locali che vi si trovano per caso, e i guasti che ne derivano sembrano un tunnel rotto più che una rotta troppo ampia.

Il tunnel diviso è deciso dall’elenco dei prefissi

Non esiste un interruttore per il tunnel diviso; l’elenco dei prefissi è la decisione. Un peer con un intervallo per la LAN dell’ufficio e uno per una rete di laboratorio invia esattamente quelle destinazioni attraverso il tunnel e lascia in pace tutto il resto. Un singolo host ha bisogno di un /32, e gli intervalli che si sovrappongono in due sedi hanno bisogno di prefissi host finché qualcuno non rinumera una sottorete.

Scegliere di non inviare nulla attraverso il tunnel porta la stessa decisione al suo limite: un elenco minimo mantiene il collegamento attivo mentre il traffico ordinario segue il suo percorso abituale. Scrivete l’intenzione, altrimenti il lettore successivo prenderà l’elenco breve per una svista e lo estenderà premurosamente.

Un solo proprietario per la tabella di routing

wg-quick e NetworkManager credono entrambi di possedere le rotte dell’interfaccia. Importate una configurazione scritta per wg-quick e poi avviate anche il servizio wg-quick, e ottenete voci duplicate o in conflitto il cui comportamento dipende da quale è stato eseguito per ultimo. Scegliete un solo proprietario e rimuovete l’altro: se NetworkManager gestisce la connessione, disattivate l’unità wg-quick per quell’interfaccia, e non aggiungete mai un secondo profilo per lo stesso dispositivo.

Quando la divisione deve seguire un adattatore fisico invece di una destinazione, siete passati al routing delle politiche, e anche il routing delle politiche richiede un solo autore. Verificate ripetendo ip route get, poi raggiungendo un host all’interno del prefisso remoto con qualcosa che stampi l’indirizzo di origine che ha scelto. Controllate IPv6 e DNS separatamente se il profilo porta l’uno o l’altro.