Curl inverse : Commandes et exemples pratiques

Introduction : comprendre curl inverse pour le débogage réseau

Quand on parle de curl inverse, on désigne généralement deux pratiques distinctes mais complémentaires : d’une part, inverser le sens habituel d’une requête curl pour tester un serveur depuis une machine cliente vers l’extérieur (reverse request testing), et d’autre part, utiliser curl en combinaison avec un tunnel ou un serveur d’écoute pour valider une connexion sortante avant de la router officiellement. Concrètement, un technicien indépendant qui intervient chez des clients avec des infrastructures hétérogènes rencontre régulièrement des situations où le sens classique de curl (client vers serveur connu) ne suffit pas à diagnostiquer le problème. Il faut alors inverser la logique : faire en sorte que la cible se connecte vers vous, ou simuler ce comportement pour isoler un pare-feu défaillant, une règle NAT mal configurée, ou une politique de sortie trop restrictive.

Ce guide pratique détaille pas à pas comment mettre en place et utiliser des commandes de curl inverse pour du débogage réseau ou du transfert de fichiers, avec des points de contrôle vérifiables à chaque étape, les pièges les plus fréquents rencontrés sur le terrain, et une estimation réaliste du temps nécessaire pour chaque bloc de manipulation.

Pourquoi utiliser curl inverse en intervention terrain

Sur une majorité de mes interventions chez des PME, le symptôme initial est toujours le même : « ça ne se connecte pas », sans plus de précision. Le réflexe standard consiste à lancer un curl -v https://exemple.com depuis le poste client. Mais cette approche ne révèle qu’une partie du problème : elle confirme que le client peut atteindre le serveur, pas l’inverse. Or de nombreux dysfonctionnements proviennent d’une asymétrie de routage ou d’un pare-feu qui bloque le trafic retour, ce qui n’apparaît jamais dans un test curl classique.

La logique de curl inverse consiste donc à retourner le test : on place un serveur d’écoute minimal côté cible (souvent via nc ou un serveur HTTP Python temporaire), puis on déclenche une requête curl depuis l’autre extrémité pour vérifier que le flux retour transite correctement. Cette méthode est particulièrement utile pour :

Diagnostiquer des règles de pare-feu asymétriques (autorisation dans un sens, blocage dans l’autre)
Valider un tunnel SSH ou VPN avant mise en production
Tester un webhook ou un callback qui doit atteindre une machine derrière un NAT
Vérifier qu’un transfert de fichier initié depuis un serveur distant peut effectivement joindre le poste local

Temps estimé pour cette phase de préparation : 10 à 15 minutes, incluant la vérification des accès et la préparation de l’environnement de test.

Prérequis avant de commencer

Avant de lancer la moindre commande, quelques vérifications s’imposent. Elles évitent de perdre du temps sur un diagnostic faussé par un environnement mal préparé.

Vérifier la version de curl installée : curl --version. Certaines options utilisées plus loin (notamment --data-binary ou --resolve) nécessitent une version récente. Sur un poste client sous Windows, curl est intégré nativement depuis Windows 10 1803, mais certaines versions embarquées sont anciennes et limitées.
Confirmer les droits d’ouverture de port sur la machine qui fera office de serveur d’écoute temporaire. Sur un poste utilisateur standard, il faut souvent une élévation de privilèges pour écouter sur un port inférieur à 1024 — privilégiez un port haut (8080, 8443, 9000) pour éviter cette contrainte.
Identifier l’adresse IP ou le nom d’hôte joignable depuis l’autre extrémité du test. Sur un réseau NAT, l’IP publique n’est pas forcément celle du poste local : passez par curl ifconfig.me pour la connaître côté sortant.
Désactiver temporairement les règles de pare-feu locales trop restrictives sur le poste de test, en gardant une trace de la configuration initiale pour tout remettre en place ensuite.

