Чаму адзін 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, якія нічога не выводзяць і робяць патрабаванне невыканальным. Назавіце прыняты метад яўна замест пераліку тых, што вам не падабаюцца. Адкіданне патрабавання шыфравання, каб кліент падключыўся, — гэта паніжэнне, а не рамонт.

Прачытайце опцыі сервера перад рэдагаваннем кліента

Большасць такіх неадпаведнасцей бачная на серверы ў двух файлах, і чытанне іх каштуе менш, чым перабудова кліента. На канцавым пункце PPTP у Linux адпаведныя налады жывуць у файле опцый 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 і рэсурсы, да якіх кожны карыстальнік мае права дасягаць. Праверце меркаванага кліента супраць патрабаванняў уладальніка, а не супраць працоўнага злучэння.

Наўмысная адмова павінна застацца адмовай, бо адкат да незабароненага рэжыму, каб тэст прайшоў, ператварае збой палітыкі ў незабароненасць. Завершаны стан — гэта падтрымліваемая, дакументаваная дамова, а не найменшы набор змен, які дазваляе аднаму старому злучэнню атрымацца. Пакіньце стары профіль на месцы, невыкарыстаным і дакументаваным, пакуль замена не пройдзе тыя ж праверкі.