Pi VPN-server: begin bij de app op de telefoon, niet bij het recept

De meeste Pi VPN-opbouwen beginnen met het serverrecept en eindigen met een telefoon die geen verbinding krijgt. De volgorde is omgekeerd. Een telefoonclient implementeert een bepaald protocol met een bepaalde authenticatie-uitwisseling, en de server moet bij die uitwisseling passen, niet andersom. Wie eerst de app vastlegt, maakt van een hele middag debuggen een korte checklist.

De volgorde die de herbouw bespaart

Noteer het besturingssysteem van de telefoon en de exacte VPN-app voordat je iets op de Pi installeert. Dat paar bepaalt welk protocol überhaupt mogelijk is. Een client-app wordt geen andere client doordat een profiel toevallig een bekend veld bevat.

Een gedeeld geheim in een profiel, of een poortnummer dat bekend voorkomt, maakt van het ene protocol geen andere. De uitwisseling past ofwel bij wat de app implementeert, ofwel mislukt in een fase die je heel weinig te lezen geeft. Er bestaat geen diagnose die met eenvoudige woorden "verkeerd protocol" zegt. Je krijgt een time-out, een certificaatfout of een stille herhalingslus, en dat alles lijkt op een serverprobleem.

Zodra de app vastligt, wordt de serverkeuze smaller en heeft de rest van de opbouw een doel.

Wat de telefoonapp feitelijk implementeert

Een gepubliceerde clientlijst beschrijft een toepassing, geen dienst. De app OpenVPN Connect voor Android verwacht een OpenVPN-server; hij levert de serverkant niet. Hij wordt ook geen IPsec- of L2TP-client wanneer een profiel er hetzelfde uitziet.

Dat onderscheid telt het meest bij het volgen van een oudere handleiding. Recepten geschreven voor een protocol dat de huidige app heeft laten vallen, installeren nog steeds schoon op de Pi en falen nog steeds op de telefoon, wat leest als een configuratiefout en niet als een protocolafwijking.

Controleer in de actuele documentatie van de app welke profielformaten hij importeert voordat je je aan een serverpakket bindt. Vijf minuten lezen is beter dan een herbouw.

De vierdelige afspraak

Noteer vier dingen en houd ze bij elkaar: het besturingssysteem en de app-versie van de telefoon, de serverimplementatie op de Pi, het authenticatie- en vertrouwensbeleid, en het externe eindpunt. Elk van de vier kan de andere drie ongeldig maken.

Een app-upgrade, een wissel van serverpakket of een nieuwe certificaatautoriteit breekt de afspraak, en de fout ziet er vanaf de telefoon elke keer hetzelfde uit. Juist de vier opgeschreven punten maken het mogelijk te herkennen welk deel is verschoven.

Inloggegevens hebben aparte taken

Bepaal of het profiel clientcertificaten, een gebruikersnaam en wachtwoord of een ondersteunde combinatie gebruikt, en breng beide kanten in overeenstemming. De identiteit van de server en het vertrouwde CA-materiaal moeten ook passen bij wat de client accepteert.

Het openbare certificaat van de CA en de bijbehorende persoonlijke ondertekeningssleutel zijn verschillende objecten. Alleen het openbare deel hoort in een telefoonprofiel. De ondertekeningssleutel op een telefoon zetten geeft de mogelijkheid identiteiten te maken weg, wat het tegenovergestelde is van waar een CA voor dient. Behandel dat bestand als het gevoeligste object van de hele opbouw.

Gebruik de door de dienst ondersteunde export- en importstroom in plaats van een profiel met de hand samen te stellen. Handmatig gebouwde profielen bevatten meestal alleen desktoprichtlijnen die de mobiele app negeert of weigert.

Bovenal: vervang certificaatvalidatie niet door "accepteer elke server" om een oud voorbeeld te laten verbinden. Dat maakt van een compatibiliteitsprobleem een omzeiling van de authenticatie, en het overleeft meestal tot in productie omdat het werkt.

Bereikbaarheid is een apart contract

De telefoon moet het externe eindpunt van de server bereiken via de werkelijke upstreamopstelling. De vertaling van de thuisrouter, filtering en de NAT van de provider zitten er allemaal tussen. Een dynamische DNS-naam geeft het eindpunt alleen een stabiele naam; hij maakt geen inkomende route.

Definieer daarna wat de client mag bereiken zodra hij verbonden is: privé-prefixen of een volledige internetuitgang, hun doorstuur- en antwoordroutes, het DNS-gedrag, en of IPv6 binnen bereik valt. Een geslaagde aanmelding bewijst daar niets van.

Accepteer de bedoelde telefoon en het profiel rechtstreeks, inclusief een controle dat een niet-geautoriseerde bron onbereikbaar blijft en dat intrekking de toegang echt verwijdert. Succes met een desktopclient bevestigt die desktopclient, niet de telefoon in je hand. De lijst van OpenVPN Connect is een concreet voorbeeld van een clientapplicatie die een passende dienst verwacht.