Wie ein GXP21xx-Telefon seinen eigenen OpenVPN-Tunnel aufbaut

Ein Tischtelefon, das sich mit dem Büro-VPN verbindet, ist ein verwalteter Endpunkt mit eigener Firmware, eigener Identität und eigenem Wiederherstellungspfad. Der eingebettete Client ist keine Desktop-Installation von OpenVPN mit kleinerem Bildschirm, und genau diese Annahme führt dazu, dass ein Telefon am Ende einen gemeinsamen Schlüssel und eine Richtlinie hält, die niemand genehmigt hat. Das passiert tatsächlich zwischen Telefon und Gateway.

Was das Telefon beim Start lädt

Lesen Sie die Systeminformationen am Gerät, bevor Sie irgendetwas vorbereiten. Das Administrationshandbuch der GXP21xx-Serie bezeichnet die Programmversion als das Haupt-Firmware-Release und zeigt ein Feld für den OpenVPN-Supportstatus, das Ihnen sagt, ob Ihr Build diese Funktion überhaupt beansprucht.

Anschließend beschreibt das Handbuch zwei Konfigurationsmodi. Der einfache Modus bietet einzelne Felder: Serveradresse, Port, Transport und hochgeladenes Zertifikatsmaterial. Der Expertenmodus nimmt ein Konfigurations-ZIP. Das sind zwei verschiedene Ladepfade in denselben Client, und das Paketformat zählt genauso viel wie der Inhalt.

Ein beliebiges Desktop-File vom Typ .ovpn in ein ZIP zu werfen, stellt keine Kompatibilität her. Das Telefon interpretiert, was seine Firmware erwartet, und eine Datei, die auf einem Laptop funktioniert, kann hier stillschweigend ignoriert werden.

Was der Client ausdrücken muss

Holen Sie die Profilanforderungen zuerst beim Gateway-Betreiber ein: Endpunkt, Transport, Peer-Verifikation, Authentifizierung, erforderliche Algorithmen und die privaten Ressourcen, die das Telefon erreichen darf. Prüfen Sie dann, ob die eingebettete Implementierung diesen Vertrag ausdrücken kann.

Diese Reihenfolge ist wichtig, denn die Alternative ist, das gemeinsame Gateway für ein einziges Telefon zu ändern. Jede Lockerung, die Sie für das Telefon vornehmen, gilt für jeden anderen Client an diesem Endpunkt, und das ist ein schlechter Tausch für ein Gerät, das telefoniert.

Lautet die Antwort, dass der Build die Richtlinie nicht erfüllen kann, sind die ehrlichen Optionen eine unterstützte Firmware oder ein unterstütztes Gerät oder eine genehmigte Gateway-Regelung für Voice-Endpunkte. Den Tunnel abzuschwächen gehört nicht dazu.

Komprimierung und alte Rezepte

Ältere Rezepte für kleine Geräte aktivieren oft die Komprimierung, um Bandbreite zu sparen. OpenVPN 2.6 stuft die Komprimierung als veraltet ein und rät im Allgemeinen davon ab, daher ist eine aus einem solchen Rezept kopierte Konfiguration keine aktuelle Sicherheitsfreigabe, egal in welchem Jahr der Forumsbeitrag geschrieben wurde.

Dasselbe gilt für Identitätsprüfungen. Wenn ein Profil nur mit deaktivierter Peer-Verifikation verbindet, ist das Profil das Problem, nicht die Verifikation. Reparieren Sie das Vertrauensmaterial, statt dem Gerät beizubringen, die Prüfung zu überspringen.

Ein Gerät, eine Identität

Drei Teile Material haben drei Rollen. Das CA-Vertrauenszertifikat lässt das Telefon den Aussteller prüfen. Das Telefonzertifikat identifiziert dieses Gerät. Der private Schlüssel des Telefons ist sensibles Gerätematerial und bleibt auf dem Gerät.

Der CA-Signaturschlüssel gehört niemals auf ein Telefon. Ebenso wenig das Laptop-Profil eines Administrators, das über eine Flotte kopiert wird und so aus einem gestohlenen Telefon eine Anmeldeinformation für jedes Telefon macht.

Das Handbuch zeigt außerdem ein Client-Key-Passwort sowie optionale Felder für VPN-Benutzername und Passwort. Diese sind nicht automatisch die Zugangsdaten der SIP-Nebenstelle. Legen Sie die Authentifizierungsregelung für dieses Gerät fest, einschließlich der Frage, wie es nach einem unbeaufsichtigten Neustart erforderliche Eingaben erhält.

Liefern Sie das Material über Ihren geschützten Bereitstellungsprozess aus und erfassen Sie das Gerät, die ausgegebene Identität und den Verantwortlichen für die Außerbetriebnahme. Wenn das Telefon ersetzt wird, ist dieser Eintrag der Unterschied zwischen einem Fünf-Minuten-Tausch und einem Nachmittag voller Vermutungen.

Halten Sie den Administrationspfad offen

Bevor Sie den Tunnel aktivieren, bestätigen Sie, dass Sie die Weboberfläche oder den Bereitstellungspfad des Telefons noch erreichen. Das Gerät braucht gewöhnlichen Netzwerkzugriff, um überhaupt den VPN-Endpunkt zu erreichen, und sein Verwaltungspfad sollte nicht mitten in der Registrierung verschwinden.

Wenn eine Routenänderung während der Registrierung Sie aussperrt, ist die Wiederherstellung meist ein Werksreset und eine Wiederholung des gesamten Ablaufs. Planen Sie die Reihenfolge so, dass das nie passiert: bereitstellen, Erreichbarkeit prüfen, dann den Tunnel aktivieren.

Nehmen Sie das Gespräch an, nicht den Tunnel

Das SIP-Konto bleibt eine separate Konfiguration. Das GXP21xx-Handbuch verweist bei einer OpenVPN-Bereitstellung auf die VPN-NAT-Traversal-Einstellung des Kontos, prüfen Sie also diese Vorgabe für die installierte Firmware und Ihr PBX-Design, statt STUN-, Proxy- und VPN-Änderungen zu kombinieren, ohne zu wissen, welcher Verantwortliche sie braucht.

Prüfen Sie dann den vorgesehenen PBX-Namen und den privaten Pfad, bestätigen Sie die SIP-Registrierung und führen Sie genehmigte eingehende und ausgehende Anrufe mit in beide Richtungen geprüftem Audio durch. Testen Sie die Anruffunktionen, die die Bereitstellung wirklich braucht, denn eine Registrierungsanzeige ist kein funktionierendes Telefon.

Wiederholen Sie das abschließend aus einem kontrollierten Kaltstart und nach einer Netzwerkunterbrechung. Beobachten Sie, ob das Telefon Tunnel, Konto und nutzbare Telefonie in der vorgesehenen Reihenfolge wiederherstellt, und bestätigen Sie das angegebene Verhalten, wenn der Tunnel keine Verbindung herstellen kann. Das Administrationshandbuch der GXP21xx-Serie ist die Referenz für die oben beschriebenen Felder.