Thứ Tư, 29 tháng 3, 2017

Pfsense 2.2: Setup Wireless N using pci-e WIFI card

Pfsense 2.2: Setup Wireless N using pci-e WIFI card

 sekular

2 years ago

Goals

1) Turn PFSense in to a Wireless N Access Point using an internal pci-e WIFI Card.

Requirements:

1) Pfsense 2.2 install on a physical device, with a compatible internal WIFI card.
2) See compatible cards: https://doc.pfsense.org/index.php/Supported_Wireless_Cards

In this example I will be using: D-Link DWA-556 Xtreme N 300M PCI-Express AR5418

Steps

1) Add the WIFI interface
2) Configure the WIFI interface
3) Setup DHCP for the interface
4) Add the Allow all firewall rule for the interface

Step 1) Add the WIFI interface

Add the interface by going to Interfaces->(assign)
Click the + to add a new interface
On the drop down select your wireless adapter. Should be ath0 orsimilar.

Step 2) Configure the WIFI interface

Click on the new interface Title usually “opt1” so that we can edit the interface. (Alternatively go to interfaces and click on the new interface from there.)
Click to enable the new interface.
Name the interface “WIFI”
Set the ipv4 IP Address to 5.5.5.1 with a cidr of /24
Gateway does not need to be set.

Set the standard to 802.11ng
Set the Channel to one that is least used around your area.
Set the region information under regulatory settings.

Set the Mode to Access Point
Set the SSID as desired
Set the Minimum wireless standard to 802.11n
Enable WME tickbox
Enable WPA and set a passphrase
Set WPA Mode to WPA2
Set WPA Pairwise to AES

Save the configuration

Step 3) Setup DHCP for the interface

Go to Services->DHCP Server
Select the WIFI interface Tab.
Enable DHCP on the interface Tickbox.
Set the Range from: 5.5.5.100 to 5.5.5.150

Save the DHCP server configuration.

Step 4) Add the Allow all firewall rule for the interface

Go to Firewall->Rules
Select the WIFI interface (tab)
Click add new rule.
Set the TCP/IP Version to TCP/UDP
Set the Source to WIFINET (when WIFI is the name of the WIFI interface)
Set the Destination to any

Saving the configuration.
Firewall rules should look like this, to allow all outbound traffic on the interface.

Go to Status->Interfaces

Additional information:

1) As of PFSense 2.2 some wireless N cards are supported.

2) If changing modes between g and n, pfsense may need a reboot before it goes in to n mode.

Thứ Hai, 27 tháng 3, 2017

Giới thiệu pfSense v. 2

1. Giới thiệu pfSense v. 2

http://www.hvaonline.net/hvaonline/posts/list/33338.hva

Đường truyền Internet của bạn thường xuyên tắc nghẹt? Trước khi thuê thêm băng thông, hãy thử nghĩ đến tận dụng tối đa hiệu quả băng thông có sẵn bằng chính sách định tuyến (routing) và định hình (shaping) lưu thông hợp lý.

Định tuyến lưu thông là quyết định đưa loại lưu thông nào vào ngả (gateway) nào phù hợp. Có thể ví việc định tuyến như công tác điều độ nút giao thông, trong đó mỗi tuyến (route) có thể ví như một tuyến đường và bộ định tuyến (người điều độ) sẽ xác định gói tin (chiếc xe) nào đi theo tuyến (tuyến đường) nào rồi dựa vào đó quyết định cho đi theo ngả (ngả đường) nào. Nếu như với một gói tin nhất định có nhiều ngả có thể dùng được, bộ định tuyến sẽ cân bằng tải (load balance), nghĩa là quyết định chọn ngả để gửi gói tin sao cho lưu lượng tức thời trên các ngả được phân bổ đồng đều.

Định hình lưu thông là quyết định đưa loại lưu thông nào vào hàng (queue) nào dành cho nó. Các gói tin đã vào trong một hàng sẽ được phục vụ theo thứ tự ai vào trước thì ra trước, ai vào sau thì ra sau (first-in-first-out, FIFO). Nếu một đường truyền có thể ví như một con đường thì một hàng có thể ví như 1 làn xe trên con đường ấy, các xe đã vào làn thì đi đúng thứ tự, không bao giờ xe sau vượt xe trước. Mỗi hàng (làn xe) có các thông số chất lượng phục vụ (QoS) như băng thông, độ trễ, mức ưu tiên,... (ví như tốc độ lưu thông, chiều rộng làn đường,...) được tính toán phù hợp cho loại lưu thông. Nhờ đi theo hàng riêng với chất lượng phục vụ phù hợp mà lưu thông download / upload như FTP, bit torrent,.... vẫn được cấp băng thông lớn nhưng đồng thời lưu thông có độ tương tác cao như điện thoại, hội nghị truyền hình, trò chơi trực tuyến, điều khiển từ xa,... vẫn lưu thông trôi chảy với trễ nhỏ.

Cả hai việc định tuyến và định hình lưu thông đều đòi hỏi phải nhận dạng được lưu thông. Nhận dạng càng chuẩn xác thì định tuyến và định hình lưu thông càng tinh vi, càng có thể đáp ứng nhu cầu của người sử dụng hơn. Ở lớp 4 chỉ nhận dạng lưu thông theo địa chỉ nguồn, địa chỉ đích, cổng nguồn và cổng đích của gói tin. Trong khi đó ở lớp 7 có thể nhận dạng lưu thông theo toàn thể nội dung của gói tin. Ở lớp 4 việc nhận dạng chỉ dựa trên khảo sát có trạng thái (stateful inspection) nghĩa là ghi nhớ trạng thái của kết nối và xem xét thông tin của gói tin trên cơ sở biết gói tin ấy thuộc về kết nối nào, đang ở trong trạng thái nào. Ở lớp 7 việc nhận dạng là dựa trên thẩm định (deep inspection) nghĩa là trên cơ sở hiểu thấu từng chi tiết nội dung lưu thông.

pfSense, firmware với giao diện Web mã nguồn mở vốn dĩ đã tích hợp sẵn trong nhân của nó phần mềm tường lửa pf với chức năng định tuyến và định hình lưu thông, hỗ trợ nhiều WAN và nhiều LAN, có thể giải quyết vấn đề định tuyến và định hình lưu thông cho điểm truy cập Internet nhiều đường truyền. (Ở đây từ điểm truy cập ngụ ý nơi có thể quy tập mọi đường truyền Internet về một thiết bị duy nhất, ví dụ một điểm truy cập Internet là một trụ sở, một chi nhánh hay một trung tâm dữ liệu của một doanh nghiệp nhỏ.) Tuy nhiên pfSense ở phiên bản 1 (mới nhất v.1.2.3-RELEASE) chỉ hỗ trợ định hình lưu thông một WAN một LAN và chỉ nhận dạng lưu thông ở lớp 4. Chỉ phiên bản 2 (mới nhất v. 2.0 BETA 1) mới hỗ trợ đầy đủ định hình lưu thông nhiều WAN nhiều LAN và nhận dạng lưu thông ở lớp 7.

Do khuôn khổ, bài viết này chỉ giới hạn ở kỹ thuật định tuyến và định hình dựa trên nhận dạng lưu thông ở lớp 4.



2. Sơ đồ mạng

Để làm ví dụ, trong suốt bài này chúng ta sẽ dùng một sơ đồ mạng cụ thể. Ta sẽ cấu hình pfSense trong một sơ đồ gateway – firewall, tức là một tổ hợp nhiều WAN nhiều LAN cấu thành từ hai thiết bị: thiết bị trong, F (viết tắt của Firewall), với nhiều cổng LAN và một cổng WAN, và thiết bị ngoài, G (viết tắt của Gateway), với một cổng LAN và nhiều cổng WAN. Các cổng LAN của F sẽ được dẫn vào các mạng con cục bộ. Cổng WAN duy nhất của F được nối với cổng LAN duy nhất của G. Các cổng WAN của G sẽ được dẫn ra các đường truyền Internet. Thực tế, F có thể tượng trưng cho một tổ hợp phức tạp gồm nhiều tường lửa và nhiều bộ định tuyến dùng làm trung tâm của mạng cục bộ. Việc này không ảnh hưởng gì đến việc cấu hình pfSense, nên chi tiết không được đề cập; pfSense mà ta sẽ cấu hình trong bài này được cài đặt trên G.

Chúng ta có bốn đường truyền Internet. Hai đường PPPoE 10 mbps của ISP A (11.1.0.91 và 11.2.0.92), có chung một gateway (11.0.0.10). Ta sẽ dẫn hai đường này vào các giao diện OPT1, OPT2 của pfSense. Một đường PPPoE 16 mbps của ISP B (12.0.0.93), với gateway 12.0.0.10. Ta sẽ dẫn đường này vào giao diện OPT3. Cuối cùng một đường 4 mbps (10.0.0.90) dẫn đến từ một gateway (10.0.0.10) thuộc trung tâm dữ liệu của công ty liên thông với Internet, thuê của ISP C. Ta sẽ dẫn đường này vào giao diện WAN của pfSense.

Ngoài ra, để cân bằng tải pfSense cần thường xuyên kiểm tra từng đường truyền xem nó còn sống hay không bằng cách ping đến 1 địa chỉ IP ở đầu bên kia đường truyền; việc này gọi là giám sát (monitor) địa chỉ IP. Mặc định, địa chỉ IP được giám sát chính là gateway. Nhưng hai đường truyền thuê của ISP A ở đầu đằng kia lại có cùng gateway, nên ta phải chọn giám sát hai máy khác ở đầu bên kia đường truyền, và phải là hai máy khác nhau (11.0.0.11, 11.0.0.12). Thật ra chúng cũng là hai gateway của ISP A ở rất gần, nhưng không phải là gateway gần nhất.

Code:

11.0.0.11       11.0.0.12
                                \             /
                   ISP C         \   ISP A   /         ISP B
                                  \         /          
                 10.0.0.10         11.0.0.10         12.0.0.10
                     |            /         \            |
                     |           |           |           |
                     |           |           |           |
                     |           |           |           |
              +------+-----------+-----------+-----------+------+
              |  10.0.0.90   11.1.0.91   11.2.0.92   12.0.0.93  |
              |     WAN        OPT1        OPT2        OPT3     |
              |                                                 |
              |                        G                        |
              |                                                 |
              |                       LAN                       |
              |                      .0.41                      |
              +------------------------+------------------------+
                                       |
                                       |
              +------------------------+------------------------+
              |                      .0.42                      |
              |                       WAN                       |
              |                                                 |
              |                        F                        |
              |                                                 |
              |  LAN1     LAN2     LAN3        ...        LAN9  |
              |  .1.1     .2.1     .3.1                   .9.1  |
              +---+--------+--------+-----------------------+---+ 
                  |        |        |                       |
               .1.0/24  .2.0/24  .3.0/24                 .9.0/24




3. Vài thuật ngữ về tường lửa pf

