Différences

Ci-dessous, les différences entre deux révisions de la page.

--- informatique:reseau:routage-internet-multi-liens [2012/02/03 14:56] – bn8
+++ informatique:reseau:routage-internet-multi-liens [2018/03/20 15:55] (Version actuelle) – [Problématique] bn8
@@ Ligne 9: / Ligne 9: @@
 ======  Problématique  ======
-Dans ce genre de cas, la machine //gateway// possède deux liaisons internet avec chacune une IP publique. Le besoin naturel dans ce cas est de pouvoir utiliser les deux liaisons indépendamment et pouvoir ainsi établir une connexion sur un des liens en indiquant comme IP de destination, l'IP de la connexion tout en pouvant utiliser le deuxième liens pour établir une autre connexion. Autre cas encore, celui d'un site web héberger sur ou derrière la machine, votre hébergeur vous met à disposition deux liens internet permettant ainsi d'augmenter votre bande passante et vous souhaitez qu'une répartition de charge soit fait entre ces deux liens.
+Dans ce genre de cas, la machine //gateway// possède deux liaisons internet avec chacune une IP publique. Le besoin naturel dans ce cas est de pouvoir utiliser les deux liaisons indépendamment et pouvoir ainsi établir une connexion sur un des liens en indiquant comme IP de destination, l'IP de la connexion tout en pouvant utiliser le deuxième liens pour établir une autre connexion. Autre cas encore, celui d'un site web héberger sur ou derrière la machine, votre hébergeur vous met à disposition deux liens internet permettant ainsi d'augmenter votre bande passante et vous souhaitez qu'une répartition de charge soit faite entre ces deux liens.
-Le problème est que lorsque la machine reçoit une demande de connexion sur un lien, la demande arrive jusqu'au service écoutant sur le réseau et que lorsque celui-ci souhaite répondre, la table de routage de la machine sert à déterminer le lien à utiliser pour faire sortir notre réponse. La logique veut pour que tout fonctionne correctement que le lien utilisé soit le même que celui qu'à empreinté la demande du client. Cependant, le client étant sur le réseau Internet, c'est la route par défaut qui s'applique. Ainsi une connexion entrant sur la liaison 2 peut très bien ressortir par la liaison 1 en fonction du contenu de la table de routage.
+Le problème est que lorsque la machine reçoit une demande de connexion sur un lien, la demande arrive jusqu'au service écoutant sur le réseau et que lorsque celui-ci souhaite répondre, la table de routage de la machine sert à déterminer le lien à utiliser pour faire sortir notre réponse. La logique veut pour que tout fonctionne correctement que le lien utilisé soit le même que celui qu'a empreintée la demande du client. Cependant, le client étant sur le réseau Internet, c'est la route par défaut qui s'applique. Ainsi une connexion entrant sur la liaison 2 peut très bien ressortir par la liaison 1 en fonction du contenu de la table de routage.
 Il est nécessaire à lors de mettre en place des règles de routages spécifique pour chacune des liaisons internet.
-Ceci passe alors par création dans notre cas de 2 autres tables de routage qui existeront en parallèle de la table par défaut. Il s'agira ensuite d'établir des règles pour spécifier quels traffic utilisera ces tables sachant que par défaut, tout le reste du traffic utilise la table //default//.
+Ceci passe alors par création dans notre cas de 2 autres tables de routage qui existeront en parallèle de la table par défaut. Il s'agira ensuite d'établir des règles pour spécifier quel trafic utilisera ces tables sachant que par défaut, tout le reste du trafic utilise la table //default//.
 =====  Création de tables de routages supplémentaires  =====
@@ Ligne 25: / Ligne 25: @@
 =====  Peupler les tables de routages complémentaires  =====
