Aruba ClearPass [Lab - 8] Cấu hình Tính sẵn sàng cao (HA)

hiep03 · Lúc 22:46:40, Chủ nhật

Cấu hình Tính sẵn sàng cao (HA)

I. Mở đầu

Trong hạ tầng mạng doanh nghiệp hiện đại, NAC đóng vai trò như “người gác cổng” kiểm soát mọi thiết bị truy cập vào hệ thống mạng, từ máy tính nhân viên, thiết bị khách đến IoT. Nếu máy chủ NAC duy nhất gặp sự cố, quá trình xác thực và cấp quyền truy cập có thể bị gián đoạn, ảnh hưởng trực tiếp đến hoạt động của doanh nghiệp.

Để khắc phục rủi ro này, Aruba ClearPass Policy Manager hỗ trợ mô hình High Availability thông qua kiến trúc Cluster. Bài viết sẽ trình bày ngắn gọn lý thuyết, kiến trúc Hub-and-Spoke và cách triển khai mô hình ClearPass HA trong môi trường lab.

II. Lý thuyết

A. KIẾN TRÚC CLUSTER VÀ CƠ CHẾ DỰ PHÒNG (HA) TRONG CLEARPASS

1. Mô hình Cluster Publisher / Subscriber (Kiến trúc Hub & Spoke)
Aruba ClearPass không sử dụng mô hình các máy chủ ngang hàng (Peer-to-Peer), mà hoạt động nghiêm ngặt theo mô hình Publisher / Subscriber (hoặc gọi là Hub / Spoke). Trong một cụm Cluster, các máy chủ sẽ được chia làm 2 vai trò riêng biệt:

Publisher (Hub - Nút gốc): Đây là máy chủ điều khiển tối cao (Master Controller) và là trung tâm cấu hình duy nhấtcủa toàn cụm.
- Bản chất: Chỉ có duy nhất một Publisher hoạt động (Active) tại một thời điểm. Nút này nắm giữ quyền Đọc và Ghi (Read/Write) vào Cơ sở dữ liệu cấu hình. Mọi thao tác của quản trị viên (tạo chính sách, thêm thiết bị mạng, đổi mật khẩu) bắt buộc phải thực hiện trên giao diện của Publisher.
Subscriber (Spoke - Nút nhánh):Đây là các máy chủ công nhân (Worker Servers).
- Bản chất: Bạn có thể có vô số Subscriber trong một cụm. Các nút này chịu trách nhiệm gánh toàn bộ tải thực tế trên mạng (xử lý các yêu cầu RADIUS/TACACS+, đưa ra quyết định cho phép thiết bị truy cập mạng). Để tối ưu tốc độ, các Subscriber chỉ có quyền Chỉ đọc (Read-only) đối với một bản sao dữ liệu cấu hình cục bộ được đồng bộ từ Publisher xuống.

2. Bản chất của Cơ chế Đồng bộ Dữ liệu (Replication)
Một sai lầm rất phổ biến là nghĩ rằng khi kết nối Cluster, mọi thứ trên con này sẽ được copy y nguyên sang con khác. Thực tế, ClearPass chia dữ liệu làm 3 loại cơ sở dữ liệu (Database) độc lập:

Configuration Database (Cơ sở dữ liệu cấu hình): Gồm tài khoản admin, chính sách xác thực, danh sách thiết bị Switch/WLC, tài khoản Guest, chứng chỉ Onboard... Đây là Database duy nhất được đồng bộ (Replication) xuyên suốt trong Cluster. Tiến trình đồng bộ này chạy ngầm và hoạt động theo cơ chế Delta-based (chỉ đẩy đi những phần dữ liệu có sự thay đổi để tiết kiệm băng thông mạng).
Log Database (Cơ sở dữ liệu Log): Chứa lịch sử truy cập (Access Tracker) và nhật ký sự kiện (Event Viewer). Database này không được đồng bộ. Con Subscriber nào xử lý xác thực cho user nào thì log sẽ nằm chết tại con Subscriber đó để tối ưu hiệu năng.
Insight Database (Cơ sở dữ liệu báo cáo): Ghi lại thông tin lịch sử dài hạn để xuất báo cáo. Dữ liệu này cũng không đồng bộ, mà được các máy chủ gửi tập trung về một nút được chỉ định làm Insight chuyên biệt.