Phần mềm pfSense dựa trên tường lửa pf trong nhân của hệ điều hành, vốn dĩ là một tường lửa có trạng thái và tích hợp cả chức năng định tuyến và định hình lưu thông. Nhờ thế, định tuyến và định hình lưu thông cũng là có trạng thái. Một gói tin khởi xướng cho một kết nối (connection) từ một mạng (chẳng hạn, cục bộ) hướng ra một mạng khác (Internet), hễ đã đi vào pfSense qua một giao diện nhất định nào đó (LAN) và đã được định tuyến đi ra khỏi pfSense qua một giao diện nhất định nào đó (OPT1), sẽ tạo ra một kết nối mà trạng thái (state) của nó sẽ được ghi nhớ và theo dõi. Như thế gói tin khởi xướng ra kết nối đã vạch sẵn ra tuyến đi và tuyến về cho mọi gói tin tiếp theo của kết nối ấy: gói đi theo một tuyến (LAN → OPT1), và gói về theo tuyến ngược lại (OPT1 → LAN). Việc định tuyến các gói về đến giao diện (OPT1) là việc của bộ định tuyến trước pfSense (tức bộ định tuyến của ISP A trong ví dụ này), việc nhận ra đó là một gói quay về (hơn là một gói khởi xướng kết nối mới), xác định nó về thuộc về kết nối nào và định tuyến cho nó tới giao diện đúng (LAN) là việc của pfSense.

Giao diện LAN đuợc gọi là giao diện vào (in) và giao diện OPT1 được gọi là giao diện ra (out) của kết nối ví dụ nói trên. (Như thế ở đây, “vào” và “ra” được hiểu theo nghĩa gói tin khởi xướng đi vào trong hay đi ra khỏi thiết bị pfSense, nghĩa là hiểu từ con mắt quan sát của một người đứng bên trong thiết bị mà xét đoán hướng đi của gói tin khởi xướng.) Mặt khác, việc định tuyến mọi gói tin luôn được thực hiện trên giao diện thu (receiving) gói tin đến còn việc định hình lưu thông thì được thực hiện trên giao diện phát (transmitting) gói tin đi, bất kể gói tin ấy có phải là gói tin khởi xướng kết nối hay không. Như vậy, trong mọi kết nối, trên tuyến đi, việc định tuyến diễn ra tại giao diện vào, việc định hình diễn ra tại giao diện ra; còn trên tuyến về thì ngược lại, việc định tuyến diễn ra trên giao diện ra và việc định hình diễn ra tại giao diện vào. Cần nhớ rằng, trong trường hợp kết nối từ Internet đến một server đặt trong mạng cục bộ, “đi” nghĩa là đi vào mạng cục bộ, “về” là quay trở ra Internet.



4. Cấu hình cơ bản

Bắt đầu với việc cấu hình môi trường xung quanh pfSense. Cấu hình giao diện WAN của thiết bị F với địa chỉ IP tĩnh là .0.42 với subnet mask /30. Với thiết bị F ta cũng có thể cấu hình giao diện WAN nhận địa chỉ IP động cấp bằng DHCP (do một số loại thiết bị F với một giao thức định tuyến như OSPF sẽ làm việc hiệu quả hơn khi WAN của nó nhận địa chỉ IP động). Nếu ta làm thế thì cần nhớ khi sau khi cài đặt pfSense hãy cấu hình luôn DHCP server trên giao diện LAN cho phù hợp. Thiết bị F phải cấu hình để nó biết định tuyến đến đích .0.40/30 theo giao diện WAN, cùng với tuyến mặc định.

Giả sử máy G vừa mới cài đặt xong pfSense, chưa đấu nối mạng. Bước cuối cùng của quá trình cài đặt là tạo ra giao diện WAN và LAN (bắt buộc) cũng như OPT1, OPT2 và OPT3 (tùy chọn) và chỉ định card mạng cho chúng. Giả sử máy có các card mạng em0, em1, em2,..., em5 và do sơ đồ đấu nối vật lý, ta đã chỉ định LAN = em1 và WAN = em0. Ngoài ra, còn OPT1 = em4, OPT2 = em5, OPT3 = em3 thì chúng ta mới dự định gán như thế nhưng chưa gán. Lúc này, pfSense khởi động với cấu hình mặc định, như sau:

Giao diện WAN có DHCP client nhận địa chỉ IP động từ ISP.

Giao diện LAN tự gán địa chỉ IP tĩnh .1.1/24 và có DHCP server cấp địa chỉ IP cho các client trong mạng cục bộ.

Trang Web điều khiển sẵn sàng phục vụ trên giao diện LAN cổng 80, với username = admin và password = pfsense.

Từ console của pfSense, chọn mục 2 -- Set Interface(s) IP address -- và đặt lại địa chỉ IP cho giao diện LAN đúng như sơ đồ trên, với subnet mask /30, đồng thời cấu hình DHCP server cho giao diện này nếu cần.

Lúc này, cần phải tạo luôn một tuyến tĩnh (static route) để pfSense có thể định tuyến mọi gói tin vào các mạng con cục bộ liên thông gián tiếp với pfSense qua thiết bị F (tức LAN1, LAN2, LAN3,..., LAN15 trên sơ đồ). Việc này thực hiện bằng một trong hai cách.

Cách thứ nhất, từ console của pfSense, chọn mục 8 -- Shell -- và ở dấu nhắc # gõ dòng lệnh:
Code:

route add -net 192.168.0.0/16 192.168.0.42



Trong đó 192.168 là giá trị của hai octet đầu tiên của địa chỉ IP cho mạng cục bộ. Tất nhiên ta có thể chọn dùng giá trị khác cho hai octet này, chẳng hạn 10.0 hay 172.16. Rồi cắm dây mạng nối cổng LAN với thiết bị F như sơ đồ.

Cách thứ hai, cắm dây mạng nối cổng LAN với thiết bị F như sơ đồ. Dùng máy vi tính PC liên thông trực tiếp với giao diện LAN của pfSense và được gán địa chỉ IP phù hợp (.0.42) để truy cập trang Web điều khiển. Từ menu chính vào mục System: Routing, click tab Routes, gõ dấu "+" tạo 1 tuyến tĩnh (static route) mới với destination network = 192.168.0.0/16 và gateway = LAN, rồi Save.

(Nên biết rằng tuyến tĩnh không phải là giải pháp duy nhất. Trên pfSense có thể cài đặt thêm giao thức OSPF. Nếu mọi thiết bị khác trong mạng đều hỗ trợ OSPF thì dùng OSPF sẽ rất hiệu quả trong trường hợp thiết bị pfSense có nhiều giao diện LAN hay mạng cục bộ có nhiều dải địa chỉ IP hỗn tạp. Nhưng trong trường hợp này thiết bị pfSense của chúng ta có cấu trúc rất đơn giản, chỉ có một giao diện LAN, và mạng cục bộ của chúng ta được đánh địa chỉ IP rất đơn giản, tất cả các mạng con cục bộ đều thuộc một dải địa chỉ IP, chẳng hạn, 192.168/16, nên chúng ta sẽ không mất thời gian cài đặt vận hành OSPF trên pfSense.)

Tiếp đó là tạo các giao diện OPT1, OPT2, OPT3 và chỉ định card mạng OPT1 = em4, OPT2 = em5, OPT3 = em3. Từ trang Web điều khiển, vào Interfaces: assign, ta sẽ nhìn thấy hiện giờ mới có hai giao diện LAN và WAN. Click dấu "+" sẽ tạo ra thêm giao diện OPT1. Click vào combo bên cạnh OPT1, chọn em4. Để tạo ra và chỉ định card mạng cho OPT2 và OPT3, cũng làm tương tự. Rồi Save.

Sau đó, cần kích hoạt và cấu hình các giao diện WAN, OPT1, OPT2, OPT3.

Vào Interfaces: WAN. Check vào Activate. Chọn Type = Static. Điền IP address = 10.0.0.90, click combo cạnh đó, chọn /8. Click vào Gateway để tạo một gateway mới, mà nó sẽ được tự động đặt tên, ví dụ, GW_WAN. Đối với gateway này, điền địa chỉ IP = 10.0.0.10. Rồi cắm dây mạng dẫn từ xDSL modem, cable modem hay FTTx convertor vào cổng WAN.

Vào Interfaces: OPT1. Check vào Activate. Chọn Type = PPPoE. Điền username, password, MTU, service name và các thông số khác của kết nối Internet theo thông tin mà ISP cung cấp. Check vào Block private networks để chặn các dải địa chỉ mạng cục bộ (vốn dĩ bị cấm lưu thông trên Internet, như 10/8, 172.16/12, 192.168/16). Check vào Block bogon networks để chặn các dải địa chỉ bị cấm khác (như 169.254/16) hay các dải chưa được cấp và vì thế mà cũng không nên cho phép lưu thông (như 08, 5/8, 192.0.2/24). Danh sách đầy đủ các địa chỉ "bogon" này có thể xem ở mục Diagnostics: Show Bogons. Rồi cắm dây mạng từ dẫn từ xDSL modem, cable modem hay FTTx convertor vào cổng OPT1.

Với OPT2 và OPT3 cũng làm tương tự như trên.

Vào System: Routing, tab Gateways. Sẽ hiện ra một bảng đủ cả 5 gateway ứng với 5 giao diện: LAN, WAN, OPT1, OPT2, OPT3. Ta hãy chọn gateway ứng với giao diện WAN làm default gateway. Đặc biệt là cấu hình IP của các OPTx là động nên địa chỉ IP của gateway được đánh dấu là "dynamic" và sẽ được được điền tự động vào bảng. Hãy kiểm tra lại thông tin về các gateway. Đối với OPT1 và OPT2 ta cần điền thêm Monitor IP lần lượt là 11.0.0.11 và 11.0.0.12.
Để kiểm tra kỹ hơn nữa, vào Diagnostics: Routes để xem bảng định tuyến hệ thống. Trong bảng này mỗi tuyến có một hay vài Flags ký hiệu bằng các chữ cái như bảng định tuyến của hệ điều hành FreeBSD chuẩn: U = Up (tuyến đang hoạt động), H = Host (đích tuyến là 1 máy đơn), G = Gateway (tuyến dẫn đến một bộ định tuyến khác), S = Static (tuyến tĩnh), C = Clone, W = Was cloned, L = Link. Cần lưu ý rằng bảng định tuyến hệ thống được dùng để định tuyến ở lớp 3, nghĩa là không phân biệt giao thức, cổng nguồn, cổng đích và không ghi nhớ hay khai thác trạng thái kết nối. Và bảng định tuyến này được dùng làm bảng định tuyến mặc định, nghĩa là chỉ được dùng khi các quy tắc định tuyến có trạng thái ở lớp 4 (xem phần sau) không chỉ rõ tuyến phải đi.

Với default gateway, đến đây, ta đã có thể bắt đầu truy cập được Internet từ pfSense theo gateway này. Ta hãy cập nhật firmware. Vào System: Firmware, tab Updater Settings, ở Default Auto Update url chọn v. 2.0, rồi Save. Sau đó vào tab Auto Update, nếu có bản cập nhật mới hơn bản mà ta đang dùng thì ta sẽ đọc được thông báo “A new version is now available” và số hiệu bản mới, hãy chọn Invoke Auto Upgrade và chờ vài phút để hệ thống tải bản mới về, cài đặt và tự khởi động lại. 

5. Định tuyến lưu thông

