Gerouteerde VPN of gebrugd LAN voor een verbinding van filiaal naar lab

Er zijn twee manieren om een filiaal een thuislab te laten bereiken, en het verschil is geen instelling. Je kunt tussen aparte prefixen routeren, zodat elke locatie zijn eigen broadcastdomein houdt, of je kunt de twee LAN's tot één bruggen, zodat broadcasts en discoveryverkeer zich gedragen alsof iedereen in dezelfde kamer zit. Routeren is het ontwerp dat contact met een echt netwerk overleeft. Bruggen is het ontwerp dat de eerste week makkelijk maakt en de eerste storing interessant. De vergelijking hieronder gaat over wat elk oplevert en wat het kost, gevolgd door hoe je de gerouteerde variant testbaar maakt.

Twee manieren om te verbinden, één duidelijke afweging

Een gerouteerde verbinding behandelt het thuislab als een remote netwerk met eigen adressering. Het filiaal vraagt om de labprefix, de tunnel vervoert die pakketten, en de labgateway antwoordt vanuit zijn eigen subnet. Niets aan de ARP-tabel van het filiaal verandert, en niets van de DHCP-scope van het lab bereikt het filiaal.

Een gebrugde verbinding strekt één Layer 2-domein uit over beide locaties. Discoveryprotocollen werken, apparaten verschijnen automatisch, en elke broadcast, elk ARP-verzoek en elk multicastpakket is nu een kandidaat om de tunnel over te steken, wat een grote hoeveelheid verkeer is, gedragen door protocollen die voor een lokaal segment zijn ontworpen en niet voor een WAN met een andere MTU en een wisselende round-triptijd.

Wat routeren je oplevert

Het eerste voordeel is de omvang van de schade. Een loop, een rogue DHCP-server of een broadcastvloed blijft binnen de locatie die hem veroorzaakte, omdat een router geen broadcasts doorstuurt. Het tweede is adresseringshelderheid: de filiaalprefix en de labprefix zijn verschillend, dus de bestemming van een pakket vertelt je welke locatie moet antwoorden, en een firewallregel kan „filiaal naar labsubnet“ zeggen in plaats van „overal naar overal“.

Het derde is dat het past bij wat de tunnel werkelijk vervoert. Een IPsec-beleid is een paar prefixen, en het doorstuurpad aan elke kant is gewoon IP-routing met forwarding aan op de gateway:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

Wat je opgeeft, is discovery via broadcast. Dat is een echt verlies, en het moet bewust worden vervangen in plaats van omzeild door alles te bruggen.

Wat bruggen kost

Bruggen moet Layer 2-frames over een tunnel dragen, wat een inkapseling betekent zoals GRE of VXLAN over IPsec in plaats van een gewone beleidsgebaseerde tunnel. Zodra dat bestaat, delen de twee locaties een foutdomein. Spanning tree ziet de tunnel als een link, broadcastverkeer vreet tunnelbandbreedte, en elk apparaat dat een segment met lage latentie verwacht, gedraagt zich verkeerd op manieren die vanaf beide kanten moeilijk toe te schrijven zijn.

Het haalt ook de adresseringscontrole weg die je eerlijk houdt. Met één platte prefix is een dubbel adres geen routingfout maar twee hosts die elkaar stilletjes verkeer afstelen, en overlappende prefixen tussen een filiaal en een lab komen veel voor in thuislabopstellingen, dus bruggen lost dat conflict niet op; het verdeelt het.

Het beveiligingsargument is het argument dat de beslissing meestal neemt. Een brug strekt het segment uit waarop link-local protocollen werken, dus een apparaat in het filiaal kan praten met labapparaten die nooit van buitenaf bereikbaar hadden moeten zijn. Heeft het lab een hypervisor, een opslagconsole en een beheerinterface op hetzelfde platte netwerk, dan is dat nu samen met het filiaal één segment.

Namen zonder broadcast

De reden dat mensen bruggen is meestal discovery: een printer, een mediaspeler of een labhost die nooit in een lijst verschijnt. Het gerouteerde antwoord is een naamdienst. Publiceer de labhosts in een zone die de resolver van het filiaal kan bereiken, en laat gebruikers dan op naam verbinden in plaats van het netwerk te scannen. Dat is vooraf meer werk en bij elke toekomstige wijziging beduidend minder.

Multicastdiscovery is het moeilijkere geval, en het verdient precisie. Protocollen zoals mDNS gebruiken link-local multicast, dat routers standaard niet doorsturen, dus een labhost die in een discoverylijst ontbreekt, kan op zijn gedocumenteerde adres nog steeds bereikbaar zijn. Als een specifieke dienst echt multicast nodig heeft, plan dan die ene dienst, met een reflector of een gerichte doorstuurregel, in plaats van het hele LAN te bruggen als algemene reparatie.

Ook een reflector is geen gratis winst. Hij haalt hetzelfde praatgrage verkeer binnen dat je wilde vermijden, één dienst per keer, en hij heeft een eigenaar nodig die merkt wanneer een apparaat meer gaat adverteren dan vroeger. Kies hem per dienst, en schrijf op waarom. Leg vast welke dienst hem nodig had en wat hij adverteert, want een firmware-update kan die lijst veranderen zonder iemand iets te zeggen.

Maak het gerouteerde ontwerp testbaar

Kies één doel, bijvoorbeeld een webinterface van het lab op een eigen serversubnet, en bewijs het in beide richtingen. Controleer op een host in het filiaal het adres en de luisterende dienst lokaal, verbind dan door de tunnel en herhaal het. Een tunnel die omhoog staat bewijst dat de gateways het eens zijn; over de hostfirewall of de retourroute bewijst hij niets.

De normale gateway van het lab heeft een route terug naar de filiaalprefix nodig, tenzij het ontwerp de bron bewust vertaalt, en de firewall van de server zelf moet het toegestane remote bereik accepteren. Geen van beide wordt door een geslaagde tunnel geconfigureerd. De forwardingnotities van strongSwan beschrijven het pakketpad dat aan elke kant moet werken.

Test daarna ook een geweigerde bestemming. Een filiaalgebruiker die één applicatie nodig heeft, heeft de hypervisorconsole niet nodig, en de enige manier om te weten dat het beleid echt is, is precies dat proberen wat het hoort te weigeren. Leg de prefixen, de resolverafhankelijkheid en de testresultaten vast, en een toekomstige wijziging aan een van beide locaties is in minuten te beoordelen in plaats van uit het geheugen opnieuw te bouwen.