Un tunnel WireGuard domestico ha bisogno di una rotta di ritorno dalla LAN

L'accesso a casa è un unico servizio privato, non una seconda uscita internet. WireGuard termina su una macchina Linux dietro il router, il router conserva il suo compito attuale e il portatile invia solo il prefisso di casa attraverso il tunnel. Quale dispositivo inoltra e quale termina è la decisione da cui deriva ogni regola successiva. Sbagliate quella divisione e farete debug di un NAT che non volevate aggiungere.

Decidete chi inoltra e chi termina

Il router possiede l'ingresso pubblico: accetta il pacchetto UDP e lo passa all'host Linux. Quell'host possiede l'ascoltatore WireGuard e la decisione di inoltro verso la LAN. In pratica la mappatura invia UDP 51820 a 192.168.50.10, e la porta propria dell'applicazione resta chiusa. Tenere separati i ruoli tiene corto il firewall.

Scrivete il piano degli indirizzi prima di creare l'interfaccia. Router 192.168.50.1, gateway 192.168.50.10, servizio 192.168.50.20, tunnel 10.77.0.0/24 con gateway .1 e portatile .2. L'intervallo del tunnel non deve sovrapporsi a una rete che il portatile raggiunge già, altrimenti le destinazioni diventano ambigue. Il NAT dell'operatore o un router a monte possono bloccare l'accesso in entrata, e nessun inoltro di porta locale lo ripara.

Scambiate le chiavi, poi dimensionate le AllowedIPs

Create una coppia di chiavi separata per ogni estremità e spostate solo le chiavi pubbliche su un canale verificato. La voce peer del gateway consente solo la sorgente del tunnel del portatile, perché la LAN di casa sta dietro il gateway e non dietro il portatile. Mettere la LAN in quella voce descrive una topologia che non avete costruito.

[Interface]
Address = 10.77.0.2/32
PrivateKey = LAPTOP_PRIVATE_KEY_BASE64

[Peer]
PublicKey = HOME_PUBLIC_KEY_BASE64
Endpoint = home-vpn.example.com:51820
AllowedIPs = 192.168.50.0/24, 10.77.0.1/32

AllowedIPs è il prefisso di casa più l'indirizzo del tunnel del gateway, mai 0.0.0.0/0, così la navigazione ordinaria conserva il suo percorso locale. Tenete un solo proprietario della configurazione e non collegate mai la stessa interfaccia a un secondo gestore di rete.

La rotta di ritorno è la parte che le persone saltano

Questo progetto conserva la sorgente 10.77.0.2 del portatile invece di mascherarla come gateway, quindi i dispositivi di casa devono sapere come rispondere. Aggiungete una rotta statica sul router di casa per 10.77.0.0/24 con 192.168.50.10 come prossimo salto, e leggete cosa deriva wg-quick dalle AllowedIPs nella sua referenza. Senza quella rotta, un handshake completato convive con risposte dell'applicazione che non arrivano mai.

Se il router non può portare quella rotta, scegliete un progetto di ritorno documentato. Aggiungere NAT in silenzio cambia invece il modello di sorgente che avete appena scritto.

Consentite un servizio, non la sottorete

Abilitate l'inoltro IPv4 sul gateway e tenete tre compiti del firewall separati: ammettere l'ascoltatore WireGuard, inoltrare la sorgente del portatile solo a 192.168.50.20 e lasciare il resto della rete di casa chiuso a quel peer. Integrate le regole nel gestore del firewall già in uso invece di svuotarlo. Una rotta per tutto il prefisso di casa non è il permesso di usare ogni dispositivo al suo interno.

L'autenticazione propria dell'applicazione e il firewall dell'host sono una porta separata. Nominate il servizio che il set di regole consente, così il prossimo revisore può confrontarlo con il compito previsto.

Provate da fuori, poi ritirate in modo pulito

Sollevate i profili tramite il loro proprietario, confermate l'handshake, poi esercitate l'applicazione prevista da una rete esterna approvata e controllate la risposta. Provate un servizio di casa che deve restare negato, perché una regola permissiva è invisibile finché qualcosa non la usa. Per HTTPS usate il nome sul certificato e lasciate girare la validazione; digitare l'indirizzo grezzo e superare l'avviso non dimostra nulla sul percorso. PersistentKeepalive è facoltativo: aiuta un peer legato al NAT dopo un periodo di inattività, ma non è una rotta mancante né una correzione dei permessi.

Un indirizzo pubblico dinamico richiede aggiornamenti DNS, e il portatile deve risolvere di nuovo il proprio endpoint dopo un cambiamento; i nuovi record DNS non spostano un endpoint configurato. Ritirate il portatile rimuovendo il suo peer dalla configurazione salvata e attiva; cancellare solo il profilo del portatile non revoca l'autorizzazione del gateway.