L’analyse brute de Nmap échoue via un VPN, mais la connexion -sT fonctionne ?

Une page se charge par le tunnel pendant qu’une analyse de ports déclare l’hôte hors service, et le premier réflexe est que le VPN bloque quelque chose. En général, il ne bloque rien de nouveau. Les deux tests demandent au système d’exploitation des capacités différentes, et un seul a besoin d’un accès brut aux paquets. Déterminez quelle capacité a échoué avant de toucher au tunnel.

Séparez la capacité du tunnel

Une application ordinaire demande au noyau d’ouvrir une connexion TCP, et le noyau effectue la poignée de main sans privilège particulier. Une analyse brute construit elle-même les paquets, ce qui exige une socket brute ou un pilote de capture selon la plateforme. Ce sont des questions de permissions et de pilotes, et elles existent que le VPN soit connecté ou non.

Cette distinction explique l’asymétrie courante. curl réussit parce que le chemin de la socket fonctionne, tandis que l’analyse SYN échoue parce que le processus ne peut pas ouvrir de socket brute sur l’interface du tunnel. Elle explique aussi le cas inverse, où une analyse brute signale filtré parce que le chemin abandonne la sonde alors que le chemin de l’application reste bon.

Aucun des deux résultats ne décrit le service distant. Les deux décrivent un chemin sous une méthode, donc gardez la méthode attachée à la conclusion.

Lancez la vérification de connexion sur un seul hôte approuvé

Choisissez l’hôte unique que couvre votre tâche, puis utilisez le mode qui n’exige aucun accès brut. La cible d’exemple ici est 198.51.100.24, un espace de documentation réservé à ce genre d’illustration.

Une ligne, un hôte, un port, aucune phase de découverte :

nmap -sT -Pn -p 443 --unprivileged 198.51.100.24

-sT sélectionne une connexion TCP complète, donc il emprunte le même chemin noyau qu’une application et n’exige pas de pilote de capture. -Pn saute la découverte d’hôtes ; nmap effectue tout de même une résolution de couche de liaison pour les cibles du segment local, donc l’option ne garantit pas un trafic préliminaire nul. --unprivileged indique à nmap de supposer qu’il n’a aucun droit brut ni d’écoute, ce qui change la méthode et ne concède rien.

Lisez chaque option comme un changement, pas comme une réparation

Traitez chaque option comme un énoncé sur la méthode. Ni -sT, ni -Pn, ni --unprivileged n’ajoute de route, n’ouvre de pare-feu distant ni ne valide de certificat. Une analyse de connexion effectue aussi une vraie poignée de main que le service journalise, donc une vérification approuvée et un balayage non approuvé se ressemblent depuis le serveur, hormis la portée et le rythme. Empiler les options jusqu’à ce que la sortie change est la façon dont un problème de méthode se retrouve consigné comme une constatation réseau.

Quand la sortie dit fermé, quelque chose a répondu par une réinitialisation, et c’est une constatation différente du silence. Quand la sortie dit filtré, un équipement a abandonné la sonde ou sa réponse, et le VPN peut être accessoire. Notez la formulation exacte, car un verdict de la phase de découverte et une défaillance au niveau de la sonde désignent des couches différentes.

Si un mode privilégié est vraiment nécessaire, le propriétaire de la plateforme décide si le privilège, le pilote et l’agencement des interfaces sont pris en charge. Élever la même invocation ne change pas sa méthode.

Arrêtez-vous au résultat de transport, puis testez le service

Une poignée de main terminée répond à une question sur une adresse, un port, une source et un instant. Elle ne prouve pas que le backend est sain, car un répartiteur de charge ou un proxy frontal peut accepter la connexion alors que l’application derrière est arrêtée.

Poursuivez avec le client propre au service pour que l’identité TLS et le comportement applicatif soient observés comme des faits distincts :

openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/health

Une habitude de plus garde le résultat utile. Notez la commande exacte, l’adresse source utilisée et l’heure, car un résultat de transport sans ce contexte ne peut être reproduit ni comparé.

Si le certificat nomme un hôte que vous n’attendiez pas, le transport a fonctionné et le routage n’a jamais été le problème ; la panne se situe dans l’hébergement virtuel ou le DNS. Si la poignée de main échoue, consignez la chaîne d’erreur locale au lieu de généraliser sur le tunnel. Gardez la note de portée à côté du résultat, car la personne suivante doit savoir quelle méthode l’a produit.