Todos os cursos > Tecnologia, Informática e Programação > Servidores Web e Redes de computadores ::

Modelos OSI e TCP/IP aplicados a redes de servidores

Capítulo 2

Tempo estimado de leitura: 8 minutos

Por que modelos em camadas ajudam no troubleshooting

Em redes de servidores, os modelos OSI e TCP/IP são menos “teoria” e mais um checklist mental para isolar falhas. A ideia prática é: quando algo não funciona, você testa de baixo para cima (ou de cima para baixo, dependendo do sintoma) e coleta sinais mensuráveis em cada camada. Assim você evita “chutar” causas e reduz o tempo até o ponto exato da falha.

Mapeamento OSI ↔ TCP/IP (visão operacional)

OSI	TCP/IP	O que você observa/mede	Ferramentas/sinais comuns
1. Física	Acesso à Rede	Link sobe? erros físicos? velocidade/duplex? perda no meio?	LEDs, `ethtool`, `ip -s link`, contadores CRC/frames, logs do switch
2. Enlace	Acesso à Rede	MAC correto? VLAN correta? ARP funciona? loops?	`ip neigh`, `arp -n`, tabela MAC do switch, STP, `tcpdump -e`
3. Rede	Internet	IP/máscara/gateway corretos? rota existe? MTU? ICMP chega?	`ip addr`, `ip route`, `ping`, `traceroute`/`tracepath`, ACLs/SGs, `tcpdump icmp`
4. Transporte	Transporte	Porta aberta? handshake TCP? UDP chega? resets/timeouts?	`ss -lntup`, `nc`, `telnet`, `nmap`, `tcpdump tcp`, contadores de retransmissão
5-7. Sessão/Apresentação/Aplicação	Aplicação	DNS, HTTP, TLS, SSH: erro de protocolo? auth? certificado? SNI? headers?	`dig`/`nslookup`, `curl -v`, `openssl s_client`, logs do app/reverse proxy, `journalctl`

Camada 1 (Física): cabos, link e erros no meio

O que observar e medir

Estado do link: interface “UP” no servidor e porta “up” no switch.
Velocidade/duplex: mismatch pode causar perdas e lentidão.
Erros físicos: CRC, frame errors, drops, flaps (link caindo e voltando).
Qualidade do caminho: em fibra, potência; em cobre, comprimento/qualidade do cabo.

Comandos úteis (Linux)

ip link show dev eth0 ethtool eth0 ip -s link show dev eth0

Indicadores práticos: contadores de RX errors, TX errors, dropped, e no ethtool ver Speed, Duplex, Link detected.

Passo a passo rápido

Confirme se a interface está UP e com link detectado.
Compare velocidade/duplex com o esperado (e com o switch).
Verifique contadores de erro aumentando durante o problema.
Se houver flapping, troque cabo/porta e valide novamente.

Camada 2 (Enlace): MAC, VLAN e ARP

O que observar e medir

VLAN correta: porta access/trunk, VLAN nativa, tagging 802.1Q.
Aprendizado de MAC: o switch aprende o MAC do servidor na porta correta?
ARP/Neighbor: o servidor resolve o MAC do gateway/peer?
Loops e STP: instabilidade, broadcast storms, MAC flapping.

Ferramentas e sinais

ip neigh show tcpdump -ni eth0 -e arp

Se o ARP falha, você verá tentativas repetidas (ARP request) sem resposta. Se VLAN estiver errada, o servidor pode até ter link, mas não “enxerga” o gateway.

Passo a passo rápido

Verifique se o servidor está na VLAN esperada (no switch e no host, se houver subinterfaces/tagging).
Cheque a tabela ARP: há entrada para o gateway? Está REACHABLE ou FAILED?
Capture ARP com tcpdump para ver se há resposta.
No switch, confirme se o MAC do servidor aparece na porta correta e não “flutua” entre portas.

Camada 3 (Rede): IP, máscara, gateway e roteamento

O que observar e medir

