Internet passerelle debian sur plusieurs vlan ?

Bonjour tout le monde,

J’ai actuellement pour des besoin pro monter un serveur debian servant de passerelle Internet, sur lequel est brancher un switch 24 ports permettant d’éclater la connexion Internet.
pour éclater le réseau sur différentes plage IP pour différents service j’ai mis des vlan (3).
Voici un petit schéma de l’installation.

[Freebox]<--->(eth1)[Serveur Debian](eth0)<---->[Switch1]
                    [              ]            [ Vlan1 ]<---->PC1
                    [              ]            [ Vlan2 ]<---->Wifi 1

Actuellement en supprimant les Vlan dans /etc/network/interfaces et en entrant la règle Iptables adéquate

j’arrive à avoir le net, seulement dés que je réactive les vlan (en les décomentants),

[code]# The loopback network interface
auto lo
iface lo inet loopback

auto eth1
iface eth1 inet dhcp

auto eth0
iface eth0 inet static
address 12.22.12.1
netmask 255.255.255.192

This is a list of hotpluggable network interfaces.

They will be activated automatically by the hotplug subsystem.

auto vlan4
auto vlan5
auto vlan101

VLAN 4

iface vlan4 inet static
address 192.168.0.8
netmask 255.255.255.192
network 192.168.0.0
broadcast 192.168.0.63
mtu 1500
vlan_raw_device eth0

VLAN 5

iface vlan5 inet static
address 10.0.111.8
netmask 255.255.255.0
network 10.0.111.0
broadcast 10.0.111.255
mtu 1500
vlan_raw_device eth0

VLAN 101

iface vlan101 inet static
address 172.12.101.8
netmask 255.255.255.0
network 172.12.101.0
broadcast 172.12.101.255
gateway 172.12.101.1
mtu 1500
vlan_raw_device eth0
[/code]

et que je faits de nouveau pareil, je n’ai plus de net derrière sur le switch et les PC branchés dessus.

Comment faire pour que le net circule convenablement dans tout mes vlan ?
Que dois-je entré comme commande iptables ?

Merci d’avance de votre aide pour m’aider à avancer.

Il faudrait des informations supplémentaires.
Comment sont configurés le switch et les machines derrière lui (VLAN, adresse/masque, passerelle…) ?
Avant de s’occuper de l’accès internet, il faudrait commencer par vérifier la connectivité entre les machines et la passerelle avec ping ou arping.
Normalement le seul ajout d’interfaces VLAN ne devrait pas affecter le comportement du réseau non taggé (eth0 12.22.12.1/255.255.255.192).

Bonjour, (désoler d’avance pour la longueur du poste)

Le serveur tourne sous Debian 7, dessus il y a ça pour /etc/network/interfaces (j’ai refais une nouvelle config).
Vlan est installer dessus (apt-get install vlan)

# The loopback network interface
auto lo
iface lo inet loopback

# primary interface (WAN)
auto eth1
iface eth1 inet dhcp

# Secondary interfaces (LAN)
auto eth0
iface eth0 inet static
address 192.168.10.1
netmask 255.255.255.0
broadcast 192.168.10.255

# This is a list of hotpluggable network interfaces.
# They will be activated automatically by the hotplug subsystem.
auto vlan4
auto vlan5
auto vlan101

# VLAN 4 (admin Birdys)
iface vlan4 inet static
address 192.168.11.1
netmask 255.255.255.0
network 192.168.11.0
broadcast 192.168.11.255
mtu 1500
vlan_raw_device eth0

# VLAN 5 (Birdys public)
iface vlan5 inet static
address 192.168.12.1
netmask 255.255.255.0
network 192.168.12.0
broadcast 192.168.12.255
mtu 1500
vlan_raw_device eth0

# VLAN 6 (Animations Birdys)
iface vlan101 inet static
address 192.168.13.1
netmask 255.255.255.0
network 192.168.13.0
broadcast 192.168.13.255
mtu 1500
vlan_raw_device eth0

