對比Mac OS上的PF與iptables

昨天同事問我怎么在Mac上配置策略路由，其實我也不知道！由于自己的實際需求，一直以來都想玩Mac網絡功能，可是目光總被它炫爛的外表炫暈！今日同事這么一問我，頓時產生一種研究其究竟的欲望，還好，家里的電腦都是Mac系統(我非果粉，但老婆是)，周末帶女兒上完早教課，終于可以閑下來玩一番了...
       其實，MacOS絢爛的外表下面，是一輛坦克，其內核是具有學院派高貴血統的BSD UNIX，而我們知道，UNIX網絡的強大，TCP/IP和UNIX的關系，不禁覺得Mac的偉大，將UNIX放在時尚OL的雙膝上內窺外瞟，而這是多么偉大的一項征服！
       我的實驗拓撲如下：

iMac模擬一臺終端，WIFI關閉，Macbook模擬路由器，WIFI開啟，兩臺電腦之間用一根網線相連接。
       首先，我希望在Macbook上配置NAT，將作為內網的iMac發來的數據包做源地址轉換，此時希望的NAT是動態NAT或者類似Linux的MAQUERADE的那種。Macbook上的WIFI接口連接我家的路由器，因此需要將從WIFI口en1出去的數據包做SNAT，類似Linux的-o en1 -j MASQUERADE這種，我知道在BSD上可以通過多種方式來配置，有一種類似Linux iptables的工具，那就是pf，通過編輯/etc/pf.conf來實現配置是再好不過的了，因為pfctl擁有規則語法檢測機制，可以幫你檢查到很多錯誤，那么以上的這個需求可以通過下面的配置完成：
nat on en1 from 172.16.4.0/24 to any -> en1
其中，172.16.4.0/24是iMac所在段的地址，作為內網，而en1上則是所謂的外網地址192.168.1.108。實際上en1和地址段可以寫成變量的形式，這里為了簡單就直接寫了，至于可以寫成變量的形式，一會兒我要用這個和iptables和Cisco系統做對比。然后執行pfctl -e -f /etc/pf.conf就可以了！此時從iMac來ping 192.168.1.1路由器，就通了，然而從路由器卻無法ping內網，這明顯就是一個單向的轉換，如果要做成雙向的轉換，那么就需要一個一一對應的轉換了，在BSD中，這是通過binat實現的，主要在命令中，它加上了bi前綴，和bat區分開來，我們來看一下binat的配置：
binat on en1 from 172.16.4.10 to any -> 172.16.4.30
這樣就建立了一個一一的映射關系，不管從路由器主動發起還是從iMac主動發起，都可以實現地址轉換，這就是我上一篇文章費了好大勁在Linux上實現的那個功能，不管是BSD還是Cisco，都可以輕而易舉的完成配置，而Linux卻很難，即使使用RAWNAT也還得配置兩條規則！！！PF的一對一NAT雖然也內置了match，但你可以用any來覆蓋它，最關鍵的，它獨立成了binat，而不是nat的一個配置選項。
       NAT功能已經玩轉了，每一件事情我都是希望最先試成功一個最小集合，然后再慢慢拓展，當初第一次碰到iptables的時候也一樣。我一直都有一個疑惑，為何iptables沒有實現一對一的地址轉換？注意，Netfilter僅僅是一個框架，想實現任何功能都可以，所以我沒有埋怨Netfilter而怪罪iptables。這是一個基本的需求啊，試想一個WEB服務器在DMZ區對外提供服務，而它還需要主動的訪問另外的外部資源，這在云環境下很常見的，如果沒有一一映射NAT，光是ip_conntrack就要消耗多少資源啊，而僅僅為了轉換一個地址保持一個流是沒有必要的。任何其它的操作系統都可以很容易實現的功能，Linux為何沒有？另一個疑問就是，Mac OS為何沒有把常用的功能開放出來，比如在一塊網卡上添加多個IP。我猜想，Windows是比較中庸的系統，它提供添加多個地址，但是卻沒有iptables，iproute2之類的強大工具，即使netsh也只能算個雞肋，相反，Linux和Mac OS就比較極端，特別是Mac OS，它假設使用它的人不是愛折騰網絡的人，一個OL或者西裝革履的墨鏡先生是不會托著下巴配置策略路由的...然而在它的命令行卻提供了幾乎完整的BSD命令集，設計者又一次假設，如果一個購買Mac的人是一個技術狂，比如像我這樣，那么他總是會第一時間調出命令行的，一旦調出命令行，一切就都在他眼前了，這樣，將添加多個IP這個基本不會用到的功能做進GUI還有必要么？不禁崇敬Apple人啊！這方面，Windows和Linux都應該學習啊，我就不說重量級UNIX(比如AIX，HP-UX)了，因為那玩意兒一般人也不會接觸到，相反Windows，Linux的接觸人員還是很多的，Windows自不必說，Linux也是一款大眾系統，特別是安卓時代以后。附上本段的一個補充：說了那么多Mac OS上添加Secodary IP的問題，到底怎么添加呢？ifconfig enX $ip/$mask alias即可，關鍵字是alias！
       到了本文最關鍵的時候了。pf的配置和iptables的配置哪個更加好呢？這當然不是仁者見仁智者見智的問題，可以毫不猶豫的說，iptables完敗了！寫過iptables規則控制腳本的人都很頭疼，就是你得為你的每一個點子寫一條rule，然后噩夢就來了，你時刻要注意在什么情況下要刪除這個rule，還要確保刪除干凈...復雜的業務邏輯往往使這一點很難得到保證，于是你就只能將業務邏輯簡單化以遷就iptables...這到底是為什么？？
       其根本原因就是iptables在每條規則層面上沒有做到機制與策略分離，沒有做到策略的可配置話，整條iptables規則的操作原子就是該條規則本身，比如你無法將一個match參數化，無法將一個target參數化，舉以下例子：
