SSTP за праксі, якое правярае TLS: дзе сеанс абрываецца

Ваш браўзер адкрывае карпаратыўны інтранэт, сертыфікат праксі лічыцца давераным, а кліент SSTP усё роўна абрываецца бліжэй да канца злучэння. Гэтая карціна паказвае на розніцу паміж вэб-запытам і сеансам у тунэлі, а не на няправільны пароль. Прайдзіце злучэнне ад TCP уверх і адзначце першы этап, які не спрацоўвае. Менавіта этап, а не код памылкі, паказвае, ці прычына ў праксі.

Пачніце з таго месца, дзе спыняецца кліент

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

Збой TCP — гэта тайм-аўт або скід да таго, як з’явіцца хоць адзін байт TLS. Збой TLS — гэта папярэджанне або тайм-аўт рукапаціскання. Збой сертыфіката дае папярэджанне пра ланцужок або імя. Збой HTTP надыходзіць пасля паспяховага рукапаціскання, часта як код стану або імгненнае закрыццё. Збой PPP надыходзіць пасля таго, як тунэль тэхнічна ўсталяваны, таму ён выглядае як праблема аўтэнтыфікацыі.

Чытайце журнал кліента ў пошуку апошняга паспяховага этапу, а не першага радка памылкі. Радок памылкі звычайна паведамляе пра наступства, а мяжа этапу называе кампанент, які адмовіў.

Што SSTP патрабуе ад сеткі

SSTP працуе праз TLS на TCP 443 і затым адпраўляе HTTP-запыт SSTP_DUPLEX_POST, вызначаны ў спецыфікацыі SSTP, на шлях выгляду /sra_{GUID}/. Запыт абвяшчае практычна неабмежаваную даўжыню змесціва і трымае паток адкрытым у абодвух кірунках на працягу ўсяго сеансу. Кадры PPP перамяшчаюцца ўнутры гэтага патоку.

Вось чаму праксі, якое абслугоўвае звычайнае вэб-агляданне, можа ўсё роўна не спрацаваць. GET або POST з канечным целам можна буфераваць, правяраць і перасылаць; дуплексны паток з целам, якое ніколі не сканчаецца, — не. Праксі, якое чакае завяршэння цела, чакае вечна, і кліент у рэшце рэшт атрымлівае тайм-аўт.

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

Чаму праверка змяняе ідэнтычнасць

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

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

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

Вызначце эмітэнта перад змяненнем налад

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

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

Тэст браўзера да таго ж хоста даказвае толькі тое, што праксі прымае GET. Ён нічога не кажа пра метад SSTP, URI запыту або час жыцця цела, таму не лічыце працоўную старонку інтранэта доказам падтрымкі шляху тунэля.

Выберыце падтрыманы шлях

Задайце ўладальніку сеткі адно канкрэтнае пытанне: ці дазваляе праксі небуфераваны дуплексны POST да гэтага шлюза на порце 443? «Так» вядзе да выключэння ў праксі або дакументаванага абыходу для хоста VPN. «Не» азначае, што правераны шлях не можа несці SSTP, і падтрыманы рамонт — гэта іншы шлях або пратакол, а не праўка кліента.

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

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