Oanfragen fan de app mislearje efter in bedriuws-VPN, mar de browser wurket

Do iepenest it ynterne portaal yn in browser en it ladelet. Do startest de applikaasje dy’t deselde host oanropt en hy mislearret, mei in berjocht dat gjin ien laach neamt. De tunnel draacht de browser, dus de tunnel is net de earste fertochte. Fjouwer dingen steane tusken dyn oanfraach en de tsjinst, en elk lit in oar spoor efter. Dit is de folchoarder dy’t ik rin, begjinnend by de oanfraach dy’t de app echt stjoert, en net by de ynstellingsside fan ’e VPN-klant.

Sjoch nei de oanfraach dy’t de app echt stjoert

Foardatsto de konfiguraasje oanrekest, lit de app dy fertelle wat er docht. In opname fan ien oanfraach mei de proxy iepenbier útskeakele en in ienfâldige poarttest jouwe dy twa basislinen dêr’t de folgjende stappen mei ferlike wurde. As de oanfraach slagget mei de proxy út, hast trije fan ’e fjouwer lagen al dien.

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

Fier de lêste twa út nei deselde bestimming en sjoch wêr’t se útinoar geane. In browser dy’t wurket plus in curl dy’t wurket plus in app dy’t net wurket, ferneiwerje it probleem ta eat dat de app tafoeget: in proxy, in transport of in berjochtsgrutte.

De app erve in proxy dy’t nimmen konfigurearre hie

De measte HTTP-stapels lêze de proxykonfiguraasje standert út it bestjoeringssysteem. In bedriuws-VPN-klant ynstallearret faak ien as part fan syn tagongsprofyl, sadat oanfragen fia in proxy nei bûten geane dy’t de ûntwikkelder nea yn ’e koade neamd hat. Yn .NET lûkt de standerthandler út IE/WinHTTP-ynstellingen; Java lêst -Dhttp.proxyHost; Node hat gjin ynboude proxystipe oant in bibleteek dy tafoeget. De mislearring is selden in skjinne wegering, dêrom begjinne minsken nei de server te sjen.

De test kostet ien oanfraach: skeakelje de proxy iepenbier út op ien handler en ferlykje.

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

As dat slagget, heart de oplossing yn ’e konfiguraasje fan ’e app, net yn ’e tunnel. Werhelje de audit foar elke runtime yn it projekt, want elk lêst in oare boarne en miskien is mar ien fan harren stikken.

De poarte dy’tsto keazen hast is net de poarte dy’t it belied tasteat

In rûtearre host is gjin tastiene tsjinst. Bedriuwsbelied tasteat meastentiids útgeande webpoarten en smyt de rest fuort, dus in tsjinst op 8080 of 1883 is net berikber wylst 443 goed wurket. De browser bewiist hjir neat: hy brûkt 443 neffens de definysje.

Publisearje deselde tsjinst efter 443 en berik dysels by namme foardatsto in útsûndering freegst. As de útsûndering echt nedich is, behein dy dan ta ien boarnerigel en ien bestimming en behannelje it as part fan ’e tsjinstdefinysje, net as immen syn persoanlike omwei.

Rau TCP dat it paad resettelet

Langduorjende raue TCP-ferbiningen binne de laach dy’t it meast betiizjend mislearret. In paad dat webtagong tasteat, kin dochs ûngewoane útgeande TCP resette of oerskriuwe, en de klant rapportearret in socketflater dy’t as in útfal lêst. Berjocht- en barrenstsjinsten leverje meastentiids in WebSocket-transport krekt foar sa’n netwurk, en it omskeakeljen is in klantopsje, net in tunnelferoaring.

Skeakelje it transport om, test opnij en feroarje neat oars yn deselde run. Dy test mei ien fariabele fertelt dy oft de reset fan it paad of fan ’e tsjinst kaam.

Ferbinings dy’t allinne by grutte ladingen slute

In oanfraach dy’t slagget en dan sawat in sekonde letter deaget, mar allinne as it lichem grut is, wiist op in gruttegrins earne yn it midden. In tuskenlaach dy’t berjochtbytes telt, kin de ferbining healwei de oerdracht falle litte, en de klant rapportearret in abnormale sluting yn stee fan in time-out.

Diel de lading op yn stikken op appnivo. Hâld dat los fan MTU-wurk: it ferleegjen fan ’e pakketgrutte fan ’e tunnel helpt as gewoane TCP-sesjes fêstrinne by in konstante bytecount, en it docht neat foar in berjocht dat in tuskenlaach te grut fynt.

Hoe’tsto de fjouwer yn ien pass ûnderskiede

Trije observaasjes besljochtsje de measte gefallen. Bart de mislearring daliks of allinne by in grut lichem? Slaget deselde oanfraach mei de proxy út? Feroaret it resultaat as do fan poarte of transport feroarest? Skriuw de antwurden op foar de folgjende feroaring, want in bedriuws-VPN plus in erfd proxy plus in standertwearde fan ’e app jouwe dy tagelyk trije mooglike oarsaken.

Hâld ien fariabele per test en skriuw de bestimmingshost op dy’tsto brûkt hast. Sûnder dy basisline werhellet de folgjende persoan alle fjouwer stappen fan it begjin ôf.