Зошто само 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 и ресурсите до кои секој корисник е овластен. Валидирајте го предвидениот клиент спрема барањата на сопственикот, а не спрема работна врска.

Намерното одбивање треба да остане одбивање, зашто враќањето во незаштитен режим за тестот да помине го претвора неуспехот на политиката во изложеност. Завршената состојба е поддржан, документиран договор, а не најмалиот збир промени што му овозможува на една стара врска да успее. Оставете го стариот профил на место, неискористен и документиран, додека замената не ги помине истите проверки.