Le net arrive par Eth1, le ping vers google ou autre marche et réponds.
Le port Eth0 envois sur le switch (port 25).

Le switch est un Dlink DES3526 (switchs récupérés en donation à notre asso) je le manage en console mais aussi en réseau. Il est configuré comme cela :

Ports 1 à 8 vlan id 1, defaults (vlan4)
Ports 9 à 16 vlan id 2, BirdysPublic (vlan5)
Ports 17 à 24 vlan id 3, AnimBirdys (vlan6)
Ports 25 taggé dans les 3 vlan.

Étant un switch niveau2 il n’y a que d’après le support Dlink que a renseigner les ports utilisés dans quelle vlan en GVRP.

Là où le bas blesse c’est que les machines (hors les 2 miennes) tourne sous windows (chez un client pas chez moi).
Dans les paramétre IPv4 je mets en manuel pour le moment (test) en renseignant une ip adéquate appartenant à la plage ip dispo du vlan où la machine est brancher :

Par exemple :
address 192.168.11.2 netmask 255.255.255.0 passerelle 192.168.11.1 pour une machine brancher dans le vlan 1
address 192.168.12.2 netmask 255.255.255.0 passerelle 192.168.12.1 pour une machine brancher dans le vlan 2
address 192.168.13.2 netmask 255.255.255.0 passerelle 192.168.13.1 pour une machine brancher dans le vlan 3

Les ping fonctionne en local (à l’exception que j’arrive à pinger vers le eth0 dans tout les vlan, et certain poste qui ne sont pas dans la même plage ip, étrange) mais pas vers le net :

PC1 address 192.168.11.2 netmask 255.255.255.0 passerelle 192.168.11.1 brancher dans le vlan 1 :
Ping OK en 192.168.11.1 mais aussi 192.168.10.1 (étrange ou pas ?)
PC2 address 192.168.12.2 netmask 255.255.255.0 passerelle 192.168.12.1 brancher dans le vlan 2 :
Ping OK en 192.168.12.1 mais aussi 192.168.10.1 (étrange ou pas ?), par contre il arrive à communiquer avec le PC1 qui n’est pas dans le même vlan, là je comprends plus.
PC3 address 192.168.13.2 netmask 255.255.255.0 passerelle 192.168.13.1 brancher dans le vlan 3 :
Ping OK en 192.168.13.1 mais aussi 192.168.10.1 (étrange ou pas ?), par contre il arrive à communiquer lui aussi avec le PC1 qui n’est pas dans le même vlan, et visiblement vers PC2 aussi, là je comprends toujours plus.

J’avoue ne pas trop comprendre ce que tu veux dire là.

Je dois rendre la chose opérationnel et faire la pose définitive, demain vendredi 30 mai, au client (en test aujourd’hui chez moi), comment faire fonctionner la chose avec le net dans les vlan ?

Merci d’avance de votre aide pour m’aider à avancer.

C’est normal que les VLAN ID définis sur le serveur (4, 5, 101) soient différents de ceux définis sur le switch (1, 2, 3) ?

GVRP pour quoi faire ?

[quote=“24fr22”]PC3 address 192.168.13.2 netmask 255.255.255.0 passerelle 192.168.13.1 brancher dans le vlan 3 :
Ping OK en 192.168.13.1 mais aussi 192.168.10.1 (étrange ou pas ?), par contre il arrive à communiquer lui aussi avec le PC1 qui n’est pas dans le même vlan, et visiblement vers PC2 aussi, là je comprends toujours plus.[/quote]
Qu’est-ce que tu ne comprends pas ? Tout est normal, c’est ainsi que cela doit fonctionner. Le “serveur” est en fait un routeur et se comporte comme tel en faisant passer les paquets entre ses différents réseaux.

