Server VPN pe Raspberry Pi: începe cu aplicația din telefon, nu cu rețeta

Majoritatea montajelor VPN pe Raspberry Pi încep cu rețeta serverului și se termină cu un telefon care nu se poate conecta. Ordinea este inversă. Un client din telefon implementează un anumit protocol cu un anumit schimb de autentificare, iar serverul trebuie să corespundă acelui schimb, nu invers. Dacă alegi mai întâi aplicația, o întreagă după-amiază de depanare devine o listă scurtă de verificare.

Ordinea care economisește reconstrucția

Notează sistemul de operare al telefonului și aplicația VPN exactă înainte de a instala ceva pe Pi. Această pereche determină ce protocol este măcar posibil. O aplicație client nu devine alt client doar pentru că un profil conține din întâmplare un câmp cunoscut.

Un secret partajat într-un profil sau un număr de port care pare cunoscut nu transformă un protocol în altul. Schimbul fie corespunde cu ce implementează aplicația, fie eșuează într-o etapă care îți lasă foarte puțin de citit. Nu există niciun diagnostic care să spună în cuvinte simple "protocol greșit". Primești un timp expirat, o eroare de certificat sau o buclă mută de reîncercări, și toate par o problemă a serverului.

Odată ce aplicația este fixată, alegerea serverului se îngustează, iar restul montajului are o țintă.

Ce implementează de fapt aplicația din telefon

O listă publicată de clienți descrie o aplicație, nu un serviciu. Aplicația OpenVPN Connect pentru Android așteaptă un server OpenVPN; ea nu oferă partea de server. De asemenea, nu devine un client IPsec sau L2TP atunci când un profil pare similar.

Această distincție contează cel mai mult atunci când urmezi un ghid mai vechi. Rețetele scrise pentru un protocol pe care aplicația actuală l-a abandonat se instalează în continuare curat pe Pi și eșuează în continuare pe telefon, ceea ce se citește ca o eroare de configurare, nu ca o nepotrivire de protocol.

Verifică în documentația actuală a aplicației ce formate de profil importă înainte de a te angaja la un pachet de server. Cinci minute de citit valorează mai mult decât o reconstrucție.

Acordul în patru părți

Notează patru lucruri și ține-le împreună: sistemul de operare și versiunea aplicației din telefon, implementarea serverului pe Pi, politica de autentificare și încredere, și punctul final extern. Oricare dintre cele patru poate invalida celelalte trei.

O actualizare a aplicației, o schimbare a pachetului de server sau o nouă autoritate de certificare rup acordul, iar eșecul arată identic din telefon de fiecare dată. Tocmai cele patru notate îți permit să identifici care parte s-a mișcat.

Datele de autentificare au sarcini separate

Decide dacă profilul folosește certificate de client, nume de utilizator și parolă sau o combinație acceptată, și aliniază ambele capete. Identitatea serverului și materialul CA de încredere trebuie să corespundă și ele cu ce va accepta clientul.

Certificatul public al CA și cheia sa privată de semnare sunt obiecte diferite. Doar partea publică aparține unui profil de telefon. Plasarea cheii de semnare pe un telefon oferă capacitatea de a crea identități, ceea ce este opusul scopului unui CA. Tratează acel fișier ca pe cel mai sensibil obiect din întregul montaj.

Folosește fluxul de export și import acceptat de serviciu în loc să construiești un profil manual. Profilurile construite manual poartă de obicei directive doar pentru desktop pe care aplicația mobilă le ignoră sau le respinge.

Mai presus de toate, nu înlocui validarea certificatului cu "acceptă orice server" pentru a face un exemplu vechi să se conecteze. Asta transformă o problemă de compatibilitate într-o ocolire a autentificării, și de obicei supraviețuiește până în producție pentru că funcționează.

Accesibilitatea este un contract separat

Telefonul trebuie să ajungă la punctul final extern al serverului prin aranjamentul real din amonte. Traducerea routerului de acasă, filtrarea și NAT-ul operatorului stau toate între ele. Un nume DNS dinamic oferă punctului final doar un nume stabil; nu creează o cale de intrare.

Apoi definește ce poate atinge clientul după conectare: prefixe private sau o ieșire completă în internet, căile lor de redirecționare și răspuns, comportamentul DNS și dacă IPv6 este în scop. O autentificare reușită nu dovedește nimic din toate acestea.

Acceptă telefonul și profilul prevăzute direct, inclusiv o verificare că o resursă neautorizată rămâne inaccesibilă și că revocarea chiar înlătură accesul. Succesul cu un client de desktop validează acel client de desktop, nu telefonul din mâna ta. Lista OpenVPN Connect este un exemplu concret de aplicație client care așteaptă un serviciu corespunzător.