IPIP WireGuard-ის შიგნით: ის დამატებითი 20 ბაიტი, რომელიც არავინ არ ჩადო ბიუჯეტში
IPIP WireGuard-ის შიგნით 20 დამატებით ბაიტს ხარჯავს. ბიუჯეტი სწორ ფენაზე გაითვალისწინეთ, სანამ ცოცხალ გვირაბზე შეჩერებული გადაცემისთვის ფრაგმენტაციას დააბრალებთ.
პატარა ping-ები მთელი დღე გადის გვირაბში, SSH-ის ბანერი მოდის და შემდეგ სესია იყინება იმ მომენტში, როცა ფაილის გადაცემა იწყება. ეს ნიმუში მიუთითებს არასწორ ფენაზე დათვლილ ბაიტურ ბიუჯეტზე, სადაც გარე გვირაბი გაზომილი იყო საკუთარი ხარჯისთვის და შიდა არავინ გამოაკლო. ჩადგმული IPIP პაკეტი WireGuard-ისთვის უბრალოდ კიდევ ერთი IP პაკეტია და სწორედ ამიტომ ხარჯავს ბაიტებს, რომლებიც არასდროს გამოგიყოფიათ. შესწორება არითმეტიკაა და ის სამ ბრძანებასა და ერთ ცხრილში ეტევა.
სიმპტომი, რომელიც ამას ამხელს
ფრაგმენტაციის პრობლემა თავს იჩენს ზომით, არასდროს მისამართებით. თქვენი პარტნიორი ერთი საათის განმავლობაში პასუხობს 56-ბაიტიან ping-ს და შემდეგ დუმდება 1400 ბაიტზე, მაშინ როცა გვირაბი აწეული რჩება და არც ერთი მარშრუტი არ შეცვლილა. ხელის ჩამორთმევა ეტევა, პირველი სრული TCP ფანჯარა არა, და გადაცემა ჩერდება ჯანმრთელად გამოჩენიდან წამებში.
გაზომეთ ჭერი, სანამ რამეს შეასწორებთ, რადგან აუზომავი ჭერი ის არის, რასაც ორჯერ დაედევნებით. გაგზავნეთ ერთი ზონდი საეჭვო ზომის ქვემოთ do-not-fragment ბიტის ჩართვით, ping -M do -s 1000 10.9.0.2, შემდეგ გაიმეორეთ იმ ზომაზე, რომელიც უკვე იცით, რომ ძალიან დიდია. როცა გადაბრუნება მიჰყვება დატვირთვის ზომას და დანიშნულება უცვლელი რჩება, მარშრუტიზაცია აკეთებს თავის საქმეს და ბიუჯეტს ერთი თავსართი აკლია.
დათვალეთ ყოველი თავსართი ერთხელ, სწორ ფენაზე
დაიწყეთ გზის უმცირესი MTU-დან და არა გვირაბის ინტერფეისიდან, რადგან კედელი ორივე ბოლოზე ზემოთაა. WireGuard 60 ბაიტს ხარჯავს IPv4 გარე ტრანსპორტზე: 20 IP-ზე, 8 UDP-ზე და 32 საკუთარ თავსართზე, და 80 ბაიტს, როცა ეს ტრანსპორტი IPv6-ია. 1420-ბაიტიანი wg0 ინარჩუნებს 20 ბაიტ რეზერვს 1440-ის ქვემოთ, რომელიც 1500-ბაიტიან გზას ნამდვილად შეუძლია მიაწოდოს, და ამიტომაც ვიკიდან კოპირებული რიცხვი აქ ისევ ჯდება. დახაზეთ მთელი დასტა დიაგრამაზე, რადგან შემდეგი, ვინც MTU-ს შეცვლის, სხვაგვარად ახალ მრგვალ რიცხვს აირჩევს და თქვენს ხარვეზს მემკვიდრეობით მიიღებს.
| Layer | Bytes | Remaining |
|---|---|---|
| Path MTU on the wired link | none yet | 1500 |
| WireGuard outer: IP, UDP, WG header | 60 | 1440 |
| Slack kept for safety | 20 | 1420 (wg0) |
| IPIP header inside the tunnel | 20 | 1400 (ipip0) |
| Original IPv4 and TCP headers | 40 | 1360 payload |
მეხუთე სტრიქონია ის ადგილი, სადაც ბიუჯეტები ფუჭდება, რადგან ჩადგმული ინტერფეისის მიერ ნატარები 1400 ბაიტი უკვე შეიცავს ორიგინალური პაკეტის საკუთარ 40 ბაიტ თავსართებს. ამ ბაიტებიდან მხოლოდ 1360 აღწევს ფაილის მკითხველ პროცესამდე. მოექეცით 1400-ს როგორც აპლიკაციის დატვირთვას, როგორც ამ სვეტის გარეშე ნებისმიერი დიაგრამა გიწვევთ, და შიდა მოწყობილობა 40 ბაიტით ზედმეტად გულუხვი აღმოჩნდება კედლის წინ, რომელიც არ გაძვრა.
დააყენეთ ორი MTU ცალ-ცალკე
გადამზიდი და ჩადგმული მოწყობილობა ცალკე ობიექტებია, ამიტომ თითოეულს საკუთარი მნიშვნელობა სჭირდება. გამოიყენეთ ისინი ამ თანმიმდევრობით, რადგან ჩადგმული მოწყობილობა გადამზიდისგან არაფერს მემკვიდრეობს:
ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400დასამახსოვრებელი წესი: შიდა MTU = გარე MTU - 20, როცა IPIP გვირაბის მიერ ნატარები პაკეტი IPv4-ია, და - 40, როგორც კი შიდა პაკეტის რომელიმე მხარე IPv6 გახდება, რადგან ჩადგმული თავსართი 20 ბაიტიდან 40-მდე იზრდება. ამ გამოკლებაში სხვა არაფერი შედის. WireGuard-ის ხარჯი უკვე გაწეული იყო, როცა 1420 აირჩიეთ, და მისი ორჯერ დაკისრება ქმნის გვირაბს, რომელიც სრულყოფილად მუშაობს და ნელი რჩება მანამ, სანამ ვინმე არ გაზომავს. ის განლაგება, სადაც ორივე მოწყობილობა ატარებს მრგვალ 1400-ს, ზუსტად ამ შეცდომის ანაბეჭდია.
IPv6 ჩადგმული პაკეტის ნებისმიერ მხარეს აუქმებს ყველა ზემოთ მოცემულ რიცხვს, ამიტომ გადათვალეთ ნაცვლად იმისა, რომ რიცხვი მსგავსი საიტიდან დააკოპიროთ. გამოკლებული თავსართები 40 ბაიტია თითოეული, როგორც კი IPv6 გამოჩნდება გარე გზაზე ან ორიგინალურ დეტაგრამაში, და დატვირთვის რიცხვი ზუსტად იმდენით ეცემა.
ფაილის დაცვის წესი, რომელიც, სავარაუდოდ, არ გჭირდებათ
ორ WireGuard პარტნიორს შორის ერთადერთი, რაც მავთულზეა, UDP-ია, ამიტომ 4 პროტოკოლის შემოსული წესი, ის ნომერი, რომელსაც RFC 2003 IPv4-ის-IPv4-ში შეფუთვას ანიჭებს, არც ჩადგმულ გზას ქმნის და არც ცოცხლად ინარჩუნებს. IPIP თავსართი დაშიფრული დატვირთვის შიგნით ცხოვრობს, სადაც არც ერთი კიდური ფაილის დაცვა ვერ ხედავს. 4 პროტოკოლის გახსნა მაინც არაფერს ყიდულობს გარდა ჰოსტში კიდევ ერთი ნებადართული გზისა.
პოლიტიკა, რომელიც ხსნის ორიგინალური პაკეტის წყაროებსა და დანიშნულებებს, ეკუთვნის შეფუთვის მოხსნის შემდეგ, გვირაბის ინტერფეისებზე და მარშრუტიზაციის ცხრილში. მოათავსეთ იქ და კიდური წესი შეიძლება დახურული დარჩეს.
რას ამოწმებს WireGuard სინამდვილეში
AllowedIPs აფასებს WireGuard-ის მიერ ნატარები პაკეტის წყაროს, და რასაც ის ატარებს, IPIP-ით შეფუთული პაკეტია. ნებადართული IPIP წყარო მიიღება მაშინაც, როცა შიდა თავსართი ასახელებს ჰოსტს, რომელზეც ურჩევნია არ მარშრუტიზაცია. ამიტომ ორიგინალური წყარო არ არის ის, რაც პარტნიორმა თქვენთვის შეამოწმა, და ამ შიდა წყვილ მისამართს შეფუთვის მოხსნის შემდეგ საკუთარი აღსრულება სჭირდება.
გარსი იძლევა მარშრუტიზაციის სტრუქტურას და არა კრიპტოგრაფიის მეორე ფენას. IPIP-ის დამატებით დაცვად წოდება WireGuard-ის შიგნით სხვა დიზაინს აღწერს.
შეამოწმეთ კიბეზე და არა ერთი ping-ით
სცადეთ ზომები, რომლებიც თქვენ მიერ გამოთვლილ საზღვარს ორივე მხრიდან მოიცავს, შემდეგ დაადასტურეთ, რას ფიქრობს ბირთვი ორივე მოწყობილობაზე. როცა 1360 ბაიტი დატვირთვა პლუს 40 ბაიტი თავსართი იძლევა 1400-ს, ქვემოთ მოცემული პირველი ექო ეტევა, ხოლო მეორე ჭერიდან ერთი ბაიტით იქით ზის:
ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0ჭერის ქვემოთ სუფთა გავლა და მის ზემოთ პირველ ზომაზე ჩავარდნა ნიშნავს, რომ არითმეტიკა თავიდან ბოლომდე ძლებს. შემდეგ ხელახლა გაუშვით თავდაპირველად შეჩერებული გადაცემა, რადგან სინთეტიკური ზონდი ბიუჯეტს ამტკიცებს და გამგზავნის საკუთარი ჩაწერის ზომებზე არაფერს ამბობს. თუ ჩადგმული გზა კვლავ იტტყდება იმ ზომაზე, რომელიც თქვენ დაამტკიცეთ, რომ ეტევა, შეამოწმეთ შორეული ბოლოს შეფუთვის მოხსნა და მარშრუტები, სანამ MTU-ს კიდევ ათ ბაიტს მოაჭრით.