Geroutetes VPN oder gebrücktes LAN für eine Verbindung von Filiale zu Labor

Es gibt zwei Wege, auf denen eine Filiale ein Heimlabor erreicht, und der Unterschied ist keine Einstellung. Sie können zwischen getrennten Präfixen routen, sodass jeder Standort seine eigene Broadcast-Domäne behält, oder die beiden LANs zu einem brücken, sodass Broadcasts und Discovery-Verkehr sich verhalten, als säßen alle im selben Raum. Routing ist der Entwurf, der den Kontakt mit einem echten Netz übersteht. Bridging ist der Entwurf, der die erste Woche einfach und den ersten Ausfall interessant macht. Der Vergleich unten zeigt, was jeder Weg liefert und was er kostet, und danach, wie man die geroutete Variante prüfbar macht.

Zwei Verbindungswege, ein offensichtlicher Kompromiss

Eine geroutete Verbindung behandelt das Heimlabor als entferntes Netz mit eigener Adressierung. Die Filiale fragt das Labor-Präfix an, der Tunnel befördert diese Pakete, und das Labor-Gateway antwortet aus seinem eigenen Subnetz. An der ARP-Tabelle der Filiale ändert sich nichts, und kein Bereich der DHCP-Zone des Labors reicht bis in die Filiale.

Eine gebrückte Verbindung dehnt eine einzige Schicht-2-Domäne über beide Standorte aus. Discovery-Protokolle funktionieren, Geräte erscheinen automatisch, und jeder Broadcast, jede ARP-Anfrage und jedes Multicast-Paket ist nun ein Kandidat für den Weg durch den Tunnel, also eine große Menge Verkehr, getragen von Protokollen, die für ein lokales Segment gebaut sind und nicht für ein WAN mit anderer MTU und schwankender Umlaufzeit.

Was Routing Ihnen gibt

Der erste Vorteil ist der Wirkungsradius. Eine Schleife, ein rogue DHCP-Server oder eine Broadcast-Flut bleibt an dem Standort, der sie erzeugt hat, weil ein Router Broadcasts nicht weiterleitet. Der zweite ist Klarheit in der Adressierung: Das Filial-Präfix und das Labor-Präfix sind getrennt, ein Zielpaket sagt Ihnen also, welcher Standort antworten soll, und eine Firewall-Regel kann „Filiale zum Labor-Subnetz“ sagen statt „überallhin zu überallhin“.

Der dritte ist, dass Routing zu dem passt, was der Tunnel tatsächlich transportiert. Eine IPsec-Richtlinie ist ein Paar von Präfixen, und der Weiterleitungspfad auf jeder Seite ist gewöhnliches IP-Routing mit aktivierter Weiterleitung am 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

Was Sie aufgeben, ist Discovery per Broadcast. Das ist ein echter Verlust, und man sollte ihn bewusst ersetzen, statt ihn zu umgehen, indem man alles brückt.

Was Bridging kostet

Bridging muss Schicht-2-Rahmen über einen Tunnel tragen, was eine Kapselung wie GRE oder VXLAN über IPsec bedeutet statt eines einfachen richtlinienbasierten Tunnels. Sobald das existiert, teilen sich die beiden Standorte eine Fehlerdomäne. Spanning Tree sieht den Tunnel als Link, Broadcast-Verkehr verbraucht Tunnelbandbreite, und jedes Gerät, das ein Segment mit niedriger Latenz annimmt, verhält sich falsch, und zwar auf eine Weise, die von beiden Enden aus schwer zuzuordnen ist.

Es fällt außerdem die Adressprüfung weg, die Sie ehrlich hält. Mit einem flachen Präfix ist eine doppelte Adresse kein Routing-Fehler, sondern zwei Hosts, die einander stillschweigend den Verkehr stehlen, und überlappende Präfixe zwischen Filiale und Labor sind in Heimlabor-Aufbauten üblich, also löst Bridging diesen Konflikt nicht; es verteilt ihn.

Das Sicherheitsargument ist das, das die Entscheidung meist gibt. Eine Brücke dehnt das Segment aus, auf dem Link-Local-Protokolle arbeiten, ein Gerät in der Filiale kann also mit Laborgeräten sprechen, die nie von außen erreichbar sein sollten. Hat das Labor einen Hypervisor, eine Storage-Konsole und eine Management-Schnittstelle im selben flachen Netz, ist das nun zusammen mit der Filiale ein Segment.

Namen ohne Broadcast

Der Grund, aus dem Leute brücken, ist meist Discovery: ein Drucker, ein Mediengerät oder ein Laborhost, der nie in einer Liste auftaucht. Die geroutete Antwort ist ein Namensdienst. Veröffentlichen Sie die Laborhosts in einer Zone, die der Resolver der Filiale erreicht, und lassen Sie Nutzer dann über den Namen verbinden statt das Netz zu scannen. Das ist anfangs mehr Arbeit und bei jeder künftigen Änderung deutlich weniger.

Multicast-Discovery ist der schwierigere Fall, und er verdient Genauigkeit. Protokolle wie mDNS nutzen Link-Local-Multicast, das Router standardmäßig nicht weiterleiten, ein aus einer Discovery-Liste fehlender Laborhost kann also unter seiner dokumentierten Adresse weiterhin erreichbar sein. Wenn ein bestimmter Dienst wirklich Multicast braucht, planen Sie diesen einen Dienst, mit einem Reflector oder einer gezielten Weiterleitungsregel, statt das ganze LAN als allgemeine Reparatur zu brücken.

Auch ein Reflector ist kein kostenloser Gewinn. Er holt denselben geschwätzigen Verkehr herein, den Sie vermeiden wollten, einen Dienst nach dem anderen, und er braucht einen Verantwortlichen, der merkt, wenn ein Gerät anfängt, mehr anzukündigen als früher. Wählen Sie ihn pro Dienst und schreiben Sie auf, warum. Halten Sie fest, welcher Dienst ihn brauchte und was er ankündigt, denn ein Firmware-Update kann diese Liste ändern, ohne jemandem Bescheid zu sagen.

Machen Sie den gerouteten Entwurf prüfbar

Wählen Sie ein Ziel, etwa eine Weboberfläche des Labors in einem eigenen Server-Subnetz, und beweisen Sie es in beide Richtungen. Bestätigen Sie auf einem Host der Filiale die Adresse und den lauschenden Dienst lokal, verbinden Sie sich dann durch den Tunnel und wiederholen Sie es. Ein Tunnel, der steht, beweist, dass die Gateways übereinstimmen; über die Host-Firewall oder die Rückroute beweist er nichts.

Das normale Gateway des Labors braucht eine Route zurück zum Filial-Präfix, es sei denn, der Entwurf übersetzt die Quelle bewusst, und die Firewall des Servers selbst muss den erlaubten entfernten Bereich akzeptieren. Beides wird von einem erfolgreichen Tunnel nicht konfiguriert. Die Weiterleitungshinweise von strongSwan beschreiben den Paketpfad, der auf jeder Seite funktionieren muss.

Testen Sie dann auch ein verbotenes Ziel. Ein Filialnutzer, der eine Anwendung braucht, braucht nicht die Hypervisor-Konsole, und dass die Richtlinie echt ist, erfahren Sie nur, indem Sie das ausprobieren, was sie ablehnen soll. Halten Sie Präfixe, Resolver-Abhängigkeit und Testergebnisse fest, und eine künftige Änderung an einem der Standorte ist in Minuten zu prüfen statt aus dem Gedächtnis neu zu bauen.