créer passerelle/firewall entre deux cartes réseaux

Support Debian
#9

le PC 10.100.0.10 ne doit avoir accès qu’à son LAN

[quote=“PascalHambourg”]
Il n’y a aucune règle de routage dans ton script, mais seulement une règle iptables de masquerading (NAT source automatique) dont je ne comprends absolument pas l’utilité.

De toute façon, pour empêcher une communication ce n’est ni du routage ni du NAT qu’il faut mais du filtrage. Pour faire du filtrage, il faut définir pour chaque flux les interfaces d’entrée et de sortie, les adresses ou préfixes source et destination, le cas échéant les protocoles (TCP, UDP…), ports source et destination…[/quote]
C’est un script que j’ai trouvé sur le net pour faire une passerelle : j’avoue ne pas bien comprendre ce que fait exactement la ligne de commande “iptables -t nat -A POSTROUTING -s 10.1.0.250 -o eth1.1000 -j MASQUERADE” : si je la supprime, le PC 10.200.0.72 aura quand même accès au PC 10.100.0.10 ? Je pensais qu’elle servait à dire que tout ce qui provient de 10.1.0.250 est autorisé à sortir sur l’interface eth1.1000.
C’est la ligne “echo 1 > /proc/sys/net/ipv4/ip_forward” qui permet d’activer la passerelle ?
Quelle est la commande qu’il faut utiliser pour faire du filtrage ?

#10

Cette restriction s’applique seulement à cette machine ou à toutes celles de ce sous-réseau ?

Cette commande crée une règle iptables qui a pour but de remplacer l’adresse source 10.1.0.250 des connexions sortant par l’interface eth1.1000 (VLAN 1000 sur eth0) par l’adresse de cette interface. Je peux dire ce qu’elle fait, mais je ne vois pas pourquoi. En tout cas elle ne fait ni routage ni filtrage.

Oui, elle active la fonction routeur IPv4 qui permet de retransmettre les paquets reçus à destination d’une autre machine.

Il faut créer des règles iptables de filtrage dans la chaîne FORWARD pour accepter ou bloquer les paquets routés entre deux interfaces, une seule règle ne suffira pas forcément. Une règle peut prendre en compte divers critères comme les interfaces d’entrée et de sortie, les addresses source et destination, le protocole, les ports source et destination…

Pour la construction du jeu de règles il y a deux approches opposées :

  • on bloque tout par défaut et on accepte au cas par cas ;
  • on accepte tout par défaut et on bloque au cas par cas.
    La première approche est plus sure mais la seconde peut être plus simple quand le blocage est l’exception.

D’abord, quels sont les noms des interfaces réseau de ce serveur ?

#11

Ce sont les chaines FORWARD qui gèrent ce qui traverse la passerelle.

Par exemple, ce qui rentre par eth0 pour sortir par eth1
iptables -P FORWARD -i eth0 -o eth1 …

Pour bloquer la sortie des machines sur le réseau correspondant à eth0 :
iptables -P FORWARD -i eth0 DROP

Pour bloquer l’accès des machines sur le réseau correspondant à eth0
iptables -P FORWARD -o eth0 DROP

Par exemple :
iptables -P FORWARD -i eth0 -o eth1 ACCEPT
iptables -P FORWARD -i eth0 DROP
Permet de traverser de eth0 vers eth1, mais interdit de eth0 vers eth2

Les règles ressemblent aux règles input et output. Attention, il n’y a pas d’impact/interaction entre “INPUT -i eth0” et “FORWARD -i eth0” (idem pour output).

Pour masquerade, ça sert uniquement lorsque l’adresse est privé et que l’accès se fait à un réseau public.

#12

-P sert à definer la politique par défaut d’une chaîne, c’est-à-dire le sort des paquets (accepté/bloqué) qui atteignent la fin de la chaîne. Pour créer une règle, on utilise -A ou -I.

