Per què PPP CHAP sol no pot satisfer un requisit d’MPPE

Un perfil PPTP que insisteix en el xifratge sol fallar sempre al mateix punt: PPP acorda un intercanvi d’autenticació que mai no produeix el material de clau que MPPE necessita. El túnel sembla mig viu, la contrasenya s’accepta i l’enllaç cau abans que hi passi cap trànsit. Recórrer al desplegable CHAP fins que alguna cosa es connecta amaga el defecte real, que és un contracte entre el mètode d’autenticació i la política de protecció. Les comprovacions següents estan ordenades perquè cadascuna descarti una causa més barata que la següent.

Dues negociacions corren dins d’una connexió PPTP

PPTP porta una sessió PPP normal dins d’un túnel GRE, i les dues negocien per separat. La capa exterior decideix com s’encapsulen els paquets i quin canal de control existeix; la sessió PPP interior decideix qui és el par i quina protecció hi va a sobre. Per tant, una petició de contrasenya només demostra alguna cosa sobre la capa interior, i un handshake exterior complet no demostra res sobre cap de les dues. Els perfils fallen aquí perquè la gent depura el túnel mentre el desacord és dins de PPP.

CHAP simple és l’intercanvi de repte i resposta de l’RFC 1994, construït sobre un secret compartit i res més. MS-CHAPv2 és un intercanvi diferent amb missatges diferents i una sortida diferent, estandarditzat a l’RFC 2759. La paraula compartida dels dos noms és l’única cosa que tenen en comú al cable. Cap dels dos noms no diu què produeix l’intercanvi, que és l’única part que importa.

Per això una opció etiquetada simplement CHAP és ambigua en un perfil antic. Quan el servidor vol MS-CHAPv2 i el client ofereix CHAP simple, el control d’enllaç encara pot completar-se i una contrasenya encara es pot acceptar. El fracàs arriba més tard, quan el servidor intenta derivar claus de protecció d’un intercanvi que no n’ha produït cap.

Feu coincidir el mètode requerit amb les claus que pot produir

Les claus MPPE no són una propietat de PPP en general. Per a la família Microsoft CHAP la derivació s’especifica a l’RFC 3079, i pren com a entrada la sortida d’un intercanvi MS-CHAP en lloc d’un secret compartit. Els mètodes EAP arriben al mateix lloc per una altra via, amb el servidor d’autenticació retornant les claus com a atributs MS-MPPE-Recv-Key i MS-MPPE-Send-Key. CHAP simple no apareix en cap dels dos camins, i aquesta és tota la raó que el desajust existeixi.

Una configuració que exigeix MPPE mentre rebutja tots els mètodes capaços de subministrar claus és internament contradictòria. pppd resol aquesta contradicció rebutjant l’enllaç, no inventant claus, així que el resultat visible és una sessió que s’autentica i després acaba durant la fase de xarxa. Reintentar el client no ho canviarà mentre el servidor rebutja els únics mètodes que en deriven alguna.

La regla que se’n deriva és curta: si el perfil exigeix MPPE, el mètode ha de ser una variant de MS-CHAP o un mètode EAP les claus del qual el servidor retorni. Rebutjar només MS-CHAPv2 no ho imposa, perquè MS-CHAPv1 també deriva claus i resta disponible tret que es rebutgi per separat; rebutjar tots dos deixa CHAP simple i PAP, que no en deriven cap i fan el requisit insatisfactible. Anomeneu el mètode acceptat explícitament en lloc de llistar els que no us agraden. Abandonar el requisit de xifratge perquè un client es connecti és una degradació, no una reparació.

Llegiu les opcions del servidor abans d’editar un client

La majoria d’aquests desajustos són visibles al servidor en dos fitxers, i llegir-los costa menys que reconstruir un client. En un punt final PPTP de Linux els paràmetres rellevants viuen al fitxer d’opcions de pppd que pptpd passa. Executeu-lo al servidor, no des d’una pantalla d’estat del client. Comenceu per les línies que exigeixen, rebutgen o nomenen un mode de protecció:

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

Llegiu la sortida com un contracte i no com una llista de marques. Una línia que exigeix MPPE mentre rebutja les dues variants de MS-CHAP no la pot satisfer cap client, i un requisit absent per a un mètode MS-CHAP deixa la porta oberta a intercanvis que no donen claus. Després comproveu qui pot autenticar-se en absolut, cosa que decideix el fitxer de secrets:

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

Anoteu tres valors abans de canviar res: el protocol exterior, el mètode d’autenticació que exigeix el servidor i si la protecció és obligatòria o opcional. Aquests tres determinen cada decisió posterior, i endevinar-los des d’un diàleg de client és com un perfil acaba mig configurat. Manteniu el fitxer obert mentre treballeu, perquè la secció següent necessita els mateixos tres valors.

Localitzeu la fallada per fase de PPP

PPP informa de les fallades per fases, i la fase diu quina clàusula del contracte s’ha trencat. Un enllaç que mai no surt del control d’enllaç té un problema d’encapsulació o de negociació, mentre que un que s’autentica i després mor sol tenir un problema de política o de clau. Un enllaç que es manté aixecat i no porta res ha passat a l’encaminament, que és una investigació diferent.

El diari guarda les línies de fase, i són més útils que un nivell de depuració més alt. Demaneu els processos PPP i els missatges de protecció, i després llegiu el resultat d’autenticació abans que res. Les últimes línies solen nomenar la clàusula que ha rebutjat:

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

En aquesta sortida, busqueu primer el resultat d’autenticació i després una queixa que la protecció era requerida però no s’ha negociat. El segon missatge és la signatura de la contradicció anterior, i cap quantitat de reintents l’esborra mentre el servidor rebutja l’únic mètode que pot produir claus. Val la pena nomenar dues trampes: pujar el nivell de depuració sense llegir les línies de fase produeix soroll, i capturar material de repte o contrasenyes converteix una tasca de configuració en una fuita de credencials. Enregistreu aquesta fase abans de canviar cap opció.

Planifiqueu la sortida abans que el punt final antic es desconnecti

MPPE és un mecanisme històric de protecció d’enllaç, i la seva presència no fa que PPTP sigui una opció sensata per a un desplegament nou. Les directrius actuals de Microsoft ja aconsellen contra PPTP i contra L2TP/IPsec amb una clau precompartida per als nous desplegaments d’accés remot. Mantenir viu un punt final antic és una decisió sobre un servei existent, no una plantilla per al següent.

Quan el punt final ha de quedar-se, escriviu el contracte: protocol exterior, mètode d’autenticació requerit, protecció obligatòria i la versió de client que el negocia. Quan pot marxar, trieu la identitat de la passarel·la del substitut, la seva autenticació de client i on viuran les credencials abans de tocar el perfil antic. Després planifiqueu les rutes, el DNS i els recursos als quals cada usuari està autoritzat. Valideu el client previst contra els requisits del propietari i no contra una connexió que funciona.

Un rebuig deliberat ha de romandre un rebuig, perquè tornar a un mode no protegit perquè una prova passi converteix un fracàs de política en una exposició. L’estat acabat és un contracte suportat i documentat, no el conjunt més petit de canvis que fa que una connexió antiga tingui èxit. Deixeu el perfil antic al seu lloc, sense ús i documentat, fins que el substitut passi les mateixes comprovacions.