Chegar a um dispositivo de casa através de uma VPN de acesso remoto: cinco portas

Uma VPN comercial de saída para a internet esconde o seu endereço; não o liga à sua própria casa. Chegar ao NAS ou à impressora de uma rede doméstica exige um gateway situado nessa rede e um cliente que construa um túnel até ele. O pacote tem então de passar cinco verificações, e qualquer uma delas que falhe parece igual do exterior.

Porta 1: o cliente tem de selecionar o túnel

Verifique se o prefixo de destino é realmente encaminhado para o túnel no cliente. Um perfil de túnel dividido que só empurra a sub-rede própria da VPN enviará 192.168.x.x diretamente pela interface local, onde não chega a lado nenhum. Olhe para a tabela de encaminhamento do cliente, não para o nome do perfil.

É a falha mais comum com clientes de telefone, que muitas vezes por omissão só enviam DNS ou só um prefixo. Se faltar a rota, o handshake pode ser perfeito e o dispositivo continuar inacessível.

Confirme que o endereço do pool do cliente e a sub-rede de casa não se sobrepõem antes de continuar.

Porta 2: o gateway tem de reencaminhar

A VPN termina num host que tem de reencaminhar o pacote desencriptado para a LAN. Isso exige o reencaminhamento IP ativado e uma política de firewall que permita o fluxo da interface VPN para a interface LAN. Num equipamento router isto costuma vir integrado; numa máquina Linux com strongSwan ou WireGuard são dois ajustes que as pessoas esquecem. Verifique ambos antes de testar o serviço, porque cada um por si produz o mesmo tempo de espera.

Teste com uma captura na interface LAN, porque um pacote que nunca aparece ali foi descartado ou nunca reencaminhado.

É uma falha diferente da de um serviço que recusa a ligação, e a distinção poupa muito tempo. Mantenha a permissão estreita, limitada ao serviço e ao pool da VPN em vez de toda a sub-rede.

Porta 3: o caminho de resposta decide tudo

O destino responde ao endereço de origem que viu, que é ou o endereço do pool do cliente ou o gateway, conforme traduza ou não. Se o gateway predefinido do destino for o router de casa e esse router não tiver rota para o pool da VPN, a resposta sai pela internet e morre. É a clássica ligação unidirecional.

Existem duas correções legítimas: adicionar uma rota para o pool no gateway LAN, ou fazer source-NAT no gateway VPN para que o destino só veja o endereço do gateway. A segunda é mais fácil e perde a identidade original da origem.

Escolha uma deliberadamente e anote qual, porque as regras de firewall e os registos dependem disso. O guia de reencaminhamento do strongSwan percorre o lado Linux dessa decisão.

Porta 4: nomes e sobreposição de prefixos

Os nomes de descoberta locais não atravessam uma fronteira encaminhada, por isso um dispositivo que em casa aparece com um nome amigável pode ser invisível pelo túnel. Forneça DNS para a zona privada, ou documente o endereço. Qualquer nome que use tem de resolver para algo que o cliente remoto consiga encaminhar. É por isso que um dispositivo pode estar acessível por endereço e invisível por nome ao mesmo tempo.

Os prefixos sobrepostos são a outra armadilha: se o pool do cliente for 192.168.1.0/24 e a rede de casa também, o cliente trata o destino como local e nunca o envia pelo túnel.

Renumere um lado, ou use um pool de um intervalo que nunca encontrará em casa.

Porta 5: teste de fora de casa

Um teste a partir da cozinha não prova nada, porque o tráfego pode nunca sair da LAN. Ligue-se a partir de um hotspot móvel ou de outra rede e depois percorra as portas por ordem: rota no cliente, captura na interface LAN, resposta do serviço, captura da resposta e resolução de nomes. A primeira porta que não produza provas é onde está o trabalho.

Se o serviço responde mas o nome não, tem um problema de DNS e não um problema de túnel.

Guarde a configuração que funciona numa nota com o pool, a rota e a escolha de NAT, porque a próxima substituição do router reinicia as três coisas.