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 не може да започне преди това. Отказ по контролната връзка означава, че тайната на тунела се различава между краищата или единият край изисква тайна, която другият никога не изпраща. Клиентите често показват едно поле, наречено споделена тайна, и то обикновено принадлежи на IPsec, а не на L2TP. Попълването му не настройва тайната на тунела, а изчистването му не я изключва.

Ако нито една страна няма настроена тайна на тунела, пропуснете този етап и третирайте отказа на контролната връзка като проблем с достъпността. Потвърдете, че UDP 1701 достига до демона и че двата края са съгласни за една и съща инкапсулация. Правило на защитната стена, написано за едно от тези две условия, е честа причина за връзка, която се отваря наполовина.

Само сесия, която започва да преговаря PPP, действително е преминала етапа на тунела.

Стъпка трета: PPP ли отхвърля акаунта?

Провалът на PPP изглежда различно отвън: тунелът е установен, сесията започва и демонът записва провал на метод за удостоверяване или отказ на акаунт. Прочетете метода, посочен в това съобщение. PAP и CHAP се провалят по различни причини и сървър, който отказва единия, ще отхвърли клиент, който предлага само него.

На сървър с Linux прегледайте файла с опции, който демонът подава на PPP, обикновено /etc/ppp/options.xl2tpd, и потвърдете кои методи се приемат и къде се разрешават акаунтите. Име, което съществува в RADIUS, но не в локалния файл с тайни, се проваля чисто и изглежда като лоша парола. След това проверете дали клиентът предлага метод, който сървърът приема, а не по-силен, от преговори за който сървърът отказва. Смяната на предварително споделения ключ, за да поправите този етап, губи следобеда и не променя нищо.

Когато сесията най-накрая се вдигне, раздаването на адреси, DNS и маршрутите остават непроверени и всяко от тях тихо се проваля по свой начин. Дръжте трите слоя отделно в бележките си: правилен ключ с грешен акаунт винаги се проваля и поправянето на един слой никога не поправя друг.