Réseaux privés avec « Roadrunner » en utilisant l'IP Masquerading

Gazette Linux n°51 — Mars 2000

Thierry Hamon

Adaptation française 

Frédéric Marchal

Correction du DocBook 

Article paru dans le n°51 de la Gazette Linux de mars 2000.

Cet article est publié selon les termes de la Open Publication License. La Linux Gazette n'est ni produite, ni sponsorisée, ni avalisée par notre hébergeur principal, SSC, Inc.


Table des matières

Lectures nécessaires
Le schéma d'ensemble
Choix du matériel
Installation de la passerelle
Configuration de IPChains et du Masquerading
Configuration du DNS pour le réseau privé
Configuration des stations de travail
Du coté de la sécurité
Résumé sur la sécurité
Un DNS dynamique
Commentaires
Fichiers d'exemples
/etc/rc.d/rc.local (passerelle)
/etc/sysconfig/network (passerelle)
/etc/sysconfig/network (stations de travail)
/etc/hosts (passerelle et stations de travail)
/etc/resolv.conf (passerelle et stations de travail)
/etc/pump.conf (sur la passerelle seulement)
/etc/named.conf (sur la passerelle seulement)
/var/named/local.zone (sur la passerelle seulement)
/var/named/local.reverse (sur la passerelle seulement)
A ajouter au fichier /etc/rc.d/rc.local (support dynsdns avec ddup)
/etc/conf.modules (sur la passerelle ; seules les lignes « alias ethx » nous concernent)
À propos de l'auteur

Résumé

Cet article est destiné à vous aider dans l'installation du réseau TCP/IP privé « masqueradé », connecté à l'Internet par le câble grâce au service Roadrunner de Time Warner. Il s'agit de la ré-écriture d'un article précédent sur le même sujet — avec l'arrivée de la RedHat 6 et la migration de Roadrunner vers le DHCP (au moins à Columbus, Ohio. Vérifiez si le DHCP est utilisé dans votre ville.), plusieurs choses ont changées. C'est une opération importante en ce qui concerne le réseau, qui implique des concepts allant du DNS au pare-feu. Quand vous aurez terminé ce travail, vous aurez acquis une réelle expérience dans l'installation d'un réseau de petite taille.

Une chose est à noter. J'ai appelé Roadrunner, ils avaient une idée plutôt vague en ce qui concerne l'autorisation d'utiliser l'IP-Masquerading. Les commerciaux disaient simplement que ça les dérangerait si vous monopolisez la bande passante.

Il y a deux « Je » dans ce document. Parfois, c'est Andrew qui parle, d'autres fois c'est Mark.

Lectures nécessaires

Ces HOWTOs contiennent les informations nécessaires pour comprendre le reste de cet article. Si vous décidez de continuer sans les lire, vous risquez de ne pas saisir totalement ce qui va être décrit ci-dessous.

  1. Networking — Les informations de base sur Ethernet et TCP/IP. Les sections 5 et 6 sont les plus intéressantes.

  2. IPCHAINS — Les chaînes pare-feu IP feront le plus gros du travail dans votre configuration. Cela a aussi de nombreuses implications au niveau de la sécurité.

  3. DNS — L'installation d'un DNS sera beaucoup plus facile si vous comprenez son fonctionnement.

  4. IP Masquerading — Ce document couvre l'IP Masquerading de manière plus générale qu'ici.

  5. Notre précédent article sur ce thème (version française).

  6. RRLinux Help Site — Le site d'assistance Linux de RoadRunner.

  7. Unix Security — La sécurité sous UNIX, située sur Yahoo.

  8. The Central Ohio Linux User Group — Le groupe des utilisateurs de Linux du centre de l'OHIO, d'où beaucoup d'idées proviennent.

Le schéma d'ensemble

Ce diagramme présente le principe :

Chaque gros point noir sur le diagramme est une carte ethernet, et chaque ligne de connexion est une longueur de câble CAT5, à l'exception du câble de connexion vers Time Warner qui part du boîtier de connexion. Notez que vous avez besoin d'une carte d'interface (de type ethernet) pour chaque station de travail et de deux pour votre passerelle.

