Ubuntu-fr

Zakhar

[Astuce + Question pointue] Freebox en Serveur VPN

Bonjour,

la Freebox (Revolution et au delà) fait Serveur VPN depuis longtemps, et maintenant WireGuard que je n'ai pas encore testé !..

Une petite astuce selon votre usage pour le Serveur VPN OpenVPN (mode routé).

Celui-ci est conçu pour un cas d'usage bien précis : pouvoir se balader sur l'internet avec votre Freebox en adresse de sortie.

Utilité, par exemple vous êtes dans un pays qui censure, et vous voulez surfer normalement comme depuis chez vous. Aussi dans tous les cas où vous voulez "faire croire" (télé-travail ) que vous êtes chez vous même si ce n'est pas le cas !

Pour ce cas d'usage, le fichier de configuration standard en OpenVPN routé que vous récupérez depuis la Freebox contient deux directives essentielles :

redirect-gateway
pull

La première va simplement, comme son nom l'indique, rediriger la passerelle par défaut vers le VPN.
La directive pull sert pour éviter les "fuites", notamment en réponse la Freebox pousse (PUSH) une option pour rediriger le DNS vers 212.27.38.253 laquelle est l'adresse déclarée dans les DNS comme "mafreebox.freebox.fr" et se trouve aussi redirigé vers le VPN.

Exemple de PUSH reçu:

PUSH: Received control message: 'PUSH_REPLY,ping 30,ping-restart 120,dhcp-option DNS 212.27.38.253,route 192.168.27.64 255.255.255.224,route 192.168.0.0 255.255.255.0,ifconfig 192.168.27.xx 212.27.38.253,peer-id 0,cipher AES-256-GCM'

La directive ifconfig fait passer la trafic pour notre IP de VPN 192.168.27.xx (je vous conseille une IP fixe déclarée côté serveur) vers 212.27.38.253 et la directive dhcp-option DNS 212.27.38.253 route précisément les DNS vers cela.

A noter que ce mode "routé" permet aussi de joindre les "clients" qui sont derrière la Freebox distante. Très pratique par exemple si vous avez un Raspberry Pi qui tourne derrière la Freebox ciblée.

Tout cela est bel et bon si votre cas d'usage est bien celui prévu par Free !

Autre cas d'usage :

• Certains sites utilisent l'adresse IP comme "clé" de contrôle ou font de la limitation par IP.

• Vous voulez peut-être juste accéder à votre Raspberry Pi derrière votre Freebox distante, mais pas vraiment rediriger tout le trafic local !..

Dans ce cas, le fichier de configuration fourni par Free doit être "bidouillé".

Enlever (mettre en commentaire) la directive redirect-gateway semblera fonctionner, mais présente plusieurs limitations que j'ai découvertes récemment, d'où la présente astuce.

Le trafic DNS est redirigé vers votre box distante ! Pas ce que vous voulez dans ces cas d'usage.
Si vous avez plusieurs Freebox distantes (mon cas, toute ma famille est chez Free), dès le deuxième VPN ça va coincer à cause du push de l'ipconfig vers la même adresse unique.

Donc en plus de commenter redirect-gateway, voici ce que je vous recommande :

# redirect-gateway

# Avoid redirecting DNS, and the common public address of freebox server
pull-filter ignore "ifconfig"
ifconfig 192.168.27.xx 192.168.0.254
pull-filter ignore "dhcp"
pull-filter ignore "route"
route 192.168.0.0 255.255.255.0

On va en fait purement et simplement "ignorer" les réponses PUSH de la Freebox qui ne nous plaisent pas, donc déjà laisser le DNS en local ce qui nous va bien, et faire notre routage nous même avec le ifconfig qui va bien.

Dans l'exemple ci-dessus, remplacez xx par l'IP fixe du VPN configuré pour l'utilisateur, et le routage vers 192.168.0.254 doit être adapté si votre Freebox est routée en 192.168.1.x ou 2.x etc...

