Mise à jour Debian derrière un VPN

Support Debian
#1

Bonjour à tous,

J’utilise parfois pour mes besoins un VPN, et lorsque je suis connecté par VPN et que je lance une mise à jour par console, la connexion au ftp.fr Debian est interminable et le processus bloque dessus…

root@GOGI:/home/gogi# agd Atteint http://ppa.launchpad.net trusty InRelease Atteint http://repos.fds-team.de unstable InRelease Atteint http://ppa.launchpad.net trusty/main amd64 Packages Atteint http://repos.fds-team.de testing InRelease Atteint http://ppa.launchpad.net trusty/main i386 Packages Atteint http://repos.fds-team.de stable InRelease Atteint http://ppa.launchpad.net trusty/main Translation-en Atteint http://repos.fds-team.de unstable/main amd64 Packages Atteint http://repos.fds-team.de unstable/main i386 Packages Atteint http://repos.fds-team.de testing/main amd64 Packages Atteint http://repos.fds-team.de testing/main i386 Packages Atteint http://repos.fds-team.de stable/main amd64 Packages Atteint http://repos.fds-team.de stable/main i386 Packages Ign http://repos.fds-team.de unstable/main Translation-fr_FR Ign http://repos.fds-team.de unstable/main Translation-fr Ign http://repos.fds-team.de unstable/main Translation-en Ign http://repos.fds-team.de testing/main Translation-fr_FR Ign http://repos.fds-team.de testing/main Translation-fr Ign http://repos.fds-team.de testing/main Translation-en Ign http://repos.fds-team.de stable/main Translation-fr_FR Ign http://repos.fds-team.de stable/main Translation-fr Ign http://repos.fds-team.de stable/main Translation-en 100% [Connexion à ftp.fr.debian.org (2a01:e0c:1:1598::2)] [Connexion à security.debian.org (2001:a78:5:0:216:35ff:fe7f:be4f)]

Alors je cherche à savoir pourquoi il est impossible de s’y connecter lorsqu’on est derrière un VPN? Ça m’oblige à couper le VPN pour revenir sur une connexion classique et recommencer l’opération.

#2

Ça a l’air lié à la connectivité IPv6. Les deux miroirs Debian ont une adresse IPv6, pas les autres.
Le VPN et le FAI fournissent-ils une connectivité IPv6 ?

ip -6 addr ip -6 route ip route get 2a01:e0c:1:1598::2
A comparer avec et sans VPN.

Les sites web debian-fr.org et debian.org ont aussi une adresse IPv6, tu n’as pas de problème pour y accéder avec le VPN ?

#3

[quote=“PascalHambourg”]Ça a l’air lié à la connectivité IPv6. Les deux miroirs Debian ont une adresse IPv6, pas les autres.
Le VPN et le FAI fournissent-ils une connectivité IPv6 ?

ip -6 addr ip -6 route ip route get 2a01:e0c:1:1598::2
A comparer avec et sans VPN.

Les sites web debian-fr.org et debian.org ont aussi une adresse IPv6, tu n’as pas de problème pour y accéder avec le VPN ?[/quote]

Salut Pascal,

Le VPN et FAI fournissent une connectivité IPv6, et j’ai accès à debian-fr.org et debian.org normalement, d’ailleurs j’écris à l’instant au travers du tunnel VPN.

#4

Pardon je ne t’ai pas donné les retours commande…

Donc avec VPN :

gogi@GOGI:~$ ip -6 addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2a01:e35:139c:b160:44d:de2b:df89:cf7e/64 scope global temporary dynamic valid_lft 86215sec preferred_lft 80856sec inet6 2a01:e35:139c:b160:227:10ff:fe83:d69c/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 86215sec preferred_lft 86215sec inet6 fe80::227:10ff:fe83:d69c/64 scope link valid_lft forever preferred_lft forever 14: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qlen 100 inet6 2001:db8:123::2/64 scope global valid_lft forever preferred_lft forever

gogi@GOGI:~$ ip -6 route 2001:db8:123::/64 dev tun0 proto kernel metric 256 pref medium 2a01:e35:139c:b160::/64 dev wlan0 proto kernel metric 256 expires 86047sec pref medium 2000::/3 via 2001:db8:123::1 dev tun0 proto static metric 50 pref medium fe80::/64 dev wlan0 proto kernel metric 256 pref medium default dev tun0 proto static metric 50 pref medium default via fe80::207:cbff:fe49:93b7 dev wlan0 proto static metric 600 pref medium

gogi@GOGI:~$ ip route get 2a01:e0c:1:1598::2 2a01:e0c:1:1598::2 from :: via 2001:db8:123::1 dev tun0 proto static src 2001:db8:123::2 metric 50 pref medium

Et sans VPN :

gogi@GOGI:~$ ip -6 addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2a01:e35:139c:b160:44d:de2b:df89:cf7e/64 scope global temporary dynamic valid_lft 86179sec preferred_lft 80610sec inet6 2a01:e35:139c:b160:227:10ff:fe83:d69c/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 86179sec preferred_lft 86179sec inet6 fe80::227:10ff:fe83:d69c/64 scope link valid_lft forever preferred_lft forever

gogi@GOGI:~$ ip -6 route 2a01:e35:139c:b160::/64 dev wlan0 proto kernel metric 256 expires 86162sec pref medium fe80::/64 dev wlan0 proto kernel metric 256 pref medium default via fe80::207:cbff:fe49:93b7 dev wlan0 proto static metric 600 pref medium

gogi@GOGI:~$ ip route get 2a01:e0c:1:1598::2 2a01:e0c:1:1598::2 from :: via fe80::207:cbff:fe49:93b7 dev wlan0 proto static src 2a01:e35:139c:b160:44d:de2b:df89:cf7e metric 600 pref medium

#5

D’où vient ce préfixe 2001:db8:123::/64 ? Le préfixe 2001:db8::/32 est réservé à la rédaction d’exemples et de documentations. Les adresses dans ce préfixe ne sont pas valides sur une machine et ne sont pas routées sur l’internet public. Sans NAT IPv6 ou proxy transparent à la sortie du VPN, ça ne peut pas marcher. Peux-tu en dire plus sur ce VPN (perso ou fournisseur) ?

Les miroirs Debian dans sources.list sont-ils en [mono]ftp://[/mono] ou [mono]http://[/mono] ?

#6

[quote=“PascalHambourg”]D’où vient ce préfixe 2001:db8:123::/64 ? Le préfixe 2001:db8::/32 est réservé à la rédaction d’exemples et de documentations. Les adresses dans ce préfixe ne sont pas valides sur une machine et ne sont pas routées sur l’internet public. Sans NAT IPv6 ou proxy transparent à la sortie du VPN, ça ne peut pas marcher. Peux-tu en dire plus sur ce VPN (perso ou fournisseur) ?

Les miroirs Debian dans sources.list sont-ils en [mono]ftp://[/mono] ou [mono]http://[/mono] ?[/quote]

Honnêtement je n’en ai aucune idée, mes connaissances en termes de réseaux sont très limitées pour ne pas dire nulles… (du moins tout ce qui est addressage…).
Oui bien sûr, je passe par un fournisseur VPN qui est HMA, et les miroirs Debian sont en ftp.

[code]gogi@GOGI:~$ cat /etc/apt/sources.list
#deb cdrom:[Debian GNU/Linux 7.1.0 Jessie - Official amd64 CD Binary-1 20150606-14:19]/ jessie main

EXPERIMENTAL

deb http://ftp.fr.debian.org/debian/ experimental main contrib non-free
#deb-src http://ftp.fr.debian.org/debian/ experimental main contrib non-free

UNSTABLE / SID

deb http://ftp.fr.debian.org/debian/ unstable main contrib non-free
#deb-src http://ftp.fr.debian.org/debian/ unstable main contrib non-free

TESTING / STRETCH

deb http://ftp.fr.debian.org/debian/ testing main contrib non-free
#deb-src http://ftp.fr.debian.org/debian/ testing main contrib non-free

deb http://security.debian.org/ testing/updates main contrib non-free
#deb-src http://security.debian.org/ testing/updates main contrib non-free

STABLE / JESSIE 8

deb http://ftp.fr.debian.org/debian/ stable main contrib non-free
#deb-src http://ftp.fr.debian.org/debian/ stable main contrib non-free

deb http://security.debian.org/ stable/updates main contrib non-free
#deb-src http://security.debian.org/ stable/updates main contrib non-free

JAVA 8

deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main
#deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main

PIPELIGHT

deb http://repos.fds-team.de/stable/debian/ unstable main
deb http://repos.fds-team.de/stable/debian/ testing main
deb http://repos.fds-team.de/stable/debian/ stable main[/code]

#7

Non, il sont en [mono]http://[/mono] dans ton sources.list. Ne te fie pas au nom des serveurs qui commence par “ftp.”.

