我们当前正在配置 Azure 负载均衡器，以与支持 IPv4 和 IPv6 的基于 Linux 的后端配合使用。作为设置的一部分，负载均衡器通过尝试建立 TCP 连接来定期执行运行状况检查。然而，由于 IPv6 数据包传输问题，我们后端的健康检查一直失败。
语境
- 负载均衡器不支持 NAT64，需要两端都支持 IPv6。
- 我们的后端配置了 IPv6，并且 Web 服务正在主动侦听所需的端口。
- 通过查询从一个后端到另一个后端的服务来验证连接，以确认配置正确。
问题：
当 Azure 负载均衡器使用从链路本地地址发送到非链路本地地址的 IPv6 数据包启动运行状况检查时，就会出现此问题，从而导致失败。
要求：
我们正在寻求指导，使我们的后端能够响应从链路本地地址发送到常规 IPv6 地址的 IPv6 数据包。我们是否需要调整任何配置或设置来适应 Azure 负载均衡器环境中的这种情况？
额外细节：
下面在其中一个后端虚拟机上进行的网络捕获很好地解释了这种情况。 Azure 负载均衡器从链路本地地址执行其运行状况探测fe80::1234:5678:9abc。该数据包将发送到分配给该虚拟机接口的常规 IPv6 地址。然而，后端拒绝了这个数据包，并立即通过 ICMPv6 响应一个错误，告知链路本地地址超出了源地址范围。我们无法更改 Azure 负载均衡器的工作方式，因此我们想知道是否可以在后端应用解决方法以允许响应此数据包。
| 来源 | 目的地 | 协议 | 长度 | 信息 |
|---|---|---|---|---|
| fe80::1234:5678:9abc | 2404:f800:8000:122::4 | 传输控制协议 | 86 | 58675 → 80 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 WS=256 SACK_PERM |
| 2404:f800:8000:122::4 | fe80::1234:5678:9abc | ICMPv6 | 134 | 目标不可达（超出源地址范围） |
答案1
您无法在第 3 层上路由本地链路。如果我们假设负载均衡器只能从所述本地链路发送数据包，则仅当目标位于同一第 2 层网络中时它才有效...
两端都需要全球单播 IPv6。这听起来像是 Azure 负载均衡器上的错误配置。