13.2. Configurations obscures

Bon, il y a beaucoup de paramètres qui peuvent être modifiés. Nous essayons de tous les lister. Voir aussi une documentation partielle dans Documentation/ip-sysctl.txt.

Certaines de ces configurations ont des valeurs par défaut différentes suivant que vous répondez Yes ou No à la question Configure as router and not host lors de la compilation du noyau.

Oskar Andreasson a une page sur ces options et il apparaît qu'elle soit meilleure que la notre. De ce fait, allez également voir http://ipsysctl-tutorial.frozentux.net/.

13.2.1. ipv4 générique

En remarque générale, les fonctionnalités de limitation de débit ne fonctionnent pas sur l'interface loopback. N'essayez donc pas de les tester localement. Les limites sont exprimées en « tic-tac » (jiffies) et elles utilisent obligatoirement le Token Bucket Filter mentionné plus tôt.

[NdT : le terme jiffies désigne un mouvement régulier, faisant référence au « tic-tac » d'une horloge. Dans le noyau lui-même, une variable globale nommée jiffies est incrémentée à chaque interruption d'horloge]

Le noyau a une horloge interne qui tourne à HZ impulsions (ou jiffies) par seconde. Sur Intel, HZ est la plupart du temps égale à 100. Donc, configurer un fichier *_rate à, disons 50, autorise 2 paquets par seconde. Le Token Bucket Filter est également configuré pour autoriser une rafale de données de 6 paquets au plus, si suffisamment de jetons ont été gagnés.

Plusieurs éléments de la liste suivante proviennent du fichier /usr/src/linux/Documentation/networking/ip-sysctl.txt, écrit par Alexey Kuznetsov et Andi Kleen.

/proc/sys/net/ipv4/icmp_destunreach_rate

Si le noyau décide qu'il ne peut pas délivrer un paquet, il le rejettera et enverra à la source du paquet un ICMP notifiant ce rejet.

/proc/sys/net/ipv4/icmp_echo_ignore_all

N'agit en aucun cas comme écho pour les paquets. Ne configurez pas ceci par défaut. Cependant, si vous êtes utilisé comme relais dans une attaque de Déni de Services, cela peut être utile.

/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts [Utile]

Si vous pinguez l'adresse de diffusion d'un réseau, tous les hôtes sont sensés répondre. Cela permet de coquettes attaques de déni de service. Mettez cette valeur à 1 pour ignorer ces messages de diffusion.

/proc/sys/net/ipv4/icmp_echoreply_rate

Le débit auquel les réponses echo sont envoyées aux destinataires.

/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

Configurer ceci pour ignorer les erreurs ICMP d'hôtes du réseau réagissant mal aux trames envoyées vers ce qu'ils perçoivent comme l'adresse de diffusion.

/proc/sys/net/ipv4/icmp_paramprob_rate

Un message ICMP relativement peu connu, qui est envoyé en réponse à des paquets qui ont des en-têtes IP ou TCP erronés. Avec ce fichier, vous pouvez contrôler le débit auquel il est envoyé.

/proc/sys/net/ipv4/icmp_timeexceed_rate

Voici la célèbre cause des « étoiles Solaris » dans traceroute. Limite le nombre de messages ICMP Time Exceeded envoyés.

/proc/sys/net/ipv4/igmp_max_memberships

Nombre maximal de sockets igmp (multidistribution) en écoute sur l'hôte. FIXME: Est-ce vrai ?

/proc/sys/net/ipv4/inet_peer_gc_maxtime

FIXME : Ajouter une petite explication sur le stockage des partenaires internet (inet peer) ? Intervalle de temps minimum entre deux passages du ramasse-miettes. Cet intervalle est pris en compte lors d'une faible (voire inexistante) utilisation du pool. Mesuré en jiffies. [NdT : Le pool désigne ici la liste des adresses IP des partenaires internet.]

/proc/sys/net/ipv4/inet_peer_gc_mintime

Intervalle de temps minimum entre deux passages du ramasse-miettes. Cet intervalle est pris en compte lors d'une utilisation intensive du pool. Mesuré en jiffies.

