ფიქსირებული 1,500-ბაიტიანი შიდა პაკეტის გატანა VPN-ის გავლით

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

დაწერე ბაიტების ბიუჯეტი პროფილის რედაქტირებამდე

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

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

გამოიკვლიე underlay do-not-fragment ping-ებით

გაზომე გზა და ნუ ენდობი ინტერფეისის MTU-ს, რადგან გარე გზაზე ყველაზე პატარა რგოლია მნიშვნელოვანი. Linux-ზე, -M do აყენებს do-not-fragment ბიტს და -s იღებს ICMP payload-ს, ამიტომ 1,500-ბაიტიანი ჩარჩო პასუხობს 1,472 ბაიტი payload-ით, როცა 20-ბაიტიან IP სათაურს და 8-ბაიტიან ICMP სათაურს გამოაკლებ. ზარდე payload-ს სანამ ზონდი არ ჩავარდება, შემდეგ გადახტი jumbo ზომაზე, რომ ნახო გადაიტანს თუ არა გზა მას საერთოდ.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

გზა, რომელიც 1,472-ს ატარებს და 8,972-ზე ვარდება, ვერ გადაიტანს 1,500-ბაიტიან შიდა პაკეტს პლუს ოვერჰედი ერთ გარე პაკეტში. ეს არის პასუხი, რომელიც გჭირდებოდა VPN-ის კონფიგურაციის გახსნამდე. ის ასევე წყვეტს, შემდეგი ორი სექციიდან რომელი გეხება, ამიტომ ორი ზონდის შედეგი ბილეთის გვერდით შეინახე. აქ გამოცნობა ერთ ტექნიკურ ფანჯარას აფასებს, რადგან გვირაბი, რომელიც თავს up-ად აცხადებს, არაფერს გეუბნება ყველაზე დიდ პაკეტზე, რომელსაც გზა მიიღებს.

გაზარდე გზის MTU მხოლოდ იქ, სადაც ყველა hop თანახმაა

Jumbo ჩარჩოები end-to-end თვისებაა, და არა პარამეტრი, რომელსაც ჩართავ იმ ორ endpoint-ზე, რომელსაც შემთხვევით აკონტროლებ. გარე გზაზე ყველა კომუტატორი, როუტერი და პროვაიდერის გადაცემის წერტილი უნდა შეთანხმდეს უფრო დიდ ზომაზე, და ერთი 1,500-ბაიტიანი hop ჩუმად გადააგდებს პაკეტს, რომელიც ახლახან გაზარდე. მხოლოდ ლოკალური ინტერფეისის გაზრდა კლასიკური ნახევრად ცვლილებაა, რომელიც გვირაბს გატეხილად აჩვენებს, სანამ underlay ჩუმად აგდებს.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

შეცვალე ინტერფეისი, შემდეგ ხელახლა გამოიკვლიე იგივე გზა, სანამ სხვა რამეს შეცვლი. თუ ზონდი კვლავ ვარდება, დააბრუნე ip link set dev eth1 mtu 1500 და გადადი ფრაგმენტაციაზე იმის ნაცვლად, რომ პროვაიდერს ეკამათო ბმულზე, რომელიც არ გეკუთვნის.

გამოიყენე გვირაბის ფრაგმენტაცია, როცა underlay ვერ გაიზრდება

შიდა პაკეტის ქვემოთ არსებული მხარდაჭერილი ფრაგმენტაციის მექანიზმი საშუალებას აძლევს რამდენიმე გარე პაკეტს ერთი შიდა პაკეტი გადაიტანოს, და მოპირდაპირე გვირაბის endpoint აწყობს მათ ხელახლა, სანამ ორიგინალს სტეკს გადასცემს. Community OpenVPN-ის UDP fragment ოფცია ამ იდეის ერთი იმპლემენტაციაა და არ არის იგივე, რაც გარე პაკეტის ჩვეულებრივი IP ფრაგმენტაცია. ორივე peer-მა უნდა გაუშვას ვერსია, რომელიც ამ ფორმატს მხარს უჭერს, და მონაცემთა გზა უნდა იყოს ის, რასაც ფიქრობ: OpenVPN 3 კლიენტებსა და kernel-ით აჩქარებულ მონაცემთა არხებს განსხვავებული ლიმიტები აქვთ, ამიტომ პროფილი, რომელიც ერთ კლიენტზე მუშაობს, შეიძლება მეორეზე ჩავარდეს.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

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

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

დაადასტურე, რომ შიდა პაკეტი უცვლელად ჩამოვა

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

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

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

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