Auteur Sujet: VPN entre VM debian et freebox distante (Lu 2441 fois)

Zweit · « **le:** 04 avril 2020 à 09:15:36 »

Bonjour à tous,

Je poste car je suis confronté depuis quelques jours à un soucis que je n'arrive pas à résoudre. Je suis sûr que ça doit être tout con, mais je n'arrive pas à mettre le doigt sur le problème.

Le contexte : Deux logements, A et B.

- Dans le logement A il y a une freebox en mode bridge, avec un ERL derrière et de nombreux équipements réseaux dont un serveur avec des machines virtuelles. L'une d'elle est une debian 10 qui me sert de serveur OpenVPN pour mes accès depuis l'extérieur.
- Dans le logement B, une freebox en mode routeur avec des équipements classiques derrière (PC, tablettes, ...)

Je suis dans le logement A. J'utilise VNC et RDP pour prendre le contrôle à distance des machines du logement B. Pour ce faire, je monte un tunnel OpenVPN tap depuis mon PC via le GUI OpenVPN. Cela fonctionne très bien.

Adressage IP du logement A : 10.0.0.0/16 (et d'autres, sans importance pour le problème ici), routeur (ERL) en 10.0.0.1
VM debian en 10.0.2.101
Adressage IP du logement B : 192.168.1.0/24, routeur (Freebox) en 192.168.1.254

Ce que je voudrais faire :

Pour éviter de monter le tunnel à chaque fois et pouvoir faire du VPN / RDP depuis d'autres équipements de A, je souhaiterai monter un tunnel plus persistant. Pour ce faire, je souhaite utiliser ma VM en tant que client OpenVPN et router le trafic du réseau du logement B via celle-ci.

Ce que j'ai fait :

Un petit script de connexion OpenVPN issu de la freebox et très légèrement modifié :

Code: [Sélectionner]

client
remote 2a01:xxxxx[IPv6 Freebox B]xxxxx::1 34338
proto udp
nobind
dev-type tun
tun-ipv6
pull
dev tun0
#redirect-gateway
auth-user-pass
auth-retry interact
fragment 1452
mssfix 1452
explicit-exit-notify 3
cipher AES-256-CBC
remote-cert-tls server
verify-x509-name "C=FR, O=Freebox SA, CN=Freebox OpenVPN server 27xxxxxxxxxxxxxxxxxxxxxxxxxxx"
# use tls-remote instead of verify-x509-name for deprecated openssl
# tls-remote "/C=FR/O=Freebox_SA/CN=Freebox_OpenVPN_server_27xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
<ca>
-----BEGIN CERTIFICATE-----
...Bla bla bla...

Depuis ma VM je lance la connexion (le $dir est défini dans le script bash utilié pour lancer la connexion) :

Code: [Sélectionner]

openvpn --config $dir/vpn.ovpn --auth-user-pass $dir/vpn.pwd --daemon

Le tunnel monte bien.

Les interfaces de la VM :

Code: [Sélectionner]

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun1
       valid_lft forever preferred_lft forever
    inet6 fd42:42:42:42::1/112 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxxxxxxxx/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 192.168.27.65 peer 212.27.38.253/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 2a01:xxxxx[préfixe IPv6 du la Freebox B]xxxxx::10/124 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxxxxx/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
40: eth0@if41: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 82:cd:06:f3:35:4e brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.2.101/16 brd 10.0.255.255 scope global dynamic eth0
       valid_lft 58345sec preferred_lft 58345sec
    inet6 2a01:xxxxx[préfixe IPv6 du logement A]xxxxx:354e/64 scope global dynamic mngtmpaddr 
       valid_lft 2591940sec preferred_lft 604740sec
    inet6 fe80::xxxxxxxxxxx/64 scope link 
       valid_lft forever preferred_lft forever

eth0 => interface par laquelle tout passe
tun1 => interface sur serveur OpenVPN pour les accès distants
tun0 => interface créée suite à l'établissement du tunnel qui nous intéresse

Les routes de la VM :

Code: [Sélectionner]

# ip route
default via 10.0.0.1 dev eth0 
10.0.0.0/16 dev eth0 proto kernel scope link src 10.0.2.101 
10.8.0.0/24 dev tun1 proto kernel scope link src 10.8.0.1 
192.168.1.0/24 via 212.27.38.253 dev tun0 
192.168.27.64/27 via 212.27.38.253 dev tun0 
212.27.38.253 dev tun0 proto kernel scope link src 192.168.27.65

Depuis la VM, je peux sans soucis pinger le routeur B :

Code: [Sélectionner]

# ping 192.168.1.254
PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.
64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=8.80 ms
64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=8.44 ms
64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=9.16 ms
64 bytes from 192.168.1.254: icmp_seq=4 ttl=64 time=8.84 ms
64 bytes from 192.168.1.254: icmp_seq=5 ttl=64 time=9.35 ms
^C
--- 192.168.1.254 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 10ms
rtt min/avg/max/mdev = 8.440/8.916/9.347/0.319 ms

Le routage IP est bien activé sur la VM :

Code: [Sélectionner]

# cat /proc/sys/net/ipv4/ip_forward
1

Dans mon ERL du logement A, j'ai ajouté la route statique 192.168.1.0/24 via 10.0.2.101.

Je n'ai pas activé de pare-feu sur la VM le temps des tests.

Mon problème :

Depuis un PC du logement A, je n'arrive pas à joindre le logement B. Exemple sous Windows :

Code: [Sélectionner]

C:\WINDOWS\System32>ping 192.168.1.254

Envoi d’une requête 'Ping'  192.168.1.254 avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.

Statistiques Ping pour 192.168.1.254:
    Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
Ctrl+C
^C
C:\WINDOWS\System32>tracert 192.168.1.254

Détermination de l’itinéraire vers 192.168.1.254 avec un maximum de 30 sauts.

  1    <1 ms    <1 ms    <1 ms  10.0.0.1
  2    <1 ms    <1 ms    <1 ms  10.0.2.101
  3     *        *        *     Délai d’attente de la demande dépassé.
  4     *        *        *     Délai d’attente de la demande dépassé.
  5     *        *        *     Délai d’attente de la demande dépassé.
  6     *        *        *     Délai d’attente de la demande dépassé.
  7     *        *        *     Délai d’attente de la demande dépassé.
  8  ^C

Et là je bloque. Il doit me manquer un tout petit truc de rien du tout, mais je ne vois pas... Quelqu'un pour m'aider ?

Merci d'avance !

cali · « **Réponse #1 le:** 04 avril 2020 à 21:37:36 »

C'est hyper crade.

Ce que tu veux faire c'est interconnecter différents réseaux ensemble, donc il faut utiliser --topology subnet.

Ensuite, openvpn a une table de routage interne, ça fait firewall. Donc en plus de rajouter les réseaux dans table de routage du système il faut aussi les rajouter dans celle d'openvpn avec --iroute.

kgersen · « **Réponse #2 le:** 05 avril 2020 à 00:49:36 »

Passe sur wireguard c'est 10 fois plus simple et plus performant.

Manuellement ou mieux encore avec https://tailscale.com qui peut déployer cela automatiquement en utilisant un compte Gmail comme moyen d’authentification.

Zweit · « **Réponse #3 le:** 05 avril 2020 à 17:39:54 »

Merci à vous deux pour vos réponses.

J'ai oublié de préciser certaines petites choses qui ont leur intérêt :
- Je n'ai pas moyen de mettre un routeur / serveur alternatif côté logement B. Il s'agit de chez mes parents, qui refusent catégoriquement l'ajout d'"encore un boiter en plus avec plein de fils qui sert à rien"

- La Freebox B est une mini 4k (comme la A d'ailleurs, mais ça n'a pas vraiment d'importance, la debian est sur un serveur fait main à part), donc pas moyen de mettre une VM dessus non plus pour un serveur VPN alternatif

Il faut donc que je compose avec le serveur VPN limité préinstallé sur la Freebox, sans grande possibilité de modification de conf de ce côté... (sinon j'aurais déjà monté un tunnel site à site et la question ne se poserait pas)

Mais l'essentiel est que les équipements de A puissent se connecter à B, l'inverse n'est pas très important.

En creusant encore, j'ai compris que le problème se situait au niveau de la Freebox B qui ne routait pas les paquets de retour vers mon réseau 10.0.0.0/16. N'ayant pas la possibilité de changer le routage sur cette dernière, j'ai tenté un NAT du côté A avant de passer dans le tunnel (qui masque 10.0.0.0/16 en 192.168.27.0/24). Ça fonctionne cette fois, mais je l'admet, c'est hyper crade

Toutefois dans ma situation et avec les restrictions ci-dessus, existe t-il une autre solution plus propre ?

cali · « **Réponse #4 le:** 05 avril 2020 à 18:04:46 »

Citation de: Zweit le 05 avril 2020 à 17:39:54

Toutefois dans ma situation et avec les restrictions ci-dessus, existe t-il une autre solution plus propre ?

Oui, tu routes une adresse du réseau local B dans le tunnel VPN pour l'utiliser sur le réseau A.