Petoj de la aplikaĵo malsukcesas malantaŭ entreprena VPN, sed la retumilo funkcias

Unu aplikaĵo paneas dum la retumilo ŝargas la retejon. Trairu en tiu ordo la prokurilon, kiun ĝi heredis, la havenan politikon, restarigojn de kruda TCP kaj la limojn de ŝarĝa grandeco.

Vi malfermas la internan portalon en retumilo kaj ĝi ŝargiĝas. Vi lanĉas la aplikaĵon, kiu alvokas la saman gastiganton, kaj ĝi paneas, kun mesaĝo, kiu nomas neniun tavolon. La tunelo portas la retumilon, do la tunelo ne estas la unua suspektato. Kvar aferoj staras inter via peto kaj la servo, kaj ĉiu lasas alian spuron. Jen la ordo, kiun mi sekvas, komencante de la peto, kiun la aplikaĵo vere sendas, kaj ne de la agorda paĝo de la VPN-kliento.

Rigardu la peton, kiun la aplikaĵo vere sendas

Antaŭ ol tuŝi la agordon, lasu la aplikaĵon diri al vi, kion ĝi faras. Kapto de unu peto kun la prokurilo eksplicite malŝaltita kaj simpla haventesto donas al vi du bazliniojn, kun kiuj komparos la sekvaj paŝoj. Se la peto sukcesas kun la prokurilo malŝaltita, vi jam finis tri el la kvar tavoloj.

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

Rulu la lastajn du al la sama celo kaj rigardu, kie ili disiĝas. Funkcianta retumilo plus funkcianta curl plus aplikaĵo, kiu ne funkcias, mallarĝigas la problemon al io, kion la aplikaĵo aldonas: prokurilo, transporto aŭ mesaĝa grandeco.

La aplikaĵo heredis prokurilon, kiun neniu agordis

Plej multaj HTTP-stakoj legas la prokurilan agordon el la operaciumo defaŭlte. Entreprena VPN-kliento ofte instalas unu kiel parton de sia alirprofilo, do petoj eliras tra prokurilo, kiun la programisto neniam menciis en la kodo. En .NET la defaŭlta traktilo legas el agordoj de IE/WinHTTP; Java legas -Dhttp.proxyHost; Node havas neniun enkonstruitan prokurilan subtenon, ĝis biblioteko aldonas ĝin. La malsukceso malofte estas pura rifuzo, tial homoj komencas rigardi la servilon.

La testa kosto estas unu peto: malŝaltu la prokurilon eksplicite en unu traktilo kaj komparu.

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

Se tio sukcesas, la korekto apartenas al la agordo de la aplikaĵo, ne al la tunelo. Ripetu la revizion por ĉiu rulmedio en la projekto, ĉar ĉiu legas alian fonton kaj eble nur unu estas difektita.

La haveno, kiun vi elektis, ne estas la haveno, kiun la politiko permesas

Enkursigita gastiganto ne estas permesita servo. Entreprena politiko kutime permesas elirajn retajn havenojn kaj forĵetas la ceterajn, do servo sur 8080 aŭ 1883 estas neatingebla dum 443 funkcias bone. La retumilo pruvas nenion ĉi tie: ĝi uzas 443 laŭdifine.

Publikigu la saman servon malantaŭ 443 kaj atingi ĝin laŭnome antaŭ ol peti escepton. Se la escepto vere necesas, limigu ĝin al unu fonta gamo kaj unu celo kaj traktu ĝin kiel parton de la serva difino, ne kiel ies personan provizoran solvon.

Kruda TCP, kiun la vojo restarigas

Longdaŭraj krudaj TCP-konektoj estas la tavolo, kiu paneas plej konfuze. Vojo, kiu permesas retan trafikon, tamen povas restarigi aŭ reskribi neordinaran eliran TCP, kaj la kliento raportas prisekan eraron, kiu legiĝas kiel paneo. Mesaĝaj kaj eventaj servoj kutime liveras WebSocket-transporton ĝuste por tia reto, kaj la ŝanĝo estas klienta opcio, ne tunela ŝanĝo.

Ŝanĝu la transporton, retestu kaj ne ŝanĝu ion alian en la sama rulo. Tiu testado kun unu variablo diras al vi, ĉu la restarigo venis de la vojo aŭ de la servo.

Konektoj, kiuj fermas nur ĉe grandaj ŝarĝoj

Peto, kiu sukcesas kaj poste mortas ĉirkaŭ sekundon poste, sed nur kiam la korpo estas granda, montras al grandeca limo ie meze. Peranto, kiu kalkulas mesaĝajn bitokojn, povas faligi la konekton meze de la transdono, kaj la kliento raportas nenormalan fermon anstataŭ tempolimon.

Dividu la ŝarĝon je pecoj ĉe la aplikaĵa tavolo. Tenu tion aparte de MTU-laboro: malpliigi la paketan grandecon de la tunelo helpas, kiam ordinaraj TCP-sesioj haltas ĉe konstanta bitoka kvanto, kaj ĝi faras nenion por mesaĝo, kiun peranto konsideras tro granda.

Kiel distingi la kvar en unu paŝo

Tri observoj solvas plej multajn kazojn. Ĉu la malsukceso okazas tuj aŭ nur kun granda korpo? Ĉu la sama peto sukcesas kun la prokurilo malŝaltita? Ĉu la rezulto ŝanĝiĝas, kiam vi ŝanĝas havenon aŭ transporton? Skribu la respondojn antaŭ la sekva ŝanĝo, ĉar entreprena VPN plus heredita prokurilo plus aplikaĵa defaŭlto donas al vi tri verŝajnajn kaŭzojn samtempe.

Tenu unu variablon por testo kaj notu la celan gastiganton, kiun vi uzis. Sen tiu bazlinio, la sekva persono ripetas ĉiujn kvar paŝojn de la komenco.

Rilataj artikoloj