Resumo

  • A RFC 3539 manda agentes e servidores AAA esperar duplicatas em qualquer conexão. A cópia enviada ao alternativo pode chegar primeiro, sem provar que a requisição original deixou de existir.
  • Em autenticação dependente de estado, uma cópia pode receber Accept e outra Reject. Identidade fim a fim, disposição da duplicata, escolha do cliente, aplicação no NAS, reconciliação contábil e resultado para o usuário são comprovantes diferentes.

Alta disponibilidade costuma ser celebrada no instante em que uma rota substituta responde. Esse instante é importante, mas pequeno. Ele prova que um caminho voltou a transportar mensagens. Não prova que o trabalho anterior foi cancelado, que dois servidores compartilham o mesmo estado ou que apenas uma autorização alcançou o equipamento de acesso.

Publicada em junho de 2003 como Proposed Standard, a RFC 3539 trata do perfil de transporte para Authentication, Authorization and Accounting. Ela não descreve uma pane de produção específica. O texto é valioso porque torna visível uma dívida que o painel esconde: para recuperar serviço antes, o cliente pode precisar repetir trabalho cujo destino anterior ainda é desconhecido.

Failover não é teletransporte

Um cliente AAA pode manter conexões com vários agentes ou servidores, em configuração primário/secundário ou de balanceamento. Ao decidir pelo alternativo, ele não dispõe de uma prova instantânea de que todos os pacotes da conexão original saíram da rede. A cópia alternativa pode ultrapassar a original; a original pode aparecer depois.

A RFC 3539 exige, por isso, que agentes e servidores tratem duplicatas e suponham que elas chegam por qualquer conexão. Socket e transação pertencem a camadas diferentes. Uma conexão nova não cria intenção nova. Uma conexão que falhou não apaga intenção já enviada.

O erro operacional ocorre quando “peer indisponível” é convertido em “requisição inexistente”. O primeiro é um diagnóstico de adjacência. O segundo seria uma afirmação sobre toda a jornada, incluindo proxies, filas, servidor final e resposta. O watchdog não tem essa visibilidade.

Um relatório mínimo precisa separar o relógio do peer do relógio da transação: quando a conexão passou a suspeita, quando o watchdog falhou, quando a fila foi copiada, quando cada servidor decidiu e quando cada resposta chegou.

O watchdog não patrulha o realm inteiro

O perfil requer uma mensagem de watchdog na camada de aplicação para descobrir mais depressa falhas de transporte ou da função do peer. Seu desenho é deliberadamente imediato: testa o peer adjacente, não os proxies, servidores e bancos de dados que podem estar atrás dele. Também não é heartbeat de cluster.

Qualquer resposta AAA do peer funciona como evidência de que ele está vivo. A ausência de resposta a uma transação comum não basta para declará-lo morto, pois a espera pode estar no downstream. Só a falha em responder ao watchdog sustenta a mudança de estado prevista pelo algoritmo.

Essa contenção reduz instabilidade em cascata, mas impede inferências amplas. Um watchdog respondido não demonstra disponibilidade do home realm, convergência de réplicas, autorização concluída, perfil instalado ou acesso do usuário.

O temporizador distribui o risco. A RFC apresenta Twinit de 30 segundos antes do jitter e permite descer a seis segundos, sem o jitter, mas avisa que valores curtos aumentam duplicatas e failovers ou failbacks espúrios. Recuperar rápido de um peer realmente morto significa copiar mais cedo o trabalho de um peer que talvez apenas esteja lento.

Ajustar o timer não resolve a ambiguidade. Decide se ela será paga em espera ou em reconciliação.

A fila pendente enxerga apenas a falta de resposta local

Para realizar failover, cliente ou agente mantém uma fila de mensagens pendentes por peer. Quando chega a resposta correspondente, remove a requisição. Quando a mudança começa, envia ao agente alternativo tudo o que ainda está na fila.

