Nmap affiche des résultats différents via un VPN ? Fixez la cible
Un nom d'hôte peut se résoudre vers une autre adresse une fois le tunnel monté. Gardez la cible numérique fixe avant d'interpréter le moindre changement d'état des ports.
Deux scans de ports du même site peuvent diverger parce que le nom s'est résolu vers une autre adresse entre les exécutions, et non parce que le tunnel a changé ce que la cible expose. Un nom d'hôte est une instruction de recherche, et Nmap la suit au moment du scan. Quand le résolveur répond avec un autre enregistrement, le second scan a mesuré une autre machine.
Fixez l'adresse numérique et la comparaison redevient significative. Tout le reste du rapport, du chronométrage aux équipements intermédiaires, demeure une variable distincte qui exige son propre contrôle.
Deux expériences qui semblent identiques dans un rapport
Comparez un nom à lui-même et vous avez changé au moins deux choses à la fois : le chemin que prennent vos paquets et la destination renvoyée par le résolveur. Une différence dans la sortie ne peut être attribuée à l'une ou à l'autre. Cette ambiguïté est la raison habituelle pour laquelle un scan avant-après devient une discussion que personne ne peut trancher.
Comparez une adresse à elle-même et la destination est fixée par construction. Tout ce qui diffère encore relève du chemin, de l'adresse source, du filtrage intermédiaire ou de l'état de la machine elle-même. Vous avez retiré une variable, ce qui n'est pas la même chose que les retirer toutes.
Notez laquelle de ces deux expériences vous avez réellement exécutée avant de tirer la moindre conclusion d'un tableau de ports. La distinction semble théorique jusqu'à ce qu'un rapport affirme que le VPN a bloqué un port qui n'avait jamais été ouvert sur l'adresse atteinte la seconde fois.
| Comparison | What stays fixed | What a difference can mean |
|---|---|---|
| Name against name | The string you typed | Resolver answer, answer order or split-horizon policy changed |
| Address against address | The numeric destination | Source path, filtering or service placement changed |
Résolvez d'abord, puis scannez l'adresse enregistrée
Séparez la résolution du sondage pour que les deux faits atterrissent à des endroits différents. Demandez au système ce qu'il a résolu, enregistrez cette réponse, puis donnez à Nmap l'adresse littérale. Répétez les deux mêmes commandes tunnel coupé puis monté.
getent hosts scan.example.net dig +short scan.example.net A nmap -Pn -sV -p 443,8443 192.0.2.40
L'option -Pn compte ici, car un hôte qui ignore les sondes de découverte serait sinon signalé comme hors ligne et le résultat vide mal lu comme un port fermé. N'utilisez -sV que contre des cibles approuvées par l'opérateur ; le sondage de version est plus bruyant qu'une simple connexion et relève du périmètre écrit.
La référence de spécification de cible de Nmap indique explicitement qu'un nom d'hôte est résolu en adresse avant le scan et que, lorsque plusieurs adresses reviennent, l'outil scanne la première sauf si vous les demandez toutes. Rien dans ce comportement n'est propre au VPN. Un DNS scindé, un autre résolveur ou un répartiteur de charge qui répond dans un nouvel ordre produisent le même effet sans aucun tunnel.
Conservez la valeur résolue à côté de la sortie du scan, avec la famille d'adresses, le jeu d'options et un horodatage. Une recherche inversée qui renvoie un nom d'entreprise est une autre observation, pas la preuve du backend qui a répondu.
Ce qu'un état de port modifié peut et ne peut pas vous dire
Une fois la destination fixée, un port qui passe d'ouvert à filtré pointe généralement vers le chemin. Pensez à une ACL en amont, à un pare-feu avec état ou à un fournisseur qui traite la sortie de tunnel différemment de la sortie résidentielle. Réduisez le champ en testant une seconde adresse approuvée dans le même sous-réseau lorsque le périmètre le permet, car changer le nom d'hôte réintroduirait la question du résolveur. Une variable par exécution, c'est toute la méthode.
Un port qui reste ouvert tandis que la bannière du service change est une autre histoire. Ce schéma correspond à un frontal qui répartit les connexions entre backends, et aucune quantité de scan de votre côté ne nommera le locataire derrière.
Ce que le scan ne dit jamais, c'est l'intention. Un port filtré est un résultat de politique, pas la preuve que quelqu'un a ciblé votre tunnel, et un port ouvert n'est pas la preuve que l'application derrière vous servira. Corrélez avec les journaux du composant que vous exploitez avant d'écrire l'une ou l'autre histoire.
Enregistrez les résultats pour que la comparaison survive à la revue
Un enregistrement utile contient le nom demandé, l'adresse résolue et sa famille, les options exactes, l'adresse source utilisée et l'autorisation qui couvrait la destination. Ajoutez l'heure, car les réponses DNS tournent et un rapport sans horodatage invite deux fois la même discussion. Ajoutez aussi la version du scanner, car le comportement de sondage par défaut dérive entre versions. Si deux exécutions ont employé des méthodes différentes, traitez-les comme des expériences distinctes et dites-le en titre, pas en note de bas de page.
Étiquetez la constatation pour ce qu'elle est : destinations différentes, chemins source différents ou différence encore inexpliquée. Ce vocabulaire garde un rapport de scan honnête et empêche une réponse de résolveur d'être republiée comme un événement d'interception VPN. L'étape suivante est généralement une exécution de plus avec l'adresse fixée, pas un scan plus large.