Dịch vụ OpenVPN dừng ở lời nhắc mật khẩu khóa riêng: cách khắc phục

OpenVPN hỏi cụm mật khẩu của khóa riêng trên máy cục bộ, nên một tệp đăng nhập hoạt động không bao giờ trả lời được. Trong dịch vụ không có terminal để gõ, và lần khởi động hoặc treo hoặc thất bại với một mục journal nêu tên đầu vào chứ không phải nguyên nhân. Có hai bí mật liên quan, và mỗi bí mật cần nguồn đọc được của riêng nó trước khi unit khởi động lại. Các bước dưới đây tách chúng ra, rồi kiểm tra danh tính thực sự mở từng tệp.

Phân biệt hai lời nhắc

Cụm mật khẩu của khóa giải mã khóa riêng cục bộ; thông tin đăng nhập tài khoản xác thực phiên với máy chủ. Chúng đến từ những nơi khác nhau, thất bại ở những thời điểm khác nhau và tạo ra những thông báo khác nhau. Nhầm lẫn chúng khiến người ta đi tìm đặt lại mật khẩu trong khi tài khoản không hề liên quan. Hãy đọc văn bản của lời nhắc trước khi đổi bất kỳ tùy chọn nào, vì cách diễn đạt là manh mối đáng tin duy nhất về bí mật nào đang thiếu.

Trong Community OpenVPN 2.x, askpass chỉ định một tệp chứa cụm mật khẩu của khóa ở dòng đầu tiên, và auth-user-pass chỉ định một tệp có tên người dùng ở một dòng và mật khẩu ở dòng kế tiếp. Không tệp nào thỏa mãn tùy chọn kia. Một ứng dụng máy tính hoặc hồ sơ NetworkManager có thể giữ cả hai trong kho bí mật riêng, thứ mà ứng dụng dòng lệnh không bao giờ đọc, nên hãy ghi lại bạn đang cấu hình ứng dụng nào trước khi viết bất kỳ đường dẫn nào.

Trỏ cả hai tùy chọn vào các tệp đọc được

Một hồ sơ cần cả hai đầu vào cuối cùng có ba tham chiếu tệp: khóa được mã hóa, cụm mật khẩu mở khóa nó và cặp đăng nhập. Hãy thêm chúng mà không chạm vào CA hay các kiểm tra danh tính, vì chúng quyết định máy chủ là ai và không thuộc vấn đề này. Nếu việc triển khai không dùng thông tin tài khoản, thêm auth-user-pass sẽ tạo ra đầu vào mà không ai cung cấp được.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

Các tùy chọn không có đối số hành xử khác với tùy chọn có đường dẫn, và trong dịch vụ sự khác biệt này quan trọng. Một askpass không đối số vẫn đọc console, và một tệp auth-user-pass chỉ có tên người dùng vẫn để lại lời nhắc mật khẩu chờ. Khi ứng dụng trở thành daemon, nó không thể yêu cầu terminal nhập liệu nữa, nên dịch vụ cấu hình kiểu này không khởi động.

Đường dẫn tuyệt đối loại bỏ câu hỏi về thư mục làm việc nhưng không cấp quyền truy cập. Tiếp theo là quyền sở hữu, chế độ và việc đi qua, và cả ba được kiểm tra theo tài khoản mà tiến trình chạy dưới đó.

Đọc cấu hình của unit trước hồ sơ

Chính unit, không phải tệp bạn đang sửa, quyết định cấu hình nào được nạp. Đọc dòng lệnh của nó và mọi drop-in, rồi theo thư mục làm việc đến hồ sơ thực sự được dùng. Một tham chiếu cụm mật khẩu thêm vào tệp .ovpn khác không thay đổi gì cho phiên bản này.

Ba lệnh chỉ đọc trả lời phần lớn. Lệnh đầu in unit và mọi drop-in, lệnh thứ hai in danh tính và các thiết lập sandbox ràng buộc tiến trình, và lệnh thứ ba in điều mà lần khởi động cuối thực sự phàn nàn. Dùng tên phiên bản có trên máy chủ:

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

