In ambito automazione, ciascun laboratorio che andremo a creare ha bisogno di una caratteristica tanto banale quanto essenziale: gli indirizzi IP dei dispositivi devono essere accessibili dal sistema di automazione. Se la versione di EVE-NG PRO ha una feature nativa (NAT Cloud) che ci semplifica la vita, su EVE-NG CE dobbiamo trovare una strategia che ci permetta di ottenere lo stesso risultato.

Il desiderio è quello di poter configurare una rete aggiuntiva su EVE-NG che ci permetta di collegare le interfacce di management dei dispositivi che useremo per i nostri laboratori, sia che essi siano virtuali (interni a EVE-NG) sia che essi siano fisici (PLC, e dispositivi fisici esterni in genere). Il diagramma sotto (allegato1) riassume il nostro proposito:

Il networking di EVE-NG

Prima di tutto dobbiamo chiarire come è fatto il networking di EVE-NG e cogliamo l’occasione per introdurre alcuni concetti in ambito Linux in generale.

Un sistema Linux rappresenta le proprie schede di rete secondo vari nomi, costruiti da un prefisso (eth, ens…) associati solitamente ad un numero identificativo. Le schede di rete possono rappresentare una scheda di rete vera e propria o una scheda di rete virtuale. Nel caso del nostro ambiente troveremo che la scheda di rete fisica è rappresentata da eth0, ma ci sono altre schede di rete denominate pnet.

Possiamo vedere le schede di rete del sistema con uno dei seguenti comandi:

ifconfig -a
ip link

Le interfacce pnet configurate sono in realtà degli switch virtuali (bridge) configurati di default durante l’installazione:

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

In particolare vediamo che il bridge pnet0 è associata all’interfaccia fisica eth0. O, in altre parole, tutto ciò che sarà associato al bridge pnet0 verrà trasmesso anche sulla rete eth0. Come vedremo nell’interfaccia web potremo aggiungere delle reti Cloud. Le reti Cloud non sono altro che i bridge pnet. In particolare la rete pnet0 è utilizzata anche per l’accesso web. Infatti l’indirizzo IP di management è associato al bridge pnet0, come possiamo vedere usando uno dei seguenti comandi:

ifconfig pnet0
ip address show pnet0

Possiamo quindi configurare un indirizzo IP sulla rete pnet9 e collegare le interfacce di management dei dispositivi sulla rete Cloud9.

EVE-NG, che è basata su Ubuntu 20, configura le reti tramite il file /etc/network/interfaces. In particolare dobbiamo configurare la parte relativa al bridge pnet9 come segue:

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

Utilizziamo la rete APIPA che è definita per essere locale. In questo senso, in ambito Enterprise, abbiamo una ragionevole certezza di non essere in overlapping con altre reti. Le rimanenti interfacce pnet2-9 possono essere cancellate.

Possiamo ora ricaricare la configurazione di rete appena modificata:

sudo /etc/init.d/networking restart

Se un giorno volessimo associare una interfaccia fisica a questo bridge, dovremo aggiungere la riga:

bridge_ports eth1

Attivare DHCP

Per comodità scegliamo di assegnare automaticamente gli indirizzi IP alle interfacce di rete connesse alla rete Cloud9. Per fare questo utilizziamo il protocollo DHCP tramite Dnsmasq.

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

La configurazione di Dnsmasq) avviene tramite il file di configurazione /etc/dnsmasq.conf. In particolare noi desideriamo avere attivo il solo servizio DHCP e solo per la rete gestita dall’interfaccia pnet9. La configurazione risulta quindi:

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

Al termine, riavviamo il servizio con:

sudo systemctl restart dnsmasq

Come vedremo in seguito, per la parte automazione, ci servirà avere una associazione stabile tra gli indirizzi IP dei dispositivi e i dispositivi stessi. Non possiamo quindi affidarci ad una mappatura dinamica data da Dnsmasq, ma dobbiamo definirla staticamente. Possiamo mappare il nome host con il quale il dispositivo si presenterà durante la richiesta DHCP e mapparla staticamente su Dnsmasq:

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

L’elenco dovrà ovviamente essere completato con tutti i nomi che useremo su questo e sui futuri laboratori.

Accedere a Internet

Per completare il nostro ambiente, occorre che la rete Cloud9 possa accedere ad Internet. In altre parole occorre che il traffico in uscita venga mascherato (tramite NAT) utilizzando l’indirizzo IP configurato nell’interfaccia pnet0.

Dobbiamo quindi per prima cosa attivare il routing modificando il file /etc/sysctl.conf:

net.ipv4.ip_forward=1

Attiviamo l’impostazione eseguendo:

sudo sysctl -p

Configuriamo quindi la NAT utilizzando IPTables in modo da mascherare il traffico uscente con l’indirizzo di pnet0:

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

Per salvare le modifiche utilizziamo:

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

Sebbene non necessario, al termine consiglio di effettuare un reboot del sistema per verificare che tutto sia configurato correttamente.

I dispositivi supportati

EVE-NG supporta un grande numero di dispositivi e, in generale, è in grado di eseguire quasi qualsiasi dispositivo basato su sistemi x86. Per maggiori informazioni si veda la Supported images contenente l’elenco dei dispositivi supportati.

Per la portabilità dei laboratori, e quindi per poter usare facilmente i laboratori, è importante utilizzare il nome corretto. In caso contrario sarà necessario modificare il laboratorio assegnando le immagini corrette prima di avviarlo.

Copiamo quindi il contenuto della directory iol nella directory /opt/unetlab/addons/iol. La copia può essere fatta con PuTTY o WinSCP (Windows) o direttamente con SSH (Mac):

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/

Al termine, sulla macchina EVE-NG, eseguire:

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

Creare il primo laboratorio

L’ultimo passo è quindi quello di creare il primo laboratorio vero e proprio. Colleghiamoci alla macchina EVE-NG via Web selezionando, al login, la modalità Html5 console:

• andiamo su Add new lab;
• aggiungiamo una rete andando a destra su Add an object -> Network

• aggiungiamo un nodo IOL andando su Add an object -> Node

• colleghiamo il router R1:e0/0 alla rete Internet

• avviamo il router R1 andando a destra su More actions -> Start all nodes

Accediamo quindi alla console del router R1 e configuriamolo come segue:

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

Se la configurazione del nostro ambiente è stata fatta in modo corretto dovremmo:

• vedere un indirizzo IP configurato su R1:e0/0
• poter collegarci ad R1 dalla macchina EVE-NG

Probabilmente collegandoci ad R1 via SSH otterremo il seguente errore:

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

Il motivo è che l’immagine usata da R1 è obsoleta e utilizza ancora dei protocolli considerati obsoleti e insicuri. Sulla macchina EVE-NG occorre quindi abilitare nel file /root/.ssh/config delle configurazioni obsolete e insicure (da fare in ambiente di test, ma non in produzione):

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

Host *
    ServerAliveInterval 5
    ServerAliveCountMax 3

A questo punto dovrebbe essere possibile collegarci ad R1 via SSH.

L’ultimo test che convalida il nostro ambiente è quello di effettuare un ping da R1 ad un indirizzo su Internet, ad esempio 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