<!--
	The FreeBSD Documentation Project
	The FreeBSD French Documentation Project
         
        $FreeBSD$
        Original revision: n.nn
--> 


  <chapter id="network">
    <title>R&eacute;seaux</title>

    <sect1>
      <title>O&ugrave; 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&eacute;e depuis le
r&eacute;seau, et lit les fichiers n&eacute;cessaires depuis un serveur et non depuis 
son disque dur. Pour plus de d&eacute;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 &ecirc;tre utilis&eacute;e comme routeur d&eacute;di&eacute; ?  </title>


    <para>
Les standards de l'Internet et de bonnes pratiques techniques nous
interdisent de faire par d&eacute;faut du routage de  paquets avec
FreeBSD. Mais vous pouvez n&eacute;amoins activer cette fonctionnalit&eacute; en
changeant la variable suivante &agrave; <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> &agrave; <emphasis remap="tt">1</emphasis>.

      </para>

    <para>
Dans la plupart des cas, vous aurez aussi &agrave; lancer un processus de routage
afin de renseigner les autres syst&egrave;mes sur votre routeur.
FreeBSD est fourni avec le d&eacute;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&eacute;venir que lorsque FreeBSD est
configur&eacute; de cette mani&egrave;re, il ne correspond pas tout &agrave; fait 
aux requis standards de l'Internet sur les routeurs. N&eacute;amoins, 
il s'en rapproche assez pour un usage ordinaire.

      </para>
    </sect1>

    <sect1>
      <title> Puis-je connecter ma machine sous Win95 &agrave; l'Internet via FreeBSD ?  </title>


    <para>
Typiquement, les gens qui posent cette questions sont ceux qui ont 2 PC
&agrave; la maison, un avec FreeBSD et un avec Win95. L'id&eacute;e est d'utiliser 
la machine sous FreeBSD pour se connecter &agrave; l'Internet et puis
pouvoir ensuite acc&eacute;der &agrave; l'Internet depuis la machine sous Windows 95
via la machine sous FreeBSD.
Ce n'est en r&eacute;alit&eacute; qu'un cas particulier de la question pr&eacute;c&eacute;dente.
      </para>

    <para>
Il y a un document tr&egrave;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&eacute;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&eacute;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 &eacute;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'&agrave; 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&eacute;crits dans les sections suivantes du
<ulink url="../handbook/index.html">handbook</ulink>:
      <itemizedlist>
        <listitem>
		<para>
<ulink url="../handbook/slips.html" >r&eacute;f&eacute;rence du handbook sur SLIP (c&ocirc;t&eacute; serveur)</ulink>
		</para>
		</listitem>

        <listitem>
		<para>
<ulink url="../handbook/slipc.html" >r&eacute;f&eacute;rence du handbook sur  SLIP (c&ocirc;t&eacute; client)</ulink>
		</para>
		</listitem>

        <listitem>
		<para>
<ulink url="../handbook/ppp.html" >r&eacute;f&eacute;rence du handbook sur PPP (mode noyau)</ulink>
		</para>
		</listitem>

        <listitem>
		<para>
<ulink url="../handbook/ppp-and-slip.html#USERPPP" >r&eacute;f&eacute;rence du handbook sur PPP (mode utilisateur)</ulink>
		</para>
		</listitem>
      </itemizedlist>

      </para>

    <para>
