Administração do NAS por VPN: mantenha o nome, dispense a porta pública
Chegue à página de administração pelo túnel, não por uma nova porta pública. Resolva o nome real, faça corresponder o certificado e permita um serviço a partir de uma única origem.
A página de administração do NAS funciona em casa e deixa de funcionar no momento em que o administrador viaja, então alguém abre uma porta e o problema desaparece junto com a privacidade. Há uma forma melhor de fazer isto. Deixe a página onde está, deixe o túnel fornecer a alcançabilidade, e faça do que documenta um URL completo com um caminho de permissão com nome, em vez de um endereço de dispositivo que por acaso responde. Cada decisão abaixo, do nome ao certificado e à única porta permitida, decorre de o escrever assim.
A unidade de desenho é um URL, não um endereço
Escreva a entrada como um URL completo com a sua porta e esquema e, em seguida, anexe as condições: quem o pode usar, de que rede e por que caminho. Um exemplo pode ser https://nas.corp.example:8443 publicado apenas para clientes privados aprovados, com o nome e a porta a representar aquilo em que o dispositivo realmente escuta.
Esse enquadramento força as decisões cedo. Um URL implica um nome, um nome implica um certificado e um certificado implica um arranjo de confiança. Um endereço não implica nada disso, e é exatamente por isso que a versão só com endereço sobrevive até ao primeiro aviso do navegador e depois se torna o hábito de clicar através dele.
| 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 |
Mantenha o nome para o qual o certificado foi emitido
O cliente precisa de uma rota permitida até ao endereço privado do NAS, e um arranjo de DNS privado pode resolver o nome de anfitrião pretendido para esse endereço preservando o nome que o serviço HTTPS espera. As duas metades contam: a rota leva os pacotes até lá, o nome diz ao cliente que identidade verificar.
Escrever o endereço numérico em vez disso altera o requisito de identidade. O RFC 9525 separa o nome com que um cliente pretende contactar da identidade que um serviço apresenta, pelo que um certificado emitido para nas.corp.example pode legitimamente falhar quando o navegador foi apontado para 10.20.0.15. O aviso está correto, e a correção é o nome, não uma exceção.
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 é resolvido onde pensa, e o segundo mostra que certificado e que nomes alternativos do sujeito o serviço apresenta realmente. Uma AC privada pode ser uma escolha perfeitamente gerida; o que não deve tornar-se rotina é ensinar as pessoas a ignorar avisos de identidade.
Delimite o caminho de gestão
Permita exatamente o serviço de gestão a partir da origem pretendida, tanto na porta de ligação como no NAS. Essa frase esconde um detalhe que morde: um conjunto de clientes encaminhados e uma porta de ligação com tradução de origem chegam ao NAS com endereços de origem diferentes, pelo que uma regra de permissão escrita para um falha em silêncio para o outro.
O NAS também precisa de um caminho de retorno, e o navegador tem de usar a porta e o esquema configurados em vez do valor predefinido do fabricante retirado de um tópico de fórum. Chegar ao dispositivo não é permissão para chegar a cada porta dele. A diferença entre um dispositivo que responde a ping e uma página de administração que carrega é a diferença entre duas regras separadas. Escreva-as como duas regras com dois comentários, para que a próxima pessoa veja porque existem ambas.
Separe a admissão VPN do privilégio no NAS
Ser deixado passar pelo túnel não é o mesmo que poder administrar o dispositivo. Um utilizador que precisa legitimamente de armazenamento de ficheiros não deve herdar a administração do dispositivo só porque ambos vivem atrás de uma porta de ligação, e o modelo de contas do NAS é onde essa separação tem de ser imposta.
Um endereço de saída partilhado ou traduzido também não consegue identificar um administrador individual. Se o registo de auditoria tem de nomear uma pessoa, a identidade tem de vir de uma conta autenticada e não do endereço de origem de um túnel que muitas pessoas usam.
O que não publicar por acidente
Um proxy inverso público e um relé de fabricante são ambas arquiteturas reais, e cada uma carrega as suas próprias decisões de confiança e exposição. Nenhuma se torna necessária porque um administrador está fora de casa, e nenhuma deve aparecer como efeito secundário de expor um servidor de média ou uma partilha de ficheiros.
Documente quatro coisas e pare: o nome privado, o ouvinte para o qual é mapeado, o grupo autorizado a usá-lo e o caminho de recuperação se o túnel não estiver disponível. Essas quatro também respondem às perguntas que uma revisão de incidentes fará, o que não é verdade para uma captura de ecrã de uma página de reencaminhamento de portas. O que obtém no fim é um ponto de entrada administrativo estável em vez de um dispositivo com todas as funcionalidades viradas para a internet.