Waarom PPP CHAP alleen nie aan ’n MPPE-vereiste kan voldoen nie

’n PPTP-profiel wat op enkripsie aandring, misluk gewoonlik op dieselfde plek: PPP kom ooreen op ’n verifikasie-uitruiling wat nooit die sleutelmateriaal lewer wat MPPE nodig het nie. Die tonnel lyk half lewendig, die wagwoord word aanvaar, en die skakel val voordat enige verkeer dit oorsteek. Om na die CHAP-aftrekkieslys te gryp totdat iets konnekteer, verberg die werklike gebrek, wat ’n kontrak tussen die verifikasiemetode en die beskermingsbeleid is. Die kontroles hieronder is so gerangskik dat elkeen ’n goedkoper oorsaak as die volgende uitsluit.

Twee onderhandelinge loop binne een PPTP-verbinding

PPTP dra ’n normale PPP-sessie binne ’n GRE-tonnel, en die twee onderhandel afsonderlik. Die buitenste laag besluit hoe pakkette ingekapsel word en watter beheerkanaal bestaan; die binneste PPP-sessie besluit wie die eweknie is en watter beskerming daarbo ry. ’n Wagwoordprompt bewys dus slegs iets oor die binnelaag, en ’n voltooide buitenste handdruk bewys niks oor enige van die twee nie. Profiele misluk hier omdat mense die tonnel ontfout terwyl die meningsverskil binne PPP sit.

Gewone CHAP is die uitdaging-respons-uitruiling in RFC 1994, gebou op ’n gedeelde geheim en niks anders nie. MS-CHAPv2 is ’n ander uitruiling met ander boodskappe en ’n ander uitset, gestandaardiseer in RFC 2759. Die gedeelde woord in die twee name is die enigste ding wat hulle op die draad gemeen het. Nie een van die name sê vir jou wat die uitruiling lewer nie, en dit is juis die enigste deel wat saak maak.

Dit is waarom ’n opsie wat bloot CHAP gemerk is, dubbelsinnig is in ’n ou profiel. Wanneer die bediener MS-CHAPv2 wil hê en die kliënt gewone CHAP bied, kan skakelbeheer steeds voltooi en kan ’n wagwoord steeds aanvaar word. Die mislukking kom later, wanneer die bediener probeer om beskermingsleutels af te lei uit ’n uitruiling wat niks opgelewer het nie.

Pas die vereiste metode by die sleutels wat dit kan lewer

MPPE-sleutels is nie in die algemeen ’n eienskap van PPP nie. Vir die Microsoft CHAP-familie word die afleiding in RFC 3079 gespesifiseer, en dit neem as invoer die uitset van ’n MS-CHAP-uitruiling eerder as ’n gedeelde geheim. EAP-metodes bereik dieselfde plek langs ’n ander roete, met die verifikasiebediener wat die sleutels as MS-MPPE-Recv-Key- en MS-MPPE-Send-Key-eienskappe terugstuur. Gewone CHAP kom in nie een van die twee weë voor nie, en dit is juis die hele rede waarom die wanverhouding bestaan.

’n Konfigurasie wat MPPE vereis terwyl dit elke metode weier wat sleutels kan lewer, is innerlik teenstrydig. pppd los daardie teenstrydigheid op deur die skakel te weier, nie deur sleutels te versin nie, so die sigbare resultaat is ’n sessie wat verifieer en dan gedurende die netwerkfase eindig. Om die kliënt weer te probeer sal dit nie verander nie, solank die bediener die enigste metodes weier wat iets aflei.

Die reël wat hieruit volg is kort: as die profiel MPPE vereis, moet die metode ’n MS-CHAP-variant of ’n EAP-metode wees waarvan die bediener die sleutels terugstuur. Om net MS-CHAPv2 te weier, dwing dit nie af nie, want MS-CHAPv1 lei ook sleutels af en bly beskikbaar tensy dit afsonderlik geweier word; om albei te weier laat gewone CHAP en PAP oor, wat niks aflei nie en die vereiste onvervulbaar maak. Noem die aanvaarde metode uitdruklik in plaas daarvan om die een te lys wat jy nie wil hê nie. Om die enkripsievereiste te laat vaar om ’n kliënt te laat konnekteer, is ’n afgradering, nie ’n herstel nie.

Lees die bediener se opsies voordat jy ’n kliënt wysig

