Par Mark Nielsen zing@tcu-inc.com et Andrew Byrd byrd.74@osu.edu
Résumé
Cet article est destiné à vous aider dans l'installation d'un réseau TCP/IP privé "masqueradé", connecté à Internet grâce au service modem câble 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), de nombreuses choses ont changées. C'est une tâche ardue en ce qui concerne le réseau, qui fait appel à 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 précision cependant: j'ai appelé Roadrunner et ils étaient plutôt vague quant au fait d'autoriser les gens à faire appel à l'IP-Masquerading. Les commerciaux disaient simplement que cela les dérangerait si vous monopolisiez la bande passante.
Il y a deux "Je" dans ce document. Parfois, c'est Andrew qui parle, d'autres fois c'est Mark.
Les HOWTOs suivants 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.
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 mais cela devrait convenir pour la plupart des gens.
Les stations de travail sont nommées de w1.local (10.0.0.10) à w3.local (10.0.0.30) et la passerelle masqueradée s'appelle main.local (10.0.0.1 sur le réseau privé). Comme précédemment, vous pouvez modifier ou étendre ce schéma si vous êtes à l'aise.
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 n'est particulièrement gourmand. 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. De nos jours, les cartes ethernet ne sont plus très chères et en avoir en version PCI vous évitera des maux de tête pendant la phase de configuration. J'ai utilisé des cartes Netgear FA310TX sur plusieurs machines sans rencontrer de problèmes. 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 beaucoup utilisées) 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 vieille pour votre passerelle, vous n'aurez peut-être que des slots ISA. Il faudra alors utiliser deux cartes ethernet ISA. Dans ce cas, il vous faudra récupérer 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.
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 avez 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, 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 configurer et démarrer 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équat et indiquez lui d'utiliser DHCP pour obtenir son adresse IP. N'en spécifiez pas: le service RoadRunner vous en assignera 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écifié 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'était souvent fait dans le passé) mais il est courant et parfaitement acceptable d'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 noms mais cela fait une bonne sauvegarde.
NOTE SUR LES DEUX CARTES RESEAU 3c509 :
Connectez et configurez les deux cartes ethernet ISA avant d'installer la distribution Linux RedHat. 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, avec netconf, en éditant les fichiers manuellement ou bien pendant l'installation de la RedHat (ou tout autre distribution Linux que vous utilisez).
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.
Pour le moment, 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 le 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 aussi 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 doit y avoir 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.
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 ainsi que 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 fonctionnent correctement.
Voici un exemple pour les autres machines de votre réseau.
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.
Être connecté continuellement à l'Internet comporte des risques. Il y a beaucoup de personnes à l'extérieur qui n'ont rien de mieux à faire que de s'attquer aux systèmes non protégés. Il y en a même et encore plus qui aimeraient utiliser votre système comme point de départ pour des activités illégales.
Le masquerading est intrinsèquement quelque chose de dangereux puisqu'il nécessite de laisser passer le trafic à travers le pare-feu. En désactivant les démons qui écoutent sur les ports de votre passerelle, comme le telnet et le ftp, vous pouvez écarter le plus gros 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 ports 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 (NdT: ifconfig eth0 down sur toutes les distributions) sur votre passerelle pour désactiver votre connexion et ifup eth0 (NdT: ifconfig eth0 up sur toutes les distributions) quand vous avez besoin de l'utiliser à nouveau.
A moins que vous n'ayez demandé 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 pour habitude de 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 additionnel. Essayez et voyez ce que vous pouvez faire.
Mark Nielsen travaille comme relieur chez ZING et TCU. Andrew est un consultant Linux.
(Ce sont juste des exemples de syntaxe, 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).
# Configuration du pare-feu - ceci 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 le HowTo IP Masquerading et
# le 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 à l'aide du masquerading
# des protocoles parfois délicats de mise en oeuvre mais courants
/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 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, 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 se prétendant 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 du 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 n'est là que 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é."
NETWORKING="yes" FORWARD_IPV4="yes" HOSTNAME="main.local" DOMAINNAME="local" GATEWAY="10.0.0.1" GATEWAYDEV="eth0"
NETWORKING="yes" FORWARD_IPV4="no" # changez le nom de chaque machine HOSTNAME="w1.local" DOMAINNAME="local" GATEWAY="10.0.0.1" GATEWAYDEV="eth0"
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
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. Ne pas utiliser celui-ci,
# c'est uniquement pour les étudiants de
# l'OSU.
device eth0 {
nodns
}
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";
};
@ 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
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.
# Met à jour l'entrée sur dyndns.org avec une ruse contre l'abus.
# Cela ne fonctionne pas à moins vous n'ayez un compte sur dyndns et que
# le paquetage ddup soit installé. Il faut que certaines variables soient
# initialisées dans le script de configuration du pare-feu. Ceci doit donc
# ê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ée. DDUP non lancé.";
else
echo "L'adresse a changée. Mise à jour de votre enregistrement.";
ddup --host $reghost;
fi
alias eth0 3c509 alias parport_lowlevel parport_pc pre-install pcmcia_core /etc/rc.d/init.d/pcmcia start alias eth1 tulip
Copyright 2000, Mark Nielsen et Andrew Byrd. Paru dans le numéro 51 de la Linux Gazette de Mars 2000.
Traduction française de Thierry Hamon.