====== Architecture Homelab ======
Cette page documente la topologie physique et logique de mon réseau personnel.
===== Diagramme Réseau =====
{{network:schema_reseau_crs310_v3.png?600}}
===== Plan d'adressage (IPAM) =====
^ VLAN ID ^ Nom du réseau ^ Sous-réseau (CIDR) ^ Passerelle (OPNsense) ^ Remarques ^
| VLAN 10 | Trusted | 192.168.10.0/24 | 192.168.10.1 | Réseau principal |
| VLAN 20 | Guests | 192.168.20.0/24 | 192.168.20.1 | Isolé du réseau Trusted |
| VLAN 30 | IoT_Gaming | 192.168.30.0/24 | 192.168.30.1 | Objets connectés, consoles de jeu, accès internet restreint |
| VLAN 40 | Homelab | 192.168.40.0/24 | 192.168.40.1 | Proxmox et services homelab |
^ Équipement ^ IP Fixe ^ Remarques ^
| OPNsense (LAN) | 192.168.10.1 | Interface igc1 |
| OPNsense (WAN) | DHCP (Publique) | Interface igc0 (Liée au port 4 Freebox), lien 2.5GbE |
| MikroTik CRS310-8G+2S+IN | 192.168.10.2 | Interface vlan10-mgmt, remplace le Cisco 2960 |
| TP-Link EAP225 | 192.168.10.5 | Géré en Trunk, VLAN 10 natif (untagged), VLAN 20/30 tagués |
| Proxmox | (VLAN 40) | Access sur ether2 du CRS310, passage en trunk prévu à terme |
===== Switch MikroTik CRS310-8G+2S+IN =====
Remplace le Cisco Catalyst 2960 (décommissionné). RouterOS 7.24.2. Modèle de VLAN basé sur un bridge unique avec table VLAN centralisée (voir note ci-dessous sur la différence avec Cisco IOS).
^ Port ^ Rôle ^ Mode ^ PVID ^ VLANs taguées ^ VLAN untagged ^
| ether1 | AP TP-Link EAP225 | Trunk avec natif | 10 | 20, 30 | 10 |
| ether2 | Proxmox | Access | 40 | — | 40 |
| ether3 | Poste utilisateur | Access | 10 | — | 10 |
| ether4 | Uplink OPNsense | Trunk pur | 1 (neutre) | 10, 20, 30, 40 | — |
| ether5–8, sfp-sfpplus1–2 | Libres | — | 1 | aucune | aucune |
**Note technique — modèle RouterOS vs Cisco IOS :** RouterOS ne fonctionne pas port par port comme l'IOS (''switchport mode access/trunk''). Un bridge unique porte une **table VLAN centralisée** qui déclare, pour chaque VLAN ID, quels ports sont ''tagged='' et lesquels sont ''untagged=''. Le **PVID** par port ne classe que le trafic untagged **entrant** — il n'a aucun effet sur le trafic sortant taggé. Un port ne peut jamais être à la fois ''tagged='' et ''untagged='' pour la même VLAN.
Configuration de référence (état de production) :
/interface bridge
add admin-mac=38:32:7A:32:8C:9A auto-mac=no name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=vlan10-mgmt vlan-id=10
/interface bridge port
add bridge=bridge comment=Link-To-Wifi interface=ether1 pvid=10
add bridge=bridge comment=PROXMOX interface=ether2 pvid=40
add bridge=bridge comment=Poste-utilisateur interface=ether3 pvid=10
add bridge=bridge comment=Uplink-OPNsense interface=ether4
/interface bridge vlan
add bridge=bridge comment=VLAN-TRUSTED tagged=ether4 untagged=ether3,ether1 vlan-ids=10
add bridge=bridge comment=VLAN-GUEST tagged=ether1,ether4 vlan-ids=20
add bridge=bridge comment=VLAN-IOT tagged=ether1,ether4 vlan-ids=30
add bridge=bridge comment=VLAN-HOMELAB tagged=ether4 untagged=ether2 vlan-ids=40
/ip address
add address=192.168.10.2/24 interface=vlan10-mgmt network=192.168.10.0
/ip route
add dst-address=0.0.0.0/0 gateway=192.168.10.1
/ip dns
set servers=192.168.10.1
===== Troubleshooting & Procédures =====
==== Perte de connectivité WAN sur OPNsense ====
**Symptôme :** Après le passage de la Freebox en mode "Bridge", l'interface WAN (igc0) d'OPNsense ne récupère plus d'adresse IP publique et la connexion internet est coupée.
**Explication :** Il ne s'agit pas d'un problème de configuration logicielle sur OPNsense, mais d'une limitation matérielle de la Freebox en mode bridge.
**Résolution :**
- Côté physique : Le câble réseau reliant l'interface WAN de l'OPNsense à la Freebox doit **impérativement être branché sur le port Ethernet 4** de la Freebox.
{{adminsys:freebox_ultra_back_cercle.png?400}}
- Redémarrer l'interface WAN ou redémarrer OPNsense si le bail DHCP public n'est pas renouvelé immédiatement.
==== Impossible de joindre un SSID spécifique (ex: Trusted) ====
**Symptôme :** Les appareils se connectent au SSID "Trusted" diffusé par l'AP TP-Link EAP225, mais n'obtiennent pas d'adresse IP (pas de DHCP), ou récupèrent une IP hors plan d'adressage (ex: 192.168.2.x) — signe que l'AP est retombé en fallback DHCP/NAT usine faute de VLAN natif joignable.
**Explication :** L'AP envoie le SSID Trusted en trafic **untagged** sur son port trunk. Si aucune VLAN n'est déclarée untagged sur ce port côté switch, ce trafic est classé dans un VLAN neutre inexistant et droppé — l'AP ne reçoit plus de réponse DHCP et bascule en mode autonome.
**Résolution (MikroTik CRS310) :**
- Déclarer le VLAN 10 comme untagged **en plus** de son statut tagué existant sur le port trunk (ether1), en une seule commande pour éviter le conflit ''tagged/untagged'' :
/interface bridge vlan set [find vlan-ids=10] tagged=ether4 untagged=ether3,ether1
/interface bridge port set [find interface=ether1] pvid=10
**Résolution (ancien Cisco 2960, conservé pour référence) :**
- Déclarer le VLAN Trusted (VLAN 10) comme **VLAN natif** (Native VLAN) sur le port Trunk du switch Cisco.
- //Exemple de configuration Cisco ://
Switch> enable
Switch# configure terminal
Switch(config)# interface FastEthernet 0/1
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk native vlan 10
Switch(config-if)# end
Switch# copy running-config startup-config
==== PVID appliqué par erreur sur un port trunk déjà taggé (MikroTik) ====
**Symptôme :** Perte de connectivité sur un port trunk après ajout d'un PVID, alors que le port fonctionnait avant.
**Explication :** Ajouter un PVID correspondant à une VLAN sur un port déjà listé en ''tagged='' (et pas ''untagged='') pour cette même VLAN crée une asymétrie : le trafic entrant est classé par le PVID, mais le trafic sortant reste taggé. Un client qui ne parle pas 802.1Q (PC, AP mal configuré) perd la connectivité.
**Règle à retenir :** un port trunk pur (tagged sur toutes ses VLANs) n'a besoin d'aucun PVID pertinent. Un port trunk avec VLAN native doit avoir cette VLAN à la fois en ''untagged='' dans la table **et** en PVID sur le port — jamais l'un sans l'autre.
**Résolution :** rebrancher temporairement sur un port access fonctionnel (ex: ether3) pour reprendre la main via l'IP de management, puis corriger :
/interface bridge port set [find interface=] pvid=1
==== Lien 2.5GbE négocié en 1Gbps (OPNsense ↔ CRS310) ====
**Symptôme :** ''/interface ethernet monitor'' sur le port switch affiche ''rate=1Gbps'' malgré un CRS310 (8 ports 2.5GBASE-T) et une interface OPNsense toutes deux capables de 2.5G, avec du câblage Cat6 sur toute l'infra.
**Explication :** Le port switch annonçait correctement ''advertising: 2.5G-baseT'', mais ''link-partner-advertising'' ne montrait que ''1G-baseT-full'' — le plafond venait de la négociation côté OPNsense (interface LAN laissée en médiat forcé ou en mauvais port), pas du switch ni du câblage.
**Résolution :**
- Dans OPNsense : **Interfaces → [interface concernée] → Media**, repasser en ''autoselect'' (ou forcer ''2.5Gbase-T '' si l'autoselect ne suffit pas).
- Vérifier après application : ''ifconfig media'' côté OPNsense, et ''/interface ethernet monitor ether4'' côté CRS310 — les deux doivent annoncer et négocier 2.5G.
- Cause fréquente sur ce type de souci : mauvais port physique assigné à l'interface LAN dans **Interfaces → Assignments**, notamment quand la carte réseau expose plusieurs ports de vitesses différentes.