Tunnel diviso di WireGuard: configurarlo senza route predefinita

Un tunnel diviso è definito da ciò che si lascia fuori, e WireGuard prende questa decisione in un solo campo. AllowedIPs sul peer del client seleziona insieme quali destinazioni passano nel tunnel e filtra quali indirizzi sorgente interni vengono accettati, e wg-quick trasforma lo stesso elenco in route dell'host. Se l'elenco è sbagliato, il tunnel o inghiotte tutto o non trasporta nulla.

Decidete prima l'elenco dei prefissi

Annotate le destinazioni che devono usare il tunnel prima di toccare un file di configurazione. Sottoreti dell'ufficio, un intervallo di database, una rete di gestione: ciascuno è un prefisso con un motivo. Tutto ciò che non è nell'elenco resta sul percorso fisico, ed è tutto il senso del progetto.

Se l'elenco contiene 0.0.0.0/0 o ::/0, avete costruito un tunnel completo e dovreste dirlo, perché le modalità di errore e le aspettative DNS sono diverse.

Tenete l'elenco abbastanza corto da permettere a un revisore di confrontarlo in seguito con la tabella di routing.

Configurazione del client: peer, AllowedIPs, DNS

Il blocco interfaccia del client contiene il proprio indirizzo di tunnel e la chiave privata. Il blocco peer contiene la chiave pubblica del server, l'endpoint e i prefissi del primo passo:

[Interface]
Address = 10.9.0.2/32
PrivateKey = <client-private-key>
DNS = 10.20.0.53

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/24
PersistentKeepalive = 25

AllowedIPs sul client è l'insieme delle destinazioni remote, non l'indirizzo del client stesso. La riga DNS ha effetto solo tramite l'integrazione del resolver di wg-quick, quindi un host senza supporto per resolvconf o systemd-resolved la ignorerà. PersistentKeepalive mantiene vivo un mapping NAT ed è inutile su un percorso diretto.

Commentate ogni prefisso con il servizio che serve, altrimenti la modifica successiva sarà un'indovinello.

Configurazione del server: il punto di vista opposto

Sul server, la voce peer rappresenta il client, quindi il suo AllowedIPs è l'indirizzo di tunnel del client, di solito un /32. Non è la sottorete dell'ufficio. Copiare l'elenco del client nella voce del server è l'errore più comune del tunnel diviso, e o allarga l'accesso o rompe il controllo della sorgente interna al momento della stretta di mano.

L'indirizzo di interfaccia del server e le route che gli servono verso l'ufficio sono separati da qualsiasi voce peer.

Due file, due punti di vista, un insieme di prefissi diviso tra loro.

Alzatelo e leggete le route

Avviate l'interfaccia con il gestore supportato, poi guardate cosa ha installato, non cosa intendevate. wg-quick deriva le route da AllowedIPs; se il profilo imposta Table = off, non viene installato nulla e il routing spetta a voi. Leggete la route di ogni prefisso e confermate che punta all'interfaccia WireGuard. Un elenco di route vuoto di solito significa che il profilo applicato non è quello che avete modificato.

Controllate anche i contatori della stretta di mano, perché un peer senza stretta di mano ha un problema di chiave, endpoint o raggiungibilità, non di routing.

Scrivete il comando esatto che avete usato, perché la persona successiva lo eseguirà sotto pressione.

Verificate entrambi i lati, poi annotate il rollback

Provate un indirizzo privato, il suo nome interno e una destinazione che deve restare diretta. Se l'indirizzo privato funziona e la destinazione diretta ora esce dal tunnel, l'elenco dei prefissi è troppo ampio. Se il nome fallisce mentre l'indirizzo funziona, la riga DNS non ha avuto effetto. Il rollback è un comando, e appartiene alla stessa nota.

Dopo una riconnessione, confermate che le route ci siano ancora, perché un gestore che riapplica il profilo può sostituire le route manuali.

Tenete un solo proprietario della configurazione, perché due gestori che producono la stessa interfaccia finiranno per litigare. Il manuale di wg-quick documenta il comportamento di route e DNS che offre.