Access Server verlor seine Bindung nach dem Umbenennen einer Netzwerkschnittstelle: Schlüssel reparieren

Sie haben eine Netzwerkschnittstelle umbenannt oder eine Maschine wiederhergestellt, deren Adapter unter einem anderen Namen zurückkam, und nun startet der OpenVPN Access Server-Daemon nicht. Die Weboberfläche antwortet vielleicht noch oder auch nicht, je nachdem, welche Komponente an den alten Namen gebunden war. Der Dienst ist nicht beschädigt, die Konfiguration ist nicht verloren; eine Einstellung zeigt weiterhin auf eine Schnittstelle, die der Host nicht mehr hat.

Der Reflex ist, neu zu installieren, neu zu initialisieren oder die Datenbank zu bearbeiten, bis der Fehler verschwindet. Jedes davon ist ein größerer Eingriff als der Fehler, und das letzte kann die Benutzer, Berechtigungen und Profilabhängigkeiten löschen, die den Server die Rettung wert machten. Es ist ein Bindungsproblem, und es hat eine benannte Lösung.

Was das Symptom tatsächlich sagt

Ein Daemon, der nicht binden kann, sagt das meist in seinem eigenen Protokoll: Die Adresse ist nicht verfügbar oder die Schnittstelle existiert nicht. Die Meldung ist konkret: Sie nennt die Adresse, die der Daemon versucht hat; vergleichen Sie sie mit ip -br addr auf dem Host, um zu sehen, ob die Schnittstelle umbenannt, entfernt oder ohne ihre alte Adresse hochgefahren wurde.

Halten Sie durchgehend eine autorisierte Wiederherstellungskonsole offen. Trägt die Bindung, die Sie ändern wollen, Ihre einzige administrative Sitzung, haben Sie sich den Rückweg abgeschnitten. Eine lokale Konsole, eine zweite Verwaltungsadresse oder ein dokumentierter Out-of-Band-Weg machen die Änderung umkehrbar.

Fragen Sie die Konfiguration ab, bevor Sie sie bearbeiten

Access Server stellt seine Serverkonfiguration über seine eigene CLI bereit. Die dokumentierte Ansicht ist:

sacli ConfigQuery

Führen Sie sie in der für Ihre Version dokumentierten administrativen Umgebung aus, nicht aus einer unabhängigen Shell auf einem anderen Host. Sichern Sie die aktuellen Werte an einem geschützten Ort, bevor Sie etwas ändern, und fügen Sie die vollständige Ausgabe nicht in einen öffentlichen Support-Thread ein.

Diese Ausgabe ist eine Ansicht der Serverkonfiguration, kein vollständiges Backup. Benutzer- und Gruppeneigenschaften werden getrennt abgefragt, sodass eine saubere Bindung keine Identitäten wiederherstellt und eine wiederhergestellte Identität keinen Listener repariert. Erfassen Sie beides als zwei getrennte Artefakte.

Stellen Sie fest, welcher Listener defekt ist

Access Server betreibt mehr als einen Listener. Die OpenVPN-Daemons tragen Tunnelverkehr, der Webdienst trägt das Admin- und Kundenportal, andere Komponenten können eigene Ports haben. Eine fehlgeschlagene Browseranfrage sagt Ihnen nicht, welche davon ausgefallen ist, und die Portnummer in einer Fehlermeldung auch nicht.

Die Bindungsschlüssel des Daemons sind pro Daemon dokumentiert, und im offiziellen Tutorial ist der Wert die Schnittstellenkennung, obwohl die Schlüsselnamen auf ip_address enden. Lesen Sie diesen Satz zweimal. Das Tutorial erwartet außerdem, dass sich UDP- und TCP-Daemon eine Schnittstelle teilen, sodass die Korrektur nur eines Schlüssels eine Teilreparatur ist.

Ändern Sie die benannte Einstellung, nicht passende Zeilen

Das Tutorial dokumentiert ConfigPut auf bestimmten Schlüsseln wie vpn.daemon.0.server.ip_address und vpn.daemon.0.listen.ip_address. Verwenden Sie die produktspezifische Methode mit Schlüsselnamen und neuem Wert in der für Ihre Version dokumentierten Syntax und ändern Sie nur die Schlüssel des Listeners, den Sie diagnostiziert haben.

Was Sie nicht tun sollten, ist, die Datenbank nach jeder Zeile zu durchsuchen, deren Wert dem alten Schnittstellennamen entspricht, und alle zu ersetzen. Das setzt voraus, dass der alte Name nur in Listener-Einstellungen vorkam, was das Schema nicht zusichert. Außerdem macht es die Änderung unüberprüfbar.

Zwei weitere Versuchungen sollten Sie ablehnen. Einen Standard wiederherzustellen, der auf allen Schnittstellen lauscht, ist eine Entscheidung über die Exposition, keine Schreibkorrektur; die beabsichtigte lokale Bindung, der veröffentlichte Pfad und die Filterung davor müssen dazu passen. Eine Neuinitialisierung der Konfiguration benennt das Problem um, statt es zu lösen, denn eine frische Installation verwirft genau die Benutzer und Berechtigungen, die vor dem Umbenennen funktionierten.

Wenden Sie es an und beweisen Sie, dass der Pfad funktioniert

Nach der Korrektur wenden Sie den Wert über den dokumentierten Lebenszyklus des Produkts an ( Lebenszyklus ). Das Tutorial verwendet sacli start nach dem Setzen der Schlüssel; das ist kein vollständiger Host-Neustart und kein Datenbank-Reset.

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

Prüfen Sie den Listener, stellen Sie dann eine autorisierte VPN-Verbindung her, erreichen Sie eine private Ressource und laden Sie die Verwaltungsseite über ihren erwarteten Pfad. Behalten Sie bestehende Benutzerberechtigungen und Widerrufe bei; eine Wiederherstellung, die sie zurücksetzt, hat die Bindung repariert und die Installation verloren. Die Arbeit ist erledigt, wenn derselbe Dienst auf seiner vorgesehenen Schnittstelle läuft.