Monthly Archives: Novembre 2018

Instradamento del traffico di rete e configurazione di rotte statiche

Una macchina linux può essere configurata per funzionare come router, ovvero può essere utilizzata per facilitare la comunicazione tra due o più dispositivi. Per capire come funziona, utilizzeremo il seguente esempio:

       box1                       routingvm                        box2
+---------------------+      +----------------------+      +-------------------+
|                     |      |                      |      |                   |
|                     |      |                      |      |                   |
|  +---------------+  |      |    +---------------+ |      |                   |
|  |enp0s8:        |<-----------> |enp0s8:        | |      |                   |
|  |192.168.10.101 |  |      |    |192.168.10.100 | |      |                   |
|  |255.255.255.0  |  |      |    |255.255.255.0  | |      |                   |
|  +---------------+  |      |    +---------------+ |      |                   |
|                     |      |                      |      |                   |
|                     |      |                      |      |                   |
|                     |      |    +---------------+ |      |  +--------------+ |
|                     |      |    |enp0s9:        | |      |  | enp0s8:      | |
|                     |      |    |10.0.0.10      |<--------->| 10.0.0.11    | |
|                     |      |    |255.255.255.0  | |      |  | 255.255.255.0| |
|                     |      |    +---------------+ |      |  +--------------+ |
|                     |      |                      |      |                   |
|   +------------+    |      |    +-----------+     |      |  +----------+     |
|   |enp0s3      |    |      |    |enp0s3     |     |      |  | enp0s3   |     |
|   +-----+------+    |      |    +----+------+     |      |  +-----+----+     |
|         |           |      |         |            |      |        |          |
+---------------------+      +----------------------+      +-------------------+
          |                            |                            |
          v                            v                            v
+------------------------------------------------------------------------------+
|                        router (e.g. cisco router)                            |
|                                 (10.0.2.2)                                   |
+------------------------------------------------------------------------------+
                                       |
                                       v
+------------------------------------------------------------------------------+
|                                   INTERNET                                   |
|                                                                              |
+------------------------------------------------------------------------------+

In questo diagramma, box1, routingvm e box2 sono tutte macchine CentOS/RedHat. L’obiettivo è ottenere che box1 possa eseguire correttamente il ping verso box2. Tuttavia, box1 e box2 si trovano su reti private diverse, il che significa che non esiste un percorso diretto tra i due dispositivi e se provassimo ad effettuare un ping su box2 fallirebbe:

[root@box1 ~]# ping -c 3 10.0.0.11
PING 10.0.0.11 (10.0.0.11) 56(84) bytes of data.

--- 10.0.0.11 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2001ms

Tuttavia, routingvm è un membro di entrambe le reti private, quindi può potenzialmente essere configurato per far comunicare i due host.

Nota: tutte e tre gli host possono raggiungere Internet tramite le rispettive interfacce di rete enp0s3. L’interfaccia di rete enp0s3 è designata solo per l’accesso ad internet, quindi non sarà possibile eseguire il ping di box2 via internet.

Nella configurazione di cui sopra ci sono 2 reti interne private, dove:

box1 (tramite la rete enp0s8) appartiene a una rete interna privata, 192.168.10.0/24.
box2 (tramite la rete enp0s8) appartiene a una rete interna privata, 10.0.0.0/24.
routingvm è membro di entrambe queste reti interne private. È un membro del 192.168.10.0/24, tramite la scheda di rete enp0s8, ed è un membro di 10.0.0.0/24 tramite la scheda di rete enp0s9.

Ciò significa che routingvm può eseguire il ping sia in box1 che in box2:

# pinging box1
[root@routingvm ~]# ping -c 3 192.168.10.101
PING 192.168.10.101 (192.168.10.101) 56(84) bytes of data.
64 bytes from 192.168.10.101: icmp_seq=1 ttl=64 time=0.268 ms
64 bytes from 192.168.10.101: icmp_seq=2 ttl=64 time=0.438 ms
64 bytes from 192.168.10.101: icmp_seq=3 ttl=64 time=0.306 ms

--- 192.168.10.101 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.268/0.337/0.438/0.074 ms

# pinging box2
[root@routingvm ~]# ping -c 3 10.0.0.11
PING 10.0.0.11 (10.0.0.11) 56(84) bytes of data.
64 bytes from 10.0.0.11: icmp_seq=1 ttl=64 time=0.280 ms
64 bytes from 10.0.0.11: icmp_seq=2 ttl=64 time=0.317 ms
64 bytes from 10.0.0.11: icmp_seq=3 ttl=64 time=0.300 ms

--- 10.0.0.11 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.280/0.299/0.317/0.015 ms

Sfortunatamente, l’output sopra riportato non mostra l’interfaccia utilizzata dal comando ping. Ma puoi ottenere queste informazioni usando il comando ip:

# routing info for box1
[root@routingvm ~]# ip route get 192.168.10.101
192.168.10.101 dev enp0s8  src 192.168.10.100
    cache

# routing info for box2
[root@routingvm ~]# ip route get 10.0.0.11
10.0.0.11 dev enp0s9  src 10.0.0.10
    cache

Anche qui c’è la tabella di routing per routingvm:

[root@routingvm ~]# ip route list
default via 10.0.2.2 dev enp0s3  proto static  metric 100
10.0.0.0/24 dev enp0s9  proto kernel  scope link  src 10.0.0.10  metric 100
10.0.2.0/24 dev enp0s3  proto kernel  scope link  src 10.0.2.15  metric 100
192.168.10.0/24 dev enp0s8  proto kernel  scope link  src 192.168.10.100  metric 100

box1 e box2 possono entrambi eseguire il ping di routingvm:

[root@box1 ~]# ping -c 3 192.168.10.100
PING 192.168.10.100 (192.168.10.100) 56(84) bytes of data.
64 bytes from 192.168.10.100: icmp_seq=1 ttl=64 time=0.246 ms
64 bytes from 192.168.10.100: icmp_seq=2 ttl=64 time=0.272 ms
64 bytes from 192.168.10.100: icmp_seq=3 ttl=64 time=0.314 ms

--- 192.168.10.100 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.246/0.277/0.314/0.031 ms


[root@box1 ~]# ip route get 192.168.10.100
192.168.10.100 dev enp0s8  src 192.168.10.101
    cache


[root@box1 ~]# ip route list
default via 10.0.2.2 dev enp0s3  proto static  metric 100
10.0.2.0/24 dev enp0s3  proto kernel  scope link  src 10.0.2.15  metric 100
192.168.10.0/24 dev enp0s8  proto kernel  scope link  src 192.168.10.101  metric 100

Allo stesso modo per box2:

[root@box2 ~]# ping -c 3 10.0.0.10
PING 10.0.0.10 (10.0.0.10) 56(84) bytes of data.
64 bytes from 10.0.0.10: icmp_seq=1 ttl=64 time=0.375 ms
64 bytes from 10.0.0.10: icmp_seq=2 ttl=64 time=0.478 ms
64 bytes from 10.0.0.10: icmp_seq=3 ttl=64 time=0.325 ms

--- 10.0.0.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.325/0.392/0.478/0.067 ms


[root@box2 ~]# ip route get 10.0.0.10
10.0.0.10 dev enp0s8  src 10.0.0.11
    cache


[root@box2 ~]# ip route list
default via 10.0.2.2 dev enp0s3  proto static  metric 100
10.0.0.0/24 dev enp0s8  proto kernel  scope link  src 10.0.0.11  metric 100
10.0.2.0/24 dev enp0s3  proto kernel  scope link  src 10.0.2.15  metric 100

Dato che routingvm può comunicare liberamente sia con box1 che con box2, significa che routingvm può essere utilizzato per facilitare il traffico di rete tra box1 e box2. Per fare ciò, è necessario prima configurare le impostazioni di rete box1 in modo che il traffico destinato alla rete 10.0.0.0/24 debba essere inviato tramite l’interfaccia enp0s8 di box1 a routingvm. Ciò viene eseguito eseguendo il seguente comando per aggiungere una nuova regola alla tabella di routing di box1:

[root@box1 ~]# ip route add 10.0.0.0/24 via 192.168.10.100 dev enp0s8

Nota: puoi annullare il comando precedente eseguendolo di nuovo, ma con ‘add’ sostituito con ‘del’

Questo finisce per aggiungere la seguente voce alla tabella di routing:

[root@box1 ~]# ip route list
default via 10.0.2.2 dev enp0s3  proto static  metric 100
10.0.0.0/24 via 192.168.10.100 dev enp0s8
10.0.2.0/24 dev enp0s3  proto kernel  scope link  src 10.0.2.15  metric 100
192.168.10.0/24 dev enp0s8  proto kernel  scope link  src 192.168.10.101  metric 100

In pratica, questa linea dice che tutto il traffico destinato a un indirizzo IP compreso nell’intervallo 10.0.0.1-10.0.0.254 deve essere inviato tramite enp0s8 all’iPo 192.168.10.100. Tuttavia, questo non sarà persistente, ci sono 3 modi per renderlo persistente (tutto ciò richiede il riavvio del demone di rete), il primo approccio è creare questo file

root@box1 ~]# cat /etc/sysconfig/network-scripts/route-enp0s8
10.0.0.0/24 via 192.168.10.100

