,
,
,
Als je zoekt op “multiple VLANs on Synology”, kom je veel discussies tegen die vooral over DSM 5 en DSM 6 gaan. Veel van die aanpakken werken niet meer, of worden fragiel zodra je DSM 7, Virtual Machine Manager en Open vSwitch introduceert. DSM 7 kan nog steeds een zeer capabel platform zijn, maar het netwerkmodel is uitgesproken en wordt sterk gestuurd door wat de GUI wel en niet aanbiedt.
Deze serie is geschreven voor technische lezers die comfortabel zijn op de command line en die graag sleutelen aan home labs of kleine professionele omgevingen. Het doel is niet om Synology te bashen, en ook niet om een “alles Linux” alternatief te pushen. Het doel is om de beperkingen die wij tegenkwamen uit te leggen, de ontwerpprincipes die wij in echte netwerken hanteren, en de praktische implementatie die ervoor zorgt dat één fysieke trunk meerdere VLAN’s betrouwbaar kan dragen voor zowel DSM packages als virtuele machines.
Wij gebruiken Synology DiskStations en RackStations sinds 2010, naast andere storage- en virtualisatieplatformen. Niet omdat Synology perfect is, maar omdat in de dagelijkse praktijk van kleine organisaties en technische hobbyisten de balans telt: gebruiksgemak, stabiliteit, onderhoudbaarheid, stroomverbruik en de mogelijkheid om te debuggen als er iets stuk gaat.
Er zijn een aantal redenen waarom wij bij Synology blijven:
We hebben ook onze frustraties. Synology networking is niet “proper networking” zoals een Linux netwerk engineer dat zou definiëren. Licensing en “supported hardware” beleid kunnen frustrerend zijn. Sommige modellen hebben een geschiedenis met problemen in voedingen en de supportervaring daaromheen is niet altijd even indrukwekkend. Dat is geen geheim en ook niet uniek voor Synology. We kiezen nog steeds voor Synology omdat de totale afweging voor onze omgevingen en onze klanten werkt, en omdat we het op een professioneel niveau kunnen beheren.
Een andere frustratie is hoe Active Backup for Business vaak als een backup product wordt gepositioneerd. In onze ervaring is het beter te omschrijven als een restore convenience. Als je een directory moet terugzetten of een workstation moet herstellen na een failure, kan het prima zijn. Maar het mist eigenschappen die een “echte backup oplossing” nodig heeft voor verificatie, vergelijking en forensische restore workflows. Als er iets misgaat in een grote dataset wil je vaak vragen kunnen beantwoorden als: “wat is er veranderd”, “wat is er verdwenen” en “wat is er door malware aangepast”. Als tooling die vragen niet kan beantwoorden zonder veel handmatig werk, dan is het geen complete backup oplossing.
Wij draaien intern meerdere Synology RackStations. Eén daarvan fungeert als project fileserver. Voor dat systeem hebben we ook in nieuwe hardware geïnvesteerd: een RS1221+ met een 10GbE NIC en NVMe SSD’s als read-write cache. Dit systeem draagt het dagelijkse gewicht van projecten, documentatie en gedeelde datasets. Een praktisch detail dat voor veel home lab bouwers relevant is: Synology ondersteunt op verschillende modellen officieel geen 64 GB RAM, maar in de praktijk kun je 64 GB betrouwbaar draaien door het standaardgeheugen te vervangen en een matched pair te gebruiken. Onze voorkeur is een bewezen matched pair van 2 x 32 GB dual-channel, 2666 MHz, unbuffered, 1.2V ECC modules met lagere thermische verliezen.
Een andere RackStation gebruiken we voor opslag van videobeelden van Axis security camera’s. We gebruiken hiervoor expliciet geen Surveillance Station; de camera’s schrijven naar storage en footage wordt vanaf meerdere locaties naar een centraal systeem gesynchroniseerd over VPN. Het camera-retentievolume is non-RAID. Het ontwerpdoel is om footage een beperkte periode te bewaren (weken), het opslagmodel voorspelbaar te houden en het trade-off te accepteren dat deze dataset niet “business-critical voor altijd” is.
De RackStation waar deze serie over gaat is onze nieuwe dedicated virtualisatie host; een RS1822+ met dezelfde upgrades als de andere nieuwe RackStation. We hebben virtuele machines die eerder verspreid draaiden over meerdere systemen naar deze nieuwe unit verplaatst om stroomverbruik en operationele complexiteit te verlagen. Tegelijkertijd hebben we oudere RackStations geroteerd naar andere rollen en locaties, en legacy systemen uitgefaseerd die operationeel niet meer logisch waren (waaronder een DS210j). Oudere hardware hebben we waar dat zinvol was nog in dienst gehouden, maar alleen nadat bekende issues waren aangepakt en het systeem naar een niveau was gebracht waar we het met vertrouwen kunnen beheren.
Veel home lab en small business netwerken ontstaan door apparaten op te stapelen: hier een switch, daar nog een firewall, en vervolgens meer poorten, meer voedingen en meer idle power draw. Wij proberen het tegenovergestelde te ontwerpen: minder apparaten, minder poorten en minder altijd-aan watts. Dat is één van de redenen waarom wij oplossingen vermijden die “vijf fysieke NICs voor vijf VLANs” vereisen terwijl één trunk hetzelfde kan.
Ons netwerk is gesegmenteerd. We gebruiken een management VLAN, een VoIP VLAN, een IoT devices VLAN (printers, camera’s, 3D printers en vergelijkbare devices), een KNX VLAN en een workstation VLAN (computers, laptops, tablets). Meerdere fysieke locaties zijn met elkaar verbonden via site-to-site VPN.
We filteren op iedere laag waar het ertoe doet, en we doen dat expliciet. We draaien meerdere EdgeRouters met verschillende rollen: één dedicated voor de internet edge, één dedicated voor VPN en inter-VLAN routing, en daar passen we strikte ingress en egress filtering toe. Op onze servers en RackStations hanteren we een custom firewall policy via systemd die default deny is en alleen expliciet benodigde traffic toestaat. Dit omvat ook default-deny voor egress; iets dat de Synology built-in firewall niet als first-class feature biedt. Daarbovenop gebruiken we een dedicated security gateway die outbound web traffic op applicatieniveau (HTTP/HTTPS) controleert. Camera’s, printers en veel IoT devices hebben geen directe internettoegang; ze kunnen alleen expliciet toegestane bestemmingen bereiken via die gateway.
Voor naming en addressing gebruiken we een conventie die bewust self-describing is. De VLAN ID is het anker: die matcht met het IPv4 subnet, matcht met de IPv6 prefix, en is verwerkt in MAC address schemes voor infrastructure devices. Dat doen we niet voor de vorm. We doen dit omdat debugging snel en ondubbelzinnig moet zijn. Als je naar ARP, spanning tree, neighbour discovery of link-local traffic kijkt, wil je direct herkennen waar je naar kijkt.
We draaien split-horizon DNS. Onze primaire en secundaire DNS servers heten aphex en polygon, en onze security gateway heet joyrex. Dat zijn niet “de enige servers op het netwerk” (we draaien ook veel andere systemen, zoals rephlex, uziq, planetmu, kid, strider, tusken, filter, lfo, warp en cylob), maar het zijn wel de infrastructuurnamen die ertoe doen voor name resolution, routing behaviour en gecontroleerde egress. Hun IPv4 adressen volgen per VLAN een consistent patroon:
| Rol | Host | IPv4 (per VLAN) | IPv6 (per VLAN) | MAC (per VLAN) |
|---|---|---|---|---|
| Primaire DNS | aphex | 192.168.<VLANID>.5 |
2a10:3781:2271:<VLANID>::5 |
90:09:D0:6E:D7:<VLANID> |
| Security gateway / proxy | joyrex | 192.168.<VLANID>.6 |
2a10:3781:2271:<VLANID>::6 |
08:00:27:C8:44:<VLANID> |
| Secundaire DNS | polygon | 192.168.<VLANID>.7 |
2a10:3781:2271:<VLANID>::7 |
90:09:D0:72:43:<VLANID> |
IPv6 is geen afterthought. We waren vroege adopters: we draaien al decennia IPv6 en hebben bijgedragen aan het verbeteren van IPv6 adoptie in software, hardware en echte netwerken. Op kantoor hadden we IPv6 zo’n 25 jaar geleden al werkend, inclusief vroege deployments die afhankelijk waren van IPv6 transition mechanisms die NAT konden traversen voordat ze gestandaardiseerd waren; aanpakken die inmiddels lang obsolete zijn. Tegenwoordig draaien we router advertisements (RA) die prefixes adverteren en het gebruik van DHCPv6 signaleren. DHCPv6 gebruikt DUIDs. Infrastructure devices krijgen stabiele toewijzingen (via DHCP reservations of handmatige configuratie) zodat links die up/down gaan geen address drift veroorzaken. Workstations krijgen dynamische leases in dedicated sub-ranges voor IPv4 en sub-prefixes voor IPv6. Zowel DHCP als DHCPv6 propagaten de default gateway en distribueren routing information die relevant is voor VLAN en VPN reachability.
Deze serie gaat niet proberen om de basis van VLAN trunk configuratie op MikroTik, Cisco, Juniper of Ubiquiti switches uit te leggen. We gaan ervan uit dat de lezer een access port en trunk port kan configureren, of een vendor-specifieke how-to kan opzoeken. Wat we wel uitleggen is hoe deze netwerkontwerpkeuzes samenhangen met DSM 7, Open vSwitch en virtual machine networking.
Zonder modificaties kan DSM niet uitdrukken wat wij via de GUI nodig hebben: meerdere VLAN’s op één trunk die niet alleen bruikbaar zijn voor DSM zelf, maar ook voor packages en voor Virtual Machine Manager. DSM kan in de GUI één VLAN ID aan een interface koppelen. Het biedt geen nette GUI voor “meerdere VLAN IDs op één poort”, en ook niet voor het aanmaken van virtuele interfaces. Handmatig extra configuratiebestanden maken onder /etc/sysconfig/network-scripts/ zoals veel gebruikers dat op oudere DSM versies deden, “werkt ook niet meer gewoon” op nieuwere DSM versies.
Zodra Virtual Machine Manager is geïnstalleerd, vereist DSM dat je Open vSwitch activeert. Dat is een logische default voor een virtualisatiehost, maar het verandert ook het speelveld. De grootste hobbel is niet één enkele beperking; het is een combinatie:
linux-4.4.x.txz voor jouw platform uit de GPL sources gepubliceerd door Synology, extract de archive en zoek naar ovs_eth of syno_ in de bestanden onder linux-4.4.x/net/openvswitch/.Met andere woorden: dit is niet simpelweg “maak ethX.100 aan en klaar.” Op DSM 7 moet de oplossing zo ontworpen zijn dat DSM de interfaces als online toont, packages ze niet negeren of verkeerd interpreteren, en VMM networks er op een voorspelbare manier aan kan koppelen.
Een klein maar belangrijk resultaat van ons naming scheme is dat DSM duidelijker te bedienen wordt. DSM toont interfaces als “LAN1…LAN5” voor de base NICs. We namen VLAN-facing interfaces bewust zo, dat DSM ze toont als “LAN20” voor VLAN 20, “LAN30” voor VLAN 30, enzovoort. Intern sluit dit aan bij ons maintenance- en segmentatiemodel (bijvoorbeeld: LAN5 is ons management VLAN 10, en LAN20/LAN30 mappen direct naar VLAN 20/VLAN 30). Dit klinkt cosmetisch totdat je onder druk moet troubleshooten. Duidelijke interface identity voorkomt fouten, en in gesegmenteerde netwerken kunnen fouten outages worden.
Dit is een driedelige serie, met de mogelijkheid om Part 2 of Part 3 op te splitsen in A/B als de stof te groot wordt.
Part 3 bevat code en configuratie die low-level networking beïnvloedt. Voordat je dit op je eigen NAS implementeert: plan recovery. In onze omgeving houden we een unfirewalled management interface klaar om in te pluggen, houden we een duidelijke gateway priority order aan, activeren we DSM’s “multiple gateways” behaviour bij multi-homed gebruik, en houden we console access als last resort. We passen patches na DSM upgrades ook niet automatisch toe; we doen handmatige merges en tracken upstream changes met vendor branches en tags in CVS. Daarmee blijft het systeem onderhoudbaar terwijl DSM evolueert.
Als deze serie je ongemakkelijk maakt, is dat geen failure. Het doel is om de trade-offs expliciet te maken en een pad te tonen dat stabiel, energiezuinig en operationeel sane is voor mensen die meerdere VLAN’s op één Synology trunk willen zonder VMM op te geven.
Volgende: Multi-VLAN Trunking op Synology DSM 7 - Diepgaande netwerkontwerp Deel A
Copyright © 2026, ASK-Solutions
