Diagnóstico de Conectividade Linux Avançado: curl, TLS, nftables, WireGuard e BBR

Linux · Diagnóstico de Rede · nftables · WireGuard · Cloudflare Tunnel · TCP/BBR · TLS · gping · trippy · bandwhich
 |  ✎ Duarte Spínola  |  16 de Junho de 2026

Em 2026, o diagnóstico de rede em Linux exige dominar quatro camadas em simultâneo. Uma aplicação SaaS que fica lenta pode ter o problema no handshake TLS (camada 7), num MTU mal configurado (camada 3), numa regra nftables que descarta pacotes em silêncio (camada 2/3), ou numa janela TCP subdimensionada que impede o servidor de usar a largura de banda contratada (camada 4). Cada camada tem ferramentas próprias — e a maioria dos problemas reais cruza duas ou mais.

Este guia cobre o diagnóstico completo de cima para baixo: testes end-to-end com curl, debugging TLS com openssl s_client, debugging de firewall com nftables (o sucessor de iptables, default em RHEL 9+, Debian 12+ e Ubuntu 22.04+), debugging de VPN com wg, debugging de Cloudflare Tunnel, ferramentas modernas escritas em Rust (gping, trippy, bandwhich) e tuning TCP/BBR para extrair o máximo de uma ligação de 1 Gbps.

1. Pré-requisitos e Setup

Antes de iniciar qualquer diagnóstico, certifique-se de que as ferramentas necessárias estão instaladas. Em distribuições baseadas em Debian/Ubuntu:

# Ferramentas base
sudo apt install -y curl openssl nftables conntrack iproute2 tcpdump

# Ferramentas modernas (Rust-based)
# gping — ping com gráfico em tempo real
cargo install gping
# trippy — traceroute moderno com TUI
cargo install trippy
# bandwhich — monitor de largura de banda por processo
cargo install bandwhich

# WireGuard tools
sudo apt install -y wireguard-tools

# cloudflared
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o /usr/local/bin/cloudflared
chmod +x /usr/local/bin/cloudflared

2. Testes End-to-End com curl (Camada 7)

A maioria dos problemas “a app está lenta” exige olhar para a camada aplicação. curl é a ferramenta canónica para decompor o tempo de um pedido HTTP/S em fases individuais.

2.1 Decomposição Completa de Latência

O parâmetro -w do curl permite extrair métricas temporais precisas de cada fase do pedido:

# Testado em: curl 8.x — Ubuntu 22.04/24.04
curl -o /dev/null -s -w "\n  DNS:   %{time_namelookup}s\n  TCP:   %{time_connect}s\n  TLS:   %{time_appconnect}s\n  TTFB:  %{time_starttransfer}s\n  Total: %{time_total}s\n  Size:  %{size_download} bytes\n" https://www.google.com

Saída esperada num servidor bem configurado:

  DNS:   0.004s
  TCP:   0.012s
  TLS:   0.045s
  TTFB:  0.089s
  Total: 0.123s
  Size:  14523 bytes

Tabela de Referência — Intervalos Normais vs Anomalia:

Métrica curl	O que mede	✓ Normal (LAN/DC)	✓ Normal (Fibra Nacional)	⚠ Anomalia — Investigar	Causa Provável
time_namelookup	Resolução DNS	< 2ms	< 30ms	> 100ms	Resolver saturado, DNSSEC lento, MTU DNS
time_connect	Handshake TCP (SYN/ACK)	< 1ms	< 20ms	> 70ms	Firewall com SPI lenta, rota subóptima, congestionamento
time_appconnect - time_connect	Handshake TLS (delta)	< 5ms	< 80ms	> 200ms	CPU alta no servidor, cifras RSA-2048 sem ECDHE, OCSP lento
time_starttransfer - time_appconnect	TTFB — Processamento App	< 30ms	< 150ms	> 500ms	Query DB lenta, lock de aplicação, cold start de container
time_total	Tempo total do pedido	< 50ms	< 300ms	> 1s	Soma de todos os problemas acima

