Configurare in modo sicuro la VPN WireGuard per gli amministratori di sistema

Una rete di manutenzione anziché porte di amministrazione aperte al pubblico

Le porte di amministrazione accessibili pubblicamente aumentano la superficie di attacco di un server: i tentativi di accesso SSH, le configurazioni errate delle interfacce di amministrazione e i servizi di monitoraggio esposti accidentalmente sono raggiungibili direttamente da reti esterne. Un accesso tramite WireGuard riduce questa visibilità, poiché inizialmente deve rimanere accessibile solo una porta UDP definita per il tunnel crittografato. Tuttavia, WireGuard non maschera il traffico come HTTPS e non offre una modalità di trasporto TCP.

Il modello di riferimento ideale per l'amministrazione di una VPN è solitamente una rete hub-and-spoke: il server gestisce l'interfaccia wg0 e riceve, ad esempio, l'indirizzo interno 10.77.0.1. Il portatile di un utente autorizzato si connette come peer autonomo e utilizza, ad esempio, l'indirizzo 10.77.0.10. SSH, una console web interna o gli endpoint di monitoraggio accettano quindi gli accessi tramite la rete tunnel anziché tramite l'indirizzo pubblico del server.

Non si tratta di una VPN per utenti finali, destinata a reindirizzare l’intero traffico web di un dispositivo. Per la manutenzione è più opportuno un modello di accesso ristretto: il tunnel funge solo da percorso verso destinazioni di gestione chiaramente definite. Sebbene sia possibile utilizzare consapevolmente un tunnel completo, questo modifica anche il routing, l’utilizzo del DNS e l’accessibilità dei servizi esterni. Questi effetti collaterali non sono solitamente necessari per un accesso destinato esclusivamente alla manutenzione.

Il sito Rete di manutenzione È esclusivamente un limite di rete. Non determina quale account Linux possa effettuare l'accesso, quali comandi tale account possa eseguire o se il sistema operativo sia aggiornato. Inoltre, sono necessarie chiavi SSH e account personali, diritti sudo adeguatamente limitati, regole del firewall, aggiornamenti di sicurezza, registrazione degli eventi e un accesso di emergenza ben gestito. In questo modo, un errore in un singolo livello di protezione non sarà l’unico fattore determinante per l’accesso.

Classificare correttamente chiavi, peer e indirizzi IP consentiti

Ogni peer WireGuard dispone di una propria coppia di chiavi. La chiave privata rimane esclusivamente sul server, sul laptop o sul dispositivo di gestione associato; sul lato remoto viene memorizzata solo la chiave pubblica derivata da essa. Una chiave pre-condivisa (PresharedKey) opzionale integra la crittografia a chiave pubblica con un ulteriore materiale di chiave simmetrico. Si tratta di un livello aggiuntivo, ma non sostituisce né le chiavi private né una gestione delle chiavi tracciabile.

Metti un Peer per dispositivo anziché un peer comune per un team. In questo modo è possibile rimuovere in modo mirato una workstation smarrita o un dispositivo di un fornitore di servizi non più necessario. Le chiavi WireGuard consentono l’accesso alla rete di manutenzione. Indipendentemente da ciò, le chiavi SSH autenticano una persona o un dispositivo nei confronti del servizio SSH; pertanto, la revoca deve essere pianificata su entrambi i livelli.

Particolarmente importanti sono i Indirizzi IP consentiti sul server. In WireGuard costituiscono una tabella di routing delle chiavi crittografiche: per i pacchetti in uscita, determinano il peer appropriato in base all’indirizzo di destinazione. Per i pacchetti in entrata già autenticati, limitano al contempo gli indirizzi di origine interni che tale peer è autorizzato a utilizzare. L’impostazione è quindi più di una semplice specificazione di percorso.

Se al portatile dell'amministratore viene assegnato l'indirizzo 10.77.0.10, sul server deve essere presente, proprio per quel peer, AllowedIPs = 10.77.0.10/32. L'assegnazione /32 associa un singolo indirizzo di tunnel a questo peer. Se assegnassi in modo generico 10.77.0.0/24 a ogni peer di amministrazione, tale associazione risulterebbe poco chiara e la configurazione diventerebbe inutilmente generica. Verifica inoltre che la rete VPN scelta non entri in conflitto né con le reti di sede, né con quelle dei container, né con le reti domestiche.

