Pi VPN-server: start med appen på telefonen, ikke med oppskriften

De fleste Pi VPN-oppsett begynner med serveroppskriften og ender med en telefon som ikke får koblet til. Rekkefølgen er motsatt. En telefonklient implementerer en bestemt protokoll med en bestemt autentiseringsutveksling, og serveren må samsvare med den utvekslingen, ikke omvendt. Velger du appen først, blir en hel ettermiddag med feilsøking til en kort sjekkliste.

Rekkefølgen som sparer gjenoppbyggingen

Skriv ned telefonens operativsystem og den nøyaktige VPN-appen før du installerer noe på Pi-en. Det paret avgjør hvilken protokoll som i det hele tatt er mulig. En klientapp blir ikke en annen klient bare fordi en profil tilfeldigvis inneholder et kjent felt.

En delt hemmelighet i en profil, eller et portnummer som ser kjent ut, gjør ikke én protokoll til en annen. Utvekslingen samsvarer enten med det appen implementerer, eller den feiler i en fase som gir deg svært lite å lese. Det finnes ingen diagnostikk som sier "feil protokoll" med enkle ord. Du får en tidsavbrudd, en sertifikatfeil eller en stille gjentakelsesløkke, og alt dette ser ut som et serverproblem.

Når appen er låst, snevres servervalget inn, og resten av oppsettet har et mål.

Hva telefonappen faktisk implementerer

En publisert klientliste beskriver en applikasjon, ikke en tjeneste. Appen OpenVPN Connect for Android forventer en OpenVPN-server; den leverer ikke serversiden. Den blir heller ikke en IPsec- eller L2TP-klient når en profil ser lik ut.

Den forskjellen betyr mest når du følger en eldre veiledning. Oppskrifter skrevet for en protokoll som den nåværende appen har forlatt, installeres fortsatt rent på Pi-en og feiler fortsatt på telefonen, noe som leses som en konfigurasjonsfeil og ikke som en protokollavvik.

Sjekk appens gjeldende dokumentasjon for hvilke profilformater den importerer før du binder deg til en serverpakke. Fem minutters lesing slår en gjenoppbygging.

Den firedelte avtalen

Skriv ned fire ting og hold dem sammen: telefonens operativsystem og appversjon, serverimplementasjonen på Pi-en, autentiserings- og tillitspolicyen og det eksterne endepunktet. Hver av de fire kan ugyldiggjøre de andre tre.

En appoppdatering, et bytte av serverpakke eller en ny sertifiseringsinstans bryter avtalen, og feilen ser lik ut fra telefonen hver gang. Det er de fire nedskrevne punktene som gjør det mulig å identifisere hvilken del som flyttet seg.

Påloggingsdetaljer har separate jobber

Bestem om profilen bruker klient-sertifikater, brukernavn og passord eller en støttet kombinasjon, og få begge ender til å stemme. Serverens identitet og det betrodde CA-materialet må også samsvare med det klienten godtar.

CA-ens offentlige sertifikat og dens private signeringsnøkkel er forskjellige objekter. Bare den offentlige delen hører hjemme i en telefonprofil. Legger du signeringsnøkkelen på en telefon, gir du bort evnen til å lage identiteter, noe som er det motsatte av det en CA er til for. Behandle filen som det mest følsomme objektet i hele oppsettet.

Bruk tjenestens støttede eksport- og importflyt i stedet for å sette sammen en profil for hånd. Håndbygde profiler har vanligvis direktiver bare for skrivebordet, som mobilappen ignorerer eller avviser.

Fremfor alt: ikke erstatt sertifikatvalidering med "godta enhver server" for å få et gammelt eksempel til å koble til. Det gjør et kompatibilitetsproblem om til en omgåelse av autentisering, og det overlever ofte til produksjon fordi det virker.

Tilgjengelighet er en egen kontrakt

Telefonen må nå serverens eksterne endepunkt gjennom den virkelige oppstrømsordningen. Hjemmeruterens oversettelse, filtrering og mobiloperatørens NAT ligger alle imellom. Et dynamisk DNS-navn gir bare endepunktet et stabilt navn; det skaper ikke en innkommende vei.

Definer deretter hva klienten kan nå etter tilkobling: private prefikser eller en full internettutgang, deres videresendings- og svarveier, DNS-atferd, og om IPv6 er innenfor omfanget. En vellykket innlogging beviser ingen av disse.

Godta den tiltenkte telefonen og profilen direkte, inkludert en sjekk av at en uautorisert ressurs forblir utilgjengelig og at tilbakekalling faktisk fjerner tilgang. Suksess med en skrivebordsklient bekrefter den skrivebordsklienten, ikke telefonen i hånden din. Listen over OpenVPN Connect er et konkret eksempel på en klientapplikasjon som forventer en samsvarende tjeneste.