Instradamento del traffico di rete e configurazione di rotte statiche

By | novembre 25, 2018

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

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.