DNS của OpenVPN còn sót lại sau SIGKILL: kiểm tra chủ sở hữu trước

DNS ngừng phân giải sau khi một máy khách OpenVPN bị giết, và phản xạ đầu tiên là viết lại /etc/resolv.conf. Thay đổi đó có thể làm hỏng một trình phân giải đang hoạt động trong khi trạng thái cũ thực sự nằm ở nơi khác. Câu hỏi cần giải quyết trước là ai sở hữu các thiết lập DNS mà đường hầm đã cài, và liệu việc thoát bỏ qua dọn dẹp có thực sự quan trọng không.

Ba điều kiện quyết định việc sửa: tín hiệu đã kết thúc tiến trình, thành phần trình phân giải đã nhận thiết lập, và liên kết đường hầm còn tồn tại hay không. Trả lời theo thứ tự đó và cách sửa thường đến mà không cần chạm vào tệp toàn cục.

Xác định loại thoát đã xảy ra

Trong bản Community của OpenVPN, cả SIGINT và SIGTERM đều là yêu cầu thoát êm. Không thể bắt SIGKILL: không thể chặn hay xử lý nó, nên không thủ tục tắt máy nào có cơ hội chạy. Ctrl+C bình thường trong một terminal ở tiền cảnh tạo SIGINT, còn một giám sát từ bỏ việc chờ thường leo thang lên SIGKILL. Sự khác biệt quan trọng vì chỉ trường hợp thứ hai đảm bảo các hook đã bị bỏ qua.

Chạy bên trong screen hay tmux không thay đổi tín hiệu mà Ctrl+C gửi. Hãy kiểm tra những gì tiến trình thực sự nhận, không phải những gì terminal thường làm.

Khi một dịch vụ hoặc trình quản lý kết nối chạy đường hầm, hãy dừng đúng kết nối đó qua chủ sở hữu của nó thay vì giết pid. Trình quản lý có thể dựng lại tiến trình, để bạn với một đường hầm mới và trạng thái trình phân giải rối rắm. Một tiến trình độc lập chỉ cần một yêu cầu kết thúc thông thường để việc dọn dẹp chạy.

Xác định ai sở hữu trình phân giải

systemd-resolved, một script kiểu resolvconf và việc ghi lại tệp đơn giản là ba chủ sở hữu khác nhau. Cái đầu giữ thiết lập theo liên kết trong bộ nhớ và bỏ chúng khi giao diện biến mất. Cái thứ hai giữ bản ghi tồn tại cho đến khi có thứ gì xóa chúng. Cái thứ ba ghi một tệp và để việc khôi phục cho người đã ghi nó.

Xác định chủ sở hữu trước khi chọn lệnh sửa. Cùng một triệu chứng có ba câu trả lời đúng khác nhau tùy theo cái nào đang được dùng.

Một VPN do NetworkManager quản lý có thể đã sở hữu các thay đổi trình phân giải. Thêm một trình trợ giúp thứ hai lên trên tạo ra hai chủ sở hữu tranh nhau cùng một liên kết, và trạng thái của bên thua lại xuất hiện ở lần kết nối lại tiếp theo. Nếu một trình quản lý phụ trách, sửa thiết lập trong trình quản lý chứ không phải trong script.

Hook down có thể và không thể làm gì

Script down chạy một lần sau khi thiết bị TUN/TAP đã đóng. Thêm down-pre đảo ngược thứ tự đó và chạy script khi thiết bị vẫn còn tồn tại, điều mà các trợ giúp cần liên kết sống yêu cầu.

Không chỉ thị nào khiến một hook chạy sau SIGKILL. Quyền cũng không được khôi phục bởi down-pre: nếu daemon hạ xuống một user hoặc group hoặc đi vào một chroot, hook chạy với quyền truy cập mà điều đó để lại. Một hook được gọi vẫn có thể thất bại trong việc cập nhật trình phân giải. Tài liệu tham chiếu OpenVPN bao gồm các tín hiệu và vòng đời của lệnh gọi lại.

Kiểm tra lỗi của chính hook bên cạnh trạng thái thoát của tiến trình. Dọn dẹp bị thiếu và dọn dẹp thất bại trông giống nhau trong trình phân giải và khác nhau trong nhật ký.

Kiểm tra trạng thái thực sự còn lại

Trên một hệ thống dùng systemd-resolved, resolvectl status cho thấy liên kết nào vẫn mang máy chủ DNS của VPN hoặc miền định tuyến. Liên kết đó có thể thuộc về một kết nối đã mất, hoặc một đường hầm khác vẫn đang hoạt động.

Một giao diện biến mất mang theo cấu hình theo liên kết của nó, nên một hook bị bỏ qua có thể cùng tồn tại với DNS sạch. Nếu liên kết vẫn được đăng ký và chỉ do kết nối đã dừng sở hữu, trình quản lý sở hữu nên xóa nó. Nếu một script cũ hơn đã ghi lại một tệp trình phân giải toàn cục, hãy tìm bước khôi phục được ghi chép của script đó thay thế.

Khôi phục mà không đánh cắp liên kết khác

Khi thiết lập theo liên kết thuộc quyền quản lý của bạn, resolvectl revert lấy tên liên kết và xóa cấu hình DNS thời gian chạy cho giao diện đó. Đây là hành động thời gian chạy chứ không phải chỉnh sửa hồ sơ, nên cấu hình kết nối lâu dài vẫn nguyên vẹn. Đặt tên sai liên kết và bạn sẽ xóa DNS của một đường hầm đang chạy, vì thế tên được lấy từ kết quả trạng thái.

Trước khi sửa, hãy xác nhận rằng /etc/resolv.conf là một liên kết tượng trưng được quản lý, sau đó dừng máy khách một lần nữa như bình thường và xem DNS lại. Nếu lần dừng thứ hai dọn sạch, vấn đề trước đó là do thoát cưỡng bức chứ không phải cấu hình.