Page suivante Page précédente Table des matières

6. Autres sujets relatifs à IP Masquerade et au support logiciel

6.1 Problèmes avec IP Masquerade

Certains protocoles TCP/IP propriétaires ne marcheront pas avec l'IP masquerading Linux, soit car ils supposent des choses sur les numéros de port ou soit qu'ils encodent les adresses/ports TCP/IP dans leurs les données. Ces protocoles ont besoin de proxy ou de modules intégrés dans le code du masquerading pour fonctionner.

6.2 Services entrants

A la base, le masquerading ne peut pas du tout prendre en charge les services entrants mais il y a plusieurs façons de les autoriser

Si vous n'avez pas besoin d'une grande sécurité, vous pouvez simplement rediriger ou forwarder les ports. Il y a de nombreuses façons de faire cela toutefois, la meilleur solution est d'utiliser IPPORTFW. Pour plus d'informations, référez vous a la section Forwarders .

Si vous désirez avoir des niveaux d'autorisation sur les connexions entrantes, vous aurez alors soit à utiliser les TCP Wrappers soit Xinetd pour autoriser seulement des adresses IP données, ou utiliser d'autre outils. La boîte à outils pour firewall TIS (TIS Firewall Toolkit) est un bon produit pour ceux qui cherchent des outils et des informations.

Plus de détails sur la sécurité peuvent être trouvés dans le document TrinityOS et sur la page de l'IP Masquerade.

6.3 Programmes clients supportés et autres remarques pour la configuration

** Voyez la page sur les applications fonctionnant au travers d'IP Masquerading contient plein de bonnes informations. Malheureusement, Cette page n'est plus vraiment mise a jour, si vous voulez vous en occuper, envoyez un mail a ambrose@writeme.com et/ou dranch@trinnet.net.

En général, toutes les applications qui utilisent TCP et/ou UDP de manière standard devraient fonctionner. Si vous avez une quelconque suggestion ou question à propos des applications compatibles avec IP masquerade, visitez la page de l'IP Masquerade.

Les clients réseau qui fonctionnent avec l'IP Masq

Clients génériques

Archie

toutes les plateformes, client de recherche de fichiers (tous les clients ne fonctionnent pas) ;

FTP

toutes les plateformes, avec le module ip_masq_ftp.o (tous les sites ne fonctionnent pas avec certains clients ; par exemple, certains sites ne peuvent pas être atteints en utilisant ws_ftp32 mais fonctionnent avec Netscape) ;

Gopher

toutes les plateformes ;

HTTP

toutes les plateformes, naviguer sur le web ;

IRC

toutes les plateformes, avec le module ip_masq_irc.o ;

NNTP

toutes les plateformes, client news USENET ;

ping

toutes plateformes, avec le patch ICMP

POP

toutes les plateformes, clients de courrier électronique ;

SSH

toutes plateformes, client Telnet/FTP sécurisé ;

SMTP

toutes les plateformes, clients de courrier électronique ;

Telnet

toutes les plateformes, sessions distantes ;

traceroute

surtout les plateformes UNIX, certaines variantes ne devraient pas fonctionner ;

VRML

Windows (peut être toutes les plateformes), réalité virtuelle ;

WAIS

toutes les plateformes.

Clients Multimédia et de communication

Alpha Worlds

Windows, programme client-serveur de discussion 3D

CU-SeeMe

toutes les plateformes, avec le module cuseeme, voir la section CuSeeme pour les détails.

ICQ

Tous clients supportés. Requiert d'avoir compilé le noyau avec IPPORTFW et qu'ICQ soit configuré pour être derrière un proxy non socks. Une description complète de la configuration se trouve dans la section ICQ .

Internet Phone 3.2

Windows, communications audio. Vous ne pouvez être contacté que si vous initiez la connexion, mais on ne peut pas vous appeler si vous n'avez pas mis en place un port forwarding spécifique. Référez vous a la section Forwarders pour plus de détails.

Internet Wave Player

Windows, flux audio par réseau

Powwow

Windows, communication audio. Vous ne pouvez être contacté que si vous initiez la connexion, mais on ne peut pas vous appeler si vous n'avez pas mis en place un port forwarding spécifique. Référez vous a la section Forwarders pour plus de détails.

Real Audio Player 2.0

Windows, flux audio par réseau, on obtient une meilleur qualité avec le module ip_masq_raudio.

True Speech Player 1.1b

Windows, flux audio par réseau

VDOLive

Windows, avec le patch ip_masq_vdolive

Worlds Chat 0.9a

Windows, programme client-serveur de discussion 3D

Jeux - Référez vous a la section LooseUDP pour plus d'informations sur comment utiliser le patch LooseUDP.

Battle.net

Fonctionne mais requiert que les ports TCP 116 et 118 et le port UDP 6112 soient IPPORTFW sur la machine qui joue. Référez vous a la section Forwarders pour plus de détails. Notez que les serveurs FSGS et Bnetd requièrent toujours IPPORTFW car ils n'ont pas été réécrits pour marcher avec le NAT.

BattleZone 1.4

Fonctionne avec le patch LooseUDP et les nouvelles .DLLs d'Activision qui marchent avec le NAT.

Dark Reign 1.4

Fonctionne avec le patch LooseUDP ou requiert que les ports TCP 116 et 118 et le port UDP 6112 soient IPPORTFW sur la machine qui joue. Référez vous a la section Forwarders pour plus de détails

Diablo

Fonctionne avec le patch LooseUDP ou requiert que les ports TCP 116 et 118 et le port UDP 6112 soient IPPORTFW sur la machine qui joue. Les dernières version de Diablo utilisent uniquement les ports TCP et UDP 6112. Référez vous a la section Forwarders pour plus de détails

Heavy Gear 2

Fonctionne avec le patch LooseUDP ou requiert que les ports TCP 116 et 118 et le port UDP 6112 soient IPPORTFW sur la machine qui joue. Référez vous a la section Forwarders pour plus de détails

