Diagnóstico de Lentidão de Rede com iperf3: Do Cliente ao Servidor

✎ Duarte Spínola | 2026-07-12

O utilizador liga-se ao servidor e tudo está lento. O ficheiro que demorava 10 segundos a transferir agora demora 5 minutos. O RDP está com lag. A replicação da base de dados não termina. O primeiro reflexo é culpar o servidor — mas na maioria dos casos o problema está na rede entre o cliente e o servidor. O iperf3 é a ferramenta definitiva para medir o throughput real entre dois pontos, isolar o problema à camada de rede, e identificar se o gargalo é bandwidth, latência, packet loss, MTU ou configuração TCP. Referência: iperf.fr — documentação oficial.

O iperf3 mede o throughput entre dois pontos — mas não diz onde o problema está no caminho. Para localizar o salto problemático, combinar com mtr (ver secção 7). Para validar se o problema é de rede ou de aplicação, usar iperf3 primeiro e depois comparar com a velocidade da aplicação.

1. O que Está Lento — Camadas de Diagnóstico

A lentidão de acesso a um servidor pode ter origem em cinco camadas. Antes de testar com iperf3, identificar qual camada está afectada.

Camada	Sintoma	Ferramenta de diagnóstico
DNS	Nome demora a resolver, depois é rápido	`dig`, `nslookup`, `Resolve-DnsName`
Rede (bandwidth)	Transferência lenta mas latência baixa	`iperf3` (TCP throughput)
Rede (latência/jitter)	RDP lag, VOIP mau, SSH lento	`iperf3` (UDP), `ping`, `mtr`
Rede (packet loss)	Conexões cortadas, retransmissões	`iperf3` (UDP), `mtr`, `Wireshark`
Rede (MTU/MSS)	Transferências grandes falham, pequenas OK	`ping -f -l`, `iperf3 -M`
Servidor (CPU/RAM/IO)	Rede OK mas aplicação lenta	PerfMon, `top`, `iostat`
Aplicação	Rede e servidor OK mas app lenta	Profiler, logs da aplicação

O iperf3 diagnostica as camadas de rede (bandwidth, latência, jitter, packet loss, MTU). Se o iperf3 mostra throughput normal, o problema está no servidor ou na aplicação.

2. Instalar iperf3

2.1 Linux (Debian/Ubuntu)

sudo apt update

sudo apt install iperf3

2.2 Linux (RHEL/Fedora/Rocky)

sudo dnf install iperf3

2.3 Windows

Descarregar de iperf.fr — extrair o .zip e executar iperf3.exe a partir da linha de comandos. Não requer instalação.

2.4 macOS

brew install iperf3

3. Teste Básico — TCP Throughput

O iperf3 funciona em modo cliente/servidor. Primeiro iniciar o servidor num dos pontos (normalmente o servidor de destino), depois correr o cliente a partir do outro ponto (o PC do utilizador).

3.1 Iniciar o servidor (no servidor de destino)

<span style=”color:#6c7086;”># Iniciar servidor iperf3 na porta padrão (5201)</span>

iperf3 -s
<span style=”color:#6c7086;”># Ou numa porta específica</span>

iperf3 -s -p 5201
<span style=”color:#6c7086;”># Em background com timeout</span>

iperf3 -s -D –one-off

3.2 Correr o cliente (no PC do utilizador)

<span style=”color:#6c7086;”># Teste TCP básico — 10 segundos</span>

iperf3 -c 192.168.1.100
<span style=”color:#6c7086;”># Especificar duração (60 segundos para resultado mais estável)</span>

iperf3 -c 192.168.1.100 -t 60
<span style=”color:#6c7086;”># Especificar porta (se o servidor usa porta diferente)</span>

iperf3 -c 192.168.1.100 -p 5201
<span style=”color:#6c7086;”># Output em JSON (para processamento automático)</span>

iperf3 -c 192.168.1.100 -J

3.3 Interpretar o resultado

Connecting to host 192.168.1.100, port 5201

[  5] local 192.168.1.50 port 49152 connected to 192.168.1.100 port 5201

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd

[  5]   0.00-1.00   sec  112 MBytes   940 Mbits/sec    0   256 KBytes

[  5]   1.00-2.00   sec  112 MBytes   940 Mbits/sec    0   256 KBytes

