Miksi pelkkä PPP CHAP ei täytä MPPE-vaatimusta

Salaukseen nojaava PPTP-profiili epäonnistuu yleensä samassa kohdassa: PPP sopii todennusvaihdosta, joka ei koskaan tuota MPPE:n tarvitsemaa avainmateriaalia. Tunneli näyttää puoliksi elävältä, salasana hyväksytään ja yhteys katkeaa ennen kuin yksikään liikennevirta ylittää sen. CHAP-valikon hakeminen, kunnes jokin yhdistyy, peittää varsinaisen vian, ja se on todennusmenetelmän ja suojauskäytännön välinen sopimus. Alla olevat tarkistukset on järjestetty niin, että kukin sulkee pois halvemman syyn kuin seuraava.

Yhden PPTP-yhteyden sisällä käydään kaksi neuvottelua

PPTP kuljettaa tavallista PPP-istuntoa GRE-tunnelin sisällä, ja ne kaksi neuvottelevat erikseen. Ulompi kerros päättää, miten paketit kapseloidaan ja mikä ohjauskanava on olemassa; sisempi PPP-istunto päättää, kuka vastapuoli on ja mikä suojaus kulkee sen päällä. Salasanakehote todistaa siis jotain vain sisemmästä kerroksesta, eikä valmis ulompi kättely todista mitään kummastakaan. Profiilit epäonnistuvat tässä, koska ihmiset debuggaavat tunnelia, kun erimielisyys istuu PPP:n sisällä.

Tavallinen CHAP on RFC 1994:n haaste-vastausvaihto, joka rakentuu jaetulle salaisuudelle eikä millekään muulle. MS-CHAPv2 on erilainen vaihto, jossa on eri viestit ja eri tulos, ja se on standardoitu RFC 2759:ssä. Kahden nimen yhteinen sana on ainoa, mikä niillä on yhteistä johdolla. Kumpikaan nimi ei kerro, mitä vaihto tuottaa, ja juuri se on ainoa osa, jolla on merkitystä.

Siksi pelkästään CHAP-niminen valinta on monitulkintainen vanhassa profiilissa. Kun palvelin haluaa MS-CHAPv2:n ja asiakas tarjoaa tavallista CHAPia, linkin ohjaus voi silti valmistua ja salasana silti tulla hyväksytyksi. Vika saapuu myöhemmin, kun palvelin yrittää johtaa suojausavaimet vaihdosta, joka ei tuottanut mitään.

Sovita vaadittu menetelmä avaimiin, joita se voi tuottaa

MPPE-avaimet eivät ole PPP:n ominaisuus yleisesti. Microsoft CHAP -perheelle johto on määritelty RFC 3079:ssä, ja se ottaa syötteeksi MS-CHAP-vaihdon tuloksen jaetun salaisuuden sijaan. EAP-menetelmät päätyvät samaan paikkaan toista reittiä, jolloin todennuspalvelin palauttaa avaimet MS-MPPE-Recv-Key- ja MS-MPPE-Send-Key-attribuutteina. Tavallinen CHAP ei esiinny kummallakaan reitillä, ja se on koko syy siihen, miksi epäsuhde on olemassa.

Kokoonpano, joka vaatii MPPE:tä mutta hylkää jokaisen avaimia toimittamaan pystyvän menetelmän, on sisäisesti ristiriitainen. pppd ratkaisee ristiriidan hylkäämällä yhteyden eikä keksimällä avaimia, joten näkyvä tulos on istunto, joka todennetaan ja päättyy sitten verkkovaiheessa. Asiakkaan uudelleenyritys ei muuta sitä, kunnes palvelin lakkaa hylkäämästä ainoita menetelmiä, jotka johtavat jotain.

Siitä seuraava sääntö on lyhyt: jos profiili vaatii MPPE:tä, menetelmän on oltava MS-CHAP-muunnos tai EAP-menetelmä, jonka avaimet palvelin palauttaa. Pelkän MS-CHAPv2:n hylkääminen ei pakota sitä, koska myös MS-CHAPv1 johtaa avaimia ja pysyy saatavilla, ellei sitä hylätä erikseen; molempien hylkääminen jättää jäljelle tavallisen CHAPin ja PAPin, jotka eivät johda mitään ja tekevät vaatimuksesta täyttämättömän. Nimeä hyväksytty menetelmä nimenomaisesti sen sijaan, että luetteloisit ne, joista et pidä. Salausvaatimuksesta luopuminen asiakkaan yhdistämiseksi on heikennys, ei korjaus.

Lue palvelimen asetukset ennen asiakkaan muokkaamista

