我的 ISP 提供 IPv6 前缀委派,但带有动态前缀。我希望为一些本地服务使用公开路由的静态前缀,因此我还设置了 Hurricane Electric 隧道,这意味着客户端必须在多地址多宿主模式。HE 隧道还要求源自 HE 静态前缀的流量通过 HE 隧道路由;否则,响应数据包将被丢弃到我的路由器上游。
隧道必然比原生 IPv6 慢,因此我希望客户端优先选择属于 ISP 动态前缀的源 IP 地址除了直接连接到本地服务时。如何配置客户端(Ubuntu 和 Windows 混合)以首选本机(但动态)“主页”?
答案1
经过进一步研究,处理这种情况的推荐方法是将路由器首选项包含在路由器广告中。从https://www.rfc-editor.org/rfc/rfc4191#section-5.1:
默认路由的最佳路由器是具有最佳通向更广阔互联网的路由的路由器。最不可能重定向流量的路由器取决于实际流量使用情况。当大多数通信实际上需要通过其他路由器时,这两个概念可能会有所不同。
例如,假设您有一个包含两个路由器 X 和 Y 的链接。路由器 X 最适合 2002::/16。(它是您的 6to4 站点网关。)路由器 Y 最适合 ::/0。(它连接到本地 IPv6 互联网。)路由器 X 将本地 IPv6 流量转发到路由器 Y;路由器 Y 将 6to4 流量转发到路由器 X。如果来自此站点的大多数流量被发送到 2002:/16 目的地,则路由器 X 是最不可能重定向的路由器。
为了使 A 类主机正常工作,两个路由器都应将自己宣传为默认路由器。具体来说,如果路由器 Y 发生故障,A 类主机应将流量发送到路由器 X 以维持 6to4 连接,因此路由器 X 和路由器 Y 需要成为默认路由器。
为了使 B 类主机正常工作,路由器 X 应使用高默认路由器首选项来宣传自己。这将导致 B 类主机优先选择路由器 X,从而最大限度地减少重定向次数。
为了使 C 类主机正常工作,路由器 X 还应以低优先级通告 ::/0 路由,并以中优先级通告 2002::/16 路由。C 类主机的路由表中最终会有三条路由:::/0 -> 路由器 X(低)、::/0 -> 路由器 Y(中)、2002::/16 -> 路由器 X(中)。它会将 6to4 流量发送到路由器 X,将其他流量发送到路由器 Y。C 类主机不会导致任何重定向。
请注意,当 C 类主机处理来自路由器 X 的路由器通告时,::/0 的低优先级将覆盖高默认路由器优先级。如果 ::/0 特定路由不存在,则 C 类主机会将高默认路由器优先级应用于其到路由器 X 的 ::/0 路由。
答案2
这不是一个真正的解决方案,但我最近发现,我可以通过配置路由器来缓解这个问题根据源地址路由数据包。 引用:
出于性能原因,ISP 委托的前缀应该是默认路由。简单的
pass
规则将允许入站请求通过隧道路由并转发到内部服务器;出站数据包就没那么容易了。服务器的响应将来自与隧道关联的静态地址,但通常会采用默认路由返回到外部客户端,随后被不为来自隧道前缀的数据包提供服务的外部路由器丢弃。我们需要通过隧道路由来自服务器的出站数据包;简而言之,我们需要基于源的路由。普法其子句提供了一个方便的基于源的路由解决方案
route-to
,但还必须禁用所有入站和出站数据包的状态跟踪,以便状态跟踪器不会绕过我们的route-to
规则。状态跟踪器默认启用,因此我们必须禁用状态跟踪对于路由上的每个接口。server = <webserver ipv6 addr> ... pass in quick on $he_if proto tcp to $server port https no state pass out quick on $lan proto tcp to $server port https no state pass in quick on $lan proto tcp from $server port https route-to $he_if no state pass out quick on $he_if proto tcp from $server port https no state ...
如果规则集设计巧妙,则可能不需要使用
quick
;我选择强调易读性而不是巧妙性。虽然可以删除这些规则的端口和协议说明符,但我发现与其他规则的交互很难管理。您的情况可能会有所不同。