SSTP прво го автентификува серверот, а потоа корисникот

SSTP клиент може да го заврши TLS и сепак да го одбие корисникот една секунда подоцна. Таа низа не е грешка, тоа е протоколскиот стек: прво безбедност на транспортот, потоа автентикација на корисникот. Бидејќи двете фази не успеваат со различни пораки, потребни им се и различни поправки. Читањето која фаза ја создала грешката е најголемиот дел од дијагнозата.

Доверлив сертификат ја докажува крајната точка; за сметката не кажува ништо.

Што утврдува TLS ракувањето

Клиентот го проверува сертификатот што го презентира серверот против своето доверливо складиште, бараното име на хост, прозорецот на важност и секоја дополнителна политика што ја применува платформата. Тоа го штити поврзувањето со предвидената крајна точка. Но не докажува дека одредена сметка е овозможена, не е истечена или е дозволена за далечински пристап. Тоа се одделни прашања што подоцна ги поставува друга компонента.

Затоа отстранувањето на проверките на сертификатот за да се стигне до поканата за најава е погрешна поправка. Добивате покана за најава на врска што не можете да ја проверите. Грешка со сертификатот припаѓа на името на хостот, часовникот, синџирот или конфигурацијата за доверба.

Што додаваат SSTP и PPP одозгора

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

Затоа одбивањето на корисникот може да значи акредитиви, ограничување на сметката или несовпаѓање на методот.

Причината на страната на серверот е далеку покорисна од ресетирање на секоја тајна во профилот. Настанот за оневозможена сметка и неуспехот на преговорите за метод изгледаат слично кај клиентот и немаат ништо заедничко кај серверот.

Поврзете ја грешката со фазата

Проверете дали врската стигнува до TLS, потоа до SSTP HTTP размената, потоа до PPP фазата. Држете ги временските ознаки во дневниците порамнети помеѓу обидите за да не се помеша претходен неуспех со подоцнешен успех. Клиент што евидентира два обиди во еден прозорец инаку ќе изгледа како да не успеал во последната достигната фаза. Читајте ја првата релевантна грешка, не последниот ред.

Истото порамнување е важно на страната на серверот, каде записот за автентикација и дневникот на транспортот често се одделни датотеки со одделни часовници. Две минути отстапување се доволни за очигледна причина да изгледа невозможна.

По најавата, авторизацијата останува одделна

Успешната најава не доделува секој приватен ресурс. Рутите одредуваат што е достапно, DNS одредува што се решава, и секоја услуга сепак ги применува сопствените дозволи. Сесијата прикажана како поврзана е изјава за тунелот, а не за споделувањето датотеки. Кога корисникот може да се поврзе, а не може да достигне еден хост, фазата на тунелот е веќе завршена.

Тоа е истото раслојување што го покажа ракувањето, едно ниво погоре.

Задржете го обновувањето на сметката во поддржаниот процес на операторот наместо да менувате поставки за транспорт како одговор на експлицитно одбивање од корисникот. Менувањето на транспортот за да се поправи оневозможена сметка е вид поправка што изгледа дека работи кога сметката повторно се овозможува од неврзана причина.