La dernière fois, nous avons disséqué le battage médiatique autour de l'écotaxe du ministère de l'Industrie et du Commerce et la manière dont les blogs génèrent de l'audience avec le mot « taxe ». Aujourd'hui, en respectant strictement notre rythme d'alternance « galère du quotidien / hardcore ingénierie », nous retournons au niveau des octets, des sockets et du routage réseau.
Parlons d'une menace sournoise à laquelle fait face toute personne déployant sa propre passerelle ou gérant une infrastructure de nœuds : la mécanique du sondage actif (Active Probing).
Le symptôme est familier à tout administrateur attentif : vous avez mis en place un serveur, configuré un nouveau protocole de camouflage, lié un domaine et connecté deux ou trois clients. Les journaux sont propres, la charge minime, et les règles DPI semblent avoir été franchies. Mais entre deux heures et deux jours plus tard, l'adresse IP du nœud cesse soudainement de répondre aux poignées de main (handshakes) entrantes depuis l'intérieur du périmètre de filtrage. Pourtant, depuis n'importe quel autre point du globe, le port 443 reste ouvert et accessible.
Vous n'avez pas été « repéré par vos volumes de trafic ». On est simplement venu vous auditer en secret.
Anatomie d'une sonde active : comment fonctionne le provocateur réseau
Quand le système TSPU sur le backbone observe une session vers une adresse IP étrangère que ses filtres heuristiques ne parviennent pas à classifier de manière univoque (pas de SNI en liste blanche, profil de chiffrement atypique, entropie suspecte), il ne prend pas le risque de couper la connexion net : cela risquerait de provoquer des faux positifs sur le trafic B2B légitime.
À la place, un protocole de vérification active est déclenché :
Inspection à la volée avec déclenchement ultérieur. La session du client est laissée passer, mais les métadonnées (IP du serveur, port, minutage) sont immédiatement transmises à un réseau distribué de scanners de sondage situés au sein de l'infrastructure des opérateurs.
Requêtes synthétiques (Mutated Handshakes). En l'espace de quelques secondes ou minutes après la fermeture de votre session, une série de paquets spécifiques est envoyée sur votre serveur depuis des adresses IP contrôlées par le régulateur. Il ne s'agit pas d'un simple scan de ports via nmap. La sonde envoie :
Rejouage de session (Replay Attack) : des copies exactes des octets du premier paquet de votre client avec de minimes mutations.
TLS Client Hello corrompu : des requêtes dont l'ordre des chiffrements est intentionnellement altéré ou dont les champs d'extension sont tronqués.
Données parasites (Garbage Probing) : des paquets d'octets aléatoires envoyés dans un socket TLS ouvert pour tester la réaction de l'application.
Vérification de la matrice comportementale. Un véritable serveur Nginx, Apache ou Caddy qui reçoit des données parasites sur un port HTTPS réagit strictement selon les spécifications RFC : il renvoie une erreur standardisée (par exemple, 400 Bad Request avec le code The plain HTTP request was sent to HTTPS port) ou ferme proprement la session avec un paquet d'alerte chiffrée TLS (TLS Encrypted Alert) doté du code decode_error. Si votre proxy se contente de rompre brutalement la session TCP via un RST, subit un délai d'attente (timeout) ou répond par un paquet non standard, la sonde détecte l'anomalie. Le nœud est alors étiqueté comme tunnel non autorisé et placé sur liste noire.
Où pèche la configuration type de l'administrateur
La plupart des tutoriels en ligne suggèrent de configurer ce que l'on appelle un fallback (le renvoi du trafic non valide vers un site miroir local ou un domaine tiers). Mais le diable se cache dans les détails de l'implémentation :
Différence de certificats. Si le proxy accepte une connexion entrante, déchiffre l'en-tête et décide seulement ensuite où la rediriger, une sonde au handshake corrompu peut repérer une empreinte de certificat qui ne correspond pas à l'hôte public que vous imitez.
Anomalies de latence lors du proxyfiement (Latency Delta). Si une requête non valide est transmise vers un site de couverture externe, la sonde mesure le temps écoulé entre l'envoi du paquet et la réception d'un TCP RST ou d'une réponse d'erreur. Une latence de 80 à 120 millisecondes trahit immédiatement la présence d'une couche de proxy intermédiaire.
Absence de réaction aux méthodes HTTP. Les sondages envoient fréquemment des méthodes classiques GET / ou POST en HTTP pur sans TLS. Si le port 443 ne sait pas traiter adéquatement les requêtes HTTP en clair et renvoyer une redirection correcte 301 Moved Permanently, le serveur se fait repérer lors d'un contrôle de base.
Contre-offensive technique : bâtir un nœud imprenable
Pour résister aux attaques des sondes actives, le serveur doit devenir indiscernable d'un site web monolithique et légitime :
Serveur web local avec socket unique (Real Fallback to Nginx/Caddy). Le serveur de couverture ne doit pas se trouver à l'autre bout d'Internet. Un véritable serveur web hébergeant un site valide doit tourner sur la même machine, lié à un socket local (127.0.0.1:8443 ou socket UNIX). Tout trafic n'ayant pas validé la clé d'autorisation du protocole doit être transmis de manière transparente et sans délai au Nginx local, qui renverra à la sonde une réponse absolument légitime d'un site réel.
Tarpitting des sessions suspectes (SYN Tarpit / Delay Defense). Si une série de poignées de main répétées sans transmission de charge utile est constatée depuis une même IP (signature caractéristique d'une sonde), ne fermez pas la connexion par un RST. Configurez votre pare-feu (iptables / nftables) pour maintenir le socket en suspens avec une fenêtre de réception minimale (TCP Zero Window). Le scanner de sondage épuisera sa limite de threads et partira inspecter d'autres cibles.
Blocage des systèmes autonomes de scan connus. Une part importante des sondes est lancée à partir de plages d'adresses fixes appartenant à des instituts de recherche, des passerelles d'opérateurs et des centres de données de surveillance. Le filtrage géographique et par ASN au niveau du pare-feu, qui coupe l'accès direct au port 443 aux sous-réseaux de scan suspects, élimine jusqu'à 85 % des vérifications synthétiques avant même qu'elles n'atteignent la pile TLS.
La censure moderne ne tolère plus les observateurs passifs : chaque canal fermé est surveillé par des algorithmes prêts à frapper à votre porte pour un contrôle. Seul survit le nœud capable d'ouvrir cette porte avec l'air d'un serveur web ennuyeux et parfaitement banal.
Mots-clés (SEO) : sondage actif dpi tspu, active probing contournement blocage, configuration fallback xray vless, pourquoi les ip de serveurs vps sont bloquées, replay attack blocage vpn, protection de nœud contre le scan de ports, sécurité réseau des tunnels 2026