http://www.pppei.net/blog/post/331

在作流量管理時，這些概念很重要，不要迷失。。

這里再對Limiter 的源地址和目的地址做個說明，因為limiter是被應用在Lan接口的Rule里，相對pfsense來說，用戶發往 Lan口的流量為In，pfsense通過Lan口發給用戶的流量為OUT，因此限制上傳的limiter因該應用在In方向，limiter的參照值應該為“源IP”，下載的Limiter應該應用在OUT方向，因為是轉發給用戶的所以這個limiter的參數值應該是“目的IP”。

?

另外，，，，策略路由，還有流控，就在LAN里作就OK了，，，但目前不很清楚它和FLOATING的差別。因為同樣都會生效呢。。難道FLOATING規則真的是為了不指定具體出口之類的？？？？

?

~~~~~~~~~~~~

流量管理

pfsense 有三種流量管理方法。
一是Queue，這種方式適合做QOS（服務質量保證），對數據進行分類，根據不同數據的不同特性，提供不同的服務質量，比如IP電話的語音數據，需要低網絡延時，而某用戶的下載流量只關心總帶寬，這時就可以將ip電話的數據標記出來放到低延時的隊列里，下載的流量放到只保證帶寬的隊列里，網關會用不同的算法轉發相應的數據包，達到預定的服務質量。如果要實現對每個IP分別限速，就要為每個ip都建立一個隊列，然后將每個IP的數據對應到唯這個隊列上；
二是使用Captive portal，這種方式更適合用在無線網絡環境中，用戶需要打開瀏覽器輸入用戶名密碼之后才能正常上網，同時為每個用戶分配固定的帶寬。只要開啟了Captive portal，即使關閉了認證，也還是要打開瀏覽器在彈出的頁面上點擊確定后才能上網，用在有線環境里太影響用戶體驗，而且目前Captive portal 只有全局一個實例，2.1版可以針對不同的端口啟用不同的實例；
三是使用防火墻的高功特性（這種方法是根據IP地址分別進行限速的）。在防火墻規則中限速有一個缺點，限速和訪問控制策略偶合在了一塊，失去了靈活性，配置的時候要謹慎一點不然可能會出現限速失效的情況，舉個例子，為說明簡單這里限速指的是下載限速：
①——-permit tcp any? to host 1.1.1.1 from lan————————
②——-permit any to any and speed limit 2M from Lan——

策略①中沒有做流量限制，②中每用戶的下載都限制在了2M。防火墻規則匹配是自上到下，匹配成功就不再向下進行，因此去往1.1.1.1的流量匹配了第一條策略，沒做限速，第二條規則中的限速也就失效了。

另外再對速度做個說明，同樣的策略在第一條上加上限速：
①——-permit?tcp any? to host 1.1.1.1?and speed limit at 2M from lan——-
②——-permit any to any and speed limit 2M from Lan——

去往1.1.1.1的流量還會匹配策略①，其它的流量匹配策略②，那么如果用戶同時有從1.1.1.1下載的流量和其它從其它地方下載的流量，從1.1.1.1下載.限制在2M，從其它地方下載也被限制在2M，因為是同時產生的流量，所以加起來用戶得到了4M帶寬。其實結果并不是這樣的，在防火墻規則中限速時要先定義limiter，然后在規則中引用。內部是這樣實現的，BSD的 PF（packet filter）沒有限速功能，定義出來的limiter其實是另一個防火墻實現：IPFW中的組件，這個組件實現了限速，而且這個組件支持PIPE（管道）。PF中將匹配到的下載流量通過PIPE送到IPFW的Limiter中，limiter會根據定義時規定的參照值（源、目的ip，下載參照目的IP），為每個ip生成一個bukket，數據通過bukket的速度是它所屬Limiter的速率。回到上面的例子規則 ①②中下載2M的limiter為同一個，同時匹配了兩條規則的數據，通過PIPE被送到同一個Limiter中，這個limiter會根據目的ip生成一個BUKKET，這個bukket最大速度2M，用戶得到的帶寬最大也只是2M。如果規則①中使用了其它limiter比如下載3M的limiter，那么用戶最終得到的帶寬就是5M了。

　　實施方法前邊也都說過了，很簡單了Firewall ->Traffic Shaper -> limiter 下創建Limiter（需單獨為上傳下載創建limiter） ，然后在Firewall -> rule->Lan 規則的高級特性 In/Out 中應用limiter。

這里再對Limiter 的源地址和目的地址做個說明，因為limiter是被應用在Lan接口的Rule里，相對pfsense來說，用戶發往 Lan口的流量為In，pfsense通過Lan口發給用戶的流量為OUT，因此限制上傳的limiter因該應用在In方向，limiter的參照值應該為“源IP”，下載的Limiter應該應用在OUT方向，因為是轉發給用戶的所以這個limiter的參數值應該是“目的IP”。

還有人可能會有疑問應用在Lan口只是轉發給用戶的速度慢了，從Wan口進來的流量一樣不受限制。這種想法是錯的，因為TCP有流控機質，UDP的話就要看上層應用的質量了。

在應用了新策略后，之前已經建立的連接是不會受這些規則影響的，可能得不到你想要的效果，需要在Diagnostics->States -> reset status 下清理一下pfsense的狀態，中斷用戶的連接，就能看到效果了。

如果你更習慣在命令行操作，給出一些常用命令，不用和web界面死磕了：

pfctl -sn?? #顯示nat規則
pfctl -sr ? #顯示filter規則
pfctl -sa? #顯示所有規則
pfctl -ss? #顯示防火墻狀態
pfctl -F nat #重置防火墻狀態（清空NAT狀態表）
ipfw pipe show #顯示limiter的狀態? 其中0000x 為limiter的編號 BKT一列就是為每個ip分配的bukket編號

總結

以上是生活随笔為你收集整理的pfsense下的流量管理（转）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。