Como um login VPN chega ao RADIUS e ao seu provedor de identidade

Na semana passada, um usuário conseguiu entrar na VPN e mesmo assim foi parar em uma rede onde nada era resolvido. O cliente dizia conectado, o log do gateway dizia Access-Accept e a equipe de identidade dizia que a conta estava certa. O login tinha funcionado; a autorização por trás dele não. Quando um login VPN falha, eu percorro o caminho que a requisição realmente segue — cliente, gateway, servidor RADIUS, provedor de identidade — e paro no primeiro salto cuja resposta não concorda com a seguinte.

O cliente nunca fala RADIUS

Diga o que disser o aplicativo no notebook, o primeiro salto é o protocolo VPN: IKEv2, OpenVPN, WireGuard ou um cliente baseado em TLS. RADIUS não aparece nessa troca. O cliente se autentica no gateway com um certificado, um nome de usuário e senha, ou um método EAP transportado na configuração do túnel.

Isso importa ao ler logs, porque o erro genérico de autenticação que o usuário vê é produzido pelo gateway depois que ele já falou com outra coisa. Se o cliente nunca chega ao gateway, não existe requisição RADIUS para depurar, e uma hora gasta no servidor RADIUS é desperdiçada. Confirme que o túnel subiu antes de tocar no backend.

O gateway é o cliente RADIUS

Assim que a configuração do túnel chega ao ponto em que as credenciais precisam ser verificadas, o gateway se torna um servidor de acesso à rede. Ele monta uma Access-Request: User-Name, uma senha ou carga EAP, NAS-IP-Address ou NAS-Identifier, e um Message-Authenticator quando o método exige. A requisição vai para UDP 1812 por padrão, e a contabilidade para 1813. Implantações mais antigas ainda usam 1645 e 1646, então uma regra de firewall escrita para um par explica muitas falhas silenciosas.

Os dois lados compartilham um segredo, e ele não é uma credencial de usuário. Ele assina a troca, e cada resposta é verificada contra ele. Configure o segredo de forma diferente nos dois lados e o servidor não responde com segredo errado: ele descarta a requisição ou a resposta falha na verificação, então o gateway relata um tempo esgotado. Um segredo errado e um servidor morto parecem idênticos a partir do gateway, por isso testo o salto com uma ferramenta de cliente antes de culpar o diretório.

O protocolo é pequeno e antigo — RFC 2865 define a troca de autenticação —, mas os atributos que ele carrega são a base sobre a qual a maior parte da política VPN é construída.

# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123

# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'

O servidor RADIUS pode ser apenas a fachada do provedor de identidade

As pessoas falam de RADIUS e provedor de identidade como se fossem a mesma caixa. Muitas vezes não são. O servidor RADIUS recebe a Access-Request e então pergunta a outra coisa — Active Directory via LDAP ou Kerberos, um arquivo de usuários local ou um serviço externo — antes de responder. FreeRADIUS com o módulo LDAP ou krb5, Windows NPS e Cisco ISE ocupam todos essa posição.

A distinção decide onde olhar. Uma senha rejeitada é uma resposta do provedor de identidade repassada pelo RADIUS. Um tempo esgotado costuma ser o trecho RADIUS-diretório: uma conta de bind expirada, um diretório inalcançável ou uma requisição roteada para o backend errado. Se o nome de usuário traz um sufixo de domínio, o servidor pode rotear por ele, e a mesma conta enviada como CORP\alice e [email protected] pode cair em lugares diferentes. No Windows NPS, o log Security registra 6272 para uma concessão e 6273 para uma negação, o que diz se a decisão veio do NPS.

Leia a falha no salto que a produziu

Uma única mensagem de não é possível conectar cobre quatro falhas diferentes. Antes de mudar qualquer coisa, associe o sintoma ao salto que o produziu.

A última linha é a que manda as pessoas para a equipe errada. Access-Accept significa que as credenciais foram aceitas; não significa que o gateway colocou o usuário no pool certo ou empurrou rotas. Atributos de grupo só importam se a política do gateway os lê. Já vi um login correto cair em um pool de convidados porque o mapeamento de grupos estava configurado no lado RADIUS para um atributo diferente do que o gateway inspeciona.

Siga um login de ponta a ponta

Escolha uma única conta de teste e um gateway, e observe a mesma tentativa nos quatro pontos. Inicie uma execução de depuração no lado RADIUS — freeradius -X imprime a requisição e cada módulo que ela toca — acompanhe o log de autenticação do gateway e execute tcpdump para a troca UDP. Conecte uma vez e leia os quatro rastros em ordem.

O que você quer ver é concordância: o gateway perguntou pelo usuário que você esperava, o servidor RADIUS escolheu o backend que você esperava, esse backend devolveu uma decisão, e os atributos na resposta batem com a política que o gateway aplica. O primeiro lugar onde os rastros discordam é a sua linha de falha. Se a resposta não traz atributo de grupo, o problema está no lado RADIUS, não no perfil VPN; se o atributo está lá e o gateway o ignora, a política do gateway é o problema.

Uma nota de segurança enquanto você está aí. O segredo compartilhado protege a troca, mas não criptografa a maioria dos atributos. Se o gateway e o servidor RADIUS estão em segmentos diferentes, coloque esse salto em RADIUS sobre TLS ou em um caminho privado. Um túnel de usuário criptografado não diz nada sobre o link do backend.

Antes de fechar o chamado, confirme quatro coisas. O gateway alcança o servidor RADIUS na porta para a qual está realmente configurado. O segredo compartilhado confere nos dois lados. O servidor RADIUS resolve a forma exata do nome de usuário que o gateway envia. A aceitação traz os atributos de que a política do gateway precisa. Quando as quatro valem, um login que ainda falha é um problema de política do gateway, não de autenticação.