Les peticions de l’aplicació fallen darrere d’una VPN corporativa, però el navegador funciona

Obriu el portal intern en un navegador i es carrega. Executeu l’aplicació que crida el mateix host i falla, amb un missatge que no anomena cap capa. El túnel porta el navegador, així que el túnel no és el primer sospitós. Hi ha quatre coses entre la vostra petició i el servei, i cadascuna deixa una signatura diferent. Aquest és l’ordre que segueixo, començant per la petició que l’aplicació envia de debò i no per la pàgina de configuració del client VPN.

Mireu la petició que l’aplicació envia realment

Abans de tocar la configuració, feu que l’aplicació us digui què fa. Una captura d’una petició amb el proxy desactivat explícitament i una prova de port simple us donen dues línies base amb què comparar els passos següents. Si la petició funciona amb el proxy desactivat, ja heu acabat amb tres de les quatre capes.

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

Executeu les dues últimes amb la mateixa destinació i mireu on divergeixen. Un navegador que funciona més un curl que funciona més una aplicació que no funciona redueixen el problema a alguna cosa que afegeix l’aplicació: un proxy, un transport o una mida de missatge.

L’aplicació ha heretat un proxy que ningú no ha configurat

La majoria de piles HTTP llegeixen la configuració del proxy del sistema operatiu per defecte. Un client VPN corporatiu sovint n’instal·la un com a part del seu perfil d’accés, així que les peticions surten per un proxy que el desenvolupador no ha esmentat mai al codi. A .NET el gestor per defecte llegeix la configuració d’IE/WinHTTP; Java llegeix -Dhttp.proxyHost; Node no té suport de proxy integrat fins que una biblioteca l’afegeix. La fallada poques vegades és un rebuig net, i per això la gent comença a mirar el servidor.

La prova costa una petició: desactiveu el proxy explícitament en un sol gestor i compareu.

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

Si això funciona, la correcció pertany a la configuració de l’aplicació, no al túnel. Repetiu l’auditoria per a cada entorn d’execució del projecte, perquè cadascun llegeix una font diferent i potser només un està trencat.

El port que heu triat no és el port que permet la política

Un host encaminat no és un servei permès. La política corporativa sol permetre els ports web de sortida i descartar la resta, així que un servei al 8080 o al 1883 és inaccessible mentre que el 443 funciona bé. El navegador no demostra res aquí: fa servir el 443 per definició.

Publiqueu el mateix servei darrere del 443 i arribeu-hi pel nom abans de demanar una excepció. Si l’excepció és realment necessària, limiteu-la a un rang d’origen i una destinació i tracteu-la com a part de la definició del servei, no com la solució improvisada d’algú.

TCP cru que el camí reinicia

Les connexions TCP crues de llarga durada són la capa que falla de manera més confusa. Un camí que permet trànsit web encara pot reiniciar o reescriure TCP de sortida poc habitual, i el client informa d’un error de sòcol que es llegeix com una caiguda. Els serveis de missatgeria i d’esdeveniments solen incloure un transport WebSocket precisament per a aquest tipus de xarxa, i canviar-lo és una opció del client, no un canvi del túnel.

Canvieu el transport, torneu a provar i no canvieu res més en la mateixa execució. Aquesta prova d’una sola variable us diu si el reinici ve del camí o del servei.

Connexions que només es tanquen amb càrregues grans

Una petició que funciona i després mor aproximadament un segon més tard, però només quan el cos és gran, apunta a un límit de mida en algun punt del mig. Un intermediari que compta els bytes dels missatges pot deixar caure la connexió a mig trànsit, i el client informa d’un tancament anormal en lloc d’un temps d’espera.

Trossegeu la càrrega a la capa d’aplicació. Manteniu-ho separat de la feina d’MTU: reduir la mida dels paquets del túnel ajuda quan les sessions TCP normals s’encallen en un recompte de bytes constant, i no fa res per a un missatge que un intermediari considera massa gran.

Com distingir les quatre en una sola passada

Tres observacions resolen la majoria de casos. La fallada passa immediatament o només amb un cos gran? La mateixa petició funciona amb el proxy desactivat? El resultat canvia quan canvieu de port o de transport? Escriviu les respostes abans del canvi següent, perquè una VPN corporativa més un proxy heretat més un valor per defecte de l’aplicació us donen tres causes plausibles alhora.

Manteniu una variable per prova i anoteu l’host de destinació que heu fet servir. Sense aquesta línia base, la persona següent repeteix els quatre passos des del principi.