Varför PPP CHAP ensamt inte kan uppfylla ett MPPE-krav

En PPTP-profil som insisterar på kryptering misslyckas oftast på samma ställe: PPP kommer överens om ett autentiseringsutbyte som aldrig producerar det nyckelmaterial som MPPE behöver. Tunneln ser halvt levande ut, lösenordet accepteras och förbindelsen faller innan någon trafik korsar den. Att gripa efter CHAP-rullgardinen tills något ansluter döljer det verkliga felet, och det är ett kontrakt mellan autentiseringsmetoden och skyddspolicyn. Kontrollerna nedan är ordnade så att var och en utesluter en billigare orsak än nästa.

Två förhandlingar löper inuti en PPTP-anslutning

PPTP bär en vanlig PPP-session inuti en GRE-tunnel, och de två förhandlar var för sig. Det yttre lagret bestämmer hur paket kapslas in och vilken kontrollkanal som finns; den inre PPP-sessionen bestämmer vem motparten är och vilket skydd som ligger ovanpå. En lösenordsfråga bevisar därför bara något om det inre lagret, och ett slutfört yttre handskakning bevisar ingenting om något av dem. Profiler misslyckas här eftersom folk felsöker tunneln medan oenigheten sitter inne i PPP.

Vanlig CHAP är utmaning-svar-utbytet i RFC 1994, byggt på en delad hemlighet och ingenting annat. MS-CHAPv2 är ett annat utbyte med andra meddelanden och en annan utdata, standardiserat i RFC 2759. Det gemensamma ordet i de två namnen är det enda de har gemensamt på ledningen. Ingen av namnen säger vad utbytet producerar, och det är den enda delen som spelar roll.

Därför är ett alternativ som bara heter CHAP tvetydigt i en gammal profil. När servern vill ha MS-CHAPv2 och klienten erbjuder vanlig CHAP kan länkkontrollen fortfarande slutföras och ett lösenord fortfarande accepteras. Felet kommer senare, när servern försöker härleda skyddsnycklar från ett utbyte som inte producerade några.

Anpassa den krävda metoden till de nycklar den kan producera

MPPE-nycklar är inte en egenskap hos PPP generellt. För Microsoft CHAP-familjen anges härledningen i RFC 3079, och den tar som indata utdata från ett MS-CHAP-utbyte i stället för en delad hemlighet. EAP-metoder når samma plats via en annan väg, där autentiseringsservern returnerar nycklarna som attributen MS-MPPE-Recv-Key och MS-MPPE-Send-Key. Vanlig CHAP förekommer inte på någon av de två vägarna, och det är hela skälet till att missförhållandet finns.

En konfiguration som kräver MPPE men avvisar varje metod som kan leverera nycklar är inre motsägelsefull. pppd löser den motsägelsen genom att avvisa förbindelsen, inte genom att hitta på nycklar, så det synliga resultatet är en session som autentiserar och sedan avslutas i nätverksfasen. Nya försök från klienten ändrar inte det så länge servern avvisar de enda metoder som härleder något.

Regeln som följer är kort: om profilen kräver MPPE måste metoden vara en MS-CHAP-variant eller en EAP-metod vars nycklar servern returnerar. Att avvisa bara MS-CHAPv2 genomdriver inte det, eftersom MS-CHAPv1 också härleder nycklar och förblir tillgänglig om den inte avvisas separat; avvisas båda återstår vanlig CHAP och PAP, som inte härleder något och gör kravet ouppfyllbart. Namnge den accepterade metoden uttryckligen i stället för att lista dem du inte gillar. Att släppa krypteringskravet för att en klient ska ansluta är en nedgradering, inte en reparation.

Läs serverns alternativ innan du redigerar en klient

De flesta av dessa missförhållanden syns på servern i två filer, och att läsa dem kostar mindre än att bygga om en klient. På en Linux-PPTP-slutpunkt bor de relevanta inställningarna i pppd-alternativfilen som pptpd skickar vidare. Kör den på servern, inte från en klientstatusskärm. Börja med raderna som kräver, avvisar eller namnger ett skyddsläge:

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

Läs utdata som ett kontrakt och inte som en lista flaggor. En rad som kräver MPPE men avvisar båda MS-CHAP-varianterna kan ingen klient uppfylla, och ett saknat krav för en MS-CHAP-metod lämnar dörren öppen för utbyten som inte ger nycklar. Kontrollera sedan vem som över huvud taget får autentisera, vilket hemlighetsfilen avgör:

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

Skriv ned tre värden innan du ändrar något: det yttre protokollet, autentiseringsmetoden servern kräver och om skyddet är obligatoriskt eller valfritt. De tre bestämmer varje senare beslut, och att gissa dem från en klientdialog är hur en profil hamnar halvkonfigurerad. Håll filen öppen medan du arbetar, eftersom nästa avsnitt behöver samma tre värden.

Hitta felet efter PPP-fas

PPP rapporterar fel i faser, och fasen säger vilken klausul i kontraktet som bröts. En förbindelse som aldrig lämnar länkkontrollen har ett inkapslings- eller förhandlingsproblem, medan en som autentiserar och sedan dör oftast har ett policy- eller nyckelproblem. En förbindelse som står kvar och inte bär något har gått vidare till routning, vilket är en annan undersökning.

Journalen behåller fasraderna, och de är mer användbara än en högre felsökningsnivå. Be om PPP-processerna och skyddsmeddelandena, och läs sedan autentiseringsresultatet före allt annat. De sista raderna namnger oftast klausulen som avvisade:

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

I dessa utdata ska du först leta efter autentiseringsresultatet och sedan efter ett klagomål om att skydd krävdes men inte förhandlades. Det andra meddelandet är signaturen för motsägelsen ovan, och ingen mängd nya försök tar bort det så länge servern avvisar den enda metod som kan producera nycklar. Två fällor är värda att namnge: att höja felsökningsnivån utan att läsa fasraderna ger brus, och att fånga utmaningsmaterial eller lösenord förvandlar en konfigurationsuppgift till ett läckage av inloggningsuppgifter. Notera den fasen innan du ändrar någon inställning.

Planera utgången innan den gamla slutpunkten stängs av

MPPE är en historisk mekanism för länkskydd, och dess närvaro gör inte PPTP till ett förnuftigt val för en ny utrullning. Microsofts nuvarande vägledning avråder redan från PPTP och från L2TP/IPsec med en i förväg delad nyckel för nya fjärråtkomstutrullningar. Att hålla en gammal slutpunkt vid liv är ett beslut om en befintlig tjänst, inte en mall för nästa.

När slutpunkten måste stanna skriver du ned kontraktet: yttre protokoll, krävd autentiseringsmetod, obligatoriskt skydd och den klientversion som förhandlar det. När den kan gå väljer du ersättarens gateway-identitet, dess klientautentisering och var inloggningsuppgifterna ska bo innan du rör den gamla profilen. Planera sedan rutter, DNS och de resurser varje användare är auktoriserad att nå. Validera den avsedda klienten mot ägarens krav i stället för mot en fungerande förbindelse.

En avsiktlig avvisning bör förbli en avvisning, eftersom att falla tillbaka till ett oskyddat läge för att få ett test att gå igenom förvandlar ett policyfel till ett exponerat läge. Det färdiga tillståndet är ett stött, dokumenterat kontrakt, inte den minsta uppsättning ändringar som får en gammal förbindelse att lyckas. Låt den gamla profilen ligga kvar, oanvänd och dokumenterad, tills ersättaren klarar samma kontroller.