Utiliser Internet sans connexion IPv4

• Même en cas de coupure de la connectivité IPv4, il devient possible d’utiliser l’ensemble d’Internet grâce à IPv6, WireGuard et un VPS Hetzner
• À cause du Carrier Grade NAT (NAT à grande échelle), seule la couche IPv4 était en panne, tandis qu’IPv6 n’était pas affecté
• En configurant un tunnel WireGuard pour faire passer le trafic IPv4 via le VPS, l’environnement d’accès normal aux sites web a pu être rétabli
• L’article présente aussi l’usage des network namespaces et de Docker, ainsi que la manière de résoudre les problèmes de MTU
• Il met en avant l’expérience consistant à résoudre soi-même un problème réseau complexe grâce à Linux et aux outils open source

---

Aperçu

Il y a quelques jours, l’auteur a rencontré, après une panne de courant, un problème de perte d’accès IPv4 sur le routeur de son domicile. Heureusement, la connectivité IPv6 fonctionnait normalement, ce qui permettait encore d’accéder à certains sites (Google, Meta, etc.), mais la majorité des sites (comme GitHub) restaient inaccessibles. L’article récapitule donc la manière dont il a utilisé Linux, WireGuard et un VPS Hetzner pour restaurer un accès complet à Internet en s’appuyant uniquement sur IPv6.

Cause de la panne et contexte

Détection d’une anomalie dans l’environnement réseau

• Lors du rétablissement après la coupure de courant, il a constaté que les serveurs en IPv6 étaient joignables, tandis que les serveurs en IPv4 ne l’étaient pas
• Les commandes de diagnostic (ping -6, traceroute) ont elles aussi seulement mis en évidence une différence selon la version d’IP
• Après échange avec l’opérateur, il s’est avéré qu’un problème était survenu dans la couche CG-NAT (Carrier Grade NAT), chargée de la traduction IPv4
• Comme la remise en état côté FAI devait prendre plusieurs jours, il a fallu trouver une solution par ses propres moyens

Explication de NAT et du CG-NAT

• NAT (Network Address Translation) : mécanisme qui permet à plusieurs appareils de partager une seule adresse IPv4 publique
  • Le routeur remplace l’IP interne par une IP publique et un port unique pour gérer le trafic, puis restaure la destination interne grâce aux informations de correspondance lors du retour
  • Cette structure entraîne l’existence d’un pare-feu implicite et la nécessité du port forwarding
• CG-NAT (Carrier Grade NAT) : structure en couches dans laquelle le FAI applique une seconde couche de NAT aux routeurs domestiques
  • Le FAI empile ainsi les NAT en interne pour pallier la pénurie d’adresses IPv4
  • Dans un environnement CG-NAT, l’exposition de services, comme via le port forwarding, devient encore plus limitée
  • Si seule la couche IPv4 a été touchée, c’est précisément à cause d’un problème de traitement des paquets IPv4 à ce niveau

Les avantages d’IPv6

• L’espace d’adressage IPv6 est immensément plus grand, ce qui permet d’attribuer directement une adresse à chaque appareil sans NAT
  • La plupart des routeurs domestiques reçoivent un sous-réseau /64, permettant d’utiliser des billions d’adresses
• Comme aucun NAT supplémentaire n’est nécessaire, la communication directe est possible, mais la configuration du pare-feu devient d’autant plus importante
• Le CG-NAT ne s’appliquant qu’à IPv4, seul IPv6 continuait donc de fonctionner normalement dans ce cas
• En revanche, de nombreux serveurs (par exemple GitHub) restent encore inaccessibles en IPv6 seul

Restaurer IPv4 via un tunnel WireGuard

Vue d’ensemble de la mise en œuvre

• En utilisant un VPS Hetzner (compatible à la fois IPv4 et IPv6) et WireGuard, l’auteur a mis en place un environnement permettant un accès complet à Internet malgré une connexion disponible uniquement en IPv6
  • Le VPS héberge un serveur WireGuard et un tunnel est établi avec l’équipement client
  • Le trafic est redirigé vers le VPS via IPv6, puis sort sur Internet depuis ce VPS, permettant l’accès à l’ensemble des sites, y compris en IPv4
  • Le principe est proche de celui de Dual-Stack Lite

Exemples de configuration serveur et client

