Xác thực proxy bằng tên người dùng và mật khẩu: cách kết nối và tránh lỗi

Với xác thực bằng tên người dùng và mật khẩu, ứng dụng gửi cho proxy thông tin xác thực do nhà cung cấp cấp. Proxy kiểm tra và cho phép bạn dùng dịch vụ. Phương thức này hữu ích khi làm việc từ nhiều thiết bị và mạng: nếu dịch vụ không yêu cầu thêm ủy quyền bằng IP, chuyển tập lệnh sang máy chủ khác không đòi hỏi đổi địa chỉ IP được phép.

Kết nối hoạt động cần nhiều hơn tên người dùng và mật khẩu. Bạn còn cần đúng địa chỉ proxy, cổng và giao thức. Ứng dụng phải hỗ trợ phương thức xác thực cần thiết. Vì vậy, lỗi xác thực không nhất thiết có nghĩa mật khẩu sai.

Để so sánh các phương thức truy cập và chọn cách phù hợp, xem Xác thực proxy. Bài viết này trình bày kết nối bằng tên người dùng và mật khẩu, từ nhập cài đặt đến chẩn đoán vấn đề trong tập lệnh đang sử dụng.

Xác thực bằng tên người dùng và mật khẩu là gì?

Tên người dùng xác định tài khoản hoặc quyền truy cập một dịch vụ cụ thể, còn mật khẩu xác nhận quyền sử dụng. Khi kiểm tra thành công, proxy xử lý kết nối trong phạm vi được cấp: danh sách địa chỉ khả dụng, hạn mức đã mua và giới hạn áp dụng.

Đừng nhầm thông tin xác thực proxy với mật khẩu bảng điều khiển. Chi tiết ứng dụng dùng có thể khác với thông tin đăng nhập trang web của nhà cung cấp. Khóa API dành cho yêu cầu đến API dịch vụ, còn mật khẩu trang web đích dành cho đăng nhập trang đó. Chỉ dùng một trong các thông tin này làm mật khẩu proxy khi nhà cung cấp quy định rõ phương thức kết nối ấy.

Xác thực proxy thành công không có nghĩa bạn đã đăng nhập vào trang web đích. Nếu trang yêu cầu tài khoản, cookie hoặc token riêng, ứng dụng vẫn phải cung cấp chúng riêng biệt.

Khi nào phương thức này hữu ích?

Truy cập bằng tên người dùng và mật khẩu có thể phục vụ ứng dụng ở nhiều địa điểm, dù địa điểm cố định hay thay đổi. Khi không có hạn chế IP, mỗi ứng dụng cần thông tin xác thực và cài đặt kết nối proxy, không cần mục danh sách được phép riêng cho mạng của nó.

Ví dụ, nhóm làm việc từ hai văn phòng và nhà riêng, mỗi nơi có IP công cộng khác nhau. Các ứng dụng có thể dùng cùng thông tin xác thực proxy nếu dịch vụ cho phép những ứng dụng đó dùng chung mà không ràng buộc IP. Mỗi ứng dụng giữ cài đặt kết nối riêng; proxy kiểm tra thông tin xác thực từng ứng dụng gửi.

Phương thức này cũng dùng được cho nhiều máy chủ cố định. Tuy nhiên, số thiết bị, kết nối đồng thời và tài nguyên khả dụng tùy thuộc gói dịch vụ. Một mật khẩu không cấp quyền truy cập không giới hạn.

Cách ứng dụng gửi thông tin xác thực proxy

Trình tự chung đơn giản: ứng dụng liên hệ proxy, vượt qua kiểm tra truy cập rồi dùng proxy để đến tài nguyên được yêu cầu. Chi tiết tùy thuộc giao thức.

Proxy HTTP có thể trả về trước 407 Proxy Authentication Required và chỉ ra phương thức xác thực nó chấp nhận. Ứng dụng gửi thông tin xác thực trong tiêu đề Proxy-Authorization. Một số máy khách gửi ngay, nên yêu cầu xác thực ban đầu có thể không xuất hiện trong nhật ký.

Khi mở trang HTTPS qua proxy HTTP thông thường, xác thực có thể diễn ra trong yêu cầu CONNECT tạo đường hầm. Sau đó, ứng dụng thiết lập kết nối bảo mật với trang web. Các yêu cầu tiếp theo đến trang qua đường hầm đã tạo không lặp lại đăng nhập proxy đã dùng để mở đường hầm.

