Access Server mistet bindingen etter at et nettverksgrensesnitt fikk nytt navn: rett nøklene

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

Refleksen er å reinstalere, 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 forteller

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 prøvde; sammenlign den med ip -br addr på verten for å se om grensesnittet ble omdøpt, fjernet eller reist 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 av deg selv retretten. En lokal konsoll, en sekundær administrasjonsadresse eller en dokumentert out-of-band-vei gjør endringen reversibel.

Spør etter konfigurasjonen før du redigerer den

Access Server eksponerer serverkonfigurasjonen sin 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 admin- 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 den 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 til bør avvises. Å gjenopprette en standard som lytter på alle grensesnitt er en eksponeringsbeslutning, ikke en stavefeilretting; den tiltenkte lokale bindingen, den publiserte veien og filtreringen foran må samsvare 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 fungerte før navneendringen.

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 inn 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.