VPN 开启后，云防火墙看到的地址
完整隧道会改变数据库看到的源地址。要改的是允许列表、私有路径或拆分隧道，而不是凭据。
连上 VPN 之前能用、连上之后就失败的数据库，很少是凭据问题。云防火墙匹配源地址，而完整隧道恰好把被匹配的地址换掉了。你以为笔记本发出的地址和服务器实际收到的地址之间的差距就是整个问题，而且一步就能测出来。
源地址会变成什么
在完整隧道里，每个数据包都从 VPN 网关出去，所以服务器看到的是网关的出口地址，而不是你家的宽带。如果路径上还有正向代理，到达的就是代理的地址。两者都是合法来源，也都不是你最初规则里的那个地址。
Azure SQL 的服务器级和数据库级防火墙规则匹配的是到达逻辑服务器的客户端地址，经过完整隧道后就是出口地址。只放行单个地址的 AWS 安全组也是同样的逻辑。数据包在认证之前就被丢弃，所以你收到的报错看起来像网络故障，而不是权限问题。人们开始重置密码，原因正是这个。
允许列表在哪里被决定
去读和失败路径真正对应的那条规则，而不是你记忆中创建过的那条。看清它的作用范围、端口、协议，以及它是否在任何身份校验之前生效。
然后再判断这一层是否应该由它来决定。地址规则回答流量从哪里来。私有端点回答服务到底能不能走私有路径。拆分隧道例外回答哪些目标绕过隧道。三者不能互换，隧道一变，各自失败的方式也不同。
三种修法，三个层面
下面每个选项都是因为不同的原因修好流量，选错了只会得到一条撑到下次网关变更的连接。
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
补上出口地址是改动最小、也最脆的做法，因为换网关或换区域会悄悄让它失效。把地址写在隧道定义旁边，两者才能一起改。临时放宽的大段范围只是诊断手段，不是修法；一直留着它，内部服务迟早会暴露。
为什么托管平台进不了隧道
Heroku、AppHarbor 或 CloudBees 这类应用平台运行代码的环境里没有 tun 或 tap 设备，也没有创建它的权限。它们的入站模型是 HTTP，而不是任意监听套接字。即使 buildpack 里带了 VPN 二进制，也没有地方放那个接口。可行的做法是让数据库放行一个固定出口地址、使用平台提供的私有连接产品，或者走 DMZ 里通过 HTTPS 访问的代理。
那个代理是一条自带认证和日志的访问路径。它并不会让平台成为你 VPN 的一员，按那种说法写出来的规则没人审计得了。
从失败的那个客户端去验证
重连，并把客户端路径原样再走一遍。按顺序检查服务记录的源地址、客户端为数据库名选择的走法，以及实际查询的结果。从网关测通只能证明网关是好的，而这一点本来就没被怀疑过。如果连接现在能认证、查询还是失败，剩下的问题就是数据库权限。
每次隧道变更后都要复查这些规则。换掉的网关或新的出口网段会在应用配置完全没变的情况下把路断掉。