L'handshake di WireGuard funziona, il servizio no

L'handshake si completa, il client mostra un contatore di trasferimento recente, eppure una richiesta a un servizio sullo stesso server fallisce. Questa combinazione confonde, perché il tunnel funziona in modo dimostrabile. Ciò che non è dimostrato è la consegna locale: il pacchetto ha raggiunto l'host, e l'host deve ancora accettarlo sul socket giusto e passarlo a un processo autorizzato a rispondere. Percorrere questi tre punti di controllo nell'ordine.

Fermarsi al primo che non vale, e non aggiungere regole per gli altri.

L'handshake dimostra solo il tunnel

L'handshake di WireGuard stabilisce chiavi tra pari e autorizza il traffico per gli intervalli elencati da ciascun pari. Non dice nulla su quali processi ascoltano sul server, né se il firewall dell'host accetta pacchetti indirizzati a uno dei suoi stessi indirizzi.

È proprio quest'ultima distinzione a essere trascurata più spesso: il traffico verso l'host stesso è input locale, mentre il traffico che attraversa l'host verso altrove è inoltro. Li gestiscono catene di firewall diverse e impostazioni diverse. Controllare la catena sbagliata costa un pomeriggio e restituisce contatori che sembrano innocui.

Leggere il listener e la rotta

Sul client, confermare che l'indirizzo del tunnel del server sia instradato nel tunnel. Sul server, confermare che esista un socket sull'indirizzo usato dal client e che il processo dietro sia quello previsto.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

Un listener su 127.0.0.1 non risponderà mai a una richiesta indirizzata a 10.66.0.1, qualunque cosa consenta il firewall. Un listener sull'indirizzo generico lo farà, a meno che una regola lo blocchi. L'elenco dei socket risolve quindi metà dei casi prima ancora di esaminare una regola. Porta e indirizzo insieme decidono se una richiesta può arrivare.

Confrontare l'indirizzo usato dal client con l'indirizzo che il server possiede davvero sull'interfaccia del tunnel. Una configurazione obsoleta su uno dei due lati produce una richiesta instradata correttamente verso un pari che non ha quell'indirizzo.

Applicare regole per l'input locale, non per l'inoltro

Se il pacchetto arriva e il socket esiste, il confine rimasto è la politica di input. Una regola che consente l'inoltro non consente la consegna locale, e una regola limitata a un'interfaccia può non corrispondere al nome dell'interfaccia del tunnel atteso.

Provare con un solo port consentito verso il servizio previsto invece di aprire l'host. Poi controllare l'autorizzazione dell'applicazione stessa: un elenco di consentiti, un requisito di account o un binding a un nome host specifico possono rifiutare una richiesta che la rete ha consegnato con successo.

Mantenere i controlli sui certificati. Un'identità di certificato inattesa è un'informazione su quale host ha risposto, non un ostacolo da aggirare. Cliccare oltre nasconde l'unico indizio che identifica il servizio sbagliato.

Separare i guasti di nome, dimensione e identità

Un servizio che funziona per indirizzo ma fallisce per nome è un problema DNS, e la correzione appartiene alla configurazione del resolver inviata al client, non al firewall. Un servizio che risponde a richieste piccole ma si blocca su risposte più grandi indica dimensione dei pacchetti e MTU, che è un'indagine del tutto diversa.

Un errore HTTPS che nomina l'host sbagliato di solito significa che la richiesta ha raggiunto un altro servizio, spesso perché un proxy o un altro listener possiede quella porta. Leggere il soggetto del certificato e confrontarlo con l'host che si voleva raggiungere. Questo confronto non costa nulla e spesso chiude l'indagine.

Annotare quale punto di controllo ha fallito: socket, regola di input o politica dell'applicazione. Quella singola riga distingue un guasto di rete da una decisione di autorizzazione. Impedisce anche alla persona successiva di aprire porte che non sono mai state il problema.