下面是也是我在12580工作时发生的事情，重新记录并发出来。这种特殊需求很考 验PF的功底。在新旧系统并存，做重构的时候有时很需要这种救急的作法。
一、缘起
miscweb1(172.16.88.228)的系统近段时间经常死掉，没有查到最终原因，现在的
一、缘起
miscweb1(172.16.88.228)的系统近段时间经常死掉，没有查到最终原因，现在的
策略是将其中一个端口上的服务摘出来，以确认问题，所以新准备了另一台机器 (172.16.88.116)，由于miscweb1上还有别的服务，所以不能通过切换域名到新机器的 方式进行测试，另外也不方便让所有调用待迁移服务的部门手工改程序调用新的机器，这 样实施起来时间比较长，协调多个部门也困难，更可怕的是万一调用新的机器上的服务仍 然有问题的话，再改回去更加劳民伤财。
所以通过网络层的策略透明地实现，将流量从miscweb1上转到新机器上(用户仍然访问 miscweb1，但实际上是由新机器提供的服务)，将是一个简便易行、修改最小的方式。
二、用PF实现透明转发的几种方式及对比
1、miscweb1代理转发
在miscweb1上： . 起用pf . 起用三层数据包转发功能(net.inet.ip.forwarding=1) . 增加下面的pf策略
int_if="bce0" new_dump="172.16.88.116" rdr pass on $int_if proto tcp from any to any port 9999 -> $new_dump nat pass on $int_if from any to $new_dump port 9999 -> ($int_if)
rdr数据包进入(ip_input)miscweb1时，修改目标地址到新机器上，因为起用了三层转 发，它发现目标地址是不是本机的地址(而是新机器的IP)，随即通过int_if转发出去(ip_forward)。
nat在数据包即将从int_if发出去之前(ip_output)，将源地址改成int_if的接口IP地址，这样新机器 看到的请求都是来源于miscweb1，这样，不需要对新机器做任何修改，回来的流量都会通过miscweb1。
在新机器上： 不需要做任何修改
特点： . 请求及返回的流量都经过miscweb1，相当于做了代理 . 新机器上显示请求都是来源于miscweb1，看不到真实的客户端地址 . 只修改了miscweb1，新机器及客户端不需要做任何修改
2、miscweb1及新机器协同实现代理转发
在miscweb1上：
. 起用pf . 起用三层数据包转发功能(net.inet.ip.forwarding=1) . 增加下面的pf策略
int_if="bce0" new_dump="172.16.88.116" rdr pass on
$int_if proto tcp from any to any port 9999 ->
$new_dump
rdr数据包进入(ip_input)miscweb1时，修改目标地址到新机器上，因为起用了三层转 发，它发现目标地址是不是本机的地址(而是新机器IP)，随即通过int_if转发出去(ip_forward)。
在新机器上： . 起用pf . 增加下面的pf策略
int_if="bce0" old_dump="172.16.88.228" pass in quick on $int_if reply-to ($int_if $old_dump) proto tcp from any to any port 9999
reply-to策略在收到数据包时，记住回包时的转发地址，回给misceweb1，因为msicweb1是用 rdr进行转发，需要返回的数据也通过它，如果没有这策略，新机器会将这些回包直接发给缺省 网关。
特点： . 请求及返回的流量都经过miscweb1，相当于做了代理 . 新机器上显示请求能看到真实的客户端地址 . miscweb1和新机器都需要修改，协同操作，客户端不需要修改
3、miscweb1上单臂进行单方向的流量转发
在miscweb1上：
. 起用pf . 起用三层数据包转发功能(net.inet.ip.forwarding=1) . 增加下面的pf策略
int_if="bce0" new_dump="172.16.88.116" pass in quick on $int_if route-to ($int_if $new_dump) proto tcp from any to any port 9999 no state
route-to策略将包直接转发给新机器，注意后面的"no state"，这个让pf对这个策略不生成状态，也就不 按状态表转发，每个符合这条规则的包都将进行规则匹配。原因是freebsd使用的pf落后于openbsd很多 ，不支持sloppy(松散地记录状态)记录状态方式，这要在流量单臂通过(回来的流量不通过时)，导致后续 的包不能通过状态表的严格检查而中断连接。
在新机器上：
. 修改rc.conf.local，将miscweb1的ip(172.16.88.228)绑定在新蛋机的loopback接口上
特点： . 客户发过来的包都经过miscweb1，新机器回的数据包直接返回给客户端，不通过miscweb1 . 新机器上能看到客户端的真实IP . miscweb1和新机器都需要修改，协同操作，客户端不需要修改
三、其它事项
freebsd上起用pf的步骤
1、加载pf相关的内核模块
运行命令： kldload pf
修改起动配置文件(/boot/loader.conf)增加下面的配置行，让机器每次起动自动加载pf模块)： pf_load="YES"
2、起用pf，freebsd下pf缺省没有起用pf(disabled)
运行命令： pfctl -e
修改起动配置文件(/etc/rc.conf.local)，增加下面一行，让机器每次起动自动起用pf功能： pf_enable="YES"
所以通过网络层的策略透明地实现，将流量从miscweb1上转到新机器上(用户仍然访问 miscweb1，但实际上是由新机器提供的服务)，将是一个简便易行、修改最小的方式。
二、用PF实现透明转发的几种方式及对比
1、miscweb1代理转发
在miscweb1上： . 起用pf . 起用三层数据包转发功能(net.inet.ip.forwarding=1) . 增加下面的pf策略
int_if="bce0" new_dump="172.16.88.116" rdr pass on $int_if proto tcp from any to any port 9999 -> $new_dump nat pass on $int_if from any to $new_dump port 9999 -> ($int_if)
rdr数据包进入(ip_input)miscweb1时，修改目标地址到新机器上，因为起用了三层转 发，它发现目标地址是不是本机的地址(而是新机器的IP)，随即通过int_if转发出去(ip_forward)。
nat在数据包即将从int_if发出去之前(ip_output)，将源地址改成int_if的接口IP地址，这样新机器 看到的请求都是来源于miscweb1，这样，不需要对新机器做任何修改，回来的流量都会通过miscweb1。
在新机器上： 不需要做任何修改
特点： . 请求及返回的流量都经过miscweb1，相当于做了代理 . 新机器上显示请求都是来源于miscweb1，看不到真实的客户端地址 . 只修改了miscweb1，新机器及客户端不需要做任何修改
2、miscweb1及新机器协同实现代理转发
在miscweb1上：
. 起用pf . 起用三层数据包转发功能(net.inet.ip.forwarding=1) . 增加下面的pf策略
int_if="bce0" new_dump="172.16.88.116" rdr pass on
$int_if proto tcp from any to any port 9999 ->
$new_dump
rdr数据包进入(ip_input)miscweb1时，修改目标地址到新机器上，因为起用了三层转 发，它发现目标地址是不是本机的地址(而是新机器IP)，随即通过int_if转发出去(ip_forward)。
在新机器上： . 起用pf . 增加下面的pf策略
int_if="bce0" old_dump="172.16.88.228" pass in quick on $int_if reply-to ($int_if $old_dump) proto tcp from any to any port 9999
reply-to策略在收到数据包时，记住回包时的转发地址，回给misceweb1，因为msicweb1是用 rdr进行转发，需要返回的数据也通过它，如果没有这策略，新机器会将这些回包直接发给缺省 网关。
特点： . 请求及返回的流量都经过miscweb1，相当于做了代理 . 新机器上显示请求能看到真实的客户端地址 . miscweb1和新机器都需要修改，协同操作，客户端不需要修改
3、miscweb1上单臂进行单方向的流量转发
在miscweb1上：
. 起用pf . 起用三层数据包转发功能(net.inet.ip.forwarding=1) . 增加下面的pf策略
int_if="bce0" new_dump="172.16.88.116" pass in quick on $int_if route-to ($int_if $new_dump) proto tcp from any to any port 9999 no state
route-to策略将包直接转发给新机器，注意后面的"no state"，这个让pf对这个策略不生成状态，也就不 按状态表转发，每个符合这条规则的包都将进行规则匹配。原因是freebsd使用的pf落后于openbsd很多 ，不支持sloppy(松散地记录状态)记录状态方式，这要在流量单臂通过(回来的流量不通过时)，导致后续 的包不能通过状态表的严格检查而中断连接。
在新机器上：
. 修改rc.conf.local，将miscweb1的ip(172.16.88.228)绑定在新蛋机的loopback接口上
特点： . 客户发过来的包都经过miscweb1，新机器回的数据包直接返回给客户端，不通过miscweb1 . 新机器上能看到客户端的真实IP . miscweb1和新机器都需要修改，协同操作，客户端不需要修改
三、其它事项
freebsd上起用pf的步骤
1、加载pf相关的内核模块
运行命令： kldload pf
修改起动配置文件(/boot/loader.conf)增加下面的配置行，让机器每次起动自动加载pf模块)： pf_load="YES"
2、起用pf，freebsd下pf缺省没有起用pf(disabled)
运行命令： pfctl -e
修改起动配置文件(/etc/rc.conf.local)，增加下面一行，让机器每次起动自动起用pf功能： pf_enable="YES"