OpenVPN 服务器助手：网络加子网掩码，绝不用 CIDR

把 CIDR 后缀和点分掩码混在同一条 server 行里，守护进程会在打开端口之前就停下。IPv4 的 server 助手需要两个分开的参数：一个对齐的网络地址，然后是点分形式的子网掩码。那条行上其余的一切都是推断，而地址池大小和客户端掩码正是在推断上出错。

助手接受的两种参数

先写网络，再写掩码，地址后面不要接任何东西：

server 10.72.16.0 255.255.240.0

这是 /20 的写法。下面一行是错误写法，它会在解析选项时失败，而不是在运行时失败：

server 10.72.16.0/20 255.255.240.0

排查时把两个概念分开。前缀长度和点分掩码描述的是同一个跨度，但助手不接受两者同时出现，被拒绝的行会报出选项错误，指出的是指令而不是算术。

在写掩码之前先对齐网络

第一个地址是该范围的网络地址，不是其中某个方便的客户端地址。/20 的跨度从 10.72.16.0 到 10.72.31.255，其中只有第一个是有效的网络参数。/21 使用 255.255.248.0，覆盖 10.72.16.0 到 10.72.23.255，所以它的行是 server 10.72.16.0 255.255.248.0。

改变前缀只改变跨度，别的都不变。它不会改变单个客户端分到几个地址，因为那是拓扑的属性，不是这一行掩码的属性。

从服务器端确认地址池

在前台用详细日志启动实例，读取助手输出的行。它构建的地址池会在启动时打印出来，这比手工推算算术更可靠：

openvpn --config /etc/openvpn/server.conf --verb 4 --dev tun9 --port 1195

在输出靠上的位置找地址池摘要。它会列出助手预留的范围，如果该范围与你的意图不符，那么无论掩码算术怎么说，这一行的参数就是错的。

然后连接一个客户端，找到记录它拿到哪个地址的那一行。那个地址和地址池范围一对照，就能看出客户端是落在预留块内，还是落在你没预料到的地方。如果两者不符，要修的是参数而不是客户端。如果两者相符而客户端仍然什么都访问不到，那问题从来就不在地址池。

结合拓扑去读客户端的掩码

客户端在隧道接口上显示 /30，并不是地址池坏了的证据。点对点寻址下每个客户端拿到一个小块，它的接口掩码描述的是那个块，而服务器的地址池覆盖的是整体。子网拓扑下则相反，客户端的掩码与地址池掩码一致。所以单看掩码只能说明当前用的是哪种拓扑，并不能说明地址池写得对不对。

下结论之前，把配置的拓扑和分配的地址放在一起核对：

ip -4 addr show tun0

如果地址在池内而掩码比池更窄，那是拓扑在正常发挥作用。如果地址在池外，那就是地址池错了，客户端这边怎么查都修不好。

改动正在使用的地址池

选一个不与当前地址池、局域网，以及任何已经下发给客户端的路由重叠的范围。重叠是那种能熬过一次重启、然后在几天后表现为某个站点从某个方向不可达的故障。

改完这一行、重启，并在放用户回来之前重新读取启动时的地址池。如果新范围与什么撞上了，同一次启动输出会立刻显示出来，回滚就是改一行再重启一次。

改动之后，把旧范围再预留一段时间。晚些重连的客户端可能还握着上一个池里的地址，而重用这些地址的新范围会产生重复分配，看起来像路由故障。OpenVPN 2.6 手册记录了助手的参数及其展开方式，在假定某个指令和它的邻居使用同一种写法之前，值得一读。