Зашто сам 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 и ресурсе до којих сваки корисник има овлашћење. Проверите предвиђени клијент према захтевима власника, а не према радној вези.

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