OpenVPN PPPoE-ზე: შევამციროთ link-mtu, tun-mtu თუ mssfix?

Ping პასუხობს, DNS წყვეტს, და ყველა გვერდი, რომელსაც სრული ზომის სეგმენტი სჭირდება, ჩერდება. არხზე, რომელიც საკუთარ კაფსულაციას ამატებს, გზა ჩუმად კარგავს რამდენიმე ათეულ ბაიტს ბიუჯეტიდან, და სუფთა Ethernet-ისთვის დაწერილი პროფილი ისევ ითხოვს პაკეტებს, რომლებსაც ხაზი ვერ წაიღებს. კავშირი არ არის ნელი; ის ზუსტად იმ პაკეტებს აგდებს, რომლებიც მნიშვნელოვანია.

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

სამი ღილაკი, სამი განსხვავებული დონე

link-mtu გარე ბიუჯეტია: დაშიფრული დატვირთვა პლუს OpenVPN-ის თავსართი, UDP-ის თავსართი და გარე IP თავსართი. ის აღწერს, რა გადის მანქანიდან, და ამიტომ სწორედ ეს რიცხვი შემოიფარგლება ფიზიკური გზით.

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

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

თუ link-mtu-ს ცხადად დააყენებთ, OpenVPN აკლებს საკუთარ ხარჯს შიდა MTU-ს გამოსაყვანად. ეს ხარჯი ფიქსირებული მუდმივა არ არის; ის დამოკიდებულია შიფრზე და ავთენტიფიკაციაზე, ამიტომ ფორუმიდან კოპირებული მნიშვნელობა სხვა პროფილზე შეიძლება არასწორი იყოს. ორივეს, link-mtu-ს და tun-mtu-ს, დაყენება კლიენტს ორ ურთიერთსაწინააღმდეგო მითითებას აძლევს.

გაზომეთ გზა ნებისმიერი რიცხვის არჩევამდე

გაზომეთ ფიზიკური ინტერფეისიდან და არა გვირაბის შიგნიდან, და გახსოვდეთ, რომ ping აცნობებს დატვირთვას და არა პაკეტის ზომას. სანამ დატვირთვას 1500 ბაიტიან კადრს შეადარებთ, დაამატეთ 28 ბაიტი IPv4-ისა და ICMP-ის თავსართებისთვის, და გაითვალისწინეთ ეს შესწორება, როცა პარტნიორი სხვა რიცხვს აცნობებს.

Linux კლიენტზე ping -M do -s 1472 კრძალავს ფრაგმენტაციას და ვარდება, თუ პაკეტი ძალიან დიდია. შეამცირეთ დატვირთვა, სანამ გაივლის, შემდეგ დაამატეთ 28 გზის MTU-ს მისაღებად. PPPoE 8 ბაიტი ღირს, ამიტომ DSL-ზე 1492 ნორმალურია. DS-Lite და ზოგიერთი მობილური გზა 40 ან მეტი ღირს, და პასუხი ჩვეულებრივ უფრო დაბალია, ვიდრე ნომინალური არხის სიჩქარე გვთავაზობს.

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

ჯერ TCP შეზღუდეთ, შემდეგ გვირაბი შეამცირეთ

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

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

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

რატომ აგრძელებენ პატარა ცდები მუშაობას

DNS მოთხოვნები, ICMP ექოები და TCP-ის ხელის ჩამორთმევა ყველა ვარდნილი ზომაზე ბევრად დაბლაა. ამიტომ გვირაბი ყოველ სწრაფ ტესტში ჯანმრთელად გამოიყურება, სანამ TLS-ის ხელის ჩამორთმევა და HTTP პასუხები ჩუმად ვარდება. სწორედ ეს კომბინაცია, მომუშავე traceroute და ბრაუზერი, რომელიც პირველ დიდ პასუხზე ჩერდება, არის ნიშანი, რომელიც უნდა ვეძებოთ. სანამ ახალ პროფილს მიმართავთ, სრული ზომის ცდას მიმართეთ.

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

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