Quake I/][/]I[

Fonctionne sans problèmes avec le module ip_masq_quake si il y a plusieurs joueurs derrière la machine MASQ. Ce module ne supporte que Quake I et QuakeWorld par défaut. Si vous avez besoin d'utiliser Quake ][ ou des ports non standards, regardez comment s'installe le module dans les sections rc.firewall-2.0.x et rc.firewall-2.2.x .

StarCraft

Fonctionne avec le patch LooseUDP ou requiert que les ports TCP et UDP 6112 soient IPPORTFW sur la machine qui joue. Référez vous a la section Forwarders pour plus de détails

WorldCraft

Fonctionne avec le patch LooseUDP.

Autres clients

Linux net-acct package

Linux, package d'administration par réseau

NCSA Telnet 2.3.08

DOS, une suite de logiciels contenant telnet, ftp, ping, etc...

PC-anywhere pour Windows

MS-Windows, controle d'un PC à distance avec TCP/IP, fonctionne uniquement si la machine est un client et non un hôte si vous n'avez pas joué avec IPPORTFW. Référez vous a la section Forwarders pour plus de détails

Socket Watch

utilise ntp - network time protocol

Clients qui ne fonctionnent pas

Tous les programmes H.323

MS Netmeeting, Intel Internet Phone Beta 2... Connexion ok, mais la voix ne peut que sortir de votre réseau. Allez faire un tour sur la passerelle H.323 Equivalence's PhonePatch qui est une solution possible.

Intel Streaming Media Viewer Beta 1

Connexion impossible au serveur.

Netscape CoolTalk

Connexion à l'hôte distant impossible.

WebPhone

Ne peut pas fonctionner (il fait des suppositions invalides sur les adresses).

6.4 Regles ipfwadm plus sures

Cette section constitue un guide plus précis sur l'utilisation de l'outil de reglage du firewall sur les noyaux 2.0, ipfwadm. Allez voire plus bas pour ipchains.

Voici un exemple de script d'initialisation pour un système qui fait office de firewall et de masquerading derriere un lien PPP avec une IP statique (des instructions pour les ip dynamiques sont données, mais commentées). L'interface à laquelle on fait confiance est 192.168.0.1 (celle du réseau local) et l'adresse IP de l'interface PPP a été changée pour des raisons de sécurité. Toutes les interfaces sont listées individuellement pour intercepter l'IP spoofing et les routages inexacts. Tout ce qui n'est pas explicitement autorisé est INTERDIT (disons plutôt rejeté). Si machine IP MASQ ne marche plus apres avoir lancé ce script, assurez vous de bien avoir édité le script pour qu'il sont en accord avec votre configuration, allez aussi jeter un coup d'oeil dans votre syslog /var/log/messages ou /var/adm/messages pour y trouver une ou deux erreurs de firewall.

Pour des exemples plus précis sur l'implémentation de règles sures pour PPP, modem Câble, etc., référez vous à TrinityOS - Section 10 et GreatCircle's Firewall WWW page

NOTE : Si vous avez une adresse TCP/IP assignée dynamiquement par votre FAI (PPP, ADSL, Câble, etc.), vous ne pouvez pas charger ce script au boot. Vous allez soit avoir a le recharger a chaque fois que vous changez d'adresse IP, soit rendre votre /etc/rc.d/rc.firewall plus intelligent. Pour les utilisateurs de PPP, lisez attentivement et décommentez les lignes qui vous concernent dans la section "Récupération dynamique de l'IP en PPP" ci dessous. Vous pourrez aussi trouver plus de détails dans TrinityOS - Section 10 pour plus de détails sur les règles plus sures avec des IP Dynamiques.

Rappelez vous qu'il y a plein d'outils graphiques pour régler votre Firewall. Référez vous a la section FAQ pour plus de détails.

Enfin, si vous utilisez une adresse PPP statique, changez la ligne "ppp_ip = "votre_adresse_ip_statique"" pour refléter votre adresse. 

#!/bin/sh
#
# /etc/rc.d/rc.firewall, un exemple de regles plutot sures de firewall avec ipfwadm
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin

# pour les tests, attend un moment puis efface toutes les règles du
# firewall. Décommentez les lignes suivantes si vous voulez que le firewall soit
# désactivé automatiquement après 10 minutes.
# (sleep 600; \
# ipfwadm -I -f; \
# ipfwadm -I -p accept; \
# ipfwadm -O -f; \
# ipfwadm -O -p accept; \
# ipfwadm -F -f; \
# ipfwadm -F -p accept; \
# ) &


########################################################################################
# Necessaire pour charger les modules
#
/sbin/depmod -a

# Supporte le masquerading des transferts de fichiers FTP utilisant la méthode PORT.
#
/sbin/modprobe ip_masq_ftp

# Supporte le masquerading de RealAudio via UDP. Sans ce module, RealAudio FONCTIONNERA,
# mais en mode TCP. Cela peut causer une réduction dans la qualité du son.
#
#/sbin/modprobe ip_masq_raudio

# Supporte le masquerading des transferts IRC DCC.
#
#/sbin/modprobe ip_masq_irc

# Supporte le masquerading de Quake et QuakeWorld par défaut. Ce module sert si vous
# avez plusieurs utilisateurs derriere le serveur MASQ. Si vous allez jouer a Quake I,
# ][ et ]I[, utilisez le deuxieme exemple.
#
#Quake I / QuakeWorld (ports 26000 et 27000)
#/sbin/modprobe ip_masq_quake
#
#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960)
#/sbin/modprobe ip_masq_quake ports=26000,27000,27910,27960

# Supporte le masquerading du systeme de visioconférences CuSeeMe
#
#/sbin/modprobe ip_masq_cuseeme

# Supporte le masquerading du systeme de visioconférences VDO Live
#
#/sbin/modprobe ip_masq_vdolive


# CRITIQUE : Permet le relayage de paquets IP car il est désactivé par défaut depuis le
#            noyau 2.0.34
#
# Utilisateurs RedHat : Vous pouvez aussi changer l'option dans /etc/sysconfig/network
#                             de :
#                       FORWARD_IPV4=false  
#                             à :
#                       FORWARD_IPV4=true
#
echo "1" > /proc/sys/net/ipv4/ip_forward

# Utilisateurs d'IP dynamiques :
#
# Si vous avez une adresse IP dynamique via SLIP, PPP ou DHCP, décommentez l'option
# suivante. Elle permet d'utiliser une bidouille dans l'IP MASQ qui sert pour les IP
# dynamiques, ce qui rends la vie avec DialD, PPPd et les programmes similaires bien
# plus facile.
#
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr


# Spécifiez votre adresse IP statique ici.
#
#   Si vous utilisez une adresse IP DYNAMIQUE, vous avez besoin de faire comprendre a ce
#   jeu de règles que votre IP a changée a chaque fois qu'elle change. Pour faire cela,
#   décommentez le script suivant. (Notez qu'il y a une différence importante entre les
#   guillemets simples et doubles).
#
#   Vous aurez aussi besoin soit de créer le lien suivant ou que votre /etc/ppp/ip-up
#   existant lance votre /etc/rc.d/rc.firewall.
#
#       ln -s /etc/rc.d/rc.firewall /etc/ppp/ip-up
#
#   Si le fichier /etc/ppp/ip-up existe déjà, vous devriez l'éditer et ajouter une ligne
#   contenant "/etc/rc.d/rc.firewall" aux alentours de la fin du fichier.
#
#   Si vous ne vous en etes pas encore rendu comptes, le script /etc/ppp/ip-up est
#   toujours lancé lorsqu'une connexion PPP est établie. Grâce a cela, nous pouvons dire
#   au script d'aller chercher la nouvelle adresse IP pour pouvoir mettre a jour les
#   règles sures.
#
#   Utilisateurs PPP : 
#        Le bout de script suivant devrais marcher sans problèmes.
#
#   Utilisateurs de DHCP :
#        Si vous obtenez votre adresse TCP/IP via DHCP, vous aurez a remplacer le mot
#        ppp0 par le nom de votre interface via laquelle vous êtes connectés a Internet
#        (eth0, eth1, etc). Il devrais aussi être noté que le DHCP peut changer votre IP
#        adresse. Pour régler cela vous devriez configurer votre client DHCP pour
#        relancer vos règles de firewall a chaque vois que votre bail est
#        renouvelé. Pour les utilisateurs de DHCPcd, utilisez l'option -c.
#   
#ppp_ip = "`/sbin/ifconfig ppp0 | perl -ne 'if (/inet addr:([^ ]*)/) {print $1}'`"
#
ppp_ip = "votre_adresse_ip_statique"


# Durée de vie des connexion MASQuées
#
#    2 hrs pour une session TCP
#   10 sec apres qu'un paquet "FIN" soit passé
#  160 sec pour le traffic UDP (Important pour les utilisateurs d'ICQ)
#
/sbin/ipfwadm -M -s 7200 10 160


########################################################################################
# Connexions entrantes, efface tout et positionne le comportement par défaut à reject
# (refus). En fait, le comportement par défaut est inadéquat puisqu'il y a une règle
# pour tout intercepter, avec refus et logging.
#
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p reject

# interface locale, machines locales. Aller n'importe où est autorisé.
#
/sbin/ipfwadm -I -a accept -V 192.168.0.1 -S 192.168.0.0/24 -D 0.0.0.0/0

# interface distante, prétendant être une machine locale. C'est de l'IP spoofing, on
# refuse.
#
/sbin/ipfwadm -I -a reject -V $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o

# interface distante, n'importe qu'elle source, l'accès à notre adresse PPP est valide
#
/sbin/ipfwadm -I -a accept -V $ppp_ip -S 0.0.0.0/0 -D $ppp_ip/32

# l'interface loopback est valide.
#
/sbin/ipfwadm -I -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0

# une fois toutes les règles faites, toutes les autres connexions entrantes sont
# refusées et logguées.
#
/sbin/ipfwadm -I -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o


########################################################################################
# Connexions sortantes,efface tout et positionne le comportement par défaut à reject
# (refus).En fait, le comportement par défaut est inadéquat puisqu'il y a une règle pour
# tout intercepter, avec refus et logging.
#
/sbin/ipfwadm -O -f
/sbin/ipfwadm -O -p reject

# interface locale, machines locales. N'importe quelle source allant vers le réseau
# local est valide.
#
/sbin/ipfwadm -O -a accept -V 192.168.0.1 -S 0.0.0.0/0 -D 192.168.0.0/24

# destination vers le réseau local à partir de l'interface sortante. C'est du routage
# piraté, tout refuser.
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -o

# sortante depuis le réseau local sur l'interface sortante. C'est du masquerading
# pirate, tout refuser.
#
/sbin/ipfwadm -O -a reject -V  $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o

# sortante depuis le réseau local sur l'interface sortante. C'est du masquerading
# pirate, tout refuser.
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -o

# Tout ce qui sort d'autre de l'interface distante est bon
#
/sbin/ipfwadm -O -a accept -V $ppp_ip -S $ppp_ip/32 -D 0.0.0.0/0

# l'interface loopback est valide.
#
/sbin/ipfwadm -O -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0

# une fois toutes les règles faites, toutes les autres connexions sortantes sont
# refusées et logguées.
#
/sbin/ipfwadm -O -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o


########################################################################################
# Connexions à faire suivre (forwarding), efface tout et positionne le comportement par
# défaut à reject (refus). En fait, le comportement par défaut est inadéquat puisqu'il y
# a une règle pour tout intercepter, avec refus et logging.
#
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p reject

# Masquerade depuis le réseau local sur l'interface locale vers n'importe où
#
/sbin/ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/24 -D 0.0.0.0/0

# une fois toutes les règles faites, toutes les autres connexions à faire suivre sont
# refusées et logguées.
#
/sbin/ipfwadm -F -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o

Avec IPFWADM, vous pouvez bloquer le trafic vers ou depuis un site particulier en utilisant -I, -O ou -F appropriées. Souvenez vous que les règles sont analysées de haut en bas, et "-a" signifie ajoute ("append") à l'ensemble des règles existantes. Avec cela en mémoire, toute restriction spécifique doit venir avant les regles globales. Par exemple :

En utilisant les règles -I. Probablement le plus rapide mais stoppe uniquement les machines locales, le firewall peut encore accéder au site "interdit". C'est peut être d'ailleurs le comportement que vous désirez.

Dans le /etc/rc.d/rc.firewall : 

... début des règles -I ...

# rejette et loggue l'interface locale et la machine locale allant sur 204.50.10.13
#
/sbin/ipfwadm -I -a reject -V 192.168.0.1 -S 192.168.0.0/24 -D 204.50.10.13/32 -o

# interface locale, machines locales. Aller n'importe où est autorisé.
#
/sbin/ipfwadm -I -a accept -V 192.168.0.1 -S 192.168.0.0/24 -D 0.0.0.0/0

... fin des règles -I ...

En utilisant les règles -O. C'est le plus lent puisque les paquets passent d'abord à travers le masquerading, mais cette règle empèche même au firewall d'accéder au site interdit. 

... début des règles -O ...

# rejette et loggue les connexions sortantes vers 204.50.10.13
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S $ppp_ip/32 -D 204.50.10.13/32 -o

# tout le reste, sortant vers l'interface distante est valide
#
/sbin/ipfwadm -O -a accept -V $ppp_ip -S $ppp_ip/32 -D 0.0.0.0/0

... fin des règles -O ...

En utilisant les règles -F. Probablement plus lent qu'en utilisant les règles -I, et cela stoppe uniquement les machines pour lesquelles on effetue du masquerading (c'est à dire les machines internes). Le firewall peut encore accéder au site interdit. 

