Servidor VPN doméstico versus servidor na nuvem: qual chega ao seu NAS?

O túnel sobe, o cliente mostra um ponto verde e ssh 192.168.1.20 continua pendurado até o tempo esgotar. Aconteceu exatamente isso comigo depois de alugar uma pequena instância na nuvem e instalar WireGuard nela: handshake certo, DNS certo, e o NAS da minha mesa tão inacessível como se estivesse na lua. O túnel não tinha nada de errado. O endpoint estava estacionado numa rede sem rota para a minha casa. A localização do endpoint decide quais redes são adjacentes, então escolha-a pelo recurso que você precisa alcançar primeiro e compare a hospedagem depois.

Um túnel só alcança as redes que o endpoint consegue rotear

Uma VPN entrega ao seu cliente um endereço dentro do domínio de roteamento do próprio endpoint. Quando o cliente envia um pacote para 192.168.1.20, o endpoint precisa saber para onde ele vai. A tabela de uma VM na nuvem conhece as sub-redes VPC do provedor; da sua LAN ela nunca ouviu falar. Conectado e alcançável são dois fatos diferentes, e a maior parte da confusão entre casa e nuvem vem de tomar o primeiro como prova do segundo.

Um comando resolve. No endpoint, ip route get 192.168.1.20 ou nomeia uma interface LAN ou aponta para a rota padrão. Numa máquina de casa a resposta é o lado LAN. Numa instância na nuvem o pacote sai para a internet e morre. Ativar net.ipv4.ip_forward=1 e acrescentar uma regra MASQUERADE não muda isso, porque não há para onde encaminhar até que algo do lado de casa encerre um enlace para a nuvem.

O caso doméstico tem uma segunda metade: o caminho de volta. Os pacotes que saem da LAN pelo equipamento do túnel passam por NAT, ou a LAN precisa de uma rota estática de volta para a sub-rede do túnel. Quando só uma direção funciona, verifique sysctl net.ipv4.conf.all.rp_filter. O filtro estrito de caminho inverso descarta as respostas que chegam por uma interface diferente da que a rota prevê, e o sintoma parece exatamente uma regra de firewall.

Leia o sintoma antes de tocar na configuração

O túnel não se estabelece: chaves, endereço do endpoint ou porta UDP bloqueada. Túnel no ar, mas hosts da LAN mortos: posicionamento e roteamento. Túnel no ar, mas navegação morta: encaminhamento, NAT ou DNS. São três camadas e três verificações diferentes, e reescrever uma configuração que já estava correta desperdiça uma noite.

A acessibilidade de entrada a partir de casa merece verificação própria, porque decide se hospedar em casa é possível. Compare o endereço WAN que o roteador informa com o endereço que um host externo vê. Se ele cair em 100.64.0.0/10, ou os dois não baterem, você está atrás de NAT de operadora e nenhum encaminhamento de porta vai funcionar jamais. As opções reais são um relé, um enlace na nuvem que disca para fora a partir de casa, ou mover o endpoint.

O que a hospedagem em casa compra e quanto custa

Casa é o único posicionamento que fica dentro da LAN por padrão, e essa é toda a razão de colocar um servidor ali. Dispositivos que só respondem no segmento local, como impressoras e páginas de administração do NAS que recusam sub-redes não locais, funcionam sem roteamento extra. Você também opera a máquina, o roteador e o enlace por conta própria.

Os custos são físicos. O upload de casa é o teto para todos os clientes ao mesmo tempo, então uma videochamada e um backup disputam o mesmo tubo. Energia, desgaste do disco, patches, um endereço dinâmico que precisa de DDNS, um roteador que precisa encaminhar UDP para dentro e possivelmente NAT duplo caem todos sobre você. O que as pessoas pulam é a recuperação: se o equipamento morre enquanto você está fora, seu único caminho até a casa morre com ele. Mantenha um segundo aparelho com as mesmas chaves, ou pelo menos um plano de acesso físico.

Se você quer acesso à LAN sem o equipamento em casa, construa um enlace em vez de fingir. O endpoint na nuvem vira um roteador: um túnel do lado de casa com AllowedIPs = 192.168.1.0/24 no peer da nuvem, mais encaminhamento e NAT no equipamento da nuvem. O guia de encaminhamento do strongSwan percorre a metade de volta dessa configuração, e é aí que a maioria dessas tentativas falha. O peer de casa agora tem que estar no ar para qualquer coisa funcionar, então você trocou uma dependência por outra e deveria anotar isso.

Para que serve de fato um endpoint na nuvem

Um endpoint na nuvem muda a sua saída pública. O tráfego sai da faixa de endereços do provedor, e os sites veem esse endereço em vez do endereço de casa. Esse é o valor, e é também por isso que uma VPN na nuvem não entrega o NAS: você moveu a saída, não a LAN.

Você ainda opera o sistema convidado, o serviço VPN e as credenciais dele enquanto o provedor opera o hipervisor e a rede física, e essa divisão importa quando algo quebra às 2 da manhã. Um endpoint público é escaneado continuamente, então mantenha a porta de gestão fechada, permita só a porta VPN e aplique patches conforme um calendário. Grupos de segurança e firewalls do provedor precisam permitir essa porta, e algumas nuvens descartam o tráfego encaminhado a menos que você ajuste a verificação de origem e destino na instância.

Uma instância pequena cobre um punhado de clientes, mas a criptografia é trabalho de CPU, e uma instância burstable sem créditos se comporta de forma irregular sob carga contínua. Olhe o caminho que você realmente usa, não a folha de especificações.

Uma decisão que você pode anotar

A tarefa decide o posicionamento, não o rótulo no equipamento. Se você precisa de um dispositivo na LAN de casa, a resposta correta mais barata é um endpoint em casa; um equipamento na nuvem só funciona depois de construir o enlace de volta. Se precisa de outra saída pública, a resposta é a nuvem e a questão da LAN nunca aparece. Querer as duas é legítimo, mas significa dois endpoints, dois conjuntos de chaves e duas rotas documentadas.

Verifique pelo cliente na ordem: handshake, endereço do peer, um host da LAN, depois o IP de saída. curl -s https://ifconfig.me mostra o que a internet vê, e ip route get 192.168.1.20 mostra o que o endpoint acredita. Quando a verificação de saída passa e a do NAS trava, você já tem a resposta sobre o posicionamento; ajustar AllowedIPs no cliente não vai fazer aparecer uma rota. Uma linha dividida como 10.8.0.0/24, 192.168.1.0/24 só mantém o tráfego da LAN dentro do túnel quando essa rota existe de verdade.