在建立VPN加密隧道前，核心风险在于理解流量实际被保护的范围。加密隧道并非让所有网络活动都进入同一层壳，不同协议的包保护范围不同。若误判作用域，可能导致敏感数据在特定环节暴露，或因路由策略错误导致连接中断。务必区分“传输模式”与“隧道模式”的差异，猫头鹰VPN明确哪些流量被封装，哪些仅被认证。
模式决定保护边界
IPsec支持传输模式和隧道模式。传输模式仅加密IP包的有效载荷，保留原始IP报头，主要用于主机到主机的点对点通信。此时，源目IP地址仍可见，且协议号（如ESP的50）直接暴露在包头中。隧道模式则将整个原始IP包（包括报头）封装在新的IP包内，外层报头包含隧道端点地址。这种模式常用于网关到网关，能隐藏内部网络结构。选择哪种模式，猫头鹰直接决定了攻击者能看到的元数据范围。
直观对比IPsec传输模式与隧道模式的数据封装差异，明确加密保护的实际边界。
原生协议号而非端口
很多用户混淆ESP的传输方式。原生IPsec ESP使用IP协议号50，它位于IP报头中，而非UDP或TCP端口。只有在UDP封装（UDP-Encapsulated IPsec）场景下，才会使用UDP端口（通常4500）来穿越NAT设备。如果网络环境允许，原生ESP无需依赖特定端口映射。若配置为UDP封装，需确保防火墙放行相应UDP端口，否则隧道协商会失败。检查配置时，应明确是原生IPsec还是UDP封装，避免错误地在防火墙上放行错误的协议类型。
隧道模式的流量盲区
在隧道模式中，只有被策略匹配到的流量才会进入加密隧道。未被匹配的数据包仍通过普通接口路由，未经加密。例如，访问公司内部应用可能走加密隧道，猫头鹰而访问公共互联网DNS查询可能仍走明文通道。这种“部分加密”状态是常态，而非异常。用户需通过路由策略（如split-tunneling）明确定义哪些目的地地址使用隧道。若策略配置过宽，可能导致带宽浪费；过窄则可能泄露业务数据。务必审查路由表，确认关键流量是否正确指向隧道接口。
协商失败的路径排查
当隧道无法建立时，首先检查IKE协商阶段。失败可能源于证书不匹配、预共享密钥错误或时间不同步。仅测试“能否连接”不足以定位原因，因为即使IKE阶段一成功，若阶段二（IPsec SA）协商失败，隧道仍无法生效。应查看两端安全网关的日志，确认是否完成了完整的SA交换。若使用UDP封装，还需验证NAT遍历是否成功。不要假设只要端口通就代表隧道可用，猫头鹰必须验证IPsec安全关联是否真正建立并用于数据包传输。