Si vous avez acc&egrave;s &agrave; l'Internet &agrave; 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&egrave;s (limit&eacute;) 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&eacute;seau local (une ou plusieur machines), mais qu'une
seule adresse IP vous a &eacute;t&eacute; allou&eacute;e (m&ecirc;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&eacute;seau entier 
&agrave; 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&eacute;s similaires construit par l'interm&eacute;diaire
de l'option  <emphasis remap="tt">-alias</emphasis> switch.  
La 
<ulink url="http://www.freebsd.org/cgi/man.cgi?libalias">biblioth&egrave;que alias</ulink>
est utilis&eacute;e dans les deux cas.

      </para>
    </sect1>

    <sect1>
      <title> Je n'arrive pas &agrave; faire marcher ppp. O&ugrave; me suis-je tromp&eacute; ?  </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-&ecirc;tre tap&eacute;e &agrave; l'invite de commande de <emphasis remap="bf">ppp</emphasis> 
ou peut-&ecirc;tre entr&eacute;e dans le fichier de configuration 
<emphasis remap="tt">/etc/ppp/ppp.conf</emphasis>.
(le d&eacute;but de la section par d&eacute;faut <emphasis remap="bf">default</emphasis> 
est l'endroit id&eacute;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&eacute;tez pas m&ecirc;me si cela vous semble d&eacute;nu&eacute; 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&egrave;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&ucirc; au fait que votre nom d'h&ocirc;te ne peut &ecirc;tre r&eacute;solu. La meilleure solution pour r&eacute;soudre ce probl&egrave;me est de s'assurer que votre 
<emphasis remap="tt">/etc/hosts</emphasis> est consult&eacute; en 
premier par votre r&eacute;solveur en &eacute;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&eacute;e pour votre machine locale 
dans <emphasis remap="tt">/etc/hosts</emphasis>. 
Si vous n'avez pas de r&eacute;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&eacute;e pour votre h&ocirc;te. Consultez les pages de manuels appropri&eacute;es pour plus de d&eacute;tails.
Vous devrez &ecirc;tre alors capable de r&eacute;ussir  &agrave; 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&eacute;rifiez que vous avez bien un routage par d&eacute;faut
en lan&ccedil;ant <ulink url="http://www.freebsd.org/cgi/man.cgi?netstat"> netstat -rn</ulink>, vous devriez voir deux entr&eacute;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&eacute; les adresses donn&eacute;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&eacute;faut, c'est peut-&ecirc;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&eacute;rieure &agrave; 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&eacute;faut soit 
manquante est que vous avez pu r&eacute;gler un routage par d&eacute;faut erron&eacute; dans
le fichier <ulink url="http://www.freebsd.org/cgi/man.cgi?rc.conf" >/etc/rc.conf</ulink> (ce fichier est appel&eacute;
<emphasis remap="tt">/etc/sysconfig</emphasis> avant la release 2.2.2), et que vous avez
oubli&eacute; la ligne suivante :
        <programlisting>
delete ALL
        </programlisting>

        </para>

    <para>
from <emphasis remap="tt">ppp.conf</emphasis>.  Si cela est le cas,  revenez &agrave; la section du
handbook sur 
<ulink url="../handbook/ppp-and-slip.html" >la configuration finale du syst&egrave;me</ulink> section of the handbook.

      </para>
      </sect2>
      <sect2>
        <title> Que veut dire  "No route to host" ?  </title>

	    <para>
Cette erreur est usuellement d&ucirc;e &agrave; 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&eacute;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&egrave;s &ecirc;tre entr&eacute; 
en <emphasis remap="tt">mode paquet</emphasis> (le mode paquet est indiqu&eacute; par le
<emphasis remap="bf">PPP</emphasis> en majuscule &agrave; l'invite):

        <programlisting>
delete ALL
add 0 0 HISADDR
        </programlisting>

        </para>

   		 <para>
Se r&eacute;f&eacute;rer &agrave; la section du handbook sur 
<ulink url="../handbook/ppp-and-slip.html"> PPP et les adresses IP dynamiques </ulink>pour plus de d&eacute;tails.

     	 </para>
      </sect2>
	</sect1>

	<sect1>
        <title>Ma connexion se termine au bout de 3 minutes</title>
    <para>
La limite de temps (timeout) par d&eacute;faut de ppp est de 3 minutes. Cela peut-&ecirc;tre
ajust&eacute; avec les lignes :

        <programlisting>
set timeout NNN
        </programlisting>

        </para>

    <para>
o&ugrave; <emphasis remap="bf">NNN</emphasis> est le nombre de secondes d'inactivit&eacute; avant que la connexion ne
soit ferm&eacute;e.
Si <emphasis remap="bf">NNN</emphasis> est &eacute;gal &agrave; zero, la connexion ne sera jamais ferm&eacute;e pour cause
de limite de temps &eacute;coul&eacute;e.

Il est possible de mettre cette commande dans le fichier
<emphasis remap="tt">ppp.conf</emphasis>, ou de la taper &agrave; l'invite en mode interactif.
Il est &eacute;galement possible de l'ajuster au vol alors que la ligne est
active, en se connectant &agrave; 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&eacute;ferer &agrave;  la page de manuel de
<ulink url="http://www.freebsd.org/cgi/man.cgi?ppp">ppp</ulink>
pour plus de d&eacute;tails.

      </para>
      <sect2>
        <title>Ma connexion se termine lors de gros chargements.</title>

    <para>
Si vous avez activ&eacute; le report de la qualit&eacute; 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&eacute;duit que la ligne doit &ecirc;tre trop
mauvaise, et se d&eacute;connecte. Avant la version 2.2.5 de FreeBSD,
LQR &eacute;tait activ&eacute; par d&eacute;faut.  
Il est maintenant d&eacute;sactiv&eacute; par d&eacute;faut.
LQR peut-&ecirc;tre d&eacute;sactiv&eacute; avec la ligne suivante :

        <programlisting>
disable lqr
        </programlisting>

      </para>
      </sect2>
      <sect2>
        <title> Ma connexion se termine apr&egrave;s un certain temps al&eacute;atoire.  </title>

    <para>
Parfois, sur une ligne de t&eacute;l&eacute;phone avec des parasites, ou m&ecirc;me
sur une ligne avec des attentes d'appels activ&eacute;es, le modem peut se
suspendre parce qu'il pense (de mani&egrave;re erron&eacute;e) qu'il y a une perte du
support de connexion (lost carrier)

        </para>

    <para>
Il y a un r&eacute;glage sur la plupart des modems qui d&eacute;terminent le degr&eacute; de
tol&eacute;rance sur la perte temporaire de la ligne porteuse. Sur un
USR Sportster par exemple, cela est mesur&eacute; par le registre S10 en 
dixi&egrave;me de secondes. Pour rendre votre modem plus tol&eacute;rant, vous
pouvez ajouter la s&eacute;quence envoi-attente suivante &agrave; votre cha&icirc;ne de
connexion :

        <programlisting>
set dial "...... ATS10=10 OK ......"
        </programlisting>

        </para>

    <para>
Se r&eacute;f&eacute;rer au manuel de votre modem pour plus de d&eacute;tails.

      </para></sect2>

      <sect2>
        <title> Rien ne se passe apr&egrave;s le message Login Ok!  </title>

    <para>
Avant la version 2.2.5 de FreeBSD, une fois la ligne &eacute;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&ocirc;le de ligne (Line Control Protocol (LCP).  
Or, plusieurs ISPs ne d&eacute;buteront pas la n&eacute;gociation et attendront du client 
qu'il le fasse. Pour forcer <emphasis remap="bf">ppp</emphasis> 
&agrave; 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&eacute;gats si chacun des deux parties initialisent tous les deux
la connexion, c'est pourquoi openmode est &agrave; pr&eacute;sent activ&eacute; par d&eacute;faut.
Quoiqu'il en soit, la prochaine section expliquera quand est-ce ce que 
cela peut g&ecirc;ner.

      </para></sect2>

      <sect2>
        <title> Je n'arr&ecirc;te pas de voir des erreurs &agrave; propos de magic being the same </title>

    <para>
De temps en temps, juste apr&egrave;s la connexion, vous pouvez voir des
messages dans le log qui dit "magic is the same".  
Parfois ces messages sont sans cons&eacute;quences, et parfois l'un ou l'autre des
partis quitte.
La plupart des impl&eacute;mentations ppp ne peuvent survivre &agrave; ce probl&egrave;me, et
m&ecirc;me si la ligne semble venir, vous verrez r&eacute;guli&egrave;rement des demandes de
configuration et des accus&eacute;s de r&eacute;ception de configuration dans le
fichier log &agrave; moins que ppp abandonne et ne ferme la connexion.
        </para>

    <para>
Cela appara&icirc;t normallement sur les machines serveurs avec des disques 
lents qui diffusent un getty sur le port, et qui ex&eacute;cute ppp depuis un
script ou programme de login apr&egrave;s le login.
J'ai aussi eu vent de cela arrivant lorsqu'on utilise slirp.
La raison est qu'entre le temps o&ugrave; getty quitte et que ppp commence, 
le ppp c&ocirc;t&eacute;-client commence par envoyer des paquets 
Line Control Protocol (LCP). Parce que l'ECHO est toujours actif 
sur les ports du c&ocirc;t&eacute; serveur, le client ppp verra ces paquets qui lui
seront "refl&egrave;t&eacute;".

        </para>

    <para>
Une partie de la n&eacute;gociation LCP est d'&eacute;tablir un nombre magique 
(magic number)
de chaque c&ocirc;t&eacute; de la ligne, ceci afin que les "r&eacute;flexions" soient
d&eacute;tect&eacute;es. Le protocole dit que lorsque  l'autre parti essaye de
n&eacute;gocier le m&ecirc;me nombre magique, un NAK devrait &ecirc;tre envoy&eacute; et un
nouveau nombre magique choisi.
Durand la p&eacute;riode o&ugrave; le serveur o&ugrave; le port serveur a l'ECHO activ&eacute;, le
client ppp envoie des paquets LCP, voit le m&ecirc;me nombre magique dans les
paquets refl&egrave;t&eacute;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 &eacute;norme
nombre de nombre magiques &agrave; changer, chacun d'entre eux tous
s'empilant joyeusement dans le buffer stty du serveur.
Aussit&ocirc;t que ppp d&eacute;marre sur le serveur, il est innond&eacute; par des
changement de nombre magique et souvent d&eacute;cide qu'il a assez essay&eacute;
de n&eacute;gociation LCP et abandonne.
Pendant ce temps, le client qui ne voit alors plus de r&eacute;flexions, 
se r&eacute;jouit juste le temps de voir que le serveur l'a d&eacute;connect&eacute;.

        </para>

    <para>
Cela peut-&ecirc;tre &eacute;vit&eacute; en autorisant l'autre parti &agrave; d&eacute;marrer la
n&eacute;gociation avec la ligne suivante dans le fichier ppp.conf

        <programlisting>
set openmode passive
        </programlisting>

        </para>

    <para>
Cela dit &agrave; ppp d'attendre que le serveur d&eacute;bute la n&eacute;gociation LCP.
Certains serveurs toutefois peuvent ne jamais initier la n&eacute;gociation. Si
cela est le cas, vous pouvez faire quelque chose du genre :

        <programlisting>
set openmode active 3
        </programlisting>

        </para>

    <para>
Cela dit &agrave; ppp de rester passif pendant 3 secondes, et puis commencer &agrave;
envoyer les requ&ecirc;tes LCP/ Si l'autre parti commence &agrave; envoyer des
requ&ecirc;tes durant cette p&eacute;riode, ppp r&eacute;pondra imm&eacute;diatement plut&ocirc;t qu'en
attendant que la p&eacute;riode des 3 secondes se termine.
      </para>
      </sect2>

      <sect2>
        <title> Les n&eacute;gociations LCP continuent jusqu'&agrave; ce que la connexion soit ferm&eacute;e.  </title>

    <para>
Cela est pour l'instant un d&eacute;faut d'impl&eacute;mentation dans
<emphasis remap="bf">ppp</emphasis> o&ugrave; il n'associe pas les r&eacute;ponses
LCP, CCP &amp; IPCP  avec leur requ&ecirc;te originale.
Comme cons&eacute;quence, si l'une des impl&eacute;mentations  
<emphasis remap="bf">ppp</emphasis> est  6 secondes plus lente que
l'autre c&ocirc;t&eacute;, l'autre c&ocirc;t&eacute; enverra 2 requ&ecirc;tes de configuration LCP
suppl&eacute;mentaire. Cela est fatal.

Soient 2 impl&eacute;mentations, <emphasis remap="bf">A</emphasis> et 
<emphasis remap="bf">B</emphasis>.  <emphasis remap="bf">A</emphasis> 
commence &agrave; envoyer des requ&ecirc;tes LCP imm&eacute;diatement apr&egrave;s s'&ecirc;tre connect&eacute;
et <emphasis remap="bf">B</emphasis> met 7 secondes &agrave; d&eacute;marer.
Quand <emphasis remap="bf">B</emphasis> d&eacute;marre, 
<emphasis remap="bf">A</emphasis> a envoy&eacute; 3 requ&ecirc;tes LCP.
Nous supposons que la ligne a d&eacute;sactiv&eacute;e l'ECHO, car dans le cas
contraire nous verrions des probl&egrave;mes de nombres magiques comme d&eacute;crit
dans la section pr&eacute;c&eacute;dente.

<emphasis remap="bf">B</emphasis> envoi un REQ, puis un ACK au premier
REQ de  <emphasis remap="bf">A</emphasis>.
Le r&eacute;sultat est que <emphasis remap="bf">A</emphasis> entre
dans l'&eacute;tat  <emphasis remap="bf">OPENED</emphasis> et envoie un ACK
(le premier) en retour &agrave; <emphasis remap="bf">B</emphasis>.  
Pendant ce temps, <emphasis remap="bf">B</emphasis> renvoi 2 ACK de plus
en r&eacute;ponse au 2 REQ suppl&eacute;mentaires envoy&eacute;s par
<emphasis remap="bf">A</emphasis> avant 
<emphasis remap="bf">B</emphasis> que B n'ait commenc&eacute;.
<emphasis remap="bf">B</emphasis> re&ccedil;oit alors le premier ACK
de <emphasis remap="bf">A</emphasis> et entre dans l'&eacute;tat
<emphasis remap="bf">OPENED</emphasis>.  
<emphasis remap="bf">A</emphasis> re&ccedil;oit le deuxi&egrave;me ACK de
<emphasis remap="bf">B</emphasis> et revient &agrave; l'&eacute;tat
<emphasis remap="bf">REQ-SENT</emphasis>, et envoie un autre (quatri&egrave;me)
REQ comme d&eacute;crit dans la RFC.  
Il envoie alors un troisi&egrave;me ACK et entre dans l'&eacute;tat 
<emphasis remap="bf">OPENED</emphasis>.  
Durant ce moment, <emphasis remap="bf">B</emphasis> 
re&ccedil;oit le quatri&egrave;me REQ de  <emphasis remap="bf">A</emphasis>, 
par cons&eacute;quent, revient dans l'&eacute;tat 
<emphasis remap="bf">ACK-SENT</emphasis> et envoie un autre (second)
REQ et (quatri&egrave;me) ACK as per the RFC.  
<emphasis remap="bf">A</emphasis> re&ccedil;oit le REQ, va dans l'&eacute;tat
<emphasis remap="bf">REQ-SENT</emphasis> et envoie un autre REQ.
Il re&ccedil;oit alors imm&eacute;diatement le ACK suivant et entre dans l'&eacute;tat 
<emphasis remap="bf">OPENED</emphasis>.
        </para>

    <para>
Cela continue tant qu'un des partis ne s'aper&ccedil;oive qu'ils n'iront 
nulle part comme cela et abandonne.		

        </para>

    <para>
La meilleure fa&ccedil;on d'&eacute;viter cela est de configurer un c&ocirc;t&eacute; comme &eacute;tant
<emphasis remap="bf">passif</emphasis> - cela fait, 
faire de telle sorte qu'un des c&ocirc;t&eacute;s attende que l'autre commence la
n&eacute;gociation. Cela peut-&ecirc;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&eacute;e avant que
<emphasis remap="bf">ppp</emphasis> attende de l'autre parti de 
commencer la n&eacute;gociation. 
D'une autre fa&ccedil;on, la commande
        <programlisting>
set openmode active N
        </programlisting>

(o&ugrave; <emphasis remap="bf">N</emphasis> est le nombre de secondes
qu'il faut attendre avant que le d&eacute;marrage de la n&eacute;gociation ne soit
faite). Regardez les pages de manuels pour plus de d&eacute;tails.
      </para>
      </sect2>

      <sect2>
        <title> Ppp se verrouille peu apr&egrave;s la connexion.  </title>

    <para>
Avant la version 2.2.5 de FreeBSD, il &eacute;tait possible que votre
ligne soit d&eacute;sactiv&eacute;e peu apr&egrave;s la connexion, d&ucirc;e &agrave;
une mauvaise n&eacute;gociation de compression Predictor1 de 
<emphasis remap="bf">ppp</emphasis>

Cela ne devrait arriver que si 
deux c&ocirc;t&eacute;s essayent de n&eacute;gocier des protocoles de
contr&ocirc;le de compression (
Compression Control Protocols (CCP) diff&eacute;rents.  
Ce probl&egrave;me est &agrave; pr&eacute;sent r&eacute;solu, mais si vous utilisez toujours une
vieille version de 
<emphasis remap="bf">ppp</emphasis>, 
le probl&egrave;me peut-&ecirc;tre saut&eacute; 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&eacute;cutez le <emphasis remap="tt">shell</emphasis> ou la 
commande <emphasis remap="tt">!</emphasis>, 
<emphasis remap="bf">ppp</emphasis> ex&eacute;cute un shell (ou si vous avez
pass&eacute; des arguments, <emphasis remap="bf">ppp</emphasis>
ex&eacute;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&icirc;tra
alors comme ayant &eacute;t&eacute; gel&eacute;e.
Cela parce que <emphasis remap="bf">ppp</emphasis> attend que la
commande se termine.

        </para>

    <para>
Si vous voulez ex&eacute;cuter des commandes comme cela, utilisez  plut&ocirc;t la
commande <emphasis remap="tt">!bg</emphasis>.
Cela ex&eacute;cutera la commande en arri&egrave;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&egrave;re pour que <emphasis remap="bf">ppp</emphasis> 
d&eacute;termine automatiquement qu'une connexion directe 
s'est achev&eacute;e. Cela est d&ucirc; aux lignes utilis&eacute;es dans un c&acirc;ble s&eacute;rie
null-modem. Quand on utilise cette sorte de connexion, LQR devrait 
&ecirc;tre toujours activ&eacute; avec la ligne :

        <programlisting>
enable lqr
        </programlisting>

        </para>

    <para>
LQR est accept&eacute; pas d&eacute;faut si n&eacute;goci&eacute; 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&eacute;terminer la cause et mettre en place
des filtrages d'appels (dfilters) pour pr&eacute;venir de tels appels.

        </para>

    <para>
Afin d'en d&eacute;terminer la cause, utilisez la ligne suivant :

        <programlisting>
set log +tcp/ip
        </programlisting>

        </para>

    <para>
Cela tracera tous le trafic &agrave; travers une connexion. La prochaine fois
que la connexion se mettra en place de mani&egrave;re inattendue, vous verrez
la  raison trac&eacute; avec le moment o&ugrave; cela s'est produit &agrave; c&ocirc;t&eacute;.
        </para>

    <para>
Vous pouvez &agrave; pr&eacute;sent d&eacute;sactiver les appels sous ces circonstances.
D'habitude, ces sortes de probl&egrave;mes arrivent &agrave; cause des DNS lookup.
Pour emp&ecirc;cher le DNS lookup d'&eacute;tablir une connexion (cela n'emp&ecirc;chera
<emphasis remap="bf">pas</emphasis> <emphasis remap="bf">ppp</emphasis> 
de passer les paquets &agrave; travers une connexion &eacute;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&egrave;vera effectivement vos fonctionnalit&eacute;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&eacute;seau.

        </para>

    <para>
Dans le cas DNS, vous pouvez essayer de d&eacute;terminer qui est-ce qui essaye
actuellement de r&eacute;soudre le nom de l'h&ocirc;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 &agrave; 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&eacute;tails de comment cr&eacute;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'&agrave; ce que la file soit lanc&eacute;e (habituellement, sendmail est
invoqu&eacute; avec ``-bd -q30m'', lui disant de lancer la file
d'attente toutes les 30 minutes) ou jusqu'&agrave; ce que un
``sendmail -q'' soit effectu&eacute; (peut-&ecirc;tre dans votre fichier ppp.linkup).

      </para>
      <sect2>
        <title> Que veulent dire ces erreurs CCP ?  </title>


    <para>
Je n'arr&ecirc;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&eacute;gocier la compression 
Predictor1 et que l'autre parti ne veut pas du tout n&eacute;gocier de compression.
Ces messages sont sans cons&eacute;quences aucune, mais si vous voulez les enleverm
vous pouvez d&eacute;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&eacute;ception de paquets plus grands que la taille du MTU
r&eacute;sultait en une erreur IO qui &eacute;tait alors trac&eacute; avec syslogd,
        </para>

    <para>
Les sp&eacute;cifications ppp disent qu'un MTU de 1500 devrait 
<emphasis remap="bf">toujours</emphasis> &ecirc;tre accept&eacute; 
comme un minimum, ceci
quelque soit la n&eacute;gociation LCP. Il est toutefois possible que vous
diminuez le MTU &agrave; moins de 1500, votre ISP vous transmettra des paquets
de 1500 sans s'en pr&eacute;occuper, et cela vous bloquera,
gelant ainsi la ligne.

        </para>

    <para>
Ce probl&egrave;me peut &ecirc;tre contourn&eacute; en ne r&eacute;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&ccedil;on de tracer toutes les lignes de la ``conversation'' de 
votre modem est d'activer :

        <programlisting>
set log +connect
        </programlisting>

        </para>

    <para>
Cela permettra &agrave;
<ulink url="http://www.freebsd.org/cgi/man.cgi?ppp">ppp</ulink>
de tout tracer jusqu'&agrave; la derni&egrave;re cha&icirc;ne de requ&ecirc;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&egrave;s le CONNECT
dans le script dial - pas de script "set login"), vous devez 
vous assurer que vous pr&eacute;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&ccedil;ant 
<emphasis remap="bf">ppp</emphasis> &agrave; lire  toute la r&eacute;ponse
CONNECT.

      </para></sect2>

      <sect2>
        <title>Ppp ignore le caract&egrave;re `\' dans mon script chat</title>

    <para>
Ppp parse chacune des lignes de votre fichier de configuration, de telle
sorte qu'il puisse interpr&ecirc;ter des chaines comme
<emphasis remap="tt">set phone "123 456 789"</emphasis> correctement
(et r&eacute;aliser qu'il n'y a que  <emphasis remap="bf">un</emphasis> 
seul argument.
Pour pouvoir sp&eacute;cifier un caract&egrave;re ``"'', vous devez 
l'&eacute;chapper avec un backslash (``\'').

        </para>

    <para>
Quand l'interpr&ecirc;teur chat parse chaque argument, il re-interpr&ecirc;te
l'argument de telle sorte &agrave; trouver des s&eacute;quences de caract&egrave;res
d'&eacute;chappement comme
``\P'' ou ``\T'' (voir les pages de manuel). En cons&eacute;quence de 
ce double-parsing, vous devez vous souvenir d'utiliser le nombre
correct d'&eacute;chappement.
        </para>

    <para>
Si vous voulez envoyer un caract&egrave;re ``\'' &agrave; 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&eacute;sultera en la s&eacute;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&eacute;sultera en la s&eacute;quence suivante :

        <programlisting>
ATZ
OK
ATDT1234567
        </programlisting>
      </para>
      </sect2>

      <sect2>
        <title>Ppp re&ccedil;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&ecirc;me cas) ne devrait jamais
faire de coredump. Parce que ppp tourne avec une identit&eacute; d'utilisateur
effectif de 0, le syst&egrave;me d'exploitation n'&eacute;crira pas d'image du core sur le
disque avant de l'avoir termin&eacute;. Si, malgr&egrave; tout, ppp se
<emphasis remap="bf">termine</emphasis> actuellement &agrave; 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 &ecirc;tes s&ucirc;r
que vous utilisez la derni&egrave;re version (voir le d&eacute;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&eacute;boguable de ppp install&eacute;. Vous aurez &agrave; &ecirc;tre
root pour lancer ppp puisque tous ses privil&egrave;ges auront &eacute;t&eacute; r&eacute;voqu&eacute;s. Quand
vous d&eacute;marrez ppp,  retenez soigneusement le r&eacute;pertoire courant  dans lequel
vous &eacute;tiez.

        </para>

    <para>
A pr&eacute;sent, si et quand ppp recevra une violation de segmentation, cela
cr&eacute;&eacute;ra un fichier core nomm&eacute; ppp.core. Vous aurez alors &agrave; 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 &ecirc;tre donn&eacute;es suivant votre question,
rendant ainsi possible le diagnostique de votre probl&egrave;me.
        </para>

    <para>
Si vous &ecirc;tes familier avec gdb, vous pouvez vouloir trouver d'autres 
techniques pour trouver ce qui a caus&eacute; le dump, et les adresses et
valeurs des variables concern&eacute;es.
      </para></sect2>

      <sect2>
        <title> Le processus qui force un appel en mode auto ne se connecte jamais.  </title>

    <para>
Cela est un probl&egrave;me connu quand <emphasis remap="bf">ppp</emphasis> 
est r&eacute;gl&eacute; de telle sorte &agrave; n&eacute;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&eacute;e &agrave; l'extr&ecirc;mit&eacute; de la
socket. Le noyau cr&eacute;e le premier paquet sortant et l'&eacute;crit sur le
p&eacute;riph&eacute;rique tun. <emphasis remap="bf">Ppp</emphasis> 
lit alors le paquet et &eacute;tablit alors la connexion. Si, comme
r&eacute;sultat de l'assignation dynamique de  
<emphasis remap="bf">ppp</emphasis>, 
l'adresse de l'interface est chang&eacute;e, l'extr&ecirc;mit&eacute;  originale de
la socket sera invalide. Tout paquet envoy&eacute; &agrave; l'autre parti sera alors
en principe perdu. Et m&ecirc;me s'il ne l'&eacute;tait pas, toute r&eacute;ponse ne
pourrait pas &ecirc;tre renvoy&eacute;e &agrave; la machine originelle puisque l'adresse IP
ne serait plus poss&egrave;d&eacute;e par cette machine.

        </para>

    <para>
Th&eacute;oriquement, il y a plusieurs mani&egrave;res d'aborder ce probl&egrave;me.
Le mieux serait que l'homologue re-assigne la m&ecirc;me adresse IP si 
possible <emphasis remap="tt">:-)</emphasis>

        </para>

    <para>
La meilleure m&eacute;thode de notre c&ocirc;t&eacute;, serait de ne jamais changer
l'adresse IP de l'interface tun, mais &agrave; la place, changer tous les
paquets sortant de telle sorte que les adresses IP de la source soient
chang&eacute;es de l'interface Ip &agrave; l'IP n&eacute;goci&eacute; 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&ucirc;re); est d'impl&eacute;menter
un appel syst&egrave;me qui change tous  les sockets reli&eacute;es depuis une 
adresse IP &agrave; 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&eacute;goci&eacute;e.

        </para>

    <para>

Une troisi&egrave;me possibilit&eacute; est d'autoriser &agrave; une interface de 
s'activer sans adresse IP. Les paquets sortant auront une adresse IP de
255.255.255.255 jusqu'&agrave; ce que le premier  SIOCAIFADDR ioctl soit fait.  
Cela reviendrait &agrave; lier enti&egrave;rement la socket, et
&ccedil;a serait &agrave; <emphasis remap="bf">ppp</emphasis> 
de changer l'adresse IP source, mais seulement si il est &agrave;
255.255.255.255, et seulement si le num&eacute;ro IP et le checksum IP
doivent &ecirc;tre chang&eacute;s. Quoiqu'il en soit, c'est de la
bidouille puisque le noyau enverra des paquets invalides &agrave; une
interface mal configur&eacute;e, en supposant que d'autres
m&eacute;canismes seront capables de r&eacute;parer les choses
retrospectivement.

        </para>

    <para>
Aucune de ces solutions n'a (encore) &eacute;t&eacute; impl&eacute;ment&eacute;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&eacute;s ne marchent pas avec 
libalias est que la machine ext&eacute;rieure essaye d'ouvrir une connexion
ou envoyer des paquets UDP (non sollicit&eacute;s) &agrave;  la machine 
interne. Le logiciel packet alias ne sait alors pas qu'il faut envoyer
ces paquets &agrave; une machine interne.
        </para>

    <para>
Pour que &ccedil;a marche, assurez vous que la seule chose qui tourne est le
logiciel avec lequel vous avez des probl&egrave;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&eacute;marrez le logiciel incrimin&eacute;, vous devriez voir les paquets
passer &agrave; travers la machine routeur. Quand quelque chose revient depuis
l'ext&eacute;rieur, il sera retir&eacute; (c'est &ccedil;a le probl&egrave;me). Noter le num&eacute;ro
de port de ces paquets, puis arr&ecirc;tez le logiciel incrimin&eacute;. Faite ceci
quelques fois pour voir si les num&eacute;ro de ports sont consistants. Si ils
le sont, alors la ligne suivante dans la section appropri&eacute;e de 
/etc/ppp/ppp.conf rendra le logiciel fonctionnel.

        <programlisting>
alias port proto internalmachine:port port
        </programlisting>

        </para>

    <para>
o&ugrave; ``proto'' est soit ``tcp'' ou ``udp'',
``internalmachine'' est la machine &agrave; laquelle vous voulez que les
paquets soient envoy&eacute;s et ``port'' le num&eacute;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&ecirc;me temps est hors de question - apr&egrave;s tout, le monde
ext&eacute;rieur voit tout votre r&eacute;seau entier comme une seule machine.
        </para>

    <para>
Si les num&eacute;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&eacute;ciaux'' peuvent &ecirc;tre trouv&eacute;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 &agrave; la machine
ext&eacute;rieure d'initialiser la connexion en retour vers machine interne sur un port
(al&eacute;atoire) sp&eacute;cifique, et mettre en place une 
``route'' dans la table d'alias de telle sorte que les paquets concern&eacute;s
sachent o&ugrave; 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 &eacute;vite d'avoir &agrave; 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&eacute;sesp&eacute;r&eacute; !</title>
    <para>
Si tout le reste &eacute;choue, envoyer autant d'informations que vous pouvez,
y compris vos fichiers de configuration, comment vous avez d&eacute;marr&eacute;
<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&egrave;s connexion)  &agrave; 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&eacute;er un p&eacute;riph&eacute;rique <emphasis remap="tt">/dev/ed0</emphasis> !  </title>
    <para>
Dans le cadre des r&eacute;seaux Berkeley, les interfaces r&eacute;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&eacute;rents programmes r&eacute;seaux mentionn&eacute;s
ici pour plus d'informations. Si cela vous est compl&egrave;tement confus, vous
devriez prendre un livre d&eacute;crivant l'administration r&eacute;seaux sur un autre
syst&egrave;me d'exploitation relatif &agrave; BSD; &agrave; quelques exceptions
mineures, administrer un r&eacute;seau sous FreeBSD est basiquement la
m&ecirc;me chose que sur un SunOS 4.0 ou un Ultrix.

      </para>
    </sect1>

    <sect1>
      <title>Comment puis-je r&eacute;gler les alias &eacute;thernet ?</title>

    <para>
Ajouter ``<emphasis remap="tt">netmask 0xffffffff</emphasis>'' &agrave; 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&eacute;seau ?  </title>

    <para>
Si vous voulez utiliser les autres ports, vous avez &agrave; sp&eacute;cifier un
param&ecirc;tre suppl&eacute;mentaire dans la ligne de commande
<ulink url="http://www.freebsd.org/cgi/man.cgi?ifconfig">ifconfig</ulink>. 
Le port par d&eacute;faut est``<emphasis remap="tt">link0</emphasis>''. 
Pour utiliser le port AUI &agrave; la place du BNC,utiliser 
``<emphasis remap="tt">link2</emphasis>''.  
Ces param&ecirc;tres devraient &ecirc;tre sp&eacute;cifi&eacute;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&egrave;mes avec NFS depuis/vers FreeBSD.</title>

    <para>
Certaines cartes r&eacute;seaux sont meilleures que d'autres
et peuvent causer quelquefois des probl&egrave;mes lors d'applications
r&eacute;seaux intensives comme NFS.
      </para>

    <para>
Regarder <ulink url="../handbook/nfs.html">la partie du Handbook sur NFS </ulink>pour plus d'informations &agrave; 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&ecirc;tes de montages que depuis un port privil&egrave;gi&eacute;; 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&ecirc;tes de montage que depuis un port privil&egrave;gi&eacute;; essayez

      <programlisting>
mount -o -P sunbox:/blah /mnt
      </programlisting>

      </para>
    </sect1>

    <sect1>
      <title>J'ai des probl&egrave;me pour parler PPP &agrave; des machines NeXTStep.</title>

    <para>
Essayer de d&eacute;sactiver l'extension TCP dans <ulink url="http://www.freebsd.org/cgi/man.cgi?rc.conf">/etc/rc.conf</ulink> en changeant la variable &agrave; 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&ecirc;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&eacute;rations multicast sont enti&egrave;rement support&eacute;es par FreeBSD 2.0 et
plus par d&eacute;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&eacute;marrera <emphasis remap="tt">mrouted</emphasis> au moment du boot si
l'option <emphasis remap="tt">mrouted_enable</emphasis> est mis &agrave; 
"YES" dans <emphasis remap="tt">/etc/rc.conf</emphasis>.

      </para>

    <para>
Les outils MBONE tools sont disponibles dans leur 
propre cat&eacute;gorie de ports, mbone. Si vous cherchez les outils de
conf&eacute;rence <emphasis remap="tt">vic</emphasis> et 
<emphasis remap="tt">vat</emphasis>, 
c'est l&agrave; 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&eacute;seaux sont bas&eacute;es sur le chipset DEC PCI ?</title>

    <para>
Voici une liste compil&eacute;e par
<ulink url="mailto:gfoster@driver.nsta.org">Glen Foster</ulink>, 
avec quelques ajouts r&eacute;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&ocirc;tes de mon site ?  </title>


    <para>
Vous verrez probablement que l'h&ocirc;te est actuellement dans un domaine
diff&eacute;rent; par exemple, si vous &ecirc;tes dans  foo.bar.edu 
et que vous voulez atteindre un h&ocirc;te nomm&eacute; ``mumble'' 
dans le domaine bar.edu domain, vous aurez &agrave; vous y r&eacute;f&eacute;rer 
par son nom de domaine enti&egrave;rement qualifi&eacute;, ``mumble.bar.edu'', &agrave; la place de
juste ``mumble''.

      </para>

    <para>
Traditionellement, cela &eacute;tait autoris&eacute;s par les r&eacute;solveurs 
BSD BIND. Malgr&egrave; 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&eacute;viation par d&eacute;faut 
pour un domaine non enti&egrave;rement qualifi&eacute;; autre que le domaine dans
lequel vous &ecirc;tes.
Ainsi, un h&ocirc;te non-qualifi&eacute; <emphasis remap="tt">mumble</emphasis> 
doit soit &ecirc;tre trouv&eacute; comme 
<emphasis remap="tt">mumble.foo.bar.edu</emphasis>, 
ou alors il sera cherch&eacute; dans le domaine racine.

      </para>

    <para>
Cela est diff&eacute;rent du comportement d&eacute;crit auparavant, o&ugrave; la recherche 
continuait &agrave; travers <emphasis remap="tt">mumble.bar.edu</emphasis>, 
et <emphasis remap="tt">mumble.edu</emphasis>.  
Jetez un coup d'oeil &agrave; la RFC 1535 pour savoir pourquoi cela est
consid&eacute;r&eacute; comme une mauvaise pratique, ou encore m&ecirc;me un trou de
s&eacute;curit&eacute;.
      </para>

    <para>
Comme d&eacute;tour, vous pouvez placer la ligne :
      <programlisting>
search foo.bar.edu bar.edu
      </programlisting>

      </para>

    <para>
&agrave; la place de la pr&eacute;c&eacute;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&eacute;e dans la  RFC 1535.

      </para>
    </sect1>

    <sect1>
      <title>``Permission denied'' pour toutes les op&eacute;rations r&eacute;seaux.</title>


    <para>
Si vous avez compil&eacute; votre noyau avc l'option  
<emphasis remap="tt">IPFIREWALL</emphasis>, vous devez &ecirc;tre pr&eacute;venu, que la
politique par d&eacute;faut depuis le
2.1.7R (cela a chang&eacute; durant le d&eacute;veloppement 
du 2.1-STABLE) est de refuser tous les paquets qui ne sont pas
explicitement autoris&eacute;s.
      </para>

    <para>
Si vous avez inintentionnellement mal configur&eacute; votre syst&egrave;me pour le
firewall, vous pouvez r&eacute;tablir les fonctionnalit&eacute; r&eacute;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&eacute;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&eacute;ponse &agrave; ceci d&eacute;pend pour la plupart &agrave; votre ensemble de r&egrave;gle et &agrave;
votre vitesse de processeur. Pour la plupart des applications 
utilisant ethernet et de petits ensembles de r&egrave;gles, la r&eacute;ponse est :
n&eacute;gligeable. Pour tous ceux d'entre vous qui veulent des mesures
actuelles pour satisfaire leur curiosit&eacute;, continuez &agrave; lire :

      </para>

    <para>
Les mesures suivantes ont &eacute;t&eacute; r&eacute;alis&eacute;es en utilisant 2.2.5-STABLE sur
un 486-66.  IPFW a &eacute;t&eacute; modifi&eacute; pour mesurer le temps &eacute;coul&eacute; par
l'interm&eacute;diaire de la routine <emphasis remap="tt">ip_fw_chk</emphasis>
en affichant les r&eacute;sultats sur la console tous les 1000 paquets.

      </para>

    <para>
2 ensembles de r&egrave;gles, chacun avec 1000 r&egrave;gles ont &eacute;t&eacute; test&eacute;s.
Le premier ensemble a &eacute;t&eacute; con&ccedil;u pour d&eacute;montrer le sc&eacute;nario du pire des
cas en r&eacute;p&eacute;tant la r&egrave;gle :

      <programlisting>
ipfw add deny tcp from any to any 55555
      </programlisting>

      </para>

    <para>
Cela d&eacute;montre le pire des cas en faisant que chaque paquet IPFW entraine l'ex&eacute;cution de 
la routine de v&eacute;rification qui finallement d&eacute;cide que le
paquet ne correspond pas aux r&egrave;gles (en vertu du num&eacute;ro de port)?
Ap&egrave;s la 999eme it&eacute;ration de cette r&egrave;gle, il y avait un
<emphasis remap="tt">allow ip from any to any</emphasis>.

      </para>

    <para>
Le second ensemble de r&egrave;gles a &eacute;t&eacute; con&ccedil;u pour annuler la v&eacute;rification de
r&egrave;gle tr&egrave;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&egrave;gles &eacute;nonc&eacute;es
ci-dessus font que ces r&egrave;gles sont saut&eacute;es tr&egrave;s rapidement. Comme
auparavant, la 1000eme r&egrave;gle &eacute;tait un 
<emphasis remap="tt">allow ip from any to any</emphasis>.

      </para>

    <para>
L'&eacute;tude par paquet dans le premier cas a &eacute;t&eacute; approximativement de 
2.703ms/paquet, soit en gros 2.7 microseconds par r&egrave;gle
.  
Ainsi, la limite th&eacute;orique d'&eacute;tude de paquet avec ces r&egrave;gles est de 370
paquets par secondes. En supposant un &eacute;thernet 10Mbps et des paquets
d'environ 1500 bytes, nous ne pourrons &ecirc;tre capable que d'obtenir une
utilisation de la bande passante de 55.5%
      </para>

    <para>
Pour le dernier cas, chaque paquet a &eacute;t&eacute; &eacute;tudi&eacute; en approximativement 
1.172ms, soit en gros 1.2 microseconds par r&egrave;gle.
La limite th&eacute;orique de l'&eacute;tude des paquets ici, serait d'environ de 853
paquets par secondes, ce qui pourrait consommer une bande passante 
d'un &eacute;thernet 10Mbps.

      </para>

    <para>
Le nombre excessif de r&egrave;gle test&eacute;s, et la nature de ces r&egrave;gles ne
fournissent pas un sc&eacute;nario du monde r&eacute;el -- ils ont &eacute;t&eacute; utilis&eacute;s que
pour g&eacute;n&eacute;rer les informations de temps pr&eacute;sent&eacute;s ici.Voici certaines
choses &agrave; garder &agrave; l'esprit pour construire un ensemble de r&egrave;gles
efficaces : 

      <itemizedlist>

        <listitem>
		<para>
Placer une r&egrave;gle d'`&eacute;tablissement' tr&egrave;s t&ocirc;t afin de pouvoir 
g&eacute;rer la majorit&eacute; du trafic TCP. Ne  mettre aucun 
<emphasis remap="tt">allow tcp</emphasis>
avant cette r&egrave;gle.
		</para>
		</listitem>

        <listitem>
		<para>
Placer les r&egrave;gles souvent sollicit&eacute;es le plus au d&eacute;but de l'ensemble
des r&egrave;gles plut&ocirc;t que celles rarement utilis&eacute;es
(<emphasis remap="bf">sans changer la permissivit&eacute; du firewall </emphasis>, bien s&ucirc;r).  
Vous pourrez voir quels sont  les r&egrave;gles les plus souvent utilis&eacute;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&ecirc;tes de services d'une machine vers une autre ?  </title>

    <para>
Vous pouvez rediriger des requ&ecirc;tes FTP (et autre services) avec le
paquetage 'socket', disponible dans l'arbre des ports dans la cat&eacute;gorie
'sysutils'.  Remplacer simplement la ligne de commande de
service pour appeler socket &agrave; la place, ainsi:

<programlisting>
ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp
</programlisting>

      </para>

    <para>
o&ugrave; 'ftp.foo.com' et 'ftp' sont les h&ocirc;tes et les ports o&ugrave; se diriger
respectivement.
      </para>
    </sect1>
  </chapter>

