细说TF服务链丨设计一个PBR+NAT的服务链
作者：Umberto Manferdini 译者：TF编译组
原文链接 ：
https://iosonounrouter.wordpress.com/2020/08/07/designing-a-pbrnat-service-chain/
在之前的文章中，我谈到了什么是服务链，如何构建服务链，如何通过高级功能的配置具备高可用性。对于想了解服务链内部的人，还介绍了路由的工作方式。
现在，我们将把所有部分放在一起，并基于PBR服务链创建一个冗余NAT服务。
让我们看一下拓扑图：
这个思路很简单：我们在左VN和右VN之间有一个网络策略，策略规则根据源地址匹配流量。这样，我们就可以在Tungsten Fabric场景下实现一个典型的PBR用例。
在上面的示例中，我们配置了2条rules：每个都有其自己的服务实例（pbrnat1和pbrnat2）。服务实例具有引用vSRX接口的端口元组。vSRX负责从左向右“natting”流量。
构建PBR的目的是为每个服务实例分配一个地址池（我们称其为左侧池）。例如，在这里服务实例pbrnat1分配了192.168.101.0/24的池（左侧池1），而pbrnat2分配了192.168.102.0/24（左侧池2）。
有2个vSRX其实就够了，但这不能提供足够的容错能力。因此，我们添加了第三个vSRX作为备份vSRX。通过在服务实例中配置多个端口元组，并设置不同的vmi本地首选项值，来手动选择主路径和备份路径，从而进行冗余管理。
这意味着，在正常情况下，源为192.168.101.0/24的流量将发送到服务实例pbrnat1并由vSRX1实现NAT。类似地，源为192.168.102.0/24的流量将发送到服务实例pbrnat2，并由vSRX2实现NAT。
当vSRX1发生故障时，映射到服务实例pbrnat1的流量将发送到备份vSRX——vSRX3。vSRX2发生故障时同理。这或许意味着vSRX3可以管理所有的池。请记住，池已映射到服务实例，并且vSRX3端口属于所有服务实例，因为它是备份vSRX。
让我们来看看如何配置用例并启用所有功能。
首先，创建虚拟网络：
如你所见，左侧VN具有多个子网。子网101和102代表NAT池（左池）；客户端VM附加到这些子网上。vSRX的左接口使用子网103。
我们来创建连接到不同子网的端口：
在此示例中，client1和client2是要NAT的“客户”，而web是类似Internet的目的地。
所有其它接口都属于这3个vSRX——由它们组成服务链并执行NAT。
接下来，我们创建服务模板：
这个对象非常标准：具有两个接口（左和右）的in-network类型。
我们基于此模板创建服务实例：
这里的关键是要有2个端口元组，总共4个接口。在此处查看冗余在服务链中的实现。两个接口属于vSRX1，本地优先级为100（active），另外两个接口被带到vSRX3，其vmi的本地优先级为200（backup）。
服务实例pbrnat2的创建过程是一样的：
当然，我们假设vSRX VM已经启动并正在运行。
现在，该创建策略了：
如预期的那样，我们有两个规则：一个匹配源192.168.101.0/24并将流量发送到服务实例pbrnat1（vsrx1主服务器），而一个匹配源192.168.102.0/24并将流量发送到服务实例pbrnat2（vsrx2主服务器）。
策略同时附加到左网络和右网络：
现在，服务链已经建立！
是时候“丰富”它了。首先，我们要控制左右VN之间的泄漏。这是通过路由策略完成的：
第一个策略仅允许默认路由，而第二个策略则拒绝所有内容。
这种0/0的方式从右到左传递，以便客户可以访问Internet。在从左到右的方向上，无需泄漏任何东西。
返回流量，post NAT，需要遵循正确的池（post nat池）路由。这些池在vSRX（在NAT规则内）内配置，并且默认情况下对Tungsten Fabric未知。这意味着返回流量将无法正常工作。为了克服这个问题，我们创建了静态路由：
每个左池（pre nat池）都有一条静态路由。
为了实验目的，我们还提供了一条默认的静态路由。
还有什么？好吧，运行状况检查可以快速收敛：
这是左侧的运行状况检查。我们将BFD（最快的运行状况检查类型）与微秒计时器一起使用（此处的收敛时间为3×300毫秒）。
右侧的运行状况检查是相同的。
最后，我们将所有这些都添加到服务实例中。这是pbrnat1的示例：
这里出现了很多信息！让我们一个一个看。
服务实例引用2个实例和4个接口（2个端口元组）。这是预期内的，因为我们配置了2个端口元组：一个通向vSRX1（active），一个通向vSRX3（backup）。
在左侧接口上，我们应用了default_only路由策略，以便从右到左的泄漏为0/0。在右侧接口上，我们应用了deny_all路由策略，因为该方向上无需泄漏任何内容。
静态路由将应用于右接口。该静态路由指向分配给该服务实例（在本例中为192.168.101.0/24）的右侧池（post nat池）。
最后，BFD运行状况检查将同时应用于左接口和右接口。
好啦！现在我们拥有了具有容错能力和快速收敛性的PBR服务链！
细说TF服务链——
Tungsten Fabric 架构解析系列文章——
第一篇：TF主要特点和用例
第二篇：TF怎么运作
第三篇：详解vRouter体系结构
第四篇：TF的服务链
第五篇：vRouter的部署选项
第六篇：TF如何收集、分析、部署？
第七篇：TF如何编排
第八篇：TF支持API一览
第九篇：TF如何连接到物理网络
第十篇：TF基于应用程序的安全策略