VLESS და Reality ახსნილი: როგორ ემსგავსება Xray HTTPS-ს

VLESS არის Xray პროექტის მსუბუქი proxy პროტოკოლი, რომელიც კლიენტს UUID-ით ამოწმებს და მის ტრაფიკს ატარებს; საკუთარ დაშიფვრას არ აკეთებს და ქვედა ფენას ეყრდნობა. Reality სწორედ ეს ფენაა: მოდიფიცირებული TLS 1.3, რომელიც კავშირს ნებისმიერი დამკვირვებლის თვალში რეალური და ცნობილი ვებსაიტის მონახულებად აჩვენებს - და თუ ვინმე გასაღების გარეშე სერვერს შესამოწმებლად დაუკავშირდება, ის ამ რეალურ ვებსაიტზე გადამისამართდება და მის ნამდვილ სერტიფიკატს დაინახავს. XTLS Vision, ჩვეულებრივი "flow" პარამეტრი, აქრობს TLS-ის TLS-ში გაშვების სტატისტიკურ ნიშნებს. ერთად ისინი ქმნიან tunnel-ს, რომელშიც ქსელებს, რომლებიც VPN-ებს ფორმით ბლოკავენ, ამოსაცნობი არაფერი აშკარა აქვთ. ეს პოსტი ხსნის თითოეულ ნაწილს, როგორ ახდენს Reality ავთენტიფიკაციას საკუთარი სერტიფიკატის გარეშე, რას ნიშნავს vless:// ბმულის თითოეული ველი, და სად მთავრდება შენიღბვა - რადგან არცერთი პროტოკოლი არ არის შეუმჩნეველი, და საპირისპირო განცხადებებს უნდობლობით უნდა მოეკიდო.

Xray და საიდან მოდის VLESS#

Xray-core არის ღია კოდის proxy პლატფორმა, რომელსაც Project X ინახავს (XTLS ორგანიზაცია GitHub-ზე). ის 2020 წელს დაიწყო, როგორც V2Ray-ის fork - პლატფორმისა, რომელიც ძველი VMess პროტოკოლის უკან დგას - და მას შემდეგ ამ ოჯახში ახალი სამუშაოს მთავარ სახლად იქცა. Xray-ის ერთ პროცესს შეუძლია რამდენიმე პროტოკოლზე საუბარი - VLESS, VMess, Trojan, Shadowsocks - რამდენიმე transport-ზე, ხოლო მარშრუტიზაციის წესები წყვეტს, რა სად მიდის.

Xray-ის კავშირის ნაწილები ფენებად ეწყობა ერთმანეთზე, და დაბნეულობის უმეტესობა მათი აღრევიდან მოდის:

ამრიგად, "VLESS + Reality" სერვერი არის VLESS პროტოკოლი, ჩვეულებრივ Vision flow-ით, raw transport-ზე, Reality-ით დაცული. თითოეული ცალკე პარამეტრია კონფიგურაციაში და ცალკე პარამეტრი გასაზიარებელ ბმულში.

VLESS: შეგნებულად მინიმალური#

VMess, VLESS-ის წინამორბედი, საკუთარ ტრაფიკს შიფრავდა და დროზე დაფუძნებულ ავთენტიფიკაციას იყენებდა, რაც მას უფრო მძიმეს და საათის აცდენისადმი მგრძნობიარეს ხდიდა. VLESS-მა ეს ყველაფერი მოიშორა. VLESS-ის მოთხოვნის header შეიცავს ვერსიას, კლიენტის UUID-ს, არჩევით დამატებით ბლოკს (სადაც flow არის დასახელებული), ბრძანებას და დანიშნულების მისამართსა და პორტს. სულ ეს არის.

UUID არის ავტორიზაციის მონაცემი: სერვერი ინახავს კლიენტების ID-ების სიას და ყველაფერს, რაც არ ემთხვევა, აგდებს. რადგან VLESS თავად არ შიფრავს, კონფიგურაცია ამას ცალსახად ამბობს - "decryption": "none" სერვერზე, encryption=none ბმულში - და კონფიდენციალურობა მთლიანად ქვედა security ფენიდან მოდის. VLESS-ის security: none-ით ინტერნეტზე გაშვება ყველაფერს წაკითხვადი ფორმით გაგზავნიდა; ტესტის გარეთ ეს არავინ უნდა გააკეთოს.

მინიმალიზმის სარგებელი სიჩქარე და სიმარტივეა. როცა დაშიფვრა ერთხელ ხდება, TLS-ით ან Reality-ით, ორმაგი სამუშაო არ არის, და პროტოკოლს თავისთავად ძალიან ცოტა რამ აქვს, რისი ამოცნობაც ანაბეჭდით შეიძლება.

