Vì sao lỗi 403 từ một trang VPN không phải là hỏng proxy

Người dùng ngắt VPN, gặp 403 trên một trang nội bộ và báo rằng proxy đã hỏng. Ba thứ riêng biệt có thể tạo ra trang đó: nguồn gốc từ chối yêu cầu, proxy chuyển tiếp từ chối mở đường hầm, hoặc proxy đòi thông tin đăng nhập của chính nó. Mỗi thứ là câu trả lời đúng cho một câu hỏi khác, và việc gộp chúng thành một trang lỗi chung chung sẽ phá hủy bằng chứng duy nhất bạn có. Phân loại sự từ chối theo thành phần tạo ra nó, rồi so sánh đường mạng mà mỗi thành phần thực sự dùng.

Gọi tên thành phần đã tạo ra 403

Mã trạng thái HTTP thuộc về bên đã gửi nó. Khi nguồn gốc trả 403, nó đã phân tích yêu cầu và quyết định rằng người gọi có thể không có tài nguyên, đó là câu trả lời về ủy quyền chứ không phải sự cố truyền tải. Khi một proxy chuyển tiếp trả 403 cho CONNECT, nó đã từ chối xây đường hầm hoàn toàn, và không có gì ở thượng nguồn từng được liên hệ. Khi nó trả 407, nó muốn thông tin đăng nhập của chính mình, những thứ không liên quan gì đến việc đăng nhập của ứng dụng.

RFC 9110 định nghĩa các vai trò này, bao gồm thử thách dành riêng cho proxy. Hãy đọc trạng thái của chính phản hồi và mọi tiêu đề Proxy-Authenticate trước khi đọc phần thân, vì một trang lỗi HTML thân thiện thường che giấu thành phần nào đã viết nó.

Đường hầm CONNECT che giấu điều gì khỏi bộ chuyển tiếp byte

Khi một proxy trả 200 cho CONNECT, nó đang chuyển tiếp byte và trình duyệt giữ phiên TLS của riêng nó với nguồn gốc. Vì vậy một proxy chuyển tiếp byte không thể đọc 403 đã mã hóa bên trong phiên đó, và nó không bao giờ trở thành tác giả của sự từ chối. Một sự từ chối trước khi đường hầm mở ra là một sự kiện hoàn toàn khác, được tạo ra ở một tầng thấp hơn.

Một proxy ngược kết thúc TLS ở vị trí khác: nó sở hữu ranh giới TLS, phân tích HTTP và có thể ghi lại hoặc chặn phản hồi một cách hợp pháp. Khả năng đó là lựa chọn cấu hình, không phải thuộc tính của proxy nói chung, và nó không cho phép bỏ qua chính sách truy cập của ứng dụng. Đọc phản hồi là một khả năng; quyết định người gọi được thấy gì vẫn là việc của nguồn gốc.

Hệ quả thực tế là bạn phải biết mình đang chạy dạng nào trong ba dạng trước khi diễn giải một 403. Thêm quy tắc kiểm tra HTTP vào một proxy luồng không cho nó khả năng nhìn thấy, và việc mong một bộ chuyển tiếp byte giải thích sự từ chối của nguồn gốc sẽ khiến bạn tìm sai nhật ký.

So sánh đường ra của proxy với địa chỉ đường hầm của trình duyệt

Một trình duyệt kết nối VPN không tự động chuyển một máy chủ proxy riêng sang đường hầm đó. Nguồn gốc thấy địa chỉ ra của proxy, và nếu proxy vẫn đi ra qua tuyến mặc định cục bộ, trang được bảo vệ thấy một địa chỉ chưa bao giờ được cấu hình để tin cậy. Địa chỉ VPN bên trong trên máy tính xách tay là vô hình với nguồn gốc đó. Đây là lý do phổ biến nhất khiến một đường hầm đang hoạt động vẫn cho 403 từ một trang cư xử đúng với mọi người khác.

Hãy kiểm tra hai đường riêng biệt để các địa chỉ không thể bị nhầm lẫn.

curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/private

Yêu cầu đầu tiên cho thấy nguồn gốc trả lời gì cho địa chỉ của bạn, yêu cầu thứ hai cho thấy nó trả lời gì cho địa chỉ của proxy. Một cặp 403 khớp nhau chỉ vào các quy tắc ủy quyền của nguồn gốc; một 200 theo sau bởi 403 chỉ vào đường của proxy. Hãy hỏi chủ sở hữu nguồn gốc xem bộ quy tắc thực sự chấp nhận những địa chỉ nguồn nào thay vì giả định rằng nhóm VPN được bao gồm.

Kiểm tra từng ranh giới bằng một yêu cầu cô lập nó

Cô lập tầng proxy bằng cách yêu cầu nó một thứ mà nó không thể từ chối vì lý do ứng dụng. Một CONNECT tới một máy chủ mà proxy được phép tới, với đầu ra bị bỏ đi, cho bạn biết việc tiếp nhận đường hầm có hoạt động hay không.

curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'

Nếu lệnh đó in 200 cho CONNECT rồi đến bắt tay TLS, việc tiếp nhận của proxy là tốt và 403 sau đó đến từ nguồn gốc. Nếu nó in 407, hãy cung cấp thông tin đăng nhập proxy bằng --proxy-user và lặp lại trước khi kết luận bất cứ điều gì về trang. Nếu nó in 403 trên dòng CONNECT, danh sách cho phép của chính proxy là ranh giới cần xem xét, và ứng dụng không liên quan.

Giữ thông tin đăng nhập ngoài lịch sử shell và ngoài các bản ghi đã dán. Mật khẩu proxy gõ trên dòng lệnh là hiển thị với người dùng cục bộ khác, và một vết CONNECT bị bắt giữ kèm thông tin đăng nhập còn tệ hơn không có vết nào.

Giữ phán quyết dễ đọc thay vì viết lại trang

Khi bạn biết thành phần nào đã từ chối, hãy giữ lại câu trả lời đó. Một proxy ngược đổi nhãn 403 của nguồn gốc thành hết thời gian 504, hoặc thay nó bằng một trang thành công, sẽ che giấu quyết định ủy quyền sau một câu chuyện về tính sẵn sàng và gửi người phản hồi tiếp theo đến nhầm nhóm. Các trang lỗi tùy chỉnh là ổn khi chúng giữ trạng thái và thêm ngữ cảnh.

Bộ nhớ đệm cũng đáng được chăm sóc như vậy. RFC 9111 quy định cách các bộ nhớ đệm chia sẻ có thể dùng lại phản hồi, và một sự từ chối được tạo cho một người gọi không được trao cho người khác như thể đó là sự cho phép. Nếu phản hồi từ chối có được lưu trữ, hãy giữ chúng riêng tư và có phạm vi, và đừng bao giờ thêm quy tắc tươi mới công khai chỉ để giảm lưu lượng thượng nguồn.

Kết thúc bằng một phán quyết bằng văn bản nêu tên thành phần, trạng thái nó tạo ra và địa chỉ nguồn mà nguồn gốc đã thấy. Ghi lại yêu cầu chính xác, cài đặt proxy đang áp dụng và thời điểm, để báo cáo tiếp theo có thể được đối chiếu với cùng bằng chứng thay vì suy ra lại từ ký ức. Bản ghi đó trả lời báo cáo tiếp theo trong vài giây và ngăn cùng một 403 bị chẩn đoán lại thành sự cố VPN.