რატომ არის VPN ნელი? მანძილი, overhead, MTU და გზა

VPN ნელია ხუთიდან ერთ-ერთი მიზეზის გამო და, როგორც კი გაზომავ, მათი ერთმანეთისგან გარჩევა ადვილია. მანძილი: ყოველი პაკეტი ახლა VPN სერვერამდე და უკან მოგზაურობს, და თუ სერვერი შორსაა, ამას ყოველი კავშირი იხდის. დანაკარგი გზაზე: TCP მკვეთრად ნელდება, როცა პაკეტები იკარგება, ხოლო გრძელი გზა ამის მეტ შანსს იძლევა. CPU: დაშიფვრა პროცესორის დროს ხარჯავს კლიენტზეც და სერვერზეც, და პატარა სერვერი ან ძველი როუტერი ჭერს ეჯახება. MTU: შეფუთული პაკეტები აღარ ეტევა, ზოგი ჩუმად იკარგება, და ზოგიერთი საიტი იჭედება, სხვები კი ნორმალურად მუშაობს. და ქსელი შუაში: პროვაიდერი, რომელიც შენს ტრაფიკს სერვერამდე ცუდად ატარებს, ანელებს ტრაფიკს, რომელსაც ვერ ცნობს, ან უბრალოდ საღამოობით გადატვირთულია. სიჩქარის ტესტი VPN-ით და მის გარეშე, ping სერვერამდე, ერთი MTU ტესტი და ერთი mtr გაშვება გეტყვის, რომელია.

პოსტის დანარჩენი ნაწილი ხსნის, როგორ ჩაატარო ეს ტესტები, როგორ წაიკითხო ისინი და რა ასწორებს თითოეულ მიზეზს - მათ შორის გულწრფელ პასუხს, როცა გამოსავალი "შენთან უფრო ახლოს მდგარი სერვერია", რასაც ვერცერთი პარამეტრი ვერასდროს ჩაანაცვლებს.

გაზომე, სანამ რამეს შეცვლი#

ერთდროულად ერთი რამ შეცვალე და დაიწყე ციფრებით. ხუთი გაზომვა თითქმის ყველა შემთხვევას ფარავს:

1. სიჩქარის ტესტი გამორთული VPN-ით, VPN სერვერის ლოკაციასთან ახლოს მდგარ სატესტო სერვერამდე.
2. იგივე ტესტი ჩართული VPN-ით.
3. ping VPN სერვერის მისამართამდე გამორთული VPN-ით, ერთი წუთის განმავლობაში, საშუალოსა და დანაკარგის ჩანიშვნით.
4. mtr (ან WinMTR, ან pathping Windows-ზე) VPN სერვერის მისამართამდე, ასევე გამორთული VPN-ით.
5. დიდი პაკეტებით ping ტესტი MTU-სთვის, რომელიც ქვემოთაა აღწერილი.

გამორთული VPN-ით ტესტი ჩაატარე VPN სერვერთან ახლოს მდგარ სერვერამდე და არა შენთან ახლოს მდგარამდე. სხვა შემთხვევაში მოკლე გზას გრძელს ადარებ და მანძილის გამო tunnel-ს ადანაშაულებ.

მანძილი და რატომ ჯდება ის დაყოვნებაზე მეტი#

სინათლე ოპტიკურ ბოჭკოში მილიწამში დაახლოებით 200 კმ-ს გადის, ასე რომ გზის ყოველი 1,000 კმ ორმხრივ დროს დაახლოებით 10 ms-ს მატებს, სანამ პაკეტს რომელიმე მოწყობილობა შეეხება. რეალური მარშრუტები სწორ ხაზზე გრძელია. დაყოვნება, jitter და packet loss შეიცავს ცხრილს რეალისტური ციფრებით სხვადასხვა ქალაქიდან ფრანკფურტამდე.

დაყოვნება მხოლოდ ნელ შეგრძნებას არ იწვევს. ის ზღუდავს, რა სიჩქარით შეუძლია ერთ TCP კავშირს მუშაობა, თუ საერთოდ არის რაიმე დანაკარგი. სასარგებლო უხეში მოდელი (Mathis-ის ფორმულა, კლასიკური congestion control-ისთვის) ამბობს, რომ TCP კავშირის გამტარუნარიანობა მაქსიმუმ დაახლოებით სეგმენტის ზომაა, გაყოფილი ორმხრივ დროზე, გამრავლებულზე დანაკარგის წილის კვადრატულ ფესვზე.

ეს მიიღე როგორც ფორმის ილუსტრაცია და არა პროგნოზი: თანამედროვე congestion control, მაგალითად BBR, შემთხვევითი დანაკარგის მიმართ გაცილებით ნაკლებად მგრძნობიარეა, ბრაუზერები კი ერთდროულად რამდენიმე კავშირს ხსნიან. გაკვეთილი მაინც ძალაშია. VPN სერვერამდე მანძილის გაორმაგება დაახლოებით ორჯერ ამცირებს იმას, რისი გატარებაც დანაკარგიან ხაზს ერთ კავშირზე შეუძლია, და სწორედ ამიტომ შეიძლება VPN, რომელიც დილით კარგად მუშაობს, დატვირთულ საღამოს გაფუჭებული გეჩვენოს.

VPN მანძილს ამატებს ყოველთვის, როცა სერვერი იმ გზაზე არ დგას, საითაც მიდიხარ. თუ ბერლინში ხარ და საიტი ფრანკფურტშია, VPN ფრანკფურტში თითქმის არაფერი ჯდება. თუ საიტიც ბერლინშია, ყოველი პაკეტი ახლა ფრანკფურტამდე და უკან მიდის.

პროტოკოლის overhead და დაშიფვრის ფასი#

ყოველი VPN თითოეულ პაკეტს header-ებს ამატებს. გამტარუნარიანობის ფასი მცირეა:

თუ შენი VPN ხაზზე 5%-ით ნელია, ეს overhead-ია და გამოსასწორებელი არაფერია. თუ 50%-ით ნელია, ეს სხვა რამეა.

დაშიფვრა CPU-ს ხარჯავს, და ფასი გამტარუნარიანობასთან ერთად იზრდება. ბოლო რამდენიმე წლის ტელეფონები და ლეპტოპები წამში ასობით მეგაბიტს უპრობლემოდ შიფრავენ. სუსტი წერტილებია ძველი როუტერები, რომლებზეც VPN კლიენტი მუშაობს, იაფი single-board კომპიუტერები და პატარა სერვერები. სერვერის მხარეს ფასი ბაიტზეა ყველა მიერთებულ მოწყობილობაზე, ასე რომ სერვერს, რომელსაც მთელი ოჯახი ერთდროულად იყენებს, მეტი CPU სჭირდება, ვიდრე ერთი ტელეფონის სერვერს.

CPU-ის ჭერი ციფრებში ჩანს: გამტარუნარიანობა ერთსა და იმავე ციფრზე ჩერდება, რაც არ უნდა სწრაფი იყოს ხაზი, ხოლო კლიენტის ან სერვერის CPU-ის გრაფიკი ტესტის განმავლობაში ზღვარზე დგას. ჰოსტინგზე მყოფ სერვერზე CPU-ის მკაცრი ლიმიტით ეს ლიმიტი ჭერია; ხაზის მეტი სიჩქარე არ დაგეხმარება, უფრო დიდი გეგმა - კი.

MTU: როცა ზოგი საიტი იჭედება, სხვები კი კარგად მუშაობს#