Une connexion est une communication bidirectionnelle qui implique la transmission de paquets dans les deux sens. Bloquer les paquets dans un sens empêche donc toute communication dans les deux sens. Autoriser les connexions dans un seul sens n’est pas aussi simple ; il faut utiliser le suivi de connexion pour identifier le début d’une connexion.

#13

Merci à tous pour vos réponses

Je préfère de loin la première solution, ça réduit grandement le risque de faille de sécurité.
Je veux donc que eth0 vers eth1 passe mais pas l’inverse.
L’option MASQUERADE me semble aussi importante : les machines qui sont sur le WAN 10.100.0.0/16 (eth1) n’ont pas à connaitre l’adresse IP source.
=> en gros, je veux faire un firewall entre eth0 (LAN) et eth1 (WAN).

Voici où j’en suis mais après quelque tests, ça semble pas fonctionner => eth1 arrive à communiquer avec eth0

[code]#!/bin/bash

###########################

vide les tables

iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -t nat -X
iptables -t mangle -X

echo iptables clear [OK]

#########################

activation du forwarding (laisse passer tous les paquets => ne pas activer)

echo 1 > /proc/sys/net/ipv4/ip_forward

########################

règles de routage

iptables -P FORWARD -i eth0 -o eth1 ACCEPT
iptables -P FORWARD -i eth0 DROP

#######################

pour changer l’adresse IP source

iptables -t nat -A POSTROUTING -s 10.1.0.250 -o eth1 -j MASQUERADE

echo iptables rules created [OK]
[/code]

Par contre j’ai cette erreur :
sudo /etc/init.d/firewall restart

iptables clear [OK] iptables v1.4.14: -X requires a chain and a policy Try `iptables -h' or 'iptables --help' for more information. iptables v1.4.14: -X requires a chain and a policy Try `iptables -h' or 'iptables --help' for more information. iptables rules created [OK]

#14

J’ai fait quelques modif du script pour ne plus avoir de message d’erreur :

… Mais je n’arrive toujours pas à bloquer les connexion de 10.100.0.10 vers eth0

#15

=> Je pense que le problème vient de là… actuellement je pense savoir bloquer chaque sens de communication mais je ne sais comment les passer le paquets de “retour” lorsque que dans le sens retours j’ai créé un règle de blocage de paquets. Comment fait-on exactement ?

#16

En quoi est-ce utile ou souhaitable, du moment que les machines du WAN ont la bonne route pour atteindre l’adresse source ?

Cette phrase ne veut rien dire. eth1 et eth0 ne communiquent pas ensemble, elles sont sur des réseaux distincts.

Les paquets retour sont identifiables par leur état ESTABLISHED ou RELATED. Les paquets aller peuvent aussi avoir cet état quand une connexion est établie, mais le premier paquet a toujours l’état NEW. En n’autorisant que les paquets dans l’état ESTABLISHED ou RELATED dans un sens, on empêche donc les connexions dans ce sens.

Note : Il n’est pas nécessaire de faire du filtrage dans les chaînes INPUT et OUTPUT qui ne sont pas impliquées dans le traitement des paquets retransmis d’une interface à une autre. Ceux-ci ne traversent que la chaîne FORWARD.

#17

Peut être :

Ou 10.100.0.0/24 si tu veux bloquer toutes les machines 10.100.0.XX
Ca induit que les machines connectée du coté eth1 ne pourront pas recevoir de réponse de 10.100.0.10 sauf si tu as mis les règles concernant les communications en cours (cf -m state --state ESTABLISHED,RELATED)

Désolé pour l’erreur “-P”

#18

[quote=“PascalHambourg”]-m state --state ESTABLISHED,RELATED
[/quote]
Merci, c’est ce que je recherchais

#19

J’ai une autre petite question.

Si j’installe un serveur DHCP sur eth1, je suppose qu’il faut configurer quelque chose (je veux que sur le serveur on n’est accès qu’au serveur DHCP… pas d’accès SSH et autre ) ?

#20