Pianificazione dei confini della rete e del modello di accesso

Pianifica la rete di indirizzi VPN prima dell’installazione. Scegli un intervallo privato che non si sovrapponga né alle LAN esistenti, né alle reti cloud, né alle reti Docker o Kubernetes, né alle reti domestiche di uso comune. Stabilisci quali sistemi devono essere accessibili tramite il tunnel: solo il server gateway, una rete di gestione circoscritta o singoli servizi. Da ciò deriveranno in seguito i percorsi client, le regole del firewall e, se necessario, i percorsi di ritorno.

Per ogni dispositivo, documenta l’utente responsabile, la chiave pubblica WireGuard, l’IP fisso del tunnel, lo scopo dell’autorizzazione e la procedura di revoca. I gruppi dovrebbero essere definiti in base alle mansioni, ad esempio gestione operativa, gestione del database o assistenza esterna, e non in base a un generico „la VPN può fare tutto“. Conserva inoltre un accesso di emergenza indipendente, ad esempio una console del provider. Verificalo prima di apportare modifiche al firewall, a SSH o al routing, in modo che una regola errata non causi l’esclusione dall’accesso.

Il sito Firewall è il filtro di rete primario: consente l'accesso alla porta UDP di WireGuard sull'interfaccia pubblica, ma accetta connessioni SSH esclusivamente tramite l'interfaccia di ingresso wg0 ovvero l'interfaccia WireGuard effettivamente utilizzata. Un ulteriore controllo della rete di origine della VPN può restringere ulteriormente la regola, ma non deve sostituire il vincolo all'interfaccia. In questo modo, il firewall non accetta pacchetti in arrivo sull'interfaccia pubblica solo sulla base di un presunto indirizzo di origine VPN. WireGuard associa gli indirizzi interni autenticati ai peer; questa garanzia si applica ai pacchetti accettati tramite l’interfaccia del tunnel.

A livello di SSH si aggiungono le chiavi al posto dell'accesso tramite password, account personali e regole sudo il più possibile limitate. OpenSSH può essere configurato con AllowUsers Collegare gli account anche a indirizzi di origine o reti CIDR. Questa seconda barriera integra quella prevista in wg0 regola del firewall associata, ma non la sostituisce.

Le applicazioni web pubbliche continuano a richiedere una propria protezione del trasporto tramite HTTPS e certificati adeguati. Guida alla protezione TLS di un sito web Questo livello gestisce gli accessi tramite browser. WireGuard, invece, protegge l'accesso alla rete amministrativa privata; non sostituisce né il protocollo TLS per i servizi pubblici, né le relative procedure di autenticazione, verifica dei diritti e manutenzione.

Struttura di base con wg-quick senza trappole di routing

Per un singolo server di manutenzione è sufficiente uno scenario punto-punto ristretto: il server gestisce wg0 con l'indirizzo del tunnel 10.77.0.1/24, il portatile dell'amministrazione riceve in modo permanente 10.77.0.10/32. Il server pubblico accetta solo UDP per WireGuard. I seguenti file costituiscono una proposta di configurazione per wg-quick; sono state volutamente create senza chiavi reali.

Sul server, un peer associa la chiave pubblica del portatile proprio al suo indirizzo di tunnel. La chiave privata del server rimane esclusivamente nel file locale. Salva la configurazione, ad esempio, in /etc/wireguard/wg0.conf e limitare l'accesso in lettura al contesto amministrativo, poiché in esso è contenuta una chiave segreta. Le chiavi pubbliche, invece, sono destinate alla rispettiva controparte.

[Interface]
Address = 10.77.0.1/24
ListenPort = <UDP_PORT>
PrivateKey = <SERVER_PRIVATE_KEY>

[Peer]
# Administrations-Laptop Person A
PublicKey = <ADMIN_A_PUBLIC_KEY>
AllowedIPs = 10.77.0.10/32

