Неге жалғыз PPP CHAP MPPE талабын қанағаттандыра алмайды

Шифрлауды талап ететін PPTP профилі әдетте бір жерде сәтсіздікке ұшырайды: PPP MPPE-ге қажет кілт материалын ешқашан өндірмейтін аутентификация алмасуына келіседі. Туннель жартылай тірі көрінеді, құпиясөз қабылданады, және одан ешқандай трафик өтпей тұрып байланыс үзіледі. Бірдеңе қосылғанша CHAP ашылма тізіміне ұмтылу нақты ақауды жасырады, ал ол аутентификация әдісі мен қорғау саясаты арасындағы шарт. Төмендегі тексерулер әрқайсысы келесіден арзанырақ себепті жоққа шығаратындай реттелген.

Бір PPTP байланысының ішінде екі келіссөз жүреді

PPTP GRE туннелінің ішінде қарапайым PPP сессиясын тасымалдайды, және екеуі бөлек келіссөз жүргізеді. Сыртқы қабат пакеттердің қалай инкапсуляцияланатынын және қандай басқару арнасы бар екенін шешеді; ішкі 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 соңғы нүктесінде тиісті параметрлер pptpd беретін pppd опциялар файлында тұрады. Оны серверде іске қосыңыз, клиент күй экранынан емес. Қорғау режимін талап ететін, қабылдамайтын немесе атайтын жолдардан бастаңыз:

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-ті және әр пайдаланушыға рұқсат етілген ресурстарды жоспарлаңыз. Көзделген клиентті жұмыс істеп тұрған байланыспен емес, иесінің талаптарымен салыстырыңыз.

Әдейі бас тарту бас тарту болып қалуы керек, өйткені сынақтан өту үшін қорғалмаған режимге шегіну саясат сәтсіздігін әшкерелеуге айналдырады. Дайын күй — қолдау көрсетілген, құжатталған шарт, бір ескі байланысты сәтті ететін ең кіші өзгерістер жиыны емес. Ауыстырғыш сол тексерулерден өткенше ескі профильді орнында, пайдаланылмай және құжатталған күйде қалдырыңыз.