2.2 Forçar Versão TLS Específica

# Forçar TLS 1.3 (rejeitar 1.2)
curl --tlsv1.3 --tls-max 1.3 -v https://example.com 2>&1 | grep -E "SSL connection|TLS|handshake"

# Forçar TLS 1.2 (rejeitar 1.3)
curl --tlsv1.2 --tls-max 1.2 -v https://example.com 2>&1 | grep -E "SSL connection|TLS|handshake"

2.3 Testar HTTP/2 vs HTTP/3 (QUIC)

# Verificar se o servidor suporta HTTP/2
curl -I --http2 https://example.com 2>&1 | grep -i "HTTP/"

# Verificar suporte a HTTP/3 (QUIC) — requer curl compilado com quiche ou ngtcp2
curl --http3 https://example.com -v 2>&1 | grep -i "QUIC\|HTTP/3"

2.4 Testar com IP Específico (Bypass DNS)

# Testar diretamente contra um IP sem passar pelo DNS
curl --resolve example.com:443:93.184.216.34 https://example.com -v

# Útil para testar um servidor específico atrás de um load balancer
curl --resolve api.empresa.pt:443:10.0.1.50 https://api.empresa.pt/health

3. Debugging TLS com openssl s_client

O openssl s_client é a ferramenta de referência para inspecionar handshakes TLS, validar certificados e testar compatibilidade de cifras. Ao contrário do curl, mostra o processo de negociação completo.

3.1 Inspecção Básica de Certificado e Handshake

# Inspecionar certificado e handshake TLS
openssl s_client -connect api.kbase.pt:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -E "Subject:|Issuer:|Not After:|Not Before:|DNS:"

# Verificar apenas a validade do certificado
openssl s_client -connect api.kbase.pt:443 2>/dev/null | openssl x509 -noout -dates

3.2 Testar Versões e Cifras Específicas

# Forçar TLS 1.3
openssl s_client -connect api.kbase.pt:443 -tls1_3

# Listar cifras suportadas pelo servidor
nmap --script ssl-enum-ciphers -p 443 api.kbase.pt

# Testar uma cifra específica
openssl s_client -connect api.kbase.pt:443 -cipher ECDHE-RSA-AES256-GCM-SHA384

Tabela de Referência — Estado de Segurança TLS em 2026:

Versão / Cifra	Estado	Handshake RTT	Acção Recomendada
TLS 1.3 + AES-256-GCM	✓ Ideal	1-RTT (0-RTT possível)	Manter. Padrão recomendado.
TLS 1.3 + ChaCha20-Poly1305	✓ Ideal	1-RTT	Preferível em dispositivos sem AES-NI (ARM, IoT).
TLS 1.2 + ECDHE-RSA-AES256-GCM	⚠ Aceitável	2-RTT	Aceitar apenas para compatibilidade com clientes legados.
TLS 1.2 + RSA-AES128-CBC-SHA	✗ Inseguro	2-RTT	Desativar. Vulnerável a BEAST e Lucky13.
TLS 1.1 ou inferior	✗ Crítico	—	Bloquear imediatamente. Browsers modernos recusam.
SSL 3.0 / RC4 / 3DES	✗ Crítico	—	Vulnerabilidade activa. Desativar e auditar logs.

3.3 Verificar OCSP Stapling e CT Logs

# Verificar OCSP stapling (resposta de revogação em tempo real)
openssl s_client -connect api.kbase.pt:443 -status 2>/dev/null | grep -A 10 "OCSP Response"

# Verificar Certificate Transparency logs
openssl s_client -connect api.kbase.pt:443 2>/dev/null | openssl x509 -noout -text | grep -A 5 "CT Precertificate"

4. Debugging de Firewall com nftables

O nftables substituiu o iptables como framework de firewall padrão em RHEL 9+, Debian 12+ e Ubuntu 22.04+. A sua principal vantagem para diagnóstico é o suporte nativo a tracing de pacotes sem ferramentas externas.

4.1 Listar Regras Activas

