OpenVPN auth-nocache: điều gì xảy ra ở lần đăng nhập tiếp theo

Bật auth-nocache và cảnh báo về việc lưu đệm mật khẩu biến mất, cùng với bản sao thông tin xác thực mà OpenVPN giữ cho lần thương lượng lại tiếp theo. Việc đó trở thành lời nhắc, một lần thử lại im lặng hay một đường hầm bị đứt phụ thuộc vào việc thông tin xác thực đến từ đâu trong lần thứ hai. Vì vậy đây là sự so sánh giữa các hình thức triển khai chứ không phải phán quyết về tùy chọn. Hãy đọc hình thức bạn thực sự vận hành trước khi sửa bất kỳ hồ sơ nào.

Bộ thông tin xác thực thứ hai phải đến từ đâu

OpenVPN áp dụng auth-nocache cho các bí mật mà auth-user-pass và askpass thu thập: sau khi được dùng, tiến trình vứt bỏ chúng thay vì giữ lại cho lần bắt tay tiếp theo. Việc thương lượng lại đến theo bộ hẹn giờ, mặc định mỗi giờ một lần, nên yêu cầu thứ hai đến rất lâu sau khi người đã nhập mật khẩu rời đi. Khoảng trống đó là toàn bộ câu chuyện. Nếu để bộ đệm bật, máy khách phát lại bản sao đã lưu mà không hỏi ai; nếu tắt, nó phải tìm bí mật ở nơi khác hoặc thất bại.

Vì vậy hãy liệt kê mọi nơi bí mật có thể đến vào lúc đó, và trung thực về nơi nào trong số đó tồn tại trên máy chủ. Một người trước thiết bị đầu cuối, một tệp mà auth-user-pass hoặc askpass có thể đọc, hoặc một mã thông báo phiên do máy chủ cấp là ba thứ quan trọng ở đây. Nếu không có cái nào trong số đó, việc thương lượng lại thất bại một giờ sau khi thay đổi chứ không phải ngay lúc bạn thực hiện.

Ba hình thức, ba điểm thất bại

Máy khách để bàn có người ngồi trước là trường hợp nhẹ: lời nhắc quay lại, ai đó nhập lại mật khẩu, và cái giá là sự chú ý. Dịch vụ, vùng chứa hoặc bộ định tuyến chạy OpenVPN không có thiết bị đầu cuối là trường hợp khó, vì không có ai trả lời và kết nối lại từng im lặng nay kết thúc đường hầm. Hình thức lai nằm giữa hai trường hợp và hành xử như trường hợp để bàn cho đến khi phiên có thể trả lời lời nhắc biến mất. Điều phân biệt chúng không phải là có cài GUI hay không, mà là có nguồn thông tin xác thực vào thời điểm thương lượng lại hay không.

Hãy ánh xạ việc triển khai của bạn vào một trong ba hình thức trước khi thay đổi bất cứ điều gì, vì lời khuyên bạn tìm thấy trực tuyến gần như luôn được viết cho hình thức đầu tiên. Áp dụng câu trả lời của máy để bàn cho dịch vụ không có thiết bị đầu cuối chính là cách một đường hầm đã chạy nhiều tháng bắt đầu sụp mỗi giờ.

Chỉ thị hay cờ: chọn một và biết mình đã dùng cái nào

Bên trong hồ sơ, auth-nocache là một dòng riêng; trong lệnh gọi nêu rõ hồ sơ, nó là cờ trên dòng lệnh đó, và hướng dẫn OpenVPN liệt kê cả hai hình thức. Cả hai làm cùng một việc với việc giữ thông tin xác thực, và không cái nào chạm vào loại giao diện hay sửa một cảnh báo không liên quan trong cùng nhật ký. Khác biệt là độ bền: cờ chỉ bao phủ lần chạy đó, nên dịch vụ khởi động lại từ tệp unit hoặc script bao bọc sẽ không có nó trừ khi lớp bao cũng truyền nó.

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

Hãy quyết định hiện vật nào sở hữu thiết lập, thay đổi ở đó và không ở nơi nào khác. Một hồ sơ được sửa trên máy tính xách tay cùng một unit systemd ghi đè nó bằng cờ là cặp tạo ra hành vi mâu thuẫn sau khi khởi động lại.

Tệp thông tin xác thực di chuyển bí mật thay vì xóa nó

Trỏ auth-user-pass vào một tệp cho mỗi lần thương lượng lại sau đó một nguồn, và cũng đặt mật khẩu ở nơi tồn tại qua các lần khởi động lại. Hãy hỏi ai có thể đọc tệp đó, tiến trình nền còn đọc được sau khi từ bỏ đặc quyền hay không, và điều gì xảy ra khi hệ thống tệp được gắn chỉ đọc hoặc chế độ xem vùng chứa ẩn đường dẫn. Bí mật trên đĩa và bí mật trong bộ nhớ là hai vấn đề khác nhau, và giải quyết cái này để cái kia tại chỗ. Luân chuyển là bước bị bỏ qua: mật khẩu đổi trên máy chủ nhưng không đổi trong tệp tạo ra lỗi được đọc như sự cố mạng.

Giữ tệp thuộc tài khoản chạy tiến trình nền, không ai khác đọc được, và nằm ngoài các bản sao lưu rời khỏi máy chủ. Tùy chọn auth-gen-token phía máy chủ của OpenVPN trao cho máy khách một mã thông báo phiên sau khi đăng nhập thành công, đây là thứ nhỏ hơn để bỏ mặc so với mật khẩu tài khoản. Dù thế nào cũng hãy ghi bước luân chuyển bên cạnh tệp, vì tệp thường sống lâu hơn người tạo ra nó.

Kéo dài thương lượng lại di chuyển chi phí, không xóa bỏ nó

Gợi ý còn lại là tăng reneg-sec cho đến khi lời nhắc đủ hiếm để bỏ qua. Điều đó viết lại lịch luân chuyển khóa của phiên và đẩy cùng vấn đề thông tin xác thực sang một thời điểm muộn hơn, khó đoán hơn; nó không tạo ra nguồn thông tin xác thực. Chính sách gia hạn khóa theo lịch vì lý do nào đó không nên được nới lỏng chỉ để tránh phải nhập mật khẩu.

Hãy kiểm tra việc kết nối lại chứ không phải phiên bạn đang ngồi, vì phiên đang sống không chứng minh được gì. Hãy làm đường hầm sụp từ phía máy chủ, hoặc khởi động lại dịch vụ máy khách, và xem lần thương lượng lại tiếp theo làm gì khi không có ai bên bàn phím. Nếu nó kết nối lại, hãy nêu tên cơ chế đã cung cấp bí mật; nếu không, bạn đã tìm ra chi phí thực của tùy chọn trên máy chủ này. Kết quả nào cũng cho bạn câu trả lời đúng trong lúc sự cố thay vì câu trả lời chỉ đúng trong lúc thử nghiệm.

Trong một đội máy được quản lý, người sở hữu việc triển khai nên nêu được ba điều: thông tin xác thực đến từ đâu, được lưu ở đâu và ai luân chuyển chúng. Nếu bất kỳ câu trả lời nào là người đã thiết lập máy chủ, tùy chọn này chưa an toàn ở đó.