[OpenVPN] TAP créé mais pas de connexion (Résolu)

[Xorg]

Salut.

J'utilisais le serveur OpenVPN intégré dans le Freebox OS 3.1.6 (en mode bridge) et ça fonctionnait sans soucis.
J'ai eu la bonne idée de mettre à jour le Freebox OS en 3.2.1, et là c'est la vraie misère, je n'arrive plus à me connecter à Internet à travers mon VPN. Il semblerait que les développeurs de chez Free soient passé d'une interface TUN à une interface TAP, ce qui expliquerait en partie mon problème.

Quand je me connecte, je ne constate pas d'erreurs (j'ai ajouté verb 3 dans le fichier de configuration) :

Code : Tout sélectionner

...
Wed Dec 30 13:27:38 2015 TUN/TAP device tap0 opened
Wed Dec 30 13:27:38 2015 TUN/TAP TX queue length set to 100
Wed Dec 30 13:27:38 2015 Initialization Sequence Completed

Un ifconfig ne me montre pas la nouvelle interface, et un ip link la montre, mais inactive :

Code : Tout sélectionner

8: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 100
    link/ether 16:93:bb:70:ef:f7 brd ff:ff:ff:ff:ff:ff

Après avoir activé l'interface et attribué une adresse IP, tap0 apparaît bien avec un ifconfig, mais mon trafic ne transite toujours pas par le VPN.

Voici la sortie d'un route -n après cela :

Code : Tout sélectionner

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.23.255.254  0.0.0.0         UG    0      0        0 net0
0.0.0.0         192.168.0.254   0.0.0.0         UG    208    0        0 tap0
172.23.0.0      0.0.0.0         255.255.0.0     U     0      0        0 net0
192.168.0.0     0.0.0.0         255.255.255.0   U     208    0        0 tap0

Et je ne sais pas ce que je dois faire à partir de ce moment là. Toutes mes tentatives se sont soldées par la perte totale de connexion Internet.
Quand je remets en mode TUN dans le fichier de configuration, ça ne fonctionne pas mieux, et je ne comprends pas grand chose à ces histoires de TUN/TAP et de gateway...

Merci d'avance.

[Moviuro]

Plop,

En mode TAP (qui est en général une mauvaise idée : broadcast, arp poisoning, berk), c'est comme si tu ajoutais une prise ethernet à ta machine : il faut faire du DHCP (berk) dessus.

Aussi, on n'a pas ta conf client : tu peux nous la donner ?
Quid de la documentation Free ? tu l'as lue ?
Je ne sais pas où tu es physiquement quand tu tentes l'expérience, et je ne vois que des IP privées (RFC 1918) dans ton message. Il y manque l'IP publique de ta box.

[Xorg]