# Listar todas as tabelas, chains e regras
sudo nft list ruleset

# Listar apenas uma tabela específica
sudo nft list table inet filter

# Verificar contadores de pacotes por regra
sudo nft list ruleset -a

4.2 Tracing de Pacotes em Tempo Real

O tracing permite ver exactamente que regra está a processar (ou a descartar) um pacote específico:

# Passo 1: Adicionar regra de trace para um IP específico
sudo nft add rule inet filter input ip saddr 192.168.1.100 nftrace set 1

# Passo 2: Monitorizar o trace em tempo real
sudo nft monitor trace

# Passo 3: Remover a regra de trace após diagnóstico (substituir HANDLE pelo número real)
sudo nft delete rule inet filter input handle HANDLE

4.3 Diagnóstico de Drops Silenciosos

# Ver contadores de drops por chain
sudo nft list ruleset | grep -A 2 "drop\|reject"

# Monitorizar drops em tempo real com conntrack
sudo conntrack -E -e DESTROY | grep -v ASSURED

# Ver tabela de conexões activas
sudo conntrack -L | grep ESTABLISHED | wc -l

Tabela de Referência — Contadores nftables: Normal vs Anomalia:

Contador	✓ Normal	⚠ Anomalia	Causa Provável
Drops na chain INPUT	0 ou residual (tráfego não solicitado)	Crescimento contínuo de IPs legítimos	Regra demasiado restritiva ou IP não whitelisted
Drops na chain FORWARD	0 (se não for router)	Qualquer valor em servidor não-router	ip_forward activo acidentalmente
conntrack entries	< 80% do nf_conntrack_max	> 90% do nf_conntrack_max	Tabela cheia — novas conexões são descartadas silenciosamente

5. Debugging de VPN WireGuard

O WireGuard é silencioso por design: não responde a pacotes não autenticados e não envia keepalives por omissão. Isto torna o diagnóstico diferente do IPsec ou OpenVPN — o foco é no estado do handshake e no fluxo bidirecional de bytes.

5.1 Estado do Túnel

# Ver estado de todos os peers
sudo wg show

# Ver apenas o handshake mais recente
sudo wg show wg0 latest-handshakes

# Ver transferência de dados por peer
sudo wg show wg0 transfer

Saída típica de um túnel saudável:

interface: wg0
  public key: ABC123...
  listening port: 51820

peer: XYZ789...
  endpoint: 203.0.113.1:51820
  allowed ips: 10.0.0.2/32
  latest handshake: 1 minute, 23 seconds ago
  transfer: 142.50 MiB received, 89.20 MiB sent

Tabela de Referência — Estado WireGuard: Normal vs Anomalia:

Campo wg show	✓ Estado Saudável	⚠ Anomalia	Diagnóstico
latest handshake	< 3 minutos	> 5 minutos com tráfego activo	Peer inacessível: IP mudou, firewall bloqueia UDP 51820
transfer (sent/received)	Ambos crescem proporcionalmente	Sent cresce, Received = 0	Pacotes saem mas não voltam: firewall remota bloqueia retorno
endpoint	IP:porta estáveis	IP muda frequentemente	Peer em IP dinâmico sem DNS dinâmico configurado
allowed ips	Subnets correctas e não sobrepostas	0.0.0.0/0 sem split tunneling	Todo o tráfego vai para a VPN — pode quebrar acesso local

5.2 Diagnóstico de MTU em WireGuard

O MTU é a causa mais comum de problemas silenciosos em WireGuard: o ping funciona, mas páginas web não carregam ou transferências de ficheiros falham.

# Testar MTU com ping (ajustar o valor até encontrar o máximo sem fragmentação)
ping -M do -s 1400 10.0.0.1   # Linux
ping -D -s 1400 10.0.0.1      # macOS

# Verificar MTU actual da interface WireGuard
ip link show wg0 | grep mtu

# Definir MTU seguro (1280 é o mínimo IPv6, 1420 é o valor típico para WireGuard sobre IPv4)
sudo ip link set wg0 mtu 1420