Bien sûr, si vous avez plusieurs Freebox et que vous voulez toutes les joindre, prenez un sous-réseau différent pour chacune. Dans ce cas n'oubliez pas non plus de changer tun0 par défaut en tun1, tun2 etc...

On finit enfin par une commande route qui va permettre de joindre les "clients" de la Freebox ciblée, et donc notre fameux Raspberry Pi distant.

Astuce avancée :
Oui, on peut se servir de plusieurs IP à la fois (pour les sites que je ne nommerais pas qui se servent de l'IP pour limiter par exemple les téléchargements !), de façon assez simple en ligne de commande.

L'astuce "avancée" consiste a créer un nouvel utilisateur, je les ai appelés curl01 et curl02 (sans "home", ils n'en ont pas besoin) et rediriger tout le trafic de ces utilisateurs via le VPN.

Démonstration :

$ curl -4 https://icanhazip.com
77.111.222.333
$ sudo -u curl02 curl -4 https://icanhazip.com
88.22.33.44

(IP changées bien sûr !)

Le script qui permet de faire ça sur mon Raspberry Pi est :

$ cat ~/Scripts/vpn_c.sh 
#! /bin/sh
if ! [ $(id -u) = 0 ]; then
   echo "I am not root!"
   exit 1
fi
systemctl start openvpn-client@freebox_c
sleep 10
iptables -t mangle -A OUTPUT -m owner --uid-owner 123 -j MARK --set-mark 4
iptables -t nat -A POSTROUTING -o tun1 -j SNAT --to-source 192.168.27.xx
ip route add default via 192.168.27.xx table 4
ip rule add fwmark 4 table 4
ip route flush cache

- Démarrage du VPN
- On attend un peu
- règle iptables pour "marquer" les paquets du user 123 qui n'est autre que curl02 ci-dessus
- Source NAT des paquets sur le VPN pour qu'ils aient l'IP du VPN (remplacer xx par l'IP fixe configurée)
- Création d'une table de routage nouvelle dans laquelle on met l'adresse par défaut de notre VPN et sur laquelle on envoie tous les paquets marqués avec "4"
(Changer le "marquage" et la table pour chaque VPN).
- On "flush" les caches de routage pour que tout se passe bien !..

Donc vous voyez, l'exemple avec curl ci-dessus ne fait qu'afficher l'IP publique que voit icanhazip.com, mais cela pourrait très bien être un téléchargement d'une "sauvegarde du web" de plusieurs giga, et vous pouvez bien sûr faire ça en parallèle sur vos VPN différents.

Question :
C'est pour "cador des réseaux"... et je n'arrive pas à le faire mais c'est potentiellement impossible puisqu'on n'a pas accès aux tables de routages internes de la Freebox concernant sa partie Serveur VPN.

Lorsque je suis branché sur la Freebox 1 (celle en 192.168.1.x) et me connecte à ma Freebox 0 (celle en 192.168.0.x) en mode routé, de la façon indiquée ci-dessus, je peux accéder à mon Raspberry Pi qui se trouve derrière Freebox 0.
Les paquets vers 192.168.0.x sont en effet routés via le VPN, et une fois sur Freebox 0, la Freebox sait les distribuer à "x" qui est le Raspberry Pi. Lorsque le Raspberry Pi répond à un paquet, c'est à une adresse 192.168.27.xx, et ça la Freebox sait que c'est un VPN actif et renvoie bien la réponse via ce tunnel. Tout marche bien !..

Maintenant, ce que je voudrais, c'est pouvoir utiliser la même "astuce avancée" ci-dessus pour utiliser ce VPN "déjà monté". Mais là ça ne marche pas... en effet le script ci-dessus fonctionne car c'est bien le Raspberry Pi qui lance les VPN et donc il peut trafiquer ses tables de routage et ses iptables. Mais là il s'agirait d'utiliser un VPN qui n'est pas monté par le Raspberry Pi mais par mon laptop client distant.

Monter un VPN "à l'envers" du Raspberry Pi connecté à Freebox 0 vers la Freebox 1 conduit à un deadlock réseau puisque le paquets de mon client vers le Raspberry Pi et les paquets retour vont employer des tunnels différents... ce qui ne fonctionne pas du tout !

Une idée ?

192.168.0.254     192.168.0.x
/----------------\        /----------------\
| Freebox 0  |-------| Raspb Pi   |
\----------------/        \----------------/
         |        \
         |          \
         |            VPN 192.168.27.xx
/----------------\        /----------------\
| Freebox 1  |-------| Laptop       |
\----------------/        \----------------/
192.168.1.254     192.168.1.x

Laptop peut joindre Freebox 0 et tout "client" comme Raspb Pi connecté à Freebox 0.
J'aimerais depuis le Raspb Pi pouvoir "sortir" des paquets via 192.168.1.254 en utilisant le VPN monté sur la Freebox depuis mon Pi... mais sans avoir la main sur le routage de la Freebox (hélas) !..

... ou alors un autre VPN du Pi vers Freebox 1 qui ne fasse pas "dead-lock" !

Bien sûr on peut "tricher" en montant un des deux en "bridge", c'est d'ailleurs comme ça qu'on arrive à "casser" le dead-lock qui fait que le ssh vers votre Pi ne marche plus... mais si un "grand gourou" des réseaux passe par là, un conseil en "routé" (si tant est que c'est possible) est apprécié.

