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 и рутите се уште не се проверени, и секој тивко не успева на свој начин. Држете ги трите слоја одвоени во вашите белешки: правилен клуч со погрешен профил секогаш не успева, а поправката на еден слој никогаш не поправа друг.