/proc/sys/net/ipv4/inet_peer_maxttl

Durée de conservation maximale des enregistrements. Les entrées non utilisées expireront au bout de cet intervalle de temps (c'est-à-dire quand le nombre d'entrées dans le pool est très petit). Mesuré en jiffies.

/proc/sys/net/ipv4/inet_peer_minttl

Durée de conservation minimale des enregistrements. Devrait être suffisante pour prendre en compte le temps de vie des fragments sur l'hôte qui doit réassembler les paquets. Cette durée minimale est garantie si le nombre d'éléments dans le pool est inférieur au seuil fixé par inet_peer_threshold.

/proc/sys/net/ipv4/inet_peer_threshold

Taille approximative de l'espace de stockage des partenaires internet. A partir de ce seuil, les entrées sont effacées. Ce seuil détermine la durée de vie des entrées, ainsi que les intervalles de temps entre deux déclenchements du ramasse-miettes. Plus il y a d'entrées, plus le temps de vie est faible et plus l'intervalle du ramasse-miettes est faible.

/proc/sys/net/ipv4/ip_autoconfig

Ce fichier contient la valeur 1 si l'hôte a reçu sa configuration IP par RARP, BOOTP, DHCP ou un mécanisme similaire. Autrement, il contient la valeur zéro.

/proc/sys/net/ipv4/ip_default_ttl

Durée de vie (TTL) des paquets. Fixer à la valeur sûre de 64. Augmentez-la si vous avez un réseau immense, mais pas « pour s'amuser » : les boucles sans fin d'un mauvais routage sont plus dangereuses si le TTL est élevé. Vous pouvez même envisager de diminuer la valeur dans certaines circonstances.

/proc/sys/net/ipv4/ip_dynaddr

Vous aurez besoin de positionner cela si vous utilisez la connexion à la demande avec une adresse d'interface dynamique. Une fois que votre interface a été configurée, toutes les sockets TCP locaux qui n'ont pas eu de paquets de réponse seront retraitées pour avoir la bonne adresse. Cela résout le problème posé par une connexion défectueuse ayant configuré une interface, suivie par une deuxième tentative réussie (avec une adresse IP différente).

/proc/sys/net/ipv4/ip_forward

Le noyau doit-il essayer de transmettre les paquets ? Désactivé par défaut.

/proc/sys/net/ipv4/ip_local_port_range

Intervalle des ports locaux pour les connexions sortantes. En fait, assez petit par défaut, 1024 à 4999.

/proc/sys/net/ipv4/ip_no_pmtu_disc

Configurez ceci si vous voulez désactiver la découverte du MTU de chemin, une technique pour déterminer le plus grand MTU possible sur votre chemin. Voir aussi la section sur la découverte du MTU de chemin dans le chapitre Recettes de cuisine.

/proc/sys/net/ipv4/ipfrag_high_thresh

Mémoire maximum utilisée pour réassembler les fragments IP. Quand ipfrag_high_thresh octets de mémoire sont alloués pour cela, le gestionnaire de fragments rejettera les paquets jusqu'à ce que ipfrag_low_thresh soit atteint.

/proc/sys/net/ipv4/ip_nonlocal_bind

Configurez ceci si vous voulez que vos applications soient capables de se lier à une adresse qui n'appartient pas à une interface de votre système. Ceci peut être utile quand votre machine est sur un lien non-permanent (ou même permanent). Vos services sont donc capables de démarrer et de se lier à une adresse spécifique quand votre lien est inactif.

/proc/sys/net/ipv4/ipfrag_low_thresh

Mémoire minimale utilisée pour réassembler les fragments IP.

/proc/sys/net/ipv4/ipfrag_time

Temps en secondes du maintien d'un fragment IP en mémoire.

/proc/sys/net/ipv4/tcp_abort_on_overflow

Une option booléenne contrôlant le comportement dans le cas de nombreuses connexions entrantes. Quand celle-ci est activée, le noyau envoie rapidement des paquets RST quand un service est surchargé.

/proc/sys/net/ipv4/tcp_fin_timeout

