Uso de subdomínios DDns comuns pode causar degradação do serviço de banda larga da China Telecom

Problemas de desconexão IPv6 e falha de furação levaram três meses, finalmente identifiquei a causa, compartilhando com todos.

Primeiro post de solicitação de ajuda sobre desconexão IPv6

IPv6 sempre pôde acessar normalmente, sem alterações de configuração, e dispositivos têm IPv6 independentes, mas não conseguem conectar à rede IPv6.

curl 6.ipw.cn não obtém retorno, ping6 e traceroute6 2400:3200::1 interrompidos.

Modem em modo bridge e roteador podem obter endereço IPv6 do roteador, este é o endereço que pode acessar IPv6.

É possível obter prefixo /56, dispositivos sob o roteador podem obter endereço IPv6 atribuído 240e:36f:15c3:3200::/56, mas não conseguem conectar a sites IPv6.

Suspeito que a operadora não tenha configurado a rota para 240e:36f:15c3:3200::, mas não posso confirmar.

Comentário de internauta diz que pode ser tráfego de upload PCDN excessivo causando, mas tráfego de upload é pequeno, sem PCDN habilitado.

Também pode ser devido ao uso de Cloudflare e Aliyun ESA reverse proxy.

Segundo post confirmando a causa direta

Confirmei que operadoras em algumas regiões da China Telecom podem degradar o serviço devido a muitas conexões IPv6 de entrada HTTP/HTTPS, manifestando-se como:

  • IPv6 falso, IPv6 pode obter prefixo /56, distribuição IPv6 normal em dispositivos, mas tracert sem rota, resultando em IPv6 realmente incapaz de conectar à internet.
  • Falso furo, teste de conexão Tailscale mostra conexão direta, mas latência extremamente alta, velocidade real muito lenta.

Desligando Cloudflare/Aliyun ESA reverse proxy, após várias reinicializações do roteador, IPv6 e conexão direta real podem ser restaurados.

Reconexão ainda interrompida após desligar reverse proxy

Mesmo desligando reverse proxy, desligando Cloudflare e Aliyun ESA origem, também ocorre desconexão ocasional, com duração longa.

Pode haver vazamento de domínio ou alguém usando subdomínios comuns para varredura, ataque HTTP prolongado.

Desativando resolução de domínio DDns, após algum tempo, IPv6 se recupera normalmente, furação direta Tailscale também normal.

Até agora não houve mais problemas de desconexão.

Solução final

Recomendo a todos não usar subdomínios DDns comuns, como:

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

Alguns desses são os que eu sempre usei, possivelmente alguém varrendo continuamente, causando degradação do serviço de banda larga da China Telecom, IPv6 público não pode ser usado normalmente, sempre incapaz de furar conexão direta.

Todos sabem a importância de ocultar IP na segurança cibernética, aqui acrescento a recomendação de proteger seu domínio usado para DDns, isso também expõe IP essencialmente.

Mas ainda há necessidade de expor serviços, o que fazer?

Aqui há duas soluções práticas:

  • Esquema de origem, é um serviço de retransmissão, solicitação primeiro para VPS então para Home Server. Como o tráfego desvia, latência e largura de banda são afetadas.
  • Esquema DDns, é solução de conexão direta, experiência de conexão será muito melhor, recomendo essa solução. Uso pessoal geralmente não ultrapassa limite de conexões simultâneas, mas se domínio for público, bots aparecerão em massa rapidamente elevando número de conexões.

Esquema de origem (reverse proxy)

Cloudflare Tunnel

Use Tunnel da Cloudflare, assim não será como reverse proxy comum com dezenas ou centenas de IPs acessando.

Tailscale ou ZeroTier

VPN caseira, com VPS na frente, acessando serviços internos via VPN, evita número alto de conexões simultâneas.

Esquema DDns (conexão direta)

Resolução pública

Gere string aleatória como GUID, para domínio DDns, embora quase impossível de memorizar, mas impacto é pequeno no uso real, avalie por conta própria.

Resolução privada

Use serviço DNS pessoal, como:

Para resolução DDns.

Assim apenas quem consegue conectar ao servidor DNS pessoal pode obter IP de resolução personalizada para domínio especificado.

Neste esquema, pode usar subdomínios DDns comuns, mas precisa evitar vazar endereço de seu serviço DNS.

Complemento

Dizem por aí que usar speedtest como subdomínio tem efeito místico de aceleração.