Appens anmodninger fejler bag en virksomheds-VPN, men browseren virker

Én app går ned, mens browseren indlæser siden. Gå gennem den proxy, den har arvet, portpolitikken, rå TCP-nulstillinger og grænserne for nyttelastens størrelse i den rækkefølge.

Du åbner den interne portal i en browser, og den indlæses. Du kører applikationen, som kalder den samme vært, og den fejler med en besked, der ikke nævner noget lag. Tunnelen bærer browseren, så tunnelen er ikke den første mistænkte. Der ligger fire ting mellem din anmodning og tjenesten, og hver af dem efterlader en anden signatur. Her er den rækkefølge, jeg følger, startende fra den anmodning, appen faktisk sender, og ikke fra VPN-klientens indstillingsside.

Se på den anmodning, appen faktisk sender

Før du rører ved konfigurationen, så lad appen fortælle, hvad den gør. En optagelse af én anmodning med proxyen eksplicit slået fra og en simpel porttest giver dig to basislinjer, som de næste trin sammenlignes med. Hvis anmodningen lykkes med proxyen slået fra, er tre af de fire lag allerede klaret.

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ør de sidste to mod den samme destination, og se hvor de skilles. En browser, der virker, plus curl, der virker, plus en app, der ikke virker, indsnævrer problemet til noget, appen tilføjer: en proxy, en transport eller en meddelelsesstørrelse.

Appen arvede en proxy, som ingen har konfigureret

De fleste HTTP-stakke læser proxykonfiguration fra operativsystemet som standard. En virksomheds-VPN-klient installerer ofte en som en del af sin adgangsprofil, så anmodninger forlader netværket gennem en proxy, som udvikleren aldrig har nævnt i koden. I .NET trækker standardhandleren fra IE/WinHTTP-indstillinger; Java læser -Dhttp.proxyHost; Node har ingen indbygget proxyunderstøttelse, før et bibliotek tilføjer den. Fejlen er sjældent en ren afvisning, og derfor begynder folk at kigge på serveren.

Testen koster én anmodning: slå proxyen eksplicit fra på én handler, og sammenlign.

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

Hvis det lykkes, hører rettelsen i appens konfiguration, ikke i tunnelen. Gentag revisionen for hver runtime i projektet, fordi hver af dem læser en anden kilde, og kun én af dem er måske i stykker.

Den port, du valgte, er ikke den port, politikken tillader

En routet vært er ikke en tilladt tjeneste. Virksomhedspolitik tillader ofte udgående webporte og dropper resten, så en tjeneste på 8080 eller 1883 er utilgængelig, mens 443 virker fint. Browseren beviser intet her: den bruger 443 per definition.

Udgiv den samme tjeneste bag 443, og nå den ved navn, før du beder om en undtagelse. Hvis undtagelsen virkelig er nødvendig, så afgræns den til ét kildeområde og én destination, og behandl den som en del af tjenestedefinitionen, ikke som nogens personlige omvej.

Rå TCP, som stien nulstiller

Langvarige rå TCP-forbindelser er det lag, der fejler mest forvirrende. En sti, der tillader webtrafik, kan stadig nulstille eller omskrive usædvanlig udgående TCP, og klienten rapporterer en socketfejl, der læses som et udfald. Besked- og begivenhedstjenester leverer normalt en WebSocket-transport netop til denne slags netværk, og skiftet er en klientindstilling, ikke en tunnelændring.

Skift transport, test igen, og ændr intet andet i samme kørsel. Den test med én variabel fortæller, om nulstillingen kom fra stien eller fra tjenesten.

Forbindelser, der kun lukker ved store nyttelaster

En anmodning, der lykkes og derefter dør omkring et sekund senere, men kun når kroppen er stor, peger på en størrelsesgrænse et sted i midten. En mellemled, der tæller meddelelsesbytes, kan droppe forbindelsen midt i overførslen, og klienten rapporterer en unormal lukning i stedet for en timeout.

Opdel nyttelasten på applikationslaget. Hold det adskilt fra MTU-arbejde: at sænke tunnelens pakkestørrelse hjælper, når almindelige TCP-sessioner går i stå ved et konstant byteantal, og det gør intet for en meddelelse, som en mellemled anser for stor.

Sådan skelner du de fire i én kørsel

Tre observationer afgør de fleste sager. Sker fejlen med det samme eller kun med en stor krop? Lykkes den identiske anmodning med proxyen slået fra? Ændres resultatet, når du skifter port eller transport? Skriv svarene ned før den næste ændring, fordi en virksomheds-VPN plus en arvet proxy plus en appstandard giver dig tre sandsynlige årsager på én gang.

Hold én variabel pr. test, og noter den destinationsvært, du brugte. Uden den basislinje gentager den næste person alle fire trin fra begyndelsen.

Relaterede artikler