OpenVPN Access Server：重启守护进程还是应用设置

在 OpenVPN Access Server 上，两个命令常被粘贴到看起来同样的事情上，但它们做的事并不相同。systemctl restart openvpnas 会停止并启动整个产品。sacli start 则拉起内部服务，让它们读取你刚刚修改的配置。两者之间怎么选不是口味问题：它取决于该设置自身的文档怎么说、你的会话是否正经过即将重启的服务器，以及你是否在看对的产品。

两层，一个守护进程

Access Server 以单一的 systemd 单元 openvpnas 运行，该守护进程监管网页界面背后的内部服务与 VPN 监听器。sacli 是同一套安装的命令行接口，位于 /usr/local/openvpn_as/scripts/sacli，它可以在不替换单元的情况下启动、停止和查询这些内部组件。

这就是两个命令都存在的理由。重启守护进程会把一切重新执行一遍，包括终止客户端隧道的那个进程。sacli start 请已运行的守护进程拉起它的组件，让它们读到新配置，而多数属性变更真正需要的正是这一步。

条件一：设置的文档怎么说

要读你改过的那项设置的页面，而不是上个月改过的那项。通过 ConfigPut 写入的属性之后通常接 sacli start，这一对就是文档写明的应用步骤。改动监听器层面的行为，或者页面明确说明需要重启服务的任何变更，才属于重启单元正确的类别。

两个命令不能互换，所以猜错的失败方式并不对称。在需要完整重启时使用 sacli start，会让旧进程继续用旧配置提供服务，看起来像设置被忽略了。在 sacli start 就够用时做完整重启，则会毫无理由地踢掉所有已连接客户端。

条件二：你自己的会话是否在隧道里

如果你是经由它提供的 VPN 来管理 Access Server，重启会切断承载你 shell 的连接。命令可能在你会话死掉之后才结束，于是你只能猜它到底有没有生效。同样地，当被重启的组件正在处理你的流量时，sacli start 也可能短暂打断会话。

执行任一命令前，先准备好带外通道：服务商控制台、虚拟机管理程序控制台或串口会话。这个条件决定你什么时候执行，而不是执行哪一条，也正是它把两分钟的改动变成一份故障报告。

条件三：这是不是你以为了的那个产品

Access Server 不是 Community OpenVPN。社区版安装运行的是 openvpn@server 或 openvpn-client@profile 之类的单元，配置在 /etc/openvpn，那里并没有 sacli。在共享主机上重启每个名字里带 openvpn 的单元，正是让互不相关的隧道一起掉线的方式。

动手之前先确认：systemctl status openvpnas --no-pager 回答运行的是不是 Access Server，sacli status 列出它的内部组件，systemctl list-units --type=service 列出名字中含 openvpn 的单元。如果最后一条命令显示的是带配置文件名的单元，那你就在社区版产品上，后面的内容不适用于你。

应用它，然后验证到 active 之外

报告 active 的单元只说明有进程在跑，这并不等于一条可用的身份验证路径。应用步骤之后，对期望被重启的组件检查 sacli status，用 sacli ConfigQuery 确认值已保存，然后用测试账号做一次受限的客户端登录。

最后用应用层的东西收尾：通过隧道访问一个私有资源，而不只是 ping 服务器的公网地址。在推送路由或 DNS 设置错误时成功的握手，会通过所有服务检查，却仍然让报告问题的人失败。

厂商的服务管理教程 是判断哪些操作属于 sacli 的参考，在决定重启是安全选项之前值得打开看看。

一次流程里做完决定

顺着这四行往下走，遇到第一条匹配的就停下：

• 设置页面点名 sacli start，或者你刚执行过 ConfigPut：用 sacli start。
• 页面要求重启，或者改动触及的是监听器而不是属性：用 systemctl restart openvpnas。
• 你的 shell 是经过这台服务器进来的：先安排控制台访问，再执行上面两行选出的命令。
• 验证：sacli status、用 ConfigQuery 取该值、一次登录、一个私有资源。只有服务状态不算终点。

这四行里两条是检查、两条是动作，顺序的意义正在于此。如果你回答不了产品那个问题，就停下：你即将执行的命令属于另一套安装，你放倒的隧道不会是你想的那条。