Access Server mista bindinga etter at eit nettverksgrensesnitt fekk nytt namn: rett nøklane

Du har gjeve eit nettverksgrensesnitt nytt namn, eller gjenoppretta ein maskin der adapteren kom tilbake under eit anna namn, og no startar ikkje OpenVPN Access Server-dæmonen. Nettgrensesnittet svarar kanskje framleis, eller kanskje ikkje, avhengig av kva komponent som var bunden til det gamle namnet. Tenesta er ikkje øydelagd, og konfigurasjonen er ikkje borte; éi innstilling peikar framleis på eit grensesnitt verten ikkje lenger har.

Refleksen er å reinstallere, reinitialisere eller redigere databasen til feilen forsvinn. Kvar av dei er ei større endring enn feilen, og den siste kan slette brukarane, løyva og profilavhengigheitene som gjorde tenaren verd å redde. Dette er eit bindingsproblem, og det har ei namngjeven løysing.

Kva symptomet eigentleg fortel

Ein dæmon som ikkje kan binde, seier det vanlegvis i sin eigen logg: adressa er ikkje tilgjengeleg, eller grensesnittet finst ikkje. Meldinga er konkret: ho namngjev adressa dæmonen prøvde; samanlikn henne med ip -br addr på verten for å sjå om grensesnittet vart omdøypt, fjerna eller reist utan si gamle adresse.

Hald ein autorisert gjenopprettingskonsoll open heile tida. Viss bindinga du skal endre ber den einaste administrative økta di, har du skore av deg sjølv retretten. Ein lokal konsoll, ei sekundær administrasjonsadresse eller ein dokumentert veg utanfor bandet gjer endringa reversibel.

Spør etter konfigurasjonen før du redigerer han

Access Server eksponerer tenarkonfigurasjonen sin gjennom sin eigen CLI. Den dokumenterte visninga er:

sacli ConfigQuery

Køyr henne i det administrative miljøet som er dokumentert for versjonen din, ikkje frå eit uvedkommande skal på ein annan vert. Lagre gjeldande verdiar på ein verna stad før du endrar noko, og lim ikkje inn heile utdata i ein offentleg støttetråd.

Desse utdata er ei visning av tenarkonfigurasjonen, ikkje ein full tryggingskopi. Brukar- og gruppeegenskapar vert spurde om separat, så ei rein binding gjenopprettar ikkje identitetar, og ein gjenoppretta identitet reparerer ikkje ein lyttar. Registrer båe som to separate artefaktar.

Avgjer kva lyttar som er øydelagd

Access Server køyrer meir enn éin lyttar. OpenVPN-dæmonane ber tunneltrafikk, wektenesta ber admin- og kundeportalen, og andre komponentar kan ha eigne portar. Ei mislukka nettlesarførespurnad seier ikkje kven av dei som feila, og portnummeret i ei feilmelding gjer det heller ikkje.

Bindingsnøklane til dæmonen er dokumenterte per dæmon, og i den offisielle rettleiinga er verdien identifikatoren til grensesnittet sjølv om nøkkelnamna endar på ip_address. Les den setninga to gonger. Rettleiinga ventar òg at UDP- og TCP-dæmonane deler eitt grensesnitt, så å rette berre éin nøkkel er ei delvis reparasjon.

Endre den namngjevne innstillinga, ikkje samsvarande rader

Rettleiinga dokumenterer ConfigPut mot bestemte nøklar, som vpn.daemon.0.server.ip_address og vpn.daemon.0.listen.ip_address. Bruk den eigen metoden til produktet med nøkkelnamnet og den nye verdien, i syntaksen versjonen din dokumenterer, og endre berre nøklane til lyttaren du diagnostiserte.

Det du ikkje bør gjere, er å søkje gjennom databasen etter kvar rad der verdien er det gamle grensesnittnamnet, og erstatte dei alle. Det føreset at det gamle namnet berre førekom i lyttarinnstillingar, noko skjemaet ikkje lovar. Det gjer òg endringa umogleg å gjennomgå.

To freistingar til bør avvisast. Å gjenopprette ein standard som lyttar på alle grensesnitt er eit vedtak om eksponering, ikkje ei stavefeilretting; den tiltenkte lokale bindinga, den publiserte vegen og filtreringa framfor må samsvare med det valet. Å reinitialisere konfigurasjonen gjev problemet nytt namn i staden for å løyse det, fordi ein fersk installasjon kastar nettopp dei brukarane og løyva som fungerte før namneendringa.

Bruk det, og prov at vegen verkar

Når verdien er retta, bruk han gjennom den dokumenterte livssyklusen til produktet ( livssyklus ). Rettleiinga brukar sacli start etter at nøklane er sette; det er ikkje ein full vertsomstart eller ein databasereset.

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

Sjekk lyttaren, opprett deretter éi autorisert VPN-tilkopling, nå éin privat ressurs og last inn administrasjonssida via den venta vegen. Hald på dei eksisterande brukarløyva og tilbakekallingane; ein gjenoppretting som nullstiller dei, har retta bindinga og mista utrullinga. Arbeidet er ferdig når den same tenesta verkar på det tiltenkte grensesnittet.