SSTP кліент SSTP прымае сервер толькі пасля паспяховай праверкі TLS, і гэтая праверка параўноўвае імя, ланцужок і прызначэнне. Імя бярэцца з профілю злучэння, а не з адраса, які вы выпадкова можаце пінгаваць. Калі адзін з трох не супадае, кліент паведамляе пра праблему сертыфіката і ніколі не даходзіць да запрашэння ўваходу.

Імя ў профілі вызначае, што менавіта правяраецца

SSTP запускае TLS па TCP 443, таму кліент паводзіць сябе як любы іншы TLS-кліент: бярэ імя хоста з профілю, запытвае гэтае імя і параўноўвае сертыфікат з ім. Калі ўвесці ў профіль IP-адрас, параўнанне становіцца параўнаннем IP-адрасоў, якому большасць сертыфікатаў сервера не адпавядае.

Таму тэст у браўзеры можа прайсці, хоць VPN не працуе, бо браўзер ужыў іншае імя, чым профіль. Такое ж раздваенне ўзнікае, калі split-horizon DNS пераводзіць імя хоста VPN ва ўнутраны адрас, а браўзер дабраўся да публічнага. Спачатку прывядзіце профіль у адпаведнасць з дакументаваным імем хоста, потым параўноўвайце сертыфікаты. Усё астатняе, што вы зменіце да гэтага, — здагадкі.

Што павінен змяшчаць сертыфікат сервера

Сучасныя кліенты супастаўляюць з пашырэннем альтэрнатыўных імён суб'екта, таму імя хоста павінна быць там як запіс DNS. Адно агульнае імя недастаткова для сучасных стэкаў праверкі, а сімвал падстаноўкі пакрывае адну метку, а не любы субдамен, які вы прыдумаеце. Тры сертыфікаты паказваюць мяжу: правільнае імя з няправільным прызначэннем пацвярджае асобу і потым не праходзіць праверку прызначэння, правільныя імя і прызначэнне без прамежкавага сертыфіката не праходзяць ланцужок, а імя, якое ёсць толькі ў агульным імені, не праходзіць раней за любое з гэтых двух.

Сертыфікату таксама патрэбна прызначэнне аўтэнтыфікацыі сервера — пашыранае значэнне выкарыстання ключа, названае ў спецыфікацыі SSTP ад Microsoft, гэта значыць serverAuth з ідэнтыфікатарам аб'екта 1.3.6.1.5.5.7.3.1. Выкарыстанне ключа і сапраўдны ланцужок дапаўняюць набор. Сертыфікат, які ёсць на серверы, выдадзены на правільнае імя, але толькі для аўтэнтыфікацыі кліента, усё роўна не праходзіць.

Праверце ланцужок і гадзіннік да ўводу даных

Збоі часу і даверу даюць такі ж бачны вынік, як нясупадзенне імені, і абодва дэфекты дыягнаставаць танней, чым праблему з паролем. Праверце гадзіннік сервера і гадзіннік кліента, потым прачытайце ланцужок так, як яго бачыць кліент:

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

Першая каманда выводзіць імя, акно сапраўднасці і альтэрнатыўныя імёны, з якімі кліент будзе параўноўваць. Другая паведамляе пра памылкі праверкі разам з прадстаўленым ланцужком, і менавіта там выяўляецца адсутны прамежкавы сертыфікат. У Windows запыт службы часу кажа, ці гадзіннік выпраўляецца, ці проста сышоў.

Унутраная CA дадае яшчэ адну ўмову: кліент павінен давяраць гэтай CA. Усталюйце арганізацыйны корань праз зацверджаны канал распаўсюджвання, а не са старонкі, якая прапануе заменны сертыфікат, бо гэтае рашэнне і ёсць уся мадэль даверу ў мініяцюры.

Праверка сервера і аўтэнтыфікацыя карыстальніка — паслядоўныя этапы з рознымі адмовамі. Памылка сертыфіката азначае, што кліент ніколі не давяраў серверу, а адхілены пароль азначае, што ён давяраў серверу і даныя былі няправільныя. Адключэнне праверкі сертыфіката, каб дайсці да запыту пароля, прыбірае гарантыю замест таго, каб адрамантаваць яе. Каб даказаць, што астатні шлях працуе, праверце тое ж імя хоста і порт з кліента, які ўжо давярае ланцужку, і не чапайце разгорнуты профіль.

Выпраўце імя або сертыфікат і праверце зноў

Выпраўленне вызначаюць тры ўмовы. Калі імя ў профілі няправільнае, выпраўце профіль або дадайце адсутнае імя ў сертыфікат. Калі ланцужок няпоўны, усталюйце прамежкавы сертыфікат на серверы. Калі прызначэнне няправільнае, перавыдайце сертыфікат, а не абыходзьце гэта латкамі.

Пасля змены перападключыцеся падтрыманым кліентам і ўпэўніцеся, што з'явілася запрашэнне ўваходу, а потым што тунель падняўся. Запішыце ў тыкет імя хоста, эмітэнта і дату заканчэння. Менавіта гэты запіс робіць наступнае абнаўленне планаванай задачай, а не чарговым збоем, і паказвае наступнаму чалавеку, якая з трох умоў была сапраўды парушана.

Падобныя артыкулы