Khi định tuyến với vài đường truyền Internet, mỗi loại lưu thông có thể theo một quy tắc riêng. Ví dụ, với bốn đường truyền Internet thuộc ba ISP của chúng ta, giả sử rằng ta quyết định sẽ sử dụng ba đường OPT1, OPT2 và OPT3 làm đường chính để truy cập Internet theo một số quy tắc như sau.

    Any Link. Dùng cả ba đường OPT1, OPT2, OPT3, cân bằng tải với nhau.
    ISP A first. Hai đường của ISP A cân bằng tải với nhau và được ưu tiên dùng; chỉ khi chúng đứt hay quá tải thì mới nhảy sang dùng đường truyền của ISP B.
    ISP B first. Đường truyền của ISP B được ưu tiên dùng; chỉ khi nó đứt hay quá tải thì mới nhảy sang dùng hai đường của ISP A, và hai đường này sẽ cân bằng tải với nhau.
    ISP A only. Chỉ dùng hai đường của ISP A, và chúng cân bằng tải với nhau. Không bao giờ nhảy sang đường truyền của ISP khác.
    ISP B only. Chỉ dùng đường của ISP B, không bao giờ nhảy sang đường khác.
    ISP A 1 first. Đường OPT1 của ISP A được ưu tiên dùng; chỉ khi nó bị đứt hay quá tải thì mới nhảy sang dùng đường OPT2 của ISP này; và chỉ khi cả hai đường ấy đứt hay quá tải thì mới nhảy sang đường OPT3 của ISP B.
    ISP A 2 first. Đường OPT2 của ISP A được ưu tiên dùng; chỉ khi nó bị đứt hay quá tải thì mới nhảy sang dùng OPT1 của ISP này; và chỉ khi cả 2 đường ấy đứt hay quá tải thì mới nhảy sang đường OPT3 của ISP B.
    ISP A 1 only. Chỉ dùng đường OPT1 của ISP A. Không bao giờ nhảy sang đường khác.
    ISP A 2 only. Chỉ dùng đường OPT2 của ISP A. Không bao giờ nhảy sang đường khác.


Để định tuyến tốt, cần phân tích các đặc điểm kỹ thuật, kinh doanh của từng đường truyền Internet như băng thông, độ trễ, khoảng cách đến các mạng, phương thức ngăn chặn và kiểm soát đường truyền nếu có, chính sách bảo mật, độ tin cậy, độ tin tưởng lẫn nhau,... rồi trên cơ sở đó vạch ra một chính sách định tuyến phù hợp. Giả sử chúng ta đã thiết lập chính sách định tuyến như sau.

a) Gửi e-mail từ mail server của company1.com theo quy tắc ISP A 1 only. Đường truyền này được đăng ký cho company1.com và là đường truyền duy nhất hợp lệ để gửi e-mail từ miền này.

b) Gửi e-mail từ mail server của company2.com theo quy tắc ISP A 2 only. Lý do tương tự như trên.

c) Gửi e-mail từ mail server khác hay từ máy trạm của người sử dụng theo quy tắc ISP B only. Đó là thư rác, không được để chúng phát tán đi theo những đường truyền đã đăng ký cho các mail server hợp lệ vì như thế sẽ giảm uy tín của những mail server hợp lệ. Khi cần phải "đổ rác", ta dùng ISP B.

d) Yahoo Instant Messenger (YIM) từ client thuộc các mạng con cục bộ LAN1 - LAN3 truy cập Internet theo quy tắc ISP A 1 first. Mỗi lần YIM client nhảy từ đường truyền này sang đường truyền khác, nó sẽ logout login, gây khó chịu cho người dùng.

e) YIM từ client có thuộc LAN4 - LAN7 truy cập Internet theo quy tắc ISP A 2 first. Lý do như mục d) ở trên.

f) Truy cập DNS ra Internet từ các mạng con cục bộ LAN4, LAN8 và LAN9 theo quy tắc ISP A only. Ba mạng đó là những mạng có DNS forwarder chính thức có quyền phục vụ mạng cục bộ. ISP A được xem là một đối tác chuyên nghiệp hơn về mặt kinh doanh – giữ đúng cam kết băng thông, trung lập về chính trị, không kinh doanh tràn lan nhiều ngành nghề, có chính sách bảo mật thông tin khách hàng nghiêm túc,... do đó đáng tin cậy hơn các ISP khác.

g) Truy cập DNS ra Internet từ các mạng con cục bộ khác theo quy tắc ISP B first. Các truy cập DNS này có lẽ đều sinh từ phần mềm gửi thư rác hay mã độc khác trên một máy tính của user đã bị tin tặc chiếm quyền kiểm soát. Khi cần phải "đổ rác", ta dùng ISP B.

h) Truy cập NTP ra Internet theo quy tắc ISP A only. NTP là loại lưu thông cần trễ thấp. Các NTP server cấp 1 (stratum 1) đều đặt ở nước ngoài mà đối với khu vực này này ISP A cho trễ thấp hơn ISP B.

i) Truy cập các Web site trong nước theo quy tắc ISP A first. ISP B được xem là một đối tác chuyên nghiệp hơn về kỹ thuật. Các proxy của ISP B chặn ngang đường truyền quốc tế nhưng không gây ra trở ngại nào, còn các proxy của ISP A thường xuyên làm chậm hay làm đứt kết nối Web quốc tế. Nhưng mặt khác, đo kiểm cho thấy băng thông 16 mb/s của đường truyền của ISP B chỉ là danh nghĩa, còn thực tế cũng chỉ đạt khoảng 10 mb/s, còn ISP A giữ đúng được băng thông 10 mb/s cho mỗi đường truyền. Cuối cùng, thống kê ở site cho thấy lưu lượng truy cập Web trong nước lớn gấp đôi lưu lượng truy cập Web nước ngoài. ISP A có hai đường truyền, chất lượng phục vụ truy cập Web trong nước của mỗi đường đều ngang với đường ISP B. Vì thế, sẽ hợp lý và cân bằng nếu chuyên dùng hai đường ISP A để phục vụ truy cập Web trong nước và đường ISP B để phục vụ truy cập Web nước ngoài.

j) Truy cập các Web site nước ngoài theo quy tắc ISP B first. Lý do xem mục i) trên.

k) Các lưu thông còn lại theo quy tắc Any Link. Về các loại dịch vụ khác, cả ba đường truyền và cả hai ISP có chất lượng phục vụ như nhau.


Mỗi quy tắc trong chính sách nói trên sử dụng một gateway hay một nhóm gateway. Nếu ví thiết bị pfSense như một nút giao thông thì một gateway tượng trưng cho một ngả đường, gồm có một cặp thông tin: một giao diện (interface) và địa chỉ IP của một bộ định tuyến lân cận giao diện ấy (gateway). (Chú ý rằng có sự nhập nhằng về thuật ngữ. Ngoài nghĩa trên, từ gateway còn dùng để chỉ một bộ định tuyến, hoặc địa chỉ IP của một bộ định tuyến lân cận, và trong ngữ cảnh đó đôi khi còn gọi là next hop. Quả thật pfSense dùng từ này theo cả ba nghĩa, phân biệt bằng ngữ cảnh.) Trong ví dụ của chúng ta, vào System: Routings: tab Gateways ta sẽ thấy hiện giờ ta đã có năm gateway như sau.
Code:

Name   Interface Gateway     Monitor IP Description
====== ========= =========== ========== =========================
LAN_GW LAN       .0.42       .0.42      LAN static gateway
GW_WAN WAN       10.0.0.10   10.0.0.10  ISP C static gateway
ISPA1  OPT1      11.0.0.10   11.0.0.11  ISP A 1st dynamic gateway
ISPA2  OPT2      11.0.0.10   11.0.0.12  ISP A 2nd dynamic gateway
ISPB   OPT3      12.0.0.10   11.0.0.13  ISP B gateway
====== ========= =========== ========== =========================


Quy tắc ISP B only chỉ đòi hỏi một gateway duy nhất là ISPB, tức gateway (đã có sẵn) ứng với giao diện OPT3. Quy tắc ISP A 1 only và ISP A 2 only cũng tương tự. Mỗi quy tắc còn lại đòi hỏi một nhóm gateway. Một nhóm gateway tượng trưng cho một quy tắc định tuyến phức tạp, bao gồm một hay nhiều tầng (tier), mỗi tầng lại gồm một hay nhiều gateway. Các tầng được đánh số 1, 2, 3,... ứng với mức ưu tiên (priority). Khi định tuyến, tầng 1 được ưu tiên huy động trước tiên. Chỉ khi nào một tầng bị quá tải thì tầng kế tiếp mới được huy động. Các gateway cùng thuộc một tầng, do có cùng mức ưu tiên, sẽ được cân bằng tải với nhau khi tầng ấy được huy động.

Như vậy, để thực hiện các quy tắc trong ví dụ trên, ta vào System: Routings: tab Groups, lần lượt tạo ra các nhóm gateway như sau.

    AnyLink. Cả ba gateway ISPA1, ISPA2, ISPB thuộc tầng 1.
    ISPBfirst. ISPB thuộc tầng 1, ISPA1 và ISPA2 thuộc tầng 2.
    ISPAfirst. ISPA1 và ISPA2 thuộc tầng 1, ISPB thuộc tầng 2.
    ISPAonly. ISPA1 và ISPA2 thuộc tầng 1.
    ISPA1first. ISPA1 thuộc tầng 1. ISPA2 thuộc tầng 2. ISPB thuộc tầng 3.
    ISPA2first. ISPA2 thuộc tầng 1. ISPA1 thuộc tầng 2. ISPB thuộc tầng 3.


Tiếp theo, cần chuẩn bị những bí danh (alias), tức là những tập hợp gồm một hay nhiều dải địa chỉ IP để về sau có thể tiện tham chiếu. Vào Firewall: Aliases, click vào nút “+” và tạo một bí danh mới, Servers, mà ta sẽ cần để thực hiện điểm f) của chính sách định tuyến, gồm có ba dải địa chỉ IP: LAN4 (.4.0/24), LAN8 (.8.0/24) và LAN9 (.9.0/24), như sau.
Code:

Name:        Servers
Description: server zones
Type:        Network(s)

Network  CIDR Description
======== ==== ===========
    .4.0   24 LAN4
    .8.0   24 LAN8
    .9.0   24 LAN9
======== ==== ===========


Cũng tương tự như vậy, hãy tạo bí danh Vietnam, mà ta sẽ cần để thực hiện điểm i) của chính sách định tuyến, chứa tất cả các dải địa chỉ IP của Việt Nam. Mỗi bí danh chỉ được phép chứa không quá 64 dải địa chỉ IP. Hiện nay Việt Nam đã được cấp khoảng 130 dải địa chỉ IP nên thực tế ta sẽ phải dùng đến vài bí danh thì mới chứa hết được các dải địa chỉ này; nhưng trong bài này ta đơn giản hóa và giả sử có thể chứa hết tất cả trong một bí danh duy nhất.

Bây giờ, vào Firewall: Rules, tab LAN, lần lượt tạo ra các luật (rule), mỗi luật ứng với một điểm trong các điểm từ a) đến k) của chính sách đã đề ra. Cụ thể, theo thứ tự từ trên xuống dưới như sau.
Code:

