Hạn mức dữ liệu hàng tháng nên thuộc về đâu theo mỗi tài khoản OpenVPN

Một hạn mức bị đặt lại mỗi khi đường hầm kết nối lại không phải là giới hạn, và đó chính là thứ bạn nhận được khi một bộ đếm byte được gắn vào máy chủ VPN mà không có chỗ lưu trạng thái bền vững. Bộ đếm thuộc về một phiên; hạn mức thuộc về một người hoặc một hợp đồng thiết bị. Mọi khó khăn của tính năng này đến từ sự lệch pha đó, nên các kiểm tra dưới đây nói về nơi trạng thái sống và lớp nào được phép quyết định.

Gắn hạn mức vào tài khoản, không phải vào đường hầm

Bắt đầu bằng việc đặt tên cho chủ thể của hạn mức. Một người có thể giữ ba chứng chỉ thiết bị, và không chứng chỉ nào nên nhận một ngân sách hàng tháng độc lập chỉ vì chúng xác thực riêng lẻ. Một định danh tài khoản ổn định sống sót qua các lần kết nối lại, địa chỉ đường hầm mới và việc chuyển sang cổng thứ hai là mỏ neo duy nhất mà hạn mức có thể dùng. Tên chung của chứng chỉ chỉ đóng vai trò khóa đó khi chính sách cấp phát của bạn bảo đảm một tài khoản cho mỗi tên.

Địa chỉ đường hầm được cấp không bao giờ là câu trả lời. Địa chỉ được tái sử dụng, các nhóm được chia sẻ, và cùng một tài khoản có thể xuất hiện hai lần trên hai cổng trong cùng một phút. Nếu sổ cái khóa theo địa chỉ, ngắt kết nối rồi nối lại là đủ để đổ đầy bình chứa.

Ghi đủ cho mỗi phiên để phép tính có thể kiểm toán: tài khoản, kỳ thanh toán, phiên bản cổng, định danh phiên, các bộ đếm được quan sát lần cuối và tổng đã cam kết. Đưa thế hệ khởi động của daemon vào định danh phiên, vì máy chủ khởi động lại dùng lại ID máy khách và một phép khớp ngây thơ sẽ thừa hưởng đường cơ sở trước đó.

Ấn định đơn vị, hướng và ranh giới đặt lại

Bốn định nghĩa phải được ấn định bằng văn bản trước khi bất kỳ việc thu thập nào bắt đầu. Hạn mức có tính byte máy khách gửi, byte máy khách nhận, hay tổng của cả hai? Một gigabyte là 10^9 byte hay 2^30? Kỳ hạn quay vòng vào giờ địa phương nào và ở múi giờ nào? Và bộ đếm đo chính xác cái gì, khi mà phần chi phí phụ của đường hầm và các lần truyền lại được tính còn kích thước tệp ứng dụng và hóa đơn của nhà cung cấp thì không?

Không lựa chọn nào trong số đó là sai, nhưng cách triển khai và con số khách hàng nhìn thấy phải khớp nhau. Hai nửa của cùng một hệ thống không đồng ý về GiB, hoặc về việc quay vòng xảy ra lúc nửa đêm UTC thay vì giờ địa phương, sẽ tạo ra đúng loại phiếu yêu cầu làm xói mòn niềm tin vào toàn bộ hạn mức.

Biến tổng byte thành một chênh lệch được tính một lần

Giao diện quản lý báo cáo các dòng BYTECOUNT_CLI định kỳ mang ID máy khách cùng tổng byte tích lũy theo mỗi hướng, và lệnh bytecount quy định tần suất chúng đến. Từ góc nhìn của máy chủ, con số nhận được đếm số byte máy khách đã gửi và con số gửi đi đếm số byte đã chuyển đến nó. Đặt khoảng thời gian thành thứ mà sổ cái có thể hấp thụ; khoảng quá ngắn mua lấy độ chính xác mà bạn thực sự không có được.

Một ràng buộc định hình toàn bộ thiết kế: socket quản lý chỉ chấp nhận một kết nối điều khiển duy nhất. Một bộ xuất giám sát, một GUI và bộ điều khiển của bạn không thể mỗi bên mở kết nối riêng. Hãy quyết định tiến trình nào sở hữu kênh và để những bên khác đọc trạng thái từ đó, vì giao diện này trao các hành động quản trị và dù sao cũng không nên lộ ra ngoài máy chủ.

