Một shaper tc không tự giới hạn từng khách hàng VPN

Chỉ thị nghe có vẻ trọn vẹn: giới hạn mỗi khách hàng VPN ở 20 Mbit/s. Nhưng nó không trọn vẹn, và một kỷ luật hàng đợi duy nhất trên giao diện tunnel sẽ không mang lại điều đó. Mỗi khách hàng có thể nghĩa là mỗi địa chỉ tunnel, mỗi thiết bị hoặc mỗi tài khoản, và mỗi lựa chọn phân loại gói tin theo cách khác nhau. Trước khi viết bất kỳ quy tắc nào, hãy quyết định yêu cầu thực sự gọi tên cái nào.

Mọi thứ dưới đây nói về khoảng cách giữa câu đó và một thứ hoạt động được.

«Mỗi khách hàng» trước hết phải nghĩa là gì

Địa chỉ tunnel dễ phân loại và dễ tái sử dụng. Thiết bị khó hơn, vì một tài khoản có thể mang nhiều thiết bị, và một thiết bị có thể có nhiều địa chỉ, nhất là với IPv6. Đối với chính sách công bằng, tài khoản là đơn vị có ý nghĩa nhất, và cũng khó thấy nhất trong tiêu đề gói tin. Mỗi định nghĩa hàm ý một khóa đếm riêng, nên một chính sách trôi giữa chúng sẽ không làm điều mà phần mô tả tuyên bố.

Hướng là từ còn thiếu thứ hai. Tải lên, tải xuống và kết hợp là ba yêu cầu khác nhau, và một quy tắc ra duy nhất trên một giao diện hiếm khi bao phủ cả hai đường.

Chọn một điểm mà khách hàng vẫn còn nhìn thấy

Mỗi hướng được định nghĩa so với một giao diện. Thứ rời tunnel của máy chủ về phía một khách hàng từ xa được tính là tải xuống cho khách hàng đó; thứ khách hàng gửi đi vào tunnel rồi đi ra về phía đích của nó. Chọn một điểm lập lịch cho mỗi hướng và hỏi những trường nào tồn tại ở đó. Trước NAT nguồn, tải lên vẫn mang địa chỉ bên trong của khách hàng; sau khi dịch, một phép so khớp nguồn đơn giản có thể không còn nhận ra nó.

Trên đường đã mã hóa, các tiêu đề thuộc về vận chuyển VPN, nên một bộ lọc khớp địa chỉ bên trong không có gì để khớp. Một thiết kế có thể phân loại sớm hơn và chuyển một dấu cho bộ lập lịch sau, nhưng việc chuyển giao đó phải có chủ ý: dấu gói, dấu kết nối và các lớp lập lịch là trạng thái khác nhau, không phải một giá trị được chuyển tiếp.

Các xô không tự xuất hiện

Một xô token gắn với một giao diện định hình bất kỳ lưu lượng nào dùng nó; nó không đúc một xô mới cho mỗi địa chỉ nguồn. Thiết kế dựa trên lớp thay vào đó sắp lưu lượng được chọn vào các lớp, bộ lọc quyết định tư cách thành viên, và sổ tay HTB tách tốc độ của một lớp khỏi trần của nó khi lớp cha còn băng thông. Nếu ý định là một trần cứng, hãy đặt trần và quyết định hành vi vay mượn một cách có chủ ý; đừng coi mọi con số tốc độ là mức tối đa tuyệt đối.

Khi yêu cầu là cho mỗi khách hàng, hai lần truyền chạy đồng thời nên chia sẻ một hạn mức. Cho mỗi luồng toàn bộ tốc độ là chính sách khác, và nó sống sót qua mọi bài kiểm tra chỉ nhìn một lần tải xuống.

Hai thiết bị, một tài khoản, một hạn mức?

Giới hạn riêng hai địa chỉ thiết bị không bao giờ cộng lại thành một hạn mức cấp tài khoản, ngay cả khi cả hai thiết bị đăng nhập như cùng một người. Điều tương tự áp dụng cho cả một LAN được dịch phía sau một peer, hoặc các địa chỉ IPv6 bổ sung mà bộ phân loại không bao giờ lường tới. Giữ cho liên kết giữa địa chỉ và danh tính luôn cập nhật, và nhớ rằng một địa chỉ ổn định làm đơn giản bản đồ mà không xác thực chủ sở hữu.

Cũng hãy định nghĩa hành vi burst và hàng đợi. Xô token cho phép các burst ngắn trên mức trung bình, và đệm thêm độ trễ; giới hạn phần dư và xếp nó vào hàng đợi cho sau này là những quyết định khác nhau với triệu chứng khác nhau.

Để kiểm chứng, hãy chạy hai lần truyền từ một khách hàng, thêm một khách hàng thứ hai, và đọc bộ đếm lớp theo mỗi hướng.