Помилка PPTP 800 проти 812 та обриви через хвилину

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

Помилка 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 зникають, тому збій виглядає як проблема з обліковими даними, хоча спроби входу не було.

Спрямуйте перенаправлення на поточну адресу сервера в локальній мережі, увімкніть пропуск 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, до якого сховища облікових записів звертатися, і прибрало помилку. Введіть ім’я вручну, замість того щоб збережені облікові дані повторювали попередній формат.

Обриви через хвилину — це рішення keepalive

Коли тунель підключається, пропускає трохи трафіку і потім відключається, подивіться на поведінку відлуння 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, налаштування відлуння для тунелю, що вмирає за розкладом.