Certaines applications des protocoles TCP/IP ne fonctionnent pas actuellement avec l'IP Masquerading sous Linux parce que soit ils supposent des choses sur les numéros de port soit ils encodent sur les adresses TCP/IP et/ou les numéros de port dans leur flux de données. Ces derniers protocoles ont besoin de proxies ou de modules IP MASQ spécifiques pour fonctionner correctement dans le code de masquerading.
Par défaut, Linux IP Masquerading ne peut pas du tout prendre en charge les services entrant mais il y a quelques façons de les lui faire accepter.
Si vous n'avez pas besoin de beaucoup de securité, vous pouvez simplement forwarder ou rédiriger les ports IP. Il y a plusieurs façon de faire ça mais la plus stable est d'utiliser IPPORTFW. Pour plus d'informations, reportez vous à la section Forwarders .
Si vous désirez avoir un certain niveau d'autorisation sur les connexions entrantes, vous aurez besoin de configurer soit des TCP-wrappers, soit Xinetd pour permettre la connexion d'adresses IP specifiques. Un bon endroit où trouver des utilitaires et de la documentation est le TIS Firewall Toolkit.
De plus amples détails sur la securité entrante peuvent être trouvés dans le document TrinityOS et a l' IP Masquerade Resource.
** La Linux Masquerade Application list a une tonne d'informations au sujet des applications qui fonctionnent à travers l'IP Masquerading sous Linux. Ce site a récemment été pris en charge par Steve Grevemeyer qui l'a doté d'une base de données complète. C'est une source exceptionnelle !
En général, toute application qui utilise le TCP et l'UDP standards devrait fonctionner. Si vous avez des suggestions, des indications etc. reportez vous à l' IP Masquerade Resource pour de plus amples détails.
Clients Généraux:
toutes les plateformes compatibles, clients pour la recherche de fichiers (tous les clients archie ne sont pas compatibles)
toutes les plateformes compatibles, avec le module noyau ip_masq_ftp.o pour les connexions FTP actives.
toutes les plateformes compatibles
toutes les plateformes compatibles, WWW surfing
toutes les plateformes compatibles, DCC est compatible via le module ip_masq_irc.o
toutes les plateformes compatibles, USENET news client
toutes les plateformes compatibles, avec le module noyau ICMP Masquerading
toutes les plateformes compatibles, clients email
toutes les plateformes compatibles, TELNET/FTP clients sécurisés
toutes les plateformes compatibles, serveurs d'email tels que Sendmail, Qmail, PostFix, etc.
toutes les plateformes compatibles, session distante
versions sous UNIX et Windows, quelques variantes pourraient ne pas fonctionner (NDT : fonctionne aussi sous MacOS)
Windows(peut-être toutes les plateformes compatibles), virtual reality surfing
toutes les plateformes compatibles
Clients Multimedia et Communication:
- MS Netmeeting, Intel Internet Phone Beta , et autres applications H.323 - Il y a maintenant deux façons de faire fonctionner ces clients aux travers de connexions MASQuées :
Il y a un module BETA stable disponible sur le MASQ WWW site ou sur http://www.coritel.it/projects/sofia/nat.html pour utiliser Microsoft Netmeeting v3.x sous les noyaux 2.2.x. Il y aussi un autre module sur le site Web de MASQ spécifique à Netmeeting 2.x pour les noyaux 2.0.x mais il n'est pas compatible avec Netmeeting v3.x.
Une autre solution, commerciale, et la passerelle Equivalence's PhonePatch H.323.
Windows, Client-Serveur 3D programme de tchatche
toutes les plateformes compatibles, avec le module ip_masq_cuseeme chargé, reportez vous SVP à la section CuSeeme pour de plus amples détails.
Tous les clients sont compatibles. Requiert un noyau compilé avec la compatibilité IPPORTFW et ICQ configuré comme étant derrière un proxy NON-SOCKS. Une description complète de cette configuration est disponible à la section ICQ .
Windows, communications audio Peer-to-peer, vous pouvez entrer en communication avec quelqu'un seulement si vous êtes l'appelant, vous ne pouvez être appelé sans un port forwarding spécifique. Reportez vous à la section Forwarders pour de plus amples détails.
Windows, streaming audio par Internet
Windows, communications textuelles peer-to-peer, vous pouvez entrer en communication avec quelqu'un seulement si vous êtes l'appelant, vous ne pouvez être appelé sans un port forwarding spécifique. Reportez vous à la section Forwarders pour de plus amples détails.
Windows, streaming audio par Internet, vous obtiendrez de meilleurs résultats avec le module UDP ip_masq_raudio
Windows, streaming audio par Internet
Windows, avec le patch ip_masq_vdolive
Windows, Client-Serveur 3D programme de tchatche
Jeux - Reportez vous à la section LooseUDP pour de plus amples détails sur le patch LooseUDP
Fonctionne mais requiert les ports TCP 116 et 118 et les ports UDP 6112 IPPORTFWés vers la machine de jeu. reportez vous à la section Forwarders pour de plus amples détails. Veuillez notez que les serveurs FSGS et Bnetd requièrent toujours IPPORTFW puisqu'ils n'ont pas été réécrits pour être compatibles NAT.
Fonctionne avec le patch LooseUDP et les nouveaux .DLLs Activision compatibles NAT.
Fonctionne avec le patch LooseUDP ou requiert les ports TCP 116 et 118 et les ports UDP 6112 IPPORTFWés vers la machine de jeu. Reportez vous à la section Forwarders pour de plus amples détails.
Fonctionne avec le patch LooseUDP ou requiert les ports TCP 116 et 118 et les ports UDP 6112 IPPORTFWés vers la machine de jeu. Les nouvelles versions de Diablo n'utilisent que le port TCP 6112 et le port UDP 6112. Reportez vous à la section Forwarders pour de plus amples détails.
Fonctionne avec le patch LooseUDP ou requiert les ports TCP 116 et 118 et les ports UDP 6112 IPPORTFWés vers la machine de jeu. Reportez vous à la section Forwarders pour de plus amples détails.
Fonctionne directement mais requiert le module ip_masq_quake s'il y a plus d'un joueur de Quake I/II/III derrière le serveur MASQ. Ce module n'est compatible qu'avec Quake I et QuakeWorld par défaut. Si vous voulez utiliser Quake II ou des ports non standard pour le server, reportez vous à la section d'installation des modules dans les jeux de règles rc.firewall-2.0.x et rc.firewall-2.2.x .
Fonctionne avec le patch LooseUDP ou requiert les ports TCP et UDP 6112 IPPORTFWés vers la machine de jeu. Reportez vous à la section Forwarders pour de plus amples détails.
Fonctionne avec le patch LooseUDP
Autres Clients:
Linux, package d'administration des comptes à distance
DOS, une suite contenant telnet, ftp, ping, etc.
MS-Windows, Controle à distance un PC par TCP/IP, fonctionne uniquement si c'est un client. Ne fonctionne pas sans un port forwarding spécifique si c'est le serveur. Reportez vous à la section Forwarders pour de plus amples details.
utilise NTP - protocole d'horloge réseau
Impossible de se connecter au serveur
Impossible de se connecter a l'hôte distant
Ne fonctionne pas (Il fait des suppositions erronnées au sujet des adresses).
Cette section fournit un guide plus detaillé d'utilisation de l'outil de firewall pour 2.0.x, IPFWADM. Reportez vous si dessous pour les règles d'IPCHAINS.
Voici un exemple d'un système de firewall/masquerade derrière une connexion PPP avec une adresse PPP statique (les instructions pour les connexions PPP dynamiques sont incluses mais désactivées). L'interface de confiance est 192.168.0.1 et l'adresse IP de l'interface PPP a été changée pour protéger le coupable :). J'ai listé chaque interface entrante et sortante pour détecter aussi bien les IP spoofings que les faux routage et/ou masquerading. Tout ce qui n'est pas explicitement permis est INTERDIT (euh... rejeté en fait). Si votre serveur IP MASQ ne fonctionne plus après avoir implémenté ce script rc.firewall, vérifiez que vous l'avez modifié pour votre propre configuration et contrôlez votre fichier SYSLOG /var/log/messages ou /var/adm/messages pour trouver d'éventuels erreurs de firewall.
Pour des exemples plus exhaustifs de règles Ôstrong' d'IPFWADM IP Masqueradé pour PPP, modem pour cable, etc., vous pouvez vous référer à TrinityOS - Section 10 et GreatCircle's Firewall WWW page
NB: Si vous avez une adresse TCP/IP assignée de facon dynamique par votre FAI (PPP, aDSL, Cable, etc.) vous NE POUVEZ PAS CHARGER ces règles Ôstrong' au moment du boot. Vous aurez soit à relancer le jeu de règles de ce firewall à CHAQUE FOIS que vous avez une nouvelle adresse IP soit faire un /etc/rc.d/rc.firewall plus intelligent. Pour faire ceci pour les utilisateurs de PPP, lisez attentitevement et enlever les marques de commentaires les lignes correspondantes dans la section Òrecuperation d'IP PPP dynamiqueÓ ci-dessous. Vous pouvez aussi trouver de plus amples détails dans le documentation TrinityOS - Section 10 sur les jeux de règles ÔStrong' et les adresses IP dynamiques.
Veuillez aussi noter qu'il existe plusieurs utilitaires de création de Firewall qui possèdent des interfaces graphiques. Vous pouvez vous reporter à la section FAQ pour des détails complets.
Enfin, si vous utilisez une adresse IP STATIQUE obtenue par PPP, changez la ligne "ppp_ip="votre.adresse.PPP.statique" par votre adresse.
----------------------------------------------------------------
#!/bin/sh
#
# /etc/rc.d/rc.firewall: Un exemple de jeu de regles d'un firewall IPFWADM semi-STRONG IPFWADM
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# on teste, attendre un peu puis effacer toutes les regles de firewall
# enlever les marques de commentaire des lignes qui suivent si vous voulez que
# le firewall se desactive automatiquement au bout de 10 mins.
# (sleep 600; \
# ipfwadm -I -f; \
# ipfwadm -I -p accept; \
# ipfwadm -O -f; \
# ipfwadm -O -p accept; \
# ipfwadm -F -f; \
# ipfwadm -F -p accept; \
# ) &
# Charge les modules necessaires a IP MASQ
#
# NB: Charger uniquement les modules IP MASQ dont vous avez besoin. Tous les modules
# IP MASQ actuels sont montres ci-dessous mais sont commentes pour les empecher de se charger.
# Necessaire pour le chargement initial des modules
#
/sbin/depmod -a
# Permet le masquerading correct des transfert de fichier par FTP avec la methode PORT
#
/sbin/modprobe ip_masq_ftp
# Permet le masquerading de RealAudio par UDP. Sans ce module,
# RealAudio FONCTIONNERA mais en mode TCP. Ce qui peu causer une baisse
# dans la qualite du son
#
#/sbin/modprobe ip_masq_raudio
# Permet le masquerading des transferts de fichier par DCC pour les IRC
#
#/sbin/modprobe ip_masq_irc
# Permet le masquerading de Quake et QuakeWorld par defaut. Ce module est
# necessaire pour les utilisateurs multiples dirriere un server Linux MASQ. Si vous voulez
# jouer a Quake I, II, et III, utilisez le second exemple.
#
# NB: si vous rencontrez des ERREURs lors de chargement du module QUAKE, c'est que vous utilisez
# un ancien noyau buggue. Mettez a jour votre noyau pour supprimer l'erreur.
#
#Quake I / QuakeWorld (ports 26000 and 27000)
#/sbin/modprobe ip_masq_quake
#
#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960)
#/sbin/modprobe ip_masq_quake 26000,27000,27910,27960
# Permet le masquerading du logiciel CuSeeme pour la video conference
#
#/sbin/modprobe ip_masq_cuseeme
# Permet le masquerading du logiciel VDO-live pour la video conference
#
#/sbin/modprobe ip_masq_vdolive
#CRITIQUE: Active l'IP forwarding puisqu'il est desactive par defaut
#
# Utilisateurs Redhat: vous pourrez essayer en changeant les options dans
# /etc/sysconfig/network de:
#
# FORWARD_IPV4=false
# to
# FORWARD_IPV4=true
#
echo "1" > /proc/sys/net/ipv4/ip_forward
#CRITIQUE: Active automatiquement l'IP defragmenting puisqu'il est desactive par defaut
# dans les noyaux 2.2.x. Ceci etait une option de compilation mais ca a change
# depuis le noyau 2.2.12
#
echo "1" > /proc/sys/net/ipv4/ip_always_defrag
# Utilisateurs d'IP Dynamiques:
#
# Si vous recevez votre adresse IP de maniere dynamique a partir d'un server SLIP, PPP, ou
# DHCP, activez option suivante qui active le hacking (au bon sens du terme NDT) des
# adresses IP dynamique dans IP MASQ, rendant ainsi les choses plus faciles pour les
# programmes du type Diald.
#
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr
# Specifiez ici votre adresse IP statique.
#
# Si vous avez une adresse IP DYNAMIQUE, vous devez faire trouver a ce jeu
# de regles votre adresse IP a chaque fois que vous avez une nouvelle. Dans ce but,
# activez le script d'une ligne qui suit.
#
# utilisateurs de DHCP :
# ----------------------
# Si vous recevez votre adresse TCP/IP, **vous devez** activer les commandes
# #ées sous la section PPP ET remplacer le mot "ppp0" par le nom de votre
# de votre connexion Internet EXTERNE (eth0, eth1, etc). Notez aussi que le server
# DHCP peut changer votre adresse IP. Pour resoudre ce probleme, les utilisateurs
# doivent configurer leur client DHCP de sorte qu'il relance le jeu de regles du firewall
# chaque fois que leur bail DHCP est renouvele.
#
# NB #1: Quelques clients DHCP comme l'ancienne version de "pump" (les nouvelles
# versions ont ete corrigees) n'avaient pas la capacité de relancer
# les scripts apres une renouvellement de bail. Pour cette raison, vous
# aurez besoin de le remplacer par quelquechose du style "dhcpcd" ou "dhclient".
#
# NB #2: La syntaxe de "dhcpcd" a changé dans les versions recentes.
#
# Les anciennes version avaient une syntaxe du type:
# dhcpcd -c /etc/rc.d/rc.firewall eth0
#
# Les versions plus recentes ont une syntaxe du type:
# dhcpcd eth0 /etc/rc.d/rc.firewall
#
# NB #3: Pour les utilisateurs de Pump, ajouter cette ligne de commande dans votre
# fichier /etc/pump.conf:
#
# script /etc/rc.d/rc.firewall
#
# utilisateurs de PPP :
# ---------------------
# Si vous n'etes pas deja au courant, le script /etc/ppp/ip-up est toujours lance quand
# une connexion PPP arrive. A cause de ca, on peut demander au jeu de regles d'aller recuperer
# la nouvelles adresse IP PPP et de mettre a jour notre jeu de regles du strong firewall.
#
# Si le fichier /etc/ppp/ip-up existe deja, vous devez le modifier et ajouter une ligne
# contenant "/etc/rc.d/rc.firewall" pres de la fin du fichier.
#
# Si vous n'avez pas encore de script /etc/ppp/ip-up, vous devez creer le lien suivant
# pour lancer le script /etc/rc.d/rc.firewall.
#
# ln -s /etc/rc.d/rc.firewall /etc/ppp/ip-up
#
# * Vous devez ensuite activer les commandes #ees si dessous *
#
#
# Utilisateurs de PPP et DHCP :
# -----------------------------
# Enlevez le # de la ligne si dessous et placez un # sur la ligne suivante.
#
#ppp_ip="`/sbin/ifconfig ppp0 | grep 'inet addr' | awk '{print $2}' | sed -e 's/.*://'`"
#
ppp_ip="your.static.PPP.address"
# MASQ timeouts
#
# timeout de 2 heures pour les sessions TCP
# timeout de 10 sec pour le traffic apres que le paquet TCP/IP "FIN" est recu
# timeout de 160 sec pour le traffic UDP (Important pour les utilisateur d'ICQ MASQues)
#
/sbin/ipfwadm -M -s 7200 10 60
#############################################################################
# Entrée (incoming), flush et politique par defaut de rejet. En fait la politique par defaut
# est inapplicable parce qu'il y une regle qui attrape tout, refuse et logue.
#
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p reject
# interface locale, machines locales, on peut allez n'importe ou
#
/sbin/ipfwadm -I -a accept -V 192.168.0.1 -S 192.168.0.0/24 -D 0.0.0.0/0
# interface distance, pretendant etre une machine locale, IP spoofing, tire toi
#
/sbin/ipfwadm -I -a reject -V $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o
# interface distante, toute source, peut aller a l'adresse PPP permanante
#
/sbin/ipfwadm -I -a accept -V $ppp_ip -S 0.0.0.0/0 -D $ppp_ip/32
# boucler sur l'interface est valide.
#
/sbin/ipfwadm -I -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
# regle qui attrape tout, refuse tout autre entrée et le logue. Dommage qu'il n'y ait pas
# d'options pour le log sur cette politique mais ceci va faire le travail :
#
/sbin/ipfwadm -I -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#############################################################################
# Sortie (outgoing), flush et politique par defaut de rejet. En fait la politique par defaut
# est inapplicable parce qu'il y une regle qui attrape tout, refuse et logue.
#
/sbin/ipfwadm -O -f
/sbin/ipfwadm -O -p reject
# interface locale, toute source allant vers le reseau 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
# sortie vers le reseau local d'une interface distance, routage bizarre, rejet
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -o
# sortie du reseau local vers une interface distante, masquerading modifié, rejet
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o
# sortie du reseau local d'une interface distante, rejet
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -o
# tout autre chose qui sort de l'interface distance est valide
#
/sbin/ipfwadm -O -a accept -V $ppp_ip -S $ppp_ip/32 -D 0.0.0.0/0
# boucler sur l'interface est valide.
#
/sbin/ipfwadm -O -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
# regle qui attrape tout, refuse tout autre sortie et le logue. Dommage qu'il n'y ait pas
# d'options pour le log sur cette politique mais ceci va faire le travail :
#
/sbin/ipfwadm -O -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#############################################################################
# Forwarding, flush et politique par defaut de rejet. En fait la politique par defaut
# est inapplicable parce qu'il y une regle qui attrape tout, refuse et logue.
#
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p deny
# Masquerade a partir du reseau local sur l'interface locale vers n'importe ou.
#
/sbin/ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/24 -D 0.0.0.0/0
#
# regle qui attrape tout, refuse tout autre forwarding et le logue. Dommage qu'il n'y ait pas
# d'options pour le log sur cette politique mais ceci va faire le travail :
#
/sbin/ipfwadm -F -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#Fin du fichier.
Avec IPFWADM, vous pouvez bloquer le traffic vers un site particulier en utilisant les règles -I, -O ou -F. Souvenez vous que ces jeux de règles sont parcourus de début vers la fin et que "-a" dit a IPFWADM d'"ajouter" cette nouvelle règle au jeu de règles existant. Donc, en gardant ceci à l'esprit, toute restriction spécifique a besoin d'être ajoutée avant les règles globales. Par exemple :
avec la règle -I (input ):
Vraisemblablement la méthode la plus efficace et la plus rapide pour bloquer le traffic mais elle arrête seulement les machines MASQuées et NON la machine firewall elle-même. Biensûr, vous pourriez vouloir permettre cette combinaison :
Dans tous les cas, pour bloquer 204.50.10.13:
dans le jeu de règles de /etc/rc.d/rc.firewall :
... début des règles -I ... # rejette et logue l'interface locale, les machines locales allant à 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, allez n'importe où est valide # /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 ...
avec la règle -O (output ):
C'est la méthode la plus lente parce que les paquets passent par le masquerading d'abord et sont ensuite éliminés. Cependant, cette règle empêche même la machine firewall d'accéder à des sites interdits.
... début des règles -O ... # rejette et logue les transimissions 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 autre chose qui sort de 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 ...avec la règle -F (forward ):
Sans doute plus lent pour bloquer le traffic que les règles -I (input). Ne bloque que les traffics des machines masqueradées (i.e. les machines internes). La machine firewall peut toujours atteindre le(s) site(s) interdit(s).
... début des règles -F ... # rejette et logue les transmissions de l'interface locale 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 du reseau local vers 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 de règle spéciale pour permettres aux machines du réseau 192.168.0.0/24 d'aller à 204.50.11.0. Pourquoi ? Parce que c'est déjà traité dans la règle MASQ globale.
NB : Il y a plus d'une façon de coder les interfaces dans les règles si dessus. Par example au lieu de "-V 192.168.255.1", vous pouvez mettre "-W eth0", au lieu de "-V $ppp_ip", vous pouvez utiliser "-W ppp0". La méthode "-V" a été délaissée lors de la migration vers IPCHAINS mais pour les utilisateurs IPFWADM, c'est plus un choix personnel et de documentation plus qu'autre chose.
Cette section fournit un guide plus détaillé sur l'utilisation de l'outil firewall des noyaux 2.2.X, IPCHAINS. Reportez vous ci-dessus pour les jeux de règles IPFAWDM.
Voici un exemple d'un système de firewall/masquerade derrière une connexion PPP avec une adresse PPP statique (les instructions pour les connexions PPP dynamiques sont incluses mais désactivées). L'interface de confiance est 192.168.0.1 et l'adresse IP de l'interface PPP a été changée pour protéger le coupable :). J'ai listé chaque interface entrante et sortante pour détecter aussi bien les IP spoofings que les faux routage et/ou masquerading. Tout ce qui n'est pas explicitement permis est INTERDIT (euh... rejeté en fait). Si votre serveur IP MASQ ne fonctionne plus après avoir implémenté ce script rc.firewall, vérifiez que vous l'avez modifié pour votre propre configuration et contrôlez votre fichier SYSLOG /var/log/messages ou /var/adm/messages pour trouver d'éventuels erreurs de firewall.
Pour des exemples plus exhaustifs de règles Ôstrong' d'IPFWADM IP Masqueradé pour PPP, modem pour cable, etc., vous pouvez vous référer à TrinityOS - Section 10 et GreatCircle's Firewall WWW page
NB #1: les noyaux Linux 2.2.x inférieurs à 2.2.16 ont un trou de sécurité dans la couche TCP (root exploit) et les versions inférieurs à 2.2.11 ont un bug de fragmentation dans IPCHAINS. En raison de cela, les personnes utilisant le jeu de règles 'strong IPCHAINS' sont vulnérables aux attaques. Veuillez donc faire la mise à jour de votre noyau vers une version corrigée.
NB #2: Si vous avez une adresse TCP/IP assignée de facon dynamique par votre FAI (PPP, aDSL, Cable, etc.) vous NE POUVEZ PAS CHARGER ces règles Ôstrong' au moment du boot. Vous aurez soit à relancer le jeu de règles de ce firewall à CHAQUE FOIS que vous avez une nouvelle adress IP soit faire un /etc/rc.d/rc.firewall plus intelligent. Pour faire ceci pour les utilisateurs de PPP, lisez attentitevement et enlever les marques de commentaires des lignes correspondantes dans la section Òrécuperation d'IP PPP dynamiqueÓ ci dessous. Vous pouvez aussi trouver de plus amples détails dans le documentation TrinityOS - Section 10 sur les jeux de régles ÔStrong' et les adresses IP dynamiques.
Veuillez aussi noter qu'il existe plusieurs utilitaires de création de Firewall qui possèdent des interfaces graphiques. Vous pouvez vous reporter à la section FAQ pour des détail complets.
Enfin, si vous utilisez une adresse IP STATIQUE obtenue par PPP, changer la ligne "ppp_ip="votre.adresse.PPP.statique" par votre adresse.
----------------------------------------------------------------
#!/bin/sh
#
# /etc/rc.d/rc.firewall: An example of a Semi-Strong IPCHAINS firewall ruleset.
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# Charge les modules necessaires a IP MASQ
#
# NB: Charger uniquement les modules IP MASQ dont vous avez besoin. Tous les modules
# IP MASQ actuels sont montres ci-dessous mais sont commentes pour les empecher de
# se charger.
# Necessaire pour le chargement initial des modules
#
/sbin/depmod -a
# Permet le masquerading correct des transfert de fichier par FTP avec la methode PORT
#
/sbin/modprobe ip_masq_ftp
# Permet le masquerading de RealAudio par UDP. Sans ce module,
# RealAudio FONCTIONNERA mais en mode TCP. Ce qui peu causer une baisse
# dans la qualite du son
#
/sbin/modprobe ip_masq_raudio
# Permet le masquerading des transferts de fichier par DCC pour les IRC
#
#/sbin/modprobe ip_masq_irc
# Permet le masquerading de Quake et QuakeWorld par defaut. Ce module est
# necessaire pour les utilisateurs multiples dirriere un server Linux MASQ. Si vous voulez jouer
# a Quake I, II, et III, utilisez le second exemple.
#
# NB: si vous rencontrez des ERREURs lors de chargement du module QUAKE, c'est que vous utilisez
# un ancien noyau buggue. Mettez a jour votre noyau pour supprimer l'erreur.
#
#Quake I / QuakeWorld (ports 26000 and 27000)
#/sbin/modprobe ip_masq_quake
#
#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960)
#/sbin/modprobe ip_masq_quake 26000,27000,27910,27960
# Permet le masquerading du logiciel CuSeeme pour la video conference
#
#/sbin/modprobe ip_masq_cuseeme
# Permet le masquerading du logiciel VDO-live pour la video conference
#
#/sbin/modprobe ip_masq_vdolive
#CRITIQUE: Active l'IP forwarding puisqu'il est desactive par defaut
#
# Utilisateurs Redhat: vous pourrez essayer en changeant les options dans
# /etc/sysconfig/network de:
#
# FORWARD_IPV4=false
# to
# FORWARD_IPV4=true
#
echo "1" > /proc/sys/net/ipv4/ip_forward
#CRITIQUE: Active automatiquement l'IP defragmenting puisqu'il est desactive par defaut
# dans les noyaux 2.2.x.
#
# Ceci etait une option de compilation mais ca a change
# depuis le noyau 2.2.12. Noter aussi que quelques distributions
# ont enlevé cette option de la table /proc. Cette cette entrée n'est pas
# presente dans votre /proc, ne vous inquietez pas.
#
echo "1" > /proc/sys/net/ipv4/ip_always_defrag
# Utilisateurs d'IP Dynamiques:
#
# Si vous recevez votre adresse IP de maniere dynamique a partir d'un server SLIP, PPP,
# ou DHCP, activez option suivante qui active le hacking (au bon sens du terme NDT) des
# adresses IP dynamique dans IP MASQ, rendant ainsi les choses plus faciles pour les
# programmes du type Diald.
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr
# Active le patch LooseUDP dont certains jeux reseaux ont besoin
#
# Si vous etes en train d'essayer de faire fonctionner un jeu sur Internet au travers votre
# serveur MASQ, et vous l'avez configure le mieux que vous pouviez mais que ca fonctionne
# toujours pas, essayez d'activer cette option (en supprimant le # en debut de ligne). Cette
# option est desactivee par defaut pour eviter une probable vulnerabilite au port scanning
# UDP en interne.
#
#echo "1" > /proc/sys/net/ipv4/ip_masq_udp_dloose
# Specifiez ici votre adresse IP statique.
#
# Si vous avez une adresse IP DYNAMIQUE :
# votre jeu de regles doit trouver votre adresse IP a chaque fois que vous avez une nouvelle.
# Dans ce but, activez le script d'une ligne qui suit. (Veuillez SVP noter que les differents
# apostrophes, guillemets etc. ont leur importance et sont distincts).
#
#
# utilisateurs de DHCP :
# ----------------------
# Si vous recevez votre adresse TCP/IP, **vous devez** activer les commandes
# #és sous la section PPP ET remplacerle mot "ppp0" par le nom de votre
# de votre connetion Internet EXTERNE (eth0, eth1, etc). Notez aussi que le server
# DHCP peut changer votre adress IP. Pour resoudre ce probleme, les utilisateurs
# doivent configurer leur client DHCP de sorte qu'il relance le jeu de regles du firewall
# chaque fois que leur bail DHCP est renouvele.
#
# NB #1: Quelques clients DHCP comme l'ancienne version de "pump" (les nouvelles
# versions ont ete corrigees) n'avait pas la capacité de relancer
# les scripts apres une renouvellement de bail. Pour cette raison, vous
# aurez besoin de le remplacer par quelquechose du style "dhcpcd" ou "dhclient".
#
# NB #2: La syntaxe de "dhcpcd" a changé dans les versions recentes.
#
# Les anciennes version avaient une syntaxe du type:
# dhcpcd -c /etc/rc.d/rc.firewall eth0
#
# Les versions plus recentes ont une syntaxe du type:
# dhcpcd eth0 /etc/rc.d/rc.firewall
#
# NB #3: Pour les utilisateurs de Pump, ajouter cette ligne de commande dans votre fichier
# /etc/pump.conf:
#
# script /etc/rc.d/rc.firewall
#
# utilisateurs de PPP :
# ---------------------
# Si vous n'etes pas deja au courant, le script /etc/ppp/ip-up est toujours lance quand
# une connexion PPP arrive. A cause de ca, on peut demander au jeu de regles d'aller recuperer
# la nouvelles adresse IP PPP et de mettre a jour notre jeu de regles du strong firewall.
#
# Si le fichier /etc/ppp/ip-up existe deja, vous devez le modifier et ajouter une ligne
# contenant "/etc/rc.d/rc.firewall" pres de la fin du fichier.
#
# Si vous n'avez pas encore de script /etc/ppp/ip-up, vous devez creer le lien suivant
# pour lancer le script /etc/rc.d/rc.firewall.
#
# ln -s /etc/rc.d/rc.firewall /etc/ppp/ip-up
#
# * Vous devez ensuite activer les commandes #ees si dessous *
#
#
# Utilisateurs de PPP et DHCP :
# -----------------------------
# Enlevez le # de la ligne si dessous et placez un # sur la ligne suivante.
#
#extip="`/sbin/ifconfig ppp0 | grep 'inet addr' | awk '{print $2}' | sed -e 's/.*://'`"
# Pour les utilisateurs de PPP avec une adresse IP statique:
#
extip="your.static.PPP.address"
# Tous les utilisateurs de PPP et DHCP doivent utiliser ceci pour corriger le nom de
# leur interface EXTERNE
extint="ppp0"
# Assigne l'IP interne
intint="eth0"
intnet="192.168.0.0/24"
# MASQ timeouts
#
# timeout de 2 heures pour les sessions TCP
# timeout de 10 sec pour le traffic apres que le paquet TCP/IP "FIN" est recu
# timeout de 160 sec pour le traffic UDP (Important pour les utilisateur d'ICQ MASQues)
#
ipchains -M -S 7200 10 60
#############################################################################
# Entrée (incoming), flush et politique par defaut de rejet. En fait la politique par defaut
# est inapplicable parce qu'il y une regle qui attrape tout, refuse et logue.
#
ipchains -F input
ipchains -P input REJECT
# interface locale, machines locales, on peut allez n'importe ou
#
ipchains -A input -i $intint -s $intnet -d 0.0.0.0/0 -j ACCEPT
# interface distance, pretendant etre une machine locale, IP spoofing, tire toi
#
ipchains -A input -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT
# interface distante, toute source, peut aller a l'adresse PPP permanante
#
ipchains -A input -i $extint -s 0.0.0.0/0 -d $extip/32 -j ACCEPT
# boucler sur l'interface est valide.
#
ipchains -A input -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
# regle qui attrape tout, refuse tout autre entrée et le logue. Dommage qu'il n'y ait pas
# d'options pour le log sur cette politique mais ceci va faire le travail :
#
ipchains -A input -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
#############################################################################
# Sortie (outgoing), flush et politique par defaut de rejet. En fait la politique par defaut
# est inapplicable parce qu'il y une regle qui attrape tout, refuse et logue.
#
ipchains -F output
ipchains -P output REJECT
# interface locale, toute source allant vers le reseau local est valide
#
ipchains -A output -i $intint -s 0.0.0.0/0 -d $intnet -j ACCEPT
# sortie vers le reseau local d'une interface distance, routage bizarre, rejet
#
ipchains -A output -i $extint -s 0.0.0.0/0 -d $intnet -l -j REJECT
# sortie du reseau local vers une interface distante, masquerading modifié, rejet
#
ipchains -A output -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT
# tout autre chose qui sort de l'interface distance est valide
#
ipchains -A output -i $extint -s $extip/32 -d 0.0.0.0/0 -j ACCEPT
# boucler sur l'interface est valide.
#
ipchains -A output -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
# regle qui attrape tout, refuse tout autre sortie et le logue. Dommage qu'il n'y ait pas
# d'options pour le log sur cette politique mais ceci va faire le travail :
#
ipchains -A output -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
#############################################################################
# Forwarding, flush et politique par defaut de rejet. En fait la politique par defaut
# est inapplicable parce qu'il y une regle qui attrape tout, refuse et logue.
#
ipchains -F forward
ipchains -P forward DENY
# Masquerade a partir du reseau local sur l'interface locale vers n'importe ou.
#
ipchains -A forward -i $extint -s $intnet -d 0.0.0.0/0 -j MASQ
#
# regle qui attrape tout, refuse tout autre forwarding et le logue. Dommage qu'il n'y ait pas
# d'options pour le log sur cette politique mais ceci va faire le travail :
#
ipchains -A forward -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
#Fin du fichier.
Avec IPCHAINS, on peut bloquer le traffic vers un site particuler grâce aux règles "input", "output", et/ou "forward". Souvenez vous que les jeux de règles sont traitées de haut en bas et que "-A" dit a IPCHAINS de "coller" une nouvelle règle au jeu de règles existant. Donc, avec ça en tête, toute règle spécifique doit venir avant les règles globales. Par exemple :
Avec la règle "input" :
Vraisemblablement la méthode la plus efficace et la plus rapide pour bloquer le traffic mais elle arrête seulement les machines MASQuées et NON la machine firewall elle-même. Biensûr, vous pourriez vouloir permettre cette combinaison :
Dans tous les cas, pour bloquer 204.50.10.13:
dans le jeu de règles de /etc/rc.d/rc.firewall :
... début des règles -I ... # rejette et logue l'interface locale, les machines locales allant à 204.50.10.13 # ipchains -A input -s 192.168.0.0/24 -d 204.50.10.13/32 -l -j REJECT ... fin des règles -I ...
avec la règle -O (output ):
C'est la méthode la plus lente parce qeu les paquets passent par le masquerading d'abord et sont ensuite éliminés. Cependant, cette règle empêche meme la machine firewall d'accéder à des sites interdits.
... début des règles -O ... # rejette et logue les transimissions sortantes vers 204.50.10.13 # ipchains -A output -s $ppp_ip/32 -d 204.50.10.13/32 -l -j REJECT # tout autre chose qui sort de l'interface distante est valide # ipchains -A output -s $ppp_ip/32 -d 0.0.0.0/0 -l -j ACCEPT ... fin des règles -O ...avec la règle -F (forward ):
Sans doute plus lent pour bloquer le traffic que les règles -I (input). Ne bloque que les traffics des machines masqueradées (i.e. les machines internes). La machine firewall peut toujours atteindre le(s) site(s) interdit(s).
... début des règles -F ... # rejette et logue les transmissions de l'interface locale PPP vers 204.50.10.13. # ipchains -A forward -i ppp0 -s 192.168.0.0/24 -d 204.50.10.13/32 -l -j REJECT # Masquerade du reseau local vers vers n'importe où. # ipchains -A forward -i ppp0 -s 192.168.0.0/24 -d 0.0.0.0/0 -j MASQ ... fin des règles -F ...Il n'y a pas besoin de règle spéciale pour permettre aux machines du réseau 192.168.0.0/24 d'aller à 204.50.11.0. Pourquoi ? Parce que c'est déjà traité dans la règle MASQ globale.
NB : Contrairement à IPFWADM, IPCHAINS n'a seulement qu'une manière de coder le nom des interfaces. IPCHAINS utilise l'option "-i eth0" là ou IPFADM avait le "-W" pour le nom de l'interface et le "-V" pour l'adresse IP de l'interface.
Masquerader plus d'un réseau interne est une tâche plutôt simple. Vous devez d'abord vérifier que tous vos réseaux fonctionnent correctement (internes et externes). Vous devez ensuite permettre au traffic de passer dans les interfaces internes et d'être MASQués vers Internet.
Ensuite, vous devez activer le Masquerading sur les interfaces INTERNES. Cet exemple utilise au total TROIS interfaces : eth0 est une connexion EXTERNE vers Internet, eth1 est le réseau 192.1680.0.0, et eth2 et le réseau 192.168.1.0. eth1 et eth2 vont tous deux être MASQués au travers de l'interface eth0. Dans votre jeu de règles rc.firewall, juste à côté de votre ligne activant MASQ, ajoutez ce qui suit :
#Active la communication entre les interfaces internes /sbin/ipchains -A forward -i eth1 -d 192.168.0.0/24 /sbin/ipchains -A forward -i eth2 -d 192.168.1.0/24 #Permet aux interfaces internes de MASQuer vers Internet /sbin/ipchains -A forward -j MASQ -i eth0 -s 192.168.0.0/24 -d 0.0.0.0/0 /sbin/ipchains -A forward -j MASQ -i eth0 -s 192.168.1.0/24 -d 0.0.0.0/0
#Active la communication entre les interfaces internes /sbin/ipfwadm -F -a accept -V 192.168.0.1 -D 192.168.1.0/24 /sbin/ipfwadm -F -a accept -V 192.168.1.1 -D 192.168.0.0/24 #Permet aux interfaces internes de MASQuer vers Internet /sbin/ipfwadm -F -a masq -W eth0 -S 192.168.0.0/24 -D 0.0.0.0/0 /sbin/ipfwadm -F -a masq -W eth0 -S 192.168.1.0/24 -D 0.0.0.0/0
IPPORTFW, IPAUTOFW, REDIR, UDPRED, et les autres programmes sont des outils de port forwarding TCP et/ou UDP génériques pour Linux IP Masquerade. Ces outils sont typiquement utilisés avec ou en remplacement de modules IP MASQ spécifiques tels que ceux pour FTP, Quake, etc. Avec les port forwarders, vous pouvez rédiriger les connexions venant d'Internet vers une machine interne derrière le serveur IP MASQ, dont l'adresse est privée . Cette possibilité de forwarding inclus les protocoles réseaux tels que TELNET, WWW, SMTP, FTP (avec un patch special - regardez si dessous), ICQ, et bien d'autres.
NB : Si vous voulez juste faire un simple port forwarding sans IP Masquerading, vous aurez TOUJOURS BESOIN d'activer l'IP Masquerading dans votre noyau ET soit dans votre jeu de règles IPFWADM soit IPCHAINS pour être capable d'utiliser les outils de portforwarding de Linux
Alors pourquoi tous ces choix ? IPAUTOFW, REDIR, et UDPRED (toutes les URLs sont dans la section 2.0.x-Requirements ) étaient les premiers outils disponibles pour les utilisateurs d'IP MASQ pour permettre cette fonctionnalié. Plus tard, quand Linux IP Masquerade a mûri, ces outils furent remplacés par IPPORTFW qui constitue une solution plus intelligente. A cause de la disponibilité d'outils nouveaux, il est *FORTEMENT DECONSEILLE* d'utiliser les outils tels que IPAUTOFW et REDIR parce qu'ils n'informent pas correctement le noyau de leur présence et peuvent dans les cas les plus extrèmes d'utilisation CRASHer votre serveur Linux. Notez aussi que la solution la plus recente est MFW. Son avantage principal est de permettre une intégration plus étroite avec l'outil IPCHAINS. Avec cette solution, vous utilisez un jeu de règles IPCHAINS pour "Marker" un paquet spécifique et créer ensuite une chaine différente pour faire ensuite le bon forwarding. Cette méthode n'est pas encore traitée dans ce HOWTO.
NB #2 : avec PORTFW sur les noyaux 2.2.x, les machines internes NE PEUVENT PAS utiliser la meme adresse IP PORTFWdé pour acceder une machine interne bienque ça marche très bien avec des machines externes sur Internet. Si c'est un probèleme pour vous, vous pouvez AUSSI implémenter l'outil portfw REDIR pour laisser des machines internes être redirigées vers un serveur interne. Une chose à noter est que le jeu de règles de l'imminent NetFilter résoud ce problème. Si vous désirez avoir une explication technique sur les raisons du non fonctionnement du forwarding interne/externe, reportez vous SVP à la fin de la section PORTFW du noyau 2.2.x pour les notes de Juan.
NB #3 : Le forwarding du traffic de serveurs FTP vers un serveur FTP MASQué interne, connu sous le nom de PORTFW FTP, est maintenant compatible avec les noyaux 2.0.x et les noyaux 2.2.x . C'est possible soit en patchant le noyau Linux si la compatibilité n'est pas encore implémenté dans votre noyau ou bien un utilisant un programme de proxy FTP externe. Vous devriez aussi noter que le code du module noyau est toujours expérimental et que certaines personnes obtiennent de meilleurs résultats avec des sessions FTP ACTIVES par rapport aux connexions PASSIVES. Et, chose assez intéressante, d'autres personnes obtiennent exactement le contraire. Envoyez nous SVP vos résultats. De plus amples détails sont fournis dans les sections 2.2.x et 2.0.x en tant que solutions fournis pas les différents patches.
Avant de plonger dans l'installation de IPPORTFW pour 2.0.x ou de la version de 2.2.x de IPMASQADM avec le support IPPORTFW, veuillez noter qu'il peut y avoir des problèmes liés à la sécurité avec tout port forwarder. La raison est que ces outils créent un trou dans le firewall par paquet pour les port TCP/UDP forwardés. Bienque cela ne conduise à aucune menace pour votre machine Linux, ca pourrait être un problème pour la machine interne vers lequel ce traffic est forwardé. Ne vous inquietez pas non plus, voilà ce que Steven Clarke (l'auteur de IPPORTFW) a à dire sur ce sujet :
"Port Forwarding est appelé seulement parmis les fonctions de masquerading il suit donc
les même règles que IPFWADM/IPCHAINS. Masquerading est une extension de IP forwarding.
Toutefois, ipportfw ne vois les paquets que s'ils remplissent les conditions
d'entrée et de masquerading du jeu de règles d'ipfwadm."
Donc, pour installer l'IPPORTFW forwarding pour chacun des noyaux 2.0.x ou 2.2.x, vous devez recompiler le noyau Linux avec la compatibilité IPPORTFW.
D'abord, vérifiez que vous avez les sources du noyau 2.2.x le plus récent dans /usr/src/linux. Si vous ne l'avez pas dejà fait, reportez vous SVP à la section Kernel-Compile pour de plus amples détails. Ensuite, téléchargez le programme "ipmasqadm.c" de la section 2.2.x-Requirements dans le repertoire /usr/src.
Vous aurez ensuite à compiler le noyau 2.2.x comme expliqué dans la section Kernel-Compile . Vérifiez bien que vous dites YES à l'option IPPORTFW quand vous configurez votre noyau. Une fois que vous avez compilé le noyau et que vous avez rebooté, revenez à cette section.
Maintenant, compilez et installez l'outil IPMASQADM :
cd /usr/src
tar xzvf ipmasqadm-x.tgz
cd ipmasqadm-x
make
make install
Ensuite, pour cet exemple, nous allons permettre à TOUT le traffic Internet WWW (port 80) arrivant à votre adresse Internet TCP/IP d'être forwardé vers une machine interne Masqueradée dont l'IP est 192.168.0.10.
PORTFW FTP : Comme mentionné precédemment, il y a deux solutions pour forwarder le traffic d'un server FTP vers une machine interne MASQuée. La première solution *EST* le module BETA IP_MASQ_FTP pour noyau 2.2.x pour PORT Forwarder les connexions FTP vers un serveur FTP interne MASQué. L'autre méthode est d'utiliser un programme de proxy FTP (l'URL se trouve dans la section 2.2.x-Requirements . Vouz devriez aussi noter que le module noyau FTP permet aussi d'ajouter des PORTFW FTP supplémentaires à la volée sans avoir à relancer le module et ainsi planter les connexions FTP en cours. Vous trouverez de plus amples détails sur le site d'IPMASQ WWW à http://ipmasq.cjb.net. Il y a aussi des exemples et des informations sur les connexions FTP PORTFWés ci dessous dans la section du noyau 2.0.x.
NB: Une fois le port forward du port 80 activé, ce port ne pourra plus être utilisé par le serveur Linux IP Masquerade. Pour être plus précis, si vous avez un server WWW sur le server MASQ, un portfw va maintenant diriger tous les internautes vers les pages WWW INTERNES et non vers celles du serveur IPMASQ.
Dans tous les cas, pour activer le port forwarding, modifiez le jeu de règles /etc/rc.d/rc.firewall. Ajoutez les lignes suivant mais assurez vous de remplacer le mot "$extip" par votre adresse IP.
NB: Si vous avez une adresse IP DYNAMQUE que vous recevez par votre FAI (PPP, ADSL, Cablemodems, etc.), vous aurez BESOIN de rendre votre jeu de règles /etc/rc.d/rc.firewall plus intelligent. Pour ce faire, reportez vous SVP à la section Strong-IPCHAINS-Rulesets ci-dessus ou à la section TrinityOS - Section 10 pour de plus amples détails sur les jeux de règles 'strong' et les adresses IP Dynamiques. Je vous donne une indication toutefois : /etc/ppp/ip-up pour les utilisateurs de PPP.
/etc/rc.d/rc.firewall
--
#echo "Activation de l'IPPORTFW sur le LAN externe..."
#
/usr/sbin/ipmasqadm portfw -f
/usr/sbin/ipmasqadm portfw -a -P tcp -L $extip 80 -R 192.168.0.10 80
--
C'est tout ! Relancez juste votre jeu de règles /etc/rc.d/rc.firewall et testez le !
Si vous recevez le message d'erreur "ipchains: setsockopt failed: Protocol not available", c'est que vous n'êtes pas en train d'utiliser le nouveau noyau. Verifiez que vous avez bien installé le nouveau noyau, reconfigurez votre boot loader (par exemple LILO), et ensuite, rebootez. Si vous êtes sûr que vous êtes sur le nouveau noyau, lancez la commande "ls /proc/net/ip_masq" et verifiez que le fichier "portfw" existe. Si non, vous devez avoir fait une erreur lors de la configuation de votre noyau. Essayez de nouveau.
Pour ceux qui veulent comprendre pourquoi PORTFW ne peut pas rediriger le traffic des interfaces externes et internes, voici un email de Juanjo qui l'explique mieux :
De Juanjo Ciarlante
--
>Si j'utilise :
>
> ipmasqadm portfw -a -P tcp -L 1.2.3.4 80 -R 192.168.2.3 80
>
>Tout fonctionne très bien a partir de l'exterieur mais les requetes internes pour la meme
>adresse 1.2.3.4 echouent. Y a t-il des chaines qui permettent a une machine sur le reseau local
>192.168.2.0 d'acceder à www.periapt.com sans utiliser de proxy ?
En fait, non.
D'habitude, je mets en place une règle ipmasqadm pour l'extérieur, *ET* un port
redirector pour l'intérieur. Ceci fonctionne parce que ipmasqadm connecte avant que redir
ne recoive l'eventuelle connexion exterieur, _mais_ laisse les choses comme elles sont sinon
(géré par des règles APPROPRIEES).
Le vrai problème "conceptuel" provient du fait que la VRAIE IP du client (peer) cible
est sur le même réseau que le serveur cible
Le scénario d'un echec pour le "local masq" est :
client: 192.168.2.100
masq: 192.168.2.1
serv: 192.168.2.10
1)client->server packet
a) client: 192.168.2.100:1025 -> 192.168.2.1:80 [SYN]
b) (masq): 192.168.2.100:1025 -> 192.168.2.10:80 [SYN]
(et garde 192.168.2.1:61000 192.168.2.100:1025 apparentés)
c) serv: recoit le paquet masqué (1b)
2)server->client packet
a) serv: 192.168.2.10:80 -> 192.168.2.100:1025 [SYN,ACK]
b) client: 192.168.2.100:1025 -> 192.168.2.10:80 [RST]
Maintenant prenez le temps de comparer (1a) avec (2a).
Vous voyez, le serveur à repondu DIRECTEMENT au client sans passer par
masq (ne laissant donc pas masq ANNULER la modification du paquet) parce que
c'est le MEME réseau, donc le client annule la connexion.
J'espère que cela aide.
Amicalement,
Juanjo
D'abord, vérifiez que vous avez les sources du noyau 2.0.x le plus récent dans /usr/src/linux. Si vous ne l'avez pas dejà fait, reportez vous SVP à la section Kernel-Compile pour de plus amples détails. Ensuite, téléchargez le programme "ipmasqadm.c" de la section 2.0.x-Requirements dans le repertoire /usr/src.
Ensuite, si vous projetez de port forwarder le traffic FTP vers un serveur interne, vous allez devoir appliquer un NOUVEAU patch module additionnel, IP_MASQ_FTP, que vous trouverez à la section 2.0.x-Requirements . De plus amples détails le concernant se trouvent plus loin dans cette section. Veuillez noter SVP que ce n'est pas le même patch que pour les noyaux 2.2.x donc quelques fonctionnalités telles que le dynamique FTP PORT n'est pas présent.
Maintenant, copiez le patch IPPORTFW (subs-patch-x.gz) dans le repertoire de Linux
cp /usr/src/subs-patch-1.37.gz /usr/src/linux
Ensuite, appliquez le patch noyau pour creer l'option noyau IPPORTFW :
cd /usr/src/linux
zcat subs-patch-1.3x.gz | patch -p1
Ok, il est temps de compiler le noyau comme indiqué à la section Kernel-Compile . Repondez YES à l'option IPPORTFW qui est maintenant disponible quand vous configurez le noyau. Une fois la compilation terminée, et après avoir rebooté, vous pouvez revenir à cette section.
Maintenant, avec votre nouveau noyau fraichment compilé, compilez et installer le programme "IPPORTFW"
cd /usr/src
gcc ipportfw.c -o ipportfw
mv ipportfw /usr/local/sbin
Ensuite, pour cet exemple, nous allons permettre à TOUT le traffic Internet WWW (port 80) arrivant à votre adresse Internet TCP/IP d'être forwardé vers une machine interne Masqueradée dont l'IP est 192.168.0.10.
NB: Une fois le port forward du port 80 activé, ce port ne pourra plus être utilisé par le serveur Linux IP Masquerade. Pour être plus spécifique, si vous avez un server WWW sur le server MASQ, un portfw va maintenant diriger tous les internautes vers les pages WWW INTERNES et non vers celles du serveur IPMASQ. La seule solution à ce problème est de port fowarder un autre port, disons 8080, vers votre machine MASQ interne. Bienque cela fonctionne, tous les internautes devront coller un :8080 à l'URL pour pouvoir contacter votre server WWW MASQué interne.
Dans tous les cas, pour activer le port forwarding, modifiez le jeu de règles /etc/rc.d/rc.firewall. Ajoutez les lignes suivant mais assurez vous de remplacer le mot "$extip" par votre adresse IP.
NB: Si vous avez une adresse IP DYNAMQUE que vous recevez par votre FAI (PPP, ADSL, Cablemodems, etc.), vous aurez BESOIN de rendre votre jeu de règles /etc/rc.d/rc.firewall plus intelligent. Pour ce faire, reportez vous SVP à la section Strong-IPCHAINS-Rulesets ci dessus ou à la section TrinityOS - Section 10 pour de plus amples détails sur les jeux de règles 'strong' et les adresses IP Dynamiques. Je vous donne un peu indice toutefois : /etc/ppp/ip-up pour les utilisateurs de PPP.
/etc/rc.d/rc.firewall
--
#echo "Activation de l'IPPORTFW sur le LAN externe..."
#
/usr/local/sbin/ipportfw -C
/usr/local/sbin/ipportfw -A -t$extip/80 -R 192.168.0.10/80
# Veuillez notez SVP que le PORTFWing du port 20 N'EST PAS nécessaire pour les
# connexions ACTIVES puisque le serveur FTP interne va lancer cette connexion
# sur le port 20 et qu'il va donc être correctement pris en charge par les mechanismes
# classiques de MASQ.
--
C'est tout ! Relancez juste votre jeu de règles /etc/rc.d/rc.firewall et testez le !
Si vous recevez le message d'erreur "ipchains: setsockopt failed: Protocol not available", c'est que vous n'êtes pas en train d'utiliser le nouveau noyau. Verifiez que vous avez bien installé le nouveau noyau, reconfigurez votre boot loader (par exemple LILO), et ensuite, rebootez.
Port Forwarder des serveurs FTP :
Si vous projetez de port forwarder FTP vers une machine interne, les choses se compliquent. La raison en est que le module noyau IP_MASQ_FTP standard n'était pas écrit pour ça, meme si des utilisateurs nous ont dit que cela fonctionnait sans problème. Personnellement, sans le patch, j'ai entendu dire que les transferts de fichiers longs, qui excèdent 30 minutes vont échouer alors que d'autres personnes jurent que ça fonctionne sans problème. Quoiqu'il en soit, je vous recommande d'essayer cette instruction PORTFW avec le module STOCK ip_masq_ftp et de voir si ca fonctionne pour vous. Si ca marche pas, essayez d'utiliser le module ip_masq_ftp modifié.
Pour ceux qui ont besoin du module, Fred Viles a écrit un module IP_MASQ_FTP modifié pour faire en sorte que ca fonctionne. Si vous êtes curieux et que vous voulez savoir EXACTEMENT ce que sont les problèmes, téléchargez l'archive suivante parce que les documents de Fred sont très bien faits. Vous devez aussi comprendre que le patch est quelque peu expérimental et considerez le donc comme tel. Vous devez aussi noter que ce patch fonctionne UNIQUEMENT sur les noyaux 2.0.x puisqu'il y a un patch différent disponible pour les noyaux 2.2.x.
Donc, pour faire fonctionner le patch 2.0.x, vous avez besoin de :
Une fois que vous avez fait tout ça, modifiez votre jeu de règles /etc/rc.d/rc.firewall et ajoutez les lignes suivantes en prenant soin de remplacer "$extip" par votre propre adresse IP.
Cet exemple, comme ci-dessus, va permettre de renvoyer TOUT le traffic internet FTP (port 21) de votre connexion Internet TCP/IP vers la machine interne Masqueradée dont l'adresse IP est 192.168.0.10.
NB: Une fois le port forward du port 21 activé, ce port ne pourra plus être utilisé par le serveur Linux IP Masquerade. Pour être plus précis, si vous avez un server FTP sur le server MASQ, un portfw va maintenant diriger tous les internautes vers les pages FTP INTERNES et non vers celles du serveur IPMASQ.
/etc/rc.d/rc.firewall
--
#echo "Activation de l'IPPORTFW sur le LAN externe..."
#
/usr/local/sbin/ipportfw -C
/usr/local/sbin/ipportfw -A -t$extip/21 -R 192.168.0.10/21
#NB : Si vous allez utiliser plusieurs port locaux à PORTFWer
# vers plusieurs seveurs FTP internes (disons, 21, 2121, 2112,
# etc), vous devez configurer le module ip_masq_ftp pour qu'il
# ecoute ces ports. Pour ce faire, modifiez votre script
# /etc/rc.d/rc.firewall comme le montre ce HOWTO
# pour qu'il ressemble a ceci :
#
# /sbin/modprobe ip_masq_ftp ports=21,2121,2112
#
# Relancez le script /etc/rc.d/rc.firewall pour que les changements
# prennent effet.
#Veuillez notez SVP que le PORTFWing du port 20 N'EST PAS nécessaire pour les
# connexions ACTIVES puisque le serveur FTP interne va lancer cette connexion
# sur le port 20 et qu'il va donc être correctement pris en charge par les mechanismes
# classiques de MASQ.
--
C'est tout ! Relancez juste votre jeu de règles /etc/rc.d/rc.firewall et testez le !
Si vous recevez le message d'erreur "ipchains: setsockopt failed: Protocol not available", c'est que vous n'êtes pas en train d'utiliser le nouveau noyau. Verifiez que vous avez bien installé le nouveau noyau, reconfigurez votre boot loader (par exemple LILO), et ensuite, rebootez.
Linux IP Masquerade est compatible avec CuSeeme via le module noyau "ip_masq_cuseeme". Ce module noyau devrait être chargé par le script /etc/rc.d/rc.firewall. Une fois que le module "ip_masq_cuseeme" est installé, vous devriez être capables de recevoir et d'initier des connexions CuSeeme vers des réflecteurs distants et/ou des utilisateurs.
NB : Il est recommandé d'utiliser l'outil IPPORTFW au lieu du vieux IPAUTOFW pour utiliser CuSeeme.
Si vous avez besoin d'information explicites sur la configuration de CuSeeme, vous pouvez vous reporter à Michael Owings's CuSeeMe page pour un Mini-HOWTO ou The IP Masquerade Resources pour un mirroir de ce Mini-HOWTO.
Il y a deux méthodes pour faire fonctionner ICQ derrière un serveur Linux MASQ. Une des solutions est d'utiliser le nouveau module ICQ Masq et l'autre solution est d'utiliser IPPORTFW.
Le modue ICQ a quelques avantages. Il permet une configuration simple pour plusieurs utilisateurs ICQ derrière un server MASQ. Il ne requiert pas non plus de changement dans les clients ICQ. Récemment, la version 2.2.x du module a été mis à jour pour permettre le transfert de fichier et le "chat" en temps-réél. Toutefois, la version 2.0.x du module n'est pas parfait. Toutefois, je pense maintenant que c'est la MEILLEURE méthode pour faire fonctionner ICQ avec IP Masq sous les noyaux 2.2.x.
Pour la configuration IPPORTFW, vous allez devoir faire quelques changements sur Linux et sur les clients ICQ mais toutes les fonctionnalités d'ICQ (messages, URLs, chat, transfert de fichier, etc.) fonctionnent.
Si vous êtes interessés par le module IP Masq ICQ pour les noyaux 2.2.x d'Andrew Deryabin's [email protected], vous pouvez vous reporter à la section 2.2.x-Requirements pour plus de détails.
L'exemple qui suit est pour les noyaux 2.0.x avec IPFWADM:
J'ai inclus deux exemples ici pour l'utilisateur : les deux fonctionnent très bien.
Exemple #1
--
/usr/local/sbin/ipportfw -A -t10.1.2.3/2000 -R 192.168.0.10/2000
/usr/local/sbin/ipportfw -A -t10.1.2.3/2001 -R 192.168.0.10/2001
/usr/local/sbin/ipportfw -A -t10.1.2.3/2002 -R 192.168.0.10/2002
/usr/local/sbin/ipportfw -A -t10.1.2.3/2003 -R 192.168.0.10/2003
/usr/local/sbin/ipportfw -A -t10.1.2.3/2004 -R 192.168.0.10/2004
/usr/local/sbin/ipportfw -A -t10.1.2.3/2005 -R 192.168.0.10/2005
/usr/local/sbin/ipportfw -A -t10.1.2.3/2006 -R 192.168.0.10/2006
/usr/local/sbin/ipportfw -A -t10.1.2.3/2007 -R 192.168.0.10/2007
/usr/local/sbin/ipportfw -A -t10.1.2.3/2008 -R 192.168.0.10/2008
/usr/local/sbin/ipportfw -A -t10.1.2.3/2009 -R 192.168.0.10/2009
/usr/local/sbin/ipportfw -A -t10.1.2.3/2010 -R 192.168.0.10/2010
/usr/local/sbin/ipportfw -A -t10.1.2.3/2011 -R 192.168.0.10/2011
/usr/local/sbin/ipportfw -A -t10.1.2.3/2012 -R 192.168.0.10/2012
/usr/local/sbin/ipportfw -A -t10.1.2.3/2013 -R 192.168.0.10/2013
/usr/local/sbin/ipportfw -A -t10.1.2.3/2014 -R 192.168.0.10/2014
/usr/local/sbin/ipportfw -A -t10.1.2.3/2015 -R 192.168.0.10/2015
/usr/local/sbin/ipportfw -A -t10.1.2.3/2016 -R 192.168.0.10/2016
/usr/local/sbin/ipportfw -A -t10.1.2.3/2017 -R 192.168.0.10/2017
/usr/local/sbin/ipportfw -A -t10.1.2.3/2018 -R 192.168.0.10/2018
/usr/local/sbin/ipportfw -A -t10.1.2.3/2019 -R 192.168.0.10/2019
/usr/local/sbin/ipportfw -A -t10.1.2.3/2020 -R 192.168.0.10/2020
--
Exemple #2
--
port=2000
while [ $port -le 2020 ]
do
/usr/local/sbin/ipportfw -A t10.1.2.3/$port -R 192.168.0.10/$port
port=$((port+1))
done
--
L'exemple suivant est pour les noyaux 2.2.x avec IPCHAINS:
J'ai inclus deux exemples ici pour l'utilisateur : les deux fonctionnent très bien.
Exemple #1
--
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2000 -R 192.168.0.10 2000
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2001 -R 192.168.0.10 2001
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2002 -R 192.168.0.10 2002
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2003 -R 192.168.0.10 2003
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2004 -R 192.168.0.10 2004
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2005 -R 192.168.0.10 2005
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2006 -R 192.168.0.10 2006
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2007 -R 192.168.0.10 2007
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2008 -R 192.168.0.10 2008
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2009 -R 192.168.0.10 2009
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2010 -R 192.168.0.10 2010
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2011 -R 192.168.0.10 2011
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2012 -R 192.168.0.10 2012
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2013 -R 192.168.0.10 2013
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2014 -R 192.168.0.10 2014
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2015 -R 192.168.0.10 2015
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2016 -R 192.168.0.10 2016
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2017 -R 192.168.0.10 2017
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2018 -R 192.168.0.10 2018
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2019 -R 192.168.0.10 2019
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2020 -R 192.168.0.10 2020
--
Exemple #2
--
port=2000
while [ $port -le 2020 ]
do
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 $port -R 192.168.0.10 $port
port=$((port+1))
done
--
Ensuite ICQ vous demandera de relancer ICQ pour que les changements prennent effet. Pour être tout a fait honnête, j'ai du REBOOTER la machine Windows9x pour faire marcher tout ca mais d'autres personnes disent que ca marche très bien autrement. Donc... essayez les deux manières.
Le patch LooseUDP permet au jeux en réseau compatible NAT qui utilisent des connexion UDP de FONCTIONNER et d'avoir de bonnes performances derrière un serveur Linux IP Masquerade. Pour le moment, LooseUDP est disponible comme patch pour les noyaux 2.0.36+ mais se trouve par défaut dans les noyaux 2.2.3+ bien qu'il est DESACTIVE par DEFAUT dans 2.2.16+
Pour faire fonctionner LooseUDM sur un noyau 2.0.x, suivez les étapes suivantes :
Ensuite, placez le patch LooseUDP dans /usr/src/linux. Une fois que c'est fait, tappez :
Pour un fichier patch compressé : zcat loose-udp-2.0.36.patch.gz | patch -p1
Pour un fichier patch NON-compressé : cat loose-udp-2.0.36.patch | patch -p1
Ensuite, suivant la version de votre "patch", vous allez voir 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 les texte "Hunk FAILED" UNE et UNE SEULE fois, au tout début de la processure de patching, ne vous inquiétez pas. Vous avez probablement un ancien fichier de patch (ce problème à été réparé) mais ca fonctionne quand même. Si ça échoue complètement, vérifiez que vous avez appliqué le patch IPPORTFW AVANT ce patch.
Une fois ce patch installé, reconfigurez votre noyau comme expliqué dans la section Kernel-Compile et verifiez bien que vous dites "Y" à l'option "IP: loose UDP port managing (EXPERIMENTAL) (CONFIG_IP_MASQ_LOOSE_UDP) [Y/n/?]".
Pour faire fonctionner LooseUDM sur un noyau 2.2.x, suivez les étapes suivantes :
echo "0" > /proc/sys/net/ipv4/ip_masq_udp_dloose
en "1" et relancez votre jeu de règles rc.firewall. Un exemple de ceci est fourni dans les exemples des sections
rc.firewall-2.2.x
et
stronger-rc.firewall-2.2.x
.Une fois que vous avez relancé le nouveau noyau avec le LooseUDP activé, vous devriez être en conditions pour la plupart des jeux compatibles NAT. Nous vous fournissons quelques URL pour des patchs qui feront fonctionner des jeux tels que BattleZone ou d'autres jeux compatibles NAT. Vous pouvez vous reporter à la section Game-Clients pour de plus amples détails.