Порт 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 е начинът, по който петминутна проверка на сертификат се превръща в ден преинсталиране на софтуер.