Si la règle iptables MASQUERADE est toujours en place, alors l’accès à internet depuis les VLAN devrait fonctionner aussi, au moins par adresse IP. As-tu défini correctement les DNS pour la résolution de nom sur les postes ?

Hummmm en faite je dois lui indiquer les même nom (switch et serveur) ? j’avoue qu’un collègue de mon asso m’a sorti que c’était pas grave, d’où le fait que c’est comme ça.
Le seul hic c’est que le switch refuse que je renomme le vlan default déjà présent dessus.
Dois-je au pire en créer trois autre avec les même nom : serveur = switch ?

D’après le mec au tel du support Dlink il faut le faire, pour définir au switch que telle port à telle port est pour tel vlan. M’aurait il raconter des connerie et que c’est pas utile de le faire ?

[quote=“PascalHambourg”][quote=“24fr22”]PC3 address 192.168.13.2 netmask 255.255.255.0 passerelle 192.168.13.1 brancher dans le vlan 3 :
Ping OK en 192.168.13.1 mais aussi 192.168.10.1 (étrange ou pas ?), par contre il arrive à communiquer lui aussi avec le PC1 qui n’est pas dans le même vlan, et visiblement vers PC2 aussi, là je comprends toujours plus.[/quote]
Qu’est-ce que tu ne comprends pas ? Tout est normal, c’est ainsi que cela doit fonctionner. Le “serveur” est en fait un routeur et se comporte comme tel en faisant passer les paquets entre ses différents réseaux.[/quote]

Oui mais une fois de plus le collègue de mon asso a prétendu que ça ne devais pas se faire et les postes qui ne sont pas dans le même vlan ne devaient pas communiquer entre eux. Une fois de plus m’as t’il raconter des crack ?
De mon côté je me doute qu’il ping sur les ip des vlan, mais entre les pc entre deux vlan normalement il devrait pas ?

Parce que en même temps c’est une demande du client : je souhaite que les ordis de telle “zone” ne communique pas avec ceux d’une autre, en gros si je mets l’imprimante sur telle zone je ne veux pas que ceux du publique puisse aller dessus mais ok pour du net.

Pour ça il me semble qu’il faille mettre une autre règle iptables DROP sur le serveur genre :

iptables -A FORWARD -i vlan4 -o ! vlan5 -j DROP ???

Tu parle bien de celle ci de règle : iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE ?

Hummmm j’avoue que sur les postes il n’y a pas de chose mis dans les DNS, l’erreur viendrait il de cela ?
Si oui lequels dois-je entrée ? celle du FAI ? l’ip du serveur ? l’ip du modem/box brancher sur le serveur sur Eth1 ?

Merci d’avance de votre aide pour m’aider à avancer.

Je ne parle pas des noms mais des VLAN ID (tags) utilisés pour marquer les trames sur le port connecté au serveur. Pour Linux une interface vlan5 ou eth0.5 a forcément le VLAN ID 5. Je ne connais pas ton switch et ne sais pas comment il se configure. Bien sûr il faut définir les VLAN sur les ports mais je ne vois pas le rapport avec le protocole GVRP qui sert à plusieurs switches pour se transmettre les configurations.

C’est vrai uniquement au niveau du switch (couche 2, liaison). Mais entre tous ces VLAN, il y a ton serveur qui fonctionne comme un routeur, qui fait donc du routage IP (couche 3, réseau) entre tous ces réseaux et leur permet de communiquer les uns avec les autres. C’est le principe d’internet : un tas de réseaux différents interconnectés par des routeurs. Autrement tous ces réseaux seraient isolés, car on ne peut pas mettre tout l’internet sur un même réseau.

Si tu veux restreindre les communications entre les VLAN, il va falloir ajouter des règles de filtrage iptables dans la chaîne FORWARD. Mais après avoir validé l’accès internet et le reste. Sinon tu ne sauras jamais d’où vient le problème, d’un filtrage inadapté ou d’autre chose.