Votre réseau privé est indiqué par un fond blanc dans l'image, et le reste du monde est dans la zone grisée. Vos stations de travail et vos hubs sont à l'intérieur de votre réseau privé. Notez que la passerelle est à la frontière des deux. Une adresse IP est assignée à chacune des cartes Ethernet, votre passerelle en possède une pour le monde extérieur et une autre pour votre réseau interne. Telle qu'elle est située, la passerelle a la possibilité de faire suivre des communications de votre réseau privé vers le monde extérieur.

Pour la suite de cette description, je vais donner au réseau privé le bloc d'adresses IP privées réservées 10.x.x.x (avec comme masque réseau 255.0.0.0) et choisir le nom de domaine « local ». Ceci peut bien sûr être modifié si vous savez ce que vous faîtes, ça marchera pour la plupart des gens.

Les stations de travail sont nommées « w1.local » (10.0.0.10) à « w3.local » (10.0.0.30) et la passerelle « masqueradée » est appelée « main.local » (10.0.0.1 sur le réseau privé). Comme auparavant, vous pouvez modifier ou étendre ce schéma si vous êtes à l'aise.

Choix du matériel

La passerelle nécessite relativement peu de ressources. Il peut s'agir d'un vieux 486 avec relativement peu de mémoire. Le routage des paquets ne demande pas particulièrement beaucoup de ressources. Si vous pouvez y faire tourner Linux, ça devrait faire l'affaire.

Les stations de travail peuvent être n'importe quelle machine sur laquelle est installé un système d'exploitation gérant le TCP/IP, tel que Linux, MacOS ou les systèmes d'exploitation de Microsoft. Vous aurez besoin d'équiper chaque machine d'une carte ethernet.

Choisissez un hub auto-configurable 10/100 Mbits. Il vous simplifiera la vie. Utilisez des cartes ethernet avec un débit de 100 Mbits à l'intérieur du réseau. Sur votre passerelle, la carte ethernet connectée à l'extérieur peut être une simple carte ethernet à 10 Mbits. J'utilise partout le même type de cartes ethernet. Elles ont toutes un débit de 10/100 Mbits. en utilisant le même matériel partout, vous vous simplifierez la vie la plupart du temps.

Utiliser des cartes PCI sur les systèmes Linux est une bonne chose. Maintenant, les cartes ethernet ne sont plus très chères et elles vous éviteront des maux de tête pendant la phase de configuration. J'ai utilisé des cartes Netgear FA310TX sur plusieurs machines sans rencontrer de problème. J'ai entendu dire que les cartes Intel rendaient de très bons services. Quoi qu'il en soit, faites une recherche sur le web et assurez-vous que les modules existent pour les cartes que vous achetez. Les pilotes des cartes Netgear et 3com (que j'ai utilisé largement) sont fournis avec la RedHat 6. Si vous devez utiliser de cartes ISA, la carte 3c509 de 3com est plutôt facile à utiliser. Cependant, gardez à l'esprit que si vous utilisez une machine plus vielle pour votre passerelle, vous devriez avoir que des slots ISA. Il faudra alors utiliser deux cartes ethernet. Dans ce cas, vous devrez avoir un utilitaire fourni par le constructeur de vos cartes (qui, d'habitude, ne tourne que sous DOS). Il vous permettra de sélectionner l'adresse E/S et/ou l'IRQ de vos cartes afin de prévenir les conflits.

Installation de la passerelle

La machine que vous utiliserez comme passerelle sera celle connectée à RoadRunner.

Tout d'abord, installez physiquement dans la machine les cartes ethernet que vous soigneusement choisies. En utilisant deux cartes de marques différentes sur la passerelle, vous éviterez les risques de confusion. Ainsi un pilote unique pour chaque carte vous permettra de connaître le nom de chacune (eth0 et eth1). Vous aurez aussi moins de risque de rencontrer des conflits d'interruption (qui doivent être fuis comme la peste). Si vous optez pour des cartes ISA, vous aurez besoin de récupérer des utilitaires DOS afin de configurer l'IRQ et les adresses d'entrée/sortie.

