Sai mật khẩu bị từ chối là vấn đề vùng chứa, không phải quy tắc mật khẩu
Một thông tin đăng nhập bị từ chối có thể chưa từng đến cổng. Hãy so sánh vùng chứa đầu vào, giai đoạn xác thực và chính tài khoản trước.
Thấy thông báo sai mật khẩu thường dẫn đến một kết luận: VPN không thích dấu câu. Kết luận đó thường sai, vì thông báo hay đến từ xử lý cục bộ trước khi bất kỳ cổng nào nhìn vào tài khoản. Hai thiết kế cùng truyền một mật khẩu, một ô đồ họa và một tệp thông tin đăng nhập, và chúng hỏng ở những chỗ khác nhau. Hãy so sánh các vùng chứa trước khi đơn giản hóa một mật khẩu vốn đã đúng.
Lỗi đến trước cổng
Kiểm tra cục bộ, kho bí mật bị khóa, thiếu agent và tệp thông tin đăng nhập sai định dạng đều tạo ra lỗi mà người dùng cảm nhận như một lần từ chối. Không cái nào liên quan đến máy chủ xác thực. Việc cổng tự từ chối là một sự kiện riêng, và nó thường đến với thông báo khác và thời điểm khác. Nó xảy ra sau khi tunnel đã tồn tại và thông tin đăng nhập đã được truyền đi.
Vậy câu hỏi đầu tiên không phải ký tự nào hợp lệ mà là lần thử đã dừng ở đâu. Một client chưa từng mở kết nối thì chưa bị ai từ chối. Hãy ghi lại giai đoạn bạn quan sát được, vì mọi bước sau đều phụ thuộc vào cách phân loại đó.
Sự phân biệt cũng thay đổi ai là người sửa. Vấn đề vùng chứa thuộc về thiết bị và chủ sở hữu nó, còn việc tài khoản bị từ chối thuộc về người vận hành backend xác thực.
So sánh vùng chứa, không phải ký tự
Một ô mật khẩu đồ họa, một mục keychain, một tệp thông tin đăng nhập hai dòng và một bí mật tự động hóa đều mang cùng một giá trị trong những phong bì khác nhau. Phong bì có quy tắc riêng, và chính những quy tắc đó thường bị phá. Giá trị hiếm khi là vấn đề; cách vận chuyển giá trị mới thường là. Tách hai ý đó ra thì chẩn đoán sẽ ngắn hơn.
| Where the value stops | What you see | What you check | Who owns the fix |
|---|---|---|---|
| GUI field or managed profile | A validation message before any connection opens | The selected authentication mode and whether the field holds the secret or the username | The device owner or the profile author |
| Keychain or secret agent | A prompt that keeps reappearing, or an agent error | Whether the agent is unlocked and holds an entry for this profile | The user who owns the keychain |
| Two-line credential file | A prompt for a password that was already supplied | Line count, line order and whether a trailing newline is present | Whoever generated the file |
| Shell argument or environment | Works interactively but fails in automation | Whether the shell expanded, trimmed or logged the value | Whoever wrote the automation |
Tùy chọn client Community OpenVPN 2.6 mô tả tệp hai dòng đó cho auth-user-pass, kể cả hành vi khi thiếu dòng mật khẩu: client sẽ hỏi. Chi tiết duy nhất đó giải thích một nhóm báo cáo kiểu nó hỏi mật khẩu tôi đã nhập. Nó cũng cho bạn biết dòng thứ hai rỗng là một trạng thái có nghĩa chứ không phải lựa chọn định dạng vô hại.
Dấu ngoặc kép lại là một lớp riêng: dấu ngoặc trong tệp thông tin đăng nhập thường được lưu như dữ liệu, còn shell gỡ chúng trước khi chương trình thấy bất cứ thứ gì. Cùng một ký tự vô hại ở chỗ này và mang tính cấu trúc ở chỗ kia. Bảng không thể cho biết client của bạn dùng vùng chứa nào, nên hãy đọc cấu hình của chính client trước khi chọn một dòng.
Ngắt dòng cũng mang tính cấu trúc. Tệp có các trường phân tách bằng dòng không thể mang giá trị chứa ký tự xuống dòng, và đó là giới hạn của định dạng chứ không phải đánh giá về độ mạnh mật khẩu. Hãy dùng cơ chế phân phối được hỗ trợ của triển khai thay vì cắt bớt bí mật cho vừa một tệp tùy tiện.
Tạo tệp thông tin đăng nhập mà shell không làm hỏng
Cách cục bộ an toàn nhất giữ bí mật ngoài lịch sử shell và ngoài danh sách tham số tiến trình. Đọc cả hai trường một cách tương tác, rồi ghi hai dòng mà client mong đợi. Mọi thứ khác có thể nằm trong tệp cấu hình dễ xem lại.
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/credsHai lệnh đầu đọc tên người dùng rồi mật khẩu mà không hiển thị, lệnh thứ ba ghi cả hai dòng, lệnh thứ tư giới hạn quyền tệp, và lệnh cuối khởi động client với tệp đó. Lưu ý rằng read -r giữ nguyên dấu gạch chéo ngược, đúng kiểu chi tiết mà khi bỏ qua sẽ biến một mật khẩu đang chạy được thành một mật khẩu hỏng.
Tránh tạo tệp bằng một biến không có ngoặc kép hoặc bằng here-document đầy các phép mở rộng của shell. Cả hai đều có thể biến đổi ký tự trước khi chúng đến tệp, và lỗi sinh ra trông giống như VPN từ chối vì mật khẩu trên đĩa thực sự khác với mật khẩu bạn biết. Nếu nghi điều này, hãy so sánh độ dài byte của tệp với giá trị mong đợi mà không in ra chính bí mật. Lệch một hoặc hai byte là dấu hiệu của một tai nạn về ngoặc kép.
Đọc giai đoạn từ lỗi đầu tiên
Giữ thông báo cụ thể đầu tiên từ một lần thử, rồi phân loại nó. Lỗi kiểm tra cục bộ, thiếu khóa riêng, không có agent bí mật và lỗi xác thực ở cổng là bốn kết quả khác nhau với bốn người chịu trách nhiệm khác nhau. Chỉ một trong số đó liên quan đến tài khoản.
Nếu cổng thực sự từ chối một thông tin đăng nhập được truyền đúng, hãy kiểm tra tài khoản, backend xác thực và mọi thử thách bắt buộc với quản trị viên. Một lỗi xác thực chung chung không nêu tên ký tự bị cấm.
Hãy khôi phục giá trị đã được phê duyệt qua đúng cơ chế thay vì rút gọn nó thành chữ và số. Chính sách mật khẩu thuộc về người vận hành, và một cách lách lặng lẽ vô hiệu hóa nó không phải là cách sửa. Nó còn che giấu khiếm khuyết thật với người tiếp theo, người sẽ gặp đúng lỗi đó với một mật khẩu yếu hơn và không có ý tưởng tốt hơn.