ESXi-Gast-VPN: Routing oder Bridging — entscheiden Sie vor der Portgruppe
Ein geroutetes TUN braucht Rückrouten; ein gebrücktes TAP braucht Layer-2-Erreichbarkeit und eine breitere Portgruppen-Richtlinie. Legen Sie die Rolle fest, bevor Sie den Promiscuous-Modus ausweiten.
Leiten Sie die Pakete weiter, oder erweitern Sie die Ethernet-Domäne: Die Änderung der Portgruppe folgt auf diese Entscheidung. Aus Sicht einer Anwendung mit privater Adresse können die Ergebnisse identisch aussehen, während die Anforderungen an den Hypervisor völlig verschieden sind. Deshalb wird die Portgruppe zuerst erweitert und die Designfrage danach beantwortet, meist nach einem Broadcast-Sturm. Gehen Sie diese Prüfungen der Reihe nach durch und halten Sie an, solange die Anforderung noch unklar ist, denn keine Portgruppen-Einstellung repariert ein Design, das nie gewählt wurde.
Die Entscheidung gehört dem Eigentümer des Dienstes; die Hypervisor-Konfiguration soll sie umsetzen und nicht versehentlich bestimmen.
Prüfen Sie, was die Gegenseite tatsächlich braucht
Listen Sie die Dienste auf, die die entfernten Clients erreichen müssen, und die Protokolle, die sie verwenden. Ist die Liste eine Handvoll TCP-Dienste auf bekannten Präfixen, deckt Routing das ab. Braucht etwas wirklich Layer-2-Nachbarschaft — broadcastabhängige Erkennung, Nicht-IP-Protokolle, ein Gerät, das kein Gateway akzeptiert —, kann Routing das nicht nachbilden, und das sollte früh gesagt werden. Seien Sie ehrlich bei den Nicht-IP-Einträgen auf dieser Liste, denn dort scheitert ein geroutetes Design eine Woche später still.
Prüfen Sie dann den Client-Pool. Ein geroutetes Design braucht einen Adressbereich und eine ausdrückliche Rückroute auf der Gegenseite; ein gebrücktes Design braucht eine erweiterte Ethernet-Domäne, die Adressvergabe und Isolation besitzt. Was immer Sie wählen, jemand außerhalb dieser VM muss zustimmen.
Was jedes Design vom virtuellen Netz verlangt
Die beiden Designs unterscheiden sich darin, was das virtuelle Netz aushalten muss, und die Tabelle zeigt es am kürzesten:
| Design | Rolle auf der Gastseite | Was das virtuelle Netz aufnehmen muss | Fehlerbild bei falscher Wahl |
|---|---|---|---|
| Geroutetes TUN | Router zwischen getrennten Präfixen | Ein gerouteter Client-Pool plus Rückwege auf der Gegenseite | Clients erreichen das Gateway und nie den Dienst dahinter |
| Gebrücktes TAP | Layer-2-Brücke für die Clients, die beitreten | Zusätzliche Ethernet-Identitäten, Broadcast-Verkehr und VLAN-Regeln | Der vSwitch verwirft Frames, oder das Design braucht einen Promiscuous-Modus, den niemand genehmigt hat |
Routing lässt die Broadcast-Domäne, wo sie ist, und gibt einen natürlichen Ort, um zu begrenzen, welche Dienste das Gateway überqueren. Bridging verschiebt die Grenze: Die Clients werden Teilnehmer der erweiterten Ethernet-Domäne, und Adressvergabe, Isolation und jede Layer-2-Richtlinie gelten nun für sie. Schreiben Sie die gewählte Zeile ins Änderungsprotokoll. Ein Satz wie „geroutetes TUN, Client-Pool 10.90.0.0/24, Rückroute auf dem Core“ hindert den nächsten Ingenieur daran, das Design aus den Portgruppen-Einstellungen neu zu verhandeln.
Wer wessen Frames sehen darf
Stellen Sie dem Plattform-Eigentümer eine Frage, bevor Sie die Portgruppe anfassen: Verlangt das Design, dass diese VM Frames empfängt, die an andere Teilnehmer adressiert sind? Lautet die Antwort nein, gilt nichts in diesem Abschnitt, denn ein geroutetes TUN braucht diese Sichtbarkeit nie. Lautet die Antwort ja, ist Broadcoms Leitfaden zum Promiscuous-Modus die Lektüre, auf die es ankommt: Er legt dar, wie viel mehr vom vSwitch die VM sehen kann, und empfiehlt, diese Richtlinie auf eine Portgruppe zu beschränken.
Behandeln Sie das als Anforderungsprüfung, nicht als Freibrief. Schalten Sie die Einstellung für eine dedizierte Anbindung ein, wenn der Bridge-Bedarf schriftlich vorliegt, und lassen Sie sie überall sonst aus. Ein breiter VLAN-Trunk, aus einem anderen Bridge-Beispiel kopiert, ist der Teil, den niemand zu entfernen denkt, und ein Single-VLAN-Design sollte Single-VLAN bleiben.
Halten Sie fest, welche Portgruppe sich geändert hat und warum, an derselben Stelle, an der Sie die Designzeile notiert haben. Diese Paarung ermöglicht das nächste Audit.
Halten Sie die Objekte des Gastes eindeutig
Innerhalb von Linux sind Bridge-Mitgliedschaft und Adresseigentum getrennte Objekte, und ihre Vermischung erzeugt den verwirrenden halbfunktionierenden Zustand. Weisen Sie Adressen dem Bridge-Interface oder dem gerouteten Tunnel zu, nicht beiden Seiten desselben Pfads, und halten Sie die Mitgliedsports frei von IP-Konfiguration.
Vermeiden Sie es, ein Subnetz unabhängig auf einem gerouteten TUN und auf einem unabhängigen Ethernet-Interface zu platzieren. Diese Konfiguration erzeugt zwei Wege zum selben Präfix, asymmetrische Antworten und einen Support-Thread über Flapping, der keinen der Wege erwähnt. Wenn der Gast auch Container oder einen lokalen Hypervisor hostet, prüfen Sie, ob diese nicht bereits in denselben Uplink brücken. Zwei Bridges auf einer NIC sind ein Design, kein Unfall, den Sie während eines Änderungsfensters entdecken wollen.
Bestätigen Sie mit einem Paketpfad, nicht mit einem Ping
Prüfen Sie den tatsächlichen Pfad, nicht nur die Erreichbarkeit. Bestätigen Sie von einem Client, welche Quelladresse beim entfernten Dienst ankommt, und dann, dass die Antwort denselben Weg zurücknimmt. Prüfen Sie auf dem Gast die Weiterleitungszähler für den konkreten Fluss und auf der Portgruppe, dass keine zusätzliche Sichtbarkeit über das gewählte Design hinaus aktiviert wurde.
Testen Sie schließlich die Fehlerrichtung. Stoppen Sie den Tunnel oder trennen Sie den Client, und prüfen Sie, dass der Verkehr nicht still auf einen gerouteten Pfad zurückfällt, den Sie für ungenutzt hielten, denn dieser Rückfall ist der Weg, auf dem ein gebrücktes Design still zum unbeabsichtigten Router wird.