Introdução ao GTC PRO

O GTC PRO é uma plataforma completa de diagnóstico de rede desenvolvida para provedores de internet (ISPs) e profissionais de telecomunicações. A plataforma permite executar mais de 25 tipos de testes de rede a partir de múltiplos pontos de presença (POPs) distribuídos pelo Brasil.

Principais Funcionalidades

• Teste de Velocidade — Download e upload com medição real via LibreSpeed
• Diagnóstico Completo — Ping, jitter, perda de pacotes, traceroute, MSS/MTU
• Análise de Roteamento — BGP em tempo real, Looking Glass, IRR, RPKI
• Verificação de Segurança — Blacklist DNSBL, varredura de portas, detecção de middlebox
• Testes de Serviços — Streaming (Netflix, YouTube, etc.), jogos online, CDN
• Sistema de Protocolos — Cada sessão de teste gera um protocolo único rastreável
• Multiplataforma — Web, Windows, macOS, Linux e Android

URLs de Acesso

Ambiente	URL	Descrição
Produção	https://gtcpro.com.br	Painel principal
Admin	/admin	Painel administrativo
Provedor	/provedor	Portal do provedor
Mobile	/mobile	Interface para dispositivos móveis
Desktop	/desktop	Interface do aplicativo desktop

Arquitetura do Sistema

Stack Tecnológica

Componente	Tecnologia	Detalhes
Backend	Node.js 20 + Express	API REST na porta 3000
Banco de Dados	SQLite (better-sqlite3)	WAL mode, em /opt/gtcpro/data/tests.db
Frontend	HTML/CSS/JS puro + D3.js	Sem frameworks, carregamento rápido
Proxy Reverso	Nginx + Let's Encrypt	SSL/TLS automático, rate limiting
WebSocket	ws (biblioteca Node.js)	Medição precisa de latência em /ws
Servidor	Debian 12	8 CPUs, 15 GB RAM, 97 GB disco
Mapas	Leaflet.js	Visualização geográfica dos POPs
Graficos	D3.js v7	Gráficos BGP e barras de velocidade

Estrutura de Diretórios no Servidor

/opt/gtcpro/
  backend/
    server.js          # Backend principal (Express + APIs)
  frontend/
    admin.html         # Painel administrativo
    home.html          # Página inicial
    mobile.html        # Interface mobile
    desktop.html       # Interface desktop
    ...                # 31 páginas HTML
  data/
    tests.db           # Banco SQLite
  logs/                # Logs da aplicação

/opt/librespeed/
  server.js            # Servidor LibreSpeed (porta 8989)

/etc/nginx/
  sites-enabled/gtcpro    # Configuração Nginx
  conf.d/rate-limit.conf   # Regras de rate limiting

Fluxo de uma Requisição

Cliente → Cloudflare (DNS) → Nginx (SSL + rate limit) → Express (:3000) → SQLite

Para testes de velocidade: Cliente → Nginx → LibreSpeed (:8989)

Para medição de latência: Cliente ↔ WebSocket (/ws)

POPs (Pontos de Presença)

O GTC PRO opera com 12 servidores distribuídos pelo Brasil: 1 servidor principal e 11 POPs remotos. Cada POP executa um agente (agent.js) e um servidor LibreSpeed para testes de velocidade locais.

Servidor Principal

POPs Remotos

Cidade	IPv4	IPv6	Hostname
Ananindeua, PA	200.4.113.39	2804:9304:1::40	pop-pa
Acailandia, MA	45.163.103.22	2804:539c:8001:1::22	pop-ma-acailandia
Uirauna, PB	181.224.49.139	2804:7c70:ffa0::139	pop-pb-uirauna
Jaboatao, PE	45.70.217.9	2804:83b8:1::71	pop-pe-jaboatao
Contagem, MG	45.180.91.11	2804:8928:11:4::6	pop-mg-contagem
Frutal, MG	45.239.232.30	2804:5070:ff10::30	pop-mg-frutal
Gov. Valadares, MG	187.85.240.13	2804:91ac:12::13	pop-mg-gvaladares
Trabiju, SP	45.171.122.247	2804:5be8:810:2::247	pop-sp-trabiju
Pacaja, PA	143.0.220.58	2804:2990:10:52::58	pop-pa-pacaja
Lavras, MG	160.238.180.27	2804:3f20::1a	pop-mg-lavras
S.S. do Pontal, MG	201.182.60.6	2804:4270:c000:1::7	pop-mg-sspontal

Como Funciona a Seleção de POP

O sistema utiliza o algoritmo de Haversine para calcular a distância geográfica entre o cliente e cada POP. O POP mais próximo é selecionado automaticamente para testes de velocidade, ping e outros diagnósticos que dependem de proximidade física.

Para comandos BGP e whois, o servidor principal de Belo Horizonte é sempre utilizado, pois é o único com as ferramentas instaladas.

Segurança dos POPs

• SSH na porta 60002 (não padrão)
• Usuário: gabriel (acesso root via su)
• UFW ativo (permite apenas 60002, 80 e 443)
• Fail2ban com ban de 24 horas para SSH
• Atualizações automáticas via unattended-upgrades
• PermitRootLogin desabilitado

Sistema de Protocolos

Cada sessão de diagnóstico gera um número de protocolo único no formato:

GTCPRO-YYYYMMDD-XXXXXX

Exemplo: GTCPRO-20260512-000042

Como Funciona

1. O cliente inicia uma sessão de testes (web, desktop ou mobile)
2. O servidor gera um número sequencial único para o dia
3. Todos os testes executados naquela sessão ficam vinculados ao mesmo protocolo
4. O protocolo pode ser consultado depois no painel admin ou no portal do provedor

