Les requêtes de l’application échouent derrière un VPN d’entreprise, mais le navigateur fonctionne

Une application casse alors que le navigateur charge le site. Parcourez dans cet ordre le proxy qu’elle a hérité, la politique de ports, les réinitialisations de TCP brut et les limites de taille de charge utile.

Vous ouvrez le portail interne dans un navigateur et il se charge. Vous lancez l’application qui appelle le même hôte et elle échoue, avec un message qui ne nomme aucune couche. Le tunnel transporte le navigateur, donc le tunnel n’est pas le premier suspect. Quatre choses se trouvent entre votre requête et le service, et chacune laisse une signature différente. Voici l’ordre que je suis, en partant de la requête que l’application envoie réellement, et non de la page de réglages du client VPN.

Regardez la requête que l’application envoie vraiment

Avant de toucher à la configuration, faites dire à l’application ce qu’elle fait. Une capture d’une seule requête avec le proxy explicitement désactivé et un simple test de port vous donnent deux lignes de base auxquelles comparer les étapes suivantes. Si la requête réussit avec le proxy désactivé, vous avez déjà réglé trois des quatre couches.

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

Exécutez les deux dernières vers la même destination et regardez où elles divergent. Un navigateur qui fonctionne, plus un curl qui fonctionne, plus une application qui ne fonctionne pas, réduisent le problème à ce que l’application ajoute : un proxy, un transport ou une taille de message.

L’application a hérité d’un proxy que personne n’a configuré

La plupart des piles HTTP lisent la configuration du proxy dans le système d’exploitation par défaut. Un client VPN d’entreprise en installe souvent un dans le cadre de son profil d’accès, si bien que les requêtes sortent par un proxy que le développeur n’a jamais mentionné dans le code. En .NET, le gestionnaire par défaut lit les réglages IE/WinHTTP ; Java lit -Dhttp.proxyHost ; Node n’a aucun support de proxy intégré tant qu’une bibliothèque ne l’ajoute pas. L’échec est rarement un refus net, c’est pourquoi les gens commencent à regarder le serveur.

Le test coûte une requête : désactivez le proxy explicitement sur un seul gestionnaire et comparez.

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

Si cela réussit, le correctif appartient à la configuration de l’application, pas au tunnel. Répétez l’audit pour chaque environnement d’exécution du projet, car chacun lit une source différente et un seul est peut-être cassé.

Le port choisi n’est pas celui que la politique autorise

Un hôte routé n’est pas un service autorisé. La politique d’entreprise autorise généralement les ports web sortants et abandonne les autres, si bien qu’un service sur 8080 ou 1883 est inaccessible alors que 443 fonctionne très bien. Le navigateur ne prouve rien ici : il utilise 443 par définition.

Publiez le même service derrière 443 et atteignez-le par son nom avant de demander une exception. Si l’exception est réellement nécessaire, limitez-la à une plage source et une destination et traitez-la comme une partie de la définition du service, pas comme le contournement personnel de quelqu’un.

Le TCP brut que le chemin réinitialise

Les connexions TCP brutes de longue durée sont la couche qui échoue le plus confusément. Un chemin qui autorise le trafic web peut tout de même réinitialiser ou réécrire un TCP sortant inhabituel, et le client signale une erreur de socket qui se lit comme une panne. Les services de messagerie et d’événements fournissent généralement un transport WebSocket précisément pour ce type de réseau, et le changement est une option du client, non une modification du tunnel.

Changez de transport, retestez et ne changez rien d’autre dans la même exécution. Ce test à une seule variable vous dit si la réinitialisation venait du chemin ou du service.

Les connexions qui ne se ferment que sur de grosses charges

Une requête qui réussit puis meurt environ une seconde plus tard, mais seulement quand le corps est gros, pointe vers une limite de taille quelque part au milieu. Un intermédiaire qui compte les octets des messages peut couper la connexion en pleine transmission, et le client signale une fermeture anormale au lieu d’un délai d’attente.

Découpez la charge au niveau applicatif. Gardez cela séparé du travail sur le MTU : réduire la taille des paquets du tunnel aide quand des sessions TCP ordinaires bloquent à un nombre d’octets constant, et cela ne fait rien pour un message qu’un intermédiaire juge trop gros.

Comment distinguer les quatre en une seule passe

Trois observations règlent la plupart des cas. L’échec survient-il immédiatement ou seulement avec un gros corps ? La même requête réussit-elle avec le proxy désactivé ? Le résultat change-t-il quand vous changez de port ou de transport ? Notez les réponses avant le changement suivant, car un VPN d’entreprise plus un proxy hérité plus une valeur par défaut de l’application vous donnent trois causes plausibles à la fois.

Gardez une variable par test et notez l’hôte de destination utilisé. Sans cette ligne de base, la personne suivante refait les quatre étapes depuis le début.

Articles similaires