[Edit] en réalité le besoin d'avoir "plusieurs IP" sur la Raspberry Pi seul est suffisant, donc je vais probablement essayer le VPN à partir du Raspberry Pi vers Freebox 1 et la connexion au RPi via son adresse de VPN (ça devrait fonctionner !). L'avantage à faire ainsi est que l'IP du VPN persiste sur le Pi même si on coupe le Laptop... ce qui est en fait un des besoins !

Dernière modification par Zakhar (Le 10/10/2021, à 10:24)

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Zakhar

Re : [Astuce + Question pointue] Freebox en Serveur VPN

Une précision intéressante avec les scripts ci-dessus :
- Avec un Ubuntu (Desktop) cela marche parfaitement car le DNS est confié à systemd, et donc les DNS sont émis avec un user qui est celui de systemd et donc non affectés par les règles UID de sélection.
- Avec le Raspberry Pi sous Raspberry OS (Buster 32 bis), le DNS est redirigé vers le VPN mais il échoue (l'IP demandée n'existe pas), et il est ensuite refait en local ce qui donne un temps d'attente chaque fois qu'un programme lancé par le UID filtré fait un DNS.

On est en réalité dans un cas d'usage non prévu par Linux !..

On peut bien sûr affecter des DNS par interface (avec Systemd) mais le raisonnement est que quand on fait un DNS on ne connaît pas encore l'IP et donc on n'a pas la décision de routage qui pourrait nous indiquer quelle interface utiliser.
En l'occurrence, comme on filtre par UID, on voudrait ici un DNS avec l'IP affectée à l'interface sur une interface qui dépend de l'UID puisqu'on aimerait tout le trafic de cet UID sur l'interface désigné.

Il est compliqué de résoudre un truc qui n'existe pas (encore) sur Linux, donc on en reste aux scripts ci-dessus qui sont fonctionnellement suffisants, en tout cas pour mon usage !

Il faut donc savoir que le script ci-dessus est totalement fonctionnel sur un Ubuntu Desktop, cependant les DNS de l'UID filtré ne sont pas envoyés sur le VPN mais résolus en local.

Sur un Raspberry Pi, pour éviter le temps d'attente, il faut rajouter une règle de filtrage pour éviter précisément que les DNS tentent d'aller sur l'interface ciblée puisqu'alors ils échoueraient.
Je vous laisse faire la règle en question puisque désormais je vais utiliser Wireguard.

Post à venir pour Wireguard!

Dernière modification par Zakhar (Le 10/10/2021, à 07:37)

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)