... début des règles -F ...

# Rejette et loggue les connexions depuis le réseau local sur l'interface PPP vers
# 204.50.10.13.
#
/sbin/ipfwadm -F -a reject -W ppp0 -S 192.168.0.0/24 -D 204.50.10.13/32 -o

# Masquerade depuis le réseau local sur l'interface locale vers n'importe où
#
/sbin/ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/24 -D 0.0.0.0/0

... fin des règles -F ...

Il n'y a pas besoin d'une règle spéciale pour autoriser 192.168.0.0/24 à se connecter sur 204.50.11.0, ce comportement est inclus dans les règles globales.

Il y a plus d'une façon d'écrire les règles précédentes. Par exemple, au lieu de -V 192.168.0.1, vous pouvez utiliser -W eth0, au lieu de -V $ppp_ip, vous pouvez utiliser -W ppp0. Le -V a été supprimé lors du passage a ipchains, mais pour les utilisateurs de ipfwadm, c'est une question de goût personnel.

6.5 Chaines IP Firewalling (ipchains)

Cette section constitue un guide plus précis sur l'utilisation de l'outil de reglage du firewall sur les noyaux 2.2, ipchains. Allez voire plus haut pour ipfwadm.

Voici un exemple de script d'initialisation pour un système qui fait office de firewall et de masquerading derriere un lien PPP avec une IP statique (des instructions pour les ip dynamiques sont données, mais commentées). L'interface à laquelle on fait confiance est 192.168.0.1 (celle du réseau local) et l'adresse IP de l'interface PPP a été changée pour des raisons de sécurité. Toutes les interfaces sont listées individuellement pour intercepter l'IP spoofing et les routages inexacts. Tout ce qui n'est pas explicitement autorisé est INTERDIT (disons plutôt rejeté). Si machine IP MASQ ne marche plus apres avoir lancé ce script, assurez vous de bien avoir édité le script pour qu'il sont en accord avec votre configuration, allez aussi jeter un coup d'oeil dans votre syslog /var/log/messages ou /var/adm/messages pour y trouver une ou deux erreurs de firewall.