3. Cơ chế HA (High Availability) trong ClearPass
Bản chất của cấu hình HA trong ClearPass thực chất là giải quyết 2 bài toán dự phòng độc lập:
a. HA cho tầng Quản trị (Dự phòng Publisher)
Vì hệ thống chỉ cho phép có 1 Publisher duy nhất nắm quyền Ghi (Read/Write) vào Database, nên nếu Publisher này chết, toàn bộ hệ thống sẽ rơi vào trạng thái "đóng băng cấu hình" (IT không thể sửa chính sách, lễ tân không thể tạo tài khoản Wi-Fi Guest mới).

Để xử lý việc này, ClearPass cung cấp tính năng Standby-Publisher. Bạn sẽ chỉ định một con Subscriber làm để làm một node thay thế. Bình thường nó vẫn làm Subscriber đi xác thực cho user. Nhưng khi nó phát hiện con Publisher chính bị sập (qua một khoảng thời gian mất liên lạc - Timeout), con Standby này sẽ tự động hoặc chờ kích hoạt thủ công để tự phong nó lên làm Publisher mới, chuyển database của nó từ Chỉ đọc (read) thành Đọc/Ghi (read/write) để cứu nguy cho hệ thống quản trị.

b. HA cho tầng Xác thực (Dự phòng Subscriber)
Đối với người dùng cuối, họ không quan tâm Publisher sống hay chết, họ chỉ cần thiết bị của họ kết nối được vào mạng. Trọng trách này đè lên vai các Subscriber.

Bản thân tính năng Cluster của ClearPass không tự cung cấp một địa chỉ IP ảo (VIP) tự động cho toàn cụm để người dùng kết nối. Do đó, để đạt được HA ở tầng này, các kỹ sư hệ thống phải áp dụng một trong hai cách:

Cách 1 (Cấu hình trên thiết bị mạng): Trên các thiết bị Switch/WLC, khi khai báo máy chủ RADIUS, người ta sẽ khai báo cả IP của Subscriber 1 (Primary) và IP của Subscriber 2 (Secondary). Nếu Subscriber 1 không phản hồi, Switch/WLC sẽ tự chuyển hướng yêu cầu sang Subscriber 2.
Cách 2 (Cấu hình Virtual IP - VIP của ClearPass): Gom nhóm các Subscriber chạy chung một địa chỉ IP ảo thông qua giao thức VRRP ngầm của ClearPass. Thiết bị mạng chỉ cần trỏ về IP VIP này. Nếu một con sập, con còn lại sẽ tự động gánh lấy IP VIP đó để xử lý tiếp mà mạng không bị rớt một giây nào.

B. CƠ CHẾ HOẠT ĐỘNG CỦA LICENSE TRONG CỤM CLEARPASS

Khi bạn dựng Lab ảo hoặc triển khai thực tế, việc hiểu rõ cách thức hoạt động của License trong cụm Cluster là cực kỳ quan trọng để tránh hệ thống bị mất bản quyền đột ngột:
1. License nền tảng (Platform License / CPPM VM License)

Quy tắc:Mỗi máy ảo ClearPass bắt buộc phải có một License Platform riêng.
Ý nghĩa: Đây là license định danh cho phần cứng hoặc máy ảo (VM) để hệ thống chấp nhận khởi động. Trong môi trường Lab, bạn cần xin hãng hoặc đối tác các file license Eval (Evaluation) tương ứng với số lượng VM bạn muốn dựng. Ví dụ lab có 2 con VM = Bạn cần 2 key Platform License khác nhau.

2. License tính năng (Capacity Licenses: Entry, Access, Onboard, OnGuard)

Quy tắc dùng chung cho cả hệ thống (Tập trung tại Publisher).
Ý nghĩa: Khi bạn gộp các con Subscriber vào cụm, toàn bộ các license tính năng sẽ được gộp chung lại thành một bể chứa (Shared Pool) nằm trên con Publisher. Con Publisher sẽ tự động phân phối các license này xuống cho các Subscriber dựa trên lượng tải thực tế.

