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

Пачніце са знешняга носьбіта

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

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

Ідзіце за інкапсуляцыяй унутр

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

Адзін перахоп рэдка паказвае ўвесь стэк. Знешнія загалоўкі бачныя толькі звонку ад канчатковага пункта, а ўнутраныя — толькі пасля дэкапсуляцыі. Гэтая асіметрыя паходзіць з таго, дзе вы стаіце, а не з пратакола.

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

outer IP header
  TCP to port 443
    TLS record layer
      SSTP control and data packets
        PPP frames
          inner IP packet
            application transport and payload

Пазначце назіральніка, перш чым чытаць перахоп

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

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

Захавайце праверкі, якія схема не можа даказаць

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

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

openssl s_client -connect vpn.corp.internal:443 -servername vpn.corp.internal
tshark -r sstp.pcap -Y "tls.handshake.type == 1"

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