Pi VPN-server: börja med appen i telefonen, inte med receptet

De flesta Pi VPN-byggen börjar med serverreceptet och slutar med en telefon som inte kan ansluta. Ordningen är omvänd. En telefonklient implementerar ett visst protokoll med ett visst autentiseringsutbyte, och servern måste matcha det utbytet, inte tvärtom. Väljer du appen först blir en hel eftermiddags felsökning till en kort checklista.

Ordningen som sparar ombygget

Skriv ned telefonens operativsystem och den exakta VPN-appen innan du installerar något på Pi. Det paret avgör vilket protokoll som ens är möjligt. En klientapp blir inte en annan klient bara för att en profil råkar innehålla ett bekant fält.

En delad hemlighet i en profil, eller ett portnummer som ser bekant ut, gör inte ett protokoll till ett annat. Utbytet stämmer antingen med det appen implementerar, eller misslyckas i ett skede som ger dig mycket lite att läsa. Det finns ingen diagnostik som säger "fel protokoll" med enkla ord. Du får en tidsgräns, ett certifikatfel eller en tyst återförsöksslinga, och allt detta ser ut som ett serverproblem.

När appen är låst smalnar servervalet av och resten av bygget har ett mål.

Vad telefonappen faktiskt implementerar

En publicerad klientlista beskriver en applikation, inte en tjänst. Appen OpenVPN Connect för Android förväntar sig en OpenVPN-server; den tillhandahåller inte serversidan. Den blir inte heller en IPsec- eller L2TP-klient när en profil ser likadan ut.

Den skillnaden spelar störst roll när du följer en äldre guide. Recept skrivna för ett protokoll som den nuvarande appen har övergett installeras fortfarande rent på Pi och misslyckas fortfarande i telefonen, vilket läses som ett konfigurationsfel och inte som en protokollavvikelse.

Kontrollera appens aktuella dokumentation för vilka profilformat den importerar innan du binder dig till ett serverpaket. Fem minuters läsning slår en ombyggnad.

Den fyrdelade överenskommelsen

Skriv ned fyra saker och håll dem tillsammans: telefonens operativsystem och appversion, serverimplementeringen på Pi, autentiserings- och förtroendepolicyn och den externa slutpunkten. Var och en av de fyra kan ogiltigförklara de andra tre.

En appuppdatering, ett byte av serverpaket eller en ny certifikatutfärdare bryter överenskommelsen, och felet ser likadant ut från telefonen varje gång. Det är just de fyra nedskrivna som gör det möjligt att identifiera vilken del som flyttade sig.

Inloggningsuppgifter har separata uppgifter

Bestäm om profilen använder klientcertifikat, användarnamn och lösenord eller en kombination som stöds, och få båda ändarna att stämma. Serverns identitet och det betrodda CA-materialet måste också matcha det klienten accepterar.

CA:ns offentliga certifikat och dess privata signeringsnyckel är olika objekt. Bara den offentliga delen hör hemma i en telefonprofil. Att lägga signeringsnyckeln på en telefon ger bort förmågan att skapa identiteter, vilket är motsatsen till vad en CA är till för. Behandla filen som det mest känsliga objektet i hela bygget.

Använd tjänstens stödda export- och importflöde i stället för att sätta ihop en profil för hand. Handbyggda profiler brukar bära direktiv bara för skrivbordet, som mobilappen ignorerar eller avvisar.

Framför allt: ersätt inte certifikatvalidering med "acceptera vilken server som helst" för att få ett gammalt exempel att ansluta. Det gör ett kompatibilitetsproblem till en kringgång av autentiseringen, och det överlever ofta ända till produktion eftersom det fungerar.

Nåbarhet är ett separat avtal

Telefonen måste nå serverns externa slutpunkt genom det verkliga uppströmsarrangemanget. Hemmarouterns översättning, filtrering och mobiloperatörens NAT ligger alla däremellan. Ett dynamiskt DNS-namn ger bara slutpunkten ett stabilt namn; det skapar inte en inkommande väg.

Definiera sedan vad klienten får nå när den är ansluten: privata prefix eller en full internetutgång, deras vidarebefordrings- och svarsvägar, DNS-beteende, och om IPv6 ingår. En lyckad inloggning bevisar inget av detta.

Acceptera den avsedda telefonen och profilen direkt, inklusive en kontroll att en obehörig resurs förblir onåbar och att återkallelse verkligen tar bort åtkomst. Framgång med en skrivbordsklient bekräftar den skrivbordsklienten, inte telefonen i din hand. Listan över OpenVPN Connect är ett konkret exempel på en klientapplikation som förväntar sig en matchande tjänst.