1588 lines
58 KiB
Text
1588 lines
58 KiB
Text
<!--
|
|
The FreeBSD Documentation Project
|
|
The FreeBSD French Documentation Project
|
|
|
|
$FreeBSD$
|
|
Original revision: n.nn
|
|
-->
|
|
|
|
|
|
<chapter id="network">
|
|
<title>Réseaux</title>
|
|
|
|
<sect1>
|
|
<title>Où puis-je trouver des informations sur le ``boot sans disque''? </title>
|
|
|
|
|
|
<para>
|
|
Le ``boot sans disque'' veut dire que la machine sous FreeBSD est bootée depuis le
|
|
réseau, et lit les fichiers nécessaires depuis un serveur et non depuis
|
|
son disque dur. Pour plus de détails, lisez <ulink url="../handbook/diskless.html"> la section du Handbook sur le Diskless booting </ulink>
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title> Une machine sous FreeBSD peut-elle être utilisée comme routeur dédié ? </title>
|
|
|
|
|
|
<para>
|
|
Les standards de l'Internet et de bonnes pratiques techniques nous
|
|
interdisent de faire par défaut du routage de paquets avec
|
|
FreeBSD. Mais vous pouvez néamoins activer cette fonctionnalité en
|
|
changeant la variable suivante à <emphasis remap="tt">YES</emphasis>
|
|
dans <ulink url="http://www.freebsd.org/cgi/man.cgi?rc.conf"> rc.conf</ulink>:
|
|
<programlisting>
|
|
gateway_enable=YES # L'hote agira comme routeur s'il est positionne a YES
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Cette option mettra la variable <ulink url="http://www.freebsd.org/cgi/man.cgi?sysctl">sysctl</ulink>
|
|
<emphasis remap="tt">net.inet.ip.forwarding</emphasis> à <emphasis remap="tt">1</emphasis>.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Dans la plupart des cas, vous aurez aussi à lancer un processus de routage
|
|
afin de renseigner les autres systèmes sur votre routeur.
|
|
FreeBSD est fourni avec le démon de routage standard BSD
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?routed" >routed</ulink>,
|
|
ou pour des situations plus complexes, vous pouvez essayer <emphasis remap="em">GaTeD</emphasis> (disponible par FTP depuis <emphasis remap="tt">ftp.gated.Merit.EDU) </emphasis>
|
|
qui supporte FreeBSD depuis 3_5Alpha7.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Nous nous devons de vous prévenir que lorsque FreeBSD est
|
|
configuré de cette manière, il ne correspond pas tout à fait
|
|
aux requis standards de l'Internet sur les routeurs. Néamoins,
|
|
il s'en rapproche assez pour un usage ordinaire.
|
|
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title> Puis-je connecter ma machine sous Win95 à l'Internet via FreeBSD ? </title>
|
|
|
|
|
|
<para>
|
|
Typiquement, les gens qui posent cette questions sont ceux qui ont 2 PC
|
|
à la maison, un avec FreeBSD et un avec Win95. L'idée est d'utiliser
|
|
la machine sous FreeBSD pour se connecter à l'Internet et puis
|
|
pouvoir ensuite accéder à l'Internet depuis la machine sous Windows 95
|
|
via la machine sous FreeBSD.
|
|
Ce n'est en réalité qu'un cas particulier de la question précédente.
|
|
</para>
|
|
|
|
<para>
|
|
Il y a un document très pratique qui explique comment configurer
|
|
FreeBSD comme <ulink url="http://www.ssimicro.com/~jeremyc/ppp.html" >routeur par connexion PPP</ulink>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis remap="bf">NOTE:</emphasis>
|
|
Cela requiert que vous ayez au moins deux adresses IP fixes, et
|
|
probablement 3 ou plus, cela dépend du travail que vous voulez effectuer
|
|
pour pouvoir mettre en place la machine sous Windows.
|
|
Comme alternative, si vous n'avez pas d'adresse IP fixe, vous pouvez
|
|
utiliser une des adresses IP privés et installer des <emphasis remap="bf">proxies</emphasis>
|
|
comme
|
|
<ulink url="http://squid.nlanr.net/Squid/">SQUID</ulink> et
|
|
<ulink url="http://www.tis.com/">le TIS firewall toolkit</ulink>
|
|
sur la machine sous FreeBSD.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Voir aussi la section sur
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?natd"> natd </ulink>.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title> Pourquoi la recompilation du dernier BIND de ISC échoue-t-elle ? </title>
|
|
|
|
|
|
<para>
|
|
Il y a un conflit entre le fichier ``<emphasis remap="tt">cdefs.h</emphasis>''
|
|
de la distribution et celui fourni par FreeBSD.
|
|
Vous n'avez qu'à enlever
|
|
<emphasis remap="tt">compat/include/sys/cdefs.h</emphasis>.
|
|
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>FreeBSD supporte-t-il SLIP et PPP?</title>
|
|
|
|
<para>
|
|
Oui, regardez les pages de manuel
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?slattach" >slattach</ulink>,
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?sliplogin">sliplogin</ulink>,
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?pppd">pppd</ulink> et
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?ppp">ppp</ulink>.
|
|
<emphasis remap="tt">pppd</emphasis> et <emphasis remap="tt">ppp</emphasis>
|
|
permettent les connexions entrantes et sortantes
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?sliplogin" >Sliplogin</ulink> ne peut s'utiliser qu'avec des connexions entrantes
|
|
et
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?slattach" >slattach</ulink> qu'avec des connexions sortantes.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Ces programmes sont décrits dans les sections suivantes du
|
|
<ulink url="../handbook/index.html">handbook</ulink>:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<ulink url="../handbook/slips.html" >référence du handbook sur SLIP (côté serveur)</ulink>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<ulink url="../handbook/slipc.html" >référence du handbook sur SLIP (côté client)</ulink>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<ulink url="../handbook/ppp.html" >référence du handbook sur PPP (mode noyau)</ulink>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<ulink url="../handbook/ppp-and-slip.html#USERPPP" >référence du handbook sur PPP (mode utilisateur)</ulink>
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Si vous avez accès à l'Internet à travers un "compte shell"
|
|
vous pouvez jeter un coup d'oeil au paquetage
|
|
<ulink url="http://www.freebsd.org/cgi/ports.cgi?^slirp">slirp</ulink>.
|
|
|
|
Il peut vous fournir un accès (limité) aux services tels que ftp
|
|
et http directement depuis votre machine locale.
|
|
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title> Est-ce que FreeBSD supporte NAT ou le Masquerading ?</title>
|
|
|
|
<para>
|
|
Si vous avez un sous-réseau local (une ou plusieur machines), mais qu'une
|
|
seule adresse IP vous a été allouée (même si ce n'est qu'une adresse IP
|
|
dynamique), vous pouvez regarder le programme
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?natd">natd</ulink>
|
|
. <emphasis remap="tt">Natd</emphasis> vous permet de connecter un sous-réseau entier
|
|
à l'Internet en n'utilisant qu'une seule adresse IP.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Le programme <ulink url="http://www.freebsd.org/cgi/man.cgi?ppp" >ppp</ulink> a des fonctionnalités similaires construit par l'intermédiaire
|
|
de l'option <emphasis remap="tt">-alias</emphasis> switch.
|
|
La
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?libalias">bibliothèque alias</ulink>
|
|
est utilisée dans les deux cas.
|
|
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title> Je n'arrive pas à faire marcher ppp. Où me suis-je trompé ? </title>
|
|
|
|
<para>
|
|
Vous devriez tout d'abord lire la page de manuel
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?ppp">ppp</ulink> et
|
|
<ulink url="../handbook/ppp-and-slip.html#USERPPP" >la section du handbook sur ppp</ulink>.
|
|
Activer le logging avec la commande
|
|
|
|
<programlisting>
|
|
set log Phase Chat Connect Carrier lcp ipcp ccp command
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Cette commande peut-être tapée à l'invite de commande de <emphasis remap="bf">ppp</emphasis>
|
|
ou peut-être entrée dans le fichier de configuration
|
|
<emphasis remap="tt">/etc/ppp/ppp.conf</emphasis>.
|
|
(le début de la section par défaut <emphasis remap="bf">default</emphasis>
|
|
est l'endroit idéal pour le mettre).
|
|
|
|
Assurez vous que le fichier <ulink url="http://www.freebsd.org/cgi/man.cgi?syslog.conf"
|
|
>/etc/syslog.conf</ulink> contienne les lignes
|
|
|
|
<programlisting>
|
|
!ppp
|
|
*.* /var/log/ppp.log
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
et que le fichier <emphasis remap="tt">/var/log/ppp.log</emphasis> existe.
|
|
Vous pouvez aussi tirer pas mal de renseignements sur ce qui se passe en
|
|
lisant les fichiers log.
|
|
Ne vous inquiétez pas même si cela vous semble dénué de sens, si vous obtenez
|
|
de l'aide de quelqu'un, pour lui, cela aura un sens.
|
|
</para>
|
|
|
|
<para>
|
|
Si votre version de ppp ne comprend pas la commande "set log"
|
|
vous devriez charger la
|
|
<ulink url="http://www.freebsd.org/~brian">dernière version</ulink>.
|
|
Il pourrra se construire sur FreeBSD version 2.1.5 et plus.
|
|
|
|
</para>
|
|
<sect2>
|
|
<title>Ppp se bloque quand je le lance</title>
|
|
<para>
|
|
Cela est usuellement dû au fait que votre nom d'hôte ne peut être résolu. La meilleure solution pour résoudre ce problème est de s'assurer que votre
|
|
<emphasis remap="tt">/etc/hosts</emphasis> est consulté en
|
|
premier par votre résolveur en éditant
|
|
<emphasis remap="tt">/etc/host.conf</emphasis> et en mettant la ligne
|
|
<emphasis remap="tt">hosts</emphasis> en premier.
|
|
Puis, ajoutez simplement une entrée pour votre machine locale
|
|
dans <emphasis remap="tt">/etc/hosts</emphasis>.
|
|
Si vous n'avez pas de réseau local, changez simplement votre
|
|
ligne <emphasis remap="tt">localhost</emphasis> :</para>
|
|
<programlisting>
|
|
127.0.0.1 foo.bar.com foo localhost
|
|
</programlisting><para>
|
|
Sinon, ajoutez simplement une autre entrée pour votre hôte. Consultez les pages de manuels appropriées pour plus de détails.
|
|
Vous devrez être alors capable de réussir à faire un
|
|
<emphasis remap="tt">ping -c1 `hostname`</emphasis> quand vous aurez fini.
|
|
|
|
</para>
|
|
</sect2>
|
|
<sect2>
|
|
<title>Ppp ne veut pas communiquer en mode -auto</title>
|
|
<para>
|
|
Tout d'abord, vérifiez que vous avez bien un routage par défaut
|
|
en lançant <ulink url="http://www.freebsd.org/cgi/man.cgi?netstat"> netstat -rn</ulink>, vous devriez voir deux entrées comme suivent :
|
|
|
|
<programlisting>
|
|
Destination Gateway Flags Refs Use Netif Expire
|
|
default 10.0.0.2 UGSc 0 0 tun0
|
|
10.0.0.2 10.0.0.1 UH 0 0 tun0
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
ici, on supposera que vous avez utilisé les adresses données en exemple
|
|
dans le handbook, les pages man ou depuis le fichier
|
|
ppp.conf.sample.
|
|
Si vous n'avez pas de routage par défaut, c'est peut-être parce que vous
|
|
utilisez une vieille version de <ulink url="http://www.freebsd.org/cgi/man.cgi?ppp" >ppp</ulink> qui ne comprend pas le mot
|
|
<emphasis remap="tt">HISADDR</emphasis> dans le fichier ppp.conf.
|
|
Si votre version de
|
|
<emphasis remap="bf">ppp</emphasis> est antérieure à FreeBSD 2.2.5,
|
|
changer la ligne
|
|
|
|
<programlisting>
|
|
add 0 0 HISADDR
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
par celle-ci :
|
|
|
|
<programlisting>
|
|
add 0 0 10.0.0.2
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Une autre raison au fait que la ligne du routage par défaut soit
|
|
manquante est que vous avez pu régler un routage par défaut erroné dans
|
|
le fichier <ulink url="http://www.freebsd.org/cgi/man.cgi?rc.conf" >/etc/rc.conf</ulink> (ce fichier est appelé
|
|
<emphasis remap="tt">/etc/sysconfig</emphasis> avant la release 2.2.2), et que vous avez
|
|
oublié la ligne suivante :
|
|
<programlisting>
|
|
delete ALL
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
from <emphasis remap="tt">ppp.conf</emphasis>. Si cela est le cas, revenez à la section du
|
|
handbook sur
|
|
<ulink url="../handbook/ppp-and-slip.html" >la configuration finale du système</ulink> section of the handbook.
|
|
|
|
</para>
|
|
</sect2>
|
|
<sect2>
|
|
<title> Que veut dire "No route to host" ? </title>
|
|
|
|
<para>
|
|
Cette erreur est usuellement dûe à une omission de la section
|
|
<programlisting>
|
|
MYADDR:
|
|
delete ALL
|
|
add 0 0 HISADDR
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
dans votre fichier <emphasis remap="tt">/etc/ppp/ppp.linkup</emphasis>.
|
|
Cela est seulement nécessaire si vous avez une adresse IP dynamique ou que
|
|
vous ne savez pas l'adresse de votre routeur. Si vous utilisez le mode
|
|
interactif, vous pouvez taper les lignes suivantes après être entré
|
|
en <emphasis remap="tt">mode paquet</emphasis> (le mode paquet est indiqué par le
|
|
<emphasis remap="bf">PPP</emphasis> en majuscule à l'invite):
|
|
|
|
<programlisting>
|
|
delete ALL
|
|
add 0 0 HISADDR
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Se référer à la section du handbook sur
|
|
<ulink url="../handbook/ppp-and-slip.html"> PPP et les adresses IP dynamiques </ulink>pour plus de détails.
|
|
|
|
</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Ma connexion se termine au bout de 3 minutes</title>
|
|
<para>
|
|
La limite de temps (timeout) par défaut de ppp est de 3 minutes. Cela peut-être
|
|
ajusté avec les lignes :
|
|
|
|
<programlisting>
|
|
set timeout NNN
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
où <emphasis remap="bf">NNN</emphasis> est le nombre de secondes d'inactivité avant que la connexion ne
|
|
soit fermée.
|
|
Si <emphasis remap="bf">NNN</emphasis> est égal à zero, la connexion ne sera jamais fermée pour cause
|
|
de limite de temps écoulée.
|
|
|
|
Il est possible de mettre cette commande dans le fichier
|
|
<emphasis remap="tt">ppp.conf</emphasis>, ou de la taper à l'invite en mode interactif.
|
|
Il est également possible de l'ajuster au vol alors que la ligne est
|
|
active, en se connectant à la socket du serveur <emphasis remap="bf">ppp</emphasis>
|
|
en utilisant
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?telnet">telnet</ulink> ou
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?pppctl" >pppctl</ulink>.
|
|
Se réferer à la page de manuel de
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?ppp">ppp</ulink>
|
|
pour plus de détails.
|
|
|
|
</para>
|
|
<sect2>
|
|
<title>Ma connexion se termine lors de gros chargements.</title>
|
|
|
|
<para>
|
|
Si vous avez activé le report de la qualité de connexion (Link Quality Reporting (LQR)),
|
|
il est possible ce soit parce que que trop de paquets LQR sont perdus entre la machine
|
|
et son interlocuteur. PPP en déduit que la ligne doit être trop
|
|
mauvaise, et se déconnecte. Avant la version 2.2.5 de FreeBSD,
|
|
LQR était activé par défaut.
|
|
Il est maintenant désactivé par défaut.
|
|
LQR peut-être désactivé avec la ligne suivante :
|
|
|
|
<programlisting>
|
|
disable lqr
|
|
</programlisting>
|
|
|
|
</para>
|
|
</sect2>
|
|
<sect2>
|
|
<title> Ma connexion se termine après un certain temps aléatoire. </title>
|
|
|
|
<para>
|
|
Parfois, sur une ligne de téléphone avec des parasites, ou même
|
|
sur une ligne avec des attentes d'appels activées, le modem peut se
|
|
suspendre parce qu'il pense (de manière erronée) qu'il y a une perte du
|
|
support de connexion (lost carrier)
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Il y a un réglage sur la plupart des modems qui déterminent le degré de
|
|
tolérance sur la perte temporaire de la ligne porteuse. Sur un
|
|
USR Sportster par exemple, cela est mesuré par le registre S10 en
|
|
dixième de secondes. Pour rendre votre modem plus tolérant, vous
|
|
pouvez ajouter la séquence envoi-attente suivante à votre chaîne de
|
|
connexion :
|
|
|
|
<programlisting>
|
|
set dial "...... ATS10=10 OK ......"
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Se référer au manuel de votre modem pour plus de détails.
|
|
|
|
</para></sect2>
|
|
|
|
<sect2>
|
|
<title> Rien ne se passe après le message Login Ok! </title>
|
|
|
|
<para>
|
|
Avant la version 2.2.5 de FreeBSD, une fois la ligne établie,
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?ppp" >ppp</ulink> devait attendre que ce soit l'autre parti (peer)
|
|
qui initialise le protocole de
|
|
contrôle de ligne (Line Control Protocol (LCP).
|
|
Or, plusieurs ISPs ne débuteront pas la négociation et attendront du client
|
|
qu'il le fasse. Pour forcer <emphasis remap="bf">ppp</emphasis>
|
|
à initialiser le LCP, utiliser la ligne suivante :
|
|
|
|
<programlisting>
|
|
set openmode active
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis remap="bf">Note</emphasis>:
|
|
Cela ne fait pas de dégats si chacun des deux parties initialisent tous les deux
|
|
la connexion, c'est pourquoi openmode est à présent activé par défaut.
|
|
Quoiqu'il en soit, la prochaine section expliquera quand est-ce ce que
|
|
cela peut gêner.
|
|
|
|
</para></sect2>
|
|
|
|
<sect2>
|
|
<title> Je n'arrête pas de voir des erreurs à propos de magic being the same </title>
|
|
|
|
<para>
|
|
De temps en temps, juste après la connexion, vous pouvez voir des
|
|
messages dans le log qui dit "magic is the same".
|
|
Parfois ces messages sont sans conséquences, et parfois l'un ou l'autre des
|
|
partis quitte.
|
|
La plupart des implémentations ppp ne peuvent survivre à ce problème, et
|
|
même si la ligne semble venir, vous verrez régulièrement des demandes de
|
|
configuration et des accusés de réception de configuration dans le
|
|
fichier log à moins que ppp abandonne et ne ferme la connexion.
|
|
</para>
|
|
|
|
<para>
|
|
Cela apparaît normallement sur les machines serveurs avec des disques
|
|
lents qui diffusent un getty sur le port, et qui exécute ppp depuis un
|
|
script ou programme de login après le login.
|
|
J'ai aussi eu vent de cela arrivant lorsqu'on utilise slirp.
|
|
La raison est qu'entre le temps où getty quitte et que ppp commence,
|
|
le ppp côté-client commence par envoyer des paquets
|
|
Line Control Protocol (LCP). Parce que l'ECHO est toujours actif
|
|
sur les ports du côté serveur, le client ppp verra ces paquets qui lui
|
|
seront "reflèté".
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Une partie de la négociation LCP est d'établir un nombre magique
|
|
(magic number)
|
|
de chaque côté de la ligne, ceci afin que les "réflexions" soient
|
|
détectées. Le protocole dit que lorsque l'autre parti essaye de
|
|
négocier le même nombre magique, un NAK devrait être envoyé et un
|
|
nouveau nombre magique choisi.
|
|
Durand la période où le serveur où le port serveur a l'ECHO activé, le
|
|
client ppp envoie des paquets LCP, voit le même nombre magique dans les
|
|
paquets reflètés et il le "NAK".
|
|
Il voit aussi les reflexions de NAK (qui veut aussi dire que ppp devrait
|
|
changer son nombre magique). Cela produit potentiellement un énorme
|
|
nombre de nombre magiques à changer, chacun d'entre eux tous
|
|
s'empilant joyeusement dans le buffer stty du serveur.
|
|
Aussitôt que ppp démarre sur le serveur, il est innondé par des
|
|
changement de nombre magique et souvent décide qu'il a assez essayé
|
|
de négociation LCP et abandonne.
|
|
Pendant ce temps, le client qui ne voit alors plus de réflexions,
|
|
se réjouit juste le temps de voir que le serveur l'a déconnecté.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Cela peut-être évité en autorisant l'autre parti à démarrer la
|
|
négociation avec la ligne suivante dans le fichier ppp.conf
|
|
|
|
<programlisting>
|
|
set openmode passive
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Cela dit à ppp d'attendre que le serveur débute la négociation LCP.
|
|
Certains serveurs toutefois peuvent ne jamais initier la négociation. Si
|
|
cela est le cas, vous pouvez faire quelque chose du genre :
|
|
|
|
<programlisting>
|
|
set openmode active 3
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Cela dit à ppp de rester passif pendant 3 secondes, et puis commencer à
|
|
envoyer les requêtes LCP/ Si l'autre parti commence à envoyer des
|
|
requêtes durant cette période, ppp répondra immédiatement plutôt qu'en
|
|
attendant que la période des 3 secondes se termine.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title> Les négociations LCP continuent jusqu'à ce que la connexion soit fermée. </title>
|
|
|
|
<para>
|
|
Cela est pour l'instant un défaut d'implémentation dans
|
|
<emphasis remap="bf">ppp</emphasis> où il n'associe pas les réponses
|
|
LCP, CCP & IPCP avec leur requête originale.
|
|
Comme conséquence, si l'une des implémentations
|
|
<emphasis remap="bf">ppp</emphasis> est 6 secondes plus lente que
|
|
l'autre côté, l'autre côté enverra 2 requêtes de configuration LCP
|
|
supplémentaire. Cela est fatal.
|
|
|
|
Soient 2 implémentations, <emphasis remap="bf">A</emphasis> et
|
|
<emphasis remap="bf">B</emphasis>. <emphasis remap="bf">A</emphasis>
|
|
commence à envoyer des requêtes LCP immédiatement après s'être connecté
|
|
et <emphasis remap="bf">B</emphasis> met 7 secondes à démarer.
|
|
Quand <emphasis remap="bf">B</emphasis> démarre,
|
|
<emphasis remap="bf">A</emphasis> a envoyé 3 requêtes LCP.
|
|
Nous supposons que la ligne a désactivée l'ECHO, car dans le cas
|
|
contraire nous verrions des problèmes de nombres magiques comme décrit
|
|
dans la section précédente.
|
|
|
|
<emphasis remap="bf">B</emphasis> envoi un REQ, puis un ACK au premier
|
|
REQ de <emphasis remap="bf">A</emphasis>.
|
|
Le résultat est que <emphasis remap="bf">A</emphasis> entre
|
|
dans l'état <emphasis remap="bf">OPENED</emphasis> et envoie un ACK
|
|
(le premier) en retour à <emphasis remap="bf">B</emphasis>.
|
|
Pendant ce temps, <emphasis remap="bf">B</emphasis> renvoi 2 ACK de plus
|
|
en réponse au 2 REQ supplémentaires envoyés par
|
|
<emphasis remap="bf">A</emphasis> avant
|
|
<emphasis remap="bf">B</emphasis> que B n'ait commencé.
|
|
<emphasis remap="bf">B</emphasis> reçoit alors le premier ACK
|
|
de <emphasis remap="bf">A</emphasis> et entre dans l'état
|
|
<emphasis remap="bf">OPENED</emphasis>.
|
|
<emphasis remap="bf">A</emphasis> reçoit le deuxième ACK de
|
|
<emphasis remap="bf">B</emphasis> et revient à l'état
|
|
<emphasis remap="bf">REQ-SENT</emphasis>, et envoie un autre (quatrième)
|
|
REQ comme décrit dans la RFC.
|
|
Il envoie alors un troisième ACK et entre dans l'état
|
|
<emphasis remap="bf">OPENED</emphasis>.
|
|
Durant ce moment, <emphasis remap="bf">B</emphasis>
|
|
reçoit le quatrième REQ de <emphasis remap="bf">A</emphasis>,
|
|
par conséquent, revient dans l'état
|
|
<emphasis remap="bf">ACK-SENT</emphasis> et envoie un autre (second)
|
|
REQ et (quatrième) ACK as per the RFC.
|
|
<emphasis remap="bf">A</emphasis> reçoit le REQ, va dans l'état
|
|
<emphasis remap="bf">REQ-SENT</emphasis> et envoie un autre REQ.
|
|
Il reçoit alors immédiatement le ACK suivant et entre dans l'état
|
|
<emphasis remap="bf">OPENED</emphasis>.
|
|
</para>
|
|
|
|
<para>
|
|
Cela continue tant qu'un des partis ne s'aperçoive qu'ils n'iront
|
|
nulle part comme cela et abandonne.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
La meilleure façon d'éviter cela est de configurer un côté comme étant
|
|
<emphasis remap="bf">passif</emphasis> - cela fait,
|
|
faire de telle sorte qu'un des côtés attende que l'autre commence la
|
|
négociation. Cela peut-être fait par la commande :
|
|
|
|
<programlisting>
|
|
set openmode passive
|
|
</programlisting>
|
|
Faire attention avec cette option, vous devriez aussi utiliser
|
|
la commande
|
|
<programlisting>
|
|
set stopped N
|
|
</programlisting>
|
|
afin de limiter la durée avant que
|
|
<emphasis remap="bf">ppp</emphasis> attende de l'autre parti de
|
|
commencer la négociation.
|
|
D'une autre façon, la commande
|
|
<programlisting>
|
|
set openmode active N
|
|
</programlisting>
|
|
|
|
(où <emphasis remap="bf">N</emphasis> est le nombre de secondes
|
|
qu'il faut attendre avant que le démarrage de la négociation ne soit
|
|
faite). Regardez les pages de manuels pour plus de détails.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title> Ppp se verrouille peu après la connexion. </title>
|
|
|
|
<para>
|
|
Avant la version 2.2.5 de FreeBSD, il était possible que votre
|
|
ligne soit désactivée peu après la connexion, dûe à
|
|
une mauvaise négociation de compression Predictor1 de
|
|
<emphasis remap="bf">ppp</emphasis>
|
|
|
|
Cela ne devrait arriver que si
|
|
deux côtés essayent de négocier des protocoles de
|
|
contrôle de compression (
|
|
Compression Control Protocols (CCP) différents.
|
|
Ce problème est à présent résolu, mais si vous utilisez toujours une
|
|
vieille version de
|
|
<emphasis remap="bf">ppp</emphasis>,
|
|
le problème peut-être sauté avec la ligne
|
|
|
|
<programlisting>
|
|
disable pred1
|
|
</programlisting>
|
|
|
|
</para></sect2>
|
|
|
|
<sect2>
|
|
<title> Ppp se verrouille quand je "shell" pour le tester. </title>
|
|
|
|
|
|
<para>
|
|
Quand vous exécutez le <emphasis remap="tt">shell</emphasis> ou la
|
|
commande <emphasis remap="tt">!</emphasis>,
|
|
<emphasis remap="bf">ppp</emphasis> exécute un shell (ou si vous avez
|
|
passé des arguments, <emphasis remap="bf">ppp</emphasis>
|
|
exécutera ces arguments). Ppp attendra que la commande se termine avant
|
|
de continuer. Si vous avez l'intention d'utiliser la connexion ppp
|
|
pendant que vous lancez la commande, la connexion apparaîtra
|
|
alors comme ayant été gelée.
|
|
Cela parce que <emphasis remap="bf">ppp</emphasis> attend que la
|
|
commande se termine.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Si vous voulez exécuter des commandes comme cela, utilisez plutôt la
|
|
commande <emphasis remap="tt">!bg</emphasis>.
|
|
Cela exécutera la commande en arrière plan, et ppp
|
|
pourra continuer de servir la connexion.
|
|
|
|
</para></sect2>
|
|
|
|
<sect2>
|
|
<title> Ppp sur un null-modem ne quitte jamais. </title>
|
|
|
|
<para>
|
|
Il n'y a aucune manière pour que <emphasis remap="bf">ppp</emphasis>
|
|
détermine automatiquement qu'une connexion directe
|
|
s'est achevée. Cela est dû aux lignes utilisées dans un câble série
|
|
null-modem. Quand on utilise cette sorte de connexion, LQR devrait
|
|
être toujours activé avec la ligne :
|
|
|
|
<programlisting>
|
|
enable lqr
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
LQR est accepté pas défaut si négocié par l'autre parti.
|
|
|
|
</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title> Pourquoi ppp tente de se connecter sans raison em mode -auto ? </title>
|
|
|
|
<para>
|
|
Si <emphasis remap="bf">ppp</emphasis> tente de se comnnecter
|
|
sans raison aucune, vous devez en déterminer la cause et mettre en place
|
|
des filtrages d'appels (dfilters) pour prévenir de tels appels.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Afin d'en déterminer la cause, utilisez la ligne suivant :
|
|
|
|
<programlisting>
|
|
set log +tcp/ip
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Cela tracera tous le trafic à travers une connexion. La prochaine fois
|
|
que la connexion se mettra en place de manière inattendue, vous verrez
|
|
la raison tracé avec le moment où cela s'est produit à côté.
|
|
</para>
|
|
|
|
<para>
|
|
Vous pouvez à présent désactiver les appels sous ces circonstances.
|
|
D'habitude, ces sortes de problèmes arrivent à cause des DNS lookup.
|
|
Pour empêcher le DNS lookup d'établir une connexion (cela n'empêchera
|
|
<emphasis remap="bf">pas</emphasis> <emphasis remap="bf">ppp</emphasis>
|
|
de passer les paquets à travers une connexion établie), utilisez les
|
|
lignes suivantes :
|
|
|
|
<programlisting>
|
|
set dfilter 1 deny udp src eq 53
|
|
set dfilter 2 deny udp dst eq 53
|
|
set dfilter 3 permit 0/0 0/0
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Cela ne convient pas toujours puisqu'il
|
|
enlèvera effectivement vos fonctionnalités de demandes d'appels - la
|
|
plupart des programmes auront besoin du DNS lookup
|
|
avant de faire quelque chose ayant un rapport avec le réseau.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Dans le cas DNS, vous pouvez essayer de déterminer qui est-ce qui essaye
|
|
actuellement de résoudre le nom de l'hôte.
|
|
La plupart du temps, c'est
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?sendmail" >sendmail</ulink> le coupable.
|
|
Vous devez vous assurer que vous avez dit à sendmail de ne faire aucun
|
|
DNS lookup dans ses fichiers de configuration,
|
|
regardez la section sur
|
|
<ulink url="ispmail">la configuration du mail</ulink> pour les détails de comment créer son propre fichier de
|
|
comfiguration, et qu'est ce qu'on doit mettre dedans.
|
|
Vous pouvez aussi vouloir ajouter les lignes suivantes dans votre
|
|
fichier <emphasis remap="bf">.mc</emphasis> :
|
|
|
|
<programlisting>
|
|
define(`confDELIVERY_MODE', `d')dnl
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Cela fera que sendmail mettra tout en file d'attente
|
|
jusqu'à ce que la file soit lancée (habituellement, sendmail est
|
|
invoqué avec ``-bd -q30m'', lui disant de lancer la file
|
|
d'attente toutes les 30 minutes) ou jusqu'à ce que un
|
|
``sendmail -q'' soit effectué (peut-être dans votre fichier ppp.linkup).
|
|
|
|
</para>
|
|
<sect2>
|
|
<title> Que veulent dire ces erreurs CCP ? </title>
|
|
|
|
|
|
<para>
|
|
Je n'arrête pas de voir les erreurs suivantes dans mon fichier log :
|
|
<programlisting>
|
|
CCP: CcpSendConfigReq
|
|
CCP: Received Terminate Ack (1) state = Req-Sent (6)
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Ceci est obtenu parce que ppp est en train de négocier la compression
|
|
Predictor1 et que l'autre parti ne veut pas du tout négocier de compression.
|
|
Ces messages sont sans conséquences aucune, mais si vous voulez les enleverm
|
|
vous pouvez désactiver la compression Predictor1 aussi en local.
|
|
|
|
<programlisting>
|
|
disable pred1
|
|
</programlisting>
|
|
|
|
</para></sect2>
|
|
|
|
<sect2>
|
|
<title>Ppp se bloque durant les transferts de fichiers avec une erreur IO. </title>
|
|
|
|
<para>
|
|
Sous FreeBSD 2.2.2 et avant, il y avait un bug dans le driver tun
|
|
qui stoppait tous les paquets entrants d'une taille plus grande que la taille
|
|
MTU de l'interace tun.
|
|
La réception de paquets plus grands que la taille du MTU
|
|
résultait en une erreur IO qui était alors tracé avec syslogd,
|
|
</para>
|
|
|
|
<para>
|
|
Les spécifications ppp disent qu'un MTU de 1500 devrait
|
|
<emphasis remap="bf">toujours</emphasis> être accepté
|
|
comme un minimum, ceci
|
|
quelque soit la négociation LCP. Il est toutefois possible que vous
|
|
diminuez le MTU à moins de 1500, votre ISP vous transmettra des paquets
|
|
de 1500 sans s'en préoccuper, et cela vous bloquera,
|
|
gelant ainsi la ligne.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Ce problème peut être contourné en ne réglant jamais un MTU en dessous
|
|
de 1500 sous FreeBSD 2.2.2 et avant.
|
|
|
|
</para></sect2>
|
|
|
|
<sect2>
|
|
<title> Pourquoi ppp ne trace-t-il pas ma vitesse de connexion ? </title>
|
|
|
|
<para>
|
|
La façon de tracer toutes les lignes de la ``conversation'' de
|
|
votre modem est d'activer :
|
|
|
|
<programlisting>
|
|
set log +connect
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Cela permettra à
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?ppp">ppp</ulink>
|
|
de tout tracer jusqu'à la dernière chaîne de requête d'"attente"
|
|
</para>
|
|
|
|
<para>
|
|
Si vous voulez voir votre vitesse de connexion et que vous utilisez
|
|
PAP ou CHAP (et donc ne rien avoir avec "chat" après le CONNECT
|
|
dans le script dial - pas de script "set login"), vous devez
|
|
vous assurer que vous prévenez ppp de s'attendre tout la ligne CONNECT,
|
|
quelque chose comme :
|
|
|
|
<programlisting>
|
|
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Ici, nous avons notre CONNECT, ne rien envoyer, et puis attendre
|
|
un saut de ligne, forçant
|
|
<emphasis remap="bf">ppp</emphasis> à lire toute la réponse
|
|
CONNECT.
|
|
|
|
</para></sect2>
|
|
|
|
<sect2>
|
|
<title>Ppp ignore le caractère `\' dans mon script chat</title>
|
|
|
|
<para>
|
|
Ppp parse chacune des lignes de votre fichier de configuration, de telle
|
|
sorte qu'il puisse interprêter des chaines comme
|
|
<emphasis remap="tt">set phone "123 456 789"</emphasis> correctement
|
|
(et réaliser qu'il n'y a que <emphasis remap="bf">un</emphasis>
|
|
seul argument.
|
|
Pour pouvoir spécifier un caractère ``"'', vous devez
|
|
l'échapper avec un backslash (``\'').
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Quand l'interprêteur chat parse chaque argument, il re-interprête
|
|
l'argument de telle sorte à trouver des séquences de caractères
|
|
d'échappement comme
|
|
``\P'' ou ``\T'' (voir les pages de manuel). En conséquence de
|
|
ce double-parsing, vous devez vous souvenir d'utiliser le nombre
|
|
correct d'échappement.
|
|
</para>
|
|
|
|
<para>
|
|
Si vous voulez envoyer un caractère ``\'' à votre modem,
|
|
vous aurez besoin de faire quelque chose comme :
|
|
|
|
<programlisting>
|
|
set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
qui se résultera en la séquence suivante :
|
|
|
|
<programlisting>
|
|
ATZ
|
|
OK
|
|
AT\X
|
|
OK
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
ou encore
|
|
|
|
<programlisting>
|
|
set phone 1234567
|
|
set dial "\"\" ATZ OK ATDT\\T"
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
résultera en la séquence suivante :
|
|
|
|
<programlisting>
|
|
ATZ
|
|
OK
|
|
ATDT1234567
|
|
</programlisting>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Ppp reçoit une erreur de segmentation, mais je ne trouve pas de fichier <emphasis remap="tt">ppp.core</emphasis></title>
|
|
|
|
|
|
<para>
|
|
Ppp (ou n'importe quel programme dans le même cas) ne devrait jamais
|
|
faire de coredump. Parce que ppp tourne avec une identité d'utilisateur
|
|
effectif de 0, le système d'exploitation n'écrira pas d'image du core sur le
|
|
disque avant de l'avoir terminé. Si, malgrè tout, ppp se
|
|
<emphasis remap="bf">termine</emphasis> actuellement à cause d'une violation
|
|
de segmentation, ou n'importe quel autre signal qui cause normalement un
|
|
core dump, <emphasis remap="bf">et</emphasis> que vous êtes sûr
|
|
que vous utilisez la dernière version (voir le début de cette section),
|
|
alors vous devriez faire la chose suivante :
|
|
<programlisting>
|
|
$ tar xfz ppp-*.src.tar.gz
|
|
$ cd ppp*/ppp
|
|
$ echo STRIP= >>Makefile
|
|
$ echo CFLAGS+=-g >>Makefile
|
|
$ make clean all
|
|
$ su
|
|
make install
|
|
chmod 555 /usr/sbin/ppp
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Vous aurez alors une version déboguable de ppp installé. Vous aurez à être
|
|
root pour lancer ppp puisque tous ses privilèges auront été révoqués. Quand
|
|
vous démarrez ppp, retenez soigneusement le répertoire courant dans lequel
|
|
vous étiez.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
A présent, si et quand ppp recevra une violation de segmentation, cela
|
|
crééra un fichier core nommé ppp.core. Vous aurez alors à faire la chose
|
|
suivante :
|
|
|
|
<programlisting>
|
|
$ su
|
|
gdb /usr/sbin/ppp ppp.core
|
|
(gdb) bt
|
|
.....
|
|
(gdb) f 0
|
|
.....
|
|
(gdb) i args
|
|
.....
|
|
(gdb) l
|
|
.....
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Toutes ces informations devront être données suivant votre question,
|
|
rendant ainsi possible le diagnostique de votre problème.
|
|
</para>
|
|
|
|
<para>
|
|
Si vous êtes familier avec gdb, vous pouvez vouloir trouver d'autres
|
|
techniques pour trouver ce qui a causé le dump, et les adresses et
|
|
valeurs des variables concernées.
|
|
</para></sect2>
|
|
|
|
<sect2>
|
|
<title> Le processus qui force un appel en mode auto ne se connecte jamais. </title>
|
|
|
|
<para>
|
|
Cela est un problème connu quand <emphasis remap="bf">ppp</emphasis>
|
|
est réglé de telle sorte à négocier une adresse IP dynamique avec son
|
|
homologue. Quand ce programme initial appelle
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?connect"> connect(2) </ulink>,
|
|
l'adresse IP de l'interface tun est assignée à l'extrêmité de la
|
|
socket. Le noyau crée le premier paquet sortant et l'écrit sur le
|
|
périphérique tun. <emphasis remap="bf">Ppp</emphasis>
|
|
lit alors le paquet et établit alors la connexion. Si, comme
|
|
résultat de l'assignation dynamique de
|
|
<emphasis remap="bf">ppp</emphasis>,
|
|
l'adresse de l'interface est changée, l'extrêmité originale de
|
|
la socket sera invalide. Tout paquet envoyé à l'autre parti sera alors
|
|
en principe perdu. Et même s'il ne l'était pas, toute réponse ne
|
|
pourrait pas être renvoyée à la machine originelle puisque l'adresse IP
|
|
ne serait plus possèdée par cette machine.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Théoriquement, il y a plusieurs manières d'aborder ce problème.
|
|
Le mieux serait que l'homologue re-assigne la même adresse IP si
|
|
possible <emphasis remap="tt">:-)</emphasis>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
La meilleure méthode de notre côté, serait de ne jamais changer
|
|
l'adresse IP de l'interface tun, mais à la place, changer tous les
|
|
paquets sortant de telle sorte que les adresses IP de la source soient
|
|
changées de l'interface Ip à l'IP négocié au vol. C'est essentiellement ce
|
|
que
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?libalias"> libalias(3) </ulink>
|
|
(et l'option <emphasis remap="bf">-alias</emphasis> de ppp)
|
|
font actuellement.
|
|
</para>
|
|
|
|
<para>
|
|
Une autre alternative (et probablement la plus sûre); est d'implémenter
|
|
un appel système qui change tous les sockets reliées depuis une
|
|
adresse IP à une autre.
|
|
<emphasis remap="bf">Ppp</emphasis> utiliserait cet appel pour
|
|
modifier la socket de tous les programmes existant lorsqu'une nouvelle
|
|
adresse IP est négociée.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Une troisième possibilité est d'autoriser à une interface de
|
|
s'activer sans adresse IP. Les paquets sortant auront une adresse IP de
|
|
255.255.255.255 jusqu'à ce que le premier SIOCAIFADDR ioctl soit fait.
|
|
Cela reviendrait à lier entièrement la socket, et
|
|
ça serait à <emphasis remap="bf">ppp</emphasis>
|
|
de changer l'adresse IP source, mais seulement si il est à
|
|
255.255.255.255, et seulement si le numéro IP et le checksum IP
|
|
doivent être changés. Quoiqu'il en soit, c'est de la
|
|
bidouille puisque le noyau enverra des paquets invalides à une
|
|
interface mal configurée, en supposant que d'autres
|
|
mécanismes seront capables de réparer les choses
|
|
retrospectivement.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Aucune de ces solutions n'a (encore) été implémentée.
|
|
|
|
</para></sect2>
|
|
|
|
<sect2>
|
|
<title>Pourquoi la plupart des jeux ne marchent pas avec l'option -alias ?</title>
|
|
|
|
|
|
<para>
|
|
La raison pour laquelle les jeux et assimilés ne marchent pas avec
|
|
libalias est que la machine extérieure essaye d'ouvrir une connexion
|
|
ou envoyer des paquets UDP (non sollicités) à la machine
|
|
interne. Le logiciel packet alias ne sait alors pas qu'il faut envoyer
|
|
ces paquets à une machine interne.
|
|
</para>
|
|
|
|
<para>
|
|
Pour que ça marche, assurez vous que la seule chose qui tourne est le
|
|
logiciel avec lequel vous avez des problèmes, puis alors, soit vous
|
|
lancez tcpdump sur votre interface tun de votre routeur, soit vous
|
|
activez le login ppp tcp/ip (``set log +tcp/ip'') sur votre routeur.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Quand vous démarrez le logiciel incriminé, vous devriez voir les paquets
|
|
passer à travers la machine routeur. Quand quelque chose revient depuis
|
|
l'extérieur, il sera retiré (c'est ça le problème). Noter le numéro
|
|
de port de ces paquets, puis arrêtez le logiciel incriminé. Faite ceci
|
|
quelques fois pour voir si les numéro de ports sont consistants. Si ils
|
|
le sont, alors la ligne suivante dans la section appropriée de
|
|
/etc/ppp/ppp.conf rendra le logiciel fonctionnel.
|
|
|
|
<programlisting>
|
|
alias port proto internalmachine:port port
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
où ``proto'' est soit ``tcp'' ou ``udp'',
|
|
``internalmachine'' est la machine à laquelle vous voulez que les
|
|
paquets soient envoyés et ``port'' le numéro de port de destination des
|
|
paquets.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Vous ne pourrez pas utiliser le logiciel sur d'autres machines sans
|
|
changer la commande du dessus, et lancer le logiciel sur 2 machines
|
|
internes en même temps est hors de question - après tout, le monde
|
|
extérieur voit tout votre réseau entier comme une seule machine.
|
|
</para>
|
|
|
|
<para>
|
|
Si les numéros de ports ne sont pas consistants, il y a 3 autres
|
|
options :
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis remap="bf">1)</emphasis> Soumettre le support dans libalias.
|
|
Des exemples de ``cas spéciaux'' peuvent être trouvés dans
|
|
/usr/src/lib/libalias/alias_*.c (alias_ftp.c
|
|
iest un bon prototype).
|
|
Cela implique habituellement la lecture de certains paquets sortant
|
|
reconnus, identification des instructions qui dit à la machine
|
|
extérieure d'initialiser la connexion en retour vers machine interne sur un port
|
|
(aléatoire) spécifique, et mettre en place une
|
|
``route'' dans la table d'alias de telle sorte que les paquets concernés
|
|
sachent où aller.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
C'est la solution la plus difficile, mais c'est la meilleure et
|
|
permettra au logiciel de marcher sur plusieurs machines
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis remap="bf">2)</emphasis>
|
|
Utiliser un proxy. L'application peut pouvoir supporter socks5 par
|
|
exemple, ou (comme dans le cas de ``cvsup'') peut avoir une option
|
|
``passive'' qui évite d'avoir à toujours demander que l'autre parti
|
|
ouvre une connexion en retour sur la machine locale.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis remap="bf">3)</emphasis>
|
|
Tout rediriger vers une machine interne utilisant
|
|
``alias addr''. C'est l'approche "bourrin".
|
|
|
|
</para></sect2>
|
|
|
|
<sect2>
|
|
<title>Rien de cela ne marche - je suis désespéré !</title>
|
|
<para>
|
|
Si tout le reste échoue, envoyer autant d'informations que vous pouvez,
|
|
y compris vos fichiers de configuration, comment vous avez démarré
|
|
<emphasis remap="bf">ppp</emphasis>, les parties pertinentes de
|
|
votre fichier log, et la sortie de la commande
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?netstat"> netstat -rn </ulink>(avant et après connexion) à la liste de diffusion
|
|
<ulink url="mailto:freebsd-questions@FreeBSD.org"> freebsd-questions@FreeBSD.org </ulink>ou au newsgroup
|
|
<ulink url="news:comp.unix.bsd.freebsd.misc"> comp.unix.bsd.freebsd.misc, </ulink>et quelqu'un devrait vous orienter dans la bonne direction.
|
|
</para></sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Je ne peux pas créer un périphérique <emphasis remap="tt">/dev/ed0</emphasis> ! </title>
|
|
<para>
|
|
Dans le cadre des réseaux Berkeley, les interfaces réseaux sont
|
|
seulement directement accessibles par le code du noyau.
|
|
Regarder le fichier
|
|
<emphasis remap="tt">/etc/rc.network</emphasis>
|
|
et les pages de manuels pour les différents programmes réseaux mentionnés
|
|
ici pour plus d'informations. Si cela vous est complètement confus, vous
|
|
devriez prendre un livre décrivant l'administration réseaux sur un autre
|
|
système d'exploitation relatif à BSD; à quelques exceptions
|
|
mineures, administrer un réseau sous FreeBSD est basiquement la
|
|
même chose que sur un SunOS 4.0 ou un Ultrix.
|
|
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Comment puis-je régler les alias éthernet ?</title>
|
|
|
|
<para>
|
|
Ajouter ``<emphasis remap="tt">netmask 0xffffffff</emphasis>'' à votre
|
|
ligne de commande
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?ifconfig">ifconfig</ulink>
|
|
comme ci-dessous :
|
|
|
|
<programlisting>
|
|
ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff
|
|
</programlisting>
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title> Comment puis-je faire pour que mon 3C503 utilise l'autre port réseau ? </title>
|
|
|
|
<para>
|
|
Si vous voulez utiliser les autres ports, vous avez à spécifier un
|
|
paramêtre supplémentaire dans la ligne de commande
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?ifconfig">ifconfig</ulink>.
|
|
Le port par défaut est``<emphasis remap="tt">link0</emphasis>''.
|
|
Pour utiliser le port AUI à la place du BNC,utiliser
|
|
``<emphasis remap="tt">link2</emphasis>''.
|
|
Ces paramêtres devraient être spécifiés en utilisant les variables
|
|
de ifconfig_* variables dans <ulink url="http://www.freebsd.org/cgi/man.cgi?rc.conf">/etc/rc.conf</ulink>.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>J'ai des problèmes avec NFS depuis/vers FreeBSD.</title>
|
|
|
|
<para>
|
|
Certaines cartes réseaux sont meilleures que d'autres
|
|
et peuvent causer quelquefois des problèmes lors d'applications
|
|
réseaux intensives comme NFS.
|
|
</para>
|
|
|
|
<para>
|
|
Regarder <ulink url="../handbook/nfs.html">la partie du Handbook sur NFS </ulink>pour plus d'informations à ce sujet.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title> Pourquoi ne puis-je pas monter par NFS depuis une machine sous Linux ? </title>
|
|
|
|
<para>
|
|
Certaines versions du code NFS de Linux ne peuvent accepter des
|
|
requêtes de montages que depuis un port privilègié; essayez
|
|
|
|
<programlisting>
|
|
mount -o -P linuxbox:/blah /mnt
|
|
</programlisting>
|
|
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title> Pourquoi ne puis-je pas monter un NFS depuis une machine Sun ? </title>
|
|
|
|
<para>
|
|
Les stations de travail Sun sous SunOS 4.X n'acceptent seulement des
|
|
requêtes de montage que depuis un port privilègié; essayez
|
|
|
|
<programlisting>
|
|
mount -o -P sunbox:/blah /mnt
|
|
</programlisting>
|
|
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>J'ai des problème pour parler PPP à des machines NeXTStep.</title>
|
|
|
|
<para>
|
|
Essayer de désactiver l'extension TCP dans <ulink url="http://www.freebsd.org/cgi/man.cgi?rc.conf">/etc/rc.conf</ulink> en changeant la variable à NO :
|
|
|
|
<programlisting>
|
|
tcp_extensions=NO
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
les machines Xylogic's Annex ne marchent pas non plus dans ce contexte,
|
|
et vous devez changer de même que ci-dessus pour pouvoir vous
|
|
connecter au travers d'elles.
|
|
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Comment activer le support multicast IP ?</title>
|
|
|
|
<para>
|
|
Les opérations multicast sont entièrement supportées par FreeBSD 2.0 et
|
|
plus par défaut. Si vous voulez que votre machine marche comme un
|
|
routeur multicast, vous devez recompiler votre noyau avec l'option
|
|
<emphasis remap="tt">MROUTING</emphasis> et lancer
|
|
<emphasis remap="tt">mrouted</emphasis>. FreeBSD 2.2 et plus
|
|
démarrera <emphasis remap="tt">mrouted</emphasis> au moment du boot si
|
|
l'option <emphasis remap="tt">mrouted_enable</emphasis> est mis à
|
|
"YES" dans <emphasis remap="tt">/etc/rc.conf</emphasis>.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Les outils MBONE tools sont disponibles dans leur
|
|
propre catégorie de ports, mbone. Si vous cherchez les outils de
|
|
conférence <emphasis remap="tt">vic</emphasis> et
|
|
<emphasis remap="tt">vat</emphasis>,
|
|
c'est là qu'il faut voir !
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Pour plus d'informations, regarder
|
|
<ulink url="http://www.mbone.com/">le web d'information Mbone</ulink>.
|
|
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Quelles cartes réseaux sont basées sur le chipset DEC PCI ?</title>
|
|
|
|
<para>
|
|
Voici une liste compilée par
|
|
<ulink url="mailto:gfoster@driver.nsta.org">Glen Foster</ulink>,
|
|
avec quelques ajouts récents :
|
|
|
|
<programlisting>
|
|
Vendor Model
|
|
----------------------------------------------
|
|
ASUS PCI-L101-TB
|
|
Accton ENI1203
|
|
Cogent EM960PCI
|
|
Compex ENET32-PCI
|
|
D-Link DE-530
|
|
Dayna DP1203, DP2100
|
|
DEC DE435
|
|
Danpex EN-9400P3
|
|
JCIS Condor JC1260
|
|
Linksys EtherPCI
|
|
Mylex LNP101
|
|
SMC EtherPower 10/100 (Model 9332)
|
|
SMC EtherPower (Model 8432)
|
|
TopWare TE-3500P
|
|
Zynx ZX342
|
|
</programlisting>
|
|
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title> Pourquoi dois-je utiliser le FQDN pour les hôtes de mon site ? </title>
|
|
|
|
|
|
<para>
|
|
Vous verrez probablement que l'hôte est actuellement dans un domaine
|
|
différent; par exemple, si vous êtes dans foo.bar.edu
|
|
et que vous voulez atteindre un hôte nommé ``mumble''
|
|
dans le domaine bar.edu domain, vous aurez à vous y référer
|
|
par son nom de domaine entièrement qualifié, ``mumble.bar.edu'', à la place de
|
|
juste ``mumble''.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Traditionellement, cela était autorisés par les résolveurs
|
|
BSD BIND. Malgrè tout, la version courante de
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?named">bind</ulink>
|
|
qui est fournie avec FreeBSD ne fournit plus d'abbréviation par défaut
|
|
pour un domaine non entièrement qualifié; autre que le domaine dans
|
|
lequel vous êtes.
|
|
Ainsi, un hôte non-qualifié <emphasis remap="tt">mumble</emphasis>
|
|
doit soit être trouvé comme
|
|
<emphasis remap="tt">mumble.foo.bar.edu</emphasis>,
|
|
ou alors il sera cherché dans le domaine racine.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Cela est différent du comportement décrit auparavant, où la recherche
|
|
continuait à travers <emphasis remap="tt">mumble.bar.edu</emphasis>,
|
|
et <emphasis remap="tt">mumble.edu</emphasis>.
|
|
Jetez un coup d'oeil à la RFC 1535 pour savoir pourquoi cela est
|
|
considéré comme une mauvaise pratique, ou encore même un trou de
|
|
sécurité.
|
|
</para>
|
|
|
|
<para>
|
|
Comme détour, vous pouvez placer la ligne :
|
|
<programlisting>
|
|
search foo.bar.edu bar.edu
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
à la place de la précédente :
|
|
|
|
<programlisting>
|
|
domain foo.bar.edu
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
dans votre fichier
|
|
<ulink url="http://www.freebsd.org/cgi/man.cgi?resolv.conf"> /etc/resolv.conf </ulink>.
|
|
Quoiqu'il en soit, assurez vous que l'ordre de recherche
|
|
ne vas pas en dehors des ``limites entre l'administration locale
|
|
et publique'', comme appelée dans la RFC 1535.
|
|
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>``Permission denied'' pour toutes les opérations réseaux.</title>
|
|
|
|
|
|
<para>
|
|
Si vous avez compilé votre noyau avc l'option
|
|
<emphasis remap="tt">IPFIREWALL</emphasis>, vous devez être prévenu, que la
|
|
politique par défaut depuis le
|
|
2.1.7R (cela a changé durant le développement
|
|
du 2.1-STABLE) est de refuser tous les paquets qui ne sont pas
|
|
explicitement autorisés.
|
|
</para>
|
|
|
|
<para>
|
|
Si vous avez inintentionnellement mal configuré votre système pour le
|
|
firewall, vous pouvez rétablir les fonctionnalité réseaux en tapant la
|
|
commande suivante sous root :
|
|
|
|
<programlisting>
|
|
ipfw add 65534 allow all from any to any
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Vous pouvez aussi régler "firewall_type='open'" dans
|
|
<emphasis remap="tt">/etc/rc.conf</emphasis>.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Pour plus d'informations sur la configuration d'un firewall FreeBSD,
|
|
voir la <ulink url="../handbook/firewalls.html">section correspondante du handbook</ulink>.
|
|
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Combien d'overhead, IPFW implique-t-il ?</title>
|
|
|
|
<para>
|
|
La réponse à ceci dépend pour la plupart à votre ensemble de règle et à
|
|
votre vitesse de processeur. Pour la plupart des applications
|
|
utilisant ethernet et de petits ensembles de règles, la réponse est :
|
|
négligeable. Pour tous ceux d'entre vous qui veulent des mesures
|
|
actuelles pour satisfaire leur curiosité, continuez à lire :
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Les mesures suivantes ont été réalisées en utilisant 2.2.5-STABLE sur
|
|
un 486-66. IPFW a été modifié pour mesurer le temps écoulé par
|
|
l'intermédiaire de la routine <emphasis remap="tt">ip_fw_chk</emphasis>
|
|
en affichant les résultats sur la console tous les 1000 paquets.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
2 ensembles de règles, chacun avec 1000 règles ont été testés.
|
|
Le premier ensemble a été conçu pour démontrer le scénario du pire des
|
|
cas en répétant la règle :
|
|
|
|
<programlisting>
|
|
ipfw add deny tcp from any to any 55555
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Cela démontre le pire des cas en faisant que chaque paquet IPFW entraine l'exécution de
|
|
la routine de vérification qui finallement décide que le
|
|
paquet ne correspond pas aux règles (en vertu du numéro de port)?
|
|
Apès la 999eme itération de cette règle, il y avait un
|
|
<emphasis remap="tt">allow ip from any to any</emphasis>.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Le second ensemble de règles a été conçu pour annuler la vérification de
|
|
règle très rapidement :
|
|
|
|
<programlisting>
|
|
ipfw add deny ip from 1.2.3.4 to 1.2.3.4
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Les adresses IP des sources non correspondantes aux règles énoncées
|
|
ci-dessus font que ces règles sont sautées très rapidement. Comme
|
|
auparavant, la 1000eme règle était un
|
|
<emphasis remap="tt">allow ip from any to any</emphasis>.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
L'étude par paquet dans le premier cas a été approximativement de
|
|
2.703ms/paquet, soit en gros 2.7 microseconds par règle
|
|
.
|
|
Ainsi, la limite théorique d'étude de paquet avec ces règles est de 370
|
|
paquets par secondes. En supposant un éthernet 10Mbps et des paquets
|
|
d'environ 1500 bytes, nous ne pourrons être capable que d'obtenir une
|
|
utilisation de la bande passante de 55.5%
|
|
</para>
|
|
|
|
<para>
|
|
Pour le dernier cas, chaque paquet a été étudié en approximativement
|
|
1.172ms, soit en gros 1.2 microseconds par règle.
|
|
La limite théorique de l'étude des paquets ici, serait d'environ de 853
|
|
paquets par secondes, ce qui pourrait consommer une bande passante
|
|
d'un éthernet 10Mbps.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Le nombre excessif de règle testés, et la nature de ces règles ne
|
|
fournissent pas un scénario du monde réel -- ils ont été utilisés que
|
|
pour générer les informations de temps présentés ici.Voici certaines
|
|
choses à garder à l'esprit pour construire un ensemble de règles
|
|
efficaces :
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
Placer une règle d'`établissement' très tôt afin de pouvoir
|
|
gérer la majorité du trafic TCP. Ne mettre aucun
|
|
<emphasis remap="tt">allow tcp</emphasis>
|
|
avant cette règle.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Placer les règles souvent sollicitées le plus au début de l'ensemble
|
|
des règles plutôt que celles rarement utilisées
|
|
(<emphasis remap="bf">sans changer la permissivité du firewall </emphasis>, bien sûr).
|
|
Vous pourrez voir quels sont les règles les plus souvent utilisées en
|
|
examinant les statistiques des comptages des paquets avec
|
|
<emphasis remap="tt">ipfw -a l</emphasis>.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Comment puis-je rediriger les requêtes de services d'une machine vers une autre ? </title>
|
|
|
|
<para>
|
|
Vous pouvez rediriger des requêtes FTP (et autre services) avec le
|
|
paquetage 'socket', disponible dans l'arbre des ports dans la catégorie
|
|
'sysutils'. Remplacer simplement la ligne de commande de
|
|
service pour appeler socket à la place, ainsi:
|
|
|
|
<programlisting>
|
|
ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
où 'ftp.foo.com' et 'ftp' sont les hôtes et les ports où se diriger
|
|
respectivement.
|
|
</para>
|
|
</sect1>
|
|
</chapter>
|
|
|