Dados Registrados por Protocolo

• IP do cliente (IPv4 e IPv6)
• Geolocalização (cidade, estado, país)
• ISP e ASN do cliente
• Plataforma utilizada (WEB, ANDROID, APP-BASICO)
• Todos os testes executados com seus resultados
• Nota de qualidade do provedor (score e grade)
• Data e hora de cada teste

Plataformas

Os protocolos são agrupados por plataforma de origem. As plataformas legadas (desktop, mobile, WEB-V2) foram normalizadas para WEB.

Plataforma	Origem	Descrição
WEB	Navegador	Testes executados via interface web (inclui acessos antigos de desktop, mobile e WEB-V2)
ANDROID	App Android	Testes executados pelo aplicativo Android nativo
APP-BASICO	App Desktop (Electron)	Testes executados pelo aplicativo desktop via Electron

Filtros na Aba Protocolos

A aba Protocolos no painel admin oferece dois níveis de filtro:

• Badges de plataforma — Clique em WEB, ANDROID ou APP-BASICO para filtrar por plataforma. Clique novamente para desativar o filtro. O badge Todos mostra todas as plataformas.
• Filtros de tempo — Todos, Hoje, Semana, Mês para limitar o período.
• Busca — Filtra por IP, cidade, ISP ou número de protocolo.

Os três filtros se combinam: por exemplo, selecionar ANDROID + Hoje mostra apenas protocolos Android do dia.

Teste de Velocidade

Realiza transferência real de dados entre o dispositivo do cliente e o servidor GTC PRO mais próximo (POP selecionado automaticamente por geolocalização).

Como funciona

• Download: o servidor envia blocos de dados para o cliente e mede a taxa de transferência
• Upload: o cliente envia dados para o servidor, que calcula a velocidade recebida
• Utiliza o LibreSpeed (porta 8989) como motor de medicao
• Os resultados são medidos em Megabits por segundo (Mbps)

Interpretacao

Velocidade	Classificação
Acima de 100 Mbps	Excelente
30 a 100 Mbps	Bom
Abaixo de 30 Mbps	Insuficiente

Ping e Latência

Envia pacotes ICMP (ping) do servidor GTC PRO até o destino especificado. Mede o tempo de ida e volta (RTT - Round Trip Time) de cada pacote em milissegundos. Por padrão, envia 10 pacotes e exibe mínimo, médio e máximo.

Interpretacao

Latência	Classificação
Abaixo de 30 ms	Excelente
30 a 80 ms	Aceitável
Acima de 80 ms	Problema de latência

O sistema também oferece o HTTP Ping (/api/http-ping), que mede a latência via requisições HTTP em vez de ICMP. Isso é útil quando o ICMP está bloqueado no destino.

Jitter

Envia 20 pacotes ICMP consecutivos e calcula a variação de tempo entre cada pacote recebido. O jitter é a medida de instabilidade da conexão.

Interpretacao

Jitter	Classificação	Impacto
Abaixo de 5 ms	Excelente	Ideal para VoIP e jogos
5 a 15 ms	Aceitável	Pode afetar chamadas de vídeo
Acima de 15 ms	Problemático	Causa falhas em tempo real

Perda de Pacotes

Envia 50 pacotes ICMP e conta quantos se perderam no caminho. A perda é exibida em percentual.

• 0% — Ideal, nenhum pacote perdido
• Acima de 1% — Indica problema na rota (congestionamento, falha em equipamento ou interferência WiFi)
• Acima de 5% — Problema crítico, afeta todos os serviços

MSS / MTU

Mede o MSS (Maximum Segment Size) e o MTU (Maximum Transmission Unit) da conexão TCP entre o cliente e o servidor.

O que são

• MTU: tamanho máximo de um pacote que pode trafegar sem fragmentação (padrão Ethernet: 1500 bytes)
• MSS: tamanho máximo de dados dentro de um segmento TCP (MTU menos cabeçalhos IP e TCP, geralmente 1460 bytes)

Método de Medição

Utiliza o método PLPMTUD (RFC 4821), que envia pacotes de tamanhos crescentes para descobrir o MTU real do caminho.

Interpretacao

MSS	Significado
1460	Normal (Ethernet padrão)
1400 a 1459	Tunelamento detectado (PPPoE, VPN)
Abaixo de 1400	Múltiplos encapsulamentos (GRE, IPv6-in-IPv4)

Subdomínio Forçado (IPv4 / IPv6)

Para medir o MSS separadamente por protocolo, o sistema utiliza subdomínios dedicados:

• v4-pop-XX.gtcpro.com.br — Força conexão IPv4 (registro A)
• v6-pop-XX.gtcpro.com.br — Força conexão IPv6 (registro AAAA)

Esses registros DNS são gerenciados no Cloudflare (domínio gtcpro.com.br).

Traceroute

Rastreia o caminho completo que os pacotes percorrem entre o servidor GTC PRO e o destino. Cada salto (hop) mostra o IP do roteador intermediário e a latência.

• Máximo de 30 saltos
• Suporta IPv4 e IPv6 (traceroute6)
• Disponível também via Looking Glass com seleção de POP

Testes de DNS

Consulta DNS com Rastreamento

Executa dig +trace para mostrar toda a cadeia de resolução DNS, desde os servidores raiz até o registro final. Útil para identificar problemas de propagação.

Teste de Resolvers DNS

Testa o tempo de resposta dos principais resolvers DNS públicos:

Resolver	IP
Google DNS	8.8.8.8
Cloudflare DNS	1.1.1.1
Quad9	9.9.9.9
OpenDNS	208.67.222.222

Permite identificar qual DNS é mais rápido para o cliente e se algum esta bloqueado pelo provedor.

