Routing mit Linux in virtuellen Umgebungen

Vor 4 Jahren hatte ich einen Blog geschrieben, wie man einen Microsoft Hyper-V Server 2016 als Router “verwenden” kann.

Natürlich stellt man sich dabei die Frage, wieso man das tun sollte? Zum einen ist der Hyper-V Server von Microsoft kostenlos und hat als Mitglied der Windows Server Core Familie geringere Systemanforderungen.

Es gibt hier eine Alternative, dazu müssen wir aber die Windows-Welt verlassen und uns Linux anschauen. Ich selbst bin historisch mit SUSE Linux verbunden, daher habe ich für diese Lösung openSUSE Leap 15.2 verwendet.

Als Ausgangslage haben wir die gleichen Voraussetzungen wie im Blog damals, also gleiche Netzwerke, IP-Adressen und die FRITZ!box usw. Also einfach mal den Blog nochmals anschauen, dort ist auch die Konfiguration der FRITZ!box selbst beschrieben.

Ausgangslage

Hier eine kurze Zusammenfassung davon:

  • Server mit 3 Netzwerkkarten (172.16.16.253, 192.168.110.0 und 192.168.120.1)
  • Fritz!BOX für den Internet-Zugang
  • Netzwerk an der FRITZ!box ist 172.16.16.0/24, das Gateway ist immer die 1 (also die FRITZ!box selbst)

Konfiguration der Linux VM

Für die VM unter Hyper-V habe ich die folgenden Parameter verwendet:

  • Hyper-V Generation 2 VM mit deaktiviertem Secure Boot
  • 2 CPUs
  • Dynamischer Hauptspeicher mit 1GB Start und maximal 2GB, im Betrieb läuft die VM mit grob 800MB
  • 64GB Festplatte (wobei hier auch weniger ausreichend ist), da die VHDX aber dynamisch ist, stellen die 64GB kein Problem dar
  • Zum Start nur einen Netzwerk-Adapter, wobei im Verlauf der Konfiguration weitere hinzugefügt werden

Die folgende Abbildung zeigt eine Übersicht der VM.

image

Installation openSUSE Leap 15.2 in der VM

Für die Installation wird das ISO-Image gemounted und die VM gestartet.

image

Im nun folgenden Menü Installation auswählen und den Dingen seinen Lauf lassen.

image

Da die VM über den einen Adapter eine IP-Adresse vom DHCP-Server bekommen hat, ist das Linux Setup in der Lage ggf. notwendige Updates aus dem Netz zu laden. Nach knapp 2min erscheint die Auswahl zur Konfiguration der Tastatur und der Lizenzvereinbarung. Ich verwende gerne VMs in englischer Sprache (English US) dazu aber eine Tastatur mit den deutschen (QWERTZ) Layout.

image

Hier dann auf Next drücken. Im nun folgenden Menü können wir auf eine Aktivierung von Online Repositories für unseren Zweck verzichten, also No auswählen.

image

Da wir einen schlanken Server wollen, treffen wir die Auswahl Server bei der Abfrage der System Role. Damit  haben wir zwar keine Oberfläche, können aber auf YaST zurück greifen, der alle notwendigen Aufgaben für uns erledigen kann.

image

Weiter geht es mit Next mit dem Vorschlag der Partitionierung die wir so übernehmen können.

image

Hier ebenfalls mit Next die Installation fortsetzen. Als Zeitzone wähle ich Europe und Germany und drücke abermals den Next Button.

Der Benutzer der im nächsten Schritt angelegt wird, findet später seine Verwendung für alle Aufrufe mit sudo.

image

Mit der Übersicht der gewählten Parameter kann die Installation starten.

image

Die gut 800 Pakete mit knapp 2GB Gesamtgröße installiert das Setup relativ schnell, für einen Kaffee reicht es aber trotzdem Smile

Konfiguration der Netzwerk-Adapter

Nach dem Neustart kann das ISO von der VM entfernt werden und die Anmeldung erfolgen.

image

YaST wird danach mit dem sudo Befehl gestartet und alle weiteren Schritte erfolgen im YaST Control Center unter System / Network Settings.

image

Als erstes verpassen wir der Netzwerkkarte eine feste IP (172.16.16.253/24). Dazu wird mit Edit die Konfiguration bearbeitet. Innerhalb von YaST springt man mit der TAB-Taste zwischen den einzelnen Menüpunkten hin und her. Zusätzlich zur IP-Adresse setze ich auch gleich den Hostnamen.

image

Mit Next bekommen wir wieder die Übersicht über die gemachten Einstellungen.

image

In den Einstellungen System / Network Settings / Hostname / DNS trage ich nochmals einen statischen Hostnamen ein und dazu noch die beiden im Netzwerk vorhandenen DNS-Server.

Mit Quit wird YaST beendet und die VM heruntergefahren, was wieder mit einem sudo shutdown erfolgt. Das Herunterfahren der VM ist notwendig, da ich zwei weitere  Netzwerk-Adapter hinzufüge die mit den Netzen 192.168.110.0/24 und 192.168.120.0/24 konfiguriert werden.

image

Der Trick, nur einen der beiden neuen Netzwerk-Adapter zu verbinden funktioniert unter Linux leider nicht, beide werden als Not Connected dargestellt. Nach dem Start der VM sind beide Netzwerk-Adapter zusätzlich sichtbar und können konfiguriert werden.

image

Welcher nun der richtige Adapter ist, lässt sich über die MAC-Adresse herausfinden.

image