Chú ý đến ProtectHome và các tùy chọn riêng của hồ sơ user, group và chroot. Một tệp dưới thư mục nhà có thể đọc được trong shell của bạn nhưng vô hình bên trong dịch vụ khi thư mục nhà bị ẩn. Tài khoản mà systemd khởi động không phải lúc nào cũng là tài khoản cuối cùng mở khóa.

Chứng minh danh tính lúc chạy có thể mở cả hai tệp

Đọc chế độ là chưa đủ, vì mọi thư mục trên đường dẫn phải đi qua được bởi cùng một danh tính. Hãy đi hết đường dẫn theo từng thành phần, rồi thử mở với tư cách tài khoản mà tiến trình dùng. Một tệp có chế độ 600 thuộc sở hữu root chỉ hoạt động khi tiến trình còn là root, điều không còn đúng sau khi hạ quyền mà nhiều hồ sơ thực hiện. Hai lệnh bao quát việc đi qua và mở:

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

Lệnh đầu in chế độ của từng thành phần và thất bại ở nơi tài khoản không đi qua được; lệnh thứ hai trả lời câu hỏi duy nhất quan trọng, liệu danh tính lúc chạy có mở được tệp để đọc hay không. Cả hai đều không in nội dung tệp, và đó chính là điểm mấu chốt khi tệp chứa cụm mật khẩu. Lặp lại kiểm tra cho tệp đăng nhập, vì hai tệp thường được lưu với quyền sở hữu khác nhau.

Nếu tiến trình dùng chroot hoặc namespace hạn chế, hãy chạy cùng kiểm tra đó từ bên trong khung nhìn ấy, nếu không câu trả lời mô tả sai hệ thống tệp. Một cụm mật khẩu lưu dưới thư mục nhà ẩn là ví dụ thường gặp của phép thử đạt bên ngoài unit và thất bại bên trong nó.

Kiểm tra lần khởi động đầu, rồi đến kết nối lại

Khởi động phiên bản một lần và đọc lỗi đầu tiên chứ không phải lỗi cuối. Thiếu tệp đầu vào, giải mã khóa thất bại và AUTH_FAILED từ máy chủ là ba sự kiện khác nhau với ba cách sửa khác nhau. Sửa một cảnh báo quyền không chứng minh gì về việc khóa đã được mở hay chưa.

Dòng journal cho biết bạn thuộc trường hợp nào trong ba. Cách sửa phụ thuộc vào đầu vào nào đã thất bại:

Sau đó thử vòng đời bạn thực sự cần: khởi động khi boot và mọi kết nối lại được hỗ trợ, không chỉ khởi động thủ công từ shell của bạn. Với auth-nocache, đầu vào bị bỏ sau lần dùng đầu tiên, nên lần kết nối lại sau đó vẫn cần nguồn đọc được. Một chuỗi khóa mở khi đăng nhập máy tính không khả dụng cho dịch vụ khởi động trước khi có người đăng nhập, và đó là lý do thường gặp khiến thử thủ công đạt còn khởi động lại thì thất bại. Nếu lần khởi động đầu thành công và lần kết nối lại sau thất bại, hãy đọc journal cho sự kiện kết nối lại trước khi đổi quyền lần nữa.

Lưu cụm mật khẩu cạnh khóa làm giảm giá trị của mã hóa, nên hãy hạn chế tệp đó và các bản sao lưu. Hãy coi việc bỏ cụm mật khẩu của khóa là một quyết định thông tin xác thực riêng, không phải cách sửa cho đầu vào thiếu. Một triển khai phụ thuộc vào phê duyệt của con người hoặc MFA tương tác cần agent hoặc tích hợp quản lý được hỗ trợ; mã dùng một lần lưu vĩnh viễn không phải phương án thay thế tương đương.