[OpenBSD]

[Index de la FAQ] [Section 5 - Construire le Système à partir des Sources] [Section 7 - Contrôles du clavier et de l'affichage]

6 - Le réseau

Table des matières

6.1 - Avant d'aller plus loin

Afin de mieux comprendre ce document, vous devriez lire et assimiler au moins partiellement la section Construire le Système à partir des Sources de la FAQ ainsi que le manuel ifconfig(8) et netstat(1).

Si vous êtes administrateur de réseau et que vous mettez en place des protocoles de routage, si vous utilisez OpenBSD en tant que routeur, ou si vous souhaitez en savoir plus sur les réseaux IP, vous devriez lire " Understanding IP Addressing" (Comprendre l'adressage IP). Il s'agit d'un excellent document. Vous pouvez vous appuyer sur celui-ci afin de vous aider à travailler sur les réseaux IP, surtout si vous en avez un ou plusieurs sous votre responsabilité.

Si vous travaillez sur des applications telles que des serveurs web, des serveurs ftp et des serveurs de messagerie, vous pourriez bénéficier de la lecture des RFCs. A priori, vous ne pourrez pas toutes les lire. Choisissez les sujets qui vous intéressent ou les technologies que vous utilisez sur votre réseau. Lisez-les et voyez comment ces technologies fonctionnent. Les RFCs standardisent beaucoup (plusieurs milliers) de protocoles Internet et la façon dont ils sont censés fonctionner.

6.2 - Configuration du réseau

Normalement, OpenBSD est configuré initialement durant la procédure d'installation. Cependant il est intéressant de comprendre ce qui se passe pendant cette procédure et la façon dont cela fonctionne. Toute la configuration réseau est effectuée en utilisant de simples fichiers texte sous le répertoire /etc.

6.2.1 - Identifier et configurer vos interfaces réseau

Sous OpenBSD, les interfaces sont nommées en fonction du type de la carte réseau, et non en fonction du type de la connexion. Vous pouvez voir l'initialisation de votre carte pendant la procédure de démarrage, ou après celle-ci en utilisant la commande dmesg(8) . Vous avez aussi la possibilité de voir votre carte réseau grâce à l'utilisation de la commande ifconfig(8). Voici par exemple la sortie de la commande dmesg pour une carte Intel Fast Ethernet qui utilise le nom de périphérique fxp.

fxp0 at pci0 dev 10 function 0 "Intel 82557" rev 0x0c: irq 5, address 00:02:b3:2b:10:f7 inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4

Si vous ne connaissez pas le nom du périphérique associé à votre carte, regardez dans la liste des plates-formes actuellement supportées par votre architecture. Vous pourrez y trouver le nom des cartes les plus courantes et leur équivalent sous OpenBSD. Ajoutez au nom alphabétique du périphérique (par exemple fxp) le numéro assigné par le noyau et vous aurez le nom de votre interface (par exemple fxp0). Le chiffre est attribué selon plusieurs critères dépendant du type de carte et d'autres détails du système. Certaines cartes se voient assigner un chiffre selon l'ordre dans lequel elles ont été détectées au démarrage et d'autres selon la configuration des ressources matérielles ou de l'adresse MAC.

Vous pouvez connaître quelles interfaces réseaux ont été identifiées à l'aide de l'utilitaire ifconfig(8). La commande suivante montrera toutes les interfaces réseau d'un système. Cet exemple montre qu'il n'y a qu'une seule interface Ethernet physique : fxp(4) .

$ ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 lo1: flags=8008<LOOPBACK,MULTICAST> mtu 33224 fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 address: 00:04:ac:dd:39:6a media: Ethernet autoselect (100baseTX full-duplex) status: active inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::204:acff:fedd:396a%fxp0 prefixlen 64 scopeid 0x1 pflog0: flags=0<> mtu 33224 pfsync0: flags=0<> mtu 2020 sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296 sl1: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296 ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 ppp1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 tun0: flags=10<POINTOPOINT> mtu 3000 tun1: flags=10<POINTOPOINT> mtu 3000 enc0: flags=0<> mtu 1536 bridge0: flags=0<> mtu 1500 bridge1: flags=0<> mtu 1500 vlan0: flags=0<> mtu 1500 address: 00:00:00:00:00:00 vlan1: flags=0<> mtu 1500 address: 00:00:00:00:00:00 gre0: flags=9010<POINTOPOINT,LINK0,MULTICAST> mtu 1450 carp0: flags=0<> mtu 1500 carp1: flags=0<> mtu 1500 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 gif1: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 gif2: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 gif3: flags=8010<POINTOPOINT,MULTICAST> mtu 1280

Comme vous pouvez le voir, ifconfig(8) nous fourni ici beaucoup plus d'informations que nécessaire. Mais nous pouvons tout de même voir notre interface. Dans l'exemple précédent, la carte est déjà configurée. Ceci est évident de part la présence d'une configuration réseau IP pour fxp0, à savoir "inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255". Les indicateurs UP et RUNNING sont également présents.

Finalement, vous noterez que d'autres interfaces sont activées par défaut. Il s'agit d'interfaces virtuelles servant différentes fonctions. Les manuels suivants les décrivent :

L'interface est configurée au démarrage en utilisant les fichiers /etc/hostname.if(5) où if est remplacé par le nom complet de votre interface, c'est à dire dans notre exemple: /etc/hostname.fxp0.

Le format de ce fichier est simple :

address_family address netmask broadcast [autres options]
Beaucoup plus d'informations sur la syntaxe de ce fichier sont disponibles dans le manuel hostname.if(5). Vous devrez le lire si vous avez besoin de configurations moins triviales.

Un fichier de configuration typique pour une interface IPv4 ressemblera à :

$ cat /etc/hostname.fxp0 inet 10.0.0.38 255.255.255.0 NONE

Dans ce cas, nous avons défini une adresse IPv4 (inet), avec une adresse IP de 10.0.0.38, un masque de sous-réseau de 255.255.255.0 et pas d'adresse de broadcast spécifique (qui sera mise par défaut à 10.0.0.255 dans notre cas).

Vous pouvez également spécifier le type de media d'une connexion Ethernet pour, par exemple, forcer le mode 100baseTX full-duplex.

inet 10.0.0.38 255.255.255.0 NONE media 100baseTX mediaopt full-duplex

Bien entendu, vous ne devriez jamais forcer le mode full duplex à moins que les deux extrémités de la connexion ne soient configurées ainsi ! Si ce n'est pour des besoins spécifiques, la configuration du type de media n'est pas nécessaire. Un cas plus réaliste serait de forcer le mode 10base-T ou half duplex lorsque cela est rendu nécessaire par votre infrastructure.

Vous pouvez aussi vouloir utiliser des indicateurs spécifiques à une certaine interface. Le format du fichier hostname ne change que très peu.

$ cat /etc/hostname.vlan0 Inet 172.21.0.31 255.255.255.0 NONE vlan 2 vlandev fxp1

6.2.2 - Passerelle par défaut

Mettez l'adresse IP de votre passerelle par défaut dans le fichier /etc/mygate. Cela permettra à votre route par défaut d'être configurée au démarrage. Le fichier n'est constitué que d'une seule ligne comportant l'adresse IP de la passerelle pour cette machine :
10.0.0.1
Il est possible d'utiliser un nom symbolique ici mais soyez prudents : vous ne pouvez jamais être certain que le résolveur soit configuré ni même accessible AVANT que la passerelle par défaut n'est été elle-même configurée. En d'autres termes, il est souhaitable que cela soit une adresse IP ou un objet défini dans le fichier /etc/hosts.

6.2.3 - Résolution DNS

La résolution de noms DNS est configurée par le fichier /etc/resolv.conf. Voici un exemple de fichier /etc/resolv.conf :
search example.com nameserver 125.2.3.4 nameserver 125.2.3.5 lookup file bind
Dans notre cas, le domaine par défaut sera example.com, il y a deux serveurs DNS, 125.2.3.4 et 125.2.3.5, spécifiés et le fichier /etc/hosts sera consulté avant que les DNS ne le soient.

Comme sous la plupart des Unix (ainsi que de nombreux systèmes non-Unix), il existe un fichier /etc/hosts permettant de définir des systèmes qui ne sont pas (ou, si utilisés avec la directive de priorité "lookup", ne sont pas désirés) dans le système DNS formel.

Si vous utilisez DHCP, lisez 6.4 - DHCP en faisant attention à la partie sur resolv.conf.tail(5).

6.2.4 - Nom d'hôte

Chaque machine sous Unix possède un nom. Sous OpenBSD, ce nom est défini comme FQDN ("Fully Qualified Domain Name" - Nom d'Hôte Pleinement Qualifié") dans le fichier /etc/myname. Si cette machine se nomme "puffy" et que son domaine est "example.com", le fichier contiendra la ligne :
puffy.example.com

6.2.5 - Activer les changements

A présent, vous pouvez soit redémarrer, soit lancer le script /etc/netstart. Vous pouvez l'exécuter simplement en tapant (en tant que root) :
# sh /etc/netstart writing to routing socket: File exists add net 127: gateway 127.0.0.1: File exists writing to routing socket: File exists add net 224.0.0.0: gateway 127.0.0.1: File exists

Notez que plusieurs erreurs sont apparues. En exécutant ce script, vous reconfigurez certaines choses qui le sont déjà. De fait, certaines routes sont déjà présentes dans la table de routage du noyau. A présent, votre système devrait être en état de fonctionner. Une nouvelle fois, vous pouvez vérifier que votre interface a été correctement configurée avec ifconfig(8).

Bien que vous puissiez complètement reconfigurer le réseau sous OpenBSD sans redémarrer, un reboot est FORTEMENT conseillé après tout changement significatif dans la configuration. La raison en est que l'environnement de démarrage est légèrement différent de celui d'un système en production. Ainsi, si vous avez défini un nom symbolique à résoudre par DNS dans un de vos fichiers de configuration, vous vous apercevrez probablement que cela fonctionnait après une reconfiguration mais que lors du démarrage, votre résolveur pourrait ne pas être disponible et la configuration échouer.

6.2.6 - Vérification des routes

Vous pouvez vérifier vos routes via netstat(1) ou route(8) . Si vous avez des problèmes de routage, vous pouvez utiliser l'option -n de la commande route(8) qui affichera l'adresse IP plutôt que d'effectuer une requête DNS et d'afficher le nom d'hôte. Voici un exemple qui vous permettra de voir vos tables de routage en utilisant ces deux programmes.
$ netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Mtu Interface default 10.0.0.1 UGS 0 86 - fxp0 127/8 127.0.0.1 UGRS 0 0 - lo0 127.0.0.1 127.0.0.1 UH 0 0 - lo0 10.0.0/24 link#1 UC 0 0 - fxp0 10.0.0.1 aa:0:4:0:81:d UHL 1 0 - fxp0 10.0.0.38 127.0.0.1 UGHS 0 0 - lo0 224/4 127.0.0.1 URS 0 0 - lo0 Encap: Source Port Destination Port Proto SA(Address/SPI/Proto) $ route show Routing tables Internet: Destination Gateway Flags default 10.0.0.1 UG 127.0.0.0 LOCALHOST UG localhost LOCALHOST UH 10.0.0.0 link#1 U 10.0.0.1 aa:0:4:0:81:d UH 10.0.0.38 LOCALHOST UGH BASE-ADDRESS.MCA LOCALHOST U

6.2.7 - Mettre en place une passerelle OpenBSD

Voici les informations nécessaires à la mise en place d'une passerelle OpenBSD (appelé aussi routeur). Si vous devez installer OpenBSD pour en faire un routeur Internet, nous vous suggérons de lire les instructions sur la mise en place du filtre de paquets (plus loin) afin de bloquer le trafic non-autorisé. Avec le peu de disponibilité d'adresses IPv4 de la part des fournisseurs d'accès à Internet ainsi que des registres Internet régionaux, vous pourriez vouloir vous renseigner sur la translation d'adresses (NAT) afin d'économiser votre adressage IP.

Le noyau GENERIC est déjà configuré pour permettre le routage IP, mais celui-ci doit être explicitement activé. Vous pouvez l'activer avec l'utilitaire sysctl(8). Afin d'autoriser le routage de façon permanente, éditez le fichier /etc/sysctl.conf et ajoutez-y la ligne suivante.

net.inet.ip.forwarding=1

Pour prendre en compte ce changement sans redémarrer, vous utiliserez directement l'utilitaire sysctl(8). Souvenez-vous que ce changement ne sera pas sauvegardé au redémarrage et que vous devrez être root pour utiliser cette commande.

# sysctl net.inet.ip.forwarding=1 net.inet.ip.forwarding: 0 -> 1

A présent, modifiez les routes sur les hôtes aux deux extrémités. Il existe beaucoup d'autres usages d'OpenBSD en tant que routeur avec l'aide de programmes comme OpenBGPD (qui fait partie du projet OpenBSD), routed(8), mrtd, zebra et quagga. Sous OpenBSD, zebra et mrtd sont disponibles en tant que ports. OpenBGPD et routed sont inclus dans le système de base. OpenBSD supporte différentes interfaces T1, HSSI, ATM, FDDI, Ethernet et série (PPP/SLIP).

6.2.8 - Configurer les alias sur une interface

OpenBSD possède un mécanisme simple pour la mise en place d'alias IP sur une interface. Pour ce faire, il suffit d'éditer le fichier /etc/hostname.<if>. Ce fichier est lu au boot par le script /etc/netstart(8) faisant partie de la séquence de démarrage rc. Admettons par exemple qu'un utilisateur utilise l'interface dc0 et se trouve sur le réseau 192.168.0.0. Autres informations importantes :

Notes sur les alias. Sous OpenBSD, vous utilisez le nom de l'interface uniquement. Il n'y a pas de différence entre le premier et le second alias. A la différence d'autres systèmes d'exploitation, OpenBSD ne s'y réfère pas en tant que dc0:0, dc0:1. Si vous vous référez à une adresse IP d'alias avec ifconfig ou si vous ajoutez un alias, soyez sûr d'utiliser la commande "ifconfig int alias" au lieu de "ifconfig int". Vous pouvez supprimer les alias en utilisant "ifconfig int delete".

En admettant que vous utilisiez plusieurs adresses avec alias sur le même sous-réseau IP, le masque correspondant à chaque alias devient 255.255.255.255. Il n'est pas nécessaire d'utiliser le masque correspondant à l'adresse IP primaire de l'interface. Dans cet exemple, /etc/hostname.dc0, deux alias sont configurés pour le périphérique dc0, qui lui-même possède l'adresse 192.168.0.2 avec un masque de 255.255.255.0.

# cat /etc/hostname.dc0 inet 192.168.0.2 255.255.255.0 media 100baseTX inet alias 192.168.0.3 255.255.255.255 inet alias 192.168.0.4 255.255.255.255

Après avoir édité ce fichier, il suffit de redémarrer pour que les changements prennent effet. Mais vous pouvez aussi créer les alias à la main en utilisant l'utilitaire ifconfig(8). Pour créer le premier alias, lancez la commande suivante :

# ifconfig dc0 inet alias 192.168.0.3 netmask 255.255.255.255
(mais encore une fois, un redémarrage est conseillé afin d'être certain que vous ayez rentré la configuration que vous pensiez !)

Pour voir les alias, utilisez la commande suivante :

$ ifconfig -A dc0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> media: Ethernet manual inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 inet 192.168.0.3 netmask 0xffffffff broadcast 192.168.0.3

6.3 - Comment filtrer et utiliser un pare-feu sous OpenBSD ?

Sous OpenBSD, le filtrage du trafic IP ainsi que la translation d'adresses (NAT) est pris en charge par "Packet Filter" (filtre de paquet ; auquel nous nous référerons à présent sous le nom de PF) . PF est aussi capable de normaliser et de traiter le trafic IP, d'offrir une gestion de la bande passante et une prioritarisation des paquets ainsi que d'être utilisé dans la création de puissants et flexibles pare-feu. Tout ceci est décrit dans le Guide de l'Utilisateur PF.

6.4 - DHCP

Le protocole d'attribution dynamique des adresses (DHCP) permet de configurer les interfaces réseau automatiquement. OpenBSD peut être serveur DHCP (afin de configurer les autres machines), client DHCP (afin de recevoir sa configuration à partir d'une autre machine) et, dans certains cas, les deux.

6.4.1 Client DHCP

Pour utiliser le client DHCP dhclient(8) inclus avec OpenBSD, éditez le fichier /etc/hostname.xl0 (sous-entendu que l'interface Ethernet soit xl0. La vôtre pouvant être aussi bien ep0 que fxp0 ou encore autre chose). Tout ce que vous avez besoin d'écrire dans ce fichier est 'dhcp' :

# echo dhcp > /etc/hostname.xl0

Ceci aura pour effet de démarrer automatiquement le client DHCP au démarrage. OpenBSD se verra attribuer son adresse IP, sa passerelle par défaut et ses serveurs de noms (DNS) à partir du serveur DHCP.

Si vous souhaitez démarrer le client DHCP à partir de la ligne de commande, vérifiez bien que /etc/dhclient.conf existe, puis lancez la commande :

# dhclient fxp0

Où fxp0 représente l'interface que vous voulez configurer par DHCP.

Peu importe la façon dont vous démarrez le client DHCP, vous pouvez éditer /etc/dhclient.conf afin de ne pas mettre à jour vos DNS à l'aide du serveur dhcp en décommentant les lignes 'request' (il y a des exemples de configurations, mais vous devez les décommenter afin de changer le comportement par défaut de dhclient.)

request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, lpr-servers, ntp-servers;

et supprimez domain-name-servers. Bien sûr, vous pouvez également supprimer hostname ainsi que d'autres options.

En changeant les options dans le fichier dhclient.conf(5), vous indiquez au client DHCP la façon de créer votre fichier resolv.conf(5). Le client DHCP écrase toutes les données déjà présentes dans resolv.conf(5) en utilisant les informations envoyées par le serveur DHCP. De fait, tous les changements que vous aurez apportés manuellement seront perdus.

Il existe deux mécanismes pour empêcher cela :

Imaginions que vous souhaitiez utiliser le client DHCP mais que vous vouliez ajouter lookup file bind au fichier resolv.conf(5) créé par dhclient(8). Il n'existe pas de telle option dans le fichier dhclient.conf et vous devrez donc utiliser resolv.conf.tail pour préserver ce changement.

# echo "lookup file bind" > /etc/resolv.conf.tail
A présent, votre fichier resolv.conf(5) devrait inclure "lookup file bind" à la fin.
nameserver 192.168.1.1 nameserver 192.168.1.2 lookup file bind

6.4.2 Serveur DHCP

Pour utiliser OpenBSD en tant que serveur DHCP dhcpd(8) , éditez le fichier /etc/rc.conf.local afin qu'il contienne la ligne dhcpd_flags="". Placez le nom des interfaces sur lesquelles vous souhaitez que le serveur écoute, dans le fichier /etc/dhcpd.interfaces. # echo xl1 xl2 xl3 >/etc/dhcpd.interfaces

Ensuite, éditez /etc/dhcpd.conf. Les options sont plutôt explicites. option domain-name "example.com"; option domain-name-servers 192.168.1.3, 192.168.1.5; subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.1; range 192.168.1.32 192.168.1.127; }

Ceci indique à vos clients DHCP que le domaine à ajouter aux requêtes DNS est example.com (ainsi, si un utilisateur lance la commande 'telnet joe', il sera renvoyé vers joe.example.com). Les clients auront comme serveurs DNS 192.168.1.3 et 192.168.1.5. Pour les hôtes présents sur le sous-réseau correspondant à l'interface du serveur OpenBSD, à savoir dans la plage 192.168.1.0/24, ils se verront attribuer une adresse IP entre 192.168.1.32 et 192.168.1.127. Leur passerelle par défaut sera 192.168.1.1.

Si vous souhaitez démarrer dhcpd(8) à partir de la ligne de commandes, une fois /etc/dhcpd.conf configuré, tapez : # touch /var/db/dhcpd.leases # dhcpd fxp0

La ligne invoquant touch est nécessaire afin de créer un fichier dhcpd.leases vide avant que dhcpd(8) ne démarre. Les scripts de démarrage d'OpenBSD se chargeront de créer ce fichier au boot, mais si vous lancez dhcpd(8) manuellement, vous devez au préalable créer ce fichier. fxp0 représente l'interface sur laquelle vous voulez répondre aux requêtes DHCP.

Si vous prévoyez de servir DHCP à des machines Windows, pour pourriez souhaiter donner à ces clients une adresse de serveur 'WINS'. Pour ce faire, ajoutez simplement la ligne suivante dans votre fichier /etc/dhcpd.conf : option netbios-name-servers 192.168.92.55;

(où 192.168.92.55 est l'adresse IP de votre serveur Windows ou Samba.) Reportez vous au manuel dhcp-options(5) si vos clients DHCP ont besoin de plus d'options.

6.5 - PPP

Le protocole point à point est généralement utilisé afin de créer une connexion modem vers votre FAI (fournisseur d'accès à Internet). Sous OpenBSD, deux solutions existent.

Chacune des implémentations (ppp et pppd) offrent des fonctionnalités similaires de différentes façons. pppd utilise le pilote ppp(4) inclus dans le noyau alors que ppp utilise tun(4) dans l'espace utilisateur. Ce document ne couvrira que l'implémentation en espace utilisateur du démon PPP car il est plus simple à utiliser et diagnostiquer. Pour commencer, vous aurez besoin de certaines informations concernant votre FAI. En voici une liste non-exhaustive.

Certaines de ces options ne sont pas obligatoires mais vous aideront à la mise en place de ppp. Le fichier de configuration du démon PPP est /etc/ppp/ppp.conf. Selon votre situation, les nombreux fichiers présents dans /etc/ppp peuvent vous aider à la mise en place de votre configuration. Vous devriez jeter un oeil à ce répertoire.

Configuration initiale - pour PPP(8)

La configuration initiale de PPP nécessite l'édition du fichier /etc/ppp/ppp.conf. Ce fichier n'existe pas par défaut, mais vous pouvez vous inspirer du fichier /etc/ppp/ppp.conf.sample afin de créer votre propre ppp.conf. Je commencerai par une configuration simple et généralement très employée. Voici rapidement un petit fichier ppp.conf définissant quelques valeurs par défaut :

default: set log Phase Chat LCP IPCP CCP tun command set device /dev/cua01 set speed 115200 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"

La section définie par le marqueur default: sera exécutée à chaque fois. Cette section recense des informations importantes. "set log" défini le niveau de verbosité des logs. Il peut être changé : référez-vous au manuel de ppp(8) pour plus d'informations concernant les niveaux d'enregistrement des différents événements. Le périphérique utilisé est indiqué par "set device". Il s'agit du port sur lequel est présent notre modem. Dans cet exemple, le modem est branché sur le port com 2. Ainsi, le port com 1 sera indiqué par /dev/cua00. La vitesse de la connexion est précisée par "set speed" et "set dial" renseigne nos paramètres de numérotation. Avec ceci, nous pouvons changer l'expiration ("timeout") de la connexion, etc. Ceci étant, cette ligne ne devrait pas tellement varier.

Nous pouvons maintenant continuer et configurer les informations spécifiques à notre FAI. Pour ce faire, nous allons rajouter une autre section en dessous de default:. Le marqueur définissant cette nouvelle section pourra être ce que vous désirez - le plus simple étant d'utiliser le nom de votre FAI. Ici, nous utiliserons myisp: pour indiquer le commencement de la section correspondant à notre FAI. Voici une configuration simple contenant le nécessaire afin de nous connecter :

myisp: set phone 1234567 set login "ABORT NO\\sCARRIER TIMEOUT 5 ogin:--ogin: ppp word: ppp" set timeout 120 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR enable dns

Ici nous avons fourni les éléments essentiels concernant ce FAI. La première option, "set phone", donne le numéro de téléphone du FAI. Nos options d'ouverture de session sont renseignées par "set login". Notre "timeout" est égal à 5 ; ce qui signifie que notre tentative de connexion expirera après 5 secondes si aucune porteuse n'est trouvée. Dans le cas contraire, "login:" sera envoyé avec notre nom d'utilisateur et notre mot de passe.

Dans cet exemple, notre nom d'utilisateur est : ppp ; notre mot de passe est : ppp. Ces valeurs doivent être changées. La ligne "set timeout" permet de couper la connexion après 120 secondes de non-utilisation. L'option "set ifaddr" est un peu plus compliquée. En voici une explication plus complète.

set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0

La ligne précédente se définit avec le format suivant : "set ifaddr [myaddr[/nn] [hisaddr[/nn] [netmask [triggeraddr]]]]". La première IP désigne l'adresse IP que nous souhaitons nous voir attribuer. Si vous avez une adresse IP statique, vous devez l'indiquer ici. Dans notre exemple, nous utilisons la notation /0 qui dit qu'aucun "bit" de cette adresse ne doit forcément correspondre et que celle-ci peut être changée. La deuxième adresse IP est celle du FAI. La troisième option est notre masque de sous-réseau, ici défini à 255.255.255.0. Si triggeraddr est renseigné, il remplacera myaddr comme adresse IP utilisée pour la négociation IPCP initiale. Cependant, seule une adresse incluse dans la gamme d'adressage correspondant à myaddr sera acceptée. Ceci peut être utile dans la négociation avec certaines implémentations PPP qui n'attribuent pas d'adresse IP à moins que l'initiateur de la connexion ne demande explicitement l'adresse "0.0.0.0".

L'option suivante "add default HISADDR" attribue comme route par défaut l'adresse IP de votre FAI. Cette entrée permet d'ajuster automatiquement notre route par défaut en cas de changement d'adresse IP de celui-ci. "enable dns" est utilisé afin de récupérer la liste des serveurs DNS du FAI. N'utilisez PAS cette option si vous avez votre propre serveur DNS local car ppp empêchera les requêtes vers celui-ci en remplaçant les lignes "nameserver" de votre fichier /etc/resolv.conf.

A la place des méthodes traditionnelles de connexion, certains FAI utilisent à présent l'authentification CHAP ou PAP. Si c'est le cas, notre configuration sera un peu différente:

myisp: set phone 1234567 set authname ppp set authkey ppp set login set timeout 120 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR enable dns

Dans l'exemple précédent, nous spécifions notre nom d'utilisateur (ppp) et notre mot de passe à l'aide des options authname et authkey, respectivement. Il n'est pas nécessaire de spécifier le type d'authentification CHAP ou PAP utilisé, car il sera négocié automatiquement. "set login" signifie simplement de tenter de se connecter en utilisant le nom d'utilisateur et le mot de passe précisés précédemment.

Utiliser PPP(8)

Maintenant que ppp.conf est configuré, nous pouvons essayer d'initier une connexion vers notre FAI. Je détaillerais certaines des options les plus utilisées :

Si les commandes précédentes ne fonctionnent pas, lancez /usr/sbin/ppp sans option, ce qui vous placera en mode interactif. Les options peuvent être spécifiées une par une afin de diagnostiquer les erreurs et autres problèmes. En utilisant la configuration précédente, ppp enregistrera les événements dans /var/log/ppp.log. Ce fichier de log ainsi que la page de manuel contiennent des informations utiles.

Autres options de ppp(8)

Dans certaines situations, vous pourriez avoir besoin de lancer certaines commandes au lancement ou à la coupure de votre connexion. Si vous vous trouvez dans cette situation, il existe deux fichiers que vous pouvez créer : /etc/ppp/ppp.linkup et /etc/ppp/ppp.linkdown. Des exemples de configurations sont disponibles ici :

variations sur ppp(8)

De nos jours, beaucoup de FAI offrent des services xDSL plus rapides que les méthodes traditionnelles de connexion. Ceux-ci incluent des variantes de type ADSL et SDSL. Bien qu'aucun appel à distance n'est lieu, la connexion reste basée sur le protocole point-à-point. En voici des exemples:

PPPoE/PPPoA

Le protocole d'encapsulation de PPP dans Ethernet (PPPoE - "Point to Point Protocol over Ethernet") permet d'envoyer des paquets PPP à l'intérieur de trames Ethernet. Le protocole d'encapsulation de PPP dans ATM (PPPoA - "Point to Point Protocol over ATM") est généralement utilisé dans les réseaux ATM tels qu'au Royaume-Uni ou en Belgique.

En résumé cela signifie que vous pouvez établir une connexion vers votre FAI à l'aide d'une carte Ethernet standard et d'un modem DSL-Ethernet (à l'inverse des modems USB).

Si vous possédez un modem compatible PPPoE/PPPoA, il est possible de le configurer afin qu'il initie lui-même la connexion. Dans le cas contraire, si le modem est capable de fonctionner en mode "bridge", il est possible d'activer ce mode afin que celui-ci fasse "transiter" les paquets vers une machine exécutant un logiciel PPPoE (voir plus loin).

Sous OpenBSD, l'interface logicielle PPPoE/PPPoA principale est pppoe(8) , qui est l'implémentation en espace utilisateur (de la même manière que ppp(8) , précédemment décrit). Une implémentation noyau de PPPoE, pppoe(4) , a été ajoutée dans OpenBSD.

PPTP

Le "Point to Point Tunneling Protocol" (PPTP) est un protocole propriétaire Microsoft. Un client pptp s'interfaçant avec pppd(8) est disponible et est capable de se connecter à un réseau privé virtuel PPTP (VPN) utilisé par certains fournisseurs d'accès câble ou xDSL. Le logiciel pptp quant à lui doit être installé en utilisant les paquets ou les ports. De plus amples instructions sur la façon de mettre en place et d'utiliser pptp sont disponibles dans la page de manuel installée avec le paquet pptp.

6.6 - Optimisation des paramètres réseau

6.6.1 - Comment configurer le noyau pour avoir un plus grand nombre d'essais et augmenter le délai d'expiration des sessions TCP ?

Généralement, vous utiliserez ceci en cas de problèmes de routage ou de connexion. Bien sûr, pour que cette configuration soit la plus efficace, les deux extrémités de la connexion doivent utiliser des valeurs similaires.

Pour optimiser ceci, utilisez sysctl et augmentez les valeurs de : net.inet.tcp.keepinittime net.inet.tcp.keepidle net.inet.tcp.keepintvl

Avec sysctl -a, vous pouvez voir les valeurs courantes de ces paramètres (ainsi que beaucoup d'autres). Pour en changer un, tapez par exemple sysctl net.inet.tcp.keepidle=28800.

6.6.2 - Comment activer les émissions ("broadcasts") dirigées ?

Normalement, vous ne devriez pas utiliser ceci. Cette option permet à quelqu'un de diriger le trafic vers la ou les adresses "broadcast" des réseaux sur lesquels vous êtes connecté si vous utilisez OpenBSD en tant que routeur.

Dans certaines situations, sur des réseaux fermés, cette option peut- être utile, surtout lors de l'utilisation de vieilles implémentations du protocole NetBIOS. Il s'agit d'un autre paramètre sysctl. sysctl net.inet.ip.directed- broadcast=1 active cette option. Lisez la section sur les "attaques de type smurf" si vous voulez savoir pourquoi cette option est désactivée par défaut.

6.6.3 - Je ne veux pas que le noyau alloue dynamiquement un port donné

Il existe également un paramètre sysctl pour cela. D'après sysctl(8) : Définie la liste des ports TCP ne devant pas être alloués dynamiquement par le noyau. Ceci peut être utile afin d'éviter l'appropriation d'un port spécifique dont un autre programme a besoin pour fonctionner. Les éléments listés peuvent être séparés par une virgule et/ou un espace. # sysctl net.inet.tcp.baddynamic=749,750,751,760,761,871 Il est aussi possible d'ajouter ou de retirer des ports de la liste courante. # sysctl net.inet.tcp.baddynamic=+748 # sysctl net.inet.tcp.baddynamic=-871

6.6.4 - Comment augmenter les performances sur les liens à grande vitesse et à fort trafic ?

Si vous avez des soucis de performances sur des liens WAN à grande vitesse lorsque vous transférez beaucoup de données, vous devriez pouvoir optimiser ces performances en éditant les valeurs sysctls suivantes :
net.inet.tcp.recvspace net.inet.tcp.sendspace
Essayez une valeur comme 65536 au lieu de 16384. Notez que très peu de personnes verront un gain réel. N'ajustez ces valeurs que si vous obtenez des performances en deçà de vos attentes.

6.7 - Utilisation simple de NFS

NFS ("Network File System") est utilisé afin de partager un système de fichiers à travers un réseau. Voici un certain nombre de manuels à lire avant la mise en place d'un serveur NFS :

Cette section détaillera les étapes nécessaires à la mise en oeuvre d'une configuration NFS simple. Cet exemple détaille un serveur et ses clients NFS sur un LAN. Il ne s'agit pas d'étudier la sécurisation de NFS. Nous assumerons que le filtre de paquets (PF) ou qu'un autre type de pare-feu est configuré afin d'interdire les accès extérieurs. Si vous autorisez l'accès à votre serveur NFS depuis l'extérieur et que vous hébergez des données sensibles, nous vous conseillons fortement d'utiliser IPsec. Autrement certaines personnes pourraient voir ce qui transite dans votre trafic NFS. Quelqu'un pourrait également usurper l'adresse IP que vous autorisez à se connecter à votre serveur NFS. Plusieurs types d'attaques peuvent en découler. Mais lorsqu'IPsec est correctement configuré, il offre une protection contre ces attaques.

Autre note concernant la sécurité. Ne vous contentez pas juste d'ajouter un système de fichiers dans /etc/exports sans mettre en place une liste recensant les hôtes autorisés à se connecter. Sans une liste d'hôtes autorisés à monter un répertoire particulier, n'importe qui, capable de vous atteindre, sera en mesure de monter vos systèmes de fichiers exportés par NFS.

portmap(8) doit être lancé afin que NFS puisse fonctionner. Sous OpenBSD, portmap(8) est désactivé par défaut, vous devez donc ajouter la ligne

portmap=YES
dans le fichier rc.conf.local(8) pour le lancer au démarrage. Il peut également être lancé manuellement :
# /usr/sbin/portmap

Cette configuration consiste en un serveur d'adresse IP 10.0.0.1. Ce serveur n'offrira NFS qu'aux clients présents sur ce réseau. La première étape pour installer un serveur NFS est de renseigner votre fichier /etc/exports. Ce fichier liste les systèmes de fichiers que vous souhaitez rendre accessibles par NFS et définit qui peut y accéder. Beaucoup d'options sont disponibles pour l'édition de /etc/exports et vous devriez lire la page de manuel exports(5). Pour cet exemple, notre fichier /etc/exports ressemblera à :

# # NFS exports Database # See exports(5) for more information. Be very careful, misconfiguration # of this file can result in your filesystems being readable by the world. /work -alldirs -ro -network=10.0.0 -mask=255.255.255.0

Ceci signifie que le système de fichiers local /work sera accessible par NFS. L'option -alldirs permet au client de monter n'importe quel répertoire sous le point de montage /work. L'option -ro exporte le système de fichiers en lecture seule. Les deux derniers arguments spécifient que seuls les clients présents dans le réseau 10.0.0.0 et utilisant un masque de 255.255.255.0 seront autorisés à monter ce système de fichiers. Ceci est important pour certains serveurs accessibles dans différents réseaux.

Une fois que votre fichier /etc/exports est configuré, vous pouvez mettre en place votre serveur NFS. Tout d'abord, vérifiez que les options NFSSERVER & NFSCLIENT sont bien présentes dans votre fichier de configuration noyau. (Le noyau GENERIC inclus ces options.) Ensuite, il vous faut inclure la ligne

nfs_server=YES
dans le fichier /etc/rc.conf.local. Ceci aura pour effet de démarrer nfsd(8) et mountd(8) au redémarrage. A présent, vous pouvez lancer les démons manuellement. Ils doivent être lancés par root et vous devez vérifier que portmap(8) est bien démarré sur votre système. Voici un exemple de lancement de nfsd(8) servant les requêtes TCP et UDP et utilisant 4 démons. Vous devriez utiliser un nombre approprié de démons NFS en fonction du nombre maximum de connexions concurrentes que vous souhaitez servir.
# /sbin/nfsd -tun 4

Vous devez non seulement démarrer le serveur nfsd(8) mais également mountd(8). Il s'agit du service qui se charge de passer les requêtes de montage à NFS. Pour démarrer mountd(8), soyez sûr qu'un fichier mountdtab vide existe puis lancez le démon :

# echo -n >/var/db/mountdtab # /sbin/mountd

Si vous faites des changements au fichier /etc/exports alors qu'NFS est déjà en fonction, vous devez en informer mountd ! Lancez-lui simplement un signal HUP :

# kill -HUP `cat /var/run/mountd.pid`

Statistiques NFS

Maintenant, vous pouvez vérifier que tous ces démons sont lancés et enregistrés avec RPC. Pour ce faire, utilisez rpcinfo(8).

$ rpcinfo -p 10.0.0.1 program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 633 mountd 100005 3 udp 633 mountd 100005 1 tcp 916 mountd 100005 3 tcp 916 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs

Dans le cadre d'une utilisation normale, d'autres utilitaires peuvent vous permettre de voir ce qui se passe au niveau NFS. Un de ces utilitaires est showmount(8), qui permet de voir ce qui est monté et par qui. Il existe aussi nfsstat(8) qui affiche beaucoup plus de statistiques. Pour utiliser showmount(8), essayez la commande /usr/bin/showmount -a hôte. Par exemple :

$ /usr/bin/showmount -a 10.0.0.1 All mount points on 10.0.0.1: 10.0.0.37:/work

Monter des systèmes de fichiers NFS

Les systèmes de fichiers NFS doivent être montés par mount(8), ou plus précisément, mount_nfs(8). Pour monter le système de fichiers /work sur 10.0.0.1 vers le système de fichiers local /mnt, il vous suffit de lancer la commande suivante (notez qu'il n'est pas nécessaire d'utiliser une adresse IP ; mount résoudra les noms d'hôtes) :

# mount -o ro -t nfs 10.0.0.1:/work /mnt

Pour que ce système de fichiers soit monté au démarrage, ajoutez la ligne suivante dans votre /etc/fstab :

10.0.0.1:/work /mnt nfs ro 0 0

Il est important que vous utilisiez 0 0 à la fin de la ligne afin que votre machine ne lance pas un fsck sur ce système de fichiers NFS au boot !!! Les autres options standards, comme noexec, nodev, nosuid peuvent être employées lorsqu'elles sont applicables. Par exemple :

10.0.0.1:/work /mnt nfs ro,nodev,nosuid 0 0

Ainsi, aucun périphérique ni programme setuid présent sur le serveur NFS ne peut compromettre la sécurité du client. Si vous ne montez pas de programmes que vous souhaitez utiliser sur le client NFS, ajoutez l'option noexec à cette ligne.

6.9 - Mise en place d'un pont ("bridge") avec OpenBSD

Un pont ("bridge") est un lien entre deux (ou plusieurs) réseaux séparés. A l'inverse d'un routeur, les paquets sont transférés à travers le pont de manière "invisible" -- au niveau logique, les deux segments de réseau semblent n'en faire qu'un de chaque côté du pont. Le pont ne transfèrera que les paquets passant d'un segment à l'autre, ce qui entre autres, permet de réduire le trafic sur un réseau complexe tout en permettant à n'importe quel noeud d'accéder à un autre en cas de besoin.

Notez qu'à cause de sa nature "invisible", une interface faisant partie d'un pont peut, ou non, posséder une adresse IP. Si c'est le cas, l'interface aura deux modes d'opération, l'un faisant parti du pont et l'autre se comportant comme une interface normale. Si aucune interface ne possède d'adresse IP, le pont fera transiter le trafic mais ne sera pas administrable par le réseau (ce qui peut être une fonctionnalité voulue).

Exemple d'application d'un pont

Un de mes racks possède un certain nombre d'anciens systèmes, lesquels ne sont pas équipés de carte réseau 10BASE-TX. Bien qu'ils possèdent des ports AUI ou AAUI, ma réserve de transmetteurs est limitée à des câbles coaxiaux. Une des machines de cette rangée est un serveur d'accès terminal sous OpenBSD, toujours allumée et connectée au réseau à haut débit. L'ajout d'une seconde carte équipée d'un port coaxial permettra d'utiliser cette machine comme un pont vers le réseau coaxial.

Ce système a, pour le moment, deux cartes réseau, une Intel EtherExpress/100 (fxp0) et une carte 3c590-Combo (ep0) pour le port coaxial. fxp0 fait le lien avec le reste du réseau et possède donc une adresse IP, ep0, ne faisant quant à elle que du "bridging", n'en possède pas. Les machines connectées sur le segment coaxial communiqueront comme les autres présentes sur le reste du réseau. A présent, voyons comment arriver à ce résultat.

Le fichier hostname.fxp0 contient les informations concernant la carte fxp0. Cette machine est configurée pour DHCP, donc le fichier ressemble à celui-ci :

$ cat /etc/hostname.fxp0 dhcp NONE NONE NONE

Ici, aucune surprise.

Comme vous pouvez le deviner, la configuration de la carte ep0 est un peu différente :

$ cat /etc/hostname.ep0 up media 10base2

Ici, nous demandons au système d'activer cette interface en utilisant ifconfig(8) et de la configurer pour du 10BASE-2 (coaxial). Aucune adresse ou information similaire n'est nécessaire pour cette interface. Les options possibles pour la carte ep sont disponibles en détail dans le manuel.

A présent, il nous faut paramétrer le pont. Un pont est initialisé par l'existence d'un fichier du type bridgename.bridge0. Dans ma situation, voici un exemple possible :

$ cat /etc/bridgename.bridge0 add fxp0 add ep0 up

Cela indique de mettre en place un pont constitué de deux interfaces, fxp0 et ep0 et de l'activer. Est-ce que l'ordre dans lequel les cartes sont énoncées est important ? Non, souvenez-vous qu'un pont est très symétrique -- les paquets entrent et sortent dans les deux directions.

C'est tout ! Redémarrez et vous aurez un pont fonctionnel.

Le filtrage sur un pont ("filtering bridge")

Bien qu'il existe certainement des usages pour de simples ponts du genre évoqué, il est probable que vous souhaitiez FAIRE quelque chose avec les paquets qui le traversent. Comme vous pouvez vous en douter, Packet Filter peut être utilisé pour restreindre le trafic traversant votre pont (pont filtrant).

Gardez à l'esprit que de part la nature d'un pont, les mêmes données traversent les deux interfaces, ce qui signifie que vous n'avez besoin de filtrer que sur l'une d'entre elles. Vos déclarations par défaut "Pass all" ressembleront à l'exemple suivant :

pass in on ep0 all pass out on ep0 all pass in on fxp0 all pass out on fxp0 all

Maintenant, admettons que je souhaite filtrer le trafic dirigé vers les vieux systèmes évoqués précédemment, ne permettant qu'aux protocoles Web et SSH de les atteindre. Dans ce cas, nous allons autoriser tout le trafic entrant et sortant sur l'interface ep0, mais nous filtrerons sur l'interface fxp0 en utilisant keep state pour prendre en charge les données retournées :

# Autoriser le trafic entrant et sortant sur ep0 pass in quick on ep0 all pass out quick on ep0 all # Bloquer tout le trafic sur fxp0 block in on fxp0 all block out on fxp0 all pass in quick on fxp0 proto tcp from any to any port {22, 80} \ flags S/SA keep state

Notez que cette règle bloquera tout, à l'exception des requêtes entrantes HTTP et SSH, vers la machine qui fait le pont ainsi qu'en direction des autres noeuds "derrière" elle. Il est possible d'obtenir d'autres résultats en filtrant sur l'autre interface.

Pour surveiller et contrôler le pont que vous venez de créer, servez-vous de la commande brconfig(8) qui peut aussi être utilisée pour créer un pont après le démarrage.

Astuces sur les ponts

6.10 - Comment démarrer en utilisant PXE ? (i386, amd64)

PXE ("Preboot Execution Environment", environnement d'exécution avant démarrage) permet de démarrer un ordinateur à partir du réseau plutôt que d'un disque dur, une disquette ou un CD-ROM. A l'origine, cette technologie a été développée par Intel mais est maintenant supportée par la plupart des contrôleurs réseau et des constructeurs. Sachez qu'il existe plusieurs protocoles de démarrage par le réseau, PXE étant relativement récent. Traditionnellement, un démarrage PXE est effectué en utilisant des ROMs présentes sur la carte réseau ou la carte mère elle- même, mais plusieurs disquettes permettant de démarrer en PXE sont disponibles sur différentes sources. Beaucoup de ROMs présentes sur des anciens contrôleurs supportent le démarrage en réseau mais sont incompatibles avec PXE ; s'il est équipé de tels contrôleurs, un système OpenBSD/i386 ou amd64 ne pourra pas être démarré par le réseau.

Comment fonctionne un démarrage PXE ?

Tout d'abord, il serait sage de savoir comment se déroule le processus de démarrage d'OpenBSD/i386 ? sur les plates-formes i386 et amd64. Au démarrage, chaque interface compatible PXE émet une requête DHCP en broadcast sur le réseau. Le serveur DHCP lui attribue alors une adresse IP en lui indiquant l'emplacement du fichier à exécuter sur le serveur tftp(1). Ce fichier se charge ensuite de gérer le reste du démarrage. Sous OpenBSD pxeboot remplace le fichier boot(8) standard. Il est alors capable de charger et d'exécuter un noyau (comme bsd ou bsd.rd) à partir du serveur tftp(1).

Comment le mettre en place ?

Le point évident est que vous avez besoin d'une machine ou d'un contrôleur compatible avec un démarrage PXE. Certaines documentations précisent que toutes les cartes modernes sont compatibles PXE, mais c'est tout simplement faux -- de nombreux systèmes à bas prix n'incluent pas de ROMs PXE ou utilisent un ancien protocole de démarrage sur réseau. Vous avez également besoin d'un serveur DHCP configuré ainsi qu'un serveur TFTP.

En admettant qu'une machine sous OpenBSD serve les fichiers de démarrage (cela n'étant PAS obligatoire), le fichier dhcpd.conf de votre serveur DHCP devra contenir la ligne suivante : filename "pxeboot"; afin de pouvoir offrir ce fichier de démarrage à une station de travail. Par exemple : shared-network LOCAL-NET { option domain-name "example.com"; option domain-name-servers 192.168.1.3, 192.168.1.5; subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.1; filename "pxeboot"; range 192.168.1.32 192.168.1.127; default-lease-time 86400; max-lease-time 90000; } }

Vous devrez aussi activer le service tftpd(8) . Pour ce faire, il suffit de configurer inetd(8) . L'installation standard d'OpenBSD fournit une ligne d'exemple dans inetd.conf qui devrait vous satisfaire : #tftp dgram udp wait root /usr/libexec/tftpd tftpd -s /tftpboot Retirez simplement le caractère '#' et envoyez à inetd(8) un signal -HUP afin que celui-ci relise son fichier /etc/inetd.conf. Les fichiers accessibles par tftpd(8) sont contenus dans un répertoire particulier, ici /tftpboot, que nous utiliserons pour cet exemple. Bien évidemment, ce répertoire doit être créé et contenir les fichiers nécessaires. Pour un démarrage PXE, vous n'aurez typiquement besoin que de quelques fichiers :

Notez que /etc/boot.conf n'est nécessaire qu'au cas où vous souhaiteriez démarrer un noyau ne se nommant pas bsd, ou que les options par défaut de pxeboot ne vous conviennent pas (par exemple si vous utilisez une console série). Vous pouvez tester votre serveur tftpd(8) en utilisant un client tftp(1) afin de vérifier que vous pouvez bien récupérer les fichiers nécessaires.

Une fois vos serveurs DHCP et TFTP démarrés, vous êtes prêt pour un essai. Vous devez activer PXE sur votre système ou votre carte réseau ; consultez la documentation fournie avec votre matériel. Une fois que PXE est activé, vous devriez voir apparaître des lignes similaires à celles- ci : Intel UNDI, PXE-2.0 (build 067) Copyright (C) 1997,1998 Intel Corporation For Realtek RTL 8139(X) PCI Fast Ethernet Controller v1.00 (990420) DHCP MAC ADDR: 00 E0 C5 C8 CF E1 CLIENT IP: 192.168.1.76 MASK: 255.255.255.0 DHCP IP: 192.168.1.252 GATEWAY IP: 192.168.1.1 probing: pc0 com0 com1 apm pxe![2.1] mem[540k 28m a20=on] disk: hd0* net: mac 00:e0:c5:c8:cf:e1, ip 192.168.1.76, server 192.168.1.252 >> OpenBSD/i386 PXEBOOT 1.00 boot> A présent, vous obtenez l'invite de commandes standard d'OpenBSD. Si vous tapez simplement "bsd.rd" pour récupérer le fichier bsd.rd à partir du serveur TFTP. >> OpenBSD/i386 PXEBOOT 1.00 boot> bsd.rd booting tftp:bsd.rd: 4375152+733120 [58+122112+105468]=0x516d04 entry point at 0x100120 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.1 (RAMDISK_CD) #247: Thu Mar 8 23:21:43 MST 2007 ... Le noyau d'installation bsd.rd va maintenant se lancer.

Est-il possible de démarrer d'autres noyaux que bsd.rd en utilisant PXE ?

Oui, bien qu'avec les outils actuellement présents dans OpenBSD, le démarrage PXE ne soit essentiellement prévu que pour installer le système d'exploitation.

6.11 - Protocole de redondance d'adresse commune (CARP)

6.11.1 - Qu'est-ce que CARP et comment fonctionne-t-il ?

CARP ("Common Address Redundancy Protocol") est un outil aidant à la redondance du système en ayant plusieurs ordinateurs créant une interface réseau unique entre eux, afin que si l'un d'eux ne fonctionne plus, un autre puisse répondre à sa place ; cet outil permet aussi de mettre en place un certain partage de charge entre les différents systèmes. CARP est une avancée par rapport au VRRP ("Virtual Router Redundancy Protocol" - protocole de redondance de routeur virtuel) standard. Il a été développé une fois que VRRP fut considéré comme non suffisamment libre à cause d'un brevet Cisco pouvant le couvrir. Pour plus d'informations sur les origines de CARP et les problèmes légaux entourant VRRP, rendez-vous sur cette page.

Afin d'éviter tout problème légal, Ryan McBride (avec l'aide de Michael Shalayeff, Marco Pfatschbacher et Markus Friedl) a conçut CARP de manière à être fondamentalement différent. Si l'inclusion de la cryptographie reste le changement le plus visible, il n'en reste pas moins un seul parmi beaucoup d' autres.

Comment fonctionne-t-il ? CARP est un protocole multicast. Il regroupe plusieurs systèmes physiques en une ou plusieurs adresses virtuelles. L'un d'eux est le maître et répond aux paquets destinés au groupe, alors que les autres se comportent comme des "hot spares" (remplacement à chaud et automatique du maître). Peu importe les adresses IP et MAC de l'interface physique locale, les paquets envoyés vers l'adresse CARP reviennent avec les informations CARP.

A intervalles paramétrables, le maître annonce son état sur le port IP 112. Si le maître est déconnecté, les autres systèmes du groupe CARP commencent à annoncer leur présence. L'hôte qui parvient à s'annoncer le plus fréquemment devient le nouveau maître. Lorsque le système principal est reconnecté, il se transforme par défaut en hôte de secours, bien qu'il soit possible de configurer un hôte spécifique en tant que maître par défaut lorsque cela est faisable (ex. un hôte est un Sun Fire V120 rapide et les autres sont des SPARCstation IPCs, comparativement plus lentes).

Bien que les équipements à haute redondance et tolérance de pannes minimisent le besoin de CARP, ils ne le suppriment pas. Il n'existe pas de matériel à tolérance de pannes capable de gérer le fait que quelqu'un débranche le cordon d'alimentation ou que l'administrateur système tape reboot dans la mauvaise fenêtre. L'utilisation de CARP aide à rendre transparent une mise à jour ou un redémarrage du point de vue des utilisateurs, ainsi que le test d'un programme ou une mise à jour matérielle : si cela ne fonctionne pas, vous pouvez basculer sur le reste du groupe jusqu'à ce que le problème soit résolu.

Il existe cependant certaines situations où CARP ne pourra pas vous venir en aide. La conception de CARP est telle que les membres d'un groupe doivent appartenir au même réseau physique avec une adresse IP fixe, bien que depuis l'introduction de la directive carpdev il n'y ait plus besoin d'adresse IP pour les interfaces physiques. De même, les services nécessitant une connexion constante au serveur (tels que SSH ou IRC) ne seront pas transférés de manière transparente aux autres systèmes, bien que dans ce cas, CARP puisse aider à minimiser le temps d'arrêt. CARP, lui-même, ne synchronise pas les données entre applications, ceci doit être fait au travers de "procédés alternatifs" tels que pfsync(4) (pour du filtrage redondant), rsync, pour dupliquer manuellement les données entre les machines, ou tout ce qui semble approprié à votre application.

6.11.2 - Configuration

Le contrôle de CARP s'effectue en deux endroits : sysctl(8) et ifconfig(8). Regardons tout d'abord les paramètres sysctls.

La première variable sysctl, net.inet.carp.allow, définit si l'hôte gère ou non les paquets CARP. Bien évidemment, ceci est nécessaire à l'utilisation de CARP. Cette variable sysctl est activée par défaut.

La seconde, net.inet.carp.arpbalance, est utilisée pour la balance de charge ("load balancing"). Si cette fonctionnalité est activée, CARP effectue une empreinte (hashage) de l'IP originaire de la requête. Cette empreinte est ensuite utilisée pour sélectionner à partir du groupe l'hôte virtuel qui prendra en charge cette requête. Cette fonctionnalité est désactivée par défaut.

La troisième, net.inet.carp.log, enregistre les erreurs CARP. Désactivée par défaut.

La quatrième, net.inet.carp.preempt active la sélection naturelle parmi les hôtes CARP. Le plus à même d'effectuer le travail (à savoir, celui qui est capable de s'annoncer le plus fréquemment) deviendra le maître. Celle-ci est désactivée par défaut, ce qui signifie qu'un système qui n'est pas maître ne tentera pas de (re)gagner ce status.

Toutes ces variables sysctl sont documentées dans sysctl(3).

Pour ce qui concerne le reste de la configuration de CARP, nous dépendrons d' ifconfig(8). Les commandes advbase et advskew, spécifiques à CARP, définissent l'intervalle entre les annonces CARP. La formule (en secondes) est advskew divisée par 256 puis ajoutée à advbase. advbase peut être utilisée pour diminuer le trafic réseau ou autoriser une plus grande latence avant qu'un hôte de sauvegarde ne prenne le relais ; advskew vous permet de contrôler quel hôte sera le maître sans trop de délais de basculement (si cela est nécessaire).

Ensuite, pass crée un mot de passe et vhid définit le numéro d'identification d'hôte virtuel du groupe CARP. Vous devez assigner un numéro unique pour chaque groupe CARP, même s'ils partagent (pour des raisons de balance de charge) la même adresse IP. CARP est limité à 255 groupes.

Enfin, carpdev spécifie l'interface appartenant à ce groupe CARP particulier. Par défaut, n'importe quelle interface possédant une adresse IP dans le même sous-réseau que celui assigné à l'interface CARP sera utilisée.

Voyons l'emploi de ces différents paramètres dans une configuration simple. Admettons que vous déployez deux serveurs Web identiques, rachael (192.168.0.5) et pris (192.168.0.6), afin de remplacer un ancien système à l'adresse 192.168.0.7. Les commandes :

rachael# ifconfig carp0 create rachael# ifconfig carp0 vhid 1 pass tyrell carpdev fxp0 \     192.168.0.7 netmask 255.255.255.0

créent l'interface carp0 et lui donnent un vhid de 1, le mot de passe tyrell, l'adresse IP 192.168.0.7 de masque 255.255.255.0 et assignent fxp0 en tant qu'interface membre. Afin de rendre ces changements permanents après un redémarrage, vous pouvez créer un fichier /etc/hostname.carp0 ressemblant à :

inet 192.168.0.7 255.255.255.0 192.168.0.255 vhid 1 pass tyrell carpdev fxp0
Notez qu'il faut ajouter l'adresse de diffusion ("broadcast") en plus du vhid et du mot de passe. Ce champ est nécessaire et est souvent cause d'erreurs en cas d'oubli.

Faites la même chose sur pris. Le système démarrant en premier son interface CARP deviendra le maître (en admettant que "preempt" est désactivé ; sinon, c'est l'inverse qui se produit).

Mais admettons que vous ne déployez pas cette solution à partir de zéro. Rachael était déjà en place à l'adresse 192.168.0.7. Comment allez- vous gérer cette situation ? Heureusement, CARP sait gérer ce genre de situation. Vous assignez simplement l'adresse à l'interface CARP et laissez vide l'adresse de l'interface physique spécifiée par le mot-clef `carpdev'. Cependant, il est plus propre d'avoir une adresse IP différente pour chaque système, cela rend les accès et la surveillance individuels bien plus simples.

Ajoutons un nouveau niveau de complexité ; nous souhaitons que rachael reste maître lorsque cela est possible. Plusieurs raisons peuvent nous pousser à cela : différences matérielles, simple préjudice, "si ce système n'est pas maître, c'est qu'il y a un problème", ou simplement connaître le maître par défaut sans avoir à recourir à des scripts envoyant par courriel l'analyse de la sortie d'ifconfig.

Sur rachael, nous utiliserons la variable sysctl créée précédemment puis nous éditerons /etc/sysctl.conf afin de rendre ce paramètre permanent.

rachael# sysctl net.inet.carp.preempt=1

Configurons également pris :

pris# ifconfig carp0 advskew 100

Ceci décale les annonces de pris, ce qui signifie que rachael sera maître s'il est fonctionnel.

Notez que si vous utilisez PF sur une machine CARP, vous devez utiliser "proto carp" sur toutes les interfaces concernées, avec une ligne similaire à :

pass on fxp0 proto carp keep state

6.11.3 - Balance de charge ("load balancing")

Effectuons une avance rapide de quelques mois. Notre entreprise de l'exemple précédent a grossi au point qu'un seul serveur Web interne arrive tout juste à gérer la charge. Que faire ? CARP à la rescousse. Il est temps d'essayer la balance de charge. Créons une nouvelle interface et un nouveau groupe CARP sur rachael :

rachael# ifconfig carp1 create rachael# ifconfig carp1 vhid 2 advskew 100 pass bryant carpdev fxp0 \     192.168.0.7 netmask 255.255.255.0

Sur pris, nous allons également créer un nouveau groupe et une nouvelle interface, puis activer la variable sysctl "preempt" :

pris# ifconfig carp1 create pris# ifconfig carp1 vhid 2 pass bryant carpdev fxp0 \     192.168.0.7 netmask 255.255.255.0 pris# sysctl net.inet.carp.preempt=1

A présent nous avons deux groupes CARP avec la même adresse IP. Chaque groupe est dirigé vers un hôte différent, ce qui signifie que rachael restera maître du premier groupe, mais que pris lui succédera comme maître dans le second.

Tout ce qu'il nous reste à faire désormais est d'activer la variable contrôlant la balance de charge sur les deux machines, comme nous l'avons vu précédemment :

# sysctl net.inet.carp.arpbalance=1

Bien que ces exemples ne soient que pour un cluster de deux machines, le même principe reste valable avec plus de systèmes. Notez en revanche qu'il n'est pas assuré que vous parveniez à une distribution de 50/50 sur les deux machines : CARP utilise une empreinte de l'adresse IP d'origine afin de savoir quel système répondra à la requête, indépendamment de la charge.

6.11.4 - Plus d'information sur CARP

6.12 - Utiliser OpenNTPD

Une horloge précise est importante pour plusieurs applications informatiques. Cependant, plusieurs personnes ont remarqué que leur montre à 5 euros est plus précise que leur ordinateur à 2000 euros. Certes, connaître la date et l'heure est une chose importante. Mais souvent, il est plus important de synchroniser plusieurs machines afin qu'elles s'accordent sur la date et l'heure actuelles. Durant un temps, ntp.org a produit une application "Network Time Protocol" (RFC1305, RFC2030), disponible dans le système des ports, et qui peut être utilisée pour synchroniser les horloges des machines à travers Internet. Cependant, c'est un programme difficile à configurer, dont le code est difficile à auditer, et qui nécessite une quantité de mémoire vive conséquente. En somme, c'est un programme qui rend bien des services à certaines personnes mais qui est loin d'être une solution pour tous les utilisateurs.

OpenNTPD est une tentative pour résoudre certains de ces problèmes en créant un programme compatible NTP qui soit facile à administrer, sûr, simple et qui vous permette d'avoir une horloge exacte sur votre ordinateur. Le service ntpd(8) d'OpenBSD est contrôlé travers le fichier de configuration /etc/ntpd.conf facile à comprendre.

En activant tout simplement ntpd(8) dans rc.conf.local, l'horloge de votre ordinateur avancera légèrement et restera synchronisée avec les serveurs de pool.ntp.org, une collection de serveurs de temps publics. Une fois votre horloge réglée de manière précise, ntpd la gardera à un haut degré d'exactitude. Cependant, si votre horloge est décalée de plus de quelques minutes, il est vivement recommandé de la régler plus précisément au démarrage car la synchronisation d'une horloge très décalée pourrait prendre des jours, voire des semaines. Vous pouvez la régler manuellement en utilisant l'option "-s" de ntpd ou tout autre moyen permettant de mettre l'horloge de votre système à l'heure.

6.12.1 - "Mais OpenNTPD n'est pas aussi exact que l'application de ntp.org !"

C'est probablement vrai. Ce n'est pas un des objectifs de la conception d'OpenNTPD. Ce programme a été d'abord conçu pour être libre, simple, fiable et sécurisé. Si vous avez réellement besoin d'une précision de l'ordre de la micro- seconde, alors OpenNTPD n'est pas pour vous. Utilisez plutôt le ntpd de ntp.org. Ce dernier restera disponible dans les ports et comme paquetage. Nous n'avons aucun plan ou souhait de rendre OpenNTPD bouffi en y intégrant toutes les fonctionnalités possibles et imaginables.

6.12.2 - "Quelqu'un a prétendu qu'OpenNTPD était 'nuisible' !"

Certaines personnes n'ont pas compris le but d'OpenNTPD, à savoir un moyen de synchroniser l'horloge de votre ordinateur qui soit simple, sécurisé et facile à maintenir. Si la maintenance d'un temps aussi exact que possible est une chose importante, un certain nombre d'utilisateurs ont rapporté de meilleurs résultats avec OpenNTPD par rapport au programme ntpd de ntp.org. Si la sécurité est importante, le code d'OpenNTPD est beaucoup plus lisible (et donc auditable) et a été écrit en utilisant les appels de fonction natifs d'OpenBSD tels que strlcpy, au lieu d'utiliser des fonctions plus portables telles que strcpy. Il a été écrit avec des principes sécurité dès le début. La sécurité n'a pas été ajoutée par la suite. Si le fait d'amener autant de personnes que possible à utiliser la synchronisation du temps est une chose précieuse, OpenNTPD rend une telle entreprise très facile pour beaucoup de personnes. Si cela est "nuisible", alors nous souhaitons ce genre de nuisance.

Il y a des applications pour lesquelles le programme ntpd de ntp.org est plus approprié, cependant nous croyons qu'OpenNTPD est plus que suffisant pour une large majorité d'utilisateurs.

Une réponse plus complète donnée par l'un des mainteneurs d'OpenNTPD et concernant ce fait est disponible ici.

6.12.3 - Pourquoi mes autres machines ne peuvent pas se synchroniser avec OpenNTPD?

Par défaut, ntpd(8) n'écoute sur aucune adresse. Ainsi, pour l'utiliser en tant que serveur, vous devez décommenter la ligne "#listen on *" dans /etc/ntpd.conf et redémarrer le service ntpd(8). Bien entendu, si vous préférez écouter sur une adresse particulière plutôt que sur toutes celles disponibles, remplacez "*" par l'adresse correspondante.

Lorsque ntpd(8) écoute il se peut que les autres machines ne puissent toujours pas se synchroniser ! Lorsque que le service ntpd(8) vient juste de démarrer (par exemple si vous venez de le redémarrer suite à un changement dans ntpd.conf) il se peut qu'il refuse la synchronisation des clients en attendant que lui-même ajuste sa propre horloge a un certain degré de stabilité. Lorsque ntpd(8) considère que son information temporelle est stable, il l'annonce par le message "clock now synced" dans /var/log/daemon. Même si l'horloge système est assez correcte au démarrage, cela peut prendre jusqu'à 10 minutes avant d'être synchronisé et des heures voire des jours si celle-ci est décalée.

6.13 - Quels sont les types de cartes Sans Fil supportées par OpenBSD ?

OpenBSD supporte un certain nombre de chipsets sans fil : (AP) signifie que la carte peut être utilisée comme point d'accès.
(NFF) signifie que la puce nécessite un firmware non-libre qui ne peut pas être inclu dans OpenBSD.

Les adaptateurs basés sur ces composants peuvent être utilisés de la même façon que n'importe quel autre adaptateur réseau pour connecter un système OpenBSD à un réseau sans fil existant, et sont configurés de façon standard à l'aide d' ifconfig(8) (prière de consulter les pages du manuel pour les détails précis). Certaines cartes peuvent aussi être utilisées en mode "Host-Based Access Point", ce qui leur permet d'être utilisées comme un point d'accès sans fil pour votre réseau, intégré à votre pare-feu.

Notez que pour utiliser les cartes à base de chipset Intel, vous devrez récupérer les firmwares dont Intel refuse la libre distribution, ce qui empêche qu'ils soient inclus dans OpenBSD. Lorsque cela est possible, les pages de manuel correspondantes incluent les informations de contact afin que vous puissiez contacter les bonnes personnes chez les constructeurs pour leur faire savoir ce que vous pensez de cette situation ou de les informer sur le produit que vous avez acheté à la place.

Une autre méthode pour permettre à un pare-feu OpenBSD de fournir un accès sans fil est d'utiliser une carte conventionnelle et un point d'accès externe en mode pont. Cette méthode a l'avantage de vous permettre de positionner l'antenne là où elle est la plus efficace.

6.14 - Comment puis-je mettre en oeuvre un routage multi-chemin à coût égal ?

Le routage multi-chemin à coût égal permet d'avoir de multiples routes vers le même réseau, tel que la route par défaut (0.0.0.0/0), dans la table de routage. Lorsque le noyau recherche une route pour déterminer où acheminer des paquets destinés à un réseau donné, il pourra alors choisir parmi les routes à coût égal. Dans la majorité des cas, un routage multi-chemin est utilisé pour redonder des connexions "montantes" telles que les connexions vers Internet.

La commande route(8) est employée pour ajouter, modifier et supprimer des routes dans la table de routage. L'argument -mpath est utilisé lors de l'ajout de routes s'inscrivant dans un politique de routage multi-chemin.

# route add -mpath default 10.130.128.1
# route add -mpath default 10.132.0.1

Vérifiez les routes :

# netstat -rnf inet | grep default default 10.130.128.1 UGS 2 134 - fxp1 default 10.132.0.1 UGS 0 172 - fxp2

A travers cet exemple, nous pouvons voir que la route par défaut pointe vers 10.130.128.1, accessible par le biais de l'interface fxp1 tandis que l'autre route par défaut pointe vers 10.132.0.1 qui est accessible par le biais de l'interface fxp2.

Etant donné que le fichier mygate(5) ne supporte pas encore les routes par défaut multi-chemin, les commandes précitées devraient être ajoutées à la fin des fichiers hostname.if(5) correspondant aux interfaces fxp1 et fxp2. Le fichier /etc/mygate devrait être supprimé.

/etc/hostname.fxp1
!route add -mpath default 10.130.128.1
/etc/hostname.fxp2
!route add -mpath default 10.132.0.1

Enfin, n'oubliez pas d'activer le support de routes multi-chemin à l'aide de la variable sysctl(3) adéquate.

# sysctl net.inet.ip.multipath=1
# sysctl net.inet6.ip6.multipath=1

Assurez-vous d'éditer sysctl.conf(5) pour rendre les modifications permanentes.

Maintenant essayez d'effectuer un traceroute vers des destinations différentes. Le noyau partagera le traffic entre les différentes routes multi-chemin.

# traceroute -n 154.11.0.4 traceroute to 154.11.0.4 (154.11.0.4), 64 hops max, 60 byte packets 1 10.130.128.1 19.337 ms 18.194 ms 18.849 ms 2 154.11.95.170 17.642 ms 18.176 ms 17.731 ms 3 154.11.5.33 110.486 ms 19.478 ms 100.949 ms 4 154.11.0.4 32.772 ms 33.534 ms 32.835 ms # traceroute -n 154.11.0.5 traceroute to 154.11.0.5 (154.11.0.5), 64 hops max, 60 byte packets 1 10.132.0.1 14.175 ms 14.503 ms 14.58 ms 2 154.11.95.38 13.664 ms 13.962 ms 13.445 ms 3 208.38.16.151 13.964 ms 13.347 ms 13.788 ms 4 154.11.0.5 30.177 ms 30.95 ms 30.593 ms

Pour de plus amples informations concernant la manière de choisir une route, veuillez vous référer à la RFC2992, "Analysis of an Equal-Cost Multi-Path Algorithm".

Il est utile de noter que si une interface utilisée par une route multi-chemin tombe (perte de signal par exemple), le noyau acheminera tout de même des paquets à travers cette interface. Ces paquets seront bien entendus perdus. Il est hautement recommandé d'utiliser ifstated(8) pour vérifier l'état des interfaces et ajuster la table de routage si besoin.

[Index de la FAQ] [Section 5 - Construire le Système à partir des Sources] [Section 7 - Contrôles du clavier et de l'affichage]

[back] www@openbsd.org
$OpenBSD: faq6.html,v 1.82 2007/05/02 15:10:00 jufi Exp $