Hvorfor PPP CHAP alene ikke kan opfylde et MPPE-krav

En PPTP-profil, der insisterer på kryptering, fejler som regel samme sted: PPP bliver enige om en autentificeringsudveksling, der aldrig producerer det nøglemateriale, MPPE har brug for. Tunnelen ser halvt levende ud, adgangskoden accepteres, og forbindelsen falder, før nogen trafik krydser den. At gribe efter CHAP-rullemenuen, indtil noget forbinder, skjuler den egentlige fejl, og den er en kontrakt mellem autentificeringsmetoden og beskyttelsespolitikken. Kontrollerne nedenfor er ordnet, så hver enkelt udelukker en billigere årsag end den næste.

To forhandlinger løber inde i én PPTP-forbindelse

PPTP bærer en normal PPP-session inde i en GRE-tunnel, og de to forhandler hver for sig. Det ydre lag bestemmer, hvordan pakker indkapsles, og hvilken kontrolkanal der findes; den indre PPP-session bestemmer, hvem modparten er, og hvilken beskyttelse der ligger ovenpå. En adgangskodeprompt beviser derfor kun noget om det indre lag, og et fuldført ydre håndtryk beviser intet om nogen af dem. Profiler fejler her, fordi folk fejlretter tunnelen, mens uenigheden sidder inde i PPP.

Almindelig CHAP er udfordring-svar-udvekslingen i RFC 1994, bygget på en delt hemmelighed og intet andet. MS-CHAPv2 er en anden udveksling med andre meddelelser og et andet output, standardiseret i RFC 2759. Det fælles ord i de to navne er det eneste, de har til fælles på ledningen. Ingen af navnene fortæller, hvad udvekslingen producerer, og det er den eneste del, der betyder noget.

Derfor er en indstilling, der blot hedder CHAP, tvetydig i en gammel profil. Når serveren vil have MS-CHAPv2, og klienten tilbyder almindelig CHAP, kan linkkontrol stadig fuldføres, og en adgangskode kan stadig accepteres. Fejlen kommer senere, når serveren forsøger at udlede beskyttelsesnøgler fra en udveksling, der ikke producerede nogen.

Afstem den krævede metode med de nøgler, den kan producere

MPPE-nøgler er ikke en egenskab ved PPP generelt. For Microsoft CHAP-familien er udledningen angivet i RFC 3079, og den tager outputtet fra en MS-CHAP-udveksling som input i stedet for en delt hemmelighed. EAP-metoder når samme sted ad en anden vej, hvor autentificeringsserveren returnerer nøglerne som attributterne MS-MPPE-Recv-Key og MS-MPPE-Send-Key. Almindelig CHAP optræder ikke på nogen af de to veje, og det er hele grunden til, at uoverensstemmelsen findes.

En konfiguration, der kræver MPPE, mens den afviser enhver metode, der kan levere nøgler, er indvendigt selvmodsigende. pppd løser den modsigelse ved at afvise forbindelsen, ikke ved at opfinde nøgler, så det synlige resultat er en session, der autentificerer og derefter afbrydes i netværksfasen. Gentagne forsøg i klienten ændrer ikke det, så længe serveren afviser de eneste metoder, der udleder noget.

Reglen, der følger, er kort: kræver profilen MPPE, skal metoden være en MS-CHAP-variant eller en EAP-metode, hvis nøgler serveren returnerer. At afvise kun MS-CHAPv2 håndhæver ikke det, fordi MS-CHAPv1 også udleder nøgler og forbliver tilgængelig, medmindre den afvises separat; afvises begge, er der kun almindelig CHAP og PAP tilbage, som ikke udleder noget og gør kravet uopfyldeligt. Navngiv den accepterede metode udtrykkeligt i stedet for at liste dem, du ikke kan lide. At droppe krypteringskravet for at få en klient til at forbinde er en nedgradering, ikke en reparation.

Læs serverens indstillinger, før du redigerer en klient

