Re: retour expérience sur vlan

トップ ページ

このメッセージに返信
著者: anne.guilde@free.fr
日付:  
To: guilde
題目: Re: retour expérience sur vlan
Le 25/10/2017 à 08:06, Jérôme Kieffer a écrit :
> On Tue, 24 Oct 2017 23:10:12 +0200
> Frederic Bressy <bressy.frederic@???> wrote:
>
>> Bonsoir
>>
>>
>> Je cherche un retour d'expérience sur la création de deux vlans (avec un
>> switch paramétrable) et une machine linux qui ferait le passage entre
>> les deux vlan,un "trunk" je crois.
>>
>>
>> Règle de passage avec "ip table", je suppose?
>
> J'ai joué avec cela il y a longtemps pour la freebox-tv mais j'ai
> abandonné a l'epoque sans réussir a re-injecter le vlan100 sur le vlan0
> apres mon routeur maison.
>


bizarre? Tu n'as pas réussi le vlan100
Cela fonctionne chez moi depuis 2013.
Depuis que Raphael m'a mis sur une piste :
https://www.debian-fr.org/t/ponter-le-flux-tv-vlan100-entre-2-freebox-resolu/20392/59

J'ai compris pourquoi pas iptable avec ce post.
----
PascalHambourg
...
| avec iptables n'est il pas possible de faire le tri des paquet tag

VLAN100 et de les rediriger ?

Non, iptables agit sur la couche 3/réseau (IP) et 4/transport (TCP,
UDP...), alors que les VLAN sont dans la couche 2/liaison. Peut-être
avec ebtables en pontant directement eth0 et eth2, mais à mon avis ce
serait moins propre que la solution ci-dessus.
----
PascalHambourg

Il existe dans le noyau Linux une interaction qui semble peu connue
entre le pontage et iptables. On peut a priori se demander pourquoi une
telle interaction puisque le pontage opère dans la couche ethernet
(couche 2, liaison) alors qu'iptables opère dans la couche IP (couche 3,
réseau). La réponse est : pour faire un pont filtrant capable
d'exploiter toutes les fonctionnalités d'iptables comme le suivi de
connexion, sans se limiter à celles offertes par ebtables.

Quand cette interaction est activée, ce qui est la situation par défaut
(je le déplore), les paquets IP qui traversent un pont sont soumis aux
chaînes iptables. Si on ne veut pas, plutôt que d'ajouter des règles
iptables pour accepter ces paquets on peut désactiver l'interaction en
mettant le paramètre du noyau (sysctl)
net.bridge.bridge-nf-call-iptables à 0.

On peut régler la valeur de ce paramètre au démarrage dans
/etc/sysctl.conf ou un fichier /etc/sysctl.d/*.conf.

net.bridge.bridge-nf-call-iptables=0

Mais ce paramètre n'existe que si le module "bridge" est chargé, or le
module n'est chargé automatiquement que lors de la création de la
première interface pont. Cela implique donc de le charger explicitement
avant. Le plus simple pour cela est de l'ajouter dans le fichier
/etc/modules.

Sinon, on peut le régler "manuellement" dans le fichier
/etc/network/interfaces avec une options post-up dans la définition de
l'interface br0.

auto br0
(...)
post-up sysctl -w net.bridge.bridge-nf-call-iptables=0
----

J'ai posté ma solution ici le 17/02/2013 14:29 sujet serveur linux et
configuration d'un vlan

>> Pour la machine linux un raspberry serait pas mal mais comme il ne
>> gère que la vitesse 10/100 en réseau, quelle autre machine avec un
>> petit budget pour gérer le 10/100/1000?
>
> Le pine64 a une interface en gbit native mais celui que j'ai, et plein
> d'autre ont un bug hardware qui fait que cela ne fonctionne pas. en
> 100M c'est bon. les nouveaux sont OK.
>
> A+
>


connaissais pas pine64
Je serais moins bête ce soir ;)

Anne