Endereçamento: IP e máscara corretos; conflitos de IP.
Gateway padrão: existe e está alcançável.
Rotas: rota para a rede destino e rota de retorno (muito comum em ambientes com múltiplas interfaces).
MTU: problemas de fragmentação/PMTUD podem quebrar TLS/HTTP em caminhos específicos.
Políticas/ACL: bloqueios em firewall de borda, security groups, ACLs de roteador.

Comandos úteis

ip addr show ip route show ping -c 3 <gateway> traceroute <destino> tracepath <destino>

traceroute/tracepath ajudam a localizar onde o tráfego para. Se o ping ao gateway falha, volte para camada 2/1. Se o gateway responde mas destinos externos não, foque em rotas/ACL/NAT.

Passo a passo rápido

Valide IP/máscara/gateway.
Ping no gateway; depois ping em um IP na mesma rede; depois ping em um IP remoto.
Use traceroute para ver o salto onde para.
Se suspeitar de MTU, use tracepath e testes de ping com DF (quando aplicável).

Camada 4 (Transporte): TCP/UDP, portas e handshake

O que observar e medir

Porta ouvindo: o serviço está em LISTEN no IP/porta corretos?
Handshake TCP: SYN/SYN-ACK/ACK completa? Ou há timeout?
Reset (RST): conexão recusada geralmente indica porta fechada ou rejeição ativa.
Retransmissões: perda/latência pode causar lentidão e timeouts.
UDP: não há handshake; você mede por resposta do aplicativo e captura de pacotes.

Ferramentas e sinais

ss -lntup ss -antp nc -vz <host> 443 tcpdump -ni eth0 'tcp port 443'

Interpretação rápida: timeout costuma apontar bloqueio/rota/ACL (camada 3/4). connection refused aponta para serviço não ouvindo ou firewall local rejeitando (camada 4).

Continue em nosso aplicativo e ...

Ouça o áudio com a tela desligada
Ganhe Certificado após a conclusão
+ de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Passo a passo rápido (servidor)

Confirme que o processo está ouvindo: ss -lntup.
Confirme bind correto: ouvindo em 0.0.0.0/:: ou no IP esperado.
Verifique firewall local (iptables/nftables/ufw) se aplicável.
Capture o tráfego para ver se o SYN chega e se há resposta.

Camada 7 (Aplicação no TCP/IP): DNS, HTTP, TLS, SSH

O que observar e medir

DNS: resolve para o IP correto? TTL? split-horizon? ordem de resolução?
HTTP: status code, headers, redirecionamentos, host header.
TLS/HTTPS: cadeia de certificados, validade, SNI, versões/ciphers, handshake.
SSH: banner, métodos de auth, chaves, políticas.
Logs: reverse proxy (Nginx/Apache), aplicação, systemd/journald.

Ferramentas e sinais

dig +short A exemplo.com dig exemplo.com @<dns> curl -v http://<host>/ curl -vk https://<host>/ openssl s_client -connect <host>:443 -servername exemplo.com

Um ponto operacional importante: quando a camada 4 está OK (porta abre), mas a aplicação falha, o erro costuma aparecer claramente em curl -v (HTTP) ou openssl s_client (TLS).

Cenários guiados (sintoma → camada provável → testes)

Cenário 1: “ping funciona mas o site não abre”

Leitura do sintoma: ICMP (camada 3) está OK até o destino, mas HTTP/HTTPS pode estar falhando na camada 4 (porta) ou 7 (aplicação/TLS), ou ainda DNS (se o teste de ping foi para IP e o acesso é por nome).

Checklist prático

1) Diferencie IP vs nome: se você pinga um IP e o navegador usa um nome, teste DNS: dig exemplo.com.
2) Teste porta 80/443: nc -vz host 80 e nc -vz host 443.
3) Teste HTTP direto: curl -v http://host/.
4) Se for HTTPS: curl -vk https://host/ e openssl s_client para ver handshake/cert.
5) Se porta abre mas HTTP falha: verifique logs do reverse proxy e da aplicação (camada 7).

