Požiadavky aplikácie zlyhávajú za firemným VPN, ale prehliadač funguje

Otvoríte interný portál v prehliadači a načíta sa. Spustíte aplikáciu, ktorá volá toho istého hostiteľa, a tá zlyhá, so správou, ktorá nepomenuje žiadnu vrstvu. Tunel prenáša prehliadač, takže tunel nie je prvý podozrivý. Medzi vašou požiadavkou a službou stoja štyri veci a každá zanecháva inú stopu. Toto je poradie, ktorým postupujem, začínajúc požiadavkou, ktorú aplikácia skutočne odosiela, nie stránkou nastavení VPN klienta.

Pozrite sa na požiadavku, ktorú aplikácia skutočne odosiela

Skôr než sa dotknete konfigurácie, nechajte aplikáciu povedať, čo robí. Zachytenie jednej požiadavky s výslovne vypnutým proxy a jednoduchý test portu vám dajú dve základné línie, s ktorými sa porovnávajú ďalšie kroky. Ak požiadavka s vypnutým proxy prejde, máte tri zo štyroch vrstiev 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

Spustite posledné dva príkazy na rovnaký cieľ a sledujte, kde sa rozchádzajú. Fungujúci prehliadač plus fungujúci curl plus nefungujúca aplikácia zužujú problém na niečo, čo aplikácia pridáva: proxy, transport alebo veľkosť správy.

Aplikácia zdedila proxy, ktoré nikto nenastavil

Väčšina HTTP zásobníkov číta konfiguráciu proxy predvolene z operačného systému. Firemný VPN klient ho často inštaluje ako súčasť svojho prístupového profilu, takže požiadavky odchádzajú cez proxy, ktoré vývojár v kóde nikdy nespomenul. V .NET predvolený obslužný program číta nastavenia IE/WinHTTP; Java číta -Dhttp.proxyHost; Node nemá vstavanú podporu proxy, kým ju nepridá knižnica. Zlyhanie je málokedy čisté odmietnutie, preto sa ľudia začnú pozerať na server.

Test stojí jednu požiadavku: vypnite proxy výslovne na jednom obslužnom programe a porovnajte.

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

Ak to prejde, oprava patrí do konfigurácie aplikácie, nie do tunela. Zopakujte audit pre každé runtime v projekte, pretože každé číta iný zdroj a pokazené môže byť len jedno.

Port, ktorý ste vybrali, nie je port, ktorý politika povoľuje

Smerovaný hostiteľ nie je povolená služba. Firemná politika zvyčajne povoľuje odchádzajúce webové porty a zvyšok zahadzuje, takže služba na 8080 alebo 1883 je nedostupná, kým 443 funguje dobre. Prehliadač tu nič nedokazuje: používa 443 z definície.

Publikujte tú istú službu za 443 a dosiahnite ju podľa mena, skôr než požiadate o výnimku. Ak je výnimka naozaj potrebná, ohraničte ju jedným rozsahom zdrojov a jedným cieľom a berte ju ako súčasť definície služby, nie ako niekoho osobné obchádzanie.

Surové TCP, ktoré cesta resetuje

Dlhotrvajúce spojenia surového TCP sú vrstva, ktorá zlyháva najconfúznejšie. Cesta, ktorá povoľuje webovúprevádzku, môže stále resetovať alebo prepisovať neobvyklé odchádzajúce TCP, a klient hlási chybu socketu, ktorá sa číta ako výpadok. Služby správ a udalostí zvyčajne dodávajú transport WebSocket práve pre takúto sieť a prepnutie je voľba klienta, nie zmena tunela.

Prepnete transport, otestujte znova a v tom istom behu nemeňte nič iné. Ten test s jednou premennou vám povie, či reset prišiel z cesty alebo zo služby.

Spojenia, ktoré sa zatvárajú iba pri veľkých dátach

Požiadavka, ktorá prejde a potom o približne sekundu zomrie, ale iba keď je telo veľké, ukazuje na limit veľkosti niekde v strede. Sprostredkovateľ, ktorý počíta bajty správ, môže spojenie zvaliť v polovici prenosu a klient hlási abnormálne zatvorenie namiesto časového limitu.

Rozdeľte záťaž na časti na úrovni aplikácie. Držte to oddelene od práce s MTU: zmenšenie veľkosti paketu tunela pomáha, keď sa bežné TCP relácie zaseknú na stálom počte bajtov, a pre správu, ktorú sprostredkovateľ považuje za príliš veľkú, nič neurobí.

Ako rozlíšiť štyri v jednom prechode

Tri pozorovania rozhodnú väčšinu prípadov. Nastáva zlyhanie hneď, alebo iba pri veľkom tele? Prejde tá istá požiadavka s vypnutým proxy? Zmení sa výsledok, keď prepnete port alebo transport? Zapíšte odpovede pred ďalšou zmenou, pretože firemný VPN plus zdedené proxy plus predvolené nastavenie aplikácie vám dajú tri pravdepodobné príčiny naraz.

Držte jednu premennú na test a zaznamenajte cieľového hostiteľa, ktorého ste použili. Bez tej základnej línie ďalší človek zopakuje všetky štyri kroky od začiatku.