ამოცნობის პრობლემა: ანაბეჭდები და TLS TLS-ში#

proxy-ის TLS-ში შეფუთვა - Trojan-ის და ჩვეულებრივ TLS-ზე VLESS-ის მიდგომა - მას HTTPS-ს ამსგავსებს. აღმოჩნდა, რომ ეს არ არის საკმარისი, სამი მიზეზით.

ClientHello-ს ანაბეჭდი აქვს. ყველა TLS კავშირის პირველი შეტყობინება ჩამოთვლის cipher suite-ებს, extension-ებს და მათ თანმიმდევრობას. ბრაუზერები გამორჩეულ, კარგად ცნობილ სიებს აწარმოებენ; Go-ს სტანდარტული TLS ბიბლიოთეკა, რომელზეც Xray არის დაწერილი, სხვას აწარმოებს. ქსელს, რომელიც 443 პორტზე ხედავს "ეს Go-ს ჰგავს და არა Chrome-ს", მინიშნება აქვს. ამიტომ Xray-ის კლიენტები იყენებენ uTLS-ს, რომ ბრაუზერის ClientHello ზუსტად მიბაძონ, რომელიც fingerprint პარამეტრით აირჩევა (chrome ჩვეულებრივი არჩევანია).

სერტიფიკატი საიდანღაც უნდა მოვიდეს. კლასიკურ TLS proxy-ს სჭირდება დომენი, რომელიც შენ გეკუთვნის, და მისი სერტიფიკატი. დომენი ფიქსირებული იდენტიფიკატორია, რომლის სიაში შეტანაც შეიძლება, და სერვერი, რომელიც ჰოსტინგ-პროვაიდერის IP-ზე უცნობი დომენის სერტიფიკატს აჩვენებს, ამოსაცნობ ნიმუშში ჯდება.

TLS-ს TLS-ში ფორმა აქვს. როცა HTTPS საიტს TLS-ში შეფუთული proxy-ით ათვალიერებ, ორი TLS handshake ხდება, ერთი მეორის შიგნით. შიდა handshake აწარმოებს პაკეტების ტალღას დამახასიათებელი ზომებითა და დროით, რაც გარე დაშიფვრის მიღმა სიგრძეებად და შუალედებად ჩანს. მკვლევრებმა აჩვენეს, რომ ამ ნიმუშის სტატისტიკურად ამოცნობა შესაძლებელია.

XTLS Vision, რომელიც flow: xtls-rprx-vision-ით დაყენდება, მესამე პრობლემას აგვარებს. ის შიდა handshake-ის პაკეტებს ავსებს, რომ მათი ზომები ცნობილ ნიმუშს აღარ დაემთხვეს, და როცა შიდა TLS კავშირი დამყარდება, უკვე დაშიფრული მონაცემების მეორედ დაშიფვრას წყვეტს და პირდაპირ ატარებს. შედეგად ნაკლებია ამოსაცნობი და ნაკლები CPU იხარჯება. Vision მხოლოდ raw transport-თან მუშაობს.

Reality პირველ ორს აგვარებს.

როგორ მუშაობს Reality#

Reality საკუთარი დომენისა და სერტიფიკატის საჭიროებას აქრობს სხვისი handshake-ის სესხებით. სერვერზე კონფიგურირდება target - რეალური ვებსაიტი, მაგალითად დიდი კომპანიის მთავარი გვერდი - და სერვერის სახელების (SNI მნიშვნელობების) სია, რომლებსაც ის მიიღებს, და ყველა მათგანი უნდა იყოს სახელი, რომელსაც ეს target სინამდვილეში ემსახურება.

როცა კავშირი შემოდის:

1. კლიენტი აგზავნის TLS 1.3 ClientHello-ს, რომელიც ზუსტად ბრაუზერისას ჰგავს, target-ის სახელით SNI-ად. ველებში, რომლებიც ჩვეულებრივ TLS-ში შემთხვევითია - session ID, გასაღებების გაცვლასთან ერთად - დამალულია ავთენტიფიკაციის მონაცემები, მიღებული სერვერის x25519 საჯარო გასაღებიდან და short ID-იდან.
2. სერვერი, რომელსაც შესაბამისი პირადი გასაღები აქვს, ცდილობს ამ მონაცემების გადამოწმებას. თუ ისინი სწორია, სერვერი handshake-ს თავად ასრულებს, აჩვენებს დროებით სერტიფიკატს, რომლის გადამოწმებაც კლიენტს საერთო საიდუმლოთი შეუძლია, და შიგნით VLESS tunnel ეშვება.
3. თუ სწორი არ არის - ბრაუზერი, სკანერი, ცენზორის აქტიური probe - სერვერი საკუთარი სახელით საერთოდ არ პასუხობს. ის კავშირს უცვლელად გადასცემს რეალურ target-ს. სტუმარი რეალურ TLS handshake-ს ასრულებს რეალურ ვებსაიტთან და იღებს მის ნამდვილ სერტიფიკატს და შიგთავსს.

