Немає PPTP passthrough: виправлення помилки 807 у Windows VPN

Пересилання TCP 1723 часто очищає лише першу частину PPTP і залишає решту зламаною, тому Windows під час спроби все ще повертає помилку 807. Наступний інстинкт — додати правило для порту 47, і саме цей крок витрачає півдня: GRE — це номер протоколу в заголовку IP, а не порт, який може зіставити таблиця пересилання. Доки маршрутизатор не пропустить протокол 47 і не прив'яже його до того самого виклику, тунель не може початися. Наведені нижче розділи розділяють два канали, а потім перевіряють їх по одному.

У таблиці портів немає рядка для номера протоколу

PPTP використовує дві розмови, які зазнають невдачі по-різному. Та, що на TCP 1723, починає виклик, передає інформацію про з'єднання і розриває його, коли користувач від'єднується. Бік корисного навантаження працює всередині GRE, який заголовок IP позначає номером протоколу 47, і всередині цього тунелю PPP узгоджує з'єднання, поки MS-CHAPv2 перевіряє облікові дані.

Оскільки GRE не несе заголовка транспорту, він не відкриває жодних портів, тому правило, написане для портів, не має з чим зіставлятися. Маршрутизатор, що пересилає 1723, створює відображення для цього сеансу TCP і на цьому зупиняється. Мікропрограма, яка обробляє другу половину, називає цю функцію PPTP passthrough або PPTP ALG, а деякі мікропрограми не пропонують ні того, ні іншого і взагалі не згадують цю прогалину. Напис на прапорці важливий менше, ніж те, чи взагалі розпізнається протокол 47.

Що Windows повідомляє, коли шлях даних помирає

Помилка 807 каже, що з'єднання не вдалося завершити, що на практиці означає: виклик дійшов до сервера, а канал даних не піднявся. Це вердикт про транспорт, а не про обліковий запис. Помилка 691 — це та, що вказує на облікові дані або на невідповідність протоколу автентифікації, тому вона відправляє вас зовсім в інше місце.

Працюйте з транспортом, перш ніж торкатися пароля. Зміна облікових даних у гонитві за 807 залишає справжню несправність на місці й робить наступну спробу важчою для читання.

Чому другий клієнт ламає робочий тунель

Без портів, які б їх розрізняли, пристрій NAT не може розділити двох клієнтів PPTP так, як він розділяє два сеанси HTTPS. Тому багато споживчих пристроїв дозволяють один виклик PPTP і відстежують його за вихідною адресою. Ноутбук, який працював сам, перестає завершувати з'єднання, коли лунає виклик другої машини, а з боку клієнта збій виглядає випадковим. Ця закономірність належить мікропрограмі, і жодна зміна профілю її не змінить.

Спостерігайте за таблицею з'єднань, поки обидва клієнти викликають. Якщо відображення завжди має лише перший хост, маршрутизатор досяг межі того, що підтримує, і жодне налаштування на боці клієнта цього не змінить.

Доведіть, яка половина зазнає невдачі

Підтвердьте, що TCP 1723 надходить, перш ніж щось змінювати на маршрутизаторі, бо ця відповідь визначає, яку половину ви перевіряєте. Запустіть їх із клієнта Windows проти власного імені сервера. Перша виводить, чи відповів порт, а друга викликає без діалогу, що робить повторні спроби порівнюваними.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Правдивий результат тесту порту означає, що канал керування відкритий, а GRE — підозрюваний, що залишився. Хибний результат означає, що маршрутизація, фільтр або пересилання зламані, і жодна зміна GRE це не врятує. За боком даних треба стежити там, де його видно, на боці сервера або на маршрутизаторі.

tcpdump -ni any proto 47

Відповідник у Wireshark — це фільтр відображення ip proto 47, який легше передати тому, кому незручно в оболонці. GRE, що надходить, коли у відповідь нічого не виходить, означає, що зворотний шлях треба виправити.

Що насправді виправляє помилку

Там, де маршрутизатор відкриває налаштування, увімкніть PPTP passthrough або на мікропрограмі, що приймає правила, явно дозвольте протокол 47. На RouterOS правило forward зіставляє протокол безпосередньо, чого пересилання на основі портів ніколи не могло зробити. Споживча мікропрограма зазвичай ховає те саме рішення за прапорцем, іноді в налаштуваннях безпеки, а не в пересиланні портів. Якщо такого контролю немає, ніщо на боці клієнта це не компенсує.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

Заміна PPTP — інший варіант і часто дешевший. Маршрутизатор, який сам завершує VPN, уникає подвійного NAT для вхідних клієнтів, а протокол, який NAT на основі портів уже обробляє, зовсім не потребує passthrough: OpenVPN через UDP, SSTP через TCP 443 або L2TP/IPsec із NAT-T, що загортає ESP в UDP 4500. PPTP також залежить від MS-CHAPv2, чиї задокументовані слабкості роблять його поганим вибором для нового розгортання навіть після зникнення помилки.

Запишіть, яке правило дало різницю, бо той самий майданчик зустріне ту саму межу, коли другий користувач попросить доступ. Виправлення на рівні протоколу належить до мережевих нотаток, де його шукатиме наступний інженер.