我可能对 serverfault 相关问题一窍不通，但我们 IT 部门发表了一个大胆的声明，我希望验证一下。我搜索了互联网，但找不到与我的问题相关的任何内容，所以我来这里了。
我们有 Threat Management Gateway 2010，我们过去只是将请求路由到 IIS，它包含 IP 地址，因此我们可以看到它来自哪里。但现在他们打开了“请求似乎来自 TMG 服务器”，因此 IP 地址不再转发。每个请求都有 TMG 服务器的 IP。
现在，其背后的想法是，由于多路径 BGP 路由，传入请求将通过 RouteA，但确认消息可以通过 RouteB 返回。声称由于请求不是来自第一个已知来源（我们的代理），而是来自 IIS，因此我们网站访问者的一些智能路由器无法识别确认消息并将其过滤掉。换句话说，响应永远不会到达。
再次重申，这是说法。但我在互联网上找不到任何支持这一说法的资源。我确实读过关于 bgp 多路径的文章，但更多的是当最快的路由由于某种原因失败时，有替代路由的情况。
那么这个说法是完全虚假的还是有一定道理的？有人能解释一下或给我提供一些资源吗？
提前致谢！
答案1
这种不对称路由在互联网上确实经常发生。给定的 BGP 路由器可以具有多个本地首选项规则，以及对路径的不同看法以及它更喜欢使用哪些对等点。互联网路由器不知道或不关心会话通过哪个管道，这也无关紧要；只要数据包到达目的地，一切都正常。
但是，该行为与您的 Web 服务器和 TMG 代理之间的通信完全无关。
解释的问题在于此：
请求不是来自第一个已知来源，即我们的代理，而是来自 IIS
如果这是真的，那么与 Web 服务器的所有连接都将无条件失败。客户端连接到代理的 IP 地址，并期望从同一地址获得响应流量 - 作为响应流量的源 IP（跳过 TMG）的 IIS 服务器将拒绝响应流量。
TMG 之所以能够正确工作，是因为 TMG 位于您的 Web 服务器前面（只有当 TMG 位于您的 Web 服务器前面时，它才能正常工作，充当您的路由器）。TMG 会看到您的 Web 服务器发往客户端地址的响应流量，然后将其捕获并通过正确的连接（客户端发起到 TMG 的连接）将其发送到客户端。
因此，基本上，BGP 和互联网路由与此无关，但内部网络上类似的非对称路由（其中 TMG 设备不用于路由响应流量）会中断来自 Web 客户端的连接，并且需要使用 TMG IP 地址作为明显的连接源。也许他们正在计划拓扑更改？