Pourquoi les résultats d’un scan de ports changent-ils derrière une sortie VPN ?
Changez la sortie et un port peut répondre différemment sans que le service bouge. Séparez l’observation du chemin de l’inventaire dont vous avez réellement besoin.
Lancez le même contrôle de port depuis une ligne de bureau et depuis une sortie VPN, et les deux réponses peuvent diverger au sujet d’une adresse que personne n’a modifiée. Cet écart vient de la route et de l’hôte qui a répondu, pas du fait que le service soit actif ou arrêté. Trois questions séparent ces explications : ce que la sonde a réellement demandé, quel hôte a répondu et ce que votre propre serveur a enregistré. Parcourez-les dans cet ordre et notez chaque réponse avant de passer à la suivante.
Réparez la sonde avant de comparer deux exécutions
Un mot d’état n’est comparable à un autre mot d’état que lorsque les deux proviennent de la même expérience. Cinq champs le fixent : l’adresse source vue par le côté distant, la destination résolue, le port, le type de scan et l’heure. Modifiez l’un d’eux et vous avez fait une seconde expérience au lieu de mesurer la première deux fois.
Vérifiez la source avant tout le reste, car un client VPN peut être actif alors que le trafic sort encore par l’interface physique. Demandez au côté distant ce qu’il voit, puis demandez au noyau quelle interface il a choisie :
curl -s https://ifconfig.me
ip route get 203.0.113.20Deux adresses sur des réseaux différents signifient que l’explication est déjà en main, et le reste de ces contrôles ne fera que la confirmer. Quand elles concordent, capturez la sonde avec l’indicateur de raison activé, afin que l’état revienne attaché à une explication au lieu de rester seul comme un mot nu. Le type de scan appartient aussi à cet enregistrement, car il décrit ce qui a été demandé et non ce qui est revenu. Un état sans source, sans méthode et sans horodatage ne se compare à rien :
nmap -sT -p 443,8443 --reason 203.0.113.20Gardez cette sortie à côté de l’enregistrement et non dans un tampon de défilement que la personne suivante ne peut pas voir. Deux scans honnêtes qui divergent ne sont une dispute que lorsque personne n’a écrit les conditions. Les conditions fixées, soit les résultats concordent et la question est close, soit ils diffèrent et la différence est un fait sur le chemin.
Déterminez quel hôte a terminé la poignée de main
Une poignée de main achevée prouve qu’un hôte l’a achevée, et cet hôte n’est pas forcément le processus que vous avez en tête. Un répartiteur de charge, un proxy inverse ou un proxy SYN peuvent répondre avant que le vrai serveur n’intervienne, ce qui est une conception ordinaire et non un symptôme. Un certificat valide pour le nom attendu ne resserre pas cela non plus, car un certificat décrit une relation de service et ne dit rien sur la machine qui a terminé la connexion.
La référence des états de port de Nmap considère cela comme élémentaire : un état enregistre ce qu’une sonde a pu observer depuis son point d’envoi, pas une propriété du port. Lisez un mot d’état ainsi et deux exécutions qui divergeaient commencent à paraître cohérentes plutôt que contradictoires, tandis que la question passe de « le port est-il ouvert » à « qui se tenait devant lui ».
Répondez à la deuxième question côté backend et non de l’extérieur. Un frontend qui accepte les connexions puis n’atteint pas son upstream produit exactement l’image externe d’un service sain avec une application lente. Seul l’enregistrement propre à l’upstream sépare les deux cas :
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'La ligne de journal montre l’adresse client que l’application a réellement vue, et la seconde commande montre si le processus qui détient le port 443 est votre application ou quelque chose devant elle. Si les deux divergent sur l’adresse qui s’est connectée, vous regardez deux jambes d’une même requête et le ticket devrait le dire.
Vérifiez vos propres règles avant d’accuser le tunnel
Une politique délibérée est la raison la plus courante pour qu’un port réponde sur un réseau et pas sur un autre, et c’est l’explication la moins intéressante disponible. Les règles d’accès existent pour autoriser une source et rejeter le reste, donc un changement de sortie est exactement l’événement pour lequel elles ont été écrites. Un état différent via un VPN ne montre donc pas que le fournisseur inspecte le trafic. Il montre que votre adresse source est désormais différente, ce qui est une affirmation bien plus faible.
Ces règles sont lisibles sur le serveur, alors lisez-les au lieu de spéculer sur le milieu du réseau. Listez les règles de filtrage qui mentionnent l’une ou l’autre des deux plages d’adresses, puis vérifiez si la connexion a atteint le démon :
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113Un second résultat vide est instructif, car rien n’a atteint le démon et la question relève d’un filtre, d’un groupe de sécurité ou du chemin lui-même. Un succès signifie que le service a vu votre source et choisi sa réponse, et cette décision est généralement écrite dans une règle que vous pouvez lire. Aucun des deux résultats ne soutient une histoire sur le fournisseur, et les deux sont moins coûteux à vérifier qu’une capture de paquets.
Lisez transport, certificat et réponse séparément
Trois couches produisent trois observations, et une sonde qui en teste une ne peut pas rendre compte des deux autres. Gardez-les comme des lignes distinctes dans l’enregistrement au lieu de les plier en un seul verdict, car chaque ligne échoue à sa manière et le mode d’échec vous indique où regarder ensuite.
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
Une seule commande produit les trois premières lignes contre un service que vous contrôlez. Placez sa sortie dans l’enregistrement à côté du scan et non dans un message de discussion :
curl -v --resolve office.example:443:203.0.113.20 https://office.example/Lisez la sortie dans l’ordre : la poignée de main répond à la question du transport, le sujet du certificat à la question du nom et le corps de la réponse à la question de l’application. Quand la ligne de poignée de main réussit et que celle de réponse échoue, vous avez un frontend dont l’upstream est cassé plutôt qu’un port bloqué. C’est un ticket différent de celui que vous avez ouvert, et cela vaut la peine de le dire clairement.
Terminez en écrivant quatre faits dans le ticket : adresse source, type de scan, l’hôte qui a répondu et l’heure. Tout ce dont une comparaison ultérieure a besoin vit dans ces quatre, et celui qui reprendra le dossier ensuite n’aura pas l’historique de votre terminal. Si vous ne pouvez pas remplir les quatre, l’exécution n’est pas terminée.