Pi VPN-server: start med telefonens app, ikke med opskriften

De fleste Pi VPN-opsætninger starter med serveropskriften og ender med en telefon, der ikke kan forbinde. Rækkefølgen er omvendt. En telefonklient implementerer en bestemt protokol med en bestemt godkendelsesudveksling, og serveren skal matche den udveksling og ikke omvendt. Vælger du appen først, bliver en hel eftermiddags fejlsøgning til en kort tjekliste.

Rækkefølgen der sparer genopbygningen

Skriv telefonens styresystem og den præcise VPN-app ned, før du installerer noget på Pi'en. Det par bestemmer, hvilken protokol der overhovedet er mulig. En klientapp bliver ikke en anden klient, bare fordi en profil tilfældigvis indeholder et velkendt felt.

En delt hemmelighed i en profil eller et velkendt portnummer gør ikke én protokol til en anden. Udvekslingen matcher enten det, appen implementerer, eller den fejler på et tidspunkt, hvor du har meget lidt at læse. Der findes ingen diagnostik, der med almindelige ord siger "forkert protokol". Du får en timeout, en certifikatfejl eller en tavs gentagelsesløkke, og det hele ligner et serverproblem.

Når appen er låst, snævres servervalget ind, og resten af opsætningen har et mål.

Hvad telefonens app faktisk implementerer

En offentliggjort klientliste beskriver en applikation, ikke en tjeneste. Appen OpenVPN Connect til Android forventer en OpenVPN-server; den leverer ikke serversiden. Den bliver heller ikke en IPsec- eller L2TP-klient, når en profil ser ens ud.

Den forskel betyder mest, når du følger en ældre vejledning. Opskrifter skrevet til en protokol, som den nuværende app har droppet, installerer stadig rent på Pi'en og fejler stadig på telefonen, hvilket læses som en konfigurationsfejl snarere end en protokolukompatibilitet.

Tjek appens aktuelle dokumentation for de profilformater, den importerer, før du binder dig til en serverpakke. Fem minutters læsning slår en genopbygning.

Den firedelte aftale

Skriv fire ting ned og hold dem sammen: telefonens styresystem og appversion, serverimplementeringen på Pi'en, godkendelses- og tillidspolitikken og det eksterne endepunkt. Hver af de fire kan ugyldiggøre de andre tre.

En appopdatering, et skift af serverpakke eller en ny certifikatmyndighed bryder aftalen, og fejlen ser ens ud fra telefonen hver gang. Det er de fire nedskrevne ting, der gør det muligt at afgøre, hvilken del der flyttede sig.

Legitimationsoplysninger har hver sin opgave

Beslut, om profilen bruger klientcertifikater, brugernavn og adgangskode eller en understøttet kombination, og få begge ender til at stemme. Serverens identitet og det betroede CA-materiale skal også matche det, klienten accepterer.

CA'ens offentlige certifikat og dens private signeringsnøgle er forskellige objekter. Kun den offentlige del hører hjemme i en telefonprofil. Lægger du signeringsnøglen på en telefon, giver du evnen til at lave identiteter væk, hvilket er det modsatte af, hvad en CA er til for. Behandl den fil som det mest følsomme objekt i hele opsætningen.

Brug tjenestens understøttede eksport- og importflow i stedet for at sammensætte en profil i hånden. Håndbyggede profiler plejer at indeholde direktiver kun til skrivebordet, som mobilappen ignorerer eller afviser.

Frem for alt: erstat ikke certifikatvalidering med "accepter enhver server" for at få et gammelt eksempel til at forbinde. Det gør et kompatibilitetsproblem til en omgåelse af godkendelsen, og det overlever ofte til produktion, fordi det virker.

Tilgængelighed er en separat kontrakt

Telefonen skal nå serverens eksterne endepunkt gennem det virkelige upstreamarrangement. Hjemmerouterens oversættelse, filtrering og mobiloperatørens NAT ligger alle imellem. Et dynamisk DNS-navn giver kun endepunktet et stabilt navn; det skaber ikke en indgående vej.

Definér derefter, hvad klienten må nå efter forbindelsen: private præfikser eller en fuld internetudgang, deres videresendelses- og svarveje, DNS-adfærd og om IPv6 er omfattet. Et vellykket login beviser ingen af disse ting.

Accepter den tilsigtede telefon og profil direkte, inklusive et tjek af, at en uautoriseret ressource forbliver unåelig, og at tilbagekaldelse virkelig fjerner adgang. Succes med en skrivebordsklient bekræfter den skrivebordsklient, ikke telefonen i din hånd. Listen over OpenVPN Connect er et konkret eksempel på en klientapplikation, der forventer en matchende tjeneste.