Kvifor PPP CHAP åleine ikkje kan oppfylle eit MPPE-krav

Eit PPTP-profil som insisterer på kryptering, feilar som regel på same staden: PPP blir samde om ei autentiseringsutveksling som aldri produserer nøkkelmaterialet MPPE treng. Tunnelen ser halvt levande ut, passordet blir godteke, og sambandet fell før nokon trafikk kryssar det. Å gripe etter CHAP-rullgardina til noko koplar til, skjuler den eigentlege feilen, og den er ein kontrakt mellom autentiseringsmetoden og vernepolitikken. Kontrollane nedanfor er ordna slik at kvar av dei utelukkar ei billegare årsak enn den neste.

To forhandlingar går føre seg inne i éin PPTP-samband

PPTP ber ein vanleg PPP-økt inne i ein GRE-tunnel, og dei to forhandlar kvar for seg. Det ytre laget avgjer korleis pakkar blir kapsla inn og kva kontrollkanal som finst; den indre PPP-økta avgjer kven motparten er og kva vern som ligg oppå. Ei passordførespurnad provar derfor berre noko om det indre laget, og eit fullført ytre handtrykk provar ingenting om nokon av dei. Profil feilar her fordi folk feilsøkjer tunnelen medan usemja sit inne i PPP.

Vanleg CHAP er utfordring-svar-utvekslinga i RFC 1994, bygd på ein delt løyndom og ingenting anna. MS-CHAPv2 er ei anna utveksling med andre meldingar og eit anna resultat, standardisert i RFC 2759. Det felles ordet i dei to namna er det einaste dei har felles på leidningen. Ingen av namna fortel kva utvekslinga produserer, og det er den einaste delen som tel.

Derfor er eit alternativ som berre heiter CHAP tvitydig i eit gamalt profil. Når tenaren vil ha MS-CHAPv2 og klienten tilbyr vanleg CHAP, kan lenkjekontrollen framleis fullførast og eit passord framleis bli godteke. Feilen kjem seinare, når tenaren prøver å leie ut vernenøklar frå ei utveksling som ikkje produserte nokon.

Tilpass den påkravde metoden til nøklane han kan produsere

MPPE-nøklar er ikkje ein eigenskap ved PPP generelt. For Microsoft CHAP-familien er utleiinga oppgitt i RFC 3079, og ho tek som inndata resultatet av ei MS-CHAP-utveksling i staden for ein delt løyndom. EAP-metodar når same staden via ein annan veg, der autentiseringstenaren returnerer nøklane som attributta MS-MPPE-Recv-Key og MS-MPPE-Send-Key. Vanleg CHAP førekjem ikkje på nokon av dei to vegane, og det er heile grunnen til at misforholdet finst.

Ein konfigurasjon som krev MPPE medan han avviser kvar metode som kan levere nøklar, er indre motsegnsfull. pppd løyser den motsegna ved å avvise sambandet, ikkje ved å finne opp nøklar, så det synlege resultatet er ei økt som autentiserer og deretter blir avslutta i nettverksfasen. Nye forsøk frå klienten endrar ikkje det så lenge tenaren avviser dei einaste metodane som leier ut noko.

Regelen som følgjer, er kort: krev profilen MPPE, må metoden vere ein MS-CHAP-variant eller ein EAP-metode der tenaren returnerer nøklane. Å avvise berre MS-CHAPv2 handhevar ikkje det, fordi MS-CHAPv1 òg leier ut nøklar og blir verande tilgjengeleg med mindre det blir avvist separat; blir begge avviste, står vanleg CHAP og PAP att, som ikkje leier ut noko og gjer kravet uoppfylleleg. Namngje den godtekne metoden eksplisitt i staden for å liste opp dei du ikkje likar. Å sleppe krypteringskravet for å få ein klient til å kopie til, er ei nedgradering, ikkje ein reparasjon.

Les alternativa til tenaren før du redigerer ein klient