MTU-ის კლასიკური სიმპტომი იმდენად უცნაურია, რომ თავისთავად დიაგნოზს სვამს: VPN უერთდება, პატარა რამეები მუშაობს, ზოგიერთი საიტი ან დიდი ჩამოტვირთვა კი სამუდამოდ ჩერდება. რაც ხდება: შეფუთული პაკეტები ახლა იმაზე დიდია, ვიდრე გზაზე რომელიმე რგოლი იძლევა, ზედმეტად დიდი პაკეტები იკარგება, ხოლო შეტყობინებას, რომელმაც გამგზავნს პატარების გამოყენება უნდა უთხრას (ICMP "fragmentation needed"), სადღაც firewall ბლოკავს. პატარა პაკეტები გადის, დიდები ქრება.

Ethernet-ის სტანდარტული MTU 1,500 ბაიტია. PPPoE კავშირებს, რომლებიც DSL-ზე და ზოგ ოპტიკურ ხაზზე გავრცელებულია, 1,492 აქვთ. მობილურ ქსელებსა და ზოგ tunnel-ს ნაკლები აქვს. WireGuard-ის ხელსაწყოები tunnel-ის MTU-ს ნაგულისხმევად 1420-ზე აყენებს, 1,500-ბაიტიანი გზისა და IPv6 overhead-ის დაშვებით; PPPoE ხაზზე 1,412 ან ნაკლები უფრო უსაფრთხოა.

იპოვე ყველაზე დიდი პაკეტი, რომელიც ფრაგმენტაციის გარეშე გადის. Payload-ის ზომა პლუს 28 ბაიტი (20 IP header, 8 ICMP header) არის გზის MTU.

Windows:  ping -f -l 1472 1.1.1.1Linux:    ping -M do -s 1472 1.1.1.1macOS:    ping -D -s 1472 1.1.1.1

თუ 1472 "needs to be fragmented" ან "message too long" შეცდომით ვერ გადის, ზომა შეამცირე, სანამ არ გაივლის. თუ 1464 გადის, გზის MTU 1,492-ია, PPPoE-ის მნიშვნელობა. შემდეგ tunnel-ის MTU დააყენე გზის MTU-ზე გამოკლებული VPN-ის overhead.

Xray-ზე დაფუძნებულ კავშირებზე ეს გაცილებით ნაკლებად მოქმედებს, ვიდრე WireGuard-სა და OpenVPN-ზე, რადგან ისინი IP პაკეტებს კი არ ფუთავენ, არამედ TCP ნაკადებს აპროქსებენ: თითოეული მხარე TCP-ის საკუთარ სეგმენტების ზომის შერჩევას იყენებს რეალური გზის მიმართ. VPN ან TUN რეჟიმში მომუშავე კლიენტებს მაინც აქვთ ვირტუალური ინტერფეისი MTU-ის პარამეტრით, და იქ უჩვეულოდ მაღალმა მნიშვნელობამ UDP აპლიკაციებთან პრობლემები შეიძლება გამოიწვიოს; ნაგულისხმევი მნიშვნელობები გონივრულია, ასე რომ დატოვე ისინი, თუ გაზომილი მიზეზი არ გაქვს.

ქსელი შუაში#

ხშირად tunnel კარგადაა, გზა კი, რომელზეც ის გადის - არა.

პროვაიდერის მარშრუტიზაცია. შენი პროვაიდერი წყვეტს, როგორ მიაღწევს შენი ტრაფიკი VPN სერვერის ქსელამდე, რომელი transit პროვაიდერებითა და რომელი გაცვლის წერტილებით. ცუდმა მარშრუტმა შეიძლება 30 ms და გზაზე გადატვირთული რგოლი დაამატოს. mtr აჩვენებს, სად ხტება დაყოვნება და სად იწყება დანაკარგი; traceroute-ისა და mtr-ის კითხვა ხსნის, როგორ გაარჩიო რეალური დანაკარგი როუტერისგან, რომელიც უბრალოდ probe-ებზე პასუხებს დაბალ პრიორიტეტს ანიჭებს.

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

