Servidor VPN a la Raspberry Pi: comença per l'aplicació del telèfon, no per la recepta

La majoria de muntatges de VPN a la Raspberry Pi comencen per la recepta del servidor i acaben amb un telèfon que no es pot connectar. L'ordre és invers. El client del telèfon implementa un protocol concret amb un intercanvi d'autenticació concret, i el servidor ha de coincidir amb aquest intercanvi, no a l'inrevés. Decidir primer l'aplicació converteix una tarda de depuració en una llista de comprovació curta.

L'ordre que estalvia la reconstrucció

Anota el sistema operatiu del telèfon i l'aplicació VPN exacta abans d'instal·lar res a la Pi. Aquesta parella determina quin protocol és possible. Una aplicació client no es converteix en un altre client només perquè el perfil contingui un camp familiar.

Un secret compartit en un perfil, o un número de port que sembla familiar, no converteix un protocol en un altre. L'intercanvi o coincideix amb el que implementa l'aplicació, o falla en una etapa que et deixa molt poc per llegir. No hi ha cap diagnòstic que digui amb paraules planeres "protocol incorrecte". Reps un temps d'espera exhaurit, un error de certificat o un bucle de reintents silenciós, i tot això sembla un problema del servidor.

Un cop l'aplicació està fixada, l'elecció de servidor s'estreny i la resta del muntatge té un objectiu.

Què implementa realment l'aplicació del telèfon

Un llistat publicat de clients descriu una aplicació, no un servei. L'aplicació OpenVPN Connect per a Android espera un servidor OpenVPN; no ofereix la part del servidor. Tampoc no es converteix en client IPsec o L2TP quan un perfil sembla similar.

Aquesta distinció és més important quan segueixes una guia antiga. Les receptes escrites per a un protocol que l'aplicació actual ha abandonat s'instal·laran netament a la Pi i igualment fallaran al telèfon, cosa que es llegeix com un error de configuració i no com una discrepància de protocol.

Consulta la documentació actual de l'aplicació sobre els formats de perfil que importa abans de comprometre't amb un paquet de servidor. Cinc minuts de lectura valen més que una reconstrucció.

L'acord de quatre parts

Anota quatre coses i mantén-les juntes: el sistema operatiu i la versió de l'aplicació del telèfon, la implementació del servidor a la Pi, la política d'autenticació i confiança, i el punt final extern. Cadascuna de les quatre pot invalidar les altres tres.

Una actualització de l'aplicació, un canvi de paquet de servidor o una nova autoritat de certificació trenquen l'acord, i la fallada es veu idèntica des del telèfon cada vegada. Tenir les quatre anotades és el que et permet identificar quina part s'ha mogut.

Les credencials tenen feines separades

Decideix si el perfil fa servir certificats de client, un nom d'usuari i una contrasenya, o una combinació admesa, i fes que els dos extrems coincideixin. La identitat del servidor i el material del CA de confiança també han de coincidir amb el que el client acceptarà.

El certificat públic del CA i la seva clau privada de signatura són objectes diferents. Només la part pública pertany a un perfil de telèfon. Posar la clau de signatura en un telèfon regala la capacitat de fabricar identitats, que és el contrari del que serveix un CA. Tracta aquest fitxer com l'objecte més sensible de tot el muntatge.

Utilitza el flux d'exportació i importació admès pel servei en lloc de muntar un perfil a mà. Els perfils fets a mà solen portar directives només per a escriptori que l'aplicació mòbil ignora o rebutja.

Sobretot, no substitueixis la validació de certificats per "accepta qualsevol servidor" per fer que un exemple antic es connecti. Això converteix un problema de compatibilitat en una elusió de l'autenticació, i normalment sobreviu fins a producció perquè funciona.

L'abastabilitat és un contracte a part

El telèfon ha d'arribar al punt final extern del servidor a través de la disposició real d'upstream. La traducció del router de casa, el filtratge i el NAT de l'operador se situen tots dos entremig. Un nom DNS dinàmic només dona al punt final un nom estable; no crea cap camí d'entrada.

Després defineix què pot assolir el client un cop connectat: prefixos privats o una sortida completa a internet, les seves rutes de reenviament i resposta, el comportament del DNS i si IPv6 hi entra. Un inici de sessió correcte no demostra res d'això.

Accepta el telèfon i el perfil previstos directament, inclosa una comprovació que un recurs no autoritzat continua inabastable i que la revocació realment treu l'accés. L'èxit amb un client d'escriptori valida aquell client d'escriptori, no el telèfon que tens a la mà. El llistat d'OpenVPN Connect n'és un exemple concret d'una aplicació client que espera un servei corresponent.