Temps de maintien de l'état FIN-WAIT-2 pour un socket dans le cas où il a été fermé de notre côté. Le partenaire peut être défectueux et ne jamais avoir fermé son côté ou même mourir de manière inattendue. La valeur par défaut est de 60 secondes. La valeur usuelle utilisée dans le noyau 2.2 était de 180 secondes. Vous pouvez la remettre, mais rappelez vous que si votre machine a un serveur WEB surchargé, vous risquez de dépasser la mémoire avec des kilotonnes de sockets morts. Les sockets FIN-WAIT2 sont moins dangereux que les sockets FIN-WAIT1 parce qu'ils consomment au maximum 1,5K de mémoire, mais ils ont tendance à vivre plus longtemps. Cf tcp_max_orphans.

/proc/sys/net/ipv4/tcp_keepalive_time

Durée entre l'envoi de deux messages keepalive quand l'option keepalive est activée. Par défaut : 2 heures.

/proc/sys/net/ipv4/tcp_keepalive_intvl

A quelle fréquence les sondes sont retransmises lorsqu'il n'y a pas eu acquittement de sonde. Par défaut : 75 secondes.

/proc/sys/net/ipv4/tcp_keepalive_probes

Combien de sondes TCP keepalive seront envoyées avant de décider que la connexion est brisée. Par défaut : 9. En multipliant par tcp_keepalive_intvl, cela donne le temps pendant lequel un lien peut être actif sans donner de réponses après l'envoi d'un keepalive.

/proc/sys/net/ipv4/tcp_max_orphans

Nombre maximum de sockets TCP qui ne sont pas reliés à un descripteur de fichier utilisateur, géré par le système. Si ce nombre est dépassé, les connexions orphelines sont immédiatement réinitialisées et un avertissement est envoyé. Cette limite existe seulement pour prévenir des attaques de déni de services simples. Vous ne devez pas compter sur ceci ou diminuer cette limite artificiellement, mais plutôt l'augmenter (probablement après avoir augmenté la mémoire) si les conditions du réseau réclament plus que cette valeur par défaut et régler vos services réseau pour qu'ils détruisent sans tarder ce type d'état. Laissez-moi vous rappeler encore que chaque orphelin consomme jusqu'à environ 64K de mémoire non swappable.

/proc/sys/net/ipv4/tcp_orphan_retries

Combien d'essais avant de détruire une connexion TCP, fermée par notre côté. La valeur par défaut de 7 correspond à un temps d'environ 50s à 16 min suivant le RTO. Si votre machine supporte un serveur Web, vous pouvez envisager de baisser cette valeur, dans la mesure où de tels sockets peuvent consommer des ressources significatives. Cf tcp_max_orphans.

/proc/sys/net/ipv4/tcp_max_syn_backlog

Nombre maximum de requêtes d'une connexion mémorisée, qui n'avait pas encore reçu d'accusé de réception du client connecté. La valeur par défaut est de 1024 pour des systèmes avec plus de 128 Mo de mémoire et 128 pour des machines avec moins de mémoire. Si un serveur souffre de surcharge, essayez d'augmenter ce nombre. Attention ! Si vous positionnez une valeur supérieure à 1024, il serait préférable de changer TCP_SYNQ_HSIZE dans le fichier include/net/tcp.h pour garder TCP_SYNQ_HSIZE*16 <= tcp_max_syn_backlog et de recompiler de noyau.

/proc/sys/net/ipv4/tcp_max_tw_buckets

Nombre maximum de sockets timewait gérées par le système simultanément. Si ce nombre est dépassé, le socket timewait est immédiatement détruit et un message d'avertissement est envoyé. Cette limite n'existe que pour prévenir des attaques de déni de services simples. Vous ne devez pas diminuer cette limite artificiellement, mais plutôt l'augmenter (probablement après avoir augmenté la mémoire) si les conditions du réseau réclament plus que cette valeur par défaut.

/proc/sys/net/ipv4/tcp_retrans_collapse

Compatibilité bug à bug avec certaines imprimantes défectueuses. Tentative d'envoi de plus gros paquets lors de la retransmission pour contourner le bug de certaines piles TCP.

