Router o computer separato come server VPN: come scegliere

Sia un router sia un piccolo computer possono terminare una VPN, e la decisione raramente dipende dalla velocità effettiva. Dipende da chi applica l’aggiornamento alle due di notte, da cos’altro si ferma quando quella scatola si riavvia e dalla possibilità di raggiungere ancora una console quando è proprio il tunnel a essersi rotto. Rispondete a queste tre domande per ogni candidato e la scelta di solito si fa da sola. La procedura seguente trasforma il confronto in un breve elenco di cose che potete verificare prima di impegnarvi.

Cominciate da ciò che deve restare attivo quando il tunnel si guasta

Il guasto per cui progettare è quello in cui il processo VPN muore e voi dovete comunque raggiungere l’host. Su un router, il tunnel e il gateway internet condividono lo stesso destino: una sola modifica di configurazione sbagliata può abbattere entrambi, e il percorso di ripristino è spesso un reset fisico. Su un computer separato, il gateway continua a funzionare e l’host resta raggiungibile sulla LAN. Quale di questi esiti potete tollerare decide più di qualsiasi elenco di funzionalità.

Scrivete la risposta come una frase: se l’host della VPN si riavvia, cosa perde la casa o l’ufficio? Se la risposta include tutto l’accesso a internet, avete accettato un dominio di guasto condiviso e dovreste dirlo di proposito invece di scoprirlo più tardi.

Un secondo servizio sullo stesso dispositivo non è una console di riserva. Condivide l’alimentatore, il firmware e l’account amministratore.

Contate le superfici di manutenzione che ogni host aggiunge

Un router porta il firmware del produttore con il proprio ritmo di rilascio, e la funzione VPN è di solito un modulo dentro un’immagine molto più grande. Un computer porta un sistema operativo, un gestore di pacchetti, un kernel e un insieme di servizi che ora possedete. Entrambi hanno bisogno di patch, e la vera domanda è quale ritmo terrete quando la novità svanirà.

Su un host Linux, rendete visibile quel ritmo invece di sperarci. systemctl list-timers mostra i lavori pianificati e apt list --upgradable mostra cosa è in attesa. Annotate quali aggiornamenti richiedono un riavvio, perché un host VPN che si riavvia è un’interruzione, a meno che non l’abbiate pianificata. Un router senza un percorso di aggiornamento automatico ha invece bisogno di una voce in calendario, che è un controllo più debole ma onesto.

Contate anche gli account. Ogni accesso aggiuntivo come amministratore sull’host VPN è un’altra credenziale da ruotare e un altro percorso da revocare.

Seguite il percorso della rete privata, non l’etichetta sulla scatola

Ai client non importa dove gira il server; importa se i prefissi protetti sono raggiungibili e se esiste un percorso di ritorno. Mettete il server dove l’instradamento è più semplice, il che di solito significa direttamente sul segmento che contiene le risorse. Un computer dietro il router ha ancora bisogno di un inoltro di porta, e le risorse su quella LAN hanno ancora bisogno di una rotta di ritorno verso la sottorete del tunnel.

Controllate l’inoltro sull’host prima di dare la colpa al client. sysctl net.ipv4.ip_forward dovrebbe riportare 1, e nft list ruleset o iptables -S mostra se l’interfaccia del tunnel può inoltrare. Una regola masquerade mancante appare dal lato del client esattamente come un tunnel rotto.

Decidete anche cosa il tunnel non deve raggiungere. Un server collocato sul router vede ogni sottorete che quel router instrada, e spesso è più di quanto intenda la politica di accesso. Su un host separato lo stesso isolamento è a una regola di firewall di distanza, e il raggio d’azione di un client compromesso è minore. La descrizione del gateway IPsec nell’RFC 7296 tratta questo come una questione di instradamento e di politica, non di hardware, e nessuna delle due forme è più sicura per impostazione predefinita finché la politica non è scritta.

Tenete una console di ripristino che non dipenda dal tunnel

La console che usate per riparare la VPN non può essere la VPN stessa. Tenete un indirizzo LAN, una console seriale o una console del fornitore che funzioni mentre il tunnel è giù, e usatela almeno una volta prima che vi serva. Un percorso fuori banda che non è mai stato provato è un piano e non una capacità.

Fate un backup della configurazione dove l’host stesso non possa cancellarlo. tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn cattura le chiavi e le definizioni dei servizi, e la copia deve uscire dalla macchina. Includete le regole del firewall e l’inventario dei client, perché ripristinare le chiavi senza l’elenco dei peer produce un server a cui nessuno può unirsi. Archiviate il file dove la console di ripristino può raggiungerlo.

Scrivete il passo di rollback nella stessa nota. Una modifica di configurazione senza inversione documentata è una modifica permanente, qualunque fosse l’intenzione.

Verificate la scelta con un riavvio e un aggiornamento

Provate la disposizione come fallirà, non come funziona in una buona giornata. Riavviate l’host, applicate un aggiornamento in sospeso e confermate che il tunnel torni senza passaggi manuali.

Dopo il riavvio, controllate le tre cose che si rompono più spesso. systemctl is-active wg-quick@wg0 riporta se l’interfaccia è tornata, ss -lunp mostra se qualcosa è in ascolto sulla porta, e wg show elenca un peer con handshake completato. Un servizio attivo senza handshake significa che il firewall o la rotta sono sbagliati, non il demone.

Ripetete il controllo da un client su una rete diversa da quella da cui avete configurato. Se il tunnel sopravvive a un riavvio, a un aggiornamento e a un cambio di rete del client, la scelta dell’host è risolta per ora. Se no, il pezzo mancante è di solito un passaggio documentato e non un’altra scatola.