L'utilisation de sous-domaines DDns courants peut entraîner une dégradation du service Internet par câble de China Telecom

Wednesday, February 19, 2025

Premier message sur le problème de déconnexion IPv6

IPv6 a toujours pu accéder normalement, sans aucune modification des paramètres, et les appareils disposent tous d’adresses IPv6 indépendantes, mais ne peuvent pas se connecter au réseau IPv6.

curl 6.ipw.cn ne reçoit pas de réponse, ping6 et traceroute6 2400:3200::1 sont interrompus.

Modem en mode bridge + routeur, on peut obtenir l’adresse IPv6 du routeur, c’est une adresse pouvant accéder à IPv6.

On peut obtenir le préfixe /56, les appareils sous le routeur peuvent tous obtenir l’adresse IPv6 allouée 240e:36f:15c3:3200::/56, mais ne peuvent pas se connecter aux sites Web IPv6.

On soupçonne que l’opérateur n’a pas correctement établi le routage pour 240e:36f:15c3:3200::, mais impossible de le confirmer.

Un internaute dit que cela pourrait être dû à un volume de trafic PCDN sortant élevé, mais le trafic sortant est faible, et PCDN n’est pas activé.

Cela pourrait aussi être dû à l’utilisation d’un proxy inversé Cloudflare et Aliyun ESA.

Deuxième message pour confirmer la cause directe

Confirmation que certains opérateurs China Telecom dans certaines régions dégradent le service lorsqu’il y a trop de connexions IPv6 entrantes HTTP/HTTPS, se manifestant par :

IPv6 factice : IPv6 peut obtenir le préfixe /56, la distribution IPv6 des appareils est normale, mais le tracert manque de routage, entraînant l’impossibilité réelle de se connecter à IPv6.
Tunneling factice : le test de connexion Tailscale affiche une connexion directe, mais la latence est très élevée, la vitesse réelle extrêmement lente.

Désactiver le proxy inversé Cloudflare/Aliyun ESA, après plusieurs redémarrages du routeur, IPv6 et la vraie connexion directe peuvent être restaurés.

Déconnexion persistante même après désactivation du proxy

Même après avoir désactivé le proxy, désactivé le retour source Cloudflare et Aliyun ESA, des déconnexions occasionnelles se produisent, avec une durée prolongée.

Il se peut qu’un domaine ait fui, ou qu’un sous-domaine courant soit utilisé pour le balayage, entraînant une attaque HTTP à long terme.

Désactiver la résolution du domaine DDns, après un certain temps, IPv6 se rétablit, le tunneling Tailscale fonctionne aussi normalement.

Depuis lors, plus aucune déconnexion.

Solution finale

Je recommande à tous de ne pas utiliser de sous-domaines DDns courants, tels que :

home.example.com
nas.example.com
router.example.com
ddns.example.com
cloud.example.com
dev.example.com
test.example.com
webdav.example.com

Certains d’entre eux étaient les miens utilisés auparavant, peut-être balayés en permanence par d’autres, entraînant la dégradation du service Internet par câble de China Telecom, l’impossibilité d’utiliser IPv6 en réseau public, et l’impossibilité constante de percer le tunnel.

Tout le monde sait que dans la sécurité réseau, cacher l’IP est crucial, ici j’ajoute une recommandation supplémentaire de protéger votre domaine DDns, qui expose essentiellement aussi l’IP.

Mais comment faire si on a toujours besoin d’exposer des services ?

Deux solutions pratiques :

Solution de retour source : service de relais, la requête passe d’abord par un VPS puis au serveur maison. En raison du détournement du trafic, latence et bande passante sont affectées.
Solution DDns : solution de connexion directe, expérience de connexion bien meilleure, recommandée. Pour un usage personnel, généralement pas de dépassement de la limite de connexions simultanées, mais si le domaine est public, des bots en masse augmenteront rapidement le nombre de connexions.

Solution de retour source (proxy inversé)

Cloudflare Tunnel

Utiliser le Tunnel de Cloudflare, évitant ainsi des dizaines, voire des centaines d’IP comme pour un retour source classique.

Tailscale ou ZeroTier

Créer un VPN personnel, avec un VPS en front, accéder aux services internes via VPN, évitant ainsi un nombre de connexions simultanées trop élevé.

Solution DDns (connexion directe)

Résolution publique

Générer une chaîne aléatoire comme un GUID pour le domaine DDns, bien que presque impossible à mémoriser, l’impact sur l’usage personnel est minime, à évaluer selon vos besoins.

Résolution privée

Utiliser un service DNS personnel, tel que :

Pour la résolution DDns.

Avec cette solution, seules les personnes pouvant se connecter au serveur DNS personnel peuvent obtenir l’IP de résolution personnalisée du domaine spécifié.

Avec ce schéma, on peut utiliser des sous-domaines DDns courants, mais il faut éviter de divulguer l’adresse de son service DNS.

Complément

Rumeur populaire : utiliser speedtest comme sous-domaine aurait un effet de magie accélératrice.