Por que PPP CHAP por si só non pode cumprir un requisito de MPPE

Un perfil PPTP que insiste no cifrado adoita fallar no mesmo punto: PPP acorda un intercambio de autenticación que nunca produce o material de clave que MPPE necesita. O túnel parece medio vivo, a contrasinal acéptase e a ligazón cae antes de que a cruce ningún tráfico. Recorrer ao despregable de CHAP ata que algo conecta oculta o defecto real, que é un contrato entre o método de autenticación e a política de protección. As comprobacións seguintes están ordenadas para que cada unha descarte unha causa máis barata ca a seguinte.

Dúas negociacións corren dentro dunha conexión PPTP

PPTP transporta unha sesión PPP normal dentro dun túnel GRE, e ambas negocian por separado. A capa exterior decide como se encapsulan os paquetes e que canle de control existe; a sesión PPP interior decide quen é o par e que protección vai enriba. Por tanto, unha solicitude de contrasinal só demostra algo sobre a capa interior, e un handshake exterior completado non demostra nada sobre ningunha das dúas. Os perfís fallan aquí porque a xente depura o túnel mentres o desacordo está dentro de PPP.

CHAP simple é o intercambio de desafío e resposta da RFC 1994, construído sobre un segredo compartido e nada máis. MS-CHAPv2 é un intercambio distinto con mensaxes distintas e unha saída distinta, estandarizado na RFC 2759. A palabra compartida dos dous nomes é o único que teñen en común no cable. Ningún dos nomes di que produce o intercambio, que é a única parte que importa.

Por iso unha opción etiquetada simplemente CHAP é ambigua nun perfil antigo. Cando o servidor quere MS-CHAPv2 e o cliente ofrece CHAP simple, o control de ligazón aínda pode completarse e unha contrasinal aínda pode aceptarse. O fallo chega máis tarde, cando o servidor tenta derivar claves de protección dun intercambio que non produciu ningunha.

Emparede o método requirido coas claves que pode producir

As claves MPPE non son unha propiedade de PPP en xeral. Para a familia Microsoft CHAP a derivación especifícase na RFC 3079, e toma como entrada a saída dun intercambio MS-CHAP en lugar dun segredo compartido. Os métodos EAP chegan ao mesmo punto por outra vía, co servidor de autenticación devolvendo as claves como atributos MS-MPPE-Recv-Key e MS-MPPE-Send-Key. CHAP simple non aparece en ningún dos dous camiños, e esa é toda a razón de que exista o desaxuste.

Unha configuración que esixe MPPE mentres rexeita todos os métodos capaces de fornecer claves é internamente contradictoria. pppd resolve esa contradición rexeitando a ligazón, non inventando claves, así que o resultado visible é unha sesión que se autentica e logo remata durante a fase de rede. Reintentar o cliente non o cambiará mentres o servidor rexeite os únicos métodos que derivan algo.

A regra que se segue é curta: se o perfil esixe MPPE, o método debe ser unha variante de MS-CHAP ou un método EAP cuxas claves devolva o servidor. Rexeitar só MS-CHAPv2 non o impón, porque MS-CHAPv1 tamén deriva claves e segue dispoñible salvo que se rexeite por separado; rexeitar ambos deixa CHAP simple e PAP, que non derivan nada e fan o requisito insatisfacible. Nomee o método aceptado explicitamente en lugar de listar os que non lle gustan. Abandonar o requisito de cifrado para que un cliente conecte é unha degradación, non unha reparación.

Lea as opcións do servidor antes de editar un cliente

A maioría destes desaxustes son visibles no servidor en dous ficheiros, e lelos custa menos que reconstruír un cliente. Nun extremo PPTP de Linux os axustes relevantes viven no ficheiro de opcións de pppd que pptpd pasa. Execúteo no servidor, non desde unha pantalla de estado do cliente. Empece polas liñas que esixen, rexeitan ou nomean un modo de protección:

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

Lea a saída como un contrato e non como unha lista de indicadores. Unha liña que esixe MPPE mentres rexeita as dúas variantes de MS-CHAP non a pode satisfacer ningún cliente, e un requisito ausente para un método MS-CHAP deixa a porta aberta a intercambios que non dan claves. Logo comprobe quen pode autenticarse sequera, o que decide o ficheiro de segredos:

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

Anote tres valores antes de cambiar nada: o protocolo exterior, o método de autenticación que esixe o servidor e se a protección é obrigatoria ou opcional. Eses tres determinan cada decisión posterior, e adiviñalos desde un diálogo de cliente é como un perfil acaba medio configurado. Manteña o ficheiro aberto mentres traballa, porque a sección seguinte necesita os mesmos tres valores.

Localice o fallo por fase de PPP

PPP informa dos fallos por fases, e a fase di que cláusula do contrato se rompeu. Unha ligazón que nunca sae do control de ligazón ten un problema de encapsulación ou de negociación, mentres que unha que se autentica e logo morre adoita ter un problema de política ou de clave. Unha ligazón que se mantén arriba e non transporta nada pasou ao encamiñamento, que é outra investigación.

O diario garda as liñas de fase, e son máis útiles ca un nivel de depuración máis alto. Pida os procesos PPP e as mensaxes de protección, e logo lea o resultado de autenticación antes ca nada. As últimas liñas adoitan nomear a cláusula que rexeitou:

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

Nesa saída, busque primeiro o resultado de autenticación e logo unha queixa de que a protección era necesaria pero non se negociou. A segunda mensaxe é a sinatura da contradición anterior, e ningunha cantidade de reintentos a borra mentres o servidor rexeite o único método que pode producir claves. Paga a pena nomear dúas trampas: subir o nivel de depuración sen ler as liñas de fase produce ruído, e capturar material de desafío ou contrasinais converte unha tarefa de configuración nunha fuga de credenciais. Rexistre esa fase antes de cambiar calquera opción.

Planifique a saída antes de apagar o extremo antigo

MPPE é un mecanismo histórico de protección de ligazón, e a súa presenza non fai de PPTP unha opción sensata para un despregamento novo. A guía actual de Microsoft xa desaconsella PPTP e L2TP/IPsec con clave precompartida para novos despregamentos de acceso remoto. Manter vivo un extremo heredado é unha decisión sobre un servizo existente, non un modelo para o seguinte.

Cando o extremo teña que quedar, escriba o contrato: protocolo exterior, método de autenticación requirido, protección obrigatoria e a versión de cliente que o negocia. Cando poida irse, elixa a identidade de pasarela do substituto, a súa autenticación de cliente e onde vivirán as credenciais antes de tocar o perfil antigo. Despois planifique rutas, DNS e os recursos aos que cada usuario está autorizado. Valide o cliente previsto contra os requisitos do propietario e non contra unha conexión que funciona.

Un rexeitamento deliberado debe seguir sendo un rexeitamento, porque volver a un modo sen protección para que unha proba pase converte un fallo de política nunha exposición. O estado final é un contrato soportado e documentado, non o conxunto máis pequeno de cambios que fai que unha conexión antiga teña éxito. Deixe o perfil antigo no seu sitio, sen usar e documentado, ata que o substituto pase as mesmas comprobacións.