启动时的 SoftEther 客户端：AccountStartupSet 与守护进程顺序

重启机器后，它仍然留在网络上，隧道却再次断开。SoftEther 客户端保存着两个状态，而大多数人把它们当成一个：服务是否在运行，以及已保存的账号是否被允许随服务一起启动。两者都必须为真，而后者是每个账号的标志，不是启动设置。请按顺序执行下面四项检查，并在第一个失败处停下。

确认账号已被标记为自动启动

标志保存在客户端自身配置的账号记录里，因此重装客户端或恢复空目录都会把它清除。在改动其他任何东西之前，先打开管理控制台查看账号列表。

cd /opt/softether/vpnclient
./vpncmd

选择 2 进入 VPN 客户端管理，然后按 Enter 接受本地服务器。

AccountStartupSet
office-hub
exit

AccountStartupSet 会把该账号记录为客户端服务启动时需要拉起的账号。它既不启动服务，也不创建新账号，名字写错时更不会输出任何有用的提示。执行命令后请重新读取账号列表，因为拼写错误是无声的，看起来和标志未生效完全一样。

确认服务会启动，而且启动得足够早

在 Linux 上，客户端以守护进程方式从自己的目录运行，它必须在任何启动步骤尝试使用该账号之前就绪。在仍在运行 rc.local 的系统上，一段切换目录并启动它的简短钩子就足够了。

cd /opt/softether/vpnclient
./vpnclient start

如果 rc.local 已经不存在，就写一个 systemd 单元，明确指定 WorkingDirectory 并设置重启策略。二进制文件按启动位置解析配置，因此缺少该设置时，单元可能启动成功却读不到任何东西。顺序是问题的另一半：在守护进程开始监听之前执行的连接尝试会间歇性失败，这比稳定失败更难诊断。重启策略覆盖第三种情况，即守护进程几小时后悄然死亡。

检查进程列表，而不是相信上一次启动留下的 pid 文件。

确认网卡已经获得地址

账号连接后，客户端会呈现一块虚拟网卡，而网卡仍然需要地址。运行 SecureNAT 的集线器通常应答 DHCP； 桥接到物理 LAN 的集线器则期望由该 LAN 的服务器来应答。

ip -brief address
dhclient vpn_vpn1

从列表里取接口名，因为示例中的数字并不是常量。如果地址必须是静态的，就把它写进发行版针对该接口的网络配置，让它在链路事件之后重新应用，而不只是开机时生效。一次性脚本会在当天隧道第一次重连时让网卡失去地址。这种故障看起来像隧道已死，其实账号是好的。

没有地址的网卡是清单里最安静的故障，因为账号仍然报告已连接。

确认路由指向你以为的方向

即使链路正常、地址有效，流量仍可能失败。问内核它会为集线器子网内的目的地址选择哪个接口，再把这个答案与隧道对照。

ip route get 10.10.20.15

与集线器网段重叠的本地子网会胜出，因为它的路由更具体，而且已经安装好了。

这是编号决策，不是客户端缺陷，重启服务也不会改变它。解析器配置是另一半：地址没有可用的 DNS 服务器时，隧道能通过所有链路检查，却仍然打不开任何域名。

把这四项检查写进重建笔记

把账号名、服务启动命令和接口名一起记录下来，因为重建后的主机会恢复账号数据，却不会恢复启动守护进程的操作系统钩子。这些东西位于不同位置，通常也由不同的人备份。

标志只需重新应用一行，却很容易忘记。

保持顺序：标志、服务、地址、路由。从中间开始的检查清单只会给出许多自信的错误答案。