Serviços de rede: DHCP, DNS e outros

O DHCP, protocolo de configuração dinâmica de hosts, fornece um endereço IPv4 e configurações por um período limitado chamado concessão. O servidor escuta na porta UDP 67; o cliente usa a porta UDP 68. Notebooks, impressoras, telefones e interfaces de roteadores podem ser clientes. No Cisco IOS, ip address dhcp faz uma interface solicitar suas configurações.

Obtenha a primeira concessão

Um novo cliente usa quatro mensagens, lembradas como DORA:

1. Discover: sem um endereço utilizável ou servidor conhecido, o cliente envia um broadcast de 0.0.0.0 para 255.255.255.255.
2. Offer: um servidor oferece um endereço, um tempo de concessão e configurações.
3. Request: o cliente solicita a oferta escolhida. Essa solicitação normalmente é enviada por broadcast, para que os outros servidores que fizeram ofertas saibam que não foram selecionados.
4. Acknowledge: o servidor escolhido confirma a concessão. O cliente agora pode usá-la.

Por exemplo, um notebook recebe 192.168.10.57/24, gateway 192.168.10.1, servidor DNS 192.168.10.5 e uma concessão de 8 horas. Muitos clientes verificam o endereço com ARP antes de usá-lo. Se outro host responder por esse endereço, o cliente envia DHCPDECLINE e recomeça.

As configurações chegam como opções numeradas. A opção 1 fornece a máscara de sub-rede, a 3 o roteador, a 6 os servidores DNS, a 15 o nome de domínio e a 51 o tempo de concessão. Opções como 43 ou 150 ajudam telefones e pontos de acesso a encontrar uma controladora ou um servidor de configuração. Portanto, um endereço correto com um servidor DNS incorreto ainda é um problema de configuração DHCP.

Renove antes do fim da concessão

A concessão tem dois tempos padrão de renovação, medidos a partir de seu início:

Uma confirmação durante a renovação reinicia a concessão, geralmente para o mesmo endereço. Os usuários continuam trabalhando durante a renovação normal em segundo plano; uma concessão curta não os desconecta em intervalos programados.

No Windows, ipconfig /all mostra o servidor e os horários da concessão. ipconfig /release devolve o endereço, e ipconfig /renew solicita uma concessão. Um dispositivo que sai sem liberar o endereço ainda ocupa sua concessão até ela expirar. Se o DHCP falhar, o Windows pode atribuir a si mesmo um endereço APIPA local de enlace, como 169.254.37.112. Isso permite a comunicação com outros hosts locais de enlace nesse segmento, mas não fornece acesso roteado à internet.

Compare a configuração de endereços IPv6

Com SLAAC, um host constrói um endereço IPv6 usando um prefixo /64 anunciado por um roteador. Sinalizadores do anúncio de roteador direcionam os hosts ao DHCPv6: M solicita configuração de endereço gerenciada; O solicita outras configurações, como DNS. O DHCPv6 com estado fornece um endereço; o DHCPv6 sem estado fornece configurações adicionais enquanto a SLAAC fornece o endereço. O DHCPv6 usa UDP 546 para clientes e 547 para servidores. O gateway padrão vem de anúncios de roteador ou de configuração manual, não do DHCPv6.

Um escopo, chamado de pool em dispositivos Cisco, combina os endereços que podem ser concedidos em uma sub-rede com as configurações necessárias aos clientes. Planeje os endereços antes de inserir comandos, para que o servidor DHCP e os dispositivos configurados manualmente nunca reivindiquem o mesmo endereço.

Escolha a faixa disponível

Comece pela rede, pelo prefixo e pela faixa de endereços utilizáveis de hosts. Liste o gateway, os servidores e outros dispositivos fixos e exclua seus endereços. Para 192.168.10.0/24, a faixa utilizável vai de .1 a .254. Excluir de .1 a .20 deixa de .21 a .254:

Esse pool comporta 234 concessões. Uma previsão de 260 clientes não caberá nele; use uma sub-rede maior, como uma /23 com 510 endereços utilizáveis, ou outra sub-rede. Considere o espaço excluído e reservado, além dos usuários ativos, ao planejar a expansão.

Uma exclusão determina que o servidor nunca conceda um endereço. Uma reserva vincula um endereço a um endereço MAC ou identificador de cliente específico, enquanto o dispositivo continua usando DHCP. Uma impressora com reserva recebe configurações DNS atualizadas na renovação. Uma impressora com configuração estática inserida manualmente deve ser atualizada no próprio dispositivo.

Configure um pool no Cisco IOS

Insira a exclusão na configuração global. As demais configurações pertencem ao pool:

ip dhcp excluded-address 192.168.10.1 192.168.10.20
ip dhcp pool OFFICE
 network 192.168.10.0 255.255.255.0
 default-router 192.168.10.1
 dns-server 192.168.10.5
 domain-name example.com
 lease 0 8

lease 0 8 significa 0 dias e 8 horas. Sem um comando de concessão, o padrão do IOS é 1 dia. O gateway deve corresponder a esta sub-rede; copiar o default-router de outro pool pode deixar os clientes capazes de alcançar hosts locais, mas sem conseguir sair de sua rede.

Verifique o resultado com show ip dhcp pool para consultar a capacidade do pool, show ip dhcp binding para clientes e horários de expiração e show ip dhcp conflict para endereços removidos após um conflito. O Windows Server usa os mesmos conceitos de escopo, exclusão, reserva e opção; as opções de escopo podem substituir as opções de todo o servidor.

Ajuste o tempo de concessão e a redundância à demanda

