我們正在遷移大量服務，例如從1.2.3.4到5.6.7.8。
為了測試新服務是否已正確配置，我們希望將來自我們的測試工作站的發送到原始主機的所有流量重新導向（到新主機）。
當然，這樣的重定向可以在網路本身內的路由器上實現 - 但出於穩定性原因，我們決定直接在每個工作站上實現它（都是 OS X 10.10 Yosemite，因此使用 v4.7 之前的 OpenBSD pf）。
我已經添加到/etc/pf.anchors/com.apple：
rdr-anchor "910.TestServiceMove/*"
anchor "910.TestServiceMove/*"
load anchor "910.TestServiceMove" from "/etc/pf.anchors/910.TestServiceMove"
並創建了/etc/pf.anchors/910.TestServiceMove：
rdr pass log on lo0 from any to 1.2.3.4 -> 5.6.7.8
pass out log route-to lo0 from any to 1.2.3.4 keep state
加載規則後，兩者似乎都能正常工作：
$ sudo tcpdump -v -n -e -ttt -i pflog0
tcpdump：警告：pflog0：未指派 IPv4 位址
tcpdump：監聽 pflog0，連結類型 PFLOG（OpenBSD pflog 檔案），擷取大小 65535 位元組
00:00:00.000000 規則0.910.TestServiceMove.0/0(match)：在en1 上傳遞：（tos 0x0、ttl 64、id 40691、偏移0、標誌[DF]、proto TCP (6)、長度64 TCP ）
9.9.9.9.58029 > 1.2.3.4.22：標誌 [S]、cksum 0x291a（正確）、seq 3399416413、win 65535、選項 [mss 1460、nop、wscale 5、nop、cm ,eol]，長度 0
00:00:00.000047 規則0/0(匹配): rdr in on lo0: (tos 0x0, ttl 64, id 40691, 偏移量0, 標誌[DF], proto TCP (6), 長度64, 錯誤的cksum 896a (- >b4da）！
9.9.9.9.58029 > 5.6.7.8.22：標誌[S]，cksum 0xb284（正確），seq 3399416413，win 65535，選項[mss 1460，nop，wscale 5，nop，6p ,eol]，長度 0
但是TCP握手沒有完成（SYN-ACK被忽略，並且SYN被重複發送，直到連接逾時）：
$ sudo tcpdump -v -n -e -ttt 主機 5.6.7.8
tcpdump：資料鏈路類型 PKTAP
tcpdump：監聽 pktap，連結類型 PKTAP（Packet Tap），捕捉大小 65535 位元組
00:00:00.000000 e8:80:2e:e7:67:bc > 84:80:2d:35:e5:43，以太型IPv4 (0x0800)，長度78：(tos 0x0，ttl 63，id 40691，偏偏移量 0 ，標誌 [DF]，原始 TCP (6)，長度 64)
9.9.9.9.58029 > 5.6.7.8.22：標誌[S]，cksum 0xb284（正確），seq 3399416413，win 65535，選項[mss 1460，nop，wscale 5，nop，6p ,eol]，長度 0
00:00:00.015524 84:80:2d:35:e5:43 > e8:80:2e:e7:67:bc，以太類型IPv4 (0x0800)，長度74：(tos 0x0，ttl 52，id 0，偏移量 0 ，標誌 [DF]，原始 TCP (6)，長度 60)
5.6.7.8.22 > 9.9.9.9.58029：標誌[S.]，cksum 0x7ce4（正確），seq 1901846890，ack 3399416414，win 14480，選項[mss 1460，pack p、wscale 7 ]，長度0
00:00:00.986946 e8:80:2e:e7:67:bc > 84:80:2d:35:e5:43，以太型IPv4 (0x0800)，長度78：(tos 0x0，ttl 63，id 25319，偏偏移量 0 ，標誌 [DF]，原始 TCP (6)，長度 64)
9.9.9.9.58029 > 5.6.7.8.22：標誌[S]，cksum 0xae9c（正確），seq 3399416413，win 65535，選項[mss 1460，nop，wscale 5，nop，6p，TS 65063 367 ,eol]，長度 0
00:00:00.014938 84:80:2d:35:e5:43 > e8:80:2e:e7:67:bc，以太類型IPv4 (0x0800)，長度74：(tos 0x0，ttl 52，id 0，偏移量 0 ，標誌 [DF]，原始 TCP (6)，長度 60)
5.6.7.8.22 > 9.9.9.9.58029：標誌[S.]，cksum 0x78fa（正確），seq 1901846890，ack 3399416414，win 14480，選項[mss 1460，pack p、wscale 7 ]，長度0
00:00:00.397794 84:80:2d:35:e5:43 > e8:80:2e:e7:67:bc，以太類型IPv4 (0x0800)，長度74：(tos 0x0，ttl 52，id 0，偏移量 0 ，標誌 [DF]，原始 TCP (6)，長度 60)
5.6.7.8.22 > 9.9.9.9.58029：標誌[S.]，cksum 0x776c（正確），seq 1901846890，ack 3399416414，win 14480，選項[mss 1460，g nop、wscale 7 ]，長度0
00:00:00.588237 e8:80:2e:e7:67:bc > 84:80:2d:35:e5:43，以太型IPv4 (0x0800)，長度78：(tos 0x0，ttl 63，id 50201，偏偏移量 0 ，標誌 [DF]，原始 TCP (6)，長度 64)
9.9.9.9.58029 > 5.6.7.8.22：標誌[S]，cksum 0xaab4（正確），seq 3399416413，win 65535，選項[mss 1460，nop，wscale 5，nop，nop，TSOK. ,eol]，長度 0
我猜 TCP 堆疊正在丟棄源自 SYN 發送目標主機以外的主機的 SYN-ACK。但重定向規則不應重寫流量兩個都方向——確實，不應該keep state確保為此目的追蹤連接嗎？