Proto   Source      Port Destination Port Gateway    Queue Sched Description
======= =========== ==== =========== ==== ========== ===== ===== ===============
TCP     .8.101      *    *             25 ISPA1      *     *     Rule a)
TCP     .9.202      *    *             25 ISPA2      *     *     Rule b)
TCP     *           *    *             25 ISPB       *     *     Rule c)
TCP     .0.0/22     *    *           5050 ISPA1first *     *     Rule d)
TCP     .4.0/22     *    *           5050 ISPA2first *     *     Rule e)
TCP/UDP Servers     *    *             53 ISPAfirst  *     *     Rule f)
TCP/UDP *           *    *             53 ISPBfirst  *     *     Rule g)
TCP/UDP *           *    *            123 ISPAonly   *     *     Rule h)
TCP     *           *    Vietnam       80 ISPAfirst  *     *     Rule i)
TCP     *           *    *             80 ISPBfirst  *     *     Rule j)
*       *           *    *              * AnyLink    *     *     Rule k)
======= =========== ==== =========== ==== ========== ===== ===== ===============


Trong đó, các địa chỉ .8.101 và .9.202 là địa chỉ IP lần lượt của mail server của company1.com và company2.com; Servers và Vietnam là các bí danh ta đã tạo ra ở trên.

Bảng nói trên sẽ được dùng để định tuyến theo nguyên tắc khớp đầu tiên thì thắng (first-match wins): khi cần xử lý một lưu thông từ LAN đi ra Internet, hãy dò theo bảng theo thứ tự từ trên xuống dưới, tìm luật nào khớp với lưu thông ấy; luật khớp đầu tiên sẽ được lựa chọn để áp dụng. Nguyên tắc này còn gọi là khớp nhanh (quick match) bởi vì hễ tìm được luật khớp thì luật ấy được áp dụng ngay và quá trình tìm kiếm kết thúc luôn, những luật dưới nó trong bảng sẽ không được xem xét nữa.

Để ý rằng pfSense trước hết là một tường lửa. Bởi thế nên bảng nói trên không những để định tuyến mà còn và trước hết là để cho phép (hay để ngăn chặn) lưu thông: khi tạo ra từng luật, ta phải chỉ rõ hành động (action) sẽ được thực hiện đối với lưu thông theo luật, hành động ấy luôn luôn là cho phép lưu thông (pass). Hành động mặc định, tức hành động trong trường hợp không thể tìm được luật nào khớp với lưu thông, là ngăn chặn lưu thông (block). Tuy nhiên, trong trường hợp của chúng ta, mọi lưu thông ra Internet sẽ khớp với luật cuối cùng -- luật k) -- nếu không thể khớp với luật nào trước đó, nhờ thế mà mọi lưu thông hướng ra Internet đều được phép.

Ngoài ra, đôi khi ta cần ping và trace route đến các địa chỉ IP giám sát 11.0.0.11 và 11.0.0.12. Hãy tạo thêm 2 luật nữa trong bảng trên, với Destination = địa chỉ IP giám sát và Gateway = *. (Ký hiệu Gateway = * có nghĩa là "không chỉ rõ", bảng định tuyến hệ thống sẽ được áp dụng.) Do quy tắc thứ tự khớp luật, để những luật này có tác dụng, cần đặt chúng lên trên luật k).

Do việc định tuyến là có trạng thái, ta chỉ cần thiết lập luật cho tuyến đi của kết nối, tức là luật sẽ áp dụng cho gói tin khởi xướng kết nối truy cập Internet và các gói khác cùng kết nối và đi cùng chiều. Đối với tuyến về, tức là tuyến cho gói tin quay về, việc định tuyến cho trường hợp mạng cục bộ truy cập Internet cũng chỉ dựa vào các luật từ a) đến k) mà ta đã làm ra trong tab LAN chứ chúng ta không cần phải tạo thêm luật nào riêng cho việc này.

Ta hãy quay trở lại một vấn đề đã nói ở một đoạn trên: chọn cặp địa chỉ IP của ISP A để giám sát. Việc chọn chúng là những gateway thật gần chỉ đơn giản để đảm bảo kết quả phát hiện gateway chết thật đáng tin cậy. Việc định tuyến không lệ thuộc vào băng thông của từng đường truyền, mọi đường truyền tham gia cân bằng tải bất kể nhanh chậm thế nào cũng đều chịu tải như nhau chừng nào chúng chưa quá tải. Đường truyền chậm sẽ sớm quá tải vì thế sẽ sớm bị gạt ra khỏi vòng xoay, tức là ra khỏi danh sách các đường tham gia cân bằng tải.

Sự xoay vòng mà ta nói ở đây là kết nối xoay vòng, và xoay vòng giữa các gateway trong khuôn khổ của từng luật định tuyến. Ví dụ, kết nối đầu tiên đến web site trong nước sẽ được thực hiện qua OPT1, kết nối thứ hai đến một web site trong nước sẽ được thực hiện qua OPT2, kết nối thứ ba đến một web site trong nước sẽ lại qua OPT1, kết nối thứ tư đến một web site trong nước sẽ lại qua OPT2, v.v. (Trong đó, ta đã giả sử khi định tuyến kết nối mới, mọi kết nối trước đó vẫn còn, ví dụ, kết nối thứ nhất, thứ hai và thứ ba vẫn còn khi định tuyến kết nối thứ tư.) Mọi kết nối đến web site trong nước, vốn dĩ đều khớp luật i), được xoay vòng trong giữa hai gateway ISPA1 và ISPA2 của nhóm ISPAonly. Trong khi đó, sự xoay vòng này không đếm xỉa đến các kết nối giao thức khác hay kết nối web nhưng đến các site nước ngoài, vốn dĩ không khớp với theo luật i) và do đó không nằm trong vòng xoay này. Chính vì phương pháp xoay vòng kết nối mà lưu lượng của những kết nối khác nhau nói chung là khác nhau, nên kể cả khi chỉ có một luật định tuyến duy nhất, một vòng xoay duy nhất thì lưu lượng tức thời đo được trên các đường truyền vẫn sẽ không nhất thiết bằng nhau. Thật sự ra, tiêu chí làm cân bằng tải của pfSense không phải là lưu lượng mà là số lượng kết nối.

Bên cạnh việc cấu hình bộ định tuyến, có thể phải cấu hình NAT.

Khi xử lý một gói tin khởi xướng kết nối từ mạng cục bộ hướng ra Internet, địa chỉ nguồn đề trên gói tin, vốn dĩ thường là một địa chỉ cục bộ và vì thế không thể dùng trên mạng toàn cầu, sẽ được thay thế bằng địa chỉ của giao diện với Internet vốn dĩ là một địa chỉ toàn cầu. Vì có thể có nhiều kết nối từ nhiều địa chỉ khác nhau đến cùng một địa chỉ đích, việc thay thế trên sẽ có thể gây ra đụng độ nguồn và cổng nguồn đề trên gói tin vì để tránh đụng độ mà cũng có thể phải thay thế. Đối với các gói tin đi và về tiếp theo của kết nối việc thay thế địa chỉ và cổng tương ứng cũng được thực hiện. Quá trình này gọi là dịch địa chỉ mạng (Network Address Translation), viết tắt là NAT. Quá trình này có khi còn được gọi là dịch địa chỉ và cổng mạng (Network Address and Port Translation), viết tắt là NAPT, và đôi khi còn được gọi là outbound NAT hay source NAT để phân biệt rõ ràng với inbound NAT hay destination NAT mà ta sẽ nói sau.

Mặc định, mọi giao diện ngoại trừ LAN đều được xem là giao diện với Internet, và mọi địa chỉ mạng mà hệ thống đã biết là liên thông trực tiếp hay gián tiếp với giao diện bất kỳ ngoại trừ WAN, đều được xem là địa chỉ cục bộ. Ví dụ, trong sơ đồ của chúng ta, các giao diện WAN, OPT1, OPT2 và OPT3 được mặc định xem là giao diện với Internet; ngoài ra, hệ thống biết rằng địa chỉ mạng .0.40/30, được khai báo cho giao diện LAN, là mạng liên thông trực tiếp với giao diện này, địa chỉ mạng 10/8, được khai báo cho giao diện WAN, là mạng liên thông trực tiếp với giao diện này, còn địa chỉ mạng .0.0/16, vốn dĩ được khai báo bởi một tuyến tĩnh (static route) được định tuyến vào giao diện LAN, là mạng liên thông (gián tiếp hay trực tiếp) với giao diện này; vì thế, địa chỉ .0.0/16 (bao hàm cả .0.40/30) và 10/8 sẽ được xem là những địa chỉ cục bộ.

Có khi ta cần phải thay đổi cách xử lý mặc định nói trên. Ví dụ, trong sơ đồ trên, mọi kết nối từ mạng .0.0/16 (LAN) ra mạng 10/8 (WAN) hay ra Internet gián tiếp qua mạng 10/8 đều mặc định được NAT tại giao diện WAN và việc NAT này là không cần thiết. Muốn thay đổi cách xử lý mặc định nói trên, ta bật sang chế độ outbound NAT cao cấp. Click Firewall: NAT, tab Outbound, click vào Manual outbound NAT rule generation.

Bật outbound NAT cao cấp nghĩa là tắt outbound NAT mặc định, nghĩa là mọi luật outbound NAT mà pfSense ngầm tạo ra và thực hiện sẽ không còn nữa. Ta phải xác lập bằng tay tất cả các luật outbound NAT. Trong sơ đồ mạng của chúng ta, cần phải thực hiện outbound NAT cho mọi kết nối từ mạng .0.0/16 và mạng 10/8 ra Internet qua giao diện OPT1, OPT2 và OPT3. Vì thế ta cần phải thiết lập ít nhất sáu luật outbound NAT như sau.
Code:

Interface Source  Source Dest   Dest  NAT  NAT  Static Description
                  Port          Port  Addr Port Port
========= ======= ====== ====== ===== ==== ==== ====== =========================
OPT1      .0.0/16 *      *      *     *    *    NO     LAN to Internet via OPT1
OPT2      .0.0/16 *      *      *     *    *    NO     LAN to Internet via OPT2
OPT3      .0.0/16 *      *      *     *    *    NO     LAN to Internet via OPT3
OPT1      10/8    *      *      *     *    *    NO     WAN to Internet via OPT1
OPT2      10/8    *      *      *     *    *    NO     WAN to Internet via OPT2
OPT3      10/8    *      *      *     *    *    NO     WAN to Internet via OPT3
========= ======= ====== ====== ===== ==== ==== ====== =========================


Cuối cùng, có thể cần cấu hình inbound NAT trên các giao diện với Internet (OPT1, OPT2 và OPT3). Khi xử lý một gói tin khởi xướng một kết nối mới từ Internet vào một server đặt trong mạng cục bộ, địa chỉ đích đề trên gói tin, vốn dĩ là địa chỉ toàn cục của giao diện với Internet mà gói ấy đổ bộ vào, sẽ được thay thế bằng địa chỉ cục bộ của server. Nhiều server có thể phục vụ trên cùng một số hiệu cổng trong khi để phân biệt dịch vụ, ở giao diện với Internet pfSense phải lắng nghe trên các cổng khác nhau. Trong trường hợp đó số hiệu cổng đích đề trên gói tin cũng được thay thế bằng số hiệu cổng đích ở server. Quá trình này gọi là inbound NAT, có khi còn gọi là destination NAT , port forward hay redirection.

