Demandez le diagramme réseau à trois personnes et vous obtiendrez trois images différentes : une photo de la baie, un tableur d'adresses IP et une capture de la console cloud. Aucune ne répond aux questions qui se posent lors d'une revue ou d'une panne : quels segments existent, qui peut parler à qui, et comment le trafic circule entre le bureau et le cloud.
Ce guide construit un diagramme de topologie réseau logique pour une petite entreprise typique, un LAN de bureau avec Wi-Fi et un VPN site à site vers un VPC cloud, et présente les conventions qui gardent un tel diagramme lisible.
Topologie physique ou logique
| Topologie physique | Topologie logique | |
|---|---|---|
| Montre | Équipements, ports, câbles, baies, panneaux de brassage | Segments, plages d'adresses, routage, politique entre zones |
| Répond à | « Sur quel port est branché le point d'accès ? » | « Un invité peut-il joindre le serveur de fichiers ? » |
| Lecteurs | Les personnes qui câblent et remplacent le matériel | Ingénieurs, relecteurs sécurité, auditeurs, nouvelles recrues |
| Change quand | Le matériel bouge | L'adressage, le routage ou les règles changent |
La plupart des discussions ont besoin de la vue logique. Gardez la vue physique pour les personnes qui travaillent dans la baie, et ne mélangez pas les deux sur une même page : des numéros de port à côté de la politique du pare-feu rendent l'un et l'autre plus difficiles à lire.
Les topologies courantes, en bref
- Étoile. Chaque appareil se connecte à un commutateur central. Presque tous les LAN de bureau sont une étoile ou un arbre d'étoiles.
- Maillage. Les nœuds se connectent à plusieurs autres, si bien que le trafic dispose de plus d'un chemin. Courant entre commutateurs de cœur, dans les fabrics de datacenter et les systèmes Wi-Fi maillés.
- Hybride. Les vrais réseaux combinent les deux : des étoiles en périphérie, des liens redondants au cœur, des tunnels entre sites.
Les topologies en bus et en anneau appartiennent surtout au passé sur les LAN modernes.
L'exemple : un bureau et un VPC cloud
Une entreprise de 40 personnes a un bureau avec des portables pour le personnel, un Wi-Fi invités, un serveur de fichiers et des imprimantes. Son application interne tourne dans un VPC cloud, et le personnel y accède par un VPN site à site plutôt que par l'internet public.
Le plan d'adressage vient en premier, car le diagramme se construit à partir de lui. Toutes les plages internes proviennent des blocs privés de la RFC 1918, et l'adresse publique utilise une plage de documentation de la RFC 5737 :
| Segment | VLAN | Plage | Passerelle | Ce qu'on y trouve |
|---|---|---|---|---|
| Personnel | 10 | 10.10.10.0/24 | 10.10.10.1 (pare-feu) | Portables et téléphones de bureau, filaires et Wi-Fi |
| Invités | 20 | 10.10.20.0/24 | 10.10.20.1 (pare-feu) | Appareils des visiteurs sur le SSID invités |
| Serveurs et imprimantes | 30 | 10.10.30.0/24 | 10.10.30.1 (pare-feu) | Serveur de fichiers, imprimantes |
| VPC cloud | 10.20.0.0/16 | Routeur du VPC | Serveurs d'application et base de données | |
| Sous-réseau privé | 10.20.1.0/24 | Routeur du VPC | Serveur d'application, base de données gérée | |
| Liaison FAI | 203.0.113.10 | FAI | L'adresse publique fixe du pare-feu |
Deux règles guident ce plan. D'abord, le bureau (10.10.0.0/16) et le VPC (10.20.0.0/16) ne doivent pas se chevaucher, sinon le VPN ne peut pas router entre eux. Ensuite, évitez 192.168.0.0/24 et 192.168.1.0/24 pour le bureau : beaucoup de routeurs domestiques les utilisent, et le personnel en télétravail entrerait en conflit avec eux sur un VPN client.
Le pare-feu route entre les VLAN, c'est donc aussi là que vit la politique :
| De | Vers | Autorisé |
|---|---|---|
| Personnel | Serveurs et imprimantes | Ports de partage de fichiers et d'impression |
| Personnel | Sous-réseau privé cloud | HTTPS ; SSH uniquement depuis le groupe admin |
| Invités | Tout ce qui est interne | Rien ; Internet uniquement |
| Sous-réseau privé cloud | Bureau | Réponses uniquement (stateful) |
Le VPN site à site en un paragraphe
Un VPN IPsec utilise IKE, sur le port UDP 500, pour authentifier les pairs et convenir des clés, et ESP, protocole IP 50, pour transporter le trafic chiffré ; UDP 4500 est utilisé quand un NAT se trouve sur le chemin. Sur AWS, chaque connexion Site-to-Site VPN dispose de deux tunnels avec des adresses IP publiques différentes, qui aboutissent sur une passerelle privée virtuelle ou une passerelle de transit ; configurez les deux sur votre pare-feu pour qu'une maintenance sur un tunnel ne coupe pas le bureau. Côté bureau, il faut une IP publique fixe. Le routage est statique ou dynamique avec BGP, et les tables de routage du VPC ont besoin de routes de retour vers 10.10.0.0/16, propagées depuis la passerelle privée virtuelle ou ajoutées à la main.
Le diagramme
Contenu du diagramme
- Internet
- Office firewall
- Core switch
- Wi-Fi access point
- VLAN 30 · Servers
- File server
- VLAN 10 · Staff
- Staff laptops
- VLAN 20 · Guests
- Guest devices
- Cloud VPC
- Private subnet
- App server
- Managed database
- Links
- ISP uplink · 203.0.113.10
- trunk: VLAN 10, 20, 30
- PoE + trunk
- SSID Office
- SSID Guest
- IPsec site-to-site VPN · 2 tunnels
Comment le lire :
- En haut à gauche, la périphérie. Le pare-feu du bureau porte l'adresse publique fixe et sert de pair IPsec. Il route entre les trois VLAN et applique la table de politique ci-dessus.
- Au milieu, le LAN du bureau. Le commutateur de cœur transporte les VLAN 10, 20 et 30 en trunk. Le point d'accès reçoit l'alimentation et un trunk du commutateur, et associe le SSID du personnel au VLAN 10 et le SSID invités au VLAN 20.
- À droite, le cloud. Le lien en pointillés est le VPN IPsec, deux tunnels, vers le VPC. Le serveur d'application et la base de données gérée se trouvent dans un sous-réseau privé sans route depuis Internet.
- La légende explique les styles de trait : Ethernet, Wi-Fi, alimentation par Ethernet et WAN.
Ce qu'il faut étiqueter
- La plage et l'ID de VLAN de chaque segment. Une boîte nommée « Réseau du personnel » sans 10.10.10.0/24 ne peut être vérifiée par rapport à rien.
- Les passerelles et les pairs VPN. Quel équipement route chaque segment, et quelles adresses publiques forment le tunnel.
- Ce qui peut franchir une frontière. Mettez la politique sur les liens ou dans un tableau à côté du diagramme, pas seulement dans la configuration du pare-feu.
- L'association entre SSID et VLAN pour chaque réseau sans fil.
- Le sens d'initiation quand il compte, par exemple le fait que le sous-réseau cloud ne fait que répondre.
Ce qu'il faut laisser de côté
- Chaque portable et chaque téléphone. Un nœud par type d'appareil et par segment suffit.
- Les couleurs de câble et les numéros de port sur un diagramme logique. Ils ont leur place dans le diagramme physique.
- Les détails internes du fournisseur cloud. Les extrémités du VPN appartiennent à la passerelle privée virtuelle ; inutile de dessiner le côté AWS du tunnel.
Utilisez une légende
Les styles de trait portent du sens sur un diagramme réseau, alors expliquez-les. Une petite légende avec Ethernet, Wi-Fi, alimentation par Ethernet, WAN et VPN s'ajoute en une minute et évite à chaque nouveau lecteur de deviner. Si vous colorez les segments, dites aussi ce que signifient les couleurs.
Le garder à jour
Les diagrammes réseau se périment au premier changement non annoncé. Faites du diagramme une partie du changement : quand quelqu'un ajoute un VLAN, modifie une règle de pare-feu ou ajoute un tunnel, le ticket de changement renvoie au diagramme mis à jour, et un relecteur vérifie les deux. Des diagrammes d'architecture qui ne se périment pas décrit un workflow pour exactement cela. Pour le côté cloud plus en détail, voyez le guide du diagramme de VPC AWS, et pour remplacer le réseau de bureau à plat par un accès fondé sur l'identité, le diagramme d'architecture zero trust.
Le construire dans Archboard
- Connectez-vous avec Google ou GitHub et créez un diagramme.
- Depuis le pack Réseau, ajoutez des nœuds Internet, Pare-feu, Commutateur et Sans fil pour la périphérie et le LAN du bureau.
- Ajoutez trois cadres Sous-réseau du pack Réseau pour les VLAN 10, 20 et 30, chacun avec sa plage dans le champ CIDR du cadre, et placez dans chacun un nœud Appareil ou Serveur : portables du personnel, appareils invités, serveur de fichiers.
- Ajoutez un cadre VPC du pack Réseau avec un cadre Sous-réseau à l'intérieur, et placez dans le sous-réseau un nœud Instance de calcul et un nœud Base de données gérée du pack Cloud.
- Reliez les nœuds et définissez le type de liaison de chaque lien (Ethernet, Wi-Fi, PoE ou WAN). Dessinez le VPN comme un lien en pointillés du pare-feu vers le VPC.
- Ajoutez une Légende réseau du pack Réseau pour les types de liaison.
L'exemple utilise 15 nœuds de diagramme et reste dans les limites de l'offre Free. La page du cas d'usage réseau montre ce que couvre encore le pack Réseau.
FAQ
Quelle est la différence entre un diagramme réseau et un diagramme de topologie réseau ? Les deux termes sont souvent employés indifféremment. Un diagramme de topologie met l'accent sur la façon dont les segments et les appareils sont reliés ; un diagramme de topologie logique y ajoute les plages d'adresses, le routage et la politique.
Le diagramme doit-il montrer les adresses IP ? Montrez les plages de chaque segment et les adresses des passerelles et des pairs VPN. Les adresses de chaque hôte ont leur place dans un outil de gestion des adresses IP.
Pourquoi mettre les invités sur un VLAN séparé ? Pour que le pare-feu puisse leur donner Internet et rien d'autre. Sur un segment partagé, un appareil invité peut joindre les imprimantes, les partages de fichiers et tout ce qui fait confiance au réseau local.
Ai-je besoin de deux tunnels VPN ? Sur AWS, chaque connexion est fournie avec deux tunnels, et les deux doivent être configurés sur votre équipement, pour que l'un transporte le trafic pendant que l'autre est en maintenance.
À quelle fréquence mettre à jour un diagramme réseau ? À chaque changement qui touche l'adressage, le routage ou les règles du pare-feu. Liez le diagramme au processus de changement plutôt qu'à un calendrier.