Passerelle ou client transféré ? Lire l'adresse source

Le serveur web journalise une adresse, et tout le monde suppose qu'elle appartient au processus de la passerelle elle-même. Elle peut appartenir à un client transféré dont l'adresse privée a disparu à l'étape de traduction. La destination voit la source réseau visible et rien de plus. C'est un constat de limite, non l'affirmation que l'origine ne peut jamais être établie.

Ce que la destination voit réellement

Prenez un client à 10.20.0.7, une passerelle dont l'adresse extérieure est 198.51.100.10, et une destination sur internet. Si la passerelle traduit la source du client, la socket de la destination enregistre 198.51.100.10. L'adresse privée disparaît du paquet, et la destination ne peut pas la relire depuis cet en-tête. Ces chiffres sont illustratifs, pas une capture de votre réseau.

L'observation reste utile : elle identifie la source réseau que la destination doit autoriser ou bloquer. Elle n'identifie simplement pas la personne ni le processus derrière. Pour l'exploitant de la destination, cette distinction décide si un blocage est une décision de réseau ou une décision de compte.

L'état de traduction n'est pas visible pour la destination

La passerelle conserve la correspondance entre la connexion traduite et le client d'origine, et c'est exactement cet état qui manque à la destination. description traditionnelle du NAT sépare l'enregistrement de traduction des en-têtes visibles ensuite. Lire un côté ne donne pas l'autre.

Des conceptions différentes produisent des preuves différentes. Le trafic routé avec des adresses source préservées montre l'adresse réelle du client, tandis qu'un proxy applicatif termine la connexion et en crée une nouvelle. Une route à source préservée exige aussi que l'adresse du client soit routable en retour depuis la destination, ce que tous les déploiements n'offrent pas. Demandez quelle conception est déployée avant d'interpréter une ligne de journal.

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

Le TTL et les empreintes sont des indices, pas des preuves

Le TTL d'IPv4 dépend de la valeur initiale choisie par l'émetteur et du nombre de sauts traversés par le paquet. Sans ces deux faits, une valeur ne peut pas prouver qu'un saut VPN a eu lieu. Un saut routé supplémentaire connu ne permet pas non plus de distinguer un routeur LAN, un chemin de tunnel ou un autre dispositif de transfert. Traitez une différence de TTL comme une question, non comme une conclusion.

Les autres signaux se comportent de la même manière. Un en-tête User-Agent peut être défini par l'application, et une similitude de timing peut refléter une infrastructure partagée plutôt qu'une personne partagée. Plusieurs utilisateurs peuvent partager une sortie, et un utilisateur peut changer de chemin entre les sessions. Rassemblés, plusieurs signaux faibles peuvent justifier un examen plus attentif des enregistrements d'une passerelle, mais ils ne deviennent pas des preuves solides par accumulation.

Autorisez par identité, pas par adresse

Si la destination doit séparer l'administration de la passerelle de l'activité des utilisateurs distants, donnez à ces rôles des identités authentifiées distinctes et des opérations autorisées. Une source publique partagée peut encore servir de restriction réseau, mais elle ne remplace pas l'authentification de l'utilisateur ou de l'appareil.

Gardez les preuves étiquetées : source observée, compte authentifié, moment et l'inférence à l'examen. Ne traduisez pas « aucune source interne visible ici » par « aucune attribution possible nulle part ». L'étiquette compte lorsque quelqu'un qui n'a pas participé à l'enquête lit l'enregistrement des mois plus tard.

Notez la date de l'observation et le système qui l'a produite. Un extrait de journal sans attribution est difficile à défendre plus tard.