Aussi j’aimerai savoir comment avoir les log de ces commandes :

iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
=> j’ai cherché sur le net mais je ne trouve que des méthodes pour d’anciennes versions de iptables (j’utilise la version 1.4.14) : le mot clef LOG ne semble plus reconnu

merci d’avance

#21

-P définit la politique par défaut de la chaîne, le sort appliqué aux paquets qui atteignent la fin de la chaîne. On ne peut pas utiliser la cible LOG comme politique, seulement DROP ou ACCEPT. La cible LOG ne peut s’utiliser que dans des règles, créés avec -A ou -I.

Pour logger les paquets qui arrivent en fin de chaîne, il suffit d’ajouter une règle LOG à la fin de la chaîne.

Concernant la question précédente, je ne vois pas le rapport entre l’installation d’un serveur DHCP et l’accès à SSH.

#22

Merci

[quote=“PascalHambourg”]-P définit la politique par défaut de la chaîne, le sort appliqué aux paquets qui atteignent la fin de la chaîne. On ne peut pas utiliser la cible LOG comme politique, seulement DROP ou ACCEPT. La cible LOG ne peut s’utiliser que dans des règles, créés avec -A ou -I.

Pour logger les paquets qui arrivent en fin de chaîne, il suffit d’ajouter une règle LOG à la fin de la chaîne.

[/quote]
Je n’ai pas bien compris quand tu parles de notion de “chaine” (défaut/fin) : peux-tu m’expliquer exactement ce que c’est ? iptables -A INPUT -j LOG est executé avant ou après iptables -P INPUT DROP ?

[quote=“PascalHambourg”]
Concernant la question précédente, je ne vois pas le rapport entre l’installation d’un serveur DHCP et l’accès à SSH.[/quote]
Vu que par defaut j’ai tout mis en DROP sur l’interface Eth1 : je suppose qu’il y a une règle à définir pour recevoir/emettre les paquets DHCP sur cette interface

#23

Avant. La politique par défaut définie par -P n’est appliquée à un paquet que si ce dernier ne correspond à aucune règle de la chaîne ayant une cible “terminale” (ACCEPT, REJECT, DROP).

En principe oui, mais pour des raisons pratiques les serveurs (et clients) DHCP comme dhcpd communiquent généralement directement avec l’interface réseau sans passer par la pile TCP/IP, court-circuitant iptables.

#24

Merci,

Ok, c’est plus clair.

iptables -P INPUT DROP iptables -A INPUT -j LOG
J’ai un petit doute : donc c’est bien comme ça qu’il faut faire si je veux loguer les paquets bloqués par défaut ? … car je ne vois rien dans le fichier /var/log/kern.log
=> Avant hiers, ma passerelle entre eth0 et eth1 fonctionnait mais depuis hiers ça ne fonctionne plus : la seule chose qu’il me semble avoir modifié, c’est d’avoir installé le serveur DHCP (j’ai aussi redémarré le serveur). Depuis le serveur j’arrive à pinguer les appareils en 10.100.100.0/16 mais plus depuis 10.0.200.0/24 (sur le serveur je vois le ping arriver sur l’interface eth0 via tcpdump mais je ne le vois pas ressortir sur eth1).

[quote=“PascalHambourg”]
En principe oui, mais pour des raisons pratiques les serveurs (et clients) DHCP comme dhcpd communiquent généralement directement avec l’interface réseau sans passer par la pile TCP/IP, court-circuitant iptables.[/quote]
ça va me simplifié les choses mais ça me gène un peu car ça veut dire qu’il ne suffit pas de vérifier la configuration de iptables pour être certains que le serveur est correctement protégé car n’importe qu’elle application peut contourner les règles de iptables.

#25

C’est bon j’ai trouvé d’où venait le problème : j’avais mis en commentaire la ligne suivante

=> donc vu que je n’avais pas redémarré mon PC, la commande était encore active
=> si j’ai bien compris, si cette commande n’est pas activée, toutes les règles de type FORWARD de mon script ne sont pas prises en compte : c’est bien ça ?

