|
|
KIỂM SOÁT TRUY NHẬP HỆ THỐNG TỆP ZFS
trên NexentaStor v. 3
1 Giới thiệu
Tài liệu này được viết như là "tập 2", nối tiếp theo tài liệu "kiểm soát truy nhập hệ thống tệp NTFS trên Windows Server". Người đọc cần nắm vững "tập 1" trước khi đọc và thực hành "tập 2" này.
Mặc dù tương tự nhưng giữa ZFS với NTFS vẫn có những sự khác biệt. Sự khác biệt này đôi khi không thể hiện ra khi dùng client này mà chỉ thể hiện ra khi dùng client khác. Vì sự khác biệt đó, nói chung không thể áp dụng các công thức phân quyền trên NTFS sang ZFS một cách máy móc được. Vì sự khác biệt đó, mỗi công thức phân quyền đều phải được thử nghiệm thật kỹ trên tất cả các client (trên cả hai môi trường, Windows và *NIX) trước khi đưa vào sử dụng.
2 Phân quyền cơ bản
2.1. Quan hệ giữa ZFS, CIFS với việc thi hành quản chế
Tương tự như việc kiểm soát truy nhập trên Windows Server, nơi có sự kết hợp giữa cơ chế phân quyền hệ thống tệp (NTFS) và phân quyền giao thức chia sẻ (CIFS), trên NexentaStor hệ thống tệp là ZFS và giao thức chia sẻ cơ bản dùng cho Windows và Linux cũng là CIFS. Giống như NTFS, trong ZFS chủ nhân của một file/folder luôn có quyền thay đổi quyền trên file/folder ấy bất kể quyền này có được ghi một cách tường minh trong danh sách kiểm soát truy nhập (ACL) hay không. Khác với CIFS server của Windows vốn dĩ có ba mức (quyền) truy cập Read, Change, và Full Control, CIFS server của NexentaStor chỉ có một mức truy cập là Full Control.
Do đó, khác với Windows, trên NexentaStor phân quyền share (CIFS) không phải là công cụ thực thi quản chế (ngăn chặn chủ nhân của một file/folder thay đổi quyền trên file/folder ấy). Việc thay đổi quyền bởi chủ nhân chỉ có thể giới hạn trong khuôn khổ nhất định, nhưng không thể ngăn chặn hoàn toàn; nói cách khác, trên NexentaStor, mọi share dữ liệu đều ít nhiều có tính chất tự quản.
2.2. Các công cụ phân quyền ZFS
Mười ba quyền truy nhập cơ sở của ZFS là
- execute (x) -- thi hành file / tìm kiếm trong thư mục. Đối với file, cho phép thi hành (chạy). Đối với thư mục, cho phép tìm kiếm (search). Quyền này tương tự như quyền Traverse folder / Execute file của NTFS.
- read_data / list_directory (r) -- đọc dữ liệu / hiện thư mục. Đối với file, cho phép đọc. Đối với thư mục, cho phép xem thư mục. Quyền này tương tự như quyền List folder / Read data của NTFS.
- read_attributes (a) -- đọc thuộc tính. Cho phép đọc các thuộc tính của file và thư mục. Quyền này tương tự như quyền Read attributes của NTFS.
- read_xattr (R) -- đọc thuộc tính mở rộng. Cho phép đọc các thuộc tính mở rộng của file và thư mục. Quyền này tương tự như quyền Read extended attributes của NTFS.
- add_file / write_data (w) -- thêm file, viết dữ liệu. Đối với file, cho phép viết đè vào trong file. Đối với thư mục, cho phép tạo file trong thư mục ấy. Quyền này tương tự như quyền Create files / Write data của NTFS.
- add_subdirectory / append_data (p) -- thêm thư mục con, nối dữ liệu. Đối với file, cho phép viết thêm vào cuối file1 (không cho phép thay đổi nội dung hiện hữu mà chỉ cho phép nối file dài ra thêm một đoạn với nội dung mới).) Đối với thư mục, cho phép tạo thư mục con trong thư mục ấy. Quyền này tương tự như quyền Create folders / Append data của NTFS.
- write_attributes (A) -- viết thuộc tính. Cho phép thay đổi các thuộc tính của file và thư mục. Quyền này tương tự như quyền Write attributes của NTFS.
- write_xattr (W) -- viết thuộc tính mở rộng. Cho phép thay đổi các thuộc tính mở rộng của file và thư mục. Quyền này tương tự như quyền Write extended attributes của NTFS.
- delete_child (D) -- xóa con. Đối với thư mục, cho phép xóa các file bên trong và các thư mục con của thư mục ấy. Đối với file, quyền này không tác dụng. Quyền này tương tự như Delete subfolders and files của NTFS.
- delete (d) -- xóa. Đối với file và thư mục, cho phép xóa bản thân file ấy / thư mục ấy. Quyền này tương tự như quyền Delete của NTFS.
- read_acl (c) -- đọc ACL. Cho phép đọc các quyền truy nhập thư mục/file. Quyền này tương tự như quyền Read permissions của NTFS.
- write_acl (C) -- viết ACL. Cho phép thay đổi các quyền truy nhập thư mục/file. Quyền này tương tự như quyền Change permissions của NTFS.
- write_owner (o) -- viết chủ nhân. Cho phép gán tên chủ sở hữu file / thư mục. Quyền này tương tự như quyền Take ownership của NTFS.
Tương tự như NTFS, quyền trong ZFS khi xác lập cho một thư mục cũng có thể được thừa kế bởi các thư mục con hay các file bên trong nó. Có 3 tùy chọn thừa kế.
- file_inherit (f). Các file sẽ thừa kế.
- dir_inherit (d). Các thư mục con sẽ thừa kế.
- inherit_only (i). Chỉ để thừa kế. Không tác dụng lên bản thân thư mục.
Tổ hợp từ 0 đến 3 trong số 3 tùy chọn trên sẽ được 6 kiểu thừa kế tương tự như trên NTFS.
- Không chọn gì, có tác dụng tương tự như This folder only của NTFS.
- Chọn file_inherit + dir_inherit có tác dụng tương tự như This folder, subfolders and files của NTFS.
- Chọn dir_inherit có tác dụng tương tự như This folder and subfolders của NTFS.
- Chọn file_inherit có tác dụng tương tự như This folder and files của NTFS.
- Chọn file_inherit + dir_inherit + inherit_only có tác dụng tương tự như Subfolders and files only của NTFS.
- Chọn dir_inherit + inherit_only có tác dụng tương tự như Subfolders only của NTFS.
Ngoài ra, việc thừa kế còn được điều khiển bởi một tùy chọn thứ tư.
- no_propagate (n). Không loan truyền xa. Chỉ các đối tượng cấp 1, tức các file/ thư mục con ngay bên trong thư mục này, mới được thừa kế. Các đối tượng cấp 2 và sâu hơn sẽ không thừa kế. Tùy chọn này có tác dụng tương tự như Apply these permissions to objects / container within this container only của NTFS.
Trong ZFS, việc phân quyền và thừa kế quyền còn chịu tác động các tùy biến aclmode và aclinheritance. Ý nghĩa chính xác của các tùy biến này cần xem ở trong sổ tay Solaris ZFS Admin Guide, nhưng tinh thần cơ bản là aclmode giới hạn tác dụng của ACL (danh sách kiểm soát truy nhập) trong khuôn khổ các cờ phân quyền (permission flags) của hệ điều hành UNIX, còn aclinheritance hạn chế tác dụng của việc thừa kế ACL bằng việc tước bỏ quyền thừa kế hai quyền nhạy cảm nhất: write_acl và write_owner. Giá trị mặc định của aclmode là groupmask, giá trị mặc định của aclinheritance là restricted. Với giá trị đó việc thừa kế còn chịu ràng buộc và giới hạn nhất định. Để triệt bỏ hoàn toàn mọi ràng buộc và giới hạn (nghĩa là để có một hệ thống ACL thuần túy, làm cho việc phân quyền trở nên giống NTFS hơn) cần phải chỉnh cả hai giá trị thành passthrough. Tuy nhiên, cần lưu ý rằng một thư mục với passthrough sẽ trở thành hoàn toàn tự quản, không thể thi hành quản chế. Các công thức phân quyền sẽ trình bày trong tài liệu này với aclmode = mặc định và aclinheritance = passthrough hay mặc định đều được cả.
NexentaStor có công cụ phân quyền bằng giao diện Web và giao diện dòng lệnh, tuy nhiên công cụ này không hoàn thiện bằng giao diện đồ họa hay dòng lệnh của Windows / Linux. Vì thế, phương án sử dụng được chính nhà cung cấp NexentaStor khuyến cáo là phân quyền từ xa, mà tốt nhất là từ DC hay từ một máy chủ hay máy trạm Windows thuộc cùng một miền Active Directory với thiết bị NexentaStor.
Do đó, một thủ tục tối thiểu để setup một thiết bị NAS với NexentaStor cho môi trường mạng AD có cả Windows lẫn Linux client gồm các bước như sau.
- Cài đặt NexentaStor. Cấu hình DNS client và NTP client. Update / Upgrade nếu cần.
- Nếu dùng giao diện Web, đưa giao diện Web sang chế độ Expert_mode.
- Tạo các volume từ các ổ cứng của thiết bị.
- Join thiết bị vào Active Directory domain.
- Ứng với mỗi nhóm của AD, tạo một nhóm tương ứng trên NexentaStor và thiết lập ánh xạ định danh (ID mapping) hai chiều thể hiện sự tương ứng đó. Ví dụ, nếu trong AD của domain tên là mycompany.com có một nhóm tên là Designers thì trên NexentaStor ta cũng tạo một nhóm đặt tên là designers và lập ánh xạ wingroup:designers@mycompany.com = unixgroup:designers.
- Thiết lập ánh xạ định danh hai chiều để nhóm staff = Administrators / Domain Admins (hay một nhóm người dùng nào đó chuyên trách về an ninh) của AD, hoặc người dùng admin = Administrator (hay một người dùng nào đó chuyên trách về an ninh) của AD.
Và một thủ tục tối thiểu để setup một CIFS share trên NexentaStor cho môi trường mạng nói trên gồm các bước như sau.
- Trên NexentaStor, tạo folder. Bật Mixed case sensitivity filename và bật Unicode (UTF8) filename only để tăng độ tương thích giữa các hệ điều hành. (Khuyến cáo: tắt Access time update để tăng tốc độ truy cập; bật Deduplication để tiết kiệm dung lượng.)
- Bật share với giao thức CIFS. Tắt Anonymous sharing để bảo mật.
- Cấp quyền, tối thiểu write_acl và write_owner, cho group:staff hoặc user:admin.
- Từ DC, từ một máy chủ hay một máy trạm Windows đã đăng nhập bằng một tên tương ứng với nhóm staff hoặc người dùng admin, truy nhập share. Dùng công cụ đồ họa hay dòng lệnh của Windows để hoàn thành việc phân quyền.
Chú ý rằng việc cấp quyền phân quyền cho staff hay admin để có thể phân quyền từ máy tính Windows chỉ cần thiết để thiết lập các share tự quản, share quản chế hay các loại hình tổ chức dữ liệu nâng cao khác, còn để thiết lập các share chứa dữ liệu cá nhân thì không cần thiết. Việc tạo một ZFS share chứa dữ liệu cá nhân, nhìn chung, chỉ dựa vào phân quyền mặc định. Thủ tục như sau.
- Kiểm tra khẳng định rằng owner@ có quyền list_directory, read_data, add_file, write_data, add_subdirectories, append_data, read_xattr, write_xattr, execute, read_attributes, write_attributes, read_acl, write_acl, write_owner, synchronize.
- Kiểm tra khẳng định rằng group@ có quyền list_directory, read_data, read_xattr, execute, read_attributes, read_acl, synchronize.
- Kiểm tra khẳng định rằng everyone@ có quyền list_directory, read_data, read_xattr, execute, read_attributes, read_acl, synchronize.
- Cấp quyền mặc định cho các nhóm người dùng cần tạo các thư mục chứa dữ liệu cá nhân. Kiểm tra khẳng định rằng mỗi nhóm như thế có quyền list_directory, read_data, add_subdirectory, append_data, write_xattr, execute, write_attributes, synchronize.
Chú ý rằng khi phân quyền bằng công cụ Windows, nếu cho cùng một người dùng hay nhóm người dùng có hai hay nhiều luật phân quyền áp dụng thì trên giao diện Web của NexentaStor sẽ có dòng chữ màu đỏ cảnh báo “duplicate entries” và NexentaStor sẽ gợi ý hãy “reset ACL”. Đừng reset.
Vì từ đây ta sẽ sử dụng công cụ phân quyền của Windows, trong những đoạn sau, các công thức phân quyền sẽ được trình bày bằng thuật ngữ NTFS thay vì các thuật ngữ ZFS đã được giới thiệu ở trên. Chẳng hạn, folder thay vì thư mục, create folders thay vì add_subdirectories. Nhưng phải luôn luôn nhớ rằng đó là những công thức dùng cho ZFS, mà nhìn chung là không giống như công thức NTFS tương đương.
2.3. Các quyền cơ bản của dữ liệu doanh nghiệp
Nhắc lại tập 1, hệ thống dữ liệu doanh nghiệp thường sử dụng 5 quyền cơ bản đối với một folder, kể cả folder con bên trong nó.
- Xem quyền. Xem ai có quyền gì đối với folder.
- Xem thư mục. Xem danh sách file/thư mục con cùng các thông tin cơ bản như ngày giờ biên tập, độ dài file,...
- Sử dụng. Xem quyền, xem thư mục folder/folder con và đọc nội dung mọi file bên trong.
- Đóng góp. Sử dụng, tạo file/folder con, đổi tên, sửa, xóa những file/folder bản thân tạo ra.
- Biên tập. Đóng góp và đổi tên, sửa, xóa mọi file/folder con kể cả những file/folder con mà người khác tạo ra.
2.4. Thực hiện các quyền cơ bản của dữ liệu doanh nghiệp trên ZFS
Trong ZFS, năm quyền cơ bản trên một folder dữ liệu doanh nghiệp được thực hiện theo những công thức như sau.
- Quyền sử dụng = Read & Execute, List Folder Contents và Read this folder, subfolders and files.
- Quyền đóng góp = quyền sử dụng + Create folders/Append data this folder and subfolders.
- Quyền biên tập = quyền sử dụng + Modify và Write this folder, subfolders and files.
- Quyền xem thư mục = List folder / Read data this folder and subfolders.
- Quyền xem quyền = Read Permissions this folder and subfolders (hoặc this folder, subfolders and files, đã giải thích trong tập 1).
Để ý rằng khác với NTFS, quyền đóng góp ở ZFS thật ra là chỉ đóng góp folder. Muốn đóng góp file vào một folder của người khác, phải tạo một folder con rồi ghi các file đóng góp vào trong folder con đó.
2.5. Tổ chức share tự quản
Khái niệm share tự quản đã được định nghĩa trong tập 1. Trên share tự quản, quyền truy nhập thích hợp trên folder cấp 0 là:
- Administrators (hoặc Administrator) có quyền Full Control this folder, subfolders and files.
- Current Owner có quyền Modify subfolders and files only.
- Current Group có quyền Read & Execute this folder only.
- Everyone có quyền Read & Execute this folder only.
- 0, 1, nhiều người hay mọi người trong Phòng có quyền biên tập, những người còn lại có quyền đóng góp.
CHÚ Ý. Quyền của Current Group và Everyone như trên là mặc định. Quyền của Current Group như trên dùng khi mọi người dùng không phân biệt Phòng đều có primary group = Domain Users (thiết đặt mặc định của Microsoft AD). Ngược lại khi mỗi người dùng có primary group = Phòng thì quyền thích hợp cho Current Group là quyền sử dụng.
Đối với folder con (tức folder cấp 1, 2, 3,... trong con mắt của người sử dụng máy trạm) quyền truy nhập thích hợp là quyền mặc định, nghĩa là chỉ thừa kế những quyền đã được cho phép thừa kế từ folder mẹ, không thêm bớt quyền nào.
2.6. Tổ chức share quản chế
Khái niệm share quản chế đã được định nghĩa trong tập 1. Trên share quản chế, trên folder cấp 0 quyền truy nhập thích hợp là
- Administrators (hoặc Administrator) có quyền Full Control this folder, subfolders and files.
- Nhân viên giám sát an ninh thông tin có quyền xem quyền và xem thư mục.
- Current Owner có quyền Modify subfolders and files only.
- Current Group có quyền Read & Execute, List Folder Contents và Read this folder, subfolders and files, nhưng chỉ Apply these permissions to objects / containers within this containers only.
- Everyone có quyền giống như Current Group.
Trên một folder cấp 1 (tức nhóm hồ sơ), quyền truy nhập thích hợp là mặc định.
Trên một folder cấp 2 (tức hồ sơ), quyền truy nhập thích hợp là:
- Mọi quyền thừa kế từ folder mẹ.
- Các quyền sử dụng, đóng góp, biên tập, cấp theo quyết định của người quản lý hồ sơ.
Trên một folder cấp 3 và mọi folder cấp thấp hơn (tức thành phần, thành phần con của hồ sơ), quyền truy nhập thích hợp là mặc định.
Trường hợp một hồ sơ cần tách ra thành vài phần với quyền truy nhập khác nhau thì nên thực hiện mỗi phần bằng một folder cấp 2, tức là mỗi phần xem như ngang với một hồ sơ độc lập.
3 Kết luận
Phân quyền ZFS tương tự như NTFS, vì thế khi chia xẻ hệ thống file thông qua CIFS, có thể phân quyền bằng giao diện đồ họa hay công cụ dòng lệnh từ một máy Windows.
|
|
|
Bài này có hai tập. Tập 1 nói về phân quyền trên NTFS. Tập 2 nói về phân quyền trên ZFS.
KIỂM SOÁT TRUY NHẬP HỆ THỐNG TỆP NTFS
trên Windows Server 2003 và 2008
1 Phân quyền đơn giản
Windows có một cơ chế kiểm soát truy nhập rất đơn giản là share đồng thời phân quyền. Muốn share một folder, hãy click nút phụ của con chuột vào folder ấy, sẽ hiện context menu, chọn lệnh Share..., lần lượt Add từng nhóm người dùng (hay từng người dùng), cứ mỗi nhóm chọn Permission Level để phân quyền cho nhóm ấy. Xong ấn nút Share.
Theo cách này, mỗi nhóm có thể có một trong ba quyền truy nhập.
- Viewer (người xem). Xem toàn bộ nội dung folder.
- Contributor (người đóng góp). Xem toàn bộ nội dung folder, có thể tạo thêm file và folder và sửa file / folder mà bản thân đã thêm.
- Co-owner (đồng chủ sở hữu). Xem và sửa toàn bộ nội dung của folder, kể cả các file/folder mà người khác tạo ra.
Ba quyền này không độc lập với nhau. Co-owner bao hàm Contributor, và Contributor lại bao hàm Viewer.
Cơ chế này rất dễ dùng và tiện dùng, nhưng không dùng được trong nhiều trường hợp. Hơn nữa, cơ chế này không có trên Windows Server 2003 mà chỉ có ở Windows Server 2008.
2 Phân quyền cơ bản
2.1. Giới thiệu cơ chế phân quyền NTFS
Cơ chế kiểm soát truy nhập cơ bản trên Windows Server là kết hợp giữa hai cơ chế phân quyền: phân quyền trên hệ thống tệp NTFS và phân quyền trên giao thức chia xẻ tệp CIFS (hay còn gọi là phân quyền share).
Phân quyền CIFS có ba quyền:
- Read (đọc),
- Change (sửa), và
- Full Control (toàn quyền).
Ba quyền này không độc lập với nhau. Full Control bao hàm Change, và Change lại bao hàm Read.
Phân quyền NTFS có sáu quyền:
- Full Control (toàn quyền),
- Modify (sửa),
- Read & Execute (đọc tệp và chạy chương trình),
- List folder contents (hiện nội dung thư mục),
- Read (đọc), và
- Write (viết).
Sáu quyền này không độc lập với nhau. Full Control bao hàm tất cả các quyền còn lại. Thực sự, mỗi quyền trong số đó là một tập hợp gồm nhiều quyền nhặt ra từ 13 quyền cơ sở (special access permissions) hoàn toàn độc lập với nhau. Full Control cấu thành từ tất cả cả 13 quyền cơ sở này. Xem chi tiết ở đoạn sau.
Khi truy nhập server từ máy trạm, quyền truy nhập là giao giữa hai quyền CIFS và NTFS. Ví dụ, khi một nhóm có quyền Full Control trên một NTFS folder truy nhập vào folder ấy được share với quyền Modify cho nhóm ấy thì quyền kết quả chỉ là Modify. Do đó, trong thực tiễn làm việc, để giảm bớt sự phức tạp, khi tạo nhiều share trên một server, có thể và nên tạo các share ấy theo cùng một quyền (CIFS) thống nhất cho mọi share và mọi người dùng, cụ thể:
- Trên mọi share tự quản, Everyone có quyền Full Control.
- Trên mọi share quản chế, Everyone có quyền Change.
Lưu ý. Trường hợp hộp thư tự quản (xem ở dưới) người dùng phải tự đổi quyền thư mục của mình. Để việc này có thể thi hành từ máy trạm, Full Control share là bắt buộc. Trong những trường hợp share tự quản khác, Everyone chỉ cần quyền Change là đủ.
Sự phân biệt quyền truy nhập giữa các nhóm khác nhau và trên các share khác nhau khi đó sẽ chỉ thể hiện ở phân quyền NTFS.
2.2. Các công cụ phân quyền NTFS
Mười ba quyền truy nhập cơ sở của NTFS là
- Traverse folder/execute file (đi xuyên qua folder / thi hành file). Đối với folder, cho phép đi xuyên qua folder đó để truy cập vào folder con. Đối với file, cho phép thi hành (chạy). Tất nhiên, việc thi hành (chạy) chỉ có tác dụng nếu file ấy là một file chương trình.
- List folder/read data (hiện thư mục, đọc dữ liệu). Đối với folder, cho phép xem thư mục. Đối với file, cho phép đọc.
- Read attributes (đọc thuộc tính). Cho phép đọc các thuộc tính của file và folder.
- Read extended attributes (đọc thuộc tính mở rộng). Cho phép đọc các thuộc tính mở rộng của file và folder.
- Create files/write data (tạo file, viết dữ liệu). Đối với folder, cho phép tạo file trong folder ấy. Đối với file, cho phép viết đè vào trong file.
- Create folders/append data (tạo folder, nối dữ liệu). Đối với folder, cho phép tạo folder con trong folder ấy. Đối với file, cho phép viết thêm vào cuối file (việc viết thêm không thay đổi nội dung hiện hữu mà sẽ làm cho file dài ra thêm một phần nội dung mới.)
- Write attributes (viết thuộc tính). Cho phép thay đổi các thuộc tính của file và folder.
- Write extended attributes (viết thuộc tính mở rộng). Cho phép thay đổi các thuộc tính mở rộng của file và folder.
- Delete subfolders and files (xóa folder con và file). Đối với folder, cho phép xóa các folder con và file bên trong folder ấy. Quyền này không tồn tại đối với file.
- Delete (xóa). Đối với folder và file, cho phép xóa bản thân folder ấy/file ấy.
- Read permissions (đọc quyền). Cho phép đọc các quyền truy nhập folder/file.
- Change permissions (đổi quyền). Cho phép thay đổi các quyền truy nhập folder/file.
- Take ownership (đoạt chủ quyền). Cho phép đoạt quyền sở hữu folder/file.
Khi phân quyền cho một folder, quyền đã phân sẽ có thể sẽ áp dụng lên cả các folder con và file bên trong, việc này gọi là thừa kế. Việc thừa kế thực hiện theo một trong sáu kiểu sau đây.
- This folder only (chỉ folder này thôi). Quyền chỉ áp dụng cho folder này, không thừa kế.
- This folder, subfolders and files (folder này, các folder con và các file). Quyền áp dụng cho folder này, các folder con và các file. Thừa kế toàn phần.
- This folder and subfolders (folder này và các folder con). Quyền áp dụng cho folder này và các folder con. Các folder con thừa kế.
- This folder and files (folder này và các file). Quyền áp dụng cho folder này và các file. Các file thừa kế.
- Subfolders and files only (các folder con và các file thôi). Quyền áp dụng chỉ cho các folder con và các file. Thừa kế toàn phần ngoại trừ bản thân.
- Subfolders only (chỉ các folder con thôi). Quyền áp dụng chỉ cho các folder con. Các folder thừa kế ngoại trừ bản thân.
Ngoài ra, việc thừa kế còn được điều khiển bởi một check box tên là Apply these permissions to objects / container within this container only (chỉ áp dụng những quyền này cho các đối tượng hay container ngay trong container này mà thôi). Ý nghĩa chính xác của check box này cần xem ở trong sách giáo khoa Windows, nhưng tinh thần cơ bản là thừa kế chỉ áp dụng lên các folder con / file ở cấp 1 là hết, không áp dụng lên các folder con / file ở cấp 2 và các cấp sâu hơn bên trong.
2.3. Các quyền cơ bản của dữ liệu doanh nghiệp
Hệ thống dữ liệu doanh nghiệp thường sử dụng 5 quyền cơ bản đối với một folder, kể cả folder con bên trong nó:
- Xem quyền. Xem ai có quyền gì đối với folder.
- Xem thư mục. Xem danh sách file/folder con cùng các thông tin cơ bản như ngày giờ biên tập, độ dài file,...
- Sử dụng. Xem quyền, xem thư mục (kể cả các thư mục con) và đọc nội dung mọi file bên trong.
- Đóng góp. Sử dụng, tạo file/folder con và đổi tên, sửa, xóa những file bản thân đã tạo ra.
- Biên tập. Đóng góp và đổi tên, sửa, xóa mọi file/folder con kể cả những file / folder con mà người khác tạo ra.
2.4. Thực hiện các quyền cơ bản của dữ liệu doanh nghiệp trên NTFS
Trong hệ thống tệp NTFS, năm quyền cơ bản trên folder dữ liệu doanh nghiệp được thực hiện theo những công thức sau đây.
- Quyền sử dụng = Read & Execute, List Folder Contents và Read this folder, subfolders and files.
- Quyền đóng góp = quyền sử dụng + Create files / Write data và Create folders/Append data this folder and subfolders.
- Quyền biên tập = quyền sử dụng + Modify và Write this folder, subfolders and files.
- Quyền xem thư mục = List folder / Read data this folder and subfolders.
- Quyền xem quyền = Read Permissions this folder and subfolders.
- Quyền xem quyền = Read Permissions this folder, subfolders and files.
Để ý rằng quyền xem quyền có thể thực hiện bằng một trong hai công thức. Công thức thứ nhất chỉ cho phép xem quyền cả thư mục chứ không cho phép xem quyền từng file. Công thức thứ hai cho phép xem quyền cả thư mục và từng file. Thông thường, công thức thứ nhất là đủ, và tiện lợi hơn vì có thể thực hiện quyền xem quyền cùng với quyền xem thư mục đồng thời chỉ bằng 1 luật phân quyền. Nhưng khi thật cần thiết, có thể dùng công thức thứ hai, khi đó, xem quyền và xem thư mục phải thực hiện bằng hai luật khác nhau.
2.5. Tổ chức share tự quản
Một share tự quản là một share cấp cho một nhóm nhỏ người dùng (thường là một Phòng) để cất chứa dữ liệu dùng chung giữa những người trong nhóm. Gọi là tự quản vì người dùng tự tổ chức công tác quản lý dữ liệu, ai cũng có thể tạo ra folder cấp 1 (và các cấp dưới) đặt tên một cách tùy ý. Việc phân quyền do Admin thi hành nhưng đơn giản, nên có thể yêu cầu miệng, không cần yêu cầu bằng văn bản.
Đối với folder được share (tức folder cấp 0 trong con mắt của người sử dụng máy trạm), quyền truy nhập thích hợp là:
- Administrators có quyền Full Control this folder, subfolders and files.
- CREATOR OWNER có quyền Full Control subfolders and files only.
- 0, 1, nhiều người hay mọi người trong nhóm có quyền biên tập, những người còn lại có quyền đóng góp. Chế độ không người biên tập, một người biên tập, nhiều người biên tập hay mọi người biên tập được áp dụng là tùy theo mức độ tin tưởng lẫn nhau giữa những người trong nhóm, số lượng người của nhóm và sơ đồ tổ chức của nhóm.
Đối với folder con (tức folder cấp 1, 2, 3,... trong con mắt của người sử dụng máy trạm) quyền truy nhập thích hợp là quyền mặc định, nghĩa là chỉ thừa kế những quyền đã được cho phép thừa kế từ folder mẹ, không thêm bớt quyền nào.
2.6. Tổ chức share quản chế
Một share quản chế là một share cấp cho một nhóm lớn người dùng (thường là toàn thể công ty) để cất chứa dữ liệu dùng chung giữa những người trong nhóm. Sở dĩ được gọi là quản chế vì công tác quản lý dữ liệu thực hiện theo một chế độ nhất quán và cứng rắn do bộ phận chuyên trách (IT) xây dựng. Chỉ có Admin mới có quyền tạo các folder cấp cao còn người dùng chỉ có quyền tạo các folder con ở cấp thấp. Các folder cấp cao được quản lý trong những danh bạ và được gọi bằng một thuật ngữ riêng. Mọi cấp folder cao cũng đều được gọi bằng một thuật ngữ riêng. Ví dụ, các folder cấp cao bao gồm cấp 1 và cấp 2. Trong đó mỗi folder cấp 1 được gọi là một nhóm hồ sơ, mỗi folder cấp 2 được gọi là một hồ sơ. Danh bạ quản lý các hồ sơ dữ liệu công cộng được gọi là thư viện. Danh bạ quản lý các hồ sơ dữ liệu công ty được gọi là tàng thư. Thủ tục lập hồ sơ và phân quyền được xây dựng trên cơ sở yêu cầu thi hành bằng văn bản và việc thi hành được xác nhận bằng văn bản.
Đối với một folder được share (tức folder cấp 0 trong con mắt của người sử dụng máy trạm) quyền truy nhập thích hợp là
- Administrators có quyền Full Control this folder, subfolders and files.
- CREATOR OWNER có mọi quyền, ngoại trừ Change Permissions và Take Ownership, đối với subfolders and files only.
- Nhân viên giám sát an ninh thông tin có quyền xem quyền và xem thư mục.
- Authenticated Users có quyền Read & Execute, List Folder Contents và Read this folder, subfolders and files, nhưng chỉ Apply these permissions to objects / containers within this containers only. Lưu ý: quyền này khác hẳn quyền sử dụng.
Đối với một folder nhóm hồ sơ (tức folder cấp 1 trong con mắt của người sử dụng máy trạm), quyền truy nhập thích hợp là mặc định.
Đối với một folder hồ sơ (tức folder cấp 2 trong con mắt của người sử dụng máy trạm), quyền truy nhập thích hợp là:
- Mọi quyền thừa kế từ folder mẹ.
- Các quyền sử dụng, đóng góp, biên tập, cấp theo quyết định của người quản lý hồ sơ.
Đối với folder con của hồ sơ (tức folder cấp 3 trong con mắt của người sử dụng máy trạm) và mọi folder cấp thấp hơn, quyền truy nhập thích hợp là mặc định.
Trường hợp một hồ sơ cần tách ra thành vài phần với quyền truy nhập khác nhau thì nên thực hiện mỗi phần bằng một folder cấp 2, tức là mỗi phần xem như ngang với một hồ sơ độc lập.
3 Phân quyền nâng cao
3.1. Tổ chức hộp thư tự quản
Một share trung chuyển là một share phục vụ cho việc trao đổi dữ liệu giữa những người dùng với nhau, chỉ cất dữ liệu tạm thời. Chú ý rằng nếu người sử dụng trao đổi dữ liệu bằng cách dời (move) hơn là sao chép (copy) dữ liệu vào share / từ share thì việc này thường gây ra lỗi thừa kế quyền khi thư mục nguồn và đích nằm trên cùng một NTFS partition. Vì lẽ đó, để tránh lỗi, mỗi share nhất là share trung chuyển nên được tạo trên một máy chủ riêng, một ổ cứng riêng hay ít ra một partition riêng, cách biệt hoàn toàn với các share khác.
Một hộp thư là một folder của một người dùng trên share trung chuyển để nhận dữ liệu của người khác gửi đến. Nếu các hộp thư được tổ chức trên một share tự quản, ta bảo chúng tự quản. Khi tổ chức hộp thư tự quản, ai cũng có thể tự tạo hộp thư cho mình và ai cũng có thể gửi dữ liệu vào hộp thư của bất cứ người nào.
Đối với một folder được share thành share trung chuyển (tức folder cấp 0 trong con mắt của người sử dụng máy trạm) để chứa các hộp thư tự quản, quyền truy nhập thích hợp là
- Administrators có quyền Full Control this folder, subfolders and files.
- CREATOR OWNER quyền Full Control subfolders and files only.
- Nhân viên giám sát an ninh thông tin có quyền xem quyền và xem thư mục.
- Authenticated Users có quyền Create folders / append data this folder and subfolders.
- Authenticated Users có quyền List folder / read data và Read Permissions this folder and subfolders, nhưng chỉ Apply these permissions to objects / containers within this containers only.
- Authenticated Users có quyền Create files/write data subfolders only.
Share này phải được share với quyền (CIFS) Full Control.
Để nhận dữ liệu, mỗi người sử dụng tự tạo một folder (cấp 1) làm hộp thư cho mình, tự phân cho bản thân quyền biên tập trên hộp thư này.
Người gửi dữ liệu sao chép folder dữ liệu / file dữ liệu vào hộp thư của người nhận.
Mọi người đều có đủ quyền cần thiết. Ai cũng có quyền xem quyền folder cấp 0 để biết chính xác hộp thư nào của ai và có quyền mở hộp thư của bất cứ ai để bỏ dữ liệu vào. Chủ nhân của hộp thư có quyền xem, sửa, đổi tên và xóa mọi file/folder trong hộp thư, kể cả xem quyền để biết dữ liệu nào của ai gửi đến. Ai gửi file/folder nào thì có quyền xem, sửa, đổi tên và xóa file/folder nấy. Người thứ ba khi mở hộp thư xem không thể xem được file/folder, thậm chí không biết được file/folder ấy của ai gửi đến.
3.2. Tổ chức hộp thư quản chế
Nếu các hộp thư được tổ chức trên một share (trung chuyển) quản chế thì ta bảo chúng là được quản chế. Khi quản chế, chỉ một số người nhất định (Receivers) là có quyền nhận dữ liệu và chỉ một số người nhất định (Senders) có quyền gửi dữ liệu cho người khác, hai nhóm người này không nhất thiết trùng nhau, mọi hộp thư đều do bộ phận chuyên trách (IT) lập ra và phân quyền.
Đối với một folder được share thành share trung chuyển (tức folder cấp 0 trong con mắt của người sử dụng máy trạm) để chứa các hộp thư quản chế, quyền truy nhập thích hợp là
- Administrators có quyền Full Control this folder, subfolders and files.
- CREATOR OWNER có mọi quyền ngoại trừ Delete subfolders and files, Change Permissions và Take ownership, đối với subfolders and files only.
- Nhân viên giám sát an ninh thông tin có quyền xem quyền và xem thư mục.
- Receivers có quyền Traverse folder / execute file, List folder / read data, Read attributes, Read extended attributes, Read permissions đối với this folder only.
- Senders có quyền Traverse folder / execute file, List folder / read data, Create files / write data, Create folders / append data, Read permissions đối với subfolders only, nhưng chỉ Apply these permissions to objects / containers within this containers only.
Để nhận dữ liệu, Admin tạo cho mỗi người trong nhóm Receivers một hộp thư (tức folder cấp 1 trong con mắt của người sử dụng máy trạm) và phân quyền bổ sung cho từng hộp thư như sau.
- Chủ nhân của hộp thư (tức người nhận dữ liệu gửi đến hộp thư) có quyền Read & Execute, List folder contents, Read và Delete subfolders and files trên this folder, subfolders and files.
Người gửi dữ liệu copy folder dữ liệu/file dữ liệu vào hộp thư của người nhận.
Mọi Senders đều có quyền xem quyền folder cấp 0 để biết chính xác hộp thư nào của ai và có quyền mở hộp thư của bất cứ ai để bỏ dữ liệu vào. Chủ nhân của hộp thư có quyền xem và xóa mọi file/folder trong hộp thư, kể cả xem quyền để biết chính xác từng file/folder nào của ai gửi đến. Ai gửi file/folder nào có quyền xem, sửa, đổi tên và xóa file/folder ấy. Người thứ ba nếu thuộc nhóm Senders xem hộp thư có thể biết được file/folder của ai gửi đến, nhưng không xem được nội dung những file/folder đó. Người ngoài nhóm Senders không có quyền mở hộp thư người khác, thậm chí không có quyền biết những hộp thư khác của ai.
4. Kết luận
Với Windows và hệ thống file NTFS và giao thức CIFS, có vài phương thức phân quyền khác nhau để kiểm soát truy nhập dữ liệu, từ đơn giản đến phức tạp. Tùy theo nhu cầu của doanh nghiệp mà ta có thể chọn phương thức thích hợp mà áp dụng.
|
|
|
ĐỊNH TUYẾN VÀ ĐỊNH HÌNH LƯU THÔNG TRUY CẬP INTERNET
với pfSense v. 2
(tiếp theo)
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.
|
|
|
ĐỊNH TUYẾN VÀ ĐỊNH HÌNH LƯU THÔNG TRUY CẬP INTERNET
với pfSense v. 2
(tiếp theo)
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 wwwection.
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.
(còn nữa)
|
|
|
ĐỊNH TUYẾN VÀ ĐỊNH HÌNH LƯU THÔNG TRUY CẬP INTERNET
với pfSense v. 2
1. Giới thiệu pfSense v. 2
Đườ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.
(còn nữa)
|
|
|
toitammatmay wrote:
À cái BWM mình đang định dùng nó nếu bạn đã từng xài wa thì chỉ với nhé vì tài liệu trên mạng về hướng dẫn sử dụng nó ít và hình như ko thực tế cho mấy.
Có phải bạn đang nói tới cái này
http://www.softperfect.com/products/bandwidth/
hay không?
|
|
|
toitammatmay wrote:
@dusan: có lẽ bạn vẫn chưa rõ tí. Mình là trực thuộc công ty bán hadware load balancing cho công ty A. Tất cả những yêu cầu đc công ty A dặt ra là vấn đề bên phía công ty mình hỗ trợ và ko tính phí với họ. Công ty A đầu tư hadware loadbalancing để mạng luôn đc ổn định 24/24 như đã ghi ở trên còn vấn đề phát sinh bandwidth thực sự là hỗ trợ --> nên cũng phải hết mình vì công việc
Những vấn đề đó dần đang đc mình xử lý chỉ còn mỗi cái Bandwidth khiến mình chưa nghĩ ra đc cách nào hiệu quả vì trước tới giờ mình chưa từng làm về nó nên trao đổi cùng mọi người để nhận đc sự đóng góp. Thanks các bạn đã đọc topic và đóng góp ý kiến. Vẫn mong nhận đc sự đóng góp từ phía các bằng hữu để phương án tốt hơn.
P/S : Mình từ trước tới giờ chưa từng up hình trên forum nên sơ đồ mạng của công ty A đc vẽ tới giờ vẫn chưa biết cách up lên đc .Mọi ng chỉ toitammatmay phần này với nhé. Thanks
Tôi hiểu rõ vấn đề của bạn. Load balacing không thể thiếu load balancer. )
Nhưng "traffic control" (traffic shaping) cũng không thể thiếu "traffic controller" (traffic shaper). ) Không có nó, giống như giao thông không có luật, dù đi trên xa lộ 10 làn xe vẫn bị tắc nghẹt như thường. Và đó không phải là yêu cầu "phát sinh", mà là yêu cầu chủ yếu để đảm bảo "mạng được ổn định" (QoS) trong phạm vi khả năng của khách hàng.
Yêu cầu phát sinh ở đây là một traffic shaper không phải mất tiền mua bởi vì khách hàng tưởng rằng vấn đề đó đã được giải quyết rồi nhờ thiết bị load balancer vừa mới mua. Còn bạn, nhà cung cấp thiết bị, vì lý do nào đó, không muốn cho khách hàng nhìn rõ sự thật. :wink:
Cũng OK thôi. Theo mô tả của bạn, khách hàng vẫn còn thừa một máy hiện dang dùng làm DHCP server. Bạn có thể tận dụng máy này, cài đặt một traffic shaper.
Chẳng hạn như m0n0wall, giới thiệu ở trên. Bởi có lẽ bạn chưa xem link, tôi xin mở ngoặc là m0n0wall có DHCP server; và còn nhiều tính năng khác có lẽ cũng đáng quan tâm.
Phương pháp traffic shaping dùng trong m0n0wall là một phương pháp tĩnh (non-adaptive). Nghĩa là để nó hoạt động đúng, nhà cung cấp dịch vụ Internet (ISP) phải giữ đúng cam kết băng thông. m0n0wall cũng tự động trừ đi 5-20% khi bạn khai báo max bandwidth, xem như là dung sai trong cam kết của ISP. Nhưng nếu ISP vi phạm dung sai này, non-adaptive traffic shaping sẽ không xử lý được nữa.
Thân. )
|
|
|
toitammatmay wrote:
Mình đang gặp 1 vấn đề về bandwidth control mọi người xem thử và có thể đóng góp ý kiến giúp nhé:
Công ty A có 2 lease line: 1 cáp quang và 1 line ADSL và có 70 máy Pc trong đó có 20 PC của các sếp dùng và 50 PC còn lại là của nhân viên.
Yêu cầu đặt ra là: muốn mạng luôn đc ổn định 24h/24h và 7 ngày /7 ngày. Và tất cả 20 máy PC của các sếp được đặt IP tĩnh luôn có bandwidth high (xem như 100% vậy) và 50 máy còn lại thì bandwidth dc set với mức low.
100% thì không, nhưng 90% thì được (bandwidth chia cho 2 làn sếp:nhân viên theo tỉ lệ 9:1.)
Yêu cầu hardware: 200 MHz x86 CPU, 64 MB RAM, 16 MB DOM/HDD (không biết máy như thế này bao nhiêu tiền nhỉ?)
Yêu cầu software: m0n0wall v.1.231 (free).
Xem ảnh software: http://m0n0.ch/wall/screenshots.php
Xem ảnh hardware: http://m0n0.ch/wall/gallery.php
Download: http://m0n0.ch/wall/downloads.php
|
|
|
Bạn M20T thân mến. CIPE là một phần mềm VPN thực hiện một giao thức riêng (không chuẩn), ít phổ biến trên Windows. Vì thế chúng tôi không nghĩ cài đặt nó trên Linux có lợi ích gì trong trường hợp này của bạn.
Bạn nên cho biết trong Windows bạn đã dùng loại VPN nào. Thí dụ, VPN client của Microsoft có sẵn trong Win XP có thể kết nối với 2 loại VPN server:
- PPTP
- L2TP over IPsec (chú ý: không phải là IPsec.)
|
|
|
shockdown wrote:
- Mạng trong phòng em bi tình trạng nếu như cắm các dây mạng trực tiếp từ các line có sẵn trong phòng và các máy tính để bàn thì hầu như ko thấy mạng nội bộ và cũng 1 vài máy ra internet được . Nhưng khi dùng máy tính xach tay để test các line đó thì đều ra mạng được . Sau đó dung bất cứ line nào cắm vào 1 cái switch rôi chia đuề ra các máy thì thấy mạng nội bộ và đều ra net được hết . Anh nào giải thích dc ko nhỉ
1. Có lẽ ý bạn là thế này. Bạn dùng mạng cơ quan. Cấu tạo mạng ra sao, bạn không biết. Trong phòng bạn ở trên tường có sẵn 5 ổ cắm (line) RJ45. Bạn đã thử cắm một máy xách tay lần lượt vào các ổ đó, thấy đều thông mạng được tốt. Nhưng khi cắm đồng thời các máy để bàn trong phòng vào các ổ đó, thì có cái "thông", cái không "thông". Có phải vậy không?
2. Có lẽ bạn dùng Windows. Bạn hãy cho biết ipconfig của các máy "không thông" và cả các máy "thông".
|
|
|
iat wrote:
Bây giờ bạn có nghe ai khen một người nào đó giỏi về tin học "anh ta là một hacker tài thiệt" mà thường nghe là một "hacker khét tiếng ở ...." đã bị công an bắt tại nhà riêng
Nếu bạn chưa từng nghe ai nói như thế thì đó là câu chuyện của riêng bạn. Xin đừng lôi chúng tôi vào đó. Chính bạn cũng thừa nhận rằng từ hacker đã bị hiểu sai ở một số người. Nhưng đó đâu phải là tất cả mọi người.
Bạn ra sức chứng minh một điều ai cũng biết hacker được nhiều người nhìn nhận như là kẻ xâm nhập mạng máy tính bất hợp pháp, có phải là quá lãng phí thời gian của bạn và người đọc không? Thay vào đó, viết vài câu cho newbie biết bạn hiểu thế nào là hacker, có phải tốt hơn không?
Xin lỗi vì đã đi lạc chủ đề.
|
|
|
Hacker là lập trình viên hệ thống, xuất phát từ hệ thống có sẵn (thường có cả mã nguồn) tích hợp và cải biên hay thành những hệ thống mới.
Không lập trình không phải là hacker. Viết lại cái đã có rồi, không dựa vào hệ thống có sẵn không phải là hacker. Viết ra mà không chia xẻ sản phẩm của mình cho mọi người không phải là hacker. Chia xẻ mà không được đánh giá cao không phải là hacker.
Tìm các khe hở để khai thác, tất nhiên không phải là hacker.
|
|
|
Bổ sung cho phần 5. Windows domain qua đường hầm VPN
Giải quyết trục trặc
Thêm cách thứ ba:
c) Thêm firewall rule(s) cho phép lưu thông qua đường hầm VPN với lựa chọn Allow fragmented packets. Bạn thường chỉ cần thêm một rule duy nhất ở mục firewall, tab LAN, trước default rule. Theo cách này bạn chỉ cần chỉnh sửa ở máy gateway, không cần chỉnh sửa gì ở các máy host. Cách c) này là cách giải quyết nhanh gọn nhất.
-------------------------------------------------------------------------------------
Bổ sung cho phần 3. Đường hầm VPN
Mạng hình sao
Một mạng LAN tham gia vào VPN được gọi là một site. Muốn tạo một VPN có 3 sites trở lên, từng cặp sites đều có đường hầm nối thẳng với nhau. Cách nối này gọi là mạng lưới đủ (full-mesh topology).
Thí dụ, với 4 site A, B, C, D, để có full mesh bạn cần tạo 6 đường hầm AB, AC, AD, BC, BD, CD. Nếu thiếu đường hầm AB chẳng hạn thì A và B sẽ không thể thông với nhau.
Còn một dạng VPN khác, với một site được chọn làm trung tâm và các site còn lại (gọi là chi nhánh) chỉ có 1 đường hầm nối với site trung tâm, nhưng các chi nhánh không những thông mạng với trung tâm mà còn thông được với nhau một cách gián tiếp qua trung tâm. Cách nối này gọi là mạng hình sao (star topology).
Thí dụ, với 4 site A, B, C, D để có star bạn chỉ cần 3 tạo đường hầm AB, AC, AD. Trong đó A được chọn là site trung tâm.
Bởi đường đi qua trung tâm thường dài hơn đường nối trực tiếp giữa hai chi nhánh, mạng hình sao thường có hiệu quả thấp hơn mạng full-mesh. Nhưng mạng hình sao cần tạo ít đường hầm hơn nên cài đặt, bảo trì cũng dễ hơn.
Khi khai báo đường hầm cho mạng full-mesh, local subnet và remote subnet là hai mạng rời nhau (đã viết ở trên). Trái lại, ở đường hầm cho mạng star, local subnet và remote subnet được khai báo là hai mạng lồng nhau. Chi tiết cách làm được chỉ qua thí dụ sau đây.
Thí dụ. Trong star topology, nhánh mạng
192.168.1.0/24---192.168.1.1, 50.51.52.53---Internet---60.61.62.63, 192.168.2.1--- 192.168.2.0/24
với site bên trái là trung tâm, site bên phải là chi nhánh, được thiết lập bằng một đường hầm với tham số như sau.
Ở thiết bị bên trái (trung tâm)
local gateway = 50.51.52.53
remote gateway = 60.61.62.63
local subnet = 192.168.0.0/16
remote subnet = 192.168.2.0/24
Ở thiết bị bên phải (chi nhánh)
local gateway = 60.61.62.63
remote gateway = 50.51.52.53
local subnet = 192.168.2.0/24
remote subnet = 192.168.0.0/16
Mọi gói tin xuất phát từ chi nhánh 192.168.2.0/24 nhằm tới 192.168.27.65 chẳng hạn đều được gửi qua đường hầm tới trung tâm 192.168.1.1. Tại đây nó sẽ được vứt bỏ hoặc chuyển tới mạng 192.168.27.0/24, nếu mạng ấy tồn tại. Trường hợp mạng ấy cũng là một chi nhánh, gói tin sẽ lại được chuyển qua một đường hầm VPN.
|
|
|
NTNT nên trả lời những câu hỏi của phuchn71.
|
|
|
Phụ lục B. Cấu hình VPN
Code:
racoon.conf
path pre_shared_key "/var/etc/psk.txt";
path certificate "/var/etc";
remote 70.71.72.73 {
exchange_mode main;
my_identifier fqdn "1234.mycompany.com.vn";
certificate_type x509 "server1-signed.pem" "server1-key.pem";
peers_certfile "peer1-signed.pem";
peers_identifier address 70.71.72.73;
initial_contact on;
support_proxy on;
proposal_check obey;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method rsasig;
dh_group 2;
lifetime time 604800 secs;
}
lifetime time 604800 secs;
}
sainfo address 192.168.1.0/27 any address 192.168.3.0/27 any {
encryption_algorithm rijndael;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
pfs_group 2;
lifetime time 28800 secs;
}
remote 60.61.62.63 {
exchange_mode main;
my_identifier fqdn "1234.mycompany.com.vn";
certificate_type x509 "server2-signed.pem" "server2-key.pem";
peers_identifier address 60.61.62.63;
initial_contact on;
support_proxy on;
proposal_check obey;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method rsasig;
dh_group 5;
lifetime time 604800 secs;
}
lifetime time 604800 secs;
}
sainfo address 192.168.1.0/27 any address 192.168.2.0/27 any {
encryption_algorithm rijndael;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
pfs_group 5;
lifetime time 28800 secs;
}
SPD
192.168.1.0/24[any] 192.168.1.1[any] any
in none
spid=27 seq=5 pid=30876
refcnt=1
192.168.3.0/27[any] 192.168.1.0/27[any] any
in ipsec
esp/tunnel/70.71.72.73-50.51.52.53/unique#16402
spid=30 seq=4 pid=30876
refcnt=1
192.168.2.0/27[any] 192.168.1.0/27[any] any
in ipsec
esp/tunnel/60.61.62.63-50.51.52.53/unique#16404
spid=32 seq=3 pid=30876
refcnt=1
192.168.1.1[any] 192.168.1.0/24[any] any
out none
spid=28 seq=2 pid=30876
refcnt=1
192.168.1.0/27[any] 192.168.3.0/27[any] any
out ipsec
esp/tunnel/50.51.52.53-70.71.72.73/unique#16401
spid=29 seq=1 pid=30876
refcnt=1
192.168.1.0/27[any] 192.168.2.0/27[any] any
out ipsec
esp/tunnel/50.51.52.53-60.61.62.63/unique#16403
spid=31 seq=0 pid=30876
refcnt=1
SAD
50.51.52.53 70.71.72.73
esp mode=tunnel spi=3661296152(0xda3af218) reqid=16401(0x00004011)
E: rijndael-cbc aa568542 7e3c4a68 47334abf 2a15fc36
A: hmac-md5 47ca65a4 e0698485 9b9041f0 0a0f82fc
seq=0x00000f14 replay=4 flags=0x00000000 state=mature
created: Aug 13 18:42:08 2006 current: Aug 14 00:41:53 2006
diff: 21585(s) hard: 28800(s) soft: 23040(s)
last: Aug 14 00:41:46 2006 hard: 0(s) soft: 0(s)
current: 680448(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 3860 hard: 0 soft: 0
sadb_seq=3 pid=30878 refcnt=2
70.71.72.73 50.51.52.53
esp mode=tunnel spi=145706343(0x08af4d67) reqid=16402(0x00004012)
E: rijndael-cbc fcbc7fba 828b27a1 36415592 30c26179
A: hmac-md5 36e837c9 f772708e 5d4884cf 65014749
seq=0x00000ee2 replay=4 flags=0x00000000 state=mature
created: Aug 13 18:42:08 2006 current: Aug 14 00:41:53 2006
diff: 21585(s) hard: 28800(s) soft: 23040(s)
last: Aug 14 00:41:46 2006 hard: 0(s) soft: 0(s)
current: 748767(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 3810 hard: 0 soft: 0
sadb_seq=2 pid=30878 refcnt=1
50.51.52.53 60.61.62.63
esp mode=tunnel spi=45808782(0x02bafc8e) reqid=16403(0x00004013)
E: rijndael-cbc 818a7e9d 2115a45c f2271aff 171cecda
A: hmac-md5 9fc84bf5 8cacf00c 4cf615f4 890d9ffb
seq=0x00000289 replay=4 flags=0x00000000 state=mature
created: Aug 13 21:00:15 2006 current: Aug 14 00:41:53 2006
diff: 13298(s) hard: 28800(s) soft: 23040(s)
last: Aug 14 00:41:36 2006 hard: 0(s) soft: 0(s)
current: 160040(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 649 hard: 0 soft: 0
sadb_seq=1 pid=30878 refcnt=2
60.61.62.63 50.51.52.53
esp mode=tunnel spi=209810343(0x0c8173a7) reqid=16404(0x00004014)
E: rijndael-cbc 82d2908e 88368716 9da0d6b1 b8dac65c
A: hmac-md5 78fa014d 793d9706 1e095ae8 0d8e286f
seq=0x00000213 replay=4 flags=0x00000000 state=mature
created: Aug 13 21:00:15 2006 current: Aug 14 00:41:53 2006
diff: 13298(s) hard: 28800(s) soft: 23040(s)
last: Aug 14 00:41:36 2006 hard: 0(s) soft: 0(s)
current: 82847(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 531 hard: 0 soft: 0
sadb_seq=0 pid=30878 refcnt=1
|
|
|
Phụ lục A. Cấu hình mạng
Mọi tham số cấu hình chứa trong file config.xml. Để backup / restore toàn bộ hệ thống bạn chỉ cần backup / restore file duy nhất này.
Từ file này, m0n0wall tự động sinh ra các file cấu hình cho các chương trình ứng dụng:
resolv.conf cho dnsmasq,
dhcpd.conf cho dhcpd,
racoon.conf cho racoon, v.v.
Bạn có thể xem chi tiết tất cả các file cấu hình, cũng như trạng thái tức thời của hệ thống hiển thị trong một trang web với địa chỉ:
https://192.168.1.1/status.php
Dưới đây là vài trích đoạn từ báo cáo đó.
Code:
System uptime
12:41AM up 167 days, 22:50, 0 users, load averages: 0.00, 0.00, 0.00
Processes
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 0 0.0 0.0 0 0 ?? DLs 28Feb06 0:00.00 (swapper)
root 30865 0.0 0.9 1332 968 ?? SN 12:41AM 0:00.00 sh -c ps xauww 2>&1
root 30843 0.0 1.7 2376 1812 ?? S 12:41AM 0:00.05 /usr/local/sbin/mini_httpd -S -E...
root 30842 0.0 1.7 2376 1812 ?? S 12:41AM 0:00.00 /usr/local/sbin/mini_httpd -S -E...
root 30841 0.0 6.3 7388 6820 ?? SN 12:41AM 0:02.23 /usr/local/bin/php status.php
root 59869 0.0 1.4 1880 1568 ?? INs 28Feb06 0:02.27 /usr/local/sbin/dhcpd -cf... xl0
nobody 59864 0.0 0.8 1040 844 ?? SN 28Feb06 0:40.57 /usr/local/sbin/dnsmasq --server=...
root 59818 0.0 2.0 2504 2152 ?? INs 28Feb06 5:09.18 /usr/local/sbin/racoon -d -f ...
root 25043 0.0 0.8 1104 824 ?? IN 28Feb06 0:02.24 /usr/local/bin/msntp -r -P no -l ...
root 25042 0.0 0.9 1332 996 ?? IN 28Feb06 0:00.11 /bin/sh ...
root 252 0.0 0.7 1016 788 ?? SN 28Feb06 0:09.24 /usr/local/bin/ez-ipupdate -c ...
root 166 0.0 0.8 1336 904 ?? I 28Feb06 0:00.22 /bin/sh /etc/rc.initial console
root 157 0.0 0.8 1224 856 ?? Is 28Feb06 0:05.02 /usr/sbin/dropbear -r ... -d...
root 100 0.0 1.5 2292 1644 ?? Ss 28Feb06 12:28.75 /usr/local/sbin/mini_httpd -S -E -c...
root 97 0.0 0.7 1004 736 ?? Ss 28Feb06 14:35.56 /usr/sbin/syslogd -ss
root 88 0.0 1.1 1456 1224 ?? Ss 28Feb06 20:00.48 /sbin/ipmon...
root 77 0.0 1.0 1444 1100 ?? Is 28Feb06 0:10.13 /sbin/dhclient -nw -cf ... fxp0
root 9 0.0 0.0 0 0 ?? DL 28Feb06 1:12.24 (vnlru)
root 8 0.0 0.0 0 0 ?? DL 28Feb06 3:08.83 (syncer)
root 7 0.0 0.0 0 0 ?? DL 28Feb06 57:42.83 (bufdaemon)
root 6 0.0 0.0 0 0 ?? DL 28Feb06 0:10.76 (pagedaemon)
root 5 0.0 0.0 0 0 ?? DL 28Feb06 0:00.00 (usbtask)
root 4 0.0 0.0 0 0 ?? DL 28Feb06 0:01.64 (usb0)
root 3 0.0 0.0 0 0 ?? DL 28Feb06 0:00.00 (taskqueue)
root 2 0.0 0.0 0 0 ?? DL 28Feb06 0:00.00 (cryptoret)
root 1 0.0 0.6 1060 696 ?? ILs 28Feb06 1:05.89 /sbin/init --
root 30866 0.0 0.6 1084 676 ?? RN 12:41AM 0:00.00 ps xauww
Code:
Interfaces
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=40<POLLING>
inet 50.51.52.53 netmask 0xffffff00 broadcast 50.51.52.255
ether 00:a0:49:e1:e2:e4
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=1<RXCSUM>
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
ether 00:50:50:d8:a8:56
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
xl1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
options=1<RXCSUM>
ether 00:50:50:d8:b1:8e
media: Ethernet autoselect (none)
status: no carrier
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 50.51.52.1 UGSc 5 70117308 fxp0
50.51.52/24 link#1 UC 1 0 fxp0
50.51.52.1 00:13:11:13:b4:ad UHLW 5 67 fxp0 1199
50.51.52.53 127.0.0.1 UGHS 0 0 lo0
127.0.0.1 127.0.0.1 UH 1 0 lo0
192.168.2.10/32 192.168.1.1 UGSc 1 2 xl0
192.168.1 link#2 UC 3 0 xl0
192.168.1.1 00:50:50:d8:a8:56 UHLW 4 0 lo0
192.168.1.17 00:04:76:36:77:7c UHLW 2 161523 xl0 1141
192.168.3.16/32 192.168.1.1 UGSc 1 9145 xl0
Code:
ipfw show
50000 723957 140632208 allow ip from 192.168.1.1 to any
50001 479961 59527905 allow ip from any to 192.168.1.1
50002 8873712 726357103 queue 7 tcp from any 6881-6999 to any in via fxp0
50003 0 0 queue 7 tcp from any to any dst-port 6881-6999 in via fxp0
50004 0 0 queue 5 tcp from any 6881-6999 to any out via fxp0
50005 9107395 818207561 queue 5 tcp from any to any dst-port 6881-6999 out via fxp0
50006 0 0 queue 7 ip from any 412 to any in via fxp0
50007 0 0 queue 7 ip from any to any dst-port 412 in via fxp0
50008 0 0 queue 5 ip from any 412 to any out via fxp0
50009 0 0 queue 5 ip from any to any dst-port 412 out via fxp0
50010 2291 829355 queue 7 ip from any 1044-1045 to any in via fxp0
50011 40411 1926621 queue 7 ip from any to any dst-port 1044-1045 in via fxp0
50012 40659 2961631 queue 5 ip from any 1044-1045 to any out via fxp0
50013 2821 494679 queue 5 ip from any to any dst-port 1044-1045 out via fxp0
50014 3 792 queue 7 ip from any 1214 to any in via fxp0
50015 1091 305412 queue 7 ip from any to any dst-port 1214 in via fxp0
50016 1137 155949 queue 5 ip from any 1214 to any out via fxp0
50017 5 454 queue 5 ip from any to any dst-port 1214 out via fxp0
50018 7 348 queue 7 ip from any 2340 to any in via fxp0
50019 2139 571035 queue 7 ip from any to any dst-port 2340 in via fxp0
50020 2307 411250 queue 5 ip from any 2340 to any out via fxp0
50021 7 1034 queue 5 ip from any to any dst-port 2340 out via fxp0
50022 0 0 queue 7 ip from any 4329 to any in via fxp0
50023 283 104332 queue 7 ip from any to any dst-port 4329 in via fxp0
50024 332 26344 queue 5 ip from any 4329 to any out via fxp0
50025 0 0 queue 5 ip from any to any dst-port 4329 out via fxp0
50026 301708 14926636 queue 7 ip from any 4661-4665 to any in via fxp0
50027 33814 4297927 queue 7 ip from any to any dst-port 4661-4665 in via fxp0
50028 33517 2342698 queue 5 ip from any 4661-4665 to any out via fxp0
50029 309789 26084187 queue 5 ip from any to any dst-port 4661-4665 out via fxp0
50030 354 148622 queue 7 ip from any 5190 to any in via fxp0
50031 0 0 queue 7 ip from any to any dst-port 5190 in via fxp0
50032 0 0 queue 5 ip from any 5190 to any out via fxp0
50033 263 31657 queue 5 ip from any to any dst-port 5190 out via fxp0
50034 2449 116307 queue 7 ip from any 5500-5503 to any in via fxp0
50035 0 0 queue 7 ip from any to any dst-port 5500-5503 in via fxp0
50036 0 0 queue 5 ip from any 5500-5503 to any out via fxp0
50037 2502 167472 queue 5 ip from any to any dst-port 5500-5503 out via fxp0
50038 339938 16902251 queue 7 ip from any 6346 to any in via fxp0
50039 0 0 queue 7 ip from any to any dst-port 6346 in via fxp0
50040 0 0 queue 5 ip from any 6346 to any out via fxp0
50041 352959 37879703 queue 5 ip from any to any dst-port 6346 out via fxp0
50042 3336 346923 queue 7 ip from any 6666-6668 to any in via fxp0
50043 0 0 queue 7 ip from any to any dst-port 6666-6668 in via fxp0
50044 0 0 queue 5 ip from any 6666-6668 to any out via fxp0
50045 3461 198648 queue 5 ip from any to any dst-port 6666-6668 out via fxp0
50046 230 15112 queue 7 ip from any 6699-6701 to any in via fxp0
50047 0 0 queue 7 ip from any to any dst-port 6699-6701 in via fxp0
50048 0 0 queue 5 ip from any 6699-6701 to any out via fxp0
50049 372 49649 queue 5 ip from any to any dst-port 6699-6701 out via fxp0
50050 5 904 queue 7 ip from any 7668 to any in via fxp0
50051 0 0 queue 7 ip from any to any dst-port 7668 in via fxp0
50052 0 0 queue 5 ip from any 7668 to any out via fxp0
50053 5 519 queue 5 ip from any to any dst-port 7668 out via fxp0
50054 0 0 queue 7 ip from any 7788 to any in via fxp0
50055 0 0 queue 7 ip from any to any dst-port 7788 in via fxp0
50056 0 0 queue 5 ip from any 7788 to any out via fxp0
50057 2 182 queue 5 ip from any to any dst-port 7788 out via fxp0
50058 0 0 queue 7 ip from any 8311 to any in via fxp0
50059 0 0 queue 7 ip from any to any dst-port 8311 in via fxp0
50060 0 0 queue 5 ip from any 8311 to any out via fxp0
50061 0 0 queue 5 ip from any to any dst-port 8311 out via fxp0
50062 52795 3242968 queue 7 ip from any 8888-8889 to any in via fxp0
50063 0 0 queue 7 ip from any to any dst-port 8888-8889 in via fxp0
50064 0 0 queue 5 ip from any 8888-8889 to any out via fxp0
50065 53475 4417424 queue 5 ip from any to any dst-port 8888-8889 out via fxp0
50066 0 0 queue 7 ip from any 28864-28865 to any in via fxp0
50067 0 0 queue 7 ip from any to any dst-port 28864-28865 in via fxp0
50068 0 0 queue 5 ip from any 28864-28865 to any out via fxp0
50069 0 0 queue 5 ip from any to any dst-port 28864-28865 out via fxp0
50070 19068605 1060939020 queue 3 tcp from any to any iplen 0-80 tcpflags ack out via fxp0
50071 2339266 198780287 queue 1 ip from any to any iplen 0-100 out via fxp0
50072 426 53888 queue 1 udp from any to any dst-port 53 out via fxp0
50073 0 0 queue 1 ah from any to any out via fxp0
50074 318665 46414984 queue 1 esp from any to any out via fxp0
50075 0 0 queue 1 gre from any to any out via fxp0
50076 208 39438 queue 2 icmp from any to any out via fxp0
50077 5949458 1472340168 queue 4 ip from any to any out via fxp0
50078 30577 2307318 queue 8 icmp from any to any in via fxp0
50079 23943933 975608454 queue 8 ip from any to any iplen 0-100 in via fxp0
50080 0 0 queue 8 ah from any to any in via fxp0
50081 529415 271660772 queue 8 esp from any to any in via fxp0
50082 0 0 queue 8 gre from any to any in via fxp0
50083 2922832 3094296768 queue 6 ip from any to any in via fxp0
65535 74736589 8762863319 allow ip from any to any
Code:
ipfstat -nio
@1 pass out quick on lo0 from any to any
@2 pass out quick on xl0 proto udp from 192.168.1.1/32 port = 67 to any port = 68
@3 pass out quick on fxp0 proto udp from any port = 68 to any port = 67
@4 pass out quick on fxp0 proto udp from 50.51.52.53/32 port = 500 to any
@5 pass out quick on fxp0 proto esp from 50.51.52.53/32 to any
@6 pass out quick on fxp0 proto ah from 50.51.52.53/32 to any
@7 pass out quick on xl0 proto udp from 192.168.1.1/32 port = 500 to any
@8 pass out quick on xl0 proto esp from 192.168.1.1/32 to any
@9 pass out quick on xl0 proto ah from 192.168.1.1/32 to any
@10 pass out quick on xl0 from any to any keep state
@11 pass out quick on fxp0 from any to any keep state
@12 block out log quick from any to any
@1 pass in quick on lo0 from any to any
@2 block in log quick from any to any with short
@3 block in log quick from any to any with ipopt
@4 pass in quick on xl0 proto udp from any port = 68 to 255.255.255.255/32 port = 67
@5 pass in quick on xl0 proto udp from any port = 68 to 192.168.1.1/32 port = 67
@6 block in log quick on fxp0 from 192.168.1.0/24 to any
@7 block in log quick on fxp0 proto udp from any port = 67 to 192.168.1.0/24 port = 68
@8 pass in quick on fxp0 proto udp from any port = 67 to any port = 68
@9 skip 3 in on xl0 from 192.168.3.16/32 to any
@10 skip 2 in on xl0 from 192.168.2.10/32 to any
@11 skip 1 in on xl0 from 192.168.1.0/24 to any
@12 block in log quick on xl0 from any to any
@13 block in log quick on fxp0 from 10.0.0.0/8 to any
@14 block in log quick on fxp0 from 127.0.0.0/8 to any
@15 block in log quick on fxp0 from 172.16.0.0/12 to any
@16 block in log quick on fxp0 from 192.168.0.0/16 to any
@17 pass in quick on fxp0 proto udp from any to 50.51.52.53/32 port = 500
@18 pass in quick on fxp0 proto esp from any to 50.51.52.53/32
@19 pass in quick on fxp0 proto ah from any to 50.51.52.53/32
@20 pass in quick on xl0 proto udp from any to 192.168.1.1/32 port = 500
@21 pass in quick on xl0 proto esp from any to 192.168.1.1/32
@22 pass in quick on xl0 proto ah from any to 192.168.1.1/32
@23 skip 1 in proto tcp from any to any flags S/FSRA
@24 block in log quick proto tcp from any to any
@25 block in log quick on xl0 from any to any head 100
@1 pass in quick from 192.168.1.0/24 to 192.168.1.1/32 keep state group 100
@2 block in quick from 192.168.1.64/26 to 192.168.0.0/16 group 100
@3 block in quick from 192.168.1.128/25 to any group 100
@4 pass in quick from 192.168.1.0/24 to any keep state group 100
@26 block in log quick on fxp0 from any to any head 200
@27 block in log quick from any to any
|
|
|
(tiếp theo)
5. Windows domain qua đường hầm VPN
Với các đoạn hướng dẫn trên, bạn đã có thể dùng mọi dịch vụ IP "thông thường" như DNS, Web, scp, rsync,... giữa các mạng LAN thông nhau qua đường hầm VPN.
Nhưng với các dịch vụ của Windows, có thể còn trục trặc. Một ưu thế của site-to-site so với host-to-host VPN là admin chỉ cần thiết đặt các gateway chứ không phải cài đặt hay chỉnh sửa gì ở trên các host (mà số lượng host có thể rất nhiều!). Nhưng có điều là, Windows có thể không cho bạn may mắn với ưu thế đó.
Đoạn này hướng dẫn giải quyết một trục trặc thông thường khi vận hành Windows domain qua đường hầm VPN ở Layer 3 mà m0n0wall IPsec tunnel là một kiểu đường hầm như thế.
Trục trặc này là hoàn toàn là lỗi của Windows.
Cấu hình trục trặc:
- domain controller (DC) Windows 2000 + SP4
- workstation Windows XP pro + SP2
- Hai máy này nằm ở hai mạng LAN khác nhau thông với nhau qua đường hầm VPN.
Hiện tượng trục trặc:
1. quá trình join domain rất chậm, người dùng logon domain rất chậm, hoặc connect (map) các share dữ liệu ở DC rất chậm.
Thế nào là "chậm"? Khi cả hai gateway có băng thông uplink tối thiểu 128 kb/s và không áp dụng roaming profile hay folder wwwection cho người dùng, quá trình join/logon/connect từ máy xa qua đường hầm so với từ máy nối trực tiếp qua mạng LAN 100 mb/s có tốc độ hầu như không khác gì nhau. Nếu không đạt được như vậy thì có thể coi là "chậm". Thực tế, "cái sự chậm" (tắc mạng) ấy thể hiện rất rõ. Để nhận biết nó, bạn không cần phải dùng tới đồng hồ. Thứ thích hợp hơn có lẽ là một tách cà phê.
2. Lệnh ping qua đường hầm với độ dài payload 2048 bytes cho kết quả Request Timeout.
3. Ở máy trạm Windows XP, Application log ghi lại sự kiện
Source: SceCli
Event ID: .... (Xin lỗi, vì hiện chúng tôi không logon as admin nên không xem được event này. Sẽ bổ sung sau.)
Event Type: Error
Description: ....
4. Ở máy trạm Windows XP, Application log ghi lại sự kiện
Source: Userenv
Event ID: 1054
Event Type: Error
Description: Windows cannot obtain the domain controller name for your computer network. (The specified domain either does not exist or could not be contacted. ). Group Policy processing aborted.
5. Ở máy trạm Windows XP, User Enviroment debug log (userenv.log) có thông báo lỗi "DSGetDCName failed with 59". (Xem thêm MS KB221833 và KB910206.)
Bản chất trục trặc:
Windows ước tính băng thông mạng dựa vào trễ mạng qua lệnh ping với một gói dữ liệu lớn. Khi không ping được (bị mất gói), Windows sẽ tưởng là rớt mạng.
Giải quyết trục trặc:
Có hai cách.
a) Giảm PingBufferSize. Bạn cần đọc MS KB816045 và bạn phải có hotfix KB816045 và cài lên máy trạm Windows XP. Hotfix này có trong SP3, sắp phát hành.
b) Tắt PMTU Discovery và tắt Group Policy Slow Link Detection (bằng cách thiết đặt GroupPolicyMinTransferRate =0) trên cả DC Windows 2000 lẫn máy trạm Windows XP. Xin nhấn mạnh là tắt chứ không bật. Xem thêm MS KB120642, KB314861, KB227260, KB227369.
(-- hết --)
|
|
|
Sau đây là một trình tự cài đặt dễ chịu hơn cho máy tính PC với một ổ CD boot được và có thể truy nhập được một Web server chứa file generic-pc-xxx.img. (Xin nhắc lại, file đó là binary image của m0n0wall, với xxx là số hiệu phiên bản; hiện nay xxx = 1.22.)
Cảnh báo. Cài đặt m0n0wall vào đĩa cứng sẽ xoá sạch mọi phân vùng đĩa cứng.
1. Chuẩn bị một Linux live CD, như Knoppix, DSL (Dam* Small Linux), Puppy, Hacao,...
2. Boot máy từ live CD đó.
3. Download generic-pc-xxx.img file, cất vào /ramdisk/home/knoppix (thư mục knoppix có thể xuất hiện dưới một tên gì đó khác tuỳ theo distro của bạn)
4. Từ root shell, gõ dòng lệnh
Code:
gunzip -c /ramdisk/home/knoppix/generic-pc-xxx.img | dd of=/dev/hda bs=16k
5. Xong. Chúc bạn may mắn.
|
|
|
(tiếp theo)
4. m0n0wall với các thiết bị khác
Việc kết nối giữa hai thiết bị IPsec khác loại là một việc mệt mỏi. IPsec có nhiều tham số tuỳ biến và bạn thường phải thử nghiệm thật lâu để chọn lựa được tuỳ biến tốt nhất có trong cả hai thiết bị.
Sau đây là vài cấu hình hoạt động được.
a) m0n0wall với pfsense
pfsense www.pfsense.com) là một phần mềm VPN router nguồn mở xuất xứ từ m0n0wall, nhưng đã nâng cấp lên FreeBSD 6.1. Trong khi m0n0wall dùng ipfilter, pfsense dùng pf, bộ cản lọc gói nhanh chuyển đặt từ hệ điều hành OpenBSD. Cùng với vài tính năng khác nữa như failover, load balancing, OLSR (giao thức định tuyến mạng không dây), OpenVPN, các gói phần mềm cài thêm (squid, ntop,...) và SSH daemon, đối với một số doanh nghiệp, pfsense có thể là chọn lựa thích hợp hơn m0n0wall.
Vì pfsense xuất xứ từ m0n0wall, việc kết nối không có gì trở ngại. Thực tế, mọi hướng dẫn kết nối m0n0wall - m0n0wall đều có thể dùng cho trường hợp m0n0wall - pfsense. Hơn thế nữa, pfsense còn cho phép khai báo remote gateway bằng tên miền (thay vì địa chỉ IP), điều này có ích khi m0n0wall không có địa chỉ IP tĩnh.
b) m0n0wall với IPCop
IPCop (ipcop.org) là một phần mềm VPN router nguồn mở dựa trên Linux kernel 2.4.x, được dùng rất rộng rãi. Cũng tương tự như pfsense, IPCop với những tính năng như squid, snort, OpenVPN (gói cài thêm) có thể thích hợp hơn m0n0wall đối với một số doanh nghiệp.
Theo thử nghiệm của chúng tôi, m0n0wall đàm phán tốt với IPCop nếu dùng PSK, nhưng đàm phán thất bại khi mưu toan dùng certificate. Lý do là IPCop không hiểu và không chấp nhận danh tính của m0n0wall.
Kết nối m0n0wall - IPCop là một "ca" điển hình về bế tắc đàm phán giữa hai cài đặt IPsec khác hẳn nhau.
(Một cài đặt IPsec thường có hai phần: phần kerneland thực hiện ESP và phần userland thực hiện IKE. Các hệ thống FreeBSD như m0n0wall và pfsense dùng fast_ipsec trong kerneland và racoon trong userland. Các hệ thống Linux có thể lựa chọn netkey hoặc klips cho kerneland và lựa chọn racoon hoặc pluto cho userland. Cấu trúc klips khác xa fast_ipsec. Cấu trúc netkey khá gần với fast_ipsec. Các distro Linux 2.6.x thường dùng netkey + racoon, IPCop dùng klips + pluto. Đàm phán racoon - pluto có lẽ sẽ thành công, cả hai đều là những cài đặt IPsec có tên tuổi, nhưng đàm phán m0n0wall - IPCop hầu như thất bại vì chúng là những Web GUI chỉ cho phép vài tuỳ biến trong số nhiều tuỳ biến của racoon - pluto.)
c) m0n0wall với Planet VRT311
Planet VRT311 là một VPN router rẻ tiền (khoảng 200 USD), phần cứng và phần mềm đều là proprietary. Web GUI của nó cho phép rất nhiều tuỳ biến IPsec. (Tuy nhiên, Web GUI có nhiều lỗi nặng, khiến chúng tôi đâm ra hoài nghi về chất lượng phần mềm chung của thiết bị này.)
Đàm phán m0n0wall - VRT311 về cơ bản là khả dĩ. Hướng dẫn trong đoạn 3 vẫn dùng được cho m0n0wall - VRT311. Chỉ có những khác biệt sau:
• Trên VRT311, tắt IKE PFS (nhưng vẫn bật được ESP PFS ).
• Trên m0n0wall, phải có một bản sao certificate của VRT311.
• Certificate của m0n0wall phải có subject alternative name trùng với Identifier của nó.
• Dùng DH 1024 và RSA 1024.
Lý do. Nếu VRT311 bật IKE PFS, m0n0wall xoá hết các SA sau khi đàm phán với tư cách initiator. VRT311 không gửi certificate cho m0n0wall trong một thông điệp yêu cầu phải chứa certificate. VRT311 bỏ qua subject và chỉ dựa vào subject alternative name. DH 1024 là mức bảo mật cao nhất của VRT311.
Trên đây là ba thí dụ về m0n0wall interoperability mà bản thân chúng tôi đã có dịp trải qua. Còn vô số thí dụ khác bạn có thể tham khảo trong mail list lưu tại trang web của m0n0wall, một kho kinh nghiệm quý báu của cộng đồng người dùng phần mềm này.
(còn nữa)
|
|
|
Nếu muốn nhìn thấy tận mắt giao diện web admin của m0n0wall "in action", mời bạn xem địa chỉ sau:
http://www.monowall.procad.sk/manual/system.php
Chú ý. Trong trang web trên có mục 'OpenVPN' nhưng đó là giao diện m0n0wall phiên bản 1.2 beta 7. Việc tích hợp OpenVPN vào m0n0wall đã khởi động từ đầu năm 2005 nhưng đến nay vẫn còn chưa xong vì nhiều khó khăn kỹ thuật. Phiên bản ổn định hiện nay (1.22) không chứa OpenVPN.
|
|
|
(tiếp theo)
3. Đường hầm VPN
Ở m0n0wall, đường hầm site-to-site VPN sử dụng IPsec.
Để lập một đường hầm, bạn cần khai báo các tham số mạng và lựa chọn các tham số an ninh cho cả hai appliance ở hai đầu đường hầm.
Để xác định các tham số mạng, dễ nhất là nhìn vào hình vẽ:
192.168.1.0/24---192.168.1.1, 50.51.52.53---Internet---60.61.62.63, 192.168.2.1--- 192.168.2.0/24
(192.168.1.1, 50.51.52.53) gọi là thiết bị bên trái.
(192.168.2.1, 60.61.62.63) gọi là thiết bị bên phải.
Cả hai appliance đều kết nối VPN qua giao diện WAN.
Giải sử thiết bị bên trái là m0n0wall. Đối với nó:
50.51.52.53 gọi là local gateway.
60.61.62.63 gọi là remote gateway.
192.168.1.0/24 gọi là local subnet.
192.168.2.0/24 gọi là remote subnet.
Để ý hai subnet là rời nhau (không chứa địa chỉ nào chung). Đây là yêu cầu bắt buộc.
Đoạn này hướng dẫn m0n0wall nối thông với m0n0wall. Thiết lập m0n0wall với các thiết bị IPsec khác sẽ được trình bày ở đoạn sau. Như thế thiết bị bên phải cũng là m0n0wall. Khi đó bạn cần khai báo tham số mạng ở bên phải giống như bên trái, nhưng phải đảo chiều để cho cái-gì-local của bên trái trở thành cái-đó-remote của bên phải, và ngược lại.
Trong IPsec hai bên liên lạc là ngang hàng với nhau. Bất cứ bên nào cũng có thể là bên khởi xướng (initiator) còn bên kia sẽ là bên phúc đáp (responder) trong quá trình đàm phán. Đối chiếu với quan niệm về ứng dụng client-server thì cả hai bên đều có thể là "server", khi bên này là "server" thì bên kia là "client" và ngược lại. Điều quan trọng là có thể bạn tạo thành công đường hầm khi máy của bạn là intiator, nhưng không nhất thiết thành công khi nó ở vai trò responder.
Vì thế, khi thử nghiệm một thiết bị, bạn nên tạo tình huống thử từng trường hợp. Cách đơn giản nhất là khai báo tắt Keep Alive ở cả hai bên rồi thử ping qua đường hầm từ bên initiator.
Chú ý là đối với m0n0wall, remote gateway phải có địa chỉ IP công khai và tĩnh. Không đặt remote gateway sau NAT là để tránh rắc rối về bảo mật. Không dùng địa chỉ IP động vì m0n0wall chỉ cho phép khai báo remote gateway bằng địa chỉ IP chứ không cho phép dùng tên.
Tham số mạng chỉ có bấy nhiêu Phần còn lại của đoạn này sẽ nói về các tham số an ninh.
a) IPsec tunnel hay là IPIP over IPsec transport?
IPsec tunnel và IPIP over IPsec transport (IIPtran) là hai kiểu đường hầm có cùng định dạng gói. Vì thế chúng tương thích với nhau theo nghĩa thiết bị kiểu này có thể "nói chuyện được" (thông đường hầm) với thiết bị kiểu kia. IPsec tunnel không bắt buộc phải có (và cũng thường không có) giao diện ảo với địa chỉ IP. IIPtran có định nghĩa giao diện ảo với địa chỉ IP nên giúp dễ dàng giải quyết các vấn đề mạng như định tuyến động, cản lọc gói và điều tiết băng thông. IPsec tunnel có cơ chế kiểm soát truy nhập, chỉ cho phép gói từ local subnet đã khai báo đi vào đường hầm. IIPtran không có cơ chế này nên sau khi hình thành đường hầm, mọi gói đều có thể đi vào và việc kiểm soát truy nhập nếu cần phải được thực hiện bằng phương tiện ngoài giao thức (như tường lửa). Do IIPtran là kết hợp chồng chất của hai giao thức riêng biệt (IPIP thực hiện đường hầm và IPsec transport mã hóa), việc thực thi lệch lạc có thể dẫn đến sự cố an ninh. Sự cố có thể nhẹ như để gói lạ xâm nhập đường hầm, hay có thể rất nghiêm trọng như thả gói không mã hóa đi qua đường hầm mà người dùng không hề hay biết. (Đây cũng là vấn đề chung của mọi giao thức đường-hầm-over-IPsec-transport.) Tóm lại, trong khi trên nguyên tắc cả hai dạng đường hầm đều có thể tiện dụng và bảo mật như nhau, trên thực tế một cài đặt IIPtran thường tiện dụng hơn nhưng bảo mật thường thua một cài đặt IPsec tunnel. Cài đặt IIPtran phải cố gắng đạt tới độ bảo mật của IPsec tunnel bằng cách thực hiện thật chính xác từng giao thức và kết hợp hai giao thức thật ăn khớp. Cài đặt IPsec tunnel phải cố gắng đạt tới độ tiện dụng của IPsec transport bằng nhiều cách, kể cả cố gắng nặn ra giao diện ảo với địa chỉ IP.
Với m0n0wall, bạn không thể chọn lựa: nó chỉ cho phép IPsec tunnel.
b) Lifetime?
Khi nói đến IPsec tunnel, thực ra chúng tôi nghĩ đến ESP tunnel. ESP (Encapsulating Security Payload) là giao thức truyền dữ liệu, bao gồm cả mã hóa dữ liệu và xác thực dữ liệu. Có thể nhìn một đường hầm ESP như một kênh an toàn.
Để có chìa khóa bí mật cho ESP, hai bên dùng IKE. IKE (Internet Key Exchange) là giao thức để hai bên đàm phán, trao đổi chìa khóa, xác thực danh tính và cũng để trao đổi các thông tin tạo ra, duy trì và hủy bỏ các đường hầm trong vòng bí mật. IKE cũng dùng để tạo ra, duy trì và hủy bỏ các phiên liên lạc của chính bản thân IKE. Có thể nhìn một phiên IKE như một kênh an toàn khác.
Như vậy đàm phán IKE có hai loại, gọi là 2 phases. Phase 1 để tạo kênh IKE còn Phase 2 để tạo kênh ESP trong khuôn khổ của một kênh IKE. Khi hủy bỏ một kênh IKE, mọi kênh ESP tạo ra trong khuôn khổ của kênh ấy cũng bị hủy theo. Kênh an toàn có thể được hủy bỏ do trục trặc kỹ thuật, khởi động lại máy hay đã hết thời hạn tồn tại (lifetime). Về thời gian, các kênh ESP tồn tại song song và nối tiếp (gối đầu) nhau. Nếu bạn bật Keep alive, hai bên sẽ duy trì ít nhất 1 cặp kênh (1 thu, 1 phát) luôn sẵn sàng làm việc. Khi cặp kênh sắp hết hạn, hai bên sẽ tự động đàm phán tạo cặp kênh mới.
Mọi thông tin bí mật về một kênh an toàn, bao gồm các địa chỉ IP, tên thuật giải và quan trọng nhất là các chìa khóa mật mã, được hai bên chứa trong cái gọi là SA (Security Association). Trong thuật ngữ IPsec, SA của kênh IKE gọi là ISAKMP SA, SA của kênh ESP gọi là IPsec SA.
Lựa chọn lifetime hợp lý được khuyến cáo như sau.
Khi vận hành chính thức:
• ISAKMP SA lifetime = 24 tiếng,
• IPsec SA lifetime = 8 tiếng.
Khi thử nghiệm:
• ISAKMP SA lifetime = 20 phút,
• IPsec SA lifetime = 10 phút.
Khuyến cáo lifetime cho vận hành chính thức để duy trì độ bảo mật hợp lý đồng thời tránh nguy cơ rớt mạng khi thay đổi chìa khóa quá thường xuyên, nhưng quan trọng nhất để đảm bảo đàm phán thành công. Khi các mạng đều trong tầm kiểm soát của bạn, bạn có thể đặt cho mọi thiết bị một lifetime thống nhất nào đó khác. Chẳng hạn, khi vận hành chính thức chúng tôi thường sử dụng ISAKMP SA lifetime = 7 ngày đêm.
c) PSK hay là certificate?
Sau khi trao đổi chìa khóa, hai máy ở hai bên bước vào vòng đàm phán bí mật trong đó có một việc là đôi bên xác thực danh tính của nhau. Có hai cách xác thực là PSK và certificate (chữ ký điện tử).
PSK nhanh hơn certificate nhiều. Có thể nói là PSK "nhanh như chớp".
Nhưng PSK là một chìa khóa bí mật dùng chung nghĩa là cả hai bên cùng biết. Khi dùng certificate, mỗi bên có một chìa khóa bí mật riêng. Đối phương đứng giữa đường muốn nghe trộm cuộc liên lạc giữa hai máy A và B phải giả làm A để liên lạc với B và giả làm B để liên lạc với A. Trường hợp A, B dùng PSK, đối phương chỉ cần đột nhập được một máy (A hoặc B) là đủ lấy được PSK. Trường hợp A, B dùng certificate, đối phương phải đột nhập được vào cả hai máy A và B thì mới lấy được cả hai chìa khóa bí mật, việc này khó hơn so với trường hợp trước. Vậy certificate bảo mật hơn PSK.
Việc lựa chọn là tùy ở bạn. Tuy nhiên, kể cả khi quyết định sẽ dùng certificate bạn nên luôn luôn thử nghiệm thiết bị với PSK trước và chỉ chuyển sang thử nghiệm với certificate khi sau khi liên lạc PSK đã thông suốt. Lý do: identifier với certificate là điểm dễ bất đồng nhất trong kết nối giữa các cài đặt IPsec khác nhau.
d) Main mode, Base mode hay là Aggressive mode?
Aggressive mode nhanh nhất. Aggressive mode được dùng khi một bên (initiator, client) có địa chỉ IP biến động còn bên kia (responder, server) có địa chỉ IP tĩnh. (Khi client là một máy đơn lẻ, kết nối như thế thường gọi là road-warrior.) Aggressive mode có sai lầm nghiêm trọng về bảo mật khiến nó có thể lộ mật khi dùng với PSK. Ngay cả khi dùng certificate Aggresive mode cũng không an toàn bằng Main mode. Khi đàm phán Main mode bất thành, một vài loại appliance tự động chuyển sang Aggresive mode. Nhưng thật may mắn m0n0wall không thuộc loại đó.
Base mode không có trong m0n0wall.
Main mode an toàn nhất. Theo chúng tôi, main mode là mode duy nhất chấp nhận được để net-to-net VPN thật sự an toàn.
e) PFS hay là không PFS?
PFS (Perfect Forward Secrecy) là một lựa chọn tùy biến khi đàm phán trong khuôn khổ một ISAKMP SA để bên này yêu cầu bên kia trao đổi chìa khóa mới cho IPsec SA mới hoàn toàn độc lập với những chìa khóa đã dùng trong các IPsec SA trước đây. Như vậy, nếu bạn dùng PFS thì bảo mật sẽ rất là tốt.
Nhưng thực tế khi liên lạc giữa các cài đặt khác nhau của IPsec (và đôi khi, kể cả giữa hai máy cùng kiểu, với cùng một cài đặt!) PFS là điểm khá problematic. Đàm phán dễ thất bại khi bạn bật PFS.
Vì thế, người ta thường khuyến cáo thử nghiệm thiết bị tắt PFS trước. Chỉ khi liên lạc đã thông suốt mới bật PFS thử tiếp.
f) SHA hay là MD5?
Đây là một câu hỏi về chọn lựa thuật giải. Những câu hỏi tương tự có thể là: AES hay là 3DES? AES128 hay là AES256? RSA hay là DSA? Để chọn lựa thuật giải, cần để ý:
- Diffie-Hellman (DH) không có gì thay thế được.
- AES nhanh hơn 3DES vài lần.
- RSA nhanh hơn DSA vài lần,
- MD5 nhanh hơn SHA1 vài lần.
- Khi dùng PSK, mỗi ký tự ngẫu nhiên tương đương với khoảng 5-6 bit.
- Ở thuật giải cho phép độ dài chìa khóa tùy biến, chìa khóa càng dài, tính toán càng chậm.
- Độ bảo mật của các thuật giải (xem bảng).
Code:
Độ bảo mật (bit) Thuật giải
56 DES
80 Skipjack
96 ?
112 3DES
128 HMAC MD5, AES 128
160 HMAC SHA1
192 AES 192
256 AES 256
Độ bảo mật (bit) Thuật giải
56 DH,RSA,DSA 416
80 DH,RSA,DSA 1024
96 DH,RSA,DSA 1536
112 DH,RSA,DSA 2048
128 DH,RSA,DSA 3072
160 DH,RSA,DSA 4864
192 DH,RSA,DSA 7680
256 DH,RSA,DSA 15360
(Nguồn: hai bảng trên do bạn LTVA cung cấp)
Độ bảo mật của một hệ thống nhiều khâu bằng độ bảo mật ở khâu yếu nhất. Cái giá trả cho bảo mật cao là tiêu hao nhiều điện năng và thời gian CPU. Lựa chọn lệch với những giải thuật mạnh yếu khác nhau dẫn đến lãng phí điện năng và thời gian CPU vô ích. Để máy chạy được hiệu quả cao nhất, bạn cần chọn lựa các thuật giải có độ bảo mật đồng đều.
Như vậy, với một đường hầm với cả hai gateway ở hai đầu đều là m0n0wall, chọn lựa giải thuật hợp lý như sau.
Phase 1 dùng
• DH 1536 DH key group (mức cao nhất có ở m0n0wall),
• PSK 20 ký tự hoặc X509 certificate với RSA 2048,
• 3DES (không có chọn lựa AES cho phase 1), và
• HMAC MD5.
Phase 2 dùng
• DH 1536 PFS key group (mức cao nhất có ở m0n0wall),
• AES 128, và
• HMAC MD5.
Tuy nhiên, nhiều loại card mạng có chức năng offload IPsec có thể thực hiện các phép tính 3DES, SHA,... Với PC có những card mạng này, bạn nên chọn những thuật giải sẵn có trong phần cứng như vậy để giảm nhẹ công việc cho CPU. Việc offload IPsec là hoàn toàn tự động và bạn không có tuỳ biến nào để bật hay tắt nó trong giao diện Web của m0n0wall.
(còn nữa)
|
|
|
Tự làm VPN đơn giản với m0n0wall
Chúng tôi là người dùng Windows. Nếu có lỡ viết câu nào sai về các hệ thống *NIX, xin mọi người hãy cười và bỏ qua cho nhé.
Bài này gửi tại forum của hiệp hội hacker HVA để tỏ lòng biết ơn sâu sắc tới những *NIX hackers đã viết ra m0n0wall, một phần mềm nguồn mở hết sức hữu ích.
1. m0n0wall – đặc điểm
m0n0wall http://www.m0n0.ch/wall) là phần mềm chia xẻ Internet và kết nối VPN cho người dùng Internet đầu cuối. Là chọn lựa rất tốt khi bạn muốn:
• chia xẻ một kết nối Internet băng rộng duy nhất cho mạng LAN của mình;
• qua Internet, nối thông mạng LAN của mình với một hay nhiều mạng LAN ở xa (thường được gọi là site-to-site, net-to-net hay gateway-to-gateway VPN);
• sử dụng đồng thời dịch vụ DNS ở cả hai nơi, hay nhiều nơi (split DNS);
• thiết đặt mọi thứ qua giao diện Web; và
• một thiết bị, thường gọi là VPN router, phần cứng rẻ tiền, phần mềm miễn phí, nhưng vẫn đảm bảo ổn định, an toàn.
Có nhiều phần mềm như thế, nhưng m0n0wall nổi bật với:
• kích thước rất nhỏ (< 6 MB);
• không tiếng ồn, tiết kiệm điện (nó chỉ dùng bộ nhớ RAM, không dùng swap và tắt đĩa cứng trong khi làm việc); và
• một giao diện Web hoạt động thật nhanh nhẹn và hình thức thật dễ thương.
m0n0wall không phù hợp cho bạn (rất tiếc) nếu:
• bạn biết và thích dùng những thứ như console, command, config,... để chỉnh thiết bị;
• bạn cần một cache proxy như squid hay một IDS như snort;
• bạn có 2 hay nhiều kết nối Internet và vì thế cần giao thức định tuyến; hoặc
• bạn cần một địa chỉ IP cho kết nối VPN, qua đó có thể định tuyến, cản lọc gói, điều tiết băng thông trong mạng ảo y hệt như trong mạng thực.
2. Chia xẻ kết nối Internet
Chuẩn bị phần cứng:
• một máy tính nhúng với 200-300 MHz x86 CPU, 64 MB RAM, ít nhất 2 giao diện mạng, một cổng serial, card CF (Compact Flash) hoặc IDE flash module 16MB cắm vào IDE slot; hoặc
• một máy tính x86 PC cấu hình tương đương, có bàn phím và màn hình, tốt nhất nên chọn loại nào không dùng quạt mà chỉ dùng cánh tản nhiệt. Một ổ đĩa cứng bất kỳ có thể thay cho card CF / flash module.
Bạn có thể mua hoặc tự lắp một máy tính nhúng chỉ tiêu thụ khoảng 5 - 10W, với chi phí chừng 200 USD. (Trên thị trường, nhiều m0n0wall appliance được bán với giá gấp 2-3 lần như thế.) Máy PC (cũ) rẻ hơn nhiều, có thể rẻ đến mức... không tốn một xu, nhưng sẽ tốn điện hơn nhiều lần.
Chuẩn bị phần mềm:
• m0n0wall binary image tùy theo platform của bạn. Thí dụ nếu platform là máy PC, bạn cần download file generic-pc-xxx.img, trong đó xxx là số hiệu phiên bản m0n0wall. CF và đĩa cứng đều cùng một image.
• một phần mềm làm Certification Authority (CA). Chúng tôi thường dùng một phần mềm nguồn mở chạy trên Windows tên là XCA http://freshmeat.net/projects/xca). Đối với người dùng Linux phần mềm thích hợp có lẽ là TinyCA http://tinyca.sm-zone.net/ )
Để cài đặt và dùng m0n0wall bạn không cần phải biết một chút gì về các hệ thống *NIX nhưng xin viết thêm vài dòng tham khảo. Phiên bản m0n0wall chính thức mới nhất hiện nay là 1.22, dựa trên hệ điều hành FreeBSD 4.11. Việc chuyển đặt m0n0wall lên FreeBSD 6.1 đã diễn ra, nhưng rất chậm. Tác giả ban đầu của nó đã treo giải thưởng 1000 USD và thời hạn đến tháng 10/2006 cho người nào chuyển đặt thành công sớm nhất. Phiên bản 1.22 hiện thời chỉ hỗ trợ vài loại card mạng không dây với chip Prism. Vì thế, bài này sẽ không nói tới thiết lập điểm truy cập không dây - một chức năng sẵn có trong m0n0wall. Nếu bạn có card mạng không dây với chip Atheros, bạn có thể dùng tạm phiên bản 1.2 beta 7 dựa trên FreeBSD 5.3 hoặc 1.3 alpha 3 dựa trên FreeBSD 6.1. http://chrisbuechler.com/m0n0wall/downloads/ ). Nhưng cần chú ý rằng về hiệu suất của phần mềm hệ thống mạng (network stack), so với FreeBSD 4.x, FreeBSD 5.x chậm hơn đến 40% còn FreeBSD 6.x chậm hơn đến 20%. Ở những máy có CPU yếu, sự giảm hiệu suất đó dẫn đến giảm băng thông và nâng cấp phần mềm chưa chắc đã là một quyết định sáng suốt.
Cài đặt:
Ghi image file vào card CF hoặc đĩa cứng. Việc này tương tự như ghi .iso image vào CD. Bạn có thể dùng một tiện ích nhỏ của Windows tên là physwrite.exe (có sẵn trên Website của m0n0wall). Chi tiết xem hướng dẫn sử dụng.
Ghi xong, cắm CF / đĩa cứng vào đúng vị trí cũ. Nếu appliance là PC thì cắm màn hình, bàn phím, còn nếu là máy nhúng thì cắm một PC vào cổng serial để điều khiển (dùng Microsoft Hyperterminal). Boot máy.
Trong các giao diện mạng, chỉ định cái nào bạn chọn làm giao diện LAN và đặt cho nó một địa chỉ IP và netmask, mặc định là 192.168.1.1/24. Đây là lần duy nhất bạn dùng tới console. Từ giờ, bạn có thể rút bỏ màn hình, bàn phím (hoặc dây serial).
Cắm cổng LAN vào switch, cổng WAN vào modem. Nếu bạn dùng ADSL router thì tắt chế độ router, bật chế độ bridge để nó hoạt động như một modem.
Từ Web browser truy nhập trang điều khiển qua địa chỉ IP, tên người dùng là mặc định là admin và mật khẩu mặc định là mono.
m0n0wall boot mặc định với:
• một DHCP client nhận địa chỉ cho giao diện WAN;
• một DHCP server bật sẵn cung cấp địa chỉ IP cho mạng LAN và các địa chỉ DNS servers lấy từ nhà cung cấp dịch vụ Internet;
• một NTP client (msntp) dùng NTP server pool.ntp.org, còn bản thân m0n0wall không có dịch vụ NTP;
• NAT bật sẵn;
• DNS forwarder (dnsmasq) bật sẵn.
• bộ cản lọc gói (ipfilter) mở (thông) cho mọi kết nối hướng ra và đóng (chặn) cho mọi kết nối hướng vào;
• bộ điều tiết băng thông (traffic shaper) tắt.
Bạn có thể bật tắt, chỉnh sửa các dịch vụ nói trên theo nhu cầu thực tế.
Chú ý. Có vài việc thường làm sau khi thiết lập xong đường hầm VPN nhưng chúng tôi viết trước luôn vào đoạn này cho tiện.
1. DNS forwarder cho phép bạn sử dụng DNS của ISP cho nhu cầu giải tên thông thường, đồng thời dùng DNS server khác cho nhu cầu giải tên miền đặc biệt nào đó (thí dụ, mycompany.local.) Khi DNS server "đặc biệt" như thế được đặt ở mạng LAN xa thì bạn chỉ có thể truy nhập được qua đường hầm VPN. Nếu bạn muốn chuyển DNS query vào một DNS server ở xa xuyên qua đường hầm VPN thì chỉ chỉnh DNS forwarder thôi là không đủ; m0n0wall phục vụ cho các máy khác rất tốt nhưng khi phục vụ bản thân nó dường như "lú lẫn", cứ "đâm đầu xin chết" ở giao diện WAN. Bạn phải giúp cho nó "tỉnh ra" bằng một static route hướng vào giao diện LAN. Thí dụ, với đường hầm:
192.168.1.0/24---192.168.1.1, 50.51.52.53---Internet---60.61.62.63, 192.168.2.1---192.168.2.0/24
muốn forward DNS query từ m0n0wall (192.168.1.1, 50.51.52.53) tới DNS server 192.168.2.10 chẳng hạn, cần thiết lập static route với Destination network = 192.168.2.10/32 (hoặc 192.168.2.0/24, /25,... gì đó cũng được), Interface = LAN và Gateway = 192.168.1.1.
2. Bạn có thể cản lọc kết nối hướng ra mạng xa qua đường hầm VPN bằng luật Firewall trên giao diện LAN.
3. Bạn có thể điều tiết băng thông (thí dụ, để ưu tiên VoIP) ở kết nối hướng ra mạng xa qua đường hầm VPN bằng luật Traffic Shaper trên giao diện WAN. (Chúng tôi chưa thử điều này.)
Nếu kiểm tra thấy chia xẻ Internet tốt và mạng LAN vẫn thông bình thường như trước thì phần chia xẻ Internet coi như xong. Ta có thể bắt tay vào lập đường hầm VPN.
(còn nữa)
|
|
|
|
|
|
|