Por que o PPP CHAP sozinho não pode satisfazer um requisito de MPPE

Um perfil PPTP que insiste na encriptação falha normalmente no mesmo ponto: o PPP acorda uma troca de autenticação que nunca produz o material de chave de que o MPPE precisa. O túnel parece meio vivo, a palavra-passe é aceite e a ligação cai antes de qualquer tráfego a atravessar. Recorrer à lista pendente do CHAP até algo ligar esconde o defeito real, e esse defeito é um contrato entre o método de autenticação e a política de proteção. As verificações abaixo estão ordenadas para que cada uma exclua uma causa mais barata do que a seguinte.

Duas negociações correm dentro de uma ligação PPTP

O PPTP transporta uma sessão PPP normal dentro de um túnel GRE, e as duas negociam em separado. A camada exterior decide como os pacotes são encapsulados e que canal de controlo existe; a sessão PPP interior decide quem é o par e que proteção vai por cima. Um pedido de palavra-passe prova, portanto, algo apenas sobre a camada interior, e um handshake exterior concluído não prova nada sobre nenhuma das duas. Os perfis falham aqui porque as pessoas depuram o túnel enquanto o desacordo está dentro do PPP.

O CHAP simples é a troca de desafio-resposta da RFC 1994, construída sobre um segredo partilhado e nada mais. O MS-CHAPv2 é uma troca diferente, com mensagens diferentes e uma saída diferente, normalizada na RFC 2759. A palavra partilhada nos dois nomes é a única coisa que têm em comum no cabo. Nenhum dos nomes diz o que a troca produz, e é essa a única parte que importa.

É por isso que uma opção rotulada simplesmente CHAP é ambígua num perfil antigo. Quando o servidor quer MS-CHAPv2 e o cliente oferece CHAP simples, o controlo de ligação ainda pode concluir e uma palavra-passe ainda pode ser aceite. A falha chega mais tarde, quando o servidor tenta derivar chaves de proteção de uma troca que não produziu nenhuma.

Faça corresponder o método exigido às chaves que ele pode produzir

As chaves MPPE não são uma propriedade do PPP em geral. Para a família Microsoft CHAP, a derivação está especificada na RFC 3079, e toma como entrada a saída de uma troca MS-CHAP em vez de um segredo partilhado. Os métodos EAP chegam ao mesmo ponto por outra via, com o servidor de autenticação a devolver as chaves como atributos MS-MPPE-Recv-Key e MS-MPPE-Send-Key. O CHAP simples não aparece em nenhum dos dois caminhos, e é essa toda a razão de o desajuste existir.

Uma configuração que exige MPPE ao mesmo tempo que recusa todos os métodos capazes de fornecer chaves é internamente contraditória. O pppd resolve essa contradição recusando a ligação, não inventando chaves, pelo que o resultado visível é uma sessão que se autentica e depois termina na fase de rede. Repetir a tentativa do cliente não mudará isso enquanto o servidor recusar os únicos métodos que derivam algo.

A regra que se segue é curta: se o perfil exige MPPE, o método tem de ser uma variante de MS-CHAP ou um método EAP cujas chaves o servidor devolva. Recusar apenas MS-CHAPv2 não impõe isso, porque o MS-CHAPv1 também deriva chaves e continua disponível a menos que seja recusado em separado; recusar ambos deixa o CHAP simples e o PAP, que não derivam nada e tornam o requisito insatisfazível. Nomeie o método aceite de forma explícita em vez de listar os que não lhe agradam. Abandonar o requisito de encriptação para que um cliente ligue é uma degradação, não uma reparação.

Leia as opções do servidor antes de editar um cliente

A maioria destes desajustes é visível no servidor em dois ficheiros, e lê-los custa menos do que reconstruir um cliente. Num ponto final PPTP Linux, as definições relevantes vivem no ficheiro de opções do pppd que o pptpd passa. Execute-o no servidor, não a partir de um ecrã de estado do cliente. Comece pelas linhas que exigem, recusam ou nomeiam um modo de proteção:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

Leia a saída como um contrato e não como uma lista de sinalizadores. Uma linha que exige MPPE ao mesmo tempo que recusa as duas variantes de MS-CHAP não pode ser satisfeita por nenhum cliente, e um requisito ausente para um método MS-CHAP deixa a porta aberta a trocas que não dão chaves. Depois verifique quem pode autenticar-se de todo, o que o ficheiro de segredos decide:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

Anote três valores antes de mudar o que quer que seja: o protocolo exterior, o método de autenticação exigido pelo servidor e se a proteção é obrigatória ou opcional. Esses três determinam cada decisão posterior, e adivinhá-los a partir de uma caixa de diálogo do cliente é como um perfil acaba meio configurado. Mantenha o ficheiro aberto enquanto trabalha, porque a secção seguinte precisa dos mesmos três valores.

Localize a falha pela fase do PPP

O PPP comunica falhas por fases, e a fase diz que cláusula do contrato se rompeu. Uma ligação que nunca sai do controlo de ligação tem um problema de encapsulamento ou de negociação, enquanto uma que se autentica e depois morre tem geralmente um problema de política ou de chave. Uma ligação que fica de pé e não transporta nada passou ao encaminhamento, o que é outra investigação.

O diário guarda as linhas de fase, e são mais úteis do que um nível de depuração mais alto. Peça os processos PPP e as mensagens de proteção, e leia depois o resultado da autenticação antes de tudo o resto. As últimas linhas costumam nomear a cláusula que recusou:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

Nessa saída, procure primeiro o resultado da autenticação e depois uma queixa de que a proteção era exigida mas não foi negociada. A segunda mensagem é a assinatura da contradição acima, e nenhuma quantidade de novas tentativas a apaga enquanto o servidor recusar o único método capaz de produzir chaves. Vale a pena nomear duas armadilhas: subir o nível de depuração sem ler as linhas de fase produz ruído, e capturar material de desafio ou palavras-passe transforma uma tarefa de configuração numa fuga de credenciais. Registe essa fase antes de mudar qualquer opção.

Planeie a saída antes de o ponto final antigo ser desligado

O MPPE é um mecanismo histórico de proteção de ligação, e a sua presença não faz do PPTP uma escolha sensata para uma nova implementação. A orientação atual da Microsoft já desaconselha o PPTP e o L2TP/IPsec com chave pré-partilhada para novas implementações de acesso remoto. Manter vivo um ponto final legado é uma decisão sobre um serviço existente, não um modelo para o seguinte.

Quando o ponto final tem de ficar, escreva o contrato: protocolo exterior, método de autenticação exigido, proteção obrigatória e a versão de cliente que a negocia. Quando pode sair, escolha a identidade de gateway do substituto, a sua autenticação de cliente e onde vão viver as credenciais antes de tocar no perfil antigo. Depois planeie rotas, DNS e os recursos a que cada utilizador está autorizado. Valide o cliente pretendido contra os requisitos do proprietário e não contra uma ligação que funciona.

Uma recusa deliberada deve continuar a ser uma recusa, porque voltar a um modo sem proteção para que um teste passe converte uma falha de política numa exposição. O estado final é um contrato suportado e documentado, não o menor conjunto de alterações que faz uma ligação antiga ter sucesso. Deixe o perfil antigo no lugar, sem uso e documentado, até o substituto passar nas mesmas verificações.