Sul portatile si fa riferimento a Endpoint all'indirizzo pubblico del server e alla porta UDP selezionata. Per la semplice manutenzione del server, come client è necessario Indirizzi IP consentiti di solito solo 10.77.0.1/32 necessario. In questo modo, solo il traffico diretto all’indirizzo VPN del server viene instradato nel tunnel; gli accessi a Internet dal portatile mantengono il loro percorso abituale.

[Interface]
Address = 10.77.0.10/32
PrivateKey = <ADMIN_A_PRIVATE_KEY>

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = <SERVER_PUBLIC_ADDRESS>:<UDP_PORT>
AllowedIPs = 10.77.0.1/32
PersistentKeepalive = <ONLY_IF_NEEDED>

L'indicazione 0.0.0.0/0 Sul client, invece, una rotta predefinita IPv4 attraverso il tunnel significa: una Tunnel completo. wg-quick deriva le rotte dagli AllowedIPs e gestisce le rotte predefinite con una logica aggiuntiva di policy routing. Ciò è possibile per un accesso progettato appositamente in questo modo, ma, tra le altre cose, modifica il traffico dati esterno e può far emergere problemi relativi al DNS o alla raggiungibilità.

L'esempio riguarda esclusivamente l'IPv4. Se il server dispone di connettività IPv6 pubblica, anche in quel caso la porta TCP 22 deve essere espressamente bloccata dal firewall IPv6 oppure il servizio SSH deve essere associato in modo appropriato. Un'autorizzazione IPv4 chiusa non protegge da un listener IPv6 che rimane accessibile pubblicamente. Pianifica separatamente gli indirizzi dei tunnel IPv6 e i prefissi lato client; ::/0 si tratterebbe quindi di un percorso predefinito per IPv6 e non di un’integrazione neutra della configurazione IPv4.

Attiva innanzitutto il tunnel, verifica la connessione all’indirizzo VPN e accedi tramite SSH in una seconda sessione. Solo quando questo metodo funziona in modo affidabile ed è disponibile un accesso indipendente tramite console o modalità di ripristino, dovresti rimuovere l’autorizzazione SSH pubblica. Verifica sia l’IPv4 che, se del caso, l’IPv6. Le chiavi private non devono essere inserite né nei ticket, né nei log delle chat, né nel sistema di controllo delle versioni.

Confronto tra modelli di routing e regole del firewall

Il firewall applica il modello di accesso desiderato. Sull'interfaccia pubblica è consentito accettare la porta UDP di WireGuard specificata; la porta TCP 22, invece, non deve rimanere aperta come accesso amministrativo generico. SSH viene invece abilitato solo per i pacchetti la cui interfaccia di ingresso wg0 ovvero l'interfaccia WireGuard utilizzata. Un controllo supplementare della rete di origine può limitare ulteriormente l'ambito VPN consentito, ma una regola basata esclusivamente sull'indirizzo di origine non è sufficiente.

Il collegamento all'interfaccia di ingresso impedisce che un pacchetto in arrivo sull'interfaccia pubblica soddisfi i criteri di autorizzazione SSH solo a causa di un indirizzo di origine falsificato proveniente dall'area VPN. L'assegnazione crittografica di WireGuard tra peer e indirizzo interno si applica ai pacchetti autenticati sull'interfaccia del tunnel. La sintassi specifica del firewall deve essere compatibile con il software utilizzato e tenere conto in modo univoco sia dell'interfaccia che della famiglia di indirizzi.

Prendi espressamente in considerazione la connettività IPv6 pubblica. Se si rimuove solo l'autorizzazione IPv4 per la porta TCP 22, SSH potrebbe rimanere accessibile da Internet tramite IPv6. Blocca quindi la porta anche nelle regole IPv6 oppure configura il servizio SSH in modo che non sia in ascolto su un indirizzo IPv6 pubblico. Le regole IPv4 e IPv6 devono essere verificate separatamente.

Nel caso di un firewall a stato, non è sufficiente considerare solo il percorso di andata desiderato. Anche i pacchetti di risposta di una connessione autorizzata devono raggiungere il client; in caso di accessi dietro un gateway, si aggiunge anche il percorso di ritorno dalla rete di destinazione. Un'autorizzazione generica dell'intera sottorete VPN a tutti i servizi trasforma inutilmente la rete di manutenzione in una rete di accesso interna eccessivamente ampia.

