VPN 握手步骤：流量开始之前发生了什么

按下“连接”会启动四项彼此独立成败的任务。客户端必须到达监听端、就对方身份达成一致、派生密钥，然后把可用的隧道交给系统其余部分。大多数失败的连接都被诊断到了错误的那项任务上。正因如此，第一条错误比第三次重试更重要。

先到达监听端

在任何身份被交换之前，客户端会解析名称、选择路由并打开到某个端口的传输。对所有请求都应答的强制门户、关闭的端口和错误的主机名都会在这里失败，而它们中没有一个是认证问题。改密码无法修复这三者中的任何一个。在动手改凭据之前，先读错误的第一行。

超时、证书被拒和账号被拒是三种不同的故障，对应三种不同的检查。先把它们分开，才能避免把网络问题当成凭据问题来排查。

证明对端，然后派生密钥

每个协议都需要一种识别预期服务器的方式，无论通过配置的公钥还是证书链。用户登录是对这项检查的补充，而不是替代。接受了你的密码的服务器并没有证明它自己的身份。正因如此，在客户端里输入的共享密钥不能替代对“是谁应答”的验证。

接下来，交换过程从协议自身的输入派生流量密钥，而登录密码通常并不是打在每个数据包上的那把密钥。长期身份材料与短期会话密钥有着不同的生命周期和不同的职责。前向保密讲的正是这种分离。

排查问题时请保持验证开启，因为在关闭某项检查之后才连上的隧道，除了证明那项检查确实在做点什么之外，什么都没有证明。记录你改动了什么，并在下一次测试前把它改回去。

三种协议，三段对话

在基于 TLS 的OpenVPN部署中，控制通道协商安全参数，而数据通道承载隧道流量，因此数据通道选项与证书问题位于不同的地方。IKEv2 认证双方参与者的身份，然后建立带有各自生命周期的 IPsec 安全关联。WireGuard 通过基于 Noise 的交换派生密钥，并刻意把状态机保持得很小。知道自己在跑三者中的哪一个，决定了哪份日志值得读。

外观相似的客户端并不意味着底层报文可以互换，某个产品里存在的配置字段在另一个产品里可能没有对应项。在两者之间复制配置文件是猜测，而不是迁移。

握手不做什么

路由、名称解析和目的策略全都留在这之后。即使对端已正确认证、隧道已建立，内部站点也可能因为缺少其子网路由而无法访问。把这种情况当成加密太弱，会让你在错误的层次上寻找，通常以一次并没有修好任何问题的加密算法变更收场。

密钥刷新与重新连接在大多数状态显示里看起来也很像，而两者都不会告诉你在中断期间普通流量是否被阻断。只有客户端的失败策略能回答这个问题，所以要读策略，而不是看图标。

按上面的顺序逐个处理阶段，并在第一个产生错误的阶段停下。之后的每个阶段都继承前面阶段的状态，所以第三阶段失败并不能说明第四阶段的任何情况。

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal