Im Bereich der Automatisierung erfordert jedes Labor, das wir erstellen, ein ebenso grundlegendes wie wesentliches Merkmal: Die IP-Adressen der Geräte müssen vom Automatisierungssystem aus erreichbar sein. Während die EVE-NG PRO Version eine native Funktion (NAT Cloud) bietet, die diesen Prozess vereinfacht, müssen wir mit EVE-NG CE eine Strategie entwickeln, um das gleiche Ergebnis zu erzielen.

Unser Ziel ist es, ein zusätzliches Netzwerk in EVE-NG zu konfigurieren, das es uns ermöglicht, die Verwaltungsschnittstellen der Geräte, die wir für unsere Labore verwenden werden, zu verbinden, unabhängig davon, ob es sich um virtuelle (intern zu EVE-NG) oder physische (SPS und andere externe physische Geräte) handelt. Das folgende Diagramm (siehe Anhang1) fasst unser Ziel zusammen:

EVE-NG Networking

Zunächst müssen wir verstehen, wie die Netzwerkkonfiguration in EVE-NG funktioniert, und dies bietet die Möglichkeit, einige allgemeine Linux-Konzepte einzuführen.

In einem Linux-System werden Netzwerkschnittstellen durch verschiedene Namen repräsentiert, die typischerweise mit “eth” oder “ens” gefolgt von einer Identifikationsnummer beginnen. Diese Schnittstellen können entweder physische Netzwerkkarten oder virtuelle Netzwerkkarten repräsentieren. In unserer Umgebung finden wir, dass die physische Netzwerkkarte durch eth0 repräsentiert wird, während es auch andere Netzwerkkarten namens pnet gibt.

Wir können die Netzwerkschnittstellen des Systems mit einem der folgenden Befehle anzeigen:

ifconfig -a
ip link

Die konfigurierten pnet-Schnittstellen sind tatsächlich virtuelle Switches (Bridges), die während der Installation standardmäßig eingerichtet werden:

sudo brctl show
bridge name bridge id       STP enabled interfaces
pnet0       8000.0050568a6a54   no      eth0
pnet1       8000.000000000000   no
pnet2       8000.000000000000   no
pnet3       8000.000000000000   no
pnet4       8000.000000000000   no
pnet5       8000.000000000000   no
pnet6       8000.000000000000   no
pnet7       8000.000000000000   no
pnet8       8000.000000000000   no
pnet9       8000.000000000000   no

Insbesondere sehen wir, dass die Bridge pnet0 mit der physischen Schnittstelle eth0 verbunden ist. Mit anderen Worten, alles, was mit der Bridge pnet0 verbunden ist, wird auch über das Netzwerk eth0 übertragen. Wie wir im Webinterface sehen werden, können wir Cloud-Netzwerke hinzufügen. Cloud-Netzwerke sind nichts anderes als die pnet-Bridges. Speziell wird das Netzwerk pnet0 auch für den Webzugriff verwendet. Tatsächlich ist die Verwaltungs-IP-Adresse mit der Bridge pnet0 verbunden, wie wir mit einem der folgenden Befehle sehen können:

ifconfig pnet0
ip address show pnet0

Wir können dann eine IP-Adresse im pnet9-Netzwerk konfigurieren und die Verwaltungsschnittstellen der Geräte mit dem Cloud9-Netzwerk verbinden.

EVE-NG, das auf Ubuntu 20 basiert, konfiguriert Netzwerke über die Datei /etc/network/interfaces. Insbesondere müssen wir den Teil konfigurieren, der sich auf die Bridge pnet9 bezieht, wie folgt:

# Cloud devices
auto pnet9
iface pnet9 inet static
    address 169.254.1.1
    netmask 255.255.255.0
    bridge_ports none
    bridge_stp off

Wir verwenden das APIPA-Netzwerk, das als lokal definiert ist. In diesem Sinne haben wir innerhalb eines Unternehmenskontextes eine vernünftige Sicherheit, dass wir nicht mit anderen Netzwerken überlappen. Die restlichen Schnittstellen pnet2-9 können gelöscht werden.

Wir können die modifizierte Netzwerkkonfiguration jetzt neu laden:

sudo /etc/init.d/networking restart

Wenn wir jemals eine physische Schnittstelle mit dieser Bridge verbinden möchten, müssen wir die Zeile hinzufügen:

bridge_ports eth1

DHCP aktivieren

Aus Gründen der Bequemlichkeit wählen wir, den Netzwerkschnittstellen, die mit dem Cloud9-Netzwerk verbunden sind, automatisch IP-Adressen zuzuweisen. Dazu verwenden wir das DHCP-Protokoll über Dnsmasq.

sudo apt-get update
sudo apt-get install -y dnsmasq

Die Konfiguration von Dnsmasq erfolgt über die Konfigurationsdatei /etc/dnsmasq.conf. Konkret möchten wir nur den DHCP-Dienst aktivieren und nur für das Netzwerk, das über die Schnittstelle pnet9 verwaltet wird. Die Konfiguration lautet wie folgt:

port=0
interface=pnet9
dhcp-range=169.254.1.2,169.254.1.254,3650d
log-dhcp

Starten Sie schließlich den Dienst neu mit:

sudo systemctl restart dnsmasq

