Guide de configuration Shorewall

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

et si nous la regardons comme un entier de 32 bits nous avons

C000020E

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

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 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-réseau (subnet ou subnetwork) est un ensemble contigu d'adresses IP tel que:

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 à 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:

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.

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

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

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.

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.

Ainsi, chaque adresse a.b.c.d peut aussi être écrite a.b.c.d/32 et l'ensemble des adresses possibles est écrit 0.0.0.0/0.

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.

/sbin/shorewall propose une commande ipcalc qui calcule automatiquement les informations d'un [sous-]réseau.

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

shorewall ipcalc 10.10.10.0 255.255.255.128
   CIDR=10.10.10.0/25
   NETMASK=255.255.255.128
   NETWORK=10.10.10.0
   BROADCAST=10.10.10.127

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
Destination     Gateway         Genmask         Flgs MSS Win irtt Iface
192.168.9.1     0.0.0.0         255.255.255.255 UH   40  0      0 texas
206.124.146.177 0.0.0.0         255.255.255.255 UH   40  0      0 eth1
206.124.146.180 0.0.0.0         255.255.255.255 UH   40  0      0 eth3
192.168.3.0     0.0.0.0         255.255.255.0   U    40  0      0 eth3
192.168.2.0     0.0.0.0         255.255.255.0   U    40  0      0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U    40  0      0 eth2
206.124.146.0   0.0.0.0         255.255.255.0   U    40  0      0 eth0
192.168.9.0     192.0.2.223     255.255.255.0   UG   40  0      0 texas
127.0.0.0       0.0.0.0         255.0.0.0       U    40  0      0 lo
0.0.0.0         206.124.146.254 0.0.0.0         UG   40  0      0 eth0
[root@gateway root]#

L'interface texas est un tunnel GRE vers un site pair à Dallas, au Texas.

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 routage et:

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.

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, pour router ce paquet à 192.168.1.5, il faudra le transmettre directement à l'interface eth2.

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.

Quant on envoie des paquets sur ethernet, les adresses IP ne sont pas utilisées. L'adressage ethernet est basé sur les adresses MAC (Media Access Control). Chaque carte ethernet à 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 ethernet grâce à l'utilitaire « ip »:

[root@gateway root]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0
inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0
[root@gateway root]#

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, 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
tcpdump: listening on eth2
09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42:
                arp who-has 192.168.1.19 tell 192.168.1.254
09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60:
                arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0

2 packets received by filter
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 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 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

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.

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é, 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-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 dans ces plages, il faut bien avoir à l'esprit les choses suivantes:

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.

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.

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

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 ethernet 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 ethernet adressées à cette adresse MAC et les trames seront reçues correctement par le firewall/routeur.

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.

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

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.

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.

Souvent, une combinaison de ces techniques est utilisée. Chacune d'entre elles sera détaillée dans la section suivante.

SNAT

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

On a assigné à la zone locale le sous-réseau 192.168.201.0/29 (masque de sous-réseau 255.255.255.248).

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

La SNAT est configurée dans Shorewall avec le fichier /etc/shorewall/masq.

#INTERFACE     SUBNET               ADDRESS
eth0           192.168.201.0/29     192.0.2.176

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.

#ACTION  SOURCE  DEST               PROTO  DEST    SOURCE    ORIGINAL
#                                          PORT(S) PORT(S)   DEST
DNAT     net     loc:192.168.201.4  tcp    www

Proxy ARP

Le principe du proxy ARP est:

• 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 aux requêtes ARP « qui-a-l'adresse » A émises par les hôtes à l'extérieur du firewall.

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

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

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

Attention

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

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

   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 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 eth0 66.58.99.83 # for example

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

2. 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 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, 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:

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 reply

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

NAT un-à-un

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.

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 ayez décidé d'allouer à votre fille sa propre adresse IP (192.0.2.179) pour l'ensemble des 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 firewall.

Une fois que la relation entre 192.0.2.179 et192.168.201.4 est é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. 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:

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

   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 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 eth0 66.58.99.83 # for example

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

2. 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 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, 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:

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 reply

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

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.

Vous souhaiter certainement autoriser le ping entre vos zones:

#ACTION  SOURCE  DEST               PROTO  DEST   
#                                          PORT(S)
ACCEPT   net     dmz                icmp   echo-request
ACCEPT   net     loc                icmp   echo-request
ACCEPT   dmz     loc                icmp   echo-request
ACCEPT   loc     dmz                icmp   echo-request

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)
ACCEPT   net             dmz:192.0.2.178    tcp    smtp    #Mail from
                                                           #Internet
ACCEPT   net             dmz:192.0.2.178    tcp    pop3    #Pop3 from
                                                           #Internet
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
                                                           #Firewall
ACCEPT   dmz:192.0.2.178 net                tcp    smtp    #Mail to the
                                                           #Internet
ACCEPT   net             dmz:192.0.2.177    tcp    http    #WWW from
                                                           #Internet
ACCEPT   net             dmz:192.0.2.177    tcp    https   #Secure WWW
                                                           #from Internet
ACCEPT   loc             dmz:192.0.2.177    tcp    https   #Secure WWW
                                                           #from local
                                                           #Network

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)
ACCEPT   net             dmz:192.0.2.177    udp    domain  #UDP DNS from
                                                           #Internet
ACCEPT   net             dmz:192.0.2.177    tcp    domain  #TCP DNS from
                                                           #Internet
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
                                                           #the Firewall
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 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
                                                           #Firewall

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 déjà fait, ce serait une bonne idée de parcourir le fichier /etc/shorewall/shorewall.conf 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 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" 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 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 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 - Réseau Local

#INTERFACE     SUBNET               ADDRESS
eth0           192.168.201.0/29     192.0.2.176

/etc/shorewall/proxyarp - DMZ

#ADDRESS     EXTERNAL     INTERFACE     HAVE ROUTE
192.0.2.177  eth2         eth0          No
192.0.2.178  eth2         eth0          No

/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 
#                                                  PORT(S)
ACCEPT   net             dmz                icmp   echo-request
ACCEPT   net             loc                icmp   echo-request
ACCEPT   dmz             loc                icmp   echo-request
ACCEPT   loc             dmz                icmp   echo-request
ACCEPT   net             loc:192.168.201.4  tcp    www     #Daughter's
                                                           #Server
ACCEPT   net             dmz:192.0.2.178    tcp    smtp    #Mail from
                                                           #Internet
ACCEPT   net             dmz:192.0.2.178    tcp    pop3    #Pop3 from
                                                           #Internet
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
                                                           #Firewall
ACCEPT   dmz:192.0.2.178 net                tcp    smtp    #Mail to the
                                                           #Internet
ACCEPT   net             dmz:192.0.2.177    tcp    http    #WWW from
                                                           #Internet
ACCEPT   net             dmz:192.0.2.177    tcp    https   #Secure WWW
                                                           #from Internet
ACCEPT   loc             dmz:192.0.2.177    tcp    https   #Secure WWW
                                                           #from local
                                                           #Network
ACCEPT   net             dmz:192.0.2.177    udp    domain  #UDP DNS from
                                                           #Internet
ACCEPT   net             dmz:192.0.2.177    tcp    domain  #TCP DNS from
                                                           #Internet
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
                                                           #the Firewall
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