Shaping და throttling. ზოგი ქსელი შეგნებულად ანელებს ტრაფიკს, რომელსაც VPN-ად აკლასიფიცირებს, ან საერთოდ საერთაშორისო ტრაფიკს. კარგი ტესტია ერთსა და იმავე ხაზზე შეადარო VPN, რომელიც VPN-ს ჰგავს, და ის, რომელიც ჩვეულებრივ HTTPS-ს ჰგავს: თუ შენიღბული უფრო სწრაფია, გზაზე რაღაც პროტოკოლებს სხვადასხვაგვარად ეპყრობა.

შენი საკუთარი wifi. სანამ უფრო შორს რამეს დაადანაშაულებ, კაბელით გატესტე. ლეპტოპს, რომელიც როუტერიდან ორი კედლითაა დაშორებული გადატვირთულ 2.4 GHz არხზე, თავისთავად შეუძლია პაკეტების რამდენიმე პროცენტის დაკარგვა, და როგორც ზემოთ ცხრილი აჩვენებს, დანაკარგი სწორედ ისაა, რაც TCP-ს ყველაზე მეტად სძულს.

TCP TCP-ის შიგნით და UDP TCP-ის შიგნით#

ის, თუ როგორ ატარებს VPN ტრაფიკს, ცვლის, როგორ რეაგირებს ის დანაკარგზე.

• WireGuard და OpenVPN UDP-ზე შენს პაკეტებს UDP-ში ფუთავენ. თუ ერთი დაიკარგა, შიგნით მყოფი TCP კავშირი ამას ამჩნევს და აღდგება. ხელახალი გაგზავნის ერთი ფენა, რომელიც ნორმალურად იქცევა.
• OpenVPN TCP-ზე შენს TCP კავშირებს სხვა TCP კავშირში ფუთავს. როცა პაკეტი იკარგება, ორივე ფენა საკუთარი ტაიმერებით აგზავნის ხელახლა, და მუდმივი დანაკარგის დროს შიდა კავშირის გამტარუნარიანობა შეიძლება ჩამოიშალოს. OpenVPN TCP-ზე გამოიყენე მხოლოდ მაშინ, როცა UDP დაბლოკილია.
• Xray ნაკადებს აპროქსებს: შენი TCP კავშირი კლიენტზე მთავრდება და სერვერზე ახალი იწყება, ხოლო ბაიტები შუაში TLS კავშირით გადაიტანება. ეს ვებ-ტრაფიკისთვის ორმაგი ხელახალი გაგზავნის პრობლემას აცილებს. UDP ტრაფიკი, მაგალითად თამაშები და ზარები, იმავე TCP კავშირით გადაიცემა, ასე რომ დაკარგული პაკეტი მის უკან ყველაფერს აკავებს, სანამ ხელახლა არ გაიგზავნება. სუფთა გზაზე ეს შეუმჩნეველია; დანაკარგიანზე რეალური დროის აპები ჭედავს.

ბოლო პუნქტი არის მიზეზი, რის გამოც ცენზურისადმი მდგრადი VPN თამაშების ამაჩქარებელი არ არის. ამცირებს თუ არა VPN ping-ს თამაშებში განიხილავს, როდის ეხმარება tunnel თამაშს და როდის მხოლოდ მანძილს ამატებს.

პრობლემები მოწყობილობაზე#

Proxy რეჟიმი VPN რეჟიმის ნაცვლად. ბრაუზერი proxy-ზე გადის, ჩამოტვირთვების მენეჯერი ან თამაშის launcher - არა, და შენ არასწორ რამეს ტესტავ. შეამოწმე, რომელ რეჟიმში მუშაობს კლიენტი.

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

უსაფრთხოების პროგრამა, რომელიც HTTPS-ს ამოწმებს. ანტივირუსები, რომლებიც TLS-ს წყვეტენ, ყოველ კავშირს საკუთარ დამუშავებას ამატებენ, VPN-ით თუ მის გარეშე, და ზოგი VPN ადაპტერებთან ცუდად თავსდება.

