NAS irraggiungibile tramite la VPN: indirizzo, percorso di ritorno o servizio?

I tunnel salgono, i client ricevono un indirizzo e il NAS non risponde assolutamente nulla. Questo unico sintomo copre tre guasti senza rapporto, e l'ordine in cui li provate decide quanto dura la riparazione. L'indirizzamento viene per primo, perché una sottorete sovrapposta può inviare la richiesta a un dispositivo estraneo. Il percorso di ritorno viene per secondo, perché una richiesta che arriva senza risposta sembra identica a un servizio chiuso. Il servizio e l'autorizzazione vengono per ultimi, e solo dopo che i primi due sono dimostrati.

Tre guasti che si leggono tutti come irraggiungibile

La scelta dell'indirizzo, l'instradamento di ritorno e l'autorizzazione del servizio producono lo stesso messaggio visibile: non succede nulla. Hanno prove, responsabili e correzioni diversi, quindi separarli è l'intero compito. Un ping che fallisce dimostra poco da solo, e un rifiuto TCP riuscito è in realtà una buona notizia.

Leggete la tabella come un ordine di prove e non come un elenco di cause. Ogni riga vincola la successiva, perché un rifiuto dimostra già che l'indirizzamento e il percorso di ritorno funzionano. Passare venti minuti dentro le regole del firewall prima di controllare quale interfaccia abbia scelto la rotta è il modo più comune di perdere un pomeriggio. Lavorate dall'alto verso il basso e fermatevi alla prima riga che corrisponde.

Condizione uno: quell'indirizzo è il dispositivo giusto?

Annotate la sottorete del NAS e l'intervallo che la VPN assegna ai client, poi confrontate entrambi con la rete su cui si trova il vostro portatile in questo momento. In questo percorso il NAS è su 10.40.7.25 e il pool della VPN è 10.40.9.0/24, due intervalli privati separati dentro un unico piano di sede; una casa che usa 192.168.0.0/24 o 10.0.0.0/24 ha molte più probabilità di entrare in collisione con uno dei due.

Quando la rete locale e la rete del NAS si sovrappongono, il client invia quel traffico al proprio gateway e può raggiungere un dispositivo non correlato che per caso ha lo stesso indirizzo. Verificate il percorso prima di digitare credenziali in qualunque cosa risponda.

ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25

Il primo comando indica l'interfaccia e il gateway che userebbe il kernel, e il secondo mostra i primi salti che rispondono davvero. Se i due non concordano, credete alla ricerca, perché è il percorso che prenderà il pacchetto. Un elenco di salti che si ferma un salto prima del NAS è anch'esso un riscontro e non un fallimento. Una ricerca che si risolve verso l'adattatore fisico invece del tunnel conclude l'indagine a questo punto.

Condizione due: la risposta torna indietro?

Il client ha bisogno di una rotta verso il NAS, e la rete del NAS ha bisogno di un percorso di ritorno verso il pool della VPN. L'inoltro del gateway, le regole del firewall e la traduzione deliberata influenzano ciascuno quella coppia. le note di inoltro di strongSwan descrivono le scelte di rotta di ritorno e di traduzione per una sottorete privata dietro un gateway.

Quando la richiesta arriva e la risposta esce da un altro gateway, nessuna modifica al DNS ripara l'asimmetria. Una cattura su entrambi i lati lo risolve in un solo tentativo, e mostra anche se la traduzione ha riscritto l'origine a cui il NAS ha risposto. L'amministratore possiede quel confine: consentite solo i servizi necessari e l'intervallo dei client VPN, e annotate se è stato scelto l'instradamento o la traduzione.

Condizione tre: il servizio c'è ed è consentito?

Una pagina di gestione e un servizio di condivisione file sono endpoint diversi sulla stessa macchina, e uno può accettare connessioni mentre l'altro viene bloccato dal firewall dell'host, dalla configurazione del servizio o da un permesso di condivisione. Un dispositivo che risponde con un rifiuto ha già dimostrato le prime due condizioni, il che restringe molto la terza.

Provate con l'account che serve davvero i file, non con l'account amministratore usato durante l'installazione, perché i diritti amministrativi non possono riparare una rotta mancante e una rotta non può concedere un permesso di condivisione. Anche i nomi hanno il loro posto qui: un nome NAS scoperto a casa dipende spesso dal multicast locale, che un tunnel instradato non trasporta, quindi provate il nome host privato documentato dal produttore o l'indirizzo stesso per separare la denominazione dall'accesso.

Provate dall'esterno della rete del NAS, poi allargate lentamente

Una prova eseguita sulla stessa LAN nasconde ogni parte incompleta del percorso remoto, ed è per questo che il primo tentativo remoto riuscito merita una nota nel registro delle modifiche. Eseguite i controlli da un client che raggiunge il NAS solo attraverso il tunnel, e conservate il testo di errore originale di ogni tentativo.

nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guest

Una volta che il percorso funziona, trasferite un file innocuo e confermate il comportamento di lettura o scrittura che vi serve davvero. Se i trasferimenti grandi si bloccano mentre quelli piccoli riescono, il problema rimanente è la gestione della dimensione dei pacchetti o la stabilità della connessione, non l'indirizzamento.

Non pubblicate porte di condivisione file o di amministrazione su internet per aggirare un guasto inspiegato. Riparate il percorso privato, mantenete il software del NAS supportato, e provate il ripristino di tutto ciò che salvate attraverso di esso prima di affidarvi a quel backup.