Diagnóstico de rede no Raspberry Pi

Colocar um Raspberry na rede é trivial, ainda mais se configurar a conexão pelo desktop. Mas quando se trata de um produto feito com Raspberry, não podemos contar com a sorte, esperando que nada aconteça, que a rede do cliente esteja em harmonia com seu sistema e outras coisas mais. E quando o sistema perde a comunicação com a rede? Hummm. Por essa razão resolvi escrever esse tutorial de diagnóstico de rede no Raspberry Pi. Vamos ao artigo.

Conceitos básicos de rede

Não vou entrar nos detalhes do modelo conceitual OSI, mas seria bom conhecê-lo, principalmente se sua área é redes. De qualquer modo, vou dispor um desenho de nível macro da comunicação de rede e depois discorro sobre algumas curiosidades.

Comunicação com a Internet

Temos vários modelos e representações possíveis, mas vou citar apenas dois principais; um com rede cabeada e outro com WiFi.

Nesse singelo esboço temos o seguinte para WiFi:

• O Raspberry
• Um roteador WiFi (nem sempre o CPE tem WiFi)
• Um CPE (que é o MODEM de sua operadora)
• A Internet (que já é um corte de uma parte da estrutura, mas suficiente para esse artigo)

Diagnóstico de rede no Raspberry

O primeiro ponto a garantir é a interconectividade. Devemos garantir as credenciais para autenticação. Nesse momento o RPi deve negociar o IP por DHCP (no modo padrão). Os possíveis problemas nesse ponto são:

• Credenciais incorretas - fácil resolução
• Não pega IP
• Conectividade parcial
• Conecta mas não navega

Se as credenciais estiverem incorretas e a configuração foi feita pelo desktop, será fácil ver a falha. Se o WiFi foi configurado pelo wpa_supplicant para, por exemplo, imagem mínima de sistema, já teria que olhar os logs para saber.

Se as credenciais estiverem corretas mas não pega IP, o problema pode estar no roteador WiFi - mais especificamente no servidor DHCP, que pode ter um número limitado de hosts configurado.

Se pegou IP mas informa conectividade parcial, um possível problema é DNS. Se configurou, por exemplo, o DNS do Google (8.8.8.8) e as regras da rede não permitirem resolução de nomes a partir de um DNS externo,  não será possível navegar. Nesse caso, podemos verificar se há conectividade fazendo um ping a um endereço de Internet.

Ainda, pode estar tudo configurado adequadamente, mas não navega. As razões podem ser diversas:

• Firewall da rede bloqueando o Raspberry
• A rota padrão oferecida pelo DHCP não encaminha para o gateway de Internet
• Dois gateways padrão (eth0 e wlan0 conectados)
• A rede tem proxy

Devemos iniciar os testes de diagnóstico de rede no Raspberry de dentro para fora da rede. Assim sendo:

# Pegou IP?
ifconfig wlan0 (ou ifconfig eth0, se cabeado)

# Tem DNS para resolução de nomes?
cat /etc/resolv.conf

# A rota padrão existe? Está correta?
route -n (ou 'ip route show', se não tiver o net-tools instalado)

# O DNS está resolvendo nomes?
ping -c4 www.uol.com.br

# Se não está resolvendo nomes, tem conectividade com o mundo externo?
ping 200.192.43.24 -c4

Se tiver IP, podemos passar para o segundo passo. A saída do comando ifconfig é semelhante a esse:

Se não tiver o comando ifconfig, instale o pacote net-tools:

sudo apt-get install net-tools

Ou, se não tiver como conectar o Raspberry mesmo usando tethering, use o comando ip:

O arquivo /etc/resolv.conf tem um formato semelhante a esse:

Se estiver vazio ou com um DNS que não seja o adequado, reconfigure e teste novamente. Basta editar o arquivo e trocar/adicionar o nameserver. Mas se estiver pegando IP por DHCP, esse arquivo será sobrescrito, por isso esse procedimento só é válido para diagnosticar o problema - exceto se faça modificações no comportamento padrão do sistema, mas deixemos isso para outra ocasião.

