Amministrare il NAS via VPN: mantenete il nome, lasciate il porto pubblico
Raggiungete la pagina di amministrazione dal tunnel, non da una nuova porta pubblica. Risolvete il nome reale, fate corrispondere il certificato e consentite un solo servizio da una sola origine.
La pagina di amministrazione del NAS funziona a casa e smette di funzionare nel momento in cui l'amministratore viaggia, così qualcuno apre una porta e il problema sparisce insieme alla riservatezza. Esiste una forma migliore per questo. Lasciate la pagina dov'è, lasciate che il tunnel fornisca la raggiungibilità, e fate di ciò che documentate un URL completo con un percorso di autorizzazione con nome invece di un indirizzo di dispositivo che per caso risponde. Ogni decisione qui sotto, dal nome al certificato e all'unica porta consentita, deriva dallo scriverlo così.
L'unità di progetto è un URL, non un indirizzo
Scrivete la voce come URL completo con la sua porta e lo schema, poi allegate le condizioni: chi può usarlo, da quale rete e attraverso quale percorso. Un esempio potrebbe essere https://nas.corp.example:8443 pubblicato solo per client privati approvati, con il nome e la porta che rappresentano ciò su cui il dispositivo ascolta davvero.
Quella impostazione forza le decisioni presto. Un URL implica un nome, un nome implica un certificato e un certificato implica un accordo di fiducia. Un indirizzo non implica nulla di tutto ciò, ed è proprio per questo che la versione solo indirizzo sopravvive fino al primo avviso del browser e poi diventa l'abitudine di fare clic oltre.
| Entry point | What it costs | When it fits |
|---|---|---|
| Private name over the tunnel | A private DNS zone and a certificate for that name | Administrators who already hold VPN access |
| Public reverse proxy | An exposed front end to patch and monitor | A documented, reviewed need for public reach |
| Vendor relay service | Trust in a third party path | A supported product design, not a workaround |
Mantenete il nome per cui è stato emesso il certificato
Il client ha bisogno di un percorso consentito verso l'indirizzo privato del NAS, e un assetto DNS privato può risolvere il nome host previsto su quell'indirizzo preservando il nome che il servizio HTTPS si aspetta. Contano entrambe le metà: il percorso porta i pacchetti lì, il nome dice al client quale identità verificare.
Digitare invece l'indirizzo numerico cambia il requisito di identità. La RFC 9525 separa il nome con cui un client intende contattare l'identità che un servizio presenta, quindi un certificato emesso per nas.corp.example può legittimamente fallire quando il browser è stato puntato a 10.20.0.15. L'avviso è corretto, e la correzione è il nome, non un'eccezione.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleEseguite entrambi prima di dare la colpa al tunnel. Il primo mostra se il nome privato si risolve dove pensate, il secondo mostra quale certificato e quali nomi alternativi del soggetto il servizio presenti davvero. Una CA privata può essere una scelta perfettamente gestita; ciò che non dovrebbe diventare routine è insegnare alla gente a ignorare gli avvisi di identità.
Limitate il percorso di gestione
Consentite esattamente il servizio di gestione dall'origine prevista, sia sul gateway sia sul NAS. Quella frase nasconde un dettaglio che morde: un pool di client instradati e un gateway con traduzione dell'origine arrivano al NAS con indirizzi di origine diversi, quindi una regola di autorizzazione scritta per uno fallisce silenziosamente per l'altro.
Il NAS ha bisogno anche di un percorso di ritorno, e il browser deve usare la porta e lo schema configurati invece del valore predefinito del fornitore preso da un post di un forum. Raggiungere il dispositivo non è il permesso di raggiungere ogni sua porta. Il divario tra un dispositivo che risponde al ping e una pagina di amministrazione che si carica è il divario tra due regole separate. Scrivetele come due regole con due commenti, così la persona successiva vede perché esistono entrambe.
Separate l'ammissione VPN dal privilegio NAS
Essere lasciati passare dal tunnel non è lo stesso che poter amministrare il dispositivo. Un utente che ha legittimamente bisogno di archiviazione file non dovrebbe ereditare l'amministrazione del dispositivo solo perché entrambi vivono dietro un gateway, e il modello di account del NAS è il punto in cui quella separazione va applicata.
Un indirizzo di uscita condiviso o tradotto non può nemmeno identificare un singolo amministratore. Se la traccia di controllo deve nominare una persona, l'identità deve venire da un account autenticato e non dall'indirizzo di origine di un tunnel che molte persone usano.
Cosa non pubblicare per errore
Un proxy inverso pubblico e un relè del fornitore sono entrambi architetture reali, e ciascuna porta con sé le proprie decisioni di fiducia ed esposizione. Nessuna delle due diventa necessaria perché un amministratore è fuori casa, e nessuna dovrebbe comparire come effetto collaterale dell'esporre un media server o una condivisione file.
Documentate quattro cose e fermatevi: il nome privato, il listener a cui è mappato, il gruppo autorizzato a usarlo e il percorso di ripristino se il tunnel non è disponibile. Quelle quattro rispondono anche alle domande che farà una revisione di incidente, cosa che non vale per uno screenshot di una pagina di inoltro porte. Quello che ottenete è un punto di ingresso amministrativo stabile invece di un dispositivo con ogni funzione rivolta a internet.