6. Debugging de Cloudflare Tunnel

O Cloudflare Tunnel (cloudflared) cria um túnel de saída do servidor para a rede Cloudflare, eliminando a necessidade de abrir portas no firewall. O diagnóstico foca-se no estado do daemon e na conectividade com os PoPs (Points of Presence) da Cloudflare.

6.1 Verificar Estado do Daemon

# Ver estado do serviço
sudo systemctl status cloudflared

# Ver logs em tempo real
sudo journalctl -u cloudflared -f

# Verificar conectividade com Cloudflare
cloudflared tunnel info NOME_DO_TUNNEL

6.2 Diagnóstico de Conectividade

# Testar conectividade com os PoPs da Cloudflare
cloudflared tunnel run --loglevel debug NOME_DO_TUNNEL 2>&1 | grep -E "connected|error|failed"

# Verificar se o DNS está a resolver para Cloudflare
dig +short NOME_DO_TUNNEL.cfargotunnel.com

7. Ferramentas Modernas 2026 — gping, trippy, bandwhich

As ferramentas clássicas (ping, traceroute, iftop) foram complementadas por alternativas modernas escritas em Rust que oferecem visualizações em tempo real e maior precisão.

7.1 gping — Ping com Gráfico em Tempo Real

# Comparar latência de múltiplos hosts em simultâneo
gping 8.8.8.8 1.1.1.1 9.9.9.9

# Comparar latência de um host com o tempo de resposta HTTP
gping --cmd "curl -o /dev/null -s -w '%{time_total}' https://api.empresa.pt" 8.8.8.8

7.2 trippy — Traceroute Moderno com TUI

# Traceroute interactivo com estatísticas por hop
sudo trip api.empresa.pt

# Usar ICMP (padrão) ou UDP
sudo trip --protocol udp api.empresa.pt

# Exportar resultados para JSON
sudo trip api.empresa.pt --report-mode json > traceroute_report.json

7.3 bandwhich — Monitor de Largura de Banda por Processo

# Ver consumo de largura de banda por processo e conexão
sudo bandwhich

# Filtrar por interface específica
sudo bandwhich -i eth0

Tabela de Referência — Ferramentas por Caso de Uso:

Ferramenta	Caso de Uso Principal	Vantagem vs Clássico	Alternativa Clássica
gping	Monitorização de latência visual	Gráfico em tempo real, múltiplos hosts	ping
trippy	Diagnóstico de rota e hops	TUI interactiva, estatísticas por hop, exportação JSON	traceroute / mtr
bandwhich	Identificar processo que consome largura de banda	Visibilidade por processo e conexão simultânea	iftop / nethogs

8. Tuning de TCP/BBR (Camada 4 Performance)

O TCP BBR (Bottleneck Bandwidth and Round-trip propagation time) da Google revolucionou o controlo de congestão. Ao contrário do CUBIC (que reage a perdas de pacotes), o BBR modela o comportamento da rede e mantém a janela de congestão próxima do óptimo mesmo em redes com perda de pacotes.

8.1 Activar BBR

# Verificar algoritmo actual
sysctl net.ipv4.tcp_congestion_control

# Activar BBR (requer kernel 4.9+ e qdisc fq)
echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# Verificar se BBR está activo
sysctl net.ipv4.tcp_congestion_control
# Saída esperada: net.ipv4.tcp_congestion_control = bbr

8.2 Monitorizar Métricas TCP com ss

# Ver métricas detalhadas de conexões TCP activas na porta 443
ss -tin state established '( dport = :443 )'

# Ver todas as conexões com métricas de congestão
ss -tin | grep -E "bbr|cubic|reno"

Saída típica do ss -tin com BBR activo:

