La stretta di mano di WireGuard riesce, ma non torna alcuna risposta

Le strette di mano recenti sono una buona notizia e un’affermazione molto più piccola della frase che si vorrebbe scrivere. I peer si sono scambiati messaggi di stretta di mano autenticati. Un pacchetto applicativo deve comunque raggiungere la sua destinazione interna e tornare.

Questo divario tra un piano di controllo sano e un piano dati silenzioso è l’intero argomento qui. Due letture degli stessi contatori vi dicono da quale lato vi trovate.

La stretta di mano dimostra le chiavi, non la consegna

La stretta di mano di WireGuard è un accordo di chiavi con autenticazione. Riesce appena i peer riescono a raggiungersi e hanno chiavi valide. L’instradamento, la politica del firewall e la destinazione stessa sono domande che la stretta di mano non pone mai.

Un tunnel può quindi essere perfettamente stabilito mentre ogni pacchetto al suo interno viene scartato. Un pacchetto interno instradato male e una risposta che prende un’altra strada sembrano uguali dal lato del client.

Un solo indirizzo interno è tutta la prova

Scegliete una destinazione e restateci. L’indirizzo di tunnel del peer stesso è il caso più semplice, e un host dietro il peer aggiunge esattamente un salto. Alternare tra i due senza annotare il cambiamento produce risultati che nessuno può confrontare.

Poi guardate la rotta che sceglie il client. Una rotta locale più specifica può mandare il pacchetto altrove prima ancora che WireGuard venga interrogato, e questo accade ogni volta che la LAN domestica si sovrappone all’intervallo remoto.

ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0

Un indirizzo che si risolve sull’interfaccia fisica ha già risposto alla domanda. Il tunnel non scarta nulla. Il pacchetto non vi è mai entrato.

I contatori sono prove, non un verdetto

wg show riporta i byte inviati e ricevuti per peer, e i due numeri si muovono in modo indipendente. Fate una lettura, eseguite una richiesta consentita, poi fate un’altra lettura nello stesso minuto.

wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer

Un invio che sale con ricezione piatta è la firma di una richiesta senza risposta. Non dice se la richiesta è stata filtrata, se la destinazione era spenta o se la risposta è uscita da un’altra rotta. Sono tre indagini che condividono un sintomo. Separatele prima di cambiare qualsiasi configurazione.

Nemmeno un numero fisso di byte è una soglia di successo. I valori dei contatori seguono il traffico, e trattare un solo numero come prova di salute produce assurdità piene di sicurezza.

Il peer controlla da sé il pacchetto di ritorno

Il peer remoto accetta un pacchetto interno solo quando l’origine cade nel suo allowedips. Una rotta presente sul mittente non basta. Una voce di origine mancante sul ricevitore scarta il traffico di ritorno in silenzio.

I firewall dell’host stanno dietro a quel controllo. Una regola di inoltro che permette l’interfaccia del tunnel ma non la sottorete interna accetta la stretta di mano e rifiuta il pacchetto. Dal lato del client sembra esattamente un peer morto. Un host con due interfacce può anche rispondere dall’origine sbagliata, e il peer scarta allora la risposta che non si aspettava.

Mantenete l’esperimento onesto

Provare un profilo di accesso remoto dalla stessa rete domestica che deve raggiungere esercita un percorso diverso da quello previsto. Passate alla rete esterna e annotatene il prefisso locale, così che le due esecuzioni possano essere confrontate.

Anche un piccolo scambio riuscito non esclude ogni problema di percorso. I pacchetti più grandi possono fallire dove passano quelli piccoli, e un filtro che corrisponde per dimensione o protocollo può comportarsi diversamente sotto carico.

Tenete la stretta di mano come la fase che si sa funzionante e procedete da lì. La prossima prova utile è dove si ferma una richiesta interna, non un nuovo set di chiavi e un altro giro di congetture.