Wie wir später für den Automatisierungsteil sehen werden, benötigen wir eine stabile Zuordnung zwischen den IP-Adressen der Geräte und den Geräten selbst. Daher können wir uns nicht auf eine dynamische Zuordnung verlassen, die von Dnsmasq bereitgestellt wird, sondern müssen diese statisch definieren. Wir können den Hostnamen, unter dem sich das Gerät während der DHCP-Anforderung präsentiert, mit Dnsmasq statisch zuordnen:

dhcp-host=SW1,169.254.1.101
dhcp-host=SW2,169.254.1.102
dhcp-host=SW3,169.254.1.103
dhcp-host=SW4,169.254.1.104

Die Liste sollte mit allen Namen vervollständigt werden, die wir in diesem und zukünftigen Laboren verwenden werden.

Internetzugriff

Um unsere Umgebung abzuschließen, muss das Cloud9-Netzwerk auf das Internet zugreifen können. Mit anderen Worten muss ausgehender Verkehr (über NAT) mit der auf der Schnittstelle pnet0 konfigurierten IP-Adresse maskiert werden.

Zunächst müssen wir das Routing aktivieren, indem wir die Datei /etc/sysctl.conf ändern:

net.ipv4.ip_forward=1

Aktivieren Sie die Einstellung durch Ausführen von:

sudo sysctl -p

Konfigurieren Sie dann NAT mit IPTables, um den ausgehenden Verkehr mit der Adresse von pnet0 zu maskieren:

sudo iptables -t nat -A POSTROUTING -o pnet0 -j MASQUERADE

Um die Änderungen zu speichern, verwenden Sie:

sudo apt-get install -y iptables-persistent
sudo iptables-save > /etc/iptables/rules.v4

Obwohl nicht notwendig, wird empfohlen, das System neu zu starten, um sicherzustellen, dass alles korrekt konfiguriert ist.

Unterstützte Geräte

EVE-NG unterstützt eine breite Palette von Geräten und ist im Allgemeinen in der Lage, nahezu jedes auf x86 basierende Gerät auszuführen. Für weitere Informationen siehe die Supported images enthaltene Liste der unterstützten Geräte.

Für die Labortragbarkeit und damit für eine einfache Labornutzung ist es wichtig, den korrekten Namen zu verwenden. Andernfalls müssen Sie das Labor vor dem Start zuweisen.

Kopieren Sie den Inhalt des iol-Verzeichnisses in das Verzeichnis /opt/unetlab/addons/iol. Dies kann mit PuTTY oder WinSCP (Windows) oder direkt mit SSH (Mac) erfolgen:

scp i86bi_linux_l- root@172.25.82.222:/opt/unetlab/addons/iol/bin/
scp iourc root@172.25.82.222:/opt/unetlab/addons/iol/bin/

Führen Sie dann auf der EVE-NG-Maschine aus:

sudo /opt/unetlab/wrappers/unl_wrapper -a fixpermissions

Erstellen des ersten Labors

Der letzte Schritt besteht darin, das erste tatsächliche Labor zu erstellen. Verbinden Sie sich über das Web mit der EVE-NG-Maschine, indem Sie beim Anmelden den Html5-Konsolenmodus auswählen:

• Gehen Sie zu Add new lab;
• Fügen Sie ein Netzwerk hinzu, indem Sie rechts auf Add an object -> Network gehen

• Fügen Sie einen IOL-Knoten hinzu, indem Sie zu Add an object -> Node gehen

• Verbinden Sie Router R1:e0/0 mit dem Internetnetzwerk

• Starten Sie den Router R1, indem Sie rechts auf More actions -> Start all nodes gehen

Greifen Sie dann auf die Konsole von Router R1 zu und konfigurieren Sie ihn wie folgt:

username admin privilege 15 password cisco
hostname R1
ip domain-name example.com
interface Ethernet0/0
  ip address dhcp
  no shutdown
crypto key generate rsa modulus 2048
ip ssh version 2
line vty 0 4
  transport input ssh
  login local

Wenn unsere Umgebungskonfiguration korrekt durchgeführt wurde, sollten wir:

• Eine konfigurierte IP-Adresse auf R1:e0/0 sehen
• In der Lage sein, eine Verbindung zu R1 von der EVE-NG-Maschine herzustellen

Wenn wir versuchen, eine Verbindung zu R1 über SSH herzustellen, können wir auf folgenden Fehler stoßen:

Unable to negotiate with 169.254.1.186 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

Der Grund dafür ist, dass das von R1 verwendete Image veraltet ist und immer noch als veraltet und unsicher geltende Protokolle verwendet. Auf der EVE-NG-Maschine müssen wir in der Datei /root/.ssh/config einige veraltete und unsichere Konfigurationen aktivieren (in einer Testumgebung durchzuführen, aber nicht in Produktion):

KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
HostKeyAlgorithms ssh-rsa,ssh-dss

Host *
    ServerAliveInterval 5
    ServerAliveCountMax 3

An diesem Punkt sollten wir in der Lage sein, eine Verbindung zu R1 über SSH herzustellen.

Der abschließende Test, der unsere Umgebung validiert, besteht darin, von R1 zu einer Internetadresse zu pingen, zum Beispiel 8.8.8.8:

R1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 11/11/12 ms