Чаму PPTP і L2TP/IPsec спыняюцца да запыту імені карыстальніка?
Адсутнасць запыту імені карыстальніка азначае, што PPP не пачаўся, таму няспраўнасць у транспарце, абмене ключамі або стварэнні тунеля. Праверце парадак этапаў перад пераўсталёўкай.
Адсутнасць запыту імені карыстальніка — дыягнастычны падарунак: PPP яшчэ не пачаўся, таму да ўліковага запісу, пароля і палітыкі дамена яшчэ не звярталіся. У злучэнні PPTP або L2TP/IPsec кліент запытвае ўліковыя даныя толькі пасля таго, як тунель існуе і сервер пачаў сеанс PPP. Усё, што можа зламацца да гэтага моманту, — гэта транспарт, абмен ключамі або стварэнне тунеля, гэта значна меншая плошча, чым «VPN зламаны».
Адсутны запыт звужвае няспраўнасць да трох этапаў
Запішыце апошні этап, які бачна ўдаўся, бо ў кожнага свой уласнік і сваё выпраўленне. Здагадкі пра налады ўліковага запісу, калі вы захраслі на два этапы раней, — гэта спосаб страціць паўдня.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
Кліент, які сканчаецца па тайм-ауце без запыту, ніколі не атрымаў асацыяцыю IPsec, таму няспраўнасць у IKE або ў тым, ці даходзяць вашыя пакеты да шлюза наогул. Той, што паведамляе пра праверку ўліковых даных і потым абрываецца, зайшоў далей, чым падказвае паведамленне. Запыт, за якім ідзе адмова, — гэта аўтэнтыфікацыя PPP, і яе месца ў артыкуле пра ўліковы запіс, а не ў гэтым.
Першы этап: пратакол, які міжсеткавы экран ціха адкідае
PPTP патрабуе TCP 1723 для канала кіравання і пратакол IP 47 для шляху даных, і яны падарожнічаюць асобна. Шматлікія сеткі прапускаюць 1723 і адкідаюць пратакол 47, што дае тунель, які дамаўляецца і потым не перадае нічога. Маршрутызатар з NAT таксама мае патрэбу ў пропуску з падтрымкай GRE, а шлях доступу толькі праз IPv6 не можа несці PPTP ні пры якой канфігурацыі.
L2TP праз IPsec займае порт 500 для IKE і порт 4500 для абходу NAT, затым заварочвае сам трафік L2TP у 1701, а ESP нясе абароненыя даныя пасля стварэння асацыяцыі. Дазвольце два парты кіравання, але не ESP, і вы атрымаеце менавіта той сімптом, што ў загалоўку: бачны прагрэс, потым мёртвы кліент да любога дыялогу ўліковых даных. Тэставанне з кропкі доступу тэлефона — танны спосаб аддзяліць праблему кліента ад праблемы шляху.
Другі этап: ключ, які не ключ, прапанова, якую не прапаноўваюць
Няўзгоднены папярэдне агульны ключ правальваецца хутка і ціха, і звычайны варыянт — ключ, які выглядае правільным на экране, але нясе ўстаўлены перанос радка або прабел у канцы. На кліенце Linux дыялог не абавязкова крыніца праўды: плагін L2TP у NetworkManager трымае сакрэты ў файлах пад /etc/ipsec.d/, і стары файл асобнага злучэння, які /etc/ipsec.secrets ўсё яшчэ ўключае, будзе выкарыстаны замест толькі што набранага. Скапіруйце гэты файл у бяспечнае месца, выключыце яго з шляху ўключэння, потым набярыце ключ уручную.
Другая палова гэтага этапа — прапанова. Абодва бакі мусяць дамовіцца пра адзін набор алгарытмаў фазы 1 — шыфраванне, цэласнасць і групу Diffie-Hellman — і пра адпаведныя пераўтварэнні ESP для фазы 2, інакш асацыяцыя не ўтвараецца зусім. Шлюз, які прапануе толькі 3DES, SHA1 і MODP1024, адмовіць кліенту, наладжанаму на больш моцныя алгарытмы, і ягоны журнал называе адхіленае пераўтварэнне. Журнал называе няўзгодненасць, калі вы яго чытаеце, а не перазапускаеце службу зноў. Замест капіравання радка алгарытмаў з форуму спытайце ў шлюза, якія пераўтварэнні ён сапраўды дамовіць: ike-scan, накіраваны на яго адрас, вяртае пераўтварэнні, якія ён дамовіць. Калі адзіная прапанова — крыптаграфія, якую ваша палітыка ўжо не дазваляе, выпраўленне належыць шлюзу, а не паніжэнню кліента.
У Windows ключ і метад аўтэнтыфікацыі жывуць у профілі VPN, і няўзгодненасць усплывае да запыту ўліковых даных, а не пасля. Калі прыёмнік — Windows Server, пераканайцеся, што роля аддаленага доступу ўсталяваная, што сертыфікат адпавядае імені, да якога падключаюцца кліенты, і што ні адзін фільтр партоў не вузейшы за пратаколы вышэй.
Трэці этап: тунель ёсць, а PPP не пачынаецца
Калі IKE завершаны, а запыт так і не з'яўляецца, глядзіце на дэман тунеля, а не на міжсеткавы экран. L2TP патрабуе чагосьці, што слухае UDP 1701 — xl2tpd або kl2tpd у Linux, служба аддаленага доступу ў Windows — а ўсталяваная, але спыненая служба выглядае з боку кліента гэтак жа, як адкінуты пакет. Праверце слухача, перш чым зноў адкрываць правілы, якія вы ўжо праверылі. Потым PPP мусіць дамовіцца, і першы абмен LCP — месца, дзе звычайна асядае ціхая няўдача.
Адна пастка на гэтым этапе зусім не сеткавая: Windows дазваляе толькі адно злучэнне дадзенага тыпу VPN адначасова, таму другая спроба вяртае памылку 937, «іншае злучэнне гэтага тыпу ўжываецца». Гэта лакальнае правіла, і абысці яго можна іншай прыладай, іншым тыпам тунеля або сумесным выкарыстаннем адзінага злучэння, якое ўжо існуе.
Чытайце журнал у парадку этапаў, а не здагадвайцеся
Спыніце кліент, запусціце яго зноў і чытайце кампаненты ў тым парадку, у якім яны пішуць журнал. Гэта значыць спачатку дэман IPsec — strongSwan або Libreswan, і ipsec --version скажа, які менавіта — потым дэман L2TP, потым pppd. Які б кампанент ні напісаў апошнім перад збоем, ён пазначае этап для расследавання, бо ўсё, што ідзе пасля яго ў паслядоўнасці, наогул не запускалася.
Правярайце свежым злучэннем, а не захаваным сеансам, бо кліент, які перападключаецца з кэша, можа прапусціць часткі абмену і ўзнавіць састарэлы вынік. Пацвердзіце дасягальнасць, абмен ключамі, тунель і PPP па адным, у такім парадку. Тады адсутны запыт перастае быць загадкай і робіцца другім радком спісу, па якім можна сапраўды працаваць. Гэты ж спіс вы перадаяце сеткавай камандзе, у якой інакш папросяць праверыць міжсеткавы экран на прадмет няспраўнасці, што жыве ў незапушчаным дэмане.