Hvorfor PPP CHAP alene ikke kan oppfylle et MPPE-krav

En PPTP-profil som insisterer på kryptering feiler som regel på samme sted: PPP blir enige om en autentiseringsutveksling som aldri produserer nøkkelmaterialet MPPE trenger. Tunnelen ser halvveis levende ut, passordet godtas, og forbindelsen faller før noen trafikk krysser den. Å gripe etter CHAP-rullegardinen til noe kobler til, skjuler den egentlige feilen, og den er en kontrakt mellom autentiseringsmetoden og beskyttelsespolitikken. Kontrollene nedenfor er ordnet slik at hver av dem utelukker en billigere årsak enn den neste.

To forhandlinger løper inne i én PPTP-forbindelse

PPTP bærer en vanlig PPP-økt inne i en GRE-tunnel, og de to forhandler hver for seg. Det ytre laget bestemmer hvordan pakker kapsles inn og hvilken kontrollkanal som finnes; den indre PPP-økten bestemmer hvem motparten er og hvilken beskyttelse som ligger oppå. En passordforespørsel beviser derfor bare noe om det indre laget, og et fullført ytre håndtrykk beviser ingenting om noen av dem. Profiler feiler her fordi folk feilsøker tunnelen mens uenigheten sitter inne i PPP.

Vanlig CHAP er utfordring-svar-utvekslingen i RFC 1994, bygget på en delt hemmelighet og ingenting annet. MS-CHAPv2 er en annen utveksling med andre meldinger og et annet resultat, standardisert i RFC 2759. Det felles ordet i de to navnene er det eneste de har til felles på ledningen. Ingen av navnene forteller hva utvekslingen produserer, og det er den eneste delen som betyr noe.

Derfor er et alternativ som bare heter CHAP tvetydig i en gammel profil. Når serveren vil ha MS-CHAPv2 og klienten tilbyr vanlig CHAP, kan lenkekontrollen fortsatt fullføres og et passord fortsatt godtas. Feilen kommer senere, når serveren prøver å utlede beskyttelsesnøkler fra en utveksling som ikke produserte noen.

Tilpass den påkrevde metoden til nøklene den kan produsere

MPPE-nøkler er ikke en egenskap ved PPP generelt. For Microsoft CHAP-familien er utledningen angitt i RFC 3079, og den tar som inndata resultatet av en MS-CHAP-utveksling i stedet for en delt hemmelighet. EAP-metoder når samme sted via en annen vei, der autentiseringsserveren returnerer nøklene som attributtene MS-MPPE-Recv-Key og MS-MPPE-Send-Key. Vanlig CHAP forekommer ikke på noen av de to veiene, og det er hele grunnen til at misforholdet finnes.

En konfigurasjon som krever MPPE mens den avviser enhver metode som kan levere nøkler, er indre motsetningsfull. pppd løser den motsetningen ved å avvise forbindelsen, ikke ved å finne opp nøkler, så det synlige resultatet er en økt som autentiserer og deretter avsluttes i nettverksfasen. Nye forsøk fra klienten endrer ikke det så lenge serveren avviser de eneste metodene som utleder noe.

Regelen som følger, er kort: hvis profilen krever MPPE, må metoden være en MS-CHAP-variant eller en EAP-metode hvis nøkler serveren returnerer. Å avvise bare MS-CHAPv2 håndhever ikke det, fordi MS-CHAPv1 også utleder nøkler og forblir tilgjengelig med mindre den avvises separat; avvises begge, gjenstår vanlig CHAP og PAP, som ikke utleder noe og gjør kravet uoppfyllbart. Navngi den godtatte metoden eksplisitt i stedet for å liste opp dem du ikke liker. Å droppe krypteringskravet for å få en klient til å koble til er en nedgradering, ikke en reparasjon.

Les serverens alternativer før du redigerer en klient