O Wi-Fi de visitantes se beneficia de concessões de aproximadamente 1–4 horas, pois os dispositivos que saíram liberam seu espaço mais cedo por meio da expiração. Computadores fixos podem usar concessões de vários dias; o padrão do Windows Server é 8 dias. Um pool de 200 endereços com 60 novos dispositivos de visitantes por dia pode ficar cheio em cerca de 3,3 dias se essas concessões permanecerem ocupadas. Reduzir a duração configurada ajuda à medida que novas concessões e renovações entram em vigor; isso não apaga imediatamente as concessões existentes.

Dois servidores podem dividir a faixa sem sobreposição, por exemplo, em uma divisão 80/20, ou usar um recurso de comutação por falha compatível que compartilhe o estado das concessões. Dois servidores independentes não devem alocar livremente os mesmos endereços: caso contrário, cada um poderia fornecer um mesmo endereço a um cliente diferente.

Um cliente envia seu Discover por broadcast no segmento local. Um roteador comum não encaminha esse broadcast, portanto um servidor DHCP em outra sub-rede precisa de um agente de retransmissão para recebê-lo. O agente geralmente funciona na interface de roteador ou comutador de camada 3 que serve como gateway da sub-rede do cliente.

Retransmita a solicitação e identifique a sub-rede

O agente recebe o broadcast e envia uma solicitação por unicast ao servidor. Ele insere o endereço de sua interface voltada para os clientes em giaddr, o campo de endereço IP do gateway. O servidor usa esse endereço para selecionar o escopo do cliente e envia sua resposta de volta pelo agente de retransmissão.

Para a VLAN 20, suponha que o gateway seja 192.168.20.1 em GigabitEthernet0/1 e o servidor seja 10.0.0.10. Configure:

interface GigabitEthernet0/1
 ip helper-address 10.0.0.10

O comando pertence à interface voltada para os clientes. Um helper na interface voltada para o servidor não recebe o broadcast do cliente. O servidor também precisa de um escopo para 192.168.20.0/24 e de uma rota de retorno para 192.168.20.1. Uma segunda linha de helper pode indicar um servidor de backup. No IOS, endereços helper encaminham vários serviços de broadcast UDP por padrão, incluindo DNS e TFTP; por isso, examine esse comportamento ao projetar a rede.

Investigue a partir do cliente

Use o sintoma para escolher a próxima verificação:

Em seguida, examine o caminho. Confirme a VLAN da porta do comutador, o endereço do servidor no helper, o roteamento nas duas direções e as regras de ACL ou firewall para DHCP. Clientes usam UDP 68 e servidores UDP 67; o tráfego do agente de retransmissão ao servidor usa a porta do servidor. Um serviço DNS funcionando não demonstra que o tráfego DHCP é permitido.

Por exemplo, a VLAN 10 funciona, mas uma nova VLAN 30 recebe apenas endereços APIPA. Se o servidor for remoto e a VLAN 30 não tiver helper, seu Discover nunca chegará ao servidor. Adicione o agente de retransmissão ao gateway dessa VLAN e verifique se o servidor tem um escopo correspondente antes de testar a renovação novamente.

Corrija a causa antes de limpar o estado

Um pool esgotado não tem endereços livres para oferecer. Em show ip dhcp pool, compare os endereços concedidos com o total menos os endereços excluídos e verifique a lista de conflitos para identificar mais espaço indisponível. Solicitações repetidas de ipconfig /renew não podem criar capacidade. Examine exclusões e reservas desatualizadas, ajuste a duração das concessões à rotatividade ou amplie o espaço de endereçamento.

Um dispositivo estático dentro do pool dinâmico pode causar avisos de endereço duplicado. Encontre e corrija essa sobreposição e, em seguida, limpe as entradas de conflito resolvidas com clear ip dhcp conflict *, quando apropriado. Limpar a lista enquanto o endereço duplicado ainda existe favorece a repetição da falha.

Um servidor DHCP não autorizado, frequentemente um roteador doméstico conectado à rede, pode fornecer o gateway errado. Identifique-o pela configuração do cliente e remova-o. A inspeção DHCP impede que portas não confiáveis do comutador enviem respostas de servidor, protegendo os próximos clientes do mesmo erro.

O gerenciamento de endereços IP (IPAM) une planejamento, manutenção de registros e descoberta. Ele responde a perguntas práticas: qual sub-rede pertence a esta VLAN? Quem é responsável por este endereço? Ele é estático, reservado ou concedido? Em qual faixa ainda há espaço? Uma planilha pode conter um plano pequeno; uma ferramenta dedicada também pode comparar esse plano com os dispositivos em operação. Produtos que combinam DNS, DHCP e IPAM são chamados de DDI.

Registre informações suficientes para fazer a próxima mudança com segurança

Para cada sub-rede, registre sua rede e seu prefixo, identificador de VLAN, gateway, finalidade, localização, faixa DHCP e exclusões. Para cada atribuição estática, registre o nome do host, o endereço MAC, o tipo de dispositivo, o responsável e a data de atribuição. Esses campos permitem distinguir um endereço que apenas não responde de um disponível para reutilização.

Uma unidade que usa 10.20.0.0/16 pode atribuir:

Em cada sub-rede, .1 pode ser o gateway, .2–.20 a faixa fixa e .21–.254 a faixa DHCP. Documentar esse padrão ajuda um profissional a reconhecer a função de um dispositivo e impede que duas equipes aloquem espaços sobrepostos. O plano ainda precisa de um registro individual quando um endereço fixo é atribuído.

Meça a capacidade disponível

A taxa de utilização de endereços compara os endereços em uso com os endereços utilizáveis:

Uma /22 tem 1.022 endereços IPv4 utilizáveis. Se 870 estiverem em uso, a taxa de utilização será de aproximadamente 85,1%. Um limiar de alerta de 80% já teria acionado o planejamento de mais espaço. Mantenha essa medida da sub-rede separada da disponibilidade do pool DHCP: exclusões e reservas podem deixar um pool dinâmico cheio mesmo enquanto a sub-rede ainda tem endereços não atribuídos.