Detecção de Sequestro de DNS

O teste de DNS Hijack (/api/dns-hijack) verifica se o provedor está interceptando e redirecionando consultas DNS para seus próprios servidores, mesmo quando o cliente configura resolvers alternativos.

Blacklist (DNSBL)

Verifica se um endereço IP está listado em mais de 60 listas negras (DNSBL). As verificações são feitas em lotes de 15 consultas simultâneas.

Categorias de Listas

Categoria	Exemplos	Significado
Spam	Spamhaus ZEN, SBL, Barracuda, SpamCop, SORBS	IP associado ao envio de spam
Exploit	Spamhaus XBL, CBL, DroneBL, Blocklist.de	IP comprometido ou com malware
Política	Spamhaus PBL, SpamRATS, CYMRU Bogons	IP de uso residencial ou mal configurado
Proxy	DAN TOR, DAN TOR Exit	IP associado a rede Tor
Reputação	Sender Score	Score geral de reputação do IP

Varredura de IP

Realiza uma análise completa de um endereço IP:

• Geolocalização — Cidade, estado, país, ISP, ASN
• DNS Reverso — Hostname associado ao IP
• WHOIS — Informações de registro
• Varredura TCP — Todas as 65.535 portas via nmap (SYN scan)
• Probes UDP — Testa serviços DNS, NTP, SNMP e L2TP
• Identificação de Serviços — Banner grabbing (HTTP, SSH, SMTP, etc.)

Quando executado a partir de um POP remoto, os comandos são enviados via SSH para obter resultados da perspectiva daquele ponto de presença.

Teste de Portas Distribuído

Testa a acessibilidade de portas específicas a partir de múltiplos POPs simultaneamente. Permite identificar se um bloqueio é local (no provedor do cliente) ou global (no servidor de destino).

• Cada POP testa a porta e mede a latência
• Resultado inclui status (aberta/fechada) por ponto de presença
• Ideal para diagnosticar bloqueios de firewall

BGP e Looking Glass

Looking Glass

Permite executar comandos de rede a partir dos servidores GTC PRO, simulando um terminal de operadora:

Comando	Descrição
ping / ping6	Ping ICMP (10 pacotes)
traceroute / traceroute6	Rastreamento de rota (30 saltos)
mtr	My Traceroute com 10 ciclos (ping + traceroute combinados)
dig	Consulta DNS com rastreamento (registros A ou AAAA)
whois	Consulta RADB (registro de roteamento)
bgp-route	Consulta de rota BGP + validação RPKI
bgp-path	Prefixos anunciados por um ASN

BGP em Tempo Real

Visualização gráfica das rotas BGP usando a API do RIPE RIS. Mostra:

• AS de origem e caminho AS completo
• Coletores RRC que enxergam a rota
• Validação RPKI (válido, inválido ou desconhecido)
• Next hop e comunidades BGP
• Indicador de melhor caminho (best path)

IRR e RPKI

IRR (Internet Routing Registry)

Consulta o banco de dados RADB para obter objetos de roteamento: rotas anunciadas, autnum, maintainer, e políticas de roteamento de um ASN.

RPKI (Resource Public Key Infrastructure)

Valida se um prefixo IP tem autorização criptográfica (ROA) para ser anunciado pelo ASN informado. Utiliza a API do RIPE para verificação.

Status	Significado
Valid	ROA válido, anúncio autorizado
Invalid	ROA não corresponde, possível sequestro
Unknown	Nenhum ROA encontrado

Teste de Streaming

Mede a latência entre o cliente e os servidores das principais plataformas de streaming, fazendo uma conexão HTTPS real e medindo o tempo do primeiro byte.

Plataformas Testadas

Netflix, YouTube, Disney+, Prime Video, Twitch, Globoplay, Spotify e Max.

Classificação de Qualidade

Latência	Qualidade Estimada
Abaixo de 20 ms	4K Ultra HD
20 a 50 ms	Full HD (1080p)
50 a 100 ms	HD (720p)
Acima de 100 ms	SD (480p)

Teste de Jogos

Mede a latência até os servidores dos principais jogos online no Brasil:

• AWS São Paulo — Maioria dos jogos (Fortnite, Apex, etc.)
• Google São Paulo — Jogos hospedados no GCP
• Riot Games Brasil — League of Legends e Valorant
• Valve/Steam — CS2, Dota 2
• Cloudflare — Jogos com CDN distribuída

Métricas Medidas

Tempo de resolução DNS, tempo de conexão, negociação TLS, tempo até o primeiro byte (TTFB) e tempo total.

Latência	Classificação
Abaixo de 30 ms	Ideal para jogos competitivos
30 a 60 ms	Aceitável
Acima de 60 ms	Pode causar lag perceptível

Testador de Site

Teste Rápido

Faz uma requisição HTTP/HTTPS ao site e retorna código de status, tempo de resposta, headers e informações básicas.

Teste Completo

Utiliza o Chrome headless para carregar a página completamente e medir métricas de performance:

• Tempo de carregamento total
• Métricas Web Vitals (LCP, FID, CLS)
• Cascata de carregamento de recursos
• Timeline de rede

Testes Avançados

Detecção de Traffic Shaping

Realiza múltiplos testes de download com diferentes tipos de payload (dados regulares, video e audio). Se a velocidade varia conforme o tipo de conteúdo, indica que o provedor está aplicando traffic shaping baseado em DPI (Deep Packet Inspection).

Detecção de Middlebox

Verifica se existem dispositivos intermediários (proxies, firewalls com DPI, aceleradores de conteúdo) no caminho entre o cliente e o servidor. Analisa headers HTTP manipulados via httpbin.org.

