La chaîne est appelée dans la règle suivante qui se déclenche quelles que soient l’interface d’entrée, l’adresse source et l’adresse destination.
Bonjour,
Vieux post, mais toujours d’actualité !
Un peu newbie sur Ubuntu (mes connaissances Linux remontent à une RedHat 6 en mode “KGraphique”)
Ma topo est la suivante :
[FreeBox Server{Bridge}]<---->eth1°[Ubuntu Server]°eth0 {192.168.1.1}<---->[switch]<--->FreePlayer {192.168.1.50}
<--->PC1 {192.168.1.51}
<--->PC2 {192.168.1.52}
<--->PC3 {DHCP}
<--->PC4 {DHCP}Le but du jeu étant à terme d’avoir sur ce serveur (virtualisé VM-WAre)
- un serveur ICS : faisant office de de Firewall, DHCP, DNS, Contrôle parental (Squid), … bref la porte “controlée” Internet
- un NAS (Xpenology), histoire d’avoir un accès centralisé aux données @home
- Plus tard d’autres VM selon les besoins…
j’ai fini par réussir à monter la VM ICS proprement, et çà commence à bien tourner 
Par contre j’ai un problème du côté du FreePlayer qui ne veux plus recevoir le réseau 
(icône défaut réseau affiché)
En surfant un peu, j’ai fini par comprendre qu’il y avait un VLAN 100 la dessous, mais VLAN est une notion nouvelle pour moi 
Je n’ai pas la possibilité de tirer un câble réseau entre les deux Freebox, et je ne vois pas pourquoi les paquets ne pourraient pas passer par ce serveur Ubuntu.
Je suis donc tombé sur plusieurs forums dont celui-ci ou j’ai bêtement tenté la config suivante dans /etc/network/interfaces/, mais sans succès pour la liaison Server/Player 
:
# WAN FreeBox Server Bridge
auto eth1
iface eth1 inet dhcp
# LAN
auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
post-up iptable-restore < /etc/monscript
#Bridge Pour le VLAN Free
auto eth0.100
iface eth0.100 inet manual
auto eth1.100
iface eth1.100 inet manual
auto br0
iface br0 inet manual
bridge_ports eth0.100 eth1.100
bridge_stp off
bridge_maxwait 0
post-up sysctl -w net.bridge.bridge-nf-call-iptables = 0Si une âme charitable pourvait donc m’aider à mettre en place cette configuration d’une manière simple, élégante et sans faille de sécurité je lui en serait très reconnaissant.
Merci d’avance pour votre aide !
Pascal qui perd de sa splendeur en utilisant un smiley 
Ne me dites pas qu’il suffit de supprimer ces quelques lignes pour que cela fonctionne 
auto eth0.100
iface eth0.100 inet manual
auto eth1.100
iface eth1.100 inet manualQu’il suffit simplement de laisser çà :
auto br0
iface br0 inet manual
bridge_ports eth0.100 eth1.100
bridge_stp off
bridge_maxwait 0
post-up sysctl -w net.bridge.bridge-nf-call-iptables = 0Je fais l’essai dès ce soir…
Essai non concluant 
On constate effectivement qu’il est inutile de configurer les vlan au préalable.
un brctl show le montre bien
bridge name bridge id STP Enabled Interfaces
br0 8000.000abcdefxxx no eth0.100
eth1.100en ifconfig, toutes les interfaces sont montées.
Le trafic internet passe bien depuis les PC, mais le FreePlayer reste toujours en erreur réseau (deux icones réseau qui clignotent en bas à droite de la mire) 
Le “post-up sysctl -w net.bridge.bridge-nf-call-iptables = 0” est bien censé ne par faire passer le pont par iptables ?
Est-il nécessaire de créer une règle ebtables, ou le pont se charge par défaut de router le traffic.
Que dois-je vérifier pour être sur de ne pas être passé à côté d’un truc ?
Merci d’avance pour votre aide !
Deux remarques :
- Méfiance avec les VLAN et les machines virtuelles. En effet on est tributaire de la gestion des paquets taggés IEEE 802.1Q par la machine hôte et par le système de virtualisation. Il faudrait vérifier s’il y a du trafic taggé sur les différentes interfaces : physiques, virtuelles, ponts…
- Si le freeplayer est dans un VLAN séparé du reste du LAN, ne devrait-il pas avoir une adresse IP dans un réseau IP distinct ?
Merci PascalHambourg pour ces remarques très pertinentes 
N’étant pas un as ubuntu, je ne sais pas trop comment vérifier qu’il y a du trafic vlan 100, mais quelques commandes simples (tirées du fond de ma mémoire) du genre tcpdump sur toutes les interfaces ne me montre rien du genre 
Je vais donc aller jeter un œil du côté de la configuration VMWare pour voir s’il n’y a pas quelque chose à faire pour faire passer ces paquets taggués directement entre les deux cartes réseau physiques ou pour que Esxi le fasse vis à des interfaces réseau de la VM “ICS”…
Si qqun à des astuces avant que je ne passe des heures à la google-isation 
Pour le 2), vis à vis de l’IP je ne sais pas ce qui est prévu côté protocole Free.
Je comptais donc sur une automatisation des opérations physiques réseaux entre machines 
Je pensais que leur communication directe entre VLAN était suffisante, vu que n’importe quel périphérique “habituel” CPL, Wifi, Switch semblait faire le relais.
Mais c’est trop se reposer sur la simplicité à laquelle nous avons trop tendance à nous habituer de nos jours… Merci “Pomme” et “Fenêtres” 
Je vais donc me ressortir les doigts… pardonnez-moi l’expression 
après tant d’années de souris…
et essayer de trouver une solution à ce problème qui parait trivial mais qui ne l’est pas 
[quote=“PascalHambourg”]Deux remarques :
- Méfiance avec les VLAN et les machines virtuelles. En effet on est tributaire de la gestion des paquets taggés IEEE 802.1Q par la machine hôte et par le système de virtualisation. Il faudrait vérifier s’il y a du trafic taggé sur les différentes interfaces : physiques, virtuelles, ponts…
[/quote]
Bingo !
Aucun trafic sorti de Esxi (testé avec tcpdump) sur les VLAN 100.
En me penchant un peu sur WMWare (newbie too), on voit que par défaut il ne se préoccupe pas des VLAN.
Deux possibilités, soit ajouter des NIC spécifiques pour les les VLAN taggés, soit faire passer tous les VLAN à la VM (ID VLAN tous = 4095).
J’ai testé les deux avec soit eth2 et eth3 avec des NIC dédiées sur le VLAN100, ou bien avec eth0.100 et eth1.100 dans le cas ou je laisse passer tous les VLAN à la VM.
Et là magie avec tcpdump on voit du traffic sur br0, eth0.100, et eth1.100 
Je suis donc resté avec mon br0 entre eth0.100 et eth1.100, mais le FreePlayer ne veut toujours rien savoir
Avec tcpdump je vois des requêtes passer du genre :
ARP, Request who-has 192.168.27.1 tell 192.168.27.14
{mac-address}(oui unknwown) > Broadcast, ethertype Unknown (0x0802)
Il semble donc y avoir des IP d’un autre sous réseau que mon 192.168.1.X
Cà progresse donc , prochaine étape pour essayer de solutionner ce problème ?
Tcpdump sur quelle interface ?
Suivre le chemin de ces requêtes ARP sur toutes les interfaces concernées pour voir si elles ressortent bien de l’autre côté, et par la même occasion voir si les réponses ARP entrent mais ne ressortent pas. Est-il possible de faire une capture de paquets directement sur la machine physique ?
Merci PascalHambourg.
J’avoue que ce sujet commence à dépasser mes compétences 
Les tcpdump ont été fait sur eth0.100 et eth1.100, des deux côtés j’ai ces réponses en boucle :
ARP, Request who-has 192.168.27.1 tell 192.168.27.14
{mac-address}(oui unknwown) > Broadcast, ethertype Unknown (0x0802)Ce que je ne comprends pas c’est d’où viennent ces IP en 192.168.27.X (alors que tout est censé être en 192.168.1.X)
En tout cas le paramétrage WMWare Esxi 5.1 a ouvert quelques chose, puisque auparavant je n’avait rien avec tcpdump.
Du côté de l’hôte Esxi, j’était en VLAN(0) donc aucun, je laisse passer maintenant VLAN(4095) qui d’après la documentation VMWare laisse les Tags de VLAN en l’état pour tous les VLAN. Du côté de périphérique réseau j’utilise les cartes VMXNET3.
Depuis vShpere, je n’ai aucun moyen (à ma connaissance) d’exécuter des commandes.
Un petit schéma pour illustrer…
Je cherche “simplement” à matérialiser les liens en pointillés Roses (via ICS Ubuntu) ou Jaunes (si VMWare le permet)
Je ne dois tout de même pas être le seul à chercher à faire çà en ayant la simple information que les deux box dialoguent sur un VLAN taggé 100 (pointillé rouge) ?
[A part ceux qui peuvent mettre un câble direct ou un CPL entre les deux box, mais là j’ai des contraintes physiques qui m’en empêche !]
Y’a vraiment un truc qui ne passe pas !
Même manuellement via :
vconfig add eth0 100
vconfig add eth1 100
brctl addbr br0
brctl addif br0 eth0.100
brctl addif br0 eth1.100
ifconfig eth0.100 up
ifconfig eth1.100 up
ifconfig br0 upMême résultat que via /etc/network/interfaces/…
Quand je fais des tcpdump sur eth1.100, eth0.100 ou br0, j’ai ce type de retour.
L’adresse MAC correspond visiblement à celle du FreePlayer
Que puis-je faire pour faire dialoguer ces deux boites noires correctement sur ce VLAN 100 entre deux NIC, on m’avait dit que Nunux était plus “simple” que Zindow$ 
Je viens de faire le tour de Esxi pour laisser passer tous les VLAN à tous les niveaux, voilà un résumé de l’hôte :
Et toujours rien côté FreePlayer 
Je ne sais plus quoi faire… La balle est-elle dans le camp VMWare ou Ubuntu ?
Que dois-je tester et comment faire pour vérifier où passent ces paquets taggués VLAN100 ?
Tu pourrais tester directement sur une machine physique sans VMware pour voir.
L’idée est bonne, elle permettrait de mieux cibler d’où vient le problème !
Mais je n’ai malheureusement pas d’autre machines physiques sous la main,
et par forcément l’envie de tout redéfaire sur cette machine toute neuve 
Il n’y a vraiment pas moyen suivre ce trafic VLAN pour savoir d’où il vient à quoi il ressemble et ou il va ou ne va pas ?
Je ne connais que tcpdump -i, il y a bien autre chose qui existe sous Ubuntu non ?
Pas moyen de lancer un système live sur cette machine ?
Bonjour,
Je me permets de prendre part à la discussion, car j’ai une configuration très similaire et j’ai réussi à faire ce que je voulais. Voici comment je fonctionne :
[mono]Internet – Freebox V5 mode bridge – Ubuntu server – switch – freeplayer + autres PC[/mono]
J’ai donc également Ubuntu Server (12.04), que j’utilise par contre pour la virtualisation KVM.
Première étape : J’ai commencé par faire un bridge appelé ‘BR100’ contenant eth0.100 et eth1.100 et ça a marché direct !!
Le player voit ma freebox via un simple bridge linux sur ma machine physique.
Seconde étape : j’ai voulu faire monter tous ces tags dans mon pare-feu PfSense virtuel…
C’est là que ça se complique ^^
Afin de créer des cartes virtuelles pour mon PfSense, j’ai monté deux bridges différents sur la machine physique :
- BR0 contenant eth0.100
- BR1 contenant eth1.100
J’ai ensuite ajouté deux nouvelles cartes réseaux virtuelles à mon PfSense virtuel (de la même manière qu’avec Vmware).
Dans PfSense, j’ai affecté ces deux nouvelles cartes comme suit :
- WAN_v100
- LAN_v100
et j’ai monté un bridge PfSense sur ces deux-là (oui, tout ca dans un pare-feu virtuel, un peu tiré par les cheveux quand même -_-’ ).
Problème :
A ce moment-là, le player n’a pas fonctionné… et j’ai trouvé à peu près pourquoi :
En analysant le trafic sur eth1.100, j’avais quelques requêtes DHCP avec l’adresse 192.168.27.X : OK !
Mais sur les bridges BR0 ou BR1, pas même un seul paquet de capturé…
J’en ait donc déduit que dans certaines configurations (je ne sais pas vraiment quand), les bridges nécessitent d’être taggés pour appartenir aussi au vlan 100.
Résolution du problème :
J’ai donc renommé dans /etc/network/interfaces mes bridges en :
- br0.100
- br1.100
Puis /etc/init.d/networking restart
Mes bridges physiques taggés, j’ai redémarré PfSense et là pas de souci, j’avais des logs sur mes cartes et sur mon bridge pfsense.
Et bien sûr, le player a booté 
En espérant avoir pu donner un petit coup de main…
Petit dessin de ce que ça donne au final :
______ PFSENSE _______
| |
| BR0 |
| / \ |
| vETH0 vETH1 |
|_____/ \______|
/ \
| |
br0.100 br1.100
| |
free v5 - eth0.100 eth1.100 - freeplayer
Dans quel but ?
Desole je n’ait pas du bien comprendre le but de Riquet78 alors…
Apres dans l’idee je trouve ca juste un peu plus securise que d’avoir un bridge qui permet de passer rapidement sur le lan sans pare-feu.
Pas de lecteur DVD (Physique) sur cette machine, mais je vais voir à l’occasion pour tester Lili USB un week-end