-Chaque table doit contenir les informations nécéssaires à l'établissement du traffic qui l'uilisera. Ainsi il est important de définir un règle de routage par défaut permettant les réponses aux demandes des clients : On utilisera ici l'interface de la liaison concernné pour s'assurer que le traffic sortira bien par cette interface. Il faudra également ajouter les règles néséssaire à l'établissement de la connexion initial du client : par exemple dans notre schéma d'exemple il faudra ajouter que le réseau LAN est accèssible via l'interface //eth2// pour les requêtes HTTP transmise au serveur Web puisse être routé.
+Chaque table doit contenir les informations nécessaires à l'établissement du trafic qui l’utilisera. Ainsi il est important de définir un règle de routage par défaut permettant les réponses aux demandes des clients : On utilisera ici l'interface de la liaison concerné pour s'assurer que le trafic sortira bien par cette interface. Il faudra également ajouter les règles nécessaires à l'établissement de la connexion initial du client : par exemple dans notre schéma d'exemple il faudra ajouter que le réseau LAN est accessible via l'interface //eth2// pour les requêtes HTTP transmises au serveur Web puisse être routées.
   ip route add [LAN] dev eth2 table cnx1
@@ Ligne 40: / Ligne 40: @@
 ======  En cas de PRE-ROUTING  ======
-Dans le cas particulier où vous faites du PRE-ROUTING, c'est à dire que vous redirigez le trafic arrivant sur la machine gateway vers une autre derrière elle, il faut s'assurer que les réponses emprunteront exactement le circuit inverse et ressortiront par la même interface que les demandes. Pour cela, il faut utiliser la fonctionnalité de conn-mark d'iptables (de Netfilter en réalité) pour suivre les connexions, les marquer avec le module de marquage et ensuite ajouter une règle pour faire en sorte que ces trames marquées soient routées en utilisant la table de routage de l'interface de sortie.
+Dans le cas particulier où vous faites du PRE-ROUTING, c’est-à-dire que vous redirigez le trafic arrivant sur la machine gateway vers une autre derrière elle, il faut s'assurer que les réponses emprunteront exactement le circuit inverse et ressortiront par la même interface que les demandes. Pour cela, il faut utiliser la fonctionnalité de //conn-mark// d'//iptables// (de Netfilter en réalité) pour suivre les connexions, les marquer avec le module de marquage et ensuite ajouter une règle pour faire en sorte que ces trames marquées soient routées en utilisant la table de routage de l'interface de sortie.
 =====  Marquer le trafic  =====
-  iptables -t mangle -A PREROUTING -m state --state new -i eth0 -j CONNMARK --set-mark [MARK1]
+  iptables -t mangle -A PREROUTING -m conntrack --ctstate NEW -i eth0 -j CONNMARK --set-mark [MARK1]
-  iptables -t mangle -A PREROUTING -m state --state new -i eth1 -j CONNMARK --set-mark [MARK2]
   iptables -t mangle -A PREROUTING -m connmark --mark [MARK1] -j MARK --set-mark [MARK1]
-  iptables -t mangle -A PREROUTING -m connmark --mark [MARK2] -j MARK --set-mark [MARK2]
   * **[MARK1] : ** La marque utilisé pour le trafic de l'interface de la liaison 1. Exemple : //4//
   * **[MARK2] : ** La marque utilisé pour le trafic de l'interface de la liaison 2. Exemple : //5//
@@ Ligne 55: / Ligne 51: @@
   ip rule add fwmark [MARK1] table cnx1
   ip rule add fwmark [MARK2] table cnx2
+===== Ajouter les règles de routages =====
+Il est nécessaire que les réseaux vers lesquels le //PREROUTING// est fait, soient connue de la table de routage de l'interface d'entrée. Si vous faite le routage vers un poste d'un LAN dans notre exemple, ce réseau ayant déjà été ajouté dans les tables de routages, cela devrait fonctionner sans autre modification. Si en outre, vous disposer d'autres réseaux (une DMZ par exemple), il est nécessaire qu'ils soient connus de vos tables de routages si vous souhaitez faire du //PREROUTING// vers ces réseaux :
+  ip route add [DMZ] dev [INTERFACE DMZ] table cnx1
+  ip route add [DMZ] dev [INTERFACE DMZ] table cnx2
+**Avec :**
+  * **[DMZ] :** l'IP du réseau DMZ
+  * **[INTERFACE DMZ] :** l'interface de la gateway connectée au réseau DMZ (//eth3// par exemple)