Checkpoint 1 : à ce stade, vous devez pouvoir répondre avec certitude à trois questions : quelle version de curl est utilisée, quel port sera ouvert pour le test, et quelle IP sera annoncée côté distant. Si l’une de ces réponses est floue, ne passez pas à l’étape suivante.

Étape 1 — Mettre en place un serveur d’écoute minimal

La première étape concrète consiste à créer un point d’écoute côté cible pour recevoir la requête inversée. Deux options courantes sur le terrain :

Avec Netcat (rapide, sans dépendance) :

nc -l -p 9000

Cette commande ouvre une écoute brute sur le port 9000. Elle affiche tout ce qu’elle reçoit, sans interpréter le protocole HTTP — utile pour un premier test de connectivité pure.

Avec un serveur HTTP Python (plus proche d’un cas réel) :

python3 -m http.server 9000

Cette seconde option simule un vrai serveur HTTP, ce qui permet de tester des en-têtes, des méthodes GET/POST et d’observer les codes de retour, plus représentatifs d’un cas de webhook ou d’API.

Temps estimé : 3 à 5 minutes. C’est l’étape la plus rapide, mais aussi celle où une erreur de port ou d’interface d’écoute (0.0.0.0 vs 127.0.0.1) fait perdre le plus de temps si elle passe inaperçue.

Étape 2 — Déclencher la requête curl inverse depuis la source distante

Une fois le serveur d’écoute prêt, on se place sur la machine qui doit initier la connexion vers la cible — c’est ici que la commande curl inverse entre en jeu, car on teste le sens de connexion normalement absent des vérifications standards.

curl -v http://IP_CIBLE:9000/test

Pour un test plus poussé simulant un envoi de fichier (utile pour valider un flux de transfert de fichiers inversé, où la cible pousse des données vers vous plutôt que l’inverse) :

curl -v -X POST --data-binary @fichier.txt http://IP_CIBLE:9000/upload

L’option -v (verbose) est indispensable ici : elle affiche l’intégralité du dialogue TCP/TLS, y compris les tentatives de connexion échouées, les timeouts, et les éventuelles erreurs de certificat si le test passe par HTTPS.

Si le test doit transiter par un tunnel SSH inversé (cas fréquent quand la cible est derrière un NAT sans IP publique), la commande de préparation du tunnel précède le test curl :

ssh -R 9000:localhost:9000 utilisateur@serveur_relais

Puis, depuis le serveur relais, on exécute la commande curl vers localhost:9000, qui redirige effectivement vers la machine cible via le tunnel inversé.

Checkpoint 2 : la commande curl doit retourner soit une réponse HTTP explicite (200, 404, etc.), soit une erreur de connexion clairement identifiable (connection refused, timeout, certificat invalide). Une absence totale de retour après 30 secondes signale presque toujours un blocage réseau intermédiaire plutôt qu’un problème applicatif.

Temps estimé : 5 à 10 minutes, tunnel SSH inclus si nécessaire.

Étape 3 — Interpréter les résultats et isoler la cause

C’est l’étape où la majorité des interventions terrain basculent d’un diagnostic vague à une cause précise. Voici les scénarios les plus fréquents rencontrés lors de mes déploiements :

Connection refused : le port n’est pas ouvert côté cible, ou le service d’écoute n’a pas démarré correctement. Revenir à l’étape 1.
Connection timed out : un pare-feu intermédiaire (box opérateur, firewall d’entreprise, groupe de sécurité cloud) bloque silencieusement le trafic. C’est le cas le plus fréquent en environnement PME avec un routeur non administré directement.
SSL certificate problem : si le test passe en HTTPS, un certificat auto-signé ou expiré bloque la validation. Ajouter temporairement -k à la commande curl permet de confirmer que le blocage vient bien du certificat, à ne jamais laisser en production.
Réponse reçue mais code 000 : signale généralement une rupture de connexion en cours de transfert, souvent liée à un proxy intermédiaire qui coupe les connexions longues.

