UDP ყოველთვის არ არის უფრო სწრაფი: OpenVPN-ის ტრანსპორტის არჩევა

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

რას ცვლის ტრანსპორტი სინამდვილეში

TCP უზრუნველყოფს საიმედო, დალაგებულ ბაიტურ ნაკადს და ხელახლა აგზავნის დაკარგულს, როგორც RFC 9293 განსაზღვრავს. UDP დატაგრამებს ქსელს გადასცემს, და OpenVPN ამ სოკეტზე საკუთარ საიმედოობის ფენას უშვებს. TCP-ის TCP-ში კაფსულირება ორ აღდგენის ციკლს აწყობს, ამიტომ ერთმა დაკარგულმა სეგმენტმა შეიძლება შეაკავოს შიდა ნაკადი, სანამ გარე ხელახალი გაგზავნა მოვა. სწორედ ეს ურთიერთქმედებაა UDP-ის სასარგებლოდ ნამდვილი არგუმენტი, და ის ვლინდება როგორც შეყოვნება და არა როგორც გამტარუნარიანობა.

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

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

სად იმსახურებს TCP თავის ადგილს

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

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

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

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

შეამოწმეთ, რომელი მსმენელი გაქვთ სინამდვილეში

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

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep ბეჭდავს, რაც სერვერს უთხრეს გამოიყენოს, ხოლო სოკეტების ორი სია აჩვენებს, რაზეც არის მიბმული. UDP მსმენელი მხოლოდ პირველ სიაში ჩანს, TCP მსმენელი კი მხოლოდ მეორეში, ამიტომ დაკარგული ხაზი ყველაზე სწრაფი გზაა იმ პროფილის მოსაძებნად, რომელიც არასდროს გამოყენებულა. შეადარეთ პორტიც, რადგან 1194-ზე TCP პროფილი უმეტეს წვდომის ქსელებში განსხვავებულად იქცევა, ვიდრე 443-ზე. ცვლილების შემდეგ გადატვირთეთ სერვისი და წაიკითხეთ ჟურნალის ხაზი, რომელიც კავშირზე იუწყება.

კლიენტის მხარეს დადასტურება იაფია: გაუშვით კავშირი --verb 4-ით და წაიკითხეთ ტრანსპორტის ხაზი ჟურნალში. თუ კლიენტი ამბობს UDP-ს, ხოლო სერვერი TCP-ზე ისმენს, ხელის ჩამორთმევა არასდროს იწყება და ვერც ერთი რეგულირება ვერ დაეხმარება.

შეადარეთ დატვირთვა და არა ტრანსპორტის იარლიყი

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

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

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