mitmproxy, DevTools, Gradle: ba tầng phía sau VPN
Loopback không bao giờ đi vào đường hầm. Phân loại triệu chứng thành trình lắng nghe, kho tin cậy hoặc bộ lọc gói, và sửa tầng thực sự đã hỏng.
VPN kết nối, và ba công cụ không liên quan hỏng theo ba cách khác nhau vào cùng buổi chiều. mitmproxy ngừng thấy yêu cầu, Chrome từ chối trình gỡ lỗi, và Gradle ném BindException khi liên kết một socket cục bộ. Nghi ngờ chung là đường hầm chặn localhost. Nó không thể: 127.0.0.1 được xử lý bên trong nhân và không bao giờ đến được bộ điều hợp, chứ đừng nói đến cổng mạng.
Ba tầng, ba hỏng hóc khác nhau
Điều đã thay đổi với máy khách không phải là tuyến đến loopback. Đó là proxy cục bộ, kho tin cậy của máy và bộ lọc gói, và mỗi thứ phá vỡ một phần khác nhau trong quy trình làm việc của lập trình viên. Xếp triệu chứng vào đúng hàng là phần lớn của chẩn đoán:
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
Gần như mọi báo cáo kiểu này bắt đầu từ hàng cuối và đi lên, điều đó ngược. Đường hầm là tầng duy nhất chứng minh được rằng không thể thấy lưu lượng loopback, nên nó đáng bị nghi ngờ ít nhất. Hãy bắt đầu với những gì tiến trình đã liên kết, sau đó hỏi nó tin tưởng chứng chỉ nào, và chỉ sau đó mới xem chính sách trên máy.
Bắt đầu với trình lắng nghe, không phải đường hầm
Khi một proxy trên 127.0.0.1:8080 ngừng nhận lưu lượng, một trong ba điều đã xảy ra: nó chưa bao giờ khởi động, nó liên kết cổng khác, hoặc bộ lọc đã bỏ kết nối loopback. Liệt kê các socket đang lắng nghe trả lời điều đó bằng một lệnh, và cũng cho thấy tiến trình nào sở hữu cổng khi hai công cụ không đồng ý ai đến trước.
Một địa chỉ cục bộ trong tra cứu tuyến xác nhận điều tương tự từ phía bên kia. ip route get về đích loopback báo cáo thiết bị loopback, không bao giờ báo đường hầm, đó là một câu hữu ích để sẵn sàng khi ai đó đề xuất thay đổi định tuyến như giải pháp.
Tầng proxy: môi trường không phải cấu hình
Nhiều khách hàng doanh nghiệp chạy proxy HTTP và mong ứng dụng sử dụng nó. Việc đặt HTTPS_PROXY trong shell sửa các công cụ dòng lệnh tôn trọng nó, và không làm gì cho công cụ đọc tệp cài đặt của chính nó. Gradle, Selenium và gRPC mỗi thứ tham khảo cấu hình riêng, và proxy được xuất trong một terminal là vô hình với daemon do IDE khởi động.
Công cụ container là nơi thường thấy điều này. Loopback của container là của riêng nó, vì vậy 127.0.0.1 bên trong container không bao giờ có nghĩa là proxy của máy chủ; cần địa chỉ máy chủ hoặc cài đặt mạng máy chủ. Một bản sửa hoạt động trong shell và hỏng khi build thường là hàng này, không phải đường hầm.
Tầng tin cậy: công cụ đọc kho khác
Việc chặn là thay đổi thứ hai, và nó tạo ra những lỗi dễ gây hiểu lầm nhất. Máy khách trình bày chứng chỉ riêng cho các kết nối được kiểm tra, vì vậy trình duyệt tin tưởng gốc doanh nghiệp thành công trong khi công cụ có kho CA đi kèm thất bại. requests của Python qua certifi là trường hợp kinh điển: kho của hệ điều hành có thể đúng và yêu cầu vẫn thất bại, vì môi trường thực thi đó không bao giờ đọc nó. Văn bản lỗi hiếm khi nhắc đến việc chặn, đó là lý do hàng này bị chẩn đoán sai là điểm cuối hỏng.
So sánh những gì điểm cuối thực sự trình bày với những gì công cụ đã xác thực. openssl s_client hiển thị chuỗi mà máy chủ đã gửi; đầu ra xác thực của chính công cụ hiển thị điều nó đã quyết định. Khi chúng không khớp, REQUESTS_CA_BUNDLE hoặc SSL_CERT_FILE là đòn bẩy cho môi trường thực thi đó, và gốc doanh nghiệp thuộc về kho mà môi trường đó đọc, không phải một vị trí toàn cục mà chỉ một số công cụ tôn trọng.
Thay đổi phiên bản sửa lỗi SSL là bằng chứng về chính sách tin cậy và mật mã, không phải về VPN. Việc hạ cấp Python khiến máy khách SOAP hoạt động đã thay đổi kho CA đi kèm và cài đặt TLS mặc định; đường mạng không di chuyển.
Tầng bộ lọc: nó cũng có thể bỏ loopback
Thay đổi thứ ba là bộ lọc gói, và một số sản phẩm cài đặt quy tắc bỏ lưu lượng không đi vào đường hầm. Trình lắng nghe cục bộ cũng có thể bị ảnh hưởng. Điều đó biến một socket đang hoạt động thành kết nối bị từ chối hoặc hết thời gian, và lỗi kết quả trông giống lỗi trong ứng dụng hơn là chính sách trên máy.
Quyền sở hữu cổng là nửa còn lại của tầng này. BindException có nghĩa là không thể mở socket, đây là một thất bại khác với kết nối bị từ chối. Kiểm tra xem tiến trình khác đã giữ cổng chưa trước khi đổ lỗi cho bộ lọc, sau đó tìm quy tắc bỏ lưu lượng cục bộ và thêm quyền hẹp nhất mà sản phẩm hỗ trợ. Hai công cụ tranh cùng một cổng gỡ lỗi tạo ra thông báo giống hệt như chặn bởi chính sách, và chỉ một trong số chúng được sửa bằng thay đổi tường lửa.
Cổng gỡ lỗi của Chrome hỏng trong cùng gia đình. Trình duyệt khởi động, trình điều khiển không đến được điểm cuối DevTools, và thông báo nêu tên DevTools thay vì mạng. Các cờ khởi chạy thêm và trình quản lý trình điều khiển dư thừa thay đổi tiến trình nào sở hữu cổng, đó là lý do việc xóa chúng đôi khi trông như sửa được VPN.
Sửa tầng đã hỏng
Sửa tầng đã hỏng, không phải đường hầm. Một trình lắng nghe loopback không thể tiếp cận cần được sửa trình lắng nghe hoặc cổng của nó. Một chứng chỉ không đáng tin cậy cần gốc doanh nghiệp được cài đặt ở nơi môi trường thực thi cụ thể đó nhìn vào, với ngoại lệ được giữ hẹp. Một bộ lọc bỏ lưu lượng cục bộ cần quy tắc cho phép cụ thể thay vì bộ lọc bị vô hiệu hóa, vì vô hiệu hóa cũng mở lại mọi thứ khác mà nó bảo vệ.
Kết nối lại VPN không kiểm tra bất kỳ tầng nào trong số này. Nó chỉ chạy lại thay đổi đã phá vỡ chúng, đó là lý do ba lỗi giống nhau quay lại sau mỗi lần kết nối lại và biến mất sau mỗi lần khởi động lại khiến máy khách không hoạt động.