Waarom PPP CHAP alleen niet aan een MPPE-vereiste kan voldoen

Een PPTP-profiel dat op versleuteling staat, faalt meestal op dezelfde plek: PPP komt een authenticatie-uitwisseling overeen die nooit het sleutelmateriaal oplevert dat MPPE nodig heeft. De tunnel lijkt half levend, het wachtwoord wordt geaccepteerd en de verbinding valt weg voordat er verkeer doorheen gaat. Naar de CHAP-keuzelijst grijpen tot er iets verbindt, verbergt het echte defect, en dat is een contract tussen de authenticatiemethode en het beveiligingsbeleid. De controles hieronder zijn zo geordend dat elke een goedkopere oorzaak uitsluit dan de volgende.

Er lopen twee onderhandelingen in één PPTP-verbinding

PPTP draagt een normale PPP-sessie in een GRE-tunnel, en de twee onderhandelen apart. De buitenste laag bepaalt hoe pakketten worden ingekapseld en welk besturingskanaal bestaat; de binnenste PPP-sessie bepaalt wie de peer is en welke bescherming erbovenop ligt. Een wachtwoordprompt bewijst dus alleen iets over de binnenste laag, en een voltooide buitenste handshake bewijst niets over geen van beide. Profielen falen hier omdat mensen de tunnel debuggen terwijl het meningsverschil in PPP zit.

Gewone CHAP is de challenge-response-uitwisseling uit RFC 1994, gebouwd op een gedeeld geheim en niets anders. MS-CHAPv2 is een andere uitwisseling met andere berichten en een andere uitvoer, gestandaardiseerd in RFC 2759. Het gedeelde woord in de twee namen is het enige dat ze op de draad gemeen hebben. Geen van beide namen zegt wat de uitwisseling oplevert, en dat is het enige deel dat ertoe doet.

Daarom is een optie die simpelweg CHAP heet dubbelzinnig in een oud profiel. Wanneer de server MS-CHAPv2 wil en de client gewone CHAP biedt, kan de verbindingscontrole nog steeds voltooien en kan een wachtwoord nog steeds worden geaccepteerd. De fout komt later, wanneer de server beveiligingssleutels probeert af te leiden uit een uitwisseling die er geen heeft opgeleverd.

Stem de vereiste methode af op de sleutels die hij kan opleveren

MPPE-sleutels zijn niet algemeen een eigenschap van PPP. Voor de Microsoft CHAP-familie staat de afleiding in RFC 3079, en die neemt als invoer de uitvoer van een MS-CHAP-uitwisseling in plaats van een gedeeld geheim. EAP-methoden bereiken dezelfde plek via een andere route, waarbij de authenticatieserver de sleutels teruggeeft als de attributen MS-MPPE-Recv-Key en MS-MPPE-Send-Key. Gewone CHAP komt op geen van beide routes voor, en dat is de hele reden dat de mismatch bestaat.

Een configuratie die MPPE eist en tegelijk elke methode weigert die sleutels kan leveren, is innerlijk tegenstrijdig. pppd lost die tegenstrijdigheid op door de verbinding te weigeren, niet door sleutels te verzinnen, dus het zichtbare resultaat is een sessie die authenticeert en dan in de netwerkfase eindigt. De client opnieuw proberen verandert dat niet zolang de server de enige methoden weigert die iets afleiden.

De regel die daaruit volgt is kort: als het profiel MPPE eist, moet de methode een MS-CHAP-variant of een EAP-methode zijn waarvan de server de sleutels teruggeeft. Alleen MS-CHAPv2 weigeren dwingt dat niet af, want MS-CHAPv1 leidt ook sleutels af en blijft beschikbaar tenzij het apart wordt geweigerd; beide weigeren laat gewone CHAP en PAP over, die niets afleiden en de eis onvervulbaar maken. Noem de geaccepteerde methode expliciet in plaats van de methoden op te sommen die u niet bevalt. De versleutelingseis laten vallen om een client te laten verbinden is een verlaging, geen reparatie.

Lees de opties van de server voordat u een client bewerkt

