L2TP/IPsec не ради: изолујте IPsec, аутентификацију тунела или PPP пријаву

Три ствари се аутентификују унутар једне L2TP/IPsec везе, а само једна од њих укључује особу која бира број. IPsec доказује крајње тачке тунела, L2TP контролна веза може поново да докаже партнере сопственом тајном, а затим PPP доказује кориснички налог унутар сесије. Неуспех у било којој фази изгледа као општа грешка пријаве у дијалогу клијента, а у дневнику сервера изгледа потпуно другачије. Прођите кроз фазе по реду и зауставите се на првој која не успева, јер је свака фаза испод непроверене такође непроверена.

Три фазе аутентификације, три различита идентитета

IPsec доказује чије су крајње тачке, користећи унапред подељени кључ или сертификат. Тај идентитет припада машинама или мрежним пролазима, никада човеку за тастатуром. Када партнери не могу да се договоре у овој фази, ниједан L2TP пакет се уопште не размењује.

L2TP контролна веза може да дода другу, одвојену размену изазов-одговор, којом управља заједничка тајна коју морају имати оба краја.

RFC 2661 ту аутентификацију контролне везе чини опционом, што објашњава зашто иста грешка даје различите симптоме на два сервера. Поставка која никада није конфигурисала тајну тунела потпуно прескаче фазу; она која ју је поставила само на једној страни не успева пре него што се PPP уопште понуди. Затим PPP аутентификује корисника помоћу PAP, CHAP или MSCHAPv2 и предаје име складишту налога које може бити локално, у chap-secrets или на RADIUS-у. Погрешна лозинка у том тренутку вас ипак оставља са тунелом који ради и сесијом која није успела.

Прочитајте тачку заустављања пре него што измените конфигурацију

Почните са ipsec --version да бисте знали да ли излаз стања припада strongSwan-у или Libreswan-у. Затим читајте дневник сервера, а не дијалог клијента, јер сервер бележи која је фаза одбила.

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

Држите кључни материјал и лозинке изван тог налепљивања; назив фазе усмерава посао, а унапред подељени кључ који процури поново отвара захтев са горим последицама.

Прва фаза: има ли IPsec асоцијацију?

Покрените ipsec statusall на strongSwan-у или ipsec whack --status на Libreswan-у и потражите успостављену подређену асоцијацију са бројачима који нису нула. ip xfrm state приказује поглед језгра на оба. Инсталиран пар SA са растућим бројачима значи да је прва фаза готова и можете да наставите.

Потпуно одсуство асоцијације указује на адресу партнера, скуп предлога или унапред подељени кључ, а понекад и на уређај који преписује UDP 500 а одбацује UDP 4500. Асоцијација која се успостави и затим нестане после неколико секунди обично је неслагање животног века између два краја, а не проблем са акредитивима. Проверите да ли обе стране наводе исте предлоге шифровања и хеша пре него што било шта поново укуцате. Ако не, ниједан кључ никада неће радити.

Зауставите се док асоцијација недостаје. Измена PPP опција у том тренутку ништа не мења и крије прави квар од следеће особе.

Друга фаза: да ли се L2TP контролна веза аутентификовала?

Када је IPsec подигнут, посматрајте L2TP демон због контролне везе која достиже успостављено стање, јер PPP не може да почне пре тога. Одбијање на контролној вези значи да се тајна тунела разликује између крајева, или да један крај захтева тајну коју други никада не шаље. Клијенти често приказују једно поље са ознаком shared secret, а оно обично припада IPsec-у, а не L2TP-у. Попуњавање тог поља не конфигурише тајну тунела, а брисање га не искључује.

Ако ниједна страна није конфигурисала тајну тунела, прескочите ову фазу и третирајте неуспех контролне везе као проблем доступности. Потврдите да UDP 1701 стиже до демона и да се оба краја слажу око истог инкапсулирања. Правило заштитног зида написано за један од та два услова чест је узрок везе која се отвара само половично.

Само сесија која почне да преговара PPP је заиста прошла фазу тунела.

Трећа фаза: да ли PPP одбија налог?

Неуспех PPP-а изгледа другачије споља: тунел је успостављен, сесија почиње, а демон бележи неуспех методе аутентификације или одбијање налога. Прочитајте методу наведену у тој поруци. PAP и CHAP не успевају из различитих разлога, а сервер који одбије једну одбиће клијента који нуди само ту.

На Linux серверу прегледајте датотеку опција коју демон предаје PPP-у, обично /etc/ppp/options.xl2tpd, и потврдите које се методе прихватају и где се налози решавају. Име које постоји у RADIUS-у али не у локалној датотеци тајни не успева чисто и изгледа као погрешна лозинка. Затим проверите да ли клијент нуди методу коју сервер прихвата, а не јачу коју сервер одбија да преговара. Промена унапред подељеног кључа ради поправке ове фазе траћи поподне и ништа не мења.

Када се сесија коначно подигне, додела адреса, DNS и руте још нису проверени, и свака тихо не успева на свој начин. Држите три слоја одвојено у белешкама: исправан кључ са погрешним налогом увек не успева, а поправка једног слоја никада не поправља други.