vpnc 的组密钥还是你的登录名：哪个字段填什么？

第一次有人递给你 vpnc 配置文件时，凭据对话框会问四件事，读起来像是在要一个密码。其实不是：组预共享密钥和个人 XAuth 登录名是归属不同的两个值，把账户密码填进组字段，得到的失败看起来像密码错误，而不像填错了框。把这张对应表弄对，就是这里的全部工作。底下那套协议是别人的迁移项目，所以以上任何一点都不是新建 IKEv1 隧道的理由。

两个密钥，两个归属，一个对话框

组密钥属于网关配置。所有通过该配置连接的人都用同一个值，正因如此它无法识别具体的人，也无法只从一台笔记本上收回而不改动配置的其他所有使用者。XAuth 用户名和密码则属于人，网关在 IPsec 关联已经建立之后的第二阶段才校验它们。

人们漏掉的正是这个两阶段形态。建立隧道和认证用户是输入不同的两种交换，因此从未走到凭据提示的客户端，根本不是登录失败。把对话框读成两栏而不是一栏：左边是全配置的值，右边是个人的值。连接失败时，你最近填过的那一栏并不自动就是出错的那一栏。

按职责对应字段，而不是按标签

vpnc 在项目文档里给它的指令命名，而每个图形前端又会重新贴标签。把每个值的作用翻译出来，标签就不再重要：

在组字段旁边显示“用户名”和“密码”的前端并没有错——那同样是三个值，只是叫法不同。真正出问题的是因为某个值放得进去就把它填进框里。把组密钥当成用户密码粘贴，会先通过配置认证，然后在用户阶段失败；把账户密码当成组密钥粘贴，则更早失败，在任何提示之前就失败，让人去防火墙里找问题，而问题其实在文本框里。

组标识不是什么

组这个词容易引起误读。这里的组标识是一个选择器，告诉网关应用哪份配置；它与目录成员身份毫无关系，两边名字相同只是巧合，除非运营方确认。授权发生在 XAuth 成功之后，由网关被配置去查询的东西决定，而这些在客户端对话框里都看不到。

同样的谨慎也适用于组密钥。知道它并不等于身份，把一个密钥在一支团队里传来传去，是会带来客户端无法向你显示后果的运营决定。

连接之前先把含糊的指令弄清楚

旧交接记录里常有“使用专用公网 IP”这样一行。这句话可能指的是对面允许列表期待你的流量从哪个地址到达——那是运营方网络的出口属性，与你在网关字段里输入的端点毫无关系。在值被填到任何地方之前，先问清楚指的是哪一个。填反了会把每个数据包发往一个从不回应的地址，由此产生的超时读起来像是端口被封。

通过组织已核实的渠道问四件事：支持哪种客户端和协议、使用哪个端点、网关将出示什么身份、凭据如何交付。把真正的密钥留在截图、工单和共享排障记录之外。不要关闭证书校验，也不要粘贴旧的加密套件列表来让配置不同的服务显得兼容，因为只有削弱校验才能工作的连接，并不是要求你建立的那个连接。

让旧配置保持诚实

IKEv1 已被弃用，谈到迁移时该引用的文件是 RFC 9395。字段对应正确并不能证明这套协议属于新设计；它换来的是替换方案排期之前仍可用的连接，外加书面的范围和这项迁移的负责人。

然后对着需求验证，而不是对着对话框。连接之后，确认隧道接口持有预期地址，并且某个内部目的地经由它路由；如果原始需求为允许列表指定了出口地址，也要确认那个地址，因为这与隧道已建立是两件不同的事实。一个认证正确却什么都不路由的配置，仍然没有完成它被创建来做的那件事。