Useimmat näistä epäsuhdista näkyvät palvelimella kahdessa tiedostossa, ja niiden lukeminen maksaa vähemmän kuin asiakkaan uudelleenrakentaminen. Linuxin PPTP-päätepisteessä asiaankuuluvat asetukset elävät pppd:n asetustiedostossa, jonka pptpd välittää. Aja se palvelimella, älä asiakkaan tilanäytöltä. Aloita riveistä, jotka vaativat, hylkäävät tai nimeävät suojausmuodon:

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

Lue tuloste sopimuksena, älä lippujen luettelona. Riviä, joka vaatii MPPE:tä mutta hylkää molemmat MS-CHAP-muunnokset, ei mikään asiakas voi täyttää, ja puuttuva vaatimus MS-CHAP-menetelmälle jättää oven auki vaihdoille, jotka eivät anna avaimia. Tarkista sitten, kuka ylipäätään saa todennusmenetelmän, minkä salaisuustiedosto päättää:

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

Kirjoita kolme arvoa ennen kuin muutat mitään: ulompi protokolla, palvelimen vaatima todennusmenetelmä ja se, onko suojaus pakollinen vai valinnainen. Ne kolme määräävät jokaisen myöhemmän päätöksen, ja niiden arvaaminen asiakasdialogista on se tapa, jolla profiili jää puoliksi konfiguroiduksi. Pidä tiedosto auki työskennellessäsi, koska seuraava osio tarvitsee samat kolme arvoa.

Paikanna vika PPP-vaiheen mukaan

PPP ilmoittaa vioista vaiheittain, ja vaihe kertoo, mikä sopimuksen lauseke katkesi. Yhteydellä, joka ei koskaan poistu linkin ohjauksesta, on kapselointi- tai neuvotteluongelma, kun taas se, joka todennetaan ja kuolee sitten, on yleensä käytäntö- tai avainongelma. Yhteydellä, joka pysyy pystyssä eikä kanna mitään, on siirrytty reititykseen, mikä on eri tutkimus.

Lokikirja pitää vaiherivit, ja ne ovat hyödyllisempiä kuin korkeampi debug-taso. Pyydä PPP-prosessit ja suojausviestit ja lue sitten todennuksen tulos ennen kaikkea muuta. Viimeiset rivit nimeävät yleensä lausekkeen, joka hylkäsi:

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

Etsi tästä tulosteesta ensin todennuksen tulos ja sitten valitus siitä, että suojausta vaadittiin mutta ei neuvoteltu. Toinen viesti on yllä olevan ristiriidan allekirjoitus, eikä mikään määrä uudelleenyrityksiä poista sitä, kunnes palvelin lakkaa hylkäämästä ainoan menetelmän, joka voi tuottaa avaimia. Kaksi ansaa kannattaa nimetä: debug-tason nostaminen lukematta vaiherivejä tuottaa kohinaa, ja haastemateriaalin tai salasanojen kaappaaminen muuttaa konfigurointitehtävän tunnistetietojen vuodoksi. Kirjaa se vaihe ennen kuin muutat mitään asetusta.

Suunnittele poistuminen ennen kuin vanha päätepiste sammutetaan

MPPE on historiallinen linkin suojausmekanismi, eikä sen läsnäolo tee PPTP:stä järkevää valintaa uuteen käyttöönottoon. Microsoftin nykyinen ohjeistus suosittaa jo PPTP:tä vastaan ja L2TP/IPseciä vastaan esijaetulla avaimella uusissa etäkäytön käyttöönotoissa. Vanhan päätepisteen pitäminen elossa on päätös olemassa olevasta palvelusta, ei malli seuraavalle.

Kun päätepisteen on jäätävä, kirjoita sopimus ylös: ulompi protokolla, vaadittu todennusmenetelmä, pakollinen suojaus ja asiakasversio, joka sen neuvottelee. Kun se voi lähteä, valitse korvaajan yhdyskäytävän identiteetti, sen asiakastodennus ja paikka, jossa tunnistetiedot asuvat, ennen kuin kosket vanhaan profiiliin. Suunnittele sitten reitit, DNS ja resurssit, joihin kullakin käyttäjällä on valtuutus. Validoi aiottu asiakas omistajan vaatimuksia vastaan, älä toimivaa yhteyttä vastaan.

Tahallisen hylkäyksen pitäisi jäädä hylkäykseksi, koska suojaamattomaan tilaan palaaminen testin läpäisemiseksi muuttaa käytäntövian altistumiseksi. Valmis tila on tuettu, dokumentoitu sopimus, ei pienin muutosjoukko, joka saa yhden vanhan yhteyden onnistumaan. Jätä vanha profiili paikalleen, käyttämättömänä ja dokumentoituna, kunnes korvaaja läpäisee samat tarkistukset.