Pour que veth fonctionne, une extrémité du tunnel doit être pontée avec une autre interface. Puisque vous voulez garder tout cela virtuel, vous pouvez relier l'extrémité vm1 du tunnel (vm2 est l'autre extrémité du tunnel) avec une interface virtuelle de type tap, dans un pont appelé brm. Vous donnez maintenant les adresses IP à brm et à vm2 (10.0.0.1 et 10.0.0.2, respectivement), activez le transfert IPv4 au moyen de
echo 1 > /proc/sys/net/ipv4/ip_forward
mettez toutes les interfaces en place et ajoutez une route indiquant au noyau comment atteindre les adresses IP 10.0.0.0/24. C'est tout.
Si vous souhaitez créer plus de paires, répétez les étapes ci-dessous avec différents sous-réseaux, par exemple 10.0.1.0/24, 10.0.2.0/24, etc. Étant donné que vous avez activé le transfert IPv4 et ajouté des itinéraires appropriés à la table de routage du noyau, ils pourront se parler immédiatement.
Rappelez-vous également que la plupart des commandes que vous utilisez (brctl, ifconfig, ...) sont obsolètes: la suite iproute2 a des commandes pour faire tout cela, voir ci-dessous mon utilisation de la commande ip .
Il s'agit d'une séquence correcte de commandes pour l'utilisation des interfaces de type veth :
créez d'abord toutes les interfaces requises,
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
Notez que nous n'avons pas fait apparaître brm et vm2 car nous devons leur attribuer des adresses IP, mais nous avons fait apparaître tapm et vm1, ce qui est nécessaire pour les inclure dans le pont brm. Asservissez maintenant les interfaces tapm et vm1 au pont brm,
ip link set tapm master brm
ip link set vm1 master brm
donner maintenant des adresses au pont et à l'interface veth restante vm2,
ip addr add 10.0.0.1/24 dev brm
ip addr add 10.0.0.2/24 dev vm2
maintenant amenez vm2 et brm,
ip link set brm up
ip link set vm2 up
Il n'est pas nécessaire d'ajouter explicitement la route au sous-réseau 10.0.0.0/24, il est généré automatiquement, vous pouvez vérifier avec ip route show . Il en résulte
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
Vous pouvez également le faire à l'envers, c'est- à- dire de vm2 vers 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'application la plus utile des cartes réseau du type veth est un espace de noms réseau , qui est utilisé dans les conteneurs Linux (LXC). Vous en lancez un appelé nnsm comme suit
ip netns add nnsm
puis on y transfère vm2,
ip link set vm2 netns nnsm
nous dotons le nouvel espace de noms du réseau d'une interface lo (absolument nécessaire),
ip netns exec nnsm ip link set dev lo up
nous autorisons NATting dans la machine principale,
iptables -t nat -A POSTROUTING -o brm -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
(si vous êtes connecté à Internet via eth0 , sinon changez en conséquence), démarrez un shell dans le nouvel espace de noms du réseau,
ip netns exec nnsm xterm &
et maintenant, si vous commencez à taper le nouveau xterm, vous constaterez que vous êtes dans une machine virtuelle distincte avec l'adresse IP 10.0.0.2, mais vous pouvez accéder à Internet. L'avantage de cela est que le nouvel espace de noms réseau a sa propre pile, ce qui signifie, par exemple, que vous pouvez y démarrer un VPN alors que le reste de votre PC n'est pas sur le VPN. C'est sur quoi s'appuient les LXC.
MODIFIER:
J'ai fait une erreur, apporter l'interface vm2 la fait tomber et efface son adresse. Vous devez donc ajouter ces commandes, à partir de 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
et maintenant vous pouvez naviguer depuis xterm.
Les ipcommandes peuvent également être effectuées avant le xterm avec
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-il en place?