SSTP-ի ժամանակի սպառում կամ վկայագրի սխալ՝ ինչպես տարբերակել դրանք

SSTP կապը ձախողվում է երկու եղանակով, որոնք օգտագործողի աթոռից նույնն են թվում, և յուրաքանչյուրի վերանորոգումը գտնվում է տարբեր շերտում։ Ժամանակի սպառումը նշանակում է, որ պահանջվող փոխանակումը երբեք չավարտվեց՝ վկայագրի սխալը նշանակում է, որ ինքնության նյութը հասավ և մերժվեց։ Երկրորդը առաջինի պես դիտելը ձեզ տանում է դեպի հրդեպատեր և գաղտնաբառեր, որոնք երբեք խնդիրը չեն եղել։ Տարբերակող ապացույցը հենց հաճախորդի մատյանում է, եթե կարդաք այն նախքան որևէ բան փոխելը։

Երկու ձախողում, երկու տարբեր փոխանակում

SSTP-ն թունել է տանում HTTPS-ի ձև ունեցող նստաշրջանի ներսում, դրա համար այն դիմանում է ցանցերում, որոնք բացի 443-ից ոչինչ չեն թույլատրում։ Հաճախորդը ավարտում է TLS ձեռքսեղմումը, ուղարկում է HTTP հարցում արձանագրությանը հատուկ մեթոդով, և ապա թունելն աշխատում է այդ հոսքի ներսում։ Այդ քայլերից որևէ մեկում ձախողումը կանգնեցնում է կապը, և միայն վերջիններն են առնչվում մուտքի տվյալներին։

Այդ հերթականությունը հենց ախտորոշումն է։ Եթե TLS ձեռքսեղմումը երբեք չի ավարտվում, ոչ մի մուտքի տվյալ չի ուղարկվել, ուստի գաղտնաբառի վերակայումը չի կարող օգնել։ Եթե ձեռքսեղմումն ավարտվում է և ապա կանգ է առնում, ինքնությունը ընդունվել է, և հարցման ուղու ինչ-որ բան այն մերժել է։ Եթե ձեռքսեղմումը ձախողվում է վավերացման հաղորդագրությամբ, սերվերը պատասխանել է, և հաճախորդին դուր չի եկել լսածը։ Երեք արդյունք, երեք շերտ։

Մատյանի տողը սովորաբար ասում է, թե երեքի որում եք գտնվում, դրա համար այն արժե գրանցել առաջին փոփոխությունից առաջ։

Ժամանակի սպառումը նշանակում է, որ փուլը երբեք չավարտվեց

Սկսեք անվան լուծումից և TCP հասանելիությունից, որովհետև այնտեղի ժամանակի սպառումը նույնն է թվում, ինչ ավելի ուշ։ Նավահանգստի ստուգիչը, որը 443-ը բաց է հաղորդում, ապացուցում է միայն, որ լսողը ընդունել է կապը, և ոչ ավելին։

Հաջորդ կասկածյալը ուղին է, ոչ թե հոսթը։ Պրոքսիները և ծրագրերին ծանոթ հրդեպատերը երբեմն մերժում են այն հարցման մեթոդը, որը SSTP-ն օգտագործում է, կամ գցում են ժամերով բաց մնացող հոսք, և երկու վարքագիծն էլ հաճախորդի կողմից ժամանակի սպառում է թվում։ Նույն հոսթի մատուցած սովորական HTTPS էջը կատարյալ բեռնվում է, մինչդեռ թունելի մեթոդը մերժվում է, դրա համար վերջնակետին զննարկելը շատ քիչ բան է ապացուցում։ Փորձարկեք առանց պրոքսի ցանցից՝ այդ երկու դեպքերն առանձնացնելու համար։

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

Ժամանակի սպառումը մինչև զույգի որևէ պատասխան ոչինչ չի ասում հաշվի մասին, և այդ պահին գաղտնաբառը փոխելը միայն ավելացնում է փոփոխական։

Վկայագրի սխալը նշանակում է, որ ինքնությունը մերժվել է

Այստեղ սերվերը իսկապես պատասխանել է, ուստի ցանցը աշխատում է, և հարցը տեղափոխվում է ինքնությանը։ Համեմատեք այն անունը, որով հաճախորդը հավաքում է, այն անունների հետ, որոնք վկայագիրն իրականում պնդում է, ապա ստուգեք վավերականության ամսաթվերն ու թողարկող շղթան։

Մասնավոր CA-ն, որին հաճախորդը չի վստահում, առաջացնում է նույն դասի սխալ, ինչ ժամկետանց վկայագիրը, և այդպես է նաև ժամերով սխալ ընթացող ժամացույցը։ Հում հասցեին հավաքելը ստեղծում է նոր անհամապատասխանություն, որովհետև վկայագիրը պնդում է անուններ, ոչ թե հասցեներ։ Կառավարվող տեղակայումում ստացեք նախատեսված վստահության կարգավորումը դրա ադմինիստրատորից՝ սխալի էջի առաջարկած փոխարինող արմատն ընդունելու փոխարեն։ Վավերացումը մնում է միացված, քանի դեռ շտկում եք պատճառը։

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Պահեք հաջող TLS փուլը անփոփոխ այն անցնելուց հետո, որովհետև այն ավելի ուշ հետ շրջելը թաքցնում է, թե որ փոփոխությունն է իրականում շտկել թունելը։

Որտեղ են երկուսը շփոթվում

Երկու ձախողումներն էլ երևում են որպես կապ, որը չի բարձրանում, և երկուսն էլ գալիս են այն բանից հետո, երբ օգտագործողը փոխել է ինչ-որ անկապ բան։ Հենց այդ զուգադիպությունն է սխալ վերանորոգումը որոշ ժամանակ հավանական դարձնում։

Երկու սովորություն դրանք առանձին են պահում։ Գրանցեք հաճախորդի մատյանը նախքան կարգավորումներին դիպչելը, որպեսզի առաջին վիճակը պահպանվի։ Փոխեք մեկ շերտ յուրաքանչյուր փորձի համար, որպեսզի հաջորդ արդյունքը պատկանի հայտնի փոփոխականի։ Նավահանգստի ստուգիչը և զննարկիչը մասնակի դիտարկումներ են, ոչ թե ամբողջ հաջորդականությունը, և ոչ մեկը չի փոխարինում հաճախորդի սեփական զեկույցին։ Սովորություններից ոչ մեկը ոչինչ չարժե, և երկուսն էլ կրճատում են հետաքննությունը։

Վկայագրի հարցը և հասանելիության հարցը առանձին են փաստաթղթավորված ինչ-որ պատճառով։

Կրկին փորձարկեք իրական հաճախորդով, ապա շարժվեք ներս

Երբ կոնկրետ ուղղումը տեղում է, կրկին փորձեք իրական SSTP հաճախորդով և իսկական պրոֆիլով, ոչ թե զննարկիչի ներդիրով։

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

Եթե նստաշրջանը միանում է, և ռեսուրսները դեռ ձախողվում են, թունելն այլևս կասկածյալ չէ՝ անցեք երթուղավորությանը, DNS-ին և ծառայությունների հասանելիությանը։ Դա այլ հետաքննություն է այլ ապացույցներով։ Աշխատող TLS և նույնականացման փուլերը պահելը թույլ չի տալիս, որ այն դառնա առաջինի կրկնություն։ Գրեք տոմսում այն փուլը, որը ձախողվել է, այլապես հաջորդ մարդը նորից կսկսի վերևից։