A rota padrão é o caminho utilizado para acessar qualquer coisa que seja diferente dos caminhos conhecidos pela rede. Para acessar hosts da mesma rede não é necessário ter um gateway padrão. Se fosse para, por exemplo, um host da rede 192.168.1.0/24 acessar um host da rede 172.16.0.0/16, teria que ter uma rota indicando um host da rede que conhece o caminho para essa rede de classe B. Adicionei uma rota para exemplificar a saída:

Repare na tabela que o gateway padrão é a primeira linha (0.0.0.0    192.168.1.1). Para sair para a rede 172.16.0.0/16 (qualquer host da rede 172.16) o caminho é pelo gateway 192.168.1.2 pela interface wlp3s0 (adicionei a rota em meu laptop, que estava ainda usando nome de interface preditiva).

Se tivermos outros gateways em uma rede mais complexa, pode ser que falte rota em um dos outros pontos. Para saber em que ponto a comunicação está parando, usamos o programa tracerouteou o programa mtr:

Repare que passo por 2 gateways antes de sair da minha rede. Com o comando mtr, os tempos em cada ponto são atualizados, o que ajuda a descobrir gargalos na rede.

Por acaso tem um gargalo terrível no sétimo gateway. Em uma rede complexa (como uma WAN) poderia ser um dos gateways do seu cliente ou algum enlace com parceiro/fornecedor. Como saber de quem é o IP? Com o comando whois:

whois 4.68.75.246

A saída é enorme, mas tem as informações necessárias e suficientes para identificar o responsável pelo IP:

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2021, American Registry for Internet Numbers, Ltd.
#