Per la manutenzione di un singolo server, il primo modello è quello più chiaro. Il percorso client verso 10.77.0.1/32 È sufficiente, e il firewall può accettare il protocollo SSH esclusivamente per i pacchetti in arrivo tramite l'interfaccia WireGuard. La porta UDP rimane visibile dall'esterno, ma senza la chiave peer corrispondente non è possibile ottenere alcun accesso amministrativo.

Il secondo modello richiede una netta separazione: il server VPN non è quindi solo un punto terminale, ma anche un router. Il firewall dovrebbe consentire, ad esempio, il traffico SSH verso server di gestione definiti e il traffico HTTPS verso una console interna, limitando in entrambi i casi l’accesso all’interfaccia di ingresso di WireGuard, a reti di destinazione e porte specifiche. Non dovresti autorizzare le porte del database all’interno dell’intera VPN solo perché gli utenti sono già connessi.

In un Full Tunnel, il server VPN funge anche da gateway per le destinazioni Internet. A tal fine, deve instradare i pacchetti IPv4 tra wg0 e inoltrarle al proprio uplink; inoltre, le risposte necessitano di un percorso di ritorno verso la rete VPN. In molte configurazioni di server, a tal fine viene utilizzata una regola Source NAT mirata sull’uplink, qualora la rete a monte non conosca alcuna rotta verso il prefisso VPN. Progetta queste regole con attenzione e limitale alla rete tunnel prevista.

Un "Full Tunnel" non è un requisito di sicurezza di WireGuard, bensì una scelta di routing a livello di client. Poiché wg-quick Poiché le rotte predefinite provenienti da AllowedIPs vengono elaborate in modo particolare, questa impostazione dovrebbe essere utilizzata solo in presenza di una risoluzione dei nomi pianificata, di una capacità del gateway sufficiente e di regole di uscita adeguate. Per l'uso normale Amministrazione VPN di solito è più ampia del necessario. Per l’IPv6, la stessa questione di pianificazione va affrontata separatamente: ::/0 indirizza tutto il traffico IPv6 attraverso il tunnel.

Rendere accessibili in modo mirato le reti interne

Se gli amministratori devono accedere ad altri sistemi privati situati dietro il gateway VPN, il compito passa dal semplice accesso al server alla rete di amministrazione instradata. Per prima cosa, pianifica le reti e i servizi di destinazione: ad esempio SSH verso i server nel segmento amministrativo e HTTPS verso una console interna. Ogni percorso aggiuntivo amplia l’ambito di fiducia e dovrebbe quindi essere giustificato da una specifica attività operativa.

Come primo requisito tecnico, il gateway deve essere autorizzato a inoltrare i pacchetti IPv4. L'impostazione del kernel net.ipv4.ip_forward attiva questo comportamento. Non va considerata una semplice riga di codice senza conseguenze: secondo la documentazione del kernel, una modifica di ip_forward Gli altri parametri di configurazione IPv4 tornano ai valori predefiniti dell'host o del router. Verifica quindi le impostazioni di rete e di sicurezza esistenti prima e dopo la modifica.

In secondo luogo, il firewall richiede impostazioni esplicite Norme sul transito in entrambe le direzioni. Una norma non dovrebbe limitarsi a vietare tutto il traffico da wg0 Accettarle nella LAN. Limitarle invece alla rete di origine della VPN, agli indirizzi di destinazione previsti e ai protocolli necessari, ad esempio TCP 22 verso i server di gestione e TCP 443 verso una console. I database rimangono esclusi da questa autorizzazione, salvo eccezioni giustificate.

In terzo luogo, la rete di destinazione necessita di un percorso di ritorno verso la rete VPN, ad esempio un percorso per 10.77.0.0/24 tramite l'indirizzo interno del gateway. Senza questa via di ritorno, il traffico in entrata può funzionare, mentre le risposte non riescono a tornare all'amministratore. Se il routing nella rete di destinazione non è possibile, il Source NAT sul gateway può rappresentare un'alternativa tecnica; tuttavia, nasconde l'indirizzo originale del client VPN, rendendo così più difficile la registrazione dei log sul lato di destinazione e l'applicazione di regole più precise.

