[quote=“AnonymousCoward”]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.
Tu les as subies avec [mono]apt-get[/mono],[mono]wget[/mono]… bref tous les programmes qui n’ont pas un repli rapide en IPv4.
Ils auraient pu au moins avoir le bon goût de renvoyer un ICMPv6 unreachable ou TCP RST pour raccourcir le délai.
[quote=“PascalHambourg”]Tu les as subies avec apt-get, wget… bref tous les programmes qui n’ont pas un repli rapide en IPv4.
Ils auraient pu au moins avoir le bon goût de renvoyer un [mono]ICMPv6 unreachable ou TCP RST[/mono] pour raccourcir le délai.[/quote]
Ok je comprends mieux maintenant, bon somme toute c’est pas si grave au final pour la MàJ, je deconnecte le VPN la machine fait le boulot et je reconnecte… Par contre pour wget ça peut être plus embêtant…
Par contre pour ICMPv6 unreachable et TCP RST pardonnes mon ignorance mais qu’apporteraient ces fonctions? ( en faisant court bien sûr)
Et deuxième chose puisqu’on y est, est-ce qu’il pourrait aussi y avoir une histoire de protocole TCP/UDP? Sachant que pour les systèmes Linux il n’y a pas de logiciels tout faits comme pour Windows ou Mac, on passe par openvpn, et le fournisseur de VPN fournit un tar.gz contenant les fichiers de config pour chaque adresse IP (les clés ainsi que les fichiers de config TCP et UDP).
Sachant que l’on ne peut pas utiliser les deux à la fois (TCP ou UDP), j’ai toujours choisi TCP ayant cru comprendre que c’était meilleur au niveau sécurité du protocole? Peut-être que je me trompe? Et est-ce que ça pourrait aussi avoir quelque chose avec notre souci?
Par rapport à la photo du site test-ipv6, voici ce que l’on ne peut pas voir en placant le curseur de la souris sur les points d’interrogation à droite :
Browser
Default IPv4 : Protocol selected by your browser when a site is reachable by both IPv4 and IPv6
Fallback No : Whether or not your browser falls back to the other protocol if its default above doesn"t work
En gros en passant par VPN, le navigateur se comporte complètement à l’inverse de son comportement avec une connexion classique (par le FAI je suis en default IPv6 et le fallback est activé.)
DNS
DNS4 + IP6 Unreachable : Connectivity to an IPv6 address served by an IPv4-only name server
DNS6 + IP4 Reachable : Connectivity to an IPv4 adddress served by an IPv6-only name server
DNS6 + IP6 Unreachable : Connectivity to an IPv6 address served by an IPv6-only name server
Pour résumer, pas de connectivité vers IPv6, que ce soit servi par un serveur uniquement en IPv4 ou uniquement IPv6?
Par contre connectivité en IPv4 par serveur fourni en IPv6, ce qui rejoint ce qui est dit plus haut c’est ça?
Je pense que tous les résultats du test sont induits par l’absence de connectivité globale IPv6 effective lorsque le VPN est monté, et que si tu désactives l’option IPv6 dans les paramètres d’OpenVPN, la connectivité IPv6 via le FAI sera rétablie et les résultats seront totalement différents.
Une réponse immédiate signalant que la destination est injoignable, évitant le délai avant tentative avec l’adresse suivante.
En parlant de config, ces fichiers contiennent-ils une mention du préfixe 2001:db8 ?
Ce serait un peu long à expliquer en détail mais le transport par TCP n’est pas idéal pour un VPN à cause de ses caractéristiques intrinsèques : TCP est conçu pour transmettre un flux séquentiel dans l’ordre et sans perte, alors qu’un VPN sert à transmettre des paquets individuels. En cas de perte de paquets ou de transmission dans le désordre, TCP peut causer une grosse diminution de performance. Le transport par UDP est préférable, TCP ne doit être choisi que lorsque UDP ne passe pas (par exemple bloqué par un pare-feu).
Ah ok, donc UDP est préférable à TCP? Il m’avait semblé comprendre que TCP contrairement à UDP était “bidirectionnel” dans le sens où quand tu parles de transmission sans perte TCP était capable de demander le renvoi de ce qui a été perdu contrairement à UDP qui lui est unidirectionnel, donc sans doute meilleure performances mais risques de pertes de data en chemin non?
Peux-tu vérifier l’effet du commutateur IPv6 du VPN avec [mono]ip -6 addr[/mono] et [mono]ip -6 route[/mono] ?
J’avais dit que c’était un peu compliqué à expliquer. Au contraire d’UDP qui est un service de datagramme, TCP est un service de “flot” (stream) et assure la remise dans l’ordre et la retransmission des segments non reçus. Et c’est bien ce qui pose problème pour un VPN, car attendre un segment arrivé en retard (pas reçu dans l’ordre) ou sa retransmission s’il est perdu bloque tous les segments suivants. Un réseau IP n’a pas besoin de ces services, puisque c’est la couche de transport au dessus qui s’en charge si nécessaire. Deux effets de bord se produisent :
les temporisations de la couche TCP qui transporte le VPN et des protocoles transportés dans le VPN se combinent, ce qui peut augmenter le délai et le taux de retransmission ;
la perte ou le retard d’un segment de la connexion TCP qui transporte le VPN bloque le traitement par le récepteur de tous les paquets suivants jusqu’à ce qu’il soit retransmis et/ou reçus ; or cela affecte toutes les communications transportées par le VPN, pas seulement celle à laquelle appartient le paquet perdu. Imagine : tu as plusieurs téléchargements en cours, et la perte d’un paquet sur un des téléchargements bloque tous les autres tant que ce paquet n’est pas retransmis. Pire : cela bloque aussi toutes les sessions interactives en cours (SSH, jeux en ligne, VoIP…). Ce n’est pas souhaitable.
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:6064:711:e543:a990/64 scope global temporary dynamic
valid_lft 86372sec preferred_lft 85522sec
inet6 2a01:e35:139c:b160:227:10ff:fe83:d69c/64 scope global mngtmpaddr noprefixroute dynamic
valid_lft 86372sec preferred_lft 86372sec
inet6 fe80::227:10ff:fe83:d69c/64 scope link
valid_lft forever preferred_lft forever
10: 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 86282sec 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
Le commutateur est sur off actuellement, donc aucun effet apparemment.
[quote=“PascalHambourg”]J’avais dit que c’était un peu compliqué à expliquer. Au contraire d’UDP qui est un service de datagramme, TCP est un service de “flot” (stream) et assure la remise dans l’ordre et la retransmission des segments non reçus. Et c’est bien ce qui pose problème pour un VPN, car attendre un segment arrivé en retard (pas reçu dans l’ordre) ou sa retransmission s’il est perdu bloque tous les segments suivants. Un réseau IP n’a pas besoin de ces services, puisque c’est la couche de transport au dessus qui s’en charge si nécessaire. Deux effets de bord se produisent :
les temporisations de la couche TCP qui transporte le VPN et des protocoles transportés dans le VPN se combinent, ce qui peut augmenter le délai et le taux de retransmission ;
la perte ou le retard d’un segment de la connexion TCP qui transporte le VPN bloque le traitement par le récepteur de tous les paquets suivants jusqu’à ce qu’il soit retransmis et/ou reçus ; or cela affecte toutes les communications transportées par le VPN, pas seulement celle à laquelle appartient le paquet perdu. Imagine : tu as plusieurs téléchargements en cours, et la perte d’un paquet sur un des téléchargements bloque tous les autres tant que ce paquet n’est pas retransmis. Pire : cela bloque aussi toutes les sessions interactives en cours (SSH, jeux en ligne, VoIP…). Ce n’est pas souhaitable.[/quote]
Ok je comprends bien maintenant, mais peux-tu m’expliquer en faisant court, en vulgarisant, car je comprends que c’est pas si simple à expliquer, quel sont les effets de bord à l’inverse avec une connexion UDP? Lorsqu’il y a perte d’un paquet par exemple je présume qu’à l’inverse une connexion UDP ne bloque pas tout le reste, mais qu’en est-il par exemple d’un téléchargement en cours? Faudrait-il alors reprendre tout le téléchargement?
Il n’y a pas d’effet de bord de ce type avec le transport d’un VPN en UDP puisque chaque datagramme UDP est indépendant. Un datagramme UDP perdu n’aura d’impact que sur la connexion interne au VPN à laquelle appartient le paquet transporté par ce datagramme, exactement comme dans le cas d’un paquet IP perdu.
Le protocole UDP n’est néanmoins pas exempt d’inconvénients, c’est pourquoi le transport en TCP est disponible.
UDP est sujet à la fragmentation (gérée par la couche IP) lorsque la taille des données à transporter dépasse la taille maximum d’un paquet, alors que TCP dispose de la segmentation (gérée directement par la couche TCP).
UDP est plus souvent bloqué par les pare-feux et plus difficile à faire relayer par un proxy ; il faut un proxy SOCKS 5, les proxys SOCKS 4 et HTTP (plus répandus), les relais de port SSH n’en sont pas capables.
Contrairement à TCP, UDP n’a pas de notion stricte d’état de connexion puisque c’est un protocole dit “non connecté”. Cela peut poser des difficultés pour son traitement par les pare-feux à état et systèmes NAT. C’est le protocole applicatif transporté pa UDP qui lui donne éventuellement un caractère “à état” ou “connecté”.
UDP peut aussi poser problème avec le “multihoming” (fait d’avoir plusieurs interfaces ou adresses IP). Par défaut un paquet émis en UDP a comme adresse source l’adresse de l’interface de sortie. Donc si un hôte reçoit un paquet sur l’interface I1 avec l’adresse A1 mais répond par l’interface I2, le paquet de réponse sera émis par défaut avec l’adresse source A2, ce qui peut perturber à la fois les pare-feu et systèmes NAT en chemin et le destinataire de la réponse. En TCP, l’adresse source est fixée à l’établissement de la connexion et ne change pas. Là encore, c’est au protocole applicatif de faire en sorte que UDP ressemble à TCP sur ce point.
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
(je réponds un peu à la bourre, désolé)
2001:db8:123::1 n’est clairement pas une IPv6 routable, tu ne pourras jamais avoir de la connecitvité avec cette configuration. Je te conseille de changer de fournisseur de VPN au plus vite
2001:db8::/32 est un range prévu pour la doc : tools.ietf.org/html/rfc3849
D’ailleurs, elle n’est pas annoncée en BGP (ce qui est logique) :
nominoe# show ipv6 route 2001:db8:123::1
Routing entry for ::/0
Known via "kernel", distance 0, metric 0, best
* 2001:978:2:4e::5:1, via em0
On voit qu’elle matche la route par défaut du routeur. Du coup la route s’arrête bien vite :
alarig@nominoe:~ % traceroute6 2001:db8:123::1
traceroute6 to 2001:db8:123::1 (2001:db8:123::1) from 2001:978:2:4e::5:2, 64 hops max, 12 byte packets
1 2001:978:2:4e::5:1 1.346 ms 1.569 ms 1.255 ms
2 te0-0-2-2.rcr11.cfr01.atlas.cogentco.com 3.728 ms 3.764 ms 3.610 ms
3 te0-0-2-2.rcr11.uro01.atlas.cogentco.com 8.491 ms !N 6.134 ms !N 5.877 ms !N
Petite promo au passage, grifon propose des VPN qui fonctionnent parfaitement (je sors par un des ces VPN à l’instant) : grifon.fr/services/VPN.html
Me revoilà, j’ai fait un peu de lecture pour essayer de comprendre mieux tout ça avant de venir répondre.
[quote=“PascalHambourg”]Le protocole UDP n’est néanmoins pas exempt d’inconvénients, c’est pourquoi le transport en TCP est disponible.
UDP est sujet à la fragmentation (gérée par la couche IP) lorsque la taille des données à transporter dépasse la taille maximum d’un paquet, alors que TCP dispose de la segmentation (gérée directement par la couche TCP).[/quote]
D’après ce que j’ai compris, un VPN repose déjà sur une couche TCP, dans ce cas même si les paquets sont transmis à l’intérieur en UDP, le TCP ne va t-il pas faire un contrôle d’intégrité à la sortie du tunnel par rapport à l’entrée et le cas échéant demander un renvoi de paquets?
Ça pose problème pour un accès machine à distance si je comprends bien, ou alors l’accès internet dans certains pays…?
Sachant que je suis derrière une Freebox (NAT) est-ce que je peux rencontrer par conséquent des soucis, ou bien pour mes machines virtuelles sous VirtualBox qui un connexion par pont de type NAT avec l’hôte?
Ça je ne pense pas être dans ce cas là étant donné que j’ai attribué une IP fixe à ma machine. Néanmoins je reposerai la même remarque que j’ai faite pour la question n°1 sur VPN/TCP - transport/UDP?
Enfin, en cherchant sur le net, j’ai finalement décidé de désactiver IPv6 sur ma machine car il n’y a quasiment aucun VPN qui fournisse de l’IPv6 (il y en a mais…). Petite parenthèse pour ceux qui passeront par là, il faut intervenir sur le fichier [mono]/etc/sysctl/conf[/mono] comme suit :
[code]# Désactivation de ipv6 pour toutes les interfaces
net.ipv6.conf.all.disable_ipv6 = 1
Désactivation de l’auto configuration pour toutes les interfaces
net.ipv6.conf.all.autoconf = 0
Désactivation de ipv6 pour les nouvelles interfaces (ex:si ajout de carte réseau)
net.ipv6.conf.default.disable_ipv6 = 1
Désactivation de l’auto configuration pour les nouvelles interfaces
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.lo.disable_ipv6 = 1[/code]
Pour ceux qui sont derrière une Freebox comme moi, pour être sûr du coup à 100% il faut aussi désactiver IPv6 dans l’interface Freebox sur votre compte.
Pour conclure, pour l’instant je n’ai pas de souci sans IPv6 mais je pense que je n’arriverai pas à accéder par exemple à un site qui ne fait que de l’IPv6 stricte c’est bien ça? (en même temps ça doit pas encore courir la toile…).
J’ai refait un test avec wget en console vers ftp.fr.debian.org, et cette fois ça marche même avec VPN, peut-on alors en conclure que c’est cette adresse bidon fournie par le VPN qui était la cause du blocage? (peut-être vue comme une attaque étant donné qu’elle est bidon?).
J’ai également fait des tests avec des configs TCP et UDP pour le VPN : ils n’ont donné aucune différence de qualité de connexion tant entre eux qu’en comparaison avec ma connexion FAI (ping, down et up). Après tout ce que l’on vient de dire, me conseilles-tu de rester quand même en TCP ou bien de passer en UDP finalement?
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
(je réponds un peu à la bourre, désolé)
2001:db8:123::1 n’est clairement pas une IPv6 routable, tu ne pourras jamais avoir de la connecitvité avec cette configuration. Je te conseille de changer de fournisseur de VPN au plus vite
2001:db8::/32 est un range prévu pour la doc : tools.ietf.org/html/rfc3849
D’ailleurs, elle n’est pas annoncée en BGP (ce qui est logique) :
nominoe# show ipv6 route 2001:db8:123::1
Routing entry for ::/0
Known via "kernel", distance 0, metric 0, best
* 2001:978:2:4e::5:1, via em0
On voit qu’elle matche la route par défaut du routeur. Du coup la route s’arrête bien vite :
alarig@nominoe:~ % traceroute6 2001:db8:123::1
traceroute6 to 2001:db8:123::1 (2001:db8:123::1) from 2001:978:2:4e::5:2, 64 hops max, 12 byte packets
1 2001:978:2:4e::5:1 1.346 ms 1.569 ms 1.255 ms
2 te0-0-2-2.rcr11.cfr01.atlas.cogentco.com 3.728 ms 3.764 ms 3.610 ms
3 te0-0-2-2.rcr11.uro01.atlas.cogentco.com 8.491 ms !N 6.134 ms !N 5.877 ms !N
Petite promo au passage, grifon propose des VPN qui fonctionnent parfaitement (je sors par un des ces VPN à l’instant) : grifon.fr/services/VPN.html[/quote][/quote]
Merci pour ta participation et tes explications, mais je t’avoue que ce n’est pas encore de mon niveau ce genre de choses j’ai encore du chemin à faire dans la connaissance et la compréhension dans ce domaine.
Bravo, tu viens de revenir 20 ans en arrière.
Pour les VPN avec de l’IPv6, tu as tous ceux de la FFDN au moins : ffdn.org/fr/membres (il faut regarder ceux où c’est marqué VPN dessus)
Là où il suffisait de le désactiver juste pour ton interface VPN ou dans la configuration d’OpenVPN…
Détrompe toi, l’Amérique du Nord a écoulé son stock d’IPv4. Tous les nouveaux arrivant n’ont donc que de l’IPv6. Tu ne pourras donc pas accéder à ces sites.
C’est partiellement le cas en Asie aussi et ça arrive doucement en Europe également.
Oui. Elle n’est pas routable, donc le serveur en face a bien renvoyé une réponse, mais ça s’est arrêté au routeur BGP qui ne savait pas quoi en faire, et a donc dropé les paquets.
[quote=“GOGI”]
J’ai également fait des tests avec des configs TCP et UDP pour le VPN : ils n’ont donné aucune différence de qualité de connexion tant entre eux qu’en comparaison avec ma connexion FAI (ping, down et up). Après tout ce que l’on vient de dire, me conseilles-tu de rester quand même en TCP ou bien de passer en UDP finalement?[/quote]
Il faut éviter autant que possible de faire du TCP sur du TCP. Si tu as de la perte de paquet, tu vas sentir un sérieux ralentissement.
[quote=“GOGI”]
Merci pour ta participation et tes explications, mais je t’avoue que ce n’est pas encore de mon niveau ce genre de choses j’ai encore du chemin à faire dans la connaissance et la compréhension dans ce domaine. [/quote]
En gros, le réseau marche avec des routes. C’est comme le réseau routier en voiture, tu as des routes et des panneaux. À chaque carrefour, ils te disent où aller.
Pour discuter sur Internet, il te faut une IP (par exemple la mienne est 2a01:240:fe00:82af:b317:afbe:1cf9:264a). Elle sert au serveur qui lui parle et donc qui répond.
Parmi ces IPs, il y en a qui sont réservées¹ (par exemple pour le link-local, pour la boucle local, pour le multicast, pour Teredo, etc.).
En voiture, c’est assez facile de dire aux gens où aller, un patelin ne va pas pousser au milieu de nulle part du jour au lendemain.
Sur Internet, c’est un peu différent, il y a du monde qui arrive tous les jours. Ainsi, les blocs d’IPs sont annoncés via BGP.
Comme ton IPv6 est réservée à la documentation, elle n’est pas annoncée en BGP. Il est donc impossible de la joindre.
C’est ce que je disais plus haut, ça ne suffit pas, ça ne fonctionne pas.
[quote=“SwordArMor”][quote=“GOGI”]Pour conclure, pour l’instant je n’ai pas de souci sans IPv6 mais je pense que je n’arriverai pas à accéder par exemple à un site qui ne fait que de l’IPv6 stricte c’est bien ça? (en même temps ça doit pas encore courir la toile…).
[/quote]
Détrompe toi, l’Amérique du Nord a écoulé son stock d’IPv4. Tous les nouveaux arrivant n’ont donc que de l’IPv6. Tu ne pourras donc pas accéder à ces sites.
C’est partiellement le cas en Asie aussi et ça arrive doucement en Europe également.[/quote]
Ça ne concerne donc que les nouveaux sites? Je suis conscient de ce que tu dis mais bon pour l’instant je n’ai pas ce besoin d’accès, du moins je ne l’ai pas encore rencontré. Mais en gros je n’aurai pas accès à un site en IPv6 stricte…?
Néanmoins je suis bien conscient de ce que tu me dis, et en espérant que les principaux fournisseurs de VPN fournissent bientôt un accès qui couvre aussi l’IPv6, je repasserai aussitôt en IPv6, sous réserve que ce soit stable et sans fuites bien sûr.
[quote=“SwordArMor”][quote=“GOGI”]
J’ai également fait des tests avec des configs TCP et UDP pour le VPN : ils n’ont donné aucune différence de qualité de connexion tant entre eux qu’en comparaison avec ma connexion FAI (ping, down et up). Après tout ce que l’on vient de dire, me conseilles-tu de rester quand même en TCP ou bien de passer en UDP finalement?[/quote]
Il faut éviter autant que possible de faire du TCP sur du TCP. Si tu as de la perte de paquet, tu vas sentir un sérieux ralentissement.[/quote]
C’est bien ce que j’ai cru comprendre en effet, tu me confirmes donc. Pourtant avec l’application que j’utilise sous VPN (je ne parle pas là des tests que j’ai effectué sur la qualité de mes connexions), j’ai un indicateur d’état de connexion en temps réel, et parfois lorsqu’il y a perte (c’est très rare mais ça arrive) l’indicateur passe au rouge, eh bien avec quelques essais j’ai l’impression que ça passe plus de fois au rouge avec UDP qu’avec TCP, va comprendre… (constatation visuelle seulement)
[quote=“SwordArMor”][quote=“GOGI”]
Merci pour ta participation et tes explications, mais je t’avoue que ce n’est pas encore de mon niveau ce genre de choses j’ai encore du chemin à faire dans la connaissance et la compréhension dans ce domaine. [/quote]
En gros, le réseau marche avec des routes. C’est comme le réseau routier en voiture, tu as des routes et des panneaux. À chaque carrefour, ils te disent où aller.
Pour discuter sur Internet, il te faut une IP (par exemple la mienne est 2a01:240:fe00:82af:b317:afbe:1cf9:264a). Elle sert au serveur qui lui parle et donc qui répond.
Parmi ces IPs, il y en a qui sont réservées¹ (par exemple pour le link-local, pour la boucle local, pour le multicast, pour Teredo, etc.).
En voiture, c’est assez facile de dire aux gens où aller, un patelin ne va pas pousser au milieu de nulle part du jour au lendemain.
Sur Internet, c’est un peu différent, il y a du monde qui arrive tous les jours. Ainsi, les blocs d’IPs sont annoncés via BGP.
Comme ton IPv6 est réservée à la documentation, elle n’est pas annoncée en BGP. Il est donc impossible de la joindre.
Ainsi, le serveur ne savait pas te répondre.
[1] en.wikipedia.org/wiki/Reserved_ … esses#IPv6[/quote]
Oui ça j’ai bien compris comment fonctionne internet, quand je dis que je suis encore novice dans ce domaine, je pense aux différents termes employés et ce à quoi ils renvoient, il me faut encore apprendre (boucle-locale, multicast, serveur…)
Si tu préfères je comprends le fonctionnement en général, mais si tu me demandes de configurer un réseau ou expliquer en détails comment fonctionne un réseau etc… Là je sors —>
C’est ce que je disais plus haut, ça ne suffit pas, ça ne fonctionne pas.
Je viens de regarder ta conf, à mon avis c’est le serveur qui te pousse et non toi qui les règlent dans ton fichier de conf. Du coup tu peux faire un petit script du genre vpn-up.sh avec dedans #!/bin/sh
ip -6 route del 2000::/3 via 2001:db8:123::1 dev tun0
Tu le rends exécutable et puis tu ajoutes la ligne [mono]up vpn-up.sh[/mono] avant tes certificats et clés.
Ça ne concerne donc que les nouveaux sites? Je suis conscient de ce que tu dis mais bon pour l’instant je n’ai pas ce besoin d’accès, du moins je ne l’ai pas encore rencontré. Mais en gros je n’aurai pas accès à un site en IPv6 stricte…?
Oui, c’est ça
[quote=“GOGI”]Oui ça j’ai bien compris comment fonctionne internet, quand je dis que je suis encore novice dans ce domaine, je pense aux différents termes employés et ce à quoi ils renvoient, il me faut encore apprendre (boucle-locale, multicast, serveur…)
Si tu préfères je comprends le fonctionnement en général, mais si tu me demandes de configurer un réseau ou expliquer en détails comment fonctionne un réseau etc… Là je sors —> [/quote][/quote]
Dans ce cas tu peux regarder les conférences de iletaitunefoisinternet.fr/, ça te donnera quelques pistes
Non. Cela dépend du protocole d’encapsulation. Un VPN peut utiliser les protocoles GRE (PPTP), UDP (OpenVPN, IPSec NAT-T), TCP (OpenVPN, SSH), AH/ESP (IPSec)…
Ça pose problème pour un accès machine à distance si je comprends bien, ou alors l’accès internet dans certains pays…?[/quote]
Cela ne pose pas de problème si on dispose d’une vraie connectivité IP complète. Par contre UDP risque d’être inutilisable si on n’a pas d’accès direct à internet et doit passer par un proxy (même transparent).
Si on doit passer par un dispositif NAT ou un pare-feu “à état” (stateful), UDP doit passer mais il y a des précautions à prendre : générer du trafic régulièrement (par exemple toutes les 30 secondes minimum) pour maintenir l’état de connexion dans le NAT ou le pare-feu, car les délais d’expiration pour absence de trafic sont plus courts en UDP qu’en TCP. Ce n’est pas spécifique à UDP mais à tous les protocoles “non connectés”. Cela peut être prévu dans l’implémentation du VPN via une fonction “keepalive”.
Comme l’a écrit SwordArMor, la différence se verra surtout en cas de pertes de paquets du VPN non négligeables.
Si tu as lu le fil attentivement, tu as vu que ce n’est pas si simple en passant par NetworkManager, le commutateur semble sans effet. Quant à l’interface tun, comme elle est créée dynamiquement lors de l’activation du VPN on ne peut pas la paramétrer au démarrage via /etc/sysctl.conf.
Tu es sûr ? Que l’ARIN ait alloué son dernier bloc ne veut pas dire que les organisations qui les ont reçus (et donc beaucoup sont des FAI ou FSI qui les redistribuent à leurs clients) les ont tous utilisés. Je doute fortement qu’il existe actuellement des sites autres que confidentiels qui soient accesibles uniquement en IPv6. Un exemple ?
Si tu as lu le fil attentivement, tu as vu que ce n’est pas si simple en passant par NetworkManager, le commutateur semble sans effet. Quant à l’interface tun, comme elle est créée dynamiquement lors de l’activation du VPN on ne peut pas la paramétrer au démarrage via /etc/sysctl.conf.
[/quote]
Même avec un sysctl $machin.disable=1 dans le script d’up du VPN ?
Tu es sûr ? Que l’ARIN ait alloué son dernier bloc ne veut pas dire que les organisations qui les ont reçus (et donc beaucoup sont des FAI ou FSI qui les redistribuent à leurs clients) les ont tous utilisés. Je doute fortement qu’il existe actuellement des sites autres que confidentiels qui soient accesibles uniquement en IPv6. Un exemple ?[/quote]
Là j’en ai pas sous la patte, j’ai toujours de l’IPv6 sous la main donc je ne fais pas gaffe. Mais si ça n’existe pas encore pour les sites « communs », ça veut dire que c’est très proche d’arriver. Donc autant anticiper.
Pour ma part, ça fait 10 ans que j’anticipe, et j’attends toujours de voir venir les sites, services ou applications pour lesquels l’IPv6 apportera un vrai plus. Par contre, des problèmes d’accès en IPv6 à des sites qui étaient par ailleurs parfaitement accessibles en IPv4, j’en ai vus…
Je n’ai pas écrit “impossible” mais “pas si simple”. S’il faut mettre les mains dans le cambouis d’openvpn, ce n’est pas vraiment dans la philosophie de l’utilisation du plug-in graphique pour NetworkManager.
PS : attention, tu as oublié une balise de citation.
j’ai encore du chemin à faire dans la connaissance et la compréhension dans ce domaine. 
j’ai encore du chemin à faire dans la connaissance et la compréhension dans ce domaine. 
[/quote]