iptables -A FORWARD -s 1.1.1.1 -d 2.2.2.2 -p tcp -j DROP
一旦這條規則設定了，如果有一天你控制的目標不再是2.2.2.2了，變成了3.3.3.3，那么你必須把這條規則刪掉，然后再添加一條新的規則，你無法針對match對增刪改操作。我們知道，一條規則蘊含的是一個判斷邏輯，而具體的動作一定是要參數化的，這樣才靈活，針對以上的例子規則，它蘊含的邏輯是，起始于某地到達某地的TCP包需要被丟棄！僅此而已，至于說陳述中的“某地”到底是什么，需要是可配置的。
       BSD的PF做到了這一點，它支持變量，宏等參數化配置概念。諸如最開始的NAT配置，像里面的IP地址這類配置，就可以像寫BASH腳本一樣定義。iptables的規則操作平面的缺失，確實是其硬傷，然而不能一棒子把它打死，我們知道ipset正是彌補這一缺失的努力成果之一，把匹配IP集合的定義移交給了ipset程序。我們期望見到的是很多的set，比如protoset，portset，stateset...在這方面，Cisco的NAT配置我們也可以看到類似的思想，Cisco剝離了ACL和NAT，ACL只負責match。
       但是并不是說PF就沒有任何缺點，配置太龐雜了，比如配置策略路由：從哪個網口進來的訪問包還從哪個網口出去。PF的實現方式是引入一系列硬配置route-to/reply，照這個邏輯，每一類的配置都需要引入一個配置參數咯，此法不妥啊，相反，Linux做的很好，通過mark的機制來實現策略路由，基于流的nf-mark可以標記一個流，很容易通過ip rule的fwmark來配置策略路由，策略路由本身并不是iptables負責的一塊，iptables只管打mark，至于這個mark怎么用，它不管，策略路由在Linux中是單獨實現的一塊，和Netfilter沒有任何關系。而PF則不同咯，其實它也有類似mark的tag機制，我覺得為了路由引入配置參數的方式不好。縱貫PF，它除了支持match參數化之外，其它的好像真的很亂，幾乎所有的一切都可以用PF實現，NAT只是和PASS，BLOCK平行的一個action而已，另外，像什么代理之類的，統統都有相應的配置參數，我覺得這些都可以通過tag分出去的。
       遇到PF之前，總把iptables當成寶，實際上它真的就是！PF吸引人的地方在于其配置的可維護性。如果你有Mac，那么你就真的有了一個UNIX，可以折騰，任意的蹂躪，BSD UNIX強大的網絡功能盡顯眼前。