Servidor VPN na Raspberry Pi: comeza pola app do teléfono, non pola receita

A maioría das montaxes de VPN na Raspberry Pi comezan pola receita do servidor e rematan cun teléfono que non pode conectarse. A orde está invertida. Un cliente de teléfono implementa un protocolo concreto cun intercambio de autenticación concreto, e o servidor ten que coincidir con ese intercambio, non ao revés. Decidir primeiro a app converte unha tarde de depuración nunha lista de comprobación curta.

A orde que aforra a reconstrución

Anota o sistema operativo do teléfono e a app VPN exacta antes de instalar nada na Pi. Ese par determina que protocolo é sequera posible. Unha app cliente non se converte noutro cliente porque un perfil conteña por casualidade un campo coñecido.

Un segredo compartido nun perfil, ou un número de porto que parece coñecido, non converte un protocolo noutro. O intercambio ou coincide co que implementa a app, ou falla nunha etapa que che deixa moi pouco que ler. Non hai ningún diagnóstico que diga con palabras simples "protocolo incorrecto". Obtes un tempo de espera esgotado, un erro de certificado ou un bucle de reintentos silencioso, e todo iso parece un problema do servidor.

Unha vez fixada a app, a elección de servidor estréitase e o resto da montaxe ten un obxectivo.

Que implementa realmente a app do teléfono

Unha listaxe publicada de clientes describe unha aplicación, non un servizo. A app OpenVPN Connect para Android espera un servidor OpenVPN; non achega o lado do servidor. Tampouco se converte en cliente IPsec ou L2TP cando un perfil parece similar.

Esa distinción importa sobre todo ao seguir unha guía antiga. As receitas escritas para un protocolo que a app actual abandonou instálanse igual de limpas na Pi e seguen fallando no teléfono, o que se le como un erro de configuración e non como unha discrepancia de protocolo.

Consulta a documentación actual da app sobre os formatos de perfil que importa antes de comprometerte cun paquete de servidor. Cinco minutos de lectura valen máis ca unha reconstrución.

O acordo de catro partes

Anota catro cousas e mantenas xuntas: o sistema operativo e a versión da app do teléfono, a implementación do servidor na Pi, a política de autenticación e confianza, e o punto final externo. Cada unha das catro pode invalidar as outras tres.

Unha actualización da app, un cambio de paquete de servidor ou unha nova autoridade de certificación rompen o acordo, e o fallo vese idéntico desde o teléfono cada vez. Ter as catro anotadas é o que permite identificar que parte se moveu.

As credenciais teñen tarefas separadas

Decide se o perfil usa certificados de cliente, un nome de usuario e un contrasinal, ou unha combinación admitida, e fai que os dous extremos coincidan. A identidade do servidor e o material do CA de confianza tamén teñen que coincidir co que o cliente aceptará.

O certificado público do CA e a súa clave privada de sinatura son obxectos distintos. Só a parte pública pertence a un perfil de teléfono. Poñer a clave de sinatura nun teléfono regala a capacidade de crear identidades, que é o contrario daquilo para o que serve un CA. Trata ese ficheiro como o obxecto máis sensible de toda a montaxe.

Usa o fluxo de exportación e importación admitido polo servizo en lugar de montar un perfil a man. Os perfís feitos a man adoitan levar directivas só de escritorio que a app móbil ignora ou rexeita.

Sobre todo, non substitúas a validación de certificados por "aceptar calquera servidor" para que un exemplo antigo se conecte. Iso converte un problema de compatibilidade nunha elusión da autenticación, e normalmente sobrevive ata produción porque funciona.

O alcance é un contrato aparte

O teléfono ten que chegar ao punto final externo do servidor a través da disposición real de subida. A tradución do router doméstico, o filtrado e o NAT do operador sitúanse todos no medio. Un nome DNS dinámico só lle dá ao punto final un nome estable; non crea unha ruta de entrada.

Despois define que pode alcanzar o cliente unha vez conectado: prefixos privados ou unha saída completa a internet, as súas rutas de reenvío e resposta, o comportamento do DNS, e se IPv6 entra no alcance. Un inicio de sesión correcto non demostra nada diso.

Acepta o teléfono e o perfil previstos directamente, incluída unha comprobación de que un recurso non autorizado segue sendo inalcanzable e de que a revocación retira de verdade o acceso. O éxito cun cliente de escritorio valida ese cliente de escritorio, non o teléfono que tes na man. A listaxe de OpenVPN Connect é un exemplo concreto dunha aplicación cliente que espera un servizo correspondente.