Pam na all PPP CHAP ar ei ben ei hun fodloni gofyniad MPPE

Mae proffil PPTP sy’n mynnu amgryptio fel arfer yn methu yn yr un man: mae PPP yn cytuno ar gyfnewid dilysu nad yw byth yn cynhyrchu’r deunydd allweddol y mae MPPE ei angen. Mae’r twnnel yn edrych yn hanner byw, derbynnir y cyfrinair, ac mae’r cysylltiad yn disgyn cyn i unrhyw draffig ei groesi. Mae estyn am y gwymplen CHAP nes bod rhywbeth yn cysylltu yn cuddio’r diffyg gwirioneddol, sef contract rhwng y dull dilysu a’r polisi amddiffyn. Mae’r gwiriadau isod wedi’u trefnu fel bod pob un yn diystyru achos rhatach na’r nesaf.

Mae dau drafodaeth yn rhedeg o fewn un cysylltiad PPTP

Mae PPTP yn cario sesiwn PPP arferol o fewn twnnel GRE, ac mae’r ddau yn trafod ar wahân. Mae’r haen allanol yn penderfynu sut y caiff pecynnau eu hamgáu a pha sianel reoli sy’n bodoli; mae’r sesiwn PPP fewnol yn penderfynu pwy yw’r cymar a pha amddiffyniad sy’n mynd ar ei ben. Felly nid yw anogiad cyfrinair yn profi dim ond am yr haen fewnol, ac nid yw ysgydwad llaw allanol wedi’i gwblhau yn profi dim am y naill na’r llall. Mae proffiliau’n methu yma oherwydd bod pobl yn dadfygio’r twnnel tra bo’r anghytundeb yn eistedd y tu mewn i PPP.

CHAP plaen yw’r gyfnewid her-ac-ymateb yn RFC 1994, wedi’i hadeiladu ar gyfrinach a rennir a dim arall. Mae MS-CHAPv2 yn gyfnewid gwahanol â negeseuon gwahanol a chynnyrch gwahanol, wedi’i safoni yn RFC 2759. Y gair a rennir yn y ddau enw yw’r unig beth sydd ganddynt yn gyffredin ar y wifren. Nid yw’r naill enw na’r llall yn dweud beth mae’r gyfnewid yn ei gynhyrchu, a dyna’r unig ran sy’n bwysig.

Dyna pam mae opsiwn wedi’i labelu’n syml fel CHAP yn amwys mewn hen broffil. Pan fydd y gweinydd eisiau MS-CHAPv2 a’r cleient yn cynnig CHAP plaen, gall rheolaeth cyswllt gwblhau o hyd a gall cyfrinair gael ei dderbyn o hyd. Daw’r methiant yn hwyrach, pan fydd y gweinydd yn ceisio deillio allweddi amddiffyn o gyfnewid na chynhyrchodd ddim.

Cydweddwch y dull gofynnol â’r allweddi y gall eu cynhyrchu

Nid yw allweddi MPPE yn briodwedd o PPP yn gyffredinol. Ar gyfer teulu Microsoft CHAP mae’r deilliad wedi’i nodi yn RFC 3079, ac mae’n cymryd fel mewnbwn gynnyrch cyfnewid MS-CHAP yn hytrach na chyfrinach a rennir. Mae dulliau EAP yn cyrraedd yr un man drwy lwybr gwahanol, gyda’r gweinydd dilysu yn dychwelyd yr allweddi fel priodweddau MS-MPPE-Recv-Key a MS-MPPE-Send-Key. Nid yw CHAP plaen yn ymddangos yn y naill lwybr na’r llall, a dyna’r rheswm cyfan dros fod yr anghysondeb.

Mae ffurfweddiad sy’n mynnu MPPE tra’n gwrthod pob dull sy’n gallu cyflenwi allweddi yn wrthgyferbyniol yn fewnol. Mae pppd yn datrys y gwrthgyferbyniad hwnnw drwy wrthod y cysylltiad, nid drwy ddyfeisio allweddi, felly’r canlyniad gweladwy yw sesiwn sy’n dilysu ac yna’n terfynu yn ystod y cam rhwydwaith. Ni fydd ceisio’r cleient eto yn newid hynny tra bo’r gweinydd yn gwrthod yr unig ddulliau sy’n deillio unrhyw beth.

Mae’r rheol sy’n dilyn yn fyr: os yw’r proffil yn mynnu MPPE, rhaid i’r dull fod yn amrywiolyn MS-CHAP neu’n ddull EAP y mae’r gweinydd yn dychwelyd ei allweddi. Nid yw gwrthod MS-CHAPv2 yn unig yn gorfodi hynny, oherwydd mae MS-CHAPv1 hefyd yn deillio allweddi ac yn aros ar gael oni bai ei wrthod ar wahân; mae gwrthod y ddau yn gadael CHAP plaen a PAP, nad ydynt yn deillio dim ac sy’n gwneud y gofyniad yn anfoddhaol. Enwch y dull a dderbynnir yn benodol yn lle rhestru’r rhai nad ydych yn eu hoffi. Mae gollwng y gofyniad amgryptio er mwyn i gleient gysylltu yn ddiraddiad, nid yn atgyweiriad.

Darllenwch opsiynau’r gweinydd cyn golygu cleient