Une fois la cause isolée, la correction se fait généralement sur l’équipement réseau (règle de pare-feu, redirection de port, configuration NAT) et non sur la commande curl elle-même, qui n’a servi que d’outil de diagnostic.

Temps estimé : 10 à 20 minutes selon la complexité de l’infrastructure réseau du client.

Pièges courants à éviter avec curl inverse

Sur le terrain, certaines erreurs reviennent systématiquement et font perdre un temps précieux lors d’une intervention facturée à l’heure. Voici les plus fréquentes :

Oublier de rouvrir les ports après le test. Un serveur d’écoute temporaire laissé actif sur un poste client est une faille de sécurité évidente. Toujours fermer le processus (Ctrl+C sur le terminal d’écoute) et documenter la remise en état dans le rapport d’intervention.
Confondre IP privée et IP publique. Tester avec l’IP locale d’une machine derrière un routeur NAT sans passer par la redirection de port correspondante donne systématiquement un résultat trompeur.
Ignorer la temporisation DNS. Si le test utilise un nom de domaine plutôt qu’une IP directe, un cache DNS obsolète côté client peut fausser le résultat. Ajouter --resolve nom.domaine:port:IP à la commande curl permet de forcer la résolution sans dépendre du cache local.
Tester en HTTPS sans vérifier le SNI. Sur un serveur d’écoute de test minimal, l’absence de certificat valide pour le bon nom d’hôte génère des erreurs qui n’ont rien à voir avec le problème réseau initial.
Ne pas noter les résultats intermédiaires. Sur une intervention qui s’étale sur plusieurs heures, il est facile de perdre le fil entre les différents tests. Consigner chaque commande curl exécutée et son résultat dans un fichier texte évite de refaire les mêmes vérifications deux fois.

Cas pratique : transfert de fichier inversé via curl

Un cas concret rencontré récemment : un client dont l’ERP devait pousser automatiquement des exports CSV vers un poste de traitement local, sans que ce dernier ait besoin d’aller les chercher activement. Le flux devait donc s’initier depuis le serveur ERP vers le poste local — l’inverse du sens habituel d’un client qui télécharge un fichier.

La validation s’est faite en trois temps : d’abord un serveur d’écoute HTTP minimal sur le poste local (étape 1), puis une commande curl exécutée depuis le serveur ERP simulant l’envoi du fichier CSV :

curl -v -X POST --data-binary @export.csv -H "Content-Type: text/csv" http://poste-local:9000/reception

Le premier essai a échoué avec un connection timed out, révélant que le pare-feu du routeur du client bloquait le port 9000 en entrée. Après ouverture de la redirection de port correspondante sur le routeur, le second essai a abouti avec un code 200, confirmant que le flux inversé fonctionnait correctement avant de passer à la configuration définitive du script d’automatisation côté ERP.

Temps total de ce cas pratique, tests et correction inclus : 35 minutes, contre plusieurs heures si le diagnostic avait continué à se concentrer uniquement sur des tests curl classiques dans le mauvais sens.

Récapitulatif et temps total estimé

Voici la procédure complète de débogage réseau avec curl inverse, étape par étape :

Préparation et vérifications préalables : 10 à 15 minutes
Mise en place du serveur d’écoute : 3 à 5 minutes
Déclenchement de la requête inversée : 5 à 10 minutes
Interprétation des résultats et correction : 10 à 20 minutes

Au total, comptez entre 30 minutes et un peu plus d’une heure pour une intervention complète, correction réseau incluse. Cette méthode reste l’une des plus fiables pour distinguer un problème applicatif d’un problème d’infrastructure, en particulier chez des clients dont le réseau n’a pas été documenté avec précision au fil des années. Elle demande un peu de rigueur dans l’ordre des étapes, mais évite des heures de diagnostic à l’aveugle sur un simple test curl classique qui ne révèle jamais l’asymétrie du trafic.

Pour approfondir, consultez la documentation technique de Microsoft.