Archiv der Kategorie: Networking

Routing mit Linux in virtuellen Umgebungen

Veröffentlicht am von
Antwort

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

Veröffentlicht am von
3

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!

Hyper-V, Umstellung und Konfiguration von Switch Embedded Teaming (SET)

Veröffentlicht am von
Antwort

Seit Windows Server 2016 bietet Hyper-V die Möglichkeit des Switch Embedded Teaming (SET). Dieser Blog beschreibt die Umstellung eines Hyper-V Hosts (Windows Server 2019) von normalen Teaming auf SET.

  1. https://redmondmag.com/articles/2020/03/17/hyperv-switch-embedded-teaming-1.aspx
  2. https://redmondmag.com/articles/2020/03/19/hyperv-switch-embedded-teaming-2.aspx

Da in der Regel auf Hyper-V Hosts VMs aktiv sind, sollten hier einige Vorsichtsmaßnahmen ergriffen werden.

  1. Shutdown aller VMs
  2. Für den Fall, dass eine VM automatisch startet muss diese Aktion ebenfalls deaktiviert werden
  3. Anlegen oder aktivieren eines lokalen Admins, der auch funktioniert Winking smile

Im ersten Schritt werden alle mit dem zu lösenden Team verbundenen Virtual Switches auf Internal oder Private Network umgestellt, nur dann lässt sich ein bestehendes Team löschen.

image

Die Umstellung ist temporär und damit verlieren die darauf laufenden VMs ihre Verbindung ins Netzwerk und werden darum wie in Punkt 1 oben geschrieben am besten heruntergefahren.

Der PowerShell Befehlt Get-NetLbfoTeam, zeigt die vorhandenen Teams an.

image

Beide Teams (also Team Ethernet 1 und Team Ethernet 2) werden nun gelöscht und zu einem SET verbunden.

# Löschen eines Teams
Remove-NetLbfoTeam -Name "Team Ethernet 1"
Remove-NetLbfoTeam -Name "Team Ethernet 2"
# Löschen aller Teams
Get-NetLbfoTeam | Remove-NetLbfoTeam

Hier sollte klar sein, dass damit auch die Netzwerkverbindung zum Hyper-V Host verloren geht. Ist ein DHCP-Server vorhanden, werden die Adapter von diesem neue Adressen bekommen, ansonsten kann nun nur noch der Zugriff über die Konsole oder ein ILO-Board erfolgen. Siehe hier Punkt 3 oben, wir brauchen dann einen funktionierenden lokalen Administrator.

Das SET wird nun über diesen Befehl eingerichtet.

# Konfiguration eines SET Switch embedded teams
New-VMSwitch -Name "_ Network 172.16.16.0" -NetAdapterName "Ethernet","Ethernet 2","Ethernet 3","Ethernet 4" -EnableEmbeddedTeaming $true -AllowManagementOS $true

Was nicht wirklich gut aus der Microsoft Dokumentation von New-VMSwitch hervorgeht, ist die Beschreibung von –EnableEmbeddedteaming.

Bei mehr als einem Adapter, wird automatisch –EnableEmbeddedTeaming $true verwendet, bei nur einem Adapter –EnableEmbeddedTeaming $false. Soll also ein SET gebaut werden, der zu Beginn nur einen Adapter besitzt und irgendwann erweitert wird, dann muss unbedingt –EnableEmbeddedTeaming $true verwendet werden.

-AllowManagementOS $true ist notwendig, damit auch der Hyper-V Host den Adapter verwenden kann, wir also mit einem konvergierten Adapter arbeiten. Nur dann kann eine IP-Adresse darauf gebunden werden.

Danach kann mit sconfig wieder die korrekte / alte IP des Adapters gesetzt werden und im Hyper-V Manager steht dieser dann wie folgt zur Verfügung.

image

Damit sind wir fertig, leider nein … es können nämlich eine Reihe von Dingen schief gehen!

