Les connexions UDP ne sont pas des connexions à part entière, mais plutôt des connexions "sans état". Il y a plusieurs raisons pour cela, la principale parce qu'elles ne contiennent aucun établissement ou fermeture de connexion; la plupart n'ont pas de liaison. En recevant deux datagrammes UDP dans un ordre spécifique, on ne peut savoir dans quel ordre ils ont été envoyés. Cependant, il est toujours possible de placer des états sur les connexions dans le noyau. Voyons comment une connexion peut être tracée et à quoi elle ressemblerait dans le conntrack.
Comme on peut le voir, la connexion circule presque exactement de la même façon qu'une connexion TCP. Ceci, du point de vue de l'utilisateur. En interne, l'information conntrack est un peu différente, mais intrinsèquement les détails sont les mêmes. Premièrement, regardons les entrées après que le paquet UDP initial ait été envoyé.
udp 17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 \
[UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 \
dport=137 use=1
Comme vous pouvez le voir entre la première et la deuxième
valeur, c'est un paquet UDP. Le premier est le nom du protocole, le
second le numéro du protocole. C'est identique pour une connexion
TCP. La troisième valeur indique combien de secondes cet état s'est
maintenu. Après cela, nous avons les valeurs du paquet que nous
avons vu et les probabilités que les paquets sur cette connexion
nous joignent depuis l'expéditeur. Ce sont la source, la
destination, le port source et le port destination. À ce point le
fanion [UNREPLIED] nous indique
qu'il n'y a pas eu de réponse au paquet. Enfin, nous avons une
courte liste de probabilités de retour de paquets. Notez que les
dernières entrées sont en ordre inverse des premières valeurs. Le
délai d'attente est de 30 secondes dans ce cas, par défaut.
udp 17 170 src=192.168.1.2 dst=192.168.1.5 sport=137 \
dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 \
dport=137 [ASSURED] use=1
À ce point le serveur a vu une réponse au premier paquet envoyé
et la connexion est maintenant considérée comme ESTABLISHED. Ce n'est pas indiqué
dans le traçage de connexion comme vous pouvez le voir. La
principale différence est que le fanion [UNREPLIED] est maintenant fourni.
D'ailleurs, le temps d'attente par défaut a changé pour passer à
180 secondes - mais dans cet exemple il a été décrémenté pour
passer à 170 secondes - avec un délai de 10 secondes, il sera de
160 secondes. Une chose qui a été oubliée et qui peut changer
légèrement est le fanion [ASSURED] décrit ci-dessus. Pour placer le
fanion [ASSURED] sur un traçage
de connexion, il doit y avoir un paquet en réponse au paquet
NEW.
udp 17 175 src=192.168.1.5 dst=195.22.79.2 sport=1025 \
dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 \
dport=1025 [ASSURED] use=1
Ici, la connexion est assurée. La connexion a exactement le même aspect que dans l'exemple précédent. Si cette connexion n'est pas utilisée dans les 180 secondes, elle est hors délai. 180 secondes est comparativement une valeur basse, mais qui devrait être suffisante dans la plupart des cas. Cette valeur est réinitialisée complètement pour chaque paquet qui correspond à la même entrée et passe à travers le pare-feu, comme pour tous les états internes.