/proc/sys/net/ipv4/tcp_retries1

Combien d'essais avant de décider que quelque chose est erroné et qu'il est nécessaire d'informer de cette suspicion la couche réseau. La valeur minimale du RFC est de 3. C'est la valeur par défaut ; elle correspond à un temps d'environ 3 sec à 8 min suivant le RTO.

/proc/sys/net/ipv4/tcp_retries2

Combien d'essais avant de détruire une connexion TCP active. Le RFC 1122 précise que la limite ne devrait pas dépasser 100 secondes. C'est un nombre trop petit. La valeur par défaut de 15 correspond à un temps de environ 13 à 30 minutes suivant le RTO.

/proc/sys/net/ipv4/tcp_rfc1337

Ce booléen active un rectificatif pour « l'assassinat hasardeux des time-wait dans tcp », décrit dans le RFC 1337. S'il est activé, le noyau rejette les paquets RST pour les sockets à l'état de time-wait. Par défaut : 0

/proc/sys/net/ipv4/tcp_sack

Utilise un ACK sélectif qui peut être utilisé pour signifier que des paquets spécifiques sont manquant. Facilite ainsi une récupération rapide.

/proc/sys/net/ipv4/tcp_stdurg

Utilise l'interprétation du RFC Host Requirements du champ TCP pointeur urgent. La plupart des hôtes utilisent la vieille interprétation BSD. Donc, si vous activez cette option, il se peut que Linux ne communique plus correctement avec eux. Par défaut : FALSE (FAUX)

/proc/sys/net/ipv4/tcp_syn_retries

Nombre de paquets SYN que le noyau enverra avant de tenter l'établissement d'une nouvelle connexion.

/proc/sys/net/ipv4/tcp_synack_retries

Pour ouvrir l'autre côté de la connexion, le noyau envoie un SYN avec un ACK superposé (piggyback), pour accuser réception du SYN précédemment envoyé. C'est la deuxième partie de la poignée de main à trois voies (threeway handshake). Cette configuration détermine le nombre de paquets SYN+ACK à envoyer avant que le noyau n'abandonne la connexion.

/proc/sys/net/ipv4/tcp_timestamps

Les estampillages horaires sont utilisés, entre autres, pour se protéger du rebouclage des numéros de séquence. On peut concevoir qu'un lien à 1 gigabit puisse de nouveau rencontrer un numéro de séquence précédent avec une valeur hors-ligne parcequ'il était d'une génération précédente. L'estampillage horaire permet de reconnaître cet « ancien paquet ».

/proc/sys/net/ipv4/tcp_tw_recycle

Mise en place du recyclage rapide des sockets TIME-WAIT. La valeur par défaut est 1. Celle-ci ne devrait pas être changée sans le conseil/demande d'experts techniques.

/proc/sys/net/ipv4/tcp_window_scaling

TCP/IP autorise normalement des fenêtres jusqu'à une taille de 65535 octets. Pour des réseaux vraiment rapides, cela peut ne pas être assez. Les options windows scaling autorisent des fenêtres jusqu'au gigaoctet, ce qui est adapté pour les produits à grande bande passante.

13.2.2. Configuration des périphériques

DEV peut désigner soit une interface réelle, soit all, soit default. Default change également les paramètres des interfaces qui seront créées par la suite.

/proc/sys/net/ipv4/conf/DEV/accept_redirects

Si un routeur décide que vous l'utilisez à tort (c'est-à-dire qu'il a besoin de ré-envoyer votre paquet sur la même interface), il vous enverra un message ICMP Redirect. Cela présente cependant un petit risque pour la sécurité, et vous pouvez le désactiver ou utiliser les redirections sécurisées.

/proc/sys/net/ipv4/conf/DEV/accept_source_route

Plus vraiment utilisé. On l'utilisait pour être capable de donner à un paquet une liste d'adresses IP à visiter. Linux peut être configuré pour satisfaire cette option IP.

/proc/sys/net/ipv4/conf/DEV/bootp_relay

Accepte les paquets avec une adresse source 0.b.c.d et des adresses destinations qui ne correspondent ni à cet hôte, ni au réseau local. On suppose qu'un démon de relais BOOTP interceptera et transmettra de tels paquets.

