Um login 802.1X ou NAC com fio que falha pode estar quebrado no cliente, no dispositivo de acesso que aplica a porta, ou no servidor RADIUS por trás — e o código de motivo aponta para um lugar diferente a cada vez. Esta é a cadeia a verificar em ordem, como é a troca EAP em cada salto, os códigos de erro e a CLI reais a consultar, e em que isso difere de um login de Portal ou de uma falha de autenticação sem fio.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
O 802.1X autentica a própria porta, antes mesmo de o cliente obter um endereço IP — é exatamente por isso que ele quebra de forma diferente do Portal ou do wireless.
Em uma porta de switch ou firewall com fio rodando 802.1X, nada acima da Camada 2 aconteceu ainda quando a troca começa — sem DHCP, sem endereço IP, sem redirecionamento HTTP. Essa é a diferença central em relação a um login de Portal, que autentica um dispositivo que já tem um endereço e está tentando alcançar uma página web capturada. Isso também significa que a cadeia que precisa funcionar é curta e rígida: o suplicante 802.1X do cliente, o dispositivo de acesso que aplica a porta e retransmite para o servidor RADIUS, e o próprio servidor RADIUS/AAA que decide accept ou reject.
A seguir está essa cadeia, como é a troca EAP em cada salto, os códigos de erro de autenticação de acesso e a CLI que realmente explicam a maioria dos chamados, onde se encaixa a questão de escape/contingência, e em que isso difere de uma falha de login de Portal ou de uma específica de wireless.
Cliente, dispositivo de acesso, servidor RADIUS — três elos, e a sequência de mensagens EAP entre eles indica qual realmente quebrou.
Ler essa sequência de cima para baixo antes de mexer em qualquer configuração indica se o cliente sequer enviou EAPOL-Start, se o dispositivo de acesso nunca retransmitiu para o RADIUS, ou se o RADIUS respondeu mas com uma rejeição.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Os passos 1 a 3 acontecem antes mesmo de o dispositivo de acesso ter falado com o RADIUS — se o cliente nunca passa do passo 2 ou 3, olhe para o cliente e a porta, não para o servidor RADIUS. Os passos 4 a 9 são onde uma política de domínio de autenticação, uma conta bloqueada, ou uma credencial incorreta aparece como um Access-Reject. O passo 11 é o que as pessoas esquecem: um Access-Accept no passo 9 não garante que o usuário permaneça online — uma falha de contabilização depois ainda pode derrubá-lo.
Três verificações, em ordem — quem está realmente online, por que quem não está foi derrubado, e se a própria conta é o problema.
[HUAWEI] display access-user interface 10ge 1/0/1
Total: 1
UserID Username IP address MAC Status
32984 lulu 192.85.11.2 00e0-fc55-0102 Success
<HUAWEI> display authentication-profile configuration name p1
...
Authentication mode : multi-authen
<HUAWEI> display domain name test
Domain-name : test
Domain-state : Block
// Block forces every user in this domain offline — not a credential problem
<HUAWEI> display remote-user authen-fail blocked
// lists remote accounts currently locked out after repeated authentication failuresCódigos de erro de autenticação de acesso reais, o que realmente significam, e o comando que confirma isso.
SINTOMAEAPOL client timeout (código de erro 206): o cliente simplesmente não responde à solicitação EAP.
CAUSAEm uma falha de autenticação sem fio, o mesmo código muitas vezes é um problema de sinal fraco. Em uma porta com fio não há link de rádio para culpar — quase sempre é o próprio suplicante 802.1X: não está rodando, mal configurado, ou uma falha de driver no cliente.
SOLUÇÃOConfirme que o suplicante está realmente rodando e corretamente configurado no cliente antes de mexer na porta ou no servidor RADIUS; só tente autenticar novamente depois que o lado do cliente for confirmado como saudável.
SINTOMARemote user is blocked (código de erro 519) e Authenticate fail (código de erro 147): uma conta remota fica bloqueada após muitas tentativas falhas dentro da janela de repetição, e todo dispositivo que ainda a usa falha a partir daí.
CAUSASe vários clientes 802.1X estiverem configurados para autenticar com a mesma conta, um dispositivo com senha desatualizada ou errada pode bloquear essa conta para todos os outros dispositivos que a usam — um único campo de senha errado vira uma interrupção para o escritório inteiro.
SOLUÇÃOVerifique display remote-user authen-fail blocked, desbloqueie a conta com remote-user authen-fail unblock depois de confirmar a credencial correta, e — se contas compartilhadas forem inevitáveis — desative o bloqueio por conta para esse cenário com undo access-user remote authen-fail.
<HUAWEI> display remote-user authen-fail blocked
[HUAWEI-aaa] remote-user authen-fail unblock
[HUAWEI-aaa] undo access-user remote authen-failSINTOMADomain policy failed force user to offline (código de erro 371): usuários com credenciais totalmente corretas ainda não conseguem ficar online.
CAUSAO próprio domínio de autenticação está em estado Block — uma chave em nível de domínio que substitui completamente as verificações de credenciais individuais, e é fácil de passar despercebida porque o sintoma parece idêntico a uma senha errada.
SOLUÇÃOVerifique display domain name <domain> para o campo Domain-state antes de solucionar problemas de contas individuais; reative-o na vista de domínio AAA com state active.
SINTOMABeyond access limit (código de erro 57): um novo dispositivo não consegue ficar online em uma porta que já tem um autenticado.
CAUSAOs modos single-terminal e multi-share só permitem um dispositivo online por vez nessa porta; single-voice-with-data permite exatamente um dispositivo de voz e um de dados. Uma porta com um telefone IP encadeado com um PC, ou vários terminais atrás de um pequeno switch não gerenciado, precisa de multi-authen — qualquer outro modo rejeitará o segundo dispositivo por design, não por falha.
SOLUÇÃOVerifique juntos display authentication-profile configuration e display access-user interface antes de supor um problema de RADIUS ou de licenciamento; mude o perfil para multi-authen com um max-user-number apropriado se a porta realmente precisar carregar mais de um ou dois dispositivos autenticados.
SINTOMAEAPOL client user name is different (código de erro 420): o cliente reinicia a autenticação no meio da sessão com um nome de usuário diferente daquele com que começou.
CAUSAAlguns softwares de cliente ou tentativas manuais trocam de conta entre tentativas sem antes fazer logout completo — o dispositivo de acesso trata a incompatibilidade como uma condição de falha em vez de um novo login limpo.
SOLUÇÃOCertifique-se de que o cliente faça logout de forma limpa (EAPOL-Logoff) antes de tentar novamente com uma conta diferente, em vez de trocar de credenciais no meio da sessão.
SINTOMAAccounting server no response (código de erro 410): o usuário se autentica com sucesso e depois é derrubado pouco depois.
CAUSAAutenticação e contabilização são trocas RADIUS separadas. Um caminho de autenticação funcionando com um link de contabilização quebrado ou inalcançável — um servidor diferente, um link diferente, um modo de falha completamente diferente — ainda assim força o usuário a ficar offline mesmo que suas credenciais estivessem corretas.
SOLUÇÃOFaça Ping especificamente para o servidor de contabilização e verifique seus próprios logs e status — não assuma que uma falha no estágio de contabilização é o mesmo problema do estágio de autenticação que já teve sucesso.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
O Portal autentica um dispositivo que já tem um endereço IP e está tentando alcançar uma página web capturada via HTTP — os modos de falha são uma página que não carrega, ou o RADIUS aprovando um login que o cliente ainda vê como rejeitado. O 802.1X/NAC autentica a própria porta na Camada 2, antes mesmo do DHCP rodar, usando EAPOL e EAP em vez de uma página web. Se o cliente nunca obtém um endereço IP e não há página de login envolvida, você está solucionando problemas de 802.1X, não de Portal — veja A autenticação de Portal falha em roteadores corporativos para a cadeia específica do Portal.
Os códigos de erro de autenticação de acesso são amplamente compartilhados entre com fio e sem fio — o mesmo código EAPOL client timeout, por exemplo, pode disparar em ambos. A diferença é a causa: no sem fio, esse código muitas vezes é um problema de sinal fraco ou de roaming específico do link de rádio; em uma porta com fio não há rádio para culpar, então o mesmo sintoma quase sempre aponta para o suplicante do cliente ou para o próprio cabo/porta. Diagnostique os dois de forma diferente mesmo quando o código de erro coincidir.
Isso acontece quando vários clientes 802.1X estão configurados para autenticar contra a mesma conta compartilhada. Tentativas falhas suficientes dentro da janela de repetição bloqueiam essa conta conforme display remote-user authen-fail blocked, e todo outro dispositivo que ainda a usa falha a partir daí — não por causa de algo errado do lado deles. Desbloqueie a conta com remote-user authen-fail unblock, e considere undo access-user remote authen-fail se contas compartilhadas forem inevitáveis no seu ambiente.
O modelo de domínio de autenticação separa o esquema de autenticação do esquema de contabilização, o que torna possível um esquema de autenticação local, independente de RADIUS, como contingência para um determinado domínio. O mecanismo exato de escape/desvio para um dispositivo de acesso específico é um recurso de plataforma de switch ou AC fora do que este material de origem focado em firewall cobre em profundidade — veja a nota de limites honestos abaixo antes de supor que um comando específico existe no seu dispositivo.
Autenticação e contabilização são duas trocas RADIUS separadas. Um Access-Accept confirma que as credenciais estavam corretas; não garante que o link de contabilização esteja saudável. Accounting server no response (código de erro 410) derruba o usuário depois, mesmo que a própria autenticação tenha tido sucesso — verifique especificamente o servidor de contabilização e o link até ele, não novamente o caminho de autenticação.
Esta nota se baseia na referência compartilhada de códigos de erro de autenticação de acesso da Huawei e na CLI de AAA/domínio, cruzada entre o material de manutenção HiSecEngine USG6000F/USG6000G/USG12000 e USG6000E/USG9500. Ela cobre a cadeia cliente-dispositivo de acesso-RADIUS, a troca EAP, e os códigos de erro e comandos que a referência mostra na prática. Não cobre em profundidade o mecanismo de VLAN de escape/desvio específico de um fabricante para um servidor RADIUS inalcançável, nem o comportamento de roaming sem fio específico de um AC — isso está na própria documentação de uma plataforma de switch ou AC.
Conte-nos o código de erro ou sintoma de display aaa online-fail-record, e se é com fio ou sem fio — ajudamos você a interpretar.