Accesso remoto privato

Usare WireGuard su VPS con routing e recupero chiari

Un VPS WireGuard offre accesso cifrato a sistemi autorizzati. Un’implementazione affidabile richiede indirizzi espliciti, firewall e forwarding, chiavi protette, rotte IPv4 e IPv6 provate e un recupero indipendente dal tunnel. Non promette anonimato né autorizza a eludere regole.

Dati principali

Esempio comune di ascolto
`51820/udp`, configurabile e non obbligatorio
Identità
Le chiavi pubbliche identificano i peer; le private restano segrete
Controllo routing
`AllowedIPs` influenza peer e rotte sorgente accettate
Recupero
Mantieni console o SSH fuori tunnel fino alla validazione

Disegnare tunnel e confini

Nomina utenti, dispositivi, sottoreti, DNS e destinazioni. Decidi se il VPS è endpoint, router privato o gateway; richiedono forwarding, filtri e log diversi. Evita sovrapposizioni di indirizzi.

WireGuard cifra tra peer; non protegge endpoint compromessi, autentica utenti applicativi o nasconde traffico dopo l’uscita. IP e orari restano visibili. Usalo legalmente con autenticazione applicativa.

  • Assegna indirizzo e chiavi unici.
  • Documenta IPv4, IPv6, DNS e uscita.
  • Non trasportare traffico non autorizzato.

Verificare prima del firewall

Controlla indirizzi, rotte, interfacce, firewall e forwarding. Una configurazione tipica consente un UDP come 51820/udp, conserva amministrazione e filtra per destinazione.

Usa ip route, ss -lunp e console. Per IPv6 verifica routing e regole; NAT IPv4 non basta. Salva il firewall e prepara rollback.

  • Apri solo UDP e amministrazione necessari.
  • Usa forwarding e NAT solo se richiesti.
  • Testa da rete esterna.

Trattare chiavi e `AllowedIPs` come controlli

Genera chiavi private sul dispositivo e limita permessi. In /etc/wireguard/wg0.conf, controlla ogni peer: AllowedIPs regola traffico inviato e sorgenti accettate. Valori ampi o sovrapposti possono deviare traffico o ampliare accessi.

Dietro NAT può servire PersistentKeepalive, solo quando necessario. Non sostituisce il monitoraggio. Revoca dispositivi persi, ruota dopo sospetti e mantieni inventario senza dati privati.

  • Mai inviare chiavi private in ticket o chat.
  • Usa rotte minime.
  • Registra emissione, proprietario, rotazione e revoca.

Validare handshake, routing, DNS, MTU e perdite

Dopo l’avvio usa wg show per peer, handshake, endpoint e contatori. Prova tunnel, destinazioni, DNS e uscita per entrambe le famiglie. Usa ip route sul client.

Se piccoli pacchetti passano ma trasferimenti si fermano, studia MTU e overhead. Testa reti rappresentative. Un guasto non deve esporre traffico e il recupero amministrativo deve restare attivo.

  • Testa destinazioni consentite e negate.
  • Controlla IPv4, IPv6 e DNS separatamente.
  • Registra configurazione e rollback.

Gestire il tunnel come servizio privilegiato

Aggiorna il sistema, monitora interfaccia, disco, traffico e accessi falliti, salva configurazione senza chiavi. Limita chi modifica peer e firewall e definisci aggiunta e perdita dispositivi.

Rivedi peer, chiavi, rotte, DNS e necessità. Rimuovi accessi vecchi e testa recupero dopo modifiche. Alla dismissione revoca, cancella e rimuovi DNS e automazioni.

  • Allerta senza raccogliere navigazione superflua.
  • Cifra e limita i backup.
  • Riprova dopo cambi di rete.

Fonti

  1. WireGuard — Avvio rapido
  2. Documentazione kernel Linux — Specifica Netlink WireGuard
  3. NIST SP 800-123 — Sicurezza generale dei server
Domande frequenti

Domande frequenti

WireGuard rende anonimo il traffico?

No. Cifra tra peer; IP, orari, account, uscita e applicazioni possono creare collegamenti.

Deve usare la porta 51820?

No. 51820/udp è un esempio; qualsiasi UDP adatto deve combaciare con i firewall.

Cosa controllare senza handshake?

Endpoint, porta, UDP, chiavi, ora, ascolto con ss -lunp e peer con wg show. Mantieni la console.

Tutto il traffico in `AllowedIPs`?

Solo per full tunnel intenzionale e testato. Prefissi ristretti riducono sorprese.