Handshake sì, internet no: cosa correggere prima su Windows 11

Su Windows 11 capita spesso che handshake recenti convivano con browser che non aprono nulla. L’handshake dimostra solo che lo scambio UDP con il peer è terminato. Non dice nulla sulla rotta installata da Windows, sul resolver che usa, né su se l’uscita inoltra qualcosa.

Quattro condizioni decidono quale di questi livelli ha fallito. Percorrerle in ordine richiede minuti, mentre riscrivere le chiavi richiede più tempo e non cambia nulla.

Decidete il livello prima di toccare le chiavi

Percorrete tre destinazioni, in questo ordine. Iniziate da un indirizzo lato tunnel, poi un IP pubblico come numero, e chiudete con un nome host. Dove la sequenza si rompe, lì si nomina il livello. Un guasto al primo passo è instradamento, al secondo è inoltro o NAT, e al terzo è risoluzione dei nomi.

Quest’ordine è tutto il metodo. Impedisce che un guasto DNS venga diagnosticato come tunnel rotto, che è la deviazione sbagliata più comune qui.

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

Se il tempo dell’handshake è vuoto

Quando il tempo dell’handshake è vuoto, lo scambio cifrato non è mai terminato. Il guasto quindi si trova prima dell’instradamento. Guardate prima l’indirizzo dell’endpoint e la porta, poi se la rete filtra UDP. Un provider che scarta il traffico WireGuard produce esattamente questo, e così anche un client che ha copiato un endpoint da un vecchio profilo.

Byte che escono senza che ne entri nessuno sono un altro caso. Questo indica NAT o un firewall che restituisce il traffico nel posto sbagliato.

Se la rotta perde contro l’adattatore fisico

Per un tunnel completo la sezione del peer deve coprire le destinazioni che prevedete di usare. Windows a volte mantiene la rotta predefinita dell’adattatore fisico anche con una regola generale configurata. Dividere la regola generale in 0.0.0.0/1 più 128.0.0.0/1 crea due prefissi più specifici che vincono la ricerca. La divisione è una soluzione documentata, non una preferenza.

Confermatelo con route print o con una ricerca di un indirizzo pubblico. L’interfaccia scelta dovrebbe essere l’adattatore del tunnel. Se il fisico vince ancora, correggete gli intervalli del peer prima di toccare il server.

Se gli indirizzi funzionano e i nomi falliscono

WireGuard trasporta pacchetti IP e non ha opinioni sul DNS. Mettete una riga DNS = nella sezione dell’interfaccia, oppure configurate l’adattatore da Windows. Senza di essa un ping per indirizzo riesce mentre ogni nome host fallisce, e gli utenti lo segnalano come assenza di internet.

Verificate quali server Windows usa davvero dopo la connessione. Un resolver rimasto sull’adattatore fisico spiega un guasto parziale, in cui alcuni nomi si risolvono e altri no. Ripulitelo invece di aggiungerne un secondo sopra.

Se la macchina Windows è l’uscita

Internet Connection Sharing riscrive l’indirizzamento quando è attivo, il che può spostare l’adattatore condiviso su un altro intervallo. Un client che punta ancora all’indirizzo originale smette allora di funzionare. I valori di registro ScopeAddress e StandaloneDHCPAddress controllano quell’intervallo, e l’impostazione può tornare indietro dopo un riavvio.

Vale la pena guardare altri due conflitti specifici di Windows. Il servizio Routing and Remote Access può interferire con il tunnel. Un programma di installazione creato per l’architettura sbagliata fallisce con un messaggio che non menziona mai l’architettura.

Correggete il livello indicato dal test, poi ripetete le stesse tre destinazioni. Una modifica che ripara il test del nome host ma rompe l’indirizzo del tunnel è stata applicata al livello sbagliato.