Concilie o plano com as evidências

A descoberta do IPAM pode ler concessões DHCP, registros DNS e tabelas ARP de roteadores e varrer sub-redes. Compare essas fontes: um endereço descoberto sem responsável pode ser de um dispositivo não documentado; um servidor registrado sem evidência atual pode ter sido retirado de uso. Investigue a diferença antes de alterar a atribuição.

Antes de atribuir um endereço estático, verifique o registro IPAM, as concessões DHCP e o DNS. Um ping sem resposta é evidência insuficiente: o atual usuário do endereço pode estar desligado ou bloquear pings. Após atribuir o endereço, registre o dispositivo e proteja a atribuição contra o DHCP. Ao retirar o dispositivo de uso, recupere o endereço e remova registros DNS desatualizados para que um futuro usuário não herde o nome antigo.

O DHCP pode atualizar o DNS dinamicamente, mantendo os registros A e PTR de um cliente alinhados à sua concessão. O IPAM reúne esses registros em uma única visão, mas a descoberta automática ainda precisa de um plano preciso e de informações sobre responsáveis para explicar a função esperada de um dispositivo.

O IPv6 elimina a pressão de contar cada endereço de host possível em uma /64. Isso não elimina a necessidade de planejar. Registre qual prefixo /64 pertence a cada unidade e VLAN, juntamente com os gateways e as atribuições fixas importantes. Acompanhe a estrutura e os responsáveis pelo espaço de endereçamento mesmo quando endereços individuais de hosts mudam com frequência.

O DNS, sistema de nomes de domínio, armazena informações sob nomes organizados em uma árvore. Leia www.example.com. da direita para a esquerda: a raiz é o ponto final, com é o domínio de primeiro nível e example e www identificam níveis inferiores. Um nome de domínio totalmente qualificado (FQDN) fornece o caminho completo até a raiz.

Descubra quem é responsável pela resposta

Uma zona é uma parte gerenciada dessa árvore, mantida em servidores de nomes autoritativos. O primário mantém a cópia editável; os secundários mantêm cópias somente de leitura obtidas por transferência de zona via TCP 53. O número de série do SOA permite que os secundários detectem uma versão mais recente. Vários servidores autoritativos mantêm as respostas disponíveis quando um servidor falha.

Leia o tipo de registro antes de seu valor

Por exemplo, "www.example.com. 3600 IN A 203.0.113.10" associa um nome a um endereço IPv4. "www.example.com. 3600 IN AAAA 2001:db8::10" fornece um IPv6. Nesses registros, 3600 é o tempo de permanência em cache em segundos e IN é a classe internet.

Um nome alternativo como "shop.example.com. 3600 IN CNAME www.example.com." aponta para o nome, não diretamente para seu endereço. Uma consulta segue esse destino para obter uma resposta A ou AAAA. Um CNAME não pode compartilhar seu nome com dados comuns, como registros A, MX, SOA ou NS. Metadados DNSSEC são uma exceção especial. O ápice da zona precisa de registros SOA e NS, portanto um CNAME padrão não pode ser colocado ali; recursos de alias ou flattening de provedores tratam registros de outra maneira.

As preferências MX seguem a direção oposta à de uma pontuação em que “quanto maior, melhor”. Com preferência 10 para mail1.example.com. e 20 para mail2.example.com., os remetentes tentam mail1 primeiro. Valores MX devem ser nomes de host com registros A ou AAAA diretos. Destinos MX e NS não devem ser nomes alternativos CNAME.

Inverta o endereço e controle o cache

Consultas diretas começam com um nome; consultas reversas começam com um endereço. Para o endereço IPv4 203.0.113.25, o nome do registro PTR é 25.113.0.203.in-addr.arpa.. A consulta reversa IPv6 usa dígitos hexadecimais invertidos sob ip6.arpa. Adicionar um registro A não cria um PTR, a menos que um recurso de atualização faça isso.

O tempo de vida (TTL) é o tempo máximo normal de permanência em cache em segundos: 300 são 5 minutos, 3600 é uma hora e 86400 é um dia. Antes de alterar um endereço, reduza o TTL de 86400 para 300 e aguarde pelo menos o antigo TTL de um dia. Depois, altere o endereço, permitindo que caches comuns sejam atualizados em até 5 minutos, e aumente novamente o TTL após a mudança.

Em um arquivo de zona, um nome sem ponto final é relativo à zona atual. Escrever mail.example.com na zona example.com produz mail.example.com.example.com. Use mail.example.com. para o nome completo ou o nome relativo mail.

Um computador normalmente não contata cada servidor DNS por conta própria. Seu resolvedor simplificado pede a um resolvedor recursivo que obtenha a resposta. O resolvedor tem uma resposta utilizável em cache ou contata os servidores autoritativos por partes do nome.

Comece pelo cliente

As fontes locais incluem o arquivo hosts e o cache DNS do cliente. Uma entrada no hosts pode ter prioridade sobre o DNS para aquele computador. O caminho no Windows é C:\Windows\System32\drivers\etc\hosts; Linux e macOS usam /etc/hosts. Uma entrada de teste esquecida pode explicar por que um computador acessa um servidor antigo enquanto todos os outros funcionam.

O cliente obtém o endereço de seu resolvedor pela opção DHCP 6 ou por configuração manual. Sua solicitação é recursiva: ele pede a esse resolvedor a resposta final. O cliente está delegando a busca, não pedindo orientações para encontrar o próximo servidor DNS.

Siga da raiz em direção ao nome

Para uma consulta a www.example.com com caches vazios:

1. O cliente consulta seu resolvedor recursivo.
2. O resolvedor consulta um servidor raiz, que o encaminha aos servidores com.
3. Um servidor com o encaminha aos servidores autoritativos de example.com.
4. Um servidor do domínio retorna "A 203.0.113.10", com TTL 3600.
5. O resolvedor armazena essa resposta em cache e a devolve ao cliente.

