OpenVPN Access Server: starta om daemonen eller använd inställningen
systemctl restart openvpnas startar om daemonen; sacli start reser de interna tjänsterna. Följ vad inställningens dokumentation säger och verifiera sedan mer än active.
Två kommandon klistras in för det som ser ut som samma jobb på OpenVPN Access Server, och de gör olika saker. systemctl restart openvpnas stoppar och startar hela produkten. sacli start reser de interna tjänsterna som läser konfigurationen du just ändrade. Valet mellan dem är inte en smaksak: det beror på vad inställningens egen dokumentation säger, om din session går genom servern du ska starta om, och om du ens tittar på rätt produkt.
Två lager, en daemon
Access Server körs som en enda systemd-enhet, openvpnas, och den daemonen övervakar de interna tjänsterna bakom webbgränssnittet och VPN-lyssnarna. sacli är kommandoradsgränssnittet till samma installation, på /usr/local/openvpn_as/scripts/sacli, och kan starta, stoppa och fråga dessa interna komponenter utan att byta ut enheten.
Därför finns båda kommandona. En omstart av daemonen kör allt igen, inklusive processen som avslutar klienttunnlar. sacli start ber den redan körande daemonen att resa sina komponenter så att de läser den nya konfigurationen, och det är vad de flesta egenskapsändringar faktiskt kräver.
Första villkoret: vad inställningens dokumentation säger
Läs sidan för inställningen du ändrade, inte för en du ändrade förra månaden. Efter en egenskap som skrivits via ConfigPut följer vanligtvis sacli start, och det paret är det dokumenterade användningssteget. En ändring i beteende på lyssnarnivå, eller något sidan beskriver som krävande en tjänsteomstart, är den klass där omstart av enheten är rätt.
De två kommandona är inte utbytbara, så felfallet vid gissning är asymmetriskt. Att använda sacli start när en full omstart behövdes lämnar en gammal process som fortfarande betjänar den förra konfigurationen, vilket ser ut som om inställningen ignorerades. En full omstart när sacli start hade räckt kastar ut varje ansluten klient utan anledning.
Andra villkoret: är din egen session inne i tunneln
Om du administrerar Access Server över VPN-et den levererar tar omstarten bort anslutningen som bär ditt shell. Kommandot kan bli klart först efter att sessionen dör, så du får gissa om det fungerade. sacli start kan också avbryta en session kortvarigt av samma skäl när komponenten som startas om hanterar din trafik.
Håll en väg utanför bandet öppen före båda kommandona: en leverantörskonsol, en hypervisorkonsol eller en seriell session. Detta villkor avgör när du kör kommandot, inte vilket, och det är det som gör en ändring på två minuter till en avbrottsrapport.
Tredje villkoret: är detta produkten du tror
Access Server är inte Community OpenVPN. En community-installation kör enheter som openvpn@server eller openvpn-client@profile, med konfiguration i /etc/openvpn, och sacli finns inte där. Att starta om varje enhet med openvpn i namnet på en delad värd är sättet orelaterade tunnlar faller tillsammans.
Fastställ innan du rör något: systemctl status openvpnas --no-pager svarar på om Access Server är det som körs, sacli status listar dess interna komponenter, och systemctl list-units --type=service listar enheter vars namn innehåller openvpn. Om det sista kommandot visar enheter med profilnamn är du på community-produkten och resten här gäller inte för dig.
Använd och verifiera sedan bortom active
En enhet som rapporterar active har en körande process, vilket inte är samma sak som en fungerande autentiseringsväg. Efter användningssteget, kontrollera sacli status för de komponenter du förväntade skulle startas om, bekräfta att värdet sparades med sacli ConfigQuery, och kör sedan en begränsad klientinloggning mot ett testkonto.
Avsluta med något på applikationsnivå: nå en privat resurs genom tunneln, inte bara en ping mot serverns publika adress. Ett handskakning som lyckas medan den pushade rutten eller DNS-inställningen är fel kommer att klara varje tjänstekontroll och ändå svika personen som rapporterade problemet.
leverantörens handledning i tjänsteadministration är referensen för vilka operationer som hör till sacli, och den är värd att öppna innan du bestämmer att en omstart är det säkra valet.
Beslutet i en genomgång
Gå igenom dessa fyra rader och stanna vid den första som passar:
- Inställningssidan nämner sacli start, eller du har just kört ConfigPut: använd sacli start.
- Sidan kräver en omstart, eller ändringen träffar lyssnare snarare än egenskaper: använd systemctl restart openvpnas.
- Ditt shell kommer genom denna server: ordna konsolåtkomst först och kör sedan kommandot de två raderna ovan valde.
- Verifiering: sacli status, ConfigQuery för värdet, en inloggning, en privat resurs. Enbart tjänstestatus är inte mållinjen.
Två av dessa rader är kontroller och två är handlingar, och det är poängen med ordningen. Om du inte kan svara på produktfrågan, stanna: kommandot du skulle köra tillhör en annan installation, och tunneln du tar ner blir inte den du menade.