Հիմունքներ

FakeTLS. ինչպես է պրոքսին կայք ձևացնում

Ինչ է նշանակում ee նախածանցը secret-ում և ինչու է քողարկման տիրույթի ընտրությունից կախված՝ պրոքսին կդիմանա մինչև երեկո, թե ոչ։

Բովանդակություն 16 բաժին

FakeTLS-ը MTProto պրոքսիի ռեժիմ է, որում կապը թվում է HTTPS կայք սովորական այցելություն։ Այն միացնում է secret-ի մեկ մանրուք՝ ee նախածանցը։ Ստորև՝ ինչ կա այդ նախածանցի հետևում, ինչպես է անցնում ձեռքսեղմումը, ինչպես ընտրել քողարկման տիրույթ և ինչ սխալներ են ամենից հաճախ կոտրում ռեժիմը։

Ինչ է նշանակում ee նախածանցը

Պրոքսիի հղման վերջին պարամետրն է։ Եթե այն սկսվում է 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 հաղորդագրությամբ, որում հաճախորդը դաշտում նշում է անհրաժեշտ կայքը։ FakeTLS-ը կրկնում է այս տեսքը, ուստի ֆիլտրի համար առաջին փաթեթները թվում են կայք սովորական մուտք։

  1. Հաճախորդն ուղարկում է ClientHello secret-ի տիրույթով։ Դրա մեջ կան տվյալներ, որոնցով պրոքսին ճանաչում է «իր» հաճախորդին։
  2. Պրոքսին ստուգում է դրանք և պատասխանում է այնպես, ինչպես կպատասխաներ TLS սերվերը։
  3. Հետո հաստատված կապով գնում է սովորական MTProto հոսք՝ փաթեթավորված TLS-ին նման գրառումներում։
  4. Եթե եկել է ոչ թե պրոքսիի հաճախորդ, այլ պատահական այցելու, սկաներ կամ ստուգող, պրոքսին իրեն չի բացահայտում. կապը փոխանցում է իսկական կայքին և վերադարձնում է նրա իրական պատասխանը։

Վերջին կետը ակտիվ ստուգումից պաշտպանությունն է։ mtg-ն սա կոչում է domain fronting. եթե հարցումը մերժված է, պրոքսին միանում է քողարկող կայքին և փոխանցում է տրաֆիկը, ուստի ստուգողը տեսնում է իսկական կայքի պատասխանը։ Telemt-ը նույնն անում է mask կարգավորմամբ. չճանաչված կապերը գնում են իրական վեբ սերվերին։

Ինչ է տեսնում ֆիլտրը

TSPU սարքավորման և համակարգերի համար FakeTLS կապը սա է՝

  • կապ ձեր սերվերի IP հասցեի հետ՝ 443 պորտով;
  • ClientHello՝ հանրահայտ կայքի անունով SNI-ում;
  • TLS սերվերի պատասխանին նման պատասխան;
  • հետո՝ գաղտնագրված գրառումների հոսք, ինչպես ցանկացած HTTPS-ում։

Այդպիսի կապն իսկականից տարբերելու համար ֆիլտրը պետք է փնտրի նուրբ անհամապատասխանություններ. տիրույթի և IP հասցեի չհամապատասխանությունը, ClientHello-ի ոչ բնորոշ ընդլայնումները, հոսքի վիճակագրությունը։ Իսկ պարզապես փակել «այն ամենը, ինչ նման է հանրահայտ կայքի հետ HTTPS-ի», չի լինում՝ առանց սովորական օգտատերերին վնասելու։

Ինչպես ընտրել քողարկման տիրույթ

Տիրույթը ռեժիմի թույլ տեղն է։ Դրանից է կախված՝ մատակարարը կնկատի անհամապատասխանությունը, թե ոչ։ Իրականացումների հեղինակների խորհուրդներից կազմվում է հետևյալ ցանկը՝

  • սովորական կայք, որը ձեր ցանցում արգելափակված չէ։ Եթե տիրույթը օպերատորի մոտ անհասանելի է, դրա հետ կապը կասկածելի է թվում, և հղումը կարող է չաշխատել (telemt-ի խորհուրդ);
  • սերվերի հասցեի հետ կապված տիրույթ։ mtg-ի README-ն զգուշացնում է. մատակարարները կարող են նկատել, որ google.com-ը տանում է այնպիսի IP, որը Google-ին չի պատկանում։ Խորհուրդը՝ ընտրել այն հոսթինգի տիրույթը, որտեղ կանգնած է VPS-ը (օրինակ՝ digitalocean.com DigitalOcean-ի սերվերի համար);
  • լավագույնը՝ սեփական տիրույթը։ mtg-ի BEST_PRACTICES-ում խորհուրդ է տրվում գրանցել տիրույթ և ուղղել այն VPS-ին. այդ դեպքում DNS-ը և SNI-ն համընկնում են, և ստուգումը անհամապատասխանություն չի գտնում;
  • չպատճենել կայք սեփական ենթացանցից։ Նույն խորհուրդների համաձայն՝ DNS-ով այդպիսի ստուգումը պարզ է, իսկ հասցեն կարելի է արգելափակել;
  • խոշոր բրենդ չվերցնել։ Խոշոր կայքը հեշտ է ստուգել DNS-ով. պատասխանները չեն համընկնի ձեր սերվերի հետ։