Est-ce que tu pourrais vérifier mon script pour être certain que je n’ai pas fait d’autres boulettes (pour moi, il me semble fonctionnel) :

#!/bin/bash

###########################
# vide les tables et bloc le forwarding
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -t nat -X
iptables -t mangle -X
echo 0 > /proc/sys/net/ipv4/ip_forward

echo iptables clear [OK]



########################
# Règles par défaut
# INPUT   : paquet entrant dans la machine
# FORWARD : paquet traversant la machine
# OUTPUT  : paquet générés localement

iptables -P INPUT   DROP
iptables -P OUTPUT  DROP
iptables -P FORWARD DROP

# Même chose que précédemment mais en aillant la gesiton des logs
# => les log sont mis par défaut dans le fichier /var/log/kernel.log 
#iptables -A FORWARD -j LOG


#iptables -P INPUT   ACCEPT
#iptables -P OUTPUT  ACCEPT
#iptables -P FORWARD ACCEPT



#######################
# Règles de routage des paquets à destination de la machine

#interface  loopback
iptables -A INPUT  -i lo   -j ACCEPT
iptables -A OUTPUT -o lo   -j ACCEPT

# interface eth0 (si on ne fait pas ça, on ne peut pas se connecter en SSH sur eth0
iptables -A INPUT  -i eth0 -j ACCEPT 
iptables -A OUTPUT -o eth0 -j ACCEPT


iptables -A OUTPUT -o eth1 -j ACCEPT
#iptables -A INPUT -i eth1 -j ACCEPT


# => n'accepte en entrée que les connexion qui ont été précédemment initialisée par le serveur
iptables -A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT


########################
# règles de routage eth0 vers eth1
# => laisse passer tous les paquets de eth0 vers eth1
iptables -A FORWARD -i eth0      -o  eth1  -j ACCEPT


#####################
# règles de routage eth1 vers eth0
# => laisse passer tous les paquets de  eth1 vers eth0 uniquement si la connexion a  précédemment été ouvert coté eth0
iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT 


########################
# autre règles de routage eth1 vers eth0
# => laisse passer tous les paquets de eth1 vers eth0
#iptables -A FORWARD -i eth1      -o  eth0  -j ACCEPT



#######################
# pour changer l'adresse IP source (fonctionnement standard d un firewall)
# iptables -t nat -A POSTROUTING -s 10.1.0.250 -o eth1 -j MASQUERADE


######################
# activation du forwarding (permet de prendre en compte les règles de forwading)
echo 1 > /proc/sys/net/ipv4/ip_forward


echo iptables rules created [OK]

=> ça te semble correcte ?
=> Pour éviter que le même type de problème réapparaisse, je pense qu’il faudrait que mon script gère les paramètre “start/restart/stop” : quelle est la config que je dois mettre pour le “stop” ? Je pense qu’il faut mettre ça mais j’aimerai la confirmation que c’est bon :

###########################
# vide les tables et bloc le forwarding
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -t nat -X
iptables -t mangle -X
echo 0 > /proc/sys/net/ipv4/ip_forward

##########################
# règles par défaut
iptables -P INPUT   ACCEPT
iptables -P OUTPUT  ACCEPT
iptables -P FORWARD DROP

echo re-initialisation iptables [OK]
#26

Ceux de la chaîne INPUT, oui.

Pa beaucoup, un serveur DHCP ne nécessiterait que deux règles iptables sur l’interface concernée :

[code]# requetes DHCP entrantes
iptables -A INPUT -i eth1 -p udp --sport 68 --dport 67 -j ACCEPT

reponses DHCP sortantes

iptables -A OUTPUT -o eth1 -p udp --sport 67 --dport 68 -j ACCEPT[/code]

Le jeu de règles iptables (et ip6tables si la machine a une connectivité IPv6) n’est jamais suffisant. Les applications clientes et serveur de la machine doivent aussi être à jour pour ne pas contenir de failles connues, correctement sécurisées…

