我已经在networkengineering.stackexchange.com，但也许那不是询问的正确地方。所以我被介绍到这里。
我们有以下设置
有 12 个 Hetzner 云 (HC) 服务器实例（全部为 Debian 或 Ubuntu），其中大多数运行作业和服务。两个充当网关服务器，共享一个 HC 别名 IP，并创建到 Azure WAN 的 IPSec 隧道（strongswan）。HC 服务器共享一个专用网络，其中网关服务器的别名 IP 配置为相关路由的网关。
此外，我们在 Azure 上还有一些重要的基础设施部分，最重要的是私有 DNS 区域、虚拟 WAN、虚拟网络、MSSQL 数据库、私有 DNS 解析器和几个用于通过 dnsmasq 进行 DNS 转发的 VM。（我们在遇到问题后除了私有解析器外还引入了 DNS 转发器，但这并没有改变任何东西）。虚拟网络没有特殊配置，例如没有防火墙、没有 DDos 保护和默认 DNS 服务器。私有 DNS 需要从 Azure 基础设施外部维护与数据库和 blob 存储的私有连接（使用私有 IP）。
而且效果很好大多数时候，但我们面临一个严重的问题挑战，有时我们的一些主机会遇到 DNS 问题。在每种情况下，发生超时的时间范围几乎正好是一小时。到目前为止，这个问题从未同时出现在多台 HC 服务器上，它主要影响流量大的服务器，比如我们的一台工作服务器，以及两台正在运行的监控服务器黑盒出口商。在大多数 HC 服务器上，我们实际上从未发现过此问题。有时，这个问题在任何地方几天都不会发生。然后，它会在同一台服务器上发生两次，中间间隔几个小时。我们还观察到一种情况，只有一个连接超时。
我们的一个怀疑是，我们可能会受到 Azure 某个产品的速率限制或配额耗尽的影响，例如DNS 区域。问题是，我们发现的限制不能成为原因。一方面，例如，worker-1 有时 DNS 查询率非常高，但问题并没有发生。另一方面，我们有监控服务器，其中 DNS 查询确实很稳定，数量相当少，但确实会发生。我们已经问过了了解有关使用限制的更多信息，但答案当然不是很令人满意。
我们在节点导出器指标显示，在其中一个服务器发生 DNS 超时的确切时间段内，非活动状态 (!) Azure 网关上的 UDP 错误率 (“无端口 - 在没有侦听器的端口上接收到的 UDP 数据报”) 有所增加。此外，相同的 UDP 错误 (“无侦听器的端口”) 也会在大多数其他服务器 (并非全部) 上发生，但模式不同，即使就 DNS 而言，它们的配置相同。
我们可以使用以下方法重现该问题，或者至少重现其症状：域名系统。有一次我们进行测试时，几分钟后就发生了这种情况，但另一次则要 30 多分钟后才发生。
因此，看起来确实在某个时间某个地方出现了瓶颈。但我们不知道具体在哪里，最重要的是不知道为什么。
- 在此期间，其他名称服务器确实可以工作，ping 等也是如此
- 隧道带宽为 500MB，我们甚至没有接近超过这个数字
- 自从我们引入了具有一些缓存（dnsmasq）的 DNS 转发器 Azure VM 以及使用 systemd-resolved 的本地缓存后，该问题发生得更少了。但每隔一天还是会出现
- resolv.conf 选项类似
single-request或single-request-reopen没有帮助 - 可以使用以下方法验证一小时时间范围内的超时情况：
dig - 请求超时，或者根本没有响应
- DNS 请求到达转发器（我们打开了 dnsmasq 的日志记录），但显然没有返回响应
- 两者都发生DNS 私有解析器以及我们自己的 dnsmasq 转发器
IPSec 隧道会导致这样的问题吗？
我们遇到了路由问题吗？
但为什么只是有时出现？
如何分析？
如果防火墙会导致此问题，那么这将是一个永久性问题，对吗？
没有端口正在监听，导致如此多 UDP 错误的原因可能是什么？特别是在非活动的 Azure 网关服务器上？
有什么想法吗？
谢谢你！