მესამე ნაბიჯი არის ის, რაც აქტიურ probing-ს ამარცხებს. სისტემა, რომელიც სერვერს ეჭვობს და შესამოწმებლად უკავშირდება, იღებს ცნობილი ვებსაიტის სრულიად ნორმალურ ასლს. არ არის ყალბი გვერდი და არ არის self-signed სერტიფიკატი, რომლის შემჩნევაც შეიძლება.

გასაღებების წყვილი x25519-ია. სერვერი პირად გასაღებს ინახავს; კლიენტი საჯაროს იღებს. Xray-ის მიმდინარე დოკუმენტაცია კლიენტის მხარის ველს password-ს უწოდებს და არა publicKey-ს, სერვერის ველს კი target-ს და არა dest-ს; ძველი სახელები ისევ მუშაობს ალიასებად, რის გამოც გზამკვლევებში ორივე გვხვდება.

მინიმალური სერვერის კონფიგურაცია#

სერვერზე, რომელსაც თავად მართავ, დაყენება სამი გენერირებული მნიშვნელობა და ერთი JSON ფაილია. მათ xray ბინარი აგენერირებს:

$ xray uuid                        # client ID$ xray x25519                      # server key pair; keep the private key secret$ xray x25519 -i "<private key>"   # prints the public key again from the private one$ openssl rand -hex 8              # a short ID: hex, even length, up to 16 chars

{  "inbounds": [{    "listen": "0.0.0.0",    "port": 443,    "protocol": "vless",    "settings": {      "clients": [{ "id": "<uuid>", "flow": "xtls-rprx-vision" }],      "decryption": "none"    },    "streamSettings": {      "network": "raw",      "security": "reality",      "realitySettings": {        "target": "www.example.com:443",        "serverNames": ["www.example.com"],        "privateKey": "<private key>",        "shortIds": ["<short id>"]      }    }  }],  "outbounds": [{ "protocol": "freedom" }]}

network: "raw" არის მიმდინარე სახელი იმისა, რასაც ძველი ვერსიები tcp-ს უწოდებდა; ძველ Xray-ზე გამოიყენე tcp. freedom outbound გახსნილ ტრაფიკს პირდაპირ დანიშნულების ადგილას აგზავნის. production-ის კონფიგურაცია ჩვეულებრივ ამატებს მარშრუტიზაციის წესებს და blackhole outbound-ს იმ ტრაფიკზე უარის სათქმელად, რომელიც არ გინდა - მაგალითად, კავშირებზე კერძო მისამართების დიაპაზონებთან, რომ სერვერი მისივე შიდა ქსელამდე მისაღწევად ვერ გამოიყენონ.

ერთი ID თითო მოწყობილობაზე

clients მასივს შეუძლია ნებისმიერი რაოდენობის ჩანაწერის შენახვა, თითოეული საკუთარი UUID-ით, shortIds-ს კი რამდენიმე მნიშვნელობის. სერვერზე, რომელსაც თავად მართავ, თითოეული მოწყობილობისთვის ან თითოეული ადამიანისთვის საკუთარი UUID-ის მიცემა მცირე დამატებით ძალისხმევად ღირს. როცა ტელეფონი იკარგება ან მეგობარს წვდომა აღარ სჭირდება, ამ ერთ ჩანაწერს შლი და Xray-ს გადატვირთავ; ყველა სხვა მოწყობილობა იმ ბმულით აგრძელებს მუშაობას, რომელიც უკვე აქვს. ერთი საერთო UUID-ით ნებისმიერის წვდომის გაუქმება ნიშნავს ყველასთვის ახალი ბმულის გაცემას. თითოეულ კლიენტის ჩანაწერს email ველი დაამატე - ეს მხოლოდ იარლიყია და არა მისამართი, რომელსაც ოდესმე დაუკავშირდებიან - და Xray-ის ლოგები და სტატისტიკა გეტყვის, რომელ მოწყობილობას ეკუთვნის კავშირი. short ID-ები Reality-ის ფენაზე იმავენაირად მუშაობს, ხოლო სიაში ცარიელი სტრიქონი უშვებს კლიენტებს, რომლებიც short ID-ს საერთოდ არ აგზავნიან, რაც ტესტირებისთვის მოსახერხებელია და შემდეგ სჯობს წაიშალოს.

