Dans cette section, nous allons montrer les différents patches à disposition pour permettre un meilleur suivi de connexions. Pour les utiliser, chargez simplement les modules correspondants (avec les bonnes options si nécessaire).
Ce patch par Brian J. Murrell <netfilter@interlinx.bc.ca> ajoute le support de suivi de connexions et de nat pour le protocole qu'utilise l'outil de backup Amanda.
Ce patch par Magnus Sandin <magnus@sandin.cx> ajoute le support de suivi de connexions pour les réseaux de eggdrop bots.
Ce patch par Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> ajoute le support de suivi de connexions et nat pour H.323/netmeeting.
H.323 utilise les flux de données suivants :
Les modules de suivi de connexions et de NAT pour H.323 suivent et nat les connexions demandées sur des ports dynamiques. Le module utilise le bricolage qui est de chercher/remplacer, qu'utilisait le module ip_masq_h323.c des noyaux 2.2
Au minimum, H.323/netmeeting (vidéo/audio) est fonctionnel en laissant passer les connexions sur le port 1720, et en chargeant ce(s) module(s).
Ces modules ne supportent pas :
Ce patch par Harald Welte <laforge@gnumonks.org> permet à DCC de fonctionner à travers une NAT/suivi de connexions. Par défaut, ce patch va suivre les connexions sur le port 6667. Mais vous pouvez faire en sorte que les connexions soient suivies sur un autre port avec le paramètre `port=xx'.
Ce patch par Filip Sneppe <filip.sneppe@cronos.be> ahoute le support de suivi de connexions pour le protocole Microsoft Streaming Media Services.
Ceci permet aux clients (Windows Media Player) et au serveur de négocier le protocole (UDP, TCP) et le port que le flux de données utilisera. Une analyse partielle du protocole peut être trouvée ici, avec aussi un lien vers un client Linux.
Il est recommendé d'ouvrir le port UDP 1755, puisque c'est le port qui est utilisé lors des demandes de retransmission.
Ces modules on été testés sans problème dans des mises en place utilisant SNAT et DNAT.
Ce patch par Harald Welte <laforge@gnumonks.org> permet à netfilter de suivre et de NATer les connexions pptp.
Ce patch par Filip Sneppe <filip.sneppe@cronos.be> ajoute le support de suivi de connexions et de nat pour Quake III Arena.
Ce patch par Ian Larry Latter <Ian.Latter@mq.edu.au> ajoute le support pour la suivi de connexions RSH.
Une suivi des connexions RSH deviens nécessaire si la connexion dynamique d'erreur "serveur vers client" est attendue, pendant une sessions RSH normale. Ça ce passe typiquement comme ça :
Client 0:1023 --> Serveur 514 (flux 1 - stdin/stdout)
Client 0:1023 <-- Serveur 0:1023 (flux 2 - stderr)
L'auteur de ce patch vous averti que ce module peut être dangereux, et que ça n'est pas une bonne solution que d'utiliser RSH, mais surtout vous averti que vous devriez utiliser SSH à la place, autant que possible.
Ce patch par James Morris <jmorris@intercode.com.au> permet à netfilter de NATter le SNMP basic. C'est la forme ``basic'' du protocole SNMP, comme décrite dans la RFC 2962, ça marche en modifiant l'adresse IP a l'intérieur des paquets SNMP.
Ce patch par Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> permet à netfilter de suivre les connexions talk, et aussi de les NATter. Par défaut, otalk (UDP port 517) et talk (UDP port 518) sont supportés. Le support pour otalk/talk peut être sélectionné individuellement en passant un paramètre au moment du chargement du module. Les options sont :
Où `0' signifie `pas de support' alors que `1' veut dire `supporte' le protocole voulu.
Ce patch par Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> permet à netfilter de suivre les connexions TCP en accord avec l'article Real Stateful TCP Packet Filtering in IP Filter par Guido van Rooij. Il supporte window scaling, et peut maintenant gérer les connexions déjà établies.
Ce patch par Magnus Boden <mb@ozaba.mine.nu> permet à netfilter de suivre et de NATer les connexions tftp. Par défaut, ce patch va suivre les connexions sur le port 69. Mais vous pouvez faire en sorte que les connexions soient suivies sur un autre port avec le paramètre `port=xx'.