Pi-VPN-Server: Erst die App auf dem Handy, dann das Rezept

Die meisten Pi-VPN-Projekte beginnen mit dem Serverrezept und enden mit einem Handy, das sich nicht verbinden kann. Die Reihenfolge ist verkehrt herum. Ein Handy-Client implementiert ein bestimmtes Protokoll mit einem bestimmten Authentifizierungsaustausch, und der Server muss zu diesem Austausch passen, nicht umgekehrt. Wer zuerst die App festlegt, macht aus einem Nachmittag Fehlersuche eine kurze Checkliste.

Die Reihenfolge, die den Neuaufbau spart

Notieren Sie das Betriebssystem des Handys und die genaue VPN-App, bevor Sie etwas auf dem Pi installieren. Dieses Paar entscheidet, welches Protokoll überhaupt möglich ist. Eine Client-App wird nicht dadurch ein anderer Client, dass ein Profil zufällig ein bekanntes Feld enthält.

Ein gemeinsames Geheimnis in einem Profil oder eine vertraut wirkende Portnummer macht aus einem Protokoll kein anderes. Der Austausch passt entweder zu dem, was die App implementiert, oder er scheitert in einer Phase, die Ihnen sehr wenig zum Lesen gibt. Es gibt keine Diagnose, die mit einfachen Worten "falsches Protokoll" sagt. Sie bekommen eine Zeitüberschreitung, einen Zertifikatsfehler oder eine stille Wiederholungsschleife, und alles davon sieht nach einem Serverproblem aus.

Ist die App festgelegt, verengt sich die Serverwahl, und der Rest des Aufbaus hat ein Ziel.

Was die Handy-App tatsächlich implementiert

Eine veröffentlichte Client-Liste beschreibt eine Anwendung, keinen Dienst. Die App OpenVPN Connect für Android erwartet einen OpenVPN-Server; sie stellt die Serverseite nicht bereit. Sie wird auch kein IPsec- oder L2TP-Client, wenn ein Profil ähnlich aussieht.

Dieser Unterschied zählt am meisten, wenn Sie einer älteren Anleitung folgen. Rezepte für ein Protokoll, das die aktuelle App aufgegeben hat, lassen sich weiterhin sauber auf dem Pi installieren und scheitern weiterhin auf dem Handy, was wie ein Konfigurationsfehler und nicht wie eine Protokollabweichung aussieht.

Prüfen Sie in der aktuellen Dokumentation der App, welche Profilformate sie importiert, bevor Sie sich auf ein Serverpaket festlegen. Fünf Minuten Lesen sind besser als ein Neuaufbau.

Die vierteilige Vereinbarung

Notieren Sie vier Dinge und halten Sie sie zusammen: das Betriebssystem und die App-Version des Handys, die Serverimplementierung auf dem Pi, die Authentifizierungs- und Vertrauensrichtlinie und den externen Endpunkt. Jedes der vier kann die anderen drei ungültig machen.

Ein App-Upgrade, ein Wechsel des Serverpakets oder eine neue Zertifizierungsstelle brechen die Vereinbarung, und der Fehler sieht vom Handy jedes Mal gleich aus. Gerade die schriftlich festgehaltenen vier Punkte erlauben es, den bewegten Teil zu benennen.

Anmeldedaten haben getrennte Aufgaben

Entscheiden Sie, ob das Profil Client-Zertifikate, einen Benutzernamen mit Passwort oder eine unterstützte Kombination verwendet, und bringen Sie beide Seiten zur Übereinstimmung. Die Identität des Servers und das vertrauenswürdige CA-Material müssen ebenfalls zu dem passen, was der Client akzeptiert.

Das öffentliche Zertifikat der CA und ihr privater Signaturschlüssel sind verschiedene Objekte. Nur der öffentliche Teil gehört in ein Handyprofil. Wer den Signaturschlüssel auf ein Handy legt, gibt die Fähigkeit aus, Identitäten zu erzeugen, was dem Zweck einer CA widerspricht. Behandeln Sie diese Datei als das empfindlichste Objekt des gesamten Aufbaus.

Nutzen Sie den unterstützten Export- und Importablauf des Dienstes, statt ein Profil von Hand zusammenzusetzen. Selbstgebaute Profile tragen meist reine Desktop-Direktiven, die die mobile App ignoriert oder ablehnt.

Vor allem: Ersetzen Sie die Zertifikatsprüfung nicht durch "jeden Server akzeptieren", um ein altes Beispiel zum Verbinden zu bringen. Das verwandelt ein Kompatibilitätsproblem in eine Umgehung der Authentifizierung, und sie überlebt meist bis in die Produktion, weil sie funktioniert.

Erreichbarkeit ist ein eigener Vertrag

Das Handy muss den externen Endpunkt des Servers über die tatsächliche vorgelagerte Anordnung erreichen. Die Adressübersetzung des Heimrouters, Filterung und das NAT des Mobilfunkanbieters liegen alle dazwischen. Ein dynamischer DNS-Name gibt dem Endpunkt nur einen stabilen Namen; er schafft keinen eingehenden Pfad.

Definieren Sie dann, was der Client nach dem Verbinden erreichen darf: private Präfixe oder einen vollständigen Internetausgang, ihre Weiterleitungs- und Antwortpfade, das DNS-Verhalten und ob IPv6 im Umfang liegt. Eine erfolgreiche Anmeldung beweist nichts davon.

Akzeptieren Sie das vorgesehene Handy und Profil direkt, einschließlich der Prüfung, dass eine nicht autorisierte Ressource unerreichbar bleibt und dass ein Widerruf den Zugang tatsächlich entfernt. Erfolg mit einem Desktop-Client bestätigt diesen Desktop-Client, nicht das Handy in Ihrer Hand. Die Liste von OpenVPN Connect ist ein konkretes Beispiel für eine Client-Anwendung, die einen passenden Dienst erwartet.