Redes de Computadores para o Escriturário do Banco do Brasil – Agente de Tecnologia

Por que redes importam no dia a dia do Agente de Tecnologia

Em ambientes corporativos e bancários, a maioria dos sistemas é distribuída: aplicações conversam com bancos de dados, filas, serviços de autenticação, APIs internas e serviços externos. Entender redes permite diagnosticar falhas de conectividade, latência, resolução de nomes, bloqueios por firewall e problemas de roteamento, além de interpretar logs e evidências técnicas em incidentes.

Modelos de referência: OSI e TCP/IP (visão aplicada)

Modelo OSI (7 camadas) — o que observar em cada uma

• Camada 1 (Física): sinal, cabo, Wi‑Fi, link. Sintoma típico: “sem link”, perda total.
• Camada 2 (Enlace): Ethernet, MAC, VLAN, switch. Sintoma: comunica em uma VLAN, não em outra; ARP falhando.
• Camada 3 (Rede): IP, roteamento. Sintoma: alcança a rede local, não alcança outra rede; gateway incorreto.
• Camada 4 (Transporte): TCP/UDP, portas. Sintoma: IP responde, mas porta do serviço não abre.
• Camada 5 (Sessão): manutenção de sessão (conceitual). Sintoma: quedas de sessão, timeouts de sessão.
• Camada 6 (Apresentação): codificação/criptografia (ex.: TLS). Sintoma: falha de handshake, certificado inválido.
• Camada 7 (Aplicação): HTTP, DNS, SMTP etc. Sintoma: erro 4xx/5xx, DNS não resolve, autenticação falha.

Modelo TCP/IP (4 camadas) — como ele aparece na prática

• Acesso à rede: Ethernet/Wi‑Fi, VLANs.
• Internet: IP, ICMP, roteamento.
• Transporte: TCP/UDP, portas.
• Aplicação: HTTP/HTTPS, DNS, SMTP, SSH etc.

Quadro-resumo: mapeamento rápido OSI ↔ TCP/IP

• OSI 1–2 ↔ TCP/IP Acesso à rede
• OSI 3 ↔ TCP/IP Internet
• OSI 4 ↔ TCP/IP Transporte
• OSI 5–7 ↔ TCP/IP Aplicação

Endereçamento IP: IPv4 e IPv6

IPv4: estrutura e conceitos essenciais

Um endereço IPv4 tem 32 bits, geralmente escrito em quatro octetos (ex.: 192.168.10.25). Ele se divide em parte de rede e parte de host, definidas pela máscara (ex.: /24).

• IP de rede: identifica a rede (ex.: 192.168.10.0/24).
• IP do host: identifica o dispositivo dentro da rede (ex.: .25).
• Broadcast: endereço para todos os hosts da rede (ex.: 192.168.10.255 em /24).
• Gateway padrão: roteador usado para sair da rede local (ex.: 192.168.10.1).

IPv6: por que existe e como ler

IPv6 tem 128 bits, escrito em hexadecimal (ex.: 2001:db8:abcd:0012::10). Ele resolve escassez de endereços e melhora práticas de roteamento. Conceitos úteis:

• Prefixo (ex.: /64) define a rede; o restante identifica a interface.
• Abreviação: zeros podem ser omitidos; “::” pode substituir uma sequência contínua de zeros (uma vez por endereço).
• Link-local (fe80::/10): usado na rede local, comum para descoberta e vizinhança.

Sub-redes (subnetting) em nível prático

Objetivo do subnetting

Subnetting divide uma rede em redes menores para organizar ambientes, reduzir broadcast, separar domínios (ex.: por área/sistema) e aplicar políticas (firewall/ACL) com mais precisão.

Passo a passo prático (IPv4)