Du coup l’accès aux sites en IPv6 via le VPN ne devrait pas fonctionner non plus. Aurais-tu désactivé l’IPv6 dans ton navigateur ? Que donne un wget sur une page d’un de ces sites ?

#8

[quote=“PascalHambourg”]Non, il sont en [mono]http://[/mono] dans ton sources.list. Ne te fie pas au nom des serveurs qui commence par “ftp.”.

Du coup l’accès aux sites en IPv6 via le VPN ne devrait pas fonctionner non plus. Aurais-tu désactivé l’IPv6 dans ton navigateur ? Que donne un wget sur une page d’un de ces sites ?[/quote]

Pardon, autant pour moi j’ai dit une bêtise, en effet ils sont en http… Je me suis fié au ftp derrière le http…

Quand tu parles d’accès aux sites via le VPN, tu fais référence à debian-fr.org et debian.org, ou bien par exemple un accès par le navigateur à l’un des sites de la sources.list?
De toute façon par le navigateur, j’ai accès à debian.org et debian-fr.org, et j’ai fait un test avec l’un des repo (ex : ftp.fr.debian.org/debian/) copié/collé dans le navigateur et ça marche aussi.

gogi@GOGI:~$ wget http://ftp.fr.debian.org/debian/ --2015-10-31 13:00:42-- http://ftp.fr.debian.org/debian/ Résolution de ftp.fr.debian.org (ftp.fr.debian.org)… 2a01:e0c:1:1598::2, 212.27.32.66 Connexion à ftp.fr.debian.org (ftp.fr.debian.org)|2a01:e0c:1:1598::2|:80…
Là c’est bloqué…

gogi@GOGI:~$ wget http://www.debian-fr.org --2015-10-31 13:01:42-- http://www.debian-fr.org/ Résolution de www.debian-fr.org (www.debian-fr.org)… 2400:cb00:2048:1::681c:d04, 2400:cb00:2048:1::681c:c04, 104.28.12.4, ... Connexion à www.debian-fr.org (www.debian-fr.org)|2400:cb00:2048:1::681c:d04|:80
Et là pareil…

Je n’ai rien désactivé dans mon navigateur, à moins que l’ IPv6 soit désactivée par défaut mais ça m’étonnerait, je tourne avec Iceweasel?

EDIT : j’ai vérifié dans about:config

#9

Je viens également de vérifier et comparer les paramètres de ma connexion Wifi simple avec le VPN, dans les deux IPv4 et IPv6 sont activées, et sont tous deux en automatique.

#10

Alors je ne sais pas ce que fait ton navigateur(time-out très court, connexion en IPv4 préférée, utilisation d’un proxy…) mais en tout cas ton VPN n’offre visiblement pas de connectivité IPv6. Je serais curieux de savoir si ce préfixe anormal est transmis par le fournisseur ou défini localement sur ta machine.

Vois si tu peux désactiver l’IPv6 dans les paramètres de connexion du VPN, mais sache que toute communication en IPv6 passera alors par le FAI. A voir si tu préfères cela ou pas de communication IPv6 du tout.

Edit : je suppose que tu préfèrerais que l’IPv4 soit utilisé en priorité, mais ce n’est pas si simple, par défaut c’est l’IPv6 qui est prioritaire. Il me semble qu’on peut le faire en modifiant les priorités dans /etc/gai.conf.

#11

Bonjour,

J’aimerais que tu puisses confirmer quelque-chose : Connecté au VPN, si tu utilises un site web pour te renvoyer ton adresse IP telle que vue par le site, l’adresse IPv6 est différente de celle allouée sur l’interface tun0 du tunnel VPN ?

Si oui, c’est un signe révélateur de NAT66, le NAT version IPv6.

D’ailleurs, en l’absence de NAT66 je ne m’imagine pas que l’IPv6 puisse fonctionner correctement avec ce VPN.

Tu peux obtenir cette adresses avec l’une des commmandes suivantes :

Ou encore en allant sur http://icanhazip.com/ avec ton navigateur.

–
AnonymousCoward

#12

Merci pour votre aide, je vais tester tout ça et je reviens vous donner la réponse. :wink:

#13

Bonsoir les amis :smiley:

Bon pour revenir au schmilblick, je vais reprendre depuis le début… :smiley:

Après vérifications, mon FAI (Free) fournit une connectivité IPv6, mais pas celui du VPN ça c’est confirmé (je t’avais répondu initialement oui mais je me suis trompé)

