Servidor VPN en Raspberry Pi: empieza por la app del teléfono, no por la receta

La mayoría de los montajes de VPN en Raspberry Pi empiezan por la receta del servidor y terminan con un teléfono que no puede conectarse. El orden está invertido. Un cliente de teléfono implementa un protocolo concreto con un intercambio de autenticación concreto, y el servidor tiene que coincidir con ese intercambio, no al revés. Decidir primero la app convierte una tarde de depuración en una lista de comprobación corta.

El orden que ahorra la reconstrucción

Anota el sistema operativo del teléfono y la app VPN exacta antes de instalar nada en la Pi. Ese par determina qué protocolo es siquiera posible. Una app cliente no se convierte en otro cliente porque un perfil contenga por casualidad un campo conocido.

Un secreto compartido en un perfil, o un número de puerto que parece conocido, no convierte un protocolo en otro. El intercambio o coincide con lo que implementa la app, o falla en una etapa que te deja muy poco que leer. No hay ningún diagnóstico que diga con palabras llanas "protocolo incorrecto". Obtienes un tiempo de espera agotado, un error de certificado o un bucle de reintentos silencioso, y todo ello parece un problema del servidor.

Una vez fijada la app, la elección de servidor se estrecha y el resto del montaje tiene un objetivo.

Qué implementa realmente la app del teléfono

Un listado publicado de clientes describe una aplicación, no un servicio. La app OpenVPN Connect para Android espera un servidor OpenVPN; no proporciona el lado del servidor. Tampoco se convierte en cliente IPsec o L2TP cuando un perfil parece similar.

Esa distinción importa sobre todo al seguir una guía antigua. Las recetas escritas para un protocolo que la app actual ha abandonado se siguen instalando limpiamente en la Pi y siguen fallando en el teléfono, lo que se lee como un error de configuración y no como una discrepancia de protocolo.

Consulta la documentación actual de la app sobre los formatos de perfil que importa antes de comprometerte con un paquete de servidor. Cinco minutos de lectura valen más que una reconstrucción.

El acuerdo de cuatro partes

Anota cuatro cosas y mantenlas juntas: el sistema operativo y la versión de la app del teléfono, la implementación del servidor en la Pi, la política de autenticación y confianza, y el punto final externo. Cada una de las cuatro puede invalidar a las otras tres.

Una actualización de la app, un cambio de paquete de servidor o una nueva autoridad de certificación rompen el acuerdo, y el fallo se ve idéntico desde el teléfono cada vez. Tener las cuatro anotadas es lo que permite identificar qué parte se movió.

Las credenciales tienen tareas separadas

Decide si el perfil usa certificados de cliente, un nombre de usuario y una contraseña, o una combinación admitida, y haz que ambos extremos coincidan. La identidad del servidor y el material del CA de confianza también tienen que coincidir con lo que el cliente aceptará.

El certificado público del CA y su clave privada de firma son objetos distintos. Solo la parte pública pertenece a un perfil de teléfono. Poner la clave de firma en un teléfono regala la capacidad de acuñar identidades, que es lo contrario de aquello para lo que sirve un CA. Trata ese archivo como el objeto más sensible de todo el montaje.

Usa el flujo de exportación e importación admitido por el servicio en lugar de montar un perfil a mano. Los perfiles hechos a mano suelen llevar directivas solo de escritorio que la app móvil ignora o rechaza.

Sobre todo, no sustituyas la validación de certificados por "aceptar cualquier servidor" para que un ejemplo antiguo se conecte. Eso convierte un problema de compatibilidad en una elusión de la autenticación, y normalmente sobrevive hasta producción porque funciona.

El alcance es un contrato aparte

El teléfono tiene que llegar al punto final externo del servidor a través de la disposición real de subida. La traducción del router doméstico, el filtrado y el NAT del operador se sitúan todos en medio. Un nombre DNS dinámico solo da al punto final un nombre estable; no crea una ruta de entrada.

Después define qué puede alcanzar el cliente una vez conectado: prefijos privados o una salida completa a internet, sus rutas de reenvío y respuesta, el comportamiento de DNS, y si IPv6 entra en el alcance. Un inicio de sesión correcto no demuestra nada de eso.

Acepta el teléfono y el perfil previstos directamente, incluida una comprobación de que un recurso no autorizado sigue siendo inalcanzable y de que la revocación retira de verdad el acceso. El éxito con un cliente de escritorio valida ese cliente de escritorio, no el teléfono que tienes en la mano. El listado de OpenVPN Connect es un ejemplo concreto de una aplicación cliente que espera un servicio correspondiente.