Exemplo: você tem 10.20.0.0/16 e precisa de sub-redes para até 200 hosts cada.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• 1) Calcule hosts por sub-rede: 200 hosts requer 8 bits de host (2^8 = 256 endereços; 254 utilizáveis). Logo, máscara /24 atende.
• 2) Defina o novo prefixo: de /16 para /24 significa que você “emprestou” 8 bits para sub-redes.
• 3) Liste sub-redes: 10.20.0.0/24, 10.20.1.0/24, 10.20.2.0/24 ...
• 4) Determine faixa utilizável: em 10.20.1.0/24: hosts 10.20.1.1 a 10.20.1.254; broadcast 10.20.1.255.
• 5) Defina gateway e reservas: ex.: gateway 10.20.1.1; reservar .2–.20 para infraestrutura (DNS, DHCP relay, balanceadores etc.).

Exemplo rápido de “tamanho de sub-rede” (atalho mental)

• /24: 254 hosts
• /25: 126 hosts
• /26: 62 hosts
• /27: 30 hosts
• /28: 14 hosts

Erros comuns em prova e na prática

• Confundir IP de rede com primeiro host.
• Esquecer que broadcast existe em IPv4 (em redes tradicionais) e não é “um host utilizável”.
• Configurar máscara incompatível entre hosts da mesma rede (um acha que é /24, outro /25).

DNS: resolução de nomes (e por que falha)

O que é e como funciona (fluxo básico)

DNS traduz nomes (ex.: api.interna.local) em IPs. O cliente consulta um resolvedor (DNS corporativo), que pode responder do cache ou consultar servidores autoritativos.

Registros mais cobrados

• A: nome → IPv4
• AAAA: nome → IPv6
• CNAME: alias para outro nome
• MX: servidores de e-mail do domínio
• TXT: políticas e validações (ex.: SPF/DMARC, verificações)

Sintomas típicos de problema de DNS

• Aplicação falha com “host not found” ou “name resolution failed”.
• Acesso por IP funciona, por nome não.
• Intermitência por cache/TTL inadequado ou múltiplos registros divergentes.

DHCP: entrega automática de configuração de rede

O que o DHCP fornece

• IP do host
• Máscara/prefixo
• Gateway padrão
• DNS (servidores e sufixos de busca)
• Tempo de concessão (lease)

Passo a passo do processo (DORA)

• Discover: cliente procura servidor DHCP.
• Offer: servidor oferece um IP e parâmetros.
• Request: cliente solicita a oferta escolhida.
• Ack: servidor confirma a concessão.

Falhas comuns

• Sem IP (cliente fica com IP automático/local): servidor DHCP inacessível ou escopo esgotado.
• Recebe IP, mas sem DNS correto: navegação por nome falha.
• Em redes segmentadas: necessidade de DHCP relay (encaminhamento) no roteador.

NAT: tradução de endereços (o que muda na comunicação)

Conceito

NAT altera endereços IP (e frequentemente portas) ao atravessar um roteador/firewall. É comum para permitir que redes privadas acessem redes externas usando um IP público.

Tipos úteis

• SNAT (Source NAT): altera o IP de origem (saída).
• DNAT (Destination NAT): altera o IP de destino (entrada), usado em publicação de serviços.
• PAT (Port Address Translation): múltiplos hosts compartilham um IP público via portas.

Impactos práticos

• Logs do servidor podem mostrar o IP do NAT, não o IP real do cliente (a menos que haja cabeçalhos/proxies adequados).
• Conexões de entrada exigem DNAT e regras de firewall coerentes.
• Alguns protocolos sensíveis a IP/porta podem exigir inspeção/ajustes.

Roteamento básico: como o pacote escolhe o caminho

Conceitos essenciais

• Rota: regra “para alcançar rede X, envie para o próximo salto Y”.
• Gateway padrão: rota usada quando não há rota mais específica.
• Rota mais específica vence: /24 é mais específico que /16.
• Métrica: critério de preferência entre rotas.

Cenário prático

Um servidor 10.20.1.10/24 precisa acessar 10.30.5.20/24. Se não houver rota para 10.30.5.0/24, ele enviará ao gateway padrão. Se o gateway não souber encaminhar, o tráfego falha (ou vai para lugar errado).

Protocolos essenciais (o que são e como reconhecer problemas)

HTTP e HTTPS

• HTTP: protocolo de aplicação para requisições/respostas (métodos GET/POST etc.). Normalmente porta 80/TCP.
• HTTPS: HTTP sobre TLS. Normalmente porta 443/TCP.