Il secondo approccio è ottenere il file route-enp0s8 usando il comando nmcli:

$ nmcli connection modify System\ enp0s8 +ipv4.routes "10.0.0.0/24 192.168.10.100""

Il terzo approccio consiste nel creare il seguente file con il contenuto:

$ cat /etc/sysconfig/static-routes
any net 10.0.0.0 netmask 255.255.255.0 gw 192.168.10.100 dev enp0s8

/etc/sysconfig/static-routes è specificamente menzionato nello script di init di rete: /etc/init.d/network. Dopo aver preso uno di questi 3 approcci, è necessario riavviare il demone di rete per caricarlo in:

$ systemctl restart network

Puoi vedere la nuova regola eseguendo:

[root@box1 ~]# ip route list
default via 10.0.2.2 dev enp0s3  proto static  metric 100
10.0.0.0/24 via 192.168.10.100 dev enp0s8
10.0.2.0/24 dev enp0s3  proto kernel  scope link  src 10.0.2.15  metric 100
192.168.10.0/24 dev enp0s8  proto kernel  scope link  src 192.168.10.101  metric 100

A questo punto, ora abbiamo configurato box1 per inviare il traffico destinato a box2 a routingvm. Ma se corriamo:

[root@box1 ~]# traceroute 10.0.0.11
traceroute to 10.0.0.11 (10.0.0.11), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *

Questo avviene perché non abbiamo configurato routingvm a comportarsi come un router. Per fare ciò dobbiamo prima configurare le impostazioni del kernel di routingvm per consentire l’inoltro dei pacchetti ip. Per prima cosa controlliamo se è attualmente abilitato:

[root@routingvm ~]# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

In questo caso, non lo è, quindi lo abilitiamo:In questo caso, non lo è, quindi lo abilitiamo:

[root@routingvm ~]# echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
[root@routingvm ~]# sysctl --system   # this is to reload config files.

Quindi controlla per confermare che ha funzionato:

[root@routingvm ~]# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Ora, se eseguiamo di nuovo traceroute su box1, otteniamo:

[root@box1 ~]# traceroute 10.0.0.11
traceroute to 10.0.0.11 (10.0.0.11), 30 hops max, 60 byte packets
 1  192.168.10.100 (192.168.10.100)  0.552 ms  0.506 ms  0.492 ms^C

Questo indica che la comunicazione tra box1 e routingvm ora funziona. Tuttavia routingvm non è ancora configurato per inoltrare le richieste a box2, quindi il ping non funziona ancora:

[root@box1 ~]# ping -c3 10.0.0.11
PING 10.0.0.11 (10.0.0.11) 56(84) bytes of data.

--- 10.0.0.11 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms

Successivamente avvieremo il servizio firewalld. Abbiamo bisogno di usare firewalld perché ha una caratteristica fondamentale per il reinstradamento del traffico, chiamato ‘masquerade’:

[root@routingvm ~]# systemctl start firewalld
[root@routingvm ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: active (running) since Sat 2017-08-05 23:19:40 UTC; 2s ago
     Docs: man:firewalld(1)
 Main PID: 5925 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─5925 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Aug 05 23:19:40 routingvm.local systemd[1]: Starting firewalld - dynamic firewall daemon...
Aug 05 23:19:40 routingvm.local systemd[1]: Started firewalld - dynamic firewall daemon.

Finalmente abilitiamo la funzione masquerade, ricarichiamo le config firewalld e confermiamo che è abilitato:

[root@routingvm ~]# firewall-cmd --permanent --add-masquerade
success
[root@routingvm ~]# firewall-cmd --reload
success
[root@routingvm ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp0s3 enp0s8 enp0s9
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: yes
  forward-ports:
  sourceports:
  icmp-blocks:
  rich rules:

L’abilitazione di masquerade significa fondamentalmente che il firewall inoltra attivamente qualsiasi tipo di traffico da un punto di entrata verso un punto altro punto. Questo è ora tutto ciò che è necessario per la configurazione di routingvm. Ora torniamo a box1 e facciamo un altro test di ping:

[root@box1 ~]# ping -c 3 10.0.0.11
PING 10.0.0.11 (10.0.0.11) 56(84) bytes of data.
64 bytes from 10.0.0.11: icmp_seq=1 ttl=63 time=0.543 ms
64 bytes from 10.0.0.11: icmp_seq=2 ttl=63 time=0.821 ms
64 bytes from 10.0.0.11: icmp_seq=3 ttl=63 time=0.664 ms

--- 10.0.0.11 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.543/0.676/0.821/0.113 ms

Un altro test che possiamo fare è provare ad effettuare una connessione ssh da box1 a box2:

[root@box1 ~]# ssh 10.0.0.11
The authenticity of host '10.0.0.11 (10.0.0.11)' can't be established.
ECDSA key fingerprint is 25:f0:05:ec:12:ce:9f:33:ff:38:58:31:ad:e2:4d:bd.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.11' (ECDSA) to the list of known hosts.
root@10.0.0.11's password:
Last login: Sat Aug  5 15:56:05 2017
[root@box2 ~]#

Infine, è possibile vedere il percorso del pacchetto icmp usando il comando traceroute:

[root@box1 ~]# traceroute 10.0.0.11
traceroute to 10.0.0.11 (10.0.0.11), 30 hops max, 60 byte packets
 1  192.168.10.100 (192.168.10.100)  0.306 ms  0.235 ms  0.146 ms
 2  10.0.0.11 (10.0.0.11)  0.853 ms  0.810 ms  0.728 ms

Link utili:

Rendere persistenti le rotte statiche
Configurare il routing statico per le sottoreti
Introduzione al routing con Linux

Configurazione e Troubleshooting di indirizzi IPv6

In passato molti amministratori di sistema hanno semplicemente fatto ricorso alla disabilitazione di IPv6 piuttosto che configurarlo correttamente, continuando a fare affidamento sul vecchio IPv4 che ha funzionato bene per un tempo molto lungo. Poiché lo spazio degli indirizzi IPv4 si è esaurito, gli amministratori stanno iniziando lentamente a utilizzare IPv6 per necessità.

Qui tratteremo come configurare l’indirizzamento IPv6 in Linux e forniremo alcuni suggerimenti e consigli di base per la risoluzione dei problemi relativi alla rete IPv6.

Configurazione degli indirizzi IPv6

Gli indirizzi IPv6 possono essere configurati in alcuni modi aggiuntivi rispetto a IPv4, alcuni dei quali sono elencati di seguito.

Configurazione manuale: Questo è abbastanza simile al modo in cui IPv4 viene configurato manualmente, in sostanza modifichiamo manualmente un file di interfaccia nel formato /etc/sysconfig/network-scripts/ifcfg-<interface>.
DHCPv6: Dynamic Host Protocol versione 6 è simile a DHCP per IPv4 in quanto configurerà automaticamente la nostra interfaccia.
Autoconfigurazione dell’indirizzo stateless (SLAAC): funziona in modo simile a DHCP, tuttavia funziona ricevendo i messaggi pubblicitari del router da un router IPv6 locale sulla rete.

Qui ci concentreremo principalmente sulla configurazione di rete IPv6 manuale.

Configurazione manuale IPv6

Per prima cosa date un’occhiata alla directory /etc/sysconfig/network-scripts/per vedere se esiste già una configurazione IPv6 esistente per la particolare interfaccia in questione. Il nome del file sarà elencato come ifcfg-<interfaccia>, è possibile confermare i nomi dell’interfaccia eseguendo ‘ip a’ o deprecato ‘ifconfig‘. I nomi tipici possono includere eth0 o il formato più recente ‘eno *’ come eno16777736. Questo file può contenere sia la configurazione IPv4 che IPv6 per la stessa interfaccia.

Di seguito è riportata la configurazione del file CentOS 7 /etc/sysconfig/network-scripts/ifcfg-eno16777736, notare le impostazioni che iniziano con “IPV6”.

IPV6INIT = yes – È necessario quando si configura IPv6 sull’interfaccia.
IPV6ADDR = <indirizzo ipv6>: specifica un indirizzo IPv6 statico primario.
IPV6_DEFAULTGW = <indirizzo ipv6>% eno16777736 – Aggiunge una route predefinita attraverso l’interfaccia specificata.

Nota che se modifichi manualmente questi file, dovrai eseguire “nmcli con reload” per raccogliere le modifiche. In alternativa, possiamo apportare modifiche con il comando nmcli, che per ammissione richiede un po ‘di tempo per abituarsi, ma è piuttosto potente e il suo completamento automatico della scheda aiuta molto.

nmcli con mod eno16777736 ipv6.addresses 'fe80::20c:29ff:fe27:f2b6/64'
nmcli con mod eno16777736 ipv6.method manual

Il primo comando imposta l’indirizzo IPv6, mentre il secondo assicura che questo sia un indirizzo statico e non venga perso da DHCP o SLAAC.

Per ulteriori informazioni, tenere a mente la pagina man ‘nmcli-examples‘, in quanto vi sono numerosi esempi diversi documentati qui che è possibile utilizzare.

man nmcli-examples

Configurazione IPv6 automatica

La configurazione automatica degli indirizzi IPv6 può avvenire con DHCPv6 o SLAAC. Di seguito è riportata una configurazione predefinita di CentOS 7 con IPV6_AUTOCONF abilitato, che configura le impostazioni di rete utilizzando gli annunci del router SLAAC.

[root@centos7 network-scripts]# cat ifcfg-eno16777736
HWADDR=00:0C:29:AB:12:34
TYPE=Ethernet
BOOTPROTO=dhcp
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME=eno16777736
UUID=0dbee9e5-2e7e-4c88-822b-869cfc9e2d54
ONBOOT=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes

In alternativa, è possibile impostare IPV6_AUTOCONF su no e definire DHCPV6C = yes per utilizzare DHCPv6 anziché SLAAC. Quando si utilizza SLAAC o DHCPv6, gli elementi di configurazione manuale come IPV6ADDR e IPV6_DEFAULTGW possono essere rimossi poiché verranno configurati automaticamente.

Per ulteriori informazioni su queste variabili è possibile consultare la documentazione in /usr/share/doc/initscripts-*/sysconfig.txt

Applicazione delle modifiche di rete

Dopo aver apportato eventuali modifiche ai file in /etc/sysconfig/network-scripts/ la rete deve essere riavviata affinché abbiano effetto.

systemctl restart network

È anche possibile eseguire un riavvio del sistema, tuttavia ciò richiederà più tempo, ma porterà l’interfaccia con la nuova configurazione.
Risoluzione dei problemi di IPv6 di base

Ecco alcuni strumenti di base che è possibile utilizzare per eseguire la risoluzione dei problemi IPv6 di base, funzionano in modo abbastanza simile alle loro controparti IPv4.

Ping IPv6

Il comando ping6 funziona allo stesso modo del normale comando ping, tranne per il fatto che ping6 funziona con indirizzi IPv6. Questo può essere usato per inviare il traffico ICMP ad un indirizzo IPv6 e verificare la risposta, l’esempio seguente esegue il ping dell’indirizzo localhost IPv6.

[root@centos7 ~]# ping6 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.039 ms
...

Possiamo anche eseguire il ping di un’interfaccia specificata, il comando seguente esegue il ping di tutto ciò che è collegato a eno1677736.

[root@ ~]# ping6 ff02::1%eno16777736
PING ff02::1%eno16777736(ff02::1) 56 data bytes
64 bytes from fe80::204:edff:feef:a770: icmp_seq=1 ttl=64 time=2.32 ms
64 bytes from fe80::204:edff:feef:a770: icmp_seq=2 ttl=64 time=0.640 ms

IPv6 Route

Il comando ‘ip -6 route show‘ può essere utilizzato per visualizzare il routing IPv6.

[root@centos7 ~]# ip -6 route show
unreachable ::/96 dev lo  metric 1024  error -101
unreachable ::ffff:0.0.0.0/96 dev lo  metric 1024  error -101
unreachable 2002:a00::/24 dev lo  metric 1024  error -101
unreachable 2002:7f00::/24 dev lo  metric 1024  error -101
unreachable 2002:a9fe::/32 dev lo  metric 1024  error -101
unreachable 2002:ac10::/28 dev lo  metric 1024  error -101
unreachable 2002:c0a8::/32 dev lo  metric 1024  error -101
unreachable 2002:e000::/19 dev lo  metric 1024  error -101
unreachable 3ffe:ffff::/32 dev lo  metric 1024  error -101
fe80::/64 dev eth0  proto kernel  metric 256

IPv6 Traceroute

Il comando traceroute6 può essere utilizzato per mostrare tutti gli hop nel percorso verso la destinazione specificata allo stesso modo del comando traceroute.

[root@centos7 ~]# traceroute6 ipv6.google.com
traceroute to ipv6.google.com (2607:f8b0:4006:80f::200e), 30 hops max, 80 byte packets
connect: Network is unreachable

Il comando tracepath6 funziona in modo simile.

Visualizza le informazioni sull’indirizzo IPv6 corrente

È possibile visualizzare la configurazione IPv6 corrente eseguendo il comando ‘ip a‘ che è l’abbreviazione di ‘ip address show‘. Questo mostrerà le interfacce IPv6 come “inet6” seguito dal loro indirizzo IP.

Visualizza connessioni di rete IPv6

Per impostazione predefinita, il comando ‘netstat’ mostra sia IPv4 che IPv6, tuttavia con l’opzione -6 possiamo selezionare di visualizzare solo le porte che il server sta ascoltando con i suoi indirizzi IPv6 e tutte le connessioni.

[root@centos7 ~]# netstat -antup6
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp6       0      0 :::111                  :::*                    LISTEN      787/rpcbind
tcp6       0      0 :::22                   :::*                    LISTEN      1661/sshd
tcp6       0      0 ::1:631                 :::*                    LISTEN      2476/cupsd
tcp6       0      0 ::1:25                  :::*                    LISTEN      2066/master
udp6       0      0 :::111                  :::*                                787/rpcbind
udp6       0      0 :::123                  :::*                                781/chronyd
udp6       0      0 ::1:323                 :::*                                781/chronyd
udp6       0      0 :::39836                :::*                                1439/dhclient
udp6       0      0 :::942                  :::*                                787/rpcbind

Conclusione

La configurazione degli indirizzi IPv6 non è molto diversa dalla configurazione degli indirizzi IPv4, la differenza principale è semplicemente la struttura degli indirizzi IP è diversa. Una volta individuate le basi di IPv6, è possibile configurare facilmente il networking IPv6. La maggior parte degli strumenti di risoluzione dei problemi sono anche abbastanza simili, è comunque possibile visualizzare le informazioni sull’indirizzo IP corrente, le tabelle di routing ed eseguire ping e traceroute in modo molto simile.

RHEL7: Network Bonding

Presentazione

Esistono diversi modi per configurare il collegamento di rete (bonding)in RHEL 7:

utilizzando il comando nmtui un’ interfaccia utente a testo,
utilizzando il comando nmcli un ‘interfaccia a riga di comando,
usando l’interfaccia grafica,
attraverso modifiche dirette nei file di configurazione di rete.

Per il resto di questo tutorial, è l’opzione nmcli che è stata scelta perché è il metodo più veloce e probabilmente meno incline agli errori.

Prerequisiti

Per mettere in pratica questo tutorial, hai bisogno di due VM e accedi alla loro rispettiva console.
Ogni VM è stata installata con una distribuzione di base (la distribuzione minima dovrebbe funzionare ma non è stata testata). Ogni VM ha due interfacce di rete denominate eth0 e eth1.

Se è stata configurata una precedente configurazione di rete, rimuoverla su entrambe le macchine virtuali:

# nmcli con show
NAME                UUID                                  TYPE            DEVICE
Wired connection 1  f32cfcb7-3567-4313-9cf3-bdd87010c7a2  802-3-ethernet  eth1  
System eth0         257e9416-b420-4218-b1eb-f14302f20941  802-3-ethernet  eth0  
# nmcli con del f32cfcb7-3567-4313-9cf3-bdd87010c7a2
# nmcli con del 257e9416-b420-4218-b1eb-f14302f20941

Configurazione di bonding

Eseguire i seguenti passaggi sulla console di entrambe le macchine virtuali.

Creare l’interfaccia:

# nmcli con add type bond con-name mybond0 ifname bond0 mode active-backup
[88934.922710] bonding: bond0: Setting MII monitoring interval to 100.
[88934.923313] bonding: bond0: setting mode to active-backup (1).
[88934.923845] bonding: bond0: Setting ARP monitoring interval to 0.
[88934.924382] bonding: bond0: setting arp_validate to none (0).
[88934.924891] bonding: bond0: Setting primary slave to None.
[88934.925375] bonding: bond0: setting primary_reselect to always (0).
[88934.925920] bonding: bond0: Setting fail_over_mac to none (0).
[88934.926409] bonding: bond0: Setting use_carrier to 1.
[88934.926819] bonding: bond0: Setting ad_select to stable (0).
[88934.927286] bonding: bond0: setting xmit hash policy to layer2 (0).
[88934.927786] bonding: bond0: Setting resend_igmp to 1.
Connection 'mybond0' (304e66f0-c31c-4b57-92e8-734e2b53bdac) successfully added.

Nota: se non si specifica con-name mybond0, l’interfaccia di bonding sarà denominata bond-bond0.

Aggiungi una configurazione IPv4:
In RHEL 7.0:

# nmcli con mod mybond0 ipv4.addresses "192.168.1.10/24 192.168.1.1"
# nmcli con mod mybond0 ipv4.method manual

Da RHEL 7.1 a:

# nmcli con mod mybond0 ipv4.addresses 192.168.1.10/24
# nmcli con mod mybond0 ipv4.gateway 192.168.1.1
# nmcli con mod mybond0 ipv4.method manual

Nota: se non si specifica alcuna configurazione IP, entrambe le VM otterranno il loro indirizzo IP e gateway tramite DHCP per impostazione predefinita.

Aggiungi l’interfaccia eth0 all’interfaccia di bonding:

# nmcli con add type bond-slave con-name bond0-eth0 ifname eth0 master bond0
[89010.860765] bonding: bond0: making interface eth0 the new active one.
[89010.861336] bonding: bond0: enslaving eth0 as an active interface with an up link.
Connection 'bond0-eth0' (35081742-5962-4edf-8465-6843603d7777) successfully added.

Nota: se non si specifica con-name bond0-eth0, l’interfaccia slave bonding sarà denominata bond-slave-eth0.

Aggiungi l’interfaccia eth1 all’interfaccia di bonding:

# nmcli con add type bond-slave con-name bond0-eth1 ifname eth1 master bond0
[89146.655598] bonding: bond0: enslaving eth1 as a backup interface with an up link.
Connection 'bond0-eth1' (037019f3-7115-46a4-a6f9-8fba7bf2adcd) successfully added.

Nota: se non si specifica con-name bond0-eth1, l’interfaccia slave bonding sarà denominata bond-slave-eth1.

Attivare l’interfaccia di bonding:

# nmcli con up mybond0
[89222.099283] bonding: bond0: releasing backup interface eth1
[89222.102432] bonding: bond0: releasing active interface eth0
[89222.126862] bonding: bond0: Setting MII monitoring interval to 100.
[89222.127410] bonding: bond0: setting mode to active-backup (1).
[89222.127950] bonding: bond0: Setting ARP monitoring interval to 0.
[89222.128494] bonding: bond0: setting arp_validate to none (0).
[89222.128991] bonding: bond0: Setting primary slave to None.
[89222.129460] bonding: bond0: setting primary_reselect to always (0).
[89222.129964] bonding: bond0: Setting fail_over_mac to none (0).
[89222.130443] bonding: bond0: Setting use_carrier to 1.
[89222.130847] bonding: bond0: Setting ad_select to stable (0).
[89222.131307] bonding: bond0: setting xmit hash policy to layer2 (0).
[89222.131801] bonding: bond0: Setting resend_igmp to 1.
[89222.132219] IPv6: ADDRCONF(NETDEV_UP): bond0: link is not ready
[89222.251450] bonding: bond0: making interface eth1 the new active one.
[89222.252022] bonding: bond0: first active interface up!
[89222.252462] bonding: bond0: enslaving eth1 as an active interface with an up link.
[89222.253641] IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
[89222.305553] bonding: bond0: enslaving eth0 as a backup interface with an up link.
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/70)

Controllare la configurazione:

# nmcli con show
NAME        UUID                                  TYPE            DEVICE
mybond0     304e66f0-c31c-4b57-92e8-734e2b53bdac  bond            bond0
bond0-eth1  037019f3-7115-46a4-a6f9-8fba7bf2adcd  802-3-ethernet  eth1
bond0-eth0  35081742-5962-4edf-8465-6843603d7777  802-3-ethernet  eth0

Fonte: RHEL 7 Guida alla rete.

RHEL7: Network Teaming

Presentazione

Esistono diversi modi per configurare il teaming di rete in RHEL 7:

Per il resto di questo tutorial, è l’opzione nmcli è stata scelta perché è il metodo più veloce e probabilmente meno incline agli errori.

Prerequisiti

Installa il pacchetto Teamd:

# yum install -y teamd

Se è stata configurata una precedente configurazione di rete, rimuoverla su entrambe le macchine virtuali:

# nmcli con show
NAME                UUID                                  TYPE            DEVICE
Wired connection 1  f32cfcb7-3567-4313-9cf3-bdd87010c7a2  802-3-ethernet  eth1  
System eth0         257e9416-b420-4218-b1eb-f14302f20941  802-3-ethernet  eth0  
# nmcli con del f32cfcb7-3567-4313-9cf3-bdd87010c7a2
# nmcli con del 257e9416-b420-4218-b1eb-f14302f20941

Configurazione teaming

Eseguire i seguenti passaggi sulla console di entrambe le macchine virtuali.

Creare l’interfaccia di teaming:

# nmcli con add type team con-name myteam0 ifname team0 config '{ "runner": {"name": "loadbalance"}}'
 team0 config '{ "runner": {"name": "loadbalance"}}'
[10655.288431] IPv6: ADDRCONF(NETDEV_UP): team0: link is not ready
[10655.306955] team0: Mode changed to "loadbalance"
Connection 'myteam0' (ab0a5f7b-2547-4d4f-8fc8-834030839fc1) successfully added.

Nota 1: Se non si specifica con-name myteam0, l’interfaccia di teaming verrà denominata team-team0.
Nota 2: esempi di configurazione sono disponibili in /usr/share/doc/teamd – */example_configs. Puoi anche ottenere alcuni esempi attraverso man teamd.conf.

Ora il file /etc/sysconfig/network-scripts/ifcfg-myteam0 contiene le seguenti linee principali:

DEVICE=team0
TEAM_CONFIG="{ \"runner\": {\"name\": \"loadbalance\"}}"
DEVICETYPE=Team
NAME=myteam0
ONBOOT=yes

Aggiungi una configurazione IPv4:
In RHEL 7.0:

# nmcli con mod myteam0 ipv4.addresses "192.168.1.10/24 192.168.1.1"
# nmcli con mod myteam0 ipv4.method manual

Da RHEL 7.1 a:

# nmcli con mod myteam0 ipv4.addresses 192.168.1.10/24
# nmcli con mod myteam0 ipv4.gateway 192.168.1.1
# nmcli con mod myteam0 ipv4.method manual

Nota: se non si specifica alcuna configurazione IP, entrambe le VM otterranno il loro indirizzo IP e gateway tramite DHCP per impostazione predefinita.

Aggiungi l’interfaccia eth0 all’interfaccia di teaming:

# nmcli con add type team-slave con-name team0-slave0 ifname eth0 master team0
[10707.777803] team0: Port device eth0 added
[10707.779146] IPv6: ADDRCONF(NETDEV_CHANGE): team0: link becomes ready
Connection 'team0-slave0' (a9a5b612-aad6-48b0-a097-88db35c898d3) successfully added.

Nota 1: Se non si specifica con-name team0-slave0, l’interfaccia slave di teaming verrà denominata team-slave-eth0.
Nota2: il file /etc/sysconfig/network-scripts/ifcfg-team0-slave0 è stato creato con le seguenti linee principali:

NAME=team0-slave0
DEVICE=eth0
ONBOOT=yes
TEAM_MASTER=team0
DEVICETYPE=TeamPort

Aggiungi l’interfaccia eth1 all’interfaccia di teaming:

# nmcli con add type team-slave con-name team0-slave1 ifname eth1 master team0
[10750.419419] team0: Port device eth1 added
Connection 'team0-slave1' (e468dce3-a032-4088-8173-e7bee1bd4ad5) successfully added.

Nota 1: se non si specifica con-name team0-slave1, l’interfaccia slave di teming verrà denominata team-slave-eth1.
Nota2: il file /etc/sysconfig/network-scripts/ifcfg-team0-slave1 è stato creato con le seguenti linee principali:

NAME=team0-slave1
DEVICE=eth1
ONBOOT=yes
TEAM_MASTER=team0
DEVICETYPE=TeamPort

Attivazione interfaccia:

# nmcli con up myteam0
[10818.800169] team0: Port device eth1 removed
[10818.803399] team0: Port device eth0 removed
[10818.939884] team0: Port device eth1 added
[10818.941069] IPv6: ADDRCONF(NETDEV_CHANGE): team0: link becomes ready
[10818.971887] team0: Port device eth0 added
[10819.932168] IPv6: team0: IPv6 duplicate address fe80::5054:ff:fe3f:860a detected!
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/32)

