Como diagnosticar problemas na tua rede, em Linux
Uma das coisas mais chatas quando se está a usar uma distro de Linux, é não ter ou deixar de ter net. Fica-se sem saber o que fazer ou tenta-se resolver o problema sem que haja uma metodologia correta para a deteção e posterior correção da avaria. Como também já passei por esta situação e confesso perceber pouco de redes, encontrei um artigo na Linux Format que quero partilhar convosco, pois me parece ser bastante útil para solucionar ou pelo menos detectar os problemas deste campo.
Para começar devemos ter uma ideia de como é suposto funcionar o acesso à net, desde o nosso servidor de DHCP até à abertura duma página, passando pela placa de rede e pelo IP que nos é atribuido. Devemos ter uma metodologia na procura do problema, começando por baixo no nosso PC até chegar ao servidor de DNS, isto no caso de nunca ter havido acesso à net nesse PC. Se no dia anterior tudo estava bem e de repente o problema apareceu, é mais fácil e rápido encontrar o problema invertendo esta metodologia.
Para começar devemos ter uma ideia de como é suposto funcionar o acesso à net, desde o nosso servidor de DHCP até à abertura duma página, passando pela placa de rede e pelo IP que nos é atribuido. Devemos ter uma metodologia na procura do problema, começando por baixo no nosso PC até chegar ao servidor de DNS, isto no caso de nunca ter havido acesso à net nesse PC. Se no dia anterior tudo estava bem e de repente o problema apareceu, é mais fácil e rápido encontrar o problema invertendo esta metodologia.
- O teu Linux encontra a placa de rede?
Pois é por aqui que se deve começar, será que o Linux que estás a usar encontra o interface de rede? Uma maneira de o saber é através das mensagens que o kernel cria na altura do arranque, digitando este comando dmesg:
#dmesg | grep eth
eth0: ADMtek Comet rev 17 at Port 0x3000, 00:30:05:43:C3:A3, IRQ 19.
eth0: CSR0 01a08000
eth0: Setting full-duplex based on MII#1 link partner capability of 45e1.
eth0: no IPv6 routers present
Ou em alternativa listar os dispositivos com o lspci:
#lspci | grep Ethernet
02:01.0 Ethernet controller: ADMtek NC100 Network Everywhere Fast Ethernet 10/100 (rev 11)
Um output com "failure" significa hardware não suportado, e evitas de telefonar para o apoio do teu ISP.
- O teu Linux tem um IP atribuído?
Assumindo que o kernel sabe que a tua placa de rede está lá, a questão seguinte é descobrir se tens um IP atribuído. Usa o ifconfig para saber a resposta:
#ifconfig
eth0 Encapsulamento do Link: Ethernet Endereço de HW 00:30:05:43:C3:A3
inet end.: 192.168.1.3 Bcast:192.168.1.255 Masc:255.255.255.0
endereço inet6: fe80::230:5ff:fe43:c3a3/64 Escopo:Link
UP BROADCASTRUNNING MULTICAST MTU:1500 Métrica:1
RX packets:4488395 errors:251 dropped:0 overruns:0 frame:253
TX packets:3677883 errors:6 dropped:0 overruns:0 carrier:6
colisões:0 txqueuelen:1000
RX bytes:3860098805 (3.5 GiB) TX bytes:1530189548 (1.4 GiB)
IRQ:19 Endereço de E/S:0x3000
A solução está na segunda linha onde é mostrado o endereço IP atribuído à nossa máquina que é 192.168.1.3. Se não encontrares esta linha é porque não tens IP e mesmo se o tiveres, será que ele é válido na rede onde estás? Pode haver um outro PC na rede que tenha um servidor DHCP mal configurado e ao ligares o PC com o problema de rede, ele agarre um IP não válido. Um outro exemplo é os IPs duma rede doméstica que normalmente vão do 192.168.1.1 até 192.168.1.255 que é o caso acima. É o router quem distribui os IPs, mas caso este PC estivesse atrás dum modem, o IP seria aquele que o meu ISP me atribui e podia ser algo como 85.139.145.14 ou 213.50.145.17 ou outros deste género.
Se o teu PC não tem IP atribuído, verifica os ficheiros de configuração do sistema. A tua interface de rede está configurada para arrancar ao mesmo tempo que o sistema? E está configurado para usar o DHCP (IP dinâmico) ou IP estático? Os ficheiros que precisas de verificar estão localizados nos seguintes locais:
Se o teu PC não tem IP atribuído, verifica os ficheiros de configuração do sistema. A tua interface de rede está configurada para arrancar ao mesmo tempo que o sistema? E está configurado para usar o DHCP (IP dinâmico) ou IP estático? Os ficheiros que precisas de verificar estão localizados nos seguintes locais:
/etc/sysconfig/network-scripts/ifcfg-eth* na Fedora e Red Hat
/etc/sysconfig/network/ifcfg-eth* na SuSE
/etc/network/interfaces na Debian e cópias
Também se pode usar ferramentas gráficas para inspecionar e editar essas configurações como o programa "Ferramentas de Rede".
Caso queiras saber se o DHCP está a ser executado e ver a sua actividade, basta executares o comando dhclient que ele irá mostrar-te os diálogos que estão a decorrer entre o servidor DHCP e a rede:
#dhclient
Internet Software Consortium DHCP Client 2.0pl5
Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
All rights reserved.
Please contribute if you find this software useful.
For info, please visit http://www.isc.org/dhcp-contrib.html
Listening on LPF/lo/
Sending on LPF/lo/
Listening on LPF/eth0/00:30:05:43:c3:a3
Sending on LPF/eth0/00:30:05:43:c3:a3
Sending on Socket/fallback/fallback-net
DHCPDISCOVER on lo to 255.255.255.255 port 67 interval 3
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.1.254
SIOCADDRT: File exists
bound to 192.168.1.3 -- renewal in 951570774 seconds.
Na última linha é mostrado que a interface eth0 obteve o endereço IP 162.168.1.3 do servidor DHCP.
- Consegues pingar o teu router ou outro PC?
#ping -c1 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=128 time=0.201 ms
--- 192.168.1.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.201/0.201/0.201/0.000 ms
Mas podes ter um output do ping como este:
#ping -c1 192.168.1.4
PING 192.168.1.4 (192.168.1.4) 56(84) bytes of data.
From 192.168.1.3 icmp_seq=1 Destination Host Unreachable
--- 192.168.1.4 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
Repara no pormenor "Destination Host Unreachable" que significa que essa máquina deve estar desligada da rede ou fora de serviço. Se não tiveres outro PC, na rede podes sempre pingar o router. Claro que é suposto saberes o IP do teu router, certo? Se não conseguires pingar o teu router, tens um problema local. Se for uma rede sem fios, verifica a cablagem, fichas, e os pequenos LEDs em cada lado da rede.
- A tua firewall está a bloquear a net?
Nesta altura do campeonato não é má ideia verificar se não será a tua firewall que está a estrangular o tráfego da net. Uma maneira rápida de verificar isso é suspender todas as regras da firewall no programa que estás a usar.
Verificas de seguida se o problema está resolvido. Se estiver, o problema está na firewall ou nas regras que ela tem configuradas. Deves então investigar o que se passa com ela ou com as suas regras mas o que não convém mesmo nada é teres a firewall desligada.
- Tens uma ligação ADSL para o teu ISP?
Se consegues pingar o router e as máquinas na tua rede, então é melhor passar à fase seguinte. Se o teu modem ADSl tens os LEDs a piscar indica que pode estar a comunicar com o teu ISP. Podes sempre verificar a página de administração do teu modem/router e verificar o estado da ligação. Desliga o modem e volta a ligá-lo ou desligar a ligação da linha telefónica e volta a repo-la e verificar se há algum erro Se não conseguires a ligação, deves verificar a linha telefónica do router/modem para a tomada. Nem imaginas a quantidade de avarias provocadas por maus contactos nas fichas RITA nas tomadas telefónicas. E se ligares o telefone nessa tomada, tens som no auscultador? Se sim e tudo parecer bem, talvez seja a altura de fazer uma chamadinha para o suporte do teu ISP. Não te esqueças de arranjar um bom sítio para te sentares e esperares pois é bem capaz de demorar...
- Consegues pingar uma máquina externa?
Se tudo está bem até aqui, tens uma ligação normal para o teu ISP, é altura para pingar uma máquina ou site externo à tua rede. Por exemplo pingar o google cujo IP é 66.249.91.147:
#ping -c1 66.249.91.147
PING 66.249.91.147 (66.249.91.147) 56(84) bytes of data.
64 bytes from 66.249.91.147: icmp_seq=1 ttl=240 time=56.3 ms
--- 66.249.91.147 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 56.312/56.312/56.312/0.000 ms
Neste caso funcionou bem sem perda de pacotes. Agora tenta pingar novamente o google usando o o nome DNS:
#ping -c1 www.google.com
PING www.l.google.com (66.249.91.147) 56(84) bytes of data.
64 bytes from ik-in-f147.google.com (66.249.91.147): icmp_seq=1 ttl=240 time=55.3 ms
--- www.l.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 55.351/55.351/55.351/0.000 ms
Tambem foi bem sucedido este teste, pois caso falhasse apareceria algo como:
#ping www.teste.gov
ping: unknown host www.teste.gov
Se conseguisses pingar a máquina pelo IP e não pelo nome DNS, deves investigar a tua configuração DNS. A melhor ferramenta que tens para isso é o dig. Eis um exemplo da utilização do dig com sucesso:
$dig www.google.com
; <<>> DiG 9.4.1-P1 <<>> www.google.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44880 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 7, ADDITIONAL: 7 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 430179 IN CNAME www.l.google.com. www.l.google.com. 41 IN A 66.249.91.99 www.l.google.com. 41 IN A 66.249.91.103 www.l.google.com. 41 IN A 66.249.91.104 www.l.google.com. 41 IN A 66.249.91.147 ;; AUTHORITY SECTION: l.google.com. 80289 IN NS a.l.google.com. l.google.com. 80289 IN NS b.l.google.com. l.google.com. 80289 IN NS c.l.google.com. l.google.com. 80289 IN NS d.l.google.com. l.google.com. 80289 IN NS e.l.google.com. l.google.com. 80289 IN NS f.l.google.com. l.google.com. 80289 IN NS g.l.google.com. ;; ADDITIONAL SECTION: a.l.google.com. 80722 IN A 209.85.139.9 b.l.google.com. 24527 IN A 64.233.179.9 c.l.google.com. 85881 IN A 64.233.161.9 d.l.google.com. 83547 IN A 66.249.93.9 e.l.google.com. 22106 IN A 209.85.137.9 f.l.google.com. 80606 IN A 72.14.235.9 g.l.google.com. 27130 IN A 64.233.167.9 ;; Query time: 13 msec ;; SERVER: 212.113.164.26#53(212.113.164.26) ;; WHEN: Sat Nov 24 17:54:35 2007 ;; MSG SIZE rcvd: 340
Se houvesse falha com o DNS terias um output como este:
$dig www.teste.gov ; <<>> DiG 9.4.1-P1 <<>> www.teste.gov
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42114 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.teste.gov. IN A ;; AUTHORITY SECTION: gov. 1289 IN SOA a.gov.zoneedit.com. govcontact.zoneedit.com. 1195923665 3600 900 1814400 86400 ;; Query time: 15 msec ;; SERVER: 212.113.164.26#53(212.113.164.26) ;; WHEN: Sat Nov 24 17:55:49 2007 ;; MSG SIZE rcvd: 96
Reparem que aparece uma referencia a NXDOMAIN e uma resposta zero a ANSWER. Se o endereço que colocaste como teste existe, como www.google.com, e tiveste este resultado abaixo, há uma falha com o DNS.
- Consegues encontrar o teu servidor DNS?
No segundo caso de falha de DNS era uma situação onde a máquina não conseguia encontrar o servidor DNS. Se isto te acontecer, dá uma olhada no ficheiro /etc/resolv.conf pois é aqui que o teu Linux guarda a informação onde estão os servidores DNS. Tanto uses o DHCP ou IP estático, os endereços IPs dos servidores DNS são guardados neste ficheiro. Tens algum nameserver IP válido nesse ficheiro? Consegues pingá-los directamente?
Se tudo isto falhar no teu diagnóstico, tenta usar o programa de diagnóstico wireshark também conhecido por ethereal. É uma excelente ferramenta para detectar problemas numa rede mas é necessário também já ter um conhecimento mais aprofundado do protocolo TCP/IP .
Espero que este artigo vos tenha utilidade nalgum problema que eventualmente apanhem numa rede ou PC. Caso algo não esteja bem ou queiram contribuir, força aí nos comentários!
Se tudo isto falhar no teu diagnóstico, tenta usar o programa de diagnóstico wireshark também conhecido por ethereal. É uma excelente ferramenta para detectar problemas numa rede mas é necessário também já ter um conhecimento mais aprofundado do protocolo TCP/IP .
Espero que este artigo vos tenha utilidade nalgum problema que eventualmente apanhem numa rede ou PC. Caso algo não esteja bem ou queiram contribuir, força aí nos comentários!
2 comentários:
24 novembro, 2007 20:01
falta o mii-tool / mii-diag para verificar conectividade layer2
25 novembro, 2007 05:40
Valeu Tux. Sempre muito útil.
alessandro simões.
Enviar um comentário