Erros típicos: 404 (recurso inexistente), 401/403 (autorização), 500 (erro no servidor), timeout (rede/porta/serviço indisponível).

TLS (base do HTTPS e outros)

TLS fornece criptografia, integridade e autenticação (certificados). No handshake, o cliente valida o certificado (cadeia, validade, nome do host, revogação conforme política).

• Falhas comuns: certificado expirado, nome diferente (CN/SAN não corresponde), cadeia incompleta, protocolo/cifra incompatível.

SSH

SSH permite acesso remoto seguro e tunelamento. Normalmente porta 22/TCP. Problemas comuns: porta bloqueada, chave/credencial inválida, host key alterada (alerta de segurança).

SMTP

SMTP é usado para envio de e-mails entre clientes/servidores e servidores entre si. Portas comuns: 25/TCP (relay), 587/TCP (submission), 465/TCP (SMTPS em alguns cenários). Problemas comuns: bloqueio por política, autenticação, DNS/MX incorreto, rejeição por reputação.

Portas, sockets e o que significa “serviço está ouvindo”

Porta TCP/UDP

Porta é um identificador lógico para serviços em um host. Um servidor “escuta” em uma porta; o cliente abre uma porta efêmera e conecta.

Socket (visão conceitual)

Um socket é a combinação de IP + porta + protocolo (TCP/UDP). Uma conexão TCP é identificada pelo 4‑tuplo: IP origem, porta origem, IP destino, porta destino.

Exemplo de fluxo

• Cliente 10.20.1.10 abre porta efêmera 53012 e conecta em 10.30.5.20:443 (HTTPS).
• Se o firewall bloquear 443, o IP pode até responder a ping, mas a conexão falha.

Ferramentas conceituais de diagnóstico: ping e traceroute

ping (ICMP)

Testa alcance e latência básica via ICMP Echo. Se falhar, pode ser: host fora do ar, rota inexistente, ICMP bloqueado, ou perda no caminho. Importante: ping falhar não prova que TCP/443 falha; e ping funcionar não prova que a porta do serviço está aberta.

traceroute/tracert

Mostra os saltos (roteadores) até o destino, ajudando a localizar onde o tráfego para. Pode ser afetado por bloqueios de ICMP/TTL-expired, então a ausência de resposta em um salto não significa necessariamente falha naquele ponto.

Roteiro prático de diagnóstico (passo a passo)

• 1) Verifique IP/máscara/gateway: configuração incorreta derruba tudo.
• 2) Teste alcance local: ping no gateway (quando permitido) para validar camada 3 local.
• 3) Teste DNS: se por IP funciona e por nome não, foque em DNS.
• 4) Teste porta do serviço: se IP responde mas serviço não, suspeite de firewall/porta/serviço parado/TLS.
• 5) Use traceroute: para entender onde o caminho “morre” (roteamento/ACL).
• 6) Correlacione com logs: aplicação, proxy, balanceador, firewall (quando disponíveis).

Quadros-resumo por camada (para prova e triagem rápida)

Camada de Rede (IP/roteamento)

• O que quebra: gateway errado, rota ausente, conflito de IP, máscara errada.
• Sintoma: não alcança outra rede; traceroute para cedo.
• Evidência: tabela de rotas, ARP, logs de roteador/firewall.

Camada de Transporte (TCP/UDP)

• O que quebra: porta bloqueada, serviço não está ouvindo, exaustão de conexões, timeout.
• Sintoma: ping ok, mas conexão na porta falha.
• Evidência: regras de firewall, estado do serviço, logs de conexão.

Camada de Aplicação (DNS/HTTP/SMTP/SSH)

• O que quebra: DNS incorreto, credenciais, erros HTTP, políticas SMTP, handshake TLS.
• Sintoma: respostas com códigos/erros específicos (4xx/5xx), “NXDOMAIN”, falha de certificado.
• Evidência: logs da aplicação, registros DNS, certificados e cadeias.

Cenários de comunicação (interno ↔ serviços) para interpretar em questões

Cenário 1: Sistema interno acessa API interna por nome

