L2TP падключаецца, але ўзгадненне PPP правальваецца: якая фаза?

Тунэль IPsec усталёўваецца, кліент паказвае абароненага партнёра, і потым злучэнне гіне, перш чым хоць штосьці дасягне прыватнай падсеткі. Гэтая прага — гэта PPP, які робіць сваю ўласную працу: параметры звена, аўтэнтыфікацыя карыстальніка і прызначэнне адраса ўсё адбываецца пасля таго, як зашыфраваны тунэль ужо існуе. Нішто ў паспяховым абмене першай фазы не дае пароля ці ўнутранага адраса. Чытайце фазы па чарзе, і збой звычайна сам сябе называе.

Тунэль — гэта толькі першы ўзровень

L2TP пераносіць кадры PPP унутры тунэля, абароненага IPsec, што азначае: дзве незалежныя ўзгадненні мусяць прайсці, перш чым пакет можна будзе маршрутызаваць. Знешняе даказвае, што абодва бакі згодныя на ключы і ідэнтычнасці. Унутранае вырашае параметры звена, ці аўтэнтыфікуецца карыстальнік і які адрас атрымае кліент.

Збой унутры PPP выглядае як зламаны тунэль у кожным кліенце, што паказвае адзін індыкатар стану. Калі лічыць гэта праблемай тунэля, даводзіцца перагенерыраваць ключы, перазапускаць службы і ўрэшце замяняць агульны сакрэт, які ніколі не быў няправільным. Карыснае размежаванне таннае: калі абмен з партнёрам завяршыўся і кліент перайшоў да запыту імені карыстальніка ці да этапу аўтэнтыфікацыі, тунэль у парадку. Усё пасля гэтага пункту належыць PPP.

Чытайце апошнюю фазу, якая ўдалася

Ідзіце па журнале наперад і спыніцеся на першай фазе, якая не завяршылася. Спачатку ідзе LCP, потым аўтэнтыфікацыя, потым IPCP для параметраў IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Тайм-аўт LCP азначае, што два бакі так і не дамовіліся аб базавых параметрах звена, а гэта няправільны профіль ці заблакаваны ўнутраны пратакол, а не дрэнны пароль. Яўная адмова ў аўтэнтыфікацыі — процілеглы выпадак: звяно ўзнялося, і адзін бок адхіліў уліковыя даныя. Тайм-аўт IPCP пасля паспяховай аўтэнтыфікацыі ўказвае на пулы адрасоў ці палітыку сервера. Кожны з іх мае іншага ўладальніка і іншае выпраўленне, таму фаза важнейшая за канчатковы тэкст памылкі.

Трымайце вытрымку з журнала разам з назвай фазы ў заяўцы. Устаўлены хвост без мяжы фазы запрашае наступнага чытача дагадвацца, а здагадкі тут каштуюць гадзіну.

Згода паміж кліентам і серверам

Абодва бакі мусяць прымаць адзін і той жа метад аўтэнтыфікацыі, а захаваны профіль можа запытваць той, які сервер спыніў у мінулым квартале. Кіраваныя разгортванні таксама хаваюць бок сервера, дзе прычыну адмовы звычайна запісваюць на карыстальніка, а не на прыладу.

Уключыце адзін падтрымліваемы метад замест усялякай састарэлай опцыі, бо кліент, што прапануе пяць метадаў, хавае, які з іх не спрацаваў. Спытайце ў адміністратара палітыку боку сервера і дакладную адмову — гэта не патрабуе, каб хтосьці публікаваў пароль. Састарэлы метад, уключаны дзеля выратавання аднаго кліента, схільны распаўсюджвацца на кожны профіль, які капіюе файл.

Правярайце адрас, а не ўваход

Завершаны ўваход — яшчэ не прыдатная сесія. IPCP узгадняе ўнутраны адрас, і вычарпаны пул ці палітыка, што адмаўляе кліенту, могуць пакінуць падключаны тунэль без нічога для маршрутызацыі.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Спачатку праверце ўнутраны адрас, потым маршрут і рэзалвер для рэсурсу, які вам сапраўды патрэбны. Унутраны адрас — не публічны выхад, які паведамляе вэб-сайт, і блытаніна паміж імі адпраўляе людзей шукаць уцечку, якой няма. Тэстуйце прыватны рэсурс па адрасе раней, чым па імені, каб збой DNS не прынялі за збой маршрутызацыі.

Запішыце фазу, метад і адрас у адну нататку і пастаўце дату. Калі той жа ўліковы запіс зноў не спрацуе праз месяц, гэтая нататка — розніца паміж пяціхвіліннай праверкай і новым расследаваннем. Збоі на розных фазах — розныя інцыдэнты, нават калі кліент паказвае адзіны дыялог.