隧道加密了什么，又留下了什么可读内容

隧道已经连接，一个标签页显示绿色锁标，而另一个标签页里的普通 HTTP 页面仍在警告连接不安全。这种组合让人困惑，因为这两种保护覆盖的距离并不相同。VPN 保护自身两端之间的流量，一旦越过出口，流量又恢复普通。HTTPS 保护一条连接直到网站。把这两件事放在一起，就能解释关于 VPN 究竟隐藏了什么的大部分疑问。

隧道实际覆盖的范围

在客户端与 VPN 对端之间，观察者看到的是加密后的字节，而不是可读的请求。这只覆盖隧道经过的那一段，通常正是你无法控制的部分。它并不延伸到 VPN 出口与网站之间的链路，因为隧道在出口就结束了。从隧道终止那一刻起，字节又变得可读。这并不是配置错误。

出口是一台解密并转发的机器，这正是 VPN 的用途。它转发的一切都以收到的形式对它可见，因此普通的 HTTP 请求从出口开始仍然是明文。

请把这看作特性而不是缺陷。加密只限定在一条路径上，而路径在服务开始的地方就结束了。

用平实的话说密钥、nonce 与完整性

进行中的流量由对称密码保护，两端在握手过程中派生或获取密钥材料。RFC 5116 概括描述的认证加密，在同一个构造中同时提供机密性与完整性。接收方会拒绝被改动的字节，而不只是读不出来，人们以为加密就是搅乱时，忘掉的正是这一点。

密钥来自那次交换，而不是登录时输入的密码。密码用来认证身份，随后协议建立会话材料。临时密钥交换带来前向保密，因此即使长期密钥后来泄露，已录下的会话仍然无法读取。

规范里的一个大数字回答不了这些问题中的任何一个，而跨不相关算法比较数字也不是排名。不如去问密钥交换提供了什么。

隧道在哪里结束

终止隧道的端点可以读取它转发的内容。企业网关、商业服务商和自建服务器都是如此。这是设计使然，并非缺陷。强加密无法阻止被攻陷的端点读取到达它的明文，因为端点正是保护终止的地方。

HTTPS 会越过这一点继续，所以在敌意网络中即使没有 VPN，站点也可能安全。两种保护在第一段重叠，越过出口之后只有一种继续。

这也是为什么为了让连接能用而削弱证书验证，并不是隧道的测试。它关掉了另一种保护，让你剩下的比开始时更少。

为什么匿名是另一种产品

地址、时间和流量规模在隧道之外仍然可被观察。观察者能看到流量正流向某个 VPN 端点、大致有多少以及何时发生。内容可能读不出来，但模式本身仍然有信息量。

服务商所处的位置也不同于你自己的网络，这是观察者的改变，而不是观察的消失。Cookie、登录和账户标识照常工作，因为隧道从未承诺要改变它们。

如果这是需求，就按日志政策与司法辖区挑选服务商，然后去读政策本身。营销页面很少能以任何人都能核查的方式回答这个问题。

分别检查隧道与站点

先验证隧道，这样你才知道自己在测试哪一种保护。然后验证站点自身的传输，并比较这两个结果，而不是假设其中一个意味着另一个。承载普通 HTTP 的隧道和提供 HTTPS 的站点，都在做它们被配置来做的事。

在你有权限测试的主机上运行检查，并阅读输出而不是摘要。

wg show
ip -brief addr show tun0
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com

当隧道已连接且站点是 HTTPS 时，第一段有两重保护，第二段只有一重。当站点是普通 HTTP 时，第二段对链路上的任何人都可读，包括转发该请求的出口。知道两者中缺少哪一个，就是全部诊断，而这需要两条命令，而不是一个新客户端。