[  5]   2.00-3.00   sec  112 MBytes   940 Mbits/sec    0   256 KBytes

– – – – – – – – – – – – – – – – – – – – – – – – –

[ ID] Interval           Transfer     Bitrate         Retr

[  5]   0.00-10.00  sec  1.10 GBytes   940 Mbits/sec    0   sender

[  5]   0.00-10.00  sec  1.10 GBytes   940 Mbits/sec         receiver

Colunas importantes:

Coluna	Significado	Atenção se…
Transfer	Bytes transferidos no intervalo	Menor que o esperado
Bitrate	Velocidade (bits por segundo)	Menor que a largura de banda contratada
Retr	Retransmissões TCP	>0 indica packet loss ou congestionamento
Cwnd	TCP congestion window	Pequeno e não cresce = congestionamento

3.4 O que é um resultado “bom”

Ligação	Throughput esperado (iperf3 TCP)
Ethernet 1 Gbps	900-940 Mbps
Ethernet 10 Gbps	8-9.4 Gbps
Wi-Fi 6 (ax)	500-1200 Mbps
Wi-Fi 5 (ac)	200-600 Mbps
Fibra 200 Mbps (WAN)	180-195 Mbps
VPN site-to-site	50-80% da largura de banda
WAN com CGNAT	Variável, tipicamente inferior

Se o iperf3 mostra 900+ Mbps numa ligação local de 1 Gbps, a rede está saudável. Se mostra 50 Mbps numa ligação de 1 Gbps, há um problema.

4. Teste UDP — Latência, Jitter e Packet Loss

O modo TCP mede throughput mas não mostra latência nem packet loss directamente. O modo UDP mede这三 três métricas simultaneamente.

<span style=”color:#6c7086;”># Teste UDP com 100 Mbps durante 30 segundos</span>

iperf3 -c 192.168.1.100 -u -b 100M -t 30
<span style=”color:#6c7086;”># Teste UDP com 1 Gbps (para detectar packet loss em ligações rápidas)</span>

iperf3 -c 192.168.1.100 -u -b 1G -t 30
<span style=”color:#6c7086;”># Teste UDP bidireccional (upload e download simultâneos)</span>

iperf3 -c 192.168.1.100 -u -b 100M -t 30 –bidir

Output:

[  5]   0.00-10.00  sec  119 MBytes  100 Mbits/sec  0.023 ms  0/84952 (0%)  sender

[  5]   0.00-10.00  sec  119 MBytes  99.8 Mbits/sec  0.025 ms  0/84996 (0.04%)  receiver

Métrica	Significado	Valor aceitável	Problema se…
Bitrate	Throughput UDP	Próximo do `-b` especificado	Significativamente inferior ao pedido
Jitter	Variação de latência entre pacotes	<5 ms (LAN), <30 ms (WAN)	>50 ms causa problemas em VOIP/VDI
Lost/Total	Pacotes perdidos	0% (ideal), <0.1%	>1% indica problema de rede
%	Percentagem de packet loss	0%	>1% é inaceitável para produção

Interpretação de packet loss

Packet loss	Impacto	Causa provável
0%	Nenhum	Rede saudável
0.01-0.1%	Negligenciável	Evento transitório
0.1-1%	Atenção	Congestionamento, buffer small
1-5%	Problema sério	Congestionamento, cabo mau, switch faulty
>5%	Crítico	Cabo danificado, duplex mismatch, interference

5. Testes Avançados para Isolar o Problema

5.1 Teste bidireccional (upload vs download)

Muitas vezes o download está bom mas o upload está lento (ou vice-versa). Testar ambos:

<span style=”color:#6c7086;”># Download do servidor para o cliente (reversed)</span>

iperf3 -c 192.168.1.100 -R -t 30
<span style=”color:#6c7086;”># Upload do cliente para o servidor (normal)</span>

iperf3 -c 192.168.1.100 -t 30
<span style=”color:#6c7086;”># Bidireccional simultâneo</span>

iperf3 -c 192.168.1.100 –bidir -t 30

Se o upload é 900 Mbps e o download é 50 Mbps (ou vice-versa), há um problema de duplex ou QoS que afecta apenas uma direcção.

5.2 Teste com múltiplas ligações paralelas