Oui, pourquoi ? Il y en a une autre ?

Sans serveur DNS pas de résolution de nom.
ping machin.truc -> hôte inconnu -> échec.
Mais ça n’empêche pas les communications par adresse IP, par exemple [mono]traceroute 8.8.8.8[/mono]. A vérifier avant de chercher du côté du DNS.

Ça dépend de ton cahier des charges. Y a-t-il un serveur DNS local qui servirait un domaine local à interroger en priorité, sur le serveur ou sur une autre machine ? Sinon, si la box fait office de relais DNS alors tu peux mettre son adresse IP. Sinon tu peux mettre les adresses IP des DNS du FAI ou de DNS publics ouverts comme ceux de Google (espionnés bien sûr) ou OpenDNS (espionnés et menteurs).

En gros si je comprends bien si j’entre vlan4 sur le serveur il faut que je lui dise dans le switch que le vlan en question porte l’identifiant 4 ?

Concernant le GVRP je ne faisais que de dire ce que le mec de dlink m’avais affirmer au tel qu’il falait impérativement faire pour que ça marche, mais si je comprends bien c’est pas utile et il m’a affirmer ça sans pour autant que j’ai besoin de faire ça ?

heu sur des machine sous windows ça va être dure de faire un traceroute.
Mais cherche pas je pense que le soucis dois effectivement venir de là car avant j’avais tester en direct sans vlan et avec un serveur dhcp où les dns étaient pas rentrer enfin j’avais laisser chez le client ceux de mon FAI chez moi et ça marcher pas, une fois mis ceux de son FAI pouf ok.

Non il n’y a pas de serveur DNS local. Je vais tester avec ceux du FAI.

Après confirmation de fonctionnement je verrais pour y installer les règles iptables adéquates pour qu’il n’y est pas de navigations des vlan entre eux.

Merci d’avance de votre aide pour m’aider à avancer.

Oui, si “porte l’identifiant 4” signifie bien que les trames de ce VLAN sur le port 25 du switch seront taggées avec le VLAN ID 4, et qu’il ne s’agit pas d’un autre identifiant arbitraire interne au switch.

La commande équivalente sous Windows est [mono]tracert[/mono]. Il envoie des paquets ICMP echo (comme [mono]ping[/mono]) au lieu de paquets UDP comme les traceroute Unix, mais sauf firewall parano ça ne change pas grand-chose. Ajouter l’option [mono]-d[/mono] pour ne pas faire de résolution inverse si les DNS ne sont pas ou mal configurés, sinon ça peut provoquer des ralentissements. Il y a aussi [mono]ping[/mono] évidemment, mais c’est moins parlant.

PS : On s’éloigne de la fonction routage pure, mais si tu veux du DNS facile tu peux installer [mono]dnsmasq[/mono] sur le serveur. Par défaut il retransmet les requêtes DNS vers les adresses des serveurs figurant dans /etc/resolv.conf (reçues par DHCP sur eth1), donc il peut s’adapter à n’importe quelle box. En prime il peut aussi faire office de serveur DHCP pour les VLAN, ce qui évitera de configurer manuellement les postes clients.

Si je comprends bien ce que tu dit il faut que l’id dans mon switch correspond à 4 pour vid et peut importe le nom que je lui donne, et ainsi de suite pour les autres (5 pour vlan5) ?
Ensuite concernant le tag de port dans le switch le 25 pour chaque Vlan ? (ce que je n’arrive pas à comprendre c’est qu’il me dit quand je le tag dans vlan id 4, qu’il ne peux le faire dans vlan 4)

C’est bien ça ?

Concernant le DHCP, isc-dhcp-server à était installer sur le serveur, mais pour le moment je l’ai tester que en tant que machine passerelle sans les vlan uniquement Eth0 (pour essais de config, le dns que j’ai due indiqué pour que le net passe bien est ceux du FAI), je suppose que par la suite il me sera possible de renseigner dans le fichier de config les chose pour que chaque vlan sois bien en DHCP ?