As solicitações do resolvedor ao longo da hierarquia são iterativas: cada servidor fornece sua melhor resposta ou referência. A raiz não contém o endereço de todos os sites. Há 13 identidades de servidores raiz, nomeadas de a a m, cada uma atendida por muitos sistemas físicos que usam endereços anycast.

O próximo cliente pode receber a resposta em cache sem repetir essa busca. Uma ferramenta pode identificá-la como "Non-authoritative answer"; isso identifica a origem da resposta, não um erro. Referências e respostas negativas também são armazenadas em cache. Portanto, um resultado NXDOMAIN pode continuar aparecendo depois que um nome ausente for adicionado, até que termine o tempo de permanência da resposta negativa em cache.

Use encaminhamento quando outro resolvedor deve fazer a busca

Um resolvedor pode enviar solicitações não respondidas a um encaminhador externo, que realiza a busca. Um encaminhador condicional envia solicitações de determinado domínio a servidores designados. Por exemplo, uma empresa pode direcionar o domínio interno de um parceiro ao resolvedor desse parceiro e enviar nomes públicos comuns a outro destino.

Diferencie privacidade de autenticidade

O DNS comum usa UDP ou TCP na porta 53. A maioria das consultas pequenas usa UDP; transferências de zona e muitas respostas grandes usam TCP. O DNS sobre TLS (DoT) criptografa a conexão entre cliente e resolvedor na porta TCP 853. O DNS sobre HTTPS (DoH) transporta consultas por HTTPS na porta 443 e pode contornar filtros que observam apenas o DNS comum.

O DNSSEC, por sua vez, permite que um resolvedor que faz validação verifique assinaturas e detecte dados DNS alterados ou falsificados. Ele não criptografa consultas nem respostas. A criptografia protege o caminho de transporte; os dados assinados dão suporte à autenticidade.

Após uma alteração de endereço, servidores autoritativos publicam os novos dados, mas não os enviam diretamente ao cache de cada resolvedor. Os usuários podem receber temporariamente respostas diferentes porque suas cópias em cache têm TTLs restantes diferentes. Esse tempo de permanência em cache explica o atraso geralmente descrito como “propagação de DNS”.

Comece pela falha exata. “Não foi possível encontrar o host” significa que uma consulta de nome falhou. “Conexão recusada” após uma consulta bem-sucedida aponta para outro problema. Testar um endereço conhecido e depois seu nome ajuda a separar a resolução de nomes do acesso ao destino.

Se ping 203.0.113.10 funcionar, mas ping www.example.com informar que não consegue encontrar o host, investigue a resolução. Se ambos falharem, verifique o endereçamento e o roteamento, mas lembre-se de que o ping também pode ser filtrado. Um ping malsucedido, por si só, não pode comprovar que o DNS está com defeito ou que o serviço está inacessível.

Consulte diretamente o servidor correto

Encontre os servidores DNS configurados usando ipconfig /all, resolvectl status ou /etc/resolv.conf, conforme aplicável. Depois compare as consultas:

nslookup www.example.com
nslookup www.example.com 192.0.2.53
nslookup -type=MX example.com
dig @192.0.2.53 example.com MX
dig -x 203.0.113.25
dig +trace www.example.com
Resolve-DnsName www.example.com -Type AAAA

A primeira consulta testa o resolvedor selecionado pelo cliente; um endereço de servidor explícito testa um resolvedor ou servidor autoritativo escolhido. dig +trace acompanha as referências. Uma consulta direta bem-sucedida, mas uma consulta de aplicação malsucedida, sugere configurações locais, cache ou arquivo hosts.

Interprete a resposta

SERVFAIL pode ocorrer quando um servidor autoritativo está inacessível ou a validação DNSSEC falha. REFUSED é diferente: um servidor acessível pode permitir recursão apenas para clientes internos. Em dig, o sinalizador aa identifica uma resposta autoritativa.

Compare dados antigos e novos

Suponha que um servidor tenha mudado de 203.0.113.10 para 203.0.113.80. O servidor autoritativo retorna .80, enquanto o resolvedor do escritório retorna .10 com tempo restante de um TTL antigo de 86400 segundos. A alteração foi publicada; o cache do escritório está desatualizado. Aguarde a expiração ou limpe os caches do resolvedor e dos clientes afetados. ipconfig /flushdns limpa o cache do cliente Windows, não todos os caches externos. Reduzir o TTL antecipadamente evita uma longa espera durante uma mudança planejada.

Quando apenas um computador apresentar resultado diferente, examine seu arquivo hosts e seu cache local. Quando servidores autoritativos discordarem, compare os números de série SOA: uma zona primária alterada com número de série inalterado pode não ser transferida aos secundários.

Relacione o serviço com falha a seus registros

Um registro A incorreto afeta o IPv4. Um registro AAAA incorreto ou inutilizável pode causar atrasos na conexão IPv6 mesmo quando o IPv4 funciona; um servidor apenas IPv4 não precisa de um registro AAAA. Para correio, verifique os nomes MX e seus registros A ou AAAA diretos. Sem MX, os remetentes podem tentar os próprios registros de endereço do domínio. Um PTR ausente pode afetar a aceitação de mensagens e dificultar a leitura dos logs.

Por fim, permita UDP e TCP na porta 53 onde o DNS comum exigir ambos. Um firewall que permite apenas UDP pode deixar passar respostas pequenas, mas impedir respostas grandes e transferências de zona.

Um horário compartilhado permite comparar eventos. Se um comutador registra uma falha de porta e um roteador registra a perda de um vizinho, marcas de tempo precisas ajudam a estabelecer a ordem. O horário também afeta a validade de certificados e a autenticação: por padrão, o Kerberos do Active Directory permite apenas 5 minutos de diferença entre relógios.

