Toepassings se versoeke faal agter ’n korporatiewe VPN, maar die blaaier werk

Een toepassing breek terwyl die blaaier die werf laai. Stap deur die proxy wat dit geërf het, die portbeleid, rou TCP-herstellings en die grense op vragpakkette, in daardie volgorde.

Jy maak die interne portaal in ’n blaaier oop en dit laai. Jy hardloop die toepassing wat dieselfde gasheer aanroep, en dit faal met ’n boodskap wat geen laag noem nie. Die tonnel dra die blaaier, so die tonnel is nie die eerste verdagte nie. Vier dinge sit tussen jou versoek en die diens, en elkeen laat verskillende handtekeninge. Hier is die volgorde wat ek volg, vanaf die versoek wat die toepassing werklik stuur, nie vanaf die VPN-kliënt se instellingsbladsy nie.

Kyk na die versoek wat die toepassing werklik stuur

Voordat jy aan die opstelling raak, laat die toepassing jou vertel wat dit doen. ’n Een-versoek-opname met die proxy eksplisiet afgeskakel en ’n gewone porttoets gee jou twee basislyne waarmee die later stappe vergelyk.

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 die laaste twee met dieselfde bestemming uit en kyk waar hulle uiteenloop. ’n Blaaier wat werk plus ’n curl wat werk plus ’n toepassing wat nie werk nie, vernou die probleem tot iets wat die toepassing byvoeg: ’n proxy, ’n transport, of ’n boodskapprootte.

Die toepassing het ’n proxy geërf wat niemand opgestel het nie

Die meeste HTTP-stapels lees proxy-opstelling by verstek van die bedryfstelsel. ’n Korporatiewe VPN-kliënt installeer dikwels een as deel van sy toegangsprofiel, so versoeke verlaat die netwerk deur ’n proxy wat die ontwikkelaar nooit in die kode genoem het nie. In .NET trek die verstekhandler uit IE/WinHTTP-instellings; Java lees -Dhttp.proxyHost; Node het geen ingeboude proxy-ondersteuning tot ’n biblioteek dit byvoeg nie. Die mislukking is selde ’n skoon weiering, en daarom begin mense na die bediener kyk.

Die toets kos een versoek: skakel die proxy eksplisiet af op een handler en vergelyk.

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

As dit slaag, hoort die regstelling in die toepassing se opstelling, nie in die tonnel nie. Herhaal die oudit per looptyd in die projek, want elkeen lees ’n verskillende bron en net een van hulle is dalk stukkend.

Die port wat jy gekies het, is nie die port wat die beleid toelaat nie

’n Gerouteerde gasheer is nie ’n toegelate diens nie. Korporatiewe beleid laat gewoonlik uitgaande web-porte toe en laat die res val, so ’n diens op 8080 of 1883 is onbereikbaar terwyl 443 goed werk. Die blaaier bewys hier niks: dit gebruik 443 per definisie.

Publiseer dieselfde diens agter 443 en bereik dit op naam voordat jy enige uitsondering vra. As die uitsondering werklik nodig is, beperk dit tot een bronreeks en een bestemming, en behandel dit as deel van die diensdefinisie, nie as iemand se persoonlike noodoplossing nie.

Rou TCP wat die pad herstel

Langdurige rou TCP-verbindings is die laag wat die verwarrendste faal. ’n Pad wat webverkeer toelaat, kan steeds onuisselike uitgaande TCP herstel of herskryf, en die kliënt rapporteer ’n sokfout wat soos ’n diensonderbreking klink. Boodskap- en gebeurtenisdienste stuur gewoonlik ’n WebSocket-transport vir presies hierdie soort netwerk, en die oorskakeling is ’n kliëntopsie, nie ’n tonnelverandering nie.

Skakel die transport om, toets weer, en verander niks anders in dieselfde lopie nie. Daardie enkelveranderlike toets sê of die herstelling van die pad of van die diens gekom het.

Verbindings wat net by groot vragpakkette sluit

’n Versoek wat slaag en dan omtrent ’n sekonde later sterf, maar net wanneer die liggaam groot is, wys na ’n groottebeperking iewers in die middel. ’n Tussenlaag wat boodskapgrepe tel, kan die verbinding midde-in die oordrag laat val, en die kliënt rapporteer ’n sluiting wat nie normaal is nie eerder as ’n time-out.

Verdeel die vragpak in stukke op die toepassingslaag. Hou dit apart van MTU-werk: om die tonnel se pakketgrootte te verlaag help wanneer gewone TCP-sessies by ’n konstante grepetelling vasval, en dit doen niks vir ’n boodskap wat ’n tussenlaag te groot vind nie.

Hoe om die vier in een lopie uitmekaar te hou

Drie waarnemings beslis die meeste gevalle. Gebeur die mislukking dadelik of net met ’n groot liggaam? Slaag dieselfde versoek met die proxy afgeskakel? Verander die uitkoms wanneer jy die port of die transport omruil? Skryf die antwoorde neer voor die volgende verandering, want ’n korporatiewe VPN plus ’n geërfde proxy plus ’n toepassingverstek gee jou drie moontlike oorsake tegelyk.

Hou een veranderlike per toets en teken die bestemming-gasheer aan wat jy gebruik het. Sonder daardie basislyn herhaal die volgende persoon al vier stappe van die begin af.

Verwante artikels