Detecção de Bloqueio de Portas

Testa se o provedor bloqueia portas de saída comuns (como 25/SMTP, 445/SMB, etc.). O teste conecta a servidores externos em cada porta para verificar acessibilidade.

Detecção de Roteamento Assimétrico

Identifica quando os pacotes de ida e volta seguem caminhos diferentes pela rede. Roteamento assimétrico pode causar problemas de performance e dificuldade no diagnóstico.

Dual-Stack (IPv4/IPv6)

Testa se o cliente possui conectividade tanto IPv4 quanto IPv6, verificando qual protocolo está sendo utilizado e se ambos funcionam corretamente.

Firewall (UFW)

Todos os servidores utilizam o UFW (Uncomplicated Firewall) como firewall principal.

Regras Padrão

# Política padrão
ufw default deny incoming
ufw default allow outgoing

# Portas permitidas
ufw allow 60002/tcp   # SSH (porta customizada)
ufw allow 80/tcp      # HTTP (redirect para HTTPS)
ufw allow 443/tcp     # HTTPS

# No servidor principal (BH), a porta SSH é 45631
ufw allow 45631/tcp

Regras Anti-DDoS no before.rules

O arquivo /etc/ufw/before.rules contém regras adicionais de proteção contra ataques DDoS, aplicadas antes das regras padrão do UFW.

Proteção Anti-DDoS

A proteção anti-DDoS é implementada em múltiplas camadas:

1. Sysctl (Kernel)

Arquivo: /etc/sysctl.d/99-ddos-protection.conf

# SYN Cookies - protege contra SYN flood
net.ipv4.tcp_syncookies = 1

# Reverse Path Filtering - descarta pacotes com IP falsificado
net.ipv4.conf.all.rp_filter = 1

# Ignorar broadcasts ICMP - previne Smurf attack
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Limitar conexoes pendentes
net.ipv4.tcp_max_syn_backlog = 4096

# Reduzir tempo de conexoes TIME_WAIT
net.ipv4.tcp_fin_timeout = 15

# Reciclar conexoes TIME_WAIT
net.ipv4.tcp_tw_reuse = 1

2. UFW before.rules (iptables)

Regras de rate limiting por IP antes que o trafego chegue ao aplicativo.

3. Nginx Rate Limiting (3 camadas por peso)

Os endpoints da API são classificados por peso e cada camada tem limites diferentes:

Camada	Limite	Burst	Conexões	Endpoints
Heavy	2 req/min	2	3 simultâneas	ip-scan, block-scan, site-test, site-full-test, mss-test, mss-all-pops
Medium	2 req/s	5	20 (global)	irr, rpki, blacklist, whois, bgp-graph, looking-glass, games-test, streaming, shaping, middlebox, cdn-detect
Light	10 req/s	20	20 (global)	Todos os outros endpoints da API (dns, ping, health, etc.)
Global	30 req/s	60	20/IP	Todas as requisições

Requisições que excedem o limite recebem HTTP 429 Too Many Requests. O Nginx bloqueia antes de chegar ao Node.js.

Anti-Slowloris (timeouts agressivos)

Timeout	Valor	Proteção
client_header_timeout	10s	Corta conexões que enviam headers devagar (Slowloris)
client_body_timeout	10s	Corta conexões que enviam body devagar (Slow POST)
send_timeout	15s	Corta conexões que leem resposta devagar (Slow Read)
keepalive_timeout	30s	Libera conexões ociosas mais rápido

4. Proteção no Node.js (idempotência)

Além do Nginx, o backend Node.js tem proteção própria contra flood de protocolos:

• Máximo 3 protocolos por IP por minuto — independente do endpoint chamado
• Intervalo mínimo de 5 segundos — entre qualquer geração de protocolo do mesmo IP
• As requisições continuam retornando dados normais — apenas não geram protocolo duplicado

Isso impede que alguém use curl em loop para poluir o banco de dados com protocolos falsos, mesmo que passe pelo rate limit do Nginx.

5. Token do Provedor (segurança)

• Token Bearer com HMAC-SHA256 + salt aleatório de 32 caracteres
• Expiração de 7 dias (requer novo login após expirar)
• O base64 do token contém ID + timestamp + salt — sem o secret HMAC do servidor, não é possível forjar um token válido
• Cada provedor só visualiza protocolos dos seus blocos de IP (IPv4 e IPv6 CIDR)

6. Fail2ban

Bloqueia IPs automaticamente após comportamento suspeito (veja a seção Fail2ban).

7. IPv6 MSS Clamping

Para conexões IPv6, o MTU e ajustado para 1400 e o MSS e fixado via iptables para evitar fragmentação:

ip6tables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip6tables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Fail2ban

O Fail2ban monitora os logs do sistema e bane IPs que apresentam comportamento malicioso.

Jails Configuradas

Jail	O que monitora	Tentativas	Duração do Ban
sshd	Tentativas de login SSH falhadas	3 tentativas	24 horas
nginx-limit-req	Excesso de requisições HTTP	10 ocorrências	1 hora
nginx-botsearch	Scans de vulnerabilidade (/wp-admin, /phpmyadmin, etc.)	5 ocorrências	24 horas

Comandos Uteis

# Ver status de todas as jails
fail2ban-client status

# Ver IPs banidos em uma jail
fail2ban-client status sshd

# Desbanir um IP manualmente
fail2ban-client set sshd unbanip 1.2.3.4

SSH Hardening

Configurações de Segurança

Parametro	Valor	Motivo
Porta	60002 (todos os servidores)	Porta não padrão, evita scanners automaticos
Autenticação	Chave SSH ed25519	Sem senha, sem risco de ban por fail2ban
PermitRootLogin	no	Impede login direto como root
Acesso root	Via su (senha)	Login como gabriel, depois eleva para root
Usuário	gabriel	Padronizado em todos os 9 servidores

