Product SiteDocumentation Site

10.8. Ferramentas de Diagnóstico de Rede

Quando uma aplicação de rede não funciona como o esperado, é importante poder olhar sob o capô. E mesmo quando tudo parece rodar suave, fazer um diagnóstico da rede pode ajudar a garantir que tudo está funcionando como deveria. Várias ferramentas de diagóstico existem para esse propósito; cada uma opera em um nível diferente.

10.8.1. Diagnóstico Local: netstat

Vamos primeiro mencionar o comando netstat (do pacote net-tools); ele exibe um sumário momentâneo da atividade de rede da máquina. Quando invocado sem argumentos, esse comando lista todas as conexões abertas; essa lista pode ser bem longa já que inclui muitos soquetes Unix-domain (amplamente usados por daemons) que não tem nada a ver com redes (por exemplo, comunicação dbus, tráfego X11 e comunicações entre sistema de arquivos virtuais e o desktop).
Invocações comuns entretanto usam opções que alteram o comportamento do netstat. As opções mais comumente usadas são:
  • -t, que filtra os resultados para incluir apenas conexões TCP;
  • -u, que funciona de maneira similar para conexões UDP; essas opções não são mutuamente exclusivas, e uma delas é suficiente para parar de exibir conexões Unix-domain;
  • -a, para também listar soquetes ativos (esperando por conexões de entrada);
  • -n, para exibir os resultados com números: endereço IP (sem resolução DNS), números de porta (sem as aliases como definidas em /etc/services) e ids de usuários (sem nomes de login);
  • -p, para listar os processos envolvidos; essa opção só é útil quando o netstat é executado como root, já que usuários normais apenas verão seus próprios processos;
  • -c, para atualizar continuamente a lista de conexões.