De meeste van deze mismatches zijn op de server zichtbaar in twee bestanden, en ze lezen kost minder dan een client opnieuw opbouwen. Op een Linux-PPTP-eindpunt staan de relevante instellingen in het pppd-optiesbestand dat pptpd doorgeeft. Voer het uit op de server, niet vanaf een clientstatusschem. Begin met de regels die een beveiligingsmodus eisen, weigeren of benoemen:

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

Lees de uitvoer als een contract en niet als een lijst vlaggen. Een regel die MPPE eist en tegelijk beide MS-CHAP-varianten weigert, kan geen enkele client vervullen, en een ontbrekende eis voor een MS-CHAP-methode laat de deur open voor uitwisselingen die geen sleutels geven. Controleer daarna wie überhaupt mag authenticeren, wat het geheimenbestand beslist:

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

Noteer drie waarden voordat u iets wijzigt: het buitenste protocol, de authenticatiemethode die de server eist, en of bescherming verplicht of optioneel is. Die drie bepalen elke latere beslissing, en ze uit een clientdialoog raden is hoe een profiel half geconfigureerd eindigt. Houd het bestand open terwijl u werkt, want de volgende sectie heeft dezelfde drie waarden nodig.

Localiseer de fout per PPP-fase

PPP meldt fouten in fasen, en de fase zegt welke clausule van het contract is gebroken. Een verbinding die de verbindingscontrole nooit verlaat, heeft een inkapselings- of onderhandelingsprobleem, terwijl een die authenticeert en dan sterft meestal een beleids- of sleutelprobleem heeft. Een verbinding die overeind blijft en niets draagt, is doorgeschoven naar routering, wat een ander onderzoek is.

Het journaal bewaart de faseregels, en die zijn nuttiger dan een hoger debug-niveau. Vraag de PPP-processen en de beveiligingsberichten op, en lees daarna het authenticatieresultaat vóór al het andere. De laatste regels noemen meestal de clausule die weigerde:

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

Zoek in die uitvoer eerst het authenticatieresultaat en dan een klacht dat bescherming vereist was maar niet onderhandeld. Het tweede bericht is de signatuur van de tegenstrijdigheid hierboven, en geen enkele hoeveelheid opnieuw proberen haalt die weg zolang de server de enige methode weigert die sleutels kan opleveren. Twee valkuilen zijn het noemen waard: het debug-niveau verhogen zonder de faseregels te lezen levert ruis op, en uitdagingsmateriaal of wachtwoorden onderscheppen maakt van een configuratietaak een lek van inloggegevens. Noteer die fase voordat u een optie wijzigt.

Plan de uitgang voordat het oude eindpunt wordt uitgezet

MPPE is een historisch mechanisme voor verbindingsbeveiliging, en de aanwezigheid ervan maakt PPTP geen verstandige keuze voor een nieuwe uitrol. De huidige richtlijn van Microsoft raadt al PPTP af en ook L2TP/IPsec met een vooraf gedeelde sleutel voor nieuwe uitrollen van externe toegang. Een oud eindpunt in leven houden is een beslissing over een bestaande dienst, geen sjabloon voor de volgende.

Wanneer het eindpunt moet blijven, schrijf het contract op: buitenste protocol, vereiste authenticatiemethode, verplichte bescherming en de clientversie die dat onderhandelt. Wanneer het weg kan, kies dan de gateway-identiteit van de vervanger, de clientauthenticatie daarvan en waar de inloggegevens zullen leven voordat u het oude profiel aanraakt. Plan daarna routes, DNS en de bronnen waartoe elke gebruiker gemachtigd is. Valideer de bedoelde client tegen de eisen van de eigenaar en niet tegen een werkende verbinding.

Een bewuste weigering moet een weigering blijven, want terugvallen op een onbeveiligde modus om een test te laten slagen verandert een beleidsfout in een blootstelling. De voltooide toestand is een ondersteund, gedocumenteerd contract, niet de kleinste set wijzigingen die één oude verbinding laat slagen. Laat het oude profiel op zijn plaats, ongebruikt en gedocumenteerd, tot de vervanger dezelfde controles doorstaat.