Server VPN domestico o server cloud: quale raggiunge il tuo NAS?
Il tunnel sale, ma il NAS di casa resta irraggiungibile. Scegli la posizione dell’estremità in base alla risorsa da raggiungere, poi controlla la rotta.
Il tunnel sale, il client mostra un punto verde e ssh 192.168.1.20 resta appeso fino allo scadere del tempo. Mi è successo esattamente questo dopo aver affittato una piccola istanza cloud e averci messo WireGuard: handshake a posto, DNS a posto, e il NAS sulla mia scrivania irraggiungibile come se fosse sulla luna. Il tunnel non aveva nulla di difettoso. L’estremità era parcheggiata in una rete senza rotta verso casa mia. La posizione dell’estremità decide quali reti sono adiacenti, quindi sceglila in base alla risorsa da raggiungere per prima e confronta l’hosting dopo.
Un tunnel raggiunge solo le reti che l’estremità può instradare
Una VPN assegna al client un indirizzo nel dominio di routing dell’estremità stessa. Quando il client invia un pacchetto a 192.168.1.20, l’estremità deve sapere dove va. La tabella di una VM cloud conosce le sottoreti VPC del provider; della tua LAN non ha mai sentito parlare. Connesso e raggiungibile sono due fatti diversi, e la maggior parte della confusione casa-cloud nasce dal prendere il primo come prova del secondo.
Un comando risolve. Sull’estremità, ip route get 192.168.1.20 indica un’interfaccia LAN oppure punta alla rotta predefinita. Su una macchina di casa la risposta è il lato LAN. Su un’istanza cloud il pacchetto esce verso internet e muore. Accendere net.ipv4.ip_forward=1 e aggiungere una regola MASQUERADE non cambia nulla, perché non c’è nulla a cui inoltrare finché qualcosa dal lato casa non termina un collegamento verso il cloud.
Il caso domestico ha una seconda metà: il percorso di ritorno. I pacchetti che lasciano la LAN attraverso la macchina del tunnel passano per NAT, oppure la LAN ha bisogno di una rotta statica verso la sottorete del tunnel. Quando funziona una sola direzione, controlla sysctl net.ipv4.conf.all.rp_filter. Il filtro rigoroso del percorso inverso scarta le risposte che arrivano su un’interfaccia diversa da quella prevista dalla rotta, e il sintomo sembra esattamente una regola di firewall.
Leggi il sintomo prima di toccare la configurazione
Il tunnel non si stabilisce: chiavi, indirizzo dell’estremità o porta UDP bloccata. Tunnel su ma host della LAN morti: posizione e routing. Tunnel su ma navigazione morta: inoltro, NAT o DNS. Sono tre livelli e tre controlli diversi, e riscrivere una configurazione già corretta spreca una serata.
| Symptom | First suspect | Check |
|---|---|---|
| Handshake fails, no transfer | Keys, endpoint port, UDP blocked | wg show, then the port from outside |
| Peer pings, LAN host times out | No route to the LAN | ip route get on the endpoint |
| Tunnel up, name resolution fails | DNS options in the peer config | Resolve a name from the client |
| Large transfers reset the connection | MTU | Lower the tunnel MTU and retry |
La raggiungibilità in ingresso da casa merita un controllo a parte, perché decide se l’hosting in casa è possibile. Confronta l’indirizzo WAN riportato dal router con quello visto da un host esterno. Se cade in 100.64.0.0/10, o i due non coincidono, sei dietro NAT dell’operatore e nessun inoltro di porta funzionerà mai. Le opzioni reali sono un relay, un collegamento cloud che chiama verso l’esterno da casa, o spostare l’estremità.
Cosa ti dà l’hosting in casa e quanto costa
Casa è l’unica posizione che sta dentro la LAN per impostazione predefinita, ed è tutta la ragione per metterci un server. I dispositivi che rispondono solo sul segmento locale, come stampanti e pagine di amministrazione del NAS che rifiutano sottoreti non locali, funzionano senza routing aggiuntivo. Gestisci anche macchina, router e collegamento da solo.
I costi sono fisici. L’upload di casa è il tetto per tutti i client insieme, quindi una videochiamata e un backup competono per lo stesso tubo. Corrente, usura del disco, patch, un indirizzo dinamico che richiede DDNS, un router che deve inoltrare UDP verso l’interno e forse doppio NAT: tutto ricade su di te. Quello che la gente salta è il ripristino: se la macchina muore mentre sei via, la tua unica via verso casa muore con lei. Tieni un secondo dispositivo con le stesse chiavi, o almeno un piano di accesso fisico.
Se vuoi accesso alla LAN senza la macchina a casa, costruisci un collegamento invece di fingere. L’estremità cloud diventa un router: un tunnel dal lato casa con AllowedIPs = 192.168.1.0/24 sul peer cloud, più inoltro e NAT sulla macchina cloud. La guida all’inoltro di strongSwan percorre la metà di ritorno di quella configurazione, ed è lì che falliscono la maggior parte di questi tentativi. Il peer di casa ora deve essere attivo perché qualcosa funzioni, quindi hai scambiato una dipendenza con un’altra e dovresti annotarlo.
A cosa serve davvero un’estremità cloud
Un’estremità cloud cambia la tua uscita pubblica. Il traffico esce dall’intervallo di indirizzi del provider, e i siti vedono quell’indirizzo invece di quello di casa. Questo è il valore, ed è anche il motivo per cui una VPN cloud non ti dà il NAS: hai spostato l’uscita, non la LAN.
Esegui ancora il sistema guest, il servizio VPN e le sue credenziali mentre il provider esegue l’hypervisor e la rete fisica, e questa divisione conta quando qualcosa si rompe alle 2 di notte. Un’estremità pubblica viene scansionata di continuo, quindi tieni chiusa la porta di gestione, consenti solo la porta VPN e applica patch secondo un calendario. I gruppi di sicurezza e i firewall del provider devono permettere quella porta, e alcuni cloud scartano il traffico inoltrato se non regoli il controllo di origine e destinazione sull’istanza.
Un’istanza piccola copre una manciata di client, ma la cifratura è lavoro della CPU, e un’istanza burstable che esaurisce i crediti si comporta in modo irregolare sotto carico prolungato. Guarda il percorso che usi davvero, non la scheda tecnica.
Una decisione che puoi scrivere
Il compito decide la posizione, non l’etichetta sulla macchina. Se ti serve un dispositivo sulla LAN di casa, la risposta corretta più economica è un’estremità a casa; una macchina cloud funziona solo dopo aver costruito il collegamento di ritorno. Se ti serve un’uscita pubblica diversa, la risposta è il cloud e la questione della LAN non si pone. Volere entrambe è legittimo, ma significa due estremità, due set di chiavi e due rotte documentate.
| What you need | Endpoint location | What else must exist |
|---|---|---|
| Reach a NAS or printer on the home LAN | A box on that LAN | Port forward or relay, DDNS, recovery plan |
| Browse from an exit unrelated to home | Cloud instance | Firewall and egress rules, patching |
| Both, reliably | Two endpoints, or cloud plus a link home | Separate keys, routes, documented failure modes |
Verifica dal client in ordine: handshake, indirizzo del peer, un host della LAN, poi l’IP di uscita. curl -s https://ifconfig.me mostra cosa vede internet, e ip route get 192.168.1.20 mostra cosa crede l’estremità. Quando il controllo di uscita passa e quello del NAS si blocca, hai già la risposta sulla posizione; regolare AllowedIPs sul client non farà apparire una rotta. Una riga divisa come 10.8.0.0/24, 192.168.1.0/24 tiene il traffico della LAN nel tunnel solo quando quella rotta esiste davvero.