Concrete Logo
Hamburger button

Infra para Devs

  • Blog
  • 23 de Janeiro de 2015
Share

Um belo dia você foi testar a aplicação que está desenvolvendo e descobriu que ela não responde como deveria. As consultas que ela enviava para o banco não retornam nada, e o navegador está calado.

Por onde começar? Bom, hoje você irá partir para um troubleshooting de rede. Existem várias situações e abordagens que envolvem esse assunto, mas iremos abordar a seguinte:

O cliente será a máquina de aplicação. Você se conectará a ela e ao servidor que roda o banco. Imaginemos que são duas VMs.

Considerando que você já confirmou que a aplicação está no ar e a configuração de rede está igual a quando tudo estava rodando, neste host as coisas não mudaram.

Iremos agora para o servidor. Conecte-se a ele via ssh e começamos por aí as investigações, ok?

Infra:

Temos dois hosts envolvidos, um rodando a aplicação e o outro rodando o servidor de banco, um MySQL , por exemplo.

Perguntas que vamos buscar responder:

  • O serviço do banco está no ar?
  • A porta do serviço está estabelecendo conexão?
  • Os hosts envolvidos comunicam-se por meio da rede?
  • O cliente consegue conectar-se à porta do serviço?
  • Tem certeza? Então prove! 😉

__________________________________________________________________________________________________

– Informações em mãos: Para compreender melhor o troubleshooting é importante termos alguns dados em mente, isso vai nos ajudar a identificar o que precisamos testar e analisar do ambiente. Segue a lista:

– Nome do serviço: mysql

– Nome do processo: mysqld

– Porta padrão referente ao serviço: 3306,

*obs: Vamos considerar que o serviço esteja rodando na porta padrão

– ips envolvidos:

cliente: 10.200.0.216

servidor: 10.200.0.82

__________________________________________________________________________________________________

Vamos considerar que ..

– A comunicação entre o cliente e o servidor se dá por endereço IP, e não por nome. Se fosse por nome,  teríamos que verificar se a resolução de nome está correta. Por isso, os exemplos que trabalharemos utilizam os endereços IP.

– As configurações básicas de rede dos hosts estão corretas, ou seja, estão na mesma rede.

– A porta que o MySQL está usando é a 3306

——————————————————-

1. Servidor

Partiremos primeiro para a máquina que roda o serviço. Nela, vamos verificar se:

1.0 Acessando o servidor:

ssh username@10.200.0.82

Obs: Lembrando que esse usuário precisa ter permissão para executar os comandos listados neste artigo.

1.1 Serviço está no ar?

Listaremos os processos que estão rodando no servidor e filtraremos pelo nome do serviço  ou processo, como no exemplo:

1

Aqui temos dois processos listados. O que nós queremos é o que está sendo executado pelo user mysql, cujo PID é o 24231. Nessa linha temos diversas informações pertinentes, inclusive a porta que o serviço está rodando: 3306. Certo? Então temos agora o valor do pid e da porta do serviço, e vamos precisar desses dados para a próxima ação:

1.2. A porta do serviço está “LISTEN” ou “ESTABLISHED”  e conecta “localhost”?

Estado das conexões

– Listen: O socket está escutando as conexões de entrada

– ESTABLISHED: O socket tem uma conexão estabelecida

Escutando?

2

 

Conectando?

3

1.3. O servidor alcança o host cliente?

4

Entendendo os comandos:

  1. ps -efww|grep -v grep|egrep mysl:

As opções:

– e: Seleciona todos os processos existentes no momento

– f: Adiciona algumas colunas na saída do comando

– ww: Limita a largura da saída para o tamanho do terminal

grep -v grep: Remove do nosso filtro o processo que contenha a palavra grep

egrep mysql: Agora sim, filtra da lista de todos os processos aquele que contenha a palavra mysql. egrep é o mesmo que grep -E, –extended-rgex

  1. lsof -nPi4:3306 -ap24231:

As opções:

-n: Não resolva os nomes dos hosts   – O comando roda mais rápido

-P: Não resolva os nomes das portas – Estamos buscando pelo número da porta

-i4:Seleciona a lista dos arquivos de rede que contenham endereço de internet com a versão ipv4

– :3306: e que tenham como porta 3306

-a: O Lsof trabalha por padrão com a lógica OR. Utilizando essa opção, usaremos a AND, ou seja, me traga todas as conexões ipv4 com a porta 3306 e/and com o ip 24231

-p: Aceita como parâmetro um ip, no nosso caso é o ip 24231

  1. nc -vz 127.0.0.1 3306

As opções:

-v: Ativa a verbosidade – Se não colocarmos, não teremos nenhuma saída

-z: Faz com que o nc apenas realize um scan à procura de daemons sem precisar conectar

  1. ping -c3 10.200.0.216:

Opção:

-c count: Envia a quantidade de pacotes ECHO REQUEST indicada no “count”

Conclusão da Etapa:

1.1 – Verificamos que o serviço está no ar e conhecemos o seu pid e porta.

1.2 – Confirmamos que a sua porta do serviço está estabelecendo conexão

1.3 – Também confirmamos que o servidor consegue se comunicar com o nosso cliente.

Agora, vamos realizar testes do lado do cliente. Vamos lá:

—————————————————————————————————————————————-

2. Cliente:

2.1 O cliente alcança o servidor?

Testaremos a comunicação entre os hosts utilizando a ferramenta ping, como no exemplo abaixo:

2.1.1 Usando o comando ping:

