Schwierige Situation: Sie sind über SSH oder in der Weboberfläche eines Proxmox-Knotens verbunden, und das Netzwerk, das Sie ändern müssen, hat genau diesen Zugang. Ein falscher physischer Port, eine verschobene Adresse oder ein an der falschen Stelle hinzugefügtes Gateway können beide Türen gleichzeitig schließen.
Der Proxmox-Bridge muss also von der tatsächlich genutzten Schnittstelle, der Adresse, die am Knoten erfasst wurde, und einem zugänglichen Rollback ausgehen. Sie werden den Verwaltungsbridge vom Bridge für VMs unterscheiden, entscheiden, ob ein VLAN-Trunk erforderlich ist, und dann das Ergebnis überprüfen, bevor Sie Ihre Sitzung schließen.
Den Netzwerkpfad lokalisieren, der Proxmox zugänglich hält
Beginnen Sie damit, den Status der Schnittstellen zu prüfen. Diese Ablesung dient dazu, den genauen Namen der physischen Karte zu finden und zu prüfen, ob die Verbindung aktiv ist. Ersetzen Sie diesen Namen nicht durch ein Beispiel wie eno1, enp3s0 oder ens18.
ip -br linkDie erwartete Ausgabe zeigt jede Schnittstelle mit ihrem Status an, ohne dass Sie ihren Namen erraten müssen. Finden Sie die Karte, die mit dem von der Verwaltung verwendeten Netzwerk verbunden ist, und vergleichen Sie sie mit dem bereits vorhandenen Bridge. Wenn keine Schnittstelle dem erwarteten Pfad entspricht, halten Sie an, bevor Sie vmbrX erstellen.
Überprüfen Sie dann die Adressen, die von den Schnittstellen und den Bridges verwendet werden. Sie suchen die Verwaltungsadresse, ihr Präfix und das Netzobjekt, das sie derzeit trägt.
ip -br addressDie Ausgabe sollte es ermöglichen, eine einzige Schnittstelle oder einen einzigen Bridge zu benennen, der die Verwaltungsadresse trägt. Notieren Sie diese Zuordnung vor jeglicher Änderung. Wenn die Adresse auf einer physischen Karte erscheint, die Sie an einen Verwaltungsbridge anschließen möchten, muss der Umzug zum Bridge ausdrücklich eingeplant werden.
Beenden Sie die Vorabprüfung mit dem Route, die verwendet wird, um das lokale Netzwerk zu verlassen. Diese legt das Gateway fest, das im einfachen Fall hier beibehalten werden soll.
ip routeSie sollten eine Standardroute, ihr Gateway und die Ausgangsschnittstelle finden. Behalten Sie für diese einfache Konfiguration nur ein Standardgateway. Ein zweites Gateway löst keinen Fehler im Bridge und führt zu einer Routenwahl, die außerhalb des Rahmens dieses Tutorials liegt.
Bevor Sie den Netzwerkeditor öffnen, sammeln Sie die Elemente, die das Rollback beeinflussen:
- den genauen Namen der physischen Karte und den Status ihrer Verbindung;
- die Verwaltungs-IP-Adresse, ihr Präfix und das aktuelle Gateway;
- die Wahl zwischen Verwaltungsbridge und zusätzlichem Bridge ohne IP auf dem Host;
- das ungetaggte Netzwerk oder die tatsächlich transportierten VLANs;
- die entsprechende Portkonfiguration am Switch;
- eine tatsächlich unabhängige IPMI-, KVM- oder lokale Konsole;
- ein datiertes Backup der Netzwerkdatei;
- die ursprüngliche SSH-Sitzung bis zur Endkontrolle aufbewahrt.
Wählen Sie den Bridge, seinen physischen Port und den Standort der IP
Ein Linux-Bridge verbindet die virtuellen Netzwerkschnittstellen mit dem physischen Netzwerk wie ein virtueller Switch. Die Proxmox-Dokumentation zur Netzwerkkonfiguration beschreibt diesen Linux-Stack und seine Objekte. Ihre Entscheidung bezieht sich zunächst auf die Rolle von vmbrX und dann auf den physischen Port, der ihm als Ausgang dient.
Für die Verwaltung des Knotens platzieren Sie die IP-Adresse und das Gateway auf dem Bridge, das mit dem LAN verbunden ist. Die angehängte physische Karte dient dann als Port für den Bridge und behält keine konkurrierende Adressierung. Für einen Bridge, der ausschließlich für VMs reserviert ist, kann der Host ohne IP-Adresse in diesem Netzwerk bleiben, wenn er keinen Grund hat, dort zu kommunizieren.
Die Tabelle unterscheidet die drei hier nützlichen Fälle. Die tatsächlichen Namen der Karte und des Bridges stammen aus der Vorprüfung, nicht von einem kopierten Beispiel.
| Bedarf | IP auf dem Host | Standardgateway | Physischer Port | VLAN-aware |
|---|---|---|---|---|
| Hauptbridge für Verwaltung und VMs im LAN | Auf vmbrX | Auf diesem Bridge im einfachen Fall | Schnittstelle, die mit dem LAN verbunden ist | Nein für ein einzelnes ungetaggtes Netzwerk; ja nur für einen kohärenten Trunk |
| Zusätzlicher Bridge für VMs | Keine, wenn der Host nicht zu diesem Netzwerk gelangen soll | Kein neues Standardgateway | Dedicat ete Schnittstelle oder kein Port für ein internes Netzwerk | Je nach tatsächlichem Bedarf der VMs und des Switches |
| Trunk mehrerer VLANs zu den VMs | Nur wenn der Knoten mit einem bestimmten VLAN kommunizieren soll | Eine einzige Standardroute im Rahmen des Tutorials | Port des Switches, der für die erwarteten VLANs konfiguriert ist | Ja |
Wenn vmbrX die Verwaltung trägt, darf die Adresse nicht parallel auf der physischen Karte verbleiben. Wenn vmbrX nur für die VMs verwendet wird, kann eine fehlende Adresse auf dem Host normal sein. In beiden Fällen bleibt die Standardroute im einfachen Szenario einzigartig.
VLAN-aware nur für einen vorgesehenen Trunk am Switch aktivieren
Aktivieren Sie VLAN-aware nur, wenn mehrere VLANs denselben Bridge zu den VMs durchqueren müssen. Für ein einzelnes ungetaggtes Netzwerk fügt diese Einstellung eine Abhängigkeit hinzu, ohne einen identifizierten Bedarf zu decken. Der Schalter auf der Proxmox-Seite konfiguriert nicht den Port des Switches und entscheidet nicht über das Verwaltungs-VLAN.
Trennen Sie drei Entscheidungen: die Aktivierung von VLAN-aware auf dem Bridge, das Tag, das der Netzwerkkarte einer VM zugewiesen wird, und den Transport, der durch den physischen Port des Switches erlaubt ist. Wenn das Verwaltungs-VLAN getaggt ist, muss seine Behandlung auf beiden Seiten kohärent sein.
Nachdem Sie diese Architektur festgelegt haben, lesen Sie die VLAN-Tabelle auf der Linux-Seite. Dieser Befehl validiert nicht den Switch; er dient dazu, den Bridge und seinen Port mit den vorgesehenen VLANs zu vergleichen.
bridge vlan showDie erwartete Ausgabe sollte den tatsächlich erlaubten VLANs auf dem Trunk und den Mitgliedsporten des Bridges entsprechen. Eine leere Liste, ein fehlender Port oder eine inkohärente Zugehörigkeit erfordert eine Überprüfung des Bridges und der Switch-Konfiguration vor der Anwendung. Die Proxmox-Dokumentation zu VLANs erinnert daran, dass VLAN-aware die Einstellung des physischen Transports nicht ersetzt.
Rollback vorbereiten, bevor die Konfiguration angewendet wird
Eine Änderung des Verwaltungsbridges berührt den Pfad Ihrer Sitzung. Ich empfehle, den Zugang zu einer IPMI-, KVM- oder lokalen Konsole zu bestätigen, bevor Sie die Adressierung berühren. Eine zweite SSH-Sitzung ist nützlich für den endgültigen Nachweis, stellt jedoch keinen unabhängigen Zugang dar, wenn sie über denselben Bridge, denselben Switch und dasselbe Gateway läuft.
Bewahren Sie eine datierte Kopie der Netzwerkdatei vor dem Schreiben auf. Dieses Backup ersetzt nicht die Konsole, bietet jedoch einen bekannten Zustand zur Überprüfung, falls der entfernte Konfiguration den Zugang unterbricht.
sudo cp /etc/network/interfaces /etc/network/interfaces.bak-$(date +%F-%H%M)Nach dem Befehl sollte die Sicherungsdatei das Datum und die Uhrzeit in ihrem Namen tragen, neben der Originaldatei. Wenn die Kopie fehlschlägt oder die Notfallkonsole nicht wirklich zugänglich ist, fahren Sie nicht aus der Ferne fort. Der Rest muss von diesem unabhängigen Pfad aus wiederherstellbar bleiben.
Änderung anwenden, ohne ifdown auf dem Bridge zu erzwingen
Lesen Sie in der Proxmox-Oberfläche den Namen von vmbrX, den physischen Port, die Adresse, das Präfix, das Gateway und die VLAN-Wahl, bevor Sie bestätigen. Verwenden Sie danach den kontrollierten Anwendungsmechanismus, der von Proxmox angeboten wird, dokumentiert im Proxmox-Netzweradministrationsleitfaden. Diese Methode beseitigt nicht das Risiko einer Inkohärenz am Switch, verhindert jedoch, dass eine improvisierte Umschaltung zu diesem Risiko hinzugefügt wird.
Wenn Sie direkt /etc/network/interfaces bearbeiten, halten Sie sich an dieselbe Disziplin: Überprüfen Sie die festgestellten Namen, platzieren Sie die IP auf dem richtigen Niveau und erfinden Sie kein Beispiel für eine Schnittstelle. Achtung: Das Paar ifdown/ifup, das reflexartig gestartet wird, kann den Verkehr der Gäste unterbrechen und nicht wie vorgesehen wiederherstellen. Es ist keine Methode zur Fernwiederherstellung.
Nach der Anwendung schließen Sie nicht von einem einzigen Button oder einem offenen Fenster auf. Fahren Sie mit den Kontrollen des Bridges, der Route, des Mitgliedsports und der VLANs fort und öffnen Sie dann eine neue Verbindung.
Den Bridge prüfen, bevor Sie den VMs vertrauen
Beginnen Sie mit der Überprüfung der Adresse des Bridges. Diese Ablesung ermöglicht es, den Fall zu unterscheiden, in dem vmbrX die Verwaltung trägt, von dem Fall, in dem er absichtlich ohne IP auf dem Host verbleibt.
ip -br address show vmbrXWenn vmbrX die Verwaltung trägt, sollte die Ausgabe die zu Beginn erfasste Adresse und das Präfix anzeigen. Wenn der Bridge für VMs reserviert ist, kann das Fehlen einer Adresse erwartet werden. Eine fehlende Adresse im ersten Fall oder eine vorhandene im zweiten ohne identifizierten Bedarf erfordert eine Rückkehr zur Konfiguration, bevor Sie fortfahren.
Überprüfen Sie danach, ob die erwartete physische Karte tatsächlich dem Bridge zugeordnet ist. Sie suchen die Verbindung zwischen vmbrX und dem im Vorflug erfassten Port.
bridge linkDie erwartete Ausgabe zeigt den physischen Port, der mit dem Bridge verbunden ist, mit einem kohärenten Verbindungsstatus. Wenn der Port fehlt oder wenn ein anderer Port angezeigt wird, vertrauen Sie vmbrX keine VMs an und verwenden Sie die unabhängige Konsole, um die Konfiguration zu korrigieren.
Überprüfen Sie schließlich die Route nach der Änderung. Der Befehl sollte bestätigen, dass das einzigartige Gateway an dem vorgesehenen Pfad bleibt.
ip routeDie Ausgabe sollte die erwartete Standardroute und das Gateway anzeigen. Eine fehlende Standardroute, eine konkurrierende oder von einer falschen Schnittstelle getragene Route stoppt die Validierung. Korrigieren Sie zuerst die Adressierung und den Bridge, ohne ein zweites Gateway hinzuzufügen, um das Problem zu verbergen.
Für einen Trunk übernehmen Sie die VLAN-Kontrolle nach der Anwendung. Diese muss mit dem Port des Switches und dem vorgesehenen Tag-Plänen kohärent bleiben.
bridge vlan showDie erwartete Ausgabe zeigt die nützlichen VLANs auf dem Bridge und seinem Mitgliedsport. Ein Ergebnis, das vom Plan abweicht, erfordert, die Inbetriebnahme der VMs zu stoppen und den Switch zu überprüfen. Der aktive Bridge beweist nicht für sich allein, dass der getaggte Verkehr korrekt verläuft.
Öffnen Sie jetzt von einem anderen Client oder einer anderen Sitzung eine neue SSH-Verbindung zum Knoten und laden Sie die Weboberfläche neu. Wenn diese beiden Zugänge funktionieren, während der Bridge, die Route, der Mitgliedsport und die erwarteten VLANs kohärent sind, können Sie dann das Netzwerk einer Proxmox-VM diagnostizieren, wenn ein Gast offline bleibt.
Halten Sie bis dahin die ursprüngliche Sitzung offen. Schließen Sie diese nur, nachdem Sie eine neue SSH-Verbindung eröffnet und die Weboberfläche funktioniert. Wenn einer dieser beiden Kontrollen scheitert, verwenden Sie die unabhängige Konsole und das Backup, anstatt die Umschaltungen aus der Ferne zu vervielfachen.