ESTAB 0 0 10.0.0.1:443 10.0.0.2:54321
     cubic wscale:7,7 rto:204 rtt:2.5/0.5 ato:40 mss:1448 pmtu:1500
     rcvmss:1448 advmss:1448 cwnd:10 bytes_sent:142857 bytes_retrans:0
     bytes_acked:142857 bytes_received:8192 segs_out:99 segs_in:7
     data_segs_out:98 data_segs_in:1 send 46.3Mbps lastsnd:4 lastrcv:4
     lastack:4 pacing_rate 55.6Mbps delivery_rate 46.3Mbps delivered:99
     app_limited busy:8ms retrans:0/0 rcv_rtt:2.5 rcv_space:65536
     rcv_ssthresh:65536 minrtt:2.1 snd_wnd:65536

Tabela de Referência — Métricas TCP/BBR: Normal vs Anomalia:

Campo ss	✓ Normal	⚠ Anomalia	Causa Provável
retrans:X/Y	0/0 ou < 0.5% de Y	> 2% de Y	Perda de pacotes na rede, cablagem defeituosa, buffer overflow
rto (Retransmission Timeout)	200–400ms	> 1000ms	Latência extrema ou congestionamento severo
rtt (Round Trip Time)	< 5ms (LAN) / < 50ms (WAN)	> 200ms (WAN) ou > 20ms (LAN)	Rota subóptima, congestionamento, VPN com overhead
cwnd (Congestion Window)	Cresce progressivamente sob carga	Cai constantemente para valores baixos (< 10)	Perda de pacotes frequente a forçar slow start
pacing_rate	Próximo da largura de banda contratada	Muito abaixo do esperado sem retransmissões	Receive window do cliente demasiado pequena (rmem)

9. Troubleshooting — 7 Problemas Avançados

Problema 1: TTFB alto mas ping baixo

Sintoma: time_starttransfer > 500ms mas time_connect < 5ms.
Causa: O problema está na aplicação, não na rede. Verificar: queries de base de dados lentas, locks de aplicação, cold start de containers, ou middleware com timeouts.
Diagnóstico: curl -w "%{time_starttransfer}" -o /dev/null -s https://api.empresa.pt/endpoint em múltiplos endpoints para isolar o endpoint lento.

Problema 2: Handshake TLS lento (> 300ms)

Sintoma: time_appconnect - time_connect > 300ms.
Causas comuns: (1) Servidor sem ECDHE — a troca de chaves RSA é mais lenta; (2) OCSP sem stapling — o cliente tem de contactar a CA para verificar revogação; (3) CPU do servidor saturada.
Solução: Activar OCSP stapling no nginx/Apache e preferir cifras ECDHE.

Problema 3: WireGuard conecta mas tráfego não passa

Sintoma: wg show mostra handshake recente mas aplicações falham.
Causa mais comum: MTU incorreto — pacotes grandes são fragmentados e descartados.
Diagnóstico: ping -M do -s 1400 10.0.0.1 — se falhar, reduzir MTU da interface wg0 para 1280 e testar novamente.

Problema 4: Conexões TCP a cair aleatoriamente

Sintoma: Conexões SSH ou HTTPS a cair após alguns minutos de inactividade.
Causa: NAT timeout ou firewall stateful a remover entradas de conntrack.
Solução: Activar TCP keepalive: echo "net.ipv4.tcp_keepalive_time=60" | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Problema 5: DNS resolve mas conexão falha

Sintoma: dig api.empresa.pt retorna IP correcto mas curl falha com “Connection refused”.
Diagnóstico: nc -zv api.empresa.pt 443 — se falhar, o problema é na camada TCP (firewall, serviço não a escutar). Se passar, o problema é no TLS ou na aplicação.

Problema 6: Throughput baixo apesar de latência baixa

Sintoma: RTT de 2ms mas transferências de ficheiros grandes a 10 Mbps numa ligação de 1 Gbps.
Causa: Receive window TCP demasiado pequena — o receptor não consegue aceitar dados suficientemente rápido.
Solução: Aumentar buffers TCP: sysctl -w net.core.rmem_max=134217728 && sysctl -w net.core.wmem_max=134217728

Problema 7: nftables a descartar pacotes silenciosamente

