Appens forespørsler feiler bak en bedrifts-VPN, men nettleseren virker

Du åpner den interne portalen i en nettleser, og den lastes. Du kjører applikasjonen som kaller samme vert, og den feiler, med en melding som ikke navngir noe lag. Tunnelen bærer nettleseren, så tunnelen er ikke den første mistenkte. Fire ting står mellom forespørselen din og tjenesten, og hver av dem etterlater en annen signatur. Dette er rekkefølgen jeg følger, med utgangspunkt i forespørselen appen faktisk sender, og ikke i innstillingssiden til VPN-klienten.

Se på forespørselen appen faktisk sender

Før du rører konfigurasjonen, la appen fortelle deg hva den gjør. Et opptak av én forespørsel med proxyen eksplisitt slått av og en enkel porttest gir deg to grunnlinjer som de neste trinnene sammenlignes med. Hvis forespørselen lykkes med proxyen av, har du allerede gjort tre av de fire lagene.

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

Kjør de to siste mot samme destinasjon og se hvor de skiller lag. En nettleser som virker, pluss curl som virker, pluss en app som ikke virker, snevrer problemet inn til noe appen legger til: en proxy, en transport eller en meldingsstørrelse.

Appen arvet en proxy ingen har konfigurert

De fleste HTTP-stakker leser proxykonfigurasjonen fra operativsystemet som standard. En bedrifts-VPN-klient installerer ofte en som del av tilgangsprofilen sin, så forespørsler går ut gjennom en proxy utvikleren aldri nevnte i koden. I .NET henter standardbehandleren fra IE/WinHTTP-innstillinger; Java leser -Dhttp.proxyHost; Node har ingen innebygd proxy-støtte før et bibliotek legger den til. Feilen er sjelden en ren avvisning, derfor begynner folk å se på serveren.

Testen koster én forespørsel: slå proxyen eksplisitt av på én behandler og sammenlign.

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

Hvis det lykkes, hører rettelsen hjemme i appens konfigurasjon, ikke i tunnelen. Gjenta revisjonen for hvert kjøretidsmiljø i prosjektet, fordi hver av dem leser en annen kilde, og bare én av dem er kanskje ødelagt.

Porten du valgte er ikke porten politikken tillater

En rutet vert er ikke en tillatt tjeneste. Bedriftspolitikk tillater vanligvis utgående nettporter og dropper resten, så en tjeneste på 8080 eller 1883 er utilgjengelig mens 443 virker fint. Nettleseren beviser ingenting her: den bruker 443 per definisjon.

Publiser samme tjeneste bak 443 og nå den ved navn før du ber om et unntak. Hvis unntaket virkelig er nødvendig, begrens det til ett kildeområde og én destinasjon og behandle det som en del av tjenestedefinisjonen, ikke som noens personlige omvei.

Rå TCP som stien tilbakestiller

Langvarige rå TCP-forbindelser er laget som feiler mest forvirrende. En sti som tillater netttrafikk kan fortsatt tilbakestille eller skrive om uvanlig utgående TCP, og klienten rapporterer en socket-feil som leses som et utfall. Meldings- og hendelsestjenester leverer vanligvis en WebSocket-transport nettopp for slike nett, og byttet er et klientvalg, ikke en tunnelendring.

Bytt transport, test på nytt og ikke endre noe annet i samme kjøring. Den testen med én variabel forteller deg om tilbakestillingen kom fra stien eller fra tjenesten.

Forbindelser som bare lukkes ved store nyttelaster

En forespørsel som lykkes og deretter dør omtrent et sekund senere, men bare når kroppen er stor, peker på en størrelsesgrense et sted i midten. En mellomledd som teller meldingsbytes kan droppe forbindelsen midt i overføringen, og klienten rapporterer en unormal lukking i stedet for en tidsavbrudd.

Del nyttelasten i biter på applikasjonslaget. Hold det atskilt fra MTU-arbeid: å senke pakkestørrelsen i tunnelen hjelper når vanlige TCP-økter stopper på et konstant byteantall, og det gjør ingenting for en melding som en mellomledd synes er for stor.

Slik skiller du de fire i én runde

Tre observasjoner avgjør de fleste tilfellene. Skjer feilen umiddelbart eller bare med stor kropp? Lykkes den samme forespørselen med proxyen slått av? Endres resultatet når du bytter port eller transport? Skriv ned svarene før den neste endringen, fordi en bedrifts-VPN pluss en arvet proxy pluss en app-standard gir deg tre sannsynlige årsaker på én gang.

Hold én variabel per test og noter destinasjonsverten du brukte. Uten den grunnlinjen gjentar neste person alle fire trinnene fra begynnelsen.