Come Risolvere i Percorsi Split-Tunnel che Nascondono una Sottorete NAS Domestica

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Fix Split-Tunnel Routes That Hide One Home NAS Subnet - Zima Store Online

Ripristina la subnet NAS mancante aggiungendo la rotta bidirezionale più specifica, lasciando inalterati i percorsi split-tunnel funzionanti.

In una VPN domestica, una rete NAS può scomparire anche se il tunnel è connesso e altre subnet private rimangono raggiungibili. La causa abituale non è il servizio NAS stesso, ma una rotta mancante, una rotta locale più ampia che prevale, un prefisso di rete domestica sovrapposto, un gateway del tunnel errato o un percorso di ritorno che non sa come raggiungere il client VPN. La soluzione più sicura è confrontare una subnet funzionante con quella nascosta, correggere una decisione di routing alla volta e verificare sia il traffico in avanti che quello di ritorno prima di ampliare il tunnel.

Dimostra che è mancante solo una subnet NAS

Connetti la VPN e testa separatamente tre destinazioni: il gateway VPN, una subnet privata nota funzionante e la subnet NAS che non funziona. Usa prima indirizzi IP diretti in modo che DNS, scoperta SMB e nomi host non confondano il risultato del routing.

Lo split tunneling invia solo prefissi di destinazione selezionati attraverso la VPN, mentre il resto del traffico segue la rotta predefinita ordinaria del client. Una spiegazione pratica delle rotte split specifiche per subnet mostra che un client può considerare raggiungibile la rete VPN stessa mentre invia una subnet privata vicina al gateway sbagliato.

Se il gateway VPN e un'altra subnet remota funzionano, il tunnel e l'autenticazione sono già stabiliti. Mantieni la diagnosi focalizzata sul prefisso NAS mancante, la preferenza di rotta, la politica del firewall e il percorso di ritorno invece di ricostruire l'intera configurazione VPN.

Confronta la rotta scelta per un indirizzo funzionante e uno non funzionante

Ispeziona la tabella di routing del client dopo la connessione del tunnel e interroga la rotta selezionata per un indirizzo remoto funzionante e uno NAS. Registra il prefisso di destinazione, la lunghezza del prefisso, la metrica, l'interfaccia e il next hop usati per ciascuno.

Una rotta esistente non è automaticamente quella che prevale. I sistemi operativi normalmente preferiscono il prefisso più lungo corrispondente, quindi una rotta locale 192.168.1.0/24 può sovrascrivere una rotta VPN più ampia come 192.168.0.0/16 per gli indirizzi esatti che si sovrappongono.

Se l'indirizzo NAS segue il gateway Wi-Fi o Ethernet locale, aggiungi o pubblicizza una rotta VPN più specifica per la subnet NAS. Se segue già il tunnel, continua con la politica VPN, l'inoltro remoto e il routing di ritorno invece di aggiungere rotte client duplicate.

Rimuovi la sovrapposizione tra la rete client e la rete NAS

Confronta la subnet privata usata dalla posizione attuale del client remoto con la subnet privata dietro la VPN domestica. Hotel, uffici, hotspot mobili e altre abitazioni spesso riutilizzano intervalli comuni come 192.168.0.0/24 o 192.168.1.0/24.

Una discussione attuale su GlobalProtect descrive come una rotta split ampia possa entrare in conflitto con la rete privata locale del client. Il client può credere che l'indirizzo NAS si trovi sulla sua Wi-Fi vicina e non inserire mai il pacchetto nella VPN.

La soluzione più pulita a lungo termine è rinumerare la VLAN NAS domestica o la LAN remota con un prefisso meno comune. Quando la rinumerazione non è possibile, usa una subnet VPN tradotta, una rotta specifica per host, un proxy applicativo o un design VPN che risolva deliberatamente la sovrapposizione invece di affidarsi ad indirizzi privati ambigui.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Correggi il prefisso e il gateway dello split-tunnel

Rivedi la lista lato server delle rotte incluse o delle subnet consentite e conferma che contenga esattamente la rete NAS con la maschera corretta. Un errore di battitura come /25 invece di /24 può nascondere solo metà degli indirizzi previsti.

Un caso Cisco VPN ha trovato rotte split installate con il gateway di rotta sbagliato anche se il pool di indirizzi VPN sembrava corretto. Per questo motivo la rotta operativa del client conta più dell'etichetta di rotta configurata.

Rimuovi rotte obsolete o duplicate, riconnetti la VPN e verifica che appaia una rotta autorevole per il prefisso NAS. Non aggiungere una rotta predefinita attraverso il tunnel a meno che il tunneling completo non sia il design previsto; correggere una subnet non dovrebbe reindirizzare silenziosamente tutto il traffico internet.

Verifica l'inoltro, il firewall e la rotta di ritorno

Cattura o registra il traffico sul gateway VPN mentre il client fa ping all'indirizzo NAS. Se il pacchetto entra nel tunnel ma non esce verso la VLAN NAS, ispeziona l'inoltro IP, le regole firewall tra interfacce e la rotta dal gateway VPN a quella subnet.

Una guida all'implementazione dello split-tunnel sottolinea che l'installazione della rotta deve essere abbinata a politiche di inoltro e firewall corrispondenti. Una rotta lato client da sola non può far sì che il gateway VPN inoltri il traffico in un'altra VLAN.

Conferma quindi che il router della subnet NAS abbia una rotta di ritorno verso il pool client VPN. Se le risposte usano invece il gateway internet normale, aggiungi la rotta di ritorno o applica un source NAT attentamente limitato sul gateway VPN. Una cattura unidirezionale riuscita senza risposte è un fallimento del percorso di ritorno, non un motivo per continuare a modificare la rotta client.

Ritesta il servizio NAS senza interrompere altri percorsi

Dopo che la raggiungibilità IP funziona, testa il servizio NAS reale prima tramite IP e poi tramite nome host. Conferma SMB, la dashboard web o la porta dell'app richiesta senza presumere che un ping riuscito dimostri il percorso applicativo.

La guida ZimaSpace a un percorso VPN-to-LAN mancante fornisce la lezione adiacente che la connettività del tunnel non garantisce che ogni tipo di traffico LAN segua lo stesso percorso.

Concludi testando la subnet NAS riparata, una subnet remota precedentemente funzionante e l'accesso internet ordinario. Mantieni la modifica solo quando tutti e tre si comportano come previsto, la rotta sopravvive alla riconnessione e il client non necessita di un comando manuale dopo ogni cambiamento di rete.