De fleste af disse uoverensstemmelser er synlige på serveren i to filer, og at læse dem koster mindre end at genopbygge en klient. På et Linux-PPTP-endepunkt bor de relevante indstillinger i den pppd-indstillingsfil, som pptpd sender videre. Kør den på serveren, ikke fra en klientstatusskærm. Start med de linjer, der kræver, afviser eller navngiver en beskyttelsestilstand:

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

Læs outputtet som en kontrakt frem for en liste af flag. En linje, der kræver MPPE, mens den afviser begge MS-CHAP-varianter, kan ingen klient opfylde, og et manglende krav til en MS-CHAP-metode lader døren stå åben for udvekslinger, der ikke giver nøgler. Kontroller derefter, hvem der overhovedet må autentificere, hvilket hemmelighedsfilen afgør:

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

Skriv tre værdier ned, før du ændrer noget: den ydre protokol, den autentificeringsmetode serveren kræver, og om beskyttelse er obligatorisk eller valgfri. De tre bestemmer enhver senere beslutning, og at gætte dem ud fra en klientdialog er, hvordan en profil ender med at være halvt konfigureret. Hold filen åben, mens du arbejder, for næste afsnit har brug for de samme tre værdier.

Find fejlen via PPP-fasen

PPP rapporterer fejl i faser, og fasen fortæller, hvilken klausul i kontrakten der er brudt. En forbindelse, der aldrig forlader linkkontrol, har et indkapslings- eller forhandlingsproblem, mens en, der autentificerer og derefter dør, som regel har et politik- eller nøgleproblem. En forbindelse, der bliver oppe og ikke bærer noget, er gået videre til routing, hvilket er en anden undersøgelse.

Journalen gemmer faselinjerne, og de er mere nyttige end et højere fejlretningsniveau. Bed om PPP-processerne og beskyttelsesmeddelelserne, og læs derefter autentificeringsresultatet før alt andet. De sidste linjer navngiver som regel den klausul, der afviste:

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

I det output skal du først lede efter autentificeringsresultatet og derefter efter en klage over, at beskyttelse var krævet, men ikke forhandlet. Den anden meddelelse er signaturen på modsigelsen ovenfor, og ingen mængde genforsøg fjerner den, så længe serveren afviser den eneste metode, der kan producere nøgler. To fælder er værd at nævne: at hæve fejlretningsniveauet uden at læse faselinjerne producerer støj, og at indfange udfordringsmateriale eller adgangskoder gør en konfigurationsopgave til en lækage af legitimationsoplysninger. Noter den fase, før du ændrer nogen indstilling.

Planlæg udgangen, før det gamle endepunkt slukkes

MPPE er en historisk forbindelsesbeskyttelsesmekanisme, og dens tilstedeværelse gør ikke PPTP til et fornuftigt valg til en ny udrulning. Microsofts nuværende vejledning fraråder allerede PPTP og L2TP/IPsec med en forudelt nøgle til nye fjernadgangsudrulninger. At holde et gammelt endepunkt i live er en beslutning om en eksisterende tjeneste, ikke en skabelon til den næste.

Når endepunktet skal blive, så skriv kontrakten ned: ydre protokol, krævet autentificeringsmetode, obligatorisk beskyttelse og den klientversion, der forhandler den. Når det kan gå, så vælg erstatningens gateway-identitet, dens klientautentificering og hvor legitimationsoplysningerne skal bo, før du rører den gamle profil. Planlæg derefter ruter, DNS og de ressourcer, hver bruger er autoriseret til at nå. Validér den tilsigtede klient mod ejerens krav i stedet for mod en fungerende forbindelse.

En bevidst afvisning bør forblive en afvisning, fordi at falde tilbage til en ubeskyttet tilstand for at få en test til at bestå gør en politikfejl til en eksponering. Den færdige tilstand er en understøttet, dokumenteret kontrakt, ikke det mindste sæt ændringer, der får én gammel forbindelse til at lykkes. Lad den gamle profil blive på plads, ubrugt og dokumenteret, indtil erstatningen består de samme kontroller.