TLS текшерүүчү проксинин артындагы SSTP: сессия кайда үзүлөт
Кадимки HTTPS тейлеген прокси да SSTPнин дуплекстик POSTун жана сертификаттар чынжырын буза алат. Баскычтарды басып өтүп, биринчи ийгиликсиз баскычты атаңыз.
Браузериңиз корпоративдик интранетти жүктөйт, прокси сертификаты ишенимдүү, бирок SSTP кардары туташуунун аягына жакын үзүлөт. Бул үлгү туура эмес сырсөздү эмес, веб-суроо менен туннелдик сессиянын айырмасын көрсөтөт. Туташууну TCPден жогору карай басып өтүп, биринчи ийгиликсиз баскычты белгилеңиз. Прокси себеппи экенин ката коду эмес, баскыч айтып берет.
Кардар токтогон жерден баштаңыз
Кардар белгиленген ырааттуулуктан өтөт: 443 портуна TCP туташуу, TLS кол алышуу, сертификатты текшерүү, SSTPнин HTTP алмашуусу, PPP сүйлөшүүсү жана аутентификация, андан кийин IP конфигурация. Ар бир баскычтагы ийгиликсиздик башка из калтырат, аларды аралаштыруу сизди туура эмес конфигурация барагына алып барат.
TCP ийгиликсиздиги — кандайдыр бир TLS байты пайда болгонго чейинки күтүү же кайра кошуу. TLS ийгиликсиздиги — эскертүү же кол алышуунун күтүү убактысы. Сертификат ийгиликсиздиги чынжыр же ат жөнүндө эскертүү берет. HTTP ийгиликсиздиги ийгиликтүү кол алышуудан кийин келет, көбүнчө статус коду же дароо жабылуу түрүндө. PPP ийгиликсиздиги туннель техникалык жактан орнотулгандан кийин келет, ошондуктан ал аутентификация маселесине окшош.
Биринчи ката сабын эмес, кардардын журналындагы акыркы ийгиликтүү баскычты окуңуз. Ката сабы адатта натыйжаны билдирет, ал эми баскычтын чеги баш тарткан компонентти атайт.
SSTP тармактан эмнени ташууну талап кылат
SSTP TCP 443тө TLS үстүндө иштейт, андан соң SSTP спецификациясында аныкталган SSTP_DUPLEX_POST аттуу HTTP суроосун /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сы же дененин өмүрү жөнүндө эч нерсе айтпайт, ошондуктан иштеп жаткан интранет баракчасын туннель жолуна колдоо бар деген далил деп эсептебеңиз.
Колдоого алынган жолду тандаңыз
Тармак ээсине бир так суроо бериңиз: прокси ушул шлюзга 443 портунда буферсиз дуплекстик POSTко уруксат береби? «Ооба» проксидеги өзгөчөлүккө же VPN хосту үчүн документтелген айланып өтүүгө алып барат. «Жок» текшерилген жол SSTPни ташый албайт дегенди билдирет, ал эми колдоого алынган оңдоо кардарды бурмалоо эмес, башка жол же протокол.
Варианттарга адатта VPN шлюзи үчүн текшерилбеген чыгуу, прокси аркылуу корпоративдик трафикти гана жөнөткөн бөлүнгөн туннель долбоору же уюм башка портто колдогон альтернативалык протокол кирет. Ар бири тармактын долбооруна таандык жана салыштыруу жолду бөлүп көрсөтүшү үчүн ар бирин бир эле түзмөк жана профиль менен сыноо керек.
Натыйжаны документтештириңиз: чыгаруучу, ийгиликсиз баскыч, прокси эрежеси жана тандалган жол. Кийинки адам ошол 98 пайыздык токтоп калууну көргөндө бүт жүрүштү кайталоонун ордуна бир фактыны текшере алат.