Camada provável: 4 (porta bloqueada) ou 7 (serviço web fora, virtual host/SNI, erro de app). Se DNS estiver errado, camada 7 (aplicação/DNS no TCP/IP).

Cenário 2: “DNS resolve mas a conexão é recusada”

Leitura do sintoma: nome → IP está OK (DNS), mas ao conectar em uma porta ocorre Connection refused. Isso é tipicamente resposta TCP RST: algo ativamente rejeitou ou não há serviço ouvindo.

Checklist prático

1) Confirme o IP resolvido: dig +short exemplo.com e compare com o IP esperado (evita apontar para host errado).
2) Teste a porta: nc -vz exemplo.com 443 (ou 80/22/etc.).
3) No servidor, verifique listener: ss -lntup | grep ':443'.
4) Verifique bind: serviço pode estar ouvindo apenas em 127.0.0.1 em vez do IP externo.
5) Verifique firewall local: regras podem rejeitar (REJECT) em vez de dropar.

Camada provável: 4 (transporte) ou configuração do serviço na 7 (aplicação) que impacta o listener (por exemplo, serviço não subiu).

Cenário 3: “Conecta em HTTP mas não em HTTPS”

Leitura do sintoma: camada 3 está OK e a porta 80 funciona. O problema está específico na porta 443 (camada 4) ou no handshake TLS (camada 7).

Checklist prático

1) Teste porta 443: nc -vz host 443. Se falhar por timeout, suspeite de firewall/ACL (camada 3/4). Se for refused, serviço não está ouvindo (camada 4).
2) Se a porta 443 abre, teste TLS: openssl s_client -connect host:443 -servername exemplo.com.
3) Verifique SNI/virtual host: se sem -servername funciona diferente, pode ser configuração de SNI no proxy (camada 7).
4) Verifique certificado: expirado, cadeia incompleta, CN/SAN incorreto. No openssl, observe erros de verificação e o certificado apresentado.
5) Verifique versões/ciphers: clientes antigos podem falhar se o servidor aceitar apenas TLS moderno; o erro aparece no handshake (camada 7).

Camada provável: 4 (porta 443 bloqueada/fechada) ou 7 (TLS mal configurado, certificado, SNI, políticas de TLS).

Roteiro de troubleshooting por camadas (aplicável no dia a dia)

1) Comece pelo sintoma e escolha direção

Se nada conecta e nem ARP/ping funciona: comece na camada 1/2.
Se ping funciona mas portas não: vá para camada 4.
Se portas abrem mas a resposta é erro de protocolo: vá para camada 7.

2) Colete evidências mínimas por camada

L1: link, velocidade/duplex, erros físicos.
L2: VLAN, ARP, MAC no switch.
L3: IP/rota, traceroute, MTU.
L4: listener, handshake, refused vs timeout.
L7: DNS, HTTP status, TLS handshake, logs.

3) Use captura de pacotes para “tirar dúvida”

Quando o sintoma é ambíguo, uma captura curta resolve: veja se o pacote sai, se chega, e qual a resposta.

# Exemplo: ver tentativa de conexão HTTPS tcpdump -ni eth0 'host <ip_cliente> and tcp port 443'

Se você vê SYN chegando e não vê SYN-ACK saindo, o problema está no servidor (firewall local, serviço, rota de retorno). Se não vê SYN chegando, o problema está antes (rede/ACL/roteamento).

Agora responda o exercício sobre o conteúdo:

Em um troubleshooting, você consegue pingar o servidor (por IP), mas o site não abre no navegador. Qual sequência de verificação é mais adequada para isolar a falha?

Você acertou! Parabéns, agora siga para a próxima página

Você errou! Tente novamente.

Se o ping por IP funciona, a conectividade de camada 3 tende a estar OK. O próximo passo é diferenciar nome vs IP (DNS) e testar portas (camada 4) e, se abrirem, verificar HTTP/TLS e logs na camada 7.