FreeBSD Bugzilla – Attachment 22448 Details for
Bug 38943
French translation of filtering-bridges article
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Help
|
New Account
|
Log In
Remember
[x]
|
Forgot Password
Login:
[x]
[patch]
articles.diff
articles.diff (text/plain), 25.32 KB, created by
Marc Fonvieille
on 2002-06-06 13:10:01 UTC
(
hide
)
Description:
articles.diff
Filename:
MIME Type:
Creator:
Marc Fonvieille
Created:
2002-06-06 13:10:01 UTC
Size:
25.32 KB
patch
obsolete
>diff -ruN articles.org/filtering-bridges/Makefile articles/filtering-bridges/Makefile >--- articles.org/filtering-bridges/Makefile Thu Jan 1 01:00:00 1970 >+++ articles/filtering-bridges/Makefile Mon Jun 25 17:04:01 2001 >@@ -0,0 +1,13 @@ >+ >+DOC?= article >+ >+FORMATS?= html >+ >+INSTALL_COMPRESSED?=gz >+INSTALL_ONLY_COMPRESSED?= >+ >+SRCS= article.sgml >+ >+DOC_PREFIX?= ${.CURDIR}/../../.. >+ >+.include "${DOC_PREFIX}/share/mk/doc.project.mk" >diff -ruN articles.org/filtering-bridges/article.sgml articles/filtering-bridges/article.sgml >--- articles.org/filtering-bridges/article.sgml Thu Jan 1 01:00:00 1970 >+++ articles/filtering-bridges/article.sgml Thu Jun 6 13:46:30 2002 >@@ -0,0 +1,483 @@ >+<!-- >+ The FreeBSD Project - http://www.FreeBSD.org >+ The FreeBSD French Documentation Project >+ >+ $FreeBSD$ >+ $Id$ >+ Original revision: 1.10 >+--> >+<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [ >+<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN"> >+%man; >+<!ENTITY % abstract PUBLIC "-//FreeBSD//ENTITIES DocBook Abstract Entities//FR"> %abstract; >+<!ENTITY % artheader PUBLIC "-//FreeBSD//ENTITIES DocBook ArtHeader Entities//FR"> %artheader; >+<!ENTITY % translators PUBLIC "-//FreeBSD//ENTITIES DocBook Translator Entities//FR"> %translators; >+<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN"> >+%man; >+]> >+ >+<article> >+ <articleinfo> >+ <title>Ponts filtrants</title> >+ >+ <authorgroup> >+ <author> >+ <firstname>Alex</firstname> >+ <surname>Dupre</surname> >+ <affiliation> >+ <address><email>sysadmin@alexdupre.com</email></address> >+ </affiliation> >+ </author> >+ </authorgroup> >+ >+ <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/filtering-bridges/article.sgml,v 1.10 2002/06/05 22:09:07 keramida Exp $</pubdate> >+ >+ <abstract> >+ <para>Souvent il est utile de diviser un réseau physique (comme un >+ réseau Ethernet) en deux segments séparés sans >+ avoir a créer des sous-réseaux, et utiliser de routeur >+ pour les relier ensemble. Le dispositif qui connecte les deux >+ réseaux de cette manière est >+ appelé un pont. Un système FreeBSD avec deux cartes >+ réseau est suffisant pour jouer le rôle d'un pont.</para> >+ >+ <para>Un pont fonctionne en scannant les adresses au niveau >+ <acronym>MAC</acronym> (adresses Ethernet) des cartes connectées >+ à chacune de ses interfaces réseau et puis >+ transfère le trafic entre les deux réseaux si la >+ source et la destination sont situés sur un segment >+ différent. Sous beaucoup de points de vue >+ un pont est similaire à un commutateur (switch) Ethernet avec >+ uniquement deux ports.</para> >+ &abstract.license; >+ &abstract.disclaimer; >+ &trans.a.fonvieille; >+ </abstract> >+ </articleinfo> >+ >+ <sect1 id="filtering-bridges-why"> >+ <title>Pourquoi utiliser un pont filtrant?</title> >+ >+ <para>De plus en plus fréquemment, grâce à la >+ baisse des coûts des connexions Internet haut débit >+ (xDSL) et aussi en raison de la réduction des adresses >+ IPv4 disponibles, beaucoup de compagnies >+ sont connectées à l'Internet 24 heures sur 24 et >+ avec peu (parfois même pas une puissance de 2) d'adresses IP. >+ Dans ces situations il est souvent désirable d'avoir un >+ coupe-feu qui filtre le trafic >+ entrant et sortant depuis et vers l'Internet, mais la solution >+ d'un filtrage de paquet basé sur un routeur peut ne pas >+ être applicable, soit en raison de problèmes de >+ sous-réseau, le routeur appartient au fournisseur >+ d'accès (<acronym>ISP</acronym>), ou >+ parce qu'il ne supporte pas une telle fonction. Dans ces >+ scénarios l'utilisation d'un pont filtrant est fortement >+ conseillée.</para> >+ >+ <para>Un coupe-feu basé sur un pont peut être >+ configuré et inséré >+ entre le routeur xDSL et votre concentrateur/commutateur Ethernet >+ sans aucun problème d'adresse d'IP.</para> >+ </sect1> >+ >+ <sect1 id="filtering-bridges-how"> >+ <title>Comment l'installer</title> >+ >+ <para>Ajouter les fonctions de pont à un système >+ FreeBSD n'est pas difficile. Depuis la 4.5-RELEASE il est possible >+ de charger de telles fonctionnalités sous forme de module >+ au lieu d'avoir à recompiler le noyau, simplifiant >+ énormément la procédure. Dans >+ les sous-sections suivantes j'expliquerai les deux méthodes >+ d'installation.</para> >+ >+ <important> >+ <para><emphasis>Ne pas</emphasis> suivre les deux méthodes: une >+ procédure <emphasis>exclue</emphasis> l'autre. Choisissez la >+ meilleure en fonction de vos besoins et capacités.</para> >+ </important> >+ >+ <para>Avant d'aller plus loin, soyez sûr de disposer deux cartes >+ Ethernet qui supportent le mode promiscuous pour la réception et >+ la transmission, comme elles doivent être capable d'envoyer des >+ paquets Ethernet avec n'importe quelle adresse, et non pas juste >+ pour la leur. De plus, pour avoir de bonnes performances, les >+ cartes devront être capable contrôler le bus >+ PCI (PCI bus mastering). Les meilleurs choix sont toujours >+ l'Intel EtherExpress Pro, suivie de la série 3c9xx de chez 3Com. >+ Pour simplifier la configuration il peut être utile d'avoir deux >+ cartes de différents constructeurs (utilisant un pilote de >+ périphérique différent) afin de distinguer >+ clairement quelle interface est connectée au routeur et >+ quelle autre est connectée au réseau.</para> >+ >+ <sect2 id="filtering-bridges-kernel"> >+ <title>Configuration du noyau</title> >+ >+ <para>Donc vous avez décidé d'utiliser la bonne >+ vieille méthode d'installation. Pour commencer, vous >+ devez ajouter les lignes suivantes à votre fichier de >+ configuration du noyau:</para> >+ >+ <programlisting>options BRIDGE >+options IPFIREWALL >+options IPFIREWALL_VERBOSE</programlisting> >+ >+ <para>La première ligne est pour compiler le support du pont, la >+ seconde est le coupe-feu et la troisième sont les fonctions de >+ traces du coupe-feu.</para> >+ >+ <para>Maintenant il est nécessaire de compiler et d'installer le >+ nouveau noyau. Vous pourrez trouver des instructions >+ détaillée dans la section <ulink >+ url="../../books/handbook/kernelconfig-building.html">Compiler >+ et installer un noyau sur mesures</ulink> du Manuel de >+ FreeBSD.</para> >+ </sect2> >+ >+ <sect2 id="filtering-bridges-modules"> >+ <title>Le chargement de modules</title> >+ >+ <para>Si vous avez choisi d'employer cette méthode nouvelle et >+ plus simple; la seule chose à faire maintenant est d'ajouter la >+ ligne suivante au fichier >+ <filename>/boot/loader.conf</filename>:</para> >+ >+ <programlisting>bridge_load="YES"</programlisting> >+ >+ <para>De cette façon, durant le démarrage du >+ système le module <filename>bridge.ko</filename> sera >+ chargé avec le noyau. Il n'est pas nécessaire >+ de rajouter une ligne pour le module >+ <filename>ipfw.ko</filename>, étant donné qu'il >+ sera chargé automatiquement après >+ l'exécution des étapes présentées dans la >+ section suivante.</para> >+ </sect2> >+ </sect1> >+ >+ <sect1 id="filtering-bridges-finalprep"> >+ <title>Dernière préparation</title> >+ >+ <para>Avant de redémarrer afin de charger le nouveau noyau ou les >+ modules nécessaires (selon la méthode d'installation >+ précédemment retenue), vous devez faire quelques >+ modifications dans le fichier >+ de configuration <filename>/etc/rc.conf</filename>. La règle de >+ défaut du coupe-feu est de rejeter tous les paquets IP. Au >+ départ nous configurerons un coupe-feu “ouvert”, afin >+ de vérifier son fonctionnement sans problème relatif au >+ filtrage de paquet (dans le cas où vous faite cela à >+ distance, une telle configuration vous évitera de rester >+ isolé du réseau). Ajoutez les lignes suivantes dans >+ <filename>/etc/rc.conf</filename>:</para> >+ >+ <programlisting>firewall_enable="YES" >+firewall_type="open" >+firewall_quiet="YES" >+firewall_logging="YES"</programlisting> >+ >+ <para>La première ligne activera le coupe-feu (et chargera le module >+ <filename>ipfw.ko</filename> s'il n'est pas compilé dans le >+ noyau), la seconde le configurera dans le mode >+ “ouvert” (comme expliqué dans >+ <filename>/etc/rc.firewall</filename>), la troisième ligne rendra >+ le chargement des règles silencieux (sans affichage) et la >+ quatrième activera le support de trace d'activité >+ du coupe-feu.</para> >+ >+ <para>Au sujet de la configuration des interfaces réseau, la >+ méthode la plus utilisée est d'assigner une adresse >+ IP à une seul des cartes réseau, mais le pont >+ fonctionnera à l'identique si les deux >+ interfaces ou aucune n'ont d'adresse IP configurée. Dans le >+ dernier cas (sans adresse IP) la machine faisant office de pont >+ sera toujours cachée et inaccessible depuis le réseau: >+ pour la configurer, vous devez vous attacher depuis la console ou >+ à travers une troisième interface réseau >+ séparée du pont. Parfois, durant >+ le démarrage du système, certains programmes ont >+ besoin d'accéder au réseau, par exemple pour la >+ résolution de noms: dans ce cas il >+ est nécessaire d'assigner une adresse IP à >+ l'interface externe (celle connectée à l'Internet >+ où le serveur <acronym>DNS</acronym> >+ réside), puisque le pont sera activé à la >+ fin de la procédure de démarrage. Cela signifie que >+ l'interface <devicename>fxp0</devicename> (dans notre cas) doit >+ être mentionnée dans la section concernant ifconfig >+ du fichier <filename>/etc/rc.conf</filename>, mais pas >+ <devicename>xl0</devicename>. Assigner une adresse IP aux deux >+ cartes réseau n'a pas beaucoup de sens, à moins que, >+ durant la procédure de démarrage, des applications >+ devront accéder à des >+ services sur les deux segments Ethernet.</para> >+ >+ <para>Il y a une autre chose importante à savoir. Quand on utilise >+ l'IP sur Ethernet, il y a en fait deux protocoles Ethernet >+ utilisés: l'un est l'IP, l'autre est l'<acronym>ARP</acronym>. >+ <acronym>ARP</acronym> effectue la conversion de l'adresse IP d'un >+ hôte en son adresse Ethernet (couche <acronym>MAC</acronym>). >+ Afin d'autoriser la communication entre deux hôtes >+ séparés par le >+ pont, il est nécessaire que le pont transmette les paquets >+ <acronym>ARP</acronym>. Un tel protocole n'est pas inclut dans la >+ couche IP, puisque qu'il n'apparaît qu'avec l'utilisation de l'IP >+ sur Ethernet. Le coupe-feu de FreeBSD filtre exclusivement la >+ couche IP et donc tous les paquets non-IP (<acronym>ARP</acronym> >+ compris) seront transmis sans être filtrés, même >+ si le coupe-feu est configuré pour ne rien laisser passer.</para> >+ >+ <para>Il est maintenant temps de redémarrer le système et de >+ l'utiliser comme auparavant: il y aura de nouveau messages >+ concernant le pont et le coupe-feu, mais le pont ne sera pas >+ activé et le coupe-feu, étant en mode “ouvert”, >+ n'interdira aucune opération.</para> >+ >+ <para>Si il y a un quelconque problème, vous devriez le corriger >+ maintenant avant de continuer.</para> >+ </sect1> >+ >+ <sect1 id="filtering-bridges-enabling"> >+ <title>Activer le pont</title> >+ >+ <para>A ce point, pour activer le pont, vous devez exécuter les >+ commandes suivantes (en pensant bien de remplacer les noms des deux >+ interfaces réseau <devicename>fxp0</devicename> et >+ <devicename>xl0</devicename> avec les vôtres):</para> >+ >+ <screen>&prompt.root; <userinput>sysctl net.link.ether.bridge_cfg=fxp0:0,xl0:0</userinput> >+&prompt.root; <userinput>sysctl net.link.ether.bridge_ipfw=1</userinput> >+&prompt.root; <userinput>sysctl net.link.ether.bridge=1</userinput></screen> >+ >+ <para>La première ligne spécifie quelles interfaces >+ devront être activées par le pont, la seconde >+ activera le coupe-feu sur le pont >+ et enfin la troisième activera le pont.</para> >+ >+ <para>A ce moment là, vous devriez être en mesure >+ d'insérer la machine entre deux ensembles d'hôtes >+ sans compromettre de capacités de communication entre eux. >+ Ensuite, l'étape suivante est d'ajouter les parties >+ <literal>net.link.ether.<replaceable>[bla]</replaceable>=<replaceable>[bla]</replaceable></literal> >+ de ces lignes dans le fichier >+ <filename>/etc/sysctl.conf</filename> afin de les exécuter au >+ démarrage.</para> >+ </sect1> >+ >+ <sect1 id="filtering-bridges-ipfirewall"> >+ <title>Configurer le coupe-feu</title> >+ >+ <para>Il est maintenant temps de créer votre propre fichier de >+ règle personnalisé pour le coupe-feu, afin de >+ sécuriser le réseau >+ interne. Il y aura quelques complication à faire cela parce que >+ toute les fonctionnalités du coupe-feu ne sont pas disponibles sur >+ un pont. En outre, il y a une différence entre les paquets qui >+ sont en cours de transmission et les paquets qui sont reçus par la >+ machine locale. En général, les paquets entrants >+ traversent le coupe-feu une seule fois, et pas deux comme c'est >+ normalement le cas; en fait ils sont filtrés à la >+ réception, aussi les règles qui >+ utilisent “out” ou “xmit” n'agirons >+ jamais. Personnellement, j'utilise “in via” qui est >+ une ancienne syntaxe, mais qui a un sens quand vous la lisez. Une >+ autre limitation est que vous êtes réduit à >+ l'utilisation seulement des commandes “pass” ou >+ “drop” pour les paquets filtrés par un pont. >+ Les choses sophistiquées comme “divert”, >+ “forward” ou “reject” ne sont pas >+ disponibles. De telles options peuvent toujours être >+ utilisées, mais uniquement sur le trafic à >+ destination ou depuis le pont lui-même (s'il possède >+ une adresse IP).</para> >+ >+ <para>Une nouveauté de FreeBSD 4.0, est le concept de filtrage avec >+ gestion des états (stateful). C'est une grande >+ amélioration pour le trafic <acronym>UDP</acronym>, qui >+ typiquement est une requête de sortie, suivie peu de temps >+ après par une réponse avec le même ensemble >+ d'adresses IP et de numéro de ports (mais avec >+ une source et une destination réservée, bien sûr). >+ Pour les coupe-feux qui n'ont pas de gestion des états, >+ il n'y a presque pas de possibilité de gérer ce type >+ de trafic en une seule session. Mais avec un coupe-feu qui peut se >+ “souvenir” d'un paquet <acronym>UDP</acronym> sortant et >+ qui, pour quelques minutes, autorise une réponse, la gestion >+ des services <acronym>UDP</acronym> est triviale. L'exemple suivant >+ montre comment le faire. Il est possible de faire la même >+ chose avec les paquets <acronym>TCP</acronym>. Cela vous permet >+ d'éviter certaines attaques par refus de service et autres >+ désagréables problèmes, mais augmente >+ également rapidement la taille de votre >+ table des états.</para> >+ >+ <para>Regardons un exemple de configuration. Notez tout d'abord >+ qu'au début du fichier <filename>/etc/rc.firewall</filename> >+ il y a déjà des règles standards pour >+ l'interface de boucle locale >+ <devicename>lo0</devicename>, aussi nous ne devrions pas y faire >+ attention. Les règles personnalisées devraient >+ être placées dans un fichier séparé (disons >+ <filename>/etc/rc.firewall.local</filename>) et chargées au >+ démarrage du système, en modifiant la ligne de >+ <filename>/etc/rc.conf</filename> où nous avions défini le >+ coupe-feu “ouvert”:</para> >+ >+ <programlisting>firewall_type="/etc/rc.firewall.local"</programlisting> >+ >+ <important> >+ <para>Vous devez préciser le chemin <emphasis>complet</emphasis>, >+ sinon il ne sera pas chargé avec le risque de rester >+ isolé du réseau.</para> >+ </important> >+ >+ <para>Pour notre exemple imaginez que nous avons l'interface >+ <devicename>fxp0</devicename> connectée vers l'extérieur >+ (Internet) et l'interface <devicename>xl0</devicename> vers >+ l'intérieur (<acronym>LAN</acronym>). Le pont possède >+ une adresse IP <hostid role="ipaddr">1.2.3.4</hostid> (il n'est pas >+ possible que votre fournisseur d'accès puisse vous donner une >+ adresse de classe A comme celle-ci, mais pour cet exemple cela >+ ira).</para> >+ >+ <programlisting># Les choses dont nous avons gardé l'état avant de >+continuer >+add check-state >+ >+# Rejeter les réseaux RFC 1918 >+add drop all from 10.0.0.0/8 to any in via fxp0 >+add drop all from 172.16.0.0/12 to any in via fxp0 >+add drop all from 192.68.0.0/16 to any in via fxp0 >+ >+# Autorise la machine pont à communiquer si elle le désire >+# (si la machine est sans adresse IP, ne pas inclure ces lignes) >+add pass tcp from 1.2.3.4 to any setup keep-state >+add pass udp from 1.2.3.4 to any keep-state >+add pass ip from 1.2.3.4 to any >+ >+# Autorise les hôtes internes à communiquer >+add pass tcp from any to any in via xl0 setup keep-state >+add pass udp from any to any in via xl0 keep-state >+add pass ip from any to any in via xl0 >+ >+# Section TCP >+# Autoriser SSH >+add pass tcp from any to any 22 in via fxp0 setup keep-state >+# Autoriser SMTP seulement vers le serveur de courrier >+add pass tcp from any to relay 25 in via fxp0 setup keep-state >+# Autoriser le transfert de zone seulement par le serveur de noms esclave [dns2.nic.it] >+add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state >+# Laisser passer les sondes d'ident. C'est préférable plutôt que d'attendre >+# qu'elles s'arrêtent >+add pass tcp from any to any 113 in via fxp0 setup keep-state >+# Laisser passer la zone de "quarantaine" >+add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state >+ >+# Section UDP >+# Autorise le DNS seulement vers le serveur de noms >+add pass udp from any to ns 53 in via fxp0 keep-state >+# Laisser passer la zone de "quarantaine" >+add pass udp from any to any 49152-65535 in via fxp0 keep-state >+ >+# Section ICMP >+# Laisser passer 'ping' >+add pass icmp from any to any icmptypes 8 keep-state >+# Laisser passer les messages d'erreurs générés par 'traceroute' >+add pass icmp from any to any icmptypes 3 >+add pass icmp from any to any icmptypes 11 >+ >+# Tout le reste est suspect >+add drop log all from any to any</programlisting> >+ >+ <para>Ceux qui parmi vous ont déjà installé >+ des coupe-feux auparavant pourront noter l'absence de certaines >+ choses. En particulier, il n'y a pas de règles contre le >+ forgeage d'adresses, en fait nous n'avons <emphasis>pas</emphasis> >+ ajouté:</para> >+ >+ <programlisting>add deny all from 1.2.3.4/8 to any in via fxp0</programlisting> >+ >+ <para>Cela, bloque les paquets provenant de l'extérieur et clamant >+ être en provenance de votre réseau. C'est quelque chose >+ que vous devriez habituellement faire pour être sûr que >+ personne n'essaie de passer outre votre filtre de paquet, en >+ générant d'infames paquets qui sont comme s'il venaient >+ de l'intérieur. Le problème >+ avec cela est qu'il y a <emphasis>au moins</emphasis> un hôte de >+ l'extérieur que vous ne voulez pas ignorer: le routeur. Mais >+ habituellement, les fournisseurs d'accès contrent le forgeage sur >+ leur routeur, aussi nous ne devons pas nous en préoccuper plus que >+ cela.</para> >+ >+ <para>La dernière règle semble être une copie >+ conforme de la règle par défaut, qui ne laisse passer >+ rien de ce qui n'est pas spécifiquement autorisé. Mais >+ il y a une différence: tout le >+ trafic suspect sera tracé.</para> >+ >+ <para>Il y a deux règles pour faire passer le trafic >+ <acronym>SMTP</acronym> et <acronym>DNS</acronym> vers le serveur >+ de courrier et le serveur de noms, si vous en avez. Evidemment >+ l'ensemble du jeu de règle devra être arrangé >+ selon vos goûts >+ personnels, c'est juste un exemple particulier (le format des >+ règles est décrit précisément dans la >+ page de manuel &man.ipfw.8;). Notez qu'afin que “relay” et >+ “ns” puissent fonctionner, les services de résolution >+ de nom doivent fonctionner <emphasis>avant</emphasis> que le pont >+ soit activé. C'est un exemple pour être sûr que >+ vous avez configuré l'adresse IP sur la bonne carte >+ réseau. Alternativement >+ il est possible de spécifier l'adresse IP au lieu du nom >+ (nécessaire si la machine est sans adresse IP).</para> >+ >+ <para>Les personnes qui ont l'habitude de configurer des coupe-feux >+ ont probablement également utilisé soit une règle >+ “reset” soit une règle “forward” pour les >+ paquets ident (<acronym>TCP</acronym> port 113). Malheureusement, >+ ce n'est pas une option applicable avec un pont, aussi la >+ meilleure solution est de laisser les passer vers leur >+ destination. Aussi longtemps que la machine de destination de >+ fait pas tourner un daemon d'ident, cela est relativement >+ inoffensif. L'alternative est de bloquer les connexions sur le >+ port 113, ce qui pose problème avec des services comme >+ l'<acronym>IRC</acronym> (la sonde d'ident doit s'arrêter).</para> >+ >+ <para>La seule autre chose qui est un peu étrange que vous avez >+ peut-être noté est qu'il y a une règle pour >+ laisser le pont communiquer, et une autre pour les hôtes >+ internes. Rappelez-vous que c'est parce que les deux ensembles de >+ trafic prendront un chemin différent à travers le noyau >+ et dans le filtre de paquet. Le réseau interne ira à >+ travers le pont, alors que la machine >+ locale utilisera la pile IP normale pour communiquer. Ainsi les >+ deux règles s'occupent de cas différents. La >+ règle “in via <devicename>fxp0</devicename>” >+ fonctionne pour les deux chemins. En général, si >+ vous employez des règles “in via” dans tous le >+ filtre, vous devrez faire une exception pour les paquets >+ générés localement, parce qu'ils ne sont pas >+ passés par une de nos interfaces.</para> >+ </sect1> >+ >+ <sect1 id="filtering-bridges-contributors"> >+ <title>Participants</title> >+ >+ <para>Plusieurs parties de cet article proviennent, et furent mises >+ à jour et adaptées d'un vieux texte sur les ponts, >+ écrit par Nick Sayer. Cet article est également >+ inspiré d'une introduction sur les ponts >+ de Steve Peterson.</para> >+ >+ <para>Un grand merci à Luigi Rizzo pour l'implémentation >+ du code de pont dans FreeBSD et pour le temps qu'il a passé >+ à répondre à toutes >+ mes questions à ce sujet.</para> >+ >+ <para>Un remerciement également à Tom Rhodes qui a >+ supervisé mon travail de traduction de l'Italien (langue >+ d'origine de cet article) à l'Anglais.</para> >+ </sect1> >+</article>
<b>You cannot view the attachment while viewing its details because your browser does not support IFRAMEs. <a href="attachment.cgi?id=22448">View the attachment on a separate page</a>.</b>
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 38943
: 22448