Pendente quer dizer “este nó ainda não recebeu a resposta que encerra a entrada”. Não quer dizer “nenhum servidor executou”. A requisição pode ter sido aceita remotamente, e o retorno pode estar atrasado. Pode ter atravessado um proxy e alterado estado que a fila local não observa.

O comprovante deve registrar peer original, alternativo, geração do watchdog, motivo, snapshot da fila, identidade lógica, hash imutável do conteúdo, marca de retransmissão e os dois horários. retry sem esses campos não informa se houve cópia idêntica, reconstrução, mudança de destino ou uma nova intenção disfarçada.

A RFC 6733 preserva o algoritmo da RFC 3539 no Diameter Base Protocol. Ela encaminha requisições pendentes ao alternativo com a indicação de retransmissão e reconhece que o failover pode produzir várias requisições ou respostas idênticas.

A chave reúne cópias, mas não decide o que fazer com elas

No Diameter, Hop-by-Hop Identifier relaciona a resposta à requisição pendente naquele trecho. End-to-End Identifier combinado com Origin-Host permite reconhecer cópias do mesmo trabalho através de agentes diferentes.

Uma identidade fecha uma pergunta: essas mensagens pertencem à mesma intenção? Ela não fecha as seguintes: a primeira decisão foi persistida? as réplicas compartilham o estado? um efeito já foi aplicado? qual resposta o cliente escolheu? houve cobrança duas vezes?

Detectar duplicata é, portanto, o começo da disposição. O servidor pode reenviar uma resposta armazenada, esperar pelo dono da decisão, recusar nova avaliação ou executar a política outra vez. A RFC 6733 orienta que a duplicata produza a mesma resposta, salvo detalhes hop-by-hop. Essa regra é uma proteção contra a multiplicação de decisões.

Ela depende, porém, de memória durável. Se a primeira decisão não foi salva, se o cache expirou ou se outro servidor não recebeu o estado, o mesmo identificador não fabrica consenso. Identificação, supressão, reconciliação e compensação têm proprietários e evidências próprios.

Accept e Reject podem nascer de duas fotografias válidas

A RFC 3539 usa uma restrição de uso simultâneo para mostrar a não idempotência. A primeira requisição chega quando o usuário ainda não é considerado conectado e recebe Accept. A duplicata chega a outro servidor depois da mudança de estado e recebe Reject porque só uma sessão é permitida.

Nenhum servidor precisa estar quebrado. Cada um pode ter aplicado corretamente a regra ao estado visto naquele instante. A contradição nasce porque o mesmo pedido foi avaliado em dois epochs.

O cliente pode receber Accept e Reject para a mesma solicitação duplicada, e o texto observa que o resultado depende de qual resposta chega primeiro. A latência, então, vira política sem aparecer no documento de política. Mover o secundário, trocar o proxy ou alterar uma fila pode mudar quem vence.

Essa é uma possibilidade especificada, não a prova de um incidente. A resposta de governança é tornar a seleção explícita ou impedir que a duplicata seja uma segunda avaliação. O sistema não deve descobrir sua regra de autorização pela ordem dos pacotes durante uma pane.

Guardar somente o vencedor apaga a causa

O cliente deve registrar todas as respostas correlacionadas, não apenas o Result-Code aplicado. Cada registro precisa nomear servidor, identidade fim a fim, epoch de estado, restrição, resultado da busca de duplicata, tempo de commit e tempo de chegada.

Também deve definir “primeiro”. Pode ser o primeiro lido pelo processo, validado, gravado, enviado ao NAS ou efetivamente aplicado. Em concorrência, essas sequências podem divergir.

O recibo de seleção contém respostas recebidas, validações, regra de escolha, resultado escolhido e destino das demais. Assim a investigação distingue uma duplicação de transporte, uma divergência de estado e uma corrida de aplicação.

