,
,
,
In het vorige artikel in deze serie, Multi-VLAN Trunking op Synology DSM 7 - Achtergrond en filosofie, hebben we uitgelegd waarom deze serie bestaat en waarom we Synology blijven gebruiken ondanks de beperkingen in netwerkbeheer. Dit artikel (Deel A) is de ontwerp-deep-dive: het netwerkmodel dat de implementatie voorspelbaar en beheersbaar maakt, en de operationele “valkuilen” die een multi-VLAN Synology zich laten gedragen alsof het systeem “spookt”.
Dit is geen vendor-specifieke handleiding voor het configureren van VLAN-trunks op een MikroTik-, Cisco-, Juniper- of Ubiquiti-switch. We gaan ervan uit dat u al weet hoe u een access-poort en een trunk-poort maakt (of dat u een model-specifieke handleiding kunt opzoeken). Wat we wel doen, is de ontwerpkeuzes toelichten die complexiteit verminderen en veel voorkomende faalmodi voorkomen wanneer DSM, packages, VMM, IPv6 en split-horizon DNS allemaal samenkomen in dezelfde omgeving.
Wilt u vooruit? Als u vooral hier bent voor de praktische implementatie, dan kunt u direct door naar het volgende deel: Multi-VLAN Trunking op Synology DSM 7 - DSM 7.2.2 implementatie. Het netwerkontwerp dat we in dit artikel beschrijven is ons productie-ontwerp en maakt de uiteindelijke setup makkelijker te begrijpen, maar het is geen vereiste voor de kernaanpassing: de aanpak in Deel 3 is breed toepasbaar voor iedereen die meerdere VLANs op één NIC onder DSM 7 wil, zonder VMM op te geven.
De meeste homelabs en kleine professionele netwerken beginnen eenvoudig en groeien organisch. Ze starten zelden met VLANs. Ze beginnen met een vlak netwerk, een unmanaged switch en een consumenten-“router” die in werkelijkheid een bundel apparaten in één kastje is (NAT, firewall, switch, Wi-Fi access point) en niet bijzonder goed is in één van die taken zodra het netwerk veeleisender wordt.
De eerste echte “segmentatie” ontstaat vaak nadat er iets stuk gaat: een testopstelling trekt het netwerk onderuit, een misdragend apparaat floodt het netwerk met verkeer, of een wijziging moet gevalideerd worden zonder dat u het risico neemt dat het hele netwerk (of bijvoorbeeld thuis ineens geen televisie meer) de dupe wordt. De snelle oplossing is meestal fysieke scheiding: nog een switch kopen, een extra access point toevoegen, of zelfs een tweede router plaatsen om een apart testnetwerk, gaming-netwerk of “labhoek” te maken. Dat werkt—totdat het niet meer werkt: poorten raken vol, switches vermenigvuldigen, kabels worden onoverzichtelijk, het energieverbruik stijgt en het netwerk wordt lastiger te doorgronden. De stap naar managed switches en VLANs volgt dan vaak uit noodzaak, en soms uit nieuwsgierigheid.
We zien dit patroon al ongeveer 25 jaar: bij klanten, in community-omgevingen en in onze eigen netwerken. We hebben het vaak helpen ontwarren, en we zijn er zelf ook zo in gegroeid. In de vroege jaren 90 draaiden we twee inbel-bulletinboards (BBSen) en een FidoNet-node: gebruikers belden met een modem in op een menu-gedreven systeem om berichten te lezen en plaatsen, bestanden uit te wisselen en mail te versturen.
In die tijd betekende “internet access” niet automatisch “websites browsen”. Voor veel mensen betekende het toegang tot specifieke netwerkdiensten: e-mail, Usenet, file transfer, of het navigeren door gestructureerde informatiesystemen zoals Gopher. Zelfs met directe verbindingen binnen universiteiten of bedrijfsnetwerken was de ervaring vaak dienst-gericht en bemiddeld door gateways, catalogi en client-applicaties—niet door een grafische browser. Toen het World Wide Web opkwam en Mosaic HTML toegankelijk maakte voor een veel breder publiek, verschoof het zwaartepunt en groeiden die service-gateways snel door naar volwaardige internettoegang in de moderne betekenis.
Die machine draaide eerst DrDOS, daarna Windows NT 3.5, kortstondig NT 4 en OS/2 Warp, voordat we overstapten op Red Hat Linux. Rond 1998 is het platform vervangen door een Pentium 233MMX, bewust teruggeklokt (om energieverbruik te beperken). De details zijn gedateerd, maar de les niet: voordat u bij VLANs uitkomt, lossen de meeste mensen (wij ook) echte problemen op door hardware toe te voegen en “aparte” netwerken te bouwen. VLANs en policy routing zijn wat u adopteert zodra u de flexibiliteit wilt behouden, maar de sprawl wilt elimineren.
Ons ontwerpdoel is het tegenovergestelde: consolideren waar het veilig kan, en het resultaat deterministisch maken. Eén 10GbE trunk van de NAS naar een managed switch kan meerdere VLANs netjes en met hoge bandbreedte dragen. Het voorkomt ook dat u vijf fysieke poorten op de NAS en vijf switchpoorten aan de andere kant moet opofferen. In een omgeving die 24/7 aan staat, betekent dat: minder apparatuur en minder energieverbruik.
Er zit een belangrijke nuance: “een trunk” is op zichzelf geen ontwerp. De trunk is pas nuttig als de host-stack (DSM + packages + VMM + Linux) VLAN-netwerken op een stabiele en goed te debuggen manier exposeert. De rest van dit artikel gaat over de ontwerpkeuzes die dat waarmaken.
We segmenteren op functie. In onze omgeving omvat dat onder meer:
Meerdere fysieke locaties zijn verbonden via site-to-site VPN-links (in ons geval IPsec). De precieze VLAN-nummers zijn minder belangrijk dan het principe: segmentatie gaat niet alleen over security; het gaat ook over stabiliteit en observeerbaarheid. Als er iets stuk gaat, wilt u dat de blast radius klein is en dat de symptomen te herleiden zijn.
Segmentatie is alleen betekenisvol als er handhaving is waar dat nodig is. We handhaven beleid op meerdere lagen:
Het praktische voordeel van deze aanpak is dat “toevallige connectiviteit” veel moeilijker wordt. Als iets opeens met het internet praat, dan is het óf expliciet toegestaan, óf het is een configuratiefout die u kunt detecteren en corrigeren.
Complexe netwerken falen op voorspelbare manieren wanneer identiteit ambigu is, ook als de symptomen willekeurig aanvoelen tijdens het troubleshooten. Daarom gebruiken we een zelfbeschrijvende conventie waarbij de VLAN-ID als anker dient voor meerdere lagen:
192.168.<VLANID>.0/24).2a10:3781:2271:<VLANID>::/64).90:09:D0:6E:D7:<VLANID>).Dit is geen esthetiek. Dit is operationele engineering: dezelfde identifier komt terug in L2, L3 en naamconventies, waardoor het lastig wordt om per ongeluk verkeerd te interpreteren waar u naar kijkt.
We draaien split-horizon DNS. Dat betekent dat de DNS-“view” verschilt per netwerkcontext: per VLAN, maar ook per site-to-site VPN en voor externe/public resolutie. Een interne hostname kan naar een ander adres resolven afhankelijk van waar u queryt. Dat is normaal en wenselijk in gesegmenteerde omgevingen, maar het introduceert een veel voorkomende faalmodus: als een host de verkeerde resolver gebruikt voor zijn interface/VLAN (of VPN-context), dan kan een interne naam resolven naar een adres dat in een ander segment thuishoort.
Onze kern-infrastructuurnamen zijn:
| 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> |
Operationele regel: elke interface moet de juiste DNS-servers gebruiken voor zijn VLAN-view. Zo niet, dan krijgt u extreem verwarrend gedrag: een hostname resolve “correct” maar naar het verkeerde VLAN, en de symptomen lijken op firewall- of routingproblemen terwijl de echte oorzaak name resolution is.
Vorige: Multi-VLAN Trunking op Synology DSM 7 - Achtergrond en filosofie
Volgende: Multi-VLAN Trunking op Synology DSM 7 - Diepgaande netwerkontwerp Deel B
Copyright © 2026, ASK-Solutions