Sintoma: Serviço a funcionar localmente mas inacessível externamente sem mensagem de erro.
Diagnóstico: Activar trace para o IP do cliente e monitorizar com nft monitor trace. O output mostrará exactamente qual regra está a descartar o pacote e em que chain.

10. Cenários Adjacentes

• Diagnóstico em containers Docker/Podman: Usar nsenter -t PID -n para entrar no namespace de rede do container e executar as ferramentas acima directamente no contexto do container.
• Diagnóstico em Kubernetes: kubectl exec -it POD -- curl -w "%{time_total}" -o /dev/null -s https://service para testar conectividade entre pods.
• Diagnóstico em IPv6: Substituir -4 por -6 nos comandos curl e ping. Verificar que o MTU está ajustado para IPv6 (mínimo 1280 bytes).
• Diagnóstico em redes 5G/LTE: Latência base de 20–50ms é normal. RTT > 150ms indica congestionamento da célula ou handover frequente.

11. Boas Práticas e Checklist Final

Área	Verificação	Comando
TLS	Certificado válido e não expirado	openssl s_client -connect host:443 2>/dev/null | openssl x509 -noout -dates
TLS	Apenas TLS 1.2+ activo	nmap --script ssl-enum-ciphers -p 443 host
Firewall	Sem drops em IPs legítimos	nft list ruleset -a | grep -c drop
Firewall	conntrack não saturado	cat /proc/sys/net/netfilter/nf_conntrack_count
WireGuard	Handshake recente (< 3 min)	sudo wg show wg0 latest-handshakes
TCP	BBR activo com qdisc fq	sysctl net.ipv4.tcp_congestion_control && tc qdisc show
TCP	Retransmissões < 0.5%	ss -tin | grep retrans

12. Quick Reference — Comandos Essenciais

Problema	Comando de Diagnóstico
App lenta — decompor latência	curl -o /dev/null -s -w "DNS:%{time_namelookup} TCP:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} Total:%{time_total}" https://host
Certificado TLS — validade e cifras	openssl s_client -connect host:443 -showcerts 2>/dev/null | openssl x509 -noout -dates
Firewall — pacote a ser descartado	nft add rule inet filter input ip saddr IP nftrace set 1 && nft monitor trace
WireGuard — estado do túnel	sudo wg show
TCP — retransmissões e congestão	ss -tin state established '( dport = :443 )'
Largura de banda por processo	sudo bandwhich
Rota e hops com estatísticas	sudo trip host
Latência visual multi-host	gping 8.8.8.8 1.1.1.1 9.9.9.9

13. Glossário Técnico

Termo	Definição
MTU	Maximum Transmission Unit — tamanho máximo de um pacote na camada de rede
MSS	Maximum Segment Size — tamanho máximo do payload TCP (MTU – headers IP e TCP)
BBR	Bottleneck Bandwidth and Round-trip propagation time — algoritmo de congestion control da Google
RTT	Round Trip Time — latência de ida e volta entre dois pontos
PMTUD	Path MTU Discovery — mecanismo para descobrir o MTU máximo num caminho de rede
SNI	Server Name Indication — extensão TLS que indica o hostname ao servidor antes do handshake
OCSP	Online Certificate Status Protocol — verificação de revogação de certificados em tempo real
TLS	Transport Layer Security — protocolo de encriptação da camada de transporte (sucessor de SSL)
AEAD	Authenticated Encryption with Associated Data — modo de encriptação usado em TLS 1.3 (ex: AES-GCM)
QUIC	Protocolo UDP-based que é a base do HTTP/3; elimina head-of-line blocking do TCP
conntrack	Connection tracking — módulo kernel (nf_conntrack) que rastreia o estado de todas as conexões
NAT	Network Address Translation — tradução de endereços IP (ex: router doméstico)
eBPF	Extended Berkeley Packet Filter — framework para executar programas sandboxed no kernel Linux
ASN	Autonomous System Number — identificador único de uma rede gerida por uma entidade (ISP, empresa)
TTFB	Time To First Byte — tempo entre o pedido HTTP e o primeiro byte da resposta