La valeur par défaut est 0, puisque cette fonctionnalité n'est pas encore implémentée (noyau 2.2.12).

/proc/sys/net/ipv4/conf/DEV/forwarding

Active ou désactive la transmission IP sur cette interface.

/proc/sys/net/ipv4/conf/DEV/log_martians

Voir la section sur le Filtrage de Chemin Inverse.

/proc/sys/net/ipv4/conf/DEV/mc_forwarding

Si vous faites de la transmission multidistribution (multicast) sur cette interface.

/proc/sys/net/ipv4/conf/DEV/proxy_arp

Si vous configurez ceci à 1, cet interface répondra aux requêtes ARP pour les adresses que le noyau doit router. Peut être très utile si vous mettez en place des « pseudo ponts ip ». Prenez bien garde d'avoir des masques de sous-réseau corrects avant d'activer cette option. Faites également attention que le rp_filter agisse aussi sur le requêtes ARP !

/proc/sys/net/ipv4/conf/DEV/rp_filter

Voir la section sur le Filtrage de Chemin Inverse.

/proc/sys/net/ipv4/conf/DEV/secure_redirects

Accepte les messages de redirection ICMP seulement pour les passerelles indiquées dans la liste des passerelles par défaut. Activé par défaut.

/proc/sys/net/ipv4/conf/DEV/send_redirects

Active la possibilité d'envoyer les messages de redirections mentionnées ci-dessus.

/proc/sys/net/ipv4/conf/DEV/shared_media

Si cela n'est pas activé, le noyau ne considère pas que différents sous-réseaux peuvent communiquer directement sur cette interface. La configuration par défaut est Yes.

/proc/sys/net/ipv4/conf/DEV/tag

FIXME: à remplir

13.2.3. Politique de voisinage

DEV peut désigner soit une interface réelle, soit all, soit default. Default change également les paramètres des interfaces qui seront créées par la suite.

/proc/sys/net/ipv4/neigh/DEV/anycast_delay

Valeur maximum du délai aléatoire de réponse exprimé en jiffies (1/100 sec) aux messages de sollicitation des voisins. N'est pas encore implémenté (Linux ne possède pas encore le support anycast).

/proc/sys/net/ipv4/neigh/DEV/app_solicit

Détermine le nombre de requêtes à envoyer au démon ARP de l'espace utilisateur. Utilisez 0 pour désactiver.

/proc/sys/net/ipv4/neigh/DEV/base_reachable_time

Une valeur de base utilisée pour le calcul du temps aléatoire d'accès comme spécifié dans le RFC2461.

/proc/sys/net/ipv4/neigh/DEV/delay_first_probe_time

Délai avant de tester pour la première fois si le voisin peut être atteint. (voir gc_stale_time)

/proc/sys/net/ipv4/neigh/DEV/gc_stale_time

Détermine la fréquence à laquelle on doit vérifier les vieilles entrées ARP. Si une entrée est obsolète, elle devra de nouveau être résolue (ce qui est utile quand une adresse IP a été attribuée à une autre machine). Si ucast_solicit est supérieur à 0, alors on essaie d'abord d'envoyer un paquet ARP directement à l'hôte connu. Si cela échoue, et que mcast_solicit est supérieur à 0, alors une requête ARP est multidiffusée.

/proc/sys/net/ipv4/neigh/DEV/locktime

Une entrée ARP n'est remplacée par une nouvelle que si l'ancienne est au moins présente depuis locktime. Cela évite trop d'écriture dans le cache.

/proc/sys/net/ipv4/neigh/DEV/mcast_solicit

Nombre maximum d'essais consécutifs pour une sollicitation multicast.

/proc/sys/net/ipv4/neigh/DEV/proxy_delay

Temps maximum (le temps réel est aléatoire et compris entre 0 et proxytime) avant de répondre à une requête ARP pour laquelle nous avons une entrée de proxy ARP. Peut être utilisé dans certains cas pour se prémunir des inondations réseaux.

/proc/sys/net/ipv4/neigh/DEV/proxy_qlen

