Como Corrigir o Bloqueio do Seu Site pelo TSPU da RKN: Um Estudo de Caso Real
Este artigo detalha um estudo de caso prático sobre como administradores de sites podem contornar bloqueios impostos pelo TSPU (Equipamentos Técnicos para Contramedidas de Ameaças) da RKN (Serviço Federal de Supervisão de Comunicações, Tecnologias de Informação e Mídia de Massa). A solução envolve a otimização do protocolo HTTP/2.
MundiX News·10 de junho de 2026·4 min de leitura·👁 5 views
Em 5 de junho, uma onda de indisponibilidade de sites afetou provedores de hospedagem populares como Beget, TimeWeb, Selectel e SpaceWeb. Os próprios provedores relataram que o problema não era de sua responsabilidade, mas sim resultado de atualizações nas configurações do TSPU. Usuários enfrentavam o erro 'Connection timed out' no console e o servidor sequer respondia ao ping. A causa provável, conforme comunicado pelos provedores, foram as alterações nas configurações dos Equipamentos Técnicos para Contramedidas de Ameaças (TSPU). Os sintomas incluíam timeouts em conexões SSH/RDP e a inacessibilidade dos protocolos HTTP/HTTPS/ICMP no servidor.
Diante dessa situação crítica, especialmente para quem gerencia serviços de proteção contra bots e ataques, a perda de clientes era uma preocupação real. Uma solução inicial, que ajudou alguns usuários, foi a alteração do 'fingerprint' TLS, utilizando o flag 'Cryptography Compliance (CNSA)' no Chrome. No entanto, a eficácia dessa medida era limitada. Uma investigação mais aprofundada, incluindo a análise de artigos sobre os esquemas de restrição da RKN, levou à hipótese de que o problema estava relacionado à forma como as conexões TLS eram estabelecidas. Descobriu-se que a RKN estava acionando bloqueios com base na quantidade de conexões TLS em um curto período de tempo.
A solução encontrada e detalhada neste estudo de caso reside na ativação do protocolo HTTP/2. Ao contrário do HTTP/1.1, que pode abrir dezenas de conexões TCP/TLS paralelas para carregar elementos de um site, o HTTP/2 (e HTTP/3) utiliza multiplexação. Isso significa que apenas uma única conexão TLS é estabelecida, e centenas de requisições são transmitidas simultaneamente dentro dela. Para a RKN, isso se traduz em um único 'suspeito' pico de conexão, evitando o acionamento do bloqueio de 120 segundos. Servidores proxy modificados, como o Caddy, que por padrão suportam HTTP/2 e HTTP/3 com um stack TLS robusto, forçam o cliente a usar um único handshake TLS, resolvendo efetivamente o problema. A configuração envolve o uso de um certificado autoassinado entre o proxy e o backend, enquanto o Caddy gerencia um certificado Let's Encrypt autoatualizável para o frontend. A ativação do HTTP/2 no servidor web é, portanto, a chave para contornar esses bloqueios específicos do TSPU da RKN.
Em 5 de junho, uma onda de indisponibilidade de sites afetou provedores de hospedagem populares como Beget, TimeWeb, Selectel e SpaceWeb. Os próprios provedores relataram que o problema não era de sua responsabilidade, mas sim resultado de atualizações nas configurações do TSPU. Usuários enfrentavam o erro 'Connection timed out' no console e o servidor sequer respondia ao ping. A causa provável, conforme comunicado pelos provedores, foram as alterações nas configurações dos Equipamentos Técnicos para Contramedidas de Ameaças (TSPU). Os sintomas incluíam timeouts em conexões SSH/RDP e a inacessibilidade dos protocolos HTTP/HTTPS/ICMP no servidor.
Diante dessa situação crítica, especialmente para quem gerencia serviços de proteção contra bots e ataques, a perda de clientes era uma preocupação real. Uma solução inicial, que ajudou alguns usuários, foi a alteração do 'fingerprint' TLS, utilizando o flag 'Cryptography Compliance (CNSA)' no Chrome. No entanto, a eficácia dessa medida era limitada. Uma investigação mais aprofundada, incluindo a análise de artigos sobre os esquemas de restrição da RKN, levou à hipótese de que o problema estava relacionado à forma como as conexões TLS eram estabelecidas. Descobriu-se que a RKN estava acionando bloqueios com base na quantidade de conexões TLS em um curto período de tempo.
A solução encontrada e detalhada neste estudo de caso reside na ativação do protocolo HTTP/2. Ao contrário do HTTP/1.1, que pode abrir dezenas de conexões TCP/TLS paralelas para carregar elementos de um site, o HTTP/2 (e HTTP/3) utiliza multiplexação. Isso significa que apenas uma única conexão TLS é estabelecida, e centenas de requisições são transmitidas simultaneamente dentro dela. Para a RKN, isso se traduz em um único 'suspeito' pico de conexão, evitando o acionamento do bloqueio de 120 segundos. Servidores proxy modificados, como o Caddy, que por padrão suportam HTTP/2 e HTTP/3 com um stack TLS robusto, forçam o cliente a usar um único handshake TLS, resolvendo efetivamente o problema. A configuração envolve o uso de um certificado autoassinado entre o proxy e o backend, enquanto o Caddy gerencia um certificado Let's Encrypt autoatualizável para o frontend. A ativação do HTTP/2 no servidor web é, portanto, a chave para contornar esses bloqueios específicos do TSPU da RKN.