Sem a resposta perdedora, uma autorização contraditória se transforma retrospectivamente em login normal. O painel fica limpo porque a evidência foi descartada, não porque o sistema foi singular.

Accept ainda precisa atravessar o NAS

Accept é uma decisão do servidor em seu contexto. O cliente deve validar e relacionar; o NAS deve instalar atributos ou perfil e mudar o estado de acesso. Só a observação do plano de dados mostra se o usuário obteve serviço.

Reject também tem limite. Se um Accept anterior já foi aplicado, o Reject tardio não prova que o acesso nunca existiu. Pode iniciar encerramento, ser descartado como duplicata ou revelar uma incoerência ainda aberta.

Na contabilidade, a RFC 3539 cita Accounting Session-Id, Event-Timestamp e identidade do NAS para eliminar registros repetidos. A disposição — ignorar, mesclar, aceitar ou compensar — precisa ser ligada ao efeito em auditoria e cobrança.

A cadeia completa separa intenção, liveness do peer, repetição da fila, decisões de servidores, escolha do cliente, execução no NAS, contabilidade e experiência. O time de transporte não pode assinar pela política; o servidor não pode assinar pelo NAS; o NAS não pode assinar sozinho pelo usuário.

RADIUS e Diameter não compartilham nomes de campo

O RADIUS clássico tem Identifier de um octeto, Request Authenticator, contexto de transporte e segredo compartilhado em seu modelo de correlação e retransmissão. As RFCs 2865, 2866 e 5080 delimitam essa identidade.

Esses campos não são versões antigas de Hop-by-Hop Identifier, End-to-End Identifier e Origin-Host. Este Artigo não repete o tema da identidade RADIUS; trata da cópia entre conexões da RFC 3539 e do risco de uma política dependente de estado decidir novamente.

O princípio comum é manter identidade suficiente para que a repetição continue sendo a mesma intenção e decisão suficiente para que a intenção não produza dois efeitos.

Oito recibos para uma frase de disponibilidade

Registre a requisição lógica: origem, chave fim a fim, digest, escopo, aplicação e criação. Registre o peer: conexão, última resposta válida, watchdog, timer, jitter e causa. Registre o failover: snapshot da fila, destinos, marca e horários.

Em cada servidor, guarde estado, restrição, lookup de duplicata, decisão e commit. No cliente, guarde todas as respostas e a seleção. No NAS, a configuração aplicada. Na contabilidade, a identidade da sessão e a disposição. Por fim, observe acesso ou negação.

Só então o resumo pode afirmar: “este peer não respondeu a este watchdog; estas identidades pendentes foram enviadas ao alternativo; estas decisões foram reconciliadas por esta regra; o NAS aplicou este resultado; a sessão e a contabilidade observadas foram estas”. O que faltar deve permanecer desconhecido.

Limite de evidência

Este Artigo não identifica operador, fornecedor, realm AAA, implantação RADIUS ou Diameter, conta, login, NAS, incidente, indisponibilidade, ataque, cobrança duplicada ou usuário. Não apresenta taxa de adoção, configuração atual, latência medida nem frequência de respostas opostas.

A RFC 3539 é tratada como Proposed Standard de junho de 2003. A RFC 3588 é contexto histórico e foi substituída pela RFC 6733. A RFC 6733 mantém o algoritmo e os identificadores, mas não prova conformidade de qualquer sistema nomeado. As RFCs 8174 e 6298 limitam linguagem normativa e contexto de temporização.

Os textos de Lu Heng sobre primazia do código em execução e especificação inicial mínima são lentes editoriais declaradas. Separam publicação, implementação, decisão local e resultado; não demonstram intenção dos autores nem fato operacional.

A conclusão restrita é que o failover pode copiar uma requisição AAA antes de a original desaparecer. A identidade comum torna as cópias reconhecíveis. Somente disposição idempotente, seleção governada, aplicação verificada e resultado observado demonstram efeito único.

Fontes