Fluxograma Simplificado para Troubleshooting de Problemas com Sites

Introdução

Este fluxograma foi criado para a apresentação da palestra "Troubleshooting Like a Boss" na GTER 2024, acessível através deste link. Recomendo fortemente que você assista à esta palestra, pois nela foram ditas explicações relevantes sobre este fluxograma. Ademais, este fluxograma poderá passar por atualizações frequentes. Portanto, em vez de baixá-lo localmente em sua máquina, procure acessá-lo diretamente por aqui pela Wiki do BPF.

Eu também gostaria de lembrar que este fluxograma não deve ser considerado uma verdade absoluta em todos os casos, mas sim um guia pra te facilitar em troubleshootings.

Leia atentamente à descrição de cada etapa deste fluxograma na seção logo abaixo da imagem.

O próprio Fluxograma

Explicação sobre as etapas

1 - Site não abre

Este fluxograma deve ser iniciado assim que identificado que um determinado site não abre em todo o teu sistema autônomo. Considere iniciar estes testes apenas após confirmar que o problema é generalizado em toda a tua rede e não apenas em um usuário ou host específico.

2 - Descartou problemas locais na rede?

O objetivo principal deste fluxograma é te ajudar a diagnosticar problemas externos ao seu sistema autônomo. Portanto se certifique de realizar testes que excluam problemas internos. Uma possibilidade é realizar um teste de acesso ao site problemático através de um equipamento conectado diretamente no roteador de borda para eliminar outros hosts intermediários na rede. Complementarmente, recomendo que sejam feitos testes com outros dispositivos (diferentes computadores ou smartphones) e usando outros navegadores, preferencialmente no modo anônimo.

3 - O problema ocorre em outros sites também?

Realize o teste com outros sites em sua rede. Busque testar com mais de um navegador, com mais de um dispositivo e sempre busque realizar testes usando o modo anônimo do navegador.

4 - Ocorre com muitas outras redes?

Algumas ferramentas podem te ajudar com este teste.

ISP Tools

Além de várias outras features interessantes, o ISP Tools possui uma função de realizar testes de abertura de páginas a partir de dezenas de origens. Para utilizar este recurso, escolha a origem desejada na lista, digite o endereço do site e clique em 'testar'. Repita este teste com várias origens para entender se o problema acontece a partir de outras redes também. O resultado mais positivo da abertura de um site é o código 200 no status, mas o número dos outros status podem indicar outras informações relevantes, conforme explico em minha palestra e conforme pode ser lido na RFC 9110.

Down Detector

O [Downdetector] é um serviço que monitora a disponibilidade de sites e aplicativos em tempo real por meio de relatos de usuários; para verificar se um serviço específico está com falhas, acesse a página inicial, utilize o campo de pesquisa para localizar o serviço desejado e observe se há um aumento significativo no número de reclamações ou no gráfico de relatos recentes.

5 - Resolve nome?

Você pode testar de algumas maneiras se um domínio está sendo devidamente resolvido. Segue abaixo alguns exemplos:

nslookup (Windows e Linux)

nslookup exemple.com

Saída esperada caso funcione:

Non-authoritative answer:
Name:	example.com
Address: 203.0.113.10

Se houver resposta diferente disso, espere que não funcionou.

dig (Linux)

Para consultar:

dig +short example.com

Saída esperada caso funcione: será apenas um IP

Caso não tenha funcionado, alguma resposta de erro de comunicação ou output nenhum.

host (Linux)

host example.com

Saída esperada caso resolva:

example.com has address 203.0.113.10
example.com has IPv6 address 2001:db8::1234

Caso a saída seja diferente disso, espere que não funcionou.

6 - Com outro DNS resolve?

Você pode especificar um servidor DNS alternativo, como o 1.1.1.1 (Cloudflare), 8.8.8.8 (Google) ou suas variantes IPv6 (2606:4700:4700::1111 para Cloudflare e 2001:4860:4860::8888 para Google), adicionando-o ao comando. Veja abaixo:

nslookup (Windows e Linux):

nslookup example.com 1.1.1.1

nslookup example.com 2606:4700:4700::1111

dig (Linux):

dig +short A example.com @8.8.8.8

dig +short AAAA example.com @2001:4860:4860::8888

host (Linux):

host example.com 1.1.1.1

host example.com 2606:4700:4700::1111

Dessa forma, você verifica se o problema de resolução está no servidor DNS padrão ou não.

Os resultados que você espera são os mesmos do item 5.

Obs. Citei o Google e Cloudflare, mas poderia ser qualquer DNS público que você confie que através dele "deveria" funcionar.

7 - O site responde ping?

Faça o teste de ping normalmente para verificar se responde.

ping -c 10 example.com
PING example.com (203.0.113.10) 56(84) bytes of data.

--- example.com ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9252ms

Se não responder (como aconteceu acima), você verá 100% de packet loss. Se responder, você verá um valor que não é 100% de packet loss.

Obs. Se responder parcialmente, ou seja, se houver perdas de pacotes, o sintoma será lentidão/intermitência ao carregar o conteúdo, porém, lentidão não significa que o conteúdo não está disponível. Os problemas são diferentes.

8 - Algum IP do mesmo /24 responde ping?