Controllare la configurazione:

# nmcli con show
NAME          UUID                                  TYPE            DEVICE
team0-slave0  a9a5b612-aad6-48b0-a097-88db35c898d3  802-3-ethernet  eth0
myteam0       ab0a5f7b-2547-4d4f-8fc8-834030839fc1  team            team0
team0-slave1  e468dce3-a032-4088-8173-e7bee1bd4ad5  802-3-ethernet  eth1

È inoltre possibile utilizzare il comando teamdctl per verificare lo stato di configurazione:

# teamdctl team0 state
setup:
  runner: loadbalance
ports:
  eth0
    link watches:
      link summary: up
      instance[link_watch_0]:
        name: ethtool
        link: up
  eth1
    link watches:
      link summary: up
      instance[link_watch_0]:
        name: ethtool
        link: up

O per scaricare la configurazione:

# teamdctl team0 config dump
{
"device": "team0",
"ports": {
"eth0": {
"link_watch": {
"name": "ethtool"
}
},
"eth1": {
"link_watch": {
"name": "ethtool"
}
}
},
"runner": {
"name": "loadbalance",
"tx_hash": [
"eth",
"ipv4",
"ipv6"
]
}
}

Puoi anche ottenere lo stato delle porte con il comando teamnl:

# teamnl team0 ports
 2: eth0: up 0Mbit HD
 3: eth1: up 0Mbit HD

Inoltre, è possibile modificare direttamente il contenuto dei file nella directory /etc/sysconfig/network-scripts, ma in seguito è necessario applicare il seguente comando:

# nmcli con reload

Fonte: RHEL 7 Guida alla rete e pagina man di nmcli-examples.

Suggerimento per l’esame

Se non ricordi tutti i dettagli il giorno dell’esame, ottieni le informazioni nelle pagine man di nmcli-examples e teamd.conf o in /usr/share/doc/teamd – */example_ifcfgs e /usr/share/directory doc/teamd – */example_ifcfgs.