Je prévoyais de publier un article complet sur la configuration de VLAN dans un réseau hétérogène (materiel Netgear et Ubiquiti/Unifi). Au moment de rédiger celui-ci, je l'ai trouvé un peu trop long. J'ai donc dissocié la partie "rapel / vulgarisation" des VLAN de la configuration à proprement parler.

Avant de se lancer dans la configuration d'un switch manageable, il est bon de rappeler les bases.

Dans un réseau simple, l'ensemble des machines utilise le même plan d'adressage IP pour communiquer. Il n'y a qu'un réseau. Pour disposer d'un second réseau, il faut installer des switchs supplémentaires et le câblage qui convient.

Qu'est-ce qu'un VLAN ?

Un VLAN est un réseau virtuel. Les VLAN permet d'utiliser un même matériel pour plusieurs réseaux. Chaque VLAN représente un réseau avec son propre plan d'adressage IP et ses propres règles.
Chaque VLAN est identifié par un numéro. On parle alors de Tag. Le premier VLAN porte le Tag 1. Le nombre de VLAN utilisable dépend des capacités de votre matériel. Toutes les trames réseau associées à un VLAN portent le Tag du VLAN par lequel elles passent. Ceci permet d'avoir un routage clair des trames vers les matériels potentiellement concernés par celle-ci.

Pour pouvoir gérer des VLAN, il faut disposer de switchs managés (switch de niveau 2, à minima).

Contrairement à une idée reçue, les VLAN n'isolent pas des réseaux. C'est le routeur (ou switch de niveau 3) que vous utiliserez qui déterminera si le routage est possible entre les VLAN (dans quel sens, et si le matériel est sérieux quels ports sont autorisés vers quels IPs ou plages d’IPs).

Avec un seul switch

Quand on ne dispose que d'un seul switch, les choses sont relativement simples. Pour chaque port, on indique le VLAN utilisé et le tour est joué. Il existe une petite subtilité relative aux Tags, mais j'en parlerai un peu plus tard.

Avec plusieurs switchs

L'utilisation de plusieurs switchs implique la compréhension de quelques concepts supplémentaires :

1. Tagged : un port tagué permet de faire passer passer les communications du VLAN associées au Tag.
2. PVID (Port LAN Identifier) : désigne le Tag associé à défaut par toutes les trames réseau qui passent par un port d'un switch. Ceci permet donc de désigner le VLAN associé par défaut à un port.
3. Untagged : le port du swith n'a pas de Tag. Le PVID est utilisé pour désigner le VLAN autorisé à passer par ce port.
4. Trunk : Port du switch qui est utilisé pour communiquer avec un autre switch. Il autorise la communication sur plusieurs VLAN (voir la totalité des VLAN).

La partie la moins drôle réside dans le fait que chaque constructeur en fait un peu à sa tête. Chacun a donc sa propre manière d'implémenter ou de documenter ces principes. Même si actuellement, on observe une certaine convergence (ex: VLAN 1 Untagged par défaut).

L'élément le plus important est de comprendre que deux switchs doivent autoriser les mêmes VLAN sur les ports qu'ils ont en commun. Ce Trunk n'est peut-être pas configuré de la même manière de chaque côté, mais il doit aboutir au même comportement.

Vous l'aurez compris, la véritable difficulté arrive quand on mélange les notions de Tagged, Untagged, PVID, Trunk.

Exemple : Un port a le PVID 2 est marqué Untagged avec le VLAN 2 et Tagged sur le VLAN 3.

• Il est donc autorisé à laisser passer les VLAN 2 et 3.
• Une trame réseau sans Tag passera sur le VLAN 2.
• Une trame réseau destinée au VLAN 3 devra forcément avoir un Tag 3 (ajouté par un client compatible, ou un autre switch qui a ce port Tagged avec le Tag 3).

Vous pourriez vous dire que la solution la plus simple consisterait à ne pas utiliser la notion Untagged sur un Trunck entre switchs. Malheureusement, cela n'est pas toujours possible. La plupart des switchs utilisent le PVID 1 par défaut sur chaque port et l'option Untagged sur le VLAN 1. Le trunck “All” finit donc souvent avec Untagged 1 + Tagges 2 + Tagged 3, etc.

Promis, dans mon prochain article nous partirons dans le dur du sujet ;)

Attention, cela fait longtemps que je n'ai pas râlé sur ce blog, je risque donc de me lâcher.

