Access Server mistet bindingen etter at et nettverksgrensesnitt ble omdøpt: rett nøklene

Du har omdøpt et nettverksgrensesnitt, eller gjenopprettet en maskin der adapteren kom tilbake med et annet navn, og nå starter ikke OpenVPN Access Server-dæmonen. Webgrensesnittet svarer kanskje fortsatt, eller ikke, avhengig av hvilken komponent som var bundet til det gamle navnet. Tjenesten er ikke skadet, og konfigurasjonen er ikke borte; én innstilling peker fortsatt på et grensesnitt verten ikke lenger har.

Refleksen er å installere på nytt, reinitialisere eller redigere databasen til feilen forsvinner. Hver av dem er en større endring enn feilen, og den siste kan slette brukerne, tillatelsene og profilavhengighetene som gjorde serveren verdt å redde. Dette er et bindingsproblem, og det har en navngitt løsning.

Hva symptomet egentlig sier

En dæmon som ikke kan binde, sier det vanligvis i sin egen logg: adressen er ikke tilgjengelig, eller grensesnittet finnes ikke. Meldingen er konkret: den navngir adressen dæmonen forsøkte; sammenlign den med ip -br addr på verten for å se om grensesnittet ble omdøpt, fjernet eller heist uten sin gamle adresse.

Hold en autorisert gjenopprettingskonsoll åpen hele tiden. Hvis bindingen du skal endre bærer din eneste administrative økt, har du skåret over din egen retrett. En lokal konsoll, en sekundær administrasjonsadresse eller en dokumentert out-of-band-vei gjør endringen reversibel.

Spør om konfigurasjonen før du redigerer den

Access Server eksponerer serverkonfigurasjonen gjennom sin egen CLI. Den dokumenterte visningen er:

sacli ConfigQuery

Kjør den i det administrative miljøet som er dokumentert for versjonen din, ikke fra et uvedkommende skall på en annen vert. Lagre gjeldende verdier på et beskyttet sted før du endrer noe, og ikke lim inn hele utdataene i en offentlig støttetråd.

Disse utdataene er en visning av serverkonfigurasjonen, ikke en full sikkerhetskopi. Bruker- og gruppeegenskaper spørres om separat, så en ren binding gjenoppretter ikke identiteter, og en gjenopprettet identitet reparerer ikke en lytter. Registrer begge som to separate artefakter.

Avgjør hvilken lytter som er ødelagt

Access Server kjører mer enn én lytter. OpenVPN-dæmonene bærer tunneltrafikk, webtjenesten bærer administrasjons- og kundeportalen, og andre komponenter kan ha egne porter. En mislykket nettleserforespørsel sier ikke hvilken av dem som feilet, og portnummeret i en feilmelding gjør det heller ikke.

Dæmonens bindingsnøkler er dokumentert per dæmon, og i den offisielle veiledningen er verdien grensesnittets identifikator selv om nøkkelnavnene slutter på ip_address. Les setningen to ganger. Veiledningen forventer også at UDP- og TCP-dæmonene deler ett grensesnitt, så å rette bare én nøkkel er en delvis reparasjon.

Endre den navngitte innstillingen, ikke samsvarende rader

Veiledningen dokumenterer ConfigPut mot bestemte nøkler, som vpn.daemon.0.server.ip_address og vpn.daemon.0.listen.ip_address. Bruk produktets egen metode med nøkkelnavnet og den nye verdien, i syntaksen versjonen din dokumenterer, og endre bare nøklene til lytteren du diagnostiserte.

Det du ikke bør gjøre, er å søke gjennom databasen etter hver rad der verdien er det gamle grensesnittnavnet, og erstatte dem alle. Det forutsetter at det gamle navnet bare forekom i lytterinnstillinger, noe skjemaet ikke lover. Det gjør også endringen umulig å gjennomgå.

To fristelser bør avvises. Å gjenopprette en standard som lytter på alle grensesnitt er en beslutning om eksponering, ikke en stavefeilretting; den tiltenkte lokale bindingen, den publiserte veien og filtreringen foran må stemme med det valget. Å reinitialisere konfigurasjonen gir problemet nytt navn i stedet for å løse det, fordi en fersk installasjon kaster nettopp de brukerne og tillatelsene som virket før omdøpingen.

Bruk det, og bevis at veien virker

Når verdien er rettet, bruk den gjennom produktets dokumenterte livssyklus ( livssyklus ). Veiledningen bruker sacli start etter at nøklene er satt; det er ikke en full vertsrestart eller en databasereset.

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

Sjekk lytteren, opprett deretter én autorisert VPN-tilkobling, nå én privat ressurs og last administrasjonssiden via dens forventede vei. Behold eksisterende brukertillatelser og tilbakekallinger; en gjenoppretting som nullstiller dem, har rettet bindingen og mistet utrullingen. Arbeidet er ferdig når den samme tjenesten virker på sitt tiltenkte grensesnitt.