Choisir le bon point d’observation pour un scan VPN sur téléphone

Une évaluation autorisée d’un VPN hébergé sur un téléphone échoue silencieusement lorsque le scanner se trouve du mauvais côté du tunnel. On obtient des résultats, ils paraissent plausibles et ils répondent à une question que personne n’a posée. Parcourez les cinq contrôles ci-dessous dans l’ordre. Chacun a une condition d’arrêt, et s’arrêter tôt coûte moins cher que de retester depuis zéro une fois le rapport écrit.

Étape 1 : nommez la surface que vous voulez atteindre

Trois surfaces sont régulièrement confondues parce qu’un seul appareil les relie. Elles exécutent un code et une politique différents, alors notez laquelle est dans le périmètre avant de commencer quoi que ce soit.

Si le périmètre approuvé ne dit pas laquelle des trois, arrêtez-vous et demandez. Obtenir un accès root sur le téléphone ne répond pas à cette question et change la chose testée plutôt que le point d’observation.

Notez les cibles, les adresses source autorisées, la fenêtre temporelle et la limite d’intensité en même temps. Le tunnel vous porte jusqu’à ce périmètre ; il ne vous autorise pas à sonder tout ce qu’il peut router.

Étape 2 : choisissez la source qui peut voir cette surface

Un scanner placé à l’intérieur du VPN ne peut pas reproduire un observateur internet non authentifié. Il détient déjà des routes, des identifiants et des permissions dont l’observateur extérieur est dépourvu, si bien que ses résultats décrivent la vue après admission, même lorsque la surface cible est la même. L’erreur inverse est tout aussi courante. Un scan public du port VPN ne dit presque rien d’un service privé derrière la connexion, et le présenter comme s’il le disait surestime l’exposition dans un sens et la sous-estime dans l’autre.

Arrêtez-vous si la source dont vous disposez ne correspond pas à la surface. Une évaluation menée depuis un pair à l’intérieur du tunnel ne doit pas être présentée comme un résultat avant authentification, et un test qui exige une source externe approuvée ne doit pas être déplacé en silence vers l’intérieur pour éviter la paperasse.

Étape 3 : confirmez la route et le chemin de retour à travers le téléphone

Lorsque l’appareil transfère vers un autre sous-réseau, le scanner a besoin d’une route autorisée et la cible d’un chemin de retour fonctionnel. Confirmez les deux au lieu de supposer qu’une réponse ping signifie que le chemin est complet.

ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8

Le NAT source change ce que voit le service en aval. Si le téléphone traduit l’adresse du scanner, les règles d’accès et les journaux de la cible s’appliquent à l’adresse traduite, si bien qu’un service qui semble vous accepter accepte peut-être le téléphone plutôt que le scanner.

Surveillez aussi un chevauchement avec le réseau du scanner lui-même. Si le téléphone route 192.168.1.0/24 et que le scanner se trouve sur un LAN numéroté de la même façon, les sondes atteignent des appareils locaux et le rapport les décrit comme la cible. Vérifiez la route que le scanner lui-même utiliserait avant d’envoyer un seul paquet.

Scannez l’adresse réelle de la cible et conservez le nom d’hôte dont l’application a besoin pour l’identité TLS et l’hébergement virtuel. Atteindre une passerelle prouve que la passerelle répond ; cela ne teste pas le service derrière elle.

Étape 4 : traitez la découverte comme une sonde avec des hypothèses

La découverte d’hôtes est l’endroit où les résultats d’évaluation se trompent le plus souvent. La découverte locale par Ethernet ne traverse pas un VPN routé, si bien que les sondes qui fonctionnent sur un LAN plat n’arrivent tout simplement pas. Les sondes de découverte bloquées font alors paraître absent un service accessible et autorisé.

Décidez consciemment d’ignorer ou non la découverte et de scanner directement les adresses connues, puis dites-le dans le rapport. Un port qui répond n’est pas la preuve que l’authentification VPN a réussi, et une réponse filtrée n’est pas la preuve que rien n’écoute. Le débit fait partie du même problème. Un téléphone qui limite ou abandonne des paquets lors d’un scan rapide produit des états filtrés qui appartiennent au téléphone et non au service, alors réduisez la concurrence et rescannez avant d’enregistrer un port comme fermé.

La condition d’arrêt ici relève de l’interprétation, non de la technique : si vous ne pouvez pas dire ce qu’un état signifie pour ce chemin, le résultat appartient à une annexe et non aux constats.

Étape 5 : tenez la fenêtre, puis fermez-la

Un téléphone est un mauvais serveur parce qu’il est conçu pour dormir. L’optimisation de la batterie, le doze et la gestion de l’énergie Wi-Fi peuvent suspendre l’application au milieu de l’évaluation, et une reconnexion du tunnel peut changer l’adresse utilisée par la cible. Une exécution qui couvre l’un de ces événements a une fenêtre de résultats invalide.

Maintenez le rôle de passerelle dans le périmètre le plus réduit que la tâche approuvée permet, surveillez le tunnel pendant que l’exécution est active et consignez le début et la fin de chaque fenêtre que vous rapportez. À la fin de l’évaluation, retirez l’accès temporaire par son propriétaire, conservez l’enregistrement de la source et du chemin, et protégez la sortie comme tout autre artefact de test.

Si vous avez besoin d’un point d’observation reproductible plutôt que d’un succès ponctuel, c’est le livrable pour lequel il faut argumenter. la référence sur la découverte d’hôtes explique quelles sondes présupposent un segment local, et c’est ce détail qui transforme un résultat vide en une affirmation défendable.