Fluxo: App A (10.20.1.10) → DNS resolve api.interna.local → IP 10.30.5.20 → conexão TCP/443 → handshake TLS → HTTP.

• Se falhar na resolução: foco em DNS (registro ausente, sufixo, servidor DNS errado).
• Se resolver mas não conectar: foco em roteamento/ACL/firewall/porta.
• Se conectar mas TLS falhar: foco em certificado/nome do host/cadeia.
• Se TLS ok mas HTTP retorna 500: foco na aplicação/depêndencias.

Cenário 2: Estação recebe IP via DHCP, mas não navega

Possibilidades: DNS errado, gateway errado, proxy obrigatório não configurado, rota para internet bloqueada, NAT ausente.

• Diagnóstico: validar parâmetros do DHCP; testar acesso por IP; verificar se há necessidade de proxy; checar se saída passa por NAT.

Cenário 3: Serviço publicado para parceiros (entrada)

Fluxo: Internet → IP público → firewall com DNAT → servidor interno:porta. Se o DNAT existir mas a regra de firewall não permitir, o tráfego não chega. Se chegar mas o serviço não estiver ouvindo, haverá timeout/recusa.

Exercícios (identificação de problemas de conectividade)

Exercício 1

Sintoma: Usuário acessa https://sistema.interno.local e recebe “DNS_PROBE_FINISHED_NXDOMAIN”. Acesso por IP 10.30.5.20 funciona no navegador (com aviso de certificado).

Perguntas:

• Qual componente é o mais provável causador?
• Que registro DNS seria esperado para esse nome?
• Por que aparece aviso de certificado ao acessar por IP?

Exercício 2

Sintoma: ping para 10.30.5.20 responde com baixa latência, mas a aplicação não conecta em 10.30.5.20:443 (timeout).

Perguntas:

• Quais hipóteses principais na camada de transporte/rede?
• Que evidências você buscaria (firewall, serviço, rota)?

Exercício 3

Sintoma: Após mudança de rede, servidores em 10.20.1.0/24 não alcançam 10.40.0.0/16. Traceroute para em 10.20.1.1 (gateway).

Perguntas:

• O problema tende a estar onde: host, gateway ou rede adiante?
• Que tipo de ajuste pode faltar no gateway?

Exercício 4

Sintoma: Estações recebem IP via DHCP, máscara correta, mas o DNS entregue é 8.8.8.8 e nomes internos não resolvem.

Perguntas:

• Qual parâmetro do DHCP está incorreto?
• Qual efeito prático isso causa em sistemas internos?

Exercício 5

Sintoma: Serviço SMTP de envio (porta 587) falha apenas para alguns destinatários; logs indicam “MX lookup failed”.

Perguntas:

• Qual relação com DNS?
• Que registro é consultado para entrega de e-mail?

Mini-casos de interpretação (comunicação entre sistemas)

Caso A: App → Banco de dados

Descrição: App em 10.20.2.15 conecta ao DB em 10.20.3.10:5432. Após criação de VLAN nova, a conexão caiu.

• Checklist: VLAN correta? rota entre sub-redes? ACL liberando 5432/TCP? DB ouvindo na interface correta? DNS aponta para IP antigo?

Caso B: App → Serviço externo via saída controlada

Descrição: App precisa chamar https://api.parceiro.com. Em rede corporativa, a saída exige NAT e, às vezes, proxy.

• Checklist: DNS resolve api.parceiro.com? rota de saída existe? NAT configurado? firewall libera 443? TLS falha por inspeção/cadeia? proxy obrigatório?

Caso C: Acesso remoto administrativo

Descrição: Admin tenta SSH em servidor interno e recebe “Connection refused”.

• Interpretação: “refused” sugere que chegou ao host, mas não há serviço ouvindo na porta (ou há rejeição ativa). Diferente de “timeout”, que sugere bloqueio/rota.

// Dica de prova: diferenciar sintomas comuns
// - NXDOMAIN: DNS não encontrou o nome
// - Timeout: pacote não chegou/foi bloqueado/serviço não respondeu
// - Connection refused: host respondeu, mas a porta não está aceitando conexões
// - TLS handshake failed: problema de certificado/protocolo/cifra/nome do host