Perché veth funzioni, un'estremità del tunnel deve essere collegata con un'altra interfaccia. Dato che vuoi mantenere tutto ciò virtuale, puoi collegare l'estremità vm1 del tunnel (vm2 è l'altra estremità del tunnel) con un'interfaccia virtuale di tipo tap, in un ponte chiamato brm. Ora date gli indirizzi IP a brm e a vm2 (10.0.0.1 e 10.0.0.2, rispettivamente), abilitate l'inoltro IPv4 tramite
echo 1 > /proc/sys/net/ipv4/ip_forward
porta tutte le interfacce e aggiungi una route che indica al kernel come raggiungere gli indirizzi IP 10.0.0.0/24. È tutto.
Se si desidera creare più coppie, ripetere i passaggi seguenti con diverse sottoreti, ad esempio 10.0.1.0/24, 10.0.2.0/24 e così via. Dato che hai abilitato l'inoltro IPv4 e aggiunto percorsi appropriati alla tabella di routing del kernel, saranno in grado di dialogare immediatamente.
Inoltre, ricorda che la maggior parte dei comandi che stai utilizzando (brctl, ifconfig, ...) sono obsoleti: la suite iproute2 ha i comandi per fare tutto questo, vedi sotto il mio uso del comando ip .
Questa è una sequenza corretta di comandi per l'uso di interfacce di tipo veth :
creare innanzitutto tutte le interfacce richieste,
ip link add dev vm1 type veth peer name vm2
ip link set dev vm1 up
ip tuntap add tapm mode tap
ip link set dev tapm up
ip link add brm type bridge
Notare che non abbiamo visualizzato brm e vm2 perché dobbiamo assegnare loro gli indirizzi IP, ma abbiamo fatto apparire tapm e vm1, che è necessario per includerli nel bridge brm. Ora asservisci le interfacce tapm e vm1 al bridge brm,
ip link set tapm master brm
ip link set vm1 master brm
ora fornisci gli indirizzi al bridge e all'interfaccia veth rimanente vm2,
ip addr add 10.0.0.1/24 dev brm
ip addr add 10.0.0.2/24 dev vm2
ora porta vm2 e brm up,
ip link set brm up
ip link set vm2 up
Non è necessario aggiungere esplicitamente il percorso alla sottorete 10.0.0.0/24, viene generato automaticamente, è possibile verificare con ip route show . Questo risulta in
ping -c1 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.035 m
--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.035/0.035/0.035/0.000 ms
Puoi anche farlo all'indietro, cioè da vm2 a brm:
ping -I 10.0.0.2 -c1 10.0.0.1
PING 10.0.0.1 (10.0.0.1) from 10.0.0.2 : 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.045 ms
--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.045/0.045/0.045/0.000 ms
L'applicazione più utile delle schede di rete di tipo veth è uno spazio dei nomi di rete , che viene utilizzato nei contenitori Linux (LXC). Ne inizi uno chiamato nnsm come segue
ip netns add nnsm
quindi trasferiamo vm2 ad esso,
ip link set vm2 netns nnsm
dotiamo il nuovo spazio dei nomi di rete con un'interfaccia lo (assolutamente necessaria),
ip netns exec nnsm ip link set dev lo up
consentiamo NATting nella macchina principale,
iptables -t nat -A POSTROUTING -o brm -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
(se sei connesso a Internet via eth0 , altrimenti cambia di conseguenza), avvia una shell nel nuovo spazio dei nomi di rete,
ip netns exec nnsm xterm &
e ora, se inizi a digitare il nuovo xterm, scoprirai di trovarti in una macchina virtuale separata con indirizzo IP 10.0.0.2, ma puoi raggiungere Internet. Il vantaggio di questo è che il nuovo spazio dei nomi di rete ha il suo stack, il che significa, ad esempio, che puoi avviare una VPN mentre il resto del tuo PC non è sulla VPN. Questo è il contrappunto su cui si basano gli LXC.
MODIFICARE:
Ho fatto un errore, portando l'interfaccia vm2 lo abbassa e cancella il suo indirizzo. Quindi è necessario aggiungere questi comandi, all'interno di xterm:
ip addr add 10.0.0.2/24 dev vm2
ip link set dev vm2 up
ip route add default via 10.0.0.1
echo "nameserver 8.8.8.8" >> /etc/resolv.conf
echo "nameserver 8.8.4.4" >> /etc/resolv.conf
e ora puoi navigare all'interno di xterm.
I ip
comandi possono anche essere eseguiti prima di xterm con
ip -netns nnsm addr add 10.0.0.2/24 dev vm2
ip -netns nnsm link set dev vm2 up
ip -netns nnsm route add default via 10.0.0.1
br0
è alzato?