Cela fait des années que j'utilise du matériel de Netgear sans trop me poser de questions. J'apprécie la marque, la stabilité des produits et surtout la longévité du support (garantie à vie de certains matériels, retour SAV facile, mises à jours, correctifs de sécurité, correction de l'interface, correction des traductions, etc.).

Récemment, j'ai voulu monter un petit tuto pour configurer un produit pro. Au moment de lister les actions à effectuer au clavier, je me suis rendu compte que l'action que je tentais était impossible… Oui, en 2022 il y a encore des interfaces web qui ne peuvent pas être utilisées au clavier.

Les interfaces Web façon Netgear

Ne voulant pas rester sur un apriori négatif, je me suis connecté à l'interface d'un autre produit Netgear plus récent et "grand public". Mon précédent matériel était peut-être un peu vieux.

Sur le second matériel, j'ai droit à une mise à jour toute fraiche. Je l'installe. Je me reconnecte.

Pas mieux, je ne peux pas atteindre 80% de l'interface. J'utilise donc la souris pour cliquer au milieu de l'écran. Les choses vont un peu mieux. Je peux saisir le formulaire... Mais je ne peux pas parcourir le menu pour aller modifier un autre paramètre.

Je persévère, et finis par me rendre compte que la page d'accueil n'est pas du tout accessible au clavier, tout comme le menu.

Je reviens à mon précédent matériel pour vérifier. Le constat est le même. La navigation est impossible au clavier. Le problème ne concernait donc pas que l'action que je voulais effectuer.

Ne nous appesantissons pas trop sur les meta destinées à décrire les contrôles, ni sur les infobulles affichant "JavaScript(0)", et encore moins sur le retour du focus qui est très souvent imperceptible (voir inexistant).

La solution Netgear Insight

En me renseignant un peu, je découvre que la situation serait "un peu mieux" si j'utilisais du matériel administrable via Netgear Insight. J'ai beau être très enthousiaste concernant les solutions de type Sofware Defined Networking (SDN), il y a un élément qui me bloque psychologiquement. Netgear Insight est un service soumis à un abonnement payant. Si je veux avoir une solution accessible, il faudrait donc que je change mon matériel et que je paie un abonnement. Non, décidément la pilule ne passe pas.

Je me pose alors la question du public moins pro (ou moins Geek). Là, je me rends compte que le problème a été déplacé. Netgear pousse les utilisateurs à installer une application mobile pour gérer leurs matériels. L'interface web tendrait à disparaitre des produits Netgear. Pourquoi pas?... Mais que fait-on si l'utilisateur ne peut pas utiliser un mobile?

Les application mobiles

Ne voulant pas rester sur ma faim, j'ai vérifié l'accessibilité des applications mobiles Nightawk et Insight (oui, il y a une application du même nom que le service, pour gérer localement le matériel). Ces deux applications reprennent les mêmes principes, seul le style diffère.

Sur iPhone, cela se passe bien.

Sur Android, c'est la douche froide (pas un matériel ne gère vraiment l'accessibilité de la même manière... entre narration et focus, c'est galère). Je teste donc avec un émulateur et une version Android récente. Cela m'offre une expérience proche de celle de l'iPhone.

J'en conclus qu'il faut vraiment avoir un téléphone adapté pour utiliser ces applications. Je ne vais pas sortir mes Windows Mobile 10 ou 6 du tiroir, ça n'est pas la peine.

Mais là encore, l'expérience est limitée. Par exemple : je ne peux pas gérer finement les options de mon Wifi (impossible donc de résoudre un problème causé par les Wifi des voisins).

Plus drôle : Pour mon switch managé, je dois réduire la complexité de son mot de passe. L'application Insight n'accepte pas mon mot de passe.

Conclusion

Tous les fabricants de matériel ne fournissent pas des interfaces de qualité. Dans le cas de Netgear, le problème d'accessibilité est honteux (pas de retour de focus, pas de navigation au clavier sur la totalité de l'UI, pas de description des actions possibles).

Même si les applications mobiles résolvent une partie du problème, elles ne sont pas la solution à tous. Elles réduisent même la liste des fonctionnalités offertes par le matériel et ne peuvent être utilisées dans toutes les situations de handicap.

Concernant la solution Netgear Insight, je ne suis pas fan. Désolé, mais l'idée de payer pour avoir un produit accessible ne passe pas (à vérifier, si l'accessibilité est véritable). D'autant plus que cela ne concerne que la partie pro (et uniquement sur une certaine gamme de produits). Le grand public est totalement délaissé.

Netgear est une société américaine tenue de respecter certaines règles d'accessibilité. Je ne comprends donc pas la situation.

Pourquoi un matériel pourrait-il avoir des patchs de sécurité et des patchs d'UI, mais aucune correction liée à l'accessibilité?

Avant de s'appeler Azure DevOps, TFS a eu de nombreuses vies. Migrer une infrastructure TFS vers Azure DevOps impose donc une planification minutieuse (que l'on migre dans le cloud ou on-premise). Celle-ci doit commencer par résoudre deux problèmes :

• Identifier les versions de TFS par lesquelles il faudra passer.
• Identifier les versions des produits à utiliser (Windows, SQL Server et TFS).

Premier problème

Il n'est pas forcément possible de passer d'une version X à une version Y de TFS. Parfois, il faut migrer vers une version intermédiaire Z.