De fleste av disse misforholdene er synlige på serveren i to filer, og å lese dem koster mindre enn å bygge en klient på nytt. På et Linux-PPTP-endepunkt bor de relevante innstillingene i pppd-alternativfilen som pptpd sender videre. Kjør den på serveren, ikke fra en klientstatusskjerm. Start med linjene som krever, avviser eller navngir en beskyttelsesmodus:

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

Les utdataene som en kontrakt og ikke som en liste med flagg. En linje som krever MPPE mens den avviser begge MS-CHAP-variantene, kan ingen klient oppfylle, og et manglende krav for en MS-CHAP-metode lar døren stå åpen for utvekslinger som ikke gir nøkler. Kontroller deretter hvem som i det hele tatt får autentisere, noe hemmelighetsfilen avgjør:

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

Skriv ned tre verdier før du endrer noe: den ytre protokollen, autentiseringsmetoden serveren krever, og om beskyttelsen er obligatorisk eller valgfri. De tre bestemmer hver senere beslutning, og å gjette dem fra en klientdialog er hvordan en profil ender halvveis konfigurert. Hold filen åpen mens du arbeider, fordi neste avsnitt trenger de samme tre verdiene.

Finn feilen etter PPP-fase

PPP rapporterer feil i faser, og fasen forteller hvilken klausul i kontrakten som brast. En forbindelse som aldri forlater lenkekontrollen, har et innkapslings- eller forhandlingsproblem, mens en som autentiserer og deretter dør, som regel har et politikk- eller nøkkelproblem. En forbindelse som blir stående oppe og ikke bærer noe, har gått videre til ruting, som er en annen undersøkelse.

Journalen beholder faselinjene, og de er nyttigere enn et høyere feilsøkingsnivå. Be om PPP-prosessene og beskyttelsesmeldingene, og les deretter autentiseringsresultatet før alt annet. De siste linjene navngir som regel klausulen som avviste:

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

I disse utdataene bør du først se etter autentiseringsresultatet og deretter etter en klage på at beskyttelse var påkrevd, men ikke forhandlet. Den andre meldingen er signaturen til motsetningen ovenfor, og ingen mengde nye forsøk fjerner den så lenge serveren avviser den eneste metoden som kan produsere nøkler. To feller er verdt å navngi: å heve feilsøkingsnivået uten å lese faselinjene gir støy, og å fange utfordringsmateriale eller passord gjør en konfigurasjonsoppgave om til en lekkasje av påloggingsinformasjon. Noter den fasen før du endrer noen innstilling.

Planlegg utgangen før det gamle endepunktet slås av

MPPE er en historisk mekanisme for lenkebeskyttelse, og dens tilstedeværelse gjør ikke PPTP til et fornuftig valg for en ny utrulling. Microsofts gjeldende veiledning fraråder allerede PPTP og L2TP/IPsec med en forhåndsdelt nøkkel for nye fjern tilgang-utrullinger. Å holde et gammelt endepunkt i live er en beslutning om en eksisterende tjeneste, ikke en mal for den neste.

Når endepunktet må bli, skriv ned kontrakten: ytre protokoll, påkrevd autentiseringsmetode, obligatorisk beskyttelse og den klientversjonen som forhandler den. Når det kan gå, velg erstatningens gateway-identitet, dens klientautentisering og hvor påloggingsinformasjonen skal bo før du rører den gamle profilen. Planlegg deretter ruter, DNS og ressursene hver bruker er autorisert til å nå. Valider den tiltenkte klienten mot eierens krav i stedet for mot en fungerende forbindelse.

En bevisst avvisning bør forbli en avvisning, fordi å falle tilbake til en ubeskyttet modus for å få en test til å bestå gjør en politikkfeil om til en eksponering. Den ferdige tilstanden er en støttet, dokumentert kontrakt, ikke det minste settet med endringer som får én gammel forbindelse til å lykkes. La den gamle profilen bli på plass, ubrukt og dokumentert, til erstatningen består de samme kontrollene.