Alimentez tout le trafic via OpenVPN pour un espace de noms de réseau spécifique uniquement

Vous pouvez démarrer le lien OpenVPN dans un espace de noms, puis exécuter chaque commande que vous souhaitez utiliser ce lien OpenVPN dans l'espace de noms. Les détails sur la façon de le faire sont présentés dans Exécution d'un tunnel OpenVPN dans un espace de noms réseau, par Sebastian Thorarensen.

Je l'ai essayé et ça marche. L'idée est de fournir un script personnalisé pour effectuer les phases de démarrage et de routage de la connexion OpenVPN dans un espace de noms spécifique au lieu de l'espace global. Voici une réponse basée sur la source ci-dessus, mais modifiée pour ajouter Google DNS à resolv.conf .

Créez d'abord un --up script pour OpenVPN. Ce script créera l'interface du tunnel VPN dans un espace de noms de réseau appelé vpn , au lieu de l'espace de noms par défaut.

$ cat > netns-up << 'EOF'
#!/bin/sh
case $script_type in
        up)
                ip netns add vpn
                ip netns exec vpn ip link set dev lo up
                mkdir -p /etc/netns/vpn
                echo "nameserver 8.8.8.8" > /etc/netns/vpn/resolv.conf
                ip link set dev "$1" up netns vpn mtu "$2"
                ip netns exec vpn ip addr add dev "$1" \
                        "$4/${ifconfig_netmask:-30}" \
                        ${ifconfig_broadcast:+broadcast "$ifconfig_broadcast"}
                test -n "$ifconfig_ipv6_local" && \
                        ip netns exec vpn ip addr add dev "$1" \
                                "$ifconfig_ipv6_local"/112
                ;;
        route-up)
                ip netns exec vpn ip route add default via "$route_vpn_gateway"
                test -n "$ifconfig_ipv6_remote" && \
                        ip netns exec vpn ip route add default via \
                                "$ifconfig_ipv6_remote"
                ;;
        down)
                ip netns delete vpn
                ;;
esac
EOF

Ensuite, démarrez OpenVPN et dites-lui d'utiliser notre --up script au lieu d'exécuter ifconfig et route.

openvpn --ifconfig-noexec --route-noexec --up netns-up --route-up netns-up --down netns-up

Vous pouvez maintenant démarrer les programmes à tunnelliser comme ceci :

ip netns exec vpn command

Le seul problème est que vous devez être root pour invoquer ip netns exec ... et peut-être que vous ne voulez pas que votre application s'exécute en tant que root. La solution est simple :

sudo ip netns exec vpn sudo -u $(whoami) command

Il s'avère que vous pouvez mettre une interface de tunnel dans un espace de noms réseau. Tout mon problème était dû à une erreur dans l'affichage de l'interface :

ip addr add dev $tun_tundv \
    local $ifconfig_local/$ifconfig_cidr \
    broadcast $ifconfig_broadcast \
    scope link

Le problème est le "lien de portée", que j'ai mal compris comme n'affectant que le routage. Cela amène le noyau à définir l'adresse source de tous les paquets envoyés dans le tunnel sur 0.0.0.0; vraisemblablement, le serveur OpenVPN les rejetterait alors comme non valides selon RFC1122 ; même si ce n'était pas le cas, la destination serait évidemment incapable de répondre.

Tout a fonctionné correctement en l'absence d'espaces de noms réseau car le script de configuration réseau intégré d'openvpn n'a pas commis cette erreur. Et sans "lien de portée", mon script d'origine fonctionne également.

(Comment ai-je découvert cela, demandez-vous ? En exécutant strace sur le processus openvpn, configurez pour hexdump tout ce qu'il lit à partir du descripteur de tunnel, puis décodez manuellement les en-têtes de paquet.)

L'erreur lors de la tentative de création des périphériques veth est causée par un changement de la façon dont ip interprète les arguments de la ligne de commande.

L'invocation correcte de ip créer une paire d'appareils veth est

ip link add name veth0 type veth peer name veth1

(name au lieu de dev )

Maintenant, comment faire sortir le trafic de l'espace de noms vers le tunnel VPN ? Puisque vous n'avez que des périphériques tun à votre disposition, le "host" doit router. C'est à dire. créez la paire veth et placez-en une dans l'espace de noms. Connectez l'autre via le routage au tunnel. Ainsi, activez le transfert, puis ajoutez les routes nécessaires.

Par exemple, supposons que eth0 est votre interface principale, tun0 est votre interface de tunnel VPN, et veth0 /veth1 la paire d'interfaces dont veth1 est dans l'espace de noms. Dans l'espace de noms, vous ajoutez juste une route par défaut pour veth1 .

Sur l'hôte, vous devez utiliser le routage de stratégie, voir ici par exemple. Ce que vous devez faire :

Ajouter/ajouter une entrée comme

1   vpn

à /etc/iproute2/rt_tables . Par cela, vous pouvez appeler la table (encore à créer) par son nom.

Utilisez ensuite les instructions suivantes :

ip rule add iif veth0 priority 1000 table vpn
ip rule add iif tun0 priority 1001 table vpn
ip route add default via <ip-addr-of-tun0> table vpn
ip route add <ns-network> via <ip-addr-of-veth0> table vpn

Je ne peux pas essayer ici avec une configuration comme la vôtre, mais cela devrait faire exactement ce que vous voulez. Vous pouvez augmenter cela par des règles de filtrage de paquets telles que ni le vpn ni le réseau "invité" ne soient perturbés.

N.B. Déplacement de tun0 dans l'espace de noms en premier lieu semble être la bonne chose à faire. Mais comme toi, je n'ai pas réussi à le faire fonctionner. Le routage des politiques semble être la prochaine bonne chose à faire. La solution de Mahendra est applicable si vous connaissez les réseaux derrière le VPN et toutes les autres applications n'accéderont jamais à ces réseaux. Mais votre condition initiale ("tout le trafic, et seulement le trafic, vers/depuis des processus spécifiques passe par le VPN") donne l'impression que ce dernier ne peut être garanti.