Vì sao một /24 của OpenVPN hết client sớm hơn bạn tưởng

Các pool dựng trên một /24 mà ngừng nhận client ở khoảng sáu mươi đang hành xử đúng như thiết kế, không phải chạm trần giấy phép. Dưới net30, mỗi client được cấp một liên kết điểm-điểm ảo tiêu tốn bốn địa chỉ, vì vậy một subnet 256 địa chỉ chỉ chứa được khoảng một phần tư so với điều mà tiền tố gợi ý. Con số quan trọng là số cấp phát, không phải số địa chỉ. Đọc tiền tố thành số client chính là sai lầm khiến người ta đi tìm một trần người dùng ẩn.

Hai topo, hai mô hình số học, và chỉ một trong số đó khớp với tiền tố mà mọi người vẫn giả định.

net30 tiêu tốn bốn địa chỉ cho mỗi client

net30 cấp một khối /30 cho mỗi client, vì mỗi phiên được mô hình hóa như một liên kết điểm-điểm với một địa chỉ ở mỗi đầu. Bốn địa chỉ đi vào khối đó và hai địa chỉ dùng được, nên số client hiệu dụng là một phần tư của subnet. Trên một /24, điều đó để lại 64 khối trước khi trừ khối của chính máy chủ và mọi gán tĩnh. Mức trần được báo quanh 63 là số học hiện ra, không phải một mức tối đa được cấu hình.

Máy chủ cũng cần cấp phát riêng, và các mục client tĩnh chiếm khối dù những client đó có kết nối hay không. Cả hai đều thu hẹp dải động mà không đổi tiền tố bạn đã bắt đầu.

Ranh giới pool quan trọng hơn tiền tố

Chỉ thị của máy chủ có thể định nghĩa một pool hẹp hơn subnet mà nó nêu tên, và một script hỗ trợ có thể mở rộng thành các thiết lập bổ sung không hiện trong profile bạn đã mở. Các địa chỉ cố định từ thư mục client-config nằm trong dải đó và không thể cấp hai lần. Tiền tố mô tả không gian tối đa có thể; pool hiệu dụng là thứ mà cấu hình đang chạy thực sự cung cấp.

Hãy so sánh cả hai trước khi kết luận bất cứ điều gì về dung lượng, vì một dải được cấu hình nhỏ hơn giải thích mức trần tốt như topo vậy.

Tìm giới hạn thực sự đã từ chối client

Đọc topo và pool hiệu dụng trước, rồi tính đến các gán cố định và địa chỉ dành riêng. Trước khi đổ lỗi cho không gian địa chỉ, hãy kiểm tra max-clients và mọi kiểm soát tiếp nhận ngoài OpenVPN. Cuối cùng, đối chiếu thông báo của chính máy chủ tại thời điểm từ chối với các ứng viên đó. Thông báo nêu tên ràng buộc; con số chỉ thu hẹp phạm vi.

Một lần từ chối kèm lỗi đồng thời và một lần từ chối kèm lỗi cấp phát cần cách sửa khác nhau, và đoán mò giữa hai khả năng đó chỉ làm mất một cửa sổ bảo trì.

Đổi topo thì đổi cả quy hoạch địa chỉ

Chuyển sang topo subnet cho mỗi client một địa chỉ thay vì một khối, và đó là bước đúng khi tiền tố thật sự quá nhỏ. Nó cũng đổi ý nghĩa của các tham số địa chỉ client, nên mọi gán đã ghim và mọi tệp riêng cho client phải được suy ra lại thay vì đánh số lại bằng tay. Hãy quy hoạch dải mới, chuyển các mục tĩnh và cập nhật các tuyến tham chiếu đến chúng.

Việc chuyển đổi không phải là từ đồng nghĩa của cấu hình cũ. Hãy coi đó là một thay đổi quy hoạch địa chỉ với bước xem xét riêng, và dự kiến ít nhất một client còn giữ địa chỉ từ sơ đồ trước.

Định cỡ pool từ quy hoạch, không phải từ mặt nạ

Chọn kích thước từ số client đồng thời cộng thêm dư địa cho việc kết nối lại và kiểm thử, rồi chọn tiền tố nhỏ nhất bao phủ được điều đó dưới topo đã chọn. Mở rộng lên một /16 để giải quyết trần sáu mươi client là đánh đổi vấn đề dung lượng lấy vấn đề định tuyến và chồng lấn, vì một dải riêng lớn hơn dễ đụng phải thứ mà client đã vươn tới.

Hãy ghi lại cùng lúc topo, pool, các gán cố định và trần client thu được. Khi đó câu hỏi dung lượng tiếp theo sẽ là số học thay vì một cuộc điều tra.