Эмне үчүн жалгыз 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-ти жана ар бир колдонуучуга уруксат берилген ресурстарды пландаңыз. Көздөлгөн клиентти иштеп жаткан байланышка эмес, ээсинин талаптарына салыштырып текшериңиз.

Атайын баш тартуу баш тартуу бойдон калышы керек, анткени сынак өтүшү үчүн корголбогон режимге чегинүү саясаттын ийгиликсиздигин ачыкка чыгарууга айландырат. Даяр абал — колдоого алынган, документтелген келишим, бир эски байланышты ийгиликтүү кылган эң кичине өзгөртүүлөр жыйындысы эмес. Алмаштыруучу ошол эле текшерүүлөрдөн өткөнгө чейин эски профилди ордунда, колдонулбай жана документтелген бойдон калтырыңыз.