Bei einigen, nicht bei allen Umstellungen habe ich die folgende Meldung erhalten.

External Ethernet adapter ‚Intel(R) 82574L Gigabit Network Connection‘ is already bound to the Microsoft Virtual Switch protocol.

Dadurch lässt sich der Adapter nicht in das SET aufnehmen und bedarf einer zusätzlichen Behandlung. Wahrscheinlich auch mit PowerShell möglich, habe ich aber ncspbind den Vorzug gegeben.

Das Tool ist in dem folgenden KB-Artikel beschrieben:

Creating V-switches within the hyper-V environment fails

Der folgende Befehl löst dieses Problem:

nvspbind /u “AdapterName”

Wenn ich mir nicht sicher bin, ob meine Adapter noch sauber funktionieren, gibt es die Möglichkeit diese komplett zurück zu setzen. Mit komplett meine ich komplett!!!!

netcfg –d

Danach hilft nur noch die Anmeldung über das ILO-Board und ein durchgeführter Neustart des Servers, nun kann ebenfalls der SET konfiguriert werden.

Mit einem Scanner, wie zum Beispiel dem Advanced IP-Scanner lassen sich IPs in einfach auffinden. Das Tool, habe ich bei solchen Umstellungen immer parat.

Enjoy it, b!

IPv6 Configuration OpenSuse Leap

Veröffentlicht am von
Antwort

Verwendet man eine FRITZ!Box in seinem LAN dann kann einem die schwer kontrollierbare Vergabe von IPv6-Adressen durchaus Probleme machen. Das Deaktivieren von IPv6 auf allen Windows Systemen halte ich hier für keine saubere Lösung, vielmehr habe ich mich dazu entschlossen die IPv6-Adressen selbst zu vergeben. Darüber will ich in diesem Blog aber gar nicht schreiben, sondern wie einem openSUSE Server eine funktionierende IPv6 Konfiguration eingestellt werden kann.

Eckdaten

  • IPv6 Adresse für den OpenSuse Server: fd8e:5644:167b:100a::18
  • IPv6 Adresse für den Router / Gateway: fd8e:5644:167b:100a::1
  • Interface für die Konfiguration: eth0

Konfiguration

Im Gegensatz zu Windows, ist es bei Linux möglich IP-Adressen nur zur Laufzeit zu konfigurieren oder aber statisch, damit die Konfiguration einen Neustart überlebt.

Die Konfiguration zur Laufzeit ist dabei recht einfach, benötigt aber die Rechte des SU.

# ip -6 address add fd8e:5644:167b:100a::18/64 dev eth0

# ip -6 route add default via fd8e:5644:167b:100a::1 dev eth0

Statisch erfolgt die Konfiguration wie folgt:

# cd /etc/sysconfig/network

# vi ifcfg-eth0

# hinzufügen der folgenden Zeilen ans Ende der Datei (ifcfg-eth0)
LABEL_0='0'
IPADDR_0='fd8e:5644:167b:100a::18'
PREFIXLEN_0='64'

# echo 'default fd8e:5644:167b:100a::1 - -' >> /etc/sysconfig/network/routes

Damit die Konfiguration aktiv wird, entweder den Server neu starten oder den folgenden Befehl ausführen.

# service network restart

Enjoy it, b!

Routing auf einem Hyper-V Server 2016

Veröffentlicht am von
1

Mit ein paar Handgriffen kann ein Hyper-V Server zum Routen von IP bewegt werden.

Ausgangslage

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

Der Server soll IP-Pakete vom Subnetz 192.168.120.0/24 ins 172er Netzwerk übertragen, und umgekehrt sollen Datenpakete aus dem 172er Netzwerk in das 192er Netzwerk geroutet werden. Alle Hosts im 172er Netzwerk haben die Fritz!BOX selbst als Gateway eingetragen. Daher muss dieser gesagt werden, wohin Pakete mit 192.168.120.0 geroutet werden sollen, nämlich auf die IP-Adresse 172.16.16.253 welches den ersten Adapter des Servers darstellt.

