Địa chỉ OpenVPN cố định phải theo danh tính, không phải IP nguồn

Những kế hoạch địa chỉ nói 'máy laptop này nhận 10.90.0.10' thực ra là phát biểu về danh tính: thiết bị đã xác thực nào được giữ địa chỉ đó. IP công cộng hiện tại của thiết bị đó gần như không liên quan, vì NAT và chuyển vùng thay đổi nó mà không thay đổi việc người dùng là ai. Xây kế hoạch trên địa chỉ nguồn tạo ra các quy tắc hỏng ngay ở mạng khách sạn đầu tiên. Xây nó trên danh tính đã xác thực tạo ra một kế hoạch sống sót qua các chuyến đi.

Hãy bắt đầu từ điều máy chủ có thể kiểm chứng, rồi quyết định địa chỉ dùng để làm gì.

Chọn khóa danh tính trước địa chỉ

Mỗi thiết bị một chứng chỉ máy khách riêng cho máy chủ một khóa ổn định và có thể kiểm chứng cho từng thành viên, đây là nền tảng sạch nhất cho việc gán tĩnh. Một triển khai dùng xác thực theo từng người dùng có thể lấy tên người dùng làm khóa thay thế, miễn là việc chọn cấu hình đi theo cùng trường đó. Trộn hai mô hình tạo ra các gán khớp với chứng chỉ của một máy khách và tên người dùng của máy khác, và không ai đoán được cái nào thắng. Hãy quyết định kế hoạch dùng khóa nào trước khi viết dù chỉ một đặt trước.

Với duplicate-cn, nhiều phiên đồng thời có thể trình cùng một tên chung, nên một địa chỉ được ghim không thể nhận diện riêng từng phiên. Đó là thuộc tính của mô hình danh tính, không phải thứ mà một kế hoạch địa chỉ tốt hơn có thể sửa.

Đặt trước địa chỉ ngoài dải động

Trong một mạng có topo subnet như 10.90.0.0/24, hãy giữ các địa chỉ thấp cho thành viên có tên và đặt pool động vào một dải rời. Việc gán cho một thành viên được ghim trông như ifconfig-push 10.90.0.10 255.255.255.0 trong tệp mà máy chủ chọn cho danh tính đó. Đối số thứ hai mang nghĩa khác dưới net30, nên ví dụ này không trung lập về topo. Hãy đọc topo trước khi sao chép nó.

Việc lưu bền pool ghi lại các hợp đồng thuê gần đây và thường trả lại đúng địa chỉ cũ, đó là sự tiện lợi chứ không phải đặt trước. Đừng để tệp lưu bền trở thành hồ sơ sở hữu, vì nó thay đổi theo lịch sử kết nối chứ không theo chính sách.

Thứ tự ưu tiên gán quyết định ai thắng

Tài liệu hướng dẫn ghi một thứ tự: một gán rõ ràng được tạo trong client-connect có thể có hiệu lực trước một mục client-config-dir, đến lượt nó đứng trước việc cấp phát pool thông thường. Thứ tự đó giải thích phần lớn các báo cáo 'địa chỉ được ghim không được áp dụng'. Nó cũng có nghĩa là một bộ cấp phát động ghi cấu hình theo từng phiên có thể âm thầm ghi đè một tệp tĩnh mà bạn tưởng là có thẩm quyền.

Chọn một tầng sở hữu việc gán và để các tầng khác chỉ đọc. Hai tầng cùng nhận quyết định sẽ tạo ra các gán phụ thuộc vào thời điểm.

Bộ cấp phát động cần cùng mô hình

Một tích hợp client-connect cấp địa chỉ theo từng phiên là một bộ cấp phát nhỏ với những vấn đề thường gặp của bộ cấp phát. Nó phải kiểm chứng danh tính yêu cầu, đặt trước địa chỉ một cách nguyên tử, chỉ phát ra đầu ra được hỗ trợ cho mỗi kết nối, và giải phóng đặt trước khi ngắt kết nối hoặc thất bại. Các yêu cầu đồng thời cần khóa hoặc ràng buộc cơ sở dữ liệu, không phải trình tự đọc rồi ghi. Không có dọn dẹp, pool sẽ rò rỉ địa chỉ cho đến khi khởi động lại.

Giữ trạng thái của bộ cấp phát ở nơi người vận hành tiếp theo đọc được, và ghi log quyết định từ danh tính đến địa chỉ chứ không chỉ địa chỉ.

Quyết định xem địa chỉ là chính sách hay tiện lợi

Nếu một quy tắc tường lửa hoặc tuyến đường cho phép lưu lượng từ một địa chỉ đường hầm, thì địa chỉ đó tham gia vào chính sách truy cập và một lần gán lại sẽ thừa hưởng quyền đó. Hãy phối hợp vòng đời danh tính, địa chỉ và tường lửa, hoặc gắn quy tắc vào thứ không thể gán lại. Địa chỉ ổn định làm cấu hình dễ đọc; nó không thay thế xác thực.

Viết kế hoạch như một bản kiểm kê với chủ sở hữu cho từng mục, rồi xem lại khi một thiết bị được cho nghỉ. Đặt trước không dùng chính là cái bị tái sử dụng do nhầm lẫn.