Non, pas n’importe quelle application. Il faut les droits root pour émettre ou recevoir directement sur une interface réseau.

Elles sont prises en compte mais n’ont aucun paquet à se mettre sous la dent is ip_forward=0.

  • La règle LOG en début de chaîne FORWARD va enregistrer tous les paquets routés, pas seulement ceux qui sont bloqués.
  • Certains commentaires sont approximatifs mais les règles me semblent correctes.

C’est à toi de le définir en fonction de ce que tu souhaites, et de la finalité de cette action “stop”. Si c’est pour un script d’init exécuté lors de l’arrêt ou du redémarrage du système, ça ne sert pas à grand-chose. Si c’est pour réinitialiser iptables à sa configuration par défaut (tout à ACCEPT, aucune règle), alors le résultat de ton script diffère puisqu’il met la politique par défaut de la chaîne FORWARD à DROP.

#27

ok merci beaucoup :023

#28

Rebonjour,

J’ai de nouvelles questions.
Pour rappel, archi réseau : cjoint.com/doc/16_02/FBdpY2r3RYT_network.png

J’ai installé une machine virtuelle (VM) en mode bridge sur le serveur : l’adressage IP est actuellement celui-ci

  • eth0 base : 10.1.0.2/16
  • eth1 base : 10.100.0.2/16
  • eth0 VM : 10.1.0.3/16
  • eth1 VM : 10.100.0.3/16
    => la VM est configurée de la même manière que l’OS de base à part que l’on remplace .2 par .3 (la VM et l’OS de base doivent pouvoir avoir accès à toutes les interfaces)
    => je n’ai actuellement pas de script iptables sur la VM
    => sur l’OS de base, j’ai le script iptables décrit précédemment

Le firewall est connecté à ma box internet via un port WAN que l’on ne voit pas sur le schéma
Depuis 10.0.200.72 peut pinguer 10.100.0.10. Mais 10.100.0.10 ne peux pas pinguer 10.0.200.72 (c’est ce que je veux faire)
Depuis 10.0.200.72 peut pinguer 8.8.8.8 (google). Mais 10.100.0.10 ne peux pas pinguer 8.8.8.8 (google) (c’est ce que je veux faire)

Le serveur peut pinguer 8.8.8.8 (google) que ça soit depuis l’OS de base ou de la VM (c’est ce que je veux)
Le serveur peut pinguer 10.100.0.10 depuis l’OS de base
=> le problème est que le serveur ne peut pas pinguer 10.100.0.10 depuis la VM. D’où peut venir le problème ? Il y a une règle iptables à déclarer à quelque part ?

Remarque :

  • pour simplifier le schéma, j’ai nommé la seconde interface réseau eth1 mais en réalité elle s’appelle eth1.1000 (interface eth1 VLAN 1000) car j’ai plusieurs interfaces VLAN de déclarées sur la même carte réseau. Ce n’est pas ça qui pose problème ?
  • j’aimerais installer mon serveur DHCP sur la VM au lieu de l’OS de base (je n’ai pas encore testé si ça fonctionnait vu le problème actuel)

ifconfig (OS de base) :

eth0      Link encap:Ethernet  HWaddr 30:5a:3a:47:a0:1f
          inet adr:10.1.0.2  Bcast:10.1.255.255  Masque:255.255.0.0
          adr inet6: fe80::325a:3aff:fe47:a01f/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5521 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6882 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:375419 (366.6 KiB)  TX bytes:5865175 (5.5 MiB)
          Interruption:44 Adresse de base:0x2000

eth1      Link encap:Ethernet  HWaddr 68:05:ca:3c:f1:f2
          inet adr:10.2.0.2  Bcast:10.2.255.255  Masque:255.255.0.0
          adr inet6: fe80::6a05:caff:fe3c:f1f2/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1315 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1019 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:251902 (245.9 KiB)  TX bytes:107887 (105.3 KiB)
          Interruption:19 Mémoire:f7cc0000-f7ce0000