5

 

Aqui temos uma pegadinha.

Pingamos o servidor e ele não respondeu (e isso poderia acontecer com o nosso último teste). Alguns poderiam concluir que não está ocorrendo comunicação entre os hosts, porém não é raro encontrar servidores com firewall configurados para não responderem os echo-requests “mensagens ICMP enviadas pelo ping, nas quais aguardam a mensagem de resposta echo-replay”.

Logo, após esse passo não é seguro concluir que não há comunicação entre o cliente e o servidor. Para isso, precisamos realizar mais um teste.

*OBS: Sendo assim, no teste da etapa anterior no qual rodamos o comando ping -c3 [ip_do cliente] também devemos adotar o passo abaixo:

2.2 Conecta na porta do serviço desejado?

Vamos realizar uma conexão na porta 3306, ou seja, ao invés de usarmos o protocolo ICMP que o ping trabalha usaremos o TCP. Então, qualquer possível regra de firewall que impeça mensagens “echo replay” não vão mais interferir nesse teste.

6

2.3 Usando outra ferramenta para o mesmo fim: O nmap irá realizar um “port scan” para nós agora.

7

Entendendo o comando:

A opção “PS” faz uma requisição para o servidor enviando um pacote TCP com a flag SYN mas  interrompe o processo “conhecido como three-way-handshake*”  no meio do caminho, pois a ideia nesse caso é apenas verificar se o host é alcançável e se a porta do serviço está aberta

*three-way-handshake: falaremos sobre esse processo em outro post

Conclusão da Etapa:

2.1 – Fizemos o teste mais usado para veriificar a conectividade entre hosts

2.2 – Testamos a conectividade entre hosts simulando uma conexão

2.3 – Mais uma maneira de simular uma conexão e ter certeza da possibilidade de comunicação entre os hosts em questão

—————————————————————————————————————————————-

3. Servidor:

Por fim, vamos colher os logs em tempo real para confirmar que o cliente ‘x’ está alcançando o servidor e conectando à porta do serviço, para que não reste dúvidas de que está tudo funcionando como esperado no que se refere à rede.

3.1 Colhendo logs em tempo real do fluxo vindo do cliente:

– Abra dois terminais, um logado no cliente e outro no servidor, e execute os comandos abaixo:

No servidor, rodaremos o comando:

8

Do cliente iremos enviar pacotes tcp para a porta 3306

9

No terminal do servidor veremos que ele recebeu os pacotes. Segue uma parte da saída:

10

 

Toda vez que o cliente rodar o comando “nc -vz 10.20.0.82 3306” você poderá acompanhar no terminal do servidor os pacotes chegando em “tempo real”.

Destacando: 10.200.0.216.58954  > 10.200.0.82.3306

cliente > servidor.[porta]

Entendendo o comando tcpdump:

Analisa o tráfego de redes. Com uma expressão conseguimos filtrar o tráfego que contenha as características que desejamos. Podemos filtrar por host, porta etc. A saída pode não ser lá essas belezuras, mas com um pouco de conhecimento sobre redes e a ferramenta já conseguimos obter as informações de que precisamos, o que no nosso caso seria:

Precisamos de uma prova irrefutável e em tempo real de que um determinado cliente (10.200.0.216 ) está conseguindo conectar-se ao servidor na porta 3306 (10.200.0.82.3306). Para isso, construímos aquela expressão:

Opções usadas:

– não resolva o nome de portas/serviços e hosts = -n

– escute na sua interface eth1,   = -i eth1

Expressão:

– o tráfego que tenha como host fonte o ip 10.200.0.216 = src host 10.200.0.216

– e que tenha como porta de destino a 3306 = and port 3306

Nesse filtro que criamos estamos sendo bem específicos. Isso nos ajuda a adquirir uma prova mais consistente.

Conclusão da Etapa:

3.1 – Presenciamos a troca de dados entre os hosts em tempo real

__________________________________________________________________________________________________

Resumo:

Para verificar a comunicação entre hosts podemos usar o velho comando ping, mas já sabemos que é possível encontrar barreiras “invisíveis”. Experimente pingar uma máquina Windows, um desktop mesmo, em geral o firewall dá uma “sacaneada”.

Vá de nc ou nmap, pois podemos utilizar mensagens tcp para simular uma requisição para conexão. Logo, se o servidor está no ar ele nos responderá.

Digo o mesmo quando precisamos testar a conectividade das portas dos serviços, nc e nmap resolvem bem.

Para listar as conexões em portas específicas poderíamos ter usado o netstat ou ss, mas para aumentar a precisão usaríamos o grep. Então, escolhi o lsof porque com ele podermos indicar a porta da conexão (3306). Além disso, a maioria das pessoas que conheço usam o netstat, então preferi variar.

Analisar pacotes de rede: É sempre bom ter certeza quanto ao tráfego de redes. Temos o tcpdump para ajudar, então use. Parece complicado, mas estamos trabalhando em outro post para resolver isso.

Fica assim:

Verificar a comunicação entre hosts: nc ou nmap

Conectividade das portas de serviços: nc ou nmap

Listar as conexões em portas específicas: lsof

Analisar pacotes de rede: tcpdump

E é isso, pessoal!

Espero ter conseguido expor a utilidade das ferramentas. Não expliquei a fundo cada uma delas para deixar o post bem prático e fácil de lembrar na hora de um “aperto”.

Se surgir alguma dúvida ou sugestão, é só usar os campos abaixo.

Até a próxima!