v1.3, 13 février 1999, publié dans le Numéro 38 de la Linux Gazette
Par Josh Gentry
Mars 1999
Ce document est un guide pas à pas de la configuration d'un serveur d'accès sous Linux qui autorise des connexions SLIP et PPP sur une ligne téléphonique.
Copyright 1999 Josh Gentry
La redistribution de ce document est encouragée, qu'elle soit commerciale ou non commerciale. Je souhaiterais être averti de toute redistribution. Il ne vous est PAS permis de modifier le contenu de ce document bien que je n'ai que faire des changements de présentation.
Pour la plus grande part, les informations contenues dans ce document ont été glanées dans les HOWTO suivants du LDP (Linux Documentation Project) :
Beaucoup d'informations ont été trouvées dans la documentation en ligne de Gert Doering pour mgetty+sendfax. De plus, les documents ont été d'une grande aide dans la configuration d'AutoPPP dans mgetty :
La plupart des informations sur PAP ont été tirées du Guide des Administrateurs Réseaux sous Linux (NAG) d'Olaf Kirch's et la base de données de support de S.u.S.E. ( http://wi-pc44.fh-konstanz.de/support-db/sdb_e/kfr_17.html).
La majorité des informations de ce document a été originellement rassemblée dans l'optique de configuration d'un serveur par connexion téléphonique sous un Linux RedHat 5.1 pour Mr. James Hart. Mr. James Hart est un professeur au Technical/Vocational Institute d'Albuquerque, NM. Tony Lucero a été mon assistant pour ce projet. Leur aide et leurs conseils ont été d'un grand prix.
Pour finir, merci à tous ceux qui ont contribué au développement du noyau Linux et d'applications Linux. Ce document est ma modeste contribution à leurs efforts.
Ce document ne comporte pas de garantie explicite ou implicite. Il n'y a également aucune garantie que les informations contenues dans ce document sont fiables. Il est offert dans l'espoir de pouvoir être utile aux autres mais son utilisation est à vos risques et périls. L'auteur ne saurait être tenu responsable de quelque dommage que ce soit qui résulterait de l'utilisation de ce document.
Un serveur de connexion par ligne téléphonique est un hôte équipé d'un modem et d'une ligne téléphonique qui permet à d'autres hôtes équipés eux aussi d'un modem et d'une ligne téléphonique de l'appeler et de s'y connecter. Il existe plusieurs raisons pour lesquelles quelqu'un voudrait faire cela; pour utiliser les ressources du serveur ou, si le serveur est sur un réseau, pour employer le serveur comme point de connexion au réseau. De plus, si le réseau local est connecté à Internet, le client sera alors en mesure d'accéder à Internet via le serveur.
La majorité des informations nécessaires pour la configuration d'un serveur de connexion par ligne téléphonique sous Linux est disponible via les HOWTOs du LDP. Cependant, quand j'ai consulté ces documents pour configurer un tel serveur, la fragmentation des informations s'est trouvée être un problème majeur. Ce document rassemble la plupart des informations nécessaires et les présente sous la forme d'un guide pas à pas.
Configurer un serveur de connexion par ligne téléphonique est une tâche courante mais pas simple de mise en oeuvre. Ce document tend à présenter de manière rigoureuse sous forme de guide les étapes à suivre pour y arriver. Il est cependant probable que vous aurez à faire appel à d'autres documents. Les HOWTOs du LDP mentionnés ci-dessus sont des compagnons de valeur de ce document et devraient être consultés dans l'ordre indiqué ci-dessus. Par ailleurs, ne négligez pas la documentation fournie avec vos paquetages getty et PPP.
Les protocoles utilisés pour connecter deux hôtes via une ligne téléphonique sont techniquement des protocoles point à point; il n'y a aucune différence réelle entre la machine appelante et la machine appelée. Cependant, conceptuellement parlant, il est plus simple de penser en termes de client/serveur. "Quand vous composez le numéro d'un site pour établir une connexion PPP, vous êtes un client. La machine à laquelle vous vous connectez est le serveur." ( Linux PPP HOWTO de Hart). J'utiliserai cette convention tout au long de ce document.
Configurer un serveur par connexion téléphonique consiste en :
Mon expérience se base sur la RedHat Linux 5.1. Je pense que la plupart des informations contenues dans ce document s'appliquera à toutes les distributions. Lorsque j'ai connaissance ou je suspecte l'existence de différences entre les distributions, je le mentionne dans le texte.
Pour qu'un hôte puisse faire office de serveur de connexion par ligne téléphonique, il doit être physiquement possible de lui téléphoner. Ceci nécessite que l'hôte ait au moins un modem et une ligne téléphonique. Les modems sont des périphériques série, il est donc vivement recommandé de lire le Serial HOWTO Linux ainsi que le Modem HOWTO Linux.
Les modems Plug-and-Play ne sont pas très bien supportés par Linux. Ceci signifie qu'il vous faut plutôt un modem configurable par jumper ou un modem externe. Commencez par demander à votre revendeur quelle marque il vous recommande.
Les ports série, comme tous les ports d'E/S, ont une adresse. Par défaut, Linux initialise quatre périphériques série. Ils peuvent vous être familiers sous la dénomination que leur donne Microsoft : COM 1-4. Sous Linux, ces ports sont référencés comme ttyS0-ttyS3. Par exemple, le port COM1 pour Microsoft sera ttyS0 sous Linux.
Veuillez noter que si vous utilisez une adresse de port différente des quatre
mentionnées plus haut, vous devrez initialiser ce port avec
setserial. Voir la page de manuel de setserial.
Les modems externes se branchent sur les ports série externes (RS-232) de votre PC. Ces ports reçoivent automatiquement une adresse sous Linux.
Les modems internes se connectent sur les ports internes PCI ou ISA de votre PC. Un modem interne est en fait à la fois un modem et un port série. Il en intègre un et c'est le port série de votre modem que vous connectez sur le port interne. Pour ces modems, vous choisissez l'adresse du port sur le modem. C'est pourquoi il vous faut un modem configurable par jumper. Vous utilisez les jumpers pour choisir manuellement l'adresse et l'IRQ. La documentation de votre modem devrait expliquer comment régler les jumpers en fonction de l'adresse du port et de l'IRQ.
Veuillez noter que si votre PC dispose de deux ports série externes (RS-232) comme c'est le cas pour la plupart des PC, le Modem HOW-TO Linux vous recommande de prendre comme adresse de votre modem interne ttyS2 ou plus.
Vous entrez dans la partie de la configuration qui est la plus susceptible de faire peur aux nouveaux venus à Linux. Cela m'a fait peur. Ceci dit, ce n'est pas aussi dur que cela semble être et si vous faites une erreur, il vous suffit de recompiler une nouvelle fois votre noyau. Je vous recommande de lire le Linux Kernel HOWTO.
Il existe une alternative à la compilation du gestionnaire PPP dans le noyau. Vous pouvez installer le gestionnaire en tant que module chargeable. Les avantages consistent en l'absence de recompilation et en la taille inférieure du noyau Linux. Le gestionnaire est lié au noyau et chargé dans l'espace mémoire seulement quand il le faut. Je pense que l'argument qui peut faire préférer la compilation du gestionnaire dans le noyau est que PPP s'exécute plus vite s'il est compilé dans le noyau.
Vous pouvez lier le module chargeable au noyau en recompilant le noyau comme
décrit ci-dessous mais, comme Matt Kressel me l'a fait remarquer, si vous avez
ma commande insmod installée sur votre système, il n'est pas nécessaier
d'effectuer la recompilation. Exécutez la commande insmod ppp pour
installer le gestionnaire PPP sous forme de module chargeable. J'ai découvert
qu'il me fallait exécuter la commande insmod slhc avant de pouvoir
installer le PPP avec la commande insmod ppp . Je ne sais pas trop
pourquoi mais insmod ppp ne fonctionnera pas sans le module slhc. La
commande lsmod liste les modules chargeables installés sur le système au
moment de son appel. C'est également une commande pour retirer des modules. Si
ces commandes sont installées sur votre système, il serait bon que vous lisiez
les pages de manuel. Faites un man insmod pour plus d'information.
Le noyau est un binaire, un programme exécutable. Les développeurs n'écrivent pas le noyau comme un exécutable, ils écrivent du code qui est donné à un compilateur qui produit alors l'exécutable à partir du code source.
Avec Linux, vous disposez du code source qui est utilisé pour produire le noyau exécutable. Ceci signifie que vous pouvez adapter votre noyau à vos besoins en incluant seulement les fonctionnalités qu'il vous faut : le résultat sera un noyau plus juste et plus petit. De ce fait, vous ne pouvez considérer qu'un noyau inclut le support de tâches spécialisées telles que celles que requiert le fonctionnement en réseau. Il va vous falloir le vérifier et, si votre noyau ne contient pas le support nécessaire, il va vous falloir recompiler votre noyau.
Pour compiler le noyau, vous créez un fichier de configuration. Vous pouvez consulter le fichier de configuration actuel pour voir si les fonctionnalités nécessaires sont déjà compilées dans votre noyau. La plupart des serveurs de connexion par ligne téléphonique seront des hôtes sur un réseau local. Ce document assume que l'hôte est déjà configuré comme une partie intégrante du réseau local. Si ce n'est pas le cas, vous devriez aller chercher des informations dans d'autres documents du LDP avant de continuer, le Guide des Administrateurs Réseaux sous Linux par exemple.
Je préfère utiliser xconfig. C'est un outil graphique qui permet la
visualisation et la modification du fichier de configuration du noyau. Il
nécessite qu'X Window soit installé et lancé. Par ailleurs, Tk doit aussi être
installé. Dans xconfig, vous trouverez les options concernant le support
de PPP et SLIP dans la catégorie Périphériques réseau ("Network devices").
Ceux-ci doivent être supportés par un serveur de connexion par ligne
téléphonique. Si le serveur doit assurer un accès à un réseau, le noyau doit
fournir le support pour la transmission IP. Dans xconfig, on trouve cette
fonctionnalité dans la catégorie Options réseau ("Network options").
Si vous devez recompiler le noyau, il est grandement recommandé de lire le Kernel HOWTO Linux. Voici les étapes de base :
cd /usr/src/linux-(numéro de version du noyau)make config. Si vous êtes sous X-windows, vous
pouvez essayer make xconfig pour utiliser une interface à cliquer de ce
processus.make depmake cleanmake zImagecd /usr/src/linux-(numéro de version du noyau)/arch/i386/bootcp zImage /vmlinuz (où l'endroit où se trouve votre noyauliloCela devrait suffire. Le Kernel HOWTO Linux indique qu'il devrait vous être
possible d'exécuter la commande make zlilo après que vous ayez construit
le zImage et qu'en faisant cela, zlilo copiera et installera le
nouveau noyau pour vous. Cela n'a toutefois pas fonctionné sur mon système.
Vous aurez besoin d'un getty pour pouvoir gérer les communications par
modem. Une fois démarré, généralement à partir de inittab, le getty tourne
en tâche de fond. Votre getty modem sera en veille jusqu'à ce que le modem
reçoive un appel. À partir de ce moment, il va répondre au téléphone et
négocier les détails de la communication de modem à modem avec le client. Il
existe plusieurs getty qui peuvent être utilisés pour cette tâche. Vous pouvez
récupérer le paquetage mgetty+sendfax et la documentation officielle sur le
site web de Gert Doering à
http://www.leo.org/~doering/mgetty. C'était inclus dans la RedHat
5.1 et résidait dans /sbin/mgetty et /etc/mgetty+sendfax.
Veuillez noter que chaque fois que vous voyez quelque chose tel que
/sbin/mgetty, c'est simplement le chemin vers le fichier. Les fichiers
peuvent se situer à des emplacements différents dans l'arborescence de machines
différentes et selon la distribution. De plus, le chemin vers le fichier
devrait être différent. Vous devrez vérifier l'emplacement de tous les fichiers
nécessaires sur le système.
Il y a de nombreuses options à mgetty que vous pouvez éditer pour adapter
votre configuration, la plupart se situant dans
/etc/mgetty+sendfax/mgetty.config. Référez vous à la documentation de
mgetty si vous avez besoin d'effectuer des changements aux valeurs par
défaut. Les valeurs par défaut ont fonctionné pour nous. Si vous voulez activer
AutoPPP, vous devrez éditer /etc/mgetty+sendfax/login.config. Des
instructions détaillées à ce sujet apparaissent un peu plus loin dans cette
section.
Pour démarrer mgetty, éditez /etc/inittab. Encore une autre étape
pour laquelle les HOWTO sur les périphériques série et modem seront
utiles. Vous devez indiquer à mgetty quels ports série il doit
surveiller. Sous Linux, ces ports sont numérotés de 0 à 3 et sont dénommés
ttyS* pour la connexion par ligne téléphonique. Pour un modem installé par
nos soins sur le troisième port interne, nous avons ajouté cette ligne à
/etc/inittab :
S2:2345:respawn:/sbin/mgetty ttyS2 -D /dev/ttyS2
L'option -D dit à mgetty de n'attendre que des données, pas des
faxs. Après avoir effectué cette modification, exécutez la commande kill -1
1 pour forcer initd à relire inittab. Cela permettra que
mgetty se lance.
Veuillez noter que si vous utilisez une carte à port série multiple, ces ports
peuvent porter d'autres noms que ceux des 4 ports que Linux intialise par
défaut. Dans son excellent document sur mgetty et AutoPPP, Mick Dennis signale
que les ports sur sa Cyclade Cyclom 16YeP s'appellent /dev/ttyC*.
En utilisant les réglages par défaut, mgetty négocie une connexion SLIP
(Protocole Internet sur Ligne Série) et permet l'authentification par le biais
de /etc/passwd. C'est un système fonctionnel qui permet à un
utilisateur de se loguer sur un compte shell. Si vous le souhaitez, un
dispositif peut permettre aux utilisateurs de démarrer pppd après s'être
logué par le biais de la connexion SLIP. Tout d'abord, assurez vous que tous
les utiisateurs ont le droit d'exécuter pppd en exécuant la commande :
chmod u+s /usr/sbin/pppd
Ajoutez ensuite cette ligne à /etc/bashrc :
alias ppp="exec /usr/sbin/pppd -detach"
Par ce biais, après que l'utilisateur se soit logué par l'intermédiaire de la
connexion SLIP, ils peuvent démarrer pppd en tapant ppp. Cette
manière de procéder provient du PPP HOWTO Linux de Robert Hart. Une autre
option est de créer un compte PPP. L'entrée dans /etc/passwd devrait
être du type :
ppp:x:351:230:pppclient:/home/ppp:/usr/sbin/pppd
Quand un utilisateur se connecte, il se logue simplement en tant que
ppp. Une fois qu'ils ont donné un mot de passe, pppd démarre
automatiquement.
Pour que les clients Microsoft fonctionnent sous cette configuration, le client doit être configuré de manière à fournir un écran de terminal après la connexion. Cela n'est pas le comportement par défaut. Voici les étapes à franchir sous Windows 95 :
La plupart des utilisateurs de Windows n'apprécieront pas de devoir utiliser un
écran de login après la connexion au serveur. Il est possible pour
l'administrateur système de supprimer cette étape supplémentaire en tirant
parti de la possibilité qu'a mgetty de démarrer pppd à l'intialisation
d'une connexion. Pour ce faire, vous activez AutoPPP.
Note : plusieurs personnes m'ont signalé que quand ils décidaient d'installer mgetty à partir de leur distribution Redhat 5.2, mgetty était d'ores-et-déjà compilé de manière à inclure AutoPPP.
Pour qu'AutoPPP fonctionne, vous devez éditer le makefile avant la compilation. Aux environs de la ligne 110, il vous faudra indiquer :
CFLAGS=-02 -Wall -pipe -DAUTO_PPP
Après cette modification, compilez mgetty en suivant les instructions qui figurent dans la documentation de mgetty.
Ensuite, il vous faut éditer /etc/mgetty+sendfax/login.config de
manière à ce qu'il ressemble à cela aux alentours de la ligne 50 :
/AutoPPP/ - - /usr/sbin/pppd file /etc/ppp/options.server
Une fois que vous avez fini ces étapes de configuration, mgetty démarrera
automatiquement pppd quand il recevra la requête de configuration de
LCP. (Pour plus d'informations sur LCP, voyez la page de manuel de pppd.)
L'option file dit à pppd de lire le fichier
/etc/ppp/options.server à la place du fichier par défaut /etc/ppp/options. Compte tenu du fait que pppd utilise
/etc/ppp/options par défaut quand il agit en client ou en serveur
(souvenez vous que c'est du point-à-point), utiliser cette option vous aide à
conserver les options souhaitées séparées pour les rôles de client et de
serveur.
En considérant que vous avez édité /etc/mgetty+sendfax/mgetty.config
selon vos désirs, vous avez fini. Veuillez noter qu'à chaque fois que vous
changez les options pour un processus, le processus doit être redémarré avant
que les nouvelles options puissent prendre effet.
Si vous voulez être en mesure de composer un numéro avec un modem qui est contrôlé par mgetty, il vous faudra faire attention au périphérique que le programme de communication utilise. Voir http://www.leo.org/~doering/mgetty/mgetty_10.html#SEC10.
Le protocole Point-à-Point est le protocole le plus populaire utilisé pour la connexion d'hôtes par une ligne téléphonique.
pppd
Référez vous à la documentation du paquetage PPP. Si vous souhaitez utiliser les shadow passwords, il vous faudra utiliser la commande suivante :
make HAS_SHADOW=1
Pour utiliser l'option MS-DNS pour la compatibilité et les shadow, utilisez :
make USE_MS_DNS=1 HAS_SHADOW=1
Pour plus d'informations à ce sujet, référez vous à http://oh3tr.ele.tut.fi/~oh3fg/ppp/ppps.html.
pppd
Le PPP se configure en éditant les fichiers d'options lus par pppd dans
/etc/ppp. Rappelez-vous que dans cette configuration, pppd lira
/etc/ppp/options.server lorsqu'il sera démarré par mgetty. La liste
la plus complète des options de pppd que j'ai trouvée se trouve dans la page
de manuel de pppd. Si vous n'utilisez pas PAP ou CHAP, votre fichier /etc/ppp/options.server devrait être du genre :
-detach
asyncmap 0
modem
crtscts
lock
proxyarp
ms-dns aa.bb.cc.dd
ms-dns ee.ff.gg.hh
Sa signification est la suivante :
ne pas faire de fork pour devenir un processus en tâche de fond
pour permettre à pppd de fonctionner sur une connexion rlogin ou telnet
utiliser les lignes de contrôle du modem
utiliser le contrôle de flux matériel
spécifie que pppd utilise le verrouillage de style UUCP sur le périphérique série
ajoute une entrée dans la table ARP avec l'adresse IP du client et l'adresse IP du NIC
spécifie l'adresse du serveur DNS à utiliser par les clients
Microsoft (Autant que je sache, il n'existe pas d'option équivalente pour les
clients non-Microsoft. Un client Linux doit avoir l'adresse du DNS dans le
/etc/hosts.)
PAP (Protocole d'Authentification par Password) est l'un des deux protocoles que PPP utilise pour l'authentification des postes. L'autre protocole s'appelle CHAP (Challenge Handshake Authentication Protocol). CHAP est un protocole bien plus sécurisé mais n'est pas aussi supporté que PAP. Par là même, ce document ne traite que de l'utilisation de PAP. Pour plus d'informations sur PAP et CHAP, voyez le Guide de l'Administrateur Réseau sous Linux d'Olaf Kirch.
Compte tenu du fait que PPP est un protocole point à point, PAP autorise l'authentification dans les deux sens. Ceci signifie que non seulement le serveur peut demander au client de s'authentifier mais que l'inverse est également possible. Dans la pratique, on ne le fait pas souvent. La plupart des serveurs PPP ne sont pas configurés pour s'authentifier auprès de clients. authenticate themselves to clients.
Il n'est pas difficile de configurer votre serveur PPP pour l'utilisation de
PAP. Ajoutez simplement ce qui suit à votre fichier
/etc/ppp/options.server :
require-pap refuse-chap
Sous cette configuration, pppd vérifiera les logins et les mots de passe
des clients en se basant sur le fichier /etc/ppp/pap-secrets. Le
client ne verra sa connexion acceptée que dans le cas où il correspond à une
entrée de /etc/ppp/pap-secrets.
Par exemple :
#user server secret addrs jdoe * password *
Si les champs server et addres sont renseignés, le client ne se verra autoriser l'accès que si le login et le mot de passe proviennent du serveur et de l'adresse IP ou du nom de domaine pleinement qualifié indiqués.
/etc/password
Si vous ne voulez pas créer une entrée dans /etc/ppp/pap-secrets pour
chaque client auquel vous autorisez l'accès PPP, vous pouvez dire à pppd de
chercher les logins et les mots de passe dans /etc/passwd plutôt que
dans /etc/ppp/pap-secrets. Ajoutez l'option login dans /etc/ppp/options.server. Dans cette configuration, votre fichier
/etc/ppp/options.server ressemblera à cela :
-detach
asyncmap 0
modem
crtscts
lock
require-pap
refuse-chap
login
proxyarp
ms-dns aa.bb.cc.dd
ms-dns ee.ff.gg.hh
Si l'option login est utilisée, le fichier /etc/ppp/pap-secrets
n'a pas besoin d'exister. En fait, il peut même interférer avec le bon
fonctionnement de PAP. Vous pouvez effacer le fichier ou bien lui faire
contenir la ligne suivante :
* * ""
L'avantage de maintenir un /etc/ppp/pap-secrets qui comporte cette
ligne est que cela vous laisse le choix d'interdire l'accès PPP à des comptes
individuels qui possèdent une entrée dans /etc/passwd. Pour ce faire,
au-dessus de la ligne indiquée plus haut, mettez la ligne suivante :
username * -
où username est le nom d'utilisateur du compte auquel vous voulez interdire l'accès PPP. Par exemple :
#user server secret addrs * * "" * jdoe * - *
Pour que PPP fonctionne, le client doit avoir une adresse IP. La plupart des
clients de connexion n'auront pas leur propre adresse IP, il est donc
nécessaire d'assigner une adresse IP au port série à travers lequel le client
se connecte. Plut tôt, nous avons créé un fichier d'options PPP qui spécifie la
configuration des connexions PPP que fournit le serveur dans /etc/ppp/options.server. Il est également possible de créer un fichier
d'options qui soit spécifique aux connexions effectuées sur un port série
donné. Par exemple, pour créer un fichier pour ttyS2, vous créez ke
fichier /etc/ppp/options.ttyS2.
Une des options qui peut être mentionnée dans un tel fichier est l'adresse IP assigné au port pour les connexions PPP. Voici le format de cette option :
ii.jj.kk.ll:mm.nn.oo.pp
La première adresse IP, de gauche à droite, est l'adresse IP du serveur. La seconde adresse IP est l'adresse assignée au port série pour les connexions PPP.
Veuillez noter qu'il est extrêmement important pour vous de vérifier que l'adresse IP que vous assignez est une adresse IP valide sur votre sous-réseau et qu'elle n'est pas assignée à un autre périphérique sur le réseau.
Voilà, c'est fini.
Tout retour quant à ce document sera apprécié : contactez moi via mon email jgentry@swcp.com.
----------------------------------------------------------------
Copyright © 1998, Josh Gentry - Adaptation française de Pierre Tane
"Linux Gazette...making Linux just a little more fun!"