Uma única ligação TCP pode não conseguir saturar uma ligação de alta velocidade devido ao TCP window size. Usar ligações paralelas:

<span style=”color:#6c7086;”># 8 ligações paralelas — útil para ligações >1 Gbps ou WAN com latência alta</span>

iperf3 -c 192.168.1.100 -P 8 -t 30

Se uma ligação atinge 50 Mbps mas 8 ligações paralelas atingem 800 Mbps, o problema é TCP window size ou latência alta (ver secção 6).

5.3 Teste com tamanhos de janela diferentes

O TCP window size determina quanta data não confirmada o remetente pode enviar. Em ligações de alta latência, um window pequeno limita o throughput.

<span style=”color:#6c7086;”># Window de 256 KB (útil em WAN com latência alta)</span>

iperf3 -c 192.168.1.100 -w 256K -t 30
<span style=”color:#6c7086;”># Window de 1 MB</span>

iperf3 -c 192.168.1.100 -w 1M -t 30
<span style=”color:#6c7086;”># Window automático (deixar o TCP decidir)</span>

iperf3 -c 192.168.1.100 -t 30

5.4 Teste com diferentes tamanhos de pacote (MTU)

Problemas de MTU causam lentidão em transferências grandes mas não em pequenas (o small packet passa mas o large packet fragmenta ou é dropped).

<span style=”color:#6c7086;”># Testar com MSS de 1400 (MTU ~1440) — detecta problemas de PMTU</span>

iperf3 -c 192.168.1.100 -M 1400 -t 30
<span style=”color:#6c7086;”># Comparar com MSS padrão (1460 = MTU 1500)</span>

iperf3 -c 192.168.1.100 -M 1460 -t 30

Se o throughput com MSS 1400 é significativamente melhor que com MSS 1460, há um problema de MTU/PMTU no caminho.

6. Tuning TCP para Diagnóstico

Quando o iperf3 mostra throughput baixo numa ligação de alta velocidade e baixa latência, o problema pode ser configuração TCP do sistema operativo.

6.1 Verificar BDP (Bandwidth-Delay Product)

O BDP determina o TCP window necessário para saturar uma ligação:

BDP = bandwidth × RTT
Exemplo: 1 Gbps × 10ms RTT

BDP = 1,000,000,000 × 0.01 = 10,000,000 bits = 1.25 MB

O TCP window deve ser pelo menos igual ao BDP. Se for menor, o throughput será limitado.

<span style=”color:#6c7086;”># Em Linux, verificar configuração TCP actual</span>

sysctl net.ipv4.tcp_window_scaling

sysctl net.ipv4.tcp_rmem

sysctl net.ipv4.tcp_wmem
<span style=”color:#6c7086;”># Activar TCP window scaling (se desactivado)</span>

sudo sysctl -w net.ipv4.tcp_window_scaling=1
<span style=”color:#6c7086;”># Ajustar buffers de leitura/escrita TCP</span>

sudo sysctl -w net.ipv4.tcp_rmem=’4096 87380 16777216′

sudo sysctl -w net.ipv4.tcp_wmem=’4096 65536 16777216′

6.2 Activar BBR congestion control (Linux 4.9+)

O BBR (Bottleneck Bandwidth and Round-trip propagation time) é um algoritmo de congestion control do Google que melhora significativamente o throughput em ligações WAN.

<span style=”color:#6c7086;”># Verificar algoritmo actual</span>

sysctl net.ipv4.tcp_congestion_control
<span style=”color:#6c7086;”># Activar BBR</span>

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
<span style=”color:#6c7086;”># Verificar</span>

sysctl net.ipv4.tcp_congestion_control

<span style=”color:#6c7086;”># Output esperado: net.ipv4.tcp_congestion_control = bbr</span>

6.3 Em Windows

<span style=”color:#6c7086;”># Verificar configuração TCP</span>

Get-NetTCPSetting | Select SettingName, AutoTuningLevelLocal
<span style=”color:#6c7086;”># Activar auto-tuning (se desactivado)</span>

Set-NetTCPSetting -SettingName Internet -AutoTuningLevelLocal Normal
<span style=”color:#6c7086;”># Verificar MTU</span>

netsh interface ipv4 show subinterfaces
<span style=”color:#6c7086;”># Alterar MTU (se necessário)</span>

netsh interface ipv4 set subinterface “Ethernet” mtu=1500 store=persistent