Pour des exemples plus précis sur l'implémentation de règles sures pour PPP, modem Câble, etc., référez vous à TrinityOS - Section 10 et GreatCircle's Firewall WWW page

NOTE : Si vous avez une adresse TCP/IP assignée dynamiquement par votre FAI (PPP, ADSL, Câble, etc.), vous ne pouvez pas charger ce script au boot. Vous allez soit avoir a le recharger a chaque fois que vous changez d'adresse IP, soit rendre votre /etc/rc.d/rc.firewall plus intelligent. Pour les utilisateurs de PPP, lisez attentivement et décommentez les lignes qui vous concernent dans la section "Récupération dynamique de l'IP en PPP" ci dessous. Vous pourrez aussi trouver plus de détails dans TrinityOS - Section 10 pour plus de détails sur les règles plus sures avec des IP Dynamiques.

Rappelez vous qu'il y a plein d'outils graphiques pour régler votre Firewall. Référez vous a la section FAQ pour plus de détails.

Enfin, si vous utilisez une adresse PPP statique, changez la ligne "ppp_ip = "votre_adresse_ip_statique"" pour refléter votre adresse. 

#!/bin/sh
#
# /etc/rc.d/rc.firewall: un exemple de regles plutot sures de firewall avec ipchains
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin

# pour les tests, attend un moment puis efface toutes les règles du
# firewall. Décommentez les lignes suivantes si vous voulez que le firewall soit
# désactivé automatiquement après 10 minutes.
# (sleep 600; \
# ipchains -F \
# ipchains -X \
# ) &

########################################################################################
# Necessaire pour charger les modules
#
/sbin/depmod -a

# Supporte le masquerading des transferts de fichiers FTP utilisant la méthode PORT.
#
/sbin/modprobe ip_masq_ftp

# Supporte le masquerading de RealAudio via UDP. Sans ce module, RealAudio FONCTIONNERA,
# mais en mode TCP. Cela peut causer une réduction dans la qualité du son.
#
#/sbin/modprobe ip_masq_raudio

# Supporte le masquerading des transferts IRC DCC.
#
#/sbin/modprobe ip_masq_irc

# Supporte le masquerading de Quake et QuakeWorld par défaut. Ce module sert si vous
# avez plusieurs utilisateurs derriere le serveur MASQ. Si vous allez jouer a Quake I,
# ][ et ]I[, utilisez le deuxieme exemple.
#
#Quake I / QuakeWorld (ports 26000 et 27000)
#/sbin/modprobe ip_masq_quake
#
#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960)
#/sbin/modprobe ip_masq_quake ports=26000,27000,27910,27960

# Supporte le masquerading du systeme de visioconférences CuSeeMe
#
#/sbin/modprobe ip_masq_cuseeme

# Supporte le masquerading du systeme de visioconférences VDO Live
#
#/sbin/modprobe ip_masq_vdolive


# CRITIQUE : Permet le relayage de paquets IP car il est désactivé par défaut depuis le
#            noyau 2.0.34
#
# Utilisateurs RedHat : Vous pouvez aussi changer l'option dans /etc/sysconfig/network
#                             de :
#                       FORWARD_IPV4=false  
#                             à :
#                       FORWARD_IPV4=true
#
echo "1" > /proc/sys/net/ipv4/ip_forward

# Utilisateurs d'IP dynamiques :
#
# Si vous avez une adresse IP dynamique via SLIP, PPP ou DHCP, décommentez l'option
# suivante. Elle permet d'utiliser une bidouille dans l'IP MASQ qui sert pour les IP
# dynamiques, ce qui rends la vie avec DialD, PPPd et les programmes similaires bien
# plus facile.
#
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr


# Spécifiez votre adresse IP statique ici.
#
#   Si vous utilisez une adresse IP DYNAMIQUE, vous avez besoin de faire comprendre a ce
#   jeu de règles que votre IP a changée a chaque fois qu'elle change. Pour faire cela,
#   décommentez le script suivant. (Notez qu'il y a une différence importante entre les
#   guillemets simples et doubles).
#
#   Vous aurez aussi besoin soit de créer le lien suivant ou que votre /etc/ppp/ip-up
#   existant lance votre /etc/rc.d/rc.firewall.
#
#       ln -s /etc/rc.d/rc.firewall /etc/ppp/ip-up
#
#   Si le fichier /etc/ppp/ip-up existe déjà, vous devriez l'éditer et ajouter une ligne
#   contenant "/etc/rc.d/rc.firewall" aux alentours de la fin du fichier.
#
#   Si vous ne vous en etes pas encore rendu comptes, le script /etc/ppp/ip-up est
#   toujours lancé lorsqu'une connexion PPP est établie. Grâce a cela, nous pouvons dire
#   au script d'aller chercher la nouvelle adresse IP pour pouvoir mettre a jour les
#   règles sures.
#
#   Utilisateurs PPP : 
#        Le bout de script suivant devrais marcher sans problèmes.
#
#   Utilisateurs de DHCP :
#        Si vous obtenez votre adresse TCP/IP via DHCP, vous aurez a remplacer le mot
#        ppp0 par le nom de votre interface via laquelle vous êtes connectés a Internet
#        (eth0, eth1, etc). Il devrais aussi être noté que le DHCP peut changer votre IP
#        adresse. Pour régler cela vous devriez configurer votre client DHCP pour
#        relancer vos règles de firewall a chaque vois que votre bail est
#        renouvelé. Pour les utilisateurs de DHCPcd, utilisez l'option -c.
#
extint = "ppp0"
#extip = "`/sbin/ifconfig $extint | perl -ne 'if (/inet addr:([^ ]*)/) {print $1}'`"
#
extip = "votre_adresse_ip_statique"

# L'ip interne e
intint="eth0"
intnet="192.168.0.1/24"


# Durée de vie des connexion MASQuées
#
#    2 hrs pour une session TCP
#   10 sec apres qu'un paquet "FIN" soit passé
#   60 sec pour le traffic UDP (Les utilisateurs d'ICQ doivent configurer leur ICQ avec
#                               un timeout de firewall de 30 secondes)
#
ipchains -M -S 7200 10 60

########################################################################################
# Connexions entrantes, efface tout et positionne le comportement par défaut à reject
# (refus). En fait, le comportement par défaut est inadéquat puisqu'il y a une règle
# pour tout intercepter, avec refus et logging.
#
ipchains -F input
ipchains -P input REJECT

# interface locale, machines locales. Aller n'importe où est autorisé.
#
ipchains -A input -i $intint -s $intnet -d 0.0.0.0/0 -j ACCEPT

# interface distante, prétendant être une machine locale. C'est de l'IP spoofing, on
# refuse.
#
ipchains -A input -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT

# interface distante, n'importe qu'elle source, l'accès à notre adresse PPP est valide
#
ipchains -A input -i $extint -s 0.0.0.0/0 -d $extip/32 -j ACCEPT

# l'interface loopback est valide.
#
ipchains -A input -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT

# une fois toutes les règles faites, toutes les autres connexions entrantes sont
# refusées et logguées.
#
ipchains -A input -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT

########################################################################################
# Connexions sortantes,efface tout et positionne le comportement par défaut à reject
# (refus).En fait, le comportement par défaut est inadéquat puisqu'il y a une règle pour
# tout intercepter, avec refus et logging.
#
ipchains -F output
ipchains -P output REJECT

# interface locale, machines locales. N'importe quelle source allant vers le réseau
# local est valide.
#
ipchains -A output -i $intint -s 0.0.0.0/0 -d $intnet -j ACCEPT

# destination vers le réseau local à partir de l'interface sortante. C'est du routage
# piraté, tout refuser.
#
ipchains -A output -i $extint -s 0.0.0.0/0 -d $intnet -l -j REJECT

# sortante depuis le réseau local sur l'interface sortante. C'est du masquerading
# pirate, tout refuser.
#
ipchains -A output -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT

# Tout ce qui sort d'autre de l'interface distante est bon
#
ipchains -A output -i $extint -s $extip/32 -d 0.0.0.0/0 -j ACCEPT

# l'interface loopback est valide.
#
ipchains -A output -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT

# une fois toutes les règles faites, toutes les autres connexions sortantes sont
# refusées et logguées.
#
ipchains -A output -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT

########################################################################################
# Connexions à faire suivre (forwarding), efface tout et positionne le comportement par
# défaut à reject (refus). En fait, le comportement par défaut est inadéquat puisqu'il y
# a une règle pour tout intercepter, avec refus et logging.
#
ipchains -F forward
ipchains -P forward DENY

# Masquerade depuis le réseau local sur l'interface locale vers n'importe où
#
ipchains -A forward -i $extint -s $intnet -d 0.0.0.0/0 -j MASQ
#
# une fois toutes les règles faites, toutes les autres connexions à faire suivre sont
# refusées et logguées.
#
ipchains -A forward -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT

Avec IPCHAINS, vous pouvez bloquer le trafic vers ou depuis un site particulier en utilisant les règles "input", "output" et "forward". Souvenez vous que les règles sont analysées de haut en bas, et "-A" signifie ajoute ("append") à l'ensemble des règles existantes. Avec cela en mémoire, toute restriction spécifique doit venir avant les regles globales. Par exemple :

En utilisant les règles "input". Probablement le plus rapide mais stoppe uniquement les machines locales, le firewall peut encore accéder au site "interdit". C'est peut être d'ailleurs le comportement que vous désirez.

Dans le /etc/rc.d/rc.firewall : 

... début des règles "input" ...

# rejette et loggue l'interface locale et la machine locale allant sur 204.50.10.13
#
/sbin/ipfwadm -I -a reject -V 192.168.0.1 -S 192.168.0.0/24 -D 204.50.10.13/32 -o

# interface locale, machines locales. Aller n'importe où est autorisé.
#
/sbin/ipfwadm -I -a accept -V 192.168.0.1 -S 192.168.0.0/24 -D 0.0.0.0/0

