Máy chủ OpenVPN với nopool: khai báo một dải pool rõ ràng

Các công cụ trợ giúp của máy chủ cấu hình một subnet rồi lấp đầy nó bằng một pool động do chúng tự chọn. Mặc định đó tiện lợi cho đến khi một số địa chỉ phải nằm ngoài phạm vi cấp phát — dù chúng được dành cho các gán cố định hay giữ lại cho một phân đoạn trong tương lai. Chặn pool tự động và tự khai báo dải đòi hỏi hai dòng và một quyết định có chủ đích về những địa chỉ nào không dành cho cấp phát. Phần còn lại là kỷ luật vận hành: kiểm kê, áp dụng, xác minh, hoàn tác.

Đây là thay đổi trên một dịch vụ đang chạy, nên hãy coi đó là một tác vụ vận hành: kiểm kê trước, áp dụng qua vòng đời thông thường, xác minh bằng một client mới và chuẩn bị sẵn phương án hoàn tác.

Bắt đầu từ subnet bạn đã có

Đọc cấu hình máy chủ hiện tại và những địa chỉ mà client thực sự đang giữ. Thay đổi pool chỉ có ý nghĩa so với đường cơ sở đó, và đường cơ sở không phải lúc nào cũng như tệp gợi ý, vì một sản phẩm được quản lý hoặc một trình tạo cấu hình có thể là chủ sở hữu tệp bạn đang đọc.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Xác nhận topology đang có hiệu lực. Trong topology subnet, mỗi client lấy một địa chỉ từ pool; các cách bố trí net30 cũ hơn cấp một khối nhỏ cho mỗi client và phép tính hoàn toàn khác. Nếu máy chủ vẫn ở net30, trang này là hướng dẫn chuyển đổi sai và các con số của pool sẽ không mang ý nghĩa bạn mong đợi. Hãy kiểm tra dòng đó trước khi sao chép phép tính địa chỉ từ nơi khác.

Ghi lại địa chỉ của chính máy chủ, mọi gán cố định trong thư mục cấu hình client, và mọi địa chỉ mà một tuyến hoặc một quy tắc truy cập phụ thuộc vào. Đó chính là những địa chỉ phải nằm ngoài dải động. Ghi chúng trước là điều biến dải thành quyết định thay vì phỏng đoán. Nó cũng cho việc hoàn tác một thứ cụ thể để khôi phục.

Thêm nopool và khai báo dải

Từ khóa trợ giúp chấp nhận nopool, giữ nguyên cấu hình subnet và chặn pool động tự động, như hướng dẫn OpenVPN 2.6 mô tả. Sau đó dòng ifconfig-pool tường minh cung cấp dải bao gồm cả hai đầu mà bạn muốn, và netmask của nó khớp với subnet. Cả hai dòng thuộc cùng một khối máy chủ, vì một pool không có subnet của nó thì vô nghĩa. Thứ tự giữa chúng chỉ quan trọng cho việc dễ đọc, vì công cụ trợ giúp mở rộng cặp này khi dịch vụ khởi động.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Cả hai biên đều bao gồm, nên ví dụ đưa ra bảy mươi mốt địa chỉ. Giữ địa chỉ máy chủ và mọi gán cố định ngoài khoảng đó; một gán cố định rơi vào trong dải động tạo ra xung đột phụ thuộc vào thứ tự kết nối, và đó là loại tệ nhất để gỡ lỗi. Chừa một khoảng đệm giữa tập dành riêng và dải nếu các gán cố định có khả năng tăng lên.

Kích thước dải và tính đồng thời là hai giới hạn riêng biệt. Một trăm địa chỉ không có nghĩa là một trăm client đồng thời nếu max-clients nói khác, và một pool lớn hơn giới hạn đồng thời là bình thường chứ không lãng phí. Điều quan trọng là hai giới hạn được chọn có chủ đích thay vì thừa hưởng từ mặc định.

Giữ các gán cố định ngoài dải động

Một ifconfig-push riêng cho client là cơ chế khác với việc cấp phát từ pool, và nó phải dùng tham số phù hợp với topology đang hoạt động. Ở chế độ subnet, đó là một địa chỉ và netmask; mang theo một cặp net30 chỉ vì nó xuất hiện trong ví dụ cũ là lỗi phổ biến.

Lịch sử cấp phát là gợi ý, không phải thẩm quyền. Tệp persist nhớ client nào đã có địa chỉ nào, nên các client kết nối lại thường nhận được cùng địa chỉ đó, và nó không dành riêng, không giải phóng hay thay thế một gán cố định. Nếu một thiết bị cụ thể phải luôn giữ một địa chỉ cụ thể, hãy dùng gán cố định thay vì dựa vào tệp persist.

Sau đó kiểm tra những đường đi phụ thuộc vào địa chỉ. Một tuyến được đẩy tới client, một quy tắc tường lửa cho phép một subnet, hay một kiểm tra giám sát mong đợi một máy chủ cụ thể đều có thể giả định dải cũ. Thay đổi pool mà không đọc chúng sẽ chuyển sự cố đến một nơi trông có vẻ không liên quan.

Áp dụng qua vòng đời rồi xác minh

Áp dụng thay đổi theo cách dịch vụ thường nhận cấu hình — hoặc một tệp trực tiếp kèm khởi động lại, hoặc một lớp quản lý tái tạo tệp. Chỉnh sửa thủ công trên một tệp được tạo chỉ tồn tại đến lần tạo tiếp theo, và không lâu hơn. Ghi lại cơ chế nào sở hữu tệp, vì người vận hành tiếp theo sẽ cần biết nơi thực hiện cùng thay đổi đó. Sau đó khởi động lại một lần và đọc nhật ký trước khi mời một client.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Kết nối một client chưa từng kết nối và xác nhận địa chỉ nằm trong dải đã khai báo và ngoài tập dành riêng. Sau đó xác nhận đường về: client phải tiếp cận được những gì chính sách cho phép và không hơn. Một địa chỉ khớp kế hoạch nhưng không có tuyến hoạt động không phải là thay đổi thành công.

Kết nối lại một client từng giữ địa chỉ từ dải cũ. Nó phải nhận địa chỉ từ dải mới, và mọi trạng thái cấp phiên gắn với địa chỉ cũ phải biến mất. Nếu nó vẫn giữ địa chỉ cũ, thì thứ khác đang cấp địa chỉ đó và pool không phải chủ sở hữu mà bạn nghĩ.

Hoàn tác một thay đổi dải

Giữ ba dòng trước trong bản ghi thay đổi, không chỉ tệp trước. Khôi phục chúng và khởi động lại đưa việc cấp phát về hành vi cũ, và các client kết nối lại sau đó sẽ nhận địa chỉ từ đó.

Hai lưu ý thuộc về bản ghi. Các client đã kết nối khi bạn hoàn tác vẫn giữ địa chỉ hiện tại cho đến khi kết nối lại, nên hoàn tác không tức thời trên toàn bộ đội. Và nếu dải cũ chồng lấn với một gán cố định, khôi phục nó cũng khôi phục xung đột; chính sự chồng lấn đó là lý do của thay đổi, và nó cần một cách sửa khác với hoàn tác.

Một thay đổi pool hoàn tất khi một client mới nhận được địa chỉ trong dải, một địa chỉ dành riêng không bao giờ được cấp, và các tuyến cùng quy tắc dùng những địa chỉ đó vẫn hành xử đúng như dự định. Bất cứ điều gì ít hơn đều để người tiếp theo phát hiện ra điều nào trong ba điều là không đúng.