NAS inacessível pela VPN: endereço, caminho de retorno ou serviço?

Os túneis sobem, os clientes recebem um endereço, e o NAS não responde absolutamente nada. Esse único sintoma cobre três falhas sem relação, e a ordem em que você as testa decide quanto dura o reparo. O endereçamento vem primeiro, porque uma sub-rede sobreposta pode enviar a sua requisição para um dispositivo alheio. O caminho de retorno vem em segundo, porque uma requisição que chega sem resposta parece idêntica a um serviço fechado. O serviço e a permissão vêm por último, e só depois de os dois primeiros estarem provados.

Três falhas que todas são lidas como inacessível

A escolha de endereço, o roteamento de retorno e a autorização de serviço produzem a mesma mensagem visível: nada acontece. Eles têm provas, responsáveis e correções diferentes, então separá-los é a tarefa inteira. Um ping que falha prova pouco sozinho, e uma recusa TCP bem-sucedida é, na verdade, uma boa notícia.

Leia a tabela como uma ordem de testes e não como uma lista de causas. Cada linha restringe a seguinte, porque uma recusa já prova que o endereçamento e o caminho de retorno funcionam. Passar vinte minutos dentro de regras de firewall antes de verificar qual interface a rota escolheu é a forma mais comum de perder uma tarde. Trabalhe de cima para baixo e pare na primeira linha que corresponder.

Condição um: esse endereço é o dispositivo certo?

Anote a sub-rede do NAS e a faixa que a VPN entrega aos clientes, e compare as duas com a rede em que o seu notebook está agora. Neste roteiro o NAS fica em 10.40.7.25 e o pool da VPN é 10.40.9.0/24, duas faixas privadas separadas dentro de um mesmo plano de site; uma casa que use 192.168.0.0/24 ou 10.0.0.0/24 tem muito mais chance de colidir com uma delas.

Quando a rede local e a rede do NAS se sobrepõem, o cliente envia esse tráfego para o seu próprio gateway e pode chegar a um dispositivo não relacionado que por acaso tem o mesmo endereço. Verifique o caminho antes de digitar credenciais em qualquer coisa que responda.

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

O primeiro comando informa a interface e o gateway que o kernel usaria, e o segundo mostra os primeiros saltos que realmente respondem. Se os dois discordarem, acredite na consulta, porque é o caminho que o pacote vai seguir. Uma lista de saltos que para um salto antes do NAS também é um achado e não uma falha. Uma consulta que resolve para o adaptador físico em vez do túnel encerra a investigação neste ponto.

Condição dois: a resposta volta?

O cliente precisa de uma rota até o NAS, e a rede do NAS precisa de um caminho de retorno até o pool da VPN. O encaminhamento do gateway, as regras de firewall e a tradução deliberada afetam cada um esse par. as notas de encaminhamento do strongSwan descrevem as escolhas de rota de retorno e de tradução para uma sub-rede privada atrás de um gateway.

Quando a requisição chega e a resposta sai por outro gateway, nenhuma alteração de DNS repara a assimetria. Uma captura dos dois lados resolve isso numa única tentativa, e também mostra se a tradução reescreveu a origem para a qual o NAS respondeu. O administrador é dono dessa fronteira: permita apenas os serviços necessários e a faixa de clientes da VPN, e anote se foi escolhido roteamento ou tradução.

Condição três: o serviço está lá e é permitido?

Uma página de gestão e um serviço de compartilhamento de arquivos são endpoints diferentes na mesma máquina, e um pode aceitar conexões enquanto o outro é bloqueado pelo firewall do host, pela configuração do serviço ou por uma permissão de compartilhamento. Um dispositivo que responde com uma recusa já provou as duas primeiras condições, o que estreita bastante a terceira.

Teste com a conta que realmente precisa dos arquivos, não com a conta de administrador usada na instalação, porque direitos administrativos não podem reparar uma rota ausente e uma rota não pode conceder uma permissão de compartilhamento. Os nomes também têm lugar aqui: um nome de NAS descoberto em casa costuma depender de multicast local, que um túnel roteado não transporta, então tente o nome de host privado documentado pelo fabricante ou o próprio endereço para separar a nomeação do acesso.

Teste de fora da rede do NAS e depois amplie devagar

Um teste feito na mesma LAN esconde cada parte incompleta do caminho remoto, e é por isso que a primeira tentativa remota bem-sucedida merece uma nota no registro de mudanças. Execute as verificações a partir de um cliente que só chegue ao NAS pelo túnel, e guarde o texto de erro original de cada tentativa.

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

Depois que o caminho funcionar, transfira um arquivo inofensivo e confirme o comportamento de leitura ou escrita de que você realmente precisa. Se as transferências grandes travarem enquanto as pequenas funcionam, o problema restante é o tratamento do tamanho do pacote ou a estabilidade da conexão, e não o endereçamento.

Não publique portas de compartilhamento de arquivos ou de administração na internet para contornar uma falha sem explicação. Repare o caminho privado, mantenha o software do NAS com suporte e teste a restauração de tudo o que você copia por ele antes de confiar nessa cópia.