Entenda a hierarquia dos relógios

O NTP, protocolo de tempo de rede, troca pacotes com marcas de tempo via UDP 123. Quatro marcas de tempo permitem que o cliente estime o desvio de seu relógio e o atraso da rede. Ele faz consultas repetidas, geralmente em intervalos de 64–1.024 segundos. Pequenas correções normalmente são feitas de forma gradual, em um processo chamado ajuste gradual do relógio, para evitar saltos repentinos para trás.

Um estrato descreve a distância de um relógio de referência:

Os estratos de rede utilizáveis vão de 1 a 15. Estrato não é uma pontuação de precisão: um servidor de estrato 2 próximo pode produzir resultados melhores que uma fonte de estrato 1 distante, acessada por um caminho com atraso variável.

Use várias fontes externas, idealmente pelo menos quatro, para os servidores de horário internos. Isso permite que o NTP compare fontes e rejeite uma fonte incorreta. Outros dispositivos de rede podem se sincronizar com esses servidores internos, limitando o tráfego externo e mantendo a linha do tempo local consistente.

Configure e verifique um cliente

No Cisco IOS, ntp server 192.0.2.123 seleciona um servidor de origem; adicionar prefer marca uma fonte preferencial. Um dispositivo sincronizado pode então responder a solicitações de horário de outros dispositivos. ntp master 4, por sua vez, anuncia o próprio relógio do roteador como fonte de estrato 4. O padrão é estrato 8 quando o número é omitido. Use uma referência local assim somente quando não houver fonte melhor, como em um laboratório isolado.

Consulte show ntp status para verificar a sincronização e o estrato local. Se a fonte for de estrato 2, o cliente sincronizado passa a ser de estrato 3. Em show ntp associations, um asterisco indica a fonte selecionada. Aguarde vários minutos para que uma nova associação se estabilize antes de tratar o estado inicial não sincronizado como uma falha persistente.

O NTP distribui o horário em UTC. As configurações de fuso horário e horário de verão do dispositivo controlam o horário local exibido. Por exemplo, clock timezone CET 1 define um desvio padrão de uma hora no IOS. Um erro de exatamente um número inteiro de horas sugere um problema nas configurações de exibição. Muitas organizações registram eventos em UTC para evitar conversões entre unidades durante um incidente.

Proteja o horário e escolha a precisão necessária

A autenticação por chave simétrica limita as fontes de horário aceitas àquelas que compartilham a chave configurada. A segurança do tempo de rede (NTS) usa uma troca de chaves baseada em TLS na porta TCP 4460 e depois autentica os pacotes NTP, que continuam trafegando pela porta UDP 123. Restrinja também quais hosts podem consultar ou controlar os serviços de horário.

O protocolo de tempo de precisão (PTP, IEEE 1588) segue um relógio mestre principal e usa marcas de tempo geradas por hardware em placas de rede e comutadores para alcançar precisão inferior a um microssegundo em redes locais adequadas. Ele atende necessidades como redes móveis e controle industrial, para as quais a precisão do NTP comum na escala de milissegundos é insuficiente. O PTP pode funcionar sobre Ethernet ou IP; o transporte por IP usa UDP 319 para mensagens de eventos e UDP 320 para mensagens gerais. O SNTP é uma implementação mais simples do NTP para clientes com necessidades de horário menos exigentes.

O SNMP, protocolo simples de gerenciamento de rede, permite que um gerente de monitoramento leia dados de um agente em um dispositivo. Os dados são descritos por uma base de informações de gerenciamento (MIB). Cada objeto tem um identificador de objeto (OID), um caminho pontuado em uma árvore. Por exemplo, 1.3.6.1.2.1.1.5.0 identifica sysName; 1.3.6.1.2.1.1.3.0 identifica sysUpTime. Objetos dos fabricantes ficam sob o ramo enterprises, 1.3.6.1.4.1.

Combine consultas periódicas com alertas

O agente escuta na porta UDP 161 para receber solicitações. O gerente recebe traps e informs na porta UDP 162.

Um gerente pode consultar tráfego, CPU e memória a cada 5 minutos para criar gráficos. Uma trap pode informar imediatamente a falha de um enlace. Use ambos: traps podem se perder por UDP, e um dispositivo com falha pode não conseguir enviar nenhuma notificação. Informs são reenviadas conforme as configurações de tempo limite e novas tentativas, mas ainda podem falhar depois que as tentativas se esgotam.

Escolha uma versão segura

O SNMPv1 e o v2c enviam uma string de comunidade em texto simples. O acesso somente de leitura (RO) permite leituras; o acesso de leitura e escrita (RW) também permite alterações compatíveis. A versão 2c acrescenta GetBulk, informs e contadores de alta capacidade. O SNMPv3 usa contas com os níveis de segurança noAuthNoPriv, authNoPriv e authPriv. Prefira authPriv, que autentica e criptografa mensagens, quando houver suporte.

Uma configuração IOS v2c pode usar snmp-server community N3tM0n-RO RO 10 para restringir leituras por meio da ACL 10. snmp-server host 192.0.2.50 version 2c N3tM0n-RO seleciona o destinatário das notificações, e snmp-server enable traps ativa as traps. Um exemplo de v3 é:

snmp-server group NMS v3 priv
snmp-server user monitor NMS v3 auth sha <auth-password> priv aes 128 <priv-password>

Evite comunidades padrão como "public" e "private", limite o acesso aos hosts de gerenciamento e conceda acesso de escrita somente quando necessário. O SNMP disponibiliza objetos MIB; ele não é um interpretador de comandos remoto.

Converta a variação de um contador em taxa de utilização

Contadores medem bytes acumulados, também chamados de octetos. Suponha que ifHCInOctets aumente de 18.250.000.000 para 19.750.000.000 em 300 segundos:

