Framed-IP-Address do RADIUS para um endereço de cliente VPN estável

O RADIUS pode responder com um endereço para um determinado utilizador; se o túnel o recebe de facto depende do gateway. É nesta lacuna entre devolvido e aplicado que falham a maioria dos planos de endereço estável. Um atributo numa resposta de teste prova que o servidor o pode enviar, não que o serviço de acesso remoto o aplique. A sequência abaixo verifica ambas as metades antes de o endereço acabar nas regras da firewall.

Decida qual camada é dona do endereço

Os gateways de acesso remoto costumam ter um pool local, e muitos também podem aceitar um endereço da resposta de autenticação. Qual dos dois vence depende da plataforma, do protocolo e da configuração do serviço, por isso leia a regra de precedência para a versão exata em uso. Onde o pool local tem prioridade, o atributo é decoração e o cliente continua a ficar num endereço aleatório. Registe a decisão, incluindo se um valor devolvido tem de ficar dentro do intervalo do pool ou pode ficar fora dele.

O RFC 2865 define Framed-IP-Address como o endereço a configurar para o utilizador, e não diz nada sobre a disponibilidade de um gateway concreto para o respeitar. A documentação do fornecedor é a autoridade sobre a precedência, não a definição do atributo.

Envie um pedido de teste e leia a resposta

Teste primeiro o servidor isoladamente, para que um atributo em falta não seja confundido com um problema do gateway. radtest envia um Access-Request e imprime os atributos que voltam.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Procure Framed-IP-Address no Access-Accept e confirme que o valor é o pretendido e não um endereço do pool de uma regra de recurso. Quando o atributo está ausente, a entrada de utilizador ou a política de autorização não coincidem, e a afinação do gateway não pode fornecer o que o servidor nunca enviou. Repita o pedido enquanto o servidor corre em modo de depuração se a resposta for difícil de rastrear até uma regra específica. Mantenha o segredo partilhado fora do histórico da shell e dos tickets, porque o marcador acima não é uma credencial.

Confirme que o gateway respeitou o valor

Uma resposta correta é apenas metade do contrato. O endereço que aparece na interface do túnel é a observação que importa, e é lida no cliente em vez de deduzida da configuração do gateway.

ip -4 addr show tun0

Compare esse endereço com o atributo do Access-Accept. Uma discrepância significa que o gateway ignorou ou reescreveu o valor, o que reabre a questão da precedência da primeira secção. Volte a ligar mais uma vez, porque uma reserva que só funciona na primeira tentativa costuma indicar uma sessão obsoleta ou um lease ainda detido pela ligação anterior. Registe a versão do gateway e o protocolo junto ao resultado, para que a pessoa seguinte saiba se o comportamento depende da versão.

Planeie a concorrência e a revogação

Um nome de utilizador em dois dispositivos não pode corresponder a um só endereço, a menos que o gateway distinga as sessões por algo além do login. Decida se o mapeamento pertence a uma pessoa, a um dispositivo registado ou a uma identidade de certificado, e torne essa escolha explícita no armazenamento de políticas. Teste um segundo cliente simultâneo e compare os dois endereços atribuídos, pois uma colisão aqui reaparece mais tarde como uma falha de encaminhamento. O mesmo cuidado pertence ao plano de revogação, porque um endereço reatribuído enquanto as regras antigas da firewall ainda lhe fazem referência transforma-se num erro de autorização.

O endereçamento estável simplifica regras e registos, mas nunca prova quem gerou um pacote. A autenticação e a autorização do destino continuam a importar quando esse endereço passar depois para outra sessão.