Định nghĩa một người dùng không phải là toàn bộ cấu hình đăng nhập của 3proxy. Dịch vụ cũng cần một phương thức xác thực và một quy tắc truy cập sử dụng phương thức đó. Thứ tự rất quan trọng vì các thiết lập dịch vụ được áp dụng trong khi cấu hình đang được xử lý.

Một ví dụ chỉ dành cho truy cập cục bộ với hai dịch vụ:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

Tài liệu tham chiếu cấu hình giải thích users, auth strong và các lệnh dịch vụ. CL lưu mật khẩu ví dụ này dưới dạng văn bản thuần. Hãy bảo vệ tệp và chọn một dạng lưu trữ thông tin xác thực được hỗ trợ phù hợp với việc triển khai.

Máy khách cần đúng kiểu trao đổi đăng nhập

Dịch vụ HTTP mong đợi xác thực proxy HTTP. Dịch vụ SOCKS cần một máy khách hỗ trợ xác thực SOCKS5 bằng tên người dùng và mật khẩu. Máy khách SOCKS4 không thể cung cấp kiểu trao đổi đó chỉ vì nó tiếp cận cùng cổng lắng nghe.

Từ strong là tên của một chế độ xác thực, không phải bảo đảm về truyền tải được mã hóa. Bảo vệ đoạn từ máy khách đến proxy khi cần thiết. HTTPS đến đích và mã hóa đến proxy vẫn là hai quyết định riêng.

Các liên kết loopback giới hạn ví dụ này ở truy cập cục bộ. Với máy khách từ xa, hãy chọn rõ ràng một trình lắng nghe và chính sách mạng dự kiến. Một trình lắng nghe công khai kiểu wildcard không thay thế việc kiểm tra hành vi đăng nhập.

Nếu một dịch vụ yêu cầu thông tin xác thực còn dịch vụ kia thì không, hãy kiểm tra các thiết lập trước mỗi lệnh dịch vụ, các quy tắc sau bất kỳ flush nào và bộ nhớ đệm xác thực. Đổi mật khẩu không thể sửa một dịch vụ được khởi động dưới chính sách sai. Tương tự, đổi tài khoản hệ điều hành của daemon không tạo ra người dùng proxy.

Bài viết liên quan