Virtualisation et réseau

[lol]

Salut,
Je suis un peu paumé…

J’essaye de monter une MV (avec virtmanager) mais je n’arrive pas à faire fonctionner le réseau convenablement. Ça se passe sur une squeeze.

Mon objectif :
Que la machine hôte et l’invité puisse accéder au réseau avec chacune leur IP. J’ai pensé faire ça de la manière suivante (je vous donne la config pour une seule interface.

/etc/network/interfaces

[code]allow-hotplug eth0
iface eth0 inet manual

auto br0
iface br0 inet manual
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off
bridge_maxwait 5[/code]

Au démarrage de la machine hôte, j’ai (netstat -ie)

[code]br0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
adr inet6: fe80::213:74ff:fe00:5c38/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:96 errors:0 dropped:0 overruns:0 frame:0
TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:18059 (17.6 KiB) TX bytes:4622 (4.5 KiB)

eth0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
inet adr:192.168.3.232 Bcast:192.168.3.255 Masque:255.255.252.0
adr inet6: fe80::213:74ff:fe00:5c38/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:117 errors:0 dropped:0 overruns:0 frame:0
TX packets:79 errors:0 dropped:0 overruns:0 carrier:3
collisions:0 lg file transmission:1000
RX bytes:22259 (21.7 KiB) TX bytes:16216 (15.8 KiB)
Mémoire:dffc0000-e0000000 [/code]

J’ai bien du réseau sur la machine hôte.
Au démarrage de la machine virtuelle, une nouvelle interface vient s’ajouter :

vnet0 Link encap:Ethernet HWaddr fe:54:00:54:0d:db adr inet6: fe80::fc54:ff:fe54:ddb/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:500 RX bytes:0 (0.0 B) TX bytes:3800 (3.7 KiB)

J’ai du réseau sur la machine virtuelle, mais plus rien sur la machine hôte…

La machine virtuelle utilise comme Périphérique source pour le réseau : Périphérique Hôte eth0 (Pont ‘br0’)

Je ne comprend pas bien comment ça fonctionne en fait…

J’ai fait des dizaines de tutos sur le net, mais chacun y va de sa soupe, et ça ne fonctionne pas chez moi. Si quelqu’un pouvait m’expliquer comment parvenir à avoir du réseau sur l’hôte et l’invité…

Edit : J’ai essayé en ajoutant ceci :

pre-up tunctl -u lol -t tap0 bridge_ports eth0 tap0

Rien de concluant…

[PascalHambourg]

Remarque : c’est le pont (br0) qui devrait avoir l’adresse IP, pas l’interface pontée (eth0).

[lol]

Merci,

Il faut fixer l’IP dans le fichier interfaces de l’hôte ?

[lol]

Bien, je ne comprend pas.

Je pensais que c’était auto eth0 qui posait un problème, mais non…

pour eth0 j’ai juste :

iface eth0 inet manual

Et il prend quand même une ip
Si je met “static” j’ai bien sur une erreur…
Ne rien mettre du tout ?

[lol]

Du mieux… wicd était installé (il est installé par défaut avec xfce…).

Mais je perd toujours le réseau sur l’hôte au moment ou l’invité démarre…

C’est normal ?
Comment faire pour que hôte et invité aient du réseau ?

Merci

[PascalHambourg]

Il faut fixer l’IP dans le fichier interfaces de l’hôte ?

Peu importe comment. L’important est que l’adresse soit sur br0, pas eth0.

Pour eth0, il me semble qu’il n’est pas nécessaire de la définir dans le fichier interfaces. Comme elle est dans l’option bridge-ports, le script de bridge-utils devrait l’activer automatiquement. Par contre il ne faut pas qu’elle soit configurée par autre chose comme wicd.

Recherche les différences sur l’hôte entre avant et après le démarrage de l’invité dans l’état du pont (brtcl show), les routes (route -n), les interfaces (ifconfig -a). Et vérifie que l’invité n’a pas la même adresse que l’hôte.

[lol]

Re,

brctl show

Avant :bridge name bridge id STP enabled interfaces br0 8000.001374005c38 no eth0 br1 8000.00e04ceb7283 no eth1
Après :bridge name bridge id STP enabled interfaces br0 8000.001374005c38 no eth0 vnet0 br1 8000.00e04ceb7283 no eth1 vnet1
route -n

Avant:Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.252.0 U 0 0 0 br1 0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 br1
Après :Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.252.0 U 0 0 0 br1 0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 br1

ifconfig -a

Avant:[code]br0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
adr inet6: fe80::213:74ff:fe00:5c38/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:100 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:17972 (17.5 KiB) TX bytes:4732 (4.6 KiB)

br1 Link encap:Ethernet HWaddr 00:e0:4c:eb:72:83
inet adr:192.168.3.239 Bcast:192.168.3.255 Masque:255.255.252.0
adr inet6: fe80::2e0:4cff:feeb:7283/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:674 errors:0 dropped:0 overruns:0 frame:0
TX packets:602 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:414758 (405.0 KiB) TX bytes:80004 (78.1 KiB)

eth0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
adr inet6: fe80::213:74ff:fe00:5c38/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:104 errors:0 dropped:0 overruns:0 frame:0
TX packets:51 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 lg file transmission:1000
RX bytes:19736 (19.2 KiB) TX bytes:9066 (8.8 KiB)
Mémoire:dffc0000-e0000000

eth1 Link encap:Ethernet HWaddr 00:e0:4c:eb:72:83
adr inet6: fe80::2e0:4cff:feeb:7283/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:679 errors:0 dropped:0 overruns:0 frame:0
TX packets:625 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:424608 (414.6 KiB) TX bytes:84572 (82.5 KiB)
Interruption:17 Adresse de base:0x2800[/code]

Après:[code]
br0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
adr inet6: fe80::213:74ff:fe00:5c38/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:150 errors:0 dropped:0 overruns:0 frame:0
TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:26714 (26.0 KiB) TX bytes:5472 (5.3 KiB)

br1 Link encap:Ethernet HWaddr 00:e0:4c:eb:72:83
inet adr:192.168.3.239 Bcast:192.168.3.255 Masque:255.255.252.0
adr inet6: fe80::2e0:4cff:feeb:7283/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:721 errors:0 dropped:0 overruns:0 frame:0
TX packets:611 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:423452 (413.5 KiB) TX bytes:81554 (79.6 KiB)

eth0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
adr inet6: fe80::213:74ff:fe00:5c38/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:321 errors:0 dropped:0 overruns:0 frame:0
TX packets:171 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 lg file transmission:1000
RX bytes:43882 (42.8 KiB) TX bytes:20854 (20.3 KiB)
Mémoire:dffc0000-e0000000

eth1 Link encap:Ethernet HWaddr 00:e0:4c:eb:72:83
adr inet6: fe80::2e0:4cff:feeb:7283/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:722 errors:0 dropped:0 overruns:0 frame:0
TX packets:638 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:433660 (423.4 KiB) TX bytes:86440 (84.4 KiB)
Interruption:17 Adresse de base:0x2800

vnet0 Link encap:Ethernet HWaddr fe:54:00:54:0d:db
adr inet6: fe80::fc54:ff:fe54:ddb/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:116 errors:0 dropped:0 overruns:0 frame:0
TX packets:226 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:500
RX bytes:11048 (10.7 KiB) TX bytes:27030 (26.3 KiB)

vnet1 Link encap:Ethernet HWaddr fe:54:00:2b:88:10
adr inet6: fe80::fc54:ff:fe2b:8810/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:500
RX bytes:300 (300.0 B) TX bytes:12062 (11.7 KiB)[/code]

Sur l’ĥote quand l’invité est démarré :
J’ai accès à toutes les machines du réseau local, sans problème.
Je ne perd pas complètement le réseau (vers Internet), mais la connexion est très mauvaise…

ping google.com PING google.com (74.125.43.104) 56(84) bytes of data. 64 bytes from bw-in-f104.1e100.net (74.125.43.104): icmp_req=1 ttl=47 time=273 ms ^C --- google.com ping statistics --- 9 packets transmitted, 1 received, 88% packet loss, time 17338ms rtt min/avg/max/mdev = 273.928/273.928/273.928/0.000 ms

Par contre l’invité à accès à tout et est vu par toutes les machines du lan.
Un truc (plein en fait…) m’échappe…

Une question : Le fait que les deux interfaces de l’invité soient connectées physiquement sur le même réseau peut être à l’origine du problème ?
IP de l’invité :
192.168.1.254 sur eth0 (vnet0)
192.168.3.237 sur eth1 (vnet1)

192.168.0.254 c’est la passerelle actuellement en fonction.

Merci de ta patience.

[lol]

…Une question : Le fait que les deux interfaces de l’invité soient connectées physiquement sur le même réseau peut être à l’origine du problème ?..

C’était ça…

[lol]

Merci de ton aide PascalHambourg.

J’avais oublié ce point essentiel : brancher deux interfaces de la même machine sur le même réseau physique est une connerie…

Edit: tu avais rectifié - les deux interfaces de l’hôte pas de l’invité.

[PascalHambourg]

Je m’en doutais, parce que parler de connexion physique pour une machine virtuelle… Ceci dit ce n’est pas la connexion physique (couche 1) qui compte, mais la connexion “logique” (couche 2) à un même réseau ou domaine de broadcast, incluant les ponts et liens virtuels.

En fait normalement ce n’est pas forcément gênant d’avoir deux interfaces indépendantes (c’est à dire pas pontées ou agrégées ensemble) connectées au même réseau et actives simultanément, à condition de prendre certaines précautions comme désactiver rp_filter sur celles-ci. Simplement ça ne sert pas à grand chose : pour une destination donnée la machine émet toujours avec la même et les autres machines émettent soit vers l’une soit vers l’autre.

Juste par curiosité, c’était quoi le but de cette topologie avec deux ponts reliés d’une part au même réseau et d’autre part à la même machine virtuelle ?

[lol]

Salut,

…Juste par curiosité, c’était quoi le but de cette topologie avec deux ponts reliés d’une part au même réseau et d’autre part à la même machine virtuelle ?

La machine n’est pas à son emplacement définitif, je suis en train de la monter.
Elle est destinée à servir de passerelle/routeur/pare-feu, une interface connectée à Internet et l’autre au lan.

Les services de l’hôte ne seront accessible que par depuis le lan.

J’ai eu besoin d’une connexion internet pour l’invité, et plutôt que de toucher aux routes, j’ai choisi de connecter la première interface. Évidemment c’est ce qui à causé les problèmes dans l’hôte…

[lol]

Salut,
Une dernière question me tarabuste…

Du point de vue d’iptables, inutile que je m’occupe de l’interface eth0 ou br0, puisqu’elles ne sont pas configurées ?

Mais br0 dispose bien d’un adresse ipv6… Cela a-t-il une incidence sur la sécurité ? Cette adresse est-elle visible et accessible depuis l’extérieur ?

[code]netstat -ie
Table d’interfaces noyau
br0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
adr inet6: fe80::213:74ff:fe00:5c38/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:3905 (3.8 KiB)

eth0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:2
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Mémoire:dffc0000-e0000000[/code]

[PascalHambourg]

Du point de vue d’iptables, inutile que je m’occupe de l’interface eth0 ou br0, puisqu’elles ne sont pas configurées ?

Qu’entends-tu exactement par “inutile que je m’occupe” ? Inutile de bloquer les paquets ou inutile de les accepter ?
En fait dans un cas ou dans l’autre ce n’est pas si simple.

1. Même sans avoir de configuration IP, une interface est quand même liée à la pile IP du noyau. Si elle n’est associée à aucune route elle n’émet pas de paquets IP ni de requêtes ARP, mais par défaut elles peut répondre à des requêtes ARP pour n’importe quelle adresse de la machine configurée sur une autre interface et recevoir des paquets IP. Dans le cas d’une interface pontée (eth0), les paquets reçus sont interceptés et traités comme s’ils étaient reçus par l’interface du pont (br0). Donc la pile IP ne verra rien entrer par eth0 directement car elle est pontée, mais pourra voir du trafic entrer par l’interface du pont br0 même si elle n’a pas de configuration IP.

2. Le pontage ethernet dispose d’une fonctionnalité optionnelle appelée bridge-nf qui permet à une trame passant par un pont et contenant un paquet IP/ARP/IPv6 d’être traitée par iptables/arptables/ip6tables (et pour faire simple je ne parle pas des trames VLAN et PPPoE). Cette fonctionnalité est activée par défaut. Dans ce cas, les paquets IP des trames devant traverser un pont doivent être acceptés par la chaîne FORWARD d’iptables. Voir les options de la correspondance physdev d’iptables pour les options fines. On peut aussi désactiver ce filtrage en réglant le sysctl net.bridge.bridge-nf-call-iptables (/proc/sys/net/bridge/bridge-nf-call-iptables) à 0.
   Cf. le diagramme dans la page de Wikipédia consacrée à iptables. La partie sur fond bleu représente la traversée des chaînes ebtables et iptables par un paquet entrant ou sortant par une interface pontée.

Mais br0 dispose bien d’un adresse ipv6… Cela a-t-il une incidence sur la sécurité ? Cette adresse est-elle visible et accessible depuis l’extérieur ?

C’est une adresse en fe80 de type “link local”, dont la portée est limitée au réseau local (domaine de diffusion) et accessible depuis les machines directement connectées à celui-ci. Tu peux désactiver l’émission et la réception de paquets IPv6 sur une interface en réglant le sysctl net.ipv6.conf..disable_ipv6 à 1.

[lol]

Merci pour les précisions.

Quand je disais inutile de m’en occuper, je pensais : inutile de bloquer, mais je vois bien qu’il y a une couche qu’iptable (couche matérielle) ne peut pas contrôler. Je suppose que c’est par là que passent les paquets destinés à dhcp ?

Pas évident cette histoire de couche et de pile…
De ce que j’en ai compris, par précaution je vais désactiver ipv6 sur br0 car je ne suis pas certain de maîtriser le contrôle des paquets…

J’ai réussi et à peu près compris mon histoire de pont et de machine virtuelle.
Je suis un peu paumé avec iptables.

Je vais avancer doucement et faire des essais. La machine est prête à entrer en fonction", mais il me faut impérativement régler cette histoire de sécurité…

[PascalHambourg]

Je comprends ta difficulté, ayant passé pas mal de temps et fait un certain nombre de tests pour bien comprendre l’interaction entre iptables et le pontage, avec et sans bridge-nf.

Pour ce qui nous concerne, il y a deux couches : la couche basse “liaison” (ethernet) et la couche haute “réseau” (IP, ARP, IPv6). Le pontage ethernet se situe dans la couche liaison, la pile IP se situe dans la couche réseau. Normalement netfilter et iptables fonctionnent dans la couche réseau et traitent les paquets qui passent par la pile IP, mais avec bridge-nf ils peuvent “descendre” dans la couche liaison et traiter les paquets IP qui passent par un pont avant ou sans que ceux-ci atteignent la pile IP.

Un pont, c’est comme un switch ethernet logiciel dont les ports seraient connectés d’une part aux interfaces ethernet physiques ou virtuelles pontées (ethX, tapX, vnetX…) et d’autre part à l’interface du pont (brX). Tout cela se passe dans la couche liaison, et la pile IP ne communique que via l’interface du pont et non via les interfaces pontées.

Si net.bridge.bridge-nf-call-iptables=0, alors iptables n’est appelé que depuis la pile IP, c’est-à-dire la couche réseau, et ne traite pas les paquets pontés, c’est-à-dire qui traversent un pont directement d’une interface pontée à une autre. Tout se passe comme si le pont était un switch extérieur à l’hôte, connecté à lui par l’interface du pont brX.

Si net.bridge.bridge-nf-call-iptables=1 (la situation par défaut) cela ce complique. En effet les chaînes PREROUTING, FORWARD et POSTROUTING d’iptables traitent aussi les paquets IP pontés. L’interface d’entrée et de sortie vue d’iptables est l’interface du pont (brX) et non l’interface pontée par laquelle le paquet entre ou sort.
La correspondance physdev permet de filtrer en fonction du “port” (interface pontée) d’entrée et/ou de sortie.

Donc si tu ne veux pas que le filtrage d’iptables s’applique aux paquets IP pontés, le plus simple est AMA de désactiver net.bridge.bridge-nf-call-iptables. Sinon une alternative est d’accepter les paquets ponté dans la chaîne FORWARD (-A FORWARD -m physdev --physdev-is-bridged). Il faut néanmoins souligner que si net.bridge.bridge-nf-call-iptables=1 le suivi de connexion et les règles de NAT s’appliquent aussi aux paquets pontés, ce qui n’est pas forcément souhaitable.

La situation des paquets DHCP est un peu particulière. Pas dans leur traitement par iptables ou le pontage mais par les démons DHCP, clients ou serveurs. En effet ceux-ci communiquent directement avec l’interface ethernet (entre la couche liaison et la couche réseau) et non à travers la pile IP, court-circuitant de fait les règles iptables. C’est pourquoi on peut observer qu’un client ou un serveur DHCP fonctionne même lorsque les règles iptables bloquent les paquets DHCP. bridge-nf vient un peu perturber cela en filtrant non pas au niveau (pile IP) réseau mais au niveau liaison.

Si tu ne veux pas de communication en IPv6 sur une interface, tu as le choix entre désactiver IPv6 sur celle-ci avec le sysctl comme indiqué précédemment, ou bloquer les paquets avec ip6tables.

[lol]

Merci pour les explication et les solutions.
Je vais bien sur aller au plus simple (pour l’instant).

1. Désactiver l’IPV6 sur eth0
2. Considérer que je n’ai pas à filtrer entre eth0 et le pont (br0), je n’agirais que sur le pont avec iptables.

J’ai tenté de désactiver ipv6 sur br0 (le pont) sans succès. Sur eth0 c’est bon.

net.ipv6.conf.eth0.disable_ipv6 = 1 net.ipv6.conf.br0.disable_ipv6 = 1

En fouillant sur le net j’ai trouvé d’autres directives qui concernent la désactivation du "bridge filtering :

net.bridge.bridge-nf-call-arptables = 0 net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-filter-vlan-tagged = 0

Je ne suis pas sur que la dernière soit bien nécessaire dans mon cas.

J’ai fait un petit schéma pour y voir plus clair :

[code]

---

| _______________________________ |
|00:13:74:00:5c:38 fe:54:00:de:0e:6b 52:54:00:de:0e:6b | |
eth0 <------> br0 <------------> vnet0 <-------> re0 | |
| || |
|______________________________________|[/code]

eth0 et br0 ont bien la même adresse mac, mais je ne m’explique pas que les deux adresses mac de la VM aient un “indicatif” différent…

vnet est une interface crée par virt-manager et re0 est le nom de l’interface dans la vm (pfsense) - c’est la seule interface de cette chaine qui ait une ip, l’hôte devra passer par la VM pour accéder au net (via br1 > vnet1 > re1 > re0 > vnet0 > eth0…)

J’espère que j’ai bon… Ça à l’air de fonctionner… Je pousse mes tests demain!

[PascalHambourg]

J’ai tenté de désactiver ipv6 sur br0 (le pont) sans succès.

C’est-à-dire ?
Si tu as ajouté ces lignes dans /etc/sysctl.conf ou un fichier /etc/sysctl.d/*.conf, il faut faire attention au séquencement : au démarrage ces fichiers sont lus par le script procps qui est exécuté avant le script networking qui crée le pont et les sysctls correspondants. A la place tu peux utiliser une option up dans la définition de br0 dans le fichier /etc/network/interfaces. L’interface eth0 est créée par le pilote du contrôleur ethernet qui est chargé par udev dont le script s’exécute avant procps, mais attention, dans certains cas l’asynchronisme d’udev peut faire qu’eth0 n’existe pas encore non plus donc je recommanderais la même solution que pour br0 pour plus de sûreté.

En fouillant sur le net j’ai trouvé d’autres directives qui concernent la désactivation du "bridge filtering :

Attention, même problème que ci-dessus : ces paramètres n’existent que si le module bridge est chargé, ce qui se produit automatiquement lors de la création du premier pont par le script networking, donc après procps. Tu peux ajouter le nom du module dans /etc/modules pour qu’il soit chargé avant par le script module-init-tools.

Je ne suis pas sur que la dernière soit bien nécessaire dans mon cas.

En effet si tous les bridge-nf-call-*tables sont désactivés, alors celui-ci (ainsi que bridge-nf-filter-pppoe-tagged concernant les trames PPPoE) devient sans objet puisqu’il agit comme un ET logique avec les précédents : passer les trames VLAN à iptables SI bridge-nf-call-iptables ET bridge-nf-filter-vlan-tagged sont à 1.

eth0 et br0 ont bien la même adresse mac, mais je ne m’explique pas que les deux adresses mac de la VM aient un “indicatif” différent…

Par défaut, l’interface d’un pont (ici br0) prend automatiquement la plus petite adresse MAC de ses interfaces pontées, donc ici celle d’eth0 < celle de vnet0. Les adresses MAC de vnet0 et re0 sont différentes car ce sont deux interfaces distinctes, il faut les voir comme reliées par un lien ethernet point à point virtuel. On peut noter qu’elles sont de type “locally administered” (second bit de poids faible du premier octet (U/L) à 1) contrairement à l’adresse MAC d’eth0 qui est de type “globally unique” (second bit de poids faible du premier octet à 0) puisqu’attribuée par le fabricant. On peut noter également que l’adresse MAC de vnet0 est choisie avec un premier octet de valeur maximum 0xfe (le bit de poids faible (G/I) devant rester à 0 pour une adresse unicast) afin qu’elle soit toujours supérieure à une adresse MAC matérielle et ne modifie pas l’adresse MAC du pont lorsque l’interface virtuelle y est ajoutée.

[lol]

Re,

J’ai encore du chemin à faire… Mais j’ai réussi à désactiver l’ipv6 sur eth0 et br0 (apparemment le “séquencement” est bon) :

[code]br0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:471858 errors:0 dropped:0 overruns:0 frame:0
TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:21737967 (20.7 MiB) TX bytes:840 (840.0 B)

eth0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:474911 errors:0 dropped:0 overruns:0 frame:0
TX packets:1616 errors:0 dropped:0 overruns:0 carrier:2
collisions:0 lg file transmission:1000
RX bytes:28600258 (27.2 MiB) TX bytes:146324 (142.8 KiB)
Mémoire:dffc0000-e0000000[/code]

Toutes les interfaces fonctionnent.
J’ai du ajouter une règle forward pour pouvoir accéder à la VM depuis le lan (br1) ça signifie (selon moi) que j’ai un début de protection ?

iptables -S -P INPUT DROP -P FORWARD DROP -P OUTPUT ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT ! -i br0 -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -p tcp -m tcp --dport 465 -j ACCEPT -A FORWARD -i br1 -j ACCEPT

Comme toujours la règle ESTABLISHED ne facilite pas les essais…
En enlevant “ESTABLISHED” ce ne serait pas plus facile pour les tests ?

Y’a plus qu’a me mettre en condition réelle et tester…

Merci de tes précieuses explications (et en Français c’est tellement plus facile…)

Je remarque que plus j’avance dans un début de compréhension du fonctionnement du réseau, d’iptables et des protocoles… et moins c’est clair…

[PascalHambourg]

Ta règle ESTABLISHED est dans la chaîne INPUT, qui ne concerne que les paquets destinés à la machine et pas les paquets pontés.

Tu as vérifié que sysctl net.bridge.bridge-nf-call-iptables renvoie bien 0 ?

[lol]

Salut,
J’ai pas mal bricolé, ça me prend tout mon temps cette histoire…
J’ai mis en place une connexion ppp (via une connexion edge sur usb partagé) pour les réglages et essais. Je ne peux malheureusement pas couper ma connexion filaire (le wiki est dessus…).

[quote=“PascalHambourg”]Ta règle ESTABLISHED est dans la chaîne INPUT, qui ne concerne que les paquets destinés à la machine et pas les paquets pontés.[/quote]Oui, j’ai commencé par me donner un accès à la “VM”.

[quote=“PascalHambourg”]Tu as vérifié que sysctl net.bridge.bridge-nf-call-iptables renvoie bien 0 ?[/quote] /proc/sys/net/bridge/bridge-nf-call-arptables iptables et ip6tables renvoient tous les trois… 1
Pourtant eth0 n’a pas d’adresse ipv6 ??? Je suppose finalement que c’est le bridge qui cause ça, et non moi…

[code]br0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
adr inet6: fe80::213:74ff:fe00:5c38/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:3800 (3.7 KiB)

eth0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:2
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Mémoire:dffc0000-e0000000
[/code]

Il faut donc que je trouve une solution…

• le up dans le fichier interfaces
• désactiver l’ipv6 sur toutes les interfaces par grub
• ip6tables… mais je ne sais même pas quel paquet installer, alors je ne te dit pas pour le configurer…