我有一个连接到我们的 Azure VLAN 的 Azure VPN。
如果我们从一些笔记本电脑连接到 VPN，它可以正常工作，他们可以访问所有内容，浏览内部站点，ping VLAN 上的 VM 等等。
但是，如果相同的用户从某些笔记本电脑（所有笔记本电脑都运行 Windows 10）进行连接，他们可以成功连接，但无法访问任何内容，如果他们尝试 ping 虚拟机，他们会得到：
TTL 在传输过程中已过期
现在，最近出现此问题的笔记本电脑是全新安装的 Windows 10。
有谁知道这可能是什么原因造成的？
如果我们在损坏的笔记本电脑上执行 tracert，它永远无法到达虚拟机，但在好的笔记本电脑上它可以到达。
这听起来不像是一个循环问题，因为问题是间歇性的，取决于使用的笔记本电脑
答案1
原来，连接时 VPN 没有在客户端计算机上添加 2 条路由，手动添加路由是一种解决方法。从 Azure 门户下载最新的 VPN 客户端提供了一个永久解决方案，因为新的 VPN 客户端按预期添加了所有路由。
答案2
这确实是一个路由循环，但如果没有进一步的数据，就无法做出良好的诊断，例如：
- 连接 VPN 前工作机器的路由表
- 连接VPN后工作机的路由表
- 连接到 VPN 之前非工作机器的路由表
- 连接VPN后非工作机器的路由表
我的合理猜测是，非工作机器在连接后没有通过 VPN 隧道指向 Azure VNet 的路由，因此流量会在您的公司网络内路由。这要么是因为这些机器位于不同的网络上，可能存在重叠的路由，要么是因为这些机器具有不同的权限，导致在安装 Azure 为隧道生成的 P2S 包后无法配置路由，在这种情况下，您需要检查日志。
答案3
我从您的问题中了解到，Azure VPN 上的某些笔记本电脑可以访问所有内容，但 Azure VPN 上的其他笔记本电脑则不能。当您从损坏的笔记本电脑 ping VM 时，您会收到错误消息“TTL 在传输中已过期”。
首先，这个 TTL Expired in Transit 是一个 ICMP 回复，与 Windows 10 无关。它告诉 ping 数据包上设置的生存时间值在到达 VM 之前过期。
我的第一个猜测是 Pedro Perez 建议的可能存在路由循环。但您认为这不是由于路由循环造成的。我们可以通过增加 ping 命令的 TTL 值来检查它。
建议你在 ping VM 地址时设置一个合理较高的 TTL 值。你可以使用 -i 参数来实现。
比如这里我ping Google的时候设置TTL值为300。
平www.google.com-i 300
如果您仍然收到传输中 TTL 已过期的消息，我建议您检查路由表是否存在循环。如果增加 TTL 值可以解决问题，我建议您更改损坏的笔记本电脑上的默认 TTL 值。
参考 https://www.corenetworkz.com/2011/05/ttl-expired-in-transit-reason-and.html