Nhật ký triển khai thực chiến: BACnet/SC + RC-RemoteAccess tại Bệnh viện Tư nhân Đà Nẵng (tình huống giả định)

Đây là tình huống giả định hoàn toàn, được dựng lên để mô tả quy trình kỹ thuật. Không có bệnh viện thật nào ở Đà Nẵng đang chạy giải pháp này theo mô tả dưới đây.

Mở đầu

Bệnh viện tư nhân 250 giường tại Đà Nẵng đang vận hành hệ thống BMS cũ dựa trên BACnet/IP thuần (cổng 47808), chủ yếu điều khiển HVAC và một số tủ điện chiếu sáng. Bệnh viện mong muốn mở truy cập từ xa cho nhà cung cấp nước ngoài mà không cần mở VPN truyền thống. Giải pháp được lựa chọn là BACnet Secure Connect (BACnet/SC) kết hợp RC-RemoteAccess vì hai lý do chính: mã hóa end-to-end ngay từ lớp ứng dụng BACnet và khả năng hoạt động mà không cần port forwarding, hỗ trợ đường truyền 4G dự phòng.

Nhật ký ngày 1–3 – Khảo sát hiện trạng

Quá trình quét mạng bằng Wireshark và script bacnet-scan phát hiện 47 thiết bị BACnet/IP. Trong đó, 12 thiết bị sử dụng địa chỉ IP tĩnh, số còn lại lấy DHCP từ switch Layer-2. Toàn bộ VLAN BMS đang lộ ra internet qua rule port-forward 47808 trên firewall FortiGate.

Rủi ro lộ dữ liệu rất rõ ràng: bất kỳ ai quét cổng 47808 từ bên ngoài đều có thể thu thập lưu lượng Who-Is/I-Am. Một số thiết bị vẫn còn dùng mật khẩu mặc định cho lệnh WriteProperty. Ghi chú thực tế: “Mở cổng 47808 lúc này cũng nguy hiểm như để cửa hông bệnh viện không khóa.”

Nhật ký ngày 4–7 – Cấu hình BACnet/SC Hub và RC-RemoteAccess

BACnet/SC Hub được cài đặt trên máy ảo Ubuntu 22.04 đặt trong DMZ. Hệ thống sử dụng TLS 1.3 với chứng chỉ X.509 dài hạn do CA nội bộ bệnh viện ký và short-lived token 5 phút để giảm bề mặt tấn công. Mô hình Hub-and-Spoke được chọn vì mạng bệnh viện có NAT nghiêm ngặt và nhiều thiết bị nằm sau firewall không cho phép kết nối inbound.

Node ID được gán theo chuẩn: urn:bacnet:sc:node:HVAC-01, urn:bacnet:sc:node:Lighting-03… Mỗi thiết bị cần cấu hình object “Secure Connect” với Hub URI và certificate fingerprint. Thiết bị cũ không hỗ trợ native BACnet/SC phải chạy qua BACnet/SC Router.

RC-RemoteAccess được cài trên cả Hub và các node, sử dụng mDNS để quảng bá dịch vụ trong LAN và ICE để đàm phán đường kết nối hai chiều qua IPv6. Khi chạy trên đường 4G dự phòng (v4 CGNAT), ICE thường gặp vấn đề ở giai đoạn “candidate gathering”, do đó cần thêm TURN server dự phòng.

Lỗi thường gặp nhất là “Invalid Connect Token”, chủ yếu do đồng hồ lệch hơn 30 giây hoặc chuỗi chứng chỉ thiếu intermediate CA. Giải pháp là đồng bộ NTP bắt buộc và cài đặt lại toàn bộ chuỗi chứng chỉ.

Nhật ký ngày 8–10 – Kiểm thử thực tế

Traffic BACnet/SC xuất hiện dưới dạng TLS 1.3 Application Data, không còn thấy NPDU rõ ràng. Độ trễ trung bình trong LAN là 38 ms, tăng lên 180–240 ms khi chuyển sang 4G dự phòng. Tỷ lệ mất gói 3–4% khiến một số lệnh WriteProperty bị timeout.

Thử nghiệm failover cho thấy khi Hub tắt trong 45 giây, các node chuyển sang trạng thái “Reconnect” và tự động thử lại sau 10 giây. Sau khi Hub khôi phục, toàn bộ node kết nối lại trong vòng 22 giây.

Nhật ký ngày 11–14 – Vận hành và giám sát

Logrotate được cấu hình với thời gian lưu trữ 14 ngày và nén gzip. Script giám sát kiểm tra hạn chứng chỉ và gửi cảnh báo Telegram khi còn 30 ngày. Hệ thống tích hợp với BMS hiện có qua BACnet/SC Router nên các phần mềm giám sát cũ như Desigo, Niagara không cần thay đổi.

Vấn đề còn tồn tại là một số thiết bị cũ không chịu nổi overhead TLS 1.3 + RC-RemoteAccess, khiến CPU tăng 18–25%. Đường 4G dự phòng cũng dễ bị nhà mạng hạn chế khi lưu lượng liên tục.

Nhận xét thẳng thắn

Giải pháp BACnet/SC + RC-RemoteAccess về mặt kỹ thuật là ổn định, nhưng tại Việt Nam năm 2025 vẫn còn xa thực tế. Hầu hết bệnh viện tư nhân thiếu nhân sự hiểu rõ vòng đời chứng chỉ hay khắc phục sự cố ICE. Đường truyền 4G dự phòng yếu và không ổn định. Nếu không có ngân sách cho leased line hoặc Starlink dự phòng, giải pháp dễ rơi vào tình trạng “chạy được vài tháng rồi phải quay lại dùng VPN cũ”.