Požadavky aplikace selhávají za podnikovým VPN, ale prohlížeč funguje

Otevřete interní portál v prohlížeči a načte se. Spustíte aplikaci, která volá stejný hostitel, a ta selže se zprávou, která nepojmenuje žádnou vrstvu. Tunel přenáší prohlížeč, takže tunel není první podezřelý. Mezi vaším požadavkem a službou stojí čtyři věci a každá zanechává jiný podpis. Toto je pořadí, kterým postupuji, počínaje požadavkem, který aplikace skutečně odesílá, ne stránkou nastavení VPN klienta.

Podívejte se na požadavek, který aplikace skutečně odesílá

Než sáhnete na konfiguraci, nechte aplikaci říct, co dělá. Zachycení jednoho požadavku s výslovně vypnutým proxy a prostý test portu vám dají dvě základní linie, se kterými se porovnávají další kroky. Pokud požadavek s vypnutým proxy projde, máte tři ze čtyř vrstev za sebou.

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

Spusťte poslední dva se stejnou destinací a sledujte, kde se rozcházejí. Fungující prohlížeč plus fungující curl plus aplikace, která nefunguje, zužuje problém na něco, co aplikace přidává: proxy, transport nebo velikost zprávy.

Aplikace zdědila proxy, které nikdo nenastavil

Většina HTTP stacků čte konfiguraci proxy ve výchozím stavu z operačního systému. Podnikový VPN klient ho často instaluje jako součást svého přístupového profilu, takže požadavky odcházejí přes proxy, které vývojář v kódu nikdy nezmínil. V .NET výchozí handler čte nastavení IE/WinHTTP; Java čte -Dhttp.proxyHost; Node nemá vestavěnou podporu proxy, dokud ji nepřidá knihovna. Selhání je málokdy čisté odmítnutí, a proto se lidé začnou dívat na server.

Test stojí jeden požadavek: vypněte proxy výslovně u jednoho handleru a porovnejte.

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

Pokud to projde, oprava patří do konfigurace aplikace, ne do tunelu. Zopakujte audit pro každé runtime v projektu, protože každé čte jiný zdroj a rozbité může být jen jedno.

Port, který jste vybrali, není port, který politika povoluje

Směrovaný hostitel není povolená služba. Podniková politika obvykle povoluje odchozí webové porty a zbytek zahazuje, takže služba na 8080 nebo 1883 je nedostupná, zatímco 443 funguje bez problémů. Prohlížeč zde nic nedokazuje: používá 443 z definice.

Publikujte stejnou službu za 443 a dosáhněte na ni jménem, než požádáte o výjimku. Pokud je výjimka skutečně potřeba, ohraničte ji jedním rozsahem zdrojů a jednou destinací a berte ji jako součást definice služby, ne jako něčí osobní obejití.

Surové TCP, které cesta resetuje

Dlouhotrvající spojení surového TCP jsou vrstva, která selhává nejmatoucněji. Cesta, která povoluje webový provoz, může přesto resetovat nebo přepisovat neobvyklé odchozí TCP, a klient hlásí chybu socketu, která se čte jako výpadek. Služby pro zprávy a události obvykle dodávají transport WebSocket právě pro takovou síť a přepnutí je volba klienta, ne změna tunelu.

Přepněte transport, otestujte znovu a v témže běhu neměňte nic jiného. Tento test s jednou proměnnou vám řekne, zda reset přišel z cesty, nebo ze služby.

Spojení, která se zavírají jen u velkých dat

Požadavek, který projde a pak asi o sekundu později zemře, ale jen když je tělo velké, ukazuje na limit velikosti někde uprostřed. Prostředník, který počítá bajty zpráv, může spojení uprostřed přenosu zahodit a klient hlásí abnormální uzavření místo časového limitu.

Rozdělte data na úrovni aplikace. Držte to oddělené od práce s MTU: zmenšení velikosti paketů tunelu pomáhá, když se běžné TCP relace zaseknou na stálém počtu bajtů, a pro zprávu, kterou prostředník považuje za příliš velkou, neudělá nic.

Jak rozeznat čtyři v jednom průchodu

Tři pozorování rozhodnou většinu případů. Nastává selhání hned, nebo jen u velkého těla? Projde stejný požadavek s vypnutým proxy? Změní se výsledek, když přepnete port nebo transport? Zapište odpovědi před další změnou, protože podnikový VPN plus zděděné proxy plus výchozí nastavení aplikace vám dají tři pravděpodobné příčiny najednou.

Držte jednu proměnnou na test a zaznamenejte cílového hostitele, kterého jste použili. Bez této základní linie další člověk zopakuje všechny čtyři kroky od začátku.