VPN trên Mac và proxy PAC: hai quyết định, không phải một cài đặt

Mac của bạn tải một tập lệnh chính sách rồi hỏi tập lệnh đó rằng một yêu cầu nên dùng trung gian nào, trong khi đường hầm chỉ quyết định cách đến bước nhảy đã chọn. Cả hai câu trả lời đều kết thúc trên cùng một socket, nên một yêu cầu thất bại sau khi cả hai đã thành công trông như một lỗi trong khi thực ra là hai. Tách việc tải xuống khỏi việc chọn, và việc chọn khỏi tuyến đường, là phần lớn công việc trong những phiếu này. Thứ tự dưới đây theo đúng những gì macOS thực sự làm, cùng các kiểm tra giúp mỗi giai đoạn hiện rõ.

Nơi địa chỉ PAC và proxy tách nhau

Một địa chỉ như https://config.corp.example/proxy.pac đặt tên cho một tài liệu cần tải xuống, và tài liệu đó đặt tên cho một máy chủ để gửi lưu lượng qua. Dán URL vào trường máy chủ của proxy yêu cầu ứng dụng khách mở một kết nối proxy tới một máy chủ tệp không bao giờ lắng nghe kết nối như vậy. Bên trong tệp có một hàm mà ứng dụng khách gọi cho mỗi yêu cầu, và giá trị trả về của nó là bước nhảy tiếp theo cho đúng đích đó. Sự gián tiếp này giải thích vì sao hai máy trên cùng một dịch vụ mạng có thể hành xử khác nhau dù cả hai đều có URL đúng. Nó cũng giải thích vì sao một thay đổi chính sách có hiệu lực mà không ai chạm vào chính proxy.

Đọc tập lệnh trước khi diễn giải bất cứ điều gì ở hạ nguồn, vì các quy tắc bên trong mang theo ngoại lệ của tổ chức và thứ tự áp dụng chúng. Một dải rộng sớm có thể che khuất một hậu tố nội bộ về sau, và một máy chủ lẽ ra phải bỏ qua proxy một cách rõ ràng vẫn tiếp tục dùng nó. Khi ai đó khẳng định chính sách sai, tập lệnh là nơi duy nhất để khẳng định đó được giải quyết.

Tập lệnh phải được tải về trước khi nó quyết định bất cứ điều gì

Tải chính sách cần một tên đã được phân giải và một tuyến đường tới thứ phục vụ tệp, còn một đường hầm đã kết nối không bảo đảm cả hai. Nếu máy chủ chỉ được phân giải qua DNS riêng, trình phân giải đang dùng tại thời điểm đó quyết định liệu việc tải có thể bắt đầu. Nếu máy chủ nằm trong một dải riêng, tuyến đường phải tồn tại từ máy này chứ không phải từ laptop của đồng nghiệp. Một bản sao được lưu đệm từ phiên trước che giấu tất cả những điều này cho đến khi bộ nhớ đệm hết hạn hoặc máy khởi động lại.

Chạy ba kiểm tra dưới đây theo thứ tự và dừng ở lỗi đầu tiên, vì các giai đoạn không chia sẻ nguyên nhân. Cùng nhau chúng cho thấy chính sách có được cấu hình không, có thể tiếp cận không, và nó trả về gì.

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

Lệnh đầu tiên in từ điển proxy cho dịch vụ đang hoạt động, bao gồm mọi URL cấu hình tự động mà hệ thống đang giữ. Lệnh thứ hai báo cáo URL gắn với một dịch vụ có tên, điều này quan trọng trên laptop di chuyển giữa Wi-Fi và Ethernet. Lệnh thứ ba lấy tệp mà không kết xuất nó, nên 404, hết thời gian và lỗi trình phân giải vẫn phân biệt được. Nếu lệnh cuối đó trả về tập lệnh trong khi ứng dụng vẫn thất bại, vấn đề đã vượt qua bước tải.

Câu trả lời DIRECT thực sự bỏ qua điều gì

Đặc tả PAC cung cấp cho ứng dụng khách một từ vựng nhỏ, và DIRECT là một trong những từ đó. Từ đó bảo ứng dụng khách bỏ qua proxy cho yêu cầu ấy và không nói gì về việc socket sau đó dùng giao diện nào. Một socket trực tiếp trên đường hầm đầy đủ vẫn ra ngoài qua VPN và vẫn cho đích thấy địa chỉ thoát của đường hầm.

Đọc DIRECT như nằm ngoài VPN là sai lầm khiến người ta đi nhầm bảng cài đặt. Hình ảnh phản chiếu cũng phổ biến không kém, vì có thể đến một proxy riêng qua tuyến đường chia tách trong khi phần còn lại của máy ở ngoài đường hầm. Những gì đích báo cáo khi đó thuộc về lối ra của chính proxy, nơi có thể ở một quốc gia khác. Viết kỳ vọng cho một máy chủ nội bộ và một máy chủ công cộng nhanh chóng phơi bày điều này, vì tập lệnh thường trả lời hai bên khác nhau. Khi bạn biết bước nhảy nào tạo ra địa chỉ, báo cáo không còn bí ẩn nữa.

Ba lỗi xuất hiện như một trang lỗi duy nhất

Chính sách có thể tải xuống thất bại, proxy đã chọn có thể không tiếp cận được, và một yêu cầu đến dịch vụ vẫn có thể bị từ chối ở đó. Cả ba đến như hết thời gian hoặc một trang lỗi chung, và không cái nào nêu tên giai đoạn bị hỏng. Ghi lại quyết định bên cạnh lỗi là điều tách chúng ra. Hai đầu dò dưới đây kiểm tra bước nhảy mà tập lệnh đã chọn, một cho mỗi nhánh nó có thể trả về.

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

Một kết nối hoàn tất tới proxy chuyển câu hỏi sang xác thực hoặc sang chính sách riêng của proxy, vốn có chủ khác. Một kết nối hoàn tất tới máy chủ nội bộ mà không có proxy trên đường loại trừ tuyến đường và chỉ vào chính sách. Cả hai lệnh đều bỏ qua từ điển proxy của macOS trừ khi shell xuất biến proxy, nên hãy xóa chúng trước. Không đầu dò nào chứng minh cái kia, và đó là lý do một trang lỗi đánh lừa lâu đến vậy.

Cần bàn giao gì cùng phiếu

Gửi dịch vụ mạng đang hoạt động, URL PAC, kết quả đánh giá cho máy chủ thất bại và giai đoạn nơi lỗi xuất hiện. Bốn thứ đó cho phép người tiếp theo tái tạo quyết định thay vì đoán lớp nào liên quan. Thêm trạng thái đường hầm tại thời điểm kiểm tra, vì kết quả thu được trước khi kết nối lại đã cũ. Giữ cả bản sửa đổi của tập lệnh, vì tệp chính sách thay đổi mà không báo trước và câu trả lời hôm qua có thể không còn đúng.

Ghi lại cách ứng dụng khách hành xử khi không thể lấy tập lệnh, vì các cách triển khai khác nhau và quyết định proxy không phải là công tắc ngắt toàn thiết bị. Một số quay về kết nối trực tiếp và số khác thất bại đóng, và sự khác biệt đó thay đổi việc một sự cố trông như proxy hỏng hay như chính sách đang hoạt động. Xác nhận hành vi cho đúng ứng dụng khách và phiên bản trước khi dựa vào nó trong một sự cố.