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