7. Combinar iperf3 com Outras Ferramentas

O iperf3 mede o throughput entre dois pontos. Para localizar onde o problema está no caminho, usar:

7.1 mtr — Traceroute em tempo real

O mtr combina traceroute com ping, mostrando latência e packet loss por salto.

<span style=”color:#6c7086;”># mtr durante 100 ciclos (para estatística fiável)</span>

mtr -c 100 –report 192.168.1.100
<span style=”color:#6c7086;”># Output:</span>

<span style=”color:#6c7086;”># Host                           Loss%   Snt    Last   Avg  Best  Wrst StDev</span>

<span style=”color:#6c7086;”># 1. 192.168.1.1                  0.0%   100    0.5   0.5   0.4   0.8   0.1</span>

<span style=”color:#6c7086;”># 2. 10.0.0.1                     0.0%   100    2.1   2.0   1.8   2.5   0.1</span>

<span style=”color:#6c7086;”># 3. 192.168.1.100               20.0%   100    5.0   5.2   4.8   6.0   0.3</span>

Se o salto 3 tem 20% packet loss mas o salto 2 tem 0%, o problema está entre o salto 2 e o salto 3. Referência: mtr.tools.

7.2 ping — Latência base

<span style=”color:#6c7086;”># Ping com 100 pacotes para estatística</span>

ping -c 100 192.168.1.100
<span style=”color:#6c7086;”># Windows — tamanho específico para testar MTU</span>

ping -f -l 1472 192.168.1.100

<span style=”color:#6c7086;”># Se falhar, tentar 1400, 1300, até encontrar o maior que passa</span>

7.3 PSPing — Alternativa Microsoft

O PSPing (Sysinternals) faz ping TCP (não apenas ICMP) e throughput testing. Útil quando ICMP é bloqueado por firewall.

<span style=”color:#6c7086;”># Ping TCP à porta do servidor</span>

psping -t 192.168.1.100:445
<span style=”color:#6c7086;”># Teste de throughput TCP (como iperf3)</span>

psping -b -l 8k -n 10000 192.168.1.100:445

7.4 Wireshark — Análise de pacotes

Se o iperf3 mostra retransmissões, o Wireshark pode identificar o tipo exacto de problema:

Filtros úteis:

tcp.analysis.retransmission      — retransmissões TCP

tcp.analysis.fast_retransmission  — fast retransmit (3 duplicate ACKs)

tcp.analysis.duplicate_ack        — duplicate ACKs (indica packet loss)

tcp.analysis.zero_window          — receiver não consegue acompanhar

icmp.type == 3 && icmp.code == 4  — ICMP Fragmentation Needed (PMTU problem)

8. Cenários Comuns de Diagnóstico

Cenário 1: WAN lenta (VPN site-to-site)

Sintoma: VPN entre escritório e datacenter a 20 Mbps em vez de 100 Mbps.

<span style=”color:#6c7086;”># 1. iperf3 TCP sem VPN (baseline)</span>

iperf3 -c 192.168.1.100 -t 30

<span style=”color:#6c7086;”># Resultado: 940 Mbps (LAN directa OK)</span>
<span style=”color:#6c7086;”># 2. iperf3 TCP através da VPN</span>

iperf3 -c 10.10.10.100 -t 30

<span style=”color:#6c7086;”># Resultado: 20 Mbps (VPN é o bottleneck)</span>
<span style=”color:#6c7086;”># 3. iperf3 UDP para ver packet loss</span>

iperf3 -c 10.10.10.100 -u -b 100M -t 30

<span style=”color:#6c7086;”># Resultado: 18 Mbps, 5% packet loss, 45ms jitter</span>
<span style=”color:#6c7086;”># 4. mtr para localizar o salto problemático</span>

mtr -c 100 –report 10.10.10.100

<span style=”color:#6c7086;”># Resultado: salto 4 (VPN gateway remoto) tem 5% loss</span>
<span style=”color:#6c7086;”># Conclusão: VPN gateway remoto está a dropping packets.</span>

<span style=”color:#6c7086;”># Acção: verificar CPU do VPN gateway, MTU da VPN tunnel (reduzir para 1400)</span>

Cenário 2: Transferência de ficheiros lenta

Sintoma: SMB copy a 5 MB/s em ligação de 1 Gbps.