Ví du, trong mạng cục bộ có hai mail server mail.company1.com và mail.company2.com dùng để nhận thư đến từ Internet, với địa chỉ cục bộ lần lượt là .8.100 và .9.100, và đã được đăng ký trong DNS với địa chỉ IP toàn cục của giao diện OPT1 và OPT2. Ta vào Firewall: NAT, tab Inbound, lần lượt tạo ra hai luật như sau.
Code:

Interface Proto   Ext.port range NAT IP Int.port range Description
========= ======= ============== ====== ============== =========================
OPT1      TCP     25             .8.100 25             mail.company1.com
OPT2      TCP     25             .9.100 25             mail.company2.com
========= ======= ============== ====== ============== =========================


Khi cấu hình, ở mục Filter Rule Association ta nên chọn Add / Create new associated filter rule, khi đó pfSense sẽ tạo ra luật tường lửa cho phép kết nối từ Internet đến cổng TCP 25 của giao diện OPT1 và OPT2. Ta có thể kiểm tra bằng cách click menu Firewall: Rules, ở tab OPT1, ta sẽ thấy:
Code:

Proto   Source Port Dest   Port Gateway Queue Sched Description
======= ====== ==== ====== ==== ======= ===== ===== ============================
...
TCP     *      *    .8.100   25 *       none        NAT mail.company1.com
======= ====== ==== ====== ==== ======= ===== ===== ============================


Tương tự như thế, luật tường lửa cho phép lưu thông tới mail.company2.com sẽ xuất hiện ở tab OPT2. Khác với luật tường lửa thông thường, những luật tường lửa này được đi chung (associated) với luật NAT nên ta không thể Edit chúng trực tiếp được.

Khi cấu hình inbound NAT, ở Filter Rule Association ta cũng có thể chọn Pass hay None. Nếu chọn Pass thì lưu thông sẽ được phép đi qua tường lửa mà không cần tạo ra luật tường lửa riêng nào (việc cho phép đi qua tường lửa được thực hiện ngay bởi luật NAT). Việc này tiện lợi hơn nhưng sẽ làm cho tường lửa trở nên không rõ ràng. Nếu chọn None thì không luật tường lửa nào được tạo ra tương ứng 1-1 với luật NAT, và ta sẽ phải tự lo liệu để tường lửa cho phép lưu thông vào mạng cục bộ. Ví dụ, ta có thể tạo bằng tay một luật tường lửa duy nhất là cho phép mọi lưu thông hướng vào giao diện OPT1 để bao trùm hết mọi luật inbound NAT trên OPT1.


6. Định hình lưu thông

Phần mềm pfSense hỗ trợ nhiều phương pháp định hình lưu thông. Bài nhỏ này chỉ trình bày một phương pháp là HFSC (Hiearchical Fair Service Curve, đường cong phục vụ công bằng phân cấp).

HFSC là một phương pháp định hình lưu thông phân cấp (hiearchical). Sự phân cấp thể hiện qua tổ chức các hàng thành một cây như sau.

Ứng với mỗi đường truyền, có một hàng (queue) gọi là hàng gốc (root), có băng thông bằng băng thông của uplink.

Mỗi hàng có thể có một hay nhiều hàng con (sub-queue), khi đó, nó được gọi là một hàng mẹ (parent), hoặc không có hàng con nào, khi đó nó được gọi là một hàng lá (leaf). Mỗi hàng con có một băng thông, nhưng băng thông (tĩnh) này chỉ có tính danh nghĩa, vì như ta sẽ thấy trong quá trình hoạt động, băng thông thực tế là động, có thể nhỏ hay lớn hơn băng thông danh nghĩa này. Tổng số băng thông (danh nghĩa) của các hàng con bằng băng thông (danh nghĩa) của hàng mẹ.

Khi một hàng con không dùng hết băng thông của mình, nó ký gửi phần băng thông dôi dư cho hàng mẹ.

Hàng mẹ chia băng thông được ký gửi cho các hàng con cần băng thông vay. Nếu vẫn còn dư thì nó lại ký gửi phần dư cho hàng mẹ (nếu có) của nó.

Như thế, băng thông dôi dư của một hàng có thể được chuyển cho các hàng "anh chị em" vay dùng tạm, trong đó các hàng "anh chị em ruột" được ưu tiên vay trước thông qua hàng mẹ, sau đó đến "anh chị em họ" thông qua "cha mẹ", "cô chú bác", "ông bà",...; và "họ hàng" càng xa thì ưu tiên vay mượn băng thông càng thấp.

Sự chia xẻ băng thông là chia xẻ công bằng (fair), nghĩa là chia xẻ theo tỷ lệ băng thông (danh nghĩa) đã gán cho các hàng. Ví dụ, nếu các hàng Q1, Q2, Q3, Q4 lúc đầu được gán băng thông lần lượt 1, 2, 3, 4 kb/s thì khi đem chia 100 kb/s, chúng sẽ được nhận phần lần lượt 10, 20, 30, 40 kb/s.

Băng thông mới chỉ là một tham số đặc trưng của hàng. Trong phương pháp HFSC, tham số này thật ra được bao hàm trong một khái niệm tổng quát hơn, gọi là đường cong phục vụ. Một đường cong phục vụ (service curve) là một đồ thị đặc trưng cho khả năng phục vụ của một hàng, nó biểu diễn lượng dữ liệu mà hàng có thể phục vụ được (phát đi được) phụ thuộc theo thời gian, nó được vẽ trên một phần tư mặt phẳng tọa độ Ots, trong đó t là thời gian tính bằng giây, không âm, và s là lượng dữ liệu có thể phát tính bằng bit, không âm. Trường hợp đơn giản nhất của một đường cong phục vụ, gọi là đường cong tuyến tính (linear), là một nửa đường thẳng xuất phát từ gốc tọa độ O, độ dốc của nó chính là băng thông của hàng. Ví dụ về trường hợp này là đường cong phục vụ của một đường uplink đơn giản, lý tưởng, với một băng thông cố định, không thay đổi theo thời gian. Trường hợp tổng quát nhất của một đường cong phục vụ là một nửa đường cong xuất phát từ O và không giảm.

Trên một phần tư mặt phẳng tọa độ Ots, có thể vẽ một đồ thị thể hiện lượng dữ liệu được xếp vào hàng (đã thu vào) theo thời gian, gọi là đường cong đến (arrival); đồ thị này có dạng đường bậc thang trong đó mỗi đỉnh bậc thang ứng với một gói tin vào hàng ở thời điểm đến của gói tin. Tương tự, trong phần tư mặt phẳng tọa độ Ots có thể vẽ một đồ thị thể hiện lượng dữ liệu đã ra khỏi hàng (đã phát đi) theo thời gian, gọi là đường cong đi (departure); đồ thị này có dạng đường bậc thang trong đó mỗi đỉnh bậc thang ứng với một gói tin ra khỏi hàng ở thời điểm đi của gói tin.

Dễ thấy rằng do mọi gói tin đến đều được phát đi, đường cong đi có hình dạng tương tự như đường cong đến: hai đường đều có dạng đường bậc thang mà các bậc thang tương ứng cùng chiều cao, tức là các đỉnh bậc thang tương ứng có cùng tung độ. Do trễ (sai biệt giữa thời điểm đến và thời điểm đi của từng gói tin), đường cong đi sẽ dịch sang bên phải so với đường cong đến.

Giả sử hàng làm việc hết khả năng (hết công suất). Các đỉnh bậc thang của đường cong đi khi đó hẳn phải nằm trên đường cong phục vụ. Chúng không thể nằm ở bên trái (hay nằm bên trên, cao hơn) đường cong phục vụ bởi vì như thế có nghĩa là hàng làm việc vượt khả năng của mình một cách vô lý – khả năng phục vụ của hàng, thể hiện qua đường cong phục vụ, là khả năng tối đa. Chúng cũng không thể nằm ở bên phải (hay nằm bên dưới, thấp hơn) đường cong phục vụ bởi vì như thế có nghĩa là hàng làm việc dưới khả năng của mình một cách vô cớ – khả năng phục vụ của hàng, thể hiện qua đường cong phục vụ, cũng đồng thời là khả năng tối thiểu. Cố nhiên, hàng chỉ có thể làm việc hết công suất khi dữ liệu đổ đến hàng ồ ạt, nghĩa là chỉ khi đường cong đến hoàn toàn nằm ở phía bên trái đường cong phục vụ. Tóm lại, nếu các đỉnh bậc thang của đường cong đến đều nằm ở bên trái đường cong phục vụ thì các đỉnh bậc thang tương ứng của đường cong đi nằm trên đường cong phục vụ.

Thực tế, không phải lúc nào dữ liệu cũng đổ đến ồ ạt. Sẽ có lúc hàng không phục vụ vì dòng dữ liệu đến tạm dừng. Và sau đó một lúc, dòng dữ liệu đến được phục hồi, tức là lại có gói tin mới đến hàng. Trên đồ thị, sự việc này thể hiện ở chỗ đường cong đến bị chia thành hai phần: phần tương ứng với gói tin mới đến trở về sau nằm bên phải đường cong phục vụ. Trong trường hợp này, hãy xem như gói tin mới đến mở đầu cho một phiên phục vụ mới, nghĩa là thời gian được tính lại từ đầu. Trên đồ thị, ta thực hiện việc này bằng cách tịnh tiến (dời mà không quay) đường cong phục vụ sao cho điểm xuất phát của nó được dời từ gốc toạ độ O đến điểm biểu diễn gói tin mới đến. Và việc vẽ đường cong đi cho phiên phục vụ mới này lại quy về giống như trường hợp hàng làm việc hết khả năng đã nói ở đoạn trên.

Tóm lại, đường cong phục vụ có tác dụng định hình, nghĩa là "tạo dáng" cho đường cong đi; đường cong đi gồm có nhiều phần, mỗi phần gồm một số điểm mà qua một phép tịnh tiến nằm trên một cung của đường cong phục vụ giới hạn bởi điểm đầu là điểm xuất phát của đường cong phục vụ và điểm cuối là điểm tương ứng với khoảng thời gian của một phiên phục vụ, tức là khoảng thời gian dữ liệu đổ đến liên tục, ào ào.

Phương pháp HFSC có hai thuật toán: thuật toán link-share (chia xẻ đường truyền) sẽ chọn một hàng mẹ để phục vụ, và thuật toán real-time (thời gian thực) sẽ chọn chọn một hàng lá để phục vụ, cũng tức là chọn một gói tin cụ thể, gói tin đứng ở đầu hàng ấy, để phát đi. Thuật toán real-time nhằm mục đích đảm bảo gói tin đi sẽ được phát xong kịp thời hạn quy định bởi đường cong phục vụ. Thuật toán link-share nhằm mục đích đảm bảo chia băng thông dôi dư cho các hàng theo đúng tỷ lệ quy định bởi các đường cong phục vụ.

Thuật toán real-time có sai số hằng, nghĩa là thực tế các đỉnh bậc thang của đường cong đi cũng không hoàn toàn nằm lên đường cong phục vụ mà có thể hơi bị trễ một chút ở vài nơi, sai số ấy bằng thời gian cần thiết để phát một gói tin với chiều dài tối đa có thể thu phát được bởi đường truyền. Thuật toán link-share có sai số hằng, lớn nhỏ tuỳ theo hình dạng của tất cả các đường cong phục vụ; trường hợp mọi đường cong phục vụ đều tuyến tính thì sai số của thuật toán link-share giống như sai số của thuật toán real-time, mức chia xẻ công bằng lý tưởng nhất có thể đạt được ở một thuật toán chia xẻ băng thông mà không chia nhỏ gói tin.

