Yêu cầu của ứng dụng thất bại sau VPN doanh nghiệp nhưng trình duyệt vẫn chạy

Bạn mở cổng thông tin nội bộ trong trình duyệt và nó tải được. Bạn chạy ứng dụng gọi cùng máy chủ đó và nó thất bại, với thông báo không nêu tên tầng nào. Đường hầm đang chở trình duyệt, nên đường hầm không phải nghi phạm đầu tiên. Có bốn thứ nằm giữa yêu cầu của bạn và dịch vụ, và mỗi thứ để lại một dấu vết khác nhau. Đây là thứ tự tôi đi, bắt đầu từ yêu cầu mà ứng dụng thực sự gửi, không phải từ trang cài đặt của ứng dụng khách VPN.

Xem yêu cầu mà ứng dụng thực sự gửi

Trước khi chạm vào cấu hình, hãy để ứng dụng nói cho bạn biết nó làm gì. Một lần bắt một yêu cầu với proxy bị tắt rõ ràng và một phép thử cổng đơn giản cho bạn hai đường cơ sở để các bước sau so sánh. Nếu yêu cầu thành công khi tắt proxy, bạn đã xong ba trong bốn tầng.

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

Chạy hai lệnh cuối tới cùng đích và xem chúng tách nhau ở đâu. Một trình duyệt chạy được cộng một curl chạy được cộng một ứng dụng không chạy được thu hẹp vấn đề vào thứ mà ứng dụng thêm vào: một proxy, một cách vận chuyển hoặc một kích thước thông điệp.

Ứng dụng thừa hưởng một proxy mà không ai cấu hình

Phần lớn các chồng HTTP đọc cấu hình proxy từ hệ điều hành theo mặc định. Ứng dụng khách VPN doanh nghiệp thường cài một proxy như một phần hồ sơ truy cập của nó, nên các yêu cầu đi ra qua một proxy mà lập trình viên chưa từng nhắc trong mã. Trong .NET, trình xử lý mặc định lấy từ cài đặt IE/WinHTTP; Java đọc -Dhttp.proxyHost; Node không có hỗ trợ proxy tích hợp cho tới khi một thư viện thêm vào. Lỗi hiếm khi là một lời từ chối gọn ghẽ, đó là lý do người ta bắt đầu nhìn vào máy chủ.

Phép thử tốn một yêu cầu: tắt proxy rõ ràng trên một trình xử lý và so sánh.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

Nếu cách đó chạy được, bản sửa thuộc về cấu hình của ứng dụng, không phải đường hầm. Lặp lại việc rà soát cho từng môi trường chạy trong dự án, vì mỗi môi trường đọc một nguồn khác và có thể chỉ một cái bị hỏng.

Cổng bạn chọn không phải cổng mà chính sách cho phép

Một máy chủ được định tuyến không phải là dịch vụ được phép. Chính sách doanh nghiệp thường cho phép các cổng web đi ra và bỏ phần còn lại, nên dịch vụ trên 8080 hoặc 1883 không tới được trong khi 443 chạy tốt. Trình duyệt không chứng minh gì ở đây: nó dùng 443 theo định nghĩa.

Xuất bản cùng dịch vụ đó sau 443 và tới nó bằng tên trước khi xin ngoại lệ. Nếu ngoại lệ thực sự cần thiết, hãy giới hạn nó trong một dải nguồn và một đích và coi nó là một phần định nghĩa dịch vụ, không phải đường vòng cá nhân của ai đó.

TCP thô mà đường đi đặt lại

Các kết nối TCP thô sống lâu là tầng hỏng một cách khó hiểu nhất. Một đường đi cho phép lưu lượng web vẫn có thể đặt lại hoặc viết lại TCP đi ra bất thường, và ứng dụng khách báo lỗi ổ cắm mà đọc lên như một sự cố. Các dịch vụ nhắn tin và sự kiện thường cung cấp vận chuyển WebSocket đúng cho loại mạng này, và việc chuyển là tùy chọn của ứng dụng khách, không phải thay đổi đường hầm.

Đổi cách vận chuyển, thử lại và không đổi gì khác trong cùng lần chạy. Phép thử một biến đó cho bạn biết lần đặt lại đến từ đường đi hay từ dịch vụ.

Các kết nối chỉ đóng khi tải trọng lớn

Một yêu cầu thành công rồi chết khoảng một giây sau, nhưng chỉ khi phần thân lớn, đang chỉ vào một giới hạn kích thước ở đâu đó chính giữa. Một thiết bị trung gian đếm byte thông điệp có thể làm rơi kết nối giữa lúc truyền, và ứng dụng khách báo đóng bất thường thay vì hết thời gian chờ.

Chia tải trọng thành từng mảnh ở tầng ứng dụng. Giữ việc này tách khỏi công việc MTU: giảm kích thước gói của đường hầm giúp khi các phiên TCP thông thường dừng ở một số byte cố định, và nó không làm gì cho một thông điệp mà thiết bị trung gian cho là quá lớn.

Cách phân biệt bốn thứ trong một lượt

Ba quan sát giải quyết phần lớn trường hợp. Lỗi xảy ra ngay lập tức hay chỉ khi phần thân lớn? Cùng yêu cầu đó có thành công khi tắt proxy không? Kết quả có đổi khi bạn đổi cổng hoặc cách vận chuyển không? Viết câu trả lời trước lần thay đổi tiếp theo, vì một VPN doanh nghiệp cộng một proxy thừa hưởng cộng một giá trị mặc định của ứng dụng cho bạn ba nguyên nhân khả dĩ cùng lúc.

Giữ một biến cho mỗi phép thử và ghi lại máy chủ đích bạn đã dùng. Không có đường cơ sở đó, người tiếp theo lặp lại cả bốn bước từ đầu.