ჩადგმული VPN გვირაბები: რატომ ჩერდება შიდა დიდ პაკეტებზე
თითოეული გვირაბი ხარჯავს ბილიკის პაკეტების ბიუჯეტის ნაწილს, სანამ შემდეგი დაიწყება. შეკრიბეთ თავსართები და შიდა სესია ვარდება დიდ პაკეტებზე.
DNS წყდება, SSH სესია რჩება, შემდეგ კი დიდი ატვირთვა იყინება, მაშინ როცა იმავე ჰოსტზე ping კვლავ პასუხობს. ეს გაყოფა პაკეტის ზომაზე მიუთითებს და არა გატეხილ გვირაბზე. ჩადგმული გვირაბები ამას აღწევენ იმ ზომებზე, რომლებსაც არც ერთი გვირაბი მარტო ვერ მიაღწევდა. შიდა სესია რიგზეა; უბრალოდ გადაეცემა პაკეტები, რომლებიც აღარ ეტევა.
სად მიდის სინამდვილეში ბილიკის MTU
ყოველი ინკაფსულაცია ხარჯავს ბაიტებს, სანამ შემდეგი ფენა თავის რიგს მიიღებს. Ethernet ბილიკი გარე პაკეტს სთავაზობს 1500 ბაიტს, და გარე გვირაბი თავის წილს იღებს მანამ, სანამ მის შიგნით რაიმე მისამართდება. ერთი გამოცნობილი ზედნადები ღირებულება ზუსტად იმ რაოდენობით იქნება არასწორი, რამდენიც მნიშვნელოვანია.
ჩამოთვალეთ ფენები თანმიმდევრობით: წვდომის ბილიკი, გარე ტრანსპორტი, გარე გვირაბი, შიდა ტრანსპორტი, შიდა გვირაბი, აპლიკაცია. დათვალეთ თითოეული თავსართი ერთხელ და UDP ცალკე შეინახეთ გვირაბის საკუთარი თავსართისა და ტეგისგან.
WireGuard-ის ორი ფენა, ერთხელ დათვლილი
აიღეთ IPv4 წვდომის ბილიკი ერთი WireGuard გვირაბით მეორის შიგნით. გარე ფენა ხარჯავს 20 ბაიტ IPv4-ს, 8 ბაიტ UDP-ს და 32 ბაიტს WireGuard-ის მონაცემთა თავსართისა და მისი ავთენტიფიკაციის ტეგისთვის. მის შიგნით შიდა გვირაბს სჭირდება საკუთარი 20-ბაიტიანი IPv4 თავსართი და 8-ბაიტიანი UDP თავსართი მის მეორე 32 ბაიტ WireGuard ზედნადებამდე. დარჩენილი ადგილი იტევს IPv4 თავსართს, TCP თავსართს და მონაცემებს. გარე IPv6 ბილიკი ხარჯავს 40-ს 20-ის ნაცვლად და ტოვებს 1320-ს.
| Layer | Bytes |
|---|---|
| Path MTU | 1500 |
| Outer IPv4 header | 20 |
| Outer UDP header | 8 |
| Outer WireGuard header and tag | 32 |
| Inner transport IPv4 header | 20 |
| Inner UDP header | 8 |
| Inner WireGuard header and tag | 32 |
| Innermost IPv4 header | 20 |
| TCP header | 20 |
| Payload that fits | 1340 |
არითმეტიკა 1340 ბაიტზე ჩერდება. ერთი ფენა იმავე წესებით ტოვებს 1400-ს TCP-ის სასარგებლო დატვირთვისთვის, ანუ 1500 გამოკლებული 20, 8, 32, 20 და 20, და 60 ბაიტის სხვაობა ზუსტად ის შიდა ინკაფსულაციაა, რომელსაც მეორე გვირაბი ამატებს.
გამოიყენეთ 1400 ჩადგმულ ბილიკზე და შიდა გვირაბს 60 ბაიტი აკლია, უხილავად, სანამ პაკეტი საკმარისად დიდი არ გახდება მათთვის. შევსება და პროტოკოლის საკუთარი ფრაგმენტაციის ოფცია კვლავ ცვლის რიცხვებს, ამიტომ ცხრილს ენდეთ.
MTU, MSS და ფრაგმენტაცია სხვადასხვა ადგილას მოქმედებს
ინტერფეისის MTU ზღუდავს იმას, რასაც ინტერფეისი გამოუშვებს, ხოლო TCP MSS შეკუმშვა ცვლის იმას, რისი გაგზავნაც TCP პარტნიორს სურს. შეკუმშვა ასწორებს TCP სესიებს და არაფერს აკეთებს დიდი UDP დატაგრამისთვის, ასე გამოიყურება შესწორება წარმატებულად ერთი აპლიკაციისთვის და ჩუმად ტოვებს გამოტოვებულს შემდეგს. პროტოკოლის საკუთარი ფრაგმენტაციის ოფცია მესამე ბერკეტია თავისი წარუმატებლობებით. ინტერფეისის MTU ჩვეულებრივი პირველი ნაბიჯია და ყველაზე უხეში.
ხიდოვანი და მარშრუტიზებული გვირაბები სხვადასხვა კადრს ატარებენ, ამიტომ სხვა განლაგების რიცხვები იშვიათად გადადის. ბილიკის MTU აღმოჩენა, რომელიც აღწერილია RFC 8201-ში, ეხმარება მხოლოდ მანამ, სანამ მისგან დამოკიდებული ICMP შეტყობინებები გატარებულია.
ნაკლული ფენის პოვნა
შეამოწმეთ თითოეული გვირაბი ცალკე, სანამ ჩადგამთ, თუ მოთხოვნები შედარებას იძლევა. ფიქსირებული ზომის ზონდი წყვეტს ამას: ping -M do -s 1472 -c 3 10.8.0.1 აგზავნის სრულ 1500-ბაიტიან IPv4 პაკეტს იმ ფენის შიგნით. დაამატეთ მეორე ფენა და გაიმეორეთ იგივე ზონდი, რომ ნებისმიერი წარუმატებლობა ცნობილ ცვლილებას ეკუთვნოდეს.
როცა გადაცემა ჭედავს, შეცვალეთ ერთი დოკუმენტირებული პარამეტრი ერთდროულად და ჩაწერეთ ჩავარდნილი ზომა. შეამოწმეთ დაბრუნების ბილიკიც, რადგან ჩადგმული მარშრუტების რეკურსიამ შეიძლება პაკეტის ზომის პრობლემა საკმარისად ზუსტად მიბაძოს, რომ ნახევარი დღე დაგიჯდეთ. გაფილტრულმა ICMP პასუხმა შეიძლება დამალოს ნამდვილი ზღვარი, ამიტომ ზონდი უფრო მნიშვნელოვანია, ვიდრე მსჯელობა.
დაწერეთ ბიუჯეტი იქ, სადაც შემდეგი ადამიანი იპოვის
ცხრილი თითო სტრიქონით თითოეული ფენისთვის უფრო დიდხანს ძლებს, ვიდრე ცერის წესი. შეინახეთ იგი გვირაბის სქემის გვერდით, რომ არავინ გაიმეოროს არითმეტიკა ზეწოლის ქვეშ.
მეტი გვირაბი ნიშნავს მეტ დამოკიდებულებას, ამიტომ უკან დაბრუნების გეგმა თავის ადგილს იმსახურებს ბიუჯეტის გვერდით. თუ რიცხვები მაინც არ იკრიბება, გაზომეთ ბილიკი, ნაცვლად იმისა, რომ კვლავ გამოიცნოთ. მიზანია რიცხვი, რომელსაც დაიცავთ, და არა რომელსაც დაიმახსოვრებთ.