From 8a94f79f64419b5b21586b5a856ecea0387ffb53 Mon Sep 17 00:00:00 2001 From: gmarcenac Date: Mon, 19 Dec 2005 18:39:39 +0000 Subject: [PATCH] Revision for shorewall 3.0 git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3179 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs2/shorewall_setup_guide_fr.xml | 2049 ++++++++++-------- 1 file changed, 1126 insertions(+), 923 deletions(-) diff --git a/Shorewall-docs2/shorewall_setup_guide_fr.xml b/Shorewall-docs2/shorewall_setup_guide_fr.xml index 339b60c28..9556e285a 100644 --- a/Shorewall-docs2/shorewall_setup_guide_fr.xml +++ b/Shorewall-docs2/shorewall_setup_guide_fr.xml @@ -1,11 +1,11 @@ - + -
+
- Shorewall Setup Guide + Guide de configuration Shorewall @@ -19,9 +19,15 @@ Demassieux + + + Guy + + Marcenac + - 2005-01-22 + 2005-12-18 2001-2005 @@ -29,9 +35,25 @@ Thomas M. Eastep Fabien Demassieux + + Guy Marcenac + Permission est accordée de copier, distribuer et/ou modifier ce + document selon les termes de la Licence de Documentation Libre GNU (GNU + Free Documentation License), version 1.2 ou toute version ultérieure + publiée par la Free Software Foundation ; sans section Invariables, sans + première de Couverture, et sans texte de quatrième de couverture. Une + copie de la présente Licence est incluse dans la section intitulée. Une + traduction française de la licence se trouve dans la section + Licence de + Documentation Libre GNU. Ce paragraphe est une + traduction française pour aider à votre compréhension. Seul le texte + original en anglais présenté ci-dessous fixe les conditions + d'utilisation de cette documentation. + Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with @@ -43,82 +65,77 @@ - Notes du traducteur : J'espère - vous faciliter l'accès et la prise en main d'un firewall performant, - efficace, adaptable et facile d'utilisation. Donc félicitations pour la - qualité du travail et la disponibilité offerte par Thomas M. Eastep. Si - vous trouvez des erreurs ou des améliorations à apporter vous pouvez me - contacter Fabien - Demassieux + Notes du traducteur : Le + traduction initiale a été réalisée par Fabien Demassieux. J'ai assuré la + révision pour l'adapter à la version 3 de Shorewall. Si vous trouvez des + erreurs ou des améliorations à y apporter vous pouvez me contacter Guy Marcenac. + + Cet article s'applique à Shorewall 3.0 et à + ses versions ultérieures. Si vous utilisez une version plus ancienne de + Shorewall, référez-vous à la documentation s'appliquant à votre + version. + +
Introduction - Ce guide est destiné aux utilisateurs qui configurent Shorewall dans - un environnement ou un ensemble d'adresses IP publiques doivent être - prises en compte ou à ceux qui souhaitent en savoir plus à propos de - Shorewall que ce que contient le guide pour une utilisation avec une - adresse ID unique. - Parce que le champ d'utilisation est si important, le guide vous donnera - les indications générales à suivre et vous renseignera sur d'autres - ressources si nécessaire. + Ce guide est destiné aux utilisateurs qui configurent Shorewall dans + un environnement où un ensemble d'adresses IP publiques doit être pris en + compte ainsi qu'à ceux qui souhaitent en savoir plus à propos de Shorewall + que ce que contiennent le guides pour une utilisation avec une adresse IP unique. Le champs + d'application étant très large, ce guide vous donnera des indications + générales à suivre et vous indiquera d'autres ressources si + nécessaire. - Si vous utilisez LEAF Bering, votre configuration Shorewall n'est - PAS ce que je publie -- Je suggère de prendre en considération - l'installation de Shorewall LPR disponible sur le site de shorewall.net - avant de poursuivre. - - -
- Pré-requis - - Shorewall a besoin que le package - iproute/iproute2 soit installé - (avec la distribution RedHat, le package - s'appelle iproute). Vous pouvez vérifier si le - package est installé par la présence du programme ip - sur votre firewall. En tant que root, vous pouvez utiliser la commande - which pour cela: + Shorewall a besoin que le paquetage + iproute/iproute2 + soit installé (avec la distribution RedHat, le + paquetage s'appelle iproute). Vous + pouvez contrôler que le paquetage est installé en vérifiant la présence + du programme ip sur votre + firewall. En tant que root, + vous pouvez utiliser la commande which pour + cela: [root@gateway root]# which ip /sbin/ip [root@gateway root]# -
-
- Avant de commencer + Je vous recommande de commencer par une lecture complète du guide + afin de vous familiariser avec les concepts mis en oeuvre, puis de + recommencer la lecture et seulement alors d'appliquer vos modifications + de configuration. - Je recommande en premier la lecture complète du guide afin de se - familiariser avec les tenants et aboutissants puis de revenir sur les - modifications de votre configuration adapté à votre système. + Les points où des modifications s'imposent sont indiqués par + . + - - Si vous éditez vos fichiers de configuration sur un système - Windows, vous devez les sauver comme des - fichiers Unix si votre éditeur supporte cette - option sinon vous devez les convertir avec dos2unix - avant d'essayer de les utiliser. De la même manière, si vous copiez un - fichier de configuration depuis votre disque dur - Windows vers une disquette, vous devez lancer - dos2unix sur la copie avant de l'utiliser avec - Shorewall. - - Windows - Version of dos2unix - + + Si vous éditez vos fichiers de configuration sur un système + Windows, vous devez les enregistrer comme des + fichiers Unix si votre éditeur supporte cette + option sinon vous devez les convertir avec dos2unix + avant d'essayer de les utiliser. De la même manière, si vous copiez un + fichier de configuration depuis votre disque dur + Windows vers une disquette, vous devez lancer + dos2unix sur la copie avant de l'utiliser avec + Shorewall. - - Linux - Version of dos2unix - - - -
+ + Version + Windows de dos2unix + + Version Linux de + dos2unix + +
@@ -126,142 +143,182 @@ - Les fichiers de configuration de Shorewall se trouvent dans le - répertoire /etc/shorewall -- pour - la plus par des paramétrages, vous avez juste besoin de quelques-uns - d'entre eux comme cela est décrit dans le manuel. Des squelettes de - fichiers sont créés durant la procédure - d'installation de Shorewall. + Les fichiers de configuration pour Shorewall sont situés dans le + répertoire /etc/shorewall -- pour de simples paramétrages, vous n'aurez à + faire qu'avec quelques-uns d'entre eux comme décrit dans ce guide. Des + squelettes de fichiers sont créés durant la + procédure d'installation de Shorewall. - Comme chaque fichier est abordé, je vous suggère de regarder celui - de votre système -- chaque fichier contient des instructions détaillées de - configuration et d'autres des entrées par défaut. + + Note aux utilisateurs de + Debian - Shorewall voit le réseau où il fonctionne, comme un ensemble de - zones. Dans la configuration par défaut, les noms des zones suivantes sont - utilisés: + Si vous vous servez du .deb pour installer, vous vous rendrez + compte que votre répertoire /etc/shorewall est vide. Ceci est voulu. + Les squelettes des fichiers de configuration se trouvent sur votre + système dans le répertoire /usr/share/doc/shorewall/default-config. + Copiez simplement les fichiers dont vous avez besoin depuis ce + répertoire dans /etc/shorewall, + puis modifiez ces copies. - - Zones + Remarquez que vous devez copier + /usr/share/doc/shorewall/default-config/shorewall.conf et + /usr/share/doc/shorewall/default-config/modules + dans /etc/shorewall même si + vous ne modifiez pas ces fichiers. + - - - - Name + Au fur et à mesure de la présentation de chaque fichier, je vous + suggère de jeter un oeil à ceux physiquement présents sur votre système -- + chacun des fichiers contient des instructions de configuration détaillées + et des entrées par défaut. - Description - + Shorewall voit le réseau où il fonctionne, comme étant composé d'un + ensemble de zones. Dans ce guide nous utiliserons les zones + suivantes: - - net + + + fw - L'internet - + + Le firewall lui-même. + + - - loc + + net - Votre Réseau local - + + L'internet public. + + - - dmz + + loc - Zone Démilitarisée - - - -
+ + Un réseau local privé utilisant des adresses IP + privées. + + - Les Zones sont définies dans le fichier + dmz + + + Une zone démilitarisée (DMZ) contenant les + serveurs publiquement accessibles. + + + + + Les Zones sont définies dans le fichier /etc/shorewall/zones. - Shorewall reconnaît aussi le système firewall comme sa propre zone - - par défaut, le firewall lui-même est connu sous le nom fw, mais cela peut être modifié dans le fichier - /etc/shorewall/shorewall.conf. - Dans ce guide, le nom par défaut (fw) - sera utilisé. + + Le fichier /etc/shorewall/zones fourni avec + la distribution est vide. Vous pouvez créer l'ensemble de zones standard + décrites au-dessus en copiant puis en collant ce qui suit dans le + fichier: - Mise à par fw, Shorewall n'attache - aucune importance au nom des zones. Les Zones sont entièrement ce que VOUS - en faites. Cela veut dire que vous ne devez pas vous attendre à ce que - Shorewall fasse quelque chose de spécial car il s'agit de la zone - Internet ou car c'est la zone DMZ. + #ZONE TYPE OPTIONS +fw firewall +net ipv4 +loc ipv4 +dmz ipv4 + + + Remarquez que Shorewall reconnaît aussi le système firewall comme sa + propre zone - l'exemple ci-dessus suit la convention qui veut que la zone + firewall soit nommée fw. Le nom de la + zone firewall (fw dans l'exemple plus + haut) est stocké dans la variable d'environnement $FW + lorsque le fichier /etc/shorewall/zones est traité. A + l'exception du nom attribué à la zone firewall, Shorewall n'attache aucune + signification aux noms de zone. Le zones sont entièrement ce que VOUS en + faites. Ceci signifie que vous ne devriez pas attendre de Shorewall qu'il + fasse quoi que ce soit de spécial car il s'agit de la zone + internet ou car ceci est la + DMZ. - Éditez le fichier /etc/shorewall/zones file et faites tous - changements qui s'imposent. + Éditez le fichier /etc/shorewall/zones et + faites-y les changements nécessaires. - Les Règles qui concernent le trafic à autoriser ou à refuser sous - exprimés en terme de Zones. + Les règles qui concernent le trafic à autoriser ou à refuser sous + exprimées en termes de Zones. - Vous désignez les politiques par défaut entre une zone et une - autre dans le fichier Vous exprimez les politiques par défaut entre une zone et une + autre zone dans le fichier /etc/shorewall/policy. - Vous définissez les exceptions à ces politiques par défaut dans + Vous définissez les exceptions à ces politiques par défaut dans le fichier /etc/shorewall/rules. - Shorewall est construit sur les possibilités du noyau (kernel) - Netfilter. Netfilter - implémente une Shorewall est construit sur les mécanismes de Netfilter, service de filtrage du + noyau (kernel). Netfilter fournit une fonction - de tracking qui autorise ce qui est souvent désigné comme une - inspection déclarée de paquets. Les propriétés de déclaration permettent - au firewall d'être définie en terme de connexions plutôt qu'en terme de - paquet. Avec Shorewall, vous: + de suivi de connexion qui permet une analyse d'état des paquets + (stateful inspection). Cette propriété permet aux règles du firewall + d'être définies en termes de connexions plutôt qu'en termes de paquets. + Avec Shorewall, vous: - Identifiez la zone source. + Identifiez la zone source (client). - Identifiez la zone destination. + Identifiez la zone destination (serveur). - Si la politique de la zone client vers la zone destination est - ce que vous souhaitez pour cette paire client/serveur, vous n'avez - besoin de rien de plus. + Si la politique depuis la zone du client vers la zone du serveur + est ce que vous souhaitez pour cette paire client/serveur, vous n'avez + rien de plus à faire. Si la politique n'est pas ce que vous souhaitez, alors vous - devez ajouter une règle. Cette règle est exprimé en terme de zone + devez ajouter une règle. Cette règle est exprimée en termes de zone client et de zone serveur. - Si les connexions d'un certain type sont autorisés de la zone A au - firewall et sont aussi autorisés du firewall à la zone B cela NE VEUT PAS dire que ces connections sont autorisés de la zone - A à la zone B. Cela veut plutôt dire que vous avez un proxy qui - tourne sur le firewall qui accepte les connections de la zone A et qui - ensuite établit ces propres connections du firewall à la zone B. + Autoriser les connexions d'un certain type + depuis la zone A vers le firewall et depuis firewall vers la zone B + NE SIGNIFIE PAS que ces connections sont autorisés + de la zone A à la zone B (autrement dit, les + connexions impliquant la zone firewall ne sont pas transitives). - Pour chaque requête de connexion sur le firewall, la requête est - d'abord évalué à travers le fichier - /etc/shorewall/rules. Si aucune règle dans ce fichier - ne correspond, la connexion interroge ensuite la première politique dans - /etc/shorewall/policy qui correspond à la requête et - l'applique. Si cette politique est REJECT ou DROP, la requête est a - nouveau évaluée à travers les règles du fichier - /etc/shorewall/common.def. + Pour chaque connexion demandant à entrer dans le firewall, la + requête est en premier lieu vérifiée par rapport au fichier + /etc/shorewall/rules. Si aucune règle dans ce fichier + ne correspond à la demande de connexion alors la première politique dans + le fichier /etc/shorewall/policy qui y correspond + sera appliquée. S'il y a une action commune définie pour + cette politique dans /etc/shorewall/actions ou dans + /usr/share/shorewall/actions.std cette action commune + sera exécutée avant que l'action spécifiée dans + /etc/shorewall/rules ne soit appliquée. - Le fichier de défaut /etc/shorewall/policy a - les politiques suivantes: + Avant Shorewall 2.2.0, le fichier + /etc/shorewall/policy avait les politiques + suivantes: #SOURCE ZONE DESTINATION ZONE POLICY LOG LIMIT:BURST # LEVEL @@ -269,158 +326,188 @@ fw net ACCEPT net all DROP info all all REJECT info - La politique précédente: + + Le fichier de politiques distribué actuellement est vide. Vous + pouvez y copier et coller les entrées présentées ci-dessus comme point + de départ, puis l'adapter à vos propres politiques. + + + Les politiques précédentes vont: - Permet toutes les connexions de votre réseau local vers - Internet + Autoriser (ACCEPT) toutes les connexions de votre réseau local + vers internet - Drop (ignore) toutes les connexions d'Internet vers le firewall - ou votre réseau local et génère un message au niveau info (ici se - trouve la description des niveaux de log). + Ignorer (DROP) toutes les tentatives de connexions d'internet + vers le firewall ou vers votre réseau local et enregistrer dans vos + journaux (log) un message au niveau info (vous trouverez ici la description des + niveaux de journalisation). - Reject (rejette) toutes les autres connexions et génère un - message au niveau info. Quant la requête est rejeté, le firewall - retourne un RST (si le protocole est TCP) ou un ICMP port-unreachable - paquet pour les autres protocoles. + Rejeter (REJECT) toutes les autres demandes de connexion et + générer un message de niveau info dans votre journal. Quant la requête + est rejetée et que le protocole est TCP, le firewall retourne un + paquet RST. Pour tous les autres protocoles, quand une requête est + rejetée, le firewall renvoie un paquet ICMP port-unreachable. - Maintenant, éditez votre /etc/shorewall/policy - et apportez tous les changements que vous souhaitez. + Maintenant, éditez votre /etc/shorewall/policy + et apportez-y tous les changements que vous souhaitez.
- Interfaces Réseau + Interfaces Réseau - Pour le reste de ce guide, nous utiliserons le schéma ci-dessous. - Bien qu'il ne puisse correspondre à votre propre réseau, il peut être - utilisé pour illustrer les aspects importants de la configuration de + Dans la suite du guide, nous nous référerons au schéma ci-dessous. + Bien qu'il puisse ne pas correspondre à votre propre réseau, il peut être + utilisé pour illustrer les aspects importants de la configuration de Shorewall. - Sur ce schéma: + Sur ce schéma: - La zone DMZ est composée des systèmes DMZ 1 et DMZ 2. Une DMZ - est utilisée pour isoler vos serveurs accessibles depuis Internet de - vos systèmes locaux. Ainsi si un de ces serveurs est compromis, vous - avez encore votre firewall entre le système compromis et vos systèmes + La zone DMZ est composée des systèmes DMZ 1 + et DMZ 2. On utilise une DMZ pour isoler ses + serveurs accessibles depuis internet de ses systèmes locaux. Ainsi si + un des serveurs de la DMZ est compromis, vous avez + encore un firewall entre le système compromis et vos systèmes locaux. - La zone Local est composée des systèmes Local 1, Local 2 et - Local 3. + La zone local est composée des systèmes Local 1, + Local 2 et Local 3. - Tous les systèmes du FAI vers l'extérieur et qui englobe la Zone - Internet. + Tous les systèmes à l'extérieur du firewall, y compris ceux de + votre FAI, sont dans la zone internet. - La façon la plus simple pour définir les zones est d'associer le nom - de la zone (définie précédemment dans /etc/shorewall/zones) avec une - interface réseau. C'est fait dans le fichier /etc/shorewall/interfaces. Le - firewall illustré ci-dessus à trois interfaces. Si la connexion se fait à - travers un câble ou un DSL Modem, l'Interface - Externe sera l'adaptateur qui est branché au - Modem (e.g., eth0) - tant que vous ne vous n'utilisez pas le Point-to-Point Protocol over - Ethernet (PPPoE) ou le Point-to-Point Tunneling Protocol(PPTP) dans ce cas - l'Interface Externe sera de type ppp (e.g., ppp0). Si vous utilisez un modem classique, - votre Interface externe sera également ppp0. Si vous utilisez ISDN, votre Interface - Externe sera ippp0. + La façon la plus simple pour définir les zones est d'associer le nom + de la zone (définie précédemment dans + /etc/shorewall/zones) à une interface réseau. Ceci + est fait dans le fichier /etc/shorewall/interfaces. + + Le firewall illustré ci-dessus à trois interfaces réseau. Lorsque la + connexion internet passe par un modem câble + ou ADSL + l'Interface + Externe sera l'adaptateur éthernet qui est connecté + à ce Modem (par exemple eth0). Par contre, si vous vous connectez + avec PPPoE (Point-to-Point Protocol over Ethernet) ou + avec PPTP (Point-to-Point Tunneling + Protocol), l'interface externe sera une interface ppp (par exemple + ppp0). Si vous vous connectez + avec un simple modem RTC, votre + interface externe sera aussi ppp0. Si vous vous connectez en + utilisant l'ISDN, votre interface + externe sera ippp0. - Si votre Interface Externe est ppp0 ou ippp0 alors vous pouvez fixer CLAMPMSS=yes - dans /etc/shorewall/shorewall.conf. + Si votre interface vers l'extérieur est + ppp0 ou ippp0 alors vous mettrez CLAMPMSS=yes dans + le fichier + /etc/shorewall/shorewall.conf. - Votre Interface Locale sera un adaptateur - Ethernet (eth0, - eth1 or eth2) - et doit être connecté à un hub ou un switch. Vos ordinateurs locaux - doivent être connectés au même switch (note: Si vous avez une machine - unique, vous pouvez connecter le firewall directement à l'ordinateur en - utilisant un câble croisé). + Votre Interface locale sera un adaptateur + éthernet (eth0, eth1 + or eth2) et sera connectée à un hub + ou à un switch. Vos ordinateurs locaux seront connectés à ce même hub ou + switch (note : si vous n'avez qu'un seul ordinateur en local, vous pouvez + le connecter directement au firewall par un câble croisé). - Votre Interface DMZ sera aussi être un - adaptateur Ethernet (eth0, - eth1 ou eth2) et doit être connecté à un hub ou un - switch. Vos ordinateurs DMZ doivent être connectés au même switch (note: - Si vous avez une machine DMZ unique, vous pouvez connecter le firewall - directement à l'ordinateur en utilisant un câble croisé). + Votre interface DMZ sera + aussi un adaptateur éthernet (eth0, eth1 + or eth2) et sera connecté à un hub + ou un à switch. Vos ordinateurs appartenant à la DMZ seront connectés à ce + même hub ou switch (note : si vous n'avez qu'un seul ordinateur dans la + DMZ, vous pouvez le connecter directement au firewall + par un câble croisé). - - Ne connectez pas l'interface interne et externe sur le même hub ou - switch, sauf pour tester avec une version postérieure à Shorewall 1.4.7. - Quand vous utilisez ces versions récentes, vous pouvez tester ce type de - configuration si vous spécifiez l'option arp_filter - dans le fichier /etc/shorewall/interfaces - pour toutes les interfaces connectées au hub/switch commun. Utiliser une - telle configuration avec un firewall en production est fortement - déconseillé. - + + Ne connectez pas les interfaces interne et + externe sur le même hub ou le même switch, sauf à des fins de + test. Vous pouvez tester en utilisant ce type de + configuration si vous spécifiez l'option arp_filter ou l'option arp_ignore dans le fichier /etc/shorewall/interfaces, et + ce pour toutes les interfaces connectées au hub/switch + commun. Il est très fortement déconseillé + d'utiliser une telle configuration avec un firewall en + production. + - Pour le besoin de ce Guide, nous décidons que: + Dans la suite, nous supposerons que: - L'interface externe est eth0. + L'interface externe est eth0. - L'interface locale est eth1. + L'interface locale est eth1. - L'interface DMZ est eth2. + L'interface DMZ est eth2. - La configuration par défaut de Shorewall ne définit pas le contenu - de chaque zone. Pour définir la précédente configuration en utilisant le + La configuration par défaut de Shorewall ne définit le contenu + d'aucune zone. Pour définir la configuration présentée plus haut, le fichier /etc/shorewall/interfaces, ce - fichier doit contenir: + url="Documentation.htm#Interfaces">/etc/shorewall/interfaces doit + contenir: #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect rfc1918 loc eth1 detect dmz eth2 detect + Remarquez que la zone $FW n'a aucune entrée dans le fichier + /etc/shorewall/interfaces. + - Éditer le fichier /etc/shorewall/interfaces et - définissez les interfaces du réseau sur votre firewall et associez chaque - interface avec une zone. Si vous avez une zone qui est interfacée avec - plus d'une interface, incluez simplement une entrée pour chaque interface - et répéter le nom de zone autant de fois que nécessaire. + Éditez le fichier /etc/shorewall/interfaces. + Définissez les interfaces du réseau de votre firewall et associez chacune + d'entre elles à une zone. Si vous avez une zone qui est connectée par plus + d'une interface, incluez simplement une entrée pour chaque interface et + répétez le nom de zone autant de fois que nécessaire. - Multiple Interfaces associé une Zone + Interfaces Multiples associées une Zone #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect rfc1918 @@ -430,124 +517,134 @@ loc eth2 detect - Vous pouvez définir des zones plus compliquées en utilisant le + Vous pouvez définir des zones plus compliquées en utilisant le fichier /etc/shorewall/hosts mais - dans la plus part des cas, ce n'est pas nécessaire. + dans la plus part des cas, cela ne sera pas nécessaire. Vous trouverez des + exemples dans Shorewall_and_Aliased_Interfaces.html + et Multiple_Zones.html.
- Adressage, Sous-réseaux et Routage + Adressage, Sous-réseaux et Routage - Normalement, votre FAI vous assigne des adresses Publiques. Vous - pouvez configurer l'interface externe du firewall en utilisant l'une de - ces adresses permanentes et vous pouvez décider comment utiliser le reste - de vos adresses. + Normalement, votre FAI vous attribue un ensemble + d'adresses IP publiques. Vous utiliserez une de ces adresses pour + configurer l'interface externe de votre firewall. Vous déciderez ensuite + comment utiliser le reste de vos adresses. Avant d'aborder ce point, il + nous faut rappeler le contexte. - Si vous êtes déjà familier avec l'adressage IP et le routage, vous - pouvez aller à la prochaine section. + Si vous êtes déjà familier de l'adressage IP et du routage, vous + pouvez directement aller à la prochaine section. - La présentation précédente ne fait que d'effleurer la question des - sous réseaux et du routage. Si vous êtes intéressé pour apprendre plus sur - l'adressage IP et le routage, je recommande IP - Fundamentals: What Everyone Needs to Know about Addressing & + La présentation qui suit ne fait que d'effleurer les questions de + l'adressage et du routage. Si vous vous voulez en apprendre plus sur + l'adressage IP et le routage, je vous recommande + IP Fundamentals: What Everyone Needs to Know about Addressing & Routing, Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0 (link). + url="http://www.phptr.com/browse/product.asp?product_id={58D4F6D4-54C5-48BA-8EDD-86EBD7A42AF6}">lien).
Adressage IP - L'adressage IP version 4 (IPv4) est codé sur 32-bit. La notation - w.x.y.z se réfère à une adresse dont le byte d'ordre supérieur est - w, le suivant à pour valeur x, etc. Si - nous prenons l'adresse 192.0.2.14 et l'exprimons en hexadécimal, nous - obtenons: + Les adresses IP version 4 (IPv4) sont codées sur 32 bits. La + notation w.x.y.z fait référence à une adresse dont l'octet de poids fort + a pour valeur w, le suivant a pour valeur + x, etc. Si nous prenons l'adresse 192.0.2.14 et que nous + l'exprimons en hexadécimal, nous obtenons - C0.00.02.0Eou l'exprimons comme - un entier de 32-bit + C0.00.02.0Eet si nous la + regardons comme un entier de 32 bits nous avons C000020E
- Sous-réseaux + Sous-réseaux - Vous entendrez toujours les termes Class A network, - Class B network et Class C network. Au - début de l'existence de l'IP, les réseaux ne comportaient que trois - tailles (il y avait aussi le réseau de Class D mais il était utilisé - différemment): + Vous entendrez encore aujourd'hui les termes de Réseau de + classe A, Réseau de classe B et Réseau de + classe C. Au début de l'existence de l'IP, les réseaux ne + pouvaient avoir que trois tailles (il y avait aussi les réseaux de + classe D mais il étaient utilisés différemment): - Class A - netmask 255.0.0.0, size = 2 ** 24 + Classe A - masque de sous-réseau 255.0.0.0, taille = 2 ** + 24 - Class B - netmask 255.255.0.0, size = 2 ** 16 + Classe B - masque de sous-réseau 255.255.0.0, taille = 2 ** + 16 - Class C - netmask 255.255.255.0, size = 256 + Classe C - masque de sous-réseau 255.255.255.0, taille = + 256 - La taille d'un réseau était uniquement déterminée par la valeur du - byte de l'ordre supérieur, ainsi vous pouviez regarder une adresse IP et - déterminer immédiatement le masque réseau. Le masque réseau est un - nombre qui se termine logiquement avec une adresse qui isole le - numéro de réseau; le reste de l'adresse est le - numéro d'hôte. Par exemple, dans la Classe C - l'adresse 192.0.2.14, le numéro hexadécimal du réseau est C00002 et le - numéro hexadécimal d'hôte est 0E. + La classe d'un réseau était déterminée de façon unique par la + valeur de l'octet de poids fort de son adresse, ainsi en regardant une + adresse IP on pouvait déterminer immédiatement la valeur du masque + réseau. Le masque réseau est un nombre qui combiné à une adresse par un + ET logique, isole l'adresse du réseau auquel cette adresse appartient. + Le reste de l'adresse est le numéro d'hôte. Par + exemple, dans l'adresse de classe C 192.0.2.14, la valeur hexadécimale + de l'adresse du réseau est C00002 et le numéro d'hôte est 0E. - Comme l'Internet se développait, il semblait clair que la - classification en adressage 32-bit allait devenir très limité - (rapidement, les grandes sociétés et les universités s'étaient assigné - leur propre réseau de classe A!). Après quelques faux départs, la - technique courante du sous-adressage de ces réseaux en plus petits - sous-réseaux évolua; cette technique est consignée par le - Classless InterDomain Routing (CIDR). Aujourd'hui, - tous les systèmes avec lesquels vous travaillerez comprennent - probablement la notation CIDR. Le réseau basé sur les Classes est du - domaine du passé. + Comme internet se développait, il devint clair qu'un + partitionnement aussi grossier de l'espace d'adresses de 32 bits allait + être très limitatif (rapidement, les grandes sociétés et les universités + s'étaient déjà attribuées leur propre réseau de classe A !). Après + quelques faux départs, la technique courante du sous-adressage de ces + réseaux en plus petits sous-réseaux évolua. On fait référence à cette + technique sous l'appellation de Routage Inter-Domaine Sans Classe ou + Classless InterDomain Routing + (CIDR). Aujourd'hui, les systèmes avec lesquels vous + travaillez sont probablement compatibles avec la notation CIDR. La + gestion des réseaux basée sur les Classes est du domaine du + passé. - Un sous-reseau (aussi appelé - subnet ou subnetwork) est un - ensemble d'adresses IP tel que: + Un sous-réseau (subnet + ou subnetwork) est un ensemble contigu d'adresses + IP tel que: - Le nombre d'adresses dans le jeu est un multiple de 2; - et + Le nombre d'adresses dans le jeu est un multiple de 2. - La première adresse dans le jeu est un multiple de la taille + La première adresse dans le jeu est un multiple de la taille du jeu. - La première adresse du sous-réseau est réservée et se réfère à - l'adresse du sous-réseau. + La première adresse du sous-réseau est réservée et on s'y + réfère comme étant l'adresse du + sous-réseau. - La dernière adresse du sous-réseau est réservée comme - adresse broadcast du sous-réseau. + La dernière adresse du sous-réseau est réservée comme + adresse de diffusion (broadcast) du + sous-réseau. - Comme vous pouvez le constater par cette définition, dans chaque - sous-réseau de taille n il y a (n - 2) adresses utilisables (adresses - qui peuvent être assignés à une hôte). La première et la dernière - adresse du sous-réseau sont utilisées respectivement pour identifier - l'adresse sous-réseau et l'adresse broadcast du sous-réseau. En - conséquence, de petits sous-réseaux sont plus gourmands en adresses IP - que de plus étendus. + Comme vous pouvez le constater par cette définition, dans chaque + sous-réseau de taille n il y a (n - 2) adresses utilisables (adresses + qui peuvent être attribuées à un hôte). La première et la dernière + adresse du sous-réseau sont utilisées respectivement pour identifier + l'adresse du sous-réseau et l'adresse de diffusion du sous-réseau. En + conséquence, de petits sous-réseaux sont plus gourmands en adresses IP + que des sous-réseaux plus étendus. - Comme n est une puissance de deux, nous pouvons aisément calculer - le Logarithme Naturel (log2) de n. Pour les plus - communs des sous-réseaux, la taille et leur logarithme naturel sont - donnés par la table suivante: + Comme n est une puissance de deux, nous pouvons aisément calculer + le Logarithme à base 2 de n (log2). La taille et le + logarithme à base 2 pour les tailles de sous-réseau les plus communes + sont donnés par la table suivante: - Logarithme Naturel + Logarithmes base 2 @@ -674,11 +771,12 @@ loc eth2 detect
- Vous pourrez voir que la table ci-dessus contient aussi une - colonne (32 - log2 n). Ce nombre est la - Variable de Longueur du Masque de Sous-réseau (VLSM - Variable Length Subnet Mask) pour un réseau de taille n. De la table - ci-dessus, nous pouvons dériver celle-ci, ce qui est plus facile à + Vous constaterez que la table ci-dessus contient aussi une colonne + (32 - log2 n). Ce nombre est le + Masque de Sous-réseau à Longueur Variable ou + Variable Length Subnet Mask + (VLSM) pour un sous-réseau de taille n. De la table + ci-dessus, nous pouvons déduire la suivante, qui est plus facile à utiliser. @@ -687,11 +785,13 @@ loc eth2 detect - Subnet Size + Taille du + sous-réseau VLSM - Subnet Mask + Masque de + sous-réseau @@ -817,66 +917,67 @@ loc eth2 detect
- Notez que le VLSM est écrit avec un slash (/) -- - vous pouvez souvent entendre un sous-réseau de taille 64 qui fait - référence à un sous-réseau slash 26 et un de taille 8 - faisant référence à un slash 29. + Notez que le VLSM est écrit avec un slash + (/) -- vous entendrez souvent nommer un réseau de taille + 64 comme étant un slash 26 et un de taille 8 comme étant + un slash 29. - Le masque de sous-réseau (aussi référencé par son - netmask) est simplement un nombre de 32-bit avec le - premier bit VLSM à un et les autres à zéro. Par exemple, - pour un sous-réseau de taille 64, le masque de sous-réseau débute par 26 - bits à un: + Le masque de sous-réseau est simplement un nombre de 32 bits avec + les premiers bits correspondant au VLSM positionnés à + 1 et les bits suivants à 0. Par exemple, + pour un sous-réseau de taille 64, le masque de sous-réseau débute par 26 + bits à 1: 11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 = 255.255.255.192Le - masque de sous-réseau a la propriété suivante: si vous terminez - logiquement le masque de sous-réseau avec une adresse dans le - sous-réseau, le résultat est l'adresse du sous-réseau. Attention, si - vous terminez logiquement le masque de sous-réseau avec une adresse en - dehors du sous-réseau, le résultat n'est PAS l'adresse du - sous-réseau. + masque de sous-réseau a la propriété suivante: si vous appliquez un ET + logique entre le masque de sous-réseau et une adresse dans le + sous-réseau, le résultat est l'adresse du sous-réseau. Tout aussi + important, si vous appliquer un ET logique entre le masque de + sous-réseau et une adresse en dehors du sous-réseau, le résultat n'est + PAS l'adresse du sous-réseau. Comme nous le verrons après, cette + propriété du masque de sous-réseau est très importante dans le + routage. - Comme nous l'avons vu précédemment, la propriété du masque de - sous-réseau est très importante dans le routage. - - Pour un sous-réseau dont l'adresse est a.b.c.d et dont la VLSM est /v, nous notons le sous-réseau a.b.c.d/v en utilisant la - notation CIDR. + Pour un sous-réseau dont l'adresse est a.b.c.d et dont le VLSM est + /v, nous notons le sous-réseau + a.b.c.d/v en utilisant + la notation CIDR. - Un exemple de sous-réseau (sub-network) : + Un exemple de sous-réseau : - Subnet: + Sous-réseau: 10.10.10.0 - 10.10.10.127 - Subnet Size: + Taille du + sous-réseau: 128 - Subnet Address: + Adresse du + sous-réseau: 10.10.10.0 - Broadcast - Address: + Adresse de + diffusion: 10.10.10.127 - CIDR Notation: + Notation CIDR: 10.10.10.0/25 @@ -884,8 +985,8 @@ loc eth2 detect
- Il y a deux sous-réseaux dérivés qui doivent être mentionnés; A - savoir, le sous-réseau avec un membre et le sous-réseau avec 2 ** 32 + Il existe deux sous-réseaux dégénérés qui doivent être mentionnés: + le sous-réseau avec un seul membre et le sous-réseau avec 2 ** 32 membres. @@ -894,13 +995,15 @@ loc eth2 detect - Subnet Size + Taille du + sous-réseau - VLSM Length + Longueur VLSM - Subnet Mask + Masque de + sous-réseau - CIDR Notation + Notation CIDR @@ -927,42 +1030,46 @@ loc eth2 detect
Ainsi, chaque adresse a.b.c.d - peut aussi être écrite a.b.c.d/32 et - l'ensemble des adresses possibles est écrit a.b.c.d/32 et + l'ensemble des adresses possibles est écrit 0.0.0.0/0. - Plus loin dans ce manuel, vous verrez la notation a.b.c.d/v utilisé pour décrire la configuration - IP d'une interface réseau (l'utilitaire 'ip' utilise aussi cette - syntaxe). cela veut simplement dire que l'interface est configuré avec - une adresse ip a.b.c.d et avec le - masque de réseau qui correspond à la variable VLSM /Un utilisateur de Shorewall a proposé cette très utile représentation + graphique de ces informations. + + Dans la suite, nous utiliserons la notation a.b.c.d/v pour décrire la configuration IP d'une + interface réseau (l'utilitaire ip utilise aussi cette + syntaxe). Dans cette notation l'interface est configurée avec une + adresse ip a.b.c.d avec le masque de + sous-réseau qui correspond au VLSM /v. 192.0.2.65/29 - L'interface est configuré avec l'adresse IP 192.0.2.65 et le - netmask 255.255.255.248. + L'interface est configurée avec l'adresse IP 192.0.2.65 et le + masque de sous-réseau 255.255.255.248. - Depuis Shorewall 1.4.6, /sbin/shorewall supporte une command - ipcalc qui calcule automatiquement l'information sur le - [sous]réseau. + /sbin/shorewall propose une commande ipcalc qui + calcule automatiquement les informations d'un [sous-]réseau. - En utilisant la commande <command>ipcalc</command>. + Utiliser la commande + <command><command>ipcalc</command></command>. shorewall ipcalc 10.10.10.0/25 CIDR=10.10.10.0/25 NETMASK=255.255.255.128 NETWORK=10.10.10.0 - BROADCAST=10.10.10.127 - + BROADCAST=10.10.10.127 - En utilisant la commande <command>ipcalc</command>. + Utiliser la commande + <command><command>ipcalc</command></command>. shorewall ipcalc 10.10.10.0 255.255.255.128 CIDR=10.10.10.0/25 @@ -975,9 +1082,9 @@ loc eth2 detect
Routage - L'un des buts des sous-réseaux est la base du routage. Ci-dessous - se trouve la table de routage de mon firewall (compressé pour du - PDF): + L'un des objectifs de la gestion en sous-réseaux est qu'elle pose + les bases pour le routage. Ci-dessous se trouve la table de routage de + mon firewall: [root@gateway root]# netstat -nr Kernel IP routing table @@ -994,97 +1101,100 @@ Destination Gateway Genmask Flgs MSS Win irtt Iface 0.0.0.0 206.124.146.254 0.0.0.0 UG 40 0 0 eth0 [root@gateway root]# - Le périphérique texas est le tunnel GRE vers - un site peer à Dallas, la zone Texas. + L'interface texas est un tunnel GRE vers un + site pair à Dallas, au Texas. - Les trois premières routes sont des host - routes puisqu'elles indiquent comment aller vers un hôte - unique. Dans la sortie de netstat cela peut-être vu par - le Genmask (Masque sous-réseau) de 255.255.255.255 et le - H dans la colonne Flags . Les autres sont - des routes net routes car elles - indiquent au noyau comment router des paquets à un sous-réseau. La - dernière route est la route par défaut - correspondant à la passerelle (gateway) mentionnée aussi appelé - passerelle par défaut (default gateway). + Les trois premières routes sont des routes vers des hôtes + (host routes) puisqu'elles indiquent comment aller + vers un hôte unique. Dans la sortie de netstat, cela + se voit très bien au masque de sous-réseau (Genmask) à 255.255.255.255, + ou bien au drapeau à H dans la colonne + Flags . Les autres routes sont des routes réseau car + elles indiquent au noyau comment router des paquets à un sous-réseau. La + dernière route est la route par défaut. La + passerelle mentionnée dans cette route est appelée la + passerelle par défaut (default gateway). - Quant le noyau essaye d'envoyer un paquet à une adresse IP - A, il commence au début de la table de + Quant le noyau essaye d'envoyer un paquet à une adresse IP + A, il commence au début de la table de routage et: - A est logiquement terminé - avec la valeur du Genmask dans l'entrée de la - table. + Il réalise un ET logique entre + A et la valeur du masque de sou-réseau pour + cette entrée de la table. - Le résultat est comparé avec la valeur de la - Destination dans l'entrée de la table. + Ce résultat est comparé avec la valeur de la + Destination dans cette entrée de la table. - Si le résultat et la valeur de la Destination + Si le résultat et la valeur de la Destination sont identiques, alors: Si la colonne Gateway n'est pas nulle, le - paquet est envoyé au gateway à travers l'interface nommée dans - la colonne Iface. + paquet est envoyé à la passerelle par l'interface nommée dans la + colonne Iface. - Sinon, le paquet est directement envoyé à A à travers l'interface nommée dans la + Sinon, le paquet est directement envoyé à A à travers l'interface nommée dans la colonne iface. - Autrement, les étapes précédentes sont répétées sur l'entrée + Sinon, les étapes précédentes sont répétées sur l'entrée suivante de la table. - Puisque la route par défaut correspond à toutes les adresses IP - (A donne 0.0.0.0 = 0.0.0.0), les - paquets qui ne correspondent à aucune des autres entrées de la table de - routage sont envoyés au gateway par défaut qui généralement est un - routeur vers le FAI. + Puisque la route par défaut correspond à toutes les adresses IP + (A ET 0.0.0.0 = 0.0.0.0), les paquets + qui ne correspondent à aucune des autres entrées de la table de routage + sont envoyés à la passerelle par défaut qui est généralement un routeur + de votre FAI. - Voici un exemple. Supposez que vous souhaitez router un paquet à - 192.168.1.5. Cette adresse ne correspond à aucune route d'hôte dans la - table mais si nous terminons logiquement cette adresse avec - 255.255.255.0, le résultat est 192.168.1.0 qui correspond à la l'entrée - dans la table: + Prenons un exemple. Supposons que vous souhaitiez router un paquet + à 192.168.1.5. Cette adresse ne correspond à aucune route d'hôte dans la + table mais lorsque nous faisons le ET logique de cette adresse avec + 255.255.255.0, le résultat est 192.168.1.0 qui correspond à cette entrée + de la table: 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2 - Donc le paquet vers 192.168.1.5 est directement envoyé à travers - eth2. + Donc, pour router ce paquet à 192.168.1.5, il faudra le + transmettre directement à l'interface eth2. - Un des points qui doit être souligné -- tous les paquets sont - envoyés en utilisant la table de routage et les réponses ne sont pas - exclues de ce principe. Il semble y avoir une idée fausse chez ceux qui - croient que les paquets réponses sont comme les saumons et contiennent - un code génétique qui leur permet de suivre la route emprunté par les - paquets envoyés. Ce n'est pas le cas; La réponse peut prendre un chemin - totalement différent de celui de la requête du client -- les routes - requête/réponse sont totalement indépendantes. + Un point important doit être souligné -- tous les paquets sont + envoyés en utilisant la table de routage et les paquets en réponse ne + sont pas un cas particulier. Il semble exister une idée fausse comme + quoi les paquets réponses seraient comme les saumons et contiendraient + une sorte de code génétique qui leur permettrait suivre la même route + empruntée par les paquets de requête (request) à l'aller. Ce n'est pas + le cas. Les réponses peuvent prendre un chemin totalement différent de + celui pris par les paquets de la requête client à l'aller -- Ces routes + sont totalement indépendantes.
- Protocole de Résolution d'Adresse (ARP) + Protocole de Résolution d'Adresse (ARP) - Quant on envoie des paquets à travers Ethernet, les adresses IP ne - sont pas utilisées. Bien que l'adressage Ethernet soit basé sur les - adresses Media Access Control (MAC). Chaque - périphérique Ethernet à sa propre adresse MAC qui est contenu dans une - PROM lors de la fabrication. Vous pouvez obtenir l'adresse MAC grâce à - l'utilitaire ip: + Quant on envoie des paquets sur éthernet, les adresses IP ne sont + pas utilisées. L'adressage éthernet est basé sur les adresses + MAC (Media Access Control). + Chaque carte éthernet à sa propre adresse MAC unique + qui est gravée dans une PROM lors de sa fabrication. + Vous pouvez obtenir l'adresse MAC d'une carte + éthernet grâce à l'utilitaire + ip: [root@gateway root]# ip addr show eth0 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100 @@ -1095,14 +1205,15 @@ inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0 [root@gateway root]# - Comme vous pouvez le constater ci-dessus, l'adresse MAC codé sur 6 - bytes (48 bits). L'adresse MAC est généralement aussi imprimée sur la - carte elle-même. + Comme vous pouvez le constater, l'adresse MAC + est codée sur 6 octets (48 bits). L'adresse MAC est + généralement imprimée sur la carte elle-même. - Comme IP utilise les adresses IP et Ethernet les adresses MAC, un - mécanisme est nécessaire pour transcrire une adresse IP en adresse MAC; - C'est ce dont est chargé le protocole de résolution d'adresse - Address Resolution Protocol (ARP). Voici ARP en + Comme IP utilise les adresses IP et Éthernet les adresses MAC, il + faut un mécanisme pour transcrire une adresse IP en adresse MAC. C'est + ce dont est chargé le protocole de résolution d'adresse + (Address Resolution Protocol + ARP). Voici ARP en action: [root@gateway root]# tcpdump -nei eth2 arp @@ -1116,279 +1227,303 @@ tcpdump: listening on eth2 0 packets dropped by kernel [root@gateway root]# - Dans cet échange , 192.168.1.254 (MAC 2:0:8:e3:4c:48) veut - connaître l'adresse MAC du périphérique avec l'adresse IP 192.168.1.19. - Le système ayant cette adresse IP répond que l'adresse MAC du - périphérique avec l'adresse IP 192.168.1.19 est 0:6:25:aa:8a:f0. + Dans cet échange , 192.168.1.254 (MAC 2:0:8:e3:4c:48) veut + connaître l'adresse MAC du périphérique qui a l'adresse IP 192.168.1.19. + Le système ayant cette adresse IP répond que l'adresse MAC du + périphérique avec l'adresse IP 192.168.1.19 est 0:6:25:aa:8a:f0. - Afin de rendre disponible les informations d'échange ARP chaque - fois qu'un paquet est envoyé, le système maintient un cache - ARP of IP<->MAC correspondances. Vous pouvez voir le - cache ARP sur votre système (également sur les systèmes - Windows) en utilisant la commande - arp: + Afin de ne pas avoir à échanger des information + ARP chaque fois qu'un paquet doit être envoyé, le + système maintient un cache des correspondances IP<-> MAC. Vous + pouvez voir le contenu du cache ARP sur votre système + (y compris sur les systèmes Windows) en utilisant + la commande arp [root@gateway root]# arp -na ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1 ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2 ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2 ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0 -? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2 - +? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2 - Les détails de réponse sont le résultat de l'utilisation de - l'option n (Windows - arp n'accepte pas cette option) qui force le programme - arp à la translation de résolution de noms IP->DNS. Si - je n'utilise pas cette option, le point d'interrogation sera remplacé - par le noms correspondant à chaque adresse IP. Notez que la dernière - information dans la table d'enregistrement est celle que nous voyons en - utilisant précédemment tcpdump. + Les points d'interrogation au début des lignes sont le résultat de + l'utilisation de l'option n qui empêche le programme + arp de résoudre le noms DNS pour + les adresses IP (la commande arp de + Windows n'accepte pas cette option) . Si je n'avais pas + utilisé pas cette option, les points d'interrogation seraient remplacés + par les noms pleinement qualifiés (FQDN) correspondant à chaque adresse + IP. Remarquez que la dernière information dans le cache correspond à + celle que nous avons vue en utilisant tcpdump à + l'instant.
RFC 1918 - Les adresses IP sont allouées par l'autorité Internet Assigned Number Authority - (IANA) qui délégue des allocations géographiques basées sur le Regional - Internet Registries (RIR). Par exemple, les allocations pour les - Etats-Unis sont déléguées à American - Registry for Internet Numbers (ARIN). Ces RIR peuvent déléguer à - des bureaux nationaux. La plus part d'entre nous ne traite pas avec - autorités mais obtienne plutôt leur adresse IP par leur FAI. + Les adresses IP sont allouées par l'IANA + (Internet Assigned Number + Authority) qui délégue les allocations sur une base géographique + aux Registres Internet Régionaux (RIR). Par exemple, + les allocations pour les Etats-Unis et l'Afrique sub-Saharienne sont + déléguées à l'ARIN (American Registry for Internet + Numbers). Ces RIRs peuvent à leur tour déléguer à des bureaux + nationaux. La plupart d'entre nous ne traite pas avec ces autorités mais + obtient plutôt ses adresse IP de son FAI. - Dans la réalité, généralement on ne peut se permettre autant - d'adresses IP Publiques que de périphériques à assigner si bien que nous - utiliseront des adresses IP Privées. RFC 1918 réserve plusieurs plages - d'adresse IP à cet usage: + Dans la réalité, on ne peut en général pas se permettre d'avoir + autant d'adresses IP publiques que l'on a de périphériques en + nécessitant une. C'est cette raison qui nous amène à utiliser des + adresses IP privées. La RFC 1918 réserve plusieurs plages d'adresses à + cette fin : 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 - Les adresses réservées par la RFC 1918 sont parfois appelées - non-routable car le routeur passerelle Internet ne renvoi pas les - paquets qui ont une adresse de destination RFC-1918. Cela est - compréhensible car tout le monde peut choisir ces adresses pour un usage - privé. + Les adresses réservées par la RFC 1918 sont parfois appelées + non-routables car les routeurs d'infrastructure internet ne feront pas + suivre (forward) les paquets qui ont une adresse de destination de la + RFC 1918. Cela est compréhensible puisque chacun peut choisir n'importe + laquelle ces adresses pour son usage privé. Mais le terme de + non-routable est quelque peu malencontreux car il peut amener à conclure + de manière erronée que le trafic destiné à une de ces adresses ne peut + être envoyé à travers un routeur. Ceci est faux et les routeurs privés, + dont votre firewall Shorewall, peuvent parfaitement faire suivre du + trafic avec des adresses conformes à la RFC 1918. - Quant on choisit des adresses de ces plages, il y a deux choses à - garder en mémoire: + Quant on choisit des adresses dans ces plages, il faut bien avoir + à l'esprit les choses suivantes: - Comme l'espace des adresses IPv4 s'épuise, de plus en plus - d'organisation (comprenant les FAI) commencent à utiliser les - adresses RFC 1918 dans leur infrastructures. + Comme l'espace des adresses IPv4 s'épuise, de plus en plus + d'organisation (y compris les FAI) commencent à utiliser les + adresses RFC 1918 dans leurs infrastructures. - Vous ne voulez pas utiliser des adresses IP qui sont utilisés - par votre FAI ou une autre organisation avec laquelle vous souhaiter - établir une liaison VPN + Vous ne devez pas utiliser d'adresse IP qui soit utilisée par + votre FAI ou une autre organisation avec laquelle + vous souhaitez établir une liaison VPN - C'est pourquoi c'est une bonne idée de vérifier avec votre FAI - s'il n'utilise pas (ou ne prévoie pas d'utiliser) des adresses privées - avant de décider les adresses que vous allez utiliser. + C'est pourquoi c'est une bonne idée de vérifier après de votre FAI + s'il n'utilise pas (ou ne prévoie pas d'utiliser) des adresses privées + avant de décider quelles adresses que vous allez utiliser. Dans ce document, les adresses IP externes - réels du type 192.0.2.x. 192.0.2.0/24 sont réservées - par RFC 3330 pour l'utilisation d'adresses IP publiques. Ces adresses - ne doivent pas être confondues avec les adresses 192.168.0.0/16; comme - décrit ci-dessus, celles-ci sont réservées par RFC 1918 pour une - utilisation privée. + réelles sont dans la plage 192.0.2.x. Les adresses du + réseau 192.0.2.0/24 sont réservées par RFC 3330 pour l'utilisation + d'adresses IP publiques dans les exemples imprimés ainsi que dans les + réseaux de test. Ces adresses ne doivent pas être confondues avec les + adresses 192.168.0.0/16, qui comme décrit ci-dessus, sont réservées + par la RFC 1918 pour une utilisation privée.
- Configurer votre Réseau + Configurer votre Réseau - Le choix de configuration de votre réseau dépend d'abord du nombre - d'adresses Public IP dont vous avez besoin, c'est à dire du nombre - d'entités adressables que vous avez sur votre réseau. En fonction du - nombre d'adresses que vous avez, votre FAI peut servir ce jeu d'adresses - de deux manières: + Le choix d'une configuration pour votre réseau dépend d'abord du + nombre d'adresses IP publiques dont vous disposez et du nombre d'adresses + IP dont vous avez besoin. Quel que soit le nombre d'adresses dont vous + disposez, votre FAI peut vous servir ce jeu d'adresses + de deux manières: - Routed - Le trafic vers chacune - de vos adresses sera routé à travers une unique adresse passerelle. - Cela sera généralement fait si votre FAI vous assigne un sous-réseau - complet (/29 ou plus). Dans ce cas, vous assignerez l'adresse - passerelle comme adresse IP de l'interface externe de votre - firewall/router. + Routées - Le trafic vers + chacune de vos adresses publiques sera routé à travers une seule + adresse de passerelle. Cela sera généralement fait si votre FAI vous + attribue un sous-réseau complet (/29 ou plus). Dans ce cas, vous + affecterez l'adresse de cette passerelle comme étant l'adresse de + l'interface externe de votre firewall/routeur. - Non-routed - Votre FAI vous - donnera directement le trafic de chaque adresse directement. + Non routées - Votre FAI enverra + le trafic à chacune de vos adresses directement. - Dans les paragraphes qui suivent, nous étudierons chaque cas - séparément. + Dans les paragraphes qui suivent, nous étudierons chacun de ces cas + séparément. - Avant de commencer, il y a une chose que vous devez vérifier: + Avant de commencer, il y a une chose que vous devez vérifier: - Si vous utilisez le package Debian, vérifier svp votre fichier - shorewall.conf afin de contrôler les paramètres suivants; si ce n'est pas - juste, appliquer les changements nécessaires: + Si vous utilisez un paquetage Debian, vérifiez votre fichier + shorewall.conf afin de vous assurer que les + paramètres suivants sont convenablement fixés. Si ce n'est pas le cas, + appliquez les changements nécessaires: - - NAT_ENABLED=Yes (Shorewall versions antérieures à 1.4.6) - - IP_FORWARDING=On
- Routage + Routé - Supposons que votre fournisseur d'accès FAI vous a assigné le - sous-réseau 192.0.2.64/28 routé à travers 192.0.2.65. Cela veut dire que - vous avez les adresses IP 192.0.2.64 - 192.0.2.79 et que l'adresse - externe de votre firewall est 192.0.2.65. Votre FAI vous a aussi dit que - vous pouvez utiliser le masque de réseau 255.255.255.0 (ainsi votre /28 - est une partie de /24). Avec ces adresses IP, vous pouvez scinder votre - réseau /28 en deux /29 et configurer votre réseau comme l'indique le - diagramme suivant. + Supposons que votre fournisseur d'accès vous ait assigné le + sous-réseau 192.0.2.64/28 routé par 192.0.2.65. Vous avez les adresses + IP 192.0.2.64 - 192.0.2.79 et l'adresse externe de votre firewall est + 192.0.2.65. Votre FAI vous a aussi dit que vous devez utiliser le masque + de sous-réseau 255.255.255.0 (ainsi, votre /28 est un sous-ensemble du + /24, plus grand). Avec autant d'adresses IP, vous pouvez scinder votre + réseau /28 en deux sous-réseaux /29 et configurer votre réseau comme + l'indique le diagramme suivant. - Ici, la zone démilitarisé DMZ comprend le sous-réseau - 192.0.2.64/29 et le réseau Local 192.0.2.72/29. La passerelle par défaut - pour les hôtes dans la DMZ pourra être configuré à 192.0.2.66 et la - passerelle par défaut pour les hôtes du réseau local pourra être + Dans l'exemple, la zone démilitarisé DMZ est + dans le sous-réseau 192.0.2.64/29 et le réseau local est dans + 192.0.2.72/29. La passerelle par défaut pour les hôtes dans la + DMZ doit être configurée à 192.0.2.66 et la + passerelle par défaut pour ceux du réseau local doit être configurée à 192.0.2.73. - Notez que cet arrangement est plus gourmand en adresses publiques - puisqu'il utilise 192.0.2.64 et 192.0.2.72 pour les adresses du - sous-réseau, 192.0.2.71 et 192.0.2.79 pour les adresses broadcast du - réseau, de même que 192.0.2.66 et 168.0.2.73 pour les adresses internes - que le firewall/routeur. Néanmoins, cela montre comment nous pouvons - faire avec un réseau /24 plutôt qu'un /28, l'utilisation de 6 adresses - IP parmi les 256 peut être justifié par la simplicité du - paramétrage. + Notez que cette solution est plutôt gourmande en adresses + publiques puisqu'elle utilise 192.0.2.64 et 192.0.2.72 pour les adresses + de sous-réseau, 192.0.2.71 et 192.0.2.79 pour les adresses de diffusion + (broadcast) du réseau, et 192.0.2.66 et 168.0.2.73 pour les adresses + internes sur le firewall/routeur. Elle montre néammoins comment la + gestion en sous-réseaux peut fonctionner. Et si nous avions un réseau + /24 plutôt qu'un /28, l'utilisation de 6 adresses IP parmi les 256 + disponibles serait largement justifiée par la simplicité du + paramétrage. - Le lecteur astucieux aura remarqué que l'interface externe du - firewall/Routeur est actuellement incluse dans le sous-réseau DMZ - (192.0.2.64/29). Que se passe-t-il si DMZ 1 (192.0.2.67) essaye de - communiquer avec 192.0.2.65? La table de routage sur DMZ 1 peut - ressembler à cela: + Le lecteur attentif aura peut-être remarqué que l'interface + externe du firewall/Routeur est en fait incluse dans le sous-réseau + DMZ (192.0.2.64/29). On peut se demander ce qui se + passe quand l'hôte DMZ 1 (192.0.2.67) essaye de communiquer avec + 192.0.2.65. La table de routage sur l'hôte DMZ 1 doit ressembler à + cela: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.0.2.64 0.0.0.0 255.255.255.248 U 40 0 0 eth0 0.0.0.0 192.0.2.66 0.0.0.0 UG 40 0 0 eth0 - Cela indique que DMZ 1 enverra une requête ARP "qui a 192.0.2.65" - et aucune interface sur le segment Ethernet DMZ à cette adresse IP. - Assez bizarrement, le firewall répondra à la requête avec l'adresse MAC - de sa propre DMZ Interface!! DMZ 1 - peut alors envoyer des trames Ethernet adressées à cette adresse MAC et - les trames seront reçues (correctement) par le firewall/routeur. + Donc, lorsque l'hôte DMZ 1 voudra communiquer avec 192.0.2.65, il + enverra une requête ARP "qui-a 192.0.2.65" alors + qu'aucune interface sur le segment éthernet DMZ n'a cette adresse IP. + Assez bizarrement, le firewall répondra à la requête avec + l'adresse MAC de sa propre interface + DMZ ! DMZ 1 peut alors envoyer des + trames éthernet adressées à cette adresse MAC et les + trames seront reçues correctement par le firewall/routeur. - C'est plutôt une possibilité inattendue d'ARP sur la partie du - Noyau Linux qui pousse cet avertissement très tôt dans ce manuel à - propos de la connexion de plusieurs interfaces firewall/routeur au même - hub ou switch. Quant une requête ARP destinée à une des adresses - firewall/routeur est envoyée par un autre système connecté au - hub/switch, toutes les interfaces du firewall qui se connectent au - hub/switch peuvent répondre! C'est alors une course à la réponse qui - "est-là" qui atteindra en premier l'émetteur. + L'avertissement fait plus haut qui déconseille très fortement la + connexion de plusieurs interfaces du firewall/routeur à un même hub ou + switch est une conséquence directe de ce comportement plutôt inattendu + d'ARP de la part du noyau Linux. Quant une requête + ARP destinée à une des adresses du firewall/routeur est envoyée par un + autre système connecté au même hub ou switch, toutes les interfaces du + firewall qui y sont connectées peuvent répondre ! C'est alors la course + à savoir quelle réponse c'est-ici atteindra la première + l'émetteur de la requête.
- Non-routé + Non routé - Avec la situation précédente mais non-routé, vous pouvez - configurer votre réseau exactement comme décrit ci-dessus avec une - condition supplémentaire; spécifiez simplement l'option - proxyarp sur les trois interfaces du firewall dans le - fichier /etc/shorewall/interfaces file. + Si vous êtes dans la situation précédente mais que votre trafic + n'est pas routé par votre FAI, vous pouvez configurer + votre réseau exactement comme décrit plus haut, au prix d'une légère + contorsion supplémentaire: spécifiez simplement l'option + proxyarp sur les trois interfaces du + firewall dans le fichier + /etc/shorewall/interfaces. - La plus part d'entre nous n'ont pas le luxe d'avoir assez - d'adresses publiques IP pour configurer notre réseau comme montré dans - le précédent exemple (même si la configuration est routée). + La plupart d'entre nous n'ont pas le luxe d'avoir suffisamment + d'adresses publiques IP pour configurer leur réseau comme indiqué dans + l'exemple précédent (même si la configuration est routée). - Pour le besoin de cette section, admettons - que notre FAI nous a assigné les adresses IP 192.0.2.176-180 et nous a - dit d'utiliser le masque de réseau 255.255.255.0 et la passerelle par - défaut 192.0.2.254. + Dans le reste de cette section, supposons + que notre FAI nous ait assigné la plage d'adresses IP 192.0.2.176-180, + qu'il nous ait dit d'utiliser le masque de sous-réseau 255.255.255.0 et + que la passerelle par défaut soit 192.0.2.254. - Clairement, ce jeu d'adresses ne comprend pas de sous-réseau et - n'a pas suffisamment d'adresses pour toutes les interfaces de notre - réseau. Il y a quatre possibilités qui peuvent être utilisées pour - régler ce problème. + De toute évidence, ce jeu d'adresses ne comprend pas de + sous-réseau et n'a pas suffisamment d'adresses pour toutes les + interfaces de notre réseau. Nous pouvons utiliser quatre techniques + différentes pour contourner ce problème. - Source Network Address Translation - (SNAT). + La traduction d'adresses source (Source Network + Address Translation SNAT). - Destination Network Address Translation - (DNAT) aussi nommé Port Forwarding. + La traduction d'adresses destination (Destination + Network Address Translation DNAT) nommée aussi transfert ou suivi de port + (Port Forwarding). - Proxy ARP. + Le Proxy + ARP. - Network Address Translation (NAT) aussi - appelé One-to-one NAT. + La traduction d'adresses réseau (Network Address + Translation NAT) à laquelle on fait + aussi référence sous l'appellation de un-à-un NAT (one-to-one + NAT). - Souvent une combinaison de ces techniques est utilisée. Chacune - d'entre elle sera détaillée dans la section suivante. + Souvent, une combinaison de ces techniques est utilisée. Chacune + d'entre elles sera détaillée dans la section suivante.
SNAT - Avec SNAT, un segment interne LAN est configuré en utilisant les - adresses RFC 1918. Quant un hôte A - sur ce segment interne initialise une connexion vers un hôte B sur Internet, le firewall/routeur réécrit les - entêtes IP dans la requête pour utiliser une de vos adresses publiques - IP en tant qu'adresse source. Quant B - répond et que la réponse est reçu par le firewall, le firewall change - l'adresse destination par celle RFC 1918 de A et renvoi la réponse à Avec la SNAT, un segment interne du réseau + local est configuré en utilisant des adresses de la RFC 1918. Quant un + hôte A sur ce segment interne initie + une connexion vers un hôte B sur + internet, le firewall/routeur réécrit les entêtes IP de la requête + pour utiliser une de vos adresses publiques IP en tant qu'adresse + source. Quant B répond et que la + réponse est reçue par le firewall, le firewall change l'adresse + destination par celle de la RFC 1918 de A et transfère la réponse à A. - Supposons que vous décidiez d'utiliser SNAT sur votre zone - locale et utilisiez l'adresse publique 192.0.2.176 à la fois comme - adresse externe du firewall et l'adresse source des requêtes Internet - envoyées depuis cette zone. + Supposons que vous décidiez d'utiliser la SNAT sur votre zone + locale. Supposons également que vous utilisiez l'adresse publique + 192.0.2.176 à la fois comme adresse externe du firewall et comme + adresse source des requêtes internet envoyées depuis cette + zone. - La zone locale a été assigné au sous-réseau 192.168.201.0/29 - (netmask 255.255.255.248). + On a assigné à la zone locale le sous-réseau 192.168.201.0/29 + (masque de sous-réseau 255.255.255.248). - Le système dans la zone locale pourra être configuré avec la - passerelle par défaut 192.168.201.1 (L'adresse IP de l'interface - local du firewall). + Dans ce cas, les systèmes de la zone locale seraient + configurés avec 192.168.201.1 comme passerelle par défaut (adresse + IP de l'interface local du firewall). - SNAT est configuré dans Shorewall avec le fichier + La SNAT est configurée dans Shorewall avec le fichier /etc/shorewall/masq. @@ -1396,28 +1531,30 @@ Destination Gateway Genmask Flags MSS Window irtt Iface #INTERFACE SUBNET ADDRESS eth0 192.168.201.0/29 192.0.2.176 - Cet exemple utilise la technique normale pour assigner la même - adresse publique IP pour l'interface externe du firewall et pour SNAT. - Si vous souhaitez utiliser une adresse IP différente, vous pouvez soit - utiliser les outils de configuration réseau de votre distribution pour - ajouter cette adresse IP ou vous pouvez mettre la variable - ADD_SNAT_ALIASES=Yes dans /etc/shorewall/shorewall.conf si bien que - Shorewall ajoutera l'adresse pour vous. + Cet exemple utilise la technique normale qui assigne la même + adresse publique IP pour l'interface externe du firewall et pour la + SNAT. Si vous souhaitez utiliser une adresse IP différente, vous + pouvez soit utiliser les outils de configuration réseau de votre + distribution Linux pour ajouter cette adresse IP, soit mettre la + variable ADD_SNAT_ALIASES=Yes dans + /etc/shorewall/shorewall.conf et Shorewall + ajoutera l'adresse pour vous.
DNAT - Quant SNAT est utilisé, il est impossible pour les hôtes sur - Internet d'initialiser une connexion avec un des systèmes puisque ces - systèmes n'ont pas d'adresses publiques IP. DNAT fournit une méthode - pour autoriser des connexions sélectionnés depuis Internet. + Quand la SNAT est utilisée, il est impossible pour les hôtes sur + internet d'initialiser une connexion avec un des systèmes internes + puisque ces systèmes n'ont pas d'adresses publiques IP. La DNAT + fournit une méthode pour autoriser des connexions sélectionnées depuis + internet. - Supposons que votre fille souhaite héberger un serveur Web sur - son système "Local 3". Vous pouvez autoriser les connexions d'Internet - à son serveur en ajoutant l'entrée suivante dans le fichier + Supposons que votre fille souhaite héberger un serveur Web sur + son système "Local 3". Vous pourriez autoriser les connexions + d'internet à son serveur en ajoutant l'entrée suivante dans le fichier /etc/shorewall/rules: @@ -1426,293 +1563,353 @@ eth0 192.168.201.0/29 192.0.2.176 DNAT net loc:192.168.201.4 tcp www Si une des amies de votre fille avec une adresse A veut accéder au serveur de votre fille, elle - peut se connecter à l'adresse http://192.0.2.176 (l'adresse IP externe - de votre firewall) et le firewall réécrira l'adresse IP à - 192.168.201.4 (le système de votre fille) et enverra la requête. Quant - le serveur de votre fille répond, le firewall réécrira la source de - réponse avec 192.0.2.176 et retournera la réponse à A. + role="bold">A veut accéder au serveur de votre fille, elle + peut se connecter à http://192.0.2.176 (l'adresse IP externe de votre + firewall). Le firewall réécrira l'adresse IP de destination à + 192.168.201.4 (le système de votre fille) et lui fera suivre la + requête. Quand le serveur de votre fille répondra, le firewall + remettra l'adresse source à 192.0.2.176 et retournera la réponse à + A. - Cet exemple l'adresse externe IP du firewall pour DNAT. Vous - pouvez utiliser une autre de vos adresses IP publiques, mais Shorewall - n'ajoutera pas pour vous cette adresse à l'interface externe du - firewall. + Cet exemple utilise l'adresse externe IP du firewall pour la + DNAT. Vous pouvez utiliser une autre de vos + adresses IP publiques. Pour cela, mettez-la dans la colonne ORIGINAL + DEST de la règle ci-dessus. Par contre, Shorewall n'ajoutera pas à + votre place cette adresse à l'interface externe du firewall. + + + Quand vous testez des règles DNAT comme + celles présentée plus haut, vous devez le faire depuis un client A + L'EXTÉRIEUR DE VOTRE FIREWALL (depuis la zone net). + Vous ne pouvez pas tester ces règles de l'intérieur ! + + Pour quelques astuces sur la résolution de problèmes avec la + DNAT, voyez les FAQ 1a et + 1b. +
Proxy ARP - Le principe du proxy ARP est: + Le principe du proxy ARP est: - Un hôte H derrière votre - firewall est assigné à une de vos adresses publiques (A), a le même masque de réseau (M) que l'interface externe du - firewall. + On attribue à un hôte H + derrière notre firewall une de nos adresses publiques A et on lui donne le même masque de + sous-réseau M que celui de + l'interface externe du firewall. - Le firewall répond à ARP "qui a" demandé A. + Le firewall répond aux requêtes ARP + qui-a-l'adresse A émises par les hôtes + à l'extérieur du firewall. - Quant H délivre une requête - ARP "qui a" pour une adresse du sous-réseau définit par A et M, le - firewall répondra (avec l'adresse MAC si le firewall s'interface à - H). + Lorsque c'est l'hôte H qui + émet une requête qui-a-l'adresse + pour un hôte + situé à l'extérieur du firewall et + appartenant au sous-réseau défini par A et M, + c'est le firewall qui répondra à H avec l'adresse MAC de l'interface du + firewall à laquelle est raccordé H. - Supposons que nous décidons d'utiliser Proxy ARP sur DMZ de - notre exemple réseau. + Pour une description plus complète du fonctionnement du Proxy + ARP, vous pouvez vous référer à la Documentation du Proxy Shorewall. + + Supposons que nous décidions d'utiliser le Proxy ARP sur la DMZ + de notre exemple de réseau. - Ici, nous avons assigné les adresses IP 192.0.2.177 au système - DMZ 1 et 192.0.2.178 à DMZ 2. Notez que nous avons juste assigné une - adresse arbitraire RFC 1918 et un masque de sous-réseau à l'interface - DMZ de notre firewall. Cette adresse et le masque ne sont pas - pertinentes - vérifiez juste que celle-ci n'écrase pas un autre - sous-réseau déjà défini. + Ici, nous avons assigné les adresses IP 192.0.2.177 au système + DMZ 1 et 192.0.2.178 au système DMZ 2. Remarquez que nous avons + assigné une adresse RFC 1918 et un masque de sous-réseau arbitraires à + l'interface DMZ de notre firewall. Cette adresse et ce masque ne sont + pas pertinents - vérifiez juste que celle-ci n'est en conflit avec + aucun autre sous-réseau déjà défini. - La configuration de Proxy ARP est faite dans le fichier La configuration du Proxy ARP est faite dans le fichier /etc/shorewall/proxyarp. #ADDRESS INTERFACE EXTERNAL HAVE ROUTE PERSISTANT 192.0.2.177 eth2 eth0 No 192.0.2.178 eth2 eth0 No - Parce que la variable HAVE ROUTE contient No, Shorewall ajoutera - les routes d'hôte à travers eth2 à 192.0.2.177 et 192.0.2.178. Les - interfaces ethernet de DMZ 1 et DMZ 2 pourront être configurées pour - avoir les adresses IP apparentes mais devront avoir la même passerelle - par défaut que le firewall lui-même -- nommé 192.0.2.254. En d'autres - termes, elles pourront être configurées juste comme elles devraient - être si elles étaient parallèles au firewall plutôt que derrière - lui. + La variable HAVE ROUTE étant à No, Shorewall ajoutera les routes + d'hôte pour 192.0.2.177 et 192.0.2.178 par eth2. Les interfaces éthernet des + machines DMZ 1 et DMZ 2 devront être configurées avec les adresses IP + données plus haut, mais elles devront avoir la même passerelle par + défaut que le firewall lui-même (192.0.2.254 dans notre exemple). + Autrement dit, elles doivent être configurées exactement comme si + elles étaient parallèles au firewall plutôt que derrière lui. - Ne pas ajouter le(s) adresse(s) ARP - (192.0.2.177 et 192.0.2.178 dans l'exemple ci-dessus) à l'interface - externe (eth0 dans cet exemple) du firewall. + Ne pas ajouter le(s) adresse(s) traitées + par le proxy ARP (192.0.2.177 et 192.0.2.178 dans l'exemple + ci-dessus) à l'interface externe du firewall (eth0 dans cet + exemple). - Un mot de mise en garde à sa place ici. Les FAI configure(nt) - typiquement leur routeur avec un timeout de cache ARP élevé. Si vous - déplacer un système parallèle à votre firewall derrière le Proxy ARP - du firewall, cela peut mettre des HEURES avant que le système puisse - communiquer avec Internet. Il y a deux choses que vous pouvez essayer - de faire: + Un mot de mise en garde. En général, les FAI + configurent leurs routeurs avec un timeout de cache + ARP assez élevé. Si vous déplacez un système + parallèle à votre firewall derrière le Proxy ARP du firewall, cela + peut mettre des HEURES avant que ce système ne puisse communiquer avec + internet. Il y a deux choses que vous pouvez essayer de faire: - (Courtoisement de Bradey Honsinger) Une lecture de Stevens' - TCP/IP Illustrated, Vol 1 révèle qu'un paquet ARP - gratuitous peut entraîner le routeur de votre FAI à - rafraîchir son cache(section 4.7). Une "gratuitous" ARP est - simplement une requête d'un hôte demandant l'adresse MAC de sa - propre adresse IP; éventuellement pour vérifier que l'adresse IP - n'est pas dupliquée,... + (Salutations à Bradey Honsinger) Une lecture de + TCP/IP Illustrated, Vol 1 de Richard Stevens révèle + qu'un paquet ARP gratuit (gratuitous) peut amener + le routeur de votre FAI à rafraîchir son cache (section 4.7). Un + paquet ARP gratuit est simplement une requête d'un + hôte demandant l'adresse MAC associée à sa propre adresse + IP. - Si l'hôte envoyant la commande gratuitous ARP - vient juste de changer son adresse IP..., ce paquet entraîne tous - les autres hôtes...qui ont une entrée dans son cache pour - l'ancienne adresse matériel de mettre à jour également ses caches - ARP. + En plus de garantir que cette adresse IP n'est pas + dupliquée, si l'hôte qui envoie la commande ARP + gratuit vient juste de changer son adresse + matérielle ..., ce paquet force tous les autres hôtes...qui ont + une entrée dans leur cache ARP pour l'ancienne adresse matérielle + à mettre leurs caches à jour - Ce qui est exactement, bien sûr, ce que vous souhaitez faire - lorsque vous basculez un hôte vulnérable à Internet derrière - Shorewall utilisant proxy ARP (ou one-to-one NAT). Heureusement, - des packages récents (Redhat) iputils - incluent "arping", avec l'option "-U" qui fait cela: + Ce qui est exactement, bien sûr, ce que vous souhaitez faire + lorsque vous basculez un hôte qui était directement exposé sur + internet vers l'arrière de votre firewall Shorewall en utilisant + le proxy ARP (ou en faisant du NAT un-à-un pour la même raison). + Heureusement, les versions récentes du paquetage + iputils de Redhat + comprennent arping, dont l'option "-U" fait + cela: - arping -U -I <net if> <newly proxied IP> + arping -U -I <net if> <newly proxied IP> -arping -U -I eth0 66.58.99.83 # for exampleStevens - continue en mentionnant que tous les systèmes répondent - correctement au gratuitous ARPs,et googling pour - arping -U semble aller dans ce sens. +arping -U -I eth0 66.58.99.83 # for exampleStevens + continue en mentionnant que certains systèmes ne répondent pas + correctement à la commande ARP gratuit, mais une + recherche sur google pour arping -U semble + démontrer que cela fonctionne dans la plupart des cas. - Vous pouvez appeler votre FAI et dire de purger l'ancienne - entrée du cache ARP mais la plupart ne veulent ou ne peuvent le - faire. + Vous pouvez appeler votre FAI et lui + demander de purger l'entrée obsolète de son cache + ARP, mais la plupart ne voudront ou ne pourront + le faire. - Vous pouvez vérifier si le cache ARP de votre FAI est ancien en - utilisant ping et tcpdump. Supposez que vous pensez que la passerelle - routeur a une ancienne entrée ARP pour 192.0.2.177. Sur le firewall, - lancez tcpdump de cette façon: + Vous pouvez vérifier si le cache ARP de votre FAI est obsolète + en utilisant ping et tcpdump. + Supposez que vous pensez que la passerelle routeur a une entrée ARP + obsolète pour 192.0.2.177. Sur le firewall, lancez + tcpdump de cette façon: tcpdump -nei eth0 icmp - Maintenant depuis 192.0.2.177, utilisez ping vers la passerelle - du FAI (que nous supposons être 192.0.2.254): + Maintenant depuis 192.0.2.177, pingez la + passerelle de votre FAI (que nous supposons être 192.0.2.254): ping 192.0.2.254 - Nous pouvons maintenant observer le résultat de tcpdump: + Nous pouvons maintenant observer le résultat de + tcpdump: 13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF) 13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: - 192.0.2.254 > 192.0.2.177 : icmp: echo replyNotez - que l'adresse source MAC dans la requête echo est différente de - l'adresse de destination dans la réponse echo!! Dans le cas ou - 0:4:e2:20:20:33 était l'adresse MAC de l'interface NIC eth0 du - firewall tandis que 0:c0:a8:50:b2:57 était l'adresse MAC de DMZ 1. En - d'autre termes, le cache ARP de la passerelle associe encore - 192.0.2.177 avec la NIC de DMZ 1 plutôt qu'avec eth0 du firewall. + 192.0.2.254 > 192.0.2.177 : icmp: echo replyRemarquez + que l'adresse source MAC dans la requête echo est + différente de l'adresse MAC de destination dans la + réponse echo ! Dans ce cas, 0:4:e2:20:20:33 était l'adresse + MAC de l'interface réseau eth0 du firewall tandis que + 0:c0:a8:50:b2:57 était l'adresse MAC de la carte + réseau de DMZ 1. En d'autre termes, le cache ARP de + la passerelle associe encore 192.0.2.177 avec la carte réseau de DMZ 1 + plutôt qu'avec l'interface eth0 du firewall.
- One-to-one NAT + NAT un-à-un - Avec one-to-one NAT, vous assignez les adresses systèmes RFC - 1918 puis établissez une à une l'assignation entre ces adresses et les - adresses publiques. Pour les occurrences des connexions sortantes SNAT - (Source Network Address Translation) et pour les occurrences des - connexions entrantes DNAT (Destination Network Address Translation). - Voyons avec l'exemple précédent du serveur web de votre fille tournant - sur le système Local 3. + Avec le NAT un-à-un (one-to-one NAT), vous attribuez des + adresses RFC 1918 à vos systèmes puis vous établissez une + correspondance un pour un de ces adresses avec les adresses IP + publiques. Pour les occurrences des connexions sortantes, la + traduction d'adresses sources (SNAT) sera alors + effectuée. Pour les occurrences des connexions entrantes, c'est la + traduction d'adresses destination (DNAT) qui sera + réalisée. + + Voyons avec l'exemple précédent du serveur web de votre fille + tournant sur le système Local 3. - Rappel du paramétrage, le réseau local utilise SNAT et partage - l'IP externe du firewall (192.0.2.176) pour les connexions sortantes. - Cela est obtenu avec l'entrée suivante dans le fichier - /etc/shorewall/masq: + Souvenons-nous que dans cette configuration, le réseau local + utilise la SNAT et qu'il partage l'IP externe du + firewall (192.0.2.176) pour les connexions sortantes. On obtient ce + résultat grâce à l'entrée suivante dans le fichier + /etc/shorewall/masq: #INTERFACE SUBNET ADDRESS eth0 192.168.201.0/29 192.0.2.176 - Supposons maintenant que vous avez décidé d'allouer à votre + Supposons maintenant que vous ayez décidé d'allouer à votre fille sa propre adresse IP (192.0.2.179) pour l'ensemble des - connexions entrantes et sortantes. Vous devrez faire cela en ajoutant - une entrée dans le fichier + connexions entrantes et sortantes. Vous pouvez faire cela en ajoutant + cette entrée dans le fichier /etc/shorewall/nat. #EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL 192.0.2.179 eth0 192.168.201.4 No No - Avec cette entrée active, votre fille a sa propre adresse IP et - les deux autres systèmes locaux partagent l'adresse IP du + Avec cette entrée active, votre fille a sa propre adresse IP et + les deux autres systèmes locaux partagent l'adresse IP du firewall. Une fois que la relation entre 192.0.2.179 et192.168.201.4 est - établie par l'entrée ci-dessus, ce n'est pas nécessaire d'utiliser une - règle DNAT pour le serveur Web de votre fille -- vous devez simplement - utiliser une règle ACCEPT: + établie avec l'entrée ci-dessus dans le fichier + nat, l'utilisation d'une règle d'une règle DNAT + pour le serveur Web de votre fille n'est plus appropriée -- vous + devriez plutôt utiliser une simple règle ACCEPT: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT(S) PORT(S) DEST ACCEPT net loc:192.168.201.4 tcp www - Un mot de mise en garde à sa place ici. Les FAI configure(nt) - typiquement leur routeur avec un timeout de cache ARP élevé. Si vous - déplacer un système parallèle à votre firewall derrière le One-on-one - NAT du firewall, cela peut mettre des HEURES avant que le système - puisse communiquer avec Internet. Il y a deux choses que vous pouvez - essayer de faire: + Un mot de mise en garde. En général, les FAI + configurent leurs routeurs avec un timeout de cache + ARP assez élevé. Si vous déplacez un système + parallèle à votre firewall derrière le Proxy ARP du firewall, cela + peut mettre des HEURES avant que ce système ne puisse communiquer avec + internet. Il y a deux choses que vous pouvez essayer de faire: - (Courtoisement de Bradey Honsinger) Une lecture de Stevens' - TCP/IP Illustrated, Vol 1 révèle qu'un paquet ARP - gratuitous peut entraîner le routeur de votre FAI à - rafraîchir son cache(section 4.7). Une "gratuitous" ARP est - simplement une requête d'un hôte demandant l'adresse MAC de sa - propre adresse IP; éventuellement pour vérifier que l'adresse IP - n'est pas dupliquée,... + (Salutations à Bradey Honsinger) Une lecture de + TCP/IP Illustrated, Vol 1 de Richard Stevens révèle + qu'un paquet ARP gratuit (gratuitous) peut amener + le routeur de votre FAI à rafraîchir son cache (section 4.7). Un + paquet ARP gratuit est simplement une requête d'un + hôte demandant l'adresse MAC associée à sa propre adresse + IP. - Si l'hôte envoyant la commande gratuitous ARP - vient juste de changer son adresse IP..., ce paquet entraîne tous - les autres hôtes...qui ont une entrée dans son cache pour - l'ancienne adresse matériel de mettre à jour également ses caches - ARP. + En plus de garantir que cette adresse IP n'est pas + dupliquée, si l'hôte qui envoie la commande ARP + gratuit vient juste de changer son adresse + matérielle ..., ce paquet force tous les autres hôtes...qui ont + une entrée dans leur cache ARP pour l'ancienne adresse matérielle + à mettre leurs caches à jour - Ce qui est exactement, bien sûr, ce que vous souhaitez faire - lorsque vous basculez un hôte vulnérable à Internet derrière - Shorewall utilisant proxy ARP (ou one-to-one NAT). Heureusement, - des packages récents (Redhat) iputils - incluent "arping", avec l'option "-U" qui fait cela: + Ce qui est exactement, bien sûr, ce que vous souhaitez faire + lorsque vous basculez un hôte qui était directement exposé sur + internet vers l'arrière de votre firewall Shorewall en utilisant + le proxy ARP (ou en faisant du NAT un-à-un pour la même raison). + Heureusement, les versions récentes du paquetage + iputils de Redhat + comprennent arping, dont l'option "-U" fait + cela: - arping -U -I <net if> <newly proxied IP> + arping -U -I <net if> <newly proxied IP> -arping -U -I eth0 66.58.99.83 # for exampleStevens - continue en mentionnant que tous les systèmes répondent - correctement au gratuitous ARPs,et googling pour - arping -U semble aller dans ce sens. +arping -U -I eth0 66.58.99.83 # for exampleStevens + continue en mentionnant que certains systèmes ne répondent pas + correctement à la commande ARP gratuit, mais une + recherche sur google pour arping -U semble + démontrer que cela fonctionne dans la plupart des cas. - Vous pouvez appeler votre FAI et dire de purger l'ancienne - entrée du cache ARP mais la plupart ne veulent ou ne peuvent le - faire. + Vous pouvez appeler votre FAI et lui + demander de purger l'entrée obsolète de son cache + ARP, mais la plupart ne voudront ou ne pourront + le faire. - Vous pouvez vérifier si le cache ARP de votre FAI est ancien en - utilisant ping et tcpdump. Supposez que vous pensez que la passerelle - routeur a une ancienne entrée ARP pour 192.0.2.177. Sur le firewall, - lancez tcpdump de cette façon:: + Vous pouvez vérifier si le cache ARP de votre FAI est obsolète + en utilisant ping et tcpdump. + Supposez que vous pensez que la passerelle routeur a une entrée ARP + obsolète pour 192.0.2.177. Sur le firewall, lancez + tcpdump de cette façon: tcpdump -nei eth0 icmp - Maintenant depuis 192.0.2.177, utilisez ping vers la passerelle - du FAI (que nous supposons être 192.0.2.254): + Maintenant depuis 192.0.2.177, pingez la + passerelle de votre FAI (que nous supposons être 192.0.2.254): ping 192.0.2.254 - Nous pouvons maintenant observer le résultat de tcpdump: + Nous pouvons maintenant observer le résultat de + tcpdump: 13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF) 13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: - 192.0.2.254 > 192.0.2.177 : icmp: echo replyNotez - que l'adresse source MAC dans la requête echo est différente de - l'adresse de destination dans la réponse echo!! Dans le cas ou - 0:4:e2:20:20:33 était l'adresse MAC de l'interface NIC eth0 du - firewall tandis que 0:c0:a8:50:b2:57 était l'adresse MAC de DMZ 1. En - d'autre termes, le cache ARP de la passerelle associe encore - 192.0.2.177 avec la NIC de DMZ 1 plutôt qu'avec eth0 du firewall. + 192.0.2.254 > 192.0.2.177 : icmp: echo replyRemarquez + que l'adresse source MAC dans la requête echo est + différente de l'adresse MAC de destination dans la + réponse echo ! Dans ce cas, 0:4:e2:20:20:33 était l'adresse + MAC de l'interface réseau eth0 du firewall tandis que + 0:c0:a8:50:b2:57 était l'adresse MAC de la carte + réseau de DMZ 1. En d'autre termes, le cache ARP de + la passerelle associe encore 192.0.2.177 avec la carte réseau de DMZ 1 + plutôt qu'avec l'interface eth0 du firewall.
- Règles + Règles - + + Shorewall dispose d'un mécanisme de macros comprenant des macros pour de + nombreuses applications standard. Dans cette section nous + n'utiliserons pas de macro. mais nous définirons les règles + directement. + - Avec les politiques par défaut, vos systèmes locaux (Local 1-3) - peuvent accéder à tous les serveurs sur Internet et la DMZ ne peut - accéder à aucun autre hôte (incluant le firewall). Avec les exceptions - des règles règles NAT qui entraînent la translation d'adresses et permet - aux requêtes de connexion translatées de passer à travers le firewall, - la façon d'autoriser des requêtes à travers le firewall est d'utiliser - des règles ACCEPT. + Avec les politiques définies plus tôt dans ce document, vos + systèmes locaux (Local 1-3) peuvent accéder à n'importe quel serveur sur + internet alors que la DMZ ne peut accéder à aucun + autre hôte, dont le firewall. A l'exception des règles + NAT qui entraînent la traduction d'adresses et + permettent aux requêtes de connexion traduites de passer à travers le + firewall, la façon d'autoriser des requêtes à travers votre firewall est + d'utiliser des règles ACCEPT. Puisque les colonnes SOURCE PORT et ORIG. DEST. ne sont pas - utilisées dans cette section, elle ne sont pas affichées. + utilisées dans cette section, elle ne seront pas affichées. - Vous souhaiter certainement autoriser ping entre vos zones: + Vous souhaiter certainement autoriser le ping + entre vos zones: #ACTION SOURCE DEST PROTO DEST # PORT(S) @@ -1721,9 +1918,9 @@ ACCEPT net loc icmp echo-request ACCEPT dmz loc icmp echo-request ACCEPT loc dmz icmp echo-request - En supposant que vous avez des serveurs mail et pop3 actifs sur - DMZ 2 et un serveur Web sur DMZ 1. Les règles dont vous avez besoin - sont: + Supposons que vous avez des serveurs mail et pop3 actifs sur le + système DMZ 2, et un serveur Web sur le système DMZ 1. Les règles dont + vous avez besoin sont: #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) @@ -1735,7 +1932,7 @@ ACCEPT loc dmz:192.0.2.178 tcp smtp #Mail from local #Network ACCEPT loc dmz:192.0.2.178 tcp pop3 #Pop3 from local #Network -ACCEPT fw dmz:192.0.2.178 tcp smtp #Mail from the +ACCEPT $FW dmz:192.0.2.178 tcp smtp #Mail from the #Firewall ACCEPT dmz:192.0.2.178 net tcp smtp #Mail to the #Internet @@ -1747,8 +1944,8 @@ ACCEPT loc dmz:192.0.2.177 tcp https #Secure WWW #from local #Network - Si vous utilisez un serveur DNS publique sur 192.0.2.177, vous - devez ajouter les règles suivantes: + Si vous utilisez un serveur DNS public sur 192.0.2.177, vous devez + ajouter les règles suivantes: #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) @@ -1760,73 +1957,76 @@ ACCEPT loc dmz:192.0.2.177 udp domain #UDP DNS from #Local Network ACCEPT loc dmz:192.0.2.177 tcp domain #TCP DNS from #Local Network -ACCEPT fw dmz:192.0.2.177 udp domain #UDP DNS from +ACCEPT $FW dmz:192.0.2.177 udp domain #UDP DNS from #the Firewall -ACCEPT fw dmz:192.0.2.177 tcp domain #TCP DNS from +ACCEPT $FW dmz:192.0.2.177 tcp domain #TCP DNS from #the Firewall ACCEPT dmz:192.0.2.177 net udp domain #UDP DNS to #the Internet ACCEPT dmz:192.0.2.177 net tcp domain #TCPP DNS to #the Internet - Vous souhaitez probablement communiquer entre votre firewall et - les systèmes DMZ depuis le réseau local -- Je recommande SSH qui, grâce - à son utilitaire scp peut aussi faire de la diffusion et de la mise à + Vous souhaiterez probablement communiquer depuis votre réseau + local avec votre firewall et les systèmes en DMZ -- + Je recommande SSH qui, grâce à son utilitaire + scp peut aussi faire de la diffusion et de la mise à jour de logiciels. #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT loc dmz tcp ssh #SSH to the DMZ -ACCEPT net fw tcp ssh #SSH to the +ACCEPT net $FW tcp ssh #SSH to the #Firewall
D'autres petites choses - La discussion précédente reflète ma préférence personnelle pour - l'utilisation de Proxy ARP associé à mes serveurs de la DMZ et SNAT/NAT - pour mes systèmes locaux. Je préfère utiliser NAT seulement dans le cas - ou un système qui fait partie d'un sous-réseau RFC 1918 à besoin d'avoir - sa propre adresse IP. + La discussion précédente reflète ma préférence personnelle pour + l'utilisation d'un Proxy ARP associé à mes serveurs en DMZ et de + SNAT/NAT pour les systèmes locaux. Je préfère utiliser la NAT seulement + dans le cas ou un système qui fait partie d'un sous-réseau RFC 1918 à + besoin d'avoir sa propre adresse IP publique. - Si vous ne l'avez pas fait, ce peut-être une bonne idée de - parcourir le fichier Si vous ne l'avez déjà fait, ce serait une bonne idée de parcourir + le fichier /etc/shorewall/shorewall.conf - afin de voir si autre chose pourrait être intéressant. Vous pouvez aussi - regarder aux autres fichiers de configuration que vous n'avez pas touché - pour un aperçu des autres possibilités de Shorewall. + juste pour voir si autre chose pourrait vous intéresser. Vous pouvez + aussi regarder les autres fichiers de configuration que vous n'avez pas + touchés pour avoir un aperçu des autres possibilités de + Shorewall. - Dans le cas ou vous n'auriez pas validé les étapes, ci-dessous se - trouve un jeu final des fichiers de configuration pour notre réseau - exemple. Uniquement ceux modifiés de la configuration originale sont - montrés. + Dans le cas ou vous auriez perdu le fil, vous trouverez ci-dessous + un jeu final des fichiers de configuration pour le réseau de notre + exemple. Seuls les fichiers de la configuration initiale qui ont été + modifiés sont présentés. - /etc/shorewall/interfaces (Les "options" - seront spécifiques aux sites). + /etc/shorewall/interfaces (Les "options" sont + très dépendantes des sites). #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect rfc1918,routefilter loc eth1 detect dmz eth2 detect - La configuration décrite nécessite que votre réseau soit démarré - avant que Shorewall puisse se lancer. Cela ouvre un lapse de temps - durant lequel vous n'avez pas de protection firewall. + La configuration décrite ici nécessite que votre réseau soit + démarré avant que Shorewall ne puisse se lancer. Ceci laisse un petit + intervalle de temps durant lequel vous n'avez pas la protection d'un + firewall. - Si vous remplacez detect par les valeurs des - adresses broadcoast dans les entrées suivantes, vous pouvez activer - Shorewall avant les interfaces réseau. + Si vous remplacez le detect dans les entrées + ci-dessus par la valeurs des adresses de diffusion (broadcoast) réelles, + vous pouvez activer Shorewall avant de monter vos interfaces + réseau. #ZONE INTERFACE BROADCAST OPTIONS net eth0 192.0.2.255 rfc1918 loc eth1 192.168.201.7 dmz eth2 192.168.202.7 - /etc/shorewall/masq - Sous-réseau - Local + /etc/shorewall/masq - Réseau Local #INTERFACE SUBNET ADDRESS eth0 192.168.201.0/29 192.0.2.176 @@ -1837,15 +2037,13 @@ eth0 192.168.201.0/29 192.0.2.176 192.0.2.177 eth2 eth0 No 192.0.2.178 eth2 eth0 No - /etc/shorewall/nat- Le système de ma + /etc/shorewall/nat- Le système de ma fille #EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL 192.0.2.179 eth0 192.168.201.4 No No - /etc/shorewall/rules - - #ACTION SOURCE DEST PROTO DEST COMMENTS + /etc/shorewall/rules#ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT net dmz icmp echo-request ACCEPT net loc icmp echo-request @@ -1861,7 +2059,7 @@ ACCEPT loc dmz:192.0.2.178 tcp smtp #Mail from local #Network ACCEPT loc dmz:192.0.2.178 tcp pop3 #Pop3 from local #Network -ACCEPT fw dmz:192.0.2.178 tcp smtp #Mail from the +ACCEPT $FW dmz:192.0.2.178 tcp smtp #Mail from the #Firewall ACCEPT dmz:192.0.2.178 net tcp smtp #Mail to the #Internet @@ -1880,38 +2078,41 @@ ACCEPT loc dmz:192.0.2.177 udp domain #UDP DNS from #Local Network ACCEPT loc dmz:192.0.2.177 tcp domain #TCP DNS from #Local Network -ACCEPT fw dmz:192.0.2.177 udp domain #UDP DNS from +ACCEPT $FW dmz:192.0.2.177 udp domain #UDP DNS from #the Firewall -ACCEPT fw dmz:192.0.2.177 tcp domain #TCP DNS from +ACCEPT $FW dmz:192.0.2.177 tcp domain #TCP DNS from #the Firewall ACCEPT dmz:192.0.2.177 net udp domain #UDP DNS to #the Internet ACCEPT dmz:192.0.2.177 net tcp domain #TCPP DNS to #the Internet ACCEPT loc dmz tcp ssh #SSH to the DMZ -ACCEPT net fw tcp ssh #SSH to the - #Firewall +ACCEPT net $FW tcp ssh #SSH to the + #Firewall
DNS - En donnant une collection d'adresses RFC 1918 et publiques dans la - configuration, cela justifie d'avoir des serveurs DNS interne et externe. + Compte tenu des adresses RFC 1918 et des adresses publiques + utilisées dans cette configuration, la seule façon logique de faire est + d'avoir des serveurs DNS interne et externe séparés. Vous pouvez combiner les deux dans un unique serveur BIND 9 utilisant les - vues (Views). Si vous n'êtes pas intéressé par les vues BIND 9, vous - pouvez allez à la section suivante. + vues (Views). Si vous n'êtes pas intéressé par les vues BIND 9, vous + pouvez allez à la section suivante. - Supposons que votre domaine est foobar.net et vous voulez que les - deux systèmes DMZ s'appellent www.foobar.net et mail.foobar.net, les trois - systèmes locaux "winken.foobar.net, blinken.foobar.net et nod.foobar.net. - Vous voulez que le firewall soit connu à l'extérieur sous le nom - firewall.foobar.net, son interface vers le réseau local gateway.foobar.net - et son interface vers la DMZ dmz.foobar.net. Mettons le serveur DNS sur - 192.0.2.177 qui sera aussi connu sous le nom ns1.foobar.net. + Supposons que votre domaine est foobar.net. Vous voulez que les deux + systèmes en DMZ s'appellent www.foobar.net et + mail.foobar.net, et vous voulez que les trois systèmes locaux s'appellent + winken.foobar.net, blinken.foobar.net et nod.foobar.net. Vous voulez que + le firewall soit connu à l'extérieur sous le nom de firewall.foobar.net, + que son interface vers le réseau local soit nommée gateway.foobar.net et + que son interface vers la DMZ soit dmz.foobar.net. + Mettons le serveur DNS sur 192.0.2.177 qui sera aussi connu sous le nom de + ns1.foobar.net. - Le fichier /etc/named.conf devrait ressembler à + Le fichier /etc/named.conf devrait ressembler à cela: @@ -1919,6 +2120,12 @@ ACCEPT net fw tcp ssh #SSH to the options { directory "/var/named"; listen-on { 127.0.0.1 ; 192.0.2.177; }; + transfer-format many-answers; + max-transfer-time-in 60; + +allow-transfer { + // Servers allowed to request zone tranfers + <secondary NS IP>; }; }; logging { @@ -2032,7 +2239,6 @@ view "external" { type master; notify yes; allow-update {none; }; - allow-transfer { <secondary NS IP>; }; file "ext/db.foobar"; }; @@ -2040,7 +2246,6 @@ view "external" { type master; notify yes; allow-update { none; }; - allow-transfer { <secondary NS IP>; }; file "db.192.0.2.176"; }; @@ -2048,7 +2253,6 @@ view "external" { type master; notify yes; allow-update { none; }; - allow-transfer { <secondary NS IP>; }; file "db.192.0.2.177"; }; @@ -2056,7 +2260,6 @@ view "external" { type master; notify yes; allow-update { none; }; - allow-transfer { <secondary NS IP>; }; file "db.192.0.2.178"; }; @@ -2064,17 +2267,16 @@ view "external" { type master; notify yes; allow-update { none; }; - allow-transfer { <secondary NS IP>; }; file "db.192.0.2.179"; }; }; - Voici les fichiers de /var/named (ceux qui ne sont pas présents - font partis de votre distribution BIND). + Voici les fichiers du répertoire /var/named (ceux qui ne sont pas présentés + font en général partie de votre distribution BIND). - db.192.0.2.176 - Zone inverse de l'interface - externe du firewall + db.192.0.2.176 - Zone inverse (reverse) pour + l'interface externe du firewall ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32 @@ -2099,7 +2301,7 @@ view "external" { 176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net. db.192.0.2.177 - Zone inverse pour le serveur - www/DNS server + www ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32 @@ -2149,7 +2351,7 @@ view "external" { 178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net. db.192.0.2.179 - Zone inverse du serveur web - publique de votre fille + public de votre fille ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32 @@ -2197,7 +2399,7 @@ view "external" { 1 86400 IN PTR localhost.foobar.net. int/db.192.168.201 - Zone inverse pour le - réseau local. cela n'est montré qu'aux clients internes + réseau local. Cela ne sera visible que depuis les clients internes ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29 @@ -2246,8 +2448,8 @@ view "external" { ; ############################################################ 1 86400 IN PTR dmz.foobar.net. - int/db.foobar - Forward zone pour l'utilisation - des clients internes. + int/db.foobar - Forward zone pour les clients + internes. ;############################################################## ; Start of Authority for foobar.net. @@ -2272,12 +2474,14 @@ localhost 86400 IN A 127.0.0.1 firewall 86400 IN A 192.0.2.176 www 86400 IN A 192.0.2.177 ns1 86400 IN A 192.0.2.177 -www 86400 IN A 192.0.2.177 +mail 86400 IN A 192.0.2.178 -gateway 86400 IN A 192.168.201.1 -winken 86400 IN A 192.168.201.2 -blinken 86400 IN A 192.168.201.3 -nod 86400 IN A 192.168.201.4 +gateway 86400 IN A 192.168.201.1 +winken 86400 IN A 192.168.201.2 +blinken 86400 IN A 192.168.201.3 +nod 86400 IN A 192.168.201.4 + +dmz 86400 IN A 192.168.202.1 ext/db.foobar - Forward zone pour les clients externes @@ -2329,114 +2533,113 @@ foobar.net. 86400 IN A 192.0.2.177
- Quelques Points à Garder en Mémoire + Quelques Points à Garder en Mémoire - Vous ne pouvez tester votre firewall de - l'intérieur de votre réseau. Car les requêtes que vous - envoyez à votre adresse IP ne veux pas dire qu'elles seront associées - à votre interface externe ou la zone net. Tout trafic - généré par le réseau local sera traité par loc->fw. + Vous ne pouvez pas tester votre firewall + depuis l'intérieur de votre réseau. Envoyer des requêtes à + l'adresse IP externe de votre firewall ne signifie pas qu'elle seront + associées à votre interface externe ou à la zone net. + Tout trafic généré par le réseau local sera associé à l'interface + locale et sera traité comme du trafic du réseau local ver le firewall + (loc->fw). - Les adresses IP sont des propriétés des - systèmes, pas des interfaces. C'est une erreur de croire - que votre firewall est capable de renvoyer des paquets simplement - parce que vous pouvez faire un ping sur l'adresse IP de toutes les - interfaces du firewall depuis le réseau local. La seul conclusion est - de conclure que le lien entre le réseau local et le firewall est - établi et que vous avez probablement la bonne adresse de la passerelle - sur votre système. + Les adresses IP sont des propriétés des + systèmes, pas des interfaces. C'est une erreur de croire + que votre firewall est capable de faire suivre + (forward) des paquets simplement parce que vous + pouvez faire un ping sur l'adresse IP de toutes les + interfaces du firewall depuis le réseau local. La seule conclusion que + vous puissiez faire dans ce cas est que le lien entre le réseau local + et le firewall fonctionne et que vous avez probablement la bonne + adresse de passerelle par défaut sur votre système. - Toutes les adresses IP configurées sur le + Toutes les adresses IP configurées sur le firewall sont dans la zone $FW (fw). Si 192.168.1.254 est - l'adresse IP de votre interface interne, alors vous pouvez écrire + l'adresse IP de votre interface interne, alors vous pouvez écrire $FW:192.168.1.254 dans - une régle mais vous ne devez pas écrire loc:192.168.1.254. C'est aussi un - non-sens d'ajouter 192.168.1.254 à la zone loc en utilisant une entrée dans + une régle mais vous ne devez pas écrire loc:192.168.1.254. C'est aussi une + absurdité d'ajouter 192.168.1.254 à la zone loc en utilisant une entrée dans /etc/shorewall/hosts. - Les paquets de retour (Reply) ne suivent - PAS automatiquement le chemin inverse de la requête - d'origine. Tous les paquets sont routés en se référant à la - table de routage respective de chaque hôte à chaque étape du trajet. - C'est commun chez ceux qui installent le firewall Shorewall en - parallèle à une passerelle existante et essayent d'utiliser DNAT dans - Shorewall sans changer la passerelle par défaut sur les systèmes - recevant le retour des requêtes. Les requêtes dont, à travers le - firewall Shorewall, l'adresse de destination IP est réécrite mais la - réponse va directement vers l'ancienne passerelle. + Les paquets de retour (reply) ne suivent + PAS automatiquement le chemin inverse de la requête + d'origine. Tous les paquets sont routés en se référant à la + table de routage respective de chaque hôte à chaque étape du trajet. + Ce problème se produit en général lorsque on installe un firewall + Shorewall en parallèle à une passerelle existante et qu'on essaye + d'utiliser des règles DNAT dans Shorewall sans + changer la passerelle par défaut sur les systèmes recevant les + requêtes transférées (forwarded). Les requêtes passent dans le + firewall Shorewall où l'adresse de destination IP est réécrite, mais + la réponse revient par l'ancienne passerelle qui, elle, ne modifiera + pas le paquet. - Shorewall lui-même n'a aucune notion du - dedans et du dehors. Ces concepts dépendent de la façon - dont Shorewall est configuré. + Shorewall lui-même n'a aucune notion du + dedans et du dehors. Ces concepts dépendent de la façon + dont Shorewall est configuré.
- Démarrer et Arrêter Votre Firewall + Démarrer et Arrêter Votre Firewall - La procédure d'installation - configure votre système pour lancer Shorewall au boot du système, mais au - début avec la version 1.3.9 de Shorewall le lancement est désactivé, - n'essayer pas de lancer Shorewall avant que la configuration soit finie. - Une fois que vous en aurez fini avec la configuration du firewall, vous - pouvez permettre le lancement de Shorewall en supprimant le fichier - /etc/shorewall/startup_disabled. - - Les utilisateurs des paquets .deb doivent éditer La procédure d'installation + configure votre système pour lancer Shorewall dès le boot du système, mais + le lancement est désactivé, de façon à ce que votre système ne tente pas + de lancer Shorewall avant que la configuration ne soit terminée. Une fois + que vous en avez fini avec la configuration du firewall, vous devez éditer + /etc/shorewall/shorewall.conf et y mettre STARTUP_ENABLED=Yes. + Les utilisateurs des paquetages .deb doivent éditer /etc/default/shorewall et mettre startup=1. - Le firewall est activé en utilisant la commande - shorewall start et arrêté avec - shorewall stop. Lorsque le firewall est - stoppé, le routage est autorisé sur les hôtes qui possèdent une entrée - dans /etc/shorewall/routestopped. Un - firewall qui tourne peut être relancé en utilisant la commande - shorewall restart command. Si vous - voulez enlever toutes traces de Shorewall sur votre configuration de - Netfilter, utilisez shorewall - clear. + + + Le firewall est activé en utilisant la commande + shorewall start et arrêté avec la + commande shorewall stop. Lorsque le + firewall est arrêté, le routage est autorisé sur les hôtes qui possèdent + une entrée dans /etc/shorewall/routestopped. + Un firewall qui tourne peut être relancé en utilisant la commande + shorewall restart. Si vous voulez + enlever toute trace de Shorewall sur votre configuration de Netfilter, + utilisez shorewall + clear - Les exemples supposent que vous voulez permettre le routage depuis - ou vers eth1 (le réseau local) et - eth2 (DMZ) lorsque Shorewall est - stoppé. Si ces deux interfaces ne sont pas connectées à votre réseau local - et votre DMZ, ou si vous voulez permettre un ensemble d'hôtes différents, - modifiez Modifiez /etc/shorewall/routestopped en - conséquence. - Si vous êtes connecté à votre firewall depuis Internet, - n'essayez pas une commande shorewall - stop tant que vous n'avez pas ajouté une entrée pour - votre adresse IP (celle à partir de laquelle vous - êtes connectée) dans /etc/shorewall/routestopped. - De la même manière, je ne vous recommande pas d'utiliser - shorewall restart; il est plus - intéressant de créer routestopped pour + y configurer les hôtes auxquels vous voulez accéder lorsque le firewall + est arrêté. + Si vous êtes connecté à votre firewall depuis internet, + n'essayez pas d'exécuter une commande shorewall + stop tant que vous n'avez pas ajouté une entrée dans + /etc/shorewall/routestopped + pour l'adresse IP à partir de laquelle vous êtes connecté . De la même + manière, je vous déconseille d'utiliser shorewall + restart; il est plus intéressant de créer une configuration alternative et de la tester en utilisant la commande - shorewall try. + shorewall + try
\ No newline at end of file