Probème VPN (Routage IPv6?)

Bonsoir,

Matériel RaspBerry PI 3B+
Version de YunoHost: 4.3.4.2 (stable)
J’ai accès à mon serveur : En SSH et par webadmin

Je viens de faire les mises à jour de mon YunoHost… Je crois qu’il y a un problème avec le VPN.
Symptôme: J’ai l’application NextCloud-client qui n’arrive plus à se connecter… il indique une erreur réseau.
Je me suis rendu compte que cela faisait l’erreur réseau depuis le réseau Lan… le même réseau Lan dans lequel est connecté mon YunoHost… Mais depuis l’extérieur, depuis un autre réseau, depuis une autre IP publique, ça fait plus l’erreur.

Suite à cela, je me suis rendu compte que l’on peut pinger mon IPv6 de ma YunoHost (celle du VPN), depuis une autre IP publique, mais pas depuis le même Lan que ma YunoHost!

Une idée du problème ?

JM

SI je comprend bien ton réseau local propose bien ipv6 ?
Que donne cette commande sur un ordinateur de ton réseau local (autre que ton yunohost) ?

ping -6 wikipedia.org

Que donne un traceroute d’un ordi de ton réseau local vers ton serveur ?

traceroute -6 domain.tld

Bonjour,

Actuellement NextCloud-client fonctionne! Mais bon, ça pinge toujours pas (mon YunoHost) en IPv6 de mon réseau local!

Les commandes:

$ ping -6 wikipedia.org
PING wikipedia.org(text-lb.esams.wikimedia.org (2620:0:862:ed1a::1)) 56 data bytes
64 octets de text-lb.esams.wikimedia.org (2620:0:862:ed1a::1) : icmp_seq=1 ttl=55 temps=27.6 ms
64 octets de text-lb.esams.wikimedia.org (2620:0:862:ed1a::1) : icmp_seq=2 ttl=55 temps=27.2 ms
64 octets de text-lb.esams.wikimedia.org (2620:0:862:ed1a::1) : icmp_seq=3 ttl=55 temps=27.8 ms
64 octets de text-lb.esams.wikimedia.org (2620:0:862:ed1a::1) : icmp_seq=4 ttl=55 temps=27.7 ms
64 octets de text-lb.esams.wikimedia.org (2620:0:862:ed1a::1) : icmp_seq=5 ttl=55 temps=27.6 ms
64 octets de text-lb.esams.wikimedia.org (2620:0:862:ed1a::1) : icmp_seq=6 ttl=55 temps=27.8 ms
^C
--- statistiques ping wikipedia.org ---
6 paquets transmis, 6 reçus, 0 % paquets perdus, temps 5009 ms
rtt min/avg/max/mdev = 27.189/27.618/27.837/0.211 ms
$ traceroute -6 mongt.nohost.me
traceroute to mongt.nohost.me (2001:910:1361::42), 30 hops max, 80 byte packets
 1  livebox.home (2a01:cb19:8aed:7400:769d:79ff:fe9d:f876)  0.385 ms  0.685 ms  0.628 ms
 2  2a01cb08a00402190193025300740190.ipv6.abo.wanadoo.fr (2a01:cb08:a004:219:193:253:74:190)  1.715 ms  1.691 ms  1.935 ms
 3  2a01:cfc0:200:8300:193:252:102:49 (2a01:cfc0:200:8300:193:252:102:49)  13.765 ms  13.744 ms  14.813 ms
 4  2a01:cfc4:0:1b00::13 (2a01:cfc4:0:1b00::13)  14.288 ms  14.245 ms  14.221 ms
 5  gitoyen.th2-1.hopus.net (2a02:e5c:1:5::2)  13.915 ms  13.894 ms  14.160 ms
 6  whiskey.gitoyen.net (2001:910::5)  15.008 ms  12.898 ms  13.164 ms
 7  2001:910:0:800::212 (2001:910:0:800::212)  13.091 ms  13.351 ms  13.294 ms
 8  vpn7-rw.fdn.fr (2001:910:800::111)  14.078 ms  14.088 ms  14.029 ms
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

JM

Quand tu parles de réseau local, tu parles bien du réseau de ta box et pas d’un wifi généra avec hostpot_ynh ?

Que dis ip a sur ton serveur ?

Quand tu parles de réseau local, tu parles bien du réseau de ta box et pas d’un wifi généra avec hostpot_ynh ?

Oui, le réseau de ma box!

Que dis ip a sur ton serveur ?

