SoftEther-Kaskade: zwei virtuelle Hubs bewusst verbinden

Zwei SoftEther-Hubs, die durch eine Kaskade verbunden sind, teilen sich eine Broadcast-Domäne, daher ist eine Schleife oder ein zweiter DHCP-Server kein lokaler Fehler mehr, sondern ein gemeinsamer. Das ist das ganze Risikomodell. Die Kaskade selbst ist eine konfigurierte Client-Beziehung: Der lokale virtuelle Hub verbindet sich nach außen zum Hub eines entfernten Servers unter einer Identität, die dieser Server autorisiert. Sie ist ein Baustein für ein größeres virtuelles Netzwerk, niemals ein Internet-Ausgang.

1. Entscheiden Sie, was die Verbindung tragen muss

Beginnen Sie mit der Anforderung, nicht mit dem Feature. Eine Kaskade bewegt Frames der zweiten Schicht zwischen Hubs, und das ist es, was Sie wollen, wenn zwei Standorte wie ein einziges Ethernet-Segment aussehen sollen. Wenn der Bedarf nur gerouteter Zugang zu wenigen Subnetzen ist, ist ein gerouteter Pfad einfacher und scheitert auf leichter sichtbare Weise. Die Wahl einer Kaskade verpflichtet Sie auf gemeinsamen Broadcast, gemeinsame Erkennung und eine Schleifentopologie.

Schreiben Sie die Anforderung in einer Zeile auf, bevor Sie einen Server anfassen: Welche Systeme müssen am selben Draht erscheinen, und welche brauchen nur eine Route. Alles, was mit «eine Route» antwortet, gehört außerhalb der Kaskade. Dieser eine Satz verhindert die meisten Entwürfe, die mit doppelten Adressdiensten enden.

2. Grenzen Sie die Identität ein, die sie autorisiert

Die Zugangsdaten, mit denen ein Server administriert wird, und die Identität, die eine Kaskade zum Verbinden nutzt, sind verschiedene Geheimnisse, und sie zu vermischen ist eine häufige Abkürzung mit langem Nachlauf. Der entfernte Hub braucht einen Benutzer- oder Richtlinieneintrag, der dieser Kaskade das Verbinden erlaubt. Dieser Eintrag ist die Autorisierung; eine erfolgreiche Anmeldung sagt nichts darüber, was hinter dem entfernten Hub steht.

Halten Sie fest, welcher Hub die Verbindung initiiert, welchem entfernten Hub er beitritt und was die entfernte Identität erreichen darf. Vergleichen Sie die beiden Architekturen, bevor Sie sich festlegen:

Halten Sie Zugangsdaten und Wiederherstellungsanweisungen beider Seiten aktuell. Eine Passwortänderung oder eine Richtlinienbearbeitung am entfernten Hub bricht die Kaskade, ohne Ihre lokalen Benutzer zu berühren, und der Fehler zeigt sich meist als Verbindung, die steht, aber leer ist.

3. Prüfen Sie, was der Hub bereits trägt

Ein Hub ist selten isoliert. Er überbrückt vielleicht bereits einen physischen Adapter, routet über einen virtuellen Router oder kaskadiert woandershin, und jede dieser Anbindungen wird in die neue Beziehung mitgenommen. Deshalb wird aus «wir haben nur zwei Hubs verbunden» so oft «warum sind diese beiden Standorte jetzt ein Segment?».

Zwei Hubs, die in dasselbe physische Segment überbrückt und dann miteinander kaskadiert werden, bilden eine Schleife. Fügen Sie Spanning Tree hinzu, oder bauen Sie es nicht. Derselbe Test gilt für einen Hub, der das Ziel bereits über eine andere Kaskade erreicht: Eine zweite Verbindung fügt keine Kapazität hinzu, sie fügt einen Pfad hinzu.

Fügen Sie keine Verbindung hinzu, weil eine Route fehlt; reparieren Sie die Route. Zeichnen Sie die Topologie zuerst auf Papier, einschließlich jeder Brücke und Kaskade, denn das Diagramm dauert zwei Minuten und fängt die meisten Schleifen, bevor sie entstehen.

4. Klären Sie die Adressierung vor dem Beitritt

Zusammengeführte Segmente bringen doppelte Subnetze mit, und doppelte DHCP-Server sind das klassische Symptom: Clients nehmen eine Lease von dem Server, der zuerst antwortet, daher wirkt das Verhalten zufällig und wandert zwischen Neustarts. Legen Sie vorab fest, welche Seite die Adressvergabe besitzt, und geben Sie dem fernen Segment einen Bereich, der sich mit nichts Lokalem überschneidet. Deaktivieren Sie den anderen DHCP-Dienst, bevor die Kaskade online geht, nicht erst nach der ersten Beschwerde.

DNS ist eine separate Frage. Eine Kaskade trägt Frames; sie konfiguriert keine Resolver, und ein Name, der lokal aufgelöst wird, wird über die Verbindung vielleicht nicht aufgelöst. Testen Sie die Abfrage getrennt vom IP-Pfad, denn ein funktionierender Ping beweist nur eines von beidem.

5. Beweisen Sie es mit einer echten Ressource

Wählen Sie einen erlaubten Dienst im vorgesehenen fernen Segment und bestätigen Sie, dass die Antwort über die Kaskade zurückkommt. Wiederholen Sie das dann für die Namensauflösung. Wenn das Ziel auf Broadcast-Erkennung angewiesen ist, erwarten Sie über eine überbrückte Verbindung anderes Verhalten als auf einem einzelnen Draht, und planen Sie das ein, statt es als Defekt zu melden.

Schreiben Sie schließlich die Topologie auf: welcher Hub wohin kaskadiert, welche Identität das autorisiert, welche Segmente überbrückt sind und wer in jedem die Adressvergabe besitzt. Diese Notiz ermöglicht es der nächsten Person, eine Richtlinie zu ändern, ohne ein Segment abzuschalten, von dem sie nicht wusste, dass es existiert.