1. Subtraia as leituras: chegaram 1.500.000.000 bytes.
2. Multiplique por 8: chegaram 12.000.000.000 bits.
3. Divida por 300 segundos: 40.000.000 bit/s, ou 40 Mbit/s.
4. Divida pela taxa do enlace de 100 Mbit/s: a taxa média de utilização de entrada foi de 40%.

Essa é uma média do intervalo, portanto picos breves podem ser maiores. Esquecer o fator de conversão de bytes para bits produz uma taxa oito vezes menor.

Um contador de 32 bits chega a 4.294.967.295 e retorna a zero. A 1 Gbit/s, ele retorna ao início em cerca de 34 segundos, portanto um intervalo de consulta de 5 minutos pode deixar passar vários retornos. Use os contadores de 64 bits ifHCInOctets e ifHCOutOctets, compatíveis com v2c e v3, para enlaces rápidos. Verifique a continuidade do contador antes de interpretar uma diferença negativa como tráfego negativo.

O syslog envia mensagens de eventos a um coletor central. A coleta central preserva evidências após reinicializações de dispositivos e permite que um profissional pesquise vários dispositivos em conjunto. Um sistema de gerenciamento de informações e eventos de segurança (SIEM) pode usar esses registros para correlacionar eventos.

O syslog tradicional usa UDP 514. O transporte TCP fornece confirmações de entrega na camada de transporte; TLS sobre TCP 6514 também protege a conexão. Mesmo um transporte confiável precisa de coleta e armazenamento funcionando, portanto verifique se as mensagens realmente chegam.

Interprete corretamente o limiar de severidade

Os níveis syslog vão de 0 a 7, e números menores indicam maior severidade:

Um limiar configurado inclui esse nível e todos os níveis mais graves. logging trap warnings envia os níveis 0–4, não apenas o nível 4. O padrão do IOS para registro remoto é informativo, níveis 0–6. Ativar a depuração envia todos os níveis e pode gerar grande quantidade de tráfego e trabalho de processamento.

Diferencie categoria de origem de severidade

A categoria de origem do syslog identifica uma categoria de fonte. Exemplos incluem kern (0), user (1), mail (2) e auth (4). Local0 a local7, códigos 16–23, estão disponíveis para uso local; dispositivos Cisco usam local7 por padrão. Um coletor pode organizar mensagens de dispositivos de rede usando esse código.

A prioridade de uma mensagem combina os dois campos:

Local7 com severidade 3 produz 187, escrito como "<187>". O número é um par codificado, não uma escala de severidade separada.

O padrão visível das mensagens Cisco é "%FACILITY-SEVERITY-MNEMONIC: description". Em "%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down", LINEPROTO identifica o recurso do IOS, 5 significa Notice e UPDOWN identifica o evento. Esse nome de recurso é diferente da categoria de origem de transporte local7. "%SYS-5-CONFIG_I: Configured from console by admin on vty0" registra uma alteração de configuração.

Escolha destinos e alinhe as marcas de tempo

Os destinos têm configurações separadas. logging buffered 16384 informational mantém um buffer em memória, consultado com show logging. logging host 192.0.2.50 seleciona um coletor. logging trap warnings define seu limiar. Em uma sessão de terminal remoto, terminal monitor exibe as mensagens monitoradas. A saída de depuração no console pode sobrecarregar a CPU de um dispositivo ocupado.

Use service timestamps log datetime msec para adicionar marcas de data e hora com milissegundos e o NTP para sincronizar os relógios. Um evento de queda de porta às 10:42:13,208, a perda de um vizinho pelo roteador às 10:42:13,350 e o retorno da porta às 10:42:17,511 formam uma sequência útil. Eles sugerem um problema relacionado ao enlace que merece investigação; por si só, não identificam um cabo defeituoso. Sem horário compartilhado, a ordem aparente pode simplesmente refletir um erro de relógio.

Uma chamada de voz e uma transferência de arquivo reagem de forma diferente ao congestionamento. Um arquivo pode esperar enquanto o TCP retransmite dados ausentes. Uma conversa é prejudicada quando pacotes chegam atrasados, chegam em intervalos irregulares ou desaparecem. A qualidade de serviço (QoS) permite que a rede dê tratamentos diferentes a tráfegos diferentes.

Identifique a necessidade do serviço

Quatro propriedades são importantes: largura de banda, a quantidade enviada por segundo; atraso, o tempo de percurso de ponta a ponta; variação do atraso, a variação nesse tempo; e perda, a proporção de pacotes descartados. Metas comuns de projeto para voz são no máximo 150 ms de atraso em um sentido, 30 ms de variação do atraso e 1% de perda. Essas são metas de planejamento para voz interativa utilizável, não capacidade adicional criada por uma política.

A QoS é um comportamento por salto (PHB). Cada roteador ou comutador aplica sua própria política. Um pacote marcado para prioridade ainda precisa que cada salto congestionado reconheça e atenda essa classe. As prioridades de fila mudam a ordem de atendimento quando há disputa por tráfego; classificação, marcação e limites de taxa podem atuar mesmo em um enlace sem congestionamento.

Classifique primeiro, depois marque

A classificação identifica o tráfego usando endereços e portas, uma interface de entrada, uma marcação existente ou reconhecimento de aplicações, como o Cisco NBAR. A marcação escreve um valor em um quadro ou pacote para que os dispositivos seguintes possam identificar sua classe com pouco esforço.

O DSCP ocupa seis bits do byte ToS do IPv4 ou do campo Traffic Class do IPv6. Os dois bits restantes são usados para ECN, notificação explícita de congestionamento. A CoS não pode aparecer em um quadro enviado sem a etiqueta de VLAN.

Interprete valores DSCP comuns