rx_delta = sample.rx_now - session.prev_rx
tx_delta = sample.tx_now - session.prev_tx
charge  = rx_delta + tx_delta
# same transaction:
ledger.total += charge
session.prev_rx, session.prev_tx = sample.rx_now, sample.tx_now

Cam kết các đường cơ sở mới và mức tăng sử dụng cùng lúc, để việc phát lại một mẫu không tính gì thay vì tính hai lần. Một bộ đếm đi lùi là tín hiệu, không phải món nợ: nó nghĩa là phiên đã bị thay thế hoặc daemon đã khởi động lại, và phản ứng đúng là đối soát định danh phiên chứ không phải ghi có một khoản âm.

Đường ngắt kết nối cũng cần sự cẩn trọng như vậy. Nếu một sự kiện cuối mang tổng cuối phiên, chỉ tính phần chênh lệch so với mẫu đã cam kết gần nhất. Cộng toàn bộ tổng sau khi việc lấy mẫu định kỳ đã được tính là kiểu tính trùng phổ biến nhất trong các hệ thống hạn mức tự chế. Các phiên vắt qua ranh giới kỳ hạn cũng cần một quy tắc, vì một tổng cuối duy nhất không mang thông tin về việc các byte đã vượt qua nửa đêm khi nào.

Việc cạn hạn mức phải từ chối truy cập, không chỉ giết đường hầm

Khi một tài khoản đạt giới hạn, hai việc phải xảy ra: các phiên hiện có kết thúc và các phiên mới bị từ chối. Giao thức quản lý cung cấp client-kill theo ID máy khách, xử lý nửa đầu miễn là bạn liệt kê mọi phiên còn sống của tài khoản thay vì giết đúng địa chỉ duy nhất mà bạn tình cờ để ý.

Nửa sau là nơi các thiết kế hạn mức thất bại. Chỉ giết thôi là một cuộc đua với vòng kết nối lại của máy khách, vòng này sẽ vui vẻ quay lại sau vài giây. Việc chấp nhận phải tham chiếu sổ cái chia sẻ, và trong một triển khai nhiều cổng, kiểm tra đó không thể là một tệp trên từng máy. Mọi phiên bản có thể chấp nhận đăng nhập đều phải thấy cùng một trạng thái đã cạn.

Các lần kết nối lại dựa trên token xứng đáng có bài kiểm tra riêng. OpenVPN 2.6 có thể xác thực token phiên ở bên trong bằng auth-gen-token, bỏ qua lời gọi xác thực bên ngoài mà bộ điều khiển của bạn dùng để thực thi mức trần. Vì vậy một token còn hiệu lực chứng minh danh tính, không phải hạn mức còn lại, và mọi phiên bản máy khách mới vẫn phải tham chiếu sổ cái. Nếu thay vào đó bạn bật management-client-auth, bộ điều khiển trở thành bên xác thực và thừa hưởng nghĩa vụ tự phân tích trạng thái phiên và từ chối các token hết hạn hoặc không hợp lệ.

Chấp nhận mức vượt mà việc lấy mẫu tạo ra

Quan sát định kỳ cộng với ngắt kết nối cho bạn một hạn mức được lấy mẫu với dung sai đã biết. Một máy khách có thể vượt khoảng một khoảng báo cáo cộng với thời gian bộ điều khiển cần để hành động, và các phiên đồng thời trên một tài khoản nhân cửa sổ đó lên. Hãy nói điều đó trong giao diện thay vì quảng cáo một mốc cắt chính xác ở byte cuối mà bạn không thể cung cấp.

Một mức trần cứng thực sự là một bài toán kỹ thuật khác: thực thi bên trong đường chuyển tiếp, gắn với cùng một tài khoản xuyên suốt các phiên. Đọc bộ đếm nhanh hơn không phải là cùng một việc, và nó không chịu nổi một máy khách chỉ đơn giản mở thêm đường hầm.

Trước khi triển khai, hãy chạy các ca chấp nhận làm hỏng những cách triển khai ngây thơ: kết nối lại lặp đi lặp lại, hai thiết bị cùng lúc, khởi động lại bộ điều khiển và cổng, một sự kiện ngắt kết nối bị mất, quay vòng giữa phiên và một lần thử kết nối lại bằng token ngay sau khi cạn hạn mức. Sau đó quyết định chế độ hỏng cho các gián đoạn kế toán. Một sổ cái bền vững bảo vệ mức dùng bạn đã ghi; nó không thể làm sống lại những quan sát chưa từng đến, và khách hàng xứng đáng biết mình đang ở tình huống nào trong hai tình huống đó.