Với SOCKS5, tên người dùng và mật khẩu được kiểm tra ở đầu kết nối, trước yêu cầu kết nối đến đích. Nếu kiểm tra thất bại, ứng dụng không có được kết nối yêu cầu qua proxy. Lỗi xác thực gốc của SOCKS5 không phải phản hồi HTTP 407.

Chọn giao thức và phương thức xác thực được dịch vụ hỗ trợ. SOCKS4 có trường ID người dùng nhưng không định nghĩa cuộc trao đổi tên người dùng và mật khẩu của SOCKS5. Điền trường đó không thể khiến máy khách SOCKS4 thực hiện xác thực mật khẩu SOCKS5.

Những cài đặt cần nhập trong ứng dụng

Bắt đầu với chi tiết kết nối của dịch vụ cụ thể. Nếu ứng dụng có các trường riêng, nhập từng giá trị vào đúng trường:

Một số ứng dụng chấp nhận một chuỗi theo định dạng protocol://username:password@host:port. Ví dụ, trong http://client01:River%[email protected]:8080, tên người dùng là client01, mật khẩu là River@2026, máy chủ là proxy.example và cổng là 8080. Ký tự @ trong mật khẩu được biểu diễn bằng %40 để không nhầm với dấu phân cách trước tên máy chủ.

Ví dụ, curl hỗ trợ cách diễn giải URL proxy này. Trường mật khẩu riêng thường cần chính mật khẩu, không qua mã hóa URL. Đừng sao chép giá trị đã mã hóa từ URL sang trường riêng mà chưa kiểm tra định dạng: ứng dụng có thể coi đó là mật khẩu khác. Với chuỗi chứa %, dấu hai chấm hoặc ký tự đặc biệt khác, hãy tuân theo yêu cầu định dạng của máy khách.

Mã hóa URL một lần cho những ký tự cần thiết bên trong thông tin xác thực; mã hóa toàn bộ chuỗi sẽ làm hỏng các dấu phân cách. Đặt đối số lệnh trong dấu ngoặc kép không thay thế mã hóa URL. Phương thức xác thực cũng có thể có hạn chế riêng: chẳng hạn HTTP Basic cho phép dấu hai chấm trong mật khẩu nhưng không cho phép trong tên người dùng.

Định dạng nhập cũng khác nhau. host:port:username:password và username:password@host:port không thể thay thế cho nhau. Giá trị đúng nhưng sai thứ tự sẽ không hoạt động nếu công cụ nhập chờ bố cục khác.

Tiền tố http:// trong URL proxy mô tả cách máy khách kết nối đến chính proxy. Nó không ngăn truy cập trang HTTPS: máy khách có thể tạo đường hầm cho các trang đó. Chỉ đổi tiền tố thành https:// không bổ sung khả năng hỗ trợ kết nối proxy bảo mật cho máy chủ.

Một số dịch vụ đưa quốc gia, nhóm IP đầu ra hoặc tham số phiên vào tên người dùng. Sao chép toàn bộ chuỗi. Những tham số này điều khiển định tuyến theo quy tắc nhà cung cấp; đừng tự đặt cú pháp hoặc mượn từ dịch vụ khác.

Vì sao cần kiểm tra khả năng hỗ trợ xác thực của ứng dụng?

Hỗ trợ proxy và hỗ trợ xác thực proxy là hai khả năng riêng. Có trường máy chủ và cổng không nhất thiết có nghĩa máy khách gửi được tên người dùng và mật khẩu.

Kiểm tra đúng tổ hợp giao thức proxy, phương thức xác thực và ứng dụng. Ví dụ, triển khai SOCKS5 tích hợp trong Chrome không hỗ trợ xác thực proxy SOCKS5. Chỉ thông tin xác thực đúng không khắc phục được hạn chế đó. Tiện ích chọn proxy cũng không nhất thiết bổ sung phương thức xác thực còn thiếu.

Trong tập lệnh, khả năng hỗ trợ có thể tùy thuộc thư viện, thành phần tùy chọn và cách truyền cài đặt. Ứng dụng không nhất thiết dùng cài đặt proxy của hệ thống hay cài đặt của trình duyệt đã kết nối được.

Trước khi bắt đầu tác vụ lớn, thử một yêu cầu trong ứng dụng sẽ chạy tác vụ đó. Xác nhận ứng dụng dùng proxy đã chỉ định và không tiếp tục bằng kết nối trực tiếp sau khi thất bại. Chỉ tải trang thành công chưa xác nhận cài đặt đúng.