• Dans la configuration du serveur WireGuard, le trafic IPv4 et IPv6 est tous deux pris en charge
  • Des exemples de règles MASQUERADE (traduction dynamique d’IP) et SNAT (traduction d’IP fixe) sont fournis
  • Grâce à une IPv6 globale directement attribuée, la connexion des pairs WireGuard est possible sans NAT
  • Il est possible d’écrire plusieurs entrées PostUp/PostDown pour exécuter les commandes l’une après l’autre
• Exemples de configuration côté client
  • Présentation de combinaisons possibles avec une adresse IPv6 directement attribuée ou une ULA derrière NAT
  • L’application de 0.0.0.0/0, ::/0 dans AllowedIPs permet de faire passer tout le trafic dans le tunnel
  • L’article montre aussi comment définir les DNS Google (IPv4 et IPv6) ainsi que le MTU

Fonctionnement correct du tunnel

• Une fois la configuration WireGuard terminée des deux côtés, le tunneling IPv4/IPv6 fonctionne correctement
• La même méthode a aussi été appliquée au PC de son épouse, avec une installation simple du client WireGuard sous Linux
• En revanche, une connexion simultanée avec le VPN de l’entreprise n’est généralement pas possible, ce qui impose l’usage de network namespaces supplémentaires

Network namespaces et Docker

Fonctionnement et usages

• Avec des outils comme vopono, il est possible de créer des network namespaces par application et d’y affecter directement une interface VPN ou WireGuard
  • Il faut définir des règles MASQUERADE séparées pour forcer le trafic interne à passer par le tunnel WireGuard
  • Des conseils sont également donnés sur la configuration d’un DNS isolé pour l’extérieur et de gai.conf (préférence DNS pour IPv4)
• Des exemples montrent comment établir la connexion VPN et exécuter les applications à l’intérieur d’un namespace
  • Exécuter plusieurs services dans un même namespace permet d’éviter à l’avance les conflits réseau

Combinaison avec des conteneurs Docker

• Comme le démon Docker utilise par défaut le socket réseau de l’hôte, il n’est pas accessible via une simple exécution dans un namespace classique
  • L’article propose un contournement au moyen de techniques de virtualisation Unix comme le mount namespace ou le bind mount de /sys
  • En lançant dockerd dans le namespace et en lui assignant un socket et un répertoire de données distincts, il devient possible de rétablir la connectivité Internet dans les conteneurs
  • Il est également mentionné qu’un environnement de bridges réseau complexe peut nécessiter une configuration supplémentaire

Problèmes de MTU avec WireGuard (MTU : Maximum Transmission Unit)

• Après l’établissement de la connexion WireGuard, certains sites restaient inaccessibles (SSL, etc.) alors que ping répondait normalement
• Des tests ping avec différentes tailles ont permis d’identifier que le MTU était trop élevé, ce qui provoquait la perte des gros paquets en cours de route
  • En abaissant le MTU à 1280, le problème a été résolu immédiatement
• Le MTU correspond à la taille maximale d’un paquet pouvant être transmis en une seule fois
  • Il faut définir une valeur adaptée en tenant compte de l’overhead lié au tunnel et à l’encapsulation, faute de quoi la transmission de paquets volumineux peut échouer
  • En IPv6, le MTU minimal imposé par la norme est de 1280

Conclusion et conseils pratiques

• L’article insiste sur l’expérience de diagnostic et de résolution autonome d’un problème réseau en s’appuyant sur Linux et des outils open source : mise en place d’un serveur VPN WireGuard, gestion des network namespaces, configuration particulière de Docker, dépannage du MTU, etc.
• Des services comme les VPS Hetzner sont présentés comme stables au regard de leur prix et adaptés à l’exploitation de services réseau légitimes comme WireGuard
• Il invite aussi à reconsidérer la valeur des firmwares de routeur open source (OpenWRT) et des techniques de mise en réseau sous Linux
  • La souplesse offerte par la possibilité de gérer et modifier directement son réseau constitue un grand avantage dans un contexte de travail à distance
  • Avec suffisamment de compréhension et de pratique, il devient possible de résoudre soi-même même des pannes réseau complexes

Références

• Tailscale – How NAT Traversal Works
• ArchWiki – exemples de cas d’usage de WireGuard
• Unix StackExchange – astuces Docker dans un namespace
• AskUbuntu – configuration des priorités DNS

(pour les scripts, configurations, conseils et liens de référence, voir la source originale)

[GN⁺]

Commentaires sur Hacker News

• Le titre peut être légèrement trompeur, mais en réalité cet article se rapproche davantage de « se connecter à un VPS via un tunnel IPv6 pour accéder à l’Internet IPv4 », ce qu’on appelle souvent du 4in6
  Quoi qu’il en soit, c’est une approche intéressante
  Quand notre FAI a une panne sur IPv4, tout tombe immédiatement, donc le problème de support est relativement simple à identifier ; en revanche, quand la panne touche IPv6, cela se manifeste de façon partielle, avec des connexions lentes ou des coupures intermittentes, donc de manière plus étrange
  En particulier, si la passerelle croit à tort qu’elle dispose d’IPv6, du point de vue de l’utilisateur le problème devient encore plus pénible, avec seulement certaines fonctions qui cessent de marcher

  • La dernière fois qu’IPv4 a brièvement cessé de fonctionner, je ne m’en suis rendu compte que parce que GitHub ne marchait plus
    De nos jours, la plupart des sites web grand public fonctionnent normalement en IPv6
    En revanche, ceux dont le routeur ne fournit que du DNS IPv4 ont subi une coupure Internet totale
    J’aimerais que Microsoft y prête un peu plus attention
    Pour vérifier si IPv4 était revenu, il fallait aussi se souvenir du nom d’hôte mDNS attribué au routeur

  • Honnêtement, IPv4 est déjà tombé en panne chez moi, et ma femme ne s’en est même pas aperçue
    Google, Facebook, Apple/iCloud, et presque tous les services basés sur CloudFlare fonctionnent très bien en IPv6

  • Mon expérience est similaire
    Les problèmes IPv6 sont vraiment difficiles à diagnostiquer et à reproduire, et on en revient sans cesse à « chez moi ça marche »

  • La plupart des FAI bloquent encore IPv6, et même les petites entreprises essaient parfois IPv6 sans aller au bout, en oubliant par exemple les enregistrements AAAA
    Résultat, les utilisateurs se retrouvent avec des services qui marchent chez des amis ou dans un café, sur un FAI low cost, mais pas chez eux
    Cela peut paraître étrange, mais il ne semble pas y avoir de vraie bonne solution, donc en pratique on ne peut qu’espérer la disparition d’IPv4
    Il existe des techniques comme Happy Eyeballs (tenter IPv4 et IPv6 en parallèle et choisir le plus rapide), mais en pratique les problèmes surviennent davantage au niveau applicatif, et il manque une solution générale pour ça
    Dans mon cas, je fais un compromis en laissant IPv6 activé sur le réseau, tout en désactivant le DNS IPv6 dans le navigateur, mais ce n’est pas satisfaisant

• Si vous voulez essayer IPv6 mais que votre FAI ne le fournit pas, Hurricane Electric (HE) propose gratuitement un service de tunnel depuis très longtemps
  Quelques liens utiles : tunnelbroker.net, ipv6.he.net, configuration Fedora, blog de Brandon Rozek, configuration DD-WRT, script de mise à jour automatique sur le forum Mikrotik, guide RockyLinux proposent différentes méthodes d’installation

  • Un point à noter : de nombreux services de streaming bloquent ce tunnel, en le considérant comme une forme de contournement VPN, notamment à cause des restrictions géographiques sur les contenus
    Cela dit, grâce à la fonction RA (Router Advertisement), n’importe quel équipement réseau peut diffuser un réseau IPv6 en /64, ce qui permet à plusieurs appareils du réseau d’utiliser des adresses IPv6 même si le routeur ne prend pas directement en charge le tunnel HE (à condition que le routeur ne filtre pas les RA pour des raisons de sécurité)
    C’est extrêmement pratique quand on veut héberger quelque chose chez soi sans avoir à faire de redirection de port, uniquement avec IPv6

  • Le service de Hurricane Electric est bon, mais maintenant que de plus en plus de FAI fournissent IPv6 par défaut, les utilisateurs grand public délaissent progressivement les services de tunnel
    Et comme certains services réseau se sont mis à bloquer les tunnels he.net en les associant à des abus ou à des usages malveillants, j’ai fini par devoir désactiver l’usage d’IPv6 sur la majeure partie de mon réseau

  • À noter : les tunnels Hurricane Electric nécessitent impérativement une adresse IPv4 publique fournie par le FAI pour fonctionner
    Si vous êtes derrière un NAT, par exemple avec du carrier-grade NAT, il faut chercher une autre solution pour apporter IPv6 à la maison

  • Je suis « client » du tunnel gratuit 6in4 de HE sur OpenBSD depuis 5 ans
    Cela fonctionne de façon fiable avec une simple configuration réseau, par exemple via /etc/hostname.gif0
    Je l’utilise aussi pour communiquer avec un cluster de VPS configuré volontairement sans IPv4 sur AWS
    Comme AWS facture activement les adresses IPv4, je trouve que cette approche aide énormément à réduire les coûts

• Si vous êtes vraiment dans un environnement v6 only et que vous avez besoin d’accéder à du v4, utiliser une passerelle publique DNS64+NAT64 est une solution simple
  Voir la liste des providers publics de nat64.net
  En général, il suffit de changer de serveur DNS
  DNS64 synthétise des enregistrements AAAA pour les sites qui n’en ont pas, afin qu’ils puissent être atteints via une box NAT64
  NAT64 reçoit ensuite le trafic et effectue la conversion de protocole + le NAT
  On peut d’ailleurs se connecter immédiatement à des sites comme GitHub avec des commandes d’exemple utilisant dig ou curl

  • En Europe, utiliser directement nat64.net reste tout à fait confortable
    Je n’ai eu que de bonnes expériences avec ce service

  • Avec Cloudflare WARP, on ressent des débits nettement meilleurs
    WARP permet aussi d’accéder directement aux adresses IPv4

• Je trouve toujours étonnant qu’il existe des utilisateurs en IPv6-only
  À l’époque, pour le cas inverse (environnement IPv4-only avec besoin d’accès IPv6), si on avait un contrôle total sur le serveur, la meilleure solution rapide était d’utiliser un proxy SOCKS5 via l’option ssh -D
  Il suffisait ensuite de configurer uniquement le navigateur pour utiliser ce proxy socks
  Le faire à l’échelle du système entier peut au contraire casser la connexion ssh, et c’est ce qui m’inquiète

• Je suis dans une situation similaire
  Un ticket lié à une panne IPv4 est ouvert depuis environ deux semaines, et on me répond simplement qu’« un technicien va bientôt s’en occuper »
  Comme IPv6 fonctionne, cela ne semble pas être considéré comme une panne totale
  En Allemagne, il existe des règles de compensation pour les consommateurs dans ce genre de cas, et je vais vérifier si elles s’appliquent ici
  Le problème de l’approche proposée dans l’article de blog, c’est que les plages d’IP de datacenter sont bloquées par beaucoup de services, ou bien soumises à des CAPTCHA et autres mesures de contournement, comme les IP de fournisseurs VPN, et il n’y a pas vraiment moyen de l’éviter
  Dans mon cas, il fallait résoudre ça pour toute la maison, donc j’ai mis en place du routage et des règles NAT en Wireguard sur le routeur ; heureusement c’était un équipement ouvert comme un Ubiquiti EdgeRouter
  Avec une FritzBox, cela aurait probablement été bien plus difficile
  En revanche, le routeur manque un peu de puissance et ralentit quand le nombre de connexions augmente ; je réfléchis donc à passer à IPSec avec support de l’offloading matériel

  • FritzBox propose aussi un excellent processus de configuration via l’interface graphique pour les connexions VPN
    L’hypothèse de départ est FritzBox vers FritzBox, mais tout VPN compatible fonctionne
    Il y a aussi la configuration de routes fixes IPv4/IPv6
    Le plus gros problème est de savoir quels paramètres de chiffrement IPSec sont exigés en face ; Wireguard est plus simple, mais à l’inverse pose le problème de l’accélération matérielle
    Si nécessaire, on peut aussi sauvegarder toute la configuration FritzBox, l’éditer à la main, recalculer la somme de contrôle puis la réinjecter
    AVM cache une énorme quantité de paramètres avancés qui ne sont pas exposés à l’utilisateur, de manière délibérée
    C’est aussi une façon de rendre les choses un peu plus difficiles pour éviter que quelqu’un ne casse son routeur par erreur

  • Je ne connais pas bien la situation en Allemagne, mais aux Pays-Bas, si l’on utilise le même FAI pour l’Internet fixe et mobile, on peut demander des données mobiles gratuites en cas de panne sur le réseau filaire
    Si c’est possible, je recommande de demander à votre FAI si cette option existe

