Resumo

  • A subopção 11 permite que o relay determine o endereço IPv4 colocado pelo servidor na opção 54. O valor conduz a renovação de volta ao relay; não prova a identidade nem a interface do servidor real.
  • Broadcast/unicast original, giaddr, attachment metadata, decisão do lease e resultado do cliente são fatos diferentes. A transformação feita pelo relay exige proveniência explícita.

O log do servidor mostra um DHCPREQUEST vindo do relay. A equipe presume que o cliente havia transmitido em broadcast. A suposição muda o tratamento da mensagem, mas não há Relay Agent Flags indicando a forma original. O pacote observado pelo servidor já passou por uma transformação e não pode contar sozinho como nasceu.

No fluxo inicial de DHCPv4, o relay consegue acrescentar Relay Agent Information ao DHCPDISCOVER. Circuit-ID, Remote-ID e outras subopções permitem ao servidor considerar o ponto de acesso. Depois do lease, o cliente em RENEWING normalmente envia DHCPREQUEST diretamente ao endereço de Server Identifier. Esse caminho pode contornar o relay e retirar o contexto da renovação.

RFC 5107 usa Server Identifier Override, código 11 e comprimento quatro. O relay fornece um IPv4; o servidor compatível deve copiar esse valor para a opção 54 da resposta. O cliente passa a enviar a renovação ao endereço do relay, que inclui informação atual e encaminha o pedido ao servidor que realmente mantém o lease.

Logo, o campo chamado identificador do servidor pode carregar um endereço que não pertence ao servidor. Ele identifica um ponto de retorno no plano de controle. Instância real, autoridade sobre o lease e destino usado pelo cliente precisam de campos separados.

O servidor deve registrar o endereço de override para mensagens posteriores daquele cliente até receber nova mensagem do relay. Esse estado tem geração, origem e duração. Sem identificador de geração, um restart ou uma migração pode deixar o lease válido e o caminho de retorno obsoleto.

Um servidor sem suporte ignora a subopção e usa sua própria interface na opção 54. A aquisição inicial pode funcionar. Na renovação, o cliente vai direto ao servidor, o relay não insere Circuit-ID ou Remote-ID e uma política dependente desses dados pode falhar. ACK inicial não demonstra compatibilidade do ciclo inteiro.

Em pool misto, o comportamento deve ser medido por instância. A taxa global de leases esconde se um servidor ecoou o override e outro o descartou. O recibo precisa comparar a subopção recebida, a opção 54 emitida e o caminho observado do RENEW.

Normalmente o servidor verifica se a opção 54 do DHCPREQUEST é uma de suas interfaces. Com o override, compara a opção 54 à subopção 11. Se forem iguais, pode processar a solicitação embora o endereço não seja local.

Essa igualdade não autentica ninguém. Ela apenas verifica consistência de campos. Não prova quem inseriu o override, que o relay era confiável, que o cliente recebeu uma resposta autêntica ou que o servidor controla aquele endereço. Um painel que chama isso de “server verified” excede o protocolo.

O giaddr continua sendo preenchido. O override não substitui a pista de rede usada na alocação nem Circuit-ID, Remote-ID ou Device Class. Também não substitui o fato de o cliente ter enviado originalmente por broadcast ou unicast.

Por isso RFC 5107 recomenda Relay Agent Flags de RFC 5010. O servidor recebe uma mensagem encaminhada e pode precisar saber a forma original. Sem o flag, deduzir a origem a partir do transporte relay-servidor confunde dois trechos.

Quando o relay atende mais de um servidor, deve encaminhar todos os DHCP messages, inclusive renewals, a todos. O objetivo é evitar uma tabela paralela de leases no relay. Cada servidor compara o pedido ao próprio estado e o dono responde.

O fan-out exige recibos por destino. relay_received não implica server_received; um ACK não prova que todos os envios ocorreram; silêncio de um servidor sem lease não equivale a perda. A correlação deve conservar transaction ID, geração do override e identidade interna da instância.

O endereço substituído transforma o relay em dependência da continuidade. Se o cliente não alcança o relay, a primeira perna falha. Se o relay não alcança o servidor, a segunda falha. A opção 54 pode continuar sintaticamente correta durante toda a expiração do lease.

Uma cadeia observável registra ingresso do cliente, endereço escolhido, giaddr, flag original, digest de Relay Agent Information, recebimento pelo servidor, persistência do override, opção 54 devolvida, recebimento pelo cliente, retorno da renovação, fan-out, decisão do lease, aplicação e primeiro tráfego.

Reinícios precisam ser ensaiados. O servidor pode restaurar o lease sem o estado auxiliar. O cliente preserva a opção 54 anterior. O diagnóstico correto é override_state_lost, não “cliente pediu servidor errado”. A diferença determina se a correção é persistência, compatibilidade ou rede.

Migrações também separam endereço e identidade. Um anycast pode continuar igual com novos relays. O conjunto de servidores pode permanecer igual enquanto o endereço de retorno muda. Versionar apenas a opção 54 impede provar quem tomou a decisão.

O limite de segurança está na confiança relay-servidor. Um relay malicioso pode escolher o próprio endereço, atrair futuras renovações, negá-las, alterar opções no DHCPACK ou apresentar um lease maior. RFC 5107 declara que a subopção sozinha não acrescenta segurança.

DHCP Authentication e autenticação de Relay Agent Information protegem relações diferentes. O registro deve dizer qual principal foi autenticado e quais campos foram cobertos. Autenticar o relay perante o servidor não é autenticar o servidor perante o cliente.

Mesmo um DHCPACK íntegro e recebido ainda não prova aplicação de endereço, máscara, router ou rota. Aplicação não prova política de acesso, tráfego ou serviço. A evidência de option 54 termina muito antes desses resultados.

O erro de gestão é transformar nomes de campos em conclusões. Server Identifier pode ser deliberadamente o endereço do relay. Um modelo honesto preserva client_return_address, supplying_relay, actual_server_instance, lease_authority e authentication_receipt como dimensões independentes.

Fontes