Die meeste van hierdie wanverhoudings is op die bediener in twee lêers sigbaar, en om hulle te lees kos minder as om ’n kliënt te herbou. Op ’n Linux PPTP-eindpunt woon die relevante instellings in die pppd-opsielêer wat pptpd deurgee. Voer dit op die bediener uit, nie vanaf ’n kliëntstatus-skerm nie. Begin met die reëls wat ’n beskermingsmodus vereis, weier of noem:

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

Lees die uitset as ’n kontrak eerder as ’n lys vlae. ’n Reël wat MPPE vereis terwyl dit albei MS-CHAP-variante weier, kan deur geen kliënt nagekom word nie, en ’n ontbrekende vereiste vir ’n MS-CHAP-metode laat die deur oop vir uitruilings wat geen sleutels oplewer nie. Kyk dan wie hoegenaamd mag verifieer, wat die geheime-lêer besluit:

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

Skryf drie waardes neer voordat jy enigiets verander: die buitenste protokol, die verifikasiemetode wat die bediener vereis, en of beskerming verpligtend of opsioneel is. Daardie drie bepaal elke latere besluit, en om hulle uit ’n kliëntdialoog te raai, is hoe ’n profiel half opgestel eindig. Hou die lêer oop terwyl jy werk, want die volgende afdeling het dieselfde drie waardes nodig.

Spoor die mislukking per PPP-fase op

PPP rapporteer mislukkings in fases, en die fase sê vir jou watter klousule van die kontrak gebreek het. ’n Skakel wat nooit skakelbeheer verlaat nie, het ’n inkapselings- of onderhandelingsprobleem, terwyl een wat verifieer en dan sterf gewoonlik ’n beleids- of sleutelprobleem is. ’n Skakel wat op bly en niks dra nie, het na roetering oorgegaan, wat ’n ander ondersoek is.

Die joernaal hou die faselyne, en hulle is nuttiger as ’n hoër ontfoutvlak. Vra vir die PPP-prosesse en die beskermingsboodskappe, en lees dan die verifikasie-uitslag voor enigiets anders. Die laaste reëls noem gewoonlik die klousule wat geweier het:

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

Soek in daardie uitset eerste na die verifikasie-uitslag en dan na ’n klagte dat beskerming vereis is maar nie onderhandel is nie. Die tweede boodskap is die handtekening van die teenstrydigheid hierbo, en geen hoeveelheid herprobeer maak dit skoon nie solank die bediener die enigste metode weier wat sleutels kan lewer. Twee strikke is die moeite werd om te noem: om die ontfoutvlak te verhoog sonder om die faselyne te lees, veroorsaak geraas, en om uitdagingsmateriaal of wagwoorde vas te vang, verander ’n konfigurasietaak in ’n geloofsbrieflek. Teken daardie fase aan voordat jy enige opsie verander.

Beplan die uitgang voordat die ou eindpunt afgeskakel word

MPPE is ’n historiese skakelbeskermingsmeganisme, en sy teenwoordigheid maak nie PPTP ’n sinvolle keuse vir ’n nuwe ontplooiing nie. Huidige Microsoft-riglyne raai reeds teen PPTP en teen L2TP/IPsec met ’n vooraf gedeelde sleutel vir nuwe afstandtoegang-uitrollings. Om ’n ou eindpunt aan die lewe te hou, is ’n besluit oor ’n bestaande diens, nie ’n sjabloon vir die volgende een nie.

Wanneer die eindpunt moet bly, skryf die kontrak neer: buitenste protokol, vereiste verifikasiemetode, verpligte beskerming, en die kliëntweergawe wat dit onderhandel. Wanneer dit kan gaan, kies die vervanging se poortidentiteit, sy kliëntverifikasie en waar die geloofsbriewe gaan woon voordat jy die ou profiel aanraak. Beplan dan roetes, DNS en die hulpbronne wat elke gebruiker gemagtig is om te bereik. Valideer die beoogde kliënt teen die eienaar se vereistes eerder as teen ’n werkende verbinding.

’n Doelbewuste weiering moet ’n weiering bly, want om na ’n onbeskermde modus terug te val om ’n toets te laat slaag, verander ’n beleidsmislukking in ’n blootstelling. Die voltooide toestand is ’n ondersteunde, gedokumenteerde kontrak, nie die kleinste stel veranderinge wat een ou verbinding laat slaag nie. Laat die ou profiel in plek, ongebruik en gedokumenteer, totdat die vervanging dieselfde kontroles slaag.