Une des meilleures précautions que vous pouvez prendre contre un pare-feu qui se bloque, est tout simplement d'utiliser le programme cron pour ajouter un script qui se lance toutes les 5 minutes ou qui relance le pare-feu, et ensuite supprimer la ligne du cron une fois que vous êtes sûr que l'installation fonctionne bien. La ligne du cron peut ressembler à l'exemple ci-dessous, elle sera installée par la commande crontab -e.
*/5 * * * * /etc/init.d/rc.flush-iptables.sh stop
Soyez absolument sûrs, que la ligne fonctionne et fait exactement ce que vous en attendez sinon ça peut bloquer le serveur.
Un autre outil qui est constamment utilisé pour déboguer les scripts est la fonction syslog. C'est ce qui journalise tous les messages générés par beaucoup de programmes différents. En fait, la plupart des gros programmes supportent la journalisation par syslog, y compris le noyau. Tous les messages envoyés à syslog ont deux variables de base dont il est très important de se souvenir, la fonction et le niveau/priorité de la journalisation.
La fonction indique au serveur syslog de quel endroit provient l'entrée du journal, et quoi journaliser. Il existe plusieurs fonctions spécifiques, mais celle qui nous intéresse est la fonction Kern, ou fonction kernel. Tous les messages générés par netfilter sont envoyés par cette fonction.
Le niveau de journalisation indique à syslog quelle priorité ont les messages. Il existe plusieurs priorités, voir ci-dessous :
En fonction de ces priorités, nous pouvons les envoyer vers différents fichiers journaux en utilisant le syslog.conf. Par exemple, pour envoyer tous les messages provenants de la fonction kern avec une priorité warning vers un fichier appelé /var/log/kernwarnings, nous ferons comme ci-dessous. La ligne sera placée dans /etc/syslog.conf.
kern.warning /var/log/kernwarnings
Comme vous pouvez le voir, c'est tout à fait simple. Maintenant, vous trouverez vos journaux de netfilter dans le fichier /var/log/kernwarnings (après redémarrage, ou en faisant un HUP sur le serveur syslog). Bien sûr, ceci dépend du niveau de journalisation que vous avez mis dans vos règles de netfilter. Le niveau de journalisation peut être placé avec l'option --log-level.
Ces journaux vous fourniront l'information que vous désirez via les règles de journalisation spécifiques dans la table de règles. Avec elles, vous pouvez savoir s'il existe un problème quelque part. Par exemple, vous pouvez placer vos règles de journalisation à la fin des chaînes pour voir s'il y a des paquets qui ont transité jusqu'à la frontière de vos chaînes. Une entrée de journal peut ressembler à l'exemple ci-dessous, et inclure les informations suivantes.
Oct 23 17:09:34 localhost kernel: IPT INPUT packet died: IN=eth1 OUT= MAC=08:00:09:cd:f2:27:00:20:1a:11:3d:73:08:00 SRC=200.81.8.14 DST=217.215.68.146 LEN=78 TOS=0x00 PREC=0x00 TTL=110 ID=12818 PROTO=UDP SPT=1027 DPT=137 LEN=58
Comme vous pouvez le comprendre, syslog peut réellement vous aider à déboguer vos tables de règles. Regarder ces journaux peut vous aider à comprendre pourquoi les ports que vous voulez ouvrir ne fonctionnent pas.