Hospedagem web ou um VPS: o seu plano consegue executar um servidor VPN?

Um site a funcionar é prova de que um fornecedor consegue servir HTTP, não de que você controla uma máquina. Entre um plano partilhado, uma aplicação gerida e um servidor autogerido há um grande fosso naquilo que a conta pode fazer à rede. Decida de que lado desse fosso o seu projeto de VPN precisa antes de pagar mais um ano. Quatro capacidades separam os dois casos, e nenhuma delas aparece numa lista de preços.

O que cada plano dá realmente

A comparação útil não é o preço nem o tamanho do disco, mas a autoridade. Pergunte o que a conta pode iniciar, a que funções do núcleo consegue chegar, que portas aceitam tráfego de entrada e se o tráfego admitido pode voltar a sair para outro sítio.

A maioria dos produtos de hospedagem cai em três formas, e só a última é um servidor de uso geral:

A conta de shell é a fonte habitual de confusão. A transferência de ficheiros ou o acesso a tarefas agendadas pode parecer administração, enquanto o processo fica confinado a um diretório e a um pequeno conjunto de operações permitidas.

Quatro capacidades que decidem a resposta

Tome-as por ordem, porque uma falha no primeiro passo torna o resto irrelevante.

Primeiro, o software tem de correr como um processo de longa duração que sobrevive à manutenção. Segundo, a implementação tem de conseguir criar a sua interface virtual; no Linux isso costuma significar abrir /dev/net/tun com a permissão administrativa relevante, como a documentação do núcleo sobre TUN/TAP descreve, embora nem todo o projeto de VPN use esse dispositivo. Terceiro, os clientes têm de alcançar o ouvinte no endereço público, no transporte e na porta que pretende, e um proxy inverso web que aceite HTTPS não diz nada sobre um protocolo não relacionado no mesmo número. Quarto, o tráfego admitido tem de conseguir seguir em frente, com rotas, reencaminhamento e qualquer tradução realmente suportada.

Os termos de serviço estão ao lado dessas quatro e não são nada técnicos. Os limites de tráfego ilimitado descrevem normalmente pedidos web, não um túnel que transporta transferências de outras pessoas. Leia a secção de utilização aceitável antes de desenhar à volta dela, e tenha presente o acesso de recuperação para o dia em que o serviço não arrancar.

Onde uma conta de site fica aquém

Um plano de site executa normalmente o seu código dentro de um runtime gerido com um ponto de entrada fixo. Mesmo quando existe um binário de túnel, o processo pode não ter permissão para abrir um nó de dispositivo, ligar uma porta privilegiada ou alterar a tabela de encaminhamento. Essas restrições são o produto, não um descuido.

Por isso um plugin que promete uma VPN acaba por ser um proxy para outro sítio. Se a conta atual só oferece controlos de site, o passo honesto é um servidor separado, não a procura do módulo que desbloqueia a autoridade em falta.

Quando um só servidor tem de executar as duas coisas

Partilhar é possível e por vezes sensato, mas trate-o como uma decisão de segurança e não como uma comodidade. Uma aplicação web com um formulário de carregamento fica ao lado de credenciais de túnel e de um socket de controlo, e uma exploração numa alcança a outra. Contas separadas, unidades de serviço separadas e sistemas de ficheiros separados reduzem essa exposição sem comprar uma segunda máquina.

A competição por recursos conta tanto. Uma cópia de segurança pelo túnel e um processo web ocupado disputam o mesmo uplink e o mesmo disco, e a falha parece um site lento em vez de um túnel saturado. Decida qual carga ganha antes do incidente, e limite o túnel para que o site continue a responder.

Nenhuma das duas disposições está isolada só porque ambos os serviços correm. A capacidade de os alojar juntos é o início do projeto, e o trabalho de isolamento é o que o torna defensável.

Resolva-o num servidor de teste com quatro comandos

Antes de migrar, alugue a instância mais pequena do produto alvo durante uma hora e teste as quatro capacidades diretamente. Adivinhar a partir de uma tabela de funções desperdiça menos dinheiro do que um ano do plano errado, mas muito mais tempo.

Execute estes comandos no servidor de teste e leia as falhas como respostas, não como obstáculos:

ls -l /dev/net/tun
sudo ip tuntap add dev tun9 mode tun && sudo ip link del tun9
sysctl net.ipv4.ip_forward
ss -lunp | head

As duas primeiras linhas dizem se um dispositivo de túnel pode sequer existir. A terceira indica se o servidor pode reencaminhar pacotes, e a quarta mostra o que já está à escuta para que um conflito de portas seja apanhado cedo. Um fornecedor que falha a segunda linha pode ainda suportar uma implementação no espaço do utilizador, por isso nomeie o mecanismo de que precisa e não a categoria de produto quando perguntar ao apoio.