Administración del NAS por VPN: conserve el nombre, deje el puerto público
Llegue a la página de administración por el túnel, no por un puerto público nuevo. Resuelva el nombre real, haga coincidir el certificado con él y permita un servicio desde una sola fuente.
La página de administración del NAS funciona en casa y deja de funcionar en el momento en que el administrador viaja, así que alguien abre un puerto y el problema desaparece junto con la privacidad. Hay una forma mejor de hacerlo. Deje la página donde está, deje que el túnel proporcione el alcance y haga que lo que documenta sea una URL completa con una ruta de permiso con nombre, y no una dirección de dispositivo que da la casualidad de que responde. Cada decisión de abajo, del nombre al certificado y al único puerto permitido, se deriva de escribirlo así.
La unidad de diseño es una URL, no una dirección
Escriba la entrada como una URL completa con su puerto y esquema, y después añada las condiciones: quién puede usarla, desde qué red y por qué ruta. Un ejemplo podría ser https://nas.corp.example:8443 publicado solo para clientes privados aprobados, con el nombre y el puerto representando aquello en lo que el dispositivo escucha realmente.
Ese planteamiento fuerza las decisiones pronto. Una URL implica un nombre, un nombre implica un certificado y un certificado implica un acuerdo de confianza. Una dirección no implica nada de eso, y por eso mismo la versión solo con dirección sobrevive hasta el primer aviso del navegador y después se convierte en la costumbre de hacer clic a través de él.
| 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 |
Conserve el nombre para el que se emitió el certificado
El cliente necesita una ruta permitida hacia la dirección privada del NAS, y un arreglo de DNS privado puede resolver el nombre de host previsto hacia esa dirección conservando el nombre que espera el servicio HTTPS. Las dos mitades importan: la ruta lleva los paquetes hasta allí, el nombre dice al cliente qué identidad verificar.
Escribir la dirección numérica en su lugar cambia el requisito de identidad. El RFC 9525 separa el nombre con el que un cliente pretende contactar de la identidad que presenta un servicio, así que un certificado emitido para nas.corp.example puede fallar legítimamente cuando el navegador se apuntó a 10.20.0.15. El aviso es correcto, y la solución es el nombre, no una excepción.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleEjecute ambos antes de culpar al túnel. El primero muestra si el nombre privado se resuelve donde usted cree, y el segundo muestra qué certificado y qué nombres alternativos del sujeto presenta realmente el servicio. Una CA privada puede ser una opción perfectamente gestionada; lo que no debería volverse rutina es enseñar a la gente a descartar los avisos de identidad.
Acote la ruta de gestión
Permita exactamente el servicio de gestión desde la fuente prevista, tanto en la puerta de enlace como en el NAS. Esa frase esconde un detalle que muerde: un conjunto de clientes enrutados y una puerta de enlace con traducción de origen llegan al NAS con direcciones de origen distintas, así que una regla de permiso escrita para una falla en silencio para la otra.
El NAS también necesita una ruta de retorno, y el navegador tiene que usar el puerto y el esquema configurados en lugar del valor por defecto del fabricante sacado de un hilo de foro. Llegar al dispositivo no es permiso para llegar a cada puerto suyo. La diferencia entre un dispositivo que responde a ping y una página de administración que carga es la diferencia entre dos reglas separadas. Escríbalas como dos reglas con dos comentarios, para que la siguiente persona vea por qué existen ambas.
Separe la admisión a la VPN del privilegio en el NAS
Que le dejen pasar por el túnel no es lo mismo que poder administrar el dispositivo. Un usuario que necesita legítimamente almacenamiento de archivos no debería heredar la administración del dispositivo solo porque ambos viven detrás de una puerta de enlace, y el modelo de cuentas del NAS es donde debe imponerse esa separación.
Una dirección de salida compartida o traducida tampoco puede identificar a un administrador individual. Si el registro de auditoría tiene que nombrar a una persona, la identidad debe venir de una cuenta autenticada y no de la dirección de origen de un túnel que usan muchas personas.
Qué no publicar por accidente
Un proxy inverso público y un relé de fabricante son dos arquitecturas reales, y cada una conlleva sus propias decisiones de confianza y exposición. Ninguna se vuelve necesaria porque un administrador esté fuera de casa, y ninguna debería aparecer como efecto secundario de exponer un servidor multimedia o un recurso compartido.
Documente cuatro cosas y pare: el nombre privado, el escucha al que se asigna, el grupo autorizado a usarlo y la ruta de recuperación si el túnel no está disponible. Esas cuatro también responden a las preguntas que hará una revisión de incidentes, lo que no es cierto de una captura de pantalla de una página de reenvío de puertos. Con lo que termina es con un punto de entrada administrativo estable en lugar de un dispositivo con todas sus funciones mirando a internet.