Salut,

Je me lance dans l'auto-hébergement, et j'avoue que je suis face à un petit problème que je n'arrive pas vraiment à identifier.  Je pense que c'est un problème de politique ipv6/ipv4 côté opérateur mais j'avoue ne pas être expert en la matière

En gros j'ai un serveur chez moi, avec dessus un nginx, et un VPN avec Wireguard. Le but de ce VPN est de permettre d’accéder à mes services sans exposer mon serveur sur internet.
Pour gérer le HTTPS avec letsencrypt etc... J'utilise duckdns.org comme service DNS pour me fournir une URL de la forme toto.duckdns.org qui redirige en ipv4 sur 10.0.0.1 (ip de mon serveur sur le VPN), l'ipv6 n'est pas configuré.
Je n'ai aucun problème sur tout mes périphériques connectés à ce VPN, sauf avec mon téléphone en 4G chez Bouygues (en wifi cela fonctionne).

Lorsque j'essaye d'accéder à mon URL, mon navigateur tourne dans le vide, pour au final avoir un client timed out. (et aucun signe de paquet arrivant sur mon serveur via l'interface du VPN). Quand j'essaye avec l'ipv4 10.0.0.1 cela fonctionne.
En faisant quelque test, sur un terminal sur le telephone, je vois qu'en faisant un curl vers toto.duckdns.org, il essaye de contacter une adresse ipv6 sous la forme 64:ff9b ... Quand je force le curl en ipv4, j'arrive bien à récupérer la page web.
En utilisant la commande ping, il fait bien un ping vers 10.0.0.1 et donc ça fonctionne.

Vous savez d'où ça peut venir, et s'il y a moyen de forcer l'ipv4 sur telephone ? 

Merci 

Les serveurs DNS64 alternatifs sont listés sur DNS64 alternatifs.

La problématique, c'est que tu as un mobile sans connectivité IPv4 (tout le trafic qui sort de ton mobile passe en IPv6). Bouygues Telecom et Orange ont mis en place un DNS64 pour soulager le 464XLAT. Ce n'est pas le cas de Free, ou tout le trafic passe par le 464XLAT.

Une solution serait de ne plus utiliser de DNS64, mais un DNS traditionnel, comme le fait Free. Cela va par contre obliger tout le trafic IPv4 à passer par le 464XLAT et donc cela consomme un peu plus de CPU, mais c'est raisonnable.

Tu pourrais utiliser le DNS traditionnel via l'application "1.1.1.1" de Cloudflare qui permet facilement de changer les DNS sur mobile.

Autre solution, changer manuellement les DNS et mettre ceux de Google par exemple : 2001:4860:4860::8888 et 2001:4860:4860::8844

Pour en savoir plus sur le 464XLAT :

Il y a quand même des nouveautés dans le rapport, comme les explications sur les accès IPv6 et le mécanisme de 464XLAT :

Plages privées qui peuvent être utilisées par les opérateurs pour mettre certains services non exposés sur internet.

Deux opérateurs poussent bien IPv6-only sur le mobile : Bouygues et Orange.

Si Orange a entrepris les actions pour mettre IPv6 sur tous ses services, ce n'est pas le cas de Bouygues Telecom.

Les serveurs SpeedTest.net chez Bouygues que je gère doivent être remplacés depuis des années par une solution industrielle (sur un socle virtualisé, supervisé, avec toutes les contraintes ANSSI pour monitorer les actions réalisées) et la demande d'avoir de l'IPv6 a bien retardé / compliqué le projet, Bouygues ne mettant pas d'IPv6 sur ses serveurs. Je ne sais pas s'il y a eu un changement récemment, mais l'IPv6 ne semblait pas naturelle. Je parie que les salariés de Bouygues Telecom n'ont toujours pas IPv6 sur leur poste (Orange, il me semble que c'est en cours).

Je me demande ce qui poserait problème avec l'IPv6.

Pas dans les process, formation déficiente ou réticence des admins ? C'est quasiment toujours là que ca bloque.

En plus, s'il y a des "experts sécurité" car contraintes ANSSI comme le dit Vivien, l'expert en question va surement recommander de "désactiver IPv6, car on se fait hacker avec" (si, si, c'est du vécu, et à plusieurs reprises).

C'est donc "pas exclues". Apres il n'y a pas de raisons particulières d'exclure les plages privées par défaut.

Plages privées qui peuvent être utilisées par les opérateurs pour mettre certains services non exposés sur internet.

Yep, les endpoints de services MMS, visual voice mail ou autres sont derrière un domaine qui n'a pas d'IPv6. Si certains clients sont IPv6-only (de surcroit sans CLAT), il faut que le dns64/nat64 permette d'y accéder.

Bon ben au final, j'ai pas pu utiliser la solution 1.1.1.1 de Cloudflare, étant donné que mon Samsung n'autorise pas plus d'un VPN à la fois.
Du coup, je me suis rabattu sur la solution, passer mon VPN en ipv6, j'avoue que j'ai un peu improvisé n'étant pas fin connaisseur de l'ipv6, mais bon le principal c'est que ça marche 

Merci pour les explications