Access Server verloor zijn binding na het hernoemen van een netwerkinterface: repareer de sleutels

Je hebt een netwerkinterface hernoemd, of een machine hersteld waarvan de adapter onder een andere naam terugkwam, en nu start de OpenVPN Access Server-daemon niet. De webinterface antwoordt misschien nog, of niet, afhankelijk van welke component aan de oude naam was gebonden. De dienst is niet beschadigd en de configuratie is niet weg; één instelling wijst nog naar een interface die de host niet meer heeft.

De reflex is herinstalleren, opnieuw initialiseren of de database bewerken tot de fout verdwijnt. Elk daarvan is een grotere wijziging dan het defect, en de laatste kan de gebruikers, rechten en profielafhankelijkheden wissen die de server het herstellen waard maakten. Dit is een bindingsprobleem, en het heeft een benoemde oplossing.

Wat het symptoom werkelijk zegt

Een daemon die niet kan binden, zegt dat meestal in zijn eigen log: het adres is niet beschikbaar of de interface bestaat niet. De melding is concreet: ze noemt het adres dat de daemon probeerde; vergelijk het met ip -br addr op de host om te zien of de interface is hernoemd, verwijderd of opgezet zonder het oude adres.

Houd de hele tijd een geautoriseerde herstelconsole open. Als de binding die je gaat wijzigen je enige beheersessie draagt, heb je je terugweg afgesneden. Een lokale console, een tweede beheeradres of een gedocumenteerd out-of-band-pad maken de wijziging omkeerbaar.

Vraag de configuratie op voordat je die bewerkt

Access Server toont zijn serverconfiguratie via zijn eigen CLI. De gedocumenteerde weergave is:

sacli ConfigQuery

Voer die uit in de administratieve omgeving die voor jouw versie is gedocumenteerd, niet vanuit een losse shell op een andere host. Bewaar de huidige waarden op een beschermde plek voordat je iets wijzigt, en plak de volledige uitvoer niet in een openbare supportthread.

Die uitvoer is een weergave van de serverconfiguratie, geen volledige back-up. Gebruikers- en groupeigenschappen worden apart opgevraagd, dus een schone binding herstelt geen identiteiten, en een herstelde identiteit repareert geen listener. Leg beide vast als twee afzonderlijke artefacten.

Bepaal welke listener stuk is

Access Server draait meer dan één listener. De OpenVPN-daemons dragen tunnelverkeer, de webservice draagt het beheer- en klantportaal, en andere componenten kunnen eigen poorten hebben. Een mislukte browseraanvraag zegt niet welke ervan faalde, en het poortnummer in een foutmelding ook niet.

De bindingssleutels van de daemon zijn per daemon gedocumenteerd, en in de officiële tutorial is de waarde de identificatie van de interface, ook al eindigen de sleutelnamen op ip_address. Lees die zin twee keer. De tutorial verwacht ook dat de UDP- en TCP-daemons één interface delen, dus alleen één sleutel repareren is een gedeeltelijke reparatie.

Wijzig de genoemde instelling, niet de overeenkomende rijen

De tutorial documenteert ConfigPut op specifieke sleutels, zoals vpn.daemon.0.server.ip_address en vpn.daemon.0.listen.ip_address. Gebruik de eigen methode van het product met de sleutelnaam en de nieuwe waarde, in de syntaxis die jouw versie documenteert, en wijzig alleen de sleutels van de listener die je hebt gediagnosticeerd.

Wat je niet moet doen, is de database doorzoeken op elke rij waarvan de waarde gelijk is aan de oude interfacenaam en ze allemaal vervangen. Dat veronderstelt dat de oude naam alleen in listenerinstellingen voorkwam, wat het schema niet belooft. Het maakt de wijziging ook onbeoordeelbaar.

Twee andere verleidingen zijn het weigeren waard. Een standaard herstellen die op alle interfaces luistert, is een beslissing over blootstelling, geen spelfoutcorrectie; de bedoelde lokale binding, het gepubliceerde pad en de filtering ervoor moeten met die keuze overeenkomen. De configuratie opnieuw initialiseren hernoemt het probleem in plaats van het op te lossen, omdat een verse installatie precies de gebruikers en rechten weggooit die vóór de hernoeming werkten.

Pas het toe en bewijs dat het pad werkt

Nadat de waarde is gecorrigeerd, pas je die toe via de gedocumenteerde levenscyclus van het product ( levenscyclus ). De tutorial gebruikt sacli start nadat de sleutels zijn ingesteld; dat is geen volledige herstart van de host en geen reset van de database.

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

Controleer de listener, maak dan één geautoriseerde VPN-verbinding, bereik één privéresource en laad de beheerpagina via het verwachte pad. Behoud de bestaande gebruikersrechten en intrekkingen; een herstel dat ze reset, heeft de binding gerepareerd en de implementatie verloren. Het werk is klaar wanneer dezelfde dienst op de bedoelde interface werkt.