Geolocalização dos Servidores
Mapa de Servidores
| Nome | Cidade | IPv4 | IPv6 | Ping (ms) | Status | CPU | RAM | Disco |
|---|
| Data/Hora | N. Protocolo | IP | Cidade | ISP | Plataforma | Testes | Ferramentas |
|---|
| Ticket # | Cidade | Estado | Status | Data | Ações |
|---|
| Nome | CNPJ | Usuário | Blocos IPv4 | Servidor | Online | Último Login | Status | Ações |
|---|
| Cliente | Chave de Licença | Hardware | Plano | Status | Último Check | Ações |
|---|
| Usuário | Nome | Perfil | Status | Último Login | Criado em | Ações |
|---|
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
IPv4: 45.171.71.115 | IPv6: 2804:5968:3152::115
SSH: porta 60002 | Usuário: gabriel
Funções: backend principal, banco de dados, BGP/whois, painel admin
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 viasu) - 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
- O cliente inicia uma sessão de testes (web, desktop ou mobile)
- O servidor gera um número sequencial único para o dia
- Todos os testes executados naquela sessão ficam vinculados ao mesmo protocolo
- 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
GET /api/speed/download | POST /api/speed/upload
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
GET /api/ping?host=8.8.8.8
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
GET /api/jitter?host=<destino>
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
GET /api/packetloss?host=<destino>
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
GET /api/mss
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
GET /api/traceroute?host=<destino>
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
GET /api/dns?host=<dominio> | GET /api/dns-resolvers
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)
GET /api/blacklist?ip=<endereco>
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
POST /api/ip-scan
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
POST /api/port-test-distributed
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
POST /api/looking-glass | GET /api/bgp-graph
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
GET /api/irr?query=<ASN> | GET /api/rpki?prefix=<prefixo>
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
GET /api/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
POST /api/games-test
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
POST /api/site-test | POST /api/site-full-test
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
- Administrador cria uma licença no painel (gera chave única)
- Chave é enviada ao cliente
- Cliente registra a chave no servidor:
node license-check.js --register CHAVE - O sistema coleta o fingerprint de hardware (machine-id, CPU, disco, MAC, RAM)
- A licença fica vinculada aquele hardware específico
- 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)
O app desktop carrega a interface web (/app-basico) dentro de uma janela Electron, mas executa testes de rede nativamente no sistema operacional do usuário.
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-basicovia 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:
- Ao abrir o app, verifica se há atualização disponível
- Se encontrar, notifica o usuário com opção de baixar
- 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
O app Android utiliza o Capacitor para empacotar a interface web em um aplicativo nativo, com acesso a APIs do dispositivo.
Arquitetura do App Android
- Capacitor 8 — Framework que empacota a interface web como app nativo Android
- Interface — Conteúdo web em
/www, sincronizado comnpx cap sync android - Plugins nativos —
@capacitor/devicepara 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:
- 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).
- 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
viewBoxe 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
- Na inicialização, o backend verifica se a tabela
android_devicesestá vazia - Se vazia, baixa o CSV do Google (~52k dispositivos) e popula a tabela SQLite
- Um cache in-memory (
Map) é carregado para lookups instantâneos - 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 |