Phân tích và xử lý lỗi kết nối giữa Client và Server
Khi người dùng báo lỗi không thể kết nối vào ứng dụng qua OpenZiti, nguyên nhân thường nằm ở trạng thái của Edge Router hoặc cấu hình Tunnel. Trước tiên, hãy kiểm tra trạng thái hoạt động của các thành phần này.
Thực thi lệnh dưới đây để xem trạng thái của Controller và Edge Router. Nếu thấy trạng thái "unhealthy" hoặc "down", đây là điểm gốc của sự cố.
ziti controller status
Kết quả mong đợi: Bạn sẽ thấy danh sách các Edge Router đang online với trạng thái "healthy" và thời gian ping thấp. Nếu có router nào báo lỗi, hãy kiểm tra lại service của nó.
Kiểm tra kết nối từ phía Client
Để xác định xem lỗi nằm ở phía client hay server, hãy chạy lệnh debug trực tiếp trên máy client đang gặp sự cố. Lệnh này sẽ hiển thị chi tiết quá trình handshake và kết nối tunnel.
ziti tunnel status --debug
Kết quả mong đợi: Một bảng chi tiết hiển thị trạng thái của các tunnel. Nếu thấy trạng thái "connecting" lặp đi lặp lại hoặc lỗi "certificate verification failed", hãy chuyển sang phần xử lý chứng chỉ.
Xử lý lỗi "No route to host" hoặc "Connection refused"
Lỗi này thường xảy ra khi Edge Router không nhận được yêu cầu hoặc firewall đang chặn cổng kết nối. Hãy kiểm tra xem Edge Router có đang lắng nghe đúng cổng không.
netstat -tulpn | grep 443
Kết quả mong đợi: Bạn thấy tiến trình "ziti-edge-tunnel" hoặc "cloudflared" đang lắng nghe trên cổng 443 (hoặc cổng bạn đã cấu hình). Nếu không có gì hiển thị, service của bạn đã bị sập.
Reset và khởi động lại Tunnel
Nếu trạng thái tunnel bị treo, cách nhanh nhất là buộc client ngắt kết nối và thiết lập lại. Điều này giúp đồng bộ lại các tham số kết nối với Edge Router.
ziti tunnel stop && ziti tunnel start
Kết quả mong đợi: Terminal hiển thị thông báo "Tunnel stopped" sau đó là "Tunnel started" kèm theo địa chỉ IP của tunnel đã được gán lại.
Giải quyết vấn đề chứng chỉ SSL/TLS hết hạn hoặc không khớp
Trong môi trường Zero-Trust, chứng chỉ (Certificate) là yếu tố then chốt. Nếu chứng chỉ hết hạn hoặc không khớp với Common Name (CN), kết nối sẽ bị từ chối ngay lập tức. OpenZiti tự động quản lý chứng chỉ, nhưng đôi khi cần can thiệp thủ công.
Kiểm tra thời hạn chứng chỉ của Edge Router
Truy cập vào server chứa Edge Router và kiểm tra file chứng chỉ đang sử dụng. Đường dẫn mặc định thường nằm trong thư mục cấu hình của OpenZiti.
openssl x509 -in /etc/ziti/edge/ca.crt -noout -dates
Kết quả mong đợi: Bạn thấy dòng "notAfter" hiển thị ngày hết hạn. Nếu ngày này đã qua, bạn cần tạo lại chứng chỉ hoặc gia hạn qua Controller.
Tạo lại chứng chỉ cho Client khi hết hạn
Khi client bị lỗi "certificate expired", bạn không cần cấu hình lại toàn bộ server. Chỉ cần xóa file config cũ và generate lại trên client.
rm -rf ~/.ziti && ziti tunnel start
Kết quả mong đợi: OpenZiti sẽ tự động liên hệ với Controller để tải về bộ chứng chỉ mới và cấu hình lại tunnel. Client sẽ kết nối thành công.
Xử lý lỗi "Common Name mismatch" với Cloudflare Tunnel
Khi sử dụng Cloudflare Access, lỗi này xảy ra khi tên miền trong chứng chỉ không khớp với tên miền người dùng đang truy cập. Hãy kiểm tra file cấu hình của Cloudflare Tunnel.
cat /etc/cloudflared/config.yml
Kết quả mong đợi: Kiểm tra phần "hostname" hoặc "domain". Nếu bạn đang dùng wildcard, hãy đảm bảo cấu hình đúng. Nếu không, hãy chỉnh sửa lại tên miền trong file config và khởi động lại service.
systemctl restart cloudflared
Kết quả mong đợi: Service Cloudflare Tunnel khởi động lại và bắt đầu lắng nghe yêu cầu với chứng chỉ mới.
Tối ưu hiệu năng mạng qua OpenZiti và Cloudflare Tunnel
Trong môi trường doanh nghiệp, độ trễ (latency) và băng thông (throughput) là yếu tố sống còn. Mặc định, OpenZiti và Cloudflare có thể không được tối ưu cho tải cao. Chúng ta sẽ điều chỉnh các tham số để đạt hiệu suất tốt nhất.
Tăng số lượng kết nối đồng thời cho Edge Router
Mặc định, Edge Router giới hạn số lượng kết nối đồng thời để tránh quá tải. Để tăng thông lượng, hãy chỉnh sửa file cấu hình của Edge Router.
Truy cập file cấu hình tại đường dẫn đầy đủ: /etc/ziti/edge/config.yaml
vi /etc/ziti/edge/config.yaml
Sửa phần maxConnections (hoặc tham số tương đương trong phiên bản mới) thành giá trị cao hơn, ví dụ 10000. Lưu file và khởi động lại service.
systemctl restart ziti-edge-tunnel
Kết quả mong đợi: Server có thể xử lý nhiều kết nối đồng thời hơn mà không bị từ chối (Refused).
Điều chỉnh MTU cho OpenZiti Tunnel
OpenZiti đóng gói gói tin (packet encapsulation), điều này làm tăng kích thước header và có thể gây ra lỗi phân mảnh nếu MTU quá lớn. Hãy giảm MTU để tối ưu tốc độ truyền tải.
ip link set dev ziti0 mtu 1300
Kết quả mong đợi: Giao diện mạng ảo ziti0 được đặt MTU xuống 1300 bytes, giảm thiểu tình trạng mất gói tin (packet loss) khi truyền qua nhiều tầng mạng.
Tối ưu Cloudflare Tunnel với mode "No SSL"
Nếu bạn đã sử dụng OpenZiti để mã hóa end-to-end, việc Cloudflare Tunnel mã hóa thêm một lớp (SSL/TLS) là dư thừa và gây tốn tài nguyên CPU. Hãy cấu hình để Cloudflare chỉ đóng vai trò proxy thuần túy.
Chỉnh sửa file cấu hình tại: /etc/cloudflared/config.yml
inlets:
- address: "auto"
port: 443
protocol: "http"
noSSL: true
Kết quả mong đợi: Cloudflare Tunnel giảm tải CPU đáng kể vì không thực hiện quá trình handshake SSL/TLS, chỉ chuyển tiếp gói tin đã được OpenZiti mã hóa.
Cấu hình chính sách truy cập phức tạp (Attribute-based Access Control)
Để kiểm soát truy cập chặt chẽ hơn, chúng ta sử dụng ABAC (Attribute-Based Access Control) qua Cloudflare Access và tích hợp với OpenZiti. Điều này cho phép bạn cấp quyền dựa trên vai trò, nhóm, hoặc địa chỉ IP động.
Thiết lập Policy trong Cloudflare Access
Truy cập bảng điều khiển Cloudflare Access -> Applications -> Chọn ứng dụng -> Policies. Tại đây, bạn có thể tạo các điều kiện logic phức tạp.
Ví dụ: Chỉ cho phép nhóm "Developers" truy cập vào "Staging" vào giờ hành chính.
Condition:
AND (
(Group contains "Developers"),
(Time is between "08:00" and "18:00"),
(Region equals "Vietnam")
)
Kết quả mong đợi: Policy được lưu thành công. Khi người dùng thuộc nhóm Developers truy cập ngoài giờ hoặc từ nước ngoài, họ sẽ bị chặn ngay tại Cloudflare.
Tích hợp Claim vào OpenZiti Identity
Để OpenZiti nhận diện các attribute từ Cloudflare, bạn cần cấu hình Identity của OpenZiti để chấp nhận các claims từ IdP (Identity Provider). Điều này thực hiện trong file cấu hình của Controller.
Truy cập file: /etc/ziti/controller/config.yaml
authenticators:
- type: "oidc"
config:
providerUrl: "https://your-cloudflare-idp.com"
clientSecret: "your-secret"
claimMapping:
role: "groups"
department: "department"
Kết quả mong đợi: Khi người dùng đăng nhập, OpenZiti sẽ trích xuất các trường "role" và "department" từ token OIDC của Cloudflare để áp dụng chính sách nội bộ.
Áp dụng Policy dựa trên Claim trong OpenZiti
Sau khi mapping claim, hãy tạo Policy trong OpenZiti Controller để lọc truy cập dựa trên các claim đó.
ziti controller create-policy --name "dev-access" --identity "dev-identity" --service "staging-app" --role "Developers"
Kết quả mong đợi: Chỉ những identity có role "Developers" mới có thể kết nối đến service "staging-app" thông qua tunnel OpenZiti.
Mẹo bảo mật nâng cao: Hardening VM Proxmox và Isolation mạng
Để đảm bảo nền tảng Zero-Trust thực sự an toàn, môi trường chứa các thành phần này (Proxmox) cần được "làm cứng" (hardening) và cách ly hoàn toàn khỏi mạng công ty thông thường.
Cấu hình Network Isolation cho VM OpenZiti
Không bao giờ cho phép truy cập trực tiếp từ mạng LAN công ty vào VM chứa OpenZiti Controller hay Edge Router. Hãy tạo một mạng riêng biệt (VLAN) chỉ dành cho Zero-Trust.
Trong Proxmox Web UI, vào VM Settings -> Hardware -> Network Device. Chọn Bridge Mode và chỉ định VLAN tag riêng biệt (ví dụ VLAN 100).
qm set 100 --net0 virtio,bridge=vmbr0,tag=100
Kết quả mong đợi: VM chỉ có thể giao tiếp với các thiết bị cùng VLAN 100 hoặc qua Gateway đã cấu hình. Không thể ping trực tiếp từ mạng quản trị Proxmox vào VM này.
Hardening Kernel Parameters trên VM Linux
Chặn các tính năng không cần thiết của Kernel để giảm diện tích tấn công. Tạo file cấu hình sysctl mới cho VM.
Tạo file tại: /etc/sysctl.d/99-zero-trust-hardening.conf
# Disable IP forwarding
net.ipv4.ip_forward = 0
# Disable ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
# Enable SYN Cookies to prevent SYN Flood
net.ipv4.tcp_syncookies = 1
# Disable Source Routing
net.ipv4.conf.all.accept_source_route = 0
Áp dụng cấu hình ngay lập tức:
sysctl --system
Kết quả mong đợi: Các tham số bảo mật được kích hoạt. Hệ thống sẽ tự động chặn các gói tin ICMP redirect và từ chối các gói tin có source route giả mạo.
Áp dụng AppArmor Profile cho OpenZiti
Giới hạn quyền của tiến trình OpenZiti chỉ được truy cập vào các file và cổng cần thiết. Nếu bị xâm nhập, attacker không thể leo cao (privilege escalation).
Tạo file profile tại: /etc/apparmor.d/local/usr.sbin.ziti-edge-tunnel
/usr/sbin/ziti-edge-tunnel {
# Allow network access
network inet stream,
network inet6 stream,
# Allow read/write to config dir
/etc/ziti/edge/** rw,
# Allow read to system dirs
/etc/ssl/certs/** r,
# Deny everything else
deny /,
}
Khởi động lại AppArmor để áp dụng profile:
systemctl restart apparmor
Kết quả mong đợi: Nếu ziti-edge-tunnel cố gắng truy cập file ngoài vùng cho phép, hành động đó sẽ bị chặn và ghi vào log (thường ở /var/log/syslog).
Điều hướng series:
Mục lục: Series: Series: Xây dựng nền tảng Zero-Trust Network cho doanh nghiệp với OpenZiti, Cloudflare Access và Identity-aware Proxy trên hạ tầng Proxmox
« Phần 8: Chiến lược Backup, High Availability và Disaster Recovery