PPTP грешка 800 срещу 812 и прекъсвания след минута

Три съобщения за грешка от един 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 passthrough дава точно тази картина: TCP ръкостискането завършва, после GRE пакетите изчезват, така че отказът изглежда като проблем с удостоверенията, макар да не е правен опит за вход.

Насочете пренасочването към текущия LAN адрес на сървъра, включете PPTP passthrough там, където рутерът го предлага, и опитайте отново от същата външна точка. Когато 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, настройките на ехото за тунел, който умира по график.