<span style=”color:#6c7086;”># 1. iperf3 TCP (testar rede isolada de SMB)</span>

iperf3 -c 192.168.1.100 -t 30

<span style=”color:#6c7086;”># Resultado: 940 Mbps (rede OK)</span>
<span style=”color:#6c7086;”># 2. PSPing TCP à porta 445 (SMB)</span>

psping -t 192.168.1.100:445

<span style=”color:#6c7086;”># Resultado: 20ms latency (esperado <1ms em LAN)</span>
<span style=”color:#6c7086;”># 3. iperf3 com ligações paralelas (testar SMB multichannel)</span>

iperf3 -c 192.168.1.100 -P 4 -t 30

<span style=”color:#6c7086;”># Resultado: 4 × 940 Mbps = 3.7 Gbps</span>
<span style=”color:#6c7086;”># Conclusão: rede OK, problema é SMB.</span>

<span style=”color:#6c7086;”># Acção: verificar SMB version (SMB1 é lento), SMB signing, e antivirus a scanar tráfego</span>

Cenário 3: RDP lag em WAN

Sintoma: RDP para servidor remoto com lag e cortes.

<span style=”color:#6c7086;”># 1. Ping para baseline de latência</span>

ping -c 100 servidorremoto.exemplo.pt

<span style=”color:#6c7086;”># Resultado: avg 35ms, 0% loss (latência OK para RDP)</span>
<span style=”color:#6c7086;”># 2. iperf3 UDP para jitter</span>

iperf3 -c servidorremoto -u -b 10M -t 60

<span style=”color:#6c7086;”># Resultado: 8 Mbps, 15ms jitter, 2% loss</span>
<span style=”color:#6c7086;”># Conclusão: packet loss e jitter causam lag no RDP.</span>

<span style=”color:#6c7086;”># Acção: verificar QoS no router, priorizar RDP (UDP 3389 em 2022+)</span>

Cenário 4: MTU / Fragmentação

Sintoma: Transferências pequenas OK, transferências grandes timeout.

<span style=”color:#6c7086;”># 1. iperf3 TCP normal</span>

iperf3 -c 192.168.1.100 -t 10

<span style=”color:#6c7086;”># Resultado: 940 Mbps (OK com pacotes pequenos)</span>
<span style=”color:#6c7086;”># 2. iperf3 com MSS grande (forçar pacotes grandes)</span>

iperf3 -c 192.168.1.100 -M 1460 -t 30

<span style=”color:#6c7086;”># Resultado: 50 Mbps, muitas retransmissões</span>
<span style=”color:#6c7086;”># 3. iperf3 com MSS pequeno</span>

iperf3 -c 192.168.1.100 -M 1300 -t 30

<span style=”color:#6c7086;”># Resultado: 940 Mbps (OK)</span>
<span style=”color:#6c7086;”># Conclusão: MTU problem no caminho.</span>

<span style=”color:#6c7086;”># Acção: verificar PMTU, reduzir MTU na interface ou tunnel</span>

9. Erros Comuns a Evitar

Testar com apenas 10 segundos — em ligações WAN com latência alta, 10 segundos não é suficiente para o TCP window crescer. Usar -t 60 no mínimo.
Esquecer de testar UDP — TCP esconde packet loss através de retransmissões. Só o UDP mostra o packet loss real.
Correr iperf3 em horas de pico — o throughput vai ser afectado por outro tráfego. Testar fora de horas de pico para obter baseline.
Não testar em ambos os sentidos — muitas vezes só se testa upload. Usar -R para testar download e --bidir para ambos.
Confiar apenas no iperf3 — o iperf3 mede a rede entre dois pontos. Se o problema é DNS, aplicação, ou servidor, o iperf3 não detecta.
Correr servidor iperf3 sem firewall — o iperf3 -s abre a porta 5201 a toda a rede. Restringir com firewall: iptables -A INPUT -p tcp --dport 5201 -s 192.168.1.0/24 -j ACCEPT.
Usar iperf (v2) em vez de iperf3 — o iperf2 é a versão antiga. iperf3 tem melhores features (JSON output, UDP bidir, múltiplas ligações paralelas).
Ignorar retransmissões — se o iperf3 mostra 940 Mbps mas com 500 retransmissões, a rede não está saudável. Investigar o packet loss com mtr.