NetRange:       4.0.0.0 - 4.127.255.255
CIDR:           4.0.0.0/9
NetName:        LVLT-ORG-4-8
NetHandle:      NET-4-0-0-0-1
Parent:         NET4 (NET-4-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       
Organization:   Level 3 Parent, LLC (LPL-141)
RegDate:        1992-12-01
Updated:        2019-07-17
Ref:            https://rdap.arin.net/registry/ip/4.0.0.0



OrgName:        Level 3 Parent, LLC
OrgId:          LPL-141
Address:        100 CenturyLink Drive
City:           Monroe
StateProv:      LA
PostalCode:     71203
Country:        US
RegDate:        2018-02-06
Updated:        2021-01-14
Comment:        ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE ANY ISP ANNOUNCING PORTIONS WITHIN OUR RANGES SHOULD NOT RELY ON PRESENTED LOA'S UNLESS THOSE RANGES ARE ALSO ANNOUNCED TO A CENTURYLINK ASN.
Comment:        
Comment:        All abuse reports MUST include: 
Comment:        * src IP 
Comment:        * dest IP (your IP) 
Comment:        * dest port 
Comment:        * Accurate date/timestamp and timezone of activity 
Comment:        * Intensity/frequency (short log extracts) 
Comment:        * Your contact details (phone and email) 
Comment:        Without these we will be unable to identify the correct owner of the IP address at that point in time.
Comment:        
Comment:        For subpoena or court order please fax 844.254.5800 or refer to our Law Enforcement Support page http://www.centurylink.com/static/Pages/AboutUs/Legal/LawEnforcement/
Ref:            https://rdap.arin.net/registry/entity/LPL-141


OrgTechHandle: IPADD5-ARIN
OrgTechName:   ipaddressing
OrgTechPhone:  +1-877-453-8353 
OrgTechEmail:  ipaddressing@level3.com
OrgTechRef:    https://rdap.arin.net/registry/entity/IPADD5-ARIN

OrgAbuseHandle: LAC56-ARIN
OrgAbuseName:   L3 Abuse Contact
OrgAbusePhone:  +1-877-453-8353 
OrgAbuseEmail:  abuse@level3.com
OrgAbuseRef:    https://rdap.arin.net/registry/entity/LAC56-ARIN


#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2021, American Registry for Internet Numbers, Ltd.
#

O ping é o mais básico dos comandos, pode ser usado antes do route. Ele não só mostra se há alcance ao destino, como também mostra a latência. Existem outras ferramentas para mais diagnósticos, mas não vamos nos aprofundar demais. Com o que foi disposto nesse artigo já deve ser o suficiente para você não passar apuros.

Uma ferramenta que recomendo o estudo é o tcpdump, do qual já fiz o artigo "Usa Samsung Smart? Sua privacidade foi para as nuvens". Também fiz uma interceptação de um Arduino para mostrar o handshake e flags da comunicação. Esse aqui é mais importante ainda.

Por fim, o vídeo da interceptação da TV Samsung.

Um outro problema que pode causar instabilidade é um MAC address duplicado na rede. Isso já aconteceu de fábrica, com placas da ASUS, em uma das empresas que trabalhei. Hora uma máquina navega, hora navega outra. Tínhamos mais de 3.000 computadores na rede e mais de 300 servidores no CPD. Mesmo sendo redes distintas, a interconexão dos sistemas passava por um switch gerenciável. Podemos pegar o endereço MAC pelo comando ifconfig também, assim passar para o administrador da rede, caso solicitado. Ou, se o Raspberry acessa um serviço específico da rede interna e está instável, se for necessário descer até esse nível (layer 2 do modelo OSI), podemos verificar por um tempo a tabela ARP e ver se muda o IP correspondente ao MAC do host que provê o serviço:

Como descobrir as portas abertas no Raspberry?

Esse é o mesmo processo utilizado em qualquer Linux. Aliás, todos eles são comandos de Linux. Para saber as portas abertas no Linux para, por exemplo, saber se um serviço está rodando ou simplesmente para ver se tem portas que não deveriam estar abertas, use o comando:

netstat -naut

A saída mostra o tipo de protocolo IP, local, remoto e estado.

Como descobrir quem está usando uma porta?

Com netstat conseguimos saber o estado de uma porta, mas não quem a está usando. Para descobrir informações como o número do processo, serviço e usuário (além de outras informações), use ( exemplo da porta 22):

 lsof -i :22

Esse comando retorna a informação no formato a seguir (fiz uma conexão local para gerar o processo):

Como descobrir o PID de um processo?

Também faz parte do diagnóstico de rede no Raspberry descobrir os serviços em execução, portas em utilização etc.

Com o pid podemos "matar" o processo em execução. No comando anterior também o temos, mas tem um comando mais específico para o número do processo:

pidof ssh

Se quiser finalizar o processo correspondente, podemos fazê-lo com o comando kill (exemplo para uma conexão ssh, como o anterior):

kill -9 $(pidof ssh)

Tem mais uma forma, mas essa precisa usar sudona frente do comando. Se não for um problema digitar mais 4 letras e um espaço:

sudo fuser -u 22/tcp

Podem ser que existam vários processos usando a porta 22. Para matar todos de uma vez:

sudo fuser -k 22/tcp

Exemplos:

Para ver todos os processos em execução:

ps aux

Para matar os processos relacionados ao ssh por exemplo, poderíamos fazer de uma maneira mais complicada:

ps aux|egrep ssh|while read line; do kill -9 $(echo $line|awk '{print $2}');done

Como desabilitar um serviço?

Se um serviço precisar ser desabilitado (como o ssh), podemos fazer:

sudo systemctl disable ssh

Ou:

sudo update-rc.d ssh disable

Como parar um serviço?

Se já matou a conexão e precisa parar um serviço em execução (por exemplo, ssh):

sudo service ssh stop

Espero que tenha lhe sido útil esse artigo. Siga-nos em nossas redes, que você encontra um pouco abaixo dos menus da página.

Até a próxima!

Autor: Djames Suhanko

Revisão: Ricardo Amaral de Andrade

Inscreva-se no nosso canal Manual do Maker no YouTube.

Também estamos no Instagram.