AllowedIPs è una lista di routing, non una regola del firewall

La maggior parte delle persone legge AllowedIPs come una lista di permessi, l'insieme degli indirizzi che possono connettersi a un peer, più o meno come una regola del firewall scritta per un tunnel. Non è così. Il campo è una tabella di routing che lavora in entrambe le direzioni: sceglie un peer per un pacchetto in uscita e convalida la sorgente di uno in entrata. Leggerlo come una lista di accesso produce configurazioni che instradano traffico che nessuno ha chiesto.

Un campo, due lettori: scelta in uscita e controllo della sorgente

Sul client i prefissi decidono quali destinazioni viaggiano verso quel peer e quali restano sulla rete ordinaria. Perciò una voce per 0.0.0.0/0 cattura ogni destinazione IPv4, ed è per questo che importare un profilo di tunnel completo manda la navigazione ordinaria attraverso la macchina remota. Le voci strette fanno il contrario: instradano solo le reti elencate e lasciano tutto il resto dov'era. La sezione sul routing delle chiavi crittografiche della documentazione WireGuard espone entrambi i compiti in un solo punto: la scelta del peer in uscita e la convalida della sorgente in entrata.

Sul server lo stesso campo descrive quali indirizzi di origine ogni peer può usare. È un controllo crittografico e non un filtro di pacchetti: un pacchetto la cui sorgente interna non corrisponde alla lista del peer viene scartato dentro WireGuard prima che qualsiasi firewall dell'host lo veda. I due compiti condividono un'unica lista, ed è esattamente per questo che una lista copiata altrove si comporta male in un punto che non avevi considerato.

Il blocco client è dove inizia la maggior parte di questa confusione. Un tunnel diviso nomina le reti remote, e un tunnel completo è lo stesso campo con un prefisso predefinito:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

Entrambe le forme sono complete da sole, e sono alternative anziché passi. La prima manda solo quelle due reti attraverso il tunnel; la seconda manda ogni destinazione, con la voce ::/0 che aggiunge IPv6 al valore predefinito IPv4. Qualunque scegliate, quei prefissi sono tutta la decisione di routing per quel peer quando wg-quick inizia a installare le rotte.

L'hub ha bisogno di un'altra lista

Un hub elenca l'indirizzo del tunnel di ogni client come prefisso host, più ogni rete realmente dietro quel client. Copiare la lista ampia di un client su ogni peer dell'hub dice all'hub che molti peer possono usare gli stessi indirizzi come sorgente, e questo non è un piano di indirizzamento. Il campo Endpoint appartiene a un altro livello del tutto: nomina l'indirizzo e la porta esterni del peer, mai una destinazione dentro il tunnel.

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

Il prefisso host porta l'indirizzo del tunnel e il prefisso di rete porta ciò che sta dietro il client, e servono entrambi. Senza il prefisso host l'hub non può restituire il traffico del client stesso, e senza il prefisso di rete la LAN dietro resta irraggiungibile; un peer senza nulla dietro riceve solo il prefisso host.

Saltare l'installazione delle rotte lascia un vuoto

wg-quick, l'assistente che alza un'interfaccia da un file di configurazione, installa indirizzi di interfaccia e rotte come parte di quel lavoro. Impostare Table = off dice all'assistente di saltare il lavoro sulle rotte, che non installa sostituti e non rende raggiungibile la rete privata. Quando le rotte automatiche fanno già il lavoro, nominare i prefissi necessari è la configurazione più chiara. Disattivare la gestione delle rotte e lasciare il sostituto non scritto non è un progetto, è un'omissione.

Lo strumento di base wg si comporta diversamente: configura l'interfaccia e non tocca mai le rotte, quindi un'installazione costruita direttamente su di esso richiede comandi di rotta propri. Istruzioni scritte per uno strumento possono sembrare sbagliate quando si seguono con l'altro. Un ping riuscito è anche una prova debole, perché esercita un solo percorso invece di ogni percorso applicativo che serve.

DNS e IPv6 si decidono separatamente

Controllate l'indirizzo del server DNS annunciato dal tunnel e confermate che esista una rotta verso quell'indirizzo attraverso i prefissi scelti. Un'impostazione del resolver non rende raggiungibile il resolver, e restringere un tunnel può rimuovere silenziosamente la rotta che vi arrivava. Ispezionate anche IPv6 per conto suo, perché una divisione IPv4 corretta non dice nulla su una rotta predefinita IPv6 che punta ancora al collegamento fisico. Tre decisioni separate possono cambiare insieme quando modificate un solo blocco peer.

Poi aprite una risorsa privata e un sito web ordinario da una configurazione iniziale nota. Se la risorsa risponde e la navigazione esce ancora dalla connessione locale, la divisione fa ciò che avete chiesto. Se la navigazione si rompe nello stesso momento, il tunnel ha preso la rotta predefinita e la lista dei prefissi è il punto da guardare.