Які этап VPN адмовіў: IPsec, кіраванне L2TP ці аўтэнтыфікацыя PPP
Знайдзіце апошні паспяховы этап, а потым выпраўце толькі гэты слой: IPsec, канал кіравання L2TP, аўтэнтыфікацыю PPP або прызначэнне адраса.
Вы змянілі пароль, і нічога не зрушылася, бо збой ніколі не быў у PPP. L2TP/IPsec паведамляе пра адну памылку злучэння для пяці цалкам розных перадач, і кожная перадача мае сваё выпраўленне. Працуйце ў адваротным кірунку: знайдзіце апошні этап, які ўдаўся, і змяняйце толькі тое, што ідзе пасля яго. Парадак ніжэй таксама вызначае, якія доказы збіраць першымі.
Адказвайце на чатыры пытанні па чарзе
Прымусьце новую спробу, бо некаторыя кліенты паказваюць папярэднюю памылку, пакуль профіль не адключаць і не падключаць зноў. Затым адкажыце: ці была асацыяцыя бяспекі IPsec, ці з’явілася кіраўнічае злучэнне L2TP і выклік, ці дасягнуў PPP рашэння аб аўтэнтыфікацыі і ці выдаў IPCP кліенту адрас? Першае не — гэта этап, які вы выпраўляеце. Усё пасля яго не праверана, таму адхіленае імя карыстальніка нічога не даказвае, калі асацыяцыі ніколі не было.
Сінхранізуйце гадзіннікі на абодвух канцах перад параўнаннем. Спроба, якая ачысціла IPsec і звалілася на PPP, выглядае як адзін збой, калі кліент паказвае толькі апошняе паведамленне, а серверны журнал захоўвае папярэднюю спробу. Чытайце па часе, а не па самым гучным радку.
Калі ў вас ёсць толькі здымак экрана карыстальніка, абапірайцеся на самае таннае раздзяленне: няправільны папярэдне агучаны ключ і xl2tpd, які ніколі не адказвае, даюць адзін і той жа тэкст у дыялогу Windows, але аднаму патрэбны сакрэт, зменены на абодвух канцах, а другому — запушчаны дэман або правіла фаервера на самім серверы. Прылада пасярэдзіне не можа скінуць унутраны 1701 пасля таго, як IPsec у рэжыме транспарту яго абгарнуў, таму не шукайце фільтр шляху, якога няма.
Што насамрэч належыць кожнаму слою
IPsec абараняе пакеты паміж двума аднагодкамі; L2TP нясе сеанс PPP унутры гэтага абароненага шляху, таму RFC 3193 прадпісвае рэжым транспарту, а не ўласны тунель. Этыкетка кліента кажа L2TP, таму тунель і ўваход выглядаюць адным механізмам. Гэта не так: кіраўнічае злучэнне L2TP аўтэнтыфікуе канчатковыя пункты тунеля там, дзе разгортванне гэта ўключае, а PPP асобна аўтэнтыфікуе карыстальніка праз CHAP, PAP або MS-CHAPv2 паводле палітыкі сервера.
Гэтае раздзяленне тлумачыць два сакрэты, якія людзі пастаянна блытаюць. Папярэдне агучаны ключ аўтэнтыфікуе аднагодкаў IPsec. Імя карыстальніка і пароль пазначаюць карыстальніка для PPP. Паўторны ўвод агучанага сакрэту Windows у профілі, які аўтэнтыфікуецца сертыфікатамі, нічога не змяняе на этапе збою, а правака пароля PPP не можа даць адсутны абаронены канал. Тая ж стрыманасць датычыцца праверкі асобы: не адключайце ідэнтычнасць аднагодка або праверку сертыфіката, каб атрымаць тунель, бо тады злучаецца шлях, а не аднагодак.
Аўтэнтыфікацыя таксама не канец PPP. Пасля прыняцця карыстальніка IPCP узгадняе адрас кліента і параметры DNS і WINS, якія сервер гатовы выдаць. Кліент можа прайсці CHAP або MS-CHAPv2 і ўсё роўна застацца без адраса, і гэта збой унутры PPP, а не праблема маршрутызацыі. Просты L2TP без IPsec застаецца сапраўдным і незабароненым, таму паспяховае злучэнне ніколі не даказвае, што трафік абаронены; правярайце, што патрабуе сервер, а не этыкетку кліента.
Вырашайце па першым адсутным этапе
Чытайце табліцу па першым адсутным пункце, злева направа. Правы слупок — адзіная праца, якая мае сэнс у гэты момант; усё злева ўжо даказана, а паўторная праверка спальвае акно прастою, не дадаючы інфармацыі.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
Тры радкі вартыя папярэджання. Радок 1701 — гэта месца, дзе звычайна апынаюцца кліенты Windows за NAT: асацыяцыя завяршаецца, потым нічога не прыходзіць, і прычынай з’яўляецца інкапсуляцыя, а не дрэнны пароль. Радок IPCP — той, які памылкова чытаюць як праблему маршруту, бо Windows хавае адсутны адрас у памылку 720, а значок у лотку кажа толькі, што злучэнне не ўдалося; гэты збой знаходзіцца пасля аўтэнтыфікацыі і перад маршрутызацыяй. Апошні радок зусім не збой IPsec, хоць значок у лотку кажа пра адключэнне.
Каманды, якія раздзяляюць слаі
На серверы Linux з strongSwan swanctl --list-sas пералічвае ўсталяваныя асацыяцыі з ідэнтычнасцю аднагодка, а ipsec statusall ахоплівае старэйшыя хасты strongSwan і libreswan. Ніжэй ip xfrm state паказвае фактычныя асацыяцыі ядра, а ss -lunp | grep 1701 даказвае, дзе прывязаны xl2tpd. Запусціце xl2tpd -D на пярэднім плане, каб бачыць кіраўнічыя злучэнні і выклікі, і ўключыце адладку pppd у /etc/ppp/options.xl2tpd, каб бачыць прапанаваны метад і адказ.
Калі журналы паказваюць паспяховую аўтэнтыфікацыю, наступнае пытанне — ці завяршыўся IPCP. Праверце, ці ў ip range у раздзеле [lns default] файла /etc/xl2tpd/xl2tpd.conf яшчэ ёсць свабодныя адрасы і ці /etc/ppp/options.xl2tpd сапраўды змяшчае ms-dns і ms-wins, калі кліент іх чакае. Знясілены пул і адсутны параметр DNS выглядаюць на дроце па-рознаму: першы пакідае кліента без адраса і з 720, другі дае адрас, але без рэзалвера, таму імёны не працуюць, а ping да сырых адрасоў ідзе. Ні тое ні другое не выпраўляецца паўторным уводам пароля.
На кліенце плагін L2TP у NetworkManager запісвае размову pppd у журнал, таму journalctl -u NetworkManager -b звычайна аддзяляе тунель ёсць, аўтэнтыфікацыя адхілена ад тунелю зусім няма. У Windows Get-VpnConnection паведамляе сапраўдныя параметры аўтэнтыфікацыі профілю, а падзеі RasClient у раздзеле Application у Event Viewer называюць збойны кампанент. Калі дыялог занадта невыразны, уключыце netsh ras set tracing * enable.
Здымкі патрабуюць адной асцярогі. У рэжыме транспарту IPsec унутраны UDP 1701 зашыфраваны, таму здымак на знешнім інтэрфейсе паказвае ESP або UDP 4500 пры NAT-T і зусім не паказвае L2TP. Адсутнасць 1701 у здымку — гэта чакана і не доказ заблакаванага порта; сачыце, ці рухаюцца лічыльнікі ESP або 4500.
NAT, MTU і маршруты: дзе стэк вас падманвае
NAT ламае здагадкі яшчэ да любой аўтэнтыфікацыі. ESP — гэта ўласны пратакол IP, таму прылада, якая транслюе, адкідвае яго, калі аднагодкі не інкапсулююць; менавіта гэта забяспечвае UDP 4500. На серверы Windows, які сам стаіць за хатнім роўтарам або хмарным шлюзам NAT, этап IPsec звальваецца з памылкай 789, пакуль AssumeUDPEncapsulationContextOnSendRule не будзе ўсталяваны ў 2 пад ключом PolicyAgent і машына не перазагрузіцца, і збой застаецца неадрозным ад закрытага порта. Кліенты за NAT прасцейшыя: пры публічным адрасе на серверы NAT-T на UDP 4500 нясе іх, і гэта значэнне не задзейнічана.
Калі PPP узняты, MTU з чорнай дзіркай імітуе мёртвы тунель: дробныя пакеты праходзяць, рукапоціск TLS або загрузка старонкі завісаюць, а кліент можа ўсё яшчэ паказваць падключэнне. Панізьце MTU інтэрфейса або зацісніце MSS на шлюзе, перш чым вінаваціць сервер. Маршрутызацыя раздзеленага тунеля — іншы самазванец; падсетка, адпраўленая з няправільнай маскай, пакідае тунель здаровым, а адну праграму недасяжнай. Прыватнае імя хаста дадае свой крок: калі запыт выходзіць праз лакальны рэзалвер, імя не развязваецца яшчэ да таго, як будзе правераны які-небудзь маршрут.
Кантрольны спіс перад тым, як кранаць уліковыя даныя
Праходзьце спіс па парадку і спыніцеся на першым збойным пункце. Кожны крок танны, і кожны выключае цэлы клас правак.
- Пацвердзіце, што асацыяцыя існуе на абодвух канцах, супастаўленая па ідэнтычнасці аднагодка, а не па этыкетцы злучэння.
- Пацвердзіце, што UDP 1701 дасягае xl2tpd; асацыяцыя без выкліку — гэта ваш збой.
- Прачытайце вердыкт PPP, а калі ён аўтэнтыфікаваны, вынік IPCP, перш чым меркаваць, што пароль няправільны.
- Толькі цяпер увядзіце ўліковыя даныя зноў у фармаце, якога чакае сервер, бо прэфікс дамена змяняе ўліковы запіс.
- Калі ўсё яшчэ не ўдаецца, здыміце абодва канцы з выраўнаванымі часамі і параўнайце этап за этапам.
Спыненне на другім кроку азначае праблему шляху або інкапсуляцыі, і ніякая правака пароля яго не зрушыць. Спыненне на трэцім кроку азначае, што журнал ужо называе метад або пул адрасоў, які трэба выправіць. У любым выпадку наступная змена — тая, якую вы можаце абгрунтаваць, і вы перастаеце круціць налады, якія ніколі не былі задзейнічаны.