Scegli la rete di indirizzi VPN in modo che non entri in conflitto né con le reti locali degli amministratori né con le reti esistenti di sede, cloud o container. Le sovrapposizioni rendono ambigua la selezione del percorso e generano errori che possono sembrare un problema di WireGuard o del firewall. Documenta inoltre gli indirizzi fissi dei tunnel e i dispositivi associati prima di abilitare ulteriori peer o reti di destinazione.

Gestire in modo sicuro il funzionamento e le modifiche

Una rete di manutenzione rimane gestibile solo se a ogni dispositivo viene assegnato un proprio peer, una propria coppia di chiavi e un indirizzo IP di tunnel fisso. Un inventario dovrebbe quindi contenere almeno l’indirizzo del tunnel, la denominazione del dispositivo, la persona responsabile, lo scopo, la data di emissione e quella di verifica. L’assegnazione dell’indirizzo 10.77.0.10/32 a un specifico laptop amministrativo rende tracciabili gli accessi e impedisce che più dispositivi utilizzino la stessa identità VPN.

Pianifica il cambio delle chiavi come parte integrante del processo operativo standard, non solo in risposta a un incidente. In caso di sostituzione di un dispositivo, crea un nuovo peer con un nuovo indirizzo o un indirizzo successivo chiaramente documentato, verifica l'accesso e successivamente rimuovi il vecchio peer. Le chiavi private di WireGuard devono trovarsi esclusivamente sul rispettivo dispositivo terminale; né i ticket né gli elenchi di inventario centralizzati devono contenerle.

In caso di smarrimento di un notebook o di cessazione del rapporto di lavoro di una persona esterna, rimuovi il peer corrispondente dalla configurazione del server. In questo modo si impedisce l'accesso alla rete di amministrazione senza dover sostituire le chiavi degli altri amministratori. Ritiro tra pari ma non è la stessa cosa della revoca di una chiave SSH: la chiave WireGuard regola il percorso di rete, mentre la chiave SSH regola l'accesso all'account di destinazione.

Dopo la rimozione di un peer, WireGuard non può più scambiare pacchetti relativi a una connessione SSH esistente tramite quel peer; la connessione rimane quindi bloccata o termina in seguito a interruzione o timeout. La rimozione, tuttavia, non revoca automaticamente l’accesso SSH già effettuato a livello di applicazione né termina i processi avviati in precedenza. In caso di incidente, verifica quindi anche le autorizzazioni SSH, i processi in esecuzione, gli account e, se del caso, i diritti sudo.

Per apportare modifiche mirate è possibile wg syncconf confrontare una configurazione WireGuard esistente con le differenze esplicite; secondo il manuale, ciò dovrebbe interferire meno con le sessioni tra peer rispetto a setconf. Tuttavia, non sostituisce l’approvazione, il controllo incrociato o le finestre di manutenzione. Prima di ogni modifica, salva la configurazione funzionante e prendi nota di come ripristinarla.

Diagnosi: dall'handshake all'accesso SSH

In caso di malfunzionamento, separa sistematicamente il trasporto, il routing e l'applicazione. Inizia dalla porta UDP accessibile pubblicamente e dall'handshake prima di modificare le impostazioni SSH. Il comando wg show Per i peer configurati, mostra, tra le altre cose, gli indirizzi IP consentiti (AllowedIPs), l'ora dell'ultimo handshake e il contatore dei trasferimenti. Valori mancanti o invariati indicano la presenza di un problema precedente all'accesso SSH vero e proprio.

Se è presente un handshake, verifica sia sul client che sul server l’indirizzo del tunnel effettivamente impostato e la route verso la destinazione. Per la semplice gestione del gateway, il client deve raggiungere la destinazione 10.77.0.1 tramite l'interfaccia WireGuard. Nel caso di destinazioni interne, si aggiungono i contatori del firewall, il traffico di ritorno consentito e la rotta di ritorno della rete di destinazione; un handshake riuscito non garantisce il soddisfacimento di questi requisiti.