[quote=“PascalHambourg”]Non, il sont en [mono]http://[/mono] dans ton sources.list. Ne te fie pas au nom des serveurs qui commence par “ftp.”.

Du coup l’accès aux sites en IPv6 via le VPN ne devrait pas fonctionner non plus. Aurais-tu désactivé l’IPv6 dans ton navigateur?[/quote]
Comme je te l’avais dit auparavant, je peux accéder aux sites via Iceweasel, par contre impossible via le terminal pour la MàJ. J’ai poussé un peu les recherches, et j’ai trouvé ça dans Iceweasel / about:config :
[mono]network.http.fast-fallback-to-IPv4 “true”[/mono]
Est-ce que ça pourrait être la raison pour laquelle j’arrive à accéder aux sites via Iceweasel? Si j’ai bien compris cette clé permet de retomber sur de l’IPv4 (ou peut-être que je dis n’importe quoi…). L’accès IPv6 n’est pas désactivé en tous cas dans le navigateur, ni dans mes paramètres de connexion réseau.

[quote=“PascalHambourg”]Alors je ne sais pas ce que fait ton navigateur(time-out très court, connexion en IPv4 préférée, utilisation d’un proxy…) mais en tout cas ton VPN n’offre visiblement pas de connectivité IPv6. Je serais curieux de savoir si ce préfixe anormal est transmis par le fournisseur ou défini localement sur ta machine.

Vois si tu peux désactiver l’IPv6 dans les paramètres de connexion du VPN, mais sache que toute communication en IPv6 passera alors par le FAI. A voir si tu préfères cela ou pas de communication IPv6 du tout.

Edit : je suppose que tu préfèrerais que l’IPv4 soit utilisé en priorité, mais ce n’est pas si simple, par défaut c’est l’IPv6 qui est prioritaire. Il me semble qu’on peut le faire en modifiant les priorités dans /etc/gai.conf.[/quote]
Je peux désactiver l’IPv6 dans les paramètres des connexions VPN (je fonctionne avec OpenVPN donc il suffit de faire glisser un “slide” pour activer ou désactiver) mais quelles sont les conséquences concrètement : si j’ai compris ce que tu dis, tout ce qui est en IPv4 sera “filtré” par le VPN, en revanche les sites en IPv6 ne le seront pas c’est ça?
Et je t’avoue que modifier la priorité de l’un ou l’autre est pour moi pour l’instant encore hors de portée, je ne sais même pas concrètement la différence entre IPv4 et IPv6… :smiley: :smiley: :smiley: c’est pour te dire… D’où la question suivante : pourquoi serait-il préférable d’utiliser de l’IPv4?

[quote=“PascalHambourg”]D’où vient ce préfixe 2001:db8:123::/64 ? Le préfixe 2001:db8::/32 est réservé à la rédaction d’exemples et de documentations. Les adresses dans ce préfixe ne sont pas valides sur une machine et ne sont pas routées sur l’internet public. Sans NAT IPv6 ou proxy transparent à la sortie du VPN, ça ne peut pas marcher. Peux-tu en dire plus sur ce VPN (perso ou fournisseur) ?[/quote].
Là aussi si tu pouvais éclairer ma lanterne sur cette histoire de préfixes et à quoi ils correspondent/servent?

#14

[quote=“AnonymousCoward”]Bonjour,

J’aimerais que tu puisses confirmer quelque-chose : Connecté au VPN, si tu utilises un site web pour te renvoyer ton adresse IP telle que vue par le site, l’adresse IPv6 est différente de celle allouée sur l’interface tun0 du tunnel VPN ?

Si oui, c’est un signe révélateur de NAT66, le NAT version IPv6.

D’ailleurs, en l’absence de NAT66 je ne m’imagine pas que l’IPv6 puisse fonctionner correctement avec ce VPN.

Tu peux obtenir cette adresses avec l’une des commmandes suivantes :

Ou encore en allant sur http://icanhazip.com/ avec ton navigateur.

–
AnonymousCoward[/quote]

En effet c’est le cas, les IP sont différentes.
Sans utiliser les commandes que tu m’as donné, je suis passé par deux sites distincts (iplocation et ipv6-test) : les IP données par les deux sites sont les même, mais ne correspondent pas à celle que j’ai entré dans la config de ma connexion.

EDIT : j’ai essayé avec tes deux commandes, curl n’est pas installé chez moi donc ça passe pas, et avec wget ça bloque comme pour mes MàJ au premier post… Par contre par le navigateur ça marche.

