OpenVPN Access Server: start dæmonen på nytt eller bruk innstillingen
systemctl restart openvpnas starter dæmonen på nytt; sacli start reiser de interne tjenestene. Følg det innstillingens dokumentasjon sier, og verifiser deretter mer enn active.
To kommandoer limes inn for det som ser ut som samme jobb på OpenVPN Access Server, og de gjør forskjellige ting. systemctl restart openvpnas stopper og starter hele produktet. sacli start reiser de interne tjenestene som leser konfigurasjonen du nettopp endret. Valget mellom dem er ikke en smakssak: det avhenger av hva innstillingens egen dokumentasjon sier, om økten din går gjennom serveren du er i ferd med å 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 systemd-enhet, openvpnas, og den dæmonen overvåker de interne tjenestene bak webgrensesnittet og VPN-lytterne. sacli er kommandolinjegrensesnittet til samme installasjon, på /usr/local/openvpn_as/scripts/sacli, og kan starte, stoppe og spørre disse interne komponentene uten å erstatte enheten.
Derfor finnes begge kommandoene. En omstart av dæmonen kjører alt på nytt, inkludert prosessen som avslutter klienttunneler. sacli start ber den allerede kjørende dæmonen om å reise komponentene sine slik at de leser den nye konfigurasjonen, og det er det de fleste egenskapsendringer faktisk krever.
Betingelse én: hva innstillingens dokumentasjon sier
Les siden for innstillingen du endret, ikke for en du endret i forrige måned. En egenskap skrevet via ConfigPut etterfølges vanligvis av sacli start, og det paret er det dokumenterte brukstrinnet. En endring i oppførsel på lytternivå, eller noe siden beskriver som krevende en tjenesteomstart, er den klassen der omstart av enheten er riktig.
De to kommandoene kan ikke byttes om, så feilmodusen ved gjetting er asymmetrisk. Å bruke sacli start når en full omstart var nødvendig, lar en gammel prosess fortsatt betjene den forrige konfigurasjonen, noe som ser ut som om innstillingen ble ignorert. En full omstart når sacli start hadde holdt, kaster ut hver tilkoblet klient uten grunn.
Betingelse to: er din egen økt inne i tunnelen
Hvis du administrerer Access Server over VPN-et den leverer, fjerner omstarten forbindelsen som bærer skallet ditt. Kommandoen kan fullføres etter at økten din dør, slik at du må gjette om den virket. sacli start kan også avbryte en økt kortvarig av samme grunn når komponenten som startes på nytt, håndterer trafikken din.
Hold en vei utenfor båndet åpen før begge kommandoene: en leverandørkonsoll, en hypervisor-konsoll eller en seriell økt. Denne betingelsen avgjør når du kjører kommandoen, ikke hvilken, og det er den som gjør en endring på to minutter om til en nedetidsrapport.
Betingelse tre: er dette produktet du tror
Access Server er ikke Community OpenVPN. En fellesskapsinstallasjon kjører enheter som openvpn@server eller openvpn-client@profile, med konfigurasjon i /etc/openvpn, og sacli finnes ikke der. Å starte hver enhet med openvpn i navnet på en delt vert på nytt er måten ubeslektede tunneler faller sammen.
Avgjør før du berører noe: systemctl status openvpnas --no-pager svarer på om Access Server er det som kjører, sacli status lister opp de interne komponentene, og systemctl list-units --type=service lister opp enheter hvis navn inneholder openvpn. Hvis den siste kommandoen viser enheter med profilnavn, er du på fellesskapsproduktet, og resten av dette gjelder ikke for deg.
Bruk det, og verifiser deretter utover active
En enhet som rapporterer active har en kjørende prosess, noe som ikke er det samme som en fungerende autentiseringsvei. Etter brukstrinnet, sjekk sacli status for komponentene du forventet skulle starte på nytt, bekreft at verdien ble lagret med sacli ConfigQuery, og kjør deretter én begrenset klientinnlogging mot en testkonto.
Avslutt med noe på applikasjonsnivå: nå en privat ressurs gjennom tunnelen, ikke bare en ping til serverens offentlige adresse. Et håndtrykk som lykkes mens den dyttede ruten eller DNS-innstillingen er feil, vil bestå enhver tjenestesjekk og likevel svikte personen som rapporterte problemet.
leverandørens veiledning i tjenesteadministrasjon er referansen for hvilke operasjoner som hører til sacli, og den er verdt å åpne før du bestemmer at en omstart er det trygge valget.
Beslutningen i én gjennomgang
Gå nedover 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 treffer lyttere snarere enn egenskaper: bruk systemctl restart openvpnas.
- Skallet ditt kommer gjennom denne serveren: ordne konsolltilgang først, og kjør deretter kommandoen de to linjene ovenfor valgte.
- Verifisering: sacli status, ConfigQuery for verdien, én innlogging, én privat ressurs. Tjenestestatus alene er ikke målstreken.
To av disse linjene er kontroller og to er handlinger, og det er poenget med rekkefølgen. Hvis du ikke kan svare på produktspørsmålet, stopp: kommandoen du var i ferd med å kjøre tilhører en annen installasjon, og tunnelen du tar ned blir ikke den du mente.