Exemple : Si l'on dispose d'un TFS 2012, il faut d'abord le migrer vers TFS 2015. Ensuite, il est possible de migrer vers Azure DevOps.

La documentation décrivant les différents chemins de migration se trouve ici (Upgrade your deployment to the latest version of Azure DevOps Server).

Second problème

Installer TFS implique de disposer d'un OS Windows et d'une instance de SQL Server. Seule problèmes, toutes les versions de TFS, Windows et SQL Server ne sont pas compatibles.

La liste des versions supportées est disponible ici (Requirements for Azure DevOps on-premises). Pour chaque version de TFS, vous y trouverez l'OS et le SGBD compatible.

Attention : pensez aussi à vérifier la compatibilité de SQL Server avec Windows. Ceci peut être vérifié ici (Using SQL Server in Windows).

Conclusion

Prenez bien le temps de consulter ces trois pages de documentation, avant de vous lancer. Ceci vous évitera de perdre votre temps en installant des produits incompatibles.

Azure DevOps est un produit qui a régulièrement changé de nom. Ceci a permis à la solution de toucher un plus large public. Mais le fait de contenir le mot "Azure" apporte son lot de méprises.

Il ne faut pas se leurrer quand on dit Azure, cela ne rassure pas tout le monde. Azure est un acteur majeur du Cloud. Mais le Cloud fait encore peur à de nombreuses sociétés. Le Cloud arrive avec de nombreuses notions : planification, topologie, sécurité, stockage, coûts, etc. …

Honnêtement : ces notions sont-elles vraiment propres au Cloud? À mon sens, planification, topologie, sécurité, stockage, et coûts sont aussi des notions à gérer on premise. Mais je peux me tromper.

À quoi sert l'abonnement Azure ?

Parmi les sujets d'Azure et Azure DevOps qui font un peu peu de prime abord, il y a "L'abonnement Azure" (Souscription Azure: si l'on traduit littéralement le vocabulaire Azure).

Il faut comprendre que cette souscription ne sert qu'à une chose : centraliser les coûts.

Trois catégories de dépenses sont concernées :

• Les licences utilisateurs.
• Les temps de builds.
• Le stockage des Artefacts (Nuget, npm, Maven...).

L'abonnement Azure est donc obligatoire?

Si on prend point par point les 3 catégories évoquées ci-dessus:

• Si vous gérez des abonnements Visual Studio (anciennement MSDN), Azure n'apporte rien.
• Si vous hébergez vos builds sur votre infrastructure, ou n'utilisez pas plus de 30 heures de build par mois, Azure n'apporte rien.
• Si vous n'utilisez pas les Artefacts, Azure n'apporte rien.

Moralité, si vous conjuguez les trois critères évoqués ici, l'abonnement Azure ne vous est pas utile. Vous pouvez rester sur le tiers gratuit d'Azure DevOps.

Utiliser autant que possible le rôle Stackholder pour éviter de consommer la totalité des 5 licences Basics mises à disposition et limiter le nombre d'abonnements Visual Studio à souscrire.

Personnellement, j'aime garder ces 5 licences de côté. Elles me permettent de donner rapidement un accès à un collaborateur le temps qu'un abonnement Visual Studio lui soit affecté.

Et si on part de zéro?

Si vous montez de toute pièce une solution Azure Devops sans disposer de licences Visual Studio, l'abonnement Azure est conseillé. Sa mise en place évitera de jongler entre les différents portails ou markeplaces de gestion de licences.

Conclusion

La souscription Azure est la voix royale vers Azure DevOps quand on part from scratch. Mais elle n'est pas obligatoire.

Suite à mon récent article sur le support de Workflow Foundation dans Visual Studio 2022, j'ai été contacté par un utilisateur surpris par le manque de Templates de code dans VS. Son Visual Studio 2022 n'affiche que deux Templates pour la création d'activités. Son Visual Studio 2013 en affiche huit.

Dans VS 2022, il lui manque les activités suivantes :

• CodeActivity
• CodeActivity with Result
• NativeActivity
• NativeActivity with Result
• AsyncCodeActivity
• AsyncCodeActivity with Result

C'est six Templates ne font pas partie de Visual Studio. Depuis la version 2010, Visual Studio n'a toujours eu que deux Templates d'activités. Ce n'est donc pas surprenant que la version 2022 n'en ait pas plus. Les six Templates proviennent d'une extension que j'ai moi-même réalisée il y a presque 10 ans (autant dire que je ne m'attendais pas à ce que l'on me demande d'exhumer une extension aussi ancienne).

Comme vous vous en doutez, j'ai migré ma vieille extension. J'en ai profité pour la rendre compatible avec les éditions 2017, 1019, et 2022.

Celle-ci peut être téléchargée via le marketplace.

Son code est disponible sur GitHub.