Je finis de remettre la config sur un autres serveur (rack, car le client à estimé cette après midi que lors des essais sur place il faisait trop de bruit) et je vous tien informer des résultats ou autres soucis.

Merci d’avance de votre aide pour m’aider à avancer.

La causalité est discutable. Pour utiliser plusieurs plages IP, tu utilises des vlan ?

Ta règle iptables dit de faire du nat. À mon humble avis, tu ne devrais pas, un routage natif est préférable

Si tout le monde peut causer à ton Debian, alors il te suffit d’activer l’IP forward pour que chacun parle à son voisin

[quote]La causalité est discutable. Pour utiliser plusieurs plages IP, tu utilises des vlan ?
Ta règle iptables dit de faire du nat. À mon humble avis, tu ne devrais pas, un routage natif est préférable
Si tout le monde peut causer à ton Debian, alors il te suffit d’activer l’IP forward pour que chacun parle à son voisin[/quote]

Heu bah tu connais d’autres solutions pour répondre au cahiers des charges fixé par mon client ?
J’ai bien pensais à placer juste un switch sur la connexion mais à ce moment là ça partagerais la connexion entre plusieurs machine sur la même plage IP de la box, ce qui n’est pas souhaiter par ce client.
Surtout que ces switch là ne sont pas des switch de niveau 3 mais 2.
De plus celui-ci ne souhaite pas que tout passe par le même lan et que chacun sois sur sont lan dédié, ce qui à ma connaissance est réalisable avec des vlan surtout quand on à que deux ports sur la machine serveur qui sert effectivement de machine de routage et pas le routage “merdique” (je reprends les dire de celui-ci) de Orange limitée et peu configurable à son gout.
J’utilise ce que j’ai en stock pour le moment.

Oui je fais du Nat pour le moment, mais c’est pas à chaque démarrage de la machine, et juste pour des essais et le temps du montage définitif chez le client pour qu’il dispose du net sur le réseau câblé mis sur place.
A terme justement il m’est demander que chaque personnes dans un vlan spécifique ne puisse pas causé à son voisin, en gros ne pas accéder au ressources des postes servant à l’administration par exemple.
Le Nat ne sera plus. Par contre j’ai vue sur des doc et différents HowTo que l’IP forwarding était à activé sur pour utilisé des vlan mais oui je n’y est vue aucune mention de Nat.
Si je suis donc ton raisonnement j’ai pas à entrer ça pour avoir le net dans mes vlan ?

Ok, tu veux des lan différents, donc les vlan sont biens (et pas parcque tu as des subnets différents)
Il te suffit donc de monter les vlan sur ton interface, de mettre une IP sur chacun, d’activer l’IP forward, et d’être sur que les clients ont ta machine pour passerelle.

Heu cela veux dire qu’il faut sur ces fameux poste windows que la passerelle par défaut à déclarer est l’IP de fixer de Eth0 ?
Pas l’IP du vlan qu’il utilise (renseigner dans /etc/network/interfaces) ???

T’as une interface, disons br0
Tu as 3 vlans (ID 2, 3 et 4) : br0.2, br0.3 et br0.4
Tu as des IP sur chaque interface :
br0.2: 10.2.2.1/24
br0.3: 10.3.3.1/24
br0.4: 10.4.4.1/24

Les postes qui sont dans le vlan 2 ont des IP dans le subnet 10.2.2.0/24. Ils ont 10.2.2.1 pour passerelle.
De même, les gens qui sont dans le vlan 3 ont des IP dans le subnet 10.3.3.0/24, et ont 10.3.3.1 pour passerelle.