Solo quando il percorso di rete è corretto, si procede alla verifica del servizio SSH. Controlla le voci relative all'autenticazione e alle restrizioni di origine nel file sshd_config, in particolare le condivisioni utente come AllowUsers, e verifica lo stato dei servizi e i log utilizzando gli strumenti della tua distribuzione. Successivamente, controlla l'account utente e le voci in authorized_keys e le regole sudo separatamente. La documentazione di configurazione, di per sé, non dimostra né che l'accesso sia andato a buon fine né che il servizio sia raggiungibile.

Gli AllowedIP identici o sovrapposti non sono un semplice errore di documentazione. Durante l'invio, WireGuard assegna gli indirizzi di destinazione a un peer in base a questi prefissi; durante la ricezione, essi limitano gli indirizzi di origine interni del peer autenticato. I prefissi host duplicati o contraddittori non costituiscono quindi un'identificazione univoca e tracciabile in modo affidabile Abbinamento tra pari. Non si dovrebbe dare per scontato quale risultato concreto produca uno strumento amministrativo quando si applica una configurazione di questo tipo. È invece opportuno prevenire la collisione già nell’inventario e durante la verifica della configurazione.

Applica le correzioni in modo controllato ed esegui le diagnosi solo se è disponibile un accesso di emergenza. In questo modo, una modifica errata relativa a peer, routing o firewall non bloccherà contemporaneamente la via di ritorno per la riparazione. Dopo ogni applicazione, ricontrolla l’handshake, il contatore di trasferimenti, la route e l’accesso al servizio di gestione specificatamente abilitato.

wg show
ip route

La scelta degli utensili e i limiti di sicurezza sono determinanti

La scelta del metodo di gestione dipende dalla configurazione esistente del server, non da un metodo WireGuard presumibilmente universale. wg-quick È adatto a configurazioni di dimensioni contenute: lo script di supporto configura l’interfaccia, gli indirizzi e le rotte derivate dagli AllowedIPs. Per le reti complesse, invece, la documentazione rimanda a strumenti più specifici o alla configurazione diretta tramite wg e strumenti IP.

Se un host gestisce già la propria rete in modo dichiarativo tramite systemd-networkd, i file .netdev e .network rappresentano un’alternativa adeguata. systemd-networkd supporta impostazioni specifiche per WireGuard e può ricavare le chiavi private dalle credenziali; per i contenuti riservati, la documentazione indica come misura di protezione l’uso di credenziali crittografate o, come minimo, permessi di file restrittivi. Ciò è particolarmente indicato per i server implementati in modo automatizzato.

Accessi diretti da wg e ip offrono il massimo controllo per l’automazione, il policy routing e procedure specifiche del firewall, ma richiedono un modello operativo ben definito. Non gestire mai la stessa interfaccia contemporaneamente tramite wg-quick, systemd-networkd e script personalizzati. La presenza di più entità responsabili può causare la sovrascrittura reciproca di percorsi, indirizzi o impostazioni dei peer, rendendo difficile un rollback affidabile.

PersistentKeepalive è utile solo per i peer che, trovandosi dietro un NAT o un firewall a stato, inviano raramente dati ma devono comunque rimanere raggiungibili in entrata. Se non specificato, è disattivato; la documentazione indica 25 secondi solo come intervallo possibile, non come impostazione predefinita. I client mobili traggono spesso vantaggio dal roaming, poiché WireGuard è in grado di aggiornare l’endpoint sulla base di pacchetti correttamente autenticati.

Il roaming e la limitazione fissa degli endpoint rappresentano un compromesso: un firewall che accetta il protocollo UDP solo da reti di origine note può limitare la superficie di attacco, ma impedisce un utilizzo flessibile in mobilità. WireGuard sottolinea inoltre che un aggressore attivo può reindirizzare l’indirizzo di origine esterno e favorire così un attacco Denial of Service senza leggere o modificare il contenuto crittografato.

Un tunnel WireGuard non sostituisce la gestione delle identità, il controllo dei diritti, gli aggiornamenti, i backup o la registrazione dei log. Non maschera il proprio traffico come HTTPS e non offre la modalità TCP. Le applicazioni web pubbliche necessitano quindi comunque di una protezione TLS indipendente; l'articolo spiega i requisiti e l'implementazione Configurare HTTPS in modo sicuro. Distingui chiaramente questo livello di protezione dall'accesso VPN riservato all'amministrazione.