Nederlands, English
Doneer aan ASK-Solutions (de IRADIS Foundation), Bekijk onze video's, Steun ons op Patreon
Aanmelden

Multi-VLAN Trunking op Synology DSM 7 - Diepgaande netwerkontwerp Deel B

Geschreven door ASK-Solutions in Projectnotities

Deel 2B: deze helft van de deep dive gaat over adressering (IPv4 en IPv6), policy routing, route-distributie en MAC-identiteit. Als u Deel 2A nog niet gelezen heeft, begin daar dan: dat deel behandelt het segmentatiemodel, de identiteitconventies en split-horizon DNS.

Navigatie in deze serie: Deel 1 · Deel 2A · Deel 2B · Deel 3

Op deze pagina:

IPv4-adressering: stabiele infrastructuur, dynamische clients

IPv4 is rechttoe rechtaan, maar het loont om er discipline in aan te brengen:

  • Infrastructuurapparaten en sleutel-werkplekken
    Routers, switches, servers en kernservices ontvangen bewust stabiele adressen. In ons schema zijn .5, .6 en .7 per VLAN gereserveerd voor aphex/joyrex/polygon.
  • Gedeelde randapparatuur en IoT-apparaten
    Krijgen dynamische leases uit een gedefinieerde sub-range. Dat houdt asset management eenvoudig en voorkomt dat er per ongeluk overlap ontstaat met infrastructuurranges.

Stabiele adressering is meer dan gemak. Het beïnvloedt firewallbeleid, monitoring, reverse DNS en uw vermogen om vragen te beantwoorden zoals “wat is er veranderd” zonder te gokken.

IPv6-model: RA + DHCPv6, op basis van DUID, voorspelbare link-local

IPv6 is in onze omgeving geen bijzaak. We draaien IPv6 al decennia en hebben bijgedragen aan betere IPv6-adoptie in software, hardware en echte netwerken. In ons kantoor hadden we ongeveer 25 jaar geleden al IPv6 werkend, inclusief vroege deployments die vertrouwden op IPv6-transitiemechanismen die NAT konden traverseren lang voordat ze mainstream werden—benaderingen die nu al lang obsoleet zijn.

Vandaag is ons IPv6-model:

  • Router Advertisements (RA)
    Adverteren het on-link prefix en geven aan dat DHCPv6 gebruikt wordt.
  • DHCPv6
    Biedt stateful adressering en options, en gebruikt DUID als client identifier.
  • Link-local adressen
    Zijn waar mogelijk EUI-64-afgeleid, wat betekenisvol wordt omdat we bewust deterministische MAC-patronen gebruiken. Als u neighbour discovery-verkeer bekijkt, zijn de link-local identiteiten herkenbaar.

We gebruiken stateful stabiele toewijzing voor servers, routers en switches (via DHCPv6-reservaties of handmatige configuratie) zodat infrastructuur zijn adres-identiteit niet “kwijtraakt” als links flappen. Infrastructuurapparaten en sleutel-werkplekken krijgen stabiele toewijzingen (via DHCPv6-reservaties of handmatige configuratie) zodat identiteiten voorspelbaar blijven. Algemene werkplekken en randapparatuur krijgen dynamische leases binnen een dedicated sub-prefix. Zo blijft dagelijkse client-adressering flexibel, terwijl de infrastructuur deterministisch blijft.

Waarom we “alleen SLAAC” vermijden voor infrastructuur

SLAAC is niet per definitie fout, maar “SLAAC-only overal” levert operationele frictie op als u deterministische infrastructuur belangrijk vindt:

  • Het maakt firewallregels en monitoring ingewikkelder als adressen niet bewust stabiel zijn.
  • Het maakt het lastiger om reverse DNS, certificaten en inventaris op één lijn te houden.
  • Het stimuleert “dat lossen we later wel op”-gedrag, wat vaak uitgroeit tot technische schuld.

Voor infrastructuurapparaten en sleutel-werkplekken willen we determinisme. Voor algemene werkplekken en randapparatuur willen we gecontroleerde dynamiek. RA + DHCPv6 laat ons beide schoon modelleren.

Gatewaybeleid: voorkom asymmetrische routing op multi-homed hosts

Dit is de DSM-valkuil die meer setups breekt dan mensen doorhebben. DSM verstopt het zelfs achter een enigszins misleidend label: de instelling “multiple gateways” gaat niet alleen over het hebben van meer dan één default route; het gaat erom dat DSM per-interface policy routing correct programmeert op een multi-homed systeem. Als een host meerdere actieve interfaces heeft (meerdere VLANs), kunt u anders makkelijk eindigen met asymmetrische routing:

  • Een pakket komt binnen op VLAN 30.
  • Het antwoord verlaat het systeem via de “eerste” interface die de default route wint (vaak VLAN 10 / management).

Dat gedrag verstoort state tracking (op routers en firewalls), breekt TCP op niet-obvious manieren en wekt de indruk dat VLANs verkeerd geconfigureerd zijn. In DSM moet u expliciet support voor multiple gateways inschakelen via de geavanceerde netwerkinstellingen; anders programmeert DSM mogelijk alleen één hoofd-routing table in plaats van per-interface policy routing met passende source selection.