#15

Alors pourquoi diable l’interface tun du VPN se retrouve-t-elle affublée de cette adresse IPv6 bidon ? Je ne vois qu’un défaut de configuration côté client (qui force cette adresse bidon s’il n’en reçoit pas) ou serveur VPN (qui envoie cette adresse bidon).

[quote=“GOGI”]J’ai poussé un peu les recherches, et j’ai trouvé ça dans Iceweasel / about:config :
network.http.fast-fallback-to-IPv4 "true"
Est-ce que ça pourrait être la raison pour laquelle j’arrive à accéder aux sites via Iceweasel?[/quote]
D’après son libellé, cette option pourrait bien correspondre à mon hypothèse du time-out très court.

Le VPN ne filtre rien en lui-même, c’est juste un tuyau. S’il ne modifie pas la route IPv6 par défaut, les communications en IPv6 continueront à sortie par le FAI. La conséquence dépend de l’objectif de ce VPN. Si le but est de masquer toutes les communications, c’est raté car les communications avec tout serveur accessible en IPv6 ne passeront pas par le VPN mais par le FAI.

Voir ci-dessus : parce que seul l’IPv4 passe par le VPN.

#16

Comment pourrais-je vérifier s’il s’agit du côté client ou serveur?
voici le lien qui confirme mes dires au sujet du fournisseur : https://support.hidemyass.com/hc/en-us/articles/202721936-Does-HMA-VPN-support-IPv6-yet-When-connected-to-HMA-VPN-I-have-IPv6-connections-do-they-run-encrypted-and-secure-through-the-VPN-connection-

[quote=“PascalHambourg”][quote=“GOGI”]J’ai poussé un peu les recherches, et j’ai trouvé ça dans Iceweasel / about:config :
network.http.fast-fallback-to-IPv4 "true"
Est-ce que ça pourrait être la raison pour laquelle j’arrive à accéder aux sites via Iceweasel?[/quote]
D’après son libellé, cette option pourrait bien correspondre à mon hypothèse du time-out très court.[/quote]
Oui d’après les infos que j’ai pu glaner, cette option permet de retomber sur de l’IPv4 (je ne sais pas si c’est l’expression appropriée, autant pour mon ignorance) en 1sec ou moins…

Oui pardon pour le filtrage je ne m’exprime pas avec les termes exacts parfois, je pensais aussi au tunnel. En gros si j’ai bien compris, soit le VPN modifie la route IPv6 à l’entrée et à ce moment les données passent par le tunnel, sinon elles passent “à côté” du tunnel… :smiley: et donc dans ce cas pas de tunnel pour tout ce qui est en IPv6…
Est-ce que tu connais par exemple un site en IPv6 sur lequel je pourrais vérifier mon adresse IP telle qu’il la voit, pour voir ce que ça donne?

Voir ci-dessus : parce que seul l’IPv4 passe par le VPN.[/quote]
Ah ok, je pensais qu’il y avait peut-être aussi une question de sécurité derrière pour laquelle l’IPv4 était préférable à l’IPv6…

#17

Dans les logs d’openvpn, je dirais.

whatismyipv6 (.com ou .net, je ne sais plus), et bien d’autres qui remontent dans un moteur de recherche avec ce mot-clé (test-ipv6.com, ismyipv6working.com…)

#18

Cela a l’air d’un problème intéressant.

Cet été, des chercheurs en sécurité ont dénoncé des failles/fuites d’informations dans les offres des fournisseurs de VPN dont HideMyAss. - worlds best vpns fall flat in security tests

Depuis, HMA aurait annoncé avoir réglé le soucis au niveau de l’IPv6. Cela demanderait à être confirmé.

Il faudrait que je fasse l’effort de me payer 1 mois de leur offre, pour comprendre comment elle marche et si elle fonctionne bien. Peut-être un jour.

–
AnonymousCoward

#19

Si c’est en utilisant un préfixe IPv6 non routable qu’ils ont “réglé le souci au niveau IPv6”, avec les conséquences opérationnelles que l’on sait, ce n’est pas bien joli…

#20

Bah oui que je suis con… J’ai déjà flirté sur test-IPv6 en plus, bref…

Sinon pour revenir à ta dernière remarque sur l’IPv6, quelles sont les conséquences opérationelles de ce genre de bidouilles?

EDIT : au cas où l’image ne se voit pas bien je l’ai chargée sur imgur : http://imgur.com/RWl4bB1