Żądania aplikacji zawodzą za firmowym VPN, ale przeglądarka działa

Otwierasz wewnętrzny portal w przeglądarce i strona się ładuje. Uruchamiasz aplikację, która wywołuje ten sam host, i ona zawodzi, z komunikatem, który nie nazywa żadnej warstwy. Tunel obsługuje przeglądarkę, więc tunel nie jest pierwszym podejrzanym. Między twoim żądaniem a usługą stoją cztery rzeczy i każda zostawia inny ślad. Oto kolejność, którą stosuję, zaczynając od żądania, które aplikacja naprawdę wysyła, a nie od strony ustawień klienta VPN.

Spójrz na żądanie, które aplikacja naprawdę wysyła

Zanim dotkniesz konfiguracji, pozwól aplikacji powiedzieć, co robi. Przechwycenie jednego żądania z jawnie wyłączonym proxy i prosty test portu dają dwie linie bazowe, z którymi porównuje się kolejne kroki. Jeśli żądanie przechodzi przy wyłączonym proxy, trzy z czterech warstw masz już z głowy.

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

Uruchom dwa ostatnie polecenia na ten sam cel i zobacz, gdzie się rozchodzą. Działająca przeglądarka plus działający curl plus niedziałająca aplikacja zawężają problem do czegoś, co dodaje aplikacja: proxy, transportu albo rozmiaru komunikatu.

Aplikacja odziedziczyła proxy, którego nikt nie skonfigurował

Większość stosów HTTP domyślnie czyta konfigurację proxy z systemu operacyjnego. Firmowy klient VPN często instaluje taki serwer w ramach profilu dostępu, więc żądania wychodzą przez proxy, o którym programista nigdy nie wspomniał w kodzie. W .NET domyślny handler bierze ustawienia z IE/WinHTTP; Java czyta -Dhttp.proxyHost; Node nie ma wbudowanego wsparcia proxy, dopóki nie doda go biblioteka. Awaria rzadko jest czystą odmową, dlatego ludzie zaczynają patrzeć na serwer.

Test kosztuje jedno żądanie: wyłącz proxy jawnie na jednym handlerze i porównaj.

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

Jeśli to działa, poprawka należy do konfiguracji aplikacji, a nie do tunelu. Powtórz audyt dla każdego środowiska uruchomieniowego w projekcie, bo każde czyta inne źródło i tylko jedno może być zepsute.

Wybrany port to nie ten, który dopuszcza polityka

Host z trasą to nie usługa dozwolona. Polityka firmowa zwykle dopuszcza wychodzące porty sieciowe, a resztę odrzuca, więc usługa na 8080 lub 1883 jest nieosiągalna, gdy 443 działa bez problemu. Przeglądarka niczego tu nie dowodzi: z definicji używa 443.

Opublikuj tę samą usługę za 443 i dotrzyj do niej po nazwie, zanim poprosisz o wyjątek. Jeśli wyjątek jest naprawdę potrzebny, ogranicz go do jednego zakresu źródłowego i jednego celu i traktuj jako część definicji usługi, a nie czyjś prywatny obejście.

Surowy TCP, który trasa resetuje

Długotrwałe połączenia surowego TCP to warstwa, która zawodzi najbardziej myląco. Trasa, która dopuszcza ruch sieciowy, nadal może resetować lub przepisywać nietypowy wychodzący TCP, a klient zgłasza błąd gniazda, który czyta się jak awaria. Usługi komunikatów i zdarzeń zwykle dostarczają transport WebSocket właśnie dla takiej sieci, a przełączenie jest opcją klienta, nie zmianą tunelu.

Zmień transport, przetestuj ponownie i nie zmieniaj niczego innego w tym samym przebiegu. Ten test z jedną zmienną mówi, czy reset przyszedł z trasy, czy z usługi.

Połączenia, które zamykają się tylko przy dużych ładunkach

Żądanie, które przechodzi, a potem umiera około sekundy później, ale tylko gdy ciało jest duże, wskazuje na limit rozmiaru gdzieś pośrodku. Pośrednik, który liczy bajty komunikatów, może zrzucić połączenie w środku transferu, a klient zgłasza nieprawidłowe zamknięcie zamiast przekroczenia czasu.

Dziel ładunek na kawałki na poziomie aplikacji. Trzymaj to osobno od pracy z MTU: zmniejszenie rozmiaru pakietu tunelu pomaga, gdy zwykłe sesje TCP zatrzymują się przy stałej liczbie bajtów, a nie robi nic dla komunikatu, który pośrednik uważa za zbyt duży.

Jak odróżnić cztery w jednym przebiegu

Trzy obserwacje rozstrzygają większość przypadków. Czy awaria następuje natychmiast, czy tylko przy dużym ciele? Czy to samo żądanie przechodzi przy wyłączonym proxy? Czy wynik zmienia się po zmianie portu lub transportu? Zapisz odpowiedzi przed kolejną zmianą, bo firmowy VPN plus odziedziczone proxy plus domyślne ustawienie aplikacji dają trzy prawdopodobne przyczyny naraz.

Trzymaj jedną zmienną na test i zapisuj użyty host docelowy. Bez tej linii bazowej następna osoba powtarza wszystkie cztery kroki od początku.