Operationele regel: zorg dat de default route wijst naar de interface die daadwerkelijk internet-egress levert, en zorg dat failover-prioriteiten expliciet en correct zijn. Een “maintenance”-VLAN mag niet per ongeluk uw default egress worden omdat die als eerste is geconfigureerd.

In Deel 3 laten we zien hoe we dit valideren op DSM-niveau (GUI) en op Linux-niveau (policy routing rules), maar het ontwerpprincipe is eenvoudig: multi-homing vraagt om expliciet gatewaybeleid.

Statische routes en VPN-bereikbaarheid

In gesegmenteerde omgevingen heeft u meestal meerdere “next hops”: inter-VLAN routing, site-to-site VPN routing en soms speciale egress routes richting security gateways. Het doel is om routing voorspelbaar te maken voor clients en services zonder dat ieder apparaat handmatig geconfigureerd moet worden.

In ons netwerk is routing intent gecentraliseerd: routers en DHCP-services distribueren wat clients nodig hebben, inclusief default gateway-selectie en bereikbaarheid naar andere VLANs en VPN-verbonden netwerken. Via hetzelfde mechanisme verspreiden we ook kern-infrastructuuropties zoals de interne split-horizon DNS-resolvers voor dat segment, een lokale tijdserver (NTP) en—waar relevant—proxy-instellingen. Het precieze mechanisme varieert per platform (IPv4 DHCP options versus IPv6 RA/DHCPv6 options), maar het ontwerpprincipe is consistent: clients horen geen ambachtelijke statische routes nodig te hebben.

MAC-identiteit: waarom we deterministische MACs per interface afdwingen

Hier is de ongemakkelijke waarheid: “het werkt meestal” is geen acceptabel ontwerpcriterium voor een multi-VLAN trunk die zowel DSM als virtual machines moet ondersteunen.

In generieke networking is het hergebruiken van één MAC-adres over meerdere VLAN-tagged subinterfaces niet automatisch fout. Maar zodra u DSM 7, Open vSwitch, VMM, meerdere bridges en Synology’s interface-discovery heuristieken introduceert, wordt het eenvoudig om een situatie te creëren waarin MAC-identiteit niet langer een stabiele indicator is van “waar frames horen te leven”. Het resultaat kan instabiliteit zijn die eruitziet als table poisoning: ARP/ND-churn, MAC learning flaps en intermitterende bereikbaarheid die komt en gaat met interface-events.

Onze oplossing is om MAC-identiteit te behandelen als onderdeel van het ontwerpcontract:

  • Infrastructuurapparaten gebruiken deterministische MAC-patronen die de VLAN-ID bevatten.
  • We dwingen ook deterministische MAC-identiteit af op interne interfaces waar het platform anders defaults kiest die ambigu of dubbel zijn.
  • Omdat we waar mogelijk EUI-64 gebruiken voor link-local, verbetert deterministische MAC-identiteit ook de observeerbaarheid van IPv6 en het troubleshooten.

In Deel 3 laten we zien hoe dit in de praktijk samenkomt met DSM en VMM, en hoe we het corrigeren zonder bij iedere update het systeem opnieuw te moeten bevechten.

Operator-ergonomie: laat de UI aansluiten op het netwerk

Goede engineering gebeurt niet alleen in het dataplane; het gaat ook om hoe mensen het systeem bedienen. DSM labelt interfaces als LAN1…LAN5 voor de basis-NICs, en extra interfaces kunnen verschijnen als LAN20, LAN30, enzovoort. We stemmen deze labels bewust af op de VLAN-betekenis, zodat het selecteren van een interface in DSM of in een package-UI minder foutgevoelig is.

Dit klinkt misschien cosmetisch. Dat is het niet. In gesegmenteerde netwerken kan één verkeerde interfacekeuze uitmonden in een outage of een security-incident. Duidelijke interface-identiteit vermindert fouten.

Ontwerpchecklist voordat u aan Deel 3 begint

Als u de DSM 7 trunking-aanpak uit Deel 3 wilt implementeren, verifieer dan eerst deze ontwerp-voorwaarden:

  • Uw VLAN-plan is expliciet: doel per VLAN, nummering en verwachte bereikbaarheid tussen VLANs.
  • Uw adresseringsplan is deterministisch (minimaal: stabiele infrastructuurranges; idealiter: VLAN-ID naar subnet naar prefix alignment).
  • Split-horizon DNS is bewust ingericht en per-interface resolverconfiguratie is correct.
  • Gatewaygedrag is correct op multi-homed systemen (DSM “multiple gateways” ingeschakeld; default route en failover-prioriteiten kloppen).
  • U heeft een recovery plan (management-toegangspad, console access als laatste redmiddel).

Volgende

In Deel 3 gaan we van ontwerp naar implementatie: DSM 7.2.2-update-3, Open vSwitch, kernel VLAN-interfaces en de rc.network-aanpassingen die DSM, packages en VMM op één lijn houden.

Vorige: Multi-VLAN Trunking op Synology DSM 7 - Diepgaande netwerkontwerp Deel A

Volgende: Multi-VLAN Trunking op Synology DSM 7 - DSM 7.2.2 implementatie