$ 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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:75:97:22 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.20/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
       valid_lft 60960sec preferred_lft 50160sec
    inet6 2a01:cb19:8aed:7400:761e:a69c:320f:c3f8/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 1780sec preferred_lft 580sec
    inet6 fe80::7790:9092:27f2:9022/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:20:c2:77 brd ff:ff:ff:ff:ff:ff
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 80.67.179.97/22 brd 80.67.179.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 2001:910:1361::42/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::50e6:6eaf:8261:2634/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

JM

On peut voir la sortie du ping ?

ping -6 mongt.nohost.me

Je pensais à un problème de routage entre opérateur, mais vu que ton traceroute passe, je pense pas que ce soit ça.

Bonjour,

Le ping donne ça:

$ ping -6 mongt.nohost.me
PING mongt.nohost.me(mongt.fr (2001:910:1361::42)) 56 data bytes

Il reste coincé là… il ne revoit pas la main!

JM

Ça pourrait valoir le coup de baisser temporairement le temps d’un test le firewall yunohost, de sorte à identifier si ce parefeu est responsable de la non réponse au ping sur le réseau local.

En pratique ça veut dire quoi ??

JM

  • Dans la webadmin , Services > yunohost-firewall → Arrêter
  • Faire le ping
  • Puis redémarer le firewall

Si le ping fonctionne, c’est un problème avec le firewall, sinon c’est autre chose.

Oui ljf, le problème venait bien du pare-feu… J’ai arrêté le pare-feu… Le ping est passé… J’ai redémarré le pare-feu… le ping passe toujours… J’ai testé une connexion ssh en l’IPv6… elle a fonctionné. Donc, y avait bien un problème au niveau du pare-feu!

Donc, je sais pas ce qui c’est passé… Je serais pour la prochaine fois pour le pare-feu… arrêté, redémarrer!

Merci,

JM

ljf,
Cela pourrait-il venir d’un black-listage de Fail2ban ?
Qui aurait été remis à zéro à l’arrêt du pare-feu ? C’est possible ?

Je sais pas pourquoi ce black-listage aurait duré aussi longtemps !?

JM

Non je penche de mon côté pour un soucis concernant la migration des règles parefeu ipv6 lors de la maj vers vpnclient 2.x.

Okay… et bien, bon courage! :wink:

JM

Bonjour,

Non je penche de mon côté pour un soucis concernant la migration des règles parefeu ipv6 lors de la maj vers vpnclient 2.x.

Une petite info au passage…
Pour moi cette maj n’était pas une maj du vpnclient 1.x vers 2;x … C’était plutôt une maj du vpnclient 2.x, vers 2.x … La maj 1.x vers 2.x aillant été faite 05/11/2021, pas sans difficulté, comme décrit dans ce fil de discutions:
https://forum.yunohost.org/t/resolu-pb-maj-vpn-client-en-version-2-0-ynh1/17711/19

Voilou,
De bonnes fête à tous,

JM

Bonjour,

Je sais pas pourquoi… aujourd’hui aussi le ping IPv6 ne fonctionnait pas…

Comment je m’en suis rendu compte:
J’ai créé un nouvel événement dans mon agenda KOrganizer… et comme il ne synchronisait pas, je lui ai demandé de synchroniser manuellement… et sur ce, il me demandait à se connecter… et comme il synchronisait toujours pas, je recommençais la manœuvre… et chaque fois il me redemandait à se connecter… J’ai donc eu l’idée de faire le teste du ping en IPv6… pour m’apercevoir qu’il n’aboutissait pas!

J’ai donc au départ redémarré le pare-feu de YunoHost… cela n’a pas résolu le problème… J’ai donc arrêté, puis redémarré le pare-feu… et tout-est rentré dans l’ordre! Suite à cela mon agenda était connecté, et au déclenchement d’une synchronisation, il ne me demandait plus à se connecter!

La chose problématique, c’est que le problème revient sans prévenir!
Il s’agit certainement d’un bug… alors si vous avez des suggestions, je suis preneur!

Sur ce joyeux Noël à tous,

JM

Bonjour à tous,
Bonjour ljf,

J’ai fait un test… Dès qu’on démarre (ou redémarre) une machine dans mon Lan, elle est bloquée en IPv6 par le pare-feu de ma YunoHost… Même si la machine n’a pas de compte YunoHost de configurer… (le “ping -6” ne passe pas)…
Pour débloquer, il faut arrêter, et redémarrer le pare-feu.
J’espère que c’est-un bug qui sera vite corrigé!
Merci de me tenir informer,

JM