Autenticação por Chave SSH

Todos os 9 servidores (BH + 8 POPs) utilizam autenticação por chave SSH ed25519. Isso elimina a necessidade de senhas em conexões SSH e resolve o problema de bloqueio pelo fail2ban por excesso de conexões.

Chave de deploy

Propriedade	Valor
Tipo	ed25519
Comentário	gtcpro-deploy
Localização (Mac)	~/.ssh/id_ed25519
Instalada em	Todos os 9 servidores (user gabriel)

Acesso direto (sem senha)

# Conectar em qualquer servidor
ssh -p 60002 gabriel@<IP>

# Elevar para root (precisa da senha)
echo 'SENHA' | su -c 'COMANDO' root

Deploy de arquivos

# Upload
scp -P 60002 arquivo gabriel@<IP>:~/

# Copiar para destino como root
ssh -p 60002 gabriel@<IP> "echo 'SENHA' | su -c 'cp ~/arquivo /opt/gtcpro/frontend/ && chown gtcpro:gtcpro /opt/gtcpro/frontend/arquivo' root"

Backend → POPs (server.js)

O serviço GTC PRO (gtcpro.service) roda como user gtcpro, que possui sua própria chave SSH instalada. Isso permite que o backend acesse os POPs remotos via ssh/scp com BatchMode=yes (sem interação), em vez do antigo sshpass.

• Chave do serviço: /home/gtcpro/.ssh/id_ed25519
• Config SSH: /home/gtcpro/.ssh/config (StrictHostKeyChecking no, porta 60002, user gabriel)
• Usado em: monitoramento, segurança (fail2ban/SSH log), looking glass, varredura de portas

Fail2ban e SSH

Com autenticação por chave, o fail2ban não bane mais por excesso de conexões SSH, pois não há "failed password" nos logs. O jail sshd continua ativo para proteger contra ataques externos de força bruta.

Nginx e SSL

Configuração SSL/TLS

• Protocolos: TLSv1.2 e TLSv1.3 apenas (versões antigas desabilitadas)
• Certificados: Let's Encrypt com renovação automática via Certbot
• HSTS: Habilitado com max-age de 1 ano e incluindo subdomínios
• Ciphers: Apenas ECDHE (curvas elípticas) com AES-GCM ou ChaCha20
• SSL Buffer Size: 4 KB (otimizado para IPv6)

Headers de Segurança

X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains

Proxy Reverso e Arquivos Estáticos

# Arquivos estáticos (.js, .css, .svg, etc.)
location ~* \.(js|css|svg|png|jpg|ico|woff2|ttf|json)$ {
    root /opt/gtcpro/frontend;
    try_files $uri =404;
    expires 7d;
}

# Downloads (executáveis)
location /downloads/ {
    alias /opt/gtcpro/frontend/downloads/;
    try_files $uri =404;
}

# API e rotas do Node.js
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