Ainsi, quand la machine 10.2.2.5 veut causer à 10.2.2.40, ils sont dans le même subnet, ils causent directement.
Quand la machine 10.2.2.5 veut causer à n’importe qui d’autre, le paquet arrive à ton Debian. Si ce paquet est à destination d’une machine dans un autre vlan, disons 10.3.3.5, alors ce dernier est renvoyé sur l’interface br0.3 (comportement à bloquer par la suite avec iptables, si j’ai bien compris ton besoin). Si ce paquet est à destination du grand ternet, alors il est renvoyé vers la passerelle de ton Debian (probablement eth1 ou qu’importe, l’interface qui est branché à ta livebox).

Oui et donc c’est juste l’ip foward activer dans /etc/sysctl.conf (ip-forward à 1 pas 0) qui est utilise, en gros si je tape sur une des machine qui est sur le vlan3 par exemple ping free.fr, ça arrive sur le debian qui lui renvois ça sur Eth1 où arrive la connexion qui vient effectivement d’une livebox pro, pour résolution du nom ?

La résolution de nom n’a rien à voir avec le routage.
Dans ton cas, les machines doivent joindre un resolveur DNS, soit un serveur externe (opendns ou autre), soit un serveur interne joignable (ton serveur Debian, typiquement), voir directement la livebox.

Dans tout les cas, le poste va posséder une adresse IP à qui envoyer les requêtes DNS. Ces requêtes vont donc passer plus ou moins de machines (Debian, livebox ou resolveur externe). Mais l’important, ce qu’il ne s’agit que de trafic, tout ce qui a de plus commun, il va donc emprunter les mêmes chemins que tout le reste du trafic;

Bonjour tout le monde, bon j’ai fait de nombreux test et toujours pareil.
Sur le serveur debian j’ai bien les vlan de configurer par exemple pour mon test :

auto vlan2 iface vlan2 inet static address 192.168.12.1 netmask 255.255.255.0 broadcast 192.168.12.255 vlan_raw_device eth0

J’ai ensuite fait sur le switch les vlan adéquate :

[code]VID : 1 VLAN Name : default
VLAN TYPE : static Advertisement : Enabled
Member ports : 1-24
Static ports : 1-24
Current Tagged ports :
Current Untagged ports : 1-24
Static Tagged ports :
Static Untagged ports : 1-24
Forbidden ports :

VID : 2 VLAN Name : Demo
VLAN TYPE : static Advertisement : Disabled
Member ports : 25-26
Static ports : 25-26
Current Tagged ports : 26
Current Untagged ports : 25
Static Tagged ports : 26
Static Untagged ports : 25
Forbidden ports :

Total Entries : 2[/code]

le port 26 est taggé sur le port 26 dans vlan2.

Mais toujours pareil, entre les machines j’ai bien des réponse au ping mais toujours pas de net qui arrive sur eth1.
Je ne sais plus trop quoi faire là sachant que l’ip forwarding est pourtant bien enclenché.

Une idée pour que ça marche ?

Merci d’avance pour votre aide

Fait du debug
Sur ton client :

  • tu ping Debian ?
  • tu ping la livebox ?
  • tu ping 192.0.43.8 ?
  • tu ping iana.org ?

Sur ton Debian, lance un tcpdump -i any -n -e pour voir ce qui passe

Alors pour les test chez moi je suis derrière une freebox et j’ai entendu dire que ne mode routeur elle utiliser elle aussi des vlan, ce ne serais pas ça la cause du problème (tout du moins chez moi) ?

Non. La freebox utilise le VLAN 100 pour la communication entre le boîtier ADSL et le boîtier HD. De toute façon tes VLAN sont de l’autre côté de ton serveur-routeur sur son interface eth0, donc il n’y a pas d’interaction possible entre les deux.

Si tu veux qu’on continue à t’aider, il va falloir fournir les configurations opérationnelles du switch, du serveur et des postes sans les modifier à chaque fois, et les résultats exacts des tests suggérés par haleth (capture de trafic comprise), idéalement en remplaçant ping par tracert -d.