Servidor VPN no Raspberry Pi: comece pelo aplicativo do celular, não pela receita

A maioria das montagens de VPN no Raspberry Pi começa pela receita do servidor e termina num celular que não consegue conectar. A ordem está invertida. Um cliente no celular implementa um protocolo específico com uma troca de autenticação específica, e o servidor tem de corresponder a essa troca, não o contrário. Decidir o aplicativo primeiro transforma uma tarde de depuração numa lista de verificação curta.

A ordem que poupa a reconstrução

Anote o sistema operacional do celular e o aplicativo VPN exato antes de instalar qualquer coisa no Pi. Esse par determina qual protocolo é sequer possível. Um aplicativo cliente não se torna outro cliente só porque um perfil contém por acaso um campo conhecido.

Um segredo compartilhado num perfil, ou um número de porta que parece familiar, não converte um protocolo noutro. A troca ou corresponde ao que o aplicativo implementa, ou falha numa etapa que deixa muito pouco para ler. Não existe diagnóstico que diga em palavras simples "protocolo errado". Você recebe um tempo esgotado, um erro de certificado ou um ciclo de tentativas silencioso, e tudo isso parece um problema do servidor.

Assim que o aplicativo está fixado, a escolha do servidor estreita-se e o resto da montagem tem um alvo.

O que o aplicativo do celular realmente implementa

Uma listagem publicada de clientes descreve um aplicativo, não um serviço. O aplicativo OpenVPN Connect para Android espera um servidor OpenVPN; ele não fornece o lado do servidor. Também não se torna um cliente IPsec ou L2TP quando um perfil parece semelhante.

Essa distinção importa sobretudo ao seguir um guia antigo. Receitas escritas para um protocolo que o aplicativo atual abandonou ainda se instalam limpo no Pi e ainda falham no celular, o que se lê como erro de configuração e não como discrepância de protocolo.

Consulte a documentação atual do aplicativo sobre os formatos de perfil que ele importa antes de se comprometer com um pacote de servidor. Cinco minutos de leitura valem mais do que uma reconstrução.

O acordo de quatro partes

Anote quatro coisas e mantenha-as juntas: o sistema operacional e a versão do aplicativo no celular, a implementação do servidor no Pi, a política de autenticação e confiança, e o endpoint externo. Qualquer uma das quatro pode invalidar as outras três.

Uma atualização do aplicativo, uma troca de pacote de servidor ou uma nova autoridade de certificação quebram o acordo, e a falha parece idêntica do celular todas as vezes. Ter as quatro anotadas é o que permite identificar qual parte se moveu.

As credenciais têm tarefas separadas

Decida se o perfil usa certificados de cliente, nome de usuário e senha, ou uma combinação suportada, e alinhe as duas pontas. A identidade do servidor e o material da CA confiável também têm de corresponder ao que o cliente aceitará.

O certificado público da CA e a respetiva chave privada de assinatura são objetos diferentes. Apenas a parte pública pertence a um perfil de celular. Colocar a chave de assinatura num celular entrega a capacidade de criar identidades, o que é o oposto do propósito de uma CA. Trate esse arquivo como o objeto mais sensível de toda a montagem.

Use o fluxo de exportação e importação suportado pelo serviço em vez de montar um perfil à mão. Perfis montados à mão costumam trazer diretivas apenas de desktop que o aplicativo móvel ignora ou rejeita.

Acima de tudo, não substitua a validação do certificado por "aceitar qualquer servidor" para fazer um exemplo antigo conectar. Isso converte um problema de compatibilidade num desvio de autenticação, e normalmente sobrevive até à produção porque funciona.

A alcançabilidade é um contrato separado

O celular tem de alcançar o endpoint externo do servidor através do arranjo real a montante. A tradução do router doméstico, a filtragem e o NAT da operadora ficam todos no meio. Um nome DNS dinâmico só dá ao endpoint um nome estável; não cria um caminho de entrada.

Depois defina o que o cliente pode alcançar após conectar: prefixos privados ou uma saída completa para a internet, os respetivos caminhos de encaminhamento e resposta, o comportamento do DNS, e se o IPv6 está no âmbito. Um login bem-sucedido não prova nada disso.

Aceite o celular e o perfil previstos diretamente, incluindo uma verificação de que um recurso não autorizado continua inalcançável e que a revogação remove mesmo o acesso. O sucesso com um cliente de desktop valida esse cliente de desktop, não o celular na sua mão. A listagem do OpenVPN Connect é um exemplo concreto de um aplicativo cliente que espera um serviço correspondente.