Dei fleste av desse misforholda er synlege på tenaren i to filer, og å lese dei kostar mindre enn å byggje ein klient på nytt. På eit Linux-PPTP-endepunkt bur dei relevante innstillingane i pppd-alternativfila som pptpd sender vidare. Køyr ho på tenaren, ikkje frå ein klientstatusskjerm. Start med linjene som krev, avviser eller namngjev ein vernemodus:

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

Les utdata som ein kontrakt og ikkje som ei liste med flagg. Ei linje som krev MPPE medan ho avviser båe MS-CHAP-variantane, kan ingen klient oppfylle, og eit manglande krav for ein MS-CHAP-metode lèt døra stå open for utvekslingar som ikkje gir nøklar. Kontroller deretter kven som i det heile får autentisere, noko løyndomsfila avgjer:

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

Skriv ned tre verdiar før du endrar noko: den ytre protokollen, autentiseringsmetoden tenaren krev, og om vernet er obligatorisk eller valfritt. Dei tre avgjer kvar seinare avgjerd, og å gjette dei frå ein klientdialog er korleis eit profil endar halvt konfigurert. Hald fila open medan du arbeider, fordi neste avsnitt treng dei same tre verdiane.

Finn feilen etter PPP-fase

PPP rapporterer feil i fasar, og fasen fortel kva klausul i kontrakten som braut. Eit samband som aldri forlèt lenkjekontrollen, har eit innkapslings- eller forhandlingsproblem, medan eit som autentiserer og deretter døyr, som regel har eit politikk- eller nøkkelproblem. Eit samband som blir ståande oppe og ikkje ber noko, har gått vidare til ruting, som er ei anna undersøking.

Journalen held på faselinjene, og dei er nyttigare enn eit høgare feilsøkingsnivå. Be om PPP-prosessane og vernemeldingane, og les deretter autentiseringsresultatet før alt anna. Dei siste linjene namngjev som regel klausulen som avviste:

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

I desse utdata bør du først sjå etter autentiseringsresultatet og deretter etter ei klage på at vern var påkravd, men ikkje forhandla. Den andre meldinga er signaturen til motsegna ovanfor, og inga mengd nye forsøk fjernar ho så lenge tenaren avviser den einaste metoden som kan produsere nøklar. To feller er verd å namngje: å heve feilsøkingsnivået utan å lese faselinjene gir støy, og å fange utfordringsmateriale eller passord gjer ein konfigurasjonsoppgåve om til ein lekkasje av påloggingsinformasjon. Noter den fasen før du endrar noka innstilling.

Planlegg utgangen før det gamle endepunktet blir slått av

MPPE er ein historisk mekanisme for lenkjevem, og tilstadeværet gjer ikkje PPTP til eit fornuftig val for ei ny utrulling. Gjeldande rettleiing frå Microsoft frårår allereie PPTP og L2TP/IPsec med ein førehandsdelt nøkkel for nye fjernåtkomst-utrullingar. Å halde eit gamalt endepunkt i live er ei avgjerd om ei eksisterande teneste, ikkje ein mal for den neste.

Når endepunktet må bli, skriv ned kontrakten: ytre protokoll, påkravd autentiseringsmetode, obligatorisk vern og den klientversjonen som forhandlar han. Når det kan gå, vel erstatninga sin gateway-identitet, klientautentiseringa hennar og kvar påloggingsinformasjonen skal bu før du rører det gamle profilen. Planlegg deretter ruter, DNS og ressursane kvar brukar er autorisert til å nå. Valider den tiltenkte klienten mot krava til eigaren i staden for mot eit fungerande samband.

Ei medviten avvising bør bli verande ei avvising, fordi å falle tilbake til ein uverna modus for å få ein test til å gå gjennom gjer ein politikkfeil om til ei eksponering. Den ferdige tilstanden er ein støtta, dokumentert kontrakt, ikkje det minste settet med endringar som får eitt gamalt samband til å lukkast. Lat det gamle profilen bli på plass, ubrukt og dokumentert, til erstatninga går gjennom dei same kontrollane.