Administración do NAS por VPN: conserve o nome, deixe o porto público
Chegue á páxina de administración polo túnel, non por un porto público novo. Resolva o nome real, axuste o certificado a el e permita un servizo desde unha soa fonte.
A páxina de administración do NAS funciona na casa e deixa de funcionar no momento en que o administrador viaxa, así que alguén abre un porto e o problema desaparece xunto coa privacidade. Hai unha forma mellor de facelo. Deixe a páxina onde está, deixe que o túnel proporcione o alcance e faga que o que documenta sexa un URL completo cun camiño de permiso con nome, e non un enderezo de dispositivo que dá a casualidade de que responde. Cada decisión de abaixo, do nome ao certificado e ao único porto permitido, derívase de escribilo así.
A unidade de deseño é un URL, non un enderezo
Escriba a entrada como un URL completo co seu porto e esquema, e despois engada as condicións: quen pode usalo, desde que rede e por que camiño. Un exemplo podería ser https://nas.corp.example:8443 publicado só para clientes privados aprobados, co nome e o porto representando aquilo no que o dispositivo escoita realmente.
Ese planteamento forza as decisións pronto. Un URL implica un nome, un nome implica un certificado e un certificado implica un acordo de confianza. Un enderezo non implica nada diso, e por iso mesmo a versión só con enderezo sobrevive ata o primeiro aviso do navegador e despois convértese no costume de facer clic a través del.
| 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 o nome para o que se emitiu o certificado
O cliente necesita unha ruta permitida cara ao enderezo privado do NAS, e un axuste de DNS privado pode resolver o nome de host previsto cara a ese enderezo conservando o nome que espera o servizo HTTPS. As dúas metades importan: a ruta leva os paquetes ata alí, o nome di ao cliente que identidade verificar.
Escribir o enderezo numérico no seu lugar cambia o requisito de identidade. O RFC 9525 separa o nome co que un cliente pretende contactar da identidade que presenta un servizo, así que un certificado emitido para nas.corp.example pode fallar lexitimamente cando o navegador se apuntou a 10.20.0.15. O aviso é correcto, e a solución é o nome, non unha excepción.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleExecute ambos antes de culpar o túnel. O primeiro mostra se o nome privado se resolve onde vostede cre, e o segundo mostra que certificado e que nomes alternativos do suxeito presenta realmente o servizo. Unha CA privada pode ser unha opción perfectamente xestionada; o que non debería volverse rutina é ensinar a xente a descartar os avisos de identidade.
Acoute a ruta de xestión
Permita exactamente o servizo de xestión desde a fonte prevista, tanto na pasarela como no NAS. Ese enunciado esconde un detalle que morde: un conxunto de clientes encamiñados e unha pasarela con tradución de orixe chegan ao NAS con enderezos de orixe distintos, así que unha regra de permiso escrita para unha falla en silencio para a outra.
O NAS tamén necesita unha ruta de retorno, e o navegador ten que usar o porto e o esquema configurados en lugar do valor por defecto do fabricante sacado dun fío de foro. Chegar ao dispositivo non é permiso para chegar a cada porto seu. A diferenza entre un dispositivo que responde a ping e unha páxina de administración que carga é a diferenza entre dúas regras separadas. Escríbaas como dúas regras con dous comentarios, para que a seguinte persoa vexa por que existen ambas.
Separe a admisión VPN do privilexio no NAS
Que o deixen pasar polo túnel non é o mesmo que poder administrar o dispositivo. Un usuario que necesita lexitimamente almacenamento de ficheiros non debería herdar a administración do dispositivo só porque ambos viven detrás dunha pasarela, e o modelo de contas do NAS é onde se debe impoñer esa separación.
Un enderezo de saída compartido ou traducido tampouco pode identificar un administrador individual. Se o rexistro de auditoría ten que nomear unha persoa, a identidade debe vir dunha conta autenticada e non do enderezo de orixe dun túnel que usa moita xente.
Que non publicar por accidente
Un proxy inverso público e un relé de fabricante son dúas arquitecturas reais, e cada unha leva as súas propias decisións de confianza e exposición. Ningunha se volve necesaria porque un administrador estea fóra da casa, e ningunha debería aparecer como efecto secundario de expoñer un servidor multimedia ou un recurso compartido.
Documente catro cousas e pare: o nome privado, o escoitante ao que se asigna, o grupo autorizado a usalo e a ruta de recuperación se o túnel non está dispoñible. Esas catro tamén responden ás preguntas que fará unha revisión de incidentes, o que non é certo dunha captura de pantalla dunha páxina de reenvío de portos. Co que remata é cun punto de entrada administrativo estable en lugar dun dispositivo con todas as súas funcións mirando a internet.