Verzoeken van de app mislukken achter een bedrijfs-VPN, maar de browser werkt

Je opent het interne portaal in een browser en het laadt. Je start de applicatie die dezelfde host aanroept en hij faalt, met een melding die geen enkele laag noemt. De tunnel draagt de browser, dus de tunnel is niet de eerste verdachte. Vier dingen staan tussen je verzoek en de dienst, en elk laat een andere signatuur achter. Dit is de volgorde die ik aanhoud, beginnend bij het verzoek dat de app echt verstuurt, en niet bij de instellingenpagina van de VPN-client.

Kijk naar het verzoek dat de app echt verstuurt

Voordat je de configuratie aanraakt, laat de app vertellen wat hij doet. Een opname van één verzoek met de proxy expliciet uitgeschakeld en een simpele poorttest geven je twee basislijnen waarmee de volgende stappen worden vergeleken. Als het verzoek slaagt met de proxy uit, heb je drie van de vier lagen al gehad.

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

Voer de laatste twee uit naar dezelfde bestemming en kijk waar ze uiteenlopen. Een werkende browser plus een werkende curl plus een app die niet werkt, beperken het probleem tot iets wat de app toevoegt: een proxy, een transport of een berichtgrootte.

De app heeft een proxy geërfd die niemand heeft ingesteld

De meeste HTTP-stacks lezen de proxyconfiguratie standaard uit het besturingssysteem. Een bedrijfs-VPN-client installeert er vaak een als onderdeel van zijn toegangsprofiel, zodat verzoeken via een proxy naar buiten gaan die de ontwikkelaar nooit in de code heeft genoemd. In .NET leest de standaardhandler de instellingen van IE/WinHTTP; Java leest -Dhttp.proxyHost; Node heeft geen ingebouwde proxyondersteuning tot een bibliotheek die toevoegt. De fout is zelden een schone weigering, daarom gaan mensen naar de server kijken.

De test kost één verzoek: schakel de proxy expliciet uit op één handler en vergelijk.

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

Als dat slaagt, hoort de oplossing in de configuratie van de app, niet in de tunnel. Herhaal de controle voor elke runtime in het project, want elk leest een andere bron en misschien is er maar één stuk.

De poort die je koos is niet de poort die het beleid toestaat

Een gerouteerde host is geen toegestane dienst. Bedrijfsbeleid staat meestal uitgaande webpoorten toe en gooit de rest weg, dus een dienst op 8080 of 1883 is onbereikbaar terwijl 443 prima werkt. De browser bewijst hier niets: hij gebruikt per definitie 443.

Publiceer dezelfde dienst achter 443 en bereik hem op naam voordat je om een uitzondering vraagt. Als de uitzondering echt nodig is, beperk haar tot één bronbereik en één bestemming en behandel haar als onderdeel van de dienstdefinitie, niet als iemands persoonlijke omweg.

Ruwe TCP die het pad reset

Langdurige ruwe TCP-verbindingen zijn de laag die het verwarrendst faalt. Een pad dat webverkeer toestaat kan nog steeds ongebruikelijk uitgaand TCP resetten of herschrijven, en de client meldt een socketfout die als een storing leest. Bericht- en gebeurtenisdiensten leveren meestal een WebSocket-transport juist voor zulke netwerken, en overstappen is een clientoptie, geen tunnelwijziging.

Wissel van transport, test opnieuw en verander in dezelfde run niets anders. Die test met één variabele vertelt je of de reset van het pad of van de dienst kwam.

Verbindingen die alleen bij grote payloads sluiten

Een verzoek dat slaagt en dan ongeveer een seconde later sterft, maar alleen als de body groot is, wijst op een groottelimiet ergens in het midden. Een tussenlaag die berichtbytes telt, kan de verbinding midden in de overdracht laten vallen, en de client meldt een abnormale sluiting in plaats van een time-out.

Splits de payload op applicatieniveau. Houd dat gescheiden van MTU-werk: een kleinere pakketgrootte van de tunnel helpt wanneer gewone TCP-sessies bij een constant byteaantal vastlopen, en het doet niets voor een bericht dat een tussenlaag te groot vindt.

Hoe je de vier in één rondgang onderscheidt

Drie observaties beslechten de meeste gevallen. Gebeurt de fout meteen of alleen bij een grote body? Slaagt hetzelfde verzoek met de proxy uit? Verandert de uitkomst als je van poort of transport wisselt? Schrijf de antwoorden op vóór de volgende wijziging, want een bedrijfs-VPN plus een geërfde proxy plus een app-standaard geven je drie plausibele oorzaken tegelijk.

Houd één variabele per test aan en noteer de bestemmingshost die je gebruikte. Zonder die basislijn herhaalt de volgende persoon alle vier stappen vanaf het begin.