Порт у полі адреси VPN Windows працює лише з SSTP

VPN-сервер відповідає на TCP 10443, вбудований клієнт Windows має правильні облікові дані, але з’єднання все одно обривається після паузи, схожої на тайм-аут DNS. Причина зазвичай у полі адреси: якщо ввести vpn.example.com:10443 у поле Ім’я сервера або адреса, Windows читає весь рядок як ім’я хоста, бо це поле не є загальним введенням host:port. Чи можна взагалі виразити там порт, залежить від типу тунелю, який використовує профіль, і лише один із чотирьох типів трактує значення як щось, що він може розібрати.

Чому поле адреси не є полем host:port

Властивість профілю за цим полем — ServerAddress, і кожен тип тунелю сам вирішує, що робити з рядком. У трьох із них немає параметра порту, який треба заповнити, тому двокрапка й число — просто символи в імені, яке ніколи не розв’яжеться. Четвертий працює через HTTPS, де порт є частиною URL, тому значення потрібно записати у формі, яка розбирається як URL.

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

Три типи з фіксованим портом

PPTP підключається до TCP 1723, а потім несе тунель у GRE, протоколі IP 47. L2TP/IPsec використовує UDP 1701 для тунелю та UDP 500 плюс 4500 для IPsec, причому 4500 — це порт проходження NAT. IKEv2 також використовує UDP 500 і 4500. Жоден із цих профілів ніде в інтерфейсі не показує поле порту, і жоден не погоджуватиме нестандартний порт.

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

SSTP потребує URL, а не імені

SSTP — виняток, бо працює всередині сеансу TLS. Поле має розбиратися як URL: спочатку схема https://, потім хост, потім двокрапка й порт. Без схеми Windows продовжує вважати значення звичайним ім’ям, і з’єднання падає до будь-якого обміну TLS.

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

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress показує саме те, що було збережено. Якщо він читається як голе ім’я хоста з двокрапкою, профіль ніколи не отримував URL, і жодна кількість повторних спроб це не виправить.

Синтаксис виробника, який вставляють у те саме поле

Деякі шлюзи документують додаткові домовленості для цього поля, наприклад realm, доданий після порту, або параметри запиту, які змінюють обробку сертифікатів. Їх розуміє сервер цього виробника і в деяких збірках його власний клієнт. Вони не входять до формату профілю Windows, і їх вставлення у вбудований профіль зазвичай дає той самий тихий збій імені.

До параметра, який вимикає перевірку сертифікатів, ставтеся як до попередження, а не як до виправлення. Якщо профіль підключається лише з цим параметром, сертифікат не відповідає використовуваному імені, і правильне виправлення — на шлюзі, а не в клієнті. Realm після порту має ту саму властивість: він щось робить, лише якщо сервер на тому боці його очікує.

Доведіть порт, потім прочитайте збійний етап

Перш ніж звинувачувати профіль, підтвердьте, що щось приймає TCP на цьому порту з мережі клієнта:

Test-NetConnection vpn.example.com -Port 10443

Успіх доводить наявність слухача, а не SSTP. Веб-сервер, зворотний проксі або балансувальник навантаження можуть завершити рукостискання TCP і все одно не говорити SSTP, тому зелений тест із червоним VPN — реальна комбінація. Порівняйте суб’єкт сертифіката з ім’ям у профілі та перевірте журнал RasClient у збірках, де він є, бо він фіксує збійний етап замість загального тайм-ауту.

Потім розгляньте варіант, який усуває проблему, а не документує її: переадресуйте TCP 443 ззовні на 10443 на VPN-сервері. Тоді клієнт використовує профіль за замовчуванням взагалі без порту, що зазвичай є найчистішим рішенням для керованого парку та залишає нестандартний порт внутрішньою деталлю.