Կարևոր է

Եթե վստահ չեք, mtg-ի README-ն խորհուրդ է տալիս լրացուցիչ կարգավորումները չփոխել. «եթե վստահ չեք, ոչինչ մի դիպչեք»։

Ինչպես ստուգել ընտրված տիրույթը

Տիրույթը secret-ի մեջ ներդնելուց առաջ ստուգեք այն այնպես, ինչպես կանի մատակարարը՝

  1. Տիրույթը բացվում է ձեր ցանցից։ Եթե օպերատորի մոտ այն անհասանելի է, դրա հետ կապը տարօրինակ է թվում. curl -I https://տիրույթ/-ը պետք է պատասխան վերադարձնի։
  2. Ձեռքսեղմումն անցնում է ձեր հասցեի վրա։ curl -v -I --resolve տիրույթ:443:IP https://տիրույթ/ հրամանը հարցումը ստիպողաբար ուղղում է անհրաժեշտ IP հասցեին և ցույց է տալիս TLS ձեռքսեղմումը, վստահության շղթան և վկայականի գործողության ժամկետը։
  3. Վկայականը վավեր է։ telemt-ի FAQ-ում որպես օրինակ նշված է վկայական, որի ժամկետը լրացել է 2026 թվականի մարտի 1-ին, և նշված է, որ կայքի արդիականությունը պետք է ստուգել առանձին։
  4. DNS-ը համընկնում է սերվերի հասցեի հետ։ Իդեալական է, եթե անունը մատնանշում է հենց ձեր VPS-ը. ամենավատ տարբերակը օտար խոշոր կայքն է։

Ստուգումը արժե կրկնել. կայքերը փոխում են վկայականներն ու հասցեները, և այսօր հավանական թվացող տիրույթը մեկ ամիս անց կարող է դադարել բացվել։

Օրինակ. տիրույթի նախապատրաստումը քայլ առ քայլ

Սխեման, որ խորհուրդ են տալիս mtg-ի BEST_PRACTICES-ում, հանգում է նրան, որ այն ամենը, ինչ կարող է ստուգել մատակարարը, իրար հետ համընկնի՝

  1. Գրանցեք սեփական տիրույթ և A գրառմամբ ուղղեք այն VPS-ի IP հասցեին։ Այժմ այդ անվան DNS պատասխանը մատնանշում է ձեր սերվերը։
  2. Պրոքսիի առջև դրեք հավանական կայք. մի քանի սովորական HTML էջ և Let's Encrypt-ի կամ այլ սերտիֆիկացման կենտրոնի վկայական։
  3. Ստեղծեք այդ տիրույթի secret-ը՝ mtg generate-secret --hex ձեր-տիրույթ.example։
  4. Գործարկեք պրոքսին 443 պորտով։ Սովորական այցելուներն ու ստուգողները կտեսնեն կայքը, իսկ հղմամբ հաճախորդները՝ պրոքսին։
  5. Ստուգեք կապը հեռախոսից շարժական ինտերնետով, ոչ թե տնային 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-ը ճիշտ է, իսկ պրոքսին չի միանո՞ւմ։ Պատճառները թվարկեք պարզից բարդ՝

  1. Ստուգեք, որ secret-ի տիրույթը դեռ բացվում է, և նրա վկայականը վավեր է։
  2. Համոզվեք, որ հաճախորդը թարմացված է. Telegram-ի նոր տարբերակներում TLS մատնահետքն ուղղված է։
  3. Ստուգեք պրոքսին այլ ցանցում. եթե այնտեղ աշխատում է, հասցեն արգելափակված չէ, խնդիրը կոնկրետ ցանցում է։
  4. Եթե ոչ մի տեղ չի աշխատում, սերվերի հասցեն, ամենայն հավանականությամբ, փակված է. կօգնի միայն IP հասցեի կամ նոր պրոքսիի փոփոխությունը։
  5. Սեփական սերվերի վրա նայեք մատյանը. mtg-ի մոտ՝ mtg doctor, telemt-ի մոտ՝ ծառայության վիճակը և հին հղումների «Unknown TLS SNI» սխալը։

FakeTLS-ը և մյուս ռեժիմները

ՌեժիմՆախածանցԻնչ է թաքցնումԹույլ տեղը
ՍովորականչկաՀոսքի բովանդակությունըԿապի սկիզբը և փաթեթների ռիթմը ճանաչելի են
PaddingddՓաթեթների չափերը մասամբԿապի սկիզբը նախկինն է
FakeTLSeeԱրձանագրությունը. թվում է 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» սխալ. հղումները պետք է վերաթողարկել։

Աղբյուրներ

  1. Telegram: պրոքսիներ (padding-ի և TLS emulation-ի խորհուրդներ)
  2. mtg: README — secret-ներ, domain fronting, տիրույթի ընտրություն
  3. mtg: BEST_PRACTICES
  4. telemt: README
  5. telemt: FAQ
  6. RFC 6066, բաժին 3՝ Server Name Indication
  7. Telegram: MTProto transports