# WebSocket (medição de latência)
location /ws {
    proxy_pass http://127.0.0.1:3000/ws;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

# LibreSpeed (teste de velocidade)
location /speedtest/ {
    proxy_pass http://127.0.0.1:8989/;
}

# Páginas (proxy para Node.js)
location = /home { proxy_pass http://127.0.0.1:3000/home; }
location = /admin { proxy_pass http://127.0.0.1:3000/admin; }
# ... demais rotas

# Raiz redireciona para /home
location = / { return 302 /home; }

# Catch-all: proxy para Node (retorna redirect 301 /home)
location / { proxy_pass http://127.0.0.1:3000; }

Importante: O Nginx não usa try_files $uri /index.html. Todas as URLs desconhecidas são encaminhadas ao Node.js, que redireciona para /home. Apenas arquivos estáticos (JS, CSS, imagens) são servidos diretamente pelo Nginx.

Autenticação

Painel Admin (Basic Auth)

O painel administrativo utiliza HTTP Basic Auth com hash SHA256 + salt. Os usuarios sao armazenados na tabela admin_users do banco SQLite.

Perfil	Permissões
Super Admin	Acesso total + gerenciamento de usuários
Admin	Acesso total ao painel (sem gerenciar usuários)
Visualizador	Somente leitura (não pode criar, editar ou excluir nada)

Portal do Provedor (Bearer Token)

Os provedores fazem login com usuário/senha e recebem um token Bearer (HMAC-SHA256). O token e enviado no header Authorization: Bearer <token> em todas as requisições subsequentes.

Os provedores só visualizam protocolos de testes originados de seus blocos de IP (filtragem CIDR).

Hashing de Senhas

SHA256( senha + "gtcpro_salt_2026" )

Todas as senhas (admin e provedores) são armazenadas como hash SHA256 com salt fixo. Nunca são armazenadas em texto puro.

Painel Administrativo

O painel admin (/admin) oferece visão completa do sistema:

Abas Disponíveis

Aba	Função
Resumo	Estatísticas gerais (visitas, testes, top provedores e cidades)
Servidores	Mapa interativo e tabela de status dos POPs (CPU, RAM, disco, latência)
Protocolos	Todos os protocolos de teste com busca, filtros e detalhes completos
Downloads	Estatísticas de downloads e instalações dos aplicativos
Requisições	Solicitações de servidor (aprovar/rejeitar)
Provedores	Gerenciamento de provedores (ISPs)
Licenças	Gerenciamento de licenças de hardware
Usuários	Gerenciamento de usuários administradores (somente super admin)
Monitoramento	Métricas em tempo real + gráficos históricos de cada servidor
Documentação	Esta página

Auto-Refresh

O painel atualiza os dados automaticamente a cada 5 segundos. O contador de refresh é exibido no canto superior direito.

Sistema de Provedores

Provedores de internet (ISPs) podem ter contas dedicadas para acompanhar os diagnósticos de seus clientes.

Cadastro de Provedor

• Nome e CNPJ — Identificação da empresa
• Usuário e senha — Credenciais de acesso ao portal
• Blocos IPv4 — Prefixos CIDR (ex: 200.4.113.0/24)
• Blocos IPv6 — Prefixos IPv6 (ex: 2804:9304::/32)
• Servidor atribuido — POP associado ao provedor

Portal do Provedor (/provedor)

No portal, o provedor visualiza apenas os protocolos de teste originados de seus blocos de IP. A filtragem é feita automaticamente pelo backend usando comparação CIDR.

Sistema de Licenças

O sistema de licenças vincula cada instalação do aplicativo GTC PRO a um hardware específico.

Fluxo da Licença

1. Administrador cria uma licença no painel (gera chave única)
2. Chave é enviada ao cliente
3. Cliente registra a chave no servidor: node license-check.js --register CHAVE
4. O sistema coleta o fingerprint de hardware (machine-id, CPU, disco, MAC, RAM)
5. A licença fica vinculada aquele hardware específico
6. Validação diária automática as 00:00

Status da Licença

Status	Significado
Ativa	Funcionando normalmente
Suspensa	Temporariamente desabilitada pelo admin
Expirada	Data de expiração ultrapassada

Reset de Hardware

Se o cliente trocar o servidor, o administrador pode resetar o fingerprint de hardware. O cliente precisará registrar novamente.

Aplicativos

O GTC PRO está disponível em 4 plataformas, permitindo que técnicos e clientes realizem diagnósticos completos de rede diretamente de seus dispositivos.

Plataformas e Downloads

Plataforma	Arquivo	Tamanho	Tecnologia	Versão Atual
Windows	GTC-PRO-Setup.exe	73 MB	Electron	1.6.17
macOS	GTC-PRO.dmg	89 MB	Electron	1.6.17
Linux	GTC-PRO.AppImage	100 MB	Electron	1.6.17
Android	GTC-PRO.apk	3.6 MB	Capacitor (nativo)	2.0.0

Os downloads são rastreados automaticamente pelo endpoint /api/download/:platform.

Aplicativo Desktop (Windows, macOS, Linux)

Arquitetura do App Desktop

• main.js — Processo principal do Electron. Cria a janela, gerencia atualizações e expõe APIs nativas via IPC
• preload.js — Bridge entre o processo principal e o frontend (contextIsolation habilitado)
• Interface — Carrega https://gtcpro.com.br/app-basico via URL remota

Testes Nativos Disponíveis

O app desktop executa os seguintes testes diretamente na máquina do usuário (sem depender do servidor):

Teste	Comando Nativo	Descrição
Ping	ping (10 pacotes)	Latência, jitter e perda de pacotes até o destino
Traceroute	traceroute / tracert	Rastreamento de rota com até 30 saltos
DNS Lookup	dig / nslookup	Resolução DNS com detalhes
Teste de Porta	Socket TCP nativo	Verifica se uma porta está aberta no destino
Scan de Portas	Socket TCP (18 portas)	Testa portas comuns: 21, 22, 25, 53, 80, 443, 3389, etc.
Informações de Rede	networkInterfaces()	Interfaces, IPs, MACs, gateway, DNS configurado
Info do Dispositivo	APIs do SO	CPU, RAM, SO, hostname, uptime
Resolvers DNS	Consulta direta UDP	Tempo de resposta de Google, Cloudflare, Quad9, OpenDNS
HTTP Ping	https.request()	Latência HTTPS até servidores de streaming e jogos

Vantagens dos Testes Nativos

• Perspectiva real do cliente — Os testes saem da máquina do usuário, não do servidor GTC PRO
• Detecção de problemas locais — WiFi, gateway, DNS local, bloqueio de portas pelo provedor
• Sem limitação de firewall — ICMP e portas são testados diretamente
• Informações de hardware — Tipo de conexão, potência WiFi, banda (2.4/5/6 GHz)

Sistema de Atualização Automática

O app desktop utiliza o electron-updater para atualizações automáticas:

1. Ao abrir o app, verifica se há atualização disponível
2. Se encontrar, notifica o usuário com opção de baixar
3. Após o download, oferece opção de instalar e reiniciar

As atualizações são distribuídas via GitHub Releases ou servidor de atualização configurado no package.json.

Build e Distribuição

# Build para cada plataforma
npm run build:win     # Windows (.exe)
npm run build:mac     # macOS (.dmg)
npm run build:linux   # Linux (.AppImage)
npm run build:all     # Todas as plataformas

Importante: O build para Windows deve ser feito em uma máquina Windows (servidor de build em 100.94.0.15). O build no macOS gera apenas o .dmg corretamente.

Aplicativo Android

Arquitetura do App Android

• Capacitor 8 — Framework que empacota a interface web como app nativo Android
• Interface — Conteúdo web em /www, sincronizado com npx cap sync android
• Plugins nativos — @capacitor/device para informações do dispositivo
• App ID — com.gtcpro.diagnostics

Funcionalidades do App Android

• Todos os testes de diagnóstico disponíveis na versão web
• Detecção automática do tipo de conexão (WiFi, 4G, 5G)
• Informações do dispositivo (modelo, versão do Android)
• Potência do sinal WiFi (dBm) e banda utilizada
• Geração de protocolo com identificação da plataforma como "ANDROID"
• Interface otimizada para telas menores

Build do App Android

# Sincronizar código web com o projeto Android
npx cap sync android

# Build debug
cd android && ./gradlew assembleDebug

# O APK fica em: android/app/build/outputs/apk/debug/

Interface Web Responsiva

Além dos aplicativos nativos, o GTC PRO oferece interfaces web otimizadas:

Interface	URL	Uso
Home	/home	Página inicial com seletor de ferramentas
App Básico	/app-basico	Interface simplificada (usada pelo Electron)
Mobile	/mobile	Otimizada para celulares via navegador
Desktop	/desktop	Interface completa para desktop via navegador

Telemetria e Rastreamento

O sistema registra automaticamente o ciclo de vida dos aplicativos:

1. Registro de Download

Quando um usuário clica em "Baixar", o endpoint GET /api/download/:platform registra a plataforma, IP e user-agent antes de redirecionar para o arquivo.

2. Registro de Instalação

Na primeira execução, o app gera um Device ID único e envia para POST /api/track/app-heartbeat com:

• Identificador único do dispositivo
• Plataforma (WINDOWS, MACOS, LINUX, ANDROID)
• Modelo do dispositivo
• Versão do sistema operacional
• Versão do aplicativo

3. Heartbeat (Sinal de Vida)

A cada abertura, o app envia um heartbeat que atualiza o campo last_seen. Isso permite rastrear:

• Instalações ativas — Dispositivos vistos nos últimos 30 dias
• Versões em uso — Qual versão cada instalação está rodando
• Distribuição por plataforma — Quantos de cada SO

4. Métricas no Painel Admin

A aba Downloads do painel admin exibe:

• Total de downloads por plataforma
• Instalações ativas (últimos 30 dias)
• Total de testes realizados por plataforma
• Links diretos para download de cada versão

Monitoramento de Servidores

A aba Monitoramento oferece uma visão unificada de cada servidor, combinando métricas em tempo real (via SSH on-demand) com gráficos históricos em uma única tela, sem iframes ou sub-abas.

Como Funciona

Ao selecionar um servidor no dropdown, duas requisições são disparadas em paralelo:

1. Métricas em tempo real — O backend conecta via SSH no servidor selecionado, executa um script de coleta e retorna os dados instantâneos (CPU, RAM, disco, swap, SSH, fail2ban, pacotes, rede, sistema).
2. Gráficos históricos — O backend consulta o sistema de monitoramento interno e retorna séries temporais de CPU, memória, disco e tráfego de rede.

Cards em Tempo Real

Os 8 cards exibidos no topo mostram o estado atual do servidor:

Card	Métrica	Fonte
Uptime	Tempo desde o último boot	uptime -p
CPU	Uso percentual + load average (1/5/15 min)	top -bn1 + /proc/loadavg
Memória RAM	Uso percentual + MB usados/total/livre	free -m
Disco	Uso percentual da partição raiz	df -h /
Swap	Uso percentual do swap	free -m
Conexões SSH	Conexões e sessões ativas	ss + who
Fail2ban	IPs banidos atualmente + histórico total	fail2ban-client
Pacotes	Total instalados + atualizações disponíveis	dpkg + apt

Gráficos Históricos

Abaixo dos cards, 4 gráficos D3.js mostram a evolução temporal das métricas principais:

Gráfico	Item	Cálculo
CPU	system.cpu.util[,idle]	100 - idle = uso%
Memória	vm.memory.size[available] / vm.memory.size[total]	(1 - available/total) × 100
Disco	vfs.fs.size[/,pfree]	100 - pfree = uso%
Rede	net.if.in[iface] / net.if.out[iface]	bytes/s × 8 = bits/s

Períodos Disponíveis

O seletor de período controla a janela temporal dos gráficos:

• 1h — Última hora (dados brutos do history)
• 6h — Últimas 6 horas (dados brutos)
• 24h — Últimas 24 horas (padrão, dados brutos)
• 7d — Últimos 7 dias (dados agregados via trend.get)
• 30d — Últimos 30 dias (dados agregados via trend.get)

Para períodos acima de 24h, o backend usa dados agregados (médias horárias), resultando em gráficos mais suaves e consultas mais rápidas.

Auto-Refresh

Após selecionar um servidor, os dados atualizam automaticamente a cada 30 segundos (cards e gráficos). O refresh é pausado ao trocar de aba e retomado ao voltar para Monitoramento.

Funcionalidades dos Gráficos

• Tooltip interativo — Passe o mouse sobre o gráfico para ver o valor exato e horário de cada ponto
• Estatísticas no cabeçalho — Cada gráfico mostra o valor atual, mínimo, médio e máximo do período
• Cores dinâmicas — Verde (<60%), amarelo (60-80%), vermelho (>80%) indicam criticidade
• Gradiente de área — Preenchimento com gradiente vertical para melhor visualização
• Responsivo — Gráficos usam SVG com viewBox e se adaptam a qualquer tamanho de tela

Arquitetura Técnica

Componente	Detalhes
Monitoramento	Coleta contínua em todos os 9 servidores via agents
Templates	RR Template OS Linux (38 items), RR Fail2ban, RR HTTP Servico
Coleta SSH	On-demand via /api/admin/server-monitor/:popId
Histórico	Proxy via /api/admin/server-history/:popId
Frontend	D3.js v7 (gráficos nativos, sem dependências externas)

Endpoints da API

Endpoint	Método	Descrição
/api/admin/server-monitor/:popId	GET	Métricas em tempo real via SSH (requer auth admin)
/api/admin/server-history/:popId?period=24h	GET	Histórico (CPU, RAM, disco, rede). Períodos: 1h, 6h, 24h, 7d, 30d
/api/admin/pops-status	GET	Status de todos os POPs (cache 15s)

Mapeamento de Hosts

POP ID	Hostname
belo-horizonte	SERVER-BH
ananindeua	POP-Ananindeua-PA
frutal	POP-Frutal-MG
acailandia	POP-Acailandia-MA
uirauna	POP-Uirauna-PB
jaboatao	POP-Jaboatao-PE
contagem	POP-Contagem-MG
trabiju	POP-Trabiju-SP
gvaladares	POP-GValadares-MG

Banco de Dispositivos Android

O sistema mantém um banco de dados com mais de 52.000 dispositivos Android, mapeando códigos internos (ex: SM-G990E) para nomes comerciais (ex: Samsung Galaxy S21 FE 5G).

Fonte dos Dados

Os dados são obtidos do CSV oficial do Google (supported_devices.csv), que lista todos os dispositivos certificados para Google Play. O download é automático na primeira inicialização do servidor.

Como Funciona

1. Na inicialização, o backend verifica se a tabela android_devices está vazia
2. Se vazia, baixa o CSV do Google (~52k dispositivos) e popula a tabela SQLite
3. Um cache in-memory (Map) é carregado para lookups instantâneos
4. Quando um protocolo Android é exibido no admin, o campo "Modelo" é traduzido automaticamente

Exemplo de Tradução

Código Interno	Nome Exibido
SM-G990E	Samsung Galaxy S21 FE 5G (SM-G990E)
SM-A546E	Samsung Galaxy A54 5G (SM-A546E)
Pixel 8	Google Pixel 8 (Pixel 8)
M2101K6G	Xiaomi Redmi Note 10 Pro (M2101K6G)

Endpoints

Endpoint	Método	Descrição
/api/device-name?model=SM-G990E	GET	Consulta o nome amigável de um dispositivo (público, sem auth)
/api/admin/refresh-devices	POST	Força re-download do CSV do Google e atualiza o banco (requer auth admin)

Armazenamento

Componente	Detalhes
Tabela SQLite	android_devices (model TEXT PK, brand TEXT, marketing_name TEXT)
Cache	Map in-memory (~52k entradas, ~3 MB)
Atualização	Automática no startup se tabela vazia, ou via endpoint admin

Roteamento de URLs

O sistema controla rigorosamente quais URLs são acessíveis. Qualquer URL não registrada redireciona para /home.

Páginas Ativas

URL	Descrição
/home	Página principal
/admin	Painel administrativo
/mobile	Interface mobile
/app-basico	App básico (Electron)
/meu-ip	Identificação de IP
/mss	Teste MSS/MTU
/dns	Testes DNS
/blacklist	Blacklist DNSBL
/varredura	Varredura de IP
/portas	Teste de portas
/bloco	Varredura de bloco
/rpki	Validação RPKI
/irr	Consulta IRR
/jogos	Teste de jogos
/streaming	Teste de streaming
/resolucao	Teste de resolução
/alcancabilidade	Alcançabilidade
/hospede	Solicitar servidor
/site	Testador de site
/bgp-graph	BGP em tempo real
/lg	Looking Glass
/detector-cdn	Detector de CDN
/provedor	Portal do provedor

Redirects (301)

URL Antiga	Destino	Motivo
/v2	/home	Interface descontinuada
/basico	/home	Substituída por /app-basico
/n2	/home	Removida
/desktop	/home	Removida
/qualquer-outra	/home	Catch-all para URLs desconhecidas

APIs Desconhecidas

Chamadas para /api/* que não existem retornam 404 JSON em vez de redirect, para não quebrar integrações.

Plataformas nos Protocolos

As plataformas são normalizadas na aba Protocolos:

Valores Antigos	Normalizado Para
web, WEB, WEB-V2, mobile, desktop, Desktop	WEB
ANDROID	ANDROID
APP-BASICO, APP-BÁSICO	APP-BASICO

Os badges de plataforma são clicáveis e filtram os protocolos. Combinam com os filtros de tempo (Todos/Hoje/Semana/Mês) e busca.

Referência Rápida da API

Todas as APIs estão disponíveis em https://gtcpro.com.br/api/

Diagnóstico (Público)

Método	Endpoint	Descrição
GET	/api/health	Status do servidor
GET	/api/ping?host=X	Ping ICMP
GET	/api/traceroute?host=X	Traceroute
GET	/api/jitter?host=X	Medição de jitter
GET	/api/packetloss?host=X	Perda de pacotes
GET	/api/dns?host=X	Consulta DNS
GET	/api/dns-resolvers	Teste de resolvers
GET	/api/mss	MSS/MTU do cliente
GET	/api/blacklist?ip=X	Verificação DNSBL
GET	/api/irr?query=X	Consulta IRR
GET	/api/rpki?prefix=X	Validação RPKI
GET	/api/streaming	Teste de streaming
POST	/api/games-test	Teste de jogos
POST	/api/ip-scan	Varredura de IP
POST	/api/port-test-distributed	Teste de portas distribuído
POST	/api/looking-glass	Looking Glass
GET	/api/bgp-graph	BGP em tempo real
POST	/api/site-full-test	Teste completo de site

Admin (Requer Basic Auth)

Método	Endpoint	Descrição
GET	/api/admin/stats	Estatísticas gerais
GET	/api/admin/protocols	Lista de protocolos
GET	/api/admin/pops-status	Status dos POPs
GET	/api/admin/users	Lista de usuários admin
POST	/api/admin/users	Criar usuário admin
GET	/api/admin/providers	Lista de provedores
POST	/api/admin/providers	Criar provedor
GET	/api/admin/download-stats	Estatísticas de downloads
GET	/api/admin/visits	Lista de visitas