En mode TAP (qui est en général une mauvaise idée

Le petit détail, c'est que ce n'est pas de moi que vient cette décision. La Freebox génère un fichier de configuration elle-même, et ça fonctionnait très bien en version 3.1, mais depuis la 3.2 je vois qu'il y a des différences, comme le choix d'une interface TAP.

Quand je remplace :

Code : Tout sélectionner

dev-type tap
pull
dev tap0

Par :

Code : Tout sélectionner

dev-type tun
pull
dev tun0

J'ai ces erreurs :

Code : Tout sélectionner

Wed Dec 30 13:59:28 2015 WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap'
Wed Dec 30 13:59:28 2015 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1561', remote='link-mtu 1593'
Wed Dec 30 13:59:28 2015 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
...
Wed Dec 30 13:59:31 2015 OPTIONS IMPORT: timers and/or timeouts modified
Wed Dec 30 13:59:31 2015 TUN/TAP device tun0 opened
Wed Dec 30 13:59:31 2015 TUN/TAP TX queue length set to 100
Wed Dec 30 13:59:31 2015 Initialization Sequence Completed
Wed Dec 30 14:00:17 2015 write to TUN/TAP : Invalid argument (code=22)
Wed Dec 30 14:00:47 2015 write to TUN/TAP : Invalid argument (code=22)
Wed Dec 30 14:01:08 2015 write to TUN/TAP : Invalid argument (code=22)

Aussi, on n'a pas ta conf client : tu peux nous la donner ?

Oui, bien sûr :

Code : Tout sélectionner

client
remote IP_FREEBOX 1194
proto udp
nobind
dev-type tap
pull
dev tap0
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 ..."
verb 3

Quid de la documentation Free ? tu l'as lue ?

Non, vu que je n'avais pas de problèmes en 3.1.6.

Je ne sais pas où tu es physiquement quand tu tentes l'expérience, et je ne vois que des IP privées (RFC 1918) dans ton message. Il y manque l'IP publique de ta box.

Je suis à plusieurs centaines de kilomètres de ladite Freebox, mais je suis en France, la Freebox aussi l'est.

[Moviuro]

Je ne sais pas où tu es physiquement quand tu tentes l'expérience, et je ne vois que des IP privées (RFC 1918) dans ton message. Il y manque l'IP publique de ta box.

Je suis à plusieurs centaines de kilomètres de ladite Freebox, mais je suis en France, la Freebox aussi l'est.

Dans tes routes, il manque :

Code : Tout sélectionner

ip.de.la.fbx/32 via de.fau.lt.gw

où de.fau.lt.gw est l'Ip de ta passerelle locale.

Je pense qu'il serait bon de lire la doc freebox

Ok pour tap/tun, mais je persiste : c'est mal.

[Xorg]

Je viens de faire route add IP_FREEBOX/32 gw 172.23.255.254. Maintenant j'ai :

Code : Tout sélectionner

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.23.255.254  0.0.0.0         UG    0      0        0 net0
0.0.0.0         192.168.0.254   0.0.0.0         UG    211    0        0 tap0
IP_FREEBOX   172.23.255.254  255.255.255.255 UGH   0      0        0 net0
172.23.0.0      0.0.0.0         255.255.0.0     U     0      0        0 net0
192.168.0.0     0.0.0.0         255.255.255.0   U     211    0        0 tap0

Mais ça ne passe toujours pas par le VPN...

[Moviuro]

Tu as des routes trop peu précises :

Code : Tout sélectionner

# ip ro add 0/1 via 192.168.0.254
# ip ro a 128/1 via 192.168.0.254

Voilà, ça devrait aider et pour vérifier :

Code : Tout sélectionner

curl icanhazip.com

[benjarobin]

Il faut vraiment se faire du mal pour choisir la solution bridge (tap0)
Si tu veux que ta connexion internet soit redirigé par la freebox, alors tu dois faire ceci (wlan0 est mon interface fournissant internet) :

Code : Tout sélectionner

# On met un DNS de valide (a voir si c'est nécessaire)
echo "nameserver 8.8.8.8" > /etc/resolv.conf

# On ajoute une route pour joindre le VPN,
# ip_gateway_local est la gateway que tu as avant la connexion au VPN
ip route add $ip_remote_vpn via $ip_gateway_local dev wlan0

# On se connecte au VPN (ne rend pas la main, faire la suite dans un autre terminal)
openvpn config_openvpn_bridge_xxxx.ovpn

# On demande une IP pour l'interface du VPN
dhcpcd -d tap0

# On supprime la route par défaut, c'est pour cela que l'on a ajouté une route
# auparavant pour toujours pouvoir joindre le VPN
ip route delete default dev wlan0

C'est tellement plus simple et plus propre via une connexion routed (tun0), il n'y a rien à faire, par défaut on peut accéder au réseau interne (donc aux PC connectés à la freebox), et la connexion est par défaut redirigé par la freebox

[Moviuro]

C'est tellement plus simple et plus propre via une connexion routed (tun0), il n'y a rien à faire, par défaut on peut accéder au réseau interne (donc aux PC connectés à la freebox), et la connexion est par défaut redirigé par la freebox

Bof, y'a toujours plein de soucis de routes. C'est pas plus simple, mais ça évite bien des em***des.
C'est plutôt très sale ce que tu fais : créer une nouvelle route par défaut : ça va lui péter à la figure si le VPN saute pour une raison X ou Y. D'ailleurs, openvpn lui-même utilise ma méthode (router 0/1 et 128/1).
La modifications du nameserver n'est pas obligatoire et est à adapter : tu veux plutôt utiliser 127.0.0.1 (avec unbound qui tourne) ou 192.168.0.254, qui est la freebox.

[benjarobin]

Euh, je ne vois aucun souci. Si le VPN saute il n'auras juste plus internet, mais il pourra toujours relancer la connexion au VPN (grâce à la route ajouté initialement).
Au moins avec cette méthode, tu n'es pas pris en traître, car si le VPN saute tu le sais et tu ne bascule pas vers le réseau par défaut automatiquement sans t'en rendre compte.

[Xorg]

Bon, j'ai vu que cette histoire faisait couler beaucoup de sang. toutefois, vous m'avez ouvert les yeux sur le vrai problème... J'avais oublié que bridge = TAP et route = TUN, et vu que je confonds tout le temps bridge et route, ça ne le fait pas...
L'interface de configuration du VPN en mode route dans le Freebox OS 3.2 a été modifiée, et quand j'ai reconfiguré le VPN, j'ai configuré le mode bridge à cause d'une habitude d'interface (le mode route ayant changé, je me suis dit au début que ce n'était pas ça, c'est pour ça que j'ai configuré en bridge). En fait, il fallait juste que j'utilise le mode route et non le mode bridge, ce qui est une erreur de débutant (pourtant, il me semblait que j'avais testé en mode route et que ça ne fonctionnait pas mieux hier).

Bref, je devais être fatigué hier soir, j'ai confondu les deux, et c'est pour ça que je m'acharnais sur le mode TAP (alors que jusqu'à présent j'utilisais le mode TUN sans difficulté). Sur ce, tout est rentré dans l'ordre (screenshot à l'appui).

Désolé pour le topic inutile et pour la bourde, mais merci beaucoup pour votre aide.