O que um VPS precisa permitir antes de hospedar a sua VPN

A instância inicia, as instalações de pacotes são bem-sucedidas e o serviço até relata um estado em execução, mas nada se conecta. Esse padrão é comum em servidores privados virtuais, porque um convidado que chega confortavelmente à internet ainda pode ser incapaz de criar a interface que o seu protocolo exige. Cinco verificações separam um host capaz de servir um túnel de um que apenas parece pronto, e a primeira verificação que falha costuma explicar tudo o que vem depois. Cada uma é barata de executar e termina em uma decisão, não em uma nota.

Confirme a interface de que o protocolo precisa

OpenVPN sobre TUN precisa do dispositivo de caracteres e do módulo de kernel por trás dele; o WireGuard precisa do próprio suporte no kernel ou de uma implementação em espaço de usuário com expectativas correspondentes. Contêineres gerenciados podem compartilhar um kernel de host que nunca expõe o dispositivo, e algumas plataformas proíbem totalmente a criação de interfaces de túnel, independentemente do que esteja instalado.

Teste a capacidade em vez de ler uma página de suporte, porque os rótulos de marketing mudam mais rápido do que os limites subjacentes. Uma lista de recursos escrita para um plano pode não descrever o kernel no qual o convidado realmente roda. Dois comandos curtos respondem à pergunta para os protocolos de uso comum, e ambos limpam atrás de si. Os comandos abaixo não criam nada permanente e são removidos imediatamente.

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

Uma recusa no primeiro par significa que o TUN não está disponível e que o modo padrão do OpenVPN não pode iniciar; uma recusa na última linha significa que falta a interface de kernel do WireGuard. A documentação do kernel sobre TUN/TAP descreve o dispositivo que a primeira verificação exercita. Nenhuma das duas falhas é corrigida reinstalando o pacote VPN.

Lembre-se de que o caminho de entrada tem dois donos

As regras de rede do provedor e o firewall do convidado são sistemas separados, e o tráfego precisa sobreviver aos dois. Um ouvinte vinculado no convidado não significa nada se o grupo de segurança do provedor descarta a porta, e uma regra aberta do provedor não faz nada se o convidado rejeita o pacote. Verifique o ouvinte, depois as regras do convidado, depois o painel do provedor, nessa ordem, e confirme tanto o protocolo quanto o número da porta. Pular direto para o painel do provedor é como as pessoas acabam abrindo uma faixa de que não precisavam.

O UDP é a vítima costumeira: muitas plataformas permitem TCP por padrão e tratam as regras de UDP como uma entrada separada. Se a instância fica atrás do NAT do provedor em vez de ter um endereço público, o encaminhamento de portas do lado do provedor se torna uma terceira configuração a conciliar.

Planeje o caminho de volta, não apenas a saída

O serviço de túnel completo precisa do encaminhamento ativado, de um esquema de tradução ou roteamento para o tráfego dos clientes e de um caminho de volta que alcance o conjunto de clientes. Abrir um ouvinte não fornece nada disso. Um túnel que se estabelece mas não carrega tráfego útil costuma falhar aqui, não na autenticação. Trate um aperto de mão bem-sucedido como o início do diagnóstico, não como o seu fim.

Escreva o plano como três decisões concretas: qual faixa de origem os clientes recebem, como o tráfego deles sai para a internet e como as respostas encontram o caminho de volta. Depois confirme que o kernel concorda com o plano antes de testar um cliente, para que uma discrepância silenciosa não seja confundida com uma falha do lado do cliente.

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

Decida a questão do IPv6 explicitamente

O IPv6 chega por vários mecanismos que se comportam de forma diferente para um gateway: um endereço na instância, um prefixo roteado ou nada. Apenas um prefixo roteado permite ao servidor entregar endereços aos clientes da maneira habitual. Supor que um endereço IPv6 funcional no host implica um prefixo de cliente utilizável é um erro que aparece mais tarde como conectividade meio quebrada. É o tipo de falha que sobrevive a todo teste feito apenas com IPv4.

Se o provedor não roteia nenhum prefixo, decida se o túnel é apenas IPv4 e se os clientes devem ser informados. Uma ausência documentada é mais segura do que uma configuração parcial que manda em silêncio os destinos IPv6 para um buraco negro para os usuários conectados.

Prove isso a partir de um cliente externo

O estado local do serviço descreve um processo em um host. O teste útil é um cliente autorizado em outra rede, que se conecta com o perfil que você pretende distribuir, depois alcança um aplicativo e resolve um nome. Reconecte uma vez também, porque um túnel que só funciona na primeira tentativa não cumpre o requisito que mais importa na prática.

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

Mantenha os fundamentos operacionais ao lado do teste: espaço para atualizações, registros limitados, acesso administrativo que não dependa do túnel, um console de recuperação e uma nota sobre o que acontece com os perfis dos clientes quando a instância é reconstruída e o endereço público muda. Se uma interface ou um modelo de encaminhamento necessário simplesmente não estiver disponível, nenhuma mudança do lado do cliente vai fornecê-lo, e o próximo passo honesto é outro tipo de instância, não mais configuração.