მართვადი პირადი VPN ამ ნაწილს შენ ნაცვლად აკეთებს. RE:NODE-ზე სერვერი უშვებს Xray-ს VLESS-ით და Reality-ით, აგენერირებს შენი სერვერის მისამართსა და გასაღებს და ბეჭდავს ბმულს, რომელსაც კლიენტში ჩასვამ - Renode VPN აპლიკაციაში Windows-ზე, ან ნებისმიერ VLESS კლიენტში ტელეფონებსა და Mac-ებზე.

vless:// ბმულის ანატომია#

კლიენტები კონფიგურაციებს ერთი URI-ით ცვლიან. თითოეული პარამეტრი ზემოთ აღწერილ რომელიმე პარამეტრს შეესაბამება:

vless://3f1c8a2e-...-9b7d@203.0.113.10:443  ?encryption=none  &flow=xtls-rprx-vision  &security=reality  &sni=www.example.com  &fp=chrome  &pbk=Zx9...publickey  &sid=6ba85179e30d4fc2  &type=tcp  #my-server

ბმული შეიცავს ავტორიზაციის მონაცემს და ყველაფერ დანარჩენს, რაც დასაკავშირებლად საჭიროა. ნებისმიერს, ვისაც ის აქვს, შეუძლია შენი სერვერის გამოყენება, ამიტომ პაროლივით გააზიარე და არა ჯგუფურ ჩატში. VLESS კლიენტის დაყენება განიხილავს მის იმპორტს v2rayNG-ში, Hiddify-ში, Streisand-სა და Shadowrocket-ში.

target-ის არჩევა#

საკუთარ აწყობილ სერვერზე target ერთადერთი შემოქმედებითი გადაწყვეტილებაა, და მას იმაზე მეტი მნიშვნელობა აქვს, ვიდრე ჩანს. REALITY პროექტის რეკომენდაციები და გავრცელებული პრაქტიკა მიუთითებს საიტზე, რომელიც:

• უჭერს მხარს TLS 1.3-ს და HTTP/2-ს, რადგან კლიენტის ClientHello უნდა ჰგავდეს თანამედროვე ბრაუზერს, რომელიც თანამედროვე საიტს სტუმრობს.
• არ გადამისამართებს თავის მთავარ სახელს სხვა დომენზე, რომ handshake ნორმალურად დასრულდეს.
• დამაჯერებელია შენი სერვერის ქსელიდან - დიდი საიტი, რომელიც შენი ქვეყნის გარეთ ჰოსტდება, იდეალურად სერვერებით იმავე რეგიონში, სადაც შენი, რომ ამ IP დიაპაზონიდან მასთან კავშირები უცნაური არ იყოს.
• არ დგას CDN-ის უკან, რომელიც შენს სერვერს გადამგზავნად გამოყენების საშუალებას მისცემდა. Xray-ის დოკუმენტაცია აფრთხილებს, რომ რადგან წარუმატებელი ავთენტიფიკაციები target-ზე გადაიგზავნება, CDN-ის უკან მდგარ target-ს შეუძლია შენი სერვერი სხვისი ტრაფიკის relay-ად აქციოს; limitFallbackUpload და limitFallbackDownload პარამეტრები ამას ზღუდავს.

xray tls ping www.example.com კანდიდატის TLS მხარდაჭერას თავად სერვერიდან ამოწმებს.

შენიღბვის ზღვრები#

Reality ყველაზე დამაჯერებელი მიდგომაა ფართოდ გავრცელებულთა შორის, და მაინც არ არის უხილავი. გულწრფელი ზღვრები:

