WireGuard funziona sui dati mobili ma non sulla stessa wifi

Il tunnel si alza con i dati mobili e poi resta su connessione a casa, con lo stesso profilo, la stessa chiave del peer e nessuna modifica di configurazione nel mezzo. La differenza sta nel viaggio: una richiesta da dentro la LAN verso l’indirizzo pubblico del router non è lo stesso viaggio di una richiesta che arriva da internet. La maggior parte dei gateway domestici o non implementa il percorso di ritorno o lo implementa solo per certi protocolli. Questo fa sembrare il sintomo una chiave rotta quando nulla della chiave si è mosso. Stabilite quale percorso ha fallito prima di toccare una chiave, un inoltro di porta o un profilo client.

Un indirizzo, due percorsi diversi

Dall’esterno, un pacchetto raggiunge l’indirizzo pubblico del router e una regola di inoltro di porta lo consegna al listener WireGuard sull’host interno. Dall’interno, il client compone lo stesso indirizzo pubblico, così il pacchetto lascia il client, arriva al router e deve essere girato di nuovo verso la LAN. È in quella girata che i due percorsi si separano, perché il router deve tradurre un flusso che esce e rientra sulla stessa interfaccia. Molte implementazioni lo scartano invece di tradurlo, e il client attende allora una stretta di mano che non è mai stata inviata.

Il comportamento viene di solito chiamato NAT loopback o hairpinning, e appartiene al router e non a WireGuard; RFC 4787 espone i casi di traduzione in cui un gateway può o non può supportarlo. WireGuard in sé non ha opinioni sul percorso, perché vede solo i pacchetti che raggiungono la sua interfaccia. Quando il router scarta il flusso, il demone non riceve nulla, il client segnala un timeout della stretta di mano e il registro del server resta vuoto. Un registro vuoto è quindi un indizio su dove si è fermato il pacchetto, non una prova che il server sia giù. È anche il motivo per cui reinstallare non cambia nulla.

Vale anche il contrario: un registro del server che mostra un tentativo di stretta di mano dall’indirizzo della LAN dimostra che il pacchetto è arrivato e che il percorso va bene, il che sposta l’indagine su chiavi e indirizzi consentiti. Leggete il registro per ciò che dimostra e non per ciò che speravate di vedere.

Riproducetelo prima di cambiare qualcosa

Provate da una rete esterna autorizzata con lo stesso dispositivo e lo stesso profilo, poi ripetete la prova dentro la LAN senza modificare nulla. Una stretta di mano completata fuori e un client che dentro non lascia mai il dispositivo riproducono la condizione invece di indovinarla. Entrambi i tentativi devono usare lo stesso profilo, altrimenti il confronto non dimostra nulla.

Poi guardate a cosa risolve il nome dell’endpoint per questo dispositivo. I tre comandi seguenti mostrano anche quale indirizzo il client ha davvero composto:

wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.net

Il primo comando riporta l’endpoint che l’interfaccia sta usando in questo momento, e gli altri due mostrano a cosa risolve il nome su questa macchina. Un client che compone un indirizzo pubblico mentre si trova sulla stessa rete del server sta esercitando il percorso hairpin. Un client che compone l’indirizzo della LAN non lo fa, e un guasto lì appartiene a un’altra indagine. Quella distinzione decide se la sezione seguente si applica davvero.

Modi supportati per raggiungere un server vicino

La soluzione più pulita è una risposta a orizzonte diviso: il nome pubblico risolve all’indirizzo pubblico per internet e all’indirizzo LAN del server per i client interni. Il profilo mantiene un solo nome di endpoint e il resolver sceglie il percorso. Serve il controllo della risposta DNS interna, che un router domestico di solito offre e un’organizzazione può predisporre di proposito. Senza quel controllo, le scelte rimaste sono una funzione del router o un secondo profilo.

La funzione del router è la riflessione: il gateway traduce il flusso da dentro a fuori e lo rimanda dentro. Dove funziona non serve alcuna modifica al client, e dove non funziona nessuna impostazione del client la salva. Provatela osservando il registro del server durante un tentativo interno invece di leggere l’elenco delle funzioni del router.

Modificare il profilo verso un indirizzo privato è una diagnosi, non un progetto. Dimostra che il server risponde sulla LAN, e rompe lo stesso profilo nel momento in cui il portatile esce di casa.

Mantenete il profilo utilizzabile fuori casa

Qualunque percorso scegliate, lasciate in pace il controllo d’identità. L’indirizzo dell’endpoint non è l’identità del peer, e un cambio di indirizzo non giustifica mai accettare una chiave pubblica estranea che per caso risponde. WireGuard autentica tramite chiave, quindi un host sbagliato fallisce la stretta di mano invece di concedere accesso a qualcosa di inatteso.

Se l’indirizzo pubblico si sposta, il DNS dinamico è ciò che mantiene utile il nome, e il comportamento di aggiornamento del client decide con che rapidità arriva il cambio. Provatelo dall’esterno dopo un cambio di indirizzo, perché il caso LAN non può convalidarlo. Fate attenzione a un resolver che mette in cache la risposta vecchia oltre la durata del record. Un nome che punta ancora all’indirizzo precedente sembra esattamente un server caduto.

Annotate quale nome usa il profilo e a cosa risolve su ciascun lato del confine. Un profilo che dipende da una funzione del router che nessuno ha registrato è una chiamata al supporto in attesa del prossimo aggiornamento del firmware. La nota è anche ciò che dice alla persona successiva se un guasto interno è il noto caso hairpin o qualcosa di nuovo.