13.2. Configurations obscures

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

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.

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

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

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.

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é.

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

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

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.]

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.

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.

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.

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.

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.

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.

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).

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

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

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.

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.

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.

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

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

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é.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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)

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

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.

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 >>.

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.

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.

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.

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.

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, puique cette fonctionnalité n'est pas encore implémentée (noyau 2.2.12).

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

Voir la section sur le Filtrage de Chemin Inverse.

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

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 !

Voir la section sur le Filtrage de Chemin Inverse.

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

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

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.

FIXME: à remplir

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).

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

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

Délai avant de tester pour la première fois si le voisin peut être atteint. (voir 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.

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.

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

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.

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

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.

Nombre maximum de requêtes ARP unicast.

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.

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

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.

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.

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

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.

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

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

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

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

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

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

FIXME: à remplir

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

FIXME: à remplir

FIXME: à remplir

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.

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

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.