... fin des règles -I ...

En utilisant les règles "output. C'est le plus lent puisque les paquets passent d'abord à travers le masquerading, mais cette règle empèche même au firewall d'accéder au site interdit. 

... début des règles "output" ...

# rejette et loggue les connexions sortantes vers 204.50.10.13
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S $ppp_ip/32 -D 204.50.10.13/32 -o

# tout le reste, sortant vers l'interface distante est valide
#
/sbin/ipfwadm -O -a accept -V $ppp_ip -S $ppp_ip/32 -D 0.0.0.0/0

... fin des règles -O ...

En utilisant les règles "forward". Probablement plus lent qu'en utilisant les règles -I, et cela stoppe uniquement les machines pour lesquelles on effetue du masquerading (c'est à dire les machines internes). Le firewall peut encore accéder au site interdit. 

... début des règles "forward" ...

# Rejette et loggue les connexions depuis le réseau local sur l'interface PPP vers
# 204.50.10.13.
#
/sbin/ipfwadm -F -a reject -W ppp0 -S 192.168.0.0/24 -D 204.50.10.13/32 -o

# Masquerade depuis le réseau local sur l'interface locale vers n'importe où
#
/sbin/ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/24 -D 0.0.0.0/0

... fin des règles -F ...

Il n'y a pas besoin d'une règle spéciale pour autoriser 192.168.0.0/24 à se connecter sur 204.50.11.0, ce comportement est inclus dans les règles globales.

Contrairement a ipfwadm, il n'y a qu'une seule façon de spécifier l'interface dans ipchains, utilisez "-i interface".

6.6 MASQuer de multiples sous réseaux internes

MASQuer plus d'un sous réseau interne est assez simple. Vous n'avez qu'a vous assurer que tous vos réseaux fonctionnent bien (en interne et avec l'extérieur). Ensuite, vous aurez a autoriser le traffic a passer via vos interface réseaux vers Internet.

Ensuite, vous aurez a autoriser les autres interfaces internes, cet exemple montre comment masquer les interfaces eth1 (192.168.0.1) et eth2 (192.168.1.1) derriere eth0. Dans votre rc.firewall juste apres la ligne autorisant le MASQ, ajoutez les lignes :

