OpenVPN Access Server: skal du starte dæmonen på nytt eller bruke innstillingen

Det limes inn to kommandoer for det som virker som samme oppgave på OpenVPN Access Server, men de gjør forskjellige ting. systemctl restart openvpnas stopper og starter hele produktet på nytt. sacli start løfter de interne tjenestene som leser konfigurasjonen du akkurat har endret. Å velge mellom dem handler ikke om smak: det avhenger av hva dokumentasjonen for innstillingen selv sier, om økten din går gjennom serveren du skal starte på nytt, og om du i det hele tatt ser på riktig produkt.

To lag, én dæmon

Access Server kjører som én enkelt systemd-enhet, openvpnas, og den dæmonen fører tilsyn med de interne tjenestene bak webgrensesnittet og med VPN-lytterne. sacli er kommandolinjegrensesnittet mot den samme installasjonen, på /usr/local/openvpn_as/scripts/sacli, og det kan starte, stoppe og spørre disse interne komponentene uten å bytte ut enheten.

Det er derfor begge kommandoene finnes. En omstart av dæmonen kjører alt om igjen, også prosessen som avslutter klienttunneler. sacli start ber den kjørende dæmonen om å løfte komponentene sine slik at de leser den nye konfigurasjonen, og det er nettopp dette de fleste egenskapsendringer krever.

Første betingelse: hva dokumentasjonen for innstillingen sier

Du skal lese siden for innstillingen du endret, ikke for en innstilling du endret forrige måned. Etter en egenskap som er skrevet med ConfigPut kommer vanligvis sacli start, og det paret er det dokumenterte trinnet for å ta endringen i bruk. En endring i oppførsel på lytternivå, eller noe siden beskriver som å kreve omstart av tjenesten, er den kategorien der omstart av enheten er riktig.

De to kommandoene kan ikke byttes om, så feilmåten når du gjetter er asymmetrisk. Bruker du sacli start når en full omstart var nødvendig, blir en gammel prosess stående og betjene den forrige konfigurasjonen, og det ser ut som om innstillingen ble oversett. Tar du en full omstart når sacli start hadde vært nok, kaster du ut hver tilkoblet klient uten grunn.

Andre betingelse: er din egen økt inne i tunnelen

Hvis du administrerer Access Server over VPN-en den leverer, fjerner omstarten forbindelsen som bærer shellen din. Kommandoen kan bli ferdig først etter at økten din er død, så du må gjette om den virket. sacli start kan også bryte en økt kortvarig av samme grunn når komponenten som startes på nytt, håndterer trafikken din.

Ha en vei utenfor båndet åpen før begge kommandoene: en leverandørkonsoll, en hypervisorkonsoll eller en seriell økt. Denne betingelsen avgjør når du kjører kommandoen, ikke hvilken, og den er det som gjør en endring på to minutter om til en nedetidsrapport.

Tredje betingelse: er dette produktet du tror det er

Access Server er ikke Community OpenVPN. En community-installasjon kjører enheter som openvpn@server eller openvpn-client@profile, med konfigurasjonen i /etc/openvpn, og sacli finnes ikke der. Å starte hver enhet med openvpn i navnet på nytt på en delt vert er måten ubeslektede tunneler går ned sammen på.

Fastslå før du tar i noe: systemctl status openvpnas --no-pager svarer på om Access Server er det som kjører, sacli status lister de interne komponentene, og systemctl list-units --type=service lister enheter der navnet inneholder openvpn. Viser den siste kommandoen enheter med profilnavn, er du på community-produktet, og resten her gjelder ikke for deg.

Ta i bruk, og verifiser deretter utover active

En enhet som rapporterer active har en prosess som kjører, og det er ikke det samme som en fungerende autentiseringsvei. Etter trinnet for å ta endringen i bruk, sjekk sacli status for komponentene du ventet skulle starte på nytt, bekreft at verdien ble lagret med sacli ConfigQuery, og kjør så én begrenset klientinnlogging mot en testkonto.

Avslutt med noe på applikasjonsnivå: nå en privat ressurs gjennom tunnelen, ikke bare et ping mot serverens offentlige adresse. Et håndtrykk som lykkes mens den dyttede ruten eller DNS-innstillingen er feil, vil bestå alle tjenestesjekker og likevel svikte personen som meldte problemet.

leverandørens opplæring i tjenesteadministrasjon er referansen for hvilke operasjoner som hører til sacli, og den er verdt å åpne før du konkluderer med at en omstart er det trygge valget.

Avgjørelsen i én gjennomkjøring

Gå gjennom disse fire linjene og stopp ved den første som passer:

• Innstillingssiden nevner sacli start, eller du har nettopp kjørt ConfigPut: bruk sacli start.
• Siden krever en omstart, eller endringen berører lyttere og ikke egenskaper: bruk systemctl restart openvpnas.
• Shellen din kommer gjennom denne serveren: ordne konsolltilgang først, og kjør deretter kommandoen de to linjene over valgte.
• Verifisering: sacli status, ConfigQuery for verdien, én innlogging, én privat ressurs. Tjenestestatus alene er ikke målstreken.

To av linjene er kontroller og to er handlinger, og det er hele poenget med rekkefølgen. Klarer du ikke å svare på produktspørsmålet, må du stoppe: kommandoen du skulle kjøre, hører til en annen installasjon, og tunnelen du river, blir ikke den du mente.