Commencez par installer proprement la RedHat 6 (puisque c'est le but de cet article) sur la passerelle. Si vous avez de la place sur le disque dur, allez plus loin et installez tout. Toutefois, vous n'avez pas vraiment besoin d'un serveur X, de logiciels de traitement d'images, etc, sur cette machine. Assurez-vous que vous installez ipchains, BIND, le serveur de nom avec cache, pump et d'autres paquetages importants pour ce que vous allez faire ici. Indiquez également au programme d'installation de lancer le démon named au démarrage.

Pour les besoins de cet article, eth0 ira vers le boîtier de connexion à Roadrunner et eth1 vers votre réseau privé. Vous pouvez probablement configurer et lancer la première interface ethernet pendant l'installation initiale. Connectez la carte correspondant à eth0 au boîtier de connexion avec le câble croisé adéquate et dites-lui d'utiliser DHCP pour obtenir son adresse IP (n'en spécifiez pas), le service RoadRunner vous assigera une. Utilisez le programme netconf (ou éditez directement les fichiers /etc/sysconfig/network-scripts/ifcfg-eth? et /etc/conf.modules) pour que l'interface eth1 fonctionne au démarrage, et affectez lui une adresse IP du réseau privé (10.0.0.1). Il vous faudra peut-être un peu bricoler pour qu'au démarrage les deux cartes soient détectées et fonctionnent. Assurez vous que vous avez spécifiez les bons modules/pilotes du noyau, et que lorsque vous exécutez ifconfig, vous voyez apparaître les interfaces eth0 et eth1 (ou bien vérifiez qu'elles sont configurées lors du démarrage de la machine). Vous serez alors prêt pour la suite. Il est aussi possible de compiler le noyau en incluant les pilotes des cartes réseaux (comme c'etait souvent fait dans le passé) mais il est courant et parfaitement acceptable de utiliser tout simplement des pilotes sous forme de modules comme nous le suggérons ici.

Vérifiez que votre fichier /etc/sysconfig/network ressemble à ça et remplacez /etc/hosts par votre propre version de ce fichier. Le fichier /etc/hosts n'est absolument pas nécessaire puisque nous allons installer un serveur de nom, mais c'est une bonne sauvegarde.

NOTE SUR LES DEUX CARTES RESEAU 3c509 :

Connectez et configurez les deux cartes ethernet ISA avant d'installer la distribution RedHat de Linux. Les deux cartes ethernet que Mark utilisait (il y a longtemps) étaient des 3com 3c509. La première avait comme valeurs de configuration irq=10 et address=300, et la seconde, les valeurs irq=11 et address=310. Aussi, quand vous installez la RedHat, installez la pour un LAN et procédez à une auto-détection des cartes ethernet.

NOTE SUR LE DHCP :

Vous pouvez configurer le DHCP à partir du panneau de configuration de RedHat, netconf, en éditant les fichiers manuellement ou bien pendant l'installation de la RedHat (ou tout autre distribution Linux que vous utilisez).

Configuration de IPChains et du Masquerading

Essayez d'interroger quelques serveurs à l'extérieur ou consultez quelques pages web avec lynx pour voir si votre connexion RoadRunner fonctionne. Si c'est bon, vous êtes prêt pour configurer le masquerading. Ajoutez cette partie concernant modprobe et les commandes d'ipchains à votre script /etc/rc.d/rc.local pour activer le forwarding/masquerading et aussi fournir des règles de pare-feu suffisamment efficaces.

Configuration du DNS pour le réseau privé

A présent, pump (qui récupère les informations du DHCP) configure le fichier /etc/resolv.conf pour pouvoir utiliser les DNS de RoadRunner. Cela n'apporte aucune fonctionalité permettant de connaître les noms des machines de votre réseau privé. Il serait donc nécessaire que chaque station de travail possède une copie du fichier /etc/hosts et que vous le configuriez manuellement afin d'utiliser un serveur de noms de RoadRunner. Comme ce n'est pas très propre, il est conseillé de faire tourner votre propre service DNS.

Equipé des connaissances que renferme l'HOWTO sur les DNS, créez et modifiez les fichiers /etc/named.conf, /etc/resolv.conv ainsi que les fichiers se trouvant dans le répertoire /var/named. Vous devez ausi créer ou éditer le fichier /etc/pump.conf pour empêcher pump d'écraser la configuration de votre fichier /etc/resolv.conf à chaque fois que vous lancez l'interface eth0. Vérifiez que le démon named est lancé au démarrage (il y aura un lien S??named dans le répertoire /etc/rc.d/c3.d/). Après le redémarrage, un serveur de nom avec cache, ainsi qu'un DNS pour votre réseau privé, devraient être lancés.

Configuration des stations de travail

Assurez-vous que les machines de votre réseau privé (ainsi que la passerelle) sont connectées entre elles via un hub et un câble Cat5. Vous pouvez alors configurer les stations de travail. Assignez à chaque machine/interface une adresse IP unique dans le bloc d'adresses privées. Voici un exemple de fichier /etc/sysconfig/network pour des stations de travail Linux. Ajoutez un fichier /etc/hosts que vous aurez personnalisé en fonction de votre réseau, et ce fichier /etc/resolv.conf. Maintenant ça devrait être bon. Essayez d'interroger quelques machines avec ping ou bien de lire quelques pages web sur un station de travail afin de vous assurez que le masquerading et le DNS fonctionne correctement.

Voici un exemple pour les autres machines de votre réseau.

  1. adresse IP = 10.0.0.10

  2. adresse de nom = w1.local

  3. masque de sous-réseau = 255.255.255.0

  4. le fichier /etc/resolv.conf pour vos machines Linux

  5. le fichier /etc/hosts que j'utilise mais dont vous n'aurez pas besoin. Juste au cas où le DNS tombe en panne, ce sera pratique pour restaurer le système.

La seule chose que vous devez changer sur chaque machine supplémentaire est son adresse IP et son adresse de nom. w2.local et 10.0.0.20 correspondra à la prochaine machine. Vous avez compris l'idée ?

Aussi, si vous avez des clients PC, Mac ou d'autres types de machines, consultez le mini-HOWTO sur le masquerading.

L'idée générale est de spécifier la machine qui réalise le masquerading (10.0.0.1) comme la passerelle et le serveur DNS pour chaque machine. Vous trouverez dans l'HOWTO IP-Masquerading, une section très bien faite qui propose la configuration des stations de travail d'un réseau privé, dont le système d'exploitation n'est pas Linux.

Du coté de la sécurité

Etre connecté continuellement à l'Internet comporte des risques. Il y a beaucoup de monde à l'extérieur qui n'ont rien de mieux à faire que de détruire le système non protégé. Et encore plus qui aimeraient utiliser votre système comme point de départ à des activités illégales.

Le masquerading est intrinsèquement quelque chose de dangereux puisque nous devons laisser passer le trafic à travers le pare-feu. En désactivant les démons qui écoutent les ports de votre passerelle, comme le telnet et le ftp, vous pouvez écarter la plupart du danger. Bien comprendre les chaînes pare-feu IP est aussi une aide précieuse. Une redirection de port comme ipportfw peut aussi être utilisée pour rediriger les requêtes de connexions en entrée, vers d'autres machines de votre réseau (sur lequelles le service demandé fonctionnera), écartant ainsi le danger loin de votre passerelle.

Vous pouvez empêcher l'accès à votre serveur DNS en le déplaçant sur une autre machine de votre réseau ou simplement en donnant à named une directive d'écoute appropriée (consultez la page de manuel named.conf) afin d'éviter la liaison avec un port sur votre interface externe. Si vous désirez une sécurité encore plus importante mais que vous avez besoin du login depuis l'extérieur, regardez openssh, qui permet des logins de type telnet sur une connexion cryptée. Il est aussi conseillé d'installer un enregistreur de session avancé tel que tcplogd qui pourra détecter et vous informer de la plupart des scans de port et des activités malveillantes.

Enfin, dans de nombreux cas, vous pouvez simplement couper la connexion vers l'extérieur lorsque vous ne l'utilisez pas. De cette manière, vous réduisez le risque que quelqu'un parvienne à obtenir un accès non-autorisé. Vous n'avez qu'à faire ifdown eth0 (ifconfig eth0 down sur toutes les distributions — NdT) sur votre passerelle pour désactiver votre connexion et ifup eth0 (ifconfig eth0 up sur toutes les distributions — NdT) quand vous avez besoin de l'utiliser à nouveau.

Résumé sur la sécurité

  1. Le seul service que devrait offrir votre firewall est openssh. Idéalement, vous ne devriez pas placer le DNS sur votre passerelle. Bien que dans la configuration de notre serveur, le DNS soit dessus, encore une fois vous devriez mettre le service du DNS sur une autre machine à l'intérieur du réseau. Si vous décidez de la laisser, mettez le sur le pare-feu pour qu'au moins l'extérieur ne puisse l'utiliser ;

  2. Tous les autres services (comme le serveur Web) que vous désirez laisser accessibles de l'extérieur devraient être des redirections de port, en utilisant ipportfw, vers d'autres machines à l'intérieur de votre réseau.

  3. NE LAISSEZ AUCUN service être activé sous /etc/inet.conf, ou plus simplement ne laissez pas tourner inet.

Pour ceux qui utilisent RedHat :

  1. chkconfig inet off

  2. /etc/rc.d/init.d/inet stop

  3. Installez les services internes sur une machine différente (impression, partage de fichiers, base de données, etc.)

  4. Installez tcplogd et envoyez un mail à ceux qui scanne votre machine — « eh, ce sont des informations publiques, non ? »

  5. Il existe plusieurs manières de cacher les communications de VNC, mail, ftp et d'autres programmes à travers OpenSSH. Ça peut sécuriser un peu plus les choses.

  6. Consultez le projet Abacus — le système de prévention des intrusions (The Intrusion Prevention System).

Un DNS dynamique

A moins que vous demandiez une adresse IP fixe, RoadRunner vous donne une adresse IP différente à chaque fois que vous vous connectez. Le DNS dynamique vous assigne un alias qui vous permet alors d'accéder à votre machine lorsque vous êtes au bureau ou de permettre à d'autres personnes de savoir où vous êtes.

Dyndns.org peut vous fournir un nom de domaine statique malgré votre adresse IP dynamique, donnant un nom constant à votre passerelle et, pour ceux qui sont sur l'Internet, un moyen facile de se le rappeler. Une fois que vous vous êtes enregistré avec dyndns, un utilitaire appelé ddup contacte dyndns.org et met à jour l'enregistrement de votre serveur de noms quand votre adresse IP change. Ajoutez ce fragment de script shell à votre /etc/rc.d/rc.local pour mettre à jour, au démarrage, votre enregistrement sur dyndns, mais uniquement si votre adresse IP a changé (dyndns n'apprécie pas que vous changiez votre enregistrement pour n'importe quelle raison). Cela suppose que vous ayez installé ddup proprement.

J'ai tendance à redémarrer la passerelle tous les jours ou tous les deux jours. Je n'ai eu aucun problème avec le changement de l'IP assignée tant que la machine était allumée, bien que ce soit techniquement possible. Si vous avez l'intention de laisser votre passerelle fonctionner pendant plusieurs semaines de suite, il serait préférable que vous ajoutiez une entrée dans le cron qui exécute ce script de temps en temps afin d'être sûr que vous enregistrement chez dynsdns est toujours le même. Cela demandera un peu de travail supplémentaire. Faites l'expérience et voyez ce qui vous semble le mieux.

Commentaires

  1. Pour encore plus de sécurité, vous pouvez acheter un répartiteur (switch) avec lequel vous pourrez vous isoler du trafic à l'intérieur de votre réseau. Ils sont chers mais ça vaut le coup si vous êtes vraiment souvent connecté au réseau ;

  2. Vous pouvez faire des choses encore plus complexes une fois que vous avez configuré votre réseau interne. Vous pouvez utilisé fetchmail pour récupérer tout le courrier d'un domaine et faire correspondre les adresses électroniques avec vos utilisateurs locaux, utiliser un serveur proxy pour économiser de la bande passante (ça peut ne pas être nécessaire, configurez les connexions cryptées des services du Réseau Privé Virtuel (VPN)) à l'aide de openssh, etc.

Fichiers d'exemples

(Ce sont simplement des exemples syntaxiques, vous devrez probablement modifier les noms de domaines, etc, pour votre propre usage.)

(NdT : les commentaires ont été traduits pour une meilleure compréhension des opérations réalisées et pour faire le rapprochement avec le texte. Vous pouvez toujours utiliser les scripts en anglais fournis dans l'article original).

/etc/rc.d/rc.local (passerelle)

# Configuration du pare-feu - ce devra être ajouté à la fin du fichier
# /etc/rc.d/rc.local afin d'être lancé au démarrage.
# Adapté à partir des exemples fournis dans l'HowTo IP Masquerading et
# l'HowTo IPChains. Consultez les documents originaux pour en savoir 
# plus. Ces exemples vous permettront de configurer un pare-feu 
# "masqueradé" suffisamment sécurisé.

echo "Chargement des modules pour l'IP masquerading ..."
# chargement des modules afin de manipuler des protocoles parfois 
# difficiles mais courants, à l'aide du masquerading
/sbin/depmod -a
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_raudio
/sbin/modprobe ip_masq_irc

echo "Activation de l'IP forwarding ..."
# S'assure que la redirection est activée
echo "1" > /proc/sys/net/ipv4/ip_forward

# Récupère l'adresse IP dynamique assignée par le DHCP, ainsi que le 
# nom de l'interface externe, puis les sauve dans des variables faciles
# à utiliser.
extip="`/sbin/ifconfig eth0 | grep 'inet addr' | awk '{print $2}' | sed -e 's/.*://'`"
extint="eth0"

# Fait la même chose pour le nom de réseau interne et l'interface
intint="eth1"
intnet="10.0.0.0/8"

echo "Configuration des chaines pare-feu :"
echo -n "en entree ..."
#############################################################################
# Chaîne d'entrée : remise à zéro et installation de la politique de rejet
# par défaut. En fait, la politique par défaut n'est pas pertinente
# car il y a une règle globale de refus et de signalement

ipchains -F input
ipchains -P input REJECT

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

# interface distante, machines soient disantes locales et masquage d'IP
# (IP spoofing), rejetés
ipchains -A input -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT

# interface distante, renvoi de tout ce qui essaie d'ouvrir une
# connexion avec nous. Ceci empêche quiconque d'ouvrir des connexions
# TCP avec cette machines à partir de l'extérieur. Il s'agit juste
# d'un exemple de ce que nous pouvons faire avec IPChains. Ce
# n'est pas une mauvaise idée à moins que vous ayez une raison de
# laisser les gens se connecter à votre pare-feu.
# ipchains -A input ! -f -i $extint -p TCP -y -j REJECT

# interface distante, toute source, allant à l'adresse du dhcp de
# roadrunner acceptées
ipchains -A input -i $extint -s 0.0.0.0/0 -d $extip/32 -j ACCEPT

# l'interface loopback est autorisée
ipchains -A input -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT

# règle globale, toutes les autres entrées sont refusées et signalées
ipchains -A input -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT

echo -n "en sortie ..."
#############################################################################
# Chaîne de sortie : remise à zéro et installation de la politique de
# rejet par défaut. En fait, la politique par défaut n'est pas
# pertinente car il y a une règle globale de refus et de signalement

ipchains -F output
ipchains -P output REJECT

# interface locale, toute source allant sur le réseau local est
# acceptée
ipchains -A output -i $intint -s 0.0.0.0/0 -d $intnet -j ACCEPT

# sortie vers le réseau local sur l'interface distante, routage
# engorgé refusée
ipchains -A output -i $extint -s 0.0.0.0/0 -d $intnet -l -j REJECT

# sortie du réseau local sur l'interface distante,  masquerading
# engorgé refusé
ipchains -A output -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT

# toutes les autres sorties allant sur l'interface distante sont
# valides
ipchains -A output -i $extint -s $extip/32 -d 0.0.0.0/0 -j ACCEPT

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

# règle globale, toutes les autres sorties sont refusées et signalées
ipchains -A output -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT

echo -n "redirection ..."
#############################################################################

# Chaîne de redirection : remise à zéro et installation de la politique de
# rejet par défaut. En fait, la politique par défaut n'est pas
# pertinente car il y a une règle globale de refus et de signalement
#
ipchains -F forward
ipchains -P forward DENY

# Masquerade sur le réseau local sur l'interface locale vers n'importe
# où. C'est cette ligne qui fait tout le travail, quasiment tout le
# reste dans les lignes de ce fichier ne sont là uniquement pour des raisons
# de sécurité.
ipchains -A forward -i $extint -s $intnet -d 0.0.0.0/0 -j MASQ

# règle globale, toutes les autres redirections sont refusées et
# signalées. Dommage qu'il n'y ait pas d'option de signalement dans la
# politique de rejet mais elle fait le travail à la place.
ipchains -A forward -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT

echo "Terminé."

/etc/sysconfig/network (passerelle)

NETWORKING="yes"
FORWARD_IPV4="yes"
HOSTNAME="main.local"
DOMAINNAME="local"
GATEWAY="10.0.0.1"
GATEWAYDEV="eth0"

/etc/sysconfig/network (stations de travail)

NETWORKING="yes"
FORWARD_IPV4="no"
# changez le nom de chaque machine
HOSTNAME="w1.local"
DOMAINNAME="local"
GATEWAY="10.0.0.1"
GATEWAYDEV="eth0"

/etc/hosts (passerelle et stations de travail)

127.0.0.1       localhost       localhost.localdomain
10.0.0.1        main            main.local
10.0.0.10       w1              w1.local
10.0.0.20       w2              w2.local
10.0.0.30       w3              w3.local

/etc/resolv.conf (passerelle et stations de travail)

search local columbus.rr.com
nameserver 10.0.0.1             # votre serveur de nom local
nameserver 128.146.1.7          # joue le rôle de serveur de
                                # sauvegarde. N'utiliser celui-ci,
# c'est uniquement pour les étudiants de
# l'OSU.

/etc/pump.conf (sur la passerelle seulement)

device  eth0 {  
        nodns 
        }

/etc/named.conf (sur la passerelle seulement)


options {
        directory "/var/named";
};
zone "." {
        type hint;
        file "named.ca";
};
zone "local"{
        type master;
        file "local.zone";
        notify no;
};
zone "0.0.10.in-addr.arpa"{
        type master;
        file "local.reverse";
        notify no;
};
zone "0.0.127.in-addr.arpa"{
        type master;
        file "named.local";
};

/var/named/local.zone (sur la passerelle seulement)

@               IN      SOA     main.local.     root.main.local. (
                                200001151 ; serial
                                8 ; refresh
                                2 ; retry
                                1 ; expire
                                1 ; default_ttl
                                )
@               IN      NS      main.local.
localhost       IN      A       127.0.0.1
main            IN      A       10.0.0.1
w1              IN      A       10.0.0.10
w2              IN      A       10.0.0.20
w3              IN      A       10.0.0.30

/var/named/local.reverse (sur la passerelle seulement)

0.0.10.in-addr.arpa.    IN      SOA     main.local. root.main.local. (
                                        1997022700 ; serial
                                        28800 ; refresh
                                        14400 ; retry
                                        3600000 ; expire
                                        86400 ; default_ttl
                                        )
1.0.0.10.in-addr.arpa.  IN      PTR     main.local.
10.0.0.10.in-addr.arpa. IN      PTR     w1.local.
20.0.0.10.in-addr.arpa. IN      PTR     w2.local.       
30.0.0.10.in-addr.apra. IN      PTR     w3.local.

A ajouter au fichier /etc/rc.d/rc.local (support dynsdns avec ddup)

# Mise à jour l'entrée sur dyndns.org avec une ruse contre l'abus.
# Cela ne fonctionne pas à moins vous ayez un compte sur dyndns et que
# le ddup soit installé. Il faut que certaines variables soient
# initialisées dans le script de configuration du pare-feu. Ce doit
# être ajouté à la fin du script du pare-feu.

# remplacez dummy.hostname par le nom de la machine que vous avez
# enregistré.
reghost="dummy.hostname" 
regip="`nslookup $reghost main.dyndns.org | tail -n 3 | grep 'ddress' | awk '{print $2}'`"

echo -e "\n Vérification de l'adresse IP  sur Dyndns.org pour prévenir les abus :"
echo "$reghost enregistrée : $regip"
echo -e "$extint a l'adresse IP : $extip \n"

if [ "$regip" = "$extip" ]; then
        echo "L'adresse n'a pas changé. DDUP ne fonctionne pas."; 
        else
        echo "L'adresse a changé. Mise à jour de votre enregistrement.";
        ddup --host $reghost;
fi

/etc/conf.modules (sur la passerelle ; seules les lignes « alias ethx » nous concernent)

alias eth0 3c509
alias parport_lowlevel parport_pc
pre-install pcmcia_core /etc/rc.d/init.d/pcmcia start
alias eth1 tulip

À propos de l'auteur

Mark Nielsen

Mark Nielsen travaille comme relieur chez ZING et TCU. Andrew est un consultant Linux.

Adaptation française de la Gazette Linux

L'adaptation française de ce document a été réalisée dans le cadre du Projet de traduction de la Gazette Linux.

Vous pourrez lire d'autres articles traduits et en apprendre plus sur ce projet en visitant notre site : http://www.traduc.org/Gazette_Linux.

Si vous souhaitez apporter votre contribution, n'hésitez pas à nous rejoindre, nous serons heureux de vous accueillir.