Trong mô hình đường cong phục vụ, với nhiều hàng, tổng các đường cong của các hàng con bằng đường cong của hàng mẹ. Mỗi đường cong là đồ thị của một hàm số; khái niệm "tổng của các đường cong" ở đây được hiểu theo nghĩa tổng của các hàm số tương ứng. Đối với thuật toán real-time, đường cong phục vụ là tuyệt đối – từng bit dữ liệu đến sẽ được phát đi đúng thời hạn đến từng micro-giây. Đối với thuật toán link-share, đường cong phục vụ là tương đối: độ lớn của từng băng thông, từng kb/s trên đường cong phục vụ là không quan trọng, chỉ có tỷ lệ giữa chúng trên các đường cong phục vụ của các hàng là có ý nghĩa mà thôi.

Trong phương pháp HFSC nguyên bản, cả hai thuật toán real-time và link-share dùng chung một đường cong phục vụ duy nhất cho mỗi hàng. Nhưng phương pháp HFSC được cài đặt vào pf đã được cải biên, với ba đường cong phục vụ:
Real-time, thể hiện khả năng tối thiểu của hàng.
Link-share, thể hiện khả năng bình quân của hàng.
Upper-limit, thể hiện khả năng tối đa của hàng.
Khi đó, thuật toán real-time sẽ sử dụng đường cong real-time, thuật toán link-share sẽ sử dụng đường cong link-share nhưng với ràng buộc là hàng sẽ không thể hoạt động quá mức giới hạn bởi đường cong upper-limit. Cũng như đường cong real-time, đường cong upper-limit được hiểu theo nghĩa tuyệt đối. Nếu như đường cong real-time đặt ra thời hạn chậm nhất để phát tin (tức là không được phép phát muộn hơn thời hạn này) thì đường cong upper-limit đặt ra thời hạn nhanh nhất có thể cho phép phát tin (nghĩa là không được phép phát sớm hơn thời hạn này).

Đường cong link-share là bắt buộc, mọi hàng đều phải có. Hai đường cong còn lại là tuỳ chọn, một hàng không nhất thiết phải có chúng. Hàng không có đường cong real-time hay upper-limit khi lưu thông trong hàng ấy không cần phải chịu thời hạn cứng cho việc phát tin.

Với đường cong upper-limit, việc khai thác đường truyền sẽ có lúc không còn tối đa, việc chia xẻ đường truyền có lúc sẽ mất công bằng. Ví dụ, giả sử hàng Q1 và Q2 có đường cong link-share giống nhau, đều tương ứng với băng thông cố định là 400 kb/s, nhưng Q1 không bị giới hạn còn Q2 bị giới hạn bởi đường cong upper-limit ứng với băng thông 4 mb/s, băng thông đường truyền là 30 mb/s, khi băng thông cấp cho Q1 và Q2 không quá 8 mb/s, băng thông ấy sẽ được chia đôi cho hai hàng mỗi hàng một nửa, nhưng khi băng thông ấy vượt quá 8 mb/s, Q2 cũng chỉ được 4 mb/s, phần còn lại lớn hơn, Q1 hưởng cả.

Các đường cong nói trên phải thoả mãn một số ràng buộc nhất định:
Tổng các đường cong link-share của mọi hàng lá không lớn hơn đường cong link-share của hàng gốc.
Đường cong real-time nhỏ hơn đường cong upper-limit ở mọi điểm.
Tổng các đường cong real-time của mọi hàng lá (leaf) không quá 80% đường cong link-share của hàng gốc (root). Ở một hàng gốc, cả ba đường cong link-share, upper-limit và real-time trùng nhau, và ta không cần phải chỉ ra đường cong upper-limit hay real-time của nó.
Thực tế, nên lập ra các hàng lá sao cho tổng các đường cong link-share của chúng bằng 100%, tức là bằng đường cong link-share của hàng gốc. Mặc dù như đã nói ở trên, chỉ có tỷ lệ giữa băng thông quy định trên các đường cong link-share mới có ý nghĩa chứ số trị của chúng nói chung là không có ý nghĩa, nhưng nếu ta làm theo lời khuyên “thực tế” trên thì những số trị đó sẽ nói lên chính xác băng thông thực tế cấp cho các hàng (lá) khi chúng đồng thời hoạt động hết công suất.

Cho đến giờ, ngoại trừ dạng tuyến tính, chúng ta chưa đề cập đến hình dạng cụ thể của các đường cong phục vụ. Một bộ định hình dù có dùng những đường cong phức tạp đến đâu thì hành vi của nó cũng đều có thể phân tích được, nhưng đường cong phức tạp quá thì không dễ hiểu để mà sử dụng, và đồng thời có lẽ cũng không có thuật toán hiệu quả để thực hiện chúng. Do đó, phương pháp HFSC đã được xây dựng với những đường cong đơn giản.

Đường cong phục vụ có dạng đơn giản nhất là đường cong tuyến tính mà ta đã nói ở trên. Độ dốc của nó thể hiện được một tham số chất lượng phục vụ (QoS) duy nhất: băng thông của hàng. Với dạng đường cong đơn giản này, băng thông và trễ bị ràng buộc với nhau, chứ không độc lập. Ví dụ, giả sử cần tạo một hàng riêng để phát VoIP có khả năng phục vụ tối đa một phiên thoại duy nhất. Loại VoIP mà ta sử dụng có tốc độ bit 60 kb/s và có độ dài gói cố định là 150 byte = 1,2 kb. Nếu đường cong phục vụ (real-time) được dùng có dạng tuyến tính với độ dốc, tức là băng thông (tối thiểu) cấp cho hàng, bằng 60 kb/s, thì đồng thời, trễ (tối đa) mà hàng ấy đảm bảo được khi phát mỗi gói tin với độ dài gói như trên là 1,2 / 60 = 0,02 s = 20 ms. Độ trễ tỉ lệ thuận với chiều dài của gói tin. Chẳng hạn, ở cùng băng thông đó, gói tin 12 kb sẽ có thể bị trễ đến 200 ms.

Ta có thể cải thiện độ trễ bằng cách khai báo băng thông lớn cho VoIP. Ví dụ, muốn đảm bảo trễ không quá 2 ms, ta sẽ phải cấp cho hàng VoIP băng thông 600 kb/s. Để đổi lấy trễ thấp, ta phải cấp khống cho VoIP một băng thông lớn đến mức bất hợp lý. Khi đó, VoIP vẫn chạy tốt và các giao thức khác có thể vẫn lưu thông được, nhưng việc chia băng thông sẽ mất công bằng theo nghĩa trong phần lớn thời gian sử dụng, băng thông thực tế được chia theo tỷ lệ nào đó khác hoàn toàn so với tỷ lệ quy định bởi các đường cong phục vụ.

Với HFSC, có thể đảm bảo băng thông nhỏ vừa phải mà vẫn trễ thấp, bằng cách dùng đường cong phục vụ có dạng đường gấp khúc lõm, gồm hai khúc:
Khúc đầu, từ gốc toạ độ O, có độ dốc m1 = 600 kb/s và kết thúc ở điểm có hoành độ d = 2 ms (và tung độ u = 1,2 kb).
Khúc tiếp theo, nối tiếp khúc thứ nhất ra vô cùng, có độ dốc m2 = 60 kb/s.
Dễ thấy rằng đường gấp khúc lõm này thực chất là đường cong tuyến tính độ dốc 60 kb/s được bẻ gãy ở điểm (t = 20 ms; s = 1,2 kb) và phần trên được dịch sang bên trái 18 ms sao cho điểm gãy kia trở thành (t = 2 ms; s = 1,2 kb). Đường gấp khúc lõm này khi dùng làm đường cong real-time sẽ đảm bảo băng thông tối thiểu 60 kb/s và trễ tối đa đối với gói tin 1,2 kb là 2 ms. Độ trễ rất nhỏ này đảm bảo thoại VoIP lưu thông trôi chảy bất kể đường truyền đang tải nặng đến mức nào.

Độ trễ tối đa nói trên chỉ đúng khi lưu thông là tuần hoàn lý tưởng, nghĩa là những gói tin cùng chiều dài đến đều đặn theo một chu kỳ cố định và không sai pha. Nếu có vài gói tin đến chậm pha (hay sớm pha) một chút, độ trễ tối đa sẽ giảm đi (hay tăng lên). Nhưng sự thăng giáng này không hề hấn gì, điều chủ yếu vẫn là khúc thứ hai của đường cong phục vụ là đường thẳng, và do đó các bậc thang của đường cong đi vẫn sẽ thẳng hàng, nghĩa là vẫn đảm bảo tính tuần hoàn ở những gói tin sẽ được phát đi. Như thế đường cong phục vụ có tác dụng định hình lưu thông theo nghĩa nó xoá bỏ những thăng giáng bất thường ở pha và làm bình ổn tốc độ lưu thông của luồng dữ liệu.

Trong ví dụ vừa rồi, cần chú ý rằng nếu khai báo đường cong phục vụ lõm với d quá lớn, 3 ms chẳng hạn, thì do m1 lớn hơn tốc độ lưu thông thực tế, gói tin thứ hai thực tế sẽ đến trễ hơn đường cong phục vụ và thuật toán real-time sẽ xem như gói tin này mở đầu cho một phiên phục vụ mới, tính lại thời gian phục vụ từ đầu, dịch đường cong phục vụ về điểm đến của gói tin này. Tương tự như thế với gói tin thứ ba và kế tiếp. Như thế, chỉ khúc m1 có tác dụng còn khúc m2 sẽ không bao giờ tác dụng, nghĩa là ta mắc phải sai lầm về khai khống băng thông đã nói ở trên. Do vậy, không bao giờ nên khai báo d quá lớn.

Phép tính nói trên được áp dụng để tính đường cong phục vụ cho hàng chỉ lưu thông một kết nối duy nhất, ví dụ, một cuộc thoại VoIP. Để có thể đảm bảo lưu thông cho n kết nối, ta cần nhân đường cong phục vụ một kết nối với n. Ví dụ, để duy trì chất lượng phục vụ cho đồng thời 5 cuộc thoại VoIP cùng kiểu với cuộc thoại trong ví dụ nói trên, ta hãy dùng đường cong phục vụ với m1 = 600 * 5 = 3000 kb/s, d = 2 ms và m2 = 60 * 5 = 300 kb/s.

Ta làm thế nào nếu như đường truyền sẵn có không đủ nhanh, ví dụ, giả sử chỉ có thể cấp được nhiều nhất 600 kb/s cho VoIP? Hãy bằng lòng với m1 = 600 kb/s. Khi đó, với d = 10 ms và m2 = 300 kb/s, có thể đảm bảo được cho 5 cuộc thoại đồng thời độ trễ tối đa 1,2 / (600/5) = 0,01 s = 10 ms. Nếu số cuộc thoại thực tế ít hơn 5 thì càng tốt – chất lượng đảm bảo sẽ tăng lên. Chẳng hạn, khi chỉ có 3 cuộc thoại đang đồng thời diễn ra thì độ trễ tối đa được đảm bảo lúc ấy là 1,2 / (600/3) = 0,006 s = 6 ms.

