რატომ ამტვრევს ყველა ICMP-ის ბლოკირება მომუშავე VPN გზას

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

რას ატარებს ICMP სინამდვილეში ამ გზაზე

IPv4 გზის MTU აღმოჩენა ეფუძნება იმას, რომ მარშრუტიზატორი იტყობინება: don't-fragment ბიტის მქონე პაკეტი ვერ გაიგზავნა. ეს შეტყობინება ICMP Fragmentation Needed-ია და მის გარეშე გამგზავნს საკუთარი სეგმენტის ზომის შემცირების მიზეზი არ აქვს. IPv6 უფრო მკაცრია: მარშრუტიზატორები ტრანზიტში არ ანაწილებენ, ამიტომ ICMPv6 Packet Too Big შეტყობინება ერთადერთი სიგნალია, რომელიც გამგზავნს ამცირებს.

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

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

ჩავარდნა ზომაზეა დამოკიდებული

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

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

გაზომეთ წესების რედაქტირებამდე

შეამოწმეთ don't-fragment ბიტით და თქვენ მიერ არჩეული დატვირთვის ზომით, ჩავარდნილი კლიენტიდან დაცული მისამართისკენ:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

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

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

შევიწროეთ წესი, შემდეგ ხელახლა შეამოწმეთ დავალება

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

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

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

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