WireGuard AllowedIPs: un campo che fa due mestieri (e perché il tuo è sbagliato)

Quasi tutti i problemi di configurazione di WireGuard che sopravvivono a un handshake riuscito si riducono a un solo campo, e al fatto che quasi nessuno lo legge correttamente. AllowedIPs sembra una direttiva di instradamento. Lo è, ed è anche altro allo stesso tempo.

Che cosa dice davvero il manuale

Il manuale di wg lo definisce in una frase che vale la pena leggere piano:

a comma-separated list of IP (v4 or v6) addresses with CIDR masks from which incoming traffic for this peer is allowed and to which outgoing traffic for this peer is directed

Due proposizioni, due mestieri diversi. Uscente: i pacchetti la cui destinazione cade in quella lista vengono inviati a quel peer. È la metà di instradamento, quella che tutti conoscono. Entrante: i pacchetti che arrivano da quel peer sono accettati solo se il loro indirizzo sorgente cade nella stessa lista. È una lista di controllo degli accessi, ed è la metà che viene ignorata.

È quello che WireGuard chiama cryptokey routing: l'associazione fra una chiave pubblica e un insieme di indirizzi costituisce l'intero modello di autorizzazione. Non esiste alcuna regola di firewall separata che decida quale peer possa rivendicare quale indirizzo.

La conseguenza che nessuno prevede

Metti AllowedIPs = 0.0.0.0/0 su un peer e non hai soltanto instradato tutto il traffico verso di lui. Hai anche dichiarato che quel peer può inviarti un pacchetto che dichiara qualunque indirizzo sorgente di internet, e la tua interfaccia lo accetterà.

Su un client il cui unico peer è il tuo stesso server, è esattamente ciò che vuoi ed è la normale configurazione a tunnel completo. Su un server con più peer, o su qualunque macchina dove un peer non sia pienamente fidato, è un buco aperto senza accorgersene.

Primo piano in bianco e nero di cassette postali metalliche numerate, con i numeri da 31 a 40 scritti a mano su piccole etichette. Ogni cassetta ha esattamente un numero e nessuno si ripete: è il vincolo che AllowedIPs impone tra i peer.

Perché due peer non possono mai condividere un intervallo

Poiché la lista decide a quale peer viene inviata una destinazione, uno stesso indirizzo non può appartenere a due peer insieme: la corrispondenza deve essere univoca. In pratica è per questo che lato server ogni client riceve il proprio /32 (o /128 in IPv6) invece dell'intera sottorete.

L'asimmetria sorprende. Sul client, AllowedIPs descrive che cosa vuoi raggiungere attraverso il tunnel, spesso tutto. Sul server, descrive chi quel peer preciso ha diritto di essere, di solito un solo indirizzo. Lo stesso campo, letto dai due capi, significa due cose diverse.

Il problema dell'esclusione della rete locale, e perché la sottrazione non esiste

La domanda reale più frequente è "come instradare tutto tranne la mia rete locale". Non esiste alcuna sintassi di sottrazione. 0.0.0.0/0 meno 192.168.1.0/24 non si può esprimere, perché il campo è una lista di intervalli e nulla più.

La risposta è enumerare il complemento: invece di un jolly, elenchi i blocchi CIDR che insieme coprono tutto lo spazio di indirizzamento tranne l'intervallo che vuoi tenere locale. È ingrato, produce una riga lunga, ed è l'unico modo corretto. I jolly stessi sono documentati senza ambiguità: 0.0.0.0/0 corrisponde a tutti gli indirizzi IPv4 e ::/0 a tutti gli IPv6.

Il sintomo che porta qui

Un handshake che si completa, e poi nulla. wg show mostra un handshake recente, i peer si sono chiaramente trovati, e non passa traffico. Quando l'handshake funziona, chiavi ed endpoint sono corretti per definizione: il problema è a valle, e AllowedIPs è il primo posto dove guardare. O la destinazione non è in lista dal lato che invia, o la sorgente non è accettata dal lato che riceve.