eth1.1000 Link encap:Ethernet  HWaddr 68:05:ca:3c:f1:f2
          inet adr:10.100.0.2  Bcast:10.100.255.255  Masque:255.255.0.0
          adr inet6: fe80::6a05:caff:fe3c:f1f2/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:0 (0.0 B)  TX bytes:7540 (7.3 KiB)

eth1.1001 Link encap:Ethernet  HWaddr 68:05:ca:3c:f1:f2
          inet adr:10.0.210.2  Bcast:10.0.210.255  Masque:255.255.255.0
          adr inet6: fe80::6a05:caff:fe3c:f1f2/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:0 (0.0 B)  TX bytes:8336 (8.1 KiB)

eth1.1002 Link encap:Ethernet  HWaddr 68:05:ca:3c:f1:f2
          inet adr:10.102.0.2  Bcast:10.102.255.255  Masque:255.255.0.0
          adr inet6: fe80::6a05:caff:fe3c:f1f2/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:0 (0.0 B)  TX bytes:7829 (7.6 KiB)

eth1.1003 Link encap:Ethernet  HWaddr 68:05:ca:3c:f1:f2
          inet adr:10.103.0.2  Bcast:10.103.255.255  Masque:255.255.0.0
          adr inet6: fe80::6a05:caff:fe3c:f1f2/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1315 errors:0 dropped:0 overruns:0 frame:0
          TX packets:769 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:222972 (217.7 KiB)  TX bytes:54923 (53.6 KiB)

eth1.1004 Link encap:Ethernet  HWaddr 68:05:ca:3c:f1:f2
          inet adr:10.104.0.2  Bcast:10.104.255.255  Masque:255.255.0.0
          adr inet6: fe80::6a05:caff:fe3c:f1f2/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:0 (0.0 B)  TX bytes:8336 (8.1 KiB)

lo        Link encap:Boucle locale
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:219 errors:0 dropped:0 overruns:0 frame:0
          TX packets:219 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:12273 (11.9 KiB)  TX bytes:12273 (11.9 KiB)

macvtap0  Link encap:Ethernet  HWaddr 52:54:00:d3:ad:10
          adr inet6: fe80::5054:ff:fed3:ad10/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:296 errors:0 dropped:0 overruns:0 frame:0
          TX packets:153 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:500
          RX bytes:32916 (32.1 KiB)  TX bytes:22113 (21.5 KiB)

macvtap1  Link encap:Ethernet  HWaddr 52:54:00:d4:6b:9a
          adr inet6: fe80::5054:ff:fed4:6b9a/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:500
          RX bytes:0 (0.0 B)  TX bytes:7145 (6.9 KiB)

ifconfig (VM)

eth0      Link encap:Ethernet  HWaddr 52:54:00:d3:ad:10
          inet adr:10.1.0.3  Bcast:10.1.255.255  Masque:255.255.0.0
          adr inet6: fe80::5054:ff:fed3:ad10/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:224 errors:0 dropped:0 overruns:0 frame:0
          TX packets:189 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:20025 (19.5 KiB)  TX bytes:25014 (24.4 KiB)
          Interruption:11 Adresse de base:0x4000

eth1      Link encap:Ethernet  HWaddr 52:54:00:d4:6b:9a
          inet adr:10.2.0.3  Bcast:10.2.255.255  Masque:255.255.0.0
          adr inet6: fe80::5054:ff:fed4:6b9a/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:0 (0.0 B)  TX bytes:3186 (3.1 KiB)

eth1.1000 Link encap:Ethernet  HWaddr 52:54:00:d4:6b:9a
          inet adr:10.100.0.3  Bcast:10.100.255.255  Masque:255.255.0.0
          adr inet6: fe80::5054:ff:fed4:6b9a/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:0 (0.0 B)  TX bytes:468 (468.0 B)