Điều gì xảy ra khi IP thay đổi?

Với kết nối ADSL dùng IP động, nhà cung cấp internet có thể cấp địa chỉ mới sau khi khởi động lại bộ định tuyến hoặc kết nối lại. Nếu proxy chỉ kiểm tra tên người dùng và mật khẩu, ứng dụng kết nối bằng cùng thông tin xác thực: không có IP mới cần thêm trong bảng điều khiển. Điều tương tự áp dụng khi chuyển từ văn phòng về mạng gia đình.

Tuy nhiên, đổi mạng có thể làm gián đoạn kết nối hiện có. Máy khách phải kết nối lại và yêu cầu chưa hoàn tất có thể cần thử lại. Không nên tự động coi lỗi ngay sau khi chuyển từ Wi-Fi sang internet di động là vấn đề mật khẩu.

Một số dịch vụ kiểm tra cả thông tin xác thực và địa chỉ nguồn. Mật khẩu đúng không vượt qua hạn chế mạng đó: IP mới phải khớp địa chỉ hoặc dải được phép. Trước khi chuyển tập lệnh, xác định dịch vụ chấp nhận kết nối từ mọi mạng hay áp dụng kiểm tra kết hợp.

Mật khẩu có được bảo vệ khi truyền không?

Xác thực quyết định ai được truy cập. Mã hóa quyết định người trên tuyến truyền có đọc được dữ liệu hay không. Có mật khẩu không tự làm kết nối được mã hóa.

HTTP Basic biểu diễn tên người dùng và mật khẩu bằng Base64. Đây là cách biểu diễn có thể đảo ngược, không phải mã hóa bảo mật. Nếu kết nối đến proxy không được bảo vệ, người quan sát tuyến mạng đó có thể lấy thông tin xác thực. Xác thực SOCKS5 tiêu chuẩn bằng tên người dùng và mật khẩu cũng không mã hóa quá trình truyền chúng.

HTTPS trên trang web đích bảo vệ kết nối giữa ứng dụng và trang đó. Với proxy HTTP, xác thực trong quá trình tạo đường hầm diễn ra trước; TLS của trang không bảo vệ thông tin xác thực proxy đã gửi. Tương tự, yêu cầu HTTPS qua SOCKS5 không mã hóa cuộc kiểm tra mật khẩu proxy diễn ra trước đó.

Bảo vệ phần tuyến này đòi hỏi bảo vệ giữa ứng dụng và proxy, chẳng hạn proxy HTTPS dùng TLS khi cả dịch vụ và máy khách đều hỗ trợ. Ứng dụng phải xác minh chứng chỉ proxy. Trong một số quảng cáo, “proxy HTTPS” chỉ có nghĩa truy cập được trang HTTPS, nên cần kiểm tra TLS thực sự áp dụng ở đâu.

Nếu chuỗi kết nối đầy đủ có mật khẩu hợp lệ bị lộ, người khác có thể dùng dịch vụ trong phạm vi quy tắc của nó, tiêu hao hạn mức hoặc chiếm kết nối. Điều này không tương đương với có được mật khẩu bảng điều khiển nếu hai thông tin được tách biệt. Phương thức xác thực cũng không bảo đảm địa chỉ không bị nhận diện là proxy: yêu cầu xác thực có thể truy cập từ ngoài có thể tiết lộ dịch vụ.

Nhiều ứng dụng có thể dùng chung thông tin xác thực không?

Về kỹ thuật, nhiều máy khách có thể gửi cùng tên người dùng và mật khẩu. Nhà cung cấp quyết định có cho phép hay không và đặt phạm vi: điều kiện dùng chung, giới hạn kết nối hoạt động, hạn mức đã mua và hạn chế bổ sung.

Ví dụ, hai tập lệnh có thể dùng một tài khoản nhưng mở số kết nối khác nhau. Một mật khẩu không có nghĩa một kết nối. Tương tự, chạy mười tiến trình không nhân tổng hạn mức kết nối của dịch vụ lên mười lần.

Số cặp thông tin xác thực cũng khác số IP đầu ra. Một tên người dùng và mật khẩu có thể cho phép truy cập danh sách proxy tĩnh hoặc gateway phía sau là nhóm địa chỉ. IP trang web thấy tùy thuộc proxy được chọn và quy tắc định tuyến dịch vụ.

