FakeTLS. ինչպես է պրոքսին կայք ձևացնում
Ինչ է նշանակում ee նախածանցը secret-ում և ինչու է քողարկման տիրույթի ընտրությունից կախված՝ պրոքսին կդիմանա մինչև երեկո, թե ոչ։
Բովանդակություն
FakeTLS-ը MTProto պրոքսիի ռեժիմ է, որում կապը թվում է HTTPS կայք սովորական այցելություն։ Այն միացնում է secret-ի մեկ մանրուք՝ ee նախածանցը։ Ստորև՝ ինչ կա այդ նախածանցի հետևում, ինչպես է անցնում ձեռքսեղմումը, ինչպես ընտրել քողարկման տիրույթ և ինչ սխալներ են ամենից հաճախ կոտրում ռեժիմը։
Ինչ է նշանակում ee նախածանցը
Պրոքսիի secret-ը հղման վերջին պարամետրն է։ Եթե այն սկսվում է ee-ով, պրոքսին աշխատում է FakeTLS ռեժիմով։ Հետո գալիս են բանալու 16 բայթը (32 տասնվեցական նիշ), իսկ վերջում՝ hex տեսքով գրված քողարկման տիրույթը։[1]
[1] «ee + բանալի + տիրույթ» գրառումը համընկնում է mtg-ի փաստաթղթերի օրինակի հետ՝ google.com-ի secret-ը։
Օրինակ mtg-ի փաստաթղթերից՝ google.com-ի secret-ը՝
ee473ce5d4958eb5f968c87680a23854a0676f6f676c652e636f6d
Առաջին երկու նիշը ռեժիմն է, հաջորդ 32-ը՝ բանալին, մնացածը՝ google.com բառը բայթերով։ Տիրույթը կարդացվում է մեկ հրամանով՝
echo 676f6f676c652e636f6d | xxd -r -p
Ինչպես է անցնում ձեռքսեղմումը
HTTPS կայքի հետ սովորական կապը սկսվում է ClientHello հաղորդագրությամբ, որում հաճախորդը SNI դաշտում նշում է անհրաժեշտ կայքը։ FakeTLS-ը կրկնում է այս տեսքը, ուստի ֆիլտրի համար առաջին փաթեթները թվում են կայք սովորական մուտք։
- Հաճախորդն ուղարկում է ClientHello secret-ի տիրույթով։ Դրա մեջ կան տվյալներ, որոնցով պրոքսին ճանաչում է «իր» հաճախորդին։
- Պրոքսին ստուգում է դրանք և պատասխանում է այնպես, ինչպես կպատասխաներ TLS սերվերը։
- Հետո հաստատված կապով գնում է սովորական MTProto հոսք՝ փաթեթավորված TLS-ին նման գրառումներում։
- Եթե եկել է ոչ թե պրոքսիի հաճախորդ, այլ պատահական այցելու, սկաներ կամ ստուգող, պրոքսին իրեն չի բացահայտում. կապը փոխանցում է իսկական կայքին և վերադարձնում է նրա իրական պատասխանը։
Վերջին կետը ակտիվ ստուգումից պաշտպանությունն է։ mtg-ն սա կոչում է domain fronting. եթե հարցումը մերժված է, պրոքսին միանում է քողարկող կայքին և փոխանցում է տրաֆիկը, ուստի ստուգողը տեսնում է իսկական կայքի պատասխանը։ Telemt-ը նույնն անում է mask կարգավորմամբ. չճանաչված կապերը գնում են իրական վեբ սերվերին։
Ինչ է տեսնում ֆիլտրը
TSPU սարքավորման և DPI համակարգերի համար FakeTLS կապը սա է՝
- կապ ձեր սերվերի IP հասցեի հետ՝ 443 պորտով;
- ClientHello՝ հանրահայտ կայքի անունով SNI-ում;
- TLS սերվերի պատասխանին նման պատասխան;
- հետո՝ գաղտնագրված գրառումների հոսք, ինչպես ցանկացած HTTPS-ում։
Այդպիսի կապն իսկականից տարբերելու համար ֆիլտրը պետք է փնտրի նուրբ անհամապատասխանություններ. տիրույթի և IP հասցեի չհամապատասխանությունը, ClientHello-ի ոչ բնորոշ ընդլայնումները, հոսքի վիճակագրությունը։ Իսկ պարզապես փակել «այն ամենը, ինչ նման է հանրահայտ կայքի հետ HTTPS-ի», չի լինում՝ առանց սովորական օգտատերերին վնասելու։
Ինչպես ընտրել քողարկման տիրույթ
Տիրույթը ռեժիմի թույլ տեղն է։ Դրանից է կախված՝ մատակարարը կնկատի անհամապատասխանությունը, թե ոչ։ Իրականացումների հեղինակների խորհուրդներից կազմվում է հետևյալ ցանկը՝
- սովորական կայք, որը ձեր ցանցում արգելափակված չէ։ Եթե տիրույթը օպերատորի մոտ անհասանելի է, դրա հետ կապը կասկածելի է թվում, և հղումը կարող է չաշխատել (telemt-ի խորհուրդ);
- սերվերի հասցեի հետ կապված տիրույթ։ mtg-ի README-ն զգուշացնում է. մատակարարները կարող են նկատել, որ
google.com-ը տանում է այնպիսի IP, որը Google-ին չի պատկանում։ Խորհուրդը՝ ընտրել այն հոսթինգի տիրույթը, որտեղ կանգնած է VPS-ը (օրինակ՝digitalocean.comDigitalOcean-ի սերվերի համար); - լավագույնը՝ սեփական տիրույթը։ mtg-ի BEST_PRACTICES-ում խորհուրդ է տրվում գրանցել տիրույթ և ուղղել այն VPS-ին. այդ դեպքում DNS-ը և SNI-ն համընկնում են, և ստուգումը անհամապատասխանություն չի գտնում;
- չպատճենել կայք սեփական ենթացանցից։ Նույն խորհուրդների համաձայն՝ DNS-ով այդպիսի ստուգումը պարզ է, իսկ հասցեն կարելի է արգելափակել;
- խոշոր բրենդ չվերցնել։ Խոշոր կայքը հեշտ է ստուգել DNS-ով. պատասխանները չեն համընկնի ձեր սերվերի հետ։
Կարևոր է
Եթե վստահ չեք, mtg-ի README-ն խորհուրդ է տալիս լրացուցիչ կարգավորումները չփոխել. «եթե վստահ չեք, ոչինչ մի դիպչեք»։
Ինչպես ստուգել ընտրված տիրույթը
Տիրույթը secret-ի մեջ ներդնելուց առաջ ստուգեք այն այնպես, ինչպես կանի մատակարարը՝
- Տիրույթը բացվում է ձեր ցանցից։ Եթե օպերատորի մոտ այն անհասանելի է, դրա հետ կապը տարօրինակ է թվում.
curl -I https://տիրույթ/-ը պետք է պատասխան վերադարձնի։ - Ձեռքսեղմումն անցնում է ձեր հասցեի վրա։
curl -v -I --resolve տիրույթ:443:IP https://տիրույթ/հրամանը հարցումը ստիպողաբար ուղղում է անհրաժեշտ IP հասցեին և ցույց է տալիս TLS ձեռքսեղմումը, վստահության շղթան և վկայականի գործողության ժամկետը։ - Վկայականը վավեր է։ telemt-ի FAQ-ում որպես օրինակ նշված է վկայական, որի ժամկետը լրացել է 2026 թվականի մարտի 1-ին, և նշված է, որ կայքի արդիականությունը պետք է ստուգել առանձին։
- DNS-ը համընկնում է սերվերի հասցեի հետ։ Իդեալական է, եթե անունը մատնանշում է հենց ձեր VPS-ը. ամենավատ տարբերակը օտար խոշոր կայքն է։
Ստուգումը արժե կրկնել. կայքերը փոխում են վկայականներն ու հասցեները, և այսօր հավանական թվացող տիրույթը մեկ ամիս անց կարող է դադարել բացվել։
Օրինակ. տիրույթի նախապատրաստումը քայլ առ քայլ
Սխեման, որ խորհուրդ են տալիս mtg-ի BEST_PRACTICES-ում, հանգում է նրան, որ այն ամենը, ինչ կարող է ստուգել մատակարարը, իրար հետ համընկնի՝
- Գրանցեք սեփական տիրույթ և A գրառմամբ ուղղեք այն VPS-ի IP հասցեին։ Այժմ այդ անվան DNS պատասխանը մատնանշում է ձեր սերվերը։
- Պրոքսիի առջև դրեք հավանական կայք. մի քանի սովորական HTML էջ և Let's Encrypt-ի կամ այլ սերտիֆիկացման կենտրոնի վկայական։
- Ստեղծեք այդ տիրույթի secret-ը՝
mtg generate-secret --hex ձեր-տիրույթ.example։ - Գործարկեք պրոքսին 443 պորտով։ Սովորական այցելուներն ու ստուգողները կտեսնեն կայքը, իսկ հղմամբ հաճախորդները՝ պրոքսին։
- Ստուգեք կապը հեռախոսից շարժական ինտերնետով, ոչ թե տնային Wi‑Fi-ով։
Սա ավելի բարդ է, քան օտար հանրահայտ տիրույթ վերցնելը, բայց վերանում է կասկածի հիմնական առիթը. SNI-ի անունը, DNS պատասխանը և էջի բովանդակությունը համընկնում են։
Քողարկման կարգավորումները իրականացումներում
Ծրագրերը երկու խնդիրը լուծում են տարբեր կերպ՝ ինչպես պատասխանել օտարներին և ինչպես թվալ հավանական։
- mtg։ Օտար հարցումները վերաուղղվում են քողարկող կայքին (domain fronting)։ Բացի այդ կա «կրկնակ» ռեժիմ՝
[defense.doppelganger]բաժինը, որը կրկնում է իսկական կայքի ժամանակային բնութագրերը։ README-ի համաձայն՝ կրկնակի հասցեները պետք է վերցնել հենց այն տիրույթից, որի տակ քողարկվում եք։ - telemt։
[censorship]բաժնում սահմանվում ենtls_domain,mask = true(չճանաչված կապերը փոխանցել իրական վեբ սերվերին) ևtls_emulation = true։ Եթե հաճախորդը գալիս է հին տիրույթով, վարքագիծը որոշում էunknown_sni_actionպարամետրը։
Հաճախորդի մատնահետքը
Ցանկացած հաճախորդի՝ զննարկչի կամ Telegram-ի ClientHello-ն պարունակում է պարամետրերի հավաքածու. աջակցվող ծածկագրերի ցանկ, ընդլայնումներ և դրանց հերթականությունը։ Միասին դրանք կազմում են «մատնահետք». տարբեր ծրագրերի մոտ այն տարբեր է։ Եթե Telegram-ի ուղարկած ClientHello-ն նկատելիորեն տարբերվում է զննարկչայինից, ֆիլտրը կարող է դա օգտագործել որպես հատկանիշ։
Ուստի, ըստ telemt-ի FAQ-ի, քողարկման կայունությունը կախված է հաճախորդի տարբերակից, և մշակողները խորհուրդ են տալիս թարմացնել Telegram-ը. նոր տարբերակներում մատնահետքը ուղղված է։ Գործնականում դա նշանակում է, որ նույն հղումը ձեր մոտ կարող է աշխատել, իսկ հավելվածի հին տարբերակով ծանոթի մոտ՝ ոչ։
Բնորոշ սխալներ
- Secret-ը մուտքագրված է առանց ee-ի կամ կտրված։ Հաճախորդը միանում է այլ ռեժիմով կամ չի միանում։ Secret-ը մուտքագրում են ամբողջությամբ։
- Տիրույթը չի համապատասխանում սերվերին։ Ամենահաճախակի դեպքը՝ հանրահայտ բրենդ օտար հասցեի վրա։
- Ցանցում արգելափակված տիրույթ։ Պրոքսին կարծես աշխատում է, բայց կապը հաճախ կտրվում է։
- Տիրույթի փոփոխություն առանց հղումները վերաթողարկելու։ Հին հղումները սխալ են տալիս։ telemt-ում նման հաճախորդների համար կա
unknown_sni_actionկարգավորումը՝maskևreject_handshakeարժեքներով։ - Ոչ ստանդարտ պորտ։ 443 պորտը HTTPS-ի համար ավելի բնական է թվում։
- Հնացած հաճախորդ։ telemt-ի FAQ-ի համաձայն՝ Telegram-ի նոր տարբերակներում TLS մատնահետքն ուղղված է, ուստի հաճախորդը արժե թարմացնել։
Որտեղ է ռեժիմը դադարում աշխատել
FakeTLS-ը պրոքսին անտեսանելի չի դարձնում։ Telemt-ն իր FAQ-ում ուղիղ թվարկում է դեպքերը, երբ այն չի աշխատում՝
- նպատակային հոսթի հետ IP կապ չկա;
- արգելափակված են TCP-ն, TLS-ը, պորտը կամ SNI-ն;
- միացված է բարձր էնտրոպիայով տրաֆիկի ֆիլտրումը;
- DPI-ն FakeTLS-ը ճանաչում է SNI-ով, ALPN-ով և էնտրոպիայով։
Առանձին՝ Telegram-ի հաշիվը կապված է «տնային» տվյալների կենտրոնի հետ, ուստի պրոքսին պետք է հասանելիություն ունենա Telegram-ի ամբողջ ենթակառուցվածքին, ոչ թե դրա մի մասին։
Ուստի FakeTLS-ը «ռեժիմ ընդմիշտ» չէ, այլ պաշտպանության շերտերից մեկը։ Հասցեով արգելափակման դեմ այն անզոր է, իսկ սպիտակ ցանկերով շարժական ինտերնետում պրոքսին ընդհանրապես անհասանելի է։
Ինչ չի թաքցնում FakeTLS-ը
Քողարկումը վերաբերում է կապի տեսքին, ոչ թե ձեր ներկայությանը ցանցում։ Մատակարարը շարունակում է տեսնել, որ դուք միանում եք կոնկրետ սերվերի IP հասցեին, և որքան տվյալ եք փոխանցում։ Հենց պրոքսին տեսնում է ձեր IP հասցեն, ինչպես ցանկացած միջնորդ։ Նամակագրության բովանդակությունը պաշտպանված է Telegram-ի բանալիով՝ անկախ ռեժիմից, բայց FakeTLS ռեժիմից էլ կախված չէ։ Ուստի պրոքսին «անտեսանելի» անվանել չի կարելի. այն պարզապես ավելի դժվար է ճանաչել տեսքով։
Ինչպես ստուգել, որ ռեժիմը միացված է
- Նայեք secret-ին. այն պետք է սկսվի
ee-ով և նկատելիորեն 32 նիշից երկար լինի։ - Վերծանեք պոչը
xxd -r -pհրամանով և համոզվեք, որ սա անհրաժեշտ տիրույթն է։ - mtg-ով սերվերի վրա կատարեք
mtg doctor /ճանապարհ/դեպի/config.toml. հրամանը ստուգում է կարգավորումը և կապակցվածությունը։ - telemt-ով սերվերի վրա ստուգեք TLS ձեռքսեղմումը քողարկող կայքի հետ՝
curl -v -I --resolve տիրույթ:443:IP https://տիրույթ/հրամանը ցույց կտա վկայականների շղթան և գործողության ժամկետը։
Եթե ee-ով պրոքսին դադարել է աշխատել
Ռեժիմը միացված է, secret-ը ճիշտ է, իսկ պրոքսին չի միանո՞ւմ։ Պատճառները թվարկեք պարզից բարդ՝
- Ստուգեք, որ secret-ի տիրույթը դեռ բացվում է, և նրա վկայականը վավեր է։
- Համոզվեք, որ հաճախորդը թարմացված է. Telegram-ի նոր տարբերակներում TLS մատնահետքն ուղղված է։
- Ստուգեք պրոքսին այլ ցանցում. եթե այնտեղ աշխատում է, հասցեն արգելափակված չէ, խնդիրը կոնկրետ ցանցում է։
- Եթե ոչ մի տեղ չի աշխատում, սերվերի հասցեն, ամենայն հավանականությամբ, փակված է. կօգնի միայն IP հասցեի կամ նոր պրոքսիի փոփոխությունը։
- Սեփական սերվերի վրա նայեք մատյանը. mtg-ի մոտ՝
mtg doctor, telemt-ի մոտ՝ ծառայության վիճակը և հին հղումների «Unknown TLS SNI» սխալը։
FakeTLS-ը և մյուս ռեժիմները
| Ռեժիմ | Նախածանց | Ինչ է թաքցնում | Թույլ տեղը |
|---|---|---|---|
| Սովորական | չկա | Հոսքի բովանդակությունը | Կապի սկիզբը և փաթեթների ռիթմը ճանաչելի են |
| Padding | dd | Փաթեթների չափերը մասամբ | Կապի սկիզբը նախկինն է |
| FakeTLS | ee | Արձանագրությունը. թվում է TLS | Տիրույթ, հասցե, պորտ, հաճախորդի մատնահետք |
Telegram-ի փաստաթղթերում պրոքսիի տերերին խորհուրդ են տալիս հնարավորության դեպքում միացնել և՛ padding-ը, և՛ TLS emulation-ը. ռեժիմները լրացնում են իրար։
Հաճախ տրվող հարցեր
Ի՞նչ է նշանակում ee պրոքսիի secret-ում։
ee նախածանցը միացնում է FakeTLS ռեժիմը։ Դրանից հետո գալիս են բանալու 16 բայթը (32 տասնվեցական նիշ) և քողարկման տիրույթը hex տեսքով։ Հաճախորդը կապը սկսում է որպես այդ տիրույթի հետ սովորական TLS փոխանակում։
Ինչո՞վ է FakeTLS-ը տարբերվում VPN-ից։
FakeTLS-ը MTProto պրոքսիի ռեժիմ է. այն պրոքսիի հետ կապը քողարկում է որպես HTTPS, բայց աշխատում է միայն Telegram-ի համար։ VPN-ն իր միջով անցկացնում է ամբողջ սարքի տրաֆիկը և օգտագործում է սեփական արձանագրություններ։
FakeTLS պրոքսիի համար պե՞տք է իսկական կայք։
Պրոքսիի աշխատանքի համար՝ ոչ, ձեռքսեղմմանը նա ինքն է պատասխանում։ Բայց mtg-ի հեղինակները խորհուրդ են տալիս պրոքսիի առջև դնել հավանական կայք սեփական տիրույթով և վկայականով. այդ դեպքում SNI-ի անունը, DNS-ը և սերվերի պատասխանը համընկնում են, և ստուգումը անհամապատասխանություն չի գտնում։
Ի՞նչ կլինի, եթե փոխեմ քողարկման տիրույթը։
Նախկինում տրված բոլոր հղումները կդադարեն աշխատել, քանի որ տիրույթը ներդրված է secret-ում։ telemt-ի FAQ-ի համաձայն՝ հին հղմամբ հաճախորդները ստանում են «Unknown TLS SNI» սխալ. հղումները պետք է վերաթողարկել։