3 Routage

3.1 Fichiers à examiner

Les informations importantes sont éparpillés dans beaucoup de fichiers divers. Il n'existe pas de mécanisme de test de la cohérence. Il est donc indispensable de lister ces divers éléments.

/etc/rc.config  (n'existe plus dans $SuSE-8.1$)

/etc/hosts

/etc/dhcp.conf

/etc/route.conf (n'existe plus dans $SuSE-8.1$)

/etc/printcap

/etc/smb.conf

/etc/rc.config.d/firewall.rc.config

3.2 Examiner les paquets émis

tcpdump fait cela

3.3 Récupérer les morceaux

Le batch qyr a pour objectif la récupération de tous ces morceaux. Son listing est donné LISTING 11.

1. Les commandes /etc/init.d/* renvoient des messages en couleur (codes ANSI). Cette mise en forme est commandée par /etc/rc.status. Il faut donc désactiver ce mécanisme en déclarant TERM=raw au début du batch.

• La mise en page des règles de routage par ce batch qyr a été bricolée ... et reste approximative. Il faut revoir tout cela. De même les sauts de pages aux multiples de 63 lignes.

3.4 Dial on call

3.4.1 Remarques à caractère philosophique

1. Dans les anciens temps de la téléphonie, on appelait un ordinateur distant à travers un réseau téléphonique vocal. Au prix de la minute de téléphone, mieux valait appeler... juste le temps nécessaire. En ces temps là , le gestionnaire de barnum était point to point protocol (ppp).
2. Le client KdE kppp n'a jamais vraiment fonctionné. Opinion formulée en 2001 : est devenu obsolète avec le développement du réseau par câble. Dans les lieux désolés sans réseau permanent, mieux valait utiliser une machine winxx comme passerelle.
3. Puis, les maniaques de la connexion sont revenus en force avec pppoE (ppp over Ethernet). Ce protocole a commencé par empoisonner l'adsl, puis (mars 2002) est venu empoisonner le câble monopolisé par wanadoo.
4. L'un des buts avoués est de vous déconnecter de force toutes les 24 heures, et vous empêchant ainsi d'avoir une adresse ip fixée par dhcp, et donc restant fixe au moins tant que la machine reste branchée.
5. Évidemment, des contournements sont apparus (dns dynamique). Le résultat principal est d'introduire une couche de plus, avec les surcoûts correspondants en temps et en débit. Un autre résultat est d'augmenter l'anonymat d'éventuelles agressions. En particulier, il est plus difficile de contacter les utilisateurs de bonne foi mais mal configurés.

3.4.2 kppp ($SuSE-6.2$)

1. Supprimer Lock option dans /etc/ppp/options.
2. Conflit modem souris
   • le port modem est respecté, tandis que le port souris semble recherché "best effort" : le conflit n'est visible qu'à l'activation du modem.
   • remarque : le port série requis n'est monté qu'à la demande. Ainsi, kde_control n'affiche interrupt 4 (= serial port) que lors d'une requête modem, tandis que interrupt 3 (= serial port) est affiché en permanence (souris).

• Comment avoir un dial on call (internet, mail, etc) ?
• Mort subite inexpliquée du nourrisson : kppp meurt assez souvent .... (kppp's helper process died ...)
• Vérifier que pppd est suid, ou que les utilisateurs sont dans le groupe dialout.

3.4.3 pppoed24 ($SuSE-7.2$)

1. Il faut rendre pppoed24, pppoed et pppd exécutables par les membres du groupe dialout.
2. Il faut rendre /etc/pppoed.conf lisible par les membres de dialout.
   • Il se trouve que SuseConfig ($SuSE-7.2$) réécrit cette autorisation à chaque fois : le batch qzq_anti_suse  fixe ce problème.
   • Il se trouve aussi que ce fichier contient en clair le password de la connexion : un choix est à faire. Il est stupide de devoir le faire.
3. La commande ifconfig permet de constater l'apparition d'un nouveau device, ppp0. Une habile sélection permet de récupérer l'adresse ip attribuée (batch ipipip).

   ip1=`/sbin/ifconfig eth0 | grep "inet addr"  
                            | sed -e "s/\ \ Bcast.*$//; s/^.*://"`  
   ip2=`/sbin/ifconfig ppp0 2>/dev/null | grep "inet addr"  
                            | sed -e "s/\ P-t-P.*$//; s/^.*://"`  
   echo $ip1"___"$ip2

4. Une commande ipsend permet d'envoyer cette adresse ip vers une machine ayant une adresse fixe, le tout sous le contrôle de cron (édition par kcron).
5. Le mécanisme d'encapsulation diminue la valeur de MTU qui est de 1500 pour le protocole Ethernet ordinaire. On constate que ppp0 est déclaré avec une valeur MTU=1490.
6. Le réglage de MTU pour les cartes Ethernet se trouve dans /etc/rc.config. On constate que la valeur MTU =1492 sur la deuxième carte du serveur, et sur la première carte d'une machine cliente sous linux suffit à faire fonctionner la chose.
7. Les valeurs à négocier pour MTU/MRU sont déclarées dans /etc/ppp/peers/pppoe24. La valeur positionnée par YaST2 est 1490. Si l'on met plus, par exemple 1524, la négociation avec wanadoo conduit à un MTU =1492.
8. Lorsque la machine client est sous winxx, le MTU se règle en donnant la valeur texte "1492" à la clef HKML/System/CurentControlSet/Services/Class/Nettrans/000x/MaxMtu. On peut constater la valeur à donner par la commande ping peer_to_peer_host -f -l 1464. Avec les $28$ octets de l'encapsulation par le protocole icmp, cela fait bien $1464+28=1492$ octets.
9. Sous WinXP, la clef est HKLM/System/CurrentControlSet/Services/Tcpip/Parameters/Interfaces/xxxxx/MTU. Repérer le bon interface (xxxxx) par son adresse ip. Remarque : 1500=5dc, 1492=5d4. Le MTU peut être envoyé par le serveur dhcp en positionnant : option interface-mtu 1492 ;
10. Le DNS du provider ne semble pas accessible par les machines winxx clientes. Déclarer un autre DNS peut être utile

3.4.4 pppoe ($SuSE-8.1$)

1. Consulter la documentation /usr/share/doc/packages/sysconfig.
2. Réglage du MTU dans le réseau interne. Inclure dans /etc/sysconfig/network/ifcfg-eth0 une ligne :

   MTU='1492'

3. Configuration par YaST2 (network_basic/dsl_configuration. Cela crée un fichier /etc/sysconfig/network/ifcfg-dsl0 qui contient les lignes suivantes

   DEVICE='eth1' 

   PPPMODE='pppoe' 

   PROVIDER='dsl-provider0' 

   STARTMODE='onboot' 

4. Le startmode est à l'origine manuel. Il est intéressant de remplacer cela par onboot, de façon à avoir cette connexion en permanence.
5. Le provider est en fait le nom d'un fichier /etc/sysconfig/network/providers/dsl-provider0, qui contient

   PROVIDER="DSL provider" 

   DSLSUPPORTED="yes" 

   MODEMSUPPORTED="no" 

   ISDNSUPPORTED="no" 

   USERNAME="le nom de connexion" 

   PASSWORD="le password en clair" 

   IDLETIME="300" 

   DEMAND="no" 

   DNS1="" 

   DNS2=""

6. Les diverses actions sont enregistrées dans le fichier /var/log/pppd.log (??? ré-expliquer où cela se configure...). On sait que le barnum est en vie lorsque /var/run/ppp0.pid existe.
7. Et en outre, il faut relancer périodiquement tout cela par un fichier cron.
   1. Créer un utilisateur xdialout:dialout. Placer dans xdialout/bin un lien vers ipse/bin/qso_sync_pppoed qui contient la véritable incantation de lancement du barnum.

      if test ! -f /var/run/ppp0.pid 

      then /sbin/ifup dsl0 

      fi

   2. Créer un fichier ipse/bin/qzs_send_pppoed qui envoie l'adresse obtenue vers un certain destinataire.

      tmp=`/sbin/ifconfig ppp0 2> /dev/null | grep 'inet addr' \ 

           | sed -e"s/^[^:]*:// ; s/\ .*$//"`

      echo . |  mail -s ipipip$tmp"___" douillet@ensait.fr

      echo "done ==> "$tmp

   3. Créer les deux fichiers cron dans /var/spool/cron/tabs. (??? plus de détails !!! ).

• Où est donc passé kcrontab ?

3.5 Providers en dhcp ($SuSE-8.1$)

3.5.1 Wanadou câble

De grandes manoeuvres financières ayant fait migrer ''wanadoo-câble'' en ''numericable'', il a fallu (02/07/2005) repasser la connexion en dhcp.

1. Reconfiguration des cartes réseau innocentes, de façon à revenir à la valeur MTU=1500 sur l'ensemble du réseau interne (1500 est le standard Ethernet, tandis que 1492 est une adaptation aux contraintes pppoe).
   1. Sur les machines unix, modifier /etc/sysconfig/network/ifcfg-eth0, puis valider par
      /sbin/ifdown eth0 
      /sbin/ifup eth0
   2. Sur les machines winxp, modifier la clef HKLM/System/CurrentControlSet/Services/Tcpip/Parameters/Interfaces/xxxxx/MTU. Repérer le bon interface (xxxxx) par son adresse ip. Remarque : 1500=5dc, 1492=5d4.
   3. Pour les autres machines winxx, le MTU se règle en donnant la valeur texte "1500" à la clef HKML/System/CurentControlSet/Services/Class/Nettrans/000x/MaxMtu.
2. Invalider la carte dsl0 par STARTMODE='off' dans /etc/sysconfig/network/ifcfg-dsl0.
3. Reconfigurer le firewall, la carte externe étant désormais eth1 et pas ppp0. Se reporter à la Subsection 1.7.
4. Réautoriser la modification dynamique de resolv.conf et de named.conf dans /etc/sysconfig/network/config.
5. Reconfigurer la carte réseau donnant sur l'extérieur par STARTMODE='onboot', BOOTPROTO='dhcp', puis valider par
   /sbin/ifdown eth1 
   /sbin/ifup eth1
6. On obtient alors les valeurs suivantes dans resolv.conf
   search modulonet.fr  
   nameserver 85.68.0.8  
   nameserver 85.68.0.7

3.5.2 free ($SuSE-9.3$)

connexion dhcp, adresse ip vraiment fixe.

3.5.3 neuf ($SuSE-10.2$)

Documentation sponsorisée par Bill Gates et MacroMedia. Cela se résume à : on branche les cables en les branchant. Et on constate que le "kit internet" ne délivre qu'une adresse ethernet non routable 192.168.1.20. A jeter.

3.6 Valider les modifications

1. Certaines modifications sont prises en compte immédiatement, d'autres doivent être resynchronisées. D'où les batchs qsx.
2. Les scripts de démarrage des démons ont changé de place. Depuis la $SuSE-7.2$, ils se trouvent désormais dans /etc/init.d au lieu de /sbin/init.d (cf TAB. 11).

   
   

   TAB. 11: Les scripts de démarrage

   
   

   
   

3. Le script qsn déconnecte pppoE. Il existe donc une option (qsn z) qui relance pppoE. Dans les deux cas, le script qsn se termine par le lancement de ifconfig (avec une temporisation).

• les adresses lues dans /etc/route.conf sont du texte ascii. Par conséquent 213.056.050.001 n'est pas reconnue comme étant 213.56.50.1. Par contre, les adresses lues dans /etc/hosts sont en numérique.

3.7 Serveur d'adresses dhcp

3.7.1 Ne pas saboter la passerelle

1. Lorsque l'on place le dhcp de la zone local.local sur une machine interne, il ne faut pas que la passerelle soit sabotée par le dhcp interne.
2. Le gateway de la passerelle doit rester le gateway externe (et pas réenvoyer sur la passerelle elle-même). En cas de problème, il faut repérer la passerelle externe, la confirmer et vérifier
   ifstatus eth1 
   route add default gw xx.xx.xx.xx ; route
3. Les serveurs dns de la passerelle doivent contenir explicitement les serveurs externes. Sinon les fonctions onboot (dont ntp) se passent mal.
4. Il se pourrait que les problèmes avec le gateway externe viennent d'une absence de réponse dns lors de l'enregistrement de cette passerelle (à tester en détail lorsque le problème de fixation des adresses ip sera résolu)
5. En bref, il faudrait que le dhcp interne et le dhcp externe ajoutent leurs fonctionnalités au lieu de les écraser mutuellement.

3.7.2 La version actuelle ($SuSE-10.2$)

1. Les packages concernés sont :

   dhcdbd

   dhcp d-bus daemon

   dhcpcd

   client dhcp par défaut (chrooted in /var/lib/dhcpcd)

   dhcp

   isc dhcp : common files

   ~-client

   isc dhcp : client

   ~-relay

   isc dhcp : relay

   ~-server

   isc dhcp : server

   ~-tools

   isc dhcp : tools

2. A partir de $SuSE-8.1$, le lancement se fait par les runlevels (niveaux 3 et 5) et la configuration du serveur se fait par /etc/dhcpd.conf. Pour la $SuSE-8.1$, un modèle de fichier de configuration se trouvait en /usr/share/doc/packages/dhcp/dhcpd.conf.
3. Pour la $SuSE-10.2$, lire les man et /usr/share/doc/packages/dhcp/README. Le démon ne démarre pas lorsque la syntaxe du fichier de configuration n'est pas correcte. En particulier, il faut une commande "ddns-update-style none" pour diriger les dialogues entre le service dhcp et le service ddns (dynamical dns). De toutes façons, la bonne marche du service dépend du DNS (ou du fichier /etc/hosts).
4. Configuration fixe d'une machine :

   host ZentEur {  
     hardware ethernet 00:48:54:82:e3:e8;  
     ddns-hostname zenteur;  
     fixed-address 215.56.50.88;  
   }

5. La carte serveuse est identifiée par son adresse mac (et non plus par son nom dynamique en ethx). Il n'est pas nécessaire que les autres cartes soient démarrées ou aient reçu une adresse (par un dhcp extérieur). Par contre, la carte serveuse doit être configurée on boot, avec une adresse statique.
6. La version 3.0.5-7 fournie avec $SuSE-10.2$ ne fonctionne pas correctement (pas de logs). Ceci est fixé par la 3.0.5-9 (YoU)
7. L'enregistrement des leases ne concerne que les adresses dynamiques. Ce n'est donc pas un bug si ce fichier reste vide lorsqu'il n'y a que des adresses fixes.
8. Une aide à la mise en place se trouve dans YaST (modules réseau). Est-ce bien utile ?

3.7.3 Sécurité

1. Pour des raisons de sécurité, le dhcp est maintenant exécuté sur une machine interne, pas sur le firewall.
2. Le démon est exécuté par dhcpd:nogroup plutôt que par root, et est de plus exécuté "chrooted". Le répertoire prison est /var/lib/dhcp/ et contient :
   /etc/localtime
   /etc/host.conf
   /etc/hosts
   /etc/resolv.conf... and you might have to keep these current if they are modified dynamically by other programs.
3. Les messages arrivent sur /var/log/dhcpd/dhcpd.log (commandé par dhcpd.conf et syslog).

3.7.4 Clients

1. Bien entendu, les clients doivent eux aussi être configurés. Le fichier correspondant est /etc/dhclient.conf, et l'activation se fait sous YaST.
2. Dans les anciennes versions, l'activation se faisait dans /etc/rc.config, clef "IFCONFIG_X".
3. Sous winx, le programme winipcfg est utile. Sous winx+, on obtient les mêmes fonctionnalités avec l'icône "câble réseau" (activer cette icône dans la fenêtre configuration de la carte).

3.7.5 Pour mémoire : anciennes versions

1. Jusqu'à $SuSE-7.2$, le lancement du serveur dhcp se décide dans /etc/rc.config par START_DHCPD = yes. La configuration du démon dépend de /etc/rc.config.d/dhcpd.rc.config.
2. Remarques jusqu'à $SuSE-8.1$ :
   1. Il faut que toutes les cartes réseau soient actives (avec une adresse ip fixée ou obtenue).
   2. Il faut que tous les réseaux (repérés par leur adresse de groupe) soient mentionnés, y compris pour dire qu'on ne leur parle pas.
   • Le démon a tendance à ne pas suivre les directives, et préfère écouter eth0. Renommer les interfaces en conséquence.
   • Caveat : l'identification carte physique - numéro ethx est commandée par le fichier /etc/modules.conf, tandis que l'adresse ip attribuée à un numéro ethx est commandée par le fichier /etc/sysconfig/network/ifcfg-eth0. Pour s'y retrouver, arrêter le réseau /etc/init.d/network/stop et décharger les modules par rmmod.
   • D'ailleurs, il est prudent d'utiliser des cartes réseau pilotées par des modules différents, cela permet une meilleure identification.
   • Dans le même genre d'idées, le routeur général doit être sur eth1 (sinon, le serveur dns n'est pas utilisable. La commande route donne alors le gateway par son adresse ip et non par son nom).

3.7.6 Traitement des logs du serveur dhcp

1. Premier principe : exploiter les logs depuis le compte d'un utilisateur spécial
2. Le traitement effectué est conditionné à la fois par la taille (très petite) du réseau et par le niveau de confiance (très élevé) dans les utilisateurs. Il s'agit donc uniquement de repérer des dysfonctionnements matériels.
3. Le traitement donne trois résultats : l'ensemble trié des identifiants utilisés ne serait-ce qu'une fois, l'ensemble trié des messages (sans les dates, ni les commentaires), la répartition chronologique des messages pour chaque carte concernée.
4. Constatations :
   1. Le fait que le serveur ne soit pas "authoritative" a été détecté plusieurs fois par le seul menteur, dans un contexte ancien et oublié (second démon dhcpd sous unix sur menteur ?)
   2. Lors du changement de carte réseau dans une machine, cette machine continue à bénéficier de son ancienne adresse " un certain temps" .
   3. Les noms de machine figurant dans le fichier dhcpd.conf ne sont pas utilisés. Pourquoi ?

3.8 Serveur dns

1. Charger tous les modules, c'est à dire : bind bind-chrootenv bind-doc bind-libs bind-libs-32bit bind-utils. Lire /usr/share/doc/packages/bind/arm/Bv9ARM.html (il y en a un paquet...).
2. Une zone est un groupement connexe sur lequel un serveur a autorité. Le serveur envoie des AA (authoritative answers).
3. YaST $\triangleright$ Network Services propose un utilitaire de configuration. Si le lancement n'est pas "on boot", le serveur est mort après l'utilitaire.
4. Lorsque le serveur fonctionne, il peut être le seul DNS déclaré de la machine. Puis être le seul DNS déclaré du réseau.
5. Le démon s'appelle named et s'exécute chrooted.
6. Le répertoire /etc/named.d/ contient les fichiers de configuration à inclure. Il y a forwarders.conf, fourni d'origine, et d'autres fichiers *.fonc. Cette extension est fantaisiste et destinée à différencier ces fichiers d'avec *.conf qui est inclus à l'intérieur de la section options.
7. Il faut un *.fonc pour décrire le mécanisme rncd
8. Il faut un *.fonc pour chaque lookup direct ou reverse. Quand on a ajouté quelque chose dans le répertoire named.d, il faut supprimer /etc/named.conf.include (déclenche une recompilation).

• Contrôle : rndc stats. Ne fonctionne pas (cherche /var/lib/named/var/log/named/named.stats). File not found s'il n'existe pas et acces denied s'il existe avec tous les droits d'écriture. Persiste même avec la manoeuvre rndc-confgen.

3.9 Login distant

3.9.1 ssh

1. Syntaxe : ssh -X machine_distante [-l utilisateur]
2. Les identifiants de connexion se trouvent dans ipse/.ssh.

3.9.2 telnet (deprecated)

1. Ne pas oublier d'installer le package telnet-server !!!
2. Activer le service dans /etc/inetd.conf
3. Consulter les traces dans auth.log.
4. Faire des essais en local et en semi-local.
5. Il est utile de disposer d'un visuel rappelant que l'on est sur une console à distance. Pour cela, on configure l'application konsole (cf Subsection 2.10).

3.10 ntp : time accuracy

3.10.1 A propos des horloges

1. Consulter le TimePrecision-HowTo : "Managing Accurate Date and Time HowTo". La section Installx/Configuration/Documentation/Howto décrit où diable se trouvent les HowTo.
2. Dans le monde Unix, il y a deux horloges. L'horloge matérielle -HWclock- et l'horloge immatérielle -SYSclock-. L'horloge matérielle (à quartz) est lue une fois au boot pour initialiser l'horloge immatérielle, puis est ignorée. A partir de là, SYSclock vit une vie erratique, utilisant une partie la puissance de calcul du processeur pour faire avancer ses aiguilles. Le mécanisme des interruptions fait que la gestion de SYSclock n'est qu'approximative. En conséquence, cette horloge se décale horriblement et il est nécessaire de mettre en oeuvre un mécanisme de resynchronisation.
3. La commande date lit la SYSclock, tandis que hwclock lit la HWclock.
4. Dans le monde tout court, l'heure n'est pas la même en tous les points du globe. Le fichier binaire /usr/lib/zoneinfo/localtime contient les descriptifs voulus. Plus précisément, ce fichier est un lien vers /etc/localtime qui lui-même est un lien vers le bon fichier de la base de données.
5. Cette base de données est située en /usr/share/zoneinfo/. Pour ce qui nous concerne, nous utilisons /usr/share/zoneinfo/Europe/Paris.
6. La TimeZone est également enregistrée dans le fichier /etc/sysconfig/clock. Ce fichier indique également si la HWclock est réglée en temps utc ou bien en temps local.
   HWCLOCK="-u" 
   TIMEZONE="Europe/Paris"

3.10.2 ntp ($SuSE-10.2$)

1. Package xntp
2. Serveurs : on peut utiliser des serveurs anonymes, ou des serveurs nommés, ou des serveurs décrits par une adresse ip (pour rester effectif même si le dns est en panne) :
   server 0.pool.ntp.org 
   chronos.cru.fr (195.220.94.163) 
   canon.inria.fr 
   ntp-p1.obspm.fr 
   ntp-sop.inria.fr 
   ntp1.curie.fr
3. Paramétrisation /etc/sysconfig/ntp (cf LISTING 12). Ce service doit être utilisé "chrooted".

   
   
   

4. Configuration /etc/ntp.conf(cf LISTING 13).

   
   
   

5. Le réglage par défaut ($SuSE-10.2$) des *.log ne convient pas. Préférer une gestion directe par syslog (Section 1.4) et envoyer le tout dans un répertoire spécial. Régler le niveau des *.log : logconfig =all ou bien logconfig =syncstatus +sysevents.
   • On constate que /var/log/ntp et /var/log/ntp sont acceptés comme fichiers *.log, mais que les autres échouent "Cannot open log file". En outre, on ne récupère pas tout (une partie va sur messages.log).
   • Erreur de syntaxe dans ntp.conf : à la ligne logconfig, il faut un espace devant le +, et pas d'espace après (comme pour le =).
6. Lanceur /etc/init.d/ntp. La variable INITIAL_NTPDATE règle le fonctionnement de la commande /etc/init.d/ntp ntptimeset : ou bien utiliser le serveur spécialement déclaré ou bien (valeur auto-x) les x premiers serveurs déclarés dans /etc/ntp.conf.
7. Lien avec dhcpd : définir un serveur de temps sur le réseau local, et utiliser ce serveur pour les autres machines du réseau local. Quelle est le meilleur endroit (passerelle ou dhcp ?).

3.10.3 Pour mémoire : ntp et $SuSE-8.1$

1. Le lanceur s'appelait xntpd. A spécifier aux niveaux 3 et 5 du runlevel-editor (dans YaST2).

• En utilisant "exactement" les mêmes configurations sur madras et moonlight, on obtient un serveur de temps reconnu (par un client TARDIS tournant sur une machine winxx du réseau interne) comme synchronisé sur madras, et reconnu non synchronisé sur moonlight.