Melhor esforço é 0. O encaminhamento expresso (EF) é 46, em binário 101110, comumente usado para mídia de voz. O encaminhamento assegurado (AFxy) identifica a classe x, de 1–4, e a precedência de descarte y, de 1–3:

Assim, AF11, AF21, AF31 e AF41 são 10, 18, 26 e 34. Para AF32, calcule 8 vezes 3 mais 2 vezes 2 para obter 28. Dentro da classe 4, AF43 (38) tem precedência de descarte maior que AF42 (36), que é maior que AF41 (34). Maior precedência de descarte significa maior preferência de descarte durante o congestionamento, não melhor proteção. A política configurada determina os recursos entre diferentes classes AF.

Os seletores de classe usam 8 vezes seu número: CS3 é 24, frequentemente usado para sinalização de chamadas; CS6 é 48, comumente usado para tráfego de roteamento.

Decida em quais marcações confiar

Em um limite de confiança, a rede decide quais marcações recebidas ela respeitará. Um comutador de acesso pode confiar em um telefone IP enquanto remarca o tráfego do computador conectado como melhor esforço. Caso contrário, um usuário poderia marcar um download grande como EF e competir com as chamadas. Serviços comuns de provedores de internet geralmente não preservam o tratamento de QoS de um cliente de ponta a ponta.

Para dimensionar a capacidade de voz, inclua os cabeçalhos. Uma chamada G.711 que envia 50 pacotes por segundo, cada um com 160 bytes de voz mais 40 bytes de cabeçalho, usa 200 bytes por pacote. Multiplicar por 8 e depois por 50 resulta em 80.000 bit/s, ou 80 kbit/s por direção. Vinte chamadas usam 1,6 Mbit/s em cada direção na camada IP, antes da sobrecarga da camada 2.

O congestionamento começa quando pacotes chegam mais rápido do que uma interface consegue enviá-los. Uma LAN de 1 Gbit/s alimentando uma WAN de 100 Mbit/s pode criar esse gargalo mesmo que a própria LAN esteja pouco carregada. Os pacotes em espera entram em uma fila de saída; o tempo nela acrescenta atraso.

Selecione o próximo pacote a enviar

FIFO, primeiro a entrar, primeiro a sair, envia pacotes na ordem de chegada. O enfileiramento justo ponderado baseado em classes (CBWFQ) fornece parcelas mínimas de largura de banda às classes de tráfego durante o congestionamento. O enfileiramento de baixa latência (LLQ) acrescenta uma fila de prioridade estrita para tráfego sensível a atrasos, com um limite configurado para proteger as demais classes.

Em uma WAN de 100 Mbit/s, uma política pode alocar uma classe prioritária de 10 Mbit/s para voz, garantir 30% para aplicações empresariais e deixar o restante para o tráfego padrão. Uma garantia de largura de banda é uma parcela mínima sob disputa, não necessariamente um máximo quando outras classes estão ociosas. O limite de prioridade impede que o tráfego da classe de voz consuma todo o enlace congestionado.

Descarte antes que todas as filas encham juntas

O descarte de cauda descarta pacotes recém-chegados quando uma fila está cheia. Se muitos fluxos TCP sofrerem essa perda juntos, todos podem reduzir a velocidade e depois aumentá-la juntos. Essa sincronização global desperdiça capacidade.

A detecção antecipada aleatória ponderada (WRED) começa a descartar pacotes selecionados antes que a fila fique cheia. Assim, os fluxos reduzem a velocidade em momentos diferentes. Uma política que considera o DSCP pode descartar AF13 com mais facilidade que AF11 porque ambos estão na classe 1, mas AF13 tem maior precedência de descarte. A voz UDP não reduz sua taxa de envio em resposta a essa perda, portanto o WRED não é o tratamento habitual para a fila prioritária de voz.

Diferencie policiamento de modelagem

Um provedor pode policiar na taxa de informação comprometida (CIR). Rajadas acima do contratado podem ser descartadas mesmo que a porta física seja mais rápida. O TCP pode apresentar um padrão de dente de serra à medida que se recupera e é reduzido novamente.

Um modelador armazena rajadas localmente em buffer e libera o tráfego na taxa configurada. Sua quantidade permitida por intervalo é:

Para 200 Mbit/s e um intervalo de 10 ms, converta 10 ms para 0,010 s. A multiplicação resulta em 2.000.000 bits por intervalo; a divisão por 8 resulta em 250.000 bytes.

Suponha que a unidade tenha uma conexão de 1 Gbit/s, mas o provedor policie a 200 Mbit/s. Modele o tráfego de saída da unidade para 200 Mbit/s e aplique a fila de voz dentro desse modelador. A espera ocorre, assim, onde a unidade controla a prioridade, antes que o provedor descarte os pacotes excedentes.

Aplique e examine a política

No IOS, um class-map identifica o tráfego, um policy-map define ações e service-policy associa a política a uma interface e direção. Uma política de filas só altera a disputa durante o congestionamento. O policiamento e a modelagem continuam impondo sua taxa configurada em um enlace que, de outro modo, estaria ocioso. Filas grandes demais podem piorar o atraso de voz ao aumentar o tempo de espera.

Um proxy recebe uma solicitação e faz uma solicitação separada ao destino. O cliente se conecta ao proxy, e o proxy se conecta ao destino. Essa função na camada de aplicação permite filtrar, armazenar em cache ou encaminhar solicitações. O NAT, por sua vez, reescreve endereços em pacotes sem atuar como servidor que trata solicitações da aplicação.

Pergunte quem o proxy representa

Um proxy direto pode fornecer uma única saída controlada para a internet aos usuários de uma organização. Um proxy reverso pode publicar www.example.com em 203.0.113.10 enquanto encaminha solicitações a servidores internos como 10.1.1.21 e 10.1.1.22. Quem é representado define a diferença.