Der Adapter eth1 bekommt nun die IP-Adresse 192.168.110.1/24 und dient zukünftig als Gateway für dieses Subnetz.

image

Analog dazu Adapter eth2 mit der Konfiguration 192.168.120.1/24 hier die Zusammenfassung aller Netzwerk-Adapter.

image

Was fehlt nun eigentlich noch? Richtig, wir haben das Routing selbst nicht aktiviert und ein Gateway ist ebenfalls noch nicht konfiguriert. Das erfolgt in den nächsten beiden Schritten.

Gateway und Routing

Die bisher gemachten Konfigurationen kann man mit der Auswahl von Next einfach mal schreiben lassen und hat diese damit gesichert.

Danach sind wir wieder im YaST Control Center unter System / Network Settings unterwegs.

image

Dort wird unter Network Settings / Routing die Weiterleitung für IPv4 aktiviert (wer hier IPv6 benötigt, bitte zusätzliche diese Option auswählen).

image

Damit fehlt nur noch das Gateway und das ist im YaST in der Textversion nach meiner Meinung fies versteckt.

Der Dialog zur Konfiguration ist unter System / Network Settings / Routing und dann unter der Option Add zu finden.

image

Hier wird das Gateway 172.16.16.1 für den Adapter mit der IP-Adresse 172.16.16.253 konfiguriert und damit die Konfiguration abgeschlossen.

Wer will, kann die VM nochmals neustarten. Bei mir hat es ohne diesen geklappt und der Router war fast fertig, denn natürlich muss noch die Firewall konfiguriert werden, sonst geht bei der Einstellung default nur der Ping durch.

Konfiguration der Firewall

Die Firewall in openSUSE verwendet Zonen, die eine Sammlung von geöffneten Ports und Protokollen darstellen. Ich habe die Firewall auf trusted gesetzt, damit ist ein interner Datenverkehr ohne weiteren Einschränkungen möglich.

image

Dazu werden die Netzwerk-Adapter mittels YaST von der Zone default in die Zone trusted geändert.

image

Enjoy it, b!

NIC Teaming: Warning 16945 MsLbfoSysEvtProvider

Wird auf einem Windows Server (egal ob 2012R2, 2016 oder 2019) ein Lbfo-Team erstellt, schreibt das Betriebssystem nach einem Neustart die folgende Meldung (Warning) in das System-Eventlog.

image

Ein Blick auf alle vorhandenen MAC-Adressen zeigt, dass hier Adressen doppelt vergeben worden sind. Das erstellte Team (hier Team Ethernet 1) besitzt die gleiche MAC-Adresse wie einer der für das Team verwendeten Adapter.

image

Hier nochmals die MAC-Adressen.

  • TEAM Team Ethernet 1 = 0C-C4-7A-41-7B-47
  • NIC Ethernet = 0C-C4-7A-41-7B-47
  • Hyper-V Virtual Switch vEthernet (_ Network 172.16.32.0) = 0C-C4-7A-41-7B-47

Das Problem beheben wir damit, dass alle Adapter die eine gleiche Adresse haben abgeändert werden. Dabei ist es sinnvoll MAC-Adressen des Teams und des Hyper-V Virtual Switches zu ändern, anstatt die MAC der NIC zu überschreiben. Dort ist diese nämlich fest hinterlegt, im Team und im Hyper-V Switch jedoch nicht.

  • TEAM Team Ethernet 1 = 0C-C4-7A-41-7B-45

  • Hyper-V Virtual Switch vEthernet (_ Network 172.16.32.0) =
    0C-C4-7A-41-7B-48

Das kann man über die GUI erledigen, oder falls ein Windows Server Core vorliegt mit PowerShell.

# Ändern der MAC-Adresse des Teams "Team Ethernet 1"
Set-NetAdapter -Name "Team Ethernet 1" -MacAddress "0C-C4-7A-41-7B-45"
# Ändern der MAC-Adresse des Hyper-V Switches "vEthernet (_ Network 172.16.32.0)"
Set-NetAdapter -Name "vEthernet (_ Network 172.16.32.0)" -MacAddress "0C-C4-7A-41-7B-48"

Nach der Änderung sieht die Vergabe der MAC-Adressen wie folgt aus und die Warnung 16945 wird beim nächsten Neustart nicht mehr ins Eventlog geschrieben.

image

Update zum Windows Server 2019:

Auf einem Windows Server 2019 hatte ich folgendes Verhalten, dort wurden die MAC-Adressen im Wechsel verteilt. Der Hyper-V Switch kollidierte mit MAC-Adresse des der ersten NIC, das Team mit der MAC-Adresse der zweiten NIC.

image

Beheben lässt sich das Problem aber auf die gleiche Weise. Hier nochmals die MAC-Adressen.

  • TEAM Team Ethernet 1 = AC-1F-6B-F6-3E-C1
  • NIC Ethernet = AC-1F-6B-F6-3E-C1
  • Hyper-V Virtual Switch vEthernet (_ Network 172.16.32.0) = AC-1F-6B-F6-3E-C0
  • NIC Intel Ethernet I210 #2 = AC-1F-6B-F6-3E-C0

image

  • TEAM Team Ethernet 1 = AC-1F-6B-F6-3E-C3
  • NIC Ethernet = AC-1F-6B-F6-3E-C1
  • Hyper-V Virtual Switch vEthernet (_ Network 172.16.32.0) =
    AC-1F-6B-F6-3E-C2
  • NIC Intel Ethernet I210 #2 = AC-1F-6B-F6-3E-C0

Enjoy it, b!