TLS 包装器能给你一个私有网络吗？通常不能
包装器保护其两端之间一条已配置的连接。路由型 VPN 承载每个应用的流量，这是另一种访问模型。
TLS 保护两个端点之间的一条通道，却不说明通道内有哪些服务。包装器把这条通道变成一条固定配置的转发，面向一个监听器、一个目标。以 SSL VPN 名义出售的产品，通常会在同一个原语之上再加一层接口、路由表和访问模型。把两者混为一谈，正是把一条能用的隧道误当成网络访问的原因。
包装器究竟连接什么
包装器监听本地端口，并把到达的流量转发到配置好的目标：可以是一台主机加端口，也可以是一个本地程序。目标由写配置文件的人选定，一次只对应一个监听器。安装软件包不会创建路由、虚拟接口，也不会让任何未被显式列出的东西变得可达。先读配置文件，再看软件包说明：说明覆盖的是一类用法，配置文件覆盖的是你这一例。
因此，关于包装器的有用问题不是它是否加密，而是它搭建的链条两端各是什么。
application -> local listener -> TLS connection -> remote listener -> configured backend
要从配置里读这条链条，而不是从营销名称里读。每一个箭头都是一次独立的网络跳跃，有自己的地址和自己的访问规则。
找出 TLS 通道在哪里结束
如果包装器终止了 TLS，那么它继续转发的一切都是带新属性的新连接。这条流可能是私有网段上的明文，也可能在内部再承载另一种受保护的协议。不读后端配置就假设其中一种，正是人们得出「外层保护了它再也看不到的数据」这一结论的原因。被中转的这一跳值得在它自己的地址和端口上单独检查。
监听器和后端要分开检查，因为在前门握手成功，并不能说明门后的服务如何。
ss -ltnp | grep -F 443 openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates
第一条命令显示哪个进程占用该端口、监听在哪个地址上。第二条打印客户端实际收到的证书，这是端口号无法替代的身份核验。
路由型 VPN 加上了什么，而包装器没有
路由型 VPN 会安装一个接口，接管选定的前缀，并与主机的路由和访问策略整合。机器上的每个应用都在不知道隧道存在的情况下受益。包装器只把这种可达性交给一个配置好的监听器，到此为止。
准入又是另一回事。对客户端做身份认证的 VPN，仍然需要授权来说明客户端能访问哪些资源；对端做身份认证的包装器，仍然需要一个自行执行权限的后端。
有一种正当的组合：在有意支持的 TCP 布局上，把 VPN 协议承载在 TLS 包装器内部。这只是叠加了两层，并不会让包装器和 VPN 变成同一类对象。
比较正在失败的那条边界
在改动任何东西之前，先写下前端地址、监听器、对端身份、后端目标和应用操作。然后拿可比的去比：通过另一个主机名或端口成功，并不能证明防火墙和证书条件相同。
被后端拒绝的请求，绝不应靠关闭前端身份校验来修好。那是把可诊断的授权失败换成不可诊断的信任失败。
curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30
把名字钉在选定的地址上，就把名字解析与可达性分开了，这通常是判断两者中哪一个坏了的最快办法。
真正重要的比较会点明受保护的端点对、承载的载荷、使用它的应用，以及在目标处执行的权限。TLS 对这种描述有贡献，但并不完整。