Порт 443 відповідає, а SSTP все одно не працює: який етап зламався?

Завершення TCP-рукостискання з портом 443, коли тунель так і не будується, доводить одну річ, і це дрібниця. Щось слухає і готове прийняти з'єднання на цій адресі. Це не визначає службу, сертифікат, який буде пред'явлено, і те, що станеться після перших байтів.

Між цим рукостисканням і робочим тунелем стоять чотири етапи, і кожен дає різну помилку.

Відкритий порт описує лише один рівень

Прийняти TCP-з'єднання означає, що процес володіє сокетом, а шлях дозволяє рукостискання. Це нічого не говорить про те, чи є процес сервером SSTP, чи має він сертифікат, дійсний для імені у вашому профілі, і чи авторизує він ваш обліковий запис. Веб-сервер на тій самій адресі бездоганно відповідає на рукостискання, а потім відповідає на ваш запит SSTP помилкою HTTP. Усе вище цього рукостискання залишається неперевіреним.

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

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

Відокремте чотири етапи доказами

Етапи — це доступність транспорту, перевірка TLS, обмін SSTP через HTTPS і автентифікація PPP усередині тунелю. Шляху, який проходить перший і відмовляє на четвертому, потрібне виправлення облікових даних; тому, що відмовляє на другому, потрібне виправлення сертифіката або імені. Ці виправлення не мають нічого спільного, і вибір неправильного марнує простій.

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

Третю команду варто прочитати уважно. Відповідь 200 від звичайної веб-сторінки каже, що веб-служба існує; вона не каже, що запит SSTP буде зрозумілий. Відповідь 404 з тієї ж адреси так само малоінформативна щодо VPN. Лише журнал клієнта повідомляє, якого з чотирьох етапів досягнуто.

Зверніть увагу, яке ім'я використала кожна команда. Сертифікат вибирається за іменем, яке ви надсилаєте, тому розбіжність між профілем і тестом — це розбіжність, яку внесли ви самі. Запис цього імені поруч із результатом запобігає плутанині згодом.

Читайте частковий успіх у правильному напрямку

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

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

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

Потім перевірте застосунок, а не лише сеанс

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

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