Server VPN su Raspberry Pi: parti dall’app del telefono, non dalla ricetta

La maggior parte dei montaggi VPN su Raspberry Pi inizia con la ricetta del server e finisce con un telefono che non riesce a connettersi. L’ordine è invertito. Un client sul telefono implementa un protocollo preciso con uno scambio di autenticazione preciso, e il server deve corrispondere a quello scambio, non il contrario. Scegliere prima l’app trasforma un pomeriggio di debug in una breve lista di controllo.

L’ordine che risparmia la ricostruzione

Annota il sistema operativo del telefono e l’app VPN esatta prima di installare qualsiasi cosa sul Pi. Questa coppia determina quale protocollo sia anche solo possibile. Un’app client non diventa un altro client perché un profilo contiene per caso un campo familiare.

Un segreto condiviso in un profilo, o un numero di porta che sembra familiare, non trasforma un protocollo in un altro. Lo scambio o corrisponde a ciò che l’app implementa, o fallisce in una fase che ti lascia pochissimo da leggere. Non esiste una diagnostica che dica in parole semplici «protocollo sbagliato». Ottieni un timeout, un errore di certificato o un ciclo di tentativi silenzioso, e tutto questo sembra un problema del server.

Una volta fissata l’app, la scelta del server si restringe e il resto del montaggio ha un obiettivo.

Cosa implementa davvero l’app del telefono

Una scheda cliente pubblicata descrive un’applicazione, non un servizio. L’app OpenVPN Connect per Android attende un server OpenVPN; non fornisce il lato server. Non diventa nemmeno un client IPsec o L2TP quando un profilo sembra simile.

Questa distinzione conta soprattutto quando segui una guida più vecchia. Le ricette scritte per un protocollo che l’app attuale ha abbandonato si installano ancora in modo pulito sul Pi e falliscono ancora sul telefono, il che si legge come un errore di configurazione e non come una discrepanza di protocollo.

Controlla nella documentazione attuale dell’app quali formati di profilo importa prima di impegnarti su un pacchetto server. Cinque minuti di lettura valgono più di una ricostruzione.

L’accordo in quattro parti

Annota quattro cose e tienile insieme: il sistema operativo e la versione dell’app del telefono, l’implementazione server sul Pi, la politica di autenticazione e fiducia, e l’endpoint esterno. Ognuna delle quattro può invalidare le altre tre.

Un aggiornamento dell’app, un cambio di pacchetto server o una nuova autorità di certificazione rompono l’accordo, e il guasto si vede identico dal telefono ogni volta. Sono le quattro annotate che permettono di capire quale parte si è spostata.

Le credenziali hanno compiti separati

Decidi se il profilo usa certificati client, un nome utente e una password, o una combinazione supportata, e fai coincidere le due estremità. Anche l’identità del server e il materiale della CA fidata devono corrispondere a ciò che il client accetterà.

Il certificato pubblico della CA e la sua chiave privata di firma sono oggetti diversi. Solo la parte pubblica appartiene a un profilo del telefono. Mettere la chiave di firma su un telefono regala la capacità di creare identità, che è l’opposto di ciò a cui serve una CA. Tratta quel file come l’oggetto più sensibile di tutto il montaggio.

Usa il flusso di esportazione e importazione supportato dal servizio invece di assemblare un profilo a mano. I profili costruiti a mano tendono a portare direttive solo per desktop che l’app mobile ignora o rifiuta.

Soprattutto, non sostituire la validazione del certificato con «accetta qualsiasi server» per far connettere un esempio vecchio. Questo trasforma un problema di compatibilità in un aggiramento dell’autenticazione, e di solito sopravvive fino alla produzione perché funziona.

La raggiungibilità è un contratto a parte

Il telefono deve raggiungere l’endpoint esterno del server attraverso la disposizione reale a monte. La traduzione del router domestico, il filtraggio e il NAT dell’operatore stanno tutti in mezzo. Un nome DNS dinamico dà all’endpoint solo un nome stabile; non crea un percorso in ingresso.

Poi definisci cosa il client può raggiungere una volta connesso: prefissi privati o un’uscita internet completa, i loro percorsi di inoltro e risposta, il comportamento del DNS, e se IPv6 rientra nell’ambito. Un accesso riuscito non dimostra nulla di tutto ciò.

Accetta direttamente il telefono e il profilo previsti, inclusa una verifica che una risorsa non autorizzata resti irraggiungibile e che la revoca rimuova davvero l’accesso. Il successo con un client desktop convalida quel client desktop, non il telefono nella tua mano. La scheda di OpenVPN Connect è un esempio concreto di un’app client che attende un servizio corrispondente.