Nếu dịch vụ cung cấp thông tin xác thực riêng cho từng ứng dụng hoặc thành viên nhóm, có thể vô hiệu hóa một bộ mà không đổi bộ khác. Với mật khẩu dùng chung, đổi mật khẩu đòi hỏi cập nhật mọi ứng dụng sử dụng nó. Thông tin xác thực riêng vẫn không có nghĩa hạn mức kết nối hoặc lưu lượng riêng: hãy kiểm tra những giới hạn nào được dùng chung.

Vì sao proxy từ chối tên người dùng và mật khẩu?

Trước hết, xác định bên trả lỗi. HTTP 407 liên quan đến xác thực proxy; 401 từ trang web đích liên quan đến truy cập trang đó. Không có bằng chứng bổ sung, thông báo 403 hoặc hết thời gian chờ không xác định được mật khẩu proxy đúng hay sai.

Kiểm tra trạng thái dịch vụ và hạn mức còn lại, rồi thử một yêu cầu bằng cài đặt được cấp trong ứng dụng thực tế. Nếu thất bại, dùng bảng để kiểm tra hỗ trợ của máy khách, định dạng thông tin xác thực và hạn chế IP nguồn, mỗi lần chỉ đổi một cài đặt. Khi yêu cầu hoạt động ổn định, tăng khối lượng công việc và theo dõi giới hạn chỉ xuất hiện khi có tải.

Cách lưu và thay thông tin xác thực trong tập lệnh làm việc

Tách thông tin xác thực khỏi mã nguồn, lưu trong cấu hình có kiểm soát truy cập hoặc kho bí mật của môi trường. Ứng dụng có thể nhận chúng qua biến môi trường, nhưng bản thân biến môi trường không phải mã hóa. Đừng đưa mật khẩu đang dùng vào kho mã và mẫu chia sẻ cho người khác.

Nhật ký thường cần máy chủ và cổng proxy, kết quả kết nối và mã lỗi. Chuỗi kết nối đầy đủ chứa mật khẩu; hãy che mật khẩu trước khi ghi nhật ký. Với công cụ dòng lệnh, cần tính đến việc bí mật có thể lưu trong lịch sử lệnh hoặc xuất hiện trong đối số tiến trình, tùy ứng dụng và hệ thống.

Trước khi đổi mật khẩu, tìm mọi nơi sử dụng: ứng dụng cục bộ, tiến trình máy chủ, tác vụ theo lịch và hệ thống xây dựng phần mềm. Sau khi đổi, cập nhật cài đặt và tạo kết nối mới để kiểm tra. Xác nhận tiến trình chạy lâu cũng đã nhận giá trị mới; một số cần khởi động lại.

Nếu mật khẩu cũ không còn được phép hoạt động, thử xác nhận kết nối mới dùng nó bị từ chối. Kết nối đã có tuân theo quy tắc riêng của dịch vụ: đổi mật khẩu không phải lúc nào cũng đóng chúng ngay. Khi cần thu hồi khẩn cấp, dùng phương thức vô hiệu hóa truy cập được nhà cung cấp hỗ trợ.

Xác thực kết hợp: IP và mật khẩu

Với xác thực kết hợp, proxy kiểm tra hai điều kiện: thông tin xác thực và địa chỉ mà ứng dụng kết nối từ đó. Cả hai phải đạt. Chỉ mật khẩu đúng không vượt qua hạn chế IP.

Với gói tĩnh ProxyCompass, chế độ kết hợp dùng mạng con /24. Nếu bạn có nhiều địa chỉ IPv4 công cộng trong cùng mạng con, chỉ cần thêm một địa chỉ vào danh sách được phép. Các địa chỉ khác trong mạng con đó có thể kết nối bằng tên người dùng và mật khẩu đúng, không cần mục riêng cho từng địa chỉ.

Trong hình, IP công cộng của ứng dụng có ba số đầu trùng địa chỉ được phép. Nó có thể kết nối bằng thông tin xác thực hợp lệ; địa chỉ ngoài mạng con không vượt qua kiểm tra mạng, và mật khẩu sai vẫn thất bại ngay cả trong mạng con. IP máy khách khác cùng mạng con cũng dùng được mục này. Điều này hữu ích với ứng dụng yêu cầu trường tên người dùng và mật khẩu. Quy tắc áp dụng cho IP công cộng của ứng dụng, không phải IP đầu ra proxy đã mua.