對比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強大的網路功能盡顯眼前。