WireGuard PersistentKeepalive: mantenere viva la mappatura NAT

La scatola di casa apre il tunnel e raggiunge il server cloud senza problemi. Il server cloud può raggiungere l’applicazione di casa per un minuto o due dopo che la scatola di casa ha inviato qualcosa l’ultima volta, e poi smette. Nel registro di WireGuard non appare nulla, non viene segnalato alcun errore di handshake, e riavviare il tunnel lo sistema per breve tempo. Quel modello è una mappatura che scade, non un tunnel rotto, e la guida qui sotto lo conferma prima di cambiare qualsiasi cosa.

Confermate che il modello è una scadenza per inattività

Il dettaglio che lo distingue è il tempismo. Se la connessione inversa funziona subito dopo che il peer di casa invia traffico e fallisce dopo un intervallo tranquillo, il percorso va bene e lo stato in mezzo no. Se non ha mai funzionato, anche subito dopo il traffico, questa è una diagnosi sbagliata.

sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transfer

Eseguite i primi due subito dopo che il peer di casa invia qualcosa, aspettate cinque minuti e rieseguiteli. Un timestamp di handshake che si rinnova come previsto senza un nuovo endpoint vi dice che il tunnel è vivo. Ciò che è cambiato è la capacità dei pacchetti non richiesti di arrivare dall’esterno, che è una proprietà del percorso e non del tunnel.

Poi fate un tentativo inverso e osservate i contatori di trasferimento. Se il lato cloud invia byte e il lato casa non ne riceve nessuno, il pacchetto ha lasciato il cloud ed è morto in un dispositivo con stato lungo il percorso. Questa è la firma che state cercando. Se entrambi i contatori si muovono, il tunnel ha consegnato il pacchetto e l’applicazione è il sospetto.

Mettete il keepalive sul peer dietro il router

I keepalive persistenti mantengono viva una mappatura NAT e qualsiasi stato del firewall inviando un piccolo pacchetto autenticato secondo una pianificazione. L’impostazione appartiene alla macchina dietro il router, nella sua voce per il peer remoto, perché è il lato il cui pacchetto in uscita crea lo stato.

[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25

Fondetelo nella sezione peer esistente. Aggiungere un secondo blocco con la stessa chiave pubblica non è un modo valido di aggiungere opzioni, e wg-quick non le fonderà per voi. I 25 secondi documentati sono un esempio scelto per stare sotto i timeout UDP comuni, non un valore con un significato speciale.

Mettere la stessa direttiva sul lato cloud non aiuta questo problema. I pacchetti di quel peer arrivano già da un indirizzo pubblico, quindi non c’è nessuna mappatura da preservare nella direzione che conta. Aggiunge traffico e non cambia nulla.

Leggete i timer invece di indovinare un intervallo

I keepalive funzionano perché arrivano più spesso di quanto lo stato scada. Questo rende il timeout il numero che vi serve davvero, e su Linux è leggibile sul dispositivo che fa la traduzione:

sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820

Il primo valore è il timeout per un flusso UDP visto solo in una direzione, e il secondo vale una volta osservate le risposte. Entrambi sono di solito brevi, e una mappatura che tace seguirà quello che vale per il vostro flusso.

Confrontate quel numero con il vostro intervallo. Un keepalive di 25 secondi sotto un timeout di 30 secondi funziona; lo stesso keepalive sotto un timeout di 15 secondi no. Nessuna quantità di tentativi cambia quell’aritmetica. Alcuni router domestici e operatori mobili usano valori molto più brevi del default di Linux, ed è per questo che una configurazione che funziona su una rete fallisce su un’altra.

Controllate l’ascoltatore e il firewall separatamente

Una mappatura viva è necessaria e non sufficiente. L’applicazione sulla scatola di casa deve ascoltare sull’indirizzo giusto, e il firewall dell’host deve permettere il pacchetto dopo la decifratura.

sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/health

Se il socket è legato solo all’indirizzo dell’interfaccia fisica e non all’indirizzo del tunnel, i pacchetti che arrivano sul tunnel vengono scartati prima ancora di consultare il firewall. Questo guasto, dal lato cloud, sembra identico a un problema di mappatura, e sopravvive a ogni regolazione del keepalive.

Il controllo della lista consentita è altrettanto importante nell’altra direzione. Il peer cloud deve consentire l’indirizzo del tunnel di casa come sorgente se deve rispondere, e il peer di casa deve consentire l’indirizzo cloud come destinazione. I pacchetti keepalive sono traffico autenticato e applicano le stesse regole, ed è per questo che un keepalive che sembra funzionare può convivere con un’applicazione che non funziona.

Distribuite la modifica e conoscetene i limiti

Applicate l’impostazione, riavviate l’interfaccia se è il vostro metodo di aggiornamento, e poi ripetete il test di inattività invece di quello immediato. Aspettate più del timeout che avete letto prima, fate una richiesta inversa e confermate che i contatori si sono mossi a entrambe le estremità.

Annotate l’intervallo e il timeout misurato accanto. Un futuro cambiamento del firmware del router, o un passaggio a una connessione mobile, può alterare il timeout. La nota è ciò che permette a qualcuno di ricavare di nuovo il valore invece di copiarlo. Due numeri su una riga risparmiano un’intera indagine più avanti.

I keepalive persistenti proteggono lo stato. Non aprono una porta, non aggiungono una voce alla lista consentita e non fanno comparire un ascoltatore. Quando la connessione inversa non funziona affatto, la colpa è una di queste tre, e l’avvio rapido di WireGuard descrive l’impostazione keepalive negli stessi termini ristretti.