Se è l'handshake stesso a non completarsi mai, la diagnosi è tutt'altra e la nostra guida alla risoluzione dei problemi di handshake la copre. E se i pacchetti circolano ma le pagine si bloccano a metà, probabilmente hai un problema di MTU e non con questo campo.

Da non confondere con PersistentKeepalive

Si confondono perché entrambi compaiono nella sezione del peer ed entrambi sembrano riguardare il "tenere viva la connessione". Non hanno alcun rapporto. Il manuale descrive PersistentKeepalive come un intervallo, fra 1 e 65535 secondi, che regola ogni quanto viene inviato al peer un pacchetto vuoto autenticato, allo scopo di mantenere valida una voce di firewall con stato o di NAT. È disattivato per impostazione predefinita, e il manuale aggiunge che la maggior parte degli utenti non ne avrà bisogno.

AllowedIPs decide che cosa è permesso. PersistentKeepalive decide ogni quanto bussi perché una scatola NAT non dimentichi che esisti.

Farlo giusto al primo colpo

Imposta le voci di peer lato server su un indirizzo per client e nulla più. Imposta il client sugli intervalli che vuoi davvero raggiungere: i jolly per un tunnel completo, le sottoreti precise per un tunnel diviso. Rileggi ogni riga AllowedIPs due volte: una come rotta, una come lista di invitati. I nostri modelli di configurazione pronti all'uso applicano questa separazione.

Il campo è piccolo, accetta quasi tutto ciò che scrivi, e fallisce in silenzio quando è sbagliato. È questa combinazione a meritargli più attenzione di quanta ne riceva di solito.

★ Datacenter GDPR di Norimberga · ✓ IPv4 dedicato incluso · 200+ Mbps garantiti

Ospita la tua VPN sul tuo VPS → ContaboAccesso root completo · IPv4 pubblico · scegli la tua regione→

Domande frequenti

A che cosa serve AllowedIPs in WireGuard?

Fa due cose insieme. Il manuale di wg lo definisce come la lista degli indirizzi da cui il traffico entrante di quel peer è consentito, e verso cui il traffico uscente destinato a quel peer viene diretto. È quindi al tempo stesso una regola di instradamento per ciò che invii e una lista di controllo degli accessi per ciò che accetti. La maggior parte degli errori nasce dal leggere solo la prima metà.

Perché il mio handshake riesce ma non passa traffico?

Perché l'handshake dimostra solo che chiavi ed endpoint sono corretti. Che cosa succede ai pacchetti dopo lo decide AllowedIPs. O la destinazione che cerchi di raggiungere non è elencata dal lato che invia e nulla entra nel tunnel, o l'indirizzo sorgente non è elencato dal lato che riceve e il pacchetto viene scartato all'arrivo.

Due peer possono avere lo stesso AllowedIPs?

No, e la ragione è strutturale, non una regola di ordine. Poiché la lista decide a quale peer viene inviata una data destinazione, un indirizzo appartenente a due peer renderebbe la scelta ambigua. Per questo ogni client riceve normalmente il proprio /32 lato server invece dell'intera sottorete.

Come escludo la mia rete locale dal tunnel?

Enumerando il complemento, perché il campo non ha sintassi di sottrazione. Invece di un jolly, elenchi i blocchi CIDR che insieme coprono tutto lo spazio di indirizzamento tranne l'intervallo da tenere locale. Il risultato è una riga lunga ed è l'unico modo corretto di esprimerlo.

Che differenza c'è fra AllowedIPs e PersistentKeepalive?

Risolvono problemi senza rapporto. AllowedIPs decide quale traffico è permesso in ciascun senso. PersistentKeepalive è un intervallo, fra 1 e 65535 secondi, che regola ogni quanto viene inviato un pacchetto vuoto autenticato perché una voce di firewall con stato o di NAT resti valida. È disattivato per impostazione predefinita e il manuale nota che la maggior parte degli utenti non ne avrà bisogno.