Bonjour JM,
Pour nous aider à comprendre, la prochaine fois que tu as le soucis, fait ip6tables-save puis tu corriges le problème en arrétant et redémarant ton parefeu et tu refais ip6tables-save.
Tu nous envoies ce qui s’est affiché pour les 2 commandes et ça nous aidera bien dans la résolution.
Merci,

Salut ljf,

Comme ça fait chaque fois le problème, dès qu’on démarre une machine sur le réseau…
Voila donc mes ip6tables-save
Donc avant de redémarrer le pare-feu:

# Generated by xtables-save v1.8.2 on Sun Dec 26 17:18:18 2021
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:vpnclient_in - [0:0]
:vpnclient_out - [0:0]
:vpnclient_fwd - [0:0]
-A INPUT -i eth0 -j vpnclient_in
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5269 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2223 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9009 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 5353 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A FORWARD -o eth0 -j vpnclient_fwd
-A OUTPUT -o eth0 -j vpnclient_out
-A vpnclient_in -p ipv6-icmp -j ACCEPT
-A vpnclient_in -s fd00::/8 -j ACCEPT
-A vpnclient_in -s fe80::/10 -j ACCEPT
-A vpnclient_in -p tcp -m tcp --dport 22 -j ACCEPT
-A vpnclient_in -p tcp -m tcp --dport 443 -j ACCEPT
-A vpnclient_in -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A vpnclient_in -j DROP
-A vpnclient_out -d 2001:910:800::99/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::57/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::45/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::108/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::84/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::109/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::107/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::101/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::104/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::110/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::40/128 -p udp -m udp --dport 53 -j ACCEPT
-A vpnclient_out -d fd00::/8 -j ACCEPT
-A vpnclient_out -d fe80::/10 -j ACCEPT
-A vpnclient_out -d ff02::fb/128 -p udp -m udp --dport 5353 -j ACCEPT
-A vpnclient_out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A vpnclient_out -j DROP
-A vpnclient_fwd -j DROP
COMMIT
# Completed on Sun Dec 26 17:18:18 2021

Et après avoir redémarrer le pare-feu:

# Generated by xtables-save v1.8.2 on Sun Dec 26 17:19:56 2021
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:vpnclient_in - [0:0]
:vpnclient_out - [0:0]
:vpnclient_fwd - [0:0]
-A INPUT -i eth0 -j vpnclient_in
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5269 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2223 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9009 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 5353 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A FORWARD -o eth0 -j vpnclient_fwd
-A OUTPUT -o eth0 -j vpnclient_out
-A vpnclient_in -p ipv6-icmp -j ACCEPT
-A vpnclient_in -s fd00::/8 -j ACCEPT
-A vpnclient_in -s fe80::/10 -j ACCEPT
-A vpnclient_in -p tcp -m tcp --dport 22 -j ACCEPT
-A vpnclient_in -p tcp -m tcp --dport 443 -j ACCEPT
-A vpnclient_in -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A vpnclient_in -j DROP
-A vpnclient_out -d 2001:910:800::110/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::104/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::101/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::107/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::109/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::84/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::108/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::45/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::57/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::99/128 -j ACCEPT
-A vpnclient_out -d 2001:910:800::40/128 -p udp -m udp --dport 53 -j ACCEPT
-A vpnclient_out -d fd00::/8 -j ACCEPT
-A vpnclient_out -d fe80::/10 -j ACCEPT
-A vpnclient_out -d ff02::fb/128 -p udp -m udp --dport 5353 -j ACCEPT
-A vpnclient_out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A vpnclient_out -j DROP
-A vpnclient_fwd -j DROP
COMMIT
# Completed on Sun Dec 26 17:19:56 2021

Donc, si je démarre une nouvelle machine, le problème sera à nouveau présent pour la nouvelle machine seulement… et pas pour les machines déjà connectées au moment de l’arrêt et redémarrage du pare-feu!

JM

Bonsoir,

Pas tout-à fait…
Pour pouvoir se connecter en IPv6 depuis mon Lan sur ma machine YunoHost (en IPv6 du VPN)… Il faut:
-1) que je désactive le pare-feu
-2) que je pinge ma machine YunoHost par sons IPv6 VPN (ça fonctionne, car le pare-feu est désactivé)
-3) Optionnel… arrêter le ping
-4) Redémarrer le pare-feu (car c’est plus prudent… question de sécurité)
Et en 5) maintenant, la connexion en IPv6 vers ma YunoHost fonctionne… Notamment je peux la tester avec le ping ou ssh

J’espère avoir été plus précis sur mon problème… car j’espère avoir de vos nouvelles concernant ce bug!

Librement,

JM