Outras opções, documentadas na página de manual netstat(8), fornecem um controle ainda mais apurado sobre os resultados exibidos. Na prática, as cinco primeiras opções são tão comumente usadas em conjunto que administradores de sistemas e de redes praticamente usam netstat -tupan como um reflexo. Resultados típicos em uma máquina levemente carregada devem se parecer com o seguinte:
# netstat -tupan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      397/rpcbind     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      431/sshd        
tcp        0      0 0.0.0.0:36568           0.0.0.0:*               LISTEN      407/rpc.statd   
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      762/exim4       
tcp        0    272 192.168.1.242:22        192.168.1.129:44452     ESTABLISHED 1172/sshd: roland [
tcp6       0      0 :::111                  :::*                    LISTEN      397/rpcbind     
tcp6       0      0 :::22                   :::*                    LISTEN      431/sshd        
tcp6       0      0 ::1:25                  :::*                    LISTEN      762/exim4       
tcp6       0      0 :::35210                :::*                    LISTEN      407/rpc.statd   
udp        0      0 0.0.0.0:39376           0.0.0.0:*                           916/dhclient    
udp        0      0 0.0.0.0:996             0.0.0.0:*                           397/rpcbind     
udp        0      0 127.0.0.1:1007          0.0.0.0:*                           407/rpc.statd   
udp        0      0 0.0.0.0:68              0.0.0.0:*                           916/dhclient    
udp        0      0 0.0.0.0:48720           0.0.0.0:*                           451/avahi-daemon: r
udp        0      0 0.0.0.0:111             0.0.0.0:*                           397/rpcbind     
udp        0      0 192.168.1.242:123       0.0.0.0:*                           539/ntpd        
udp        0      0 127.0.0.1:123           0.0.0.0:*                           539/ntpd        
udp        0      0 0.0.0.0:123             0.0.0.0:*                           539/ntpd        
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           451/avahi-daemon: r
udp        0      0 0.0.0.0:39172           0.0.0.0:*                           407/rpc.statd   
udp6       0      0 :::996                  :::*                                397/rpcbind     
udp6       0      0 :::34277                :::*                                407/rpc.statd   
udp6       0      0 :::54852                :::*                                916/dhclient    
udp6       0      0 :::111                  :::*                                397/rpcbind     
udp6       0      0 :::38007                :::*                                451/avahi-daemon: r
udp6       0      0 fe80::5054:ff:fe99::123 :::*                                539/ntpd        
udp6       0      0 2001:bc8:3a7e:210:a:123 :::*                                539/ntpd        
udp6       0      0 2001:bc8:3a7e:210:5:123 :::*                                539/ntpd        
udp6       0      0 ::1:123                 :::*                                539/ntpd        
udp6       0      0 :::123                  :::*                                539/ntpd        
udp6       0      0 :::5353                 :::*                                451/avahi-daemon: r
Como esperado, isso lista conexões estabelecidas, duas conexões SSH neste caso, e aplicações esperando por conexões de entrada (listadas como LISTEN), notavelmente o servidor de email Exim4 ouvindo na porta 25.

10.8.2. Diagnóstico Remoto: nmap

nmap (em pacote de nome similar) é, de certa forma, o equivalente remoto do netstat. ele pode escanear um conjunto de portas conhecidas em um ou mais servidores remotos, e listar as portas aonde uma aplicação se encontra para responder a conexões de entrada. Além do mais, o nmap é capaz de identificar algumas dessas aplicações, algumas vezes até seu número de versão. A contrapartida dessa ferramenta é que, como ela é executada remotamente, ela não pode fornecer informações sobre processos ou usuários; contudo, ela pode operar em vários alvos de uma vez.
Uma invocação típica do nmap usa apenas a opção -A (para que o nmap tente identificar as versões dos softwares no servidor que ele encontrar) seguido de um ou mais endereços IP ou nomes DNS das máquinas a escanear. Novamente, existem muitas outras opções para refinar o comportamento do nmap; por favor veja a documentação na página de manual nmap(1).
# nmap mirtuel

Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-09 16:46 CET
Nmap scan report for mirtuel (192.168.1.242)
Host is up (0.000013s latency).
rDNS record for 192.168.1.242: mirtuel.internal.placard.fr.eu.org
Not shown: 998 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
111/tcp open  rpcbind

Nmap done: 1 IP address (1 host up) scanned in 2.41 seconds
# nmap -A localhost

Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-09 16:46 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000013s latency).
Other addresses for localhost (not scanned): 127.0.0.1
Not shown: 997 closed ports
PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 6.7p1 Debian 3 (protocol 2.0)
|_ssh-hostkey: ERROR: Script execution failed (use -d to debug)
25/tcp  open  smtp    Exim smtpd 4.84
| smtp-commands: mirtuel Hello localhost [127.0.0.1], SIZE 52428800, 8BITMIME, PIPELINING, HELP, 
|_ Commands supported: AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP 
111/tcp open  rpcbind 2-4 (RPC #100000)
| rpcinfo: 
|   program version   port/proto  service
|   100000  2,3,4        111/tcp  rpcbind
|   100000  2,3,4        111/udp  rpcbind
|   100024  1          36568/tcp  status
|_  100024  1          39172/udp  status
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.7 - 3.15
Network Distance: 0 hops
Service Info: Host: mirtuel; OS: Linux; CPE: cpe:/o:linux:linux_kernel

OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.54 seconds
Como esperado, as aplicações SSH e Exim4 estão listadas. Note que nem todas as aplicações escutam em todos os endereços IP; como o Exim4 só é acessível pela interface loopback lo, ele só aparece durante uma análise do localhost e não quando se escaneia o mirtuel (que é mapeado na interface eth0 na mesma máquina).

10.8.3. Sniffers: tcpdump e wireshark

Às vezes, é preciso olhar o que realmente acontece no fio, pacote a pacote. Nesses casos é necessário invocar um “analizador de quadro”, mais comumente conhecido como sniffer. Uma ferramenta dessas observa todos os pacotes que chegam em uma determinada interface de rede, e os exibe de uma maneira amigável.
A venerável ferramenta neste domínio é o tcpdump, disponível como ferramenta padrão em uma grande variedade de plataformas. Ela permite muitos tipos de captura de tráfego de rede, mas a representação desse tráfego se mantém obscura. Nós então não iremos descrevê-la muito detalhadamente.
Uma ferramenta mais recente (e mais moderna), wireshark (do pacote wireshark), se tornou a nova referência em análise de tráfego de rede devido a seus vários módulos de "decoding" que permitem uma análise simplificada dos pacotes capturados. Os pacotes são exibidos graficamente organizados com base nas camadas de protocolo. Isso permite ao usuário visualizar todos os protocolos envolvidos em um pacote. Por exemplo, dado um pacote contendo uma requisição HTTP, o wireshark exibe, separadamente, a informação referente a camada física, camada Ethernet, informação do pacote IP, parâmetros de conexão TCP, e finalmente a própria requisição HTTP.
O analisador de tráfego de rede wireshark

Figura 10.1. O analisador de tráfego de rede wireshark

Em nosso exemplo, os pacotes que viajam pelo SSH são filtrados (pelo filtro !tcp.port == 22). O pacote exibido no momento foi desenvolvido na camada HTTP.