Førespurnadene til appen feilar bak ein verksemds-VPN, men nettlesaren verkar

Du opnar den interne portalen i ein nettlesar, og han lastar. Du køyrer applikasjonen som kallar same vert, og han feilar, med ei melding som ikkje nemner noko lag. Tunnelen ber nettlesaren, så tunnelen er ikkje den første mistenkte. Fire ting står mellom førespurnaden din og tenesta, og kvar av dei etterlet ein annan signatur. Dette er rekkjefølgja eg følgjer, med utgangspunkt i førespurnaden appen faktisk sender, og ikkje i innstillingssida til VPN-klienten.

Sjå på førespurnaden appen faktisk sender

Før du rører konfigurasjonen, la appen fortelje deg kva han gjer. Eit opptak av éin førespurnad med proxyen eksplisitt slått av og ein enkel porttest gjev deg to grunnlinjer som dei neste trinna blir samanlikna med. Viss førespurnaden lukkast med proxyen av, har du alt gjort tre av dei fire laga.

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

Køyr dei to siste mot same destinasjon og sjå kvar dei skil lag. Ein nettlesar som verkar, pluss curl som verkar, pluss ein app som ikkje verkar, snevrar problemet inn til noko appen legg til: ein proxy, ein transport eller ein meldingsstorleik.

Appen arva ein proxy ingen har konfigurert

Dei fleste HTTP-stakkar les proxykonfigurasjonen frå operativsystemet som standard. Ein verksemds-VPN-klient installerer ofte ein som del av tilgangsprofilen sin, så førespurnader går ut gjennom ein proxy utviklaren aldri nemnde i koden. I .NET hentar standardhandsamaren frå IE/WinHTTP-innstillingar; Java les -Dhttp.proxyHost; Node har inga innebygd proxy-støtte før eit bibliotek legg ho til. Feilen er sjeldan ei rein avvising, difor byrjar folk å sjå på tenaren.

Testen kostar éin førespurnad: slå proxyen eksplisitt av på éin handsamar og samanlikn.

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

Viss det lukkast, høyrer rettinga heime i konfigurasjonen til appen, ikkje i tunnelen. Gjenta revisjonen for kvart køyretidsmiljø i prosjektet, fordi kvar av dei les ei anna kjelde, og berre éin av dei er kanskje øydelagd.

Porten du valde er ikkje porten politikken tillèt

Ein ruta vert er ikkje ei tillaten teneste. Verksemdspolitikk tillèt vanlegvis utgåande nettportar og droppar resten, så ei teneste på 8080 eller 1883 er utilgjengeleg medan 443 verkar fint. Nettlesaren beviser ingenting her: han brukar 443 per definisjon.

Publiser same tenesta bak 443 og nå henne ved namn før du ber om eit unntak. Viss unntaket verkeleg er naudsynt, avgrens det til eitt kjeldeområde og éin destinasjon og handsam det som ein del av tenestedefinisjonen, ikkje som ein personleg omveg for nokon.

Rå TCP som stien tilbakestiller

Langvarige rå TCP-samband er laget som feilar mest forvirrande. Ein sti som tillèt nettraflikk kan framleis tilbakestille eller skrive om uvanleg utgåande TCP, og klienten rapporterer ein socket-feil som blir lesen som eit utfall. Meldings- og hendingetenester leverer vanlegvis ein WebSocket-transport nettopp for slike nett, og byttet er eit klientval, ikkje ei tunnelendring.

Byt transport, test på nytt og ikkje endre noko anna i same køyring. Den testen med éin variabel fortel deg om tilbakestillinga kom frå stien eller frå tenesta.

Samband som berre blir lukka ved store nyttelaster

Ein førespurnad som lukkast og deretter døyr om lag eit sekund seinare, men berre når kroppen er stor, peikar på ei storleiksgrense ein stad i midten. Eit mellomledd som tel meldingsbyte kan droppe sambandet midt i overføringa, og klienten rapporterer ei unormal lukking i staden for ein tidsavbrot.

Del nyttelasta i bitar på applikasjonslaget. Hald det skilt frå MTU-arbeid: å senke pakkestorleiken i tunnelen hjelper når vanlege TCP-øktar stoppar på eit konstant bytetal, og det gjer ingenting for ei melding som eit mellomledd synest er for stor.

Slik skil du dei fire i éin runde

Tre observasjonar avgjer dei fleste tilfella. Skjer feilen med ein gong eller berre med stor kropp? Lukkast den same førespurnaden med proxyen slått av? Endrar resultatet seg når du byter port eller transport? Skriv ned svara før den neste endringa, fordi ein verksemds-VPN pluss ein arva proxy pluss ein app-standard gjev deg tre sannsynlege årsaker på éin gong.

Hald éin variabel per test og noter destinasjonsverten du brukte. Utan den grunnlinja gientar neste person alle fire trinna frå byrjinga.