• Même après tout ce temps, je n’ai toujours pas trouvé de raison claire de migrer tout mon équipement et mon homelab vers IPv6
  La redirection de ports et les règles de firewall me paraissent encore relativement intuitives, alors qu’en passant à IPv6 je m’attends à plusieurs semaines de dépannage, de réglages firewall et de reconfiguration des adresses
  Je me demande ce que je rate

  • En pratique, à ce stade, vous ne ratez presque rien
    À l’avenir, si des grands acteurs comme Google ou Cloudflare ne peuvent plus absorber le coût croissant des adresses IPv4, ils pourraient commencer à inciter davantage à l’usage d’IPv6, par exemple en limitant le débit des connexions IPv4
    AWS aussi : avant, seuls les Elastic IP IPv4 inutilisés étaient facturés, alors qu’aujourd’hui ils sont facturés même lorsqu’ils sont utilisés
    Quand vous changerez de passerelle ou de routeur, le mieux sera sans doute d’activer simplement IPv6 ; pour l’instant, en dual stack IPv4/IPv6, les équipements et services existants continuent de fonctionner sans problème
    Pour l’attribution automatique d’adresses IPv6, l’histoire a longtemps été confuse, mais tout semble converger vers SLAAC, tandis que côté FAI, DHCPv6 restera probablement en usage encore longtemps

  • En réalité, ce n’est pas si compliqué
    Si votre réseau domestique n’est pas particulièrement complexe, il suffit de consacrer un petit moment en soirée à configurer IPv6
    Chez Comcast, il suffit d’activer l’option IPv6 sur le routeur pour que le FAI fournisse un prefix, qui est ensuite annoncé automatiquement sur le réseau ; il ne reste plus qu’à ouvrir au firewall les ports voulus

  • Vous ne ratez rien
    En environnement enterprise, les inconvénients et la complexité d’IPv6 l’emportent souvent sur ses avantages
    Je gère environ 3 500 équipements, 7 bâtiments, 2 liens WAN à 10 Gbps, 1 lien WAN à 4 Gbps, et 26 adresses IPv4 publiques
    Jusqu’ici, il n’y a jamais eu la moindre raison qui m’oblige à utiliser IPv6
    Exploiter le réseau en dual stack ajoute une charge et une complexité inutiles
    J’ai même récemment tenté à deux reprises d’obtenir un bloc d’adresses IPv6 statiques, et on me l’a refusé à chaque fois
    En pratique, il n’y a aucun gain réel, et il est même difficile d’en obtenir l’allocation
    Si l’on regarde le guide ARIN pour une première demande IPv6,
    → disposer d’une allocation IPv4
    → prévoir immédiatement du multihoming IPv6
    → avoir 13 sites finaux (bureaux, etc.) dans l’année
    → avoir 2 000 adresses IPv6 dans l’année
    → avoir 200 sous-réseaux /64 dans l’année
    il faut remplir au moins une de ces conditions pour être éligible

• J’apprécie énormément la règle de l’Apple App Store qui exige que toutes les apps fonctionnent sur des réseaux IPv6-only
  En tant que développeur, cela peut surprendre au début, mais du point de vue du consommateur, ce genre d’exigence est très bienvenu

  • Mais cette politique n’impose pas au serveur de posséder lui-même une adresse IPv6

  • Dans ce cas, je me demande si GitHub est accessible en v6 depuis l’app

• Dans le cadre du travail, nous exploitons plusieurs VPN IPv6 only pour accéder à l’infrastructure interne
  Le principal problème est que les clients Windows et macOS exigent absolument un serveur DNS en v6
  Comme les clients peuvent se trouver ou non sur un réseau compatible v6, nous faisons tourner directement un serveur DNS dans le VPN et nous le poussons automatiquement aux clients
  Mais quand la connexion VPN tombe, l’application Wireguard ne restaure pas toujours le DNS d’origine, ce qui provoque divers problèmes

  • J’ai déjà utilisé IPv6-only sans DNS séparé, même sur un réseau IPv4 only de FAI et sous macOS
    Je ne me souviens plus exactement de la méthode, mais macOS fonctionnait sans problème dès lors qu’on lui attribuait uniquement une adresse v6
    Il suffit d’assigner une adresse ULA à l’hôte, ce qui est simple dès lors qu’on connaît la marche à suivre
    On peut utiliser un script pour que l’app VPN ajoute elle-même une ULA au réseau IPv6-only
    En revanche, si cette ULA reste en place sans contrôle, cela peut poser problème quand l’utilisateur passe ensuite sur un autre réseau v6

