Памылка PPTP 800 і 812, а таксама абрывы праз хвіліну

Памылка 800, памылка 812 і тунель PPTP, які памірае праз хвіліну, — гэта тры розныя няспраўнасці. Суаднясіце кожны сімптом з узроўнем, які насамрэч адмовіў.

Тры паведамленні пра памылку ад аднаго кліента PPTP звычайна апісваюць тры розныя няспраўнасці. Памылка 800 азначае, што тунель так і не ўзнік, памылка 812 азначае, што сервер адхіліў метад аўтэнтыфікацыі, а абрыў праз хвіліну — гэта таймер захавання сувязі, які вырашае, што здаровы партнёр знік. Кожны этап адмаўляе па сваёй прычыне, таму кожнаму патрэбна свая праверка.

Памылка 800 азначае, што тунель так і не ўзнік

Windows выдае памылку 800, калі ўвогуле не можа пабудаваць тунель, а тэкст пра недасяжны сервер або неадпаведныя параметры бяспекі — гэта зводка, а не дыягназ. PPTP патрабуе ад сеткі дзве асобныя рэчы, перш чым правяраюцца хоць якія дадзеныя ўліковага запісу. TCP 1723 нясе канал кіравання, а IP-пратакол 47, GRE, нясе інкапсуляваную нагрузку.

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

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

Калі 1723 адказвае, а захоп застаецца пустым, пакуль кліент спрабуе падключыцца, шлях скідае пратакол 47. Маршрутызатар з перанакіраваным 1723, але выключаным пропускам PPTP дае менавіта такі ўзор: TCP-рукапоціск завяршаецца, потым пакеты GRE знікаюць, таму збой выглядае як праблема з дадзенымі ўліковага запісу, нават калі спроба ўваходу не рабілася.

Направіце перанакіраванне на бягучы LAN-адрас сервера, уключыце пропуск PPTP, дзе маршрутызатар яго прапануе, і паўтарыце спробу з таго ж знешняга пункту. Калі GRE фільтруецца вышэй па сетцы і вы не можаце гэтага змяніць, SSTP праз TCP 443 або L2TP/IPsec праз UDP 500 і 4500 мае лепшыя шанцы, чым любое змяненне на баку Windows.

Памылка 812 — гэта адхіленне серверам вашага метаду аўтэнтыфікацыі

Памылка 812 вяртаецца пасля таго, як тунель узняты, таму яна ўспрымаецца як праблема з паролем. Сервер адхіляе метад аўтэнтыфікацыі, узгоднены для злучэння, а не абавязкова сам пароль. На кліенце адкрыйце запіс VPN, перайдзіце на ўкладку бяспекі, задайце тып Point-to-Point Tunneling Protocol, выберыце яўны спіс пратаколаў і пазначце Microsoft CHAP версіі 2.

Вы можаце прачытаць бягучы параметр, не перабіраючы дыялог:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

Сервер, які патрабуе MS-CHAP v2, адхіляе кліента, пакінутага на PAP або на аўтаматычным тыпе, які ўзгадняе нешта слабейшае, і памылка прыходзіць раней, чым ацэньваецца пароль карыстальніка. Фармат уліковага запісу — другая палова таго ж адхілення. У адным выпадку Windows даслаў ідэнтычнасць уліковага запісу Microsoft выгляду MicrosoftAccount\[email protected], хаця серверу патрэбны быў лакальны або даменны запіс. Увод SERVERNAME\username паведаміў Windows, да якога сховішча запісаў звяртацца, і прыбраў памылку. Уводзьце імя ўручную, а не дазваляйце захаваным дадзеным уліковага запісу паўтараць папярэдні фармат.

Абрывы праз хвіліну — гэта рашэнне аб захаванні сувязі

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

На серверы Linux pptpd гэтыя значэнні жывуць у /etc/ppp/options.pptpd, і звычайнае рамантаванне — пашырыць бюджэт, а не скараціць інтэрвал:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Трыццаць пропускаў пры інтэрвале ў пяць секунд даруюць кароткае затармажэнне, а не абвяшчаюць партнёра зніклым. Паменшыць лік да аднаго-двух — значыць ператварыць звычайнае дрыжанне на транзітным шляху ў адключэнне прыкладна кожную хвіліну. Калі ваш сервер — Windows RRAS, а не pptpd, глядзіце замест гэтага на тайм-аўт сеансу PPP і палітыку адключэння пры прастоі. Яны жывуць у іншым месцы, і рэдагаванне файла pppd, якога не існуе, нічога не зменіць.

Перакрыжаваныя падсеткі ламаюць шлях даных

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

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

Пачніце з этапу, які адмовіў: GRE для 800, метад і радок уліковага запісу для 812, налады рэха для тунеля, які памірае па раскладу.

Падобныя артыкулы