Hãy xem xét một ví dụ khác. Giả sử có một hàng riêng để giới hạn ở băng thông 2,4 mb/s cho các giao thức P2P, như bittorrent, với gói tin độ dài bất kỳ không quá 1,5 kB = 12 kb. Nếu đường cong upper-limit có dạng tuyến tính với độ dốc 2,4 mb/s thì trễ (tối thiểu) mà hàng ấy ấn định khi phát gói tin độ với độ dài nói trên sẽ là 12 / 2400 = 0,005 s = 5 ms. Quá nhỏ! Ở mức trễ này, nếu đường truyền chậm, một giao thức download hung hãn như bittorrent có thể đè bẹp mọi lưu thông.

Và, vẫn tương tự như ở trên, ta có thể tăng giới hạn trễ tối thiểu bằng cách giới hạn băng thông tối đa rất nhỏ cho hàng P2P. Nhưng việc này có thể sẽ khiến P2P bị chèn ép một cách quá đáng trong khi đường truyền rỗi rãi.

Với HFSC, có thể giới hạn băng thông ở mức lớn vừa phải mà trễ vẫn cao, bằng cách dùng đường cong phục vụ có dạng đường gấp khúc lồi, gồm hai khúc:
Khúc đầu, từ gốc toạ độ O, có độ dốc m1 = 0 (tức là nằm trên trục hoành) và kết thúc ở điểm có hoành độ d = 995 ms.
Khúc thứ hai, nối tiếp khúc thứ nhất ra vô cùng, có độ dốc m2 = 2,4 mb/s.
Đường gấp khúc lồi này chính là đường cong tuyến tính độ dốc 2,4 mb/s được dịch sang bên phải 995 ms. Đường gấp khúc lồi này khi dùng làm đường cong upper-limit sẽ đảm bảo băng thông tối đa 2,4 mb/s và trễ tối thiểu đối với gói tin 12 kb là 5 + 995 = 1000 ms. Độ trễ lớn này không ảnh hưởng đến lưu lượng P2P download, mà lại giúp cho mọi giao thức khác lưu thông trôi chảy hoàn toàn như thể P2P không hề có mặt trên đường.

Tóm lại, đường cong phục vụ hai khúc có tác dụng xoá bỏ sự ràng buộc giữa băng thông và trễ. Đường cong lõm giúp ta rút ngắn trễ. Đường cong lồi, ngược lại, sẽ giúp ta kéo dài trễ.

Phần còn lại của đoạn này sẽ dành cho việc định hình lưu thông trong pfSense.

Trước hết, bạn cần phải biết rõ băng thông thực tế của các đường truyền, cả uplink lẫn downlink. HFSC có hoạt động chính xác hay không, phụ thuộc tất cả vào đó. HFSC là một phương pháp tĩnh, nó không thể tự thích nghi với băng thông thay đổi thất thường. Nó rất mẫn cảm với thăng giáng của băng thông thực tế, nên trong những trường hợp băng thông dao động bạn cần phải lấy giá trị nhỏ nhất đo được. Ngoài ra, kinh nghiệm cho thấy để nó hoạt động thật chính xác, nên khấu trừ khỏi giá trị này khoảng 120 – 250 kb/s để lấy giá trị khai báo. Ngoài ra, một số đường truyền có băng thông lớn trong khoảng thời gian vài giây đầu tiên, sau đó giảm xuống một mức bình thường nào đó. Gặp trường hợp đó, bạn nên biết rõ cả băng thông ban đầu và thời gian “vài giây đầu tiên” ấy để khai báo đường cong phục vụ hai khúc lõm, để khai thác được lợi ích của băng thông lớn.

Vào Firewall: Traffic Shaper, tab Wizard chọn kiểu nhiều WAN một LAN, sau khi đi theo sự hướng dẫn của wizard ta sẽ được một tổ chức hàng mặc định, trong đó mỗi giao diện có bảy hàng, theo thứ tự ưu tiên (priority) từ thấp lên cao: qP2P, qOthersLow, qOthersDefault, qOthersHigh, qGames, qACK, qVoIP.

Cần nói ngay rằng, số thứ tự ưu tiên này không có ý nghĩa gì lớn. Với bộ định hình HFSC, trong tuyệt đại đa số trường hợp, thuật toán real-time và thuật toán link-share, vốn dĩ chỉ dựa vào các đường cong phục vụ, đã có thể quyết định duy nhất một trình tự phát các gói tin đảm bảo đúng thời hạn và đảm bảo công bằng. Số thứ tự ưu tiên chỉ áp dụng khi phải quyết định lựa chọn giữa hai hay nhiều trình tự phát cùng thoả mãn các tiêu chí đúng thời hạn và công bằng tốt như nhau, một điều rất hiếm khi xảy ra. Như vậy, chỉ với việc phân tách lưu thông thành nhiều hàng với băng thông và trễ hợp lý thì việc định hình lưu thông đã được thực hiện hầu như triệt để rồi.

Với những hàng mặc định này, chúng ta đã có thể thiết lập một chính sách chia hàng tốt, như sau.

Hàng qACK dành cho các gói ACK (gói xác nhận) trong giao thức TCP ở những ứng dụng chính cần được hỗ trợ tốt như HTTP, SMTP,... luồng thông tin ACK là luồng thông tin tương đối nhỏ nhưng hết sức cần thiết để duy trì tốc độ lưu thông lớn. Những lưu thông không cần thiết lắm, như P2P, thì không nên dùng qACK. Cần chú ý rằng luồng ACK của một loại lưu thông đi theo chiều ngược lại với luồng dữ liệu chính. Ví dụ, khi lướt Web dữ liệu chính là dữ liệu tải xuống, chúng đi vào hàng qOthersDefault của giao diện LAN, trong khi đó các gói ACK tương ứng của thông tin tải xuống sẽ được tải lên, tức là chúng đi vào các hàng qACK của các giao diện WAN, OPT1,...

Hàng qVoIP dành cho những loại lưu thông cần đảm bảo trễ tối đa hết sức nghiêm ngặt, thường dưới 10 ms. Chẳng hạn VoIP và hội nghị truyền hình. Nhưng cần nhắc lại rằng, nếu muốn giới hạn trễ (tối đa) bằng đường cong (real-time) lõm thì chúng ta thường phải tạo ra nhiều hàng, bởi vì mỗi hàng như thế chỉ có thể phục vụ tối ưu một loại lưu thông mà thôi.

Hàng qGames dành cho các dạng lưu thông cần đảm bảo trễ tối đa rất chặt chẽ, thường dưới 50 ms. Chẳng hạn, SSH, các ứng dụng điều khiển từ xa và các trò chơi trực tuyến.

Hàng qOthersHigh dành cho các giao thức ứng dụng quan trọng có tính tương tác rất cao, cần đáp ứng rất nhanh, như các giao thức phục vụ mạng và các giao thức cần trễ thấp, chẳng hạn NTP, DNS, SNMP, ICMP.

Hàng qOthersDefault dành cho các giao thức ứng dụng quan trọng có tính tương tác vừa, cần độ đáp ứng nhất định, như là HTTP, IMAP.

Hàng qOthersLow dành cho các giao thức ứng dụng quan trọng nhưng có tính tương tác thấp, chỉ cần có độ đáp ứng chậm cũng được, như là SMTP, POP3, FTP.

Hàng qP2P dành cho các ứng dụng không tương tác, không cần đáp ứng nhanh, hoặc không quan trọng, chẳng hạn, bittorrent.

Đồng thời, ta xem xét lại quyết định dùng hàng nào làm hàng mặc định. Hàng mặc định (default queue) là hàng mà pfSense sẽ dồn vào đó tất cả những lưu thông không nhận dạng được hay không có luật định hình nào áp dụng được. Bình thường hàng mặc định là qOthersDefault. Nhưng trong mạng lưu thông P2P, vốn dĩ rất đa dạng và khó nhận diện được chính xác, chiếm một tỷ lệ lớn và là một vấn đề cần kiểm soát, sẽ an toàn hơn khi ta chọn hàng mặc định là qP2P.

Từ chính sách sử dụng hàng đó, trên cơ sở ước tính lưu lượng của từng loại lưu thông, ta có thể hoạch định các đường cong phục vụ. Vào Firewall: Traffic Shaper, click từng hàng chỉnh lại tham số của chúng theo kế hoạch. Bộ đường cong phục vụ trong bảng dưới đây là phù hợp cho môi trường mà mọi đường truyền đều đối xứng (uplink và downlink tương ứng có băng thông bằng nhau) và có nhiều ứng dụng đồng thời lưu thông, trong đó ứng dụng chủ yếu là lướt Web.
Code:

Priority Queue           B/W     Link-share      Real-time    Upper-limit
                               m1    d   m2   m1    d   m2   m1    d   m2
======== ============== ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
       1 qP2P             1%                                  0 1000  50%
       2 qOthersLow       4%                            1%
       3 qOthersDefault  50%                            1%
       4 qOthersHigh     20%                            8%
       5 qGames          10%                            4%
       6 qACK             5%                            2%
       7 qVoIP           10%                            4%
======== ============== ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
         TOTAL          100%                           20%


Một đường cong nếu chỉ khai báo m2 thì sẽ là đường cong tuyến tính. Bandwidth (B/W) chính là m2 của đường cong link-share. Do đó khi cần đường cong link-share tuyến tính chỉ cần khai báo Bandwidth là đủ. Trong bảng trên, ngoại trừ đường cong upper-limit của qP2P có dạng đường gấp khúc lồi còn mọi đường cong khác đều là tuyến tính. Tuy vậy, ở qP2P, đường cong link-share bị đường cong upper-limit chặn trên nên sẽ không có tác dụng ở khoảng ứng với thời gian nhỏ hơn 1000 ms. Nói cách khác, đường cong tuyến tính được khai báo ở đây thực tế là tương đương với một đường cong gồm hai khúc rời nhau: khúc thứ nhất, từ 0 đến 1000 ms, có giá trị 0, khúc thứ hai từ 1000 ms đi đến vô cùng là nửa đường thẳng có độ dốc bằng 1% băng thông đường truyền, mà nếu nối dài thành đường thẳng thì sẽ đi qua gốc toạ độ.

Trong bảng trên, để ý rằng mọi băng thông trên các đường cong link-share không được khai báo bằng những đơn vị tuyệt đối như kb/s, mb/s, mà bằng một đơn vị tương đối, cụ thể là bằng tỷ lệ phần trăm băng thông của đường truyền. Việc dùng đơn vị tương đối có vài lợi ích. Một là dễ dàng kiểm tra rằng tổng các đường cong link-share (trong trường hợp này là tổng số các m2, tức Bandwidth, của chúng) thỏa ràng buộc không vượt quá đường cong link-share của hàng gốc (trong trường hợp này, không quá 100%). Hai là phù hợp với nhiều đường truyền, kể cả khi có nhiều đường truyền với băng thông khác nhau, miễn đều là đường truyền đối xứng (hay nói một cách tổng quát, đều có cùng tỷ số băng thông uplink / downlink), chỉ một bộ tỷ lệ phần trăm như thế có thể áp dụng cho mọi đường truyền. Ba là dễ dàng thích ứng với thay đổi khi băng thông đường truyền thay đổi chỉ cần khai báo lại m2 (Bandwidth) của hàng gốc, còn m2 (Bandwidth) của các đường cong link-share của các hàng con sẽ tự động thay đổi theo.