Longueur maximale de la file d'attente du temporisateur de cache arp en attente (Voir proxy_delay).

/proc/sys/net/ipv4/neigh/DEV/retrans_time

Le temps, exprimé en jiffies (1/100 sec), entre deux requêtes ARP. Utilisé pour la résolution d'adresses et pour déterminer si un voisin est inaccessible.

/proc/sys/net/ipv4/neigh/DEV/ucast_solicit

Nombre maximum de requêtes ARP unicast.

/proc/sys/net/ipv4/neigh/DEV/unres_qlen

Longueur maximum de la file d'attente pour la requête ARP en cours : le nombre de paquets qui sont acceptés des autres couches pendant la résolution ARP d'une adresse.

Internet QoS: Architectures and Mechanisms for Quality of Service, Zheng Wang, ISBN 1-55860-608-4

Livre traitant des sujets liés à la qualité de service. Bien pour comprendre les concepts de base.

13.2.4. Configuration du routage

/proc/sys/net/ipv4/route/error_burst

Ces paramètres sont utilisés pour limiter le nombre de messages d'avertissement écrits dans le journal du noyau par le code de routage. Plus le paramètre error_burst est grand, moins il y aura de messages. Error_burst contrôle le moment où les messages seront supprimés. Les configurations par défaut se limitent à un message d'avertissement toutes les cinq secondes.

/proc/sys/net/ipv4/route/error_cost

Ces paramètres sont utilisés pour limiter le nombre de messages d'avertissement écrits dans le journal du noyau par le code de routage. Plus le paramètre error_cost est grand, moins il y aura de messages. error_burst contrôle le moment où les messages seront jetés. Les configurations par défaut se limitent à un message d'avertissement toutes les cinq secondes.

/proc/sys/net/ipv4/route/flush

L'écriture dans ce fichier provoque la vidange du cache du routage.

/proc/sys/net/ipv4/route/gc_elasticity

Valeurs qui contrôlent la fréquence et le comportement de l'algorithme garbage collection du cache de routage. Ceci peut être important en cas de défaut. Au moins gc_timeout secondes s'écouleront avant que le noyau ne passe à une autre route si la précédente n'est plus opérationnelle. Configuré par défaut à 300. Diminuez cette valeur si vous voulez passer plus rapidement ce type de problème.

Voir aussi ce message par Ard van Breemen.

/proc/sys/net/ipv4/route/gc_interval

Voir /proc/sys/net/ipv4/route/gc_elasticity.

/proc/sys/net/ipv4/route/gc_min_interval

Voir /proc/sys/net/ipv4/route/gc_elasticity.

/proc/sys/net/ipv4/route/gc_thresh

Voir /proc/sys/net/ipv4/route/gc_elasticity.

/proc/sys/net/ipv4/route/gc_timeout

Voir /proc/sys/net/ipv4/route/gc_elasticity.

/proc/sys/net/ipv4/route/max_delay

Délai d'attente pour la vidange du cache du routage.

/proc/sys/net/ipv4/route/max_size

Taille maximum du cache de routage. Les vieilles entrées seront purgées quand le cache aura atteint cette taille.

/proc/sys/net/ipv4/route/min_adv_mss

FIXME: à remplir

/proc/sys/net/ipv4/route/min_delay

Délai d'attente pour vider le cache de routage.

/proc/sys/net/ipv4/route/min_pmtu

FIXME: à remplir

/proc/sys/net/ipv4/route/mtu_expires

FIXME: à remplir

/proc/sys/net/ipv4/route/redirect_load

Facteurs qui déterminent si plus de redirections ICMP doivent être envoyées à un hôte spécifique. Aucune redirection ne sera envoyée une fois que la limite de charge (load limit) ou que le nombre maximum de redirections aura été atteint.

/proc/sys/net/ipv4/route/redirect_number

Voir /proc/sys/net/ipv4/route/redirect_load.

/proc/sys/net/ipv4/route/redirect_silence

Temporisation pour les redirections. Au dela de cette période, les redirections seront de nouveau envoyées, même si elles ont été stoppées parce que la charge ou le nombre limite a été atteint.