TLS 在 OpenVPN 内部处于什么位置，什么会改变形态

OpenVPN 确实使用 TLS，而人们常把这延伸成一个它承担不起的论断：隧道因此看起来像浏览器访问网站。前半句成立，后半句不成立。这里的 TLS 属于一条控制通道，它在 OpenVPN 自己的封装内部传输，旁边是一条加密方式完全不同的载荷通道，所以查看开头字节的人看到的是 OpenVPN。

一个信封里的两场对话

把一次会话想成共用同一个信封的两场对话。一场验证证书并导出密钥材料。另一场用第一场的产物，加密你真正发送的内容。

信封就是协议本身。每个数据包都以一个说明自身类型的小头部开始，而这个头部先于其他一切到达。

实际最先到达的是什么

由于这个顺序，线路上最先出现的并不是 TLS 记录，而是 OpenVPN 的头部，随后是头部所宣告的那条通道的内容。ClientHello 确实在其中，只是不在第零个字节。要察觉差别并不需要解密，因为形态本身就会暴露它。

默认值在这里也有影响。除非配置文件选择 TCP，流量都走 UDP 到 1194。两种情况下，外观都是隧道，而不是网页请求。

三种诚实改变形态的办法

像 stunnel 这样的 TLS 终结器在两端各监听一个端口接收 TLS，再把解密后的流转交给本机的 OpenVPN，因此网络看到的是发往该端口的 TLS。从第一个字节起就是 TLS 的协议又是另一番表现：ocserv 实现的 AnyConnect 兼容交换，看起来就像许多网络早已预期的企业远程接入。随 Windows 提供的 SSTP 在另一种产品里具有同样的性质。

在 Linux 上，SSH 的 -w 选项在一条 SSH 会话里承载点对点链路，这在 SSH 是唯一被允许的协议时很有用。如果该网络本来就能用 SSH，它是四者中最便宜的；如果不能用，它是最没用的。

它们都没有改变的东西

这些办法都不改变隧道能到达哪里。它们不会让被封锁的地址变得可达，不会认证任何人，也不决定路由。

套一层外壳还让你多一个部件。两个监听器和两份配置文件意味着两个故障点，而两者在用户看来一模一样。采用之前要把这笔账算进去。会话仍然是一条通往单一目的地的长寿命加密流，它的流量与时间特征依旧可见。

先诊断，再选择

所以先诊断。UDP 被丢弃就用 TCP 模式应对，被识别的特征则用另一种协议或一层外壳应对。在不了解封锁情况之前就挑工具，正是人们最终维护三层、而三层因同一个原因全部失败的原因。

只放行网页端口的网络，把选择收窄到 443 上基于 TLS 的协议。三种办法一起上，会得到一个没人能调试的堆栈，所以一次只改一样，再重测同一条流。

如果都不适用，准确的答案是：这个网络不会为你承载隧道。这是一个发现，而不是努力失败。再多试几个选项，也扭转不了上游已经做出的策略决定。

这一切之前还有一条边界。在别人的网络上运行隧道属于策略问题，与机制是否有效分开判断。这些事实解释观察者看到什么，并不授予许可。