Từ bảng trên ta cũng để ý rằng khai báo băng thông tương đối có thể dùng không những ở các đường cong link-share mà còn cả các đường cong real-time và upper-limit nữa. Những lý do của việc dùng tỷ lệ phần trăm này cũng giống như đối với đường cong link-share. Nhưng cần phải lưu ý thêm rằng một bộ tỷ lệ phần trăm đó áp dụng lên những đường truyền khác nhau thì độ đảm bảo băng thông và trễ sẽ không nhất thiết giống nhau. Ví dụ, kể cả khi cả bốn đường truyền đều đối xứng và với băng thông WAN = 4 mb/s, OPT1 = OPT2 = OPT3 = 10 mb/s, và (tự động khai báo bởi pfSense) LAN = 34 mb/s, thì năm đường cong real-time của hàng qVoIP tương ứng trên năm giao diện đó với dạng tuyến tính và với m2 = 5% sẽ chỉ đảm bảo trễ tối đa và băng thông tối thiểu giống nhau cho mọi cuộc thoại VoIP nếu số cuộc thoại đồng thời được phân bổ trên các giao diện theo tỷ lệ đúng bằng 4:10:10:10:34, nghĩa là, chẳng hạn, có 2 cuộc thoại đi qua giao diện WAN, còn OPT1, OPT2, OPT3 mỗi giao diện lưu thông 5 cuộc thoại, và cả 17 cuộc thoại đồng thời đó đều đi qua giao diện LAN. Trong pfSense không có công cụ nào cho phép phân bổ số cuộc thoại không đồng đều như thế, tuy nhiên, việc phân bổ số cuộc thoại đồng đều trên ba giao diện có băng thông lớn nhất - OPT1, OPT2 và OPT3, có thể đạt được, một cách thỏa đáng, bằng cách định tuyến riêng cho VoIP cân bằng tải trên ba giao diện này.

Ta cũng có thể để ý thêm rằng mọi đường cong real-time dùng trong bảng trên đều tuyến tính. Mặc dù không thể phủ nhận lợi ích của các đường cong real-time lõm, việc dùng các đường cong tuyến tính, khi có thể được, là việc nên làm. Các đường cong tuyến tính có một lợi ích là dễ dàng tính tổng – tổng của chúng cũng là một đường cong tuyến tính, có độ dốc bằng tổng của các m2, nhờ đó dễ dàng kiểm tra ràng buộc rằng tổng này không vượt quá giới hạn 80% băng thông, đã nói ở trên.

Một điều cần để ý nữa là độ lớn của băng thông các hàng không nhất thiết tương ứng với mức ưu tiên của chúng. Ví dụ, qACK có mức ưu tiên cao hơn qOthersDefault nhưng băng thông của qOthersDefault thì lớn gấp 10 lần băng thông của qACK. Điều đó có nghĩa là khi phát hai gói tin cùng chiều dài, gói đi qua qOthersDefault sẽ được phát nhanh hơn gói qua qACK gấp 10 lần và trễ tương ứng cũng nhỏ hơn 10 lần. Nhưng ta không bận tâm về điều này. Bình thường một gói tin của qOthersDefault dài hơn một gói tin của qACK từ 10 đến 20 lần, và lưu lượng của qOthersDefault lớn hơn lưu lượng qACK cũng khoảng từng ấy lần. Tỷ lệ băng thông 10:1 giữa hai hàng này sẽ khai thác băng thông của chúng đến mức tối đa trong phần lớn thời gian mà cả hai hàng cùng hoạt động.

Việc cuối cùng là thi hành chính sách định hình lưu thông đã đề ra. Hãy vào Firewall: Rules, tab Floating. Khá nhiều luật định hình đã được tạo ra bởi wizard. Ta có thể dựa vào chúng để viết thêm những luật mới tương tự. Click vào nút "+" để tạo luật mới; click vào nút 'e' để edit luật có sẵn. Cuối cùng ta sẽ được một bộ luật định hình đại loại như sau.
Code:

Proto Src Port Dst Port Gateway Queue               Sched Description
===== === ==== === ==== ======= =================== ===== ======================
*     *   *    *      * *       qP2P                *     catch-all out
TCP   *   *    *   3389 *       qACK/qOthersDefault *     MSRDP out
TCP   *   *    *   1723 *       qACK/qOthersHigh    *     PPTP out
GRE   *   *    *      * *       qOthersHigh         *     PPTPGRE out
UDP   *   *    *    500 *       qOthersHigh         *     IKE out
ESP   *   *    *      * *       qOthersHigh         *     IPSEC out
TCP   *   *    *     22 *       qACK/qGames         *     SSH out
UDP   *   *    *     53 *       qOthersHigh         *     DNS out
TCP   *   *    *     53 *       qACK/qOthersHigh    *     DNS out
UDP   *   *    *    123 *       qOthersHigh         *     NTP out
TCP   *   *    *    123 *       qACK/qOthersHigh    *     NTP out
ICMP  *   *    *      * *       qOthersHigh         *     ICMP out
IGRP  *   *    *      * *       qOthersHigh         *     IGRP out
TCP   *   *    *     80 *       qACK/qOthersDefault *     HTTP out
TCP   *   *    *    443 *       qACK/qOthersDefault *     HTTPS out
TCP   *   *    *     25 *       qACK/qOthersLow     *     SMTP out
TCP   *   *    *    143 *       qACK/qOthersDefault *     IMAP out
TCP   *   *    *    110 *       qACK/qOthersLow     *     POP3 out
TCP   *   *    *    119 *       qACK/qOthersLow     *     NNTP out
===== === ==== === ==== ======= =================== ===== ======================


Trong bảng trên, cần để ý rằng không phải mọi giao thức TCP đều dùng qACK. Ví dụ, luật đầu tiên vốn dĩ thu tóm tất cả mọi loại lưu thông không khớp với luật nào khác vào qP2P thì cả các gói ACK cũng được đưa vào qP2P. Và, nói chung, không có gì ngăn cản ta lập ra và sử dụng các hàng khác để lưu thông các gói ACK.

Điểm thứ hai đáng để ý là một luật định hình có cấu tạo hoàn toàn giống như luật định tuyến đã mô tả trong phần trước, bởi vì chúng đều là những luật tường lửa. Nhưng bộ luật định hình do wizard tự động tạo ra đi theo nguyên tắc khớp luật ngược lại bộ luật định tuyến: nguyên tắc ở đây là khớp cuối cùng thì thắng (last-match wins). Để tìm luật có thể áp dụng cho một một lưu thông nào đó, hệ thống sẽ phải quét từ đầu bảng đến cuối bảng; nếu không tìm thấy luật nào khớp, lưu thông sẽ bị chặn; nếu tìm thấy nhiều luật khớp, thì luật khớp cuối cùng, tức là luật khớp ở gần cuối bảng nhất, sẽ "thắng", tức là sẽ được chọn để áp dụng. Vì phải quét toàn bộ bảng, nguyên tắc khớp luật này còn được gọi là khớp đầy đủ (full match). Do nguyên tắc như thế, luật càng khái quát thì càng phải viết lên đầu bảng, càng cụ thể thì càng phải viết xuống cuối bảng. Ví dụ, luật "catch-all out" được viết ở đầu bảng và, do khớp với mọi giao thức, mọi nguồn và mọi đích, nó sẽ là luật mặc định, được áp dụng cho lưu thông khi dưới nó không có luật nào khác khớp với lưu thông. Khi tạo hay chỉnh sửa một luật, nếu cần, có thể đưa luật ấy vào chế độ khớp nhanh (quick match) đã trình bày trước đây (xem phần 5, "định tuyến lưu thông"), bằng cách check vào mục Quick. Lựa chọn Quick ở đây sẽ làm cho bộ luật định hình trở nên rất rắc rối, vì thế khi không có lý do gì thật chính đáng thì không nên dùng.

Điểm thứ ba đáng để ý, mọi luật định hình do wizard tự động tạo ra đều không chỉ rõ Interface. Một luật như thế sẽ khớp với kết nối đi qua bất cứ giao diện nào. Chẳng hạn, luật “HTTP out” sẽ được áp dụng cho bất cứ truy cập nào từ mạng cục bộ đến một Web server trên Internet và đồng thời cũng áp dụng luôn cho bất cứ truy cập nào từ Internet đến một Web server đặt trong mạng cục bộ. Khi tạo hay edit một luật, nếu cần, có thể chỉ rõ một hay nhiều giao diện mà luật ấy áp dụng bằng cách click vào tên của các giao diện ấy; nếu cần chọn nhiều giao diện hay xóa các giao diện ra khỏi danh sách các giao diện được chọn thì dùng thêm phím Ctrl. Tab Floating chuyên dùng để chứa các luật có tính khái quát, áp dụng cho mọi giao diện hay nhiều giao diện, nhờ đó làm bộ luật đơn giản hơn, rõ ràng hơn. Việc chọn các giao diện một cách tường minh như trên sẽ làm giảm hiệu quả của sự đơn giản hóa và khái quát hóa này, vì thế nếu muốn dùng phải cân nhắc thật kỹ càng.

Điểm thứ tư đáng để ý là mọi luật định hình do wizard tự động tạo ra bởi đều có Direction là out và không chỉ rõ gateway. Giá trị out chỉ rõ rằng trong một kết nối, trên tuyến đi, các gói tin sẽ được xếp hàng trên giao diện ra (còn trên tuyến về thì luôn luôn ngược lại, nghĩa là các gói tin sẽ xếp hàng trên giao diện vào); nói vắn tắt, mọi gói tin sẽ được xếp hàng trên giao diện phát. Vì như thế nghĩa là định hình thực hiện sau khi định tuyến xong nên không cần phải chỉ rõ gateway. Nếu lựa chọn Direction là in thì giao diện định hình sẽ đảo ngược, tức là các gói tin sẽ xếp hàng trên giao diện thu. Nếu lựa chọn Direction là any thì các gói tin sẽ xếp hàng trên cả giao diện thu và giao diện phát, nghĩa là mỗi gói tin khi đi qua pfSense đều phải xếp hàng hai lần. Với lựa chọn Direction = out, định tuyến và định hình trở thành hai việc độc lập với nhau, nhờ đó có thể tận dụng tối đa khả năng đơn giản hóa và khái quát hóa luật định hình của tab Floating, và vì thế, đối với đa số nhu cầu sử dụng, là lựa chọn tối ưu.



7. Kết luận

Định tuyến và định hình lưu thông hợp lý sẽ giúp khai thác hiệu quả các đường truyền và có thể giúp giải quyết vấn nạn tắc nghẹt đường truyền ở điểm truy cập Internet. Khi thiếu các thiết bị tinh xảo với các kỹ thuật định tuyến và định hình lưu thông cao cấp hay khi thiếu sự hỗ trợ tương ứng với những kỹ thuật cao cấp đó từ phía các ISP thì pfSense là một giải pháp đơn giản và hiệu quả giúp cho bạn tự mình giải quyết vấn đề, vì thế là một giải pháp rất đáng được xem xét.