Configure ou intercepte o tráfego dos clientes

Um proxy explícito é conhecido pelo cliente. Seu endereço e sua porta, como 10.0.0.8 na porta 3128 ou 8080, podem ser inseridos manualmente, distribuídos por software de gerenciamento ou selecionados por um arquivo PAC de configuração automática de proxy. O WPAD ajuda a descobrir automaticamente a configuração de proxy. Esses números de porta são escolhas comuns, não exigências universais para todos os proxies.

Um proxy transparente recebe tráfego redirecionado pela rede sem configurações de proxy no cliente. Ele ainda pode ser um proxy direto porque atua em nome dos clientes. O conhecimento do cliente e quem o proxy representa são duas comparações diferentes.

Entenda o que acontece com o HTTPS

Com um proxy explícito, um cliente pode enviar uma solicitação CONNECT. O proxy estabelece um túnel, e o tráfego criptografado passa por ele. O proxy pode ver o destino solicitado, mas o tunelamento, por si só, não revela o conteúdo HTTP protegido.

Para inspecionar esse conteúdo, o proxy precisa realizar interceptação TLS. Ele cria conexões protegidas separadas e apresenta certificados assinados pela autoridade certificadora da organização. Os clientes devem confiar nessa autoridade. Aplicações com fixação de certificados podem rejeitar esse certificado substituto, portanto alguns destinos precisam ser isentos da inspeção. A interceptação também altera quem pode ler o tráfego, o que torna a privacidade parte da decisão de projeto.

Um proxy de cache só pode reutilizar respostas quando as regras de cache HTTP permitem. Downloads repetidos de software ou recursos estáticos podem economizar largura de banda WAN. Dados pessoais ou que mudam com frequência muitas vezes não podem ser compartilhados a partir de um cache. Túneis criptografados comuns não dão ao proxy acesso ao conteúdo necessário para essa inspeção e esse armazenamento em cache.

Diagnostique uma falha específica de proxy

Se a navegação falhar enquanto outras aplicações funcionam, examine o endereço, a porta e a acessibilidade do proxy. Se a configuração automática falhar, teste o acesso ao arquivo PAC. Se sites internos falharem apenas por meio do proxy, verifique as regras de exceção: um padrão como *.corp.example.com pode manter essas solicitações no caminho interno.

Para serviços web de entrada, um proxy reverso pode enviar /api a um servidor de aplicação e /images a um servidor de conteúdo estático. Se ele distribuir solicitações elegíveis entre vários servidores de back-end, também estará realizando balanceamento de carga. O encerramento centralizado do TLS simplifica o gerenciamento de certificados, enquanto as conexões internas podem ser criptografadas novamente quando necessário.

Um balanceador de carga apresenta um endereço IP virtual (VIP) aos clientes e envia o tráfego a um pool de servidores de back-end. O cliente usa um único nome de serviço enquanto o pool fornece capacidade e tolera falhas individuais de servidores. Para manutenção, a drenagem de conexões interrompe novas conexões a um servidor e permite que o trabalho existente termine antes de sua remoção.

Teste o serviço antes de enviar trabalho a ele

Uma verificação de integridade deve corresponder ao serviço de que os clientes precisam. O ping testa se um host responde, uma verificação TCP testa se uma porta aceita conexões e uma verificação HTTP pode testar uma página como /health para obter o status 200. Um host pode responder ao ping mesmo depois que seu processo web para de funcionar.

Para shop.example.com, suponha que o VIP seja 203.0.113.20 na porta 443 e o pool seja 10.1.2.11–10.1.2.13 na porta 8080. As verificações ocorrem a cada 5 segundos e marcam um servidor como indisponível após três falhas consecutivas. A detecção leva aproximadamente três intervalos de verificação, cerca de 15 segundos, com o tempo real afetado pela programação das verificações e pelos tempos limite. Quando .13 fica indisponível, novas conexões vão para .11 e .12. Os servidores restantes precisam de capacidade disponível suficiente para a carga adicional.

Escolha como distribuir o trabalho

Pesos 3:2:1 dividem 600 novas conexões em 300, 200 e 100. Com quantidades ativas de 12, 7 e 9, o método do menor número de conexões escolhe o segundo servidor. Esses algoritmos escolhem entre servidores elegíveis em boas condições, não aqueles já removidos pelas verificações de integridade.

Mantenha o estado da sessão disponível

A persistência de sessão envia um usuário de volta ao mesmo servidor quando esse servidor armazena sua sessão, como um carrinho de compras. Um cookie ou endereço de origem pode identificar o usuário. A persistência pode tornar a carga menos uniforme; se esse servidor falhar, sua sessão local pode ser perdida. Um banco de dados ou cache compartilhado permite que outros servidores recuperem a sessão e reduz a dependência de um único back-end.

Um balanceador de camada 4 usa endereços e portas para distribuir tráfego TCP ou UDP sem ler o conteúdo da aplicação. Um balanceador de camada 7 lê informações como nomes de host HTTP, caminhos e cookies. Para inspecionar conteúdo HTTPS, ele encerra o TLS, processo chamado descarregamento de TLS, e pode estabelecer uma nova conexão criptografada com o back-end.

Proteja também o ponto de entrada

Um único balanceador de carga pode falhar. Um par ativo-passivo tem uma unidade em espera pronta para assumir o VIP; uma arquitetura ativo-ativo permite que ambas processem tráfego.

A alternância circular no DNS comum publica vários registros A para um nome e alterna sua ordem. Ela oferece distribuição simples, mas não tem verificações internas de integridade do serviço nem remoção imediata de endereços em cache. Os clientes podem continuar usando um endereço com falha até que os registros sejam alterados e os caches expirem. O balanceamento global de carga entre servidores acrescenta decisões de integridade e localização às respostas DNS, mas os tempos de permanência em cache continuam importantes.