Journal Vacances & Réseaux hostiles

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
45
17
juil.
2015

Bonjour Nal,

Cette période propice à l'oisiveté est également parfois synonyme de déplacements physiques vers des contrées ensoleillées. Et comme tu es prévoyant, cher Nal, tu as probablement en stock un ou deux VPN plus ou moins communautaires, afin de pallier à l'absence de sécurité des points réseaux rencontrés, et de préserver ta vie privée. Combinaison de photos estivales personnelles et de réseaux inconnus, il n'en fallait pas plus pour que tu t'équipes. Cependant, par défaut ce n'est pas toujours pratique car tout ton beau système va se caler sur la patte réseau disponible. Or tu voudrais bien lancer HotDog-Time sur un vpn pour lui tout seul, par exemple. Et en même temps consulter ton courriel via imap sur un second vpn. Tout en surfant pour vérifier la météo des jours prochains directement sur le wifi de l'hotel. Bref, tu voudrais tout en même temps, et tout de suite.

Proxy locaux ? Règles de routage seules ? Machine Virtuelle dédiée ? Que nenni ! Il y a plus simple, et taillé pour : l'isolation par espaces de nommages, ou namespaces La documentation est limpide, non ? Alors allons y par l'exemple. Et pour se faire, nous allons utiliser les spécificités "netns" de la commande "ip". Elle est pas belle, la vie ? :-)

A) Déclaration espace nommé "tunnel1"

ip netns add tunnel1

B) Activation boucle locale

ip netns exec tunnel1 ip addr add 127.0.0.1/8 dev lo
ip netns exec tunnel1 ip link set lo up

C) Activation interface virtuelle

ip link add vpn0 type veth peer name vpn1
ip link set vpn0 up

D) Assignation dans l'espace, IP interne & route

ip link set vpn1 netns tunnel1 up
ip addr add 10.20.20.1/24 dev vpn0
ip netns exec tunnel1 ip addr add 10.20.20.2/24 dev vpn1
ip netns exec tunnel1 ip route add default via 10.20.20.1 dev vpn1

Voilà voilà. Le plus gros est fait (attention bienzur à votre attribution d'ip, ici en exemple sur un réseau 10.20.20.0)

E) Iptables par dessus

iptables -A INPUT \! -i vpn0 -s 10.20.20.0/24 -j DROP
iptables -t nat -A POSTROUTING -s 10.20.20.0/24 -o wl+ -j MASQUERADE

C'est bon, chez Nal ? (attention là aussi à la déclaration de carte réseau, ici pour l'exemple wl+ afin de faire matcher toute carte wifi, qu'elle se nomme wlanX ou wlpZyGds0z78 :p)

F) Autorise forward

sysctl -q net.ipv4.ip_forward=1

G) Ajout d'un DNS

mkdir -p /etc/netns/tunnel1
echo 'nameserver 8.8.8.8' > /etc/netns/tunnel1/resolv.conf

(attention ici aussi : pour l'exemple c'est un dns de google, rien ne t'empêche d'utiliser un dns de la quadrature du net, par exemple) Et c'est prêt. Le namespace "tunnel1" est maintenant à tes ordres, cher Nal<

H) Lancement vpn isolé

ip netns exec tunnel1 openvpn --config /etc/openvpn/hotdog-time.ovpn

C'est sympa, non ? ip netns exec nom-espace mon-prog (attention là encore à faire pointer vers ta config à toi, ici nommé "hotdog-time.ovpn" qui pourrait aussi bien être Oslo.conf !)

I) Exécution application

ip netns exec tunnel1 sudo -u tankey /opt/hotdog-time/hotdog-time