Se caso o IP do site não responder ao ping, você pode testar pingar algum IP daquele /24. Isso ajudará a entender se há algum problema de roteamento.

O comando "fping -ga" é o que recomendamos (disponível no Linux) pois você facilmente conseguira pingar o /24 inteiro para descobrir se algum IP responde.

Se outro IP responder, você verá algo assim:

fping -ga 203.0.113.0/24
203.0.113.28
203.0.113.98
203.0.113.122
203.0.113.123
203.0.113.124
203.0.113.201

Perceba que vários outros IPs pingaram do mesmo /24.

Caso nenhum IP responda ao ping, você não terá output deste comando.

9 - Alterar o upload deste IP/rede para outro trânsito resolve o problema?

Para este item o seu conhecimento de roteamento se faz necessário.

Como esse caso é um caso que depende muito de como está sua rede, quantidade de upstreams e etc, acaba que não há como ensinarmos exatamente o que você precisará fazer, mas em suma você precisará:

Criar uma rota estática do IP descoberto no item 5 para outro caminho (outro upstream) e não o caminho onde ele está atualmente usando.

10 - O problema não é o roteamento em si (mas pode ser algum bloqueio em algum trânsito)

A conclusão desta parte é que você tem comunicação até o AS de destino deste conteúdo.

Seguiremos investigando o caso, mas já da pra saber que o problema de roteamento você não tem.

11 - Anunciar o /24 de origem somente para outro trânsito resolve o problema?

Para este item o seu conhecimento de roteamento se faz necessário.

E além disso você deve possuir mais de um upstream para conseguir efetuar este item.

Veja qual é seu IP de origem dos testes e desvie o /24 respectivo para outro caminho. Você fará isso editando politicas de roteamento de BGP. O objetivo deste item é:

Anunciar o /24 de origem respectivo para outro caminho.
Remover o /24 (caso exista) do caminho atual. Não trabalhe com prepends aqui, faça totalmente o withdraw da rota.

Caso você não anuncie nenhum /24 antes do teste, você não teria como saber o caminho escolhido do lado do conteúdo até você com precisão; neste caso, verifique se a primeira manobra de anunciar o /24 para um dos caminhos resolveu e caso não tenha resolvido, tente anunciar o /24 exclusivamente para um a um dos seus upstreams até conseguir eliminar com certeza que a mudança surtiu ou não efeito.

Obs. Caso você tenha apenas um upstream ou você não seja um sistema autônomo, você não poderá realizar o teste necessário e então se fará necessário você abrir um chamado com seu provedor atual para ele te ajudar com esta etapa.

12 - Verifique seu lado por firewalls, sistemas de manipulação de tráfego, sistemas de mitigação, dentro outras coisas

Alguns fatores que podem estar causando este problema podem ser: sistemas de mitigação, sistemas de detecção de ataques, regras de firewall, regras de ACL, sistemas de blacklist (como Team Cymru e outros similares), problemas relacionados à MTU, saturação de recursos computacionais (como CPU e RAM) de ativos como roteadores, problemas relacionados ao CGNAT e rotas estáticas legadas.

13 - O problema está no lado do conteúdo

Abra um chamado com o provedor do conteúdo que você está tendo problemas. Caso não saiba como fazer isso, sugerimos procurar contatos através do Whois ou do site da hospedagem do conteúdo.

14 - O DNS que você estava usando está com problemas de resolução

Recomendamos verificar se o DNS do seu equipamento está configurado de forma estática, pois o servidor aparenta não estar funcional. Como solução temporária, você pode usar um DNS público, como o Google DNS, Cloudflare DNS ou OpenDNS. No entanto, é importante investigar a causa da falha no DNS atual.

15 - Possível problema geral na sua conexão ou bloqueio de DNS

Verifique sua comunicação com o seu gateway e outros possíveis problemas de rede, como falha do seu provedor. Este problema provavelmente não está do lado do conteúdo. Testar abertura com seu celular via 4G/5G também é uma opção para descartar problemas do lado do conteúdo.

16 - O problema possivelmente é o trânsito eleito para a rota que te leva ao site

Recomendamos que você altere seu caminho para chegar ao IP do site através de políticas de roteamento BGP e notifique o seu caminho anterior (upstream) sobre o problema.

Se caso o seu caminho anterior for algum IX, valide problemas que possam estar acontecendo no IX e afetando mais conteúdos. Acessar o status page do IX respectivo é uma boa opção neste caso.

17 - Possível problema no trânsito para o qual este /24 era eleito no destino (ver LG)

Abra um chamado com seu trânsito e também seria bom tentar contacto com o fornecedor/mantenedor do site/serviço. Se o conteúdo possuir looking glass isso vai poder te ajudar a levantar evidências para isso.

O fato é que o caminho pelo qual o conteúdo tentava chegava até você, durante o processo de acesso, estava prejudicando a comunicação.

18 - Entre em contato com o fornecedor do site/serviço

Você precisará entrar em contato com o fornecedor/mantenedor do site/serviço. Este problema está afetando não só você como provavelmente várias outras origens.

Um bom local para encontrar onde você deve reportar algum problema é o whois ou o peeringDB.

Autores: Daniel Damito e André Almeida.