SSTP удостоверява първо сървъра, а после потребителя

SSTP клиент може да завърши TLS и въпреки това да отхвърли потребителя секунда по-късно. Тази последователност не е дефект, а протоколният стек: първо транспортна сигурност, после удостоверяване на потребителя. Понеже двата етапа се провалят с различни съобщения, те се нуждаят и от различни поправки. Прочитането кой етап е произвел грешката е по-голямата част от диагностиката.

Доверен сертификат доказва крайната точка; за акаунта не казва нищо.

Какво установява TLS ръкостискането

Клиентът проверява представения от сървъра сертификат спрямо своето хранилище за доверие, заявеното име на хост, прозореца на валидност и всяка допълнителна политика, която платформата прилага. Това защитава връзката към предвидената крайна точка. Но не доказва, че конкретен акаунт е включен, неизтекъл или има право на отдалечен достъп. Това са отделни въпроси, задавани по-късно от друг компонент.

Затова премахването на проверките на сертификата, за да се стигне до екрана за вход, е грешната поправка. Получавате екран за вход върху връзка, която не можете да проверите. Грешка в сертификата принадлежи на името на хоста, часовника, веригата или конфигурацията за доверие.

Какво добавят SSTP и PPP отгоре

SSTP работи през HTTPS и носи PPP вътре в себе си, със свой собствен контролен обмен около връзката. След това PPP изпълнява своите фази на свързване и удостоверяване, а методът за удостоверяване зависи от политиката на сървъра и възможностите на клиента. PAP, CHAP, MS-CHAPv2 и EAP са все опции за удостоверяване в PPP с много различни свойства. Проверката на потребителя във VPN е именно тази PPP фаза, а не слоят TLS под нея.

Затова отхвърлянето на потребител може да означава идентификационни данни, ограничение на акаунта или несъответствие на метода.

Причината от страна на сървъра е много по-полезна от нулирането на всяка тайна в профила. Събитие за изключен акаунт и неуспех при договаряне на метод изглеждат сходно при клиента и нямат нищо общо при сървъра.

Съпоставете грешката с етапа

Проверете дали връзката стига до TLS, после до SSTP HTTP обмена, после до PPP фазата. Дръжте времевите марки в журналите подравнени между опитите, за да не се бърка по-ранен провал с по-късен успех. Клиент, който записва два опита в един прозорец, иначе ще изглежда, че се е провалил на последния достигнат етап. Четете първата значима грешка, а не последния ред.

Същото подравняване е важно от страна на сървъра, където записът за удостоверяване и транспортният журнал често са отделни файлове с отделни часовници. Две минути разминаване са достатъчни, за да изглежда очевидна причина невъзможна.

След входа оторизацията пак е отделна

Успешният вход не дава достъп до всеки частен ресурс. Маршрутите определят какво е достижимо, DNS определя какво се резолвва, и всяка услуга пак прилага собствените си разрешения. Сесия, показана като свързана, е твърдение за тунела, а не за файловото споделяне. Когато потребител може да се свърже и не може да достигне един хост, тунелната фаза вече е приключила.

Това е същото разслояване, което показа ръкостискането, с едно ниво по-нагоре.

Дръжте възстановяването на акаунта в рамките на поддържания от оператора процес, вместо да променяте транспортните настройки в отговор на явен отказ от потребителя. Промяната на транспорта, за да поправите изключен акаунт, е вид поправка, която изглежда работи, когато акаунтът бъде включен отново по несвързана причина.