Konfiguration Fritz!BOX

Dazu wird folgende Route in der Fritz!BOX eingetragen:image

Die Konfiguration erfolgt über innerhalb der Fritz!BOX:

Heimnetz / Heimnetzübersicht / Netzwerkeinstellungen / Statische Routingtabelle

Konfiguration des Hyper-V Servers mit PowerShell

Auf dem Hyper-V Server sind die beiden Netzwerk-Adapter wie folgt konfiguriert:

Ethernet 2 172.16.16.253/24 Gateway 172.16.16.1
Ethernet 4 192.168.120.1/24 Gateway 192.168.120.1

Mit PowerShell ist die Konfiguration einfach.

Im ersten Schritt schauen wir uns an, ob und welche IP-Adressen schon vergeben sind.

PS C:\Temp> Get-NetIPAddress |ft

ifIndex IPAddress                                       PrefixLength PrefixOrigin SuffixOrigin AddressState PolicyStore
------- ---------                                       ------------ ------------ ------------ ------------ -----------
6       192.168.110.1                                             24 Manual       Manual       Preferred    ActiveStore
3       172.16.16.253                                             24 Manual       Manual       Preferred    ActiveStore
4       169.254.19.2                                              16 WellKnown    Link         Preferred    ActiveStore
1       127.0.0.1                                                  8 WellKnown    WellKnown    Preferred    ActiveStore

Wir sehen, der Adapter mit dem Interface-Index 3 (ifIndex) hat eine Adresse aus dem 172er Netzwerk. Der Adapter mit dem ifIndex 4 hat noch eine APIPA-Adresse aus dem 169er Netzwerk und soll nun die IP aus dem 192er Netzwerk bekommen.

Der Name des Adapters lässt sich übrigens mit Get-NetAdapter ermitteln

PS C:\Temp> Get-NetAdapter

Name                      InterfaceDescription                    ifIndex Status       MacAddress             LinkSpeed
----                      --------------------                    ------- ------       ----------             ---------
Ethernet 2                Microsoft Hyper-V Network Adapter #2          3 Up           00-15-5D-10-DB-00         2 Gbps
Ethernet 3                Microsoft Hyper-V Network Adapter #3          6 Up           00-15-5D-10-DB-01        10 Gbps
Ethernet                  Microsoft Hyper-V Network Adapter             4 Up           00-15-5D-10-DB-02        10 Gbps

Nun konfigurieren wir mit PowerShell die IP-Adresse aus dem 192.168.120.0 Netzwerk.

PS C:\Temp> New-NetIPAddress -InterfaceIndex 4 -IPAddress 192.168.120.1 -PrefixLength 24 -DefaultGateway 192.168.120.1


IPAddress         : 192.168.120.1
InterfaceIndex    : 4
InterfaceAlias    : Ethernet
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 24
PrefixOrigin      : Manual
SuffixOrigin      : Manual
AddressState      : Tentative
ValidLifetime     : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource      : False
PolicyStore       : ActiveStore

IPAddress         : 192.168.120.1
InterfaceIndex    : 4
InterfaceAlias    : Ethernet
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 24
PrefixOrigin      : Manual
SuffixOrigin      : Manual
AddressState      : Invalid
ValidLifetime     : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource      : False
PolicyStore       : PersistentStore

Abschließend müssen wir noch die Weiterleitung von IP-Paketen aktivieren (IP-Forwarding).

PS C:\Temp> Set-NetIPInterface -InterfaceIndex 4 -Forwarding Enabled

Ich habe das auf einem relativ neuem Microsoft Hyper-V Server 2016 durchgeführt, sollte aber auch auf dem Hyper-V Server 2012 R2 und jedem anderen Windows Server funktionieren, welcher die PowerShell-Befehle unterstützt. Ansonsten ist Netsh.exe unser Freund.

Enjoy it, b!