Appforespørsler feiler bak en bedrifts-VPN, mens nettleseren fungerer

Du åpner den interne portalen i nettleseren, og den lastes. Så kjører du applikasjonen som kaller samme vert, og den feiler, med en melding som ikke navngir noe lag. Tunnelen frakter nettleseren, altså er ikke tunnelen den første mistenkte. Mellom forespørselen din og tjenesten ligger fire ting, og hver av dem setter et annet spor. Her er rekkefølgen jeg går etter, med utgangspunkt i forespørselen appen virkelig sender, ikke i innstillingssiden til VPN-klienten.

Se på forespørselen appen virkelig sender

Før du begynner å endre konfigurasjonen, la appen fortelle hva den gjør. Et opptak av en enkelt forespørsel med proxyen uttrykkelig slått av, sammen med en enkel porttest, gir to grunnlinjer som de neste trinnene måles mot. Lykkes forespørselen uten proxy, er tre av fire lag allerede avklart.

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 adresse og legg merke til hvor de går fra hverandre. En nettleser som virker, en curl som virker, og en app som ikke virker, innsnevrer problemet til noe appen selv tilfører: en proxy, en transport eller en meldingsstørrelse.

Proxyen kom inn via appen, ikke via noen innstilling

De fleste HTTP-biblioteker henter proxyoppsettet fra operativsystemet uten at noen har bedt om det. En bedrifts-VPN-klient legger ofte inn en slik proxy som del av tilgangsprofilen, og dermed går trafikken gjennom noe utvikleren aldri skrev om i koden. I .NET leser standardbehandleren IE/WinHTTP-innstillingene; Java leser -Dhttp.proxyHost; Node mangler innebygd proxystøtte til en pakke legges til. Svikt er sjelden en ren avvisning, og det er derfor blikket går mot serveren.

Testen koster en enkelt forespørsel: skru proxyen uttrykkelig av på én behandler og sammenlign.

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

Lykkes det, hører rettelsen til i appens oppsett og ikke i tunnelen. Gjenta gjennomgangen for hvert kjøretidsmiljø i prosjektet, siden hvert av dem leser en annen kilde, og kanskje bare ett av dem er ødelagt.

Porten du valgte er ikke porten retningslinjene åpner for

En rutet vert er ikke det samme som en tillatt tjeneste. Bedriftsretningslinjer slipper vanligvis gjennom webporter og stenger resten, så en tjeneste på 8080 eller 1883 er utilgjengelig mens 443 går helt fint. Nettleseren beviser ingen ting her: den bruker 443 per definisjon.

Legg samme tjeneste bak 443 og nå den ved navn før du ber om unntak. Er unntaket virkelig nødvendig, begrens det til ett kildeområde og én adresse, og behandle det som en del av tjenestebeskrivelsen, ikke som en personlig omvei.

Rå TCP som blir nullstilt underveis

Rå TCP-forbindelser som varer lenge, er laget som svikter på mest forvirrende vis. En rute som slipper gjennom webtrafikk kan likevel nullstille eller skrive om uvanlig utgående TCP, og klienten melder en socketfeil som leses som et avbrudd. Meldings- og hendelsestjenester leverer normalt WebSocket-transport nettopp for slike nett, og byttet er et klientvalg, ikke en endring av tunnelen.

Bytt transport, test igjen, og ikke endre noe annet i samme kjøring. Den ene variabelen avgjør om nullstillingen kom fra ruten eller fra tjenesten.

Forbindelser som bare lukkes ved store laster

En forespørsel som lykkes og deretter dør omtrent ett sekund senere, men bare når kroppen er stor, peker mot en størrelsesgrense et sted i midten. Et mellomledd som teller bytes i meldingene, kan slippe forbindelsen midt i overføringen, og klienten melder unormal lukking i stedet for tidsavbrudd.

Del lasten opp på applikasjonsnivå. Hold dette atskilt fra MTU-arbeidet: å senke pakkestørrelsen i tunnelen hjelper når vanlige TCP-økter stopper på et fast bytantall, og gjør ingenting for en melding som et mellomledd finner for stor.

Slik skiller du de fire i én gjennomgang

Tre observasjoner avgjør de fleste sakene. Skjer feilen straks, eller bare ved stor kropp? Lykkes samme forespørsel med proxyen av? Endres utfallet når du bytter port eller transport? Noter svarene før neste endring, for en bedrifts-VPN pluss en arvet proxy pluss en app-standard gir tre mulige årsaker samtidig.

Hold én variabel per test, og skriv ned destinasjonsverten du brukte. Uten den grunnlinjen gjentar neste person alle fire trinnene fra starten.