6.7 L'IP Masquerade et la numérotation à la demande.

  1. Si vous voulez que votre réseau se connecte automatiquement à Internet, soit avec le package diald soit avec les dernieres versions du paquetage PPPd. Diald est la solution de numérotation à la demande recommandée.
  2. Pour mettre en place Diald, veuillez vous référer à la page (en anglais) Setting Up Diald for Linux Page ou TrinityOS - Section 23
  3. Une fois que diald et IP masq auront été installés, vous pouvez aller sur n'importe laquelle des machines clients et initier une connexion web, telnet ou ftp et cela fera que votre machine Linux se connectera a Internet.
  4. Un timeout (délai d'attente dépassé) sera inévitable sur la première connexion, mais c'est le lot des modems analogiques. Le temps mis à établir la connexion va provoquer un timeout de votre programme client. Ce n'est quand meme pas quelque chose qui arrive souvent. Il suffit de recommencer, et ça passera. Vous pouvez aussi essayer de faire un echo "1" > /proc/sys/net/ipv4/ip_dynaddr pour aider la premiere utilisation.

6.8 IPPORTFW, IPMASQADM, IPAUTOFW, REDIR, UDPRED, et autres outils de redirection de ports

IPPORTFW, IPAUTOFW, REDIR, UDPRED, et autres sont des programmes génériques pour faire de la redirection de ports avec Linux IP MASQ. Ces outils sont normalement utilisés en remplacement de modules IP MASQ spécifiques comme les modules FTP ou Quake existant. Avec les redirecteurs de ports, vous pouvez rediriger des connexions arrivant d'Internet vers le réseau interne derriere le serveur MASQ. Cette redirection inclue des protocoles réseaux comme telnet, www, smtp, ftp (avec un patch, voir plus bas), ICQ, et plein d'autres.

NOTE : Si vous n'avez besoin que de la redirection de ports et pas besoin de l'IP MASQ, vous aurez QUAND MÊME à autoriser l'IP MASQ dans le noyau et avec soit IPFWADM soit IPCHAINS pour avoir la possibilité d'utiliser la redirection de ports. Plus tard, lorsque IP Masquerade est devenu mature, ces outils sont remplacés par IPPORTFW qui est une solution plus intelligente. Du fait de la présence d'outils plus récents, il est HAUTEMENT RECOMMANDÉ de ne pas utiliser les vieux outils comme IPAUTOFW et REDIT car ils ne font pas part au noyau de leur présence et leur présence peut même PLANTER votre serveur Linux si la charge monte.

Avant de se lancer corps et âme dans l'installation de soit IPPORTFW pour les 2.0 soit IPMASQADM avec le support IPPORTFW pour les 2.2, la sécurité du réseau peut être grandement compromise avec l'utilisation d'un tel outil. La raison est que ces outils créent un trou dans le firewall. Bien que cela ne pose pas de problèmes a votre machine Linux, il se peut que cela en soit un pour la machine interne vers lesquels sont transférés les paquets. Ne vous inquiétez pas trop quand même, Voici ce que Steven Clarke (l'auteur d'IPPORTFW) réponds a cela : 

"Le relayage de ports est seulement appelé depuis les fonctions de
masquerading, Par conséquent, il rentre dans les mêmes règles
d'IPFWADM/IPCHAINS. Le masquerading est une extension du relayage IP. Par
conséquent, ipportfw ne voit que les paquets qui rentrent dans les règles
d'entrée et de sortie."

Par conséquent, il est important d'avoir de bonnes regles de firewall. Allez lire les sections Strong-IPFWADM-Rulesets et Strong-IPCHAINS-Rulesets pour plus de détails sur l'établissement de bonnes règles.

Donc, pour installer IPPORTFW, que ce soit pour les 2.0 ou 2.2, vous aurez a recompiler votre noyau avec le support pour IPPORTFW.

IPPORTFW sur un noyau 2.0

Premièrement, assurez vous que vous avez le dernier noyau 2.0 décompressé dans /usr/src/linux. Si vous n'avez pas encore fait cela allez voir la section Kernel-Compile pour plus de détails. Ensuite, téléchargez le programme "ipportfw.c" et le "subs-patch-x.gz" depuis la section 2.0.x-Requirements dans le répertoire /usr/src

NOTE : Remplacez le x de "subs-patch-x.gz" par le nom de la dernière version disponible sur le site.

Maintenant, copiez le patch IPPORTFW (subs-patch-x.gz) dans le repertorie Linux : 

cp /usr/src/subs-patch-1.37.gz /usr/src/linux

Ensuite, appliquez le patch pour créer l'option IPPORTFW au noyau : 

cd /usr/src/linux
zcat subs-patch-1.3x.gz | patch -p1

Ensuite, Si vous avez dans l'idée de faire du forwarding de trafic FTP vers un serveur interne, appliquez un NOUVEAU IP_MASQ_FTP patch de la section 2.0.x-Requirements . Plus de détails sont donnés un peu plus loin.

Bon, maintenant, il est temps de compiler votre noyau comme il l'est expliqué dans la section Kernel-Compile . Dites bien oui a l'option IPPORTFW qui est maintenant disponible quand vous configurez votre noyau. Une fois que votre noyau est compilé et que vous avz rebooté, revenez ici.

Maintenant que vous avez un noyau tout neuf, compilez et installez le programme "IPPORTFW" : 

cd /usr/src
gcc ipportfw.c -o ipportfw
mv ipportfw /usr/local/sbin

Maintenant, nous allons prendre l'exemple suivant : rediriger le trafic internet arrivant sur le port 80 d'être transféré a la machine masquée ayant l'adresse IP 192.168.0.10.

NOTE : Une fois que vous avez autorisé le relayage de ports sur le port 80, ce port ne peut plus être utilisé par le serveur MASQ. Pour être plus précis, si vous avez un serveur web qui tourne déjà sur le serveur MASQ et que vous avez mis le relayage en place, tous les utilisateurs d'Internet verront les pages web du serveur interne, et non celles du serveur MASQ. La seule parade a cela est de forwarder un autre port, disons par exemple le 8080, vers votre machine interne. Bien que cela marchera, les utilisateurs auront a ajouter un :8080 a l'URL quand ils voudront contacter le serveur WWW.

Quoi qu'il en soit, pour autoriser la redirection de port, éditez le fichier /etc/rc.d/rc.firewall. Et ajoutez les lignes suivantes, assurez vous de bien remplacer le mot $extip par votre adresse internet.

NOTE : Si vous avez une IP dynamique, vous aurez a rendre votre /etc/rc.d/rc.firewall plus intelligent. Pour ce faire, référez vous aux sections Strong-IPFWADM-Rulesets et Strong-IPCHAINS-Rulesets ou à TrinityOS - Section 10 pour plus de détails sur les ip dynamiques. 

        /etc/rc.d/rc.firewall
        --

        #echo "Mise en place d'IPPORTFW vers le LAN externe."
        #
        /usr/local/sbin/ipportfw -C
        /usr/local/sbin/ipportfw -A -t$extip/80 -R 192.168.0.10/80

        --

Et voilà ! Relancez votre /etc/rc.d/rc.firewall et testez !

Si vous avez un message d'erreur comme "ipfwadm: setsockopt failed: Protocol not available", vous avez votre ancien noyau. Assurez vous que vous avez bien installé le nouveau noyau, lancez lilo et rebootez.

Redirection de ports pour les serveurs FTP :

Si vous avez dans l'idée d'utilise la redirection de ports, les choses se compliquent... La raison est que le module standard ip_masq_ftp du noyau n'a pas été écrit dans ce but. Heureusement, Fred Viles à modifié le module pour que ça marche. Si vous êtes juste curieux de savoir comment ça marche, téléchargez le patch suivant, Fred a mis plein de commentaires dans son code. Notez aussi que ce patch est légèrement expérimental et doit être traité comme tel. Il faut aussi noter que ce patch est disponible uniquement pour les noyaux 2.0. Le portage vers les noyaux 2.2 a été entrepris, si vous voulez aider a terminer ce port, envoyez un email directement à Fred Viles - fv@episupport.com (en anglais bien sur ;).

Donc, Pour faire marcher le patch, vous allez avoir à :

Une fois cela fait, éditez le fichier /etc/rc.d/rc.firewall et ajoutez les lignes suivantes (remplacez bien $extip par votre ip externe) :

NOTE : Si vous avez une IP dynamique, vous aurez a rendre votre /etc/rc.d/rc.firewall plus intelligent. Pour ce faire, référez vous aux sections Strong-IPFWADM-Rulesets et Strong-IPCHAINS-Rulesets ou à TrinityOS - Section 10 pour plus de détails sur les ip dynamiques.

Cet exemple, comme celui ci dessus, permettra à tout le trafic ftp (sur le port 21) arrivant sur l'adresse IP internet d'être transféré a la machine interne ayant l'adresse IP 192.168.0.10.

NOTE : Une fois que vous avez autorisé le relayage du port 21, ce port ne peut plus être utilisé par le serveur MASQ. Pour être plus spécifique, si vous aviez déjà un serveur ftp sur le serveur MASQ, il ne sera plus accessible de l'extérieur. 

        /etc/rc.d/rc.firewall
        --

        #echo "Mise en place d'IPPORTFW vers le LAN externe."
        #
        /usr/local/sbin/ipportfw -C
        /usr/local/sbin/ipportfw -A -t$extip/21 -R 192.168.0.10/21

        --

Et voilà ! Relancez votre /etc/rc.d/rc.firewall et testez !

Si vous avez un message d'erreur comme "ipfwadm: setsockopt failed: Protocol not available", vous avez votre ancien noyau. Assurez vous que vous avez bien installé le nouveau noyau, lancez lilo et rebootez. Si vous êtes sur de bien utiliser votre nouveau noyau, tapez : "ls /proc/net" et vérifiez qu'il y a bien un "ip_portfw". Si il n'y est pas, vous avez du commettre une erreur dans la configuration du noyau. Essayez encore.

IPMASQADM avec IPPORTFW pour les noyaux 2.2

Tout d'abord, vérifiez que vous avez bien le dernier noyau 2.2 décompressé /usr/src/linux. Si vous ne l'avez pas encore fait, Allez voir la section Kernel-Compile pour tous les détails. Ensuite, téléchargez le programme "ipmasqadm.c" depuis la section 2.2.x-Requirements dans le repertoire /usr/src.

Ensuite, vous aurez a compiler votre noyau comme il l'est expliqué dans la section Kernel-Compile . Vérifiez que vous avez bien dit YES a l'option IPPORTFW quand vous avez configuré votre noyau. Une fois la compilation terminée et que vous avez rebooté, revenez ici.

Maintenant, compilez et installez ipmasqadm : 

        cd /usr/src
        tar xzvf ipmasqadm-x.tgz
        cd ipmasqadm-x
        make
        make install

Maintenant, nous allons prendre l'exemple suivant : rediriger le trafic internet arrivant sur le port 80 d'être transféré a la machine masquée ayant l'adresse IP 192.168.0.10.

NOTE : Actuellement, le module ip_masq_ftp modifié ne marche pas pour les noyaux 2.2. Si vous vous sentez l'âme expérimentale, essayez de le porter et envoyez vos résultats a Ambrose et David.

NOTE : Une fois que vous avez autorisé le relayage de ports sur le port 80, ce port ne peut plus être utilisé par le serveur MASQ. Pour être plus précis, si vous avez un serveur web qui tourne déjà sur le serveur MASQ et que vous avez mis le relayage en place, tous les utilisateurs d'Internet verront les pages web du serveur interne, et non celles du serveur MASQ.

Quoi qu'il en soit, pour autoriser la redirection de port, éditez le fichier /etc/rc.d/rc.firewall. Et ajoutez les lignes suivantes, assurez vous de bien remplacer le mot $extip par votre adresse internet.

NOTE : Si vous avez une IP dynamique, vous aurez a rendre votre /etc/rc.d/rc.firewall plus intelligent. Pour ce faire, référez vous aux sections Strong-IPFWADM-Rulesets et Strong-IPCHAINS-Rulesets ou à TrinityOS - Section 10 pour plus de détails sur les ip dynamiques. 

        /etc/rc.d/rc.firewall
        --

        #echo "Mise en place d'IPPORTFW vers le LAN externe."
        #
        /usr/sbin/ipmasqadm portfw -f
        /usr/sbin/ipmasqadm portfw -a -P tcp -L $extip 80 -R 192.168.0.10 80

        --

Et voilà ! Relancez votre /etc/rc.d/rc.firewall et testez !

Si vous avez un message d'erreur comme "ipfwadm: setsockopt failed: Protocol not available", vous avez votre ancien noyau. Assurez vous que vous avez bien installé le nouveau noyau, lancez lilo et rebootez. Si vous êtes sur de bien utiliser votre nouveau noyau, tapez : "ls /proc/net" et vérifiez qu'il y a bien un "ip_portfw". Si il n'y est pas, vous avez du commettre une erreur dans la configuration du noyau. Essayez encore.

6.9 CU-SeeMe et Linux IP-Masquerade

L'ip masquerade supporte CuSeeMe via le module "ip_masq_cuseeme" du noyau. Ce module devrais être chargé depuis le script /etc/rc.d/rc.firewall. Une fois que le module est chargé, tous devriez etre capable d'établir et recevoir des connexions CuSeeMe vers des serveurs et/ou des utilisateurs.

NOTE : Il est recommandé d'utiliser IPPORTFW plutôt que IPAUTOFW pour utiliser CuSeeMe.

Si vous avez besoin de plus d'explications sur la configuration de CuSeeMe, allez voire Michael Owings's CuSeeMe page pour un Mini HOWTO ou The IP Masquerade Resources pour un miroir du mini HOWTO.

6.10 Mirabilis ICQ

Il y a deux méthodes pour faire marcher ICQ derrière un serveur MASQ. L'une de ces méthodes est d'utiliser le nouveau module ICQ MASQ, et l'autre est d'utiliser IPPORTFW.

Le module ICQ a quelques bénéfices et quelques limitations. Il permet d'avoir plusieurs utilisateurs ICQ derriere le serveur MASQ. Il ne requiert pas de changements dans la configuration des clients. Toutefois, il ne permet pas les transferts de fichiers et les chat en temps réel.

Avec IPPORTFW, Vous aurez a faire quelques changements a votre machine Linux et aux clients ICQ, mais tous les types de messages ICQ (urls, chat, transferts de fichiers) marcheront.

Si vous etes interessés par le module ICQ d'Andrew Deryabin's djsf@usa.net pour les noyaux 2.2, référez vous a la section 2.2.x-Requirements pour plus de détails.

Si vous préférez utiliser la méthode classique pour faire marcher ICQ derriere votre serveur MASQ, suivez les étapes suivantes :

6.11 Joueurs : Le patch LooseUDP

Le patch LooseUDP permet aux jeux comprenant le NAT qui utilisent des connexions UDP de marcher et même bien derrière un serveur MASQ. Actuellement, LooseUDP est disponible comme patch pour les noyaux 2.0.36+ et est intégré dans les noyaux 2.2.3+. Pour le faire marcher, quelques petites choses sont nécessaires :

Maintenant, mettez le patch LooseUDP dans le répertoire /usr/src/linux. Quand c'est fait, tapez :

Pour un patch compressé : zcat loose-udp-2.0.36.patch.gz | patch -p1

Pour un patch non compressé : cat loose-udp-2.0.36.patch | patch -p1

Maintenant, suivant la version du "patch", vous verrez le texte suivant : 

patching file `CREDITS'
patching file `Documentation/Configure.help'
patching file `include/net/ip_masq.h'
patching file `net/ipv4/Config.in'
patching file `net/ipv4/ip_masq.c'

Si vous voyez le texte "Hunk FAILED" une fois et une seule au début du patch, ne vous inquiétez pas, vous avez probablement une vieille version du patch (ça à été réparé depuis) mais ça marche quand même. Si ça plante complètement, vérifiez que vous avez appliqué le patch IPPORTFW en PREMIER.

Une fois que le patch est installé, reconfigurer le noyau comme c'est expliqué dans la section Kernel-Compile et dites bien YES à l'option "IP: loose UDP port managing (EXPERIMENTAL) (CONFIG_IP_MASQ_LOOSE_UDP) [Y/n/?]".

Une fois que vous tournez avec le patch LooseUDP, vous devriez pouvoir jouer a un bon paquet de jeux. Quelques URL se trouvent dans la section Game-Clients pour savoir comment pouvoir utiliser des jeux comme BattleZone et d'autre.

Page suivante Page précédente Table des matières