ორი VPN. სამსახურის VPN და პირადი, ან VPN და firewall აპი, რომელიც ლოკალურ VPN-ად მუშაობს, გადაფარულ მარშრუტებსა და არაპროგნოზირებად გზებს გაძლევს.

DNS შორეულ ბოლოში. სრული tunnel-ით ყოველი ახალი hostname სერვერამდე ერთ ორმხრივ მოგზაურობას ჯდება, სანამ საიტთან კავშირი საერთოდ დაიწყება. 100 ms გზაზე გვერდი, რომელიც ოცდაათ დომენს მიმართავს, მის გამტარუნარიანობაზე ნელი გეჩვენება. ეს DNS-ის გაჟონვის თავიდან აცილების ფასია, და ბრაუზერების საკუთარი ქეში ამას პირველი ვიზიტის შემდეგ არბილებს.

პირადი სერვერი: რისი გამოსწორება შეგიძლია და რისი - არა#

საკუთარ სერვერზე ხუთიდან ორი მიზეზი ნაწილობრივ შენს კონტროლშია. CPU: RE:NODE-ის პირად VPN ხაზზე გეგმები იმის მიხედვით არის გათვლილი, რამდენი მოწყობილობა იყენებს სერვერს ერთდროულად, CPU-ის წილი მკაცრი ლიმიტია, ხოლო პანელის გრაფიკები CPU-ს ამ ლიმიტთან მიმართებაში აჩვენებს, ასე რომ ჭერს ხედავ და არა გამოიცნობ. და კონკურენცია: შენს სერვერზე სხვა არავინაა, ასე რომ მისთვის მხოლოდ შენი მოწყობილობები ეჯიბრებიან. რამდენი მოწყობილობა VPN-ზე ზომის შერჩევას განიხილავს.

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

FAQ#

სიჩქარის რამდენი დანაკარგია ნორმალური VPN-ით?

ახლოს მდგარი სერვერითა და ძლიერი მოწყობილობით ხაზის სიჩქარეზე 5-15%-ით ნაკლები ნორმალურია - ძირითადად overhead და ოდნავ გრძელი გზა. ნახევრის ან მეტის დაკარგვა მიუთითებს მანძილზე, დანაკარგზე, CPU-ის ჭერზე ან MTU-ის პრობლემაზე, და ზემოთ მოცემული გაზომვები გეტყვის, რომელზე.

რატომ არის ჩემი VPN სწრაფი მობილურ ინტერნეტზე და ნელი wifi-ზე?

VPN იგივეა, ასე რომ განსხვავება ლოკალური ქსელია: wifi-ის სიგნალი და ინტერფერენცია, სახლის როუტერი ან პროვაიდერის სხვა მარშრუტი სერვერამდე. ჯერ კაბელით გატესტე, რომ wifi გამორიცხო, შემდეგ კი ორივე ქსელიდან mtr შეადარე.

აჩქარებს თუ არა VPN-ს უფრო სწრაფი ინტერნეტ-პაკეტი?

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

უნდა დავწიო თუ არა MTU, რომ VPN დავაჩქარო?

მხოლოდ იმ შემთხვევაში, თუ დიდი პაკეტების ტესტი აჩვენებს, რომ გზა სრული ზომის პაკეტებს ვერ ატარებს, ან ხედავ კლასიკურ სიმპტომს, როცა ზოგი საიტი იჭედება. MTU-ის დაწევა, როცა ყველაფერი რიგზეა, გამტარუნარიანობას ოდნავ ამცირებს, რადგან ყოველი პაკეტი იმავე header-ებით ნაკლებ მონაცემს ატარებს.

რატომ არის ჩემი VPN საღამოობით უფრო ნელი?

სავარაუდოდ გადატვირთვაა შენს პროვაიდერსა და იმ ქსელებს შორის, რომლებიც ტრაფიკს სერვერამდე ატარებენ - საღამოს პიკი ამ რგოლებს ავსებს. გაუშვი mtr წყნარ დროს და ნელ დროს და შეადარე, სად ჩნდება დანაკარგი.