Exercice 1 : Le suivi de connexion un peu plus complexe
Je vais vous demander de faire un exercice sur le même principe que le précédent, mais avec un peu plus d’échanges.
Vous allez donc devoir faire le diagramme d’une connexion entre un client et un serveur qui font les échanges suivants :
Le client fait une demande au serveur avec 25 octets de données.
Le serveur lui répond avec un premier segment contenant 500 octets de données.
Puis un second de 400 octets.
Le client fait alors une nouvelle demande de 25 octets, en même temps que le serveur lui répond avec un troisième segment contenant 400 octets de données.
Le serveur répond à la seconde demande avec 500 octets.
Il y a un temps d’attente.
Le serveur répond avec 400 octets de plus.
Le client clôt sa connexion.
Le serveur clôt la sienne à son tour.
Faites bien attention à ne rien oublier. Si vous ne savez pas comment gérer certaines parties, essayez d’en imaginer les solutions et vous verrez avec la correction si vous aviez le bon raisonnement.
Exercice 2 : L’étude d’une trace Wireshark
Dans cet exercice, je vais vous demander de lancer Wireshark et de suivre une connexion TCP de A à Z. L’objectif pour vous est de retrouver les segments significatifs de la connexion, et de vérifier que les numéros de séquence et d’acquittement sont corrects en fonction des données échangées.
N’oubliez pas d’utiliser les filtres de Wireshark pour éviter d’avoir à retrouver vos échanges réseau parmi la foultitude d’autres échanges de votre carte !
Correction des exercices
Exercice 1
Alors déjà, sachez que cet exemple de connexion qui peut paraître complexe l’est en fait très peu par rapport aux connexions que vous établissez dans la vraie vie !
Parcourons ensuite la correction.
Etape 1 : Etablir la connexion
On commence par établir la connexion de façon habituelle et normale avec le three way handshake.
Le client fait sa demande de 25 octets, pas de problème.
Le serveur répond en deux fois. On peut remarquer dans le second segment que son numéro de séquence a augmenté, mais cela est conforme à la définition, vu que le numéro de séquence prend la valeur du premier octet des données, et que des données ont été envoyées dans le précédent segment.
Etape 2 : Envoi croisé de données
Ce qui se passe ensuite est un peu plus complexe : l’envoi des deux segments réseau se fait simultanément ; ils vont donc se croiser.
Pour le client, le numéro de séquence passe à 26, car 25 octets ont été envoyés dans le précédent segment, et le numéro d’acquittement montre que le client a bien reçu les 900 octets de données précédents. Par contre, les 400 octets envoyés par le serveur en parallèle n’ont pas encore été reçus et ne peuvent donc pas être indiqués dans ce numéro d’acquittement.
Pour le serveur, le numéro de séquence est à 901 pour l’envoi, car 900 octets ont été envoyés précédemment. Le numéro d’acquittement ne change pas, car le serveur n’a toujours reçu aucune donnée supplémentaire de la part du client, à ce moment-là de la communication !
Etape 3 : Envoi du segment de signalisation
Arrive un temps d’attente. Une machine qui participe à une connexion TCP doit pouvoir différencier une coupure de connexion d’une attente. C’est pour cela que même si les machines n’ont rien à envoyer, elles envoient des segments dits de signalisation. Ces segments qui ne contiennent aucune donnée servent à maintenir la connexion TCP tout en indiquant l’état actuel. Ainsi, les machines continent de savoir que tout se passe bien... ou pas.
Le client envoie donc un segment vide. Il indique dans le numéro d’acquittement tout ce qu’il a reçu, et notamment le précédent segment.
Etape 4 : Cloture de la connexion
Le serveur envoie ses dernières données et vient alors le moment de clore la connexion, puisque le client a reçu les réponses à toutes ses requêtes. La connexion se ferme normalement.
On peut remarquer que les numéros finaux d’acquittement sont égaux au nombre de données échangées + 2. En effet, il y a un +1 lors du three way handshake et de la réception du premier SYN, et un autre +1 lors de la réception du FIN pour la fermeture de la connexion.
Si vous avez réussi à écrire ces échanges sans faute, de A à Z, bravo, vous êtes prêt à vous plonger dans la sécurité associée au suivi de connexion TCP.
Mais avant cela, regardons la correction du second exercice.
Exercice 2
Alors pour cet exercice, nous n’allons pas passer tout en revue de A à Z, mais nous attarder sur les éléments importants qu’il fallait voir.
Une fois votre trace Wireshark récupérée, il faut commencer par essayer de filtrer la connexion qui nous intéresse.
On peut déjà filtrer sur les adresses IP pour isoler celle du site que nous visitons. Dans mon cas, il s’agit de l’adresse IP 195.154.106.63. Le filtre sous Wireshark utilise la syntaxe ip.addr pour les adresses IP :
En cliquant sur Apply, on voit tout de suite que seuls les paquets ayant comme adresse source ou destination l’adresse filtrée restent dans l’affichage.
Il se peut encore que plusieurs connexions aient été ouvertes avec la machine destination. Dans ce cas, on peut ajouter un filtre supplémentaire sur le port source utilisé par le client. Ainsi, nous n’aurons bien qu’une seule et unique connexion.
On se retrouve alors avec le filtre :
ip.addr==195.154.106.63 and tcp.port==57170
Et notre connexion affichée bien proprement !
Nous voyons effectivement dans la colonne info le SYN dans le premier segment, puis la réponse avec SYN+ACK, et puis les différents ACK qui suivent.
On voit aussi ici, vu que la connexion est courte et représente peu de segments, que la fin de la connexion est présente. On voit d’ailleurs les FIN+ACK suivis du ACK à la fin, même si un ACK est venu se glisser dans cette fin de connexion, ce qui ne pose d’ailleurs aucun problème !
Enfin, on peut regarder les numéros de séquence et d’acquittement du dernier segment. Cela nous permet de savoir combien d’octets ont été échangés dans cette communication :
On voit ici que le dernier numéro de séquence du serveur vaut 966, il aura donc envoyé... 964 octets. Et son dernier numéro d’acquittement est 1 193, ce qui veut dire qu’il a reçu 1 191 octets de la part du client.
On pourrait aller voir plus en détail le contenu de chaque segment, mais ça, vous pouvez tout à fait aller l’explorer de votre côté !