Mae’r rhan fwyaf o’r anghysondebau hyn yn weladwy ar y gweinydd mewn dau ffeil, ac mae eu darllen yn costio llai na ailadeiladu cleient. Ar bwynt terfyn PPTP Linux mae’r gosodiadau perthnasol yn byw yn ffeil opsiynau pppd y mae pptpd yn ei throsglwyddo. Rhedwch ef ar y gweinydd, nid o sgrin statws cleient. Dechreuwch gyda’r llinellau sy’n mynnu, yn gwrthod neu’n enwi modd amddiffyn:

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

Darllenwch y cynnyrch fel contract yn hytrach na rhestr o fflamiau. Ni all unrhyw gleient fodloni llinell sy’n mynnu MPPE tra’n gwrthod y ddau amrywiolyn MS-CHAP, ac mae gofyniad ar goll ar gyfer dull MS-CHAP yn gadael y drws yn agored i gyfnewidiadau nad ydynt yn rhoi allweddi. Yna gwiriwch pwy a ganiateir i ddilysu o gwbl, peth y mae’r ffeil gyfrinachau yn ei benderfynu:

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

Nodwch dri gwerth cyn newid unrhyw beth: y protocol allanol, y dull dilysu y mae’r gweinydd yn ei fynnu, ac a yw amddiffyniad yn orfodol neu’n ddewisol. Mae’r tri hynny’n penderfynu pob penderfyniad diweddarach, a dyfalu amdanynt o ddialog cleient yw sut mae proffil yn gorffen yn hanner ffurfweddedig. Cadwch y ffeil ar agor tra’n gweithio, oherwydd mae’r adran nesaf angen yr un tri gwerth.

Lleolwch y methiant yn ôl cam PPP

Mae PPP yn adrodd methiannau mewn camau, ac mae’r cam yn dweud pa gymal o’r contract a dorrwyd. Mae gan gysylltiad nad yw byth yn gadael rheolaeth cyswllt broblem amgáu neu drafod, tra bo un sy’n dilysu ac yna’n marw fel arfer â phroblem polisi neu allwedd. Mae cysylltiad sy’n aros i fyny ac yn cario dim wedi symud ymlaen i lwybro, sef ymchwiliad gwahanol.

Mae’r journal yn cadw’r llinellau cam, ac maent yn fwy defnyddiol na lefel dadfygio uwch. Gofynnwch am brosesau PPP a’r negeseuon amddiffyn, yna darllenwch ganlyniad y dilysu cyn unrhyw beth arall. Mae’r llinellau olaf fel arfer yn enwi’r cymal a wrthododd:

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

Yn y cynnyrch hwnnw, chwiliwch yn gyntaf am ganlyniad y dilysu ac yna am gŵyn bod amddiffyniad yn ofynnol ond heb ei drafod. Yr ail neges yw llofnod y gwrthgyferbyniad uchod, ac nid yw unrhyw faint o ailgynnig yn ei glirio tra bo’r gweinydd yn gwrthod yr unig ddull sy’n gallu cynhyrchu allweddi. Mae dau fagl yn werth eu henwi: mae codi’r lefel dadfygio heb ddarllen y llinellau cam yn cynhyrchu sŵn, ac mae dal deunydd her neu gyfrineiriau yn troi tasg ffurfweddu yn ollyngiad cymwysterau. Cofnodwch y cam hwnnw cyn newid unrhyw opsiwn.

Cynlluniwch yr allanfa cyn i’r hen bwynt terfyn gael ei ddiffodd

Mae MPPE yn fecanwaith amddiffyn cyswllt hanesyddol, ac nid yw ei bresenoldeb yn gwneud PPTP yn ddewis synhwyrol ar gyfer defnydd newydd. Mae canllawiau Microsoft cyfredol eisoes yn cynghori yn erbyn PPTP ac yn erbyn L2TP/IPsec ag allwedd a rennir ymlaen llaw ar gyfer defnyddiadau mynediad o bell newydd. Mae cadw hen bwynt terfyn yn fyw yn benderfyniad am wasanaeth sy’n bodoli, nid yn dempled ar gyfer yr un nesaf.

Pan fo’n rhaid i’r pwynt terfyn aros, ysgrifennwch y contract: protocol allanol, dull dilysu gofynnol, amddiffyniad gorfodol, a fersiwn y cleient sy’n ei drafod. Pan all fynd, dewiswch hunaniaeth porth y disodliad, ei ddilysu cleient a lle bydd y cymwysterau’n byw cyn cyffwrdd â’r hen broffil. Yna cynlluniwch lwybrau, DNS a’r adnoddau y mae gan bob defnyddiwr hawl i’w cyrraedd. Dilyswch y cleient arfaethedig yn erbyn gofynion y perchennog yn hytrach nag yn erbyn cysylltiad sy’n gweithio.

Dylai gwrthodiad bwriadol aros yn wrthodiad, oherwydd mae disgyn yn ôl i fodd heb amddiffyniad i wneud i brawf basio yn troi methiant polisi yn amlygiad. Y cyflwr gorffenedig yw contract â chymorth, wedi’i ddogfennu, nid y set leiaf o newidiadau sy’n gwneud i un hen gysylltiad lwyddo. Gadewch yr hen broffil yn ei le, heb ei ddefnyddio ac wedi’i ddogfennu, nes bod y disodliad yn pasio’r un gwiriadau.