vlan sur pfsense virtualisé sur Proxmox
-
Je progresse dans ma quête.
J'ai mis à jour le firmware de mon switch.
Miracle, j'ai pu ajouter une option pour ajouter le tag vlan 3 sur l'IP de management du switch.Ensuite, j'ai configuré le tag vlan 3 sur la carte réseau de mon PC. (ça ne fonctionnait pas sur le port sur lequel j'étais branché.)
J'ai branché ensuite cette carte sur le port 2 du switch qui avait le vLAN 3 configuré en taged et là, ça fonctionne, j'atteins le switch.
Si j'enlève le tag vlan3 sur la carte réseau du PC, ça ne fonctionne pas
Si je me branche sur un port du switch en "untagged vlan3"
ça ne fonctionne pas non plus. (avec ou sans tag vlan 3 sur le pc)Donc a priori, mon vlan3 est bien diffusé.
Maintenant je souhaiterai pouvoir atteindre le switch dans le vlan3 depuis mon PC sans ajouter la carte réseau tagée en vlan 3.
Je sais que c'est possible puisque je fais déjà cela à mon travail. Mais je ne vois pas encore quelle configuration effectuer pour y parvenir. -
This post is deleted! -
@willis
Réponse au post de 21h.Beaucoup de vos retours sont des appréciations plutôt que des règles (exemple 'virtualisation versus production').
Pour un professionnel, tout est possible ... mais ce n'est pas forcément ce qui est à faire !
En particulier pour la virtualisation, l'ANSSI (Agence nationale de la sécurité des systèmes d'information) recommande de ne pas virtualiser des machines situées sur des zones distinctes (et donc les firewall), parce que, d'évidence, la faille d'une VM peut permettre d'atteindre l'hyperviseur et par conséquence, accéder à plusieurs zones ! Il est notable qu'une seule marque de firewall est validée par l'ANSSI et que cette marque propose des firewall sous forme de VM : il est particulièrement délicat de choisir l'hyperviseur ... et de ne pas être naïf !
Personnellement, je recommande d'avoir un firewall physique en entreprise (sous la forme d'une appliance ou d'un serveur dédié, avec suffisamment d'interfaces ethernet). L'utilisation d'un chassis gérant les VLAN, il suffira d'avoir un seul lien vers la firewall, et de répartir les VLAN en 2 blocs selen la passerelle : les VLAN ayant le firewall comme passerelle, et les VLAN ayant le chassis comme passerelle.
Proxmox (qui est une solution que j'apprécie) est basé sur Debian. Elle permet de gérer les VLAN, depuis l'interface web d'administration. De facto, sans doute la bonne méthode est de créer autant d'interfaces avec VLAN que besoin et les présenter à la VM firewall ... qui ne gérera DONC pas les VLAN ... puisque c'est l'host qui le fait. (A la manière de VMware)
Faire fonctionner des VM suppose une parfaite maitrise des concepts réseau de l'hyperviseur. C'est loin d'être le cas pour un 'amateur' : il y a des hyperviseurs que je ne maitrise pas (ex hyperv). Votre cas est un exemple de ce que j'affirme sur la virtualisation : complexité à appréhender ce qui se passe. (C'est déjà vrai pour les professionnels, dont je fais partie.)
Le tuto indiqué est 'léger' et 'confusant' : l'interface de support des vlan NE DOIT PAS être configuré. Ca c'est une certitude, et la formulation fait penser autre chose ! Les explications sur les switchs sont moyennes 'sans plus' : le 'untagged' n'est pas du tout clair; ce que j'écris est plus court mais plus exact : il faut du temps pour comprendre comment cela fonctionne. Vous n'avez pas compris le 'untagged' : à travailler.
-
Le tuto indiqué renvoie à un lien qui 'explique les VLAN'. Ce qui est indiqué est vrai ... mais n'aide pas forcément à comprendre AMHA !
Pour expliquer les VLAN, je commence par expliquer que les VLAN nécessitent des paquets IP 'marqués' c'est à dire d'un certain type (802.1q). Lesquels paquets IP sont presque identiques à un paquet IP 'standard' : la seule différence réside en 2 octets, le tag, qui sont remplis dans le cas VLAN, et non remplis (=à zéro) dans le cas standard. Autrement dit, un paquet standard est dans le VLAN 0 (ou 1), et un paquet 'marqué' (ou taggé') a un VLAN entre 2 et 4095 (à peu près).
Ce marquage est essentiel car chaque switch sait alors comment aiguiller le paquet. En effet, le paquet 'marqué' (ou taggé) peut ou non passer par tel port si le tag (=n° de vlan) fait partie des vlan autorisés (les vlan 'tagged' plus le 'untagged'). On voit ici que le traitement 'normal' via les MAC address de destination n'est validé EN SUS par le n° de VLAN.
L'essentiel, dans les VLAN, est donc d'avoir des paquets 'marqués'. Et c'est le paquet qui indique (directement) à quel VLAN (unique) il appartient.
De facto, il faut penser à 2 cas évidents :
- un PC émet un paquet non taggé
- un PC reçoit un paquet taggé.
En effet, un PC standard (ou d'autres machines) ne marque pas naturellement un paquet.
Le 2ième cas est super simple : le PC fait abstraction (ou non) du tag.
Le 1er cas est aussi simple : le switch (administrable) va marquer le paquet du n° de 'vlan untagged' du port où est connecté le PC, et le paquet suivra ainsi l'aiguillage induit par ce n° de tag (vers la machine cible). (Au passage, on comprend ainsi que chaque port ne peut avoir qu'un 'untagged' unique, forcément.)
C'est le début de l'explication de VLAN, et c'est majeur de commencer par comprendre ce marquage ...
-
@jdh
Bonsoir,vos réponses sont assez déconcertantes dans leur forme mais m'ont quand même fait sourire...
Néanmoins, dans votre dernière réponse, vous expliquez assez bien et relativement simplement le fonctionnement des vLAN.
Comme nous sommes sur un forum d'entraide technique, il me semble plus intéressant de vous remercier pour les éléments techniques sur lesquels vous m'avez éclairé.Donc merci pour ce cours rapide sur les vLAN. Le untagged est de la sorte plus clair pour moi.
En attendant, je retourne à mes recherches pour savoir et surtout comprendre comment accéder à l'interface de management de mon switch dans le vlan 3 depuis mon PC sans passer par l'ajout d'une interface taggée dans ce vlan.
Je pense avoir une idée et je vais tester. Je donnerai des nouvelles.Bien cordialement.
-
Seneque (vers 65 apres JC) : "Il n'y a pas de vents favorables pour celui qui ne sait pas où il va".
Pour utiliser une TV, il suffit d'appuyer sur la zapette, mais pour la dépanner, il faut comprendre comment elle fonctionne.
Un paquet IP comporte les 2 adresses MAC 'source' et 'destination'. Contrairement à un hub, un switch regardera ces adresses :
- il notera, dans sa table ARP, l'adresse MAC 'source' avec le port d'arrivée,
- il recherchera, dans sa table ARP, l'adresse MAC 'destination' et enverra le paquet dans le port associé = port de départ,
- (S'il ne connait pas le port de départ, il effectuera une recherche via une requete ARP).
Ce mécanisme basique (et élémentaire) permet de transmettre un paquet d'une machine P1 vers une machine P2 via 3 switchs A, B et C reliés entre eux (et sans boucle).
Mais si on veut créer un réseau virtuel (VLAN) entre ces machines P1, P2, cela ne suffit plus !
Nécessairement les paquets devront être 'taggés' afin que les switchs, identifiant le n° de VLAN, aiguille correctement.
D'où l'opération de marquage réalisée par le premier switch, et la question du traitement final d'un paquet marqué. Parce que les machines ne savent pas forcément qu'elles utilisent un réseau virtuel : la plupart du temps, les machines ne marquent pas les paquets, ce sont les switchs qui le font.
Avec le schéma suivant, pour le VLAN 10 :
P1 <-> p3 / SW A / p5 <-> p1 / SW B / p2 <-> p1 / SW C / p6 <-> P2
on devra configurer
- SW A p3 : untagged 10
- SW C p6 : untagged 10
- SW A p5 : tagged 10
- SW B p1 : tagged 10
- SW B p2 : tagged 10
- SW C p1 : tagged 10
Et, sans même que P1 et P2 le sache : ils seront seuls à communiquer entre eux. Et ils ne recevront aucun paquet d'autres machines, SAUF si ces autres machines sont aussi reliées à un port en 'untagged 10'.
Il faut noter que les switchs seront donc TOUS administrables. L'ajout d'un switch oblige à configurer ET le switch supplémentaire ET le switch et port auquel il est relié, bref une opération importante.
(Evidement si on utilise un switch non administrable à un endroit avec une seule prise et 2 PC a une conséquence ... inattendue !)
(J'ai déjà écrit sur un collègue qui prétendait connaitre les VLAN, et ne voyait rien de mal à relier 2 switchs administrables via un switch non adinistrable !!)
Le tuto indiqué n'explique, en fait, aucunement les VLAN même si les mots 'tagged' et 'untagged' sont utilisés.
Stop pour moi, je vous ai indiqué déjà beaucoup, tant sur la virtualisation que sur les vlan ...
-
Merci pour votre cours accéléré de réseau et vlan.
Je vais relire attentivement quand je serai dans de meilleurs dispositions. Là il est tard...
En attendant, pour donner des nouvelles, j'arrive à atteindre par ping et tracert le switch qui est dans le vlan 3 depuis l'interface réseau de mon pc qui est dans le vlan par défaut (1),
Mais étrangement, l'interface web dans ce cas ne fonctionne pas. Je pensais que ce serait tout ou rien...
A priori, ce n'est pas le FW qui bloque puisque j'ai autorisé tout le trafic vers l'ip du switch pour ne pas être bloqué par cet élément.
Donc j'arrive encore à une incompréhension de ce que je constate. -
Vous avez indiqué dans votre première réponse :
"pour un port, le 'untagged' est le n° de vlan qui va être mis sur les paquets arrivants et sans vlan, donc les paquets suivront ensuite avec le tag 'untagged'"
=> à travers cette phrase je comprends que le switch va marquer les paquets sans vlan avec le N° de vlan spécifié untagged.Sur cet article : https://www.lecoindunet.com/comprendre-notion-vlan-tagged-untagged-1629
il est indiqué que le switch "retire" le tag sur les ports "untagged" ???
Je cite : "Untagged : le port du switch envoie le trafic après avoir retiré le tag du VLAN."Du coup, il marque ou il enlève la marque ?
=> parce que s'il retire le tag, cela signifie pour moi que peut importe la machine qui émet un paquet, la machine qui sera derrière le port untagged recevra un paquet sans tag et répondra sans tag.
Ainsi, si la machine source A émet depuis un vlan taggé, la machine de destination B recevra le paquet, mais si elle répond, la machine A ne recevra pas la réponse de B car le paquet ne sera pas taggé en retour.Et du coup, cela explique qu'il faut tagger le port pour que la machine B derrière se port répondant à A (qui est dans le vlan taggé) puisse recevoir la réponse.
-
@willis said in vlan sur pfsense virtualisé sur Proxmox:
Merci pour votre cours accéléré de réseau et vlan.
Je vais relire attentivement quand je serai dans de meilleurs dispositions. Là il est tard...
En attendant, pour donner des nouvelles, j'arrive à atteindre par ping et tracert le switch qui est dans le vlan 3 depuis l'interface réseau de mon pc qui est dans le vlan par défaut (1),
Mais étrangement, l'interface web dans ce cas ne fonctionne pas. Je pensais que ce serait tout ou rien...
A priori, ce n'est pas le FW qui bloque puisque j'ai autorisé tout le trafic vers l'ip du switch pour ne pas être bloqué par cet élément.
Donc j'arrive encore à une incompréhension de ce que je constate.EDIT : Et bien contrairement à hier, aujourd'hui ça fonctionne : j'accède bien à l'interface web du switch....
Ce qui est tout à fait cohérent.
Le comportement d'hier était sans doute un bug de mise en cache ...Donc la solution était simple et juste ....
Et découle directement de l'explication de Senec... euh pardon... JDH, il fallait tagger le port du switch sur lequel l'interface de mon PC "sans tag" est connectée. J'avais bien compris, je me suis juste fait avoir par ce bug... -
Mais du coup, pour changer le vlan par défaut et mettre 20 par ex au lieu de 1 (puisque si j'ai bien lu, en terme de sécurité c'est mieux),
Il faut marquer tous les ports de switchs en untagged 20 ? (au lieu de 1 par défaut)
ça change quoi en terme de sécurité ? -
@willis said in vlan sur pfsense virtualisé sur Proxmox:
https://www.lecoindunet.com/comprendre-notion-vlan-tagged-untagged-1629
Il semble que ce soit exact, mais la rédaction prête à confusion ! (D"autres parties idem avec 'VLAN2 PVID 2' ... bref un peu confus !)
Le lien (en anglais) https://networkdirection.net/articles/network-theory/taggeduntaggedandnativevlans/ en plus précis ...
Ce lien explique mieux la situation. Certaines machines ne peuvent tagger les paquets et donc :
- dans le sens machine vers port : le switch va tagger les paquets (non taggés) avec le n° de vlan 'untagged',
- dans le sens port vers machine : les paquets taggés du vlan 'untagged' sont 'détaggé'. (mas les paquets taggés de l'un des vlan 'tagged' ne le sont pas !)
(Si une machine ne tagge pas et que le port n'a pas de 'untagged' ... le paquet est alors taggé du 'native vlan' ou PVID, généralement à 1.)
C'est la pureté de l'échange : un paquet émis sans vlan obtient un retour sans vlan.
Du coup, un élément que j'ai écrit est faux (sans doute) : une machine qui ne tagge pas les paquets traite les paquets taggés sans s'occuper de ce tag.
(Cependant, je ne suis pas totalement sûr de cela, car un paquet reçu taggé est totalement correct : entête correct y compris le checksum. On touche là à la sécurité du principe des VLAN : la sécurité ne réside QUE dans les switchs, il est donc logique que le paquet soit détaggé.)
Le lien expose d'intéressantes questions sur les 'native vlan' et les 'mismatch native vlan' ... Cela encourage à bien maîtriser la config des switchs, et en amont bien avoir compris untagged/tagged ... et à ne pas avoir une confiance absolue dans les vlan !
EDIT : ce que j'ai écrit plus haut est pour certain aspect un peu approximatif ... Néanmoins les principes sont corrects : parler de VLAN sans commencer par expliquer que le paquet ip doit être modifié n'est pas très sérieux !
Les bons liens :
- Wikipedia https://fr.wikipedia.org/wiki/IEEE_802.1Q (le bon protocole pour les vlan ... en visant l'interopérabilité !)
- Frameip : https://www.frameip.com/entete-ethernet/ (décrit ce qu'il faut savoir sur un paquet Ethernet (avant IP) mais ne décrit pas l'utilisation des VLAN)
- Wikipedia (en) : https://en.wikipedia.org/wiki/Virtual_LAN (intéressant et rien à voir avec la traduction française)
-
@jdh
Bonjour,
je me permets de continuer le fil de cette discussion car depuis, j'ai pu poursuivre en suivant vos conseils et j'ai investi dans une machine physique sur laquelle j'ai installé et configuré pfsense. (j'ai réimporté ma configuration et réassigné mes interfaces)
Depuis que j'ai cette machine physique, l'ensemble du réseau est beaucoup plus stable que lorsque le routeur était virtualisé.
Néanmoins, je rencontre une chose que je n'explique pas concernant les vlan toujours :
Depuis mon PC, si je ping une adresse d'un de mes switchs sur le vlan 3, je n'ai pas de réponse.
Si je désactive et réactive ma carte réseau sur mon PC,
je ping à nouveau le switch et je peux me connecter à son interface web.
Puis, au bout de quelques minutes ou après redémarrage, je perds à nouveau la connectivité.
Une idée ?
-
@willis
Et pourtant, en complément, je ping bien l'interface vlan 3 du routeur :
-
Je me réponds à moi-même si ça peut aider quelqu'un :
En configurant une ip virtuelle (avec basculement CARP sur le routeur de secours), en définissant une gateway avec cette ip virtuelle, en définissant cette gateway sur l'interface vlan correspondant, et en configurant mes switchs avec cette gateway, tout fonctionne, je ping et j'accède à mes switchs sans pb et sans perte de ping sur ce vlan.
Le fait d'avoir configuré CARP sur la passerelle de l'interface vlan permet d'ajouter la HA sur ce réseau.
Le but est donc atteint.
-
@willis
Avec les images ça donne ça :
On configure la passerelle pour le VLAN
Ensuite on assigne cette passerelle à l'interface vlan
On définit l'ip virtuelle (la même que la passerelle)
Et sur les switchs, on défini la passerelle.
Du coup, depuis le LAN, je ping et j'accède à l'interface d'administration qui est dans le VLAN3.