• SNI და IP არ ემთხვევა. handshake ცნობილ ვებსაიტს ასახელებს; IP კი ჰოსტინგ-პროვაიდერს ეკუთვნის და არა ამ ვებსაიტს. დამკვირვებელს, რომელიც ამ ორს ადარებს - სახელის გადაწყვეტით ან სიებით, ვის რომელი დიაპაზონი ეკუთვნის - შეუძლია ეს შეამჩნიოს. target-ის არჩევა იმავე რეგიონსა და ჰოსტინგის სივრცეში სხვაობას ამცირებს; მთლიანად ვერაფერი ხურავს.
• ტრაფიკის ნიმუშები რჩება. ერთი ხანგრძლივი კავშირი, რომელიც საათობით შერეულ ტრაფიკს ატარებს "მთავარ გვერდზე", უჩვეულოა. Vision TLS-ის TLS-ში ნიმუშს ამცირებს; მოცულობისა და დროის ანალიზი უფრო ფართო პრობლემაა, რომელსაც ვერცერთი proxy ბოლომდე ვერ აგვარებს.
• IP-ების დაბლოკვა ამოცნობის გარეშეც შეიძლება. ქსელს შეუძლია მისამართი ნებისმიერი მიზეზით დაბლოკოს, მათ შორის იმიტომ, რომ მასთან ბევრი უცნობი კავშირი მიდის.
• ეს ანონიმურობა არ არის. სერვერი შენია და შენს სახელზეა ნაქირავები. Reality შუალედური ქსელისგან მალავს, რა არის tunnel; არაფერს მალავს საიტებისგან, რომლებსაც სტუმრობ და რომლებიც შენი სერვერის მისამართს ხედავენ, ან ანგარიშებისგან, რომლებშიც შედიხარ.

VPN-ის გამოყენება უმეტეს ადგილას ლეგალურია და ზოგან შეზღუდულია. იცოდე კანონი იქ, სადაც ხარ, და იმ ქსელების გამოყენების წესები, რომლებიც შენი არ არის; პროტოკოლი, რომლის ამოცნობაც ძნელია, არ ცვლის იმას, რაც ნებადართულია. რისგან იცავს VPN და რისგან არა და Xray, WireGuard თუ OpenVPN ამას კონტექსტში სვამს.

როცა არ უკავშირდება#

მესამე ხაზი არის Reality, რომელიც ჩანაფიქრისამებრ მუშაობს: კლიენტს, რომელიც ავთენტიფიკაციას ვერ გადის, ნებისმიერი უცნობივით ეპყრობიან და რეალურ საიტს აწვდიან. თუ target-ის გვერდს ხედავ, ბმული თავიდან დააიმპორტე და ველებს ხელით ნუ არედაქტირებ. საათის შემთხვევისთვის სერვერებს შეუძლიათ დააყენონ maxTimeDiff კლიენტების უარყოფისთვის, რომელთა დროც ძალიან აცდენილია; ტელეფონი გამორთული ავტომატური დროით შეიძლება ამას გადააწყდეს. რატომ არის ჩემი VPN ნელი განიხილავს შემთხვევას, როცა უკავშირდება, მაგრამ ძალიან ნელა მუშაობს.

FAQ#

დაშიფრულია VLESS?

VLESS თავად დაშიფვრას არ ამატებს, ჩანაფიქრით. დაშიფვრა security ფენიდან მოდის - TLS-იდან ან Reality-იდან - რის გამოც VLESS-ის ბმულში წერია encryption=none და security=reality. Reality-ით ტრაფიკი დაცულია TLS 1.3-ის გასაღებების გაცვლითა და დაშიფვრით.

მჭირდება დომენი Reality-ისთვის?

არა. ეს მისი ერთ-ერთი მთავარი უპირატესობაა. სერვერი target საიტის TLS handshake-ს სესხულობს, ამიტომ საკუთარი დომენი და სერტიფიკატი არ გჭირდება. კლიენტები სერვერის IP მისამართს უკავშირდებიან target-ის სახელით SNI-ად.

რა განსხვავებაა Reality-სა და ჩვეულებრივ TLS-ს შორის?

ჩვეულებრივი TLS აჩვენებს შენს საკუთარ სერტიფიკატს შენი საკუთარი დომენისთვის. Reality აჩვენებს ნასესხებ იდენტობას, კლიენტებს დამალული გასაღებების გაცვლით ამოწმებს და ყველა დანარჩენს რეალურ საიტზე გადაამისამართებს, ასე რომ სერვერის შემოწმება უჩვეულოს არაფერს ავლენს.

რომელი კლიენტები უჭერს მხარს VLESS-ს Reality-ით?

კლიენტები, რომლებიც Xray-core-ზე ან sing-box-ზეა აგებული Reality-ის მხარდაჭერით: v2rayNG Android-ზე, Hiddify რამდენიმე პლატფორმაზე, Streisand და Shadowrocket iPhone-სა და Mac-ზე, სხვებთან ერთად. კლიენტი განახლებული შეინახე; ძველი core-ები Reality-ზე ადრეა.

შეუძლია ქსელს მაინც დაბლოკოს?

კი. მას შეუძლია დაბლოკოს სერვერის IP მისამართი ან აღნიშნოს უჩვეულო ნიმუშები, პროტოკოლის გაგების გარეშე. Reality tunnel-ის ფორმით ამოცნობას ძალიან ართულებს; დაბლოკვას შეუძლებელს არ ხდის.