10. Checklist de Diagnóstico

Identificar a camada — DNS, rede, servidor ou aplicação (tabela da secção 1)
Instalar iperf3 em cliente e servidor
Iniciar servidor — iperf3 -s no servidor de destino
Teste TCP — iperf3 -c <IP> -t 60 para throughput base
Verificar retransmissões — coluna Retr no output
Teste UDP — iperf3 -c <IP> -u -b <bandwidth> -t 30 para jitter e packet loss
Teste bidireccional — iperf3 -c <IP> -R para download, iperf3 -c <IP> para upload
Teste paralelo — iperf3 -c <IP> -P 8 se uma ligação não satura a largura de banda
Teste MTU — iperf3 -c <IP> -M 1400 vs -M 1460 para detectar fragmentação
mtr — mtr -c 100 --report <IP> para localizar o salto problemático
PSPing (Windows) — psping <IP>:<porta> para latência TCP se ICMP bloqueado
Wireshark — se packet loss detectado, captura para analisar o tipo de problema
Acção — baseado no diagnóstico, aplicar a correção (QoS, MTU, VPN tuning, BBR, etc.)

11. Artigos Relacionados

Thiago Carvcalho em FiberGateway Meo – Configurar USB PEN/Disco16 Junho, 2026
Consegui seguindo os passos, agora alguem pode me ajudar a configurar o navegador no meu telemovel para ter acesso remoto?
Duarte Spínola em Configuração de Email @mail.telepac.pt IMAP / POP6 Junho, 2026
Poderá recuperar a password em https://login.sapo.pt/, no entanto poderá estar a solicitar as credências. As condições de utilização de serviço…
José Henriques em Configuração de Email @mail.telepac.pt IMAP / POP1 Junho, 2026
Tenho recebido no meu iPhone esta mensagem "Digite a palavra-passe da conta IMAP “Sapo” " Não me lembro da palavra…
Paulo Tadeu em Configuração de Email @mail.telepac.pt IMAP / POP20 Abril, 2026
Viva, fantástico recordar as configurações do email da Telepac, saudosos tempos. Obrigado
Duarte Spínola em Configuração de Email Sapo IMAP / POP22 Março, 2026
Deves contatar o suporte do serviço de email respectivo. Este site não tem relação com a Meo/Telepac. Nós partilhamos informação…

Diagnóstico de Lentidão de Rede com iperf3: Do Cliente ao Servidor

Pesquisa Online

Diagnóstico de Lentidão de Rede com iperf3: Do Cliente ao Servidor

1. O que Está Lento — Camadas de Diagnóstico

2. Instalar iperf3

2.1 Linux (Debian/Ubuntu)

2.2 Linux (RHEL/Fedora/Rocky)

2.3 Windows

2.4 macOS

3. Teste Básico — TCP Throughput

3.1 Iniciar o servidor (no servidor de destino)

3.2 Correr o cliente (no PC do utilizador)

3.3 Interpretar o resultado

3.4 O que é um resultado “bom”

4. Teste UDP — Latência, Jitter e Packet Loss

Interpretação de packet loss

5. Testes Avançados para Isolar o Problema

5.1 Teste bidireccional (upload vs download)

5.2 Teste com múltiplas ligações paralelas

5.3 Teste com tamanhos de janela diferentes

5.4 Teste com diferentes tamanhos de pacote (MTU)

6. Tuning TCP para Diagnóstico

6.1 Verificar BDP (Bandwidth-Delay Product)

6.2 Activar BBR congestion control (Linux 4.9+)

6.3 Em Windows

7. Combinar iperf3 com Outras Ferramentas

7.1 mtr — Traceroute em tempo real

7.2 ping — Latência base

7.3 PSPing — Alternativa Microsoft

7.4 Wireshark — Análise de pacotes

8. Cenários Comuns de Diagnóstico

Cenário 1: WAN lenta (VPN site-to-site)

Cenário 2: Transferência de ficheiros lenta

Cenário 3: RDP lag em WAN

Cenário 4: MTU / Fragmentação

9. Erros Comuns a Evitar

10. Checklist de Diagnóstico

11. Artigos Relacionados

Este artigo foi útil?

Artigos Relacionados

Duarte Spínola

Deixe um Comentário