Vì sao proxy PAC trong VM khách thất bại với URL của máy chủ

«Máy chủ dùng tệp PAC này, nên tôi đặt cùng URL đó vào VM» là một câu hợp lý và một kế hoạch chưa đầy đủ. URL PAC trỏ tới một script chính sách, không phải proxy. Cho tới khi máy khách tải được script đó, đánh giá nó bằng địa chỉ của chính máy khách rồi tới được bất kỳ proxy nào mà script nêu tên, URL chỉ là một chuỗi trong một trường cài đặt. Phần lớn sự nhầm lẫn về chính sách proxy trong máy ảo đến từ việc coi dòng duy nhất đó là toàn bộ cấu hình.

URL PAC là một script, không phải proxy

Tệp chứa một hàm nhận URL và máy chủ rồi trả về mô tả proxy hoặc từ DIRECT. Không có gì trong URL nói cho ứng dụng biết gửi lưu lượng đi đâu; quyết định đó được đưa ra khi chạy, bên trong script, với dữ liệu mà script hỏi nền tảng. Một hộp thoại cài đặt chấp nhận URL PAC là đang chấp nhận một con trỏ tới một thủ tục quyết định.

Chính sự khác biệt đó là lý do việc sao chép URL có thể trông như đã thành công. Trường được điền, cài đặt được lưu, và lỗi chỉ xuất hiện sau đó, khi không tải được script hoặc khi nó trả về một proxy mà máy khách không tới được.

Bốn bước thất bại theo bốn cách khác nhau

Bên trong máy khách, bốn việc phải xảy ra theo thứ tự, và mỗi việc có dấu hiệu lỗi riêng. Máy khách tải tệp PAC. Ứng dụng đánh giá script cho URL được yêu cầu bằng thông tin cục bộ. Proxy được chọn được phân giải và được tới. Xác thực diễn ra nếu proxy yêu cầu.

Hãy bắt đầu bằng việc chứng minh khâu tải về, vì mọi thứ sau đó là vô nghĩa nếu không có nó. Một tệp PAC trên máy chủ riêng cần một đường đi được phép tới máy chủ đó trước khi bất kỳ quy tắc nào có thể giúp, và một lựa chọn proxy bên trong script không tới được thì không thể tạo ra đường đi để tải nó về:

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

Nếu yêu cầu đó thất bại từ máy khách và thành công từ máy chủ, vấn đề là đường đi của máy khách tới máy chủ PAC, không phải nội dung của script. Nếu nó trả về một tệp JavaScript, hãy sang bước hai và tìm hiểu script quyết định gì cho bối cảnh của máy khách.

Cùng một script quyết định khác đi bên trong VM

Các hàm PAC có thể kiểm tra máy chủ được yêu cầu và thông tin về máy đang thực hiện việc đánh giá. Một quy tắc dựng trên địa chỉ của chính máy khách, chẳng hạn quy tắc kiểm tra địa chỉ giao diện hoặc tư cách thành viên của một mạng con, sẽ thấy địa chỉ của máy khách chứ không phải của máy chủ vật lý. Sau NAT phía máy chủ, đó là những địa chỉ khác nhau, nên cùng một script có thể chọn proxy khác hoặc quay về DIRECT bên trong VM.

Đây không phải lỗi trong script. Script đang làm đúng việc nó được viết ra để làm, với đầu vào khác, và điều đó giải thích báo cáo gây bối rối trong đó máy chủ dùng proxy còn máy khách kết nối trực tiếp. Hãy tái tạo quyết định thay vì lý sự về nó: một trình đánh giá PAC nhận địa chỉ và URL, nếu bản phân phối của bạn có, sẽ giải quyết câu hỏi bằng một lệnh duy nhất. Nếu không, hãy thử nghiệm bằng ứng dụng thực sự sẽ được dùng, và đọc nhật ký proxy của nó thay vì đoán.

Đừng kết luận rằng máy khách thừa hưởng cài đặt proxy của máy chủ bởi vì lưu lượng của nó đi qua một bước dịch phía máy chủ. Dịch địa chỉ mạng chuyển tiếp gói tin; nó không sao chép cấu hình ứng dụng, và proxy hệ thống là cấu hình ứng dụng.

Những công cụ không bao giờ đọc PAC

Công cụ dòng lệnh là một ranh giới riêng, và đây là chỗ mất rất nhiều thời gian. curl không thực thi tệp PAC, như tài liệu proxy của nó nói rõ. Trỏ một biến proxy vào URL tải xuống PAC không biến script thành một điểm cuối proxy; công cụ sẽ cố nói HTTP với một tệp JavaScript và thất bại theo cách trông như một sự cố mạng.

Điều tương tự áp dụng cho nhiều trình quản lý gói, môi trường chạy của ngôn ngữ và công cụ xây dựng, vốn chỉ tôn trọng các biến proxy rõ ràng hoặc cấu hình riêng của chúng. Nếu bài kiểm tra bạn quan tâm là một công cụ CLI, hãy cấu hình nó với proxy cụ thể mà script PAC sẽ chọn, và ghi lại cách bạn đi tới lựa chọn đó để người tiếp theo có thể làm lại.

Với ứng dụng máy tính để bàn trên Linux, cài đặt hệ thống phải được đặt ở chế độ tự động và cũng phải được cấp một URL; một URL được lưu khi chế độ vẫn còn thủ công thì không làm gì cả. Hãy kiểm tra cả hai, và kiểm tra chúng bên trong máy khách:

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT cũng là một quyết định

Kết quả PAC là DIRECT nghĩa là ứng dụng bỏ qua proxy HTTP, chứ không phải là nó đã thoát khỏi mạng. Kết nối tạo ra vẫn có thể đi theo tuyến của hệ điều hành qua một đường hầm, hoặc thất bại vì những lý do không liên quan gì đến việc dùng proxy. Ngược lại, một kết quả proxy mô tả yêu cầu của một ứng dụng, không phải mọi tiến trình trong máy khách.

Vì vậy hãy kiểm chứng theo đúng hướng mà yêu cầu đã được viết. Nếu yêu cầu là «ứng dụng này tới được trang nội bộ», hãy chứng minh ứng dụng đó tới được, và ghi lại proxy hoặc tuyến nào đã mang nó đi. Nếu yêu cầu là «VM nằm trên mạng công ty», một trình duyệt chạy qua proxy được chọn là bằng chứng cho trình duyệt đó và không hơn.

Hãy sửa chuỗi bên trong máy khách thay vì tắt đường hầm của máy chủ hoặc nới lỏng chính sách chuyển tiếp để một bài kiểm tra được qua. Chuỗi có bốn mắt xích, và một thay đổi bỏ qua một trong số đó sẽ giữ được cho tới lần tới khi script được cập nhật hoặc địa chỉ của máy khách thay đổi.