Защо само PPP CHAP не може да покрие изискването за MPPE

PPTP профил, който настоява на криптиране, обикновено се проваля на едно и също място: PPP се договаря за обмен на удостоверяване, който никога не произвежда ключовия материал, необходим на MPPE. Тунелът изглежда полужив, паролата се приема, а връзката пада, преди през нея да мине какъвто и да е трафик. Посегването към падащото меню CHAP, докато нещо се свърже, скрива истинския дефект, а той е договор между метода за удостоверяване и политиката за защита. Проверките по-долу са подредени така, че всяка изключва по-евтина причина от следващата.

Две преговора текат в една PPTP връзка

PPTP носи нормална PPP сесия в GRE тунел и двете преговарят отделно. Външният слой решава как пакетите се инкапсулират и кой контролен канал съществува; вътрешната PPP сесия решава кой е партньорът и каква защита върви отгоре. Затова подканата за парола доказва нещо само за вътрешния слой, а завършено външно ръкостискане не доказва нищо за нито един от двата. Профилите се провалят тук, защото хората отстраняват грешки в тунела, докато разногласието седи вътре в PPP.

Обикновеният CHAP е обменът предизвикателство-отговор в RFC 1994, изграден върху споделена тайна и нищо друго. MS-CHAPv2 е различен обмен с различни съобщения и различен резултат, стандартизиран в RFC 2759. Споделената дума в двете имена е единственото общо между тях по кабела. Нито едно от имената не казва какво произвежда обменът, а точно това е единствената важна част.

Ето защо опция, означена просто CHAP, е двусмислена в стар профил. Когато сървърът иска MS-CHAPv2, а клиентът предлага обикновен CHAP, контролът на връзката все още може да завърши и паролата все още може да бъде приета. Провалът идва по-късно, когато сървърът се опита да извлече ключове за защита от обмен, който не е произвел нищо.

Съпоставете изисквания метод с ключовете, които той може да произведе

Ключовете на MPPE не са свойство на PPP по принцип. За семейството Microsoft CHAP извеждането е определено в RFC 3079 и приема като вход резултата от MS-CHAP обмен, а не споделена тайна. Методите EAP стигат до същото място по друг път, като сървърът за удостоверяване връща ключовете като атрибути MS-MPPE-Recv-Key и MS-MPPE-Send-Key. Обикновеният CHAP не се появява в нито един от двата пътя и това е цялата причина несъответствието да съществува.

Конфигурация, която изисква MPPE, но отказва всеки метод, способен да достави ключове, е вътрешно противоречива. pppd решава това противоречие, като отказва връзката, а не като измисля ключове, така че видимият резултат е сесия, която се удостоверява и след това прекратява по време на мрежовата фаза. Повторните опити на клиента няма да променят това, докато сървърът отказва единствените методи, които извеждат нещо.

Правилото, което следва, е кратко: ако профилът изисква MPPE, методът трябва да е вариант на MS-CHAP или EAP метод, чиито ключове сървърът връща. Отказът само на MS-CHAPv2 не го налага, защото MS-CHAPv1 също извежда ключове и остава достъпен, освен ако не бъде отказан отделно; отказът и на двата оставя обикновен CHAP и PAP, които не извеждат нищо и правят изискването неизпълнимо. Назовете приетия метод изрично, вместо да изброявате тези, които не харесвате. Отпадането на изискването за криптиране, за да се свърже клиент, е понижение, а не ремонт.

Прочетете опциите на сървъра, преди да редактирате клиент

Повечето от тези несъответствия са видими на сървъра в два файла и четенето им струва по-малко от преизграждане на клиент. На Linux PPTP крайна точка съответните настройки живеят във файла с опции на pppd, който pptpd предава. Изпълнете го на сървъра, а не от екрана за състояние на клиента. Започнете с редовете, които изискват, отказват или назовават режим на защита:

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

Четете изхода като договор, а не като списък с флагове. Ред, който изисква MPPE, но отказва и двата варианта на MS-CHAP, не може да бъде изпълнен от нито един клиент, а липсващото изискване за MS-CHAP метод оставя вратата отворена за обмени, които не дават ключове. След това проверете кой изобщо може да се удостоверява, което решава файлът с тайни:

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

Запишете три стойности, преди да промените нещо: външния протокол, метода за удостоверяване, който сървърът изисква, и дали защитата е задължителна или по избор. Тези три определят всяко следващо решение и отгатването им от диалог на клиента е начинът профилът да остане наполовина конфигуриран. Дръжте файла отворен, докато работите, защото следващият раздел се нуждае от същите три стойности.

Локализирайте провала по PPP фаза

PPP съобщава провали по фази и фазата казва кой член от договора се е счупил. Връзка, която никога не напуска контрола на връзката, има проблем с инкапсулация или преговори, докато тази, която се удостоверява и след това умира, обикновено има проблем с политика или ключ. Връзка, която остава вдигната и не носи нищо, е преминала към маршрутизация, което е друго разследване.

Журналът пази редовете на фазите и те са по-полезни от по-високо ниво на отстраняване на грешки. Поискайте PPP процесите и съобщенията за защита, след което прочетете резултата от удостоверяването преди всичко друго. Последните редове обикновено назовават члена, който е отказал:

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

В този изход търсете първо резултата от удостоверяването, а след това оплакване, че защита е била изискана, но не е договорена. Второто съобщение е подписът на противоречието по-горе и никакво повторение не го изчиства, докато сървърът отказва единствения метод, който може да произведе ключове. Две капани заслужават да бъдат назовани: вдигането на нивото на отстраняване на грешки без четене на редовете на фазите произвежда шум, а улавянето на материал за предизвикателство или пароли превръща конфигурационна задача в изтичане на идентификационни данни. Запишете тази фаза, преди да промените каквато и да е опция.

Планирайте изхода, преди старата крайна точка да бъде изключена

MPPE е исторически механизъм за защита на връзката и присъствието му не прави PPTP разумен избор за ново внедряване. Актуалните указания на Microsoft вече съветват против PPTP и против L2TP/IPsec с предварително споделен ключ за нови внедрявания на отдалечен достъп. Поддържането на стара крайна точка жива е решение за съществуваща услуга, а не шаблон за следващата.

Когато крайната точка трябва да остане, запишете договора: външен протокол, изискван метод за удостоверяване, задължителна защита и версията на клиента, която я договаря. Когато може да си отиде, изберете самоличността на шлюза на замяната, нейното удостоверяване на клиента и къде ще живеят идентификационните данни, преди да докоснете стария профил. След това планирайте маршрути, DNS и ресурсите, до които всеки потребител има право да достигне. Проверете предвидения клиент спрямо изискванията на собственика, а не спрямо работеща връзка.

Умишленият отказ трябва да остане отказ, защото връщането към незащитен режим, за да мине тест, превръща провал на политиката в излагане. Завършеното състояние е поддържан, документиран договор, а не най-малкият набор от промени, който позволява на една стара връзка да успее. Оставете стария профил на място, неизползван и документиран, докато замяната мине същите проверки.