eth1.1001 Link encap:Ethernet  HWaddr 52:54:00:d4:6b:9a
          inet adr:10.0.210.3  Bcast:10.0.210.255  Masque:255.255.255.0
          adr inet6: fe80::5054:ff:fed4:6b9a/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:0 (0.0 B)  TX bytes:468 (468.0 B)

eth1.1002 Link encap:Ethernet  HWaddr 52:54:00:d4:6b:9a
          inet adr:10.102.0.3  Bcast:10.102.255.255  Masque:255.255.0.0
          adr inet6: fe80::5054:ff:fed4:6b9a/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:0 (0.0 B)  TX bytes:468 (468.0 B)

eth1.1003 Link encap:Ethernet  HWaddr 52:54:00:d4:6b:9a
          inet adr:10.103.0.3  Bcast:10.103.255.255  Masque:255.255.0.0
          adr inet6: fe80::5054:ff:fed4:6b9a/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:0 (0.0 B)  TX bytes:846 (846.0 B)

eth1.1004 Link encap:Ethernet  HWaddr 52:54:00:d4:6b:9a
          inet adr:10.104.0.3  Bcast:10.104.255.255  Masque:255.255.0.0
          adr inet6: fe80::5054:ff:fed4:6b9a/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:0 (0.0 B)  TX bytes:468 (468.0 B)

lo        Link encap:Boucle locale
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:784 (784.0 B)  TX bytes:784 (784.0 B)

OS de base > /etc/network/interfaces

# ######################################
auto lo
iface lo inet loopback

# ######################################
auto eth0
iface eth0 inet static
     address 10.1.0.2
     netmask 255.255.0.0
     gateway 10.1.0.250

auto eth1
iface eth1 inet static 
     address 10.2.0.2
     netmask 255.255.0.0



# ######################################
auto eth1.1000
iface eth1.1000 inet static
   address 10.100.0.2
   netmask 255.255.0.0
   vlan-raw-device eth1

auto eth1.1001
iface eth1.1001 inet static
   address 10.0.210.2
   netmask 255.255.255.0
   vlan-raw-device eth1

auto eth1.1002
iface eth1.1002 inet static
   address 10.102.0.2
   netmask 255.255.0.0
   vlan-raw-device eth1

auto eth1.1003
iface eth1.1003 inet static
   address 10.103.0.2
   netmask 255.255.0.0
   vlan-raw-device eth1		

auto eth1.1004
iface eth1.1004 inet static
   address 10.104.0.2
   netmask 255.255.0.0
   vlan-raw-device eth1

VM > /etc/network/interfaces

# ######################################
auto lo
iface lo inet loopback


# ######################################
auto eth0
iface eth0 inet static
   address 10.1.0.3
   netmask 255.255.0.0
   gateway 10.1.0.250

auto eth1
iface eth1 inet static
   address 10.2.0.3
   netmask 255.255.0.0


# ######################################
auto eth1.1000
iface eth1.1000 inet static
   address 10.100.0.3
   netmask 255.255.0.0
   vlan-raw-device eth1

auto eth1.1001
iface eth1.1001 inet static
   address 10.0.210.3
   netmask 255.255.255.0
   vlan-raw-device eth1

auto eth1.1002
iface eth1.1002 inet static
   address 10.102.0.3
   netmask 255.255.0.0
   vlan-raw-device eth1

auto eth1.1003
iface eth1.1003 inet static
   address 10.103.0.3
   netmask 255.255.0.0
   vlan-raw-device eth1

auto eth1.1004
iface eth1.1004 inet static
   address 10.104.0.3
   netmask 255.255.0.0
   vlan-raw-device eth1

J’ai un petit doute : actuellement, dans ma VM j’ai deux carte réseau de déclaré (eth0 et eth1) : il ne faudrait pas que je déclare autant de carte réseau que j’ai de VLAN ?
screenshot de la config de KVM : cjoint.com/c/FBrp3JHFToT

Merci d’avance,