(attention là aussi à placer ton nom de user :p, et ensuite à lancer le prog de ton choix, ici pour l'exemple hotdog-time qui aurait pu être qupzilla)

This is the end
Bref : une app = un réseau isolé des autres. Si tu veux.
& merci de bien vouloir me pardonner ma fainéantise à ne pas faire des schémas explicatifs pour les cartes et le namespace, ni de m'être lancé dans des explications concises et précises comme une doc de gentoo, mais ce sont les vacances, non ?

  • # Persistence de tout ça

    Posté par  (site web personnel, Mastodon) . Évalué à 9.

    Pardonnez-moi cette question, mais quelle est la meilleur façon de rendre persistent tout ça, c'est à dire que ça se reconfigure automatiquement à chaque démarrage ? (sur ubuntu par ex)

    • [^] # Re: Persistence de tout ça

      Posté par  (Mastodon) . Évalué à 5.

      Un service systemd, auquel tu peux attacher un timer par exemple, si tu souhaites que ça soit en plus lancé quant tu veux, et pas seulement à chaque boot. Et un watchdog qui surveille ton @vpn.

      • [^] # Re: Persistence de tout ça

        Posté par  . Évalué à 4.

        En un poil plus bourrin tu fais tourner un conteneur docker dans lequel tu as ton VPN et ton appli qui l'utilise.
        C'est un peu plus bourrin car tu fera aussi du namespace PID, cgroup en plus du namespace réseau … Mais tu te pausera moins de question puisque c'est l'outil docker qui s'occupera de configurer ton réseau à ta place . Tout dépend de ce que tu veux maîtriser.

  • # Commentaire supprimé

    Posté par  . Évalué à 10. Dernière modification le 17 juillet 2015 à 15:38.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # socks5

    Posté par  . Évalué à 10.

    Pour ma part, je suis tous les jours ébahi par la simplicité de mise en oeuvre d'un tunnel socks5 nativement fonctionnel avec openssh.
    Exemple:
    autossh -M 0 -ND 1080 server_ssh
    Après, c'est parti avec:
    SOCKS_CONF=~/.tsocks_conf01 tsocks iceweasel
    où:
    * ~/.tsocks_conf01 contient les infos basiques d'utilisation du canal socks5 sur le port 1080
    * ~/.ssh/config contient les détails (user, port, ip, etc…) des connexions aux différents serveurs ssh.
    NB: j'ai remplacé la commande "ssh" par "autossh -M 0" pour pouvoir maintenir mes connexions dans la durée. Ça fonctionne étonnamment bien, même après déconnexion réseau ou mise en veille.

    Ensuite, libre à vous d'utiliser plusieurs canaux socks sur différents serveurs ssh simultanément.

    • [^] # Re: socks5

      Posté par  (site web personnel) . Évalué à 5.

      Le problème de cette approche est que potentiellement, tout n'est pas redirigé.

      C'est pas grave, tu peux utiliser redsocks pour ca!

      • [^] # Re: socks5

        Posté par  . Évalué à 3.

        Tout à fait!

        Cependant, ma solution est plus dans l'idée de choisir explicitement ce qui doit être "tunnelisé", et en utilisant éventuellement plusieurs serveurs (ovh, amazon, serveur d'entreprise, serveur russe ou à Singapour, etc…).

        À noter que si on se limite au web, Firefox est très facile à confifurer pour le socks5.

        Par ailleurs, socks5 est aussi pris en charge nativement par des outils comme curl, ou même une jre avec maven, sans avoir à utiliser tsocks.

        Finalement, tsocks permet simplement de forcer l'utilisation du protocole socks5 pour des outils qui ne le gère pas.

      • [^] # Re: socks5

        Posté par  . Évalué à 2.

        Je voulais aussi ajouter que ça marche aussi sous Android avev ConnectBot pour établir le tunnel socks5, et la config firefox/fennec peut se faire via l'adresse "about:config", propriétés "network.proxy".

        Ça juste marche. Vous devriez pouvoir utiliser les accès Wi-Fi en web dans les aéroports… :-P (humour).

  • # Network over ssh

    Posté par  . Évalué à 2.

    J'utilise sshutle[1]. Si tu peux te connecter à un serveur SSH, c'est bon, ça marche®.

    [1] https://github.com/apenwarr/sshuttle

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.