Збой 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 і маршруты ўсё яшчэ не правераны, і кожнае з іх ціха збаіць па-свойму. Трымайце тры ўзроўні асобна ў нататках: правільны ключ з няправільным уліковым запісам заўсёды збаіць, і выпраўленне аднаго ўзроўню ніколі не выпраўляе другі.