LƯU Ý SỐNG CÒN KHI CẤU HÌNH HA: Khi thực hiện lệnh ghép cụm (make-subscriber), toàn bộ license hiện có trên máy ảo Subscriber đó sẽ bị xóa sạch. Để tính năng Standby-Publisher hoạt động hoàn hảo, bạn phải nhập thủ công tất cả các key tính năng (Capacity Licenses) vào CẢ HAI con (con Publisher chính và con dự phòng Standby-Publisher). Nếu con chính sập và con phụ lên thay thế mà không có sẵn các key này trên người nó, toàn bộ hệ thống sẽ bị lỗi phân phối license.

III. Mô hình

Ở mô hình này mình sẽ tận dụng mô hình ở bài Lab trước và thêm một ClearPass Subcriber vào

IV. Cấu hình

1. Đồng bộ thời gian (NTP Setup)
Trong hệ thống Cluster, nếu thời gian giữa các máy chủ lệch nhau quá 24 giờ, quá trình đồng bộ database sẽ bị lỗi hoàn toàn, thậm chí hệ thống sẽ khóa tài khoản quản trị.

Trên cả Publisher (10.0.137.20) và Subscriber (10.0.137.25), truy cập Administration > Server Manager > Server Configuration.

Chọn Set Date & Time

Tuy là 2 con đã có thời gian giống nhau nhưng mình sẽ hướng dẫn đồng bộ bằng NTP

Chọn NTP Server

Điền thông tin NTP Server

Các trường Key ID, Key Value và Algorithm chỉ được sử dụng khi cấu hình NTP có cơ chế xác thực. Trong trường hợp sử dụng NTP thông thường (không xác thực), bạn không cần khai báo các thông tin khóa xác thực này.
Save

Tương tự cho Subscriber
2. Đưa CPPM Subscriber gia nhập Cluster với vai trò Subscriber
Thực hiện qua giao diện WebUI
Administration > Server Manager > Server Configuration > Make Subscriber

Publisher IP: 10.0.137.20 (IP quản trị của Publisher).
Publisher Password: Nhập mật khẩu của tài khoản quản trị appadmin.
Tích chọn Restore the local log database after this operation (nếu muốn giữ lại log cũ).

Lưu ý: Khi máy join làm Subcriber thì cấu hình/database local trên máy đó sẽ bị thay bằng dữ liệu đồng bộ từ Publisher.
nên chọn Restore local log khi muốn giữ lại log có sẵn trước khi join và nên giữ bản backup để khôi phục nếu lỗi.

Proceed

Save

Chạy xong

Sẽ có thông báo Limited access only và có thêm Publisher trong phần Server Configuration

Bên Publisher

Các bạn có thể thực hiện nhau thông qua CLI như sau
Trên Subsciber

Mã:

cluster make-subscriber -i 10.0.137.20 -l

(Tùy chọn -l để khôi phục cơ sở dữ liệu log cục bộ)
Nhập y để xác nhận cảnh báo mất license cục bộ cũ, sau đó nhập mật khẩu appadmin của máy chủ Publisher (10.0.137.20).

3. Cấu hình Standy-Publisher (HA cho tầng Quản trị)
Trên máy Publisher
Administration > Server Manager > Server Configuration
chọn Cluster-Wide Parameters

Chuyển sang tab Standby Publisher

Cấu hình các thông số sau:

Mình sẽ cấu hình như sau

Save

4. Cấu hình Virtual IP (HA cho tầng Xác thực)

Thiết lập địa chỉ IP ảo chung 10.0.200.5 trên dải mạng dữ liệu để các thiết bị client xác thực qua Switch ArubaCX.
Trên Publisher đến Administration > Server Manager > Server Configuration > Virtual IP Settings

Các tham số cấu hình

Mình sẽ điền như sau mục đích là để cho con Publisher vừa đồng bộ cấu hình vừa tham gia xác thực trong mạng luôn

Còn Interface nào nhận RADIUS, TACACS+ thì các bạn chọn Interface đó. Của mình là Interface Data

Save

5. Cấu hình Aruba CX
Ở bài cũ mình đã cấu hình cho switch trỏ RADISUS Server về máy Publisher bây giờ sẽ cấu hình lại cho trỏ về VIP

Mã:

conf t

no radius-server host 10.0.200.20

radius-server host 10.0.200.5 key plaintext ClearPass@123

aaa group server radius CLEARPASS
    no server 10.0.200.20
    server 10.0.200.5

end
write memory