• Si vous rencontrez la même situation, vous pouvez mettre en place très facilement un proxy socks avec ssh -D 8080 user@hostname
  Ensuite, il suffit de configurer le proxy du navigateur sur localhost:8080

  • J’allais justement donner exactement le même conseil
    C’est extrêmement simple pour du dépannage temporaire, et cela peut aussi très bien servir comme outil permanent en cas de besoin
    Il faut simplement que AllowTcpForwarding soit activé dans sshd_config

  • J’utilise toujours cette méthode sur les Wi-Fi publics
    Pas besoin de payer un service VPN ni de lui faire confiance : il suffit d’envoyer le trafic vers mon serveur infomaniak via un proxy socks

• Personnellement, j’ai beaucoup de griefs envers IPv4, surtout parce que mon FAI m’impose encore l’IPv4 only, ce qui est particulièrement frustrant
  Je considère que la lenteur de l’adoption d’IPv6 est un grand échec de l’industrie tech
  Je me demande qui devrait en porter la responsabilité
  Constructeurs de routeurs aux firmwares médiocres, manque de leadership des FAI en faveur d’IPv4, spéculateurs sur les adresses IPv4, manque de formation des ingénieurs réseau et du support : je pense qu’il faudrait un débat de fond sur les causes
  Si Internet a pu migrer relativement correctement depuis TLS 1.0, on devrait aussi pouvoir dépasser IPv4
  Peut-être qu’à l’avenir, quelque chose comme un proxy IA pour le code legacy pourrait offrir une solution

  • La transition depuis TLS 1.0 a été plus facile grâce au end-to-end principle
    Il suffisait que le serveur et le client prennent en charge le nouveau protocole ; les équipements intermédiaires (routeurs, switches, etc.) n’avaient à voir qu’avec la couche réseau (IP), et n’étaient pas concernés par les nouvelles versions de TLS
    Dès lors qu’on change le protocole de couche réseau lui-même (IP), tous les équipements intermédiaires sont impactés
    D’ailleurs, même lors du déploiement de TLS 1.3, des middleboxes ont violé ce principe end-to-end en inspectant ou modifiant le trafic, au point que TLS 1.3 a dû recourir à l’astuce absurde de se faire passer pour une reconnexion TLS 1.2 pour préserver la compatibilité

  • La différence, c’est que pour TLS, seuls le serveur et le client doivent le prendre en charge ; les équipements intermédiaires n’ont qu’à transporter des paquets TCP
    Avec IPv6, tous les équipements intermédiaires entre serveur et client doivent le prendre en charge, donc c’est une technologie dépendante du « plus petit dénominateur commun »
    Les évolutions de TLS n’impliquaient pas de changement massif, alors qu’IPv6 a modifié trop d’éléments à la fois
    Avec le recul, on peut regretter qu’IPv6 n’ait pas simplement porté la taille des adresses à 64 bits, car son adoption aurait peut-être été plus facile

  • En pratique, beaucoup de gens restent réticents parce que les bénéfices concrets d’un remplacement sont trop faibles, voire inexistants
    Il n’y a pas de grande théorie du complot autour d’IPv4 : simplement, le rapport travail/risque/bénéfice n’est pas favorable

  • Il y a une vieille blague dans le monde du réseau : « IPv6 est une solution académique plaquée sur un problème d’ingénierie »
    Quand on prend en compte le déploiement réel à grande échelle, l’exploitation et la maintenance, tout en conservant la compatibilité avec IPv4, IPv6 devient trop complexe
    En dehors de la pénurie d’adresses, IPv4 n’a en réalité pas de problème concret suffisamment grave pour disparaître
    C’est pour cela que, sur le terrain, IPv6 ne parvient pas à s’imposer comme une solution réellement pratique