Suivre un paquet jusqu’au serveur

Quand un utilisateur ne parvient pas à joindre votre application web, vous devez savoir où le trafic circule avant de modifier le pare-feu. Une connexion ne se résume pas à une demande qui arrive : le serveur doit aussi pouvoir répondre au client.

Dans cette leçon, vous allez suivre le trajet général d’une connexion entrante vers le serveur web, puis celui de la réponse. Vous distinguerez aussi ce trajet du trafic émis par le serveur et du trafic qui le traverse vers une autre destination.

Un paquet suit un trajet

Un paquet réseau transporte une partie des données échangées entre des machines. Pour acheminer le paquet, le réseau s’appuie notamment sur l’adresse de destination ; une fois arrivé au serveur, le système peut le remettre au composant concerné. Une connexion complète implique généralement plusieurs paquets dans les deux sens, et non un unique bloc de données.

Dans le projet fil rouge, un navigateur envoie une demande destinée au serveur de l’application web. Le paquet quitte la machine du client, traverse le réseau et arrive sur le serveur : vu depuis celui-ci, ce mouvement constitue du trafic entrant. Le serveur reçoit la demande et produit une réponse à destination du client.

La réponse repart vers le client

Après réception de la demande, le serveur envoie des paquets de réponse vers le client. Du point de vue du serveur, ces paquets constituent du trafic sortant. Le chemin de retour peut traverser le même réseau sans être une simple répétition de la demande : les données et leur direction sont différentes.

Ne confondez pas les trois trajets

Le trafic entrant est destiné au serveur lui-même, comme la demande adressée à votre application. Le trafic sortant est produit par le serveur et quitte celui-ci, par exemple lorsqu’il contacte un service externe. Le trafic transféré traverse le serveur pour rejoindre une autre destination : le serveur agit alors comme un relais plutôt que comme le destinataire final.

Cette distinction porte sur le trajet par rapport au serveur, pas sur le fait qu’un paquet soit « bon » ou « mauvais ». Un échange ordinaire avec l’application comprend souvent une partie entrante et une réponse sortante. Le filtrage de ces différents trajets sera étudié avec les chaînes d’iptables dans la leçon suivante ; vous n’avez pas besoin de les configurer ici.

Suivre un échange sur le serveur

Pour observer des paquets sans modifier la configuration du pare-feu, vous pouvez utiliser tcpdump, un outil de capture réseau. Depuis le serveur, une capture sur toutes les interfaces avec un filtre portant sur l’adresse du client permet de repérer les paquets échangés avec cette machine. Remplacez l’adresse d’exemple par celle d’un client que vous êtes autorisé à tester.

sudo tcpdump -ni any 'host 198.51.100.25'

Exemple de lignes possibles :
IP 198.51.100.25.53124 > 203.0.113.10.443: ...
IP 203.0.113.10.443 > 198.51.100.25.53124: ...

Dans cet exemple fictif, la première ligne montre un paquet allant du client vers le serveur ; la seconde montre un paquet dans le sens inverse. Les adresses et valeurs affichées ici servent uniquement à illustrer la lecture et ne décrivent pas votre serveur. Une capture peut révéler la circulation de paquets, mais elle ne prouve pas à elle seule que l’application a correctement traité la demande.

À retenir

• Un paquet transporte une partie des données échangées entre des machines.
• Une demande destinée au serveur correspond à du trafic entrant ; sa réponse repart en trafic sortant.
• Le trafic transféré traverse le serveur vers une autre destination.
• Pour comprendre un accès, suivez la demande et le chemin de retour avant de changer le filtrage.

Dans la prochaine leçon, vous associerez ces trajets aux chaînes d’iptables, qui permettent de repérer à quel moment le filtrage examine le trafic.