Leggere una configurazione WireGuard riga per riga, da Interface a Peer

La maggior parte delle configurazioni WireGuard rotte non sbaglia un valore; mette il valore giusto dalla parte sbagliata. Una chiave privata appartiene a questa macchina, un peer porta la chiave pubblica dell'altra macchina, e un indirizzo sta nel blocco interface anche se descrive dove vive il tunnel. Leggi il file come due direzioni che si incontrano, poi controlla cosa ha aggiunto sopra lo script di supporto. Il protocollo stesso ha meno campi del file, e i campi in più vale la pena conoscerli a parte.

Le chiavi di interface descrivono questa macchina

Il blocco interface contiene l'identità propria di questa estremità. PrivateKey è quell'identità e non lascia mai l'host; da essa deriva la chiave pubblica corrispondente ed è quella che gli altri peer elencano. ListenPort è dove questo lato riceve gli handshake, quindi due client dietro un solo indirizzo hanno bisogno di porte diverse.

Address è l'indirizzo del tunnel a cui risponde questo host, scritto con una lunghezza di prefisso perché è anche la sorgente che userà. Sbagliare il prefisso qui cambia quali destinazioni l'host crede collegate direttamente, e questo produce guasti che sembrano di instradamento e non di configurazione.

Tutto il resto in un [Interface] blocco con un client reale di solito lo aggiunge wg-quick: DNS, MTU, Table, e le righe di hook. Non sono campi del protocollo, e un'installazione wg nuda li ignora del tutto.

Ogni voce peer descrive un altro lato

Un [Peer] blocco è la parte remota. PublicKey è la chiave derivata di quella parte, mai la sua chiave privata, e PresharedKey è un segreto extra opzionale che entrambi i lati devono tenere identico. Endpoint è dove inviare, e PersistentKeepalive chiede a questo host di inviare un pacchetto dopo l'intervallo quando non esce nient'altro.

Due errori spiegano la maggior parte della confusione qui. Copiare la propria chiave privata in un blocco peer fa condividere un'identità ai due estremi, e l'handshake fallisce in un modo che viene registrato male. Lasciare Endpoint fuori su un client di solito è intenzionale, perché il server impara l'indirizzo dall'handshake in entrata; lasciarlo fuori su un server che deve iniziare non lo è. Ricorda anche che keepalive tiene aperta una mappatura NAT, e non migliora il throughput né riduce la latenza, quindi trenta secondi di pacchetti extra non comprano nulla quando il traffico scorre già.

AllowedIPs è instradamento, non una lista di permessi

AllowedIPs è l'instradamento a chiave crittografica di WireGuard. In uscita, decide quale peer riceve un pacchetto in base alla sua destinazione. In entrata, decide se un pacchetto che arriva da quel peer viene accettato in base alla sua sorgente. Lo stesso campo fa entrambi i lavori, per questo non è una lista di controllo degli accessi né una lista di siti consentiti.

Un AllowedIPs stretto sul server per un client significa che il server accetterà solo pacchetti che dichiarano quelle sorgenti e invierà solo quelle destinazioni a quel client. Allarga un lato senza allargare l'altro e ottieni un tunnel che sale e non passa nulla.

Cosa aggiunge wg-quick attorno al protocollo

wg-quick legge lo stesso file ed esegue i passaggi di rete che il protocollo lascia al sistema operativo. Assegna l'indirizzo dell'interfaccia, aggiunge rotte derivate da AllowedIPs, scrive le impostazioni del resolver ed esegue i comandi di hook in ordine.

Quello strato spiega l'asimmetria classica. Un file con 0.0.0.0/0 e una riga DNS dà al client una rotta predefinita e un resolver, e non fa assolutamente nulla alle regole di inoltro o NAT del server. Quelle appartengono alla configurazione del server stesso, e nessun file client può fornirle.

Mantieni un solo proprietario del file. Modificarlo a mano mentre SaveConfig è attivo significa che la tua modifica scompare la prossima volta che l'interfaccia scende, e l'interfaccia non ti dirà che è successo.

Controlla lo stato applicato, non il file

Il file è un'intenzione. Lo stato applicato è ciò che il kernel tiene, e divergono ogni volta che un aiutante, un drop-in o un hook ha modificato qualcosa dopo l'attivazione.

Leggi lo stato vivo e l'indirizzamento insieme, poi confronta entrambi con ciò che hai scritto:

sudo wg show
ip -4 addr show dev wg0
ip -4 route show dev wg0
grep -v "^#" /etc/wireguard/wg0.conf

Se la lista dei peer è vuota, l'interfaccia è stata creata senza che la sua configurazione fosse applicata. Se indirizzi e rotte esistono ma i contatori restano a zero, il file si è caricato e